Security Hacks

1475 Articles

PasswordManagerCode

Tearing Apart An Android Password Manager

January 18, 2015 by 22 Comments

With all of the various web applications we use nowadays, it can be daunting to remember all of those passwords. Many people turn to password management software to help with this. Rather than remembering 20 passwords, you can store them all in a (presumably) secure database that’s protected by a single strong password. It’s a good idea in theory, but only if the software is actually secure. [Matteo] was recently poking around an Android password management software and made some disturbing discoveries.

The app claimed to be using DES encryption, but [Matteo] wanted to put this claim to the test. He first decompiled the app to get a look at the code. The developer used some kind of code obfuscation software but it really didn’t help very much. [Matteo] first located the password decryption routine.

He first noticed that the software was using DES in ECB mode, which has known issues and really shouldn’t be used for this type of thing. Second, the software simply uses an eight digit PIN as the encryption key. This only gives up to 100 million possible combinations. It may sound like a lot, but to a computer that’s nothing. The third problem was that if the PIN is less than eight characters, the same digits are always padded to the end to fill in the blanks. Since most people tend to use four digit pins, this can possibly lower the total number of combinations to just ten thousand.

As if that wasn’t bad enough, it actually gets worse. [Matteo] found a function that actually stores the PIN in a plain text file upon generation. When it comes time to decrypt a password, the application will check the PIN you enter with the one stored in the plain-text file. So really, you don’t have to crack the encryption at all. You can simply open the file and reveal the PIN.

[Matteo] doesn’t name the specific app he was testing, but he did say in the Reddit thread that the developer was supposedly pushing out a patch to fix these issues. Regardless, it goes to show that before choosing a password manager you should really do some research and make sure the developer can be trusted, lest your secrets fall into the wrongs hands.

[via Reddit]

Alarm1

Adding WiFi And SMS To An Alarm System

January 16, 2015 by 17 Comments

[Don] wanted to bring his alarm system into the modern age. He figured that making it more connected would do the trick. Specifically, he wanted his alarm system to send him an SMS message whenever the alarm was tripped.

[Don] first had to figure out a way to trigger an event when the alarm sounds. He found a screw terminal that lead to the siren. When the alarm is tripped, this screw terminal outputs 12V to enable the siren. This would be a good place to monitor for an alarm trip.

[Don] is using an Arduino nano to monitor the alarm signal. This meant that the 12V signal needed to be stepped down. He ran it through a resistor and a Zener diode to lower the voltage to something the Arduino can handle. Once the Arduino detects a signal, it uses an ESP8266 WiFi module to send an email. The address [Don] used is the email-to-SMS address which results in a text message hitting his phone over the cell network.

The Arduino also needed power. [Don] found a screw terminal on the alarm system circuit board that provided a regulated 12V output. He ran this to another power regulator board to lower the voltage to a steady 5V. This provides just the amount of juice the Arduino needs to run, and it doesn’t rely on batteries. [Don] provides a good explanation of the system in the video below. Continue reading “Adding WiFi And SMS To An Alarm System” →

Keystroke Sniffer Hides As A Wall Wart, Is Scary

January 14, 2015 by 79 Comments

For those of us who worry about the security of our wireless devices, every now and then something comes along that scares even the already-paranoid. The latest is a device from [Samy] that is able to log the keystrokes from Microsoft keyboards by sniffing and decrypting the RF signals used in the keyboard’s wireless protocol. Oh, and the entire device is camouflaged as a USB wall wart-style power adapter.

The device is made possible by an Arduino or Teensy hooked up to an NRF24L01+ 2.4GHz RF chip that does the sniffing. Once the firmware for the Arduino is loaded, the two chips plus a USB charging circuit (for charging USB devices and maintaining the camouflage) are stuffed with a lithium battery into a plastic shell from a larger USB charger. The options for retrieving the sniffed data are either an SPI Serial Flash chip or a GSM module for sending the data automatically via SMS.

The scary thing here isn’t so much that this device exists, but that encryption for Microsoft keyboards was less than stellar and provides little more than a false sense of security. This also serves as a wake-up call that the things we don’t even give a passing glance at might be exactly where a less-honorable person might look to exploit whatever information they can get their hands on. Continue past the break for a video of this device in action, and be sure to check out the project in more detail, including source code and schematics, on [Samy]’s webpage.

Thanks to [Juddy] for the tip!

Continue reading “Keystroke Sniffer Hides As A Wall Wart, Is Scary” →

Moonpig

When Responsible Disclosure Isn’t Enough

January 8, 2015 by 37 Comments

Moonpig is a well-known greeting card company in the UK. You can use their services to send personalized greeting cards to your friends and family. [Paul] decided to do some digging around and discovered a few security vulnerabilities between the Moonpig Android app and their API.

