As KrebsOnSecurity observed over the weekend, the source code that powers the “Internet of Things” (IoT) botnet responsible for launching the historically large distributed denial-of-service (DDoS) attack against KrebsOnSecurity last month has been publicly released. Here’s a look at which devices are being targeted by this malware.
The malware, dubbed “Mirai,” spreads to vulnerable devices by continuously scanning the Internet for IoT systems protected by factory default usernames and passwords. Many readers have asked for more information about which devices and hardware makers were being targeted. 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.
In all, there are 68 username and password pairs in the botnet source code. However, many of those are generic and used by dozens of products, including routers, security cameras, printers and digital video recorder (DVRs).
I examined the less generic credential pairs and tried to match each with a IoT device maker and device type. As we can see from the spreadsheet above (also available in CSV and PDFformats), most of the devices are network-based cameras, with a handful of Internet routers, DVRs and even printers sprinkled in.
I don’t claim to have special knowledge of each match, and welcome corrections if any of these are in error. Mainly, I turned to Google to determine which hardware makers used which credential pairs, but in some cases this wasn’t obvious or easy.
Which is part of the problem, says Will Dormann, senior vulnerability analyst at the CERT Coordination Center (CERT/CC).
“Even when users are interested in and looking for this information, the vendor doesn’t always make it easy,” Dormann said.
Dormann said instead of hard-coding credentials or setting default usernames and passwords that many users will never change, hardware makers should require users to pick a strong password when setting up the device.
Indeed, according to this post from video surveillance forum IPVM, several IoT device makers — including Hikvision, Samsung, and Panasonic — have begun to require unique passwords by default, with most forcing a mix of upper and lowercase letters, numbers, and special characters.
“As long as the password can’t be reversed — for example, an algorithm based off of a discoverable tidbit of information — that would be a reasonable level of security.” Dormann said.
Some readers have asked how these various IoT devices could be exposed if users have configured them to operate behind wired or wireless routers. After all, these readers note, most consumer routers assign each device inside the user’s home network so-called Network Address Translation (NAT) addresses that cannot be directly reached from the Internet.
But as several readers already commented in my previous story on the Mirai source code leak, many IoT devices will use a technology called Universal Plug and Play (UPnP) that will automatically open specific virtual portholes or “ports,” essentially poking a hole in the router’s shield for that device that allows it to be communicated with from the wider Internet. Anyone looking for an easy way to tell whether any of network ports may be open and listening for incoming external connections could do worse than to run Steve Gibson‘s “Shields Up” UPnP exposure test.
HELP! I NEVER CHANGED THE DEFAULT PASSWORD!
Regardless of whether your device is listed above, if you own a wired or wireless router, IP camera or other device that has a Web interface and you haven’t yet changed the factory default credentials, your system may already be part of an IoT botnet. Unfortunately, there is no simple way to tell one way or the other whether it has been compromised.
However, the solution to eliminating and preventing infections from this malware isn’t super difficult. Mirai is loaded into memory, which means it gets wiped once the infected device is disconnected from its power source.
But as I noted in Saturday’s story, there is so much constant scanning going on for vulnerable systems that IoT devices with default credentials can be re-infected within minutes of a reboot. Only changing the default password protects them from rapidly being reinfected on reboot.
My advice for those running devices with the default credentials? First off, make sure you know how to access the device’s administration panel. If you’re unsure how to reach the administration panel, a quick search online for the make and model of your device should reveal an address and default credential pair that can be typed or pasted into a Web browser.
If possible, reset the device to the factory-default settings. This should ensure that if any malware has been uploaded to the device that it will be wiped permanently. Most devices have a small, recessed button that needs to be pressed and held down for a several seconds while powered on to reset the thing back to the factory default settings.
When the device comes back online, quickly fire up a Web browser, navigate to the administration panel, enter the default credentials, and then change the default password to something stronger and more memorable. I hope it goes without saying that any passwords remotely resembling the default passwords noted in the image above are horrible passwords. Here’s some advice on picking better ones.
Unfortunately, many of these devices also require periodic software or “firmware” updates to fix previously unknown security vulnerabilities that the vendor discovers or that are reported to the hardware maker post-production. However, relatively few hardware makers do a good job of making this process simple and easy for users, let alone alerting customers to the availability of firmware updates.
“When it comes to software updates, automatic updates are good,” Dormann said. “Simple updates that notify the user and require intervention are okay. Updates that require the user to dig around to find and install manually are next to worthless. Devices that don’t have updates at all are completely worthless. And that can be applied to traditional computing as well. It’s just that with IoT, you likely have even-less-technical users at the helm.”
Only after fixing any problems related to default credentials should readers consider checking for firmware updates. Some hardware makers include the ability to check for updates through a Web-based administration panel (like the one used to change the device’s default password), while others may only allow firmware updates manually via downloads from the manufacturer’s site.
Firmware updates can be tricky to install, because if you fail follow the manufacturer’s instructions to the letter you may end up with little more than an oversized paperweight. So if you decide to go ahead with any firmware updates, please do so carefully and deliberately.
BUT WAIT, THERE’S MORE
Several readers have pointed out that while advising IoT users to change the password via the device’s Web interface is a nice security precaution, it may or may not address the fundamental threat. That’s because Mirai spreads via communications services called “telnet” and “SSH,” which are command-line, text-based interfaces that are typically accessed via a command prompt (e.g., in Microsoft Windows, a user could click Start, and in the search box type “cmd.exe” to launch a command prompt, and then type “telnet” <IP address> to reach a username and password prompt at the target host).
The trouble is, even if one changes the password on the device’s Web interface, the same default credentials may still allow remote users to log in to the device using telnet and/or SSH.
Brian Karas, a business analyst with IPVM — a subscription-based news, testing and training site for the video surveillance industry — said in his experience often times IP camera users can change whatever settings they want in the device’s Web interface, but that’s no guarantee the changes will affect how the device can be accessed via Telnet or SSH.
“The problem is there’s no hard and fast rule,” Karas said. “What often happens is Telnet and SSH are an operating system-level login, and the [Web interface] tends to be more of an application level login. Sometimes changing a password on one changes the password on the other, but more often the Web [interface] is completely different, and changing the password there may not change the underlying password” needed to access the device remotely via SSH and Telnet, he said.
Case in point: In February 2016 I published This is Why People Fear the Internet of Things, which examined a whole slew of IP cameras sold by Chinese Web camera giant Foscam that — by default — included a feature which would quietly phone home to a vast peer-to-peer (P2P) network run by the company. As I explained in that piece, while the Web interface for those P2P cameras included a setting allowing users to disable the P2P traffic, disabling that option didn’t actually do anything to stop the device from seeking out other Foscam P2P cameras online.
Interestingly, Karas said he’s been pressing Dahua — whose IoT devices are heavily represented in the above default password list — to tell him how many of their devices are vulnerable. Karas said Dahua told him that although the company’s newest models didn’t have this problem, the company was preparing to launch a trade-in program for customers with default-insecure devices.
“They didn’t give me a straight answer on this one, but that that tells me is they have a whole bunch of devices that may not be firmware updatable, which means they can’t make those devices more secure without swapping out the underlying hardware.”
Update, 8:30 p.m. ET: Added final section with the sobering caveat that all of this hassle in changing the default passwords and updating the firmware may not actually solve the problem for many (if not all) of the affected devices.
So what’s all the fuss about? Haven’t we always had things on our networks? In fact, until 20 or 25 years ago most of our networks were about connecting “things” — PCs, terminals, servers, hosts, routers, printers, etc. People were an afterthought, really.
Regards
Steve
Feds: hire them, don’t prosecute them! Good talent is difficult to recruit, and Silicon Valley often gobbles up top tier talent for those who can make it out of mom’s house.
When we elect a known criminal to public office – who has deliberately compromised security to cover their own tracks while shaking down foreign governments and corporations – how can we punish anyone. Legally, it’s selective enforcement.
Turn off Fox News for 24 hrs and educate yourself a bit!!
This isn’t something that requires a lot of talent, particularly because this uses simple, well-known holes in security. Indeed, no one familiar with default security on the internet is surprised by this attack.
Whoever did this should be prepared to face legal repercussions.
To the extent that we should consider cutting these people some slack, it shouldn’t be based on “talent” on their part, but because of irresponsibility of those of us who designed these systems in the first place.
Somewhat of a long shot here but, is it possible to pull out the MAC addresses of the devices that are part of the “mirai” device list and see if they can be organized into a machine discernable list so that I can write an IPS signature for it. Meaning, are the Octets in the MACs of these devices in a sequential range that allows for me to create a signature on that “subnet”. If that works, then we can work with ISPs or others in the internet business to more easily identify aggregated traffic.
Similarly, I would like to see or develop a list of Mirai-susceptible OUIs so that I can disallow those on the network.
You do realize that once a packet gets routed, the MAC address changes, right? And…there are other ways of moving data around at Layer 2 other than the usual Ethernet.
Link to Gibson’s test page is wrong; goes to a local Windows confit utility instead of his ShieldsUp scanner.
gibson pages are wordy. scroll far down to link to test page.
ubnt/ubnt is the default password for Ubiquiti Aircam and UniFi Video Cameras. Given the prevalence of cameras on this list I guess that’s more likely the target than AirOS. Could be both, though.
I believe that’s the default login for Ubiquiti stuff period. I know my UniFi AP used that as the default, as does the UniFi controller on first install
Did the cyberattack affect Linksys wireless routers or Dell laptop wireless modems? I help friends & family with computer problems & there’s been several “bricking” in the last 2 weeks.
Linksys wireless routers or Dell laptop wireless modems
Maybe those are susceptible, if those have telnet logins that are independent of logins user edits/sets in the web interface.
Check if linksys has firmware updates or dell has driver updates. Dell download pages have brief notes.
bricking
Maybe you should post details in a forum that gives help (perhaps other users in whichever forum)
So we have been working on this for some time. We helped develop a hardening guides (here’e one http://www.axis.com/files/sales/AXIS_Hardening_Guide_1488265_en_1510.pdf ) that directly addresses many of these issues as well as a platform that provides technical automation to help installers of these systems. http://www.securitysystemsnews.com/blog/eidola-created-integrators-ensure-cybersecurity
Thanks for that link, Salvatore. I can’t help but notice, however, that the guide instructs users to disable lots of settings in the name of security. Seems to me, a better option would be to disable the potential security risks by default, and encourage people to turn them on only if they need those features.
That seems to me to be the crux of the problem for most IoT devices: They are insecure by default, and require readers to step through a 23-page PDF on how to do that.
What makes the IoT attack vector unique is that there’s no incentive for anyone to fix it. How much do *YOU* care that your fridge just broke the internet? Probably not that much, definitely not enough for you to change your fridge’s admin credentials, update firmware, etc.
It’s a “problem of the commons” and, like all public goods problems, we need a public solution.
There should be a global standards body for certifying the security standards of IoT hardware. Much in the same way Underwriters Laboratories certifies my light bulb socket won’t set my house on fire (and without that certification, hardware store can’t import that socket from China) gotta find a way to bring governments and manufacturers together worldwide to enforce security audits on consumer products…
The FCC does this with radios, NHTSA does this with cars, FTC does this for most other merchandise categories… we need local and global bodies to take an active role in protecting the world from unsafely designed products.
There’s one solution but it’s gnarly and quite illegal. Have cameras /(etc) that have public exploitable vunls start perma DDOSing their manufacturers. You can bet your bottom dollar those manufacturers will be incentifvised to fix it when there very existence as internet citizens is at stake.
With that said , the nuclear option isn’t exactly fair on the poor users. Perhaps the vigilante solution is to just remote patch the damn things
(And I don’t recomendation any of those courses of action)
If you’re looking to test your devices for default username and passwords, the following sites will help you out, the following websites are great starting points:
https://cirt.net/passwords
http://www.defaultpassword.com/
Then check to see if your organization is listed on Google or Shodan. If you’re listed and default passwords works, time to reset your credentials for your device and prevent Internet crawlers to list your services.
EV ZLX 2-way speakers have zero network connectivity.
I know. I own them.
I notice there’s no link in the evidence column so I’m confused how this device ends up on the list.
There are numerous professional speakers that connect using Dante and AES50 over Ethernet but the EV ZLX series definitely does not.
Thanks, Michael. As I said in the story, these should not be taken as gospel. I will go back and look to see if I have the link to supporting evidence, but if you have found another candidate, I’d be happy to update the graphic.
Bk
More useful would be a list of devices which aren’t as vulnerable to Telnet & SSH attack. Anybody got one?
DJ, that’s ridiculous. A list of non-affected devices (whitelist) would be huge, it’s much easier to read and distribute a blacklist.
I know what he means though. This short list just happens to be the ones used in this attack on some of the low-hanging fruit. Next time it could easily be Telnet or SSH used and your really complex password will make no difference. I need to set up a DVR for CCTV cameras in an office and a requirement is they want to be able to see live footage on the web if the alarm goes off. Any advice on buying and configuring kit that isn’t leaving them wide open?
As a former Xerox certified tech for a Western NY VAR, I can attest that is the practice for some techs to reset the password to one of the defaults if they can’t log into the printer. Sheer stupidity…
Those Ubiquiti passwords are used on all of their devices that I’ve seen. That includes at least their p2p links and cameras. I’ve seen multiple nanostation and aircams using that same pair.
Not that you’re incorrect, I’m just highlighting that it goes beyond their routers.
Still trying to figure out what software was running on the infected devices. Was it windows 10 IoT, a linux or some aruidino software.
Be nice if the makers of IoT devices setup a stranded such as.
1) Post reset/boot of device the default User/PW is only good for say 1 hour
2) After that hour it default User/PWwon’t work and can only be logged into with a user/pass that is not same as default.
This would stop most botnets from crawling the net looking and logging into the devices with known/default user/PW’s successfully
Even behind a NAT with UPnP off, a device can be infected by Mirai-like malware running on a PC, smartphone or any other capable host within the LAN.
For example, a compromised laptop could infect WiFi cameras at a coffee shop it is briefly used in. (That is, if that coffee shop has a plain vanilla WiFi LAN.)
My solution was simple. My cameras are configured to work only on my intranet, and no. PNP disabled everywhere. And just to be extra safe, through parental controls on my router, all cameras MACs are blocked from contacting internet. Then, when outside, I VPN into my network, and my camera viewer software on my phone/tablet/laptop works like I’m at home. Of, course, all passwords on cameras, router, software, VPN are super long and complicated. There is no perfect security, but I think, this is as safe as I am going to get.