Security Hacks

1425 Articles

Colette Biometric Security Purse Screams When Stolen

November 8, 2017 by 18 Comments

A team of college hackers was disappointed with the selection of secure purses available. Nearly every purse on the market is attractive, secure, or neither so they are designing their own security purse with some style. Instead of just brass or leather clasps keeping unwanted hands out, they are upgrading to automation and steel.

Everything starts with a fingerprint reader connected to an Arduino. Once an acceptable finger is recognized, a motor opens a coffin lock, also known as a butt-joint fastener, which can be completely hidden inside the purse and provides a lot of holding force. That is enough to keep quick fingers from reaching into an unattended purse.

In the case of a mugging, a sound grenade will trigger which should convince most thieves to quickly abandon it. Then, the internal GPS tells the owner where the purse can be found.

We can’t imagine a real-life purse thief prepared to tackle this kind of hardware. Hackaday loves knowing the ins and out of security from purses to cars and of course IoT.

Eavesdropping With An ESP8266

November 2, 2017 by 16 Comments

In the old days, spies eavesdropped on each other using analog radio bugs. These days, everything’s in the cloud. [Sebastian] from [Hacking Beaver]  wondered if he could make a WiFi bug that was small and cheap besides. Enter the ESP8266 and some programming wizardry.

[Sebastian] is using a NodeMCU but suggests that it could be pared down to any ESP8266 board — with similar cuts made to the rest of the electronics — but has this working as a proof of concept. A PIC 18 MCU samples the audio data from a microphone at 10 kHz with an 8-bit resolution, dumping it into a 512-byte buffer. Once that fills, a GPIO pin is pulled down and the ESP8266 sends the data to a waiting TCP server over the WiFi which either records or plays the audio in real-time.

[Sebastian] has calculated that he needs at least 51.2 ms to transfer the data which this setup easily handles, but there are occasional two to three second glitches that come out of the blue. To address this and other hangups, [Sebastian] has the ESP8266 control the PIC’s reset pin so that the two are always in sync.

Continue reading “Eavesdropping With An ESP8266” →

DUHK: Don’t Use Hard-Coded Keys

October 25, 2017 by 31 Comments

The title reads like the name of a lecture in cryptography 101 or the first rule of Crypto Club. ‘DUHK‘ is in fact neither of those but the name of a recently disclosed vulnerability in a pseudorandom number generating algorithm (PNRG) that was until recently part of the federal standard X9.31.

Random numbers are essential to viable cryptography. They are also hard to obtain leading to solutions like using the physical properties of semiconductors or decaying matter, that are governed by quantum effects. The next best solution is to log events that are hard to predict like the timing of strokes on a keyboard. The weakest source of randomness is math, which makes sense, because one of maths most popular features is its predictability. Mathematical solutions have the one redeeming quality of being able to produce a lot of numbers that look random to a human in a short time.

PNRGs require a starting point from which they begin to produce their output. Once this seed is known the produced sequence becomes predictable.

The X9.31 PNRG is an algorithm that is used in various cryptographic algorithms and has been certified in the Federal Information Processing Standards for decades until it was dropped from the list of approved standards in 2016. The researchers behind DUHK found out that the standard allowed the seed to be stored in the source code of its implementation. The next step was to look for software that did this and they found X9.31 in an older version of FortiOS running on VPN gateways.

Should I be Worried?

Probably, maybe not. The analysis (PDF) published by the team behind DUHK notes that the vulnerability is limited to legacy implementations and doesn’t allow to takeover the device running them, only to eavesdrop on ‘secure’ connections. The scope of this is much more limited than exploits like remote code execution via bluetooth. It is on the other hand providing a strong case for handling standards and technical certifications with extreme scrutiny. The teams conduct also gives insight into the best practises for white-hat hacking which are frequently discussed around here. And they have a great theme song.

Exploiting Weak Crypto On Car Key Fobs

October 18, 2017 by 55 Comments

[tomwimmenhove] has found a vulnerability in the cryptographic algorithm that is used by certain Subaru key fobs and he has open-sourced the software that drives this exploit. All you need to open your Subaru is a RasPi and a DVB-T dongle, so you could complain that sharing this software equates to giving out master keys to potential car thieves. On the other hand, this only works for a limited number of older models from a single manufacturer — it’s lacking in compatibility and affordability when compared to the proverbial brick.

This hack is much more useful as a case study than a brick is, however, and [tomwimmenhove]’s work points out some bad design on the manufacturer’s side and as such can help you to avoid these kind of mistakes. The problem of predictable keys got great treatment in the comments of our post about an encryption scheme for devices low in power and memory, for instance.

