ESP8266 And ESP32 WiFi Hacked!

September 5, 2019 by Elliot Williams 48 Comments

[Matheus Garbelini] just came out with three (3!) different WiFi attacks on the popular ESP32/8266 family of chips. He notified Espressif first (thanks!) and they’ve patched around most of the vulnerabilities already, but if you’re running software on any of these chips that’s in a critical environment, you’d better push up new firmware pretty quick.

The first flaw is the simplest, and only effects ESP8266s. While connecting to an access point, the access point sends the ESP8266 an “AKM suite count” field that contains the number of authentication methods that are available for the connection. Because the ESP doesn’t do bounds-checking on this value, a malicious fake access point can send a large number here, probably overflowing a buffer, but definitely crashing the ESP. If you can send an ESP8266 a bogus beacon frame or probe response, you can crash it.

What’s most fun about the beacon frame crasher is that it can be implemented on an ESP8266 as well. Crash-ception! This takes advantage of the ESP’s packet injection mode, which we’ve covered before.

The second and third vulnerabilities exploit bugs in the way the ESP libraries handle the extensible authentication protocol (EAP) which is mostly used in enterprise and higher-security environments. One hack makes the ESP32 or ESP8266 on the EAP-enabled network crash, but the other hack allows for a complete hijacking of the encrypted session.

These EAP hacks are more troubling, and not just because session hijacking is more dangerous than a crash-DOS scenario. The ESP32 codebase has already been patched against them, but the older ESP8266 SDK has not yet. So as of now, if you’re running an ESP8266 on EAP, you’re vulnerable. We have no idea how many ESP8266 devices are out there in EAP networks, but we’d really like to see Espressif patch up this hole anyway.

[Matheus] points out the irony that if you’re using WPA2, you’re actually safer than if you’re unpatched and using the nominally more secure EAP. He also wrote us that if you’re stuck with a bunch of ESP8266s in an EAP environment, you should at least encrypt and sign your data to prevent eavesdropping and/or replay attacks.

Again, because [Matheus] informed Espressif first, most of the bugs are already fixed. It’s even percolated downstream into the Arduino-for-ESP, where it’s just been worked into the latest release a few hours ago. Time for an update. But those crusty old NodeMCU builds that we’ve got running everything in our house? Time for a full recompile.

We’ve always wondered when we’d see the first ESP8266 attacks in the wild, and that day has finally come. Thanks, [Matheus]!

1 Trillion USD Refund! (PDF Enclosed)

March 6, 2019 by Pedro Umbelino 5 Comments

Security researchers have found that it is possible to alter a digitally signed PDF without invalidating its signatures. To demonstrate it, they produced a fake document “refund order” of $1,000,000,000,000 dollars, with a valid signature from Amazon. This sparked my attention, since I was quite sure that they didn’t use some sort of quantum device to break the cryptography involved in the signing process. So what exactly is going on?

The researchers claim to found at least three different ways to, in their words:

… use an existing signed document (e.g., amazon.de invoice) and change the content of the document arbitrarily without invalidating the signatures. Thus, we can forge a document signed by invoicing@amazon.de to refund us one trillion dollars.

That’s not good news if you take into account that the main purpose of digitally signing a document is, well, prevent unauthorized changes in that document. The good news is that you can update your software to fix this flaws because of this research; the main PDF readers companies were given time to fix the issues. The bad news is that if you rely on the signature verification for any sensitive process, you likely want to go back and see if you were using vulnerable software previously and check that documents were correctly validated. I’m thinking about government institutions, banks, insurance companies and so on.

The implications are yet to be seen and probably won’t even be fully known.

There are three classes of attacks that work on different software. I’ll try to go into each one from what I could tell from reading the research.

Continue reading “1 Trillion USD Refund! (PDF Enclosed)” →

35C3: Finding Bugs In Bluetooth

December 30, 2018 by Elliot Williams 24 Comments

[Jiska Classen] and [Dennis Mantz] created a tool called Internal Blue that aims to be a Swiss-army knife for playing around with Bluetooth at a lower level. The ground for their tool is based in three functions that are common to all Broadcom Bluetooth chipsets: one that lets you read arbitrary memory, on that lets you run it, and one that lets you write it. Well, that was easy. The rest of their work was analyzing this code, and learning how to replace the firmware with their own version. That took them a few months of hard reversing work.

In the end, Internal Blue lets them execute commands at one layer deeper — the LMP layer — easily allowing monitoring and injection. In a series of live (and successful!) demos they probe around on a Nexus 6P from a modified Nexus 5 on their desk. This is where they started digging around in the Bluetooth stack of other devices with Broadcom chipsets, and that’s where they started finding bugs.

