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]!

Alarm System Defeated By $2 Wireless Dongle, Nobody Surprised

August 23, 2019 by Dan Maloney 83 Comments

It seems a bit unfair to pile on a product that has already been roundly criticized for its security vulnerabilities. But when that product is a device that is ostensibly deployed to keep one’s family and belongings safe, it’s plenty fair. And when that device is an alarm system that can be defeated by a two-dollar wireless remote, it’s practically a responsibility.

The item in question is the SimpliSafe alarm system, a fully wireless, install-it-yourself system available online and from various big-box retailers. We’ve covered the system’s deeply flawed security model before, whereby SDRs can be used to execute a low-effort replay attack. As simple as that exploit is, it looks positively elegant next to [LockPickingLawyer]’s brute-force attack, which uses a $2 RF remote as a jammer for the 433-MHz wireless signal between sensors and the base unit.

With the remote in close proximity to the system, he demonstrates how easy it would be to open a door or window and enter a property guarded by SimpliSafe without leaving a trace. Yes, a little remote probably won’t jam the system from a distance, but a cheap programmable dual-band transceiver like those offered by Baofeng would certainly do the trick. Not being a licensed amateur operator, [LockPickingLawyer] didn’t test this, but we doubt thieves would have the respect for the law that an officer of the court does.

The bottom line with alarm systems is that you get what you pay for, or sadly, significantly less. Hats off to [LockPickingLawyer] for demonstrating this vulnerability, and for his many other lockpicking videos, which are well worth watching.

Continue reading “Alarm System Defeated By $2 Wireless Dongle, Nobody Surprised” →

Use A Digital Key To Deter Lockpicking

July 19, 2019 by Bryan Cockfield 26 Comments

Spending an hour or two around any consumer-level padlock or house deadbolt lock with a simple lockpicking kit will typically instill a good amount of panic and concern about security. While it’s true that any lock can be defeated, it’s almost comically easy to pick basic locks like this. So, if you’re looking for a level of security that can’t be defeated in two minutes with a tiny piece of metal, you might want to try something a little more advanced.

This project stemmed from an idea to use a YubiKey, a USB hardware token typically used for two-factor authentication, for physical locks instead. The prototype was built around an Arduino UNO, and all of the code and build instructions are available on the project’s site. The creator, [rprinz08], does not have one built inside of a secure enclosure so that would remain an exercise for the reader, but the proof-of-concept is interesting and certainly useful.

While digital keys like this can have their own set of problems (as all locks do), this would be a great solution for anyone needing to lock up anything where physical keys are a liability or a nuisance, where logging is important, or where many people need access to the same lock. The open source code and well-known platform make it easy for anyone to build, too.

The Demise Of The Password

July 14, 2019 by Pat Whetman 73 Comments

Although we hackers will sometimes deliberately throw away our passwords and then try and hack our own phones / WIFI systems for self amusement, for many people including the actual inventor of the password, Fernardo “Corby” Corbató (1926-2019), passwords have become extremely burdensome and dis-functional.

Sadly, Fernando (according to the internet) died on July 12th, and equally sadly, part of his legacy was the ordeal of his “having a three-page crib sheet to stay on top of his own 150+ passwords”.

We’re all used to being badgered by websites to use complex passwords with a minimum length and a minimum number of upper case characters, lower case characters, numerical digits and non alphanumeric characters AND being told at the workplace to use different passwords than at other places AND to being told to change our passwords regularly. The fact that somebody like Fernando had 150 passwords is not surprising.

However, there is some hope, as according to Alex Weinert of Microsoft, in his recent synopsis, “When it comes to composition and length, your password (mostly) doesn’t matter”. This may well sound counter-intuitive but Microsofts’s own research suggests that inter-webs gurus should focus more on “multi-factor authentication (MFA), or great threat detection” rather than badgering the user.

The research goes into quite a bit of detail about passwords and concludes that the biggest threat to password security is when criminals obtain data from insecure ‘breached’ sites, in which case it would not matter if your word was written in hieroglyphics, it would be of no consequence at all. Another interesting conclusion was that by making passwords so intractable this encouraged people such as Fernando himself to write them all down, only for someone to rummage through their office desk (technically known as ‘dumpster diving’) and copy them.

Maybe the end of the password will now swiftly be upon us as technology enables biometrics such as ocular based identifications to be more widely used, but then again we’ve all watched those films where the protagonist scoops the eyeball out of a person’s skull to gain entry to a secure area.

It’s easy to get carried away about passwords and security hype, but it should not be forgotten that Fernardo Corbató was an eminent computer scientist who pioneered ‘Time sharing’ on computers, as detailed in this Hackaday article: Retrotectacular: Time Sharing.

Understanding Elliptic Curve Cryptography And Embedded Security

