This Week In Security: EUCLEAK, Revival Hijack, And More

September 6, 2024 by Jonathan Bennett 5 Comments

[Thomas Roche] of NinjaLab is out with EUCLEAK, (pdf) a physical attack against Infineon security microcontrollers, and the security tokens that contain them. The name is a portmanteau of Euclidean and leak. And no surprise, it’s a data leak in some implementations of the Extended Euclidean Algorithm (EEA), a component of an Elliptical Curve Digital Signature Algorithm (ECDSA).

OK, time to step back. Infineon microcontrollers are the digital smart parts inside popular security tokens like the Yubikey 5, some Java smart cards, and even the Infineon TPMs. These devices all serve a similar purpose. They store one or more secret keys, and are guaranteed to never disclose those keys. Instead, they use their secret keys to do cryptographic functions, like ECDSA signatures, and output the result. There’s even a special set of tests, the Common Criteria, that are intended to backstop these guarantees. What’s interesting is that an otherwise excellent product like the Yubikey 5, that passes all these auditing and certification processes, is still vulnerable.

The actual attack is to perform ECDSA signatures while monitoring the physical chip with an electromagnetic probe. This tiny directional antenna can pick up on EM noise generated by the microprocessor. That EM noise leaks timing information about the internal state of the cryptography, and the secret key can be derived as a result.

This process does require physical access to the token for several minutes. To get useful readings, the plastic case around the security token does need to be disassembled to get the probe close enough to pick up signals. From there it’s at least an hour of post-processing to actually get the key. And most of these security tokens intentionally make the disassembly process rather difficult. The point isn’t that it’s impossible to open up, but that it’s impossible not to notice that your token has been tampered with. Continue reading “This Week In Security: EUCLEAK, Revival Hijack, And More” →

This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA

August 30, 2024 by Jonathan Bennett 2 Comments

We finally have some answers about the Windows IPv6 vulnerability — and a Proof of Concept! The patch was a single change in the Windows TCP/IP driver’s Ipv6pProcessOptions(), now calling IppSendError() instead of IppSendErrorList(). That’s not very helpful on its own, which is why [Marcus Hutchins]’s analysis is so helpful here. And it’s not an easy task, since decompiling source code like this doesn’t give us variable names.

The first question that needs answered is what is the list in question? This code is handling the option field in incoming IPv6 packets. The object being manipulated is a linked list of packet structs. And that linked list is almost always a single member list. When calling IppSendErrorList() on a list with a single member, it’s functionally equivalent to the IppSendError() in the fixed code. The flaw must be in the handling of this list with multiple members. The only way to achieve that criteria is to send a lot of traffic at the machine in question, so it can’t quite keep up with processing packets one at a time. To handle the high throughput, Windows will assemble incoming packets into a linked list and process them in batch.

So what’s next? IppSendErrorList(), takes a boolean and passes it on to each call of IppSendError(). We don’t know what Microsoft’s variable name is, but [Marcus] is calling it always_send_icmp, because setting it to true means that each packet processed will generate an ICMP packet. The important detail is that IppSendError() can have side effects. There is a codepath where the packet gets reverted, and the processing pointer is set back to the beginning of the packet. That’s fine for the first packet in the list, but because the function processes errors on the entire list of packets, the state of the rest of those packets is now much different from what is expected.

This unexpected but of weirdness can be further abused through IPv6 packet fragmentation. With a bit of careful setup, the reversion can cause a length counter to underflow, resulting in data structure corruption, and finally jumping code execution into the packet data. That’s the Remote Code Execution (RCE). And the good news, beyond the IPv6-only nature of the flaw, is that so far it’s been difficult to actually pull the attack off, as it relies on this somewhat non-deterministic “packet coalescing” technique to trigger the flaw.

Continue reading “This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA” →

This Week In Security: Crash Your IPhone, Hack Your Site, And Bluetooth Woes

August 23, 2024 by Jonathan Bennett 6 Comments

There have been some hilarious issues on mobile devices over the years. The HTC Dream had a hidden shell that was discovered when a phone rebooted after sending a text containing just the word “reboot”. iOS has gotten in on the fun from time to time, and this time it’s ""::. Type the double quotes, a colon, and any other character, and Apple’s Springboard service crashes.

Another hacker dug in a bit, and realized that Springboard is trying to jump execution to a null pointer, leading to a crash. It’s very odd that user input breaks the query parser badly enough to jump to null like that. There are a couple interesting questions that we have to ask. Given that the crash trigger is quite flexible, "anything goes":x, is it possible to manipulate that function pointer to be something other than null? And perhaps more importantly, why is the code crashing, instead of an invalid address error as one would expect from a Pointer Authentication Code (PAC) violation? Regardless, the bug seems to be fixed in the latest iOS 18 builds.

Continue reading “This Week In Security: Crash Your IPhone, Hack Your Site, And Bluetooth Woes” →

This Week In Security: Three Billion SS Numbers, IPv6 RCE, And Ring -2

August 16, 2024 by Jonathan Bennett 3 Comments

You may have heard about a very large data breach, exposing the Social Security numbers of three billion individuals. Now hang on. Social Security numbers are a particularly American data point, and last time we checked there were quite a few Americans shy of even a half of a billion’s worth. As [Troy Hunt] points out, there are several things about this story that seem just a bit odd.

