This Week In Security: Morse Code Malware, Literal And Figurative Watering Holes, And More

February 12, 2021 by Jonathan Bennett 6 Comments

Code obfuscation has been around for a long time. The obfuscated C contest first ran way back in 1984, but there are examples of natural language obfuscation from way earlier in history. Namely Cockney rhyming slang, like saying “Lady from Bristol” instead of “pistol” or “lump of lead” instead of “head”. It’s speculated that Cockney was originally used to allow the criminal class to have conversations without tipping off police.

Code obfuscation in malware serves a similar purpose — hiding from security devices and applications. There are known code snippets and blacklisted IP addresses that anti-malware software scans for. If that known bad code can be successfully obfuscated, it can avoid detection. This is a bit of a constant game of cat-and-mouse, as the deobfuscation code itself eventually makes the blacklist. This leads to new obfuscation techniques, sometimes quite off the wall. Well this week, I found a humdinger of an oddball approach. Morse Code.

Yep, dots and dashes. The whole attack goes like this. You receive an email, claiming to be an invoice. It’s a .xlsx.hTML file. If you don’t notice the odd file extension, and actually let it open, you’re treated to a web page. The source of that page is a very minimal JS script that consists of a morse code decoder, and a payload encoded in Morse. In this case, the payload is simply a pair of external scripts that ask for an Office 365 login. The novel aspect of this is definitely the Morse Code. Yes, our own [Danie] covered this earlier this week, but it was too good not to mention here. Continue reading “This Week In Security: Morse Code Malware, Literal And Figurative Watering Holes, And More” →

This Week In Security: Perl.com, The Great Suspender, And Google’s Solution

February 5, 2021 by Jonathan Bennett 46 Comments

Perl has been stolen. Well, perl.com, at least. The perl.com domain was transferred to a different registrar on January 27, without the permission of the rightful owner. The first to notice the hack seems to have been [xtaran], who raised the alarm on a Reddit thread. The proper people quickly noticed, and started the process of getting control of the domain again. It seems that several other unrelated domains were also stolen in the same attack.

I’ve seen a couple of theories tossed around about how the domains were stolen. With multiple domains being moved, it initially seemed that the registrar had been compromised in some way. One of the other victims was told that a set of official looking documents had been supplied, “proving” that the attacker was the rightful owner of the domain. In any case, the damage is slowly being unwound. Perl.com is once again in the proper hands, evidenced by the proper SSL certificate issued back in December.

The Great Suspender, Suspended

I was greeted by a particularly nasty surprise on Thursday of this week. One of the Chrome extensions I’ve come to rely on was removed by Google for containing malware. The Great Suspender automatically hibernates unused tabs, saving ram and processor cycles that would otherwise be spent on those 150 open tabs that should really be bookmarks. What happened here?

I’ll point out that I’m extremely careful about installing extensions. It’s code written by a third party, often very difficult to inspect, and can view and modify the sites you visit. You can manage what sites an extension has access to, but for a tool like the Suspender, it essentially needs access to all of them. The solution is to use open source extensions, right? “Well yes, but actually no.” Suspender is open source, after all. The link above goes to the project’s Github page. In that repo you’ll find an announcement from last year, that the founding developer is finished with the project, and is selling the rights to an unknown third party, who took over maintainership. If this sounds familiar, there are echoes of the event-stream debacle.

It’s not clear exactly what malicious behavior Google found that led to the extension being pulled, but a more careful look at the project reveals that there were potential problems as early as October of 2020. An addition to the extension introduced execution of code from a remote server, never a good idea. For what it’s worth, the original maintainer has made a statement, defending the new owners, and suggesting that this was all an innocent mistake.

The lesson here? It’s not enough to confirm that an extension checks the “open source” box. Make sure there is an active community, and that there isn’t a 6 month old bug report detailing potentially malicious activity.

Libgcrypt

It’s not everyday you see a developer sending out a notice that everyone should stop using his latest release. That’s exactly what happened with Libgcrypt 1.9.0. Our friends over at Google’s Project Zero discovered an extremely nasty vulnerability in the code. It’s a buffer overflow that happens during the decryption process, before even signature verification. Since libgcrypt is used in many PGP implementations, the ramifications could be nasty. Receive an encrypted email, and as soon as your client decrypts it, code is executing. Thankfully, an update that fixes the issue has already been released.

Android Botnet

A new botnet is targeting Android devices in a peculiar way — looking for open ADB debug ports exposed to the Internet. Google makes it very clear that ADB over the network is insecure, and should only be used for development purposes, and on controlled networks. It’s astounding that so many vendors ship hardware with this service exposed. Beyond that, it’s surprising that so many people give their Android devices public IP addresses (or IPv6 addresses that aren’t behind a firewall). The botnet, named Matryosh, has another unique feature, as it uses Tor for command and control functions, making it harder to track.

Google Solution to Open-Source Security

Google published a post on their open source blog, giving an overview for their new framework for the security of open source projects. “Know, Prevent, Fix” is their name for the new effort, and it must have been written by management, because it’s full of buzzwords. The most interesting elements are their goals for critical software. They identify problems like the ability of a single maintainer to push bad code into a project, and how anonymous maintainers is probably a bad idea. It will be interesting to see how these ideas develop, and how Google will help open source communities implement them.

Microsoft in My Pi

And finally, I was amused by an article lamenting the inclusion of the VSCode repository in the default Raspberry Pi OS images. He does raise a couple legitimate points. Amont them, you do send a ping to Microsoft’s servers every time you check for new updates.

The larger point is that the official VSCode binaries have telemetry code added to them — code that isn’t in the open source repository. What is it doing? You don’t know. But it probably violates European law.

