Denial-of-Service (DoS) amplification. Relatively early in the history of the Internet — it was only 14 years old at the time — the first DoS amplification attack was discovered. [TFreak] put together smurf.c, likely in 1997, though it’s difficult to nail the date down precisely.
The first real DoS attack had only happened a year before, in 1996. Smurf worked by crafting ICMP packets with spoofed source addresses, and sending those packets to a network’s broadcast address. A host that received the request would send the packet to the target, and if multiple hosts responded, you got a bigger DoS attack for free. Fast forward to 1999, and the first botnet pulled off a Distributed DoS, DDoS, attack. Ever since then, there’s been an ongoing escalation of DDoS traffic size and the capability of mitigations.
DNS and NTP quickly became the popular choice for amplification, with NTP requests managing an amplification factor of 556, meaning that for every byte an attacker sent, the amplifying intermediary would send 556 bytes on to the victim. You may notice that so far, none of the vulnerable services use TCP. The three-way handshake of TCP generally prevents the sort of misdirection needed for an amplified attack. Put simply, you can’t effectively spoof your source address with TCP.
There are a pair of new games in town, with the first being a clever use of “middleboxes”, devices like firewalls, Intrusion Prevention Systems, and content filters. These devices watch traffic and filter content or potential attacks. The key here is that many such devices aren’t actually tracking TCP handshakes, it would be prohibitively memory and CPU intensive. Instead, most such devices just inspect as many packets as they can. This has the unexpected effect of defeating the built-in anti-spoofing of TCP.
An attacker can send a spoofed TCP packet, no handshake required, and a vulnerable middlebox will miss the fact that it’s spoofed. While that’s interesting in itself, what’s really notable is what happens when the packet appears to be a request for a vulnerable or blocked resource. The appliance tries to interrupt the stream, and inject an error message back to the requester. Since the requestor can be spoofed, this allows using these devices as DDoS amplifiers. As some of these services respond to a single packet with what is essentially an entire web page to convey the error, the amplification factor is literally off the charts. This research was published August 2021, and late February of this year, researchers at Akamai have seen DDoS attacks actually using this technique in the wild.
The second new technique is even more alien. Certain Mitel PBXs have a stress-test capability, essentially a speed test on steroids. It’s intended to only be used on an internal network, not an external target, but until a recent firmware update that wasn’t enforced. For nearly 3,000 of these devices, an attacker could send a single packet, and trigger the test against an arbitrary host. This attack, too, has recently been seen in the wild, though in what appears to be test runs. The stress test can last up to 14 hours at worst, leading to a maximum amplification factor if over four billion, measured in packets. The biggest problem is that phone systems like these a generally never touched unless there’s a problem, and there’s a decent chance that no one on sight has the login credentials. That is to say, expect these to be vulnerable for a long time to come.
Dirty Pipe
This Linux vulnerability was found in the wild — not as a vulnerability, but just a regular old bug. [Max Kellermann] of CM4all had a customer that was seeing corrupted log archives. A single corrupted file isn’t unheard of, but this was the same daily log archive, corrupted in the same way repeatedly. This sort of reproducibility tends to make developers excited, because it means a specific bug that can be tracked down and fixed. So, he started looking for a bug in his code. After eliminating his own code as the culprit, he eventually concluded this was a kernel bug.
When you have excluded the impossible, whatever remains, however improbable, must be the truth.
— Sherlock Holmes
The bug turned out to be CVE-2022-0847, demonstrated by a pair of simple programs:
#include <unistd.h>
int main(int argc, char **argv) {
for (;;) write(1, "AAAAA", 5);
}
// ./writer >foo
and
#define _GNU_SOURCE
#include <unistd.h>
#include <fcntl.h>
int main(int argc, char **argv) {
for (;;) {
splice(0, 0, 1, 0, 2, 0);
write(1, "BBBBB", 5);
}
}
// ./splicer <foo |cat >/dev/null
I was able to replicate this bug on one of my machines, by first creating a file, touch foo. Next, start the splicer program running: ./splicer /dev/null. Then finally run the writer program: ./writer >foo Let it run for a few seconds, and then terminate both processes. If there is no vulnerability, then foo will only contain a long string of “AAAAA”s. On the machine with a vulnerable kernel, grep revealed a multitude of “BBBBB”s mixed in.
The key here is the logic behind splice(). This system call is extremely useful for moving data quickly, as it asks the kernel to do the data copy between file descriptors without the need to move any bits into userspace. The problem is that you can call a splice on a pipe, a one-way communication tool, from the wrong side. In the example code above, the redirect operator < is used to read data from a file into a process’s standard input. Under the hood, that uses a pipe, and you can splice() into that pipe. The syscall moves the requested data into a cache, and then a check is performed as to whether the splice is allowed to complete. An old quirk relating to how this cache was handled was finally turned into a serious bug by a refactor in Linux 5.8. Suddenly, some of those splice() requests complete when they shouldn’t.
This bug allows any user to write data to any file they have read access on. That’s bad. There are a couple caveats — mainly that the user must have write access to the file to be tampered with. On my system, that means that /root/.ssh/authorized_keys can’t be tampered with. Next, this vulnerability can’t change the size of a file — it will only overwrite data, and that overwrite can’t include the first character of the file. At first glance, this blunts the severity quite a bit, but there’s another approach that a slightly more sophisticated actor could use: modifying setuid binaries. If you can change binaries, you can introduce your own vulnerability. In short? This vulnerability gives elevation to root to anyone with an interactive shell.
More Lapsus$ News
This story keeps giving, and there are a bunch of developments to cover. First, part of the Nvidia leak that has been released was an old signing key. Rather then being a useless proof of the hack, this has proven to be a potent tool for attackers. Why? Windows honors drivers signed with expired signatures. And already, the leaked sig has been used in attacks.
LAPSUS$ extortion group have successfully breached both NVIDIA & Samsung.
-March 1st: They demand NVIDIA open-source its drivers, or else they will
-March 4th: LAPSUS$ released Samsung proprietary source code.
See attached images for more details directly from LAPSUS$ pic.twitter.com/U3VD7R2KRl
— vx-underground (@vxunderground) March 4, 2022
The next turn in this story is that Samsung has been breached by the same group, and nearly 200 GB of that data has been released. Keys and source code are part of the release, so watch out for more developments as researchers and malware authors work through that trove.
Bits and Bytes
There’s a rather hilarious occurrence, that also manages to be extremely annoying, when a Google ad manages to trigger Google Assistant on the very device that plays the ad. Leave it to security researchers, to find a way to weaponize this quirk of modern devices. Approach #1 is a malicious radio station. Just like listening to your favorite tech podcast, and the host accidentally mentions Alexa. Some of the details have been patched, but smart devices can still be vulnerable in some cases.
Google has announced their acquisition of Mandiant, one of the larger cybersecurity firm. This is the group that led the investigation of both the SolarWinds and Colonial Pipeline attacks. Google’s plan is to put this new subsidiary in their cloud division, in order to bulk up their security offerings. Read more at Google’s announcement.
There’s a series of bugs found in the VoipMonitor platform, the worst of which being an RCE chain. VoipMonitor is used to monitor VoIP traffic — it’s right there in the name — and keep track of jitter and call quality. The fixes have landed in 24.97, so if your organization uses this software, make sure it’s up-to-date!
A pair of Firefox vulnerabilities have been patched, both use-after-free problems. Present in both Firefox and Thunderbird, these flaws have been reported to be in use in the wild. The fixes landed in Firefox 97.0.2 and Thunderbird 91.6.2.
Adafruit has announced a breach of customer data. A data set built from real data was being used for employee training, and when that employee left the company, a GitHub repository was unintentionally made public with that data. The data exposed was limited, and affected users are being notified via email.
And finally, [Troy Hunt] is back with a devilish idea — the kind of mischief we can get behind. Tired of spammers, he is creating a password purgatory to send these malcontents to. To accomplish their spammy ends, a spammer just needs to create an account. Except, of course, this is purgatory. No matter what password is chosen, it violates some odd password rule. You want to use P@ssw0rd!337? Sorry, this password must not contain two “s” characters in a row. P@5sw0rd!337 This password must include at least two capitol letters. Ad nauseum. Will it dissuade any spammers from their annoying ways? Probably not, but we can look forward to a write-up on the fallout after the project is finished and run for a while.
11 March 2022
>> Read More