Reverse Engineering The Internet Of Coffee

The public promise of the Internet Of Things from years ago when the first journalists discovered the idea and strove to make it comprehensible to the masses was that your kitchen appliances would be internet-connected and somehow this would make our lives better. Fridges would have screens, we were told, and would magically order more bacon when supplies ran low.

A decade or so later some fridges have screens, but the real boom in IoT applications has not been in such consumer-visible applications. Most of your appliances are still just as unencumbered by connectivity as they were twenty years ago, and that Red Dwarf talking toaster that Lives Only To Toast is still fortunately in the realm of fiction.

The market hasn’t been devoid of IoT kitchen appliances though. One is the Smarter Coffee coffee machine, a network-connected coffeemaker that is controlled from an app. [Simone Margaritelli] bought one, though while he loved the coffee he really wasn’t keen on its not having a console application. He thus set about creating one, starting with reverse engineering its protocol by disassembling the Android version of its app.

What he found was sadly not an implementation of RFC 2324, instead it uses a very simple byte string to issue commands with parameters such as coffee strength. There is no security, and he could even trigger a firmware upgrade. The app requires a registration and login, though this appears to only be used for gathering statistics. His coffee application can thus command all the machine’s capabilities from his terminal, and he can enjoy a drink without reaching for an app.

On the face of it you might think that the machine’s lack of security might not matter as it is on a private network behind a firewall. But it represents yet another example of a worrying trend in IoT devices for completely ignoring security. If someone can reach it, the machine is an open book and the possibility for mischief far exceeds merely pranking its owner with a hundred doppio espressos. We have recently seen the first widely publicised DDoS attack using IoT devices, it’s time manufacturers started taking this threat seriously.

If the prospect of coffee hacks interests you, take a look at our previous coverage.

[via /r/homeautomation]

How To Become Part Of An IoT Botnet

We should all be familiar with the so-called Internet Of Things, a proliferation of Internet-connected embedded electronics. The opportunities offered to hardware hackers by these technologies have been immense, but we should also be aware of some of the security issues surrounding them.

Recently, the website of the well-known security researcher [Brian Krebs] suffered a DDoS attack. What made this attack different from previous ones wasn’t its severity, but that it had been directed not from botnets of malware-laced Windows PCs but from compromised IoT devices.

One might ask how it could be possible to take control of such low-end embedded hardware, seeing as it would normally be safely behind a firewall, preloaded with its own firmware, and without a clueless human at its terminal to open malware-laden email attachments. The answer is quite shocking but not entirely surprising, and lies in some astonishingly poor security on the part of the devices themselves. An exposé of one such mechanism comes courtesy of [Brian Butterly], who took an unremarkable IP webcam and documented its security flaws.

The camera he examined exposes two services, a web interface and a Telnet port. While from a security perspective their lack of encryption is a concern this should not pose a significant danger when the device is safely on a private network and behind a suitable firewall. The problem comes from its ability to send its pictures over the Internet, for the owner to be able to check their camera from their phone some kind of outside access is required. Expensive cameras use a cloud-based web service for this task, but the cheap ones like the camera being examined simply open a port to the outside world.

If you are familiar with basic firewall set-up, you’ll be used to the idea that open ports are something that should be under control of the firewall owner; if a port has not been specifically opened then it should remain closed. How then can the camera open a port? The answer lies with UPnP, a protocol enabled by default on most home routers that allows a device to request an open port. In simple terms, the camera has an inherently insecure service which it asks the router to expose to the world, and in many cases the router meekly complies without its owner being any the wiser. We suspect that many of you who have not done so already will now be taking a look at your home router to curtail its UPnP activities.

We covered the [Brian Krebs] DDoS story  as it unfolded last week, but we’re sure this is likely to be only the first of many stories in this vein. As manufacturers of appliances struggle to learn that they are no longer in the dumb appliance business they need to start taking their software security very seriously indeed.

Webcam image: Asim18 (Own work) [CC BY-SA 3.0], via Wikimedia Commons.

Web Bluetooth: The New Hotness and Its Dangers

Google’s most recent Chrome browser, version 53, includes trial support for Web Bluetooth, and it’s like the Wild West! JavaScript code, served to your browser, can now connect directly to your Bluetooth LE (BTLE) devices, with a whole bunch of caveats that we’ll make clear below.

On the one hand, this is awesome functionality. The browser is the most ubiquitous cross-platform operating system that the world has ever seen. You can serve a website to users running Windows, Linux, Android, iOS, or MacOS and run code on their machines without having to know if it’s a cellphone, a desktop, or a virtual machine in the Matrix. Combining this ubiquity with the ability to control Bluetooth devices is going to be fun. It’s a missing piece of the IoT puzzle.

On the other hand, it’s a security nightmare. It’s bad enough when malicious websites can extract information from files that reside on your computer, but when they connect directly to your lightbulbs, your FitBits, or your BTLE-enhanced pacemaker, it opens up new possibilities for mischief. The good news is that the developers of Web Bluetooth seem to be aware of the risks and are intent on minimizing them, but there are still real concerns. How does security come out in the balance? Read on.

