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!”

This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More

There’s a VMWare problem that’s being exploited in the wild, according to the NSA (PDF). The vulnerability is a command injection on an administrative console. The web host backing this console is apparently running as root, as the vulnerability allows executing “commands with unrestricted privileges on the underlying operating system.”

The wrinkle that makes this interesting is that VMWare learned about this vuln from the NSA, which seems to indicate that it was a zero-day being used by a foreign state. The compromise chain they list is also oddly specific, making me suspect that it is a sanitized account of observed attacks.

Microsoft Teams, And the Non-CVE

[Oskars Vegeris] found a pair of interesting problems in the Microsoft Teams client, which together allows an interactionless, wormable RCE. The first vuln is an XSS problem, where a message containing a “mention” can be modified in transit to include arbitrary Javascript. To get that JS past the XSS protection filter, a unicode NULL byte is included in the payload. The second vuln is using the built-in file download code in the Teams app to download and auto-run a binary. Put together, anyone who simply loads the message in their Teams app runs the code.

Vegeris points out that since so many users have a presence in multiple rooms, it would be trivial to use this exploit to build a worm that could infect the majority of Teams users worldwide. The bug was reported privately to Microsoft and fixed back in October. A wormable RCE in a widely used tool seems like a big deal, and should net a high CVE score, right? Microsoft gave two ratings for this attack chain, for the two versions of Teams that it can affect. For the Office365 client, it’s “Important, Spoofing”, which is about as unimportant as a bug can be. The desktop app, at least, was rated “critical” for an RCE. The reason for that seems to be that the sandbox escape only works on the standalone desktop app.

But no CVE was issued for the exploit chain. In the security community, collecting CVEs is an important proof of work for your resume. Microsoft replied that they don’t issue CVEs for products that get updated automatically without user interaction. Kerfuffle ensued. Continue reading “This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More”

This Week In Security: IOS Wifi Incantations, Ghosts, And Bad Regex

I hope everyone had a wonderful Thanksgiving last week. My household celebrated by welcoming a 4th member to the family. My daughter was born on Wednesday morning, November 25th. And thus explains what I did last week instead of writing the normal Hackaday column. Never fear, we shall catch up today, and cover the news that’s fit to be noticed.

iOS Zero-click Wifi Attack

[Ian Beer] of Google’s Project Zero brings us the fruit of his lockdown-induced labors, a spectacular iOS attack. The target of this attack is the kernel code that handles AWDL, an Apple WiFi protocol for adhoc mesh networks between devices. The most notable feature that makes use of AWDL is AirDrop, Apple’s device-to-device file sharing system. Because AWDL is a proprietary protocol, the WiFi hardware can’t do any accelerated processing of packets. A few years back, there was an attack against Broadcom firmware that required a second vulnerability to jump from the WiFi chip to the device CPU. Here, because the protocol is all implemented in Apple’s code, no such pivot is necessary.

And as you’ve likely deduced, there was a vulnerability found. AWDL uses Type-Length-Value (TLV) messages for sending management data. For a security researcher, TLVs are particularly interesting because each data type represents a different code path to attack. One of those data types is a list of MAC addresses, with a maximum of 10. The code that handles it allocates a 60 byte buffer, based on that maximum. The problem is that there isn’t a code path to drop incoming TLVs of that type when they exceed 60 bytes. The remainder is written right past the end of the allocated buffer.

There is more fun to be had, getting to a full exploit, but the details are a bit too much to fully dive in to here. It interesting to note that [Ian] ran into a particular problem: His poking at the target code was triggering unexpected kernel panics. He discovered two separate vulnerabilities, both distinct from the vuln he was trying to exploit.

Finally, this exploit requires the target device to have AWDL enabled, and many won’t. But you can use Bluetooth Low Energy advertisements to trick the target device into believing an Airdrop is coming in from a trusted contact. Once the device enables AWDL to verify the request, the attack can proceed. [Ian] reported his findings to Apple way back in 2019, and this vulnerability was patched in March of 2020.

Via Ars Technica.
Continue reading “This Week In Security: IOS Wifi Incantations, Ghosts, And Bad Regex”