Security Hacks

1479 Articles

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” →

SingLock

SingLock Protects Your Valuables From Shy People

December 17, 2014 by 14 Comments

Two Cornell students have designed their own multi-factor authentication system. This system uses a PIN combined with a form of voice recognition to authenticate a user. Their system is not as simple as speaking a passphrase, though. Instead, you have to sing the correct tones into the lock.

The system runs on an ATMEL MEGA1284P. The chip is not sophisticated enough to be able to easily identify actual human speech. The team decided to focus their effort on detecting pitch instead. The result is a lock that requires you to sing the perfect sequence of pitches. We would be worried about an attacker eavesdropping and attempting to sing the key themselves, but the team has a few mechanisms in place to protect against this attack. First, the system also requires a valid PIN.  An attacker can’t deduce your PIN simply by listening from around the corner. Second, the system also maintains the user’s specific voice signature.

The project page delves much more deeply into the mathematical theory behind how the system works. It’s worth a read if you are a math or audio geek. Check out the video below for a demonstration. Continue reading “SingLock Protects Your Valuables From Shy People” →

Downloading Data Through The Display

December 14, 2014 by 75 Comments

HIPAA – the US standard for electronic health care documentation – spends a lot of verbiage and bureaucratese on the security of electronic records, making a clear distinction between the use of records by health care worker and the disclosure of records by health care workers. Likewise, the Federal Information Security Management Act of 2002 makes the same distinction; records that should never be disclosed or transmitted should be used on systems that are disconnected from networks.

This distinction between use and disclosure or transmission is of course a farce; if you can display something on a screen, it can be transmitted. [Ian Latter] just gave a talk at Kiwicon that provides the tools to do just that. He calls it ThruGlassXfer (TGXf), and it does exactly what it says on the tin: anything that can be displayed on a screen can be transmitted. All you need are the right tools.

Continue reading “Downloading Data Through The Display” →

Reverse Engineering Capcom’s Crypto CPU

December 12, 2014 by 26 Comments

There are a few old Capcom arcade titles – Pang, Cadillacs and Dinosaurs, and Block Block – that are unlike anything else ever seen in the world of coin-ops. They’re old, yes, but what makes these titles exceptional is the CPU they run on. The brains in the hardware of these games is a Kabuki, a Z80 CPU that had a few extra security features. why would Capcom produce such a thing? To combat bootleggers that would copy and reproduce arcade games without royalties going to the original publisher. It’s an interesting part of arcade history, but also a problem for curators: this security has killed a number of arcade machines, leading [Eduardo] to reverse engineering and document the Kabuki in full detail.

While the normal Z80 CPU had a pin specifically dedicated to refreshing DRAM, the Kabuki repurposed this pin for the security functions on the chip. With this pin low, the Kabuki was a standard Z80. When the pin was pulled high, it served as a power supply input for the security features. The security – just a few bits saved in memory – was battery backed, and once this battery was disconnected, the chip would fail, killing the game.

Plugging Kabuki into an old Amstrad CPC 6128 without the security pin pulled high allowed [Eduardo] to test all the Z80 instructions, and with that no surprises were found; the Kabuki is fully compatible with every other Z80 on the planet. Determining how Kabuki works with that special security pin pulled high is a more difficult task, but the Mame team has it nailed down.

The security system inside Kabuki works through a series of bitswaps, circular shifts, XORs, each translation different if the byte is an opcode or data. The process of encoding and decoding the security in Kabuki is well understood, but [Eduardo] had a few unanswered questions. What happens after Kabuki lost power and the memory contents – especially the bitswap, address, and XOR keys – vanished? How was the Kabuki programmed in the factory? Is it possible to reprogram these security keys, allowing one Kabuki to play games it wasn’t manufactured for?

[Eduardo] figured being able to encrypt new, valid code was the first step to running code encrypted with different keys. To test this theory, he wrote a simple ‘Hello World’ for the Capcom hardware that worked perfectly under Mame. While the demo worked perfectly under Mame, it didn’t work when burned onto a EPROM and put into real Capcom hardware.

That’s where this story ends, at least for the time being. The new, encrypted code is valid, Mame runs the encrypted code, but until [Eduardo] or someone else can figure out any additional configuration settings inside the Kabuki, this project is dead in the track. [Eduardo] will be back some time next week tearing the Kabuki apart again, trying to unravel the mysteries of what makes this processor work.