This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness

August 19, 2022 by Jonathan Bennett 9 Comments

It’s debatable just how useful Secure Boot is for end users, but now there’s yet another issue with Secure Boot, or more specifically, a trio of signed bootloaders. Researchers at Eclypsium have identified problems in the Eurosoft, CryptoPro, and New Horizon bootloaders. In the first two cases, a way-too-flexible UEFI shell allows raw memory access. A startup script doesn’t have to be signed, and can easily manipulate the boot process at will. The last issue is in the New Horizon Datasys product, which disables any signature checking for the rest of the boot process — while still reporting that secure boot is enabled. It’s unclear if this requires a config option, or is just totally broken by default.

The real issue is that if malware or an attacker can get write access to the EFI partition, one of these signed bootloaders can be added to the boot chain, along with some nasty payload, and the OS that eventually gets booted still sees Secure Boot enabled. It’s the perfect vehicle for really stealthy infections, similar to CosmicStrand, the malicious firmware we covered a few weeks ago.
Continue reading “This Week In Security: Secure Boot Bypass, Attack On Titan M, KASLR Weakness” →

This Week In Security: Breaches, ÆPIC, SQUIP, And Symbols

August 12, 2022 by Jonathan Bennett 9 Comments

So you may have gotten a Slack password reset prompt. Something like half a percent of Slack’s userbase had their password hash potentially exposed due to an odd bug. When sending shared invitation links, the password hash was sent to other members of the workspace. It’s a bit hard to work out how this exact problem happened, as password hashes shouldn’t ever be sent to users like this. My guess is that other users got a state update packet when the link was created, and a logic error in the code resulted in too much state information being sent.

The evidence suggests that the first person to catch the bug was a researcher who disclosed the problem mid-July. Slack seems to use a sane password policy, only storing hashed, salted passwords. That may sound like a breakfast recipe, but just means that when you type your password in to log in to slack, the password goes through a one-way cryptographic hash, and the results of the hash are stored. Salting is the addition of extra data, to make a precomputation attack impractical. Slack stated that even if this bug was used to capture these hashes, they cannot be used to directly authenticate as an affected user. The normal advice about turning on 2-factor authentication still applies, as an extra guard against misuse of leaked information. Continue reading “This Week In Security: Breaches, ÆPIC, SQUIP, And Symbols” →

Photo of the MCH2022 badge's screen, showing the "Hack me if you can" app's start splashscreen, saying "Service is accessible on IP ADDRESS : 1337"

MCH2022 Badge CTF Solved, With Plenty To Learn From

August 7, 2022 by Arya Voronova 3 Comments

Among all the things you could find at MCH2022, there were a few CTFs (Capture The Flag exercises) – in particular, every badge contained an application that you could try and break into – only two teams have cracked this one! [dojoe] was part of one of them, and he has composed an extensive reverse-engineering story for us – complete with Ghidra disassembly of Xtensa code, remote code execution attempts, ROP gadget creation, and no detail left aside.

There was a catch: badges handed out to the participants didn’t contain the actual flag. You had to develop an exploit using your personal badge that only contained a placeholder flag, then go to the badge tent and apply your exploit over the network to one of the few badges with the real flag on them. The app in question turned out to be an echo server – sending back everything it received; notably, certain messages made it crash. One man’s crashes are another man’s exploit possibilities, and after a few hacking sessions, [dojoe]’s team got their well-deserved place on the scoreboard.

If you always thought that firmware reverse-engineering sounds cool, and you also happen to own a MCH2022 badge, you should try and follow the intricately documented steps of [dojoe]’s writeup. Even for people with little low-level programming experience, repeating this hack is realistic thanks to his extensive explanations, and you will leave with way more reverse-engineering experience than you had before.

The MCH2022 badge is a featureful creation of intricate engineering, with the ESP32 portion only being part of the badge – we’re eager to hear about what you’ve accomplished or are about to accomplish given everything it has to offer!

Here’s How The Precursor Protects Your Privacy

August 6, 2022 by Arya Voronova 14 Comments

At some point, you will find yourself asking – is my device actually running the code I expect it to? [bunnie] aka [Andrew Huang] is passionate about making devices you can fundamentally, deeply trust, and his latest passion project is the Precursor communicator.