First of all, [Paul] noticed that the system was using basic authentication. This is not ideal, but the company was at least using SSL encryption to protect the customer credentials. After decoding the authentication header, [Paul] noticed something strange. The username and password being sent with each request were not his own credentials. His customer ID was there, but the actual credentials were wrong.

[Paul] created a new account and found that the credentials were the same. By modifying the customer ID in the HTTP request of his second account, he was able to trick the website into spitting out all of the saved address information of his first account. This meant that there was essentially no authentication at all. Any user could impersonate another user. Pulling address information may not sound like a big deal, but [Paul] claims that every API request was like this. This meant that you could go as far as placing orders under other customer accounts without their consent.

[Paul] used Moonpig’s API help files to locate more interesting methods. One that stood out to him was the GetCreditCardDetails method. [Paul] gave it a shot, and sure enough the system dumped out credit card details including the last four digits of the card, expiration date, and the name associated with the card. It may not be full card numbers but this is still obviously a pretty big problem that would be fixed immediately… right?

[Paul] disclosed the vulnerability responsibly to Moonpig in August 2013. Moonpig responded by saying the problem was due to legacy code and it would be fixed promptly. A year later, [Paul] followed up with Moonpig. He was told it should be resolved before Christmas. On January 5, 2015, the vulnerability was still not resolved. [Paul] decided that enough was enough, and he might as well just publish his findings online to help press the issue. It seems to have worked. Moonpig has since disabled its API and released a statement via Twitter claiming that, “all password and payment information is and has always been safe”. That’s great and all, but it would mean a bit more if the passwords actually mattered.

Reverse Engineering The Kayak Mobile API

January 3, 2015 by 8 Comments

The travel meta-search website Kayak apparently used to have a public API which is no longer available. We can’t say we mourn the loss of the interface we’d never known about. If you are someone who was automating their searches for that perfect vacation getaway deal, there’s still hope. But either way you’ll like this one. [Shubhro Saha] figured out how to access the API used by the Kayak mobile app. We like that he details how to sniff the traffic between an app and the internet and make sense of what is found.

His tool of choice is the Python package Mitmproxy. We haven’t heard of it but we have heard of Wireshark and [Shabhro] makes the case that Mitmproxy is superior for this application. As the name suggests, you set it up on your computer and use that box’s IP as the proxy connection for your phone. After using the app for a bit, there is enough data to start deconstructing what’s going on between the app and remote server which which it communicates. We could have a lot of fun with this, like seeing what info those free apps are sending home, or looking for security flaws in your own creations.

[Thanks Juan via Twitter]

The Teensy Development Board

Plug Into USB, Get A Reverse Shell

December 21, 2014 by 46 Comments

Computers blindly trust USB devices connected to them. There’s no pop-up to confirm a device was plugged in, and no validation of whether the device should be trusted. This lets you do some nefarious things with a simple USB microcontroller.

We’ve recently seen two examples of this: the USBdriveby and the Teensyterpreter. Both devices are based on the Teensy development board. When connected to a computer, they act as a Human Interface Device to emulate a keyboard and mouse.

The USBdriveby targets OS X. When connected, it changes the DNS server settings to a custom IP, to allow for DNS spoofing of the victim’s machine. This is possible without a password through the OS X System Preferences, but it requires emulating both keystrokes and clicks. AppleScript is used to position the window in a known location, then the buttons can be reliably clicked by code running on the Teensy. After modifying DNS, a reverse shell is opened using netcat. This allows for remote code execution on the machine.

The Teensyterpreter gives a reverse shell on Windows machines. It runs command prompt as administrator, then enters a one-liner to fire up the reverse shell using Powershell. The process happens in under a minute, and works on all Windows versions newer than XP.

With a $20 microcontroller board you can quickly fire up remote shells for… “support purposes”. We’d like to see the two projects merge into a single codebase that supports both operating systems. Bonus points if you can do it on our Trinket Pro. Video demos of both projects after the break.

Continue reading “Plug Into USB, Get A Reverse Shell” →

Towards The Perfect Coin Flip: The NIST Randomness Beacon

December 19, 2014 by 75 Comments

Since early evening on September 5th, 2013 the US National Institute of Standards and Technology (NIST) has been publishing a 512-bit, full-entropy random number every minute of every day. What’s more, each number is cryptographically signed so that you can easily verify that it was generated by the NIST. A date stamp is included in the process, so that you can tell when the random values were created. And finally, all of the values are linked to the previous value in a chain so that you can detect if any of the past numbers in the series have been altered after the next number is published. This is quite an extensive list of features for a list of random values, and we’ll get into the rationale, methods, and uses behind this scheme in the next section, so stick around.

Continue reading “Towards The Perfect Coin Flip: The NIST Randomness Beacon” →