Starlite: Super Material That Protects Hands from Pesky Blowtorches

A super-material that’s non-toxic, highly flame resistant, and a good enough insulator, you can literally hold fire in your hand? Our interest was definitely caught by [NightHawkInLight] and his recent video about Starlite, embedded below the break.

Starlite was the brainchild of English hairdresser, [Maurice Ward]. The famous demo was an egg, coated in Starlite, and blasted with a blowtorch for a full 5 minutes. After heating, he cracked the egg to show it still raw. The inventor died in 2011, and apparently the recipe for Starlite died with him.

[NightHawkInLight] realized he had already made something very similar, the Pharoah’s Serpent demonstration, also known as a black snake. In both examples, a carbon foam is produced, providing flame resistance and insulation. A bit of trial and error later, and he’s out doing the original Starlight demo, pointing the blow torch at his hand instead of an egg.

Continue reading “Starlite: Super Material That Protects Hands from Pesky Blowtorches”

Five Year Old Bug Spawns Router Botnet Monster

In the news has been yet another router botnet. [Hui Wang] and [RootKiter] of 360Netlab announced their discovery of what they call the “BCMUPnP_Hunter” rootkit. They estimate this botnet to be running on over 100,000 routers worldwide.

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.

Continue reading “Five Year Old Bug Spawns Router Botnet Monster”

Hack My House: Opening Raspberry Pi to the Internet, but Not the Whole World

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.

Continue reading “Hack My House: Opening Raspberry Pi to the Internet, but Not the Whole World”

Hello, And Please Don’t Hang Up: The Scourge of Robocalls

Over the last few months, I’ve noticed extra calls coming in from local numbers, and if you live in the US, I suspect maybe you have too. These calls are either just dead air, or recordings that start with “Please don’t hang up.” Out of curiosity, I’ve called back on the number the call claims to be from. Each time, the message is that this number has been disconnected and is no longer in service. This sounds like the plot of a budget horror movie, how am I being called from a disconnected number? Rather than a phantom in the wires, this is robocalling, combined with caller ID spoofing.

Continue reading “Hello, And Please Don’t Hang Up: The Scourge of Robocalls”

Raspberry Pi PoE Redux

[Martin Rowan] was lucky enough to get his hands on the revised Power Over Ethernet (PoE) hat for the Raspberry Pi. Lucky for us, he wrote it up for our benefit, including inspection of the new hat, it’s circuit, and electrical testing to compare to the original hardware.

You may remember the original release of the PoE hat for the Raspberry Pi, as well as the subsequent recall due to over-current issues. In testing the revised board, [Martin] powered a test load off the USB ports, and pulled over an amp — The first iteration of the PoE hat would often trip the over-current protection at 300 milliamps.

This afternoon, the redesigned PoE board was officially released, and the post mortem of the problem documented in a blog post. It’s a lesson in the hidden complexity of hardware design, as well as a cautionary tale about the importance of thorough testing, even when the product is late and the pressure is on.

The PoE hat converts 48 volt power down to a 5 volt supply for the Pi using a flyback transformer. The problem was that this transformer setup doesn’t deliver clean steady 5 volt power, but instead provides power as a series of spikes. While these spikes were theoretically in spec for powering the Pi and usb devices, some Raspberry Pis were detecting those spikes as too much current pushed through the USB ports. The official solution essentially consists of better power filtering between the hat and the Pi, flattening that power draw.

We’re looking forward to getting our hands on this new and improved PoE Hat, and using it in many project to come.

Bill’s 100 Year-Old Smart Home

[Bill]  purchased a house in Central Florida, and like any good hacker, he started renovating, pulling Ethernet cables, and automating things. Lucky for us, he decided to write up his experiences and lessons learned. He found a few problems along the way, like old renovations that compromised the structure of the pool house. After getting the structural problems sorted, he started installing Insteon smart switches. If automated lighting is of interest, and you don’t want to wire up relays yourself, Insteon might be the way to go.

He linked the buildings together with a wireless bridge, and then worked out how to automatically reset the PoE switch when the wireless bridge hangs, automating that recovery process. For your viewing pleasure, he even has one of the security cameras streaming 24/7 online.

His blog looks like a good resource to keep an eye on, and we wouldn’t be surprised to have more of his work show up here on Hackaday. For more home automation goodness, check out some of our previous articles on the subject.

Apple Kernel Code Vulnerability Affected All Devices

Another day, another vulnerability. Discovered by [Kevin Backhouse], CVE-2018-4407 is a particularly serious problem because it is present all throughout Apple’s product line, from the Macbook to the Apple Watch. The flaw is in the XNU kernel shared by all of these products.

This is a buffer overflow issue in the error handling for network packets. The kernel is expecting a fixed length of those packets but doesn’t check to prevent writing past the end of the buffer. The fact Apple’s XNU kernel powers all their products is remarkable, but issues like this are a reminder of the potential downside to that approach. Thanks to responsible disclosure, a patch was pushed out in September.

Anatomy of a Buffer Overflow

Buffer overflows aren’t new, but a reminder on what exactly is going on might be in order. In low level languages like C, the software designer is responsible for managing computer memory manually. They allocate memory, tagging a certain number of bytes for a given use. A buffer overflow is when the program writes more bytes into the memory location than are allocated, writing past the intended limit into parts of memory that are likely being used for a different purpose. In short, this overflow is written into memory that can contain other data or even executable code.

With a buffer overflow vulnerability, an attacker can write whatever code they wish to that out-of-bounds memory space, then manipulate the program to jump into that newly written code. This is referred to as arbitrary code execution. [Computerphile] has a great walk-through on buffer overflows and how they lead to code execution.

This Overflow Vulnerabilty Strikes Apple’s XNU Kernel

[Kevin] took the time to explain the issue he found in further depth. The vulnerability stems from the kernel code making an assumption about incoming packets. ICMP error messages are sent automatically in response to various network events. We’re probably most familiar with the “connection refused’ message, indicating a port closed by the firewall. These ICMP packets include the IP header of the packet that triggered the error. The XNU implementation of this process makes the assumption that the incoming packet will always have a header of the correct length, and copies that header into a buffer without first checking the length. A specially crafted packet can have a longer header, and this is the data that overflows the buffer.

Because of the role ICMP plays in communicating network status, a closed firewall isn’t enough to mitigate the attack. Even when sent to a closed port, the vulnerability can still trigger. Aside from updating to a patched OS release, the only mitigation is to run the macOS firewall in what it calls “stealth mode”. This mode doesn’t respond to pings, and more importantly, silently drops packets rather than sending ICMP error responses. This mitigation isn’t possible for watchOS and iOS devices.

The good news about the vulnerability is that a packet, malformed in this way, has little chance of being passed through a router at all. An attacker must be on the same physical network in order to send the malicious packet. The most likely attack vector, then, is the public WiFi at the local coffee shop.

Come back after the break for a demonstration of this attack in action.

Continue reading “Apple Kernel Code Vulnerability Affected All Devices”