Those of you interested in digital signal processing may also want to take a look at his code, where he implements filtering, demodulation and decoding of the key fob’s signal. The transmission side is handled by rpitx and attacks against unencrypted communications with this kind of setup have been shown here before. There’s a lot going on here that’s much more interesting than stealing cars.

[Via Bleeping Computer]

Continue reading “Exploiting Weak Crypto On Car Key Fobs” →

Practical Public Key Cryptography

October 18, 2017 by 25 Comments

Encryption is one of the pillars of modern-day communications. You have devices that use encryption all the time, even if you are not aware of it. There are so many applications and systems using it that it’s hard to begin enumerating them. Ranging from satellite television to your mobile phone, from smart power meters to your car keys, from your wireless router to your browser, and from your Visa to your Bitcoins — the list is endless.

One of the great breakthroughs in the history of encryption was the invention of public key cryptography or asymmetrical cryptography in the 70’s. For centuries traditional cryptography methods were used, where some secret key or scheme had to be agreed and shared between the sender and the receiver of an encrypted message.

Asymmetric cryptography changed that. Today you can send an encrypted message to anyone. This is accomplished by the use of a pair of keys: one public key and one private key. The key properties are such that when something is encrypted with the public key, only the private key can decrypt it and vice-versa. In practice, this is usually implemented based on mathematical problems that admit no efficient solution like certain integer factorization, discrete logarithm and elliptic curve relationships.

But the game changer is that the public key doesn’t have to be kept secret. This allows cryptography to be used for authentication — proving who someone is — as well as for encryption, without requiring you to have previously exchanged secrets. In this article, I’ll get into the details of how to set yourself up so that anyone in the world is able to send you an e-mail that only you can read.
Continue reading “Practical Public Key Cryptography” →

Bad RSA Library Leaves Millions Of Keys Vulnerable

October 17, 2017 by 20 Comments

So, erm… good news everyone! A vulnerability has been found in a software library responsible for generating RSA key pairs used in hardware chips manufactured by Infineon Technologies AG. The vulnerability, dubbed ROCA, allows for an attacker, via a Coppersmith’s attack, to compute the private key starting with nothing more than the public key, which pretty much defeats the purpose of asymmetric encryption altogether.

Affected hardware includes cryptographic smart cards, security tokens, and other secure hardware chips produced by Infineon Technologies AG. The library with the vulnerability is also integrated in authentication, signature, and encryption tokens of other vendors and chips used for Trusted Boot of operating systems. Major vendors including Microsoft, Google, HP, Lenovo, and Fujitsu already released software updates and guidelines for mitigation.

The researchers found and analysed vulnerable keys in various domains including electronic citizen documents (750,000 Estonian identity cards), authentication tokens, trusted boot devices, software package signing, TLS/HTTPS keys and PGP. The currently confirmed number of vulnerable keys found is about 760,000 but could be up to two to three orders of magnitude higher.

Devices dating back to at least 2012 are affected, despite being NIST FIPS 140-2 and CC EAL 5+ certified.. The vulnerable chips were not necessarily sold directly by Infineon Technologies AG, as the chips can be embedded inside devices of other manufacturers.

Continue reading “Bad RSA Library Leaves Millions Of Keys Vulnerable” →

Aussies Propose Crackdown On Insecure IoT Devices

October 16, 2017 by 36 Comments

We’ve all seen the stories about IoT devices with laughably poor security. Both within our community as fresh vulnerabilities are exposed and ridiculed, and more recently in the wider world as stories of easily compromised baby monitors have surfaced in mass media outlets. It’s a problem with its roots in IoT device manufacturers treating their products as appliances rather than software, and in a drive to produce them at the lowest possible price.

The Australian government have announced that IoT security is now firmly in their sights, announcing a possible certification scheme with a logo that manufacturers would be able to use if their products meet a set of requirements. Such basic security features as changeable, non-guessable, and non-default passwords are being mentioned, though we’re guessing that would also include a requirement not to expose ports to the wider Internet. Most importantly it is said to include a requirement for software updates to fix known vulnerabilities. It is reported that they are also in talks with other countries to harmonize some of these standards internationally.

It is difficult to see how any government could enforce such a scheme by technical means such as disallowing Internet connection to non-compliant devices, and if that was what was being proposed it would certainly cause us some significant worry. Therefore it’s likely that this will be a consumer certification scheme similar to for example the safety standards for toys, administered as devices are imported and through enforcement of trading standards legislation. The tone in which it’s being sold to the public is one of “Think of the children” in terms of compromised baby monitors, but as long-time followers of Hackaday will know, that’s only a small part of the wider problem.

Thanks [Bill Smith] for the tip.

Baby monitor picture: Binatoneglobal [CC BY-SA 3.0].