Continue reading “Web Bluetooth: The New Hotness and Its Dangers”

Desuiciding Capcom Arcade Boards

Capcom’s CPS2 – or CP System II – was the early to mid-90s arcade hardware famous for Super Street Fighter II, Alien vs. Predator, and a few of the Marvel and Capcom crossover arcade games. As you would expect, these boards have become collectors items. Unfortunately for future generations, Capcom took some short-sighted security measures to prevent copying the games, and the boards have been failing over the last two decades.

After months of work, [ArcadeHacker] and several other arcade enthusiasts have reverse engineered the security protocol and devised a method of de-suiciding these arcade boards, allowing for the preservation of this hardware and these games. The code that does the trick is up on GitHub.

Last year, [ArcadeHacker] reverse engineered the on-chip security for Capcom’s Kabuki processor, the CPU used in some of Capcom’s earlier arcade boards. It used a similar protection scheme. In the Kabuki hardware, the on-chip ROM was interspersed with a few XOR gates on the processor’s bus. With a security key kept in battery-backed memory, this was enough to keep the code for the game secret, albeit at the cost of preventing historical preservation.

Over the next few weeks, [ArcadeHacker] will post more detailed information about the copy protection scheme of the CPS2 board, but the proof-of-concept works right now. It’s now possible to revive a CPS2 board that has killed itself due to a dead battery, and the hardware is as simple as an Arduino and a few test clips. You can check out a video of the exploit in action below.

Continue reading “Desuiciding Capcom Arcade Boards”

Asking the Security Question of Home Automation

“Security” is the proverbial dead horse we all like to beat when it comes to technology. This is of course not unjust — we live in a technological society built with a mindset of “security last”. There’s always one reason or another proffered for this: companies need to fail fast and will handle security once a product proves viable, end users will have a harder time with setup and use if systems are secured or encrypted, and governments/law enforcement don’t want criminals hiding behind strongly secured systems.

This is an argument I don’t want to get bogged down in. For this discussion let’s all agree on this starting point for the conversation: any system that manages something of value needs some type of security and the question becomes how much security makes sense? As the title suggests, the technology du jour is home automation. When you do manage to connect your thermostat to your door locks, lights, window shades, refrigerator, and toilet, what type of security needs to be part of the plan?

Join me after the break for an overview of a few Home Automation security concerns. This article is the third in our series — the first asked What is Home Automation and the second discussed the Software Hangups we face.

These have all been inspired by the Automation challenge round of the Hackaday Prize. Document your own Automation project by Monday morning to enter. Twenty projects will win $1000 each, becoming finalists with a chance at the grand prize of $150,000. We’re also giving away Hackaday T-shirts to people who leave comments that help carry this discussion forward, so let us know what you think below.

Continue reading “Asking the Security Question of Home Automation”

Universal Serial Abuse

It’s probable that most Hackaday readers are aware of their own computer security even if they are not specialists. You’ll have some idea of which ports your machines expose to the world, what services they run, and you’ll know of a heap of possible attack vectors even if you may not know about every last one.

So as part of that awareness, it’s likely you’ll be wary of strange USB devices. If someone drops a Flash drive in the parking lot the chances of one of you blithely plugging it into your laptop is not high at all. USB ports are trusted by your computer and its operating system, and to have access to one is to be given the keys to the kingdom.

Our subject today is a DEF CON talk courtesy of [Dominic White] and [Rogan Dawes] entitled “Universal Serial aBUSe“, and it details a USB attack in which they create an innocuous USB stick that emulates a keyboard and mouse which is shared across a WiFi network via a VNC server. This gives an attacker (who can gain momentary physical access to a USB port to install the device) a way into the machine that completely bypasses all network and other security measures.

Their hardware features an AVR and an ESP8266, the former for USB and HID work and the latter to do the heavy lifting and provide WiFi. They started with a Cactus Micro Rev2, but graduated to their own compatible board to make the device more suitable to pose as a USB stick. Both hardware and software files can be found on their GitHub repository, with the software being a fork of esp-link. They go into significant detail of their development and debugging process, and their write-up should be an interesting read for anyone.

Below the break you can find a video description of the attack. It’s not a shock to know that USB ports have such little defense, but it is a sobering moment to realize how far attacks like this one have come into the realm of what is possible.

Continue reading “Universal Serial Abuse”

The First Evil Maid-Proof Computer

It doesn’t matter how many bits your password has, how proven your encryption is, or how many TrueCrypt volumes are on your computer. If someone wants data off your device, they can get it if they have physical access to your device. This is the ‘evil maid’ security scenario, named after hotel maids on the payroll of a three-letter agency. If someone has physical access to a laptop – even for an hour or two – the data on that laptop can be considered compromised. Until now, there has been no counter to this Evil Maid scenario, and for good reason. Preventing access to data even when it is in the possession of an Evil Maid is a very, very hard problem.

Today, Design Shift has released ORWL (as in George Orwell), the first computer designed with physical security in mind. This tiny disc of a computer is designed to defeat an Evil Maid through some very clever engineering on top of encryption tools we already use.
Continue reading “The First Evil Maid-Proof Computer”