July 4, 2019 by Maya Posch 26 Comments

We all know the usual jokes about the ‘S’ in ‘IoT’ standing for ‘Security’. It’s hardly a secret that security in embedded, networked devices (‘IoT devices’) is all too often a last-minute task that gets left to whichever intern was unfortunate enough to walk first into the office that day. Inspired by this situation, All About Circuits is publishing a series of articles on embedded security, with a strong focus on network security.

In addition to the primer article, so far they have covered the Diffie-Hellman exchange (using prime numbers, exponentiation and modular arithmetic) and the evolution of this exchange using elliptic curve cryptography (ECC) which prevents anyone from brute-forcing the key. Barring any quantum computers, naturally. All three articles should be understandable by anyone, with a simple, step-by-step format.

The upcoming articles will cover implementing security on microcontrollers specifically. For those who cannot wait to learn more, Wikipedia has a number of articles on the topic of Elliptic Curve Cryptography (comparing it to the more older and still very common RSA encryption) specifically, as well as the Elliptic-Curve Diffie-Hellman key agreement protocol as discussed in the All About Circuits article.

A detail of note here is that the hardest problem in secure communications isn’t to keep the communications going, but to securely exchange the keys in the first place. That’s why a much much computationally expensive key exchange scheme using an asymmetric (or public-key) cryptography scheme is generally used to set up the second part of the communications, which would use a much faster symmetric-key cryptography scheme, where both parties have the means to decode and encode messages using the same private key.

All the math aside, one does have to wonder about how one might denote ‘secure’ IoT. Somehow ‘SIoT’ doesn’t feel very catchy.

Neural Network Smartens Up A Security System

July 3, 2019 by Lewin Day 11 Comments

It’s all well and good having a security camera recording all the time, but that alone can’t sound the alarm in the event of a crime. Motion sensing is of limited use, often being triggered by unimportant stimuli such as moving shadows or passing traffic. [Tegwyn☠Twmffat] wanted a better security system for the farm, and decided that neural networks would likely do the trick.

The main component of the security system is a Raspberry Pi fitted with a camera and a Movidius Neural Compute Stick. This allows the Raspberry Pi to run real-time object identification on video. The Raspberry Pi is programmed to raise the alarm if it detects humans approaching, but ignores the family dog and other false targets. In the event of a detection, the Raspberry Pi sends a signal over LoRa to a base station, which sounds an alarm. The pitch of the alarm increases the closer the target gets to the camera, thanks to some simple code with bounding boxes.

It’s a nifty way to create an intelligent security system, and all the more impressive for being entirely constructed from off-the-shelf parts and code. Neural networks have become increasingly useful; they can even tell when your cat wants to go outside. Video after the break.

Continue reading →

This Week In Security: Use Emacs, Crash A Windows Server, And A Cryptocurrency Heist

June 14, 2019 by Jonathan Bennett 5 Comments

It looks like Al was right, we should all be using Emacs. On the 4th of June, [Armin Razmjou] announced a flaw in Vim that allowed a malicious text file to trigger arbitrary code execution. It’s not every day we come across a malicious text file, and the proof of concept makes use of a clever technique — escape sequences hide the actual payload. Printing the file with cat returns “Nothing here.” Cat has a “-v” flag, and that flag spills the secrets of our malicious text file. For simplicity, we’ll look at the PoC that doesn’t include the control characters. The vulnerability is Vim’s modeline function. This is the ability to include editor options in a text file. If a text file only works with 80 character columns, a modeline might set “textwidth=80”. Modeline already makes use of a sandbox to prevent the most obvious exploits, but [Armin] realized that the “:source!” command could run the contents of a file outside that sandbox. “:source! %” runs the contents of the current file — the malicious text file.

:!uname -a||" vi:fen:fdm=expr:fde=assert_fails("source\!\ \%"):fdl=0:fdt="

Taking this apart one element at a time, the “:!” is the normal mode command to run something in the shell, so the rest of the line is what gets run. “uname -a” is the arbitrary command, benign in this case. Up next is the OR operator, “||” which fully evaluates the first term first, and only evaluates what comes after the operator if the first term returns false. In this case, it’s a simple way to get the payload to run even though the rest of the line is garbage, as far as bash is concerned. “vi:” informs Vim that we have a modeline string. “:fen” enables folding, and “:fdm=expr” sets the folding method to use an expression. This feature is usually used to automatically hide lines matching a regular expression. “:fde=” is the command to set the folding expression. Here’s the exploit, the folding expression can be a function like “execute()” or “assert_fails()”, which allows calling the :source! command. This pops execution out of the sandbox, and begins executing the text file inside vim, just as if a user were typing it in from the keyboard. Continue reading “This Week In Security: Use Emacs, Crash A Windows Server, And A Cryptocurrency Heist” →