Barcodes That Hack Devices

February 17, 2016 by Elliot Williams 76 Comments

[virustracker] has been playing around with barcodes lately, and trying to use them as a vector to gain control of the system that’s reading them. It’s a promising attack — nobody expects a takeover via barcodes. The idea isn’t new, and in fact we’ve seen people trying to drop SQL attacks in barcodes long ago, but [virustracker] put a few different pieces together and came up with a viable attack.

The trick is that many POS terminals and barcode readers support command characters in their programming modes. Through use of these Advanced Data Formatting (ADF) modes, [virustracker] sends Windows-Key-r, and then cmd.exe, ftps a file down, and runs it. Whatever computer is on the other side of the barcode scanner has just been owned. ADF even supports a delay function to allow time for the command window to pop up before running the rest of the input.

The article details how they got their payload from requiring more than ten individual barcodes down to four. Still, it’s a suspicious-looking attack to try to pull off where other people (think cashiers) are looking. However, we have many automated machines in our everyday life that use barcodes. How many of these are vulnerable is an open question. [virustracker] suggests lottery machines, package-delivery automats, and even hospitals.

The defense is simple, and it’s the same as everywhere else: disable the debug and configuration modes in your production systems, and sanitize your input. Yes, even the barcodes.

The Internet Of Broken Things (or, Why Am I So Cold?)

February 8, 2016 by Al Williams 68 Comments

Although the Internet of Things (IoT) is a reasonably new term, the idea isn’t really all that new. Many engineers and hackers have created networked embedded systems for many years. So what’s different? Two things: the Internet is everywhere and the use of connected embedded systems in a consumer setting.

Like anything else, there’s a spectrum of usefulness to IoT. Watching The Expanse, the other day (which is not a bad show, by the way), I noticed that if you had the right IoT lights, you could run an app that would change your lighting to suit the show in real-time. I don’t have those lights, but I suppose when the action moves to a dark sub-basement, your lights dim and when you are in a space ship’s reactor room, they turn red, and so on. Fun, but hardly useful or life-changing.

On the other hand, there are some very practical IoT items like the Nest thermostat. It might seem lazy to want to monitor and control your thermostat from your tablet, but if you are frequently away from home, or you have multiple houses, it can be a real positive to be able to control things remotely. With the recent blizzard on the U.S. east coast, for example, it would be great to turn on the heat in your weekend cottage 150 miles away while you were still at work or home. However, the Nest recently had a hiccup during an upgrade and it has made many of their customers mad (and cold). I’ll get back to that, in a minute. First, I want to talk about the problems with deploying something that will be in many varied environments (like people’s homes) that controls something real.

Continue reading “The Internet Of Broken Things (or, Why Am I So Cold?)” →

Reverse Engineering A WiFi Security Camera

February 6, 2016 by Brian Benchoff 22 Comments

The Internet of Things is slowly turning into the world’s largest crappy robot, with devices seemingly designed to be insecure, all waiting to be rooted and exploited by anyone with the right know-how. The latest Internet-enabled device to fall is a Motorola Focus 73 outdoor security camera. It’s quite a good camera, save for the software. [Alex Farrant] and [Neil Biggs] found the software was exceptionally terrible and would allow anyone to take control of this camera and install new firmware.

The camera in question is the Motorola Focus 73 outdoor security camera. This camera connects to WiFi, features full pan, tilt, zoom controls, and feeds a live image and movement alerts to a server. Basically, it’s everything you need in a WiFi security camera. Setting up this camera is simple – just press the ‘pair’ button and the camera switches to host mode and sets up an open wireless network. The accompanying Hubble mobile app scans the network for the camera and prompts the user to connect to it. Once the app connects to the camera, the user is asked to select a WiFi connection to the Internet from a list. The app then sends the security key over the open network unencrypted. By this point, just about anyone can see the potential for an exploit here, and since this camera is usually installed outdoors – where anyone can reach it – evidence of idiocy abounds.

Once the camera is on the network, there are a few provisions for firmware upgrades. Usually, firmware upgrades are available by downloading from ‘private’ URLs and sent to the camera with a simple script that passes a URL directly into the shell as root. A few facepalms later, and [Alex] and [Neil] had root access to the camera. The root password was ‘123456’.

While there’s the beginnings of a good Internet of Camera in this product, the design choices for the software are downright stupid. In any event, if you’re looking for a network camera that you own – not a company with a few servers and a custom smartphone app – this would be near the top of the list. It’s a great beginning for some open source camera firmware.

Thanks [Mathieu] for the tip.

“Hello Barbie” Not An IoT Nightmare After All

January 29, 2016 by Elliot Williams 25 Comments

Security researchers can be a grim crowd. Everything, when looked at closely enough, is insecure at some level, and this leads to a lot of pessimism in the industry. So it’s a bit of a shock to see a security report that’s filled with neither doom nor gloom.

We’d previously covered Somerset Recon’s initial teardown of “Hello Barbie” and were waiting with bated breath for the firmware dump and some real reverse engineering. Well, it happened and basically everything looks alright (PDF report). The Somerset folks desoldered the chip, dumped the flash ROM, and when the IDA-dust settled, Mattel used firmware that’s similar to what everyone else uses to run Amazon cloud service agents, but aimed at the “toytalk.com” network instead. In short, it uses a tested and basically sound firmware.

