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

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

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

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.

OpenWRT Security Notice

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

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

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

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”

This Week In Security: SolarWinds And FireEye, WordPress DDoS, And Enhance!

The big story this week is Solarwinds. This IT management company supplies network monitoring and other security equipment, and it seems that malicious code was included in a product update as early as last spring. Their equipment is present in a multitude of high-profile networks, like Fireeye, many branches of the US government, and pretty much any other large company you can think of. To say that this supply chain attack is a big deal is an understatement. The blame has initially been placed on APT42, AKA, the Russian hacking pros.

The attack hasn’t been without some positive effects, as Fireeye has released some of their internal tooling as open source as a result. Microsoft has led the official response to the attack, managing to win control of the C&C domain in court, and black-holing it.

The last wrinkle to this story is the interesting timing of the sale of some Solarwinds stock by a pair of investment firms. If those firms were aware of the breech, and sold their shares before the news was made public, this would be a classic case of illegal insider trading. Continue reading “This Week In Security: SolarWinds And FireEye, WordPress DDoS, And Enhance!”