This Week in Security: Intel Atoms Spill Secrets, ICMP Poisons DNS, and The Blacksmith

Intel has announced CVE-2021-0146, a vulnerability in certain processors based on the Atom architecture, and the Trusted Platform Module (TPM) is at the center of the problem. The goal of the system around the TPM is to maintain system integrity even in the case of physical access by an attacker, so the hard drive is encrypted using a key stored in a secure chip on the motherboard. The TPM chip holds this encryption key and provides it during the boot process. When combined with secure boot, this is a surprisingly effective way to prevent tampering or data access even in the case of physical access. It’s effective, at least, when nothing goes wrong.

Earlier this year, we covered a story where the encryption key could be sniffed directly from the motherboard, by tapping the traces connecting the TPM to the CPU. It was pointed out that TPM 2.0 can encrypt the disk encryption key on the traces, making this attack impossible.

The entire Trusted Compute Model is based on the premise that the CPU itself is trustworthy. This brings us back to Intel’s announcement that a debug mode could be enabled via physical access. In this debug mode, the CPU master key can be extracted, leading to complete compromise. The drive encryption key can be recovered, and unsigned firmware can be loaded to the Management Engine. This means data in the TPM enclave and the TPM-stored encryption key can be compromised. Updated firmware is rolling out through motherboard vendors to address the problem.

DNS Poisoning Via ICMP

In honor of the late Dan Kaminsky, we’re once again looking at DNS cache poisoning. This time it’s a quirk of the Linux network stack that enables the attack. This attack is detailed in a paper by a trio from the University of California, Riverside.

The original DNS attack used nonrandom query IDs, and always made DSN lookups from UDP port 53. It was simple to send a spoofed DNS response, and if the malicious response arrived before the valid one, the resolver accepted the bogus data. What makes this attack particularly bad is that resolvers cache these results, so many users can be sent the bogus data. The solution was to randomize both the source port (16 bits), and a transaction ID (16 bits). Neither protection contains enough bits to be secure, but the combined space is enough to make DNS attacks impractical. If one of these values could be determined independently, the attack could be valid again.

This attack abuses the ICMP fragmentation error. When such a message is received by a Linux machine, it is validated against the active UDP connections. The request must contain the correct source and destination IP and port. If this set of information matches an open UDP socket, an entry is added to the exception cache. If an attacker can detect the change of state of the exception cache, he can use ICMP packets to probe for opened UDP sockets — effectively allowing the randomized port of a DNS lookup to be discovered.

How exactly do you detect that state change? A DNS resolver like dnsmasq opens these temporary ports using sendto(), which has the unintentional side effect of accepting UDP packets from any IP address. An ICMP fragmentation error can update the exception cache for any IP, so long as it has the correct IP and port of a temporary connection. This makes the attack trivial.

Make a request for somerandomsubdomain.google.com, and then start spamming ICMP fragmentation errors for all the UDP ports on the target system. When one of these packets matches the opened UDP port, the MTU for the specified IP is changed. Then ping the system from the IPs indicated in the ICMP errors. When one of your ping responses is fragmented, you’ve found a collision. Now that you know the port that the DNS resolver has opened, you could brute-force the transaction ID. Since it’s only 16 bits of keyspace, this is very doable.

The problem is a bit harder for other DNS resolvers, like BIND, that use connect() to open temporary UDP sockets. The same trick applies, but you can only trigger an MTU change on the specific IP the socket is connected to. Is there any way to detect this change? There is. The key here is that the exception cache is a hash table with a limited depth. This hash table works by applying an algorithm (a hash) to the remote IP address, which always returns an 11-bit number. There are 2048 “buckets” of memory allocated, and the number resulting from the hash determines the bucket that the exception data goes into. Each bucket can contain five entries, and when a sixth exception is stored in that bucket, the oldest is dropped.

In this case, an attacker needs to control remote IPs that happen to collide with the hashed value of the real upstream resolver. The attacker fills the five exception entries of their colliding IPs, then launches the storm of ICMP fragmentation errors. The attacker can test the MTUs of IPs he controls, so will know when one of his exceptions has been dropped. This signals that he’s found the correct port for a temporary UDP connection.

It’s a complicated attack, but the potential payoff is quite high, so expect to see patches addressing this in the very near future.

Weaponizing KB Numbers

Microsoft tracks their security updates using Knowledge Base article numbers. For example, CVE-2021-42279 is tracked by Microsoft as KB5007207 for Windows 10 64-bit. It’s pretty easy to list the KBs that have been installed on a Windows system, but how would you translate that to a list of potential vulnerabilities? [Arris Huijgen] has the answer. There are a plethora of tools to query the list of installed KBs, and many of those tools even work on remote systems, like systeminfo.exe and WMIC.exe. So for all your Windows exploitation needs, you need look no further than the Windows Exploit Suggester – Next Generation. This collection of tools looks like a useful kit for auditing or red-teaming a Windows machine, so be sure to add it to your toybox.

That One Time The FBI Sent Spam

You know how to handle spam, right? If an email looks fishy at all, into the spam folder it goes, never to worry about again. So when an email from the FBI arrives, you just scoff, quickly check the email headers to be sure, and off it goes. But wait, that email came from 153.31.119.142, which actually is mx-east-ic.fbi.gov. What’s going on here?

These emails look like this:

Sending IP: 153.31.119.142 (https://t.co/En06mMbR88)
From: eims@ic.fbi.gov
Subject: Urgent: Threat actor in systems pic.twitter.com/NuojpnWNLh

— Spamhaus (@spamhaus) November 13, 2021

Brian Krebs has the lowdown. The FBI’s Law Enforcement Enterprise Portal (LEEP) contains an email verification step, when creating an account. The email’s contents are generated in the visitor’s browser, and sent to whatever address is specified, making this stunt trivial. It seems that [Pompompurin] was behind the spam, and what sort of message did he send with his newfound powers? A farcical message calling out Vinny Troia of Shadowbyte, just the latest in their public feud. If you really must go down that rabbit hole, start here.

The Blacksmith and His Rowhammer

Remember Rowhammer? This technique flipped individual RAM bits by quickly pulsing the row activation line of nearby rows. In response, DDR4 ram chips have Target Row Refresh (TRR) technology built in, and that totally eliminates the Rowhammer vulnerability. Right?

A new tool, Blacksmith, combines the existing Rowhammer techniques with a fuzzing approach, and looks at how effective the TRR protections are in modern memory chips. The results aren’t pretty. The researchers estimate that their testing covers over 90% of the DRAM market, and every RAM chip they tested allowed for multiple bit flips.

MacOS Attack Analysis

Google’s Threat Analysis Group has published the details of a watering-hole attack, seemingly aimed at visitors to Hong Kong websites. The page hosted multiple exploit chains, targeting both iOS and MacOS. Among the exploits recovered was one exploiting a 0-day vulnerability, CVE-2021-30869. Google reported this flaw, and it was fixed in September.

After the attack chain succeeded, a binary was deployed, and this binary proved to be heavily obfuscated. The final malware appeared custom, and is capable of audio and keystroke recording, file upload, and screen and audio capture. Now who has access to MacOS 0-days, is interested in Hong Kong politics, and wants to spy on citizens? OK, that’s honestly a long list of governments, but I’m sure you can think of a leading contender.

That’s it for this week, stay secure out there!