As is often the case, [Jiska] was just poking around and found an external code handler that didn’t do bounds checking. And that meant that she could run other functions in the firmware simply by passing the ~~address~~ handler offset. Since they’re essentially calling functions at any location in memory, finding which functions to call with which arguments is a process of trial and error, but the ramifications of this include at least a Bluetooth module crash and reset, but can also pull such tricks as putting the Bluetooth module into “Device Under Test” mode, which should only be accessible from the device itself. All of this is before pairing with the device — just walking by is sufficient to invoke functions through the buggy handler.

All the details of this exploit aren’t yet available, because Broadcom hasn’t fixed the firmware for probably millions of devices in the wild. And one of the reasons that they haven’t fixed it is that patching the bug will disclose where the flaw lies in all of the unpatched phones, and not all vendors can be counted on to push out updates at the same time. While they focused on the Nexus 5 cellphone, which is fairly old now, it’s applicable to any device with a similar Broadcom Bluetooth chipset.

Aside from the zero-day bug here, the big story is their Bluetooth analysis framework which will surely help other researchers learn more about Bluetooth, finding more glitches and hopefully helping make Bluetooth more openly scrutinized and more secure. Now anyone with a Raspberry Pi 3/3+ or a Nexus 5, is able to turn it into a low-level Bluetooth investigation tool.

You might know [Jiska] from her previous FitBit hack. If not, be sure to check it out.

Continue reading “35C3: Finding Bugs In Bluetooth” →

Bitcoin’s Double Spending Flaw Was Hush-Hush During Rollout

October 2, 2018 by Pedro Umbelino 15 Comments

For a little while it was possible to spend Bitcoin twice. Think of it like a coin on a string, you put it into the vending machine to get a delicious snack, but if you pull the string quickly enough you could spend it again on some soda too. Except this coin is worth something like eighty-grand.

On September 20, the full details of the latest fix for the Bitcoin Core were published. This information came two days after the fix was actually released. Two vulnerabilities were involved; a Denial of Service vulnerability and a critical inflation vulnerability, both covered in CVE-2018-17144. These were originally reported to several developers working on Bitcoin Core, as well as projects supporting other cryptocurrencies, including ABC and Unlimited.

Let’s take a look at how this worked, and how the network was patched (while being kept quiet) to close up this vulnerability.

Continue reading “Bitcoin’s Double Spending Flaw Was Hush-Hush During Rollout” →

Explaining Efail And Why It Isn’t The End Of Email Privacy

May 21, 2018 by Pedro Umbelino 25 Comments

Last week the PGPocalipse was all over the news… Except that, well, it wasn’t an apocalypse.

A team of researchers published a paper(PDF) where they describe how to decrypt a PGP encrypted email via a targeted attack. The research itself is pretty well documented and, from a security researcher perspective, it’s a good paper to read, especially the cryptography parts.

But we here at Hackaday were skeptical about media claims that Efail had broken PGP. Some media reports went as far as recommending everyone turn off PGP encryption on all email clients., but they weren’t able to back this recommendation up with firm reasoning. In fact, Efail isn’t an immediate threat for the vast majority of people simply because an attacker must already have access to an encrypted email to use the exploit. Advising everyone to disable encryption all together just makes no sense.

Aside from the massive false alarm, Efail is a very interesting exploit to wrap your head around. Join me after the break as I walk through how it works, and what you can do to avoid it.

Continue reading “Explaining Efail And Why It Isn’t The End Of Email Privacy” →

Seek And Exploit Security Vulnerabilities In An Infusion Pump

January 22, 2018 by Sven Gregori 16 Comments

Infusion pumps and other medical devices are not your typical everyday, off-the-shelf embedded system. Best case scenario, you will rarely, if ever, come across one in your life. So for wide-spread exploitation, chances are that they simply seem too exotic for anyone to bother exploring their weaknesses. Yet their impact on a person’s well-being makes potential security holes tremendously more severe in case someone decides to bother one day after all.

[Scott Gayou] is one of those someones, and he didn’t shy away from spending hundreds of hours of his free time inspecting the Smiths Medical Medfusion 4000 infusion pump for any possible security vulnerabilities. Looking at different angles for his threat model, he started with the physical handling of the device’s user interface. This allowed him to enable the external communication protocols settings, which in turn opened to the device’s FTP and Telnet ports. Not to give too much away, but he manages to gain access to both the file system content and — as a result of that — to the system’s login credentials. This alone can be clearly considered a success, but for [Scott], it merely opened a door that eventually resulted in desoldering the memory chips to reverse engineer the bootloader and firmware, and ultimately executing his own code on the device.

