UPnP — in a perfect world it would have been the answer to many connectivity headaches as we add more devices to our home networks. But in practice it the cause of a lot of headaches when it comes to keeping those networks secure.
It’s likely that many Hackaday readers provide some form of technical support to relatives or friends. We’ll help sort out Mom’s desktop and email gripes, and we’ll set up her new router and lock it down as best we can to minimise the chance of the bad guys causing her problems. Probably one of the first things we’ll have all done is something that’s old news in our community; to ensure that a notorious vulnerability exposed to the outside world is plugged, we disable UPnP on whatever cable modem or ADSL router her provider supplied.
An old laptop or desktop computer that’s seen better days might still have a little bit of use left in it for a dedicated task. Grabbing a lightweight flavor of Linux and running a web server, firewall, or Super Nintendo emulator might get a few more years out of it. You can also get pretty creative repurposing obsolete single purpose machines, as [Kristjan] did with some old Cisco server equipment.
The computer in question isn’t something commonly found, either. It’s an intrusion detection system meant to mount in a server rack and protect the server itself from malicious activity. While [Kristjan] mentions that Cisco equipment seems to be the definition of planned obsolescence, we think that this Intel Celeron machine with an IDE hard drive may have gone around the bend quite some time ago. Regardless, it’s modern enough to put back to work in some other capacity.
To that end, a general purpose operating system was installed, and rather than use Linux he reached for BSD to get the system up and running. There’s one other catch, though, besides some cooling issues. Since the machine was meant to be used in a server, there’s no ACPI which means no software shutdown capability. Despite all the quirks, you can still use it to re-implement a network security system if you wanted to bring it full-circle.
There are two elements of this story that I found particularly baffling. First, this botnet infects routers using a vulnerability that was first reported by Defensecode over five years ago, in 2013! The second oddity is the wide range of devices that are vulnerable and are now part of the botnet. Dozens of brands and at least 116 models have been found to be infected.
One of the details of this story hasn’t been reported entirely accurately. The bug is not built into the Broadcom chipset. Unlike Spectre and Meltdown, it’s not actually a hardware fault. Broadcom distributes a Software Development Kit (SDK) that enables device manufacturers like D-Link, TP-Link, and Linksys to quickly develop firmware for routers using Broadcom chips. The vulnerability lies in this code, rather than part of the hardware itself.
There have been many news stories lately about companies misusing your data, including your e-mails. What’s more, these giant repositories of data are favorite targets for hackers. Even if you trust the big corporations, you are also betting on their security. Criptext claims they have (possibly) the most private e-mail service ever. It uses the open Signal protocol and stores private keys and encrypted mail only on your device. All the applications to access your mail are open source, so presumably, someone would eventually spot any backdoors or open holes.
At the moment the service is free and the company reports that even when a paid offering is ready, there will still be a free tier. Of course, you can send and receive normal e-mail, too. You can also use a passphrase you send to someone else (presumably not by e-mail) so they can read an encrypted message.
You’ve no doubt heard about the “hardware implants” which were supposedly found on some server motherboards, which has led to all sorts of hand-wringing online. There’s no end of debate about the capabilities of such devices, how large they would need to be, and quite frankly, if they even exist to begin with. We’re through the looking-glass now, and there’s understandably a mad rush to learn as much as possible about the threat these types of devices represent.
EEPROM (left) can be edited to enable SMBus access on this card (header to the right)
[Nicolas Oberli] of Kudelski Security wanted to do more than idly speculate, so he decided to come up with a model of how an implanted hardware espionage device could interact with the host system. He was able to do this with off the shelf hardware, meaning anyone who’s so inclined can recreate this “Hardware Implant Playset” in their own home lab for experimentation. Obviously this is not meant to portray a practical attack in terms of the hardware itself, but gives some valuable insight into how such a device might function.
One of the most obvious attack vectors for hardware implants is what’s known as the Baseboard Management Controller (BMC). This is a chip used on modern motherboards to allow for remote control and monitoring of the system’s hardware, and promises to be a ripe target for attackers. There are a few sideband channels which can be used by the BMC chip to talk to other chips. To keep things simple [Nicolas] focused on the older I2C-derived SMBus (rather than the newer and more complex NC-SI), demonstrating what can be done once you have control of that bus.
Only problem was, he didn’t have a motherboard with a BMC to experiment with. After a little research, the answer came in the form of the Intel EXPI9301CTBLK network card, which features the 82574L SMBus chip. This allows for experimenting with a subset of SMBus functionality on any machine with a PCI-E slot. Even better, the card has an SMBus header on the top to plug into. [Nicolas] describes in detail how he enabled the SMBus interface by modifying the card’s EEPROM, which then allowed him to detect it with his HydraBus.
With the hardware setup, the rest of the write-up focuses on what you can do with direct control of SMBus on the network card. [Nicolas] demonstrates not only creating and sending Ethernet packets, but also intercepting an incoming packet. In both cases, a running instance of tcpdump on the host computer fails to see the packets even exist.
He goes on to explain that since SMBus is very similar to I2C and only requires four wires, the techniques shown could easily be moved from the Hydrabus dev board used in the demo, to a small microcontroller like the ATtiny85. But you would still need to find a way to add that microcontroller directly onto the network card without it being obvious to the casual observer.
Every day, we’re connecting more and more devices over the internet. No longer does a household have a single connected computer — there are smartphones, tablets, HVAC systems, deadbolts — you name it, it’s been connected. As the Internet of Things proliferates, it has become readily apparent that security is an issue in this space. [Andreas Spiess] has been working on this very problem, by bringing HTTPS to the ESP8266 and ESP32.
Being the most popular platform for IOT devices, it makes sense to start with the ESP devices when improving security. In his video, [Andreas] starts at the beginning, covering the basics of SSL, before branching out into how to use these embedded systems with secure cloud services, and the memory requirements to do so. [Andreas] has made the code available on GitHub so it can be readily included in your own projects.
Obviously implementing increased security isn’t free; there’s a cost in terms of processing power, memory, and code complexity. However, such steps are crucial if IOT devices are to become trusted in wider society. A malfunctioning tweeting coffee pot is one thing, but being locked out of your house is another one entirely.
Vending machines used to be a pretty simple affair: you put some coins in, and food or drink that in all likelihood isn’t fit for human consumption comes out. But like everything else today, they are becoming increasingly complex Internet connected devices. Forget fishing around for pocket change; the Coke machine at the mall more often than not has a credit card terminal and a 30 inch touch screen display to better facilitate dispensing cans of chilled sugar water. Of course, increased complexity almost always goes hand in hand with increased vulnerability.
So when [Matteo Pisani] recently came across a vending machine that offered users the ability to pay from an application on their phone, he immediately got to wondering if the system could be compromised. After all, how much thought would be put into the security of a machine that basically sells flavored water? The answer, perhaps not surprisingly, is very little.
The write-up [Matteo] has put together is an outstanding case study in hacking Android applications, from pulling the .apk package off the phone to decompiling it into its principal components with programs like apktool and jadx. He even shows how you can reassemble the package and get it suitable for reinstallation on your device after fiddling around with the source code. If you’ve ever wanted a crash course on taking a peek inside of Android programs, this is a great resource.
By snooping around in the source code, [Matteo] was able to discover not only the location of the encrypted database that serves as the “wallet” for the user, but the routine that generates the encryption key. To cut a long story short, the program simply uses the phone’s IMEI as the key to get into the database. With that in hand, he was able to get into the wallet and give himself a nice stack of “coins” for the next time he hit the vending machines. Given his new-found knowledge of how the system works, he even came up with a separate Android app that allows adding credit to the user’s account on a rooted device.
In the video after the break, [Matteo] demonstrates his program by buying a soda and then bumping his credit back up to buy another. He ends his write-up by saying that he has reported his findings to the company that manufacturers the vending machines, but no word on what (if any) changes they plan on making. At the end of the day, you have to wonder what the cost-befit analysis looks like for a full security overhaul when when you’re only selling sodas and bags of chips.
