Researchers at Eset have published a huge report on the Ebury malware/botnet (pdf), and one of the high profile targets of this campaign was part of the kernel.org infrastructure. So on one hand, this isn’t new news, as the initial infection happened back in 2011, and was reported then. On the other hand, according to the new Eset report, four kernel.org servers were infected, with two of them possibly compromised for as long as two years. That compromise apparently included credential stealing or password cracking.

The Ebury attackers seem to gain initial access through credential stuffing — a huge list of previously captured credentials are tried one at a time. However, once the malware has a foothold in the network, a combination of automated and manual steps are taken to move laterally. The most obvious is to grab any private SSH keys from that system, and try using them to access other machines on the local network. Ebury also replaces a system library that gets called as a part of sshd, libkeyutils.so. This puts it in a position to quietly capture credentials.

For a targeted attack against a more important target, the people behind Ebury seem to go hands-on-keyboard, using techniques like Man-in-the-Middle attacks against SSH logins on the local network using ARP spoofing. In this case, someone was doing something nasty.

And that doesn’t even start to cover the actual payload. That’s nasty too, hooking into Apache to sniff for usernames and passwords in HTTP/S traffic, redirecting links to malicious sites, and more. And of course, the boring things you might expect, like sending spam, mining for Bitcoin, etc. Ebury isn’t exactly easy to notice, either, since it includes a rootkit module that hooks into system functions to hide itself. Thankfully there are a couple of ways to get a clean shell to look for the malware, like using systemd-run or launching a local shell on the system console.

And the multi-million dollar question: Who was behind this? Sadly we don’t know. A single arrest was made in 2014, and recovered files implicated another Russian citizen, but the latest work indicates this was yet another stolen identity. The rest of the actors behind Ebury have gone to great lengths to remain behind the curtain.

The Great 12 Second Ethereum Heist

Ethereum moved from a proof-of-work to proof-of-stake model back in 2022. That had some interesting ramifications, like making the previously random block times a predictable 12 second cadence. With a change that big, there were bound to be some bugs around the edges. In this case, the edge is the MEV-Boost algorithm, which a pair of brothers managed to manipulate into giving them $25 million worth of Ethereum. The DOJ went after the two for wire fraud, and made a point that the hack happened in just 12 seconds.

That seems to be the point. The trick here is was to make a bunch of worthless transactions look really appealing to the MEV-Boost algorithm, while also running the validator that actually processed the block. Being in this privileged position on both sides of the block creation allowed for tampering with the transaction. It’s definitely not what the Ethereum network needed. And pro tip: If you’re going to commit wire fraud, try not to leave a search engine history detailing your money laundering and extradition avoidance plans.

WiFi and SSID Confusion

There’s a new WiFi issue, that seems to be an actual vulnerability in the 802.11 spec itself. The key is a man-in-the-middle attack on the raw wireless traffic, which is fairly easy. Some of the negotiation process happens in the clear, so the attacker can manipulate that data, to rewrite the SSID in the initial connection attempt. This results in the legitimate access point sending back a message suggesting that the victim connect to a different AP. There is one important point to make here: The “good” and “bad” network can use different security types, but do need to use the same password. So this is of limited use, though there are certainly cases where it could be misused.

16 Year Long Tale

Turn back your clocks to 2008, and remember CVE-2008-0166, a vulnerability in the Debian OpenSSL packages. That was a Debian patch to fix a usage of uninitialized memory in the OpenSSL random number generator. Yes it was accessing uninitialized memory — to use it as seed for the random number generator. The result is that on Debian systems from 2006 to 2008 could only generate a few thousand discrete keys. What [Hanno Böck] realized was that the DKIM email specification was released in 2007. How many DKIM certificates still around today were generated on Debian before the bug was fixed? At least 855, or about a quarter of a percent of the domains checked. Oops. That’s a very long tail indeed.

Bits and Bytes

Care to shut down a website? If that site is protected by a vulnerable Web Application Firewall, it’s fairly easy to include a comment that looks suspicious enough to trick the WAF into blocking its own site. The rule that’s triggered is actually intended to keep internal error messages from spilling out into the open web. It’s a bit tamer version of the database deletion trick we covered a few weeks ago.

Sprocket Security did the hard work for us, patch diffing the fix for CVE-2024-3400 in Palo Alto GlobalProtect. This write-up is more about the actual approach to getting a vulnerable copy of the software to make the comparison against. And if you wondered, it’s command injection, due to shell=True where it shouldn’t be.

And finally, there was a VirtualBox vulnerability used in the latest Pwn2Own competition, and the details are available. A bit clearing routine for the virtual VGA device has a memory handling error in it, allowing manipulation of memory outside the intended bounds. In the competition, it was used for privilege escalation inside the VM, but it has potential for full VM escape in some cases.