At the heart of it is an FPGA, and Precursor’s CPU is created out of the gates of that FPGA. This and a myriad of other design decisions make the Precursor fundamentally hard to backdoor, and you don’t have to take [bunnie]’s word for it — he’s made an entire video going through the architecture, boot protections and guarantees of the Precursor, teaching us what goes into a secure device that’s also practical to use.

If you can’t understand how your device works, your trust in it might be misplaced. In the hour long video, [bunnie] explains the entire stack, from the lower levels of hardware to root keys used to sign and verify the integrity of your OS, along the way demonstrating how you can verify that things haven’t gone wrong.

He makes sure to point out aspects you’d want to be cautious of, from physical security limitations to toolchain nuances. If you’re not up for a video, you can always check out the Precursor wiki, which has a treasure trove of information on the device’s security model.

As you might’ve already learned, it’s not enough for hardware to be open-source in order to be trustworthy. While open-source silicon designs are undoubtedly the future, their security guarantees only go so far.

Whether it’s esoteric hard drive firmware backdoors, weekend projects turning your WiFi card into a keylogger, or rootkits you can get on store-bought Lenovo laptops, hell, even our latest This Week In Security installment has two fun malware examples – there’s never a shortage of parties interested in collecting as much data as possible.

ESP32 Powers Covert Pentesting Device

August 5, 2022 by Tom Nardi 11 Comments

Looking to expand their hardware design experience, [mentalburden] recently put together a low-cost handheld gadget that can be used for various security-related tasks such as logging WiFi traffic, operating as a dead drop, and performing deauthentication attacks.

The custom PCB plays host to the essentials — an ESP32-S microcontroller, AMS1117 3.3 V regulator, a SSD1306 OLED, and a couple of buttons. This lets the user navigate through a simple menu system and select whatever function they wish to enable. During testing, a pair of 18650 cells kept the electronics running for an impressive 22 hours.

A second version of the PCB fixed a few bodges that were required to get the original prototype working, and given how energy efficient the hardware ended up being, [mentalburden] decided to drop the power supply down to a single 18650 for a total runtime of around 15 hours. A 3D printed case and some silicone buttons, produced with a simple clay mold, completed the package.

There’s still some improvements that could be made, namely integrating a battery charging circuit into the PCB and switching over to USB-C, but overall its a solid prototype with an impressive per-unit cost of less than $10 USD. Though if you’re looking for something even cheaper, we’ve seen an even more simplistic approach based on the ESP-01.

This Week In Security: Symbiote Research And Detection, Routing Hijacks, Bruggling, And More

August 5, 2022 by Jonathan Bennett 8 Comments

Last week we covered the Symbiote Rootkit, based on the excellent work by Blackberry, Intezer, and Cyber Geeks. This particular piece of malware takes some particularly clever and devious steps to hide. It uses an LD_PRELOAD to interfere with system libraries on-the-fly, hiding certain files, processes, ports, and even traffic from users and detection tools. Read last week’s column and the source articles linked there for the details.

There is a general technique for detecting rootkits, where a tool creates a file or process that mimics the elements of the rootkit, and then checks whether any of the fakes mysteriously disappear. In reading about Symbiote, I looked for tooling that we could recommend, that uses this technique to check for infections. Coming up short, I dusted my security researcher hat off, and got to work. A very helpful pointer from Intezer led me to MalwareBazaar’s page on Symbiote. Do note, that page hosts live malware samples. Don’t download lightly.

This brings us to the first big problem we need to address. How do you handle malware without getting your machine and wider network infected? Virtualization can be a big part of the answer here. It’s a really big leap for malware to infect a virtual machine, and then jump the gap to infect the host. A bit of careful setup can make that even safer. First, use a different OS or distro for your VM host and research client. Sophisticated malware tends to be very targeted, and it’s unlikely that a given sample will have support for two different distros baked in. The bare-metal host is an up-to-date install for best security, but what about the victim?

While we want a bulletproof foundation, our research VM needs to be vulnerable. If the malware is targeted at a specific kernel version or library, we need that exact version to even get started. Unfortunately the samples at MalwareBazaar don’t include details on the machine where they were found, but they do come with links off to other analysis tools, like Intezer Analyze. One particular embedded string caught my eye: GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-17) That’s likely from the machine where this particular Symbiote sample was compiled, and it seems like a good starting point. GCC 4.4.7-17 shipped with Red Hat Enterprise Linux version 6.8. So we grab a CentOS 6.8 live DVD ISO, and get it booting on our VM host.