Want to use VSCode, but not interested in shipping info off to Microsoft? VSCodium is a thing.

This Week In Security: Sudo, Database Breaches, And Ransomware

January 29, 2021 by Jonathan Bennett 27 Comments

We couldn't resist, OK? — Obligatory XKCD

Sudo is super important Linux utility, as well as the source of endless jokes. What’s not a joke is CVE-2021-3156, a serious vulnerability around incorrect handling of escape characters. This bug was discovered by researchers at Qualys, and has been in the sudo codebase since 2011. If you haven’t updated your Linux machine in a couple days, you may very well be running the vulnerable sudo binary still. There’s a simple one-liner to test for the vulnerability:

sudoedit -s '\' `perl -e 'print "A" x 65536'`

In response to this command, my machine throws this error, meaning it’s vulnerable:

malloc(): corrupted top size Aborted (core dumped)

To understand the problem with sudo, we have to understand escape characters. It really boils down to spaces in file and folder names, and how to deal with them. You want to name your folder “My Stuff”? That’s fine, but how do you interact with that directory name on the command line, when spaces are the default delimiter between arguments? One option is to wrap it in quotation marks, but that gets old in a hurry. The Unix solution is to use the backslash character as an escape character. Hence you can refer to your fancy folder as My\ Stuff. The shell sees the escape character, and knows to interpret the space as part of the folder name, rather than an argument separator. Escape characters are a common vulnerability location, as there are plenty of edge cases. Continue reading “This Week In Security: Sudo, Database Breaches, And Ransomware” →

This Week In Security: OpenWRT, Favicons, And Steganographia

January 22, 2021 by Jonathan Bennett 29 Comments

OpenWRT is one of my absolute favorite projects, but it’s had a rough week. First off, the official OpenWRT forums is carrying a notice that one of the administrator accounts was accessed, and the userlist was downloaded by an unknown malicious actor. That list is known to include email addresses and usernames. It does not appear that password hashes were exposed, but just to be sure, a password expiration has been triggered for all users.

The second OpenWRT problem is a set of recently discovered vulnerabilities in Dnsmasq, a package installed by default in OpenWRT images. Of those vulnerabilities, four are buffer overflows, and three are weaknesses in how DNS responses are checked — potentially allowing cache poisoning. These seven vulnerabilities are collectively known as DNSpooq (Whitepaper PDF). Continue reading “This Week In Security: OpenWRT, Favicons, And Steganographia” →

This Week In Security: Ubiquiti, Nissan, Zyxel, And Dovecot

January 15, 2021 by Jonathan Bennett 27 Comments

You may have been one of the many of us who received an email from Ubiquiti this week, recommending a password change. The email stated that there was an unauthorized access of Ubiquiti systems, and while there wasn’t evidence of user data being accessed, there was also not enough evidence to say emphatically that user data was not accessed. Ubiquiti has mentioned that the database that may have been accessed contains a user’s name, email address, hashed password, and optionally the mailing address and phone number.

Depending on how the Ubiquiti authentication system is designed, that hashed password may be enough to log in to someone’s account. In any case, updating your password would invalidate the potentially compromised hash. This event underscores a complaint voiced by Ubiquiti users: Ubiquiti has been making it difficult to administrate hardware without a cloud-enabled account. Continue reading “This Week In Security: Ubiquiti, Nissan, Zyxel, And Dovecot” →

This Week In Security: Android Bluetooth RCE, Windows VMs, And HTTPS Everywhere

January 8, 2021 by Jonathan Bennett 5 Comments

Android has released it’s monthly round of security updates, and there is one patched bug in particular that’s very serious: CVE-2021-0316. Few further details are available, but a bit of sleuthing finds the code change that fixes this bug.

Fix potential OOB write in libbluetooth Check event id if of register notification command from remote to avoid OOB write.

It’s another Bluetooth issue, quite reminiscent of BleedingTooth on Linux. In fact, in researching this bug, I realized that Google never released their promised deep-dive into Bleedingtooth. Why? This would usually mean that not all the fixes have been rolled out, or that a significant number of installations are unpatched. Either way, the details are withheld until the ramifications of releasing them are minimal. This similar Bluetooth bug in Android *might* be why the BleedingTooth details haven’t yet been released. Regardless, there are some serious vulnerabilities patched this in this Android update, so make sure to watch for the eventual rollout for your device. Continue reading “This Week In Security: Android Bluetooth RCE, Windows VMs, And HTTPS Everywhere” →

This Week In Security: Deeper Dive Into SolarWinds, Bouncy Castle, And Docker Images

December 31, 2020 by Jonathan Bennett 13 Comments

Merry Christmas and happy holidays! I took Christmas day off from writing the security roundup, coming in a day early with this week’s installment, dodging New year’s day. The SolarWinds story has continued to dominate the news, so lets dive into it a bit deeper.

Microsoft has published their analysis of Solorigate, and the details are interesting. The added code was carefully written to blend in with the rest of the code, using the name OrionImprovementBusinessLayer.Initialize, which sounds like a perfectly boring-yet-legitimate function. The actual backdoor is obfuscated using zip compression and base64 encoding.

Once this bootstrap code begins, it runs a series of checks before actually doing anything malicious. It waits 2 weeks after installation to do anything, and then checks the system domain name for any indication it’s running in a test environment. It then checks for certain security applications, like Wireshark, and refuses to run if they are detected. This series of checks all seem to be an effort to avoid detection, and to only run in a deployed environment. Even the Command and Control URL that the backdoor uses is constructed to appear benign. Beyond this, it seems that the malware simply waited for instructions, and didn’t take any automated actions. All the attacks were performed manually.

Continue reading “This Week In Security: Deeper Dive Into SolarWinds, Bouncy Castle, And Docker Images” →