Any reader who has bought a TV in recent years will know that it’s now almost impossible to buy one that’s just a TV. Instead they are all “smart” TVs, with an on-board computer running a custom OS with a pile of streaming apps installed. It fits an age in which linear broadcast TV is looking increasingly archaic, but it brings with it a host of new challenges.
The root of the problem appears to be the TV running continuous network discovery attempts using random UUIDs, which when happening every few minutes for a year or more, overloads the key caches on other networked machines. The PC which brought the problem to light was a Windows machine, which leaves us sincerely hoping that our Linux boxen might be immune.
It’s fair to place this story more under the heading of bugs than of malicious intent, but even so it’s something that should never have made it to production. The linked story advises nobody to buy a HiSense TV, but to that we’d have to doubt that other manufactures wouldn’t be similarly affected.
At this point, you’re likely aware that you can store your wireless network’s credentials in a QR code, so that anyone who wants to connect with their smartphone need only scan the 2D barcode. Whether you print it out on paper, extrude it out of plastic, or paint the thing on the wall, it still works the same. It’s a neat trick for when you’ve got friends and family over, and saves you having to explain your ponderously long WPA key.
But what if you want to change up the encryption key every so often? Sure would be a hassle to have to repaint the wall. Enter this interesting project from [Predrag Mijatovic], which uses a few scripts to automatically set up a new encrypted guest WiFi network and present the appropriate QR code on an OLED display attached to a Raspberry Pi Pico. It’s a bit convoluted, and almost certainly won’t work on your network without significant tweaks, but we’re intrigued by the idea.
As [Predrag] explains, the whole thing is based on a Latvian MikroTik router that can be configured over SSH. A Bash script generates a new encryption key by base64 encoding the output /dev/urandom, logs into the router to set up a new network using it, and then generates the matching ASCII QR code. With some sed trickery, the code is then embedded into a MicroPython program that gets uploaded to the connected Pi Pico.
In the video after the break [Predrag] takes us through the process manually so it’s easier to see what’s going on. Under normal circumstances, it would all happen automatically and would take just a few seconds to complete. We’d feel more comfortable if the scripts had some error correction that would allow them to gracefully exit if something goes wrong, but as a proof of concept, it certainly works.
Among security professionals, a “drop box” is a device that can be covertly installed at a target location and phone home over the Internet, providing a back door into what might be an otherwise secure network. We’ve seen both commercial and DIY versions of this concept, and as you might expect, one of the main goals is to make the device look as inconspicuous as possible. Which is why [Walker] is hoping to build one into a standard USB wall charger.
This project is still in the early stages, but we like what we see so far. [Walker] aims to make this a 100% free and open source device, starting from the tools he’s using to produce the CAD files all the way up to the firmware the final hardware will run. With none of the currently available single-board computers (SBCs) meeting his list of requirements, the first step is to build a miniature Linux machine that’s got enough processing power to run useful security tools locally. Obviously such a board would be of great interest to the larger hacker and maker community.
The RTL8188CUS is likely to get integrated later on.
So far, [Walker] has decided on his primary components and is working on a larger development board before really going all-in on the miniaturization process. As of right now he’s planning on using the Allwinner A33 to power the board, a sub-$10 USD chipset most commonly seen in low-cost Android tablets.
The A33 boasts a quad-core Cortex-A7 clocked at 1.2 GHz, and offers USB, I2C, and SPI interfaces for expansion. It will be paired with 1 GB of DDR3 RAM, and an SD card to hold the operating system. Naturally a device like this will need WiFi, but until [Walker] can decide on which chip to use, the plan is to just use a USB wireless adapter. The Realtek RTL8188CUS is a strong contender, as the fact that it comes in both USB and module versions should make its eventual integration seamless.
Leading edge computer security is veiled in secrecy — a world where novel attacks are sprung on those who do not yet know what they need to protect against. Once certain tactics have played out within cool kids’ circles, they are introduced to the rest of the world. An IBM red team presented what they’re calling “warshipping”: sending an adversarial network to you in a box.
Companies concerned about security have learned to protect their internet-accessible points of entry. Patrolling guards know to look for potential wardrivers parked near or repeatedly circling the grounds. But some are comparatively lax about their shipping & receiving, and they are the ideal targets for warshipping.
Bypassing internet firewalls and security perimeters, attack hardware is embedded inside a shipping box and delivered by any of the common carriers. Security guards may hassle a van bristling with antennas, but they’ll wave a FedEx truck right through! The hardware can be programmed to stay dormant through screening, waiting to probe once inside the walls.
The presentation described several ways to implement such an attack. There is nothing novel about the raw hardware – Raspberry Pi, GPS receiver, cellular modems, and such are standard fare for various projects on these pages. The creative part is the software and in how they are hidden: in packing material and in innocuous looking plush toys. Or for persistence, they can be hidden in a wall mounted plaque alongside some discreet photovoltaic panels. (Editor’s note: What? No Great Seals?)
With this particular technique out in the open, we’re sure others are already in use and will be disclosed some years down the line. In the meantime, we can focus our efforts on more benign applications of similar technology, whether it is spying on our cat or finding the nearest fast food joint. The hardware is evolving as well: a Raspberry Pi actually seems rather heavyweight for this, how about a compact PCB with both an ESP32 and a cellular modem?
It’s a fairly safe bet that a Venn diagram of Hackaday readers and those who closely follow the careers of YouTube megastars doesn’t have a whole lot of overlap, so you’re perhaps blissfully unaware of the man who calls himself [PewDiePie]. As such, you might not know that a battle between himself and another YouTube channel which uploads Bollywood music videos has reached such a fever pitch that his fans have resorted to guerrilla hacking to try to sway public opinion towards their side. It’s perhaps not the dystopian future we imagined, but it just might be the one we deserve.
To briefly summarize the situation, a hacker known only by the handle [TheHackerGiraffe] decided to help out Dear Leader by launching an automated attack against 50,000 Internet connected printers. When the hack was successful, the printer would spit out a page of digital propaganda, complete with fist ASCII art, that urged the recipient to go on YouTube and pledge their support for [PewDiePie]. There’s some debate about how many of the printers [TheHackerGiraffe] targeted actually delivered their payload, but judging by reactions throughout social media, it was enough to get the message out.
While the stunt itself may have come as a surprise, the methodology wasn’t. In fact, the only surprising element to the security researchers who’ve weighed in on the situation is that this hasn’t happened more often. It certainly isn’t the first time somebody’s done it, but the fact that this time its been connected to such a high profile Internet celebrity is putting more eyes on the problem then there have been in the past. Now that the proverbial cat is out of the bag, there are even websites springing up which claim to be purveyors of “Printer Advertising”. Odds are good this won’t be the last time somebody’s printer starts running off more than TPS reports.
We here at Hackaday don’t have much interest in the battle for YouTube supremacy. We’re just pulling for Dave Jones’s EEVBlog channel to join [AvE] in breaking a million subscribers. But we’re very interested in the technology which made this attack possible, how likely it is we’re going to see more people exploit it, and what are we supposed to do now that even our own printers can be turned against us?
If you’ve followed along with our series so far, you know we’ve set up a network of Raspberry Pis that PXE boot off a central server, and then used Zoneminder to run a network of IP cameras. Now that some useful services are running in our smart house, how do we access those services when away from home, and how do we keep the rest of the world from spying on our cameras?
Before we get to VPNs and port forwarding, there is a more fundamental issue: Do you trust your devices? What exactly is the firmware on those cheap cameras really doing? You could use Wireshark and a smart switch with port mirroring to audit the camera’s traffic. How much traffic would you need to inspect to feel confident the camera never sends your data off somewhere else?
Thankfully, there’s a better way. One of the major features of surveillance software like Zoneminder is that it aggregates the feeds from the cameras. This process also has the effect of proxying the video feeds: We don’t connect directly to the cameras in order to view them, we connect to the surveillance software. If you don’t completely trust those cameras, then don’t give them internet access. You can make the cameras a physically separate network, only connected to the surveillance machine, or just set their IP addresses manually, and don’t fill in the default route or DNS. Whichever way you set it up, the goal is the same: let your surveillance software talk to the cameras, but don’t let the cameras talk to the outside world.
Edit: As has been pointed out in the comments, leaving off a default route is significantly less effective than separate networks. A truly malicious peice of hardware could easily probe for the gateway.
This idea applies to more than cameras. Any device that doesn’t need internet access to function, can be isolated in this way. While this could be considered paranoia, I consider it simple good practice. Join me after the break to discuss port forwarding vs. VPNs.
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.
