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.
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.
Early today, some party unleashed a massive DDoS attack against Dyn, a major DNS host. This led to a number of websites being completely inaccessible. DNS is the backbone of the Internet. It is the phone book that turns URLs into IP addresses. Without it, the Internet still works, but you won’t be able to find anything.
Over the past few months, security professionals have suggested — in as responsible terms as possible — that something big could happen. In early September [Bruce Schneier] wrote, Someone Is Learning How To Take Down The Internet. The implication of this very general warning is that someone — possibly a state actor, but don’t be too sure about that — was figuring out how to attack one of the core services of the web. The easiest way to effectively ‘turn off the Internet’ for everyone is a Distributed Denial of Service attack against root servers, DNS servers, or some other service that plays a key role in the web.
Dyn is responding well to the attack this morning, and the Internet is safe from attack for the time being. As for who is responsible for the attack, what the goal is, and if this will happen again, no one knows. An attack on this scale is most certainly someone with a very large pocketbook or a state actor (Russia, China, the US, UK, Germany, Israel, or the like) but that’s not a given. It’s also not given the DDoS attacks have stopped. You might not be able to read this, but if you can, it might be a good idea to find a shortwave radio.
We should all be familiar with the so-called Internet Of Things, a proliferation of Internet-connected embedded electronics. The opportunities offered to hardware hackers by these technologies have been immense, but we should also be aware of some of the security issues surrounding them.
Recently, the website of the well-known security researcher [Brian Krebs] suffered a DDoS attack. What made this attack different from previous ones wasn’t its severity, but that it had been directed not from botnets of malware-laced Windows PCs but from compromised IoT devices.
One might ask how it could be possible to take control of such low-end embedded hardware, seeing as it would normally be safely behind a firewall, preloaded with its own firmware, and without a clueless human at its terminal to open malware-laden email attachments. The answer is quite shocking but not entirely surprising, and lies in some astonishingly poor security on the part of the devices themselves. An exposé of one such mechanism comes courtesy of [Brian Butterly], who took an unremarkable IP webcam and documented its security flaws.
The camera he examined exposes two services, a web interface and a Telnet port. While from a security perspective their lack of encryption is a concern this should not pose a significant danger when the device is safely on a private network and behind a suitable firewall. The problem comes from its ability to send its pictures over the Internet, for the owner to be able to check their camera from their phone some kind of outside access is required. Expensive cameras use a cloud-based web service for this task, but the cheap ones like the camera being examined simply open a port to the outside world.
If you are familiar with basic firewall set-up, you’ll be used to the idea that open ports are something that should be under control of the firewall owner; if a port has not been specifically opened then it should remain closed. How then can the camera open a port? The answer lies with UPnP, a protocol enabled by default on most home routers that allows a device to request an open port. In simple terms, the camera has an inherently insecure service which it asks the router to expose to the world, and in many cases the router meekly complies without its owner being any the wiser. We suspect that many of you who have not done so already will now be taking a look at your home router to curtail its UPnP activities.
We covered the [Brian Krebs] DDoS story as it unfolded last week, but we’re sure this is likely to be only the first of many stories in this vein. As manufacturers of appliances struggle to learn that they are no longer in the dumb appliance business they need to start taking their software security very seriously indeed.
Now it’s official. The particular website that was hit by a record-breaking distributed denial of service (DDOS) attack that we covered a few days ago was that of white-hat security journalist [Brian Krebs]: Krebs on Security.
During the DDOS attack, his site got 600 Gigabits per second of traffic. It didn’t involve amplification or reflection attacks, but rather a distributed network of zombie domestic appliances: routers, IP webcams, and digital video recorders (DVRs). All they did was create HTTP requests for his site, but there were well in excess of 100,000 of these bots.
In the end, [Krebs’] ISP, Akamai, had to drop him. He was getting pro bono service from them to start with, and while they’ve defended him against DDOS attacks in the past, it was costing them too much to continue in this case. An Akamai exec estimates it would have cost them millions to continue defending, and [Brian] doesn’t blame them. But when Akamai dropped the shields, his hosting provider would get slammed. [Krebs] told Akamai to redirect his domain to localhost and then he went dark.
Brace yourselves. The rest of the media is going to be calling this an “IoT DDOS” and the hype will spin out of control. Hype aside, the facts on the ground make it look like an extremely large distributed denial-of-service attack (DDOS) was just carried out using mostly household appliances (145,607 of them!) rather than grandma’s old Win XP system running on Pentiums.
We can argue all day about whether a digital video recorder (DVR) or an IP webcam is an “IoT” device and whether this DDOS attack is the biggest to date or merely among them, but the class of devices exploited certainly are not traditional computers, and this is a big hit. Most of these devices run firmware out of flash, and it’s up to the end user (who is not a sysadmin) to keep it up to date or face the wrath of hackers. And it’s certainly the case that as more Internet-facing devices get deployed, the hacker’s attack surface will grow.
Why did the DDOS network use these particular devices? We’re speculating, but we’d guess it’s a combination of difficult-to-update firmware and user “convenience” features like uPnP. To quote the FBI “The UPnP describes the process when a device remotely connects and communicates on a network automatically without authentication.” You can see how this would be good for both the non-tech-savvy and hostile attackers, right? (Turn off UPnP on your router now.)
We alternate between Jekyll and Hyde on the IoT. On one hand, we love having everything in our own home hooked up to our local WiFi network and running on Python scripts. On the other hand, connecting each and every device up to the broader Internet and keeping it secure would be a system administration headache. Average users want the convenience of the latter without having to pay the setup and know-how costs of the former. Right now, they’re left out in the cold. And their toasters are taking down ISPs.
Well, that was fun… no, not really, but we’re back from the dead like Steve Jobs. We’ve been getting DDoS’d since essentially the first day we originally came back. After killing a 1G connection, we decided to find a different solution. Since the world didn’t end this week, we brought the site back using WordPress.com as the new host. We now return to our regular blog shenanigans. Here’s to another four years of beta!