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 DNS 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!
Intel clearly has put minimal effort into securing their processors. The set of affected CPUs were the only ones that weren’t hit by meltdown. I’m glad someone took a closer look at them.
At least this is a flaw requiring physical access, and with physical access its always a case of when they get in, as they will if they really want to.
My experience working for companies designing Intel-based platforms is that their idea of “security” consists entirely of obfuscation, NDAs, and tightly controlling documentation. I’m not at all surprised that they had some unsecured debug channel that could be exploited.
No, Intel has put appropriate effort into securing their processors in the exact manner agreed upon.
So… am I the only one still using DDR3 memory because I haven’t made a significant PC upgrade in nearly a decade? :)
Maybe because decade old hardware is the only stuff one can get.
Well, I think my PC is more than a decade old. I don’t recall what I loaded it with…
My acer 5332 pr0n laptop is 14 years old now, but still runs Ubuntu just fine, stuffed with 4GB and 2TB, and mplayer does a good job. Mind you it’s now on its 2nd display and 3rd motherboard!
That’s nothing, I’ve had my broom for over 20 years now, its had 17 new heads and 14 new handles :)
It’s been in the family for generations ..
My unfortunately dying workstation is around that old, but being a workstation its early ECC DDR4 if memory serves, and the other PC in the house are all DDR2 and rather older still, and one of those gets daily use…
All my Raspberry Pi’s are using DDR2, DDR3 and DDR4 depending on model…. All my desktops/servers/laptops are using DDR4.
Your probably not the only one :) .. But about time to move on, don’t ya think?
“But about time to move on, don’t ya think?”
Nope!
If it ain’t broke…
…don’t replace it with some modern crap that won’t last nearly as long!
B^)
And if you do dare to replace it, it is almost guaranteed that it will not run the software you ran on the older machine.
“compatibility” is a complete myth.
Marketing departments have done the same to “compatibility” as they did to hard disks… where you can’t buy a 5TB disk that actually holds 5TB of data.
HDD manufacturers measure data capacity in 1000. While Windows for an example measures in 1024. Ie, it is two different scales.
So no, your 5TB drive does contain 5 trillion bytes.
But when Windows wants 1.09951 trillion bytes for it to say 5TB. This is technically supposed to be written as 5TiB.
But exceptionally few people and programs use TiB, GiB, MiB and KiB. So I can understand why people are confused when their new hard drive doesn’t have “X bytes” in certain software that reports the capacity with a different scale compared to what the drive manufacturer used.
@[Jonathan Bennett],
I take that “DSN” is a typo in the first line of paragraph 5?
“The original DNS attack used nonrandom query IDs, and always made DSN lookups from UDP port 53.”
Fixed! Better late than never, right?
“The FBI’s Law Enforcement Enterprise Portal (LEEP) contains an email verification step, when creating an account.”
So, in other words, FBI’s LEEP is not 133t
Row hammer seems like a rather pervasive issue. But I do wonder how applicable it actually is in practice.
Since there is a few things making such an attack a bit infeasible on a real computer.
First of, we have typically a plethora of threads running and making memory requests all the time. (Adding a base layer of noise.)
Secondly, we have cache that ensures that if a memory request is made twice, the second request will not result in a call on our memory channel. (Here one can though dump the cached content and ask for it again. But if the cache is using a score based eviction system, then the dump command should generally be a “set to a very low score” instead of actually evicting it. Then it is most likely going to get evicted later on when space is needed. But it is still around to catch requests for the data it caches.)
Thirdly, our memory management system typically have a fair bit of a queue when it comes to asking for stuff from RAM, and a good memory management system will pick the row addresses with the most calls, or row addresses with “timed out” calls. (This effectively means that our attack will have even more junk to meander its way through, wasting time on its somewhat time sensitive mission.)
Fourthly. Our security system should generally forbid a process from accessing the data belonging to another thread. So the likelihood that our attacker has access to the relevant rows is likely quite small to begin with. (Though, most “security” systems doesn’t really protect memory in practice…)
Fifthly. ECC is progressively becoming more common. (DDR5 has it as standard. (Yes, it has on die ECC of the data in the array, + CRC for the data being sent to and from the CPU/Memory-controller. (DDR4 only had CRC on writes for some reason…))) And ECC would just flip the bit back unless the ECC information is also modified to be correct for the new pattern. This I doubt would be an easy task even if one knows the data being there. (Since row hammer is a bit like throwing a dice, it isn’t guaranteed to work every time. And worst case the thread being attacked reads the data before the attack is done resulting in ECC just restoring the original. (or getting corrupt unfixable data, ECC isn’t magic after all, but row hammer is slow.))
And lastly.
DRAM has refresh cycles. It isn’t often, but they do happen. And DDR5 comes in with more nuanced refresh mechanisms for making refreshing a stroll in the park so that it can be done more often. (Not to mention that modern DRAM has such pathetically small cells that they practically require a refresh on every read, this is thankfully fairly trivial. (There is reasons why the bit lines are pre-charged before a read, this is so that the comparators can sense if the cell getting connected is a 1 or a 0, the parasitic capacitance hanging of a FET is fairly small compared to the huge bit line. (so the victim just reading the row every once in a while can put the attacker back at square one.)))
(Some might though say, “but our victim’s data might linger in cache, so this means any reads will get caught by our cache leaving more time for the attacker to fiddle with the DRAM.” Except, on a cache evict, standard procedure is to write over whatever is in DRAM, so that “attack” (even if successful) were a waste of effort. (Reading out the contents of the DRAM and comparing is a larger waste of memory bandwidth than just writing out our data. There might in some caching implementations exist a “is modified” bit for the cache line, as to determine if it should get sent out or not.))
In the end, is row hammer a feasible attack in practice?
Personally I think it is not an all that serious threat in practice.
And honestly, the bigger threat here is that a process just has free access to neighboring rows. Statistically it would be quite rare that the attacking process ends up next to the victim.
A more proper memory security system should ensure that non allocated memory would only be accessible by the Kernel. And space allocated to thread A would only be accessible by threads that thread A has explicitly accepted. But this type of memory security system would kill a lot of backwards compatibility. (Recompiling might restore some backwards compatibility, but likely not all.)
“…and the Trusted Platform Module (TPM) is at the center of the problem.” I’ve lost count of how many times I’ve read that byline. Intel trained me to NOT trust Intel.
Intel’s handling of Intel shareholders trained me not to trust Intel!