The web services that the creepy talking doll connected to were another story, and were full of holes that were being actively patched throughout Somerset’s investigation, but we were only really interested in the firmware anyway, and that looked OK. Not everything is horror stories in IoT security. Some stories do have a happy ending. Barbie can sleep well tonight.

32C3: Shopshifting — Breaking Credit Card Payment Systems

December 30, 2015 by Elliot Williams 19 Comments

Credit card payment systems touch all of our lives, and because of this there’s a lot riding on the security of that technology. The best security research looks into a widely deployed system and finds the problems before the bad guys do. The most entertaining security presentations end up finding face-palmingly bad practices and having a good laugh along the way. The only way to top that off is with live demos. [Karsten Nohl], [Fabian Bräunlein], and [dexter] gave a talk on the security of credit-card payment systems at the 32nd annual Chaos Communications Congress (32C3) that covers all the bases.

While credit card systems themselves have been quite well-scrutinized, the many vendor payment networks that connect the individual terminals haven’t. The end result of this research is that it is possible to steal credit card PINs and remotely refund credits to different cards — even for purchases that have never been made. Of course, the researchers demonstrate stealing money from themselves, but the proof of concept is solid. How they broke two separate payment systems is part hardware hacking, part looking-stuff-up-on-the-Internet, and part just being plain inquisitive.

Continue reading “32C3: Shopshifting — Breaking Credit Card Payment Systems” →

32C3: Towards Trustworthy X86 Laptops

December 28, 2015 by Brian Benchoff 38 Comments

Security assumes there is something we can trust; a computer encrypting something is assumed to be trustworthy, and the computer doing the decrypting is assumed to be trustworthy. This is the only logical mindset for anyone concerned about security – you don’t have to worry about all the routers handling your data on the Internet, eavesdroppers, or really anything else. Security breaks down when you can’t trust the computer doing the encryption. Such is the case today. We can’t trust our computers.

In a talk at this year’s Chaos Computer Congress, [Joanna Rutkowska] covered the last few decades of security on computers – Tor, OpenVPN, SSH, and the like. These are, by definition, meaningless if you cannot trust the operating system. Over the last few years, [Joanna] has been working on a solution to this in the Qubes OS pro ject, but everything is built on silicon, and if you can’t trust the hardware, you can’t trust anything.

And so we come to an oft-forgotten aspect of computer security: the BIOS, UEFI, Intel’s Management Engine, VT-d, Boot Guard, and the mess of overly complex firmware found in a modern x86 system. This is what starts the chain of trust for the entire computer, and if a computer’s firmware is compromised it is safe to assume the entire computer is compromised. Firmware is also devilishly hard to secure: attacks against write protecting a tiny Flash chip have been demonstrated. A Trusted Platform Module could compare the contents of a firmware, and unlock it if it is found to be secure. This has also been shown to be vulnerable to attack. Another method of securing a computer’s firmware is the Core Root of Trust for Measurement, which compares firmware to an immutable ROM-like memory. The specification for the CRTM doesn’t say where this memory is, though, and until recently it has been implemented in a tiny Flash chip soldered to the motherboard. We’re right back to where we started, then, with an attacker simply changing out the CRTM chip along with the chip containing the firmware.

But Intel has an answer to everything, and to the house of cards for firmware security, Intel introduced their Management Engine. This is a small microcontroller running on every Intel CPU all the time that has access to RAM, WiFi, and everything else in a computer. It is security through obscurity, though. Although the ME can elevate privileges of components in the computer, nobody knows how it works. No one has the source code for the operating system running on the Intel ME, and the ME is an ideal target for a rootkit.

Is there hope for a truly secure laptop? According to [Joanna], there is hope in simply not trusting the BIOS and other firmware. Trust therefore comes from a ‘trusted stick’ – a small memory stick that contains a Flash chip that verifies the firmware of a computer independently of the hardware in a computer.

This, with open source firmwares like coreboot are the beginnings of a computer that can be trusted. While the technology for a device like this could exist, it will be a while until something like this will be found in the wild. There’s still a lot of work to do, but at least one thing is certain: secure hardware doesn’t exist, but it can be built. Whether secure hardware comes to pass is another thing entirely.

You can watch [Joanna]’s talk on the 32C3 streaming site.

Capture The Flag With Lightsabers

December 15, 2015 by Bryan Cockfield 2 Comments

There’s a great game of capture-the-flag that takes place every year at HITCON. This isn’t your childhood neighborhood’s capture-the-flag in the woods with real flags, though. In this game the flags are on secured servers and it’s the other team’s mission to break into the servers in whatever way they can to capture the flag. This year, though, the creators of the game devised a new scoreboard for keeping track of the game: a lightsaber.

In this particular game, each team has a server that they have to defend. At the same time, each team attempts to gain access to the other’s server. This project uses a lightsaber stand that turns the lightsabers into scoreboards for the competition at the 2015 Hacks In Taiwan Conference. It uses a cheap OpenWRT Linux Wi-Fi/Ethernet development board, LinkIt Smart 7688 which communicates with a server. Whenever a point is scored, the lightsaber illuminates and a sound effect is played. The lightsabers themselves are sourced from a Taiwanese lightsabersmith and are impressive pieces of technology on their own. As a bonus the teams will get to take them home with them.

While we doubt that this is more forced product integration advertisement from Disney, it certainly fits in with the theme of the game. Capture-the-flag contests like this are great ways to learn about cyber security and how to defend your own equipment from real-world attacks. There are other games going on all around the world if you’re looking to get in on the action.

Continue reading “Capture The Flag With Lightsabers” →