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

Ask Hackaday: Security Questions And Questionable Securities

September 22, 2017 by Lewin Day 41 Comments

Your first school. Your mother’s maiden name. Your favorite color. These are the questions we’re so used to answering when we’ve forgotten a password and need to get back into an account. They’re not a password, yet in many cases have just as much power. Despite this, they’re often based on incredibly insecure information.

Sarah Palin’s Yahoo account is perhaps the best example of this. In September 2008, a Google search netted a birthdate, ZIP code, and where the politician met her spouse. This was enough to reset the account’s password and gain full access to the emails inside.

While we’re not all public figures with our life stories splashed across news articles online, these sort of questions aren’t exactly difficult to answer. Birthdays are celebrated across social media, and the average online quiz would net plenty of other answers. The problem is that these questions offer the same control over an account that a password does, but the answers are not guarded in the same way a password is.

For this reason, I have always used complete gibberish when filling in security questions. Whenever I did forget a password, I was generally lucky enough to solve the problem through a recovery e-mail. Recently, however, my good luck ran out. It was a Thursday evening, and I logged on to check my forex trading account. I realised I hadn’t updated my phone number, which had recently changed.

Upon clicking my way into the account settings, I quickly found that this detail could only be changed by a phone call. I grabbed my phone and dialed, answering the usual name and date of birth questions. I was all set to complete this simple administrative task! I was so excited.

“Thanks Lewin, I’ll just need you to answer your security question.”

“Oh no.”

“The question is… Chutney butler?”

“Yes. Yes it is. Uh…”

“…would you like to guess?”

Needless to say, I didn’t get it.

I was beginning to sweat at this point. To their credit, the call center staffer was particularly helpful, highlighting a number of ways to recover access to the account. Mostly involving a stack of identification documents and a visit to the nearest office. If anything, it was a little reassuring that my account details required such effort to change. Perhaps the cellular carriers of the world could learn a thing or two.

In the end, I realised that I could change my security question with my regular password, and then change the phone number with the new security question. All’s well that ends well.

How do You Deal with Security Questions?

I want to continue taking a high-security approach to my security questions. But as this anecdote shows, you do occasionally need to use them. With that in mind, we’d love to hear your best practices for security questions on accounts that you care about.

Do you store your answers in a similar way to your passwords, using high entropy to best security? When you are forced to use preselected questions do you answer honestly or make up nonsensical answers (and how do you remember what you answered from one account to the next)? When given the option to choose your own questions, what is your simple trick that ensures it all makes sense to you at a later date?

We’d love to hear your best-practice solutions in the comments. While you ponder those questions, one mystery will remain, however — the answer to the question that nobody knows: Chutney butler?

Another Day, Another Air Gap Breached

September 21, 2017 by Dan Maloney 48 Comments

What high-tech, ultra-secure data center would be complete without dozens of video cameras directed both inward and outward? After all, the best informatic security means nothing without physical security. But those eyes in the sky can actually serve as a vector for attack, if this air-gap bridging exploit using networked security cameras is any indication.

It seems like the Cyber Security Lab at Ben-Gurion University is the place where air gaps go to die. They’ve knocked off an impressive array of air gap bridging hacks, like modulating power supply fans and hard drive activity indicators. The current work centers on the IR LED arrays commonly seen encircling the lenses of security cameras for night vision illumination. When a networked camera is compromised with their “aIR-Jumper” malware package, data can be exfiltrated from an otherwise secure facility. Using the camera’s API, aIR-Jumper modulates the IR array for low bit-rate data transfer. The receiver can be as simple as a smartphone, which can see the IR light that remains invisible to the naked eye. A compromised camera can even be used to infiltrate data into an air-gapped network, using cameras to watch for modulated signals. They also demonstrated how arrays of cameras can be federated to provide higher data rates and multiple covert channels with ranges of up to several kilometers.

True, the exploit requires physical access to the cameras to install the malware, but given the abysmal state of web camera security, a little social engineering may be the only thing standing between a secure system and a compromised one.

Continue reading “Another Day, Another Air Gap Breached” →