Inside Two-Factor Authentication Apps

October 16, 2017 by Elliot Williams 66 Comments

Passwords are in a pretty broken state of implementation for authentication. People pick horrible passwords and use the same password all over the place, firms fail to store them correctly and then their databases get leaked, and if anyone’s looking over your shoulder as you type it in (literally or metaphorically), you’re hosed. We’re told that two-factor authentication (2FA) is here to the rescue.

Well maybe. 2FA that actually implements a second factor is fantastic, but Google Authenticator, Facebook Code Generator, and any of the other app-based “second factors” are really just a second password. And worse, that second password cannot be stored hashed in the server’s database, which means that when the database is eventually compromised, your “second factor” blows away with the breeze.

Second factor apps can improve your overall security if you’re already following good password practices. We’ll demonstrate why and how below, but the punchline is that the most popular 2FA app implementations protect you against eavesdropping by creating a different, unpredictable, but verifiable, password every 30 seconds. This means that if someone overhears your login right now, they wouldn’t be able to use the same login info later on. What 2FA apps don’t protect you against, however, are database leaks.

Continue reading “Inside Two-Factor Authentication Apps” →

Oh Great, WPA2 Is Broken

October 16, 2017 by Brian Benchoff 131 Comments

WPA2, the standard security for Wi-Fi networks these days, has been cracked due to a flaw in the protocol. Implications stemming from this crack range from decrypting Wi-Fi, hijacking connections, and injecting content. It’s fair to say, WPA2 is now Considered Harmful. The paper is available here (PDF).

This is a proof-of-concept exploit, and like all headline-making network security stories, it has a name. It’s called KRACK, for Key Reinstallation Attack. The key insight to this exploit is a vulnerability in the handshaking between routers and devices to establish a secure connection.

This is not the first time the researchers behind this exploit have found holes in WPA2. In a paper published by the KRACK researchers at the USENIX Symposium last August (PDF), they showed that the Random Number Generator used in 802.11 is flawed, ill-defined, and insecure. The researchers have also spoken at 33c3 on predicting WPA2 Group Keys.

The practical consequences of a poor definition and implementation of an RNG can be found in consumer hardware. The researchers found that in MediaTek-based routers, the only source of randomness is the current time. Meanwhile Broadcom-based routers do not use the RNG proposed by the 802.11 spec, but instead take the MD5 of the current time in microseconds. The researchers do not mention if the current time is a secret.

So what do we do now?

This has happened before. In 2001, WEP, the Wi-Fi security protocol many security-ignorant people are still running, was cracked in much the same was as KRACK. This quickly led to the development of Aircrack, and in 2003, the Wi-Fi Alliance rolled out WPA and WPA2. Sure, you can still select a deprecated security protocol for your router, but the problem of WEP hacking is as solved as it’s ever going to be.

The early 2000s were a different time when it came to wireless networks, though here in 2017 Wi-Fi permeates every cubic inch of our lives. Everything and everyone has Wi-Fi now. This is going to be a bit bigger than cracking WEP, but it remains possible to patch devices to ensure that this exploit is rendered useless. Install those security updates, people! Of course there will still be millions of unpatched devices in a year’s time, and for those routers, IoT baubles, and other wireless devices, turning on WPA2 will be akin to having no security at all.

That said, this isn’t a world-ending Armageddon in the way the botnet of webcams was. You will only be vulnerable if an attacker is within range of your router, and you will still be secure if you’re accessing secure websites. However, turning off Wi-Fi on your phone, relying on mobile data, not ignoring HTTPS cert warnings, and plugging into an Ethernet port might not be a bad idea.

Encryption For The Most Meager Of Devices

October 15, 2017 by Jenny List 57 Comments

It seems that new stories of insecure-by-design IoT devices surface weekly, as the uneasy boundary is explored between the appliance and the Internet-connected computer. Manufacturers like shifting physical items rather than software patches, and firmware developers may not always be from the frontline of Internet security.

