security

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.

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.

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.

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.

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.

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.

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.

The computer security industry has made many positive changes since the early days of computing. One thing that seems to be catching on with bigger tech companies is bug bounty programs. PayPal offers such a program and [Yasser] decided to throw his hat in the ring and see if he could find any juicy vulnerabilities. His curiosity paid off big time.

Paypal is a huge player in the payment processing world, but that doesn’t mean they aren’t without their flaws. Sometimes the bigger the target, the more difficult it is to find problems. [Yasser] wanted to experiment with a cross-site request forgery attack. This type of attack typically requires the attacker to trick the victim into clicking a malicious link. The link would then impersonate the victim and make requests on the victim’s behalf. This is only made possible if the victim is logged into the target website.

PayPal has protection mechanisms in place to prevent this kind of thing, but [Yasser] found a loophole. When a user logs in to make a request, PayPal gives them an authentication token. This token is supposed to be valid for one user and one request only. Through experimentation, [Yasser] discovered a way to obtain a sort of “skeleton key” auth token. The attacker can attempt to initiate a payment transfer without first logging in to any PayPal account. Once the transfer is attempted, PayPal will request the user to authenticate. This process produces an auth token that apparently works for multiple requests from any user. It renders the authentication token almost entirely ineffective.

Once the attacker has a “universal auth token”, he can trick the victim into visiting a malicious web page. If the user is logged into their PayPal account at the time, the attacker’s webpage can use the universal auth token to trick the victim’s computer into making many different PayPal requests. Examples include adding email addresses to the account, changing the answers to security questions, and more. All of this can be done simply by tricking the user into clicking on a single link. Pretty scary.

[Yasser] was responsible with his disclosure, of course. He reported the bug to PayPal and reports that it was fixed promptly. It’s always great to see big companies like PayPal promoting responsible disclosure and rewarding it rather than calling the lawyers. Be sure to catch a video demonstration of the hack below. Continue reading “Hacking PayPal Accounts With CSRF”→