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”
What’s an ADSR envelope generator? If you are a big music hacker, you probably know. If you are like the rest of us, you might need to read [Mich’s] post to find out that it is an attack-decay-sustain-release (ADSR) envelope generator. Still confused? It is a circuit used in music synthesis. You can see a demo of the device in the video below.
Before the Altair–which was sort of the first hobbyist computer you could actually buy–electronics magazines were full of music synthesizer projects that had a lot in common with the analog computers of old. A lot of people took that very seriously and then computers took over the collective consciousness and we found musical hackers started working with (digital) computer-based synthesizers. But the old analog synth designs just won’t die. [Mich’s] ADSR is based on an ancient design, and the amount of information and additions he provides makes it worth a read, even if you don’t fancy building one.
Continue reading “The Sound of (Synthesized) Music”
We will all be used to malicious software, computers and operating systems compromised by viruses, worms, or Trojans. It has become a fact of life, and a whole industry of virus checking software exists to help users defend against it.
Underlying our concerns about malicious software is an assumption that the hardware is inviolate, the computer itself can not be inherently compromised. It’s a false one though, as it is perfectly possible for a processor or other integrated circuit to have a malicious function included in its fabrication. You might think that such functions would not be included by a reputable chip manufacturer, and you’d be right. Unfortunately though because the high cost of chip fabrication means that the semiconductor industry is a web of third-party fabrication houses, there are many opportunities during which extra components can be inserted before the chips are manufactured. University of Michigan researchers have produced a paper on the subject (PDF) detailing a particularly clever attack on a processor that minimizes the number of components required through clever use of a FET gate in a capacitive charge pump.
On-chip backdoors have to be physically stealthy, difficult to trigger accidentally, and easy to trigger by those in the know. Their designers will find a line that changes logic state rarely, and enact a counter on it such that when they trigger it to change state a certain number of times that would never happen accidentally, the exploit is triggered. In the past these counters have been traditional logic circuitry, an effective approach but one that leaves a significant footprint of extra components on the chip for which space must be found, and which can become obvious when the chip is inspected through a microscope.
The University of Michigan backdoor is not a counter but an analog charge pump. Every time its input is toggled, a small amount of charge is stored on the capacitor formed by the gate of a transistor, and eventually its voltage reaches a logic level such that an attack circuit can be triggered. They attached it to the divide-by-zero flag line of an OR1200 open-source processor, from which they could easily trigger it by repeatedly dividing by zero. The beauty of this circuit is both that it uses very few components so can hide more easily, and that the charge leaks away with time so it can not persist in a state likely to be accidentally triggered.
The best hardware hacks are those that are simple, novel, and push a device into doing something it would not otherwise have done. This one has all that, for which we take our hats off to the Michigan team.
If this subject interests you, you might like to take a look at a previous Hackaday Prize finalist: ChipWhisperer.
[Thanks to our colleague Jack via Wired]
Recently ZDNet and Gizmodo published articles outlining a critical flaw in a large array of personal printers. While the number of printers with this flaw is staggering, the ramifications are even more impressive. Ultimately, any of these printers could have documents sent to them stolen even if the document was only intended to be printed as a hard copy.
Luckily the people responsible for this discovery are white-hat in nature, and the release of this information has been made public so the responsible parties can fix the security flaws. Whether or not the “responsible party” is the manufacturer of the printer, though, is still somewhat unclear because part of the exploit takes advantage of a standard that is part of almost all consumer-grade printers. The standard itself may need to be patched.
Right now, however, it doesn’t seem clear exactly how deep the rabbit hole goes. We all remember the DDoS attack that was caused by Internet of Things devices that were poorly secured, and it seems feasible that networked printers could take some part in a similar botnet if a dedicated user really needed them. At the very least, however, your printed documents might not be secure at all, and you may be seeing a patch for your printer’s firmware in the near future.
After a tough summer of botnet attacks by Internet-of-Things things came to a head last week and took down many popular websites for folks in the eastern US, more attention has finally been paid to what to do about this mess. We’ve wracked our brains, and the best we can come up with is that it’s the manufacturers’ responsibility to secure their devices.
Chinese DVR manufacturer Xiongmai, predictably, thinks that the end-user is to blame, but is also consenting to a recall of up to
300 million 4.3 million of their pre-2015 vintage cameras — the ones with hard-coded factory default passwords. (You can cut/paste the text into a translator and have a few laughs, or just take our word for it. The company’s name gets mis-translated frequently throughout as “male” or “masculine”, if that helps.)
Xiongmai’s claim is that their devices were never meant to be exposed to the real Internet, but rather were designed to be used exclusively behind firewalls. That’s apparently the reason for the firmware-coded administrator passwords. (Sigh!) Anyone actually making their Internet of Things thing reachable from the broader network is, according to Xiongmai, being irresponsible. They then go on to accuse a tech website of slander, and produce a friendly ruling from a local court supporting this claim.
Whatever. We understand that Xiongmai has to protect its business, and doesn’t want to admit liability. And in the end, they’re doing the right thing by recalling their devices with hard-coded passwords, so we’ll cut them some slack. Is the threat of massive economic damage from a recall of insecure hardware going to be the driver for manufacturers to be more security conscious? (We kinda hope so.)
Meanwhile, if you can’t get enough botnets, here is a trio of recent articles (one, two, and three) that are all relevant to this device recall.