Last week, we wrote about a DDoS attack on well-known investigative cybercrime journalist Brian Krebs.
To explain.
A DDoS attack is an aggressive sort of DoS attack, where DoS is short for denial of service.
A DoS is a bit like getting into the queue at the station to buy a ticket for the next train, only to have a time-waster squeeze in front of you and slow you down.
By the time the miscreant has asked, innocently enough, about the different sorts of ticket available, and whether it costs extra to take a bicycle, and how much longer it would take if he were to change trains in Manchester, only to walk off without buying a ticket at all…
…you’ve watched your train arrive, load up with passengers, and depart without you.
A DDoS attack is worse: it’s short for distributed denial of service attack, and it’s much the same thing as a DoS, except that the trouble-stirrer doesn’t show up on his own.
Instead, he brings along a big posse of innocent-looking accomplices to flood the whole station with time-wasters.
Genuine customers who are mixed in with the trouble-makers end up waiting far longer than usual – a problem that usually gets more and more frustrating as the backlog grows.
In the attack on Krebs’s site the crooks were able to generate an astonishing combined total of over 600 gigabits per second of time-wasting network traffic.
That’s equivalent to about 60,000 fast home networks all turning their entire bandwith onto Krebs at the same time, or a whopping 600,000 regular ADSL connections at once (assuming a one megabit per second upload speed).
If we assume that even a voracious reader of Krebs’s articles would use at most 10% of a home ADSL connection’s bandwidth when browsing the site, then the cost of neutralising this level of attack is the same as supporting at least six million concurrent legitimate users.
The perpetrators in the mega-DDoS haven’t been identified, but the attack happened not long after Krebs outed a DDoS-for-hire service called vDOS, leading to the arrest of two young hackers in Israel.
(Sophos experts Chester Wisniewski and John Shier discuss this attack, and the story behind it, in this week’s Chet Chat security podcast. [Starts at 1’08”.])
LISTEN NOW
(Audio player above not working? Download MP3, listen on Soundcloud or access via iTunes.)
The reason we mentioned home networks above, by the way, is that’s exactly where this attack seems to have originated.
Not from malicious bot or zombie software on regular computers, as might have been the case a few years ago, but from so-called Internet of Things (IoT) devices such as routers, web cameras and perhaps even printers.
If you’re surprised to hear that, don’t be.
Although a typical router or webcam has just a fraction of the computing power of your laptop, it’s more than capable of filling a typical home network with outbound traffic.
(After all, your powerful new laptop relies on your router to handle all that outbound traffic, so if your laptop can fill up the network connection, that’s only possible because the router can fill it on your laptop’s behalf.)
Sadly, in the aftermath of the assault on Krebs, the source code of the malware used in the attack was openly published.
It’s been removed from the hacking forum on which it was originally outed, but it still widely available “for research purposes” to anyone willing to look.
Mirai, as the malware is known, is badly programmed and unfinished, but that doesn’t matter.
It works, and it’s effective primarily because of bad programming in the very IoT devices it uses to do its dirty work.
The Mirai malware package
The Mirai bot, called simply bot
in the source code, is written in C, and has three main components:
- A call-home system that connects to a command-and-control server (which could be another insecure IoT device) to download details of whom to attack, and how.
- A set of attack routines that can generate a range of legitimate-looking but purposeless streams of network traffic to eat away at the victim’s network capacity.
- A network scanner that searches randomly across the internet and tries to login in various ways to build and report a list of insecure IoT devices for the next wave of attacks.
The Mirai source code package also includes a command-and-control tool, called cnc
, written in Go.
Cross-platform support is one of Go’s strong points: the compiler directly supports seven different computer architecures, including the 32-bit and 64-bit Intel chips in most modern laptops and servers, and the AMD and MIPS chips common in price-sensitive home IoT devices.
In other words, both the attack bot and the control server can be built to run on regular computers as well as many commonly-used hardware devices.
There’s a list of just over 60 built-in usernames and passwords that the Mirai bot uses to scan for other vulnerable devices; by all accounts, even this modest password dictionary is enough to find hundreds of thousands of easily-owned devices at a time.
How to steal 600 Gbit/sec
As we suggested above, between 60,000 and 600,000 home networks connecting simultaneously is, indeed, enough for a monster-sized attack of 600 gigabits per second.
We’re disappointed, but not at all surprised, to hear that malware like Mirai has things so easy.
After all, when SophosLabs researchers recently looked into a strain of malware called Mal/Miner-C, they noticed that it was widely found on network attached storage (NAS) devices from a well-known vendor.
In this research, SophosLabs quickly found 7000 NAS devices that were publicly writable via the internet, using the FTP protocol, with no password at all.
Of these, 5000 (more than 70%) already contained a copy of the Mal/Miner-C malware, deliberately left behind by the crooks for future malware distribution campaigns.
When investigating the Miner-C malware, our researchers focused their investigation carefully. They looked only at NAS devices, only for public FTP servers with no password, and only for the presence of Mal/Miner-C. Malware such as Mirai has no such scruples when it goes looking for vulnerable devices, which is why it can quickly find hundreds of thousands of devices to abuse.
Following the attack on Krebs, and his fascinating reports on what happened, he wrote that:
Many readers […] asked for more information about which devices and hardware makers were [targeted by Mirai]. As it happens, this is fairly easy to tell just from looking at the list of usernames and passwords included in the Mirai source code.
As you can see directly from the list above, and from a few tries with your favourite search engine, Krebs is right.
Some of the entries don’t even need a search engine: username/password pairs such as root/realtek
, root/dreambox
and ubnt/ubnt
speak for themselves.
But even obscure-looking credentials such as root/7ujMko0vizxv
are easily traced.
And that’s just the problem with hardwired “backdoor” passwords, as we’ve pointed out many times before.
Security through obscurity lasts only until someone penetrates that obscurity and shares the necessary secret, after which anyone can search for it, and so everyone knows it.
What to do?
If you’re a device vendor, this list is for you:
- Don’t use hardwired passwords. Those “secret codes” that let your own support staff get in and fix problems cheaply for forgetful users are an injury to us all, because they also let crooks get in and create problems cheaply for everyone.
- Don’t set default passwords. At least, don’t have default passwords that exist after the device has been set up for use. After a firmware reset, or on first bootup, prevent the device going online at all until the user has connected up directly to it and chosen unique passwords.
- Don’t allow unauthenticated or unencrypted protocols for inbound connections. In particular, that means no Telnet (use SSH instead), no FTP (use SFTP instead) and no web administration via HTTP (use HTTPS instead), even for connections from the internal network.
- Don’t open administrative connections on the outside interface by default. Most users don’t need to login from the internet, so don’t open up their devices by default for crooks to have a crack at logging in remotely. Let users opt in to remote access, instead of expecting them to remember to opt out.
LEARN MORE
For more IoT security horror stories from which we can all learn, both vendors and consumers, please see:
SubSurge
Naked Security, in your stories the INsecure devices are often highlighted; could you point us to a list or database of IoT vendors who DO take security seriously, for those of us who like to play without becoming part of the botnet?
Paul Ducklin
That’s tricky, at least for now…
…maybe we should start trying to collect things like “official security manifestos” from various vendors.
One huge part of the problem is that the IoT world is a bit like Android: even if the OEM fixes a security problem, how long until that fix percolates through all the products in the ecosystem that use that OEM’s technology in one way or another?
Larry M
There’s hope. My last few AT&T U-verse VDSL modems (by Motorola, Arris, and Pace) have had unique passwords.
Why have I had so many? Lots of outside line problems here, but the silly AT&T protocol requires them to change the modem first. And then I have to go through an hour of re-defining my internal networks, wi-fi parameters, static IP addresses for printers, etc.
Bryan
I’ve got my fingers crossed your next modem lets you save a config file (and that the following gear is still compatible with said upload).
Bob Stromberg
A very useful article. What is a device owner — for example, a homeowner — to do? How do we detect the presence of malware on one or any of our IoT devices? It would be a start to be able to tell if our home network was a source of outbound DDoS traffic.
James Beckett (@hackery)
“comments … show a casual attitude to quality”
TBH that looks par for the course in professional software, and I’ve seen much worse :(
Paul Ducklin
Here’s a fun one from Google back in 2014, ironically inside Android’s KeyStore module :-)
https://nakedsecurity.sophos.com/2014/07/02/anatomy-of-a-buffer-overflow-googles-keystore-security-module-for-android/
“To keep things simple, buffers are always larger than the maximum space we needed, so boundary checks on buffers are omitted.”
Famous last word%#$$$PQSR???.-$?8?8oY8ŀEf??M?-?oT
-bash: ??c코Hi#^?m???G?貣?: command not found
Missing operating system
J Sun
Very helpful for many, thank you. What about some of the other widely used IoT devices, like Nest thermostats?
Paul Ducklin
We’ve written about them before…first bad and then good, as they’ve tried to improve security.
I haven’t ever tried one, let alone hacked on one, so I can’t be sure they’re safe, but the company does seem to take security seriously. Any Nest users care to comment?
Larry M
Why do you suppose they even wrote that function instead of invoking:
method = toupper(method)
?