An interesting aside on the security of IoT traffic comes from [boz], who has taken a look at encryption of very low data rate streams from underpowered devices. Imagine perhaps that you have an Internet-connected sensor which supplies only a few readings a day that you would like to keep private. Given that your sensor has to run on tiny power resources so a super-powerful processor is out of the question, how do you secure your data? Simple encryption schemes are too easily broken.

He makes the argument for encryption from a rather unexpected source: a one-time pad. We imagine a one-time pad as a book with pages of numbers, perhaps as used by spies in Cold-War-era East Berlin or something. Surely storing one of those would be a major undertaking! In fact a one-time pad is simply a sequence of random keys that are stepped through, one per message, and if your message is only relatively few bytes a day then you have no need to generate more than a few K of pad data to securely encrypt it for years. Given that even pretty meager modern microcontrollers have significant amounts of flash at their disposal, pad storage for sensor data of this type is no longer a hurdle.

Where some controversy might creep in is the suggestion that a pad could be recycled when its last entry has been used. You don’t have to be a cryptologist to know that reusing a one-time pad weakens the integrity of the cypher, but he has a valid answer there too, If the repeat cycle is five years, your opponent must have serious dedication to capture all packets, and at that point it’s worth asking yourself just how sensitive the sensor data in question really is.

Encrypt Data On The Fly On A Pi With Cryptopuck

October 13, 2017 by Tom Nardi 22 Comments

There was a time that encryption was almost a dirty word; a concept that really only applied to people with something to hide. If you said you wanted to encrypt your hard drive, it may as well have been an admission to a crime. But now more than ever it’s clear that encryption, whether it’s on our personal devices or on the web, is a basic necessity in a digital society. The age of Big Data is upon us, and unless you’re particularly fond of being a row in a database, you need to do everything you can to limit the amount of plaintext data you have.

Of course, it’s sometimes easier said than done. Not everyone has the time or desire to learn how the different cryptographic packages work, others may be working on systems that simply don’t have the capability. What do you do when you want to encrypt some files, but the traditional methods are out of reach?

Enter the latest project from [Dimitris Platis]: Cryptopuck. By combining the ever-versatile Raspberry Pi Zero, some clever Python programs, and a few odds and ends in a 3D printed case, he has created a completely self-contained encryption device that anyone can use. Stick a USB flash drive in, wait for the LED to stop blinking, and all your files are now securely encrypted and only accessible by those who have the private key. [Dimitris] envisions a device like this could be invaluable for reporters and photographers on the front lines, protesters, or really anyone who needs a discreet way of quickly securing data but may not have access to a computer.

The hardware side is really just the Pi, a switch, a single LED for notifications, and a battery. The real magic comes from the software, where [Dimitris] has leveraged PyCrypto to perform the AES-256 encryption, and a combination of pyinotify and udiskie to detect new mounted volumes and act on them. The various Python scripts that make up the Cryptopuck suite are all available on the project’s GitHub page, but [Dimitris] makes it very clear the software is to be considered a proof of concept, and has not undergone any sort of security audit.

For some background information on how the software used by the Cryptopuck works you may want to check out this excellent primer from a few years back; though if you’d like to read up on why encryption is so important, you don’t need to go nearly as far back in time.

Continue reading “Encrypt Data On The Fly On A Pi With Cryptopuck” →

Screwdriving

October 9, 2017 by Pedro Umbelino 1 Comment

Screwdriving! It’s like wardriving but instead of discovering WiFi networks, the aim is to discover Bluetooth Low Energy (BLE) devices of a special kind: adult toys. Yes, everything’s going to be connected, even vibrators. Welcome to the 21st century.

Security researcher [Alex Lomas] recently found that a lot of BLE-enabled adult toys are completely vulnerable to malicious attacks. In fact, they are basically wide open to anyone by design.

“Adult toys lend themselves to being great testbeds for IoT research: they’re BLE, they’re relatively cheap, they’re accessible and have companion apps for the full spectrum of testing.”