First up, the claim is that this is data grabbed from National Public Data, and there’s even a vague notice on their website about it. NPD is a legitimate business, grabbing data on as many people as possible, and providing services like background checks and credit checks. It’s not impossible that this company has records on virtually every citizen of the US, UK, and Canada. And while that’s far less than 2.9 billion people, it could feasibly add up to 2.9 billion records as was originally claimed.

The story gets strange as we consider the bits of data that have been released publicly, like a pair of files shared with [Troy] that have names, birthdays, addresses, phone numbers, and social security numbers. Those had a total of 2.69 billion records, with an average of 3 records for each ID number. That math is still just a little weird, since the US has to date only generated 450 million SSNs and change.

So far all we have are partial datasets, and claims on the Internet. The story is that there’s a grand total of 4 TB of data once uncompressed. The rest of the details are unclear, and it’s likely to take some time for the rest of the story to come out. Continue reading “This Week In Security: Three Billion SS Numbers, IPv6 RCE, And Ring -2” →

This Week In Security: GhostWrite, Localhost, And More

August 9, 2024 by Jonathan Bennett 5 Comments

You may have heard some scary news about RISC-V CPUs. There’s good news, and bad news, and the whole thing is a bit of a cautionary tale. GhostWrite is a devastating vulnerability in a pair of T-Head XuanTie RISC-V CPUs. There are also unexploitable crashes in another T-Head CPU and the QEMU soft core implementation. These findings come courtesy of a group of researchers at the CISPA Helmholtz Center for Information Security in Germany. They took at look at RISC-V cores, and asked the question, do any of these instructions do anything unexpected? The answer, obviously, was “yes”.

Undocumented instructions have been around just about as long as we’ve had Van Neumann architecture processors. The RISC-V ISA put a lampshade on that reality, and calls them “vendor specific custom ISA extensions”. The problem is that vendors are in a hurry, have limited resources, and deadlines wait for no one. So sometimes things make it out the door with problems. To find those problems, CISPA researchers put together a test framework is called RISCVuzz, and it’s all about running each instruction on multiple chips, and watching for oddball behavior. They found a couple of “halt-and-catch-fire” problems, but the real winner (loser) is GhostWrite.

Now, this isn’t a speculative attack like Meltdown or Spectre. It’s more accurate to say that it’s a memory mapping problem. Memory mapping helps the OS keep programs independent of each other by giving them a simplified memory layout, doing the mapping from each program to physical memory in the background. There are instructions that operate using these virtual addresses, and one such is vs128.v. That instruction is intended to manipulate vectors, and use virtual addressing. The problem is that it actually operates directly on physical memory addresses, even bypassing cache. That’s not only memory, but also includes hardware with memory mapped addresses, entirely bypassing the OS. This instruction is the keys to the kingdom. Continue reading “This Week In Security: GhostWrite, Localhost, And More” →

This Week In Security: Echospoofing, Ransomware Records, And Github Attestations

August 2, 2024 by Jonathan Bennett 5 Comments

It’s a bit of bitter irony, when a security product gets used maliciously, to pull off the exact attack it was designed to prevent. Enter Proofpoint, and the EchoSpoofing attack. Proofpoint offers an email security product, filtering spam and malicious incoming emails, and also handling SPF, DKIM, and DMARC headers on outgoing email. How does an external service provide those email authentication headers?

One of the cardinal sins of running an email server is to allow open relaying. That’s when anyone can forward email though an SMTP server without authentication. What we have here is two nearly open relays, that wound up with spoofed emails getting authenticated just like the real thing. The first offender is Microsoft’s Office365, which seems to completely skip checking for email spoofing when using SMTP relaying from an allowed IP address. This means a valid Office365 account allows sending emails as any address. The other half relies on the way Proofpoint works normally, accepting SMTP traffic from certain IP addresses, and adding the authentication headers to those emails. There’s an option in Proofpoint to add the Microsoft Office 365 servers to that list, and apparently quite a few companies simply select that option.

The end result is that a clever spammer can send millions of completely legitimate looking emails every day, that look very convincing even to sophisticated users. At six months of activity, averaging three millions emails a day, this campaign managed just over half a billion malicious emails from multiple high-profile domains.

The good news here is that Proofpoint and Guardio discovered the scheme, and worked with Microsoft to develop the X-OriginatorOrg header that is now applied to every email sent from or through the Office365 servers. This header marks the account tenant the email belongs to, giving vendors like Proofpoint a simple way to determine email validity. Continue reading “This Week In Security: Echospoofing, Ransomware Records, And Github Attestations” →

This Week In Security: EvilVideo, Crowdstrike, And InSecure Boot

July 26, 2024 by Jonathan Bennett 12 Comments

First up this week is the story of EvilVideo, a clever telegram exploit that disguises an APK as a video file. The earliest record we have of this exploit is on June 6th when it was advertised on a hacking forum.

Researchers at ESET discovered a demo of the exploit, and were able to disclose it to Telegram on June 26th. It was finally patched on July 11. While it was advertised as a “one-click” exploit, that’s being a bit generous, as the ESET demo video shows. But it was a clever exploit. The central trick is that an APK file can be sent in a Telegram chat, and it displays what looks like a video preview. Tap the “video” file to watch it, and Telegram prompts you to play it with an external player. But it turns out the external player in this case is Android itself, which prompts the target to install the APK. Sneaky.