Understanding the implications of his discoveries, [Scott] waited long enough to publish his research so the manufacturer could address and handle these security issues. So kudos to him for fighting the good fight. And just in case the thought of someone gaining control over a machine that is crucial to your vitality doesn’t scare you enough yet, go ahead and imagine that device was actually implanted in your body.

Let’s Talk Intel, Meltdown, And Spectre

January 5, 2018 by Mike Szczys 150 Comments

This week we’ve seen a tsunami of news stories about a vulnerability in Intel processors. We’re certain that by now you’ve heard of (and are maybe tired of hearing about) Meltdown and Spectre. However, as a Hackaday reader, you are likely the person who others turn to when they need to get the gist of news like this. Since this has bubbled up in watered-down versions to the highest levels of mass media, let’s take a look at what Meltdown and Spectre are, and also see what’s happening in the other two rings of this three-ring circus.

Meltdown and Spectre in a Nutshell

These two attacks are similar. Meltdown is specific to Intel processors and kernel fixes (basically workarounds implemented by operating systems) will result in a 5%-30% speed penalty depending on how the CPU is being used. Spectre is not limited to Intel, but also affects AMD and ARM processors and kernel fixes are not expected to come with a speed penalty.

Friend of Hackaday and security researcher extraordinaire Joe Fitz has written a superb layman’s explanation of these types of attacks. His use of the term “layman” may be a little more high level than normal — this is something you need to read.

The attack exploits something called branch prediction. To boost speed, these processors keep a cache of past branch behavior in memory and use that to predict future branching operations. Branch predictors load data into memory before checking to see if you have permissions to access that data. Obviously you don’t, so that memory will not be made available for you to read. The exploit uses a clever guessing game to look at other files also returned by the predictor to which you do have access. If you’re clever enough, you can reconstruct the restricted data by iterating on this trick many many times.

For the most comprehensive info, you can read the PDF whitepapers on Meltdown and Spectre.

Update: Check Alan Hightower’s explanation of the Meltdown exploit left as a comment below. Quite good for helping deliver better understanding of how this works.

Frustration from Kernel Developers

These vulnerabilities are in silicon — they can’t be easily fixed with a microcode update which is how CPU manufacturers usually workaround silicon errata (although this appears to be an architectural flaw and not errata per se). An Intel “fix” would amount to a product recall. They’ve already said they won’t be doing a recall, but how would that work anyway? What’s the lead time on spinning up the fabs to replace all the Intel chips in use — yikes!

So the fixes fall on the operating systems at the kernel level. Intel should be (and probably is behind the scenes) bowing down to the kernel developers who are saving their bacon. It is understandably frustrating to have to spend time and resources patching these vulnerabilities, which displaces planned feature updates and improvements. Linus Torvalds has been throwing shade at Intel — anecdotal evidence of this frustration:

“I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.”

That’s the tamest part of his message posted on the Linux Kernel Mailing List.

Stock Sales Kerfuffle is Just a Distraction

The first thing I did on hearing about these vulnerabilities on Tuesday was to check Intel’s stock price and I was surprised it hadn’t fallen much. In fact, peak to peak it’s only seen about an 8% drop this week and has recovered some from that low.

Of course, it came out that back in November Intel’s CEO Bryan Krzanich sold off his Intel stock to the tune of $24 Million, bringing him down to his contractual minimum of shares. He likely knew about Meltdown when arranging that sale. Resist the urge to flame on this decision. Whether it’s legal or not, hating on this guy is just a distraction.

What’s more interesting to me is this: Intel is too big to fail. What are we all going to do, stop using Intel and start using something else? You can’t just pull the chip and put a new one in, in the case of desktop computers you need a new motherboard plus all the supporting stuff like memory. For servers, laptops, and mobile devices you need to replace the entire piece of equipment. Intel has a huge market share, and silicon has a long production cycle. Branch prediction has been commonplace in consumer CPUs going back to 1995 when the Pentium Pro brought it to the x86 architecture. This is a piece of the foundation that will be yanked out and replaced with new designs that provide the same speed benefits without the same risks — but that will take time to make it into the real world.

CPUs are infrastructure and this is the loudest bell to date tolling to signal how important their design is to society. It’s time to take a hard look at what open silicon design would bring to the table. You can’t say this would have been prevented with Open design. You can say that the path to new processors without these issues would be a shorter one if there were more than two companies producing all of the world’s processors — both of which have been affected by these vulnerabilities.