Yes… great test beds… Erm, anyway, [Alex Lomas] found that there is no PIN nor password protection, or the PIN is static and generic (0000 / 1234) on every Bluetooth adult toy analysed. Manufacturers don’t want to go through the hassle, presumably because sex toys lack displays that would enable a classic Bluetooth pairing, with random PIN and so on. While this might be a valid point, almost all electronic appliances have an “ON/OFF” button for input and some LED (or even vibration in these cases) that allow some form of output. It could be done, and it’s not like vibrators are the only minimalistic appliances out there in the IoT world.

Although BLE security is crippled by design (PDF), it is possible to add security on top of flawed protocols. The average web-browser does it all the time. The communications don’t have to be clear-text where you can literally see “Vibrate:10” flying around in packets. Encryption could be implemented on top of the BLE link between the app and the device, for instance. Understandably, security in some devices is not absolutely critical. That being said, the security bar doesn’t have to be lowered to zero — it’s not safe for work or play.

[via Arstechnica]

Your Hard Disk As An Accidental Microphone

October 8, 2017 by Jenny List 30 Comments

We’re used to attaching peripherals to our computers, when we have a need for them to interact with the world around them. An Arduino Uno needs a shield to turn on the lights, for example. Just sometimes though there is the potential for unintended interaction between a computer and the real physical world which surrounds it, and it’s one of those moments that [Alfredo Ortega] has uncovered in his talk at the EKO Party conference in Buenos Aires. He demonstrates how a traditional spinning-rust computer hard disk interacts with vibration in its surroundings, and can either become a rudimentary microphone, or be compromised by sound at its resonant frequency (PDF).

It seems that you can measure the response time of the hard drive head during a read operation without requiring any privilege escalation. This timing varies with vibration, so can be used to reconstruct the sound that the drive is facing. Thus it becomes a microphone, albeit not a very good one with a profoundly bass-heavy response. He goes on to investigate the effect of sound on the drive, discovering that it has a resonant frequency at which the vibration causes it to be unreadable.

Sadly the talk itself appears not yet to be online, but given that previous years’ EKO talks are on YouTube it is likely that when the dust has settled you will be able to see it in full. Meanwhile he’s posted a video demonstration which we’ve posted below the break.

Continue reading “Your Hard Disk As An Accidental Microphone” →

Seek Out Scammers With Skimmer Scanner

September 25, 2017 by Jenny List 39 Comments

Last week we reported on some work that Sparkfun had done in reverse engineering a type of hardware card skimmer found installed in gasoline pumps incorporating card payment hardware. The device in question was a man-in-the-middle attack, a PIC microcontroller programmed to listen to the serial communications between card reader and pump computer, and then store the result in an EEPROM.

The devices featured a Bluetooth module through which the crooks could harvest the card details remotely, and this in turn provides a handy way to identify them in the wild. If you find a Bluetooth connection at the pump bearing the right identification and with the right password, it can then be fingered as a skimmer by a simple response test. And to make that extra-easy they had written an app, which when we reported on it was available from a GitHub repository.

In a public-spirited move, they are now calling upon the hardware hacker and maker community to come together today, Monday, September 25th, and draw as much attention as possible to these devices in the wild, and with luck to get a few shut down. To that end, they have put a compiled version of the app in the Google Play Store to make it extra-easy to install on your phone, and they are asking for your help. They are asking for people to first read their tutorial linked above, then install the app and take it on the road. Then should any of you find a skimmer, please Tweet about it including your zip code and the #skimmerscanner hashtag. Perhaps someone with a bit of time on their hands might like to take such a feed of skimmer location data and map it.

It would be nice to think that this work might draw attention to the shocking lack of security in gas pumps that facilitates the skimmers, disrupt the finances of a few villains, and even result in some of them getting a free ride in a police car. We can hope, anyway.

Gasoline pump image: Michael Rivera [CC BY-SA 3.0].