Author: Jonathan Bennett

527 Articles

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

December 31, 2020 by 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” →

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

December 18, 2020 by 11 Comments

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

December 11, 2020 by 9 Comments

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

CentOS Is Dead, Long Live CentOS

December 9, 2020 by 53 Comments

On Tuesday, December 8th, Red Hat and CentOS announced the end of CentOS 8. To be specific, CentOS 8 will reach end of life at the end of 2021, 8 years ahead of schedule. To really understand what that means, and how we got here, it’s worth taking a trip down memory lane, and looking at how the history of Red Hat Enterprise Linux (RHEL), CentOS, and IBM are intertwined.

Continue reading “CentOS Is Dead, Long Live CentOS” →

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

December 4, 2020 by 8 Comments

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

This Week In Security: SAD DNS, Incident Documentation Done Well, And TCL Responds

November 20, 2020 by 6 Comments

One of the big stories from the past few days is the return of DNS cache poisoning. The new attack has been dubbed SADDNS, and the full PDF whitepaper is now available. When you lookup a website’s IP address in a poisoned cache, you get the wrong IP address.

This can send you somewhere malicious, or worse. The paper points out that DNS has suffered a sort of feature creep, picking up more and more responsibilities. The most notable use of DNS that comes to mind is LetsEncrypt using DNS as the mechanism to prove domain ownership, and issue HTTPS certificates.

DNS Cache poisoning is a relatively old attack, dating from 1993. The first iteration of the attack was simple. An attacker that controlled an authoritative DNS server could include extra DNS results, and those extra results would be cached as if they came from an authoritative server. In 1997 it was realized that the known source port combined with a non-random transaction ID made DNS packet spoofing rather trivial. An attacker simply needs to spoof a DNS response with the appropriate txID, at the appropriate time to trick a requester into thinking it’s valid. Without the extra protections of TCP connections, this was an easy task. The response was to randomize the txID in each connection.

I have to take a moment to talk about one of my favorite gotchas in statistics. The Birthday paradox. The chances that two randomly selected people share a birthday is 1 in 365. How many people have to be in a room together to get a 50% chance of two of them sharing a birthday? If you said 182, then you walked into the paradox. The answer is 23. Why? Because we’re not looking for a specific birthday, we’re just looking for a collision between dates. Each non-matching birthday that walks into the room provides another opportunity for the next one to match.

This is the essence of the DNS birthday attack. An attacker would send a large number of DNS requests, and then immediately send a large number of spoofed responses, guessing random txIDs. Because only one collision is needed to get a poisoned cache, the chances of success go up rapidly. The mitigation was to also randomize the DNS source port, so that spoof attempts had to have both the correct source port and txID in the same attempt. Continue reading “This Week In Security: SAD DNS, Incident Documentation Done Well, And TCL Responds” →

This Week In Security: Platypus, Git.bat, TCL TVs, And Lessons From Online Gaming

November 13, 2020 by 9 Comments

Git’s Large File System is a reasonable solution to a bit of a niche problem. How do you handle large binary files that need to go into a git repository? It might be pictures or video that is part of a project’s documentation, or even a demonstration dataset. Git-lfs’s solution is to replace the binary files with a text-based pointer to where the real file is hosted. That’s not important to understanding this vulnerability, though. The problem is that git-lfs will call the main git binary as part of its operation, and when it does so, the full path is not used. On a Unix system, that’s not a problem. The $PATH variable is used to determine where to look for binaries. When git is run, /usr/bin/git is automagically run. On a Windows system, however, executing a binary name without a path will first look in the current directory, and if a matching executable file is not found, only then will the standard locations be checked.

You may already see the problem. If a repository contains a git.exe, git.bat, or another git.* file that Windows thinks is executable, git-lfs will execute that file instead of the intended git binary. This means simply checking out a malicious repository gets you immediate code execution. A standard install of git for Windows, prior to 2.29.2.2, contains the vulnerable plugin by default, so go check that you’re updated!

Then remember that there’s one more wrinkle to this vulnerability. How closely do you check the contents of a git download before you run the next git command? Even with a patched git-lfs version, if you clone a malicious repository, then run any other git command, you still run the local git.* file. The real solution is pushing the local directory higher up the path chain. Continue reading “This Week In Security: Platypus, Git.bat, TCL TVs, And Lessons From Online Gaming” →