Encryption For The Most Meager Of Devices

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.

Screwdriving

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

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”

Ask Hackaday: Security Questions And Questionable Securities

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?

OptionsBleed – Apache Bleeds In Uncommon Configuration

[Hanno Böck] recently uncovered a vulnerability in Apache webserver, affecting Apache HTTP Server 2.2.x through 2.2.34 and 2.4.x through 2.4.27. This bug only affects Apache servers with a certain configuration in .htaccess file. Dubbed Optionsbleed, this vulnerability is a use after free error in Apache HTTP that causes a corrupted Allow header to be replied by the webserver in response to HTTP OPTIONS requests. This can leak pieces of arbitrary memory from the server process that may contain sensitive information. The memory pieces change after multiple requests, so for a vulnerable host an arbitrary number of memory chunks can be leaked.

Unlike the famous Heartbleed bug in the past, Optionsbleed leaks only small chunks of memory and more importantly only affects a small number of hosts by default. Nevertheless, shared hosting environments that allow for .htaccess file changes can be quite sensitive to it, as a rogue .htaccess file from one user can potentially bleed info for the whole server. Scanning the Alexa Top 1 Million revealed 466 hosts with corrupted Allow headers, so it seems the impact is not huge so far.

The bug appears if a webmaster tries to use the “Limit” directive with an invalid HTTP method. We decided to test this behaviour with a simple .htaccess file like this:

Continue reading “OptionsBleed – Apache Bleeds In Uncommon Configuration”

Bluetooth Vulnerability Affects All Major OS

Security researchers from Armis Labs recently published a whitepaper unveiling eight critical 0-day Bluetooth-related vulnerabilities, affecting Linux, Windows, Android and iOS operating systems. These vulnerabilities alone or combined can lead to privileged code execution on a target device. The only requirement is: Bluetooth turned on. No user interaction is necessary to successfully exploit the flaws, the attacker does not need to pair with a target device nor the target device must be paired with some other device.

The research paper, dubbed BlueBorne (what’s a vulnerability, or a bunch, without a cool name nowadays?), details each vulnerability and how it was exploited. BlueBorne is estimated to affect over five billion devices. Some vendors, like Microsoft, have already issued a patch while others, like Samsung, remain silent. Despite the patches, some devices will never receive a BlueBorne patch since they are outside of their support window. Armis estimates this accounts for around 40% of all Bluetooth enabled devices.

A self-replicating worm that would spread and hop from a device to other nearby devices with Bluetooth turned on was mentioned by the researchers as something that could be done with some more work. That immediately reminds us of the BroadPwn vulnerability, in which the researchers implemented what is most likely the first WiFi only worm. Although it is definitely a fun security exercise to code such worm, it’s really a bad, bad idea… Right?…

So who’s affected?

Continue reading “Bluetooth Vulnerability Affects All Major OS”

Analysing 3D Printer Songs For Hacks

3D printers have become indispensable in industry sectors such as biomedical and manufacturing, and are deployed as what is termed as a 3D print farm. They help reduce production costs as well as time-to-market. However, a hacker with access to these manufacturing banks can introduce defects such as microfractures and holes that are intended to compromise the quality of the printed component.

Researchers at the Rutgers University-New Brunswick and Georgia Institute of Technology have published a study on cyber physical attacks and their detection techniques. By monitoring the movement of the extruder using sensors, monitored sounds made by the printer via microphones and finally using structural imaging, they were able to audit the printing process.

A lot of studies have popped up in the last year or so including papers discussing remote data exfiltration on Makerbots that talk about the type of defects introduced. In a paper by [Belikovetsky, S. et al] titled ‘dr0wned‘, such an attack was documented which allowed a compromised 3D printed propeller to crash a UAV. In a follow-up paper, they demonstrated Digital Audio Signing to thwart Cyber-physical attacks. Check out the video below.

In this new study, the attack is identified by using not only the sound of the stepper motors but also the movement of the extruder. After the part has been manufactured, a CT scan ensures the integrity of the part thereby completing the audit.

Disconnected printers and private networks may be the way to go however automation requires connectivity and is the foundation for a lot of online 3D printing services. The universe of Skynet and Terminators may not be far-fetched either if you consider ambitious projects such as this 3D printed BLDC motor. For now, learn to listen to your 3D printer’s song. She may be telling you a story you should hear.

Thanks for the tip [Qes] Continue reading “Analysing 3D Printer Songs For Hacks”