Copy And Paste Deemed Insecure

Back when Windows NT was king, Microsoft was able to claim that it met the strict “Orange Book” C2 security certification. The catch? Don’t install networking and remove the floppy drives.  Turns out most of the things you want to do with your computer are the very things that are a security risk. Even copy and paste.

[Michal Benkowki] has a good summary of his research which boils down to the following attack scenario:

  1. Visit a malicious site.
  2. Copy something to the clipboard which allows the site to put in a dangerous payload.
  3. Visit another site with a browser-based visual editor (e.g., Gmail or WordPress)
  4. Paste the clipboard into the editor.

Continue reading “Copy And Paste Deemed Insecure”

Fail Of The Week: Padlock Purports To Provide Protection, Proves Pathetic

Anyone in the know about IoT security is likely to steer clear of a physical security product that’s got some sort of wireless control. The list of exploits for such devices is a long, sad statement on security as an afterthought, if at all. So it’s understandable if you think a Bluetooth-enabled lock is best attacked via its wireless stack.

As it turns out, the Master 5440D Bluetooth Key Safe can be defeated in a few minutes with just a screwdriver. The key safe is the type a realtor or AirBnB host would use to allow access to a property’s keys. [Bosnianbill] embarked on an inspection of the $120 unit, looking for weaknesses. When physical attacks with a hammer and spoofing the solenoids with a magnet didn’t pay off, he decided to strip off the resilient skin that Master so thoughtfully provided to prevent the box from marring the finish of a door or gate. The denuded device thus revealed its awful secret: two Phillips screws, each securing a locking shackle to the cover. Once those are loose, a little prying with a screwdriver is all that’s need to get the keys to the kingdom.

In a follow-up video posted later, [Bill] took a closer look at another key safe and found that Master had made an anemic effort to fix this vulnerability with a squirt of epoxy in each screw head. It’s weak, at best, since a tap with a hammer compresses the gunk enough to get a grip on the screw.

We really thought [Bosnianbill]’s attack would be electronic, like that time [Dave Jones] cracked a safe with an oscilloscope. Who’d have thought a screwdriver would be the best way past the wireless stack?

Continue reading “Fail Of The Week: Padlock Purports To Provide Protection, Proves Pathetic”

ESP8266 And ESP32 WiFi Hacked!

[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)

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

[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

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

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”