The next step is to download the malware samples directly from MalwareBazaar. They come in encrypted zips, just to make it harder to accidentally infect yourself. We don’t want those to land anywhere but the intended target. I went a step further and disconnected both the virtual network adapter and physical network cable, to truly air gap my research environment. I had my malware and likely target, and it was time to test my theory that Symbiote was trying too hard to be sneaky, and would sound the alarm on itself if I poked it just right.

Success! We’re using touch to create a file named java.h, and using ls to verify that it’s really there. Then, add the LD_PRELOAD and run ls again, and java.h is mysteriously missing. A similar trick works for detecting process hiding. We turn java.h into a script by writing while true; do sleep 1; done into it. Run the script in the background, and see if it’s listed in ps -A -caf. For a filename on Symbiote’s hide list, it too disappears. The best part is that we can script this detection. I give you, sym-test.sh. It creates and runs a simple script for each of the known Symbiote files, then uses ls and ps to look for the scripts. A Symbiote variant that works like the samples we’ve seen in the wild will give away its presence and be detected. If you find Symbiote on your machine via this script, be sure to let us know!

BGP Hijack — Maybe

There was a bit of BGP weirdness last week, where the Russian telecom company, Rostelecom, announced routing for 17.70.96.0/19. This block of IPs is owned by Apple, and all signs point to this being an unauthorized announce. BGP, the Border Gateway Protocol, is one of the most important network protocols you may not have heard of, and essentially carries the instructions on how to route internet traffic around the world. It’s also historically not had any security protocols baked-in, simply relying on good behavior from all the players. There is RPKI, a new standard for cryptographic signatures for routing updates, but it’s not a hard requirement and not widely deployed yet.

BGP, without any of the security enhancement schemes, works by honoring the most specific route available. Apple announces routes for 17.0.0.0/9, a network of over 8,000,000 IPs. Rostelecom started announcing 17.70.96.0/19, a much smaller subnet containing just over 8,000 IPs. The more specific route wins, and Rostelecom has a valid ASN, so the Internet made the routing shift. Someone at Apple was paying attention, and pushed a routing update for 17.70.96.0/21, moving what is presumably the most important 2,046 IPs back to their proper destination. After about 12 hours, Rostelecom dropped the bogus routes. Neither Apple nor Rostelecom have released statements about the incident.

Were this the first incident involving Rostelecom, it would be natural to conclude this was an honest mistake. Rostelecom has demonstrated bad behavior in the past, so the element of plausible deniability is waning. Could this have been part of a targeted operation against someone’s iPhone or Apple account? It’s hard to say whether we’ll be privy to the details any time soon. At the very least, you can watch a replay of the network carnage.

Email Routing Hijack

Cloudflare is expanding into email routing, and researcher [Albert Pedersen] was a bit miffed not to get invited into the closed Beta. (The Beta is open now, if you need virtual email addresses for your domains.) Turns out, you can use something like the Burp Suite to “opt in” to the beta on the sly — just intercept the Cloudflare API response on loading the dashboard, and set "beta": true. The backend doesn’t check after the initial dashboard load. While access to a temporarily closed beta isn’t a huge security issue, it suggests that there might be some similar bugs to find. Spoilers: there were.

When setting up a domain on your Cloudflare account, you first add the domain, and then go through the steps to verify ownership. Until that is completed, it is an unverified domain, a limbo state where you shouldn’t be able to do anything other than complete verification or drop the domain. Even if a domain is fully active in an account, you can attempt to add it to a different account, and it will show up as one of these pending domains. Our intrepid hacker had to check, was there a similar missing check here? What happens if you add email routing to an unverified domain? Turns out, at the time, it worked without complaint. A domain had to already be using Cloudflare for email, but this trick allowed intercepting all emails going to such a domain. [Albert] informed Cloudflare via HackerOne, and scored a handy $6,000 for the find. Nice!

Post-Quantum, But Still Busted

The National Institute of Standards and Technology, NIST, is running an ongoing competition to select the next generation of cryptography algorithms, with the goal of a set of standards that are immune to quantum computers. There was recently a rather stark reminder that in addition to resistance to quantum algorithms, a cryptographic scheme needs to be secure against classical attacks as well.

SIKE was one of the algorithms making its way through the selection process, and a paper was just recently published that demonstrated a technique to crack the algorithm in about an hour. The technique used has been known for a while, but is extremely high-level mathematics, which is why it took so long for the exact attack to be demonstrated. While cryptographers are mathematicians, they don’t generally work in the realm of bleeding-edge math, so these unanticipated interactions do show up from time to time. If nothing else, it’s great that the flaw was discovered now, and not after ratification and widespread use of the new technique.

Bits and Bruggling Bytes

A portmanteau of Browser and Smuggling, Bruggling is a new data exfiltration technique that is just silly enough to work. Some corporate networks try very hard to limit the ways users and malicious applications can get data off the network and out to a bad actor over the Internet. This is something of a hopeless quest, and Bruggling is yet another example. So what is it? Bruggling is stuffing data into the names and contents of bookmarks, and letting the browser sync those bookmarks. As this looks like normal traffic, albeit potentially a *lot* of traffic, it generally won’t trigger any IDS systems the way odd DNS requests might. So far Bruggling is just an academic idea, and hasn’t been observed in the wild, but just may be coming to malware near you.

LibreOffice just patched a handful of issues, and two of them are particularly noteworthy. First is CVE-2022-26305, a flaw in how macros are signed and verified. The signature of the macro itself wasn’t properly checked, and by cloning the serial number and issuer string of a trusted macro, a malicious one could bypass the normal filter. And CVE-2022-26306 is a cryptographic weakness in how LibreOffice stores passwords. The Initialization Vector used for encryption was a static value rather than randomly created for each install. This sort of flaw usually allows a pre-computation attack, where a lookup table can be compiled that enables quickly cracking an arbitrary encrypted data set. In up-to-date versions of LibreOffice, if using this feature, the user will be prompted for a new password to re-encrypt their configuration more securely.

Samba has also fixed a handful of problems, one of which sounds like a great plot point for a Hollywood hacking movie. First is CVE-2022-32744, a logic flaw where any valid password is accepted for a password change request, rather than only accepting the valid password for the account being changed. And CVE-2022-32742 is the fun one, where an SMB1 connection can trigger a buffer underflow. Essentially a client tells the server it wants to print 10 megabytes, and sends along the 15 bytes to print (numbers are fabricated for making the point). The server copies the data from the way-too-small buffer, and uses the size value set by the attacker, a la Heartbleed. I want to see the caper movie where data is stolen by using this sort of bug to print it out to the long-forgotten line-feed printer.

And finally, Atlassian Confluence installs are under active attack, as a result of a handful of exploits. There were hard-coded credentials left behind in the on-premise Confluence solution, and those credentials were released online. A pair of critical vulnerabilities in Servlet Filters are exploitable without valid credentials. If you’re still running unpatched, unmitigated Confluence installs, it may be time to jump straight to containment and cleanup. Ouch!

USB Drive Keeps Your Secrets… As Long As Your Fingers Are Wet?

July 30, 2022 by Donald Papp 27 Comments

[Walker] has a very interesting new project: a completely different take on a self-destructing USB drive. Instead of relying on encryption or other “visible” security features, this device looks and works like an utterly normal USB drive. The only difference is this: if an unauthorized person plugs it in, there’s no data. What separates authorized access from unauthorized? Wet fingers.

It sounds weird, but let’s walk through the thinking behind the concept. First, encryption is of course the technologically sound and correct solution to data security. But in some environments, the mere presence of encryption technology can be considered incriminating. In such environments, it is better for the drive to appear completely normal.

Toggling the chip enable (CE) pin will hide the drive’s contents.

The second part is the access control; the “wet fingers” part. [Walker] plans to have hidden electrodes surreptitiously measure the resistance of a user’s finger when it’s being plugged in. He says a dry finger should be around 1.5 MΩ, but wet fingers are more like 500 kΩ.

But why detect a wet finger as part of access control? Well, what’s something no normal person would do right before plugging in a USB drive? Lick their finger. And what’s something a microcontroller should be able to detect easily without a lot of extra parts? A freshly-licked finger.

Of course, detecting wet skin is only half the equation. You still need to implement a USB Mass Storage device, and that’s where things get particularly interesting. Even if you aren’t into the covert aspect of this device, the research [Walker] has done into USB storage controllers and flash chips, combined with the KiCad footprints he’s already put together means this open source project will be a great example for anyone looking to roll their own USB flash drives.

Regular readers may recall that [Walker] was previously working on a very impressive Linux “wall wart” intended for penetration testers, but the chip shortage has put that ambitious project on hold for the time being. As this build looks to utilize less exotic components, hopefully it can avoid a similar fate.