Downloading Data Through The Display

December 14, 2014 by Brian Benchoff 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 Brian Benchoff 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.

Hacking PayPal Accounts With CSRF

December 4, 2014 by Rick Osgood 17 Comments

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

Reverse Engineering The D-Link WPS Pin Algorithm

October 31, 2014 by Brian Benchoff 36 Comments

A router with WPS requires a PIN to allow other devices to connect, and this PIN should be unique to every router and not derived from other easily accessible data found on the router. When [Craig] took a look at the firmware of a D-Link DIR-810L 802.11ac router, he found exactly the opposite; the WPS PIN was easily decipherable because it was generated entirely from the router’s MAC address and could be reverse engineered by sniffing WiFi.

When [Craig] was taking a look at the disassembled firmware from his router, he noticed a bit of code that accessed the NVRAM used for storing device-specific information like a serial number. This bit of code wasn’t retrieving a WPS pin, but the WAN MAC address instead. Instead of being unique to each device and opaque to every other bit of data on the router, the WPS pin was simply generated (with a bit of math) from the MAC address. This means anyone upstream of the router can easily derive the WPS pin of the router, and essentially gives everyone the keys to the castle of this router.

A few years ago, it was discovered the WPS pin was extremely insecure anyway, able to be brute-forced in a matter of minutes. There are patches router manufacturers could apply to detect these brute force attacks, closing that vulnerability. [Craig]’s code, though, demonstrates that a very large number of D-Link routers effectively broadcast their WPS PIN to the world. To make things even worse, the BSSID found in every wireless frame is also derived from the WAN MAC address. [Craig] has literally broken WPS on a huge number of D-Link routers, thanks to a single engineer that decided to generate the WPS PIN from the MAC address.

[Craig] has an incomplete list of routers that are confirmed affected on his site, along with a list of confirmed unaffected routers.

A Better Anonabox With The Beaglebone Black

October 31, 2014 by Brian Benchoff 29 Comments

A few weeks ago, Anonabox, the ill-conceived router with custom firmware that would protect you from ‘hackers’ and ‘legitimate governments’ drew the ire of tech media. It was discovered that this was simply an off-the-shelf router with an installation of OpenWrt, and the single common thread in the controversy was that, ‘anyone can build that. This guy isn’t doing anything new.’

Finally, someone who didn’t have the terrible idea of grabbing another off the shelf router and putting it up on Kickstarter is doing just that. [Adam] didn’t like the shortcomings of the Anonabox and looked at the best practices of staying anonymous online. He created a Tor dongle in response to this with a Beaglebone Black.

Instead of using wireless like the Anonabox and dozens of other projects, [Andy] is using the Beaglebone as a dongle/Ethernet adapter with all data passed to the computer through the USB port. No, it doesn’t protect your entire network; only a single device and only when it’s plugged in.

The installation process is as simple as installing all the relevent software, uninstalling all the cruft, and configuring a browser. [Adam] was able to get 7Mb/sec down and 250kb/sec up through his Tor-ified Ethernet adapter while only using 40% of the BBB’s CPU.

The Hackaday Prize: Interview With A ChipWhisperer

October 29, 2014 by Brian Benchoff 18 Comments

Every finalist for The Hackaday Prize has some aspect of it that hasn’t been done before; finding the chemical composition of everything with some 3D printed parts is novel, as is building a global network of satellite ground stations with off the shelf components. [Colin]’s ChipWhisperer, though, has some scary and interesting implications. By looking inside a microcontroller as its running, the ChipWhisperer is able to verify – or break – security on these chips. It’s also extremely interesting and somewhat magical being able to figure out what data a chip is processing simply by looking at its power consumption.

We have no idea who the winner of The Hackaday Prize is yet, and I’m hoping to remain ignorant of that fact until the party two weeks from now. Until then, you can read the short interview with [Colin O’Flynn], or check out his five-minute video for the ChipWhisperer below:

Continue reading “The Hackaday Prize: Interview With A ChipWhisperer” →

THP Semifinalist: Secure Your Internets With Web Security Everywhere

September 6, 2014 by Adam Fabio 50 Comments

[Arcadia Labs] has created a great little device in Web Security Everywhere, a semifinalist in The Hackaday Prize. At the center of it all is UnJailPi, a Raspberry Pi device which can act as a secure router between a protected network and the unprotected internet. UnJailPi can create OpenVPN and Tor connections on the fly from its touch screen interface. The full details are right up on [Arcadia’s] Hackaday.io project page.

One of the most amazing things about the project is its creator, [Arcadia Labs]. [Arcadia] started from square one learning python just 1 year ago. Since then he’s become a proficient python coder, and created UnJailPi’s entire user interface with pygame.

[Arcadia] is also working with simple hand tools. He has no access to the CNC routers, 3D printers, or milling machines used in many of the projects we see here on Hackaday. All the work on UnJailPi’s acrylic case was done with a handsaw, a file, and a heck of a lot of patience.

Currently [Arcadia’s] biggest hurdle is finding a good power supply for his project. UnJailPi is designed to work both on AC or an internal battery. His current power circuit throws off enough heat that the Raspberry Pi resets while the battery is charging.

We’re sure [Arcadia] will figure out his power issues, but if you have any suggestions, leave a comment here, or head over to the project page and let him know!

The project featured in this post is a semifinalist in The Hackaday Prize.