[aleaksah] got himself a Mi Smart Kettle Pro, a kettle with Bluetooth connectivity, and a smartphone app to go with it. Despite all the smarts, it couldn’t be turned on remotely. Energized with his vision of an ideal smart home where he can turn the kettle on in the morning right as he wakes up, he set out to right this injustice. (Russian, translated) First, he tore the kettle down, intending to dump the firmware, modify it, and flash it back. Sounds simple enough — where’s the catch?
This kettle is built around the QN9022 controller, from the fairly open QN902X family of chips. QN9022 requires an external SPI flash chip for code, as opposed to its siblings QN9020 and QN9021 which have internal flash akin to ESP8285. You’d think dumping the firmware would just be a matter of reading that flash, but the firmware is encrypted at rest, with a key unique to each MCU and stored internally. As microcontroller reads the flash chip contents, they’re decrypted transparently before being executed. So, some other way had to be found, involving the MCU itself as the only entity with access to the decryption key.
Continue reading “Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle”
In a perfect world, everything would be open source. Our current world, on the other hand, has a lot of malicious actors and people willing to exploit trade secrets if given the opportunity, so chip manufacturers take a lot of measures to protect their customers’ products’ firmware. These methods aren’t perfect, though, as [zapb] shows while taking a deeper look into an STM microcontroller.
The STM32F0 and F1 chips rely on various methods of protecting their firmware. The F0 has its debug interface permanently switched off, but the F1 still allows users access to this interface. It uses flash memory read-out protection instead, which has its own set of vulnerabilities. By generating exceptions and exploiting the intended functions of the chip during those exceptions, memory values can be read out of the processor despite the memory read-out protection.
This is a very detailed breakdown of this specific attack on theses controllers, but it isn’t “perfect”. It requires physical access to the debug interface, plus [zapb] was only able to extract about 94% of the internal memory. That being said, while it would be in STM’s best interests to fix the issue, it’s not the worst attack we’ve ever seen on a piece of hardware.
In the days of carburetors and leaf spring suspensions, odometer fraud was pretty simple to do just by disconnecting the cable or even winding the odometer backwards. With the OBD standard and the prevalence of electronics in cars, promises were made by marketing teams that this risk had all but been eliminated. In reality, however, the manipulation of CAN bus makes odometer fraud just as easy, and [Andras] is here to show us exactly how easy with a teardown of a few cheap CAN bus adapters.
We featured another project that was a hardware teardown of one of these devices, but [Andras] takes this a step further by probing into the code running on the microcontroller. One would imagine that basic measures would have been taken by the attackers to obscure code or at least disable debugging modes, but on this one no such effort was made. [Andras] was able to dump the firmware from both of his test devices and start analyzing them.
Analyzing the codes showed identical firmware running on both devices, which made his job half as hard. It looked like the code was executing a type of man-in-the-middle attack on the CAN bus which allowed it to insert the bogus mileage reading. There’s a lot of interesting information in [Andras]’s writeup though, so if you’re interested in CAN bus or attacks like this, it’s definitely worth a read.
All computers are vulnerable to attacks by viruses or black hats, but there are lots of steps that can be taken to reduce risk. At the extreme end of the spectrum is having an “air-gapped” computer that doesn’t connect to a network at all, but this isn’t a guarantee that it won’t get attacked. Even transferring files to the computer with a USB drive can be risky under certain circumstances, but thanks to some LED lights that [Robert Fisk] has on his drive, this attack vector can at least be monitored.
Using a USB drive with a single LED that illuminates during a read OR write operation is fairly common, but since it’s possible to transfer malware unknowingly via USB drives, one that has a separate LED specifically for writing operations will help alert a user to any write operations that might be trying to fly under the radar. A recent article by [Bruce Schneier] pointed out this flaw in USB drives, and [Robert] was up to the challenge. His build returns more control to the user by showing them when their drive is accessed and in what way, which can also be used to discover unique quirks of one’s chosen operating system.
[Robert] is pretty familiar with USB drives and their ups and downs as well. A few years ago he built a USB firewall that was able to decrease the likelihood of BadUSB-type attacks. Be careful going down the rabbit hole of device security, though, or you will start seeing potential attacks hidden almost everywhere.
Here’s a puzzler for you: If you’re phreaking something that’s not exactly a phone, are you still a phreak?
That question probably never crossed the minds of New Yorkers who were acoustically assaulted on the normally peaceful sidewalks of Manhattan over the summer by creepy sounds emanating from streetside WiFi kiosks. The auditory attacks caused quite a stir locally, leading to wild theories that Russian hackers were behind it all. Luckily, the mystery has been solved, and it turns out to have been part prank, part protest, and part performance art piece.
To understand the exploit, realize that New York City has removed thousands of traditional pay phones from city sidewalks recently and replaced them with LinkNYC kiosks, which are basically WiFi hotspots with giant HDTV displays built into them. For the price of being blitzed with advertisements while strolling by, anyone can make a free phone call using the built-in VOIP app. That was the key that allowed [Mark Thomas], an old-school phreak and die-hard fan of the pay telephones that these platforms supplanted, to launch his attack. It’s not exactly rocket surgery; [Mark] dials one of the dozens of conference call numbers he has set up with pre-recorded audio snippets. A one-minute delay lets him crank the speakerphone volume up to 11 and abscond. The recordings vary, but everyone seemed most creeped out by the familiar jingle of the [Mr. Softee] ice cream truck franchise, slowed down and distorted to make it sound like something from a fever dream.
Yes, it’s a minimal hack, and normally we don’t condone the misuse of public facilities, even ones as obnoxious as LinkNYC appears to be. But it does make a statement about the commercialization of the public square, and honestly, we’re glad to see something that at least approaches phreaking again. It’s a little less childish than blasting porn audio from a Target PA system, and far less dangerous than activating a public safety siren remotely.
Continue reading “Manhattan Mystery Of Creepy Jingles And Random Noises Solved”
Cloudflare announced recently that they are seeing an increase in amplification attacks using memcached servers, and that this exploit has the potential to be a big problem because memcached is capable of amplifying an attack significantly. This takes DDoS attacks to a new level, but the good news is that the problem is confined to a few thousand misconfigured servers, and the solution is to put the servers behind a tighter firewall and to disable UDP. What’s interesting is how the fundamental workings of the Internet are exploited to create and direct a massive amount of traffic.
We start with a botnet. This is when a bunch of Internet-connected devices are compromised and controlled by a malicious user. This could be a set of specific brand of web camera or printer or computer with unsecured firmware. Once the device is compromised, the malicious user can control the botnet and have it execute code. This code could mine cryptocurrency, upload sensitive data, or create a lot of web traffic directed at a particular server, flooding it with requests and creating a distributed denial of service (DDoS) attack that takes down the server. Since the server can’t distinguish regular traffic from malicious traffic, it can’t filter it out and becomes unresponsive.
This DDoS attack is limited to the size of the botnet’s bandwidth, though. If all the web cameras in the botnet are pounding a server as fast as they can, the botnet has reached its max. The next trick is called an amplification attack, and it exploits UDP. UDP (as opposed to TCP) is like the early post office; you send mail and hope it gets there, and if it doesn’t then oh well. There’s no handshaking between communicating computers. When a device sends a UDP packet to a server, it includes the return address so that the server can send the response back. If the device sends a carefully crafted fake request with a different return address, then the server will send the response to that spoofed return address.
So if the web camera sends a request to Server A and the response is sent to Server B, then Server A is unintentionally attacking Server B. If the request is the same size as the response, then there’s no benefit to this attack. If the request is smaller than the response, and Server A sends Server B a bunch of unrequested data for every request from the camera, then you have a successful amplification attack. In the case of memcached, traffic can be amplified by more than 50,000 times, meaning that a small botnet can have a huge effect.
Memcached is a memory caching system whose primary use is to help large websites by caching data that would otherwise be stored in a database or API, so it really shouldn’t be publicly accessible anyway. And the solution is to turn off public-facing memcached over UDP, but the larger solution is to think about what things you are making available to the Internet, and how they can be used maliciously.
Show of hands: how many of you have parked your car in the driveway, walked up to your house, and pressed your car’s key fob button thinking it would open the front door? We’ve probably all done it and felt a little dopey as a result, but when you think about it, it would be tremendously convenient, especially with grocery bags dangling off each arm and the mail clenched between your teeth. After all, we’re living in the future — shouldn’t your house be smart enough to know when you’re home?
Reverse engineer par excellence Samy Kamkar might think so, but given his recent experiences with cars smart enough to know when you’re standing outside them, he’d probably have some reservations. Samy dropped by the 2017 Hackaday Superconference in November to discuss the finer points of exploiting security flaws in passive car entry systems, and also sat down with our own Elliot Williams after his talk for a one-on-one interview. Samy has some interesting insights on vehicle cybersecurity, but the practical knowledge he’s gained while exploring the limits of these systems teach some powerful lessons about being a real-world reverse engineer.
Continue reading “Samy Kamkar: Reverse Engineering For A Secure Future”