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, virtually guaranteeing that the Internet will soon be flooded with attacks from many new botnets powered by insecure routers, IP cameras, digital video recorders and other easily hackable devices.
The leak of the source code was announced Friday on the English-language hacking community Hackforums. The malware, dubbed “Mirai,” spreads to vulnerable devices by continuously scanning the Internet for IoT systems protected by factory default or hard-coded usernames and passwords.
Vulnerable devices are then seeded with malicious software that turns them into “bots,” forcing them to report to a central control server that can be used as a staging ground for launching powerful DDoS attacks designed to knock Web sites offline.
The Hackforums user who released the code, using the nickname “Anna-senpai,” told forum members the source code was being released in response to increased scrutiny from the security industry.
“When I first go in DDoS industry, I wasn’t planning on staying in it long,” Anna-senpai wrote. “I made my money, there’s lots of eyes looking at IOT now, so it’s time to GTFO [link added]. So today, I have an amazing release for you. With Mirai, I usually pull max 380k bots from telnet alone. However, after the Kreb [sic] DDoS, ISPs been slowly shutting down and cleaning up their act. Today, max pull is about 300k bots, and dropping.”
Sources tell KrebsOnSecurity that Mirai is one of at least two malware families that are currently being used to quickly assemble very large IoT-based DDoS armies. The other dominant strain of IoT malware, dubbed “Bashlight,” functions similarly to Mirai in that it also infects systems via default usernames and passwords on IoT devices.
According to research from security firm Level3 Communications, the Bashlight botnet currently is responsible for enslaving nearly a million IoT devices and is in direct competition with botnets based on Mirai.
“Both [are] going after the same IoT device exposure and, in a lot of cases, the same devices,” said Dale Drew, Level3’s chief security officer.
Infected systems can be cleaned up by simply rebooting them — thus wiping the malicious code from memory. But experts say there is so much constant scanning going on for vulnerable systems that vulnerable IoT devices can be re-infected within minutes of a reboot. Only changing the default password protects them from rapidly being reinfected on reboot.
In the days since the record 620 Gbps DDoS on KrebsOnSecurity.com, this author has been able to confirm that the attack was launched by a Mirai botnet. As I wrote last month, preliminary analysis of the attack traffic suggested that perhaps the biggest chunk of the attack came in the form of traffic designed to look like it was generic routing encapsulation (GRE) data packets, a communication protocol used to establish a direct, point-to-point connection between network nodes. GRE lets two peers share data they wouldn’t be able to share over the public network itself.
One security expert who asked to remain anonymous said he examined the Mirai source code following its publication online and confirmed that it includes a section responsible for coordinating GRE attacks.
It’s an open question why anna-senpai released the source code for Mirai, but it’s unlikely to have been an altruistic gesture: Miscreants who develop malicious software often dump their source code publicly when law enforcement investigators and security firms start sniffing around a little too close to home. Publishing the code online for all to see and download ensures that the code’s original authors aren’t the only ones found possessing it if and when the authorities come knocking with search warrants.
My guess is that (if it’s not already happening) there will soon be many Internet users complaining to their ISPs about slow Internet speeds as a result of hacked IoT devices on their network hogging all the bandwidth. On the bright side, if that happens it may help to lessen the number of vulnerable systems.
On the not-so-cheerful side, there are plenty of new, default-insecure IoT devices being plugged into the Internet each day. Gartner Inc. forecasts that 6.4 billion connected things will be in use worldwide in 2016, up 30 percent from 2015, and will reach 20.8 billion by 2020. In 2016, 5.5 million new things will get connected each day, Gartner estimates.
For more on what we can and must do about the dawning IoT nightmare, see the second half of this week’s story, The Democratization of Censorship. In the meantime, this post from Sucuri Inc. points to some of the hardware makers whose default-insecure products are powering this IoT mess.
How are these IoT devices being exposed? Do they use UPnP or similar to have the router automatically open incoming ports? Otherwise traffic wouldn’t cross the typical NAT boundary found on most home networks.
Or are there just that many IoT devices being given public IP addresses and not protected by firewalls?
Most support UPnP or require you to open the port manually, but the point behind these systems is that they are remotely accessible – their very purpose is to be able to view a video feed off-site over the Internet.
There’s no simple way to just “lock them down” or not allow them to be publicly accessible – their very purpose is at odds with that.
They can be better secured, of course, and there are better access control technologies that could also be employed, but… for most users of these kinds of devices, plug-and-play is all they want.
I think there is a simple way.
Have these systems Require and admin password set upon first use. And block the top 10+ passwords from being used.
Let there be a reset button, but requires a password to be set when used.
The problem is these devices were released without any thought given to ongoing software support. These devices will live on the internet, in their current state, until their owners’ decommission them. The cat is already out of the bad for those devices. Unless standards are put in place around IoT security, these devices will continue to flood the market.
Many of these units are on their own dedicated line for remote administration.
I guess the ‘positive’ in this is that since there’s so many people looking to now set one of these botnets up, the units are going to be completely molested with no spare capacity, meaning no single user is going to be slinging a Tbps at a single target.
It still means there’s now a Tbps of DDOS flowing around the ‘net in every which direction, but it’s now drawing a lot of attention.
Many IoT devices communicate back to servers to “check in”. This includes ntp, ftp, ssh, http, https, ‘security patch’, ping on start, ping on , twitter, facebook, irc, etc. Once the device checks in, an application reads the channel and begins the handshake process through your silly NAT’s, poor security policies and faulty stateful firewalls.
IoT devices usually use UPNP to force-open ports. Some have additional vulnerabilities that connect to manufacturers’ servers for remote control and unsigned updates.
Question, how can i be aware if i have devices on my network vulnerable to being used in Botnets?
If you’re running devices with the default username and password, they are probably already compromised. Reboot/unplug/replug/ the device, and/or reset it to its factory default settings (most devices have a tiny button you need to press and hold for this) and then change the default credentials.
I feel the real problem would be all those legacy devices which offered a max password length of 6 (maybe 8) with alphanumeric only passwords. Not really sure if they will ever get a firmware update.
So, even if you reboot and set a new password, it will still remain vulnerable to brute forcing within acceptable amount of time.
There is a conundrum here that a solution needs to be found that is effective but not so overly complicated that it cannot be accomplished by people unsophisticated enough to properly secure their IOT devices in the first place. However, advising people to reboot and change passwords may not be enough. Is there some information they can pull from their router that would indicate they are part of a botnet? Are there any relatively inexpensive and fairly plug and play appliances or apps that would provide indications or early warning for people who want to be conscientious about this but are not full-time cybersecurity professionals or researchers? With the release of this source code, the DDoS problem only gets worse. Developing solutions at all levels will be needed but smarter people need to help well-meaning but less technically inclined people take useful action. I hope some attention will be given to this aspect of the problem by all you smart guy types.
Frank, We’ve been looking at these issues for a while now with the IoT Security Foundation and we’re close to publishing materials designed to address the issues more holistically. As one of our board directors keeps saying “IoT is a slow motion train wreck in action”. Whilst IoT is much, much bigger than the consumer segment, consumer products have been grabbing a large portion of the headlines (together with connected cars) and we’ve focused our initial efforts here (on consumer connected products). Even today we’re still witnessing well known brands making school boy errors – so ridiculously bad that its hard to know whether it’s wilful neglect or just plain ignorance (see here for one just last week https://thehackernews.com/2016/09/hacking-d-link-wireless-router.html ). For the consumer segment the basic challenge comes down to this; we cannot expect everyone (anyone) to be a security expert and so security has to be consumable, by default, and at low (no) cost. For the consumer segment, the first goal is to reach a low level of assurance as, quite frankly, in some parts of the industry it is currently below ground.
The first step is to get the basics corrected with the technology, but that’s not enough, we can see that we need to encourage culture change both at the corporate level and at the supply chain level. To do this we’ll need to share the responsibility for security – in the age of hyper connectivity we all need to do our bit and it has to start by baking as much of that in at the start.
FWIW, the GRC “Shields Up” offers a UPnP check.
. . .
So if the test comes back with “you’re good” does that mean these bots can’t get at a router?
. . .
“Reboot/unplug/replug/ the device, and/or reset it to its factory default settings (most devices have a tiny button you need to press and hold for this) and then change the default credentials.”
Brian, by “credentials” you mean the password, or other things, too (talking about a router)?
BTW, I changed the password as soon as I installed the router.
Check your router’s firewall to see if there’s any port forwarding allowing external access to devices on your LAN. If you don’t need this access, remove it.
Reboot all devices, Change all passwords on all devices from defaults, and account names if possible. Use good passphrases.
change your default username and password, disable Upnp, enable mac filtering. Close all open ports not in use. Be safe out there.
How does MAC filtering protect from exploiting IoT devices? Wouldn’t you already have to whitelist the device in order to use it in the first place?
Mac filtering is useless outside your own LAN: http://serverfault.com/questions/36002/getting-an-ips-mac-address-from-behind-a-router
Since these devices are designed to be used remotely they are useless if you try to implement MAC address filtering since none of your trusted devices MAC addresses will make it to your IoT device for verification of legitimacy. The only MAC address it will ever see is that of your or your ISP’s router – regardless of if it’s a trusted device or a botnet attempting to access it.
Brian, did Akamai gather any data on the make/model/IP of IoT gizmos involved in the attack on this your web site?
Does it make sense to use data like that to rig an IoT vulnerability checking service analogous to Troy Hunt’s “haveIbeenPwnd.com” ? People could punch in their make and model and find out how likely it is their devices were enslaved.
There are some devices out there that randomize their creds. It would be good to pressure the makers of the rest to do that.
Of course, it would probably be smart to have that web site just answer “yes, your gadget could have been enslaved. Bounce yur device and check your credentials.”
For the past few weeks we are providing extra information about the attack against this site and a few others in the website http://www.spoofit.org www. spoofit. org
Life is simple this it tech…sruff is too conplicated
There are a lot of holes in this story. If there are literally one million devices and the code is out, why are we not seeing catastrophic attacks every day?
Do you have evidence other than Akamai or Level3 said so? I imagine they’re motivated to embellish.
Methinks you aren’t looking very hard if you don’t see the daily attacks…
Meanwhile, Netflix is down worldwide for two hours, with certain “Brazilian Cyber Army” claiming credit for it. A new era of mega DDoSes? Feels like year 2000 all over again.
It seems like these IoT devices should have been designed to initiate an outbound connection back the the vendor, and then the customers could remotely control their devices by simply connecting to the vendor’s website with a browser. Then the device would not have a public IP and therefore no Internet presence. The downside is that if an attacker managed to compromise the vendor’s server(s), then they have a one-stop shop for remotely controlling a LOT of people’s IoT devices.
As for SOHO routers, I just don’t understand that. Don’t those come pre-configured to disallow mgmt connections on the external port by default? If not, they damn well should.
The other side is the vendor would charge for it and when the vendor decides to discontinue your device or your service, tough.
We need more of these but there’s way too many manufacturers and this only covers devices sold in the USA: https://www.ftc.gov/news-events/press-releases/2016/02/asus-settles-ftc-charges-insecure-home-routers-cloud-services-put
““The Internet of Things is growing by leaps and bounds, with millions of consumers connecting smart devices to their home networks,” said Jessica Rich, Director of the FTC’s Bureau of Consumer Protection. “Routers play a key role in securing those home networks, so it’s critical that companies like ASUS put reasonable security in place to protect consumers and their personal information.””
There are those of us, however, that don’t want to be at the mercy of the vendor. If they suddenly change hands, go out of business, etc. and leave us with hardware that is “dialing home” to a home that no-longer exists… Bad mojo.
The answer is for IoT products to adopt the same architecture–private device connects to public front-end server–but allow/require customers to run their own servers so the devices are not dependent on the vendor. With docker-style containers this is much easier than it used to be. But of course, the vendor loses that juicy lock-in revenue stream…
Brian, I have an idea but it seems too simple. If the bad guys can scan for routers with default pws then why can’t the good guys? If an ISP was to scan all their customers looking for such routers then they could contact the customer and demand the pw be changed. They could even offer a service call to change it. Even better they could turn off or limit the account if not changed in xx days.
From what I’ve seen, ISP’s are far more concerned about dealing with the WiFi name and password. There seems to be very little (if any) interest in the UN/PW for the router itself. But then, No one seems all that interested in this anyway. WiFi is the only thing anyone thinks about.
I wouldn’t want my ISP to scan devices for default user names and passwords, as that would open the door for the disgruntled employee to scan the IP addresses within the ISP and gather a database, and then sell that data base to others where they could then use that database to hack others. So no the ISP’s shouldn’t be allowed to scan their customer base for default usernames and passwords. Would you want your bank to do the same thing with your online banking credentials?
Remember the greatest threat to the internet and to the enterprise is the user not the device.
I do like the idea of proactive defense, but practical problems exist for it:
1. Time and expense. Running the scan is potentially a small cost, but it’s undoubtedly one in terms of time and money. And the act of contacting the customer, let alone supporting the ones who’ll need it runs higher. And yes, there will be cases where an organization will not be able to get away with informing the user they have an issue, therefore contact the device manufacturer’s tech support: Some units will be so old, there is no support. Others will have support teams who deny the problem, or refer them right back to you. There won’t be any ideal situation where all you do is notify customers and they fix things on their own, but even in that fantasy scenario there’s a cost to just contacting those customers to begin with.
2. How do you end up not looking like a compromise attempt? Too many people get taken in by the “Your computer is infected with a virus” type emails and phone calls. You may set the stage for further attacks by doing this legitimately. Also, because it can look like a compromise attempt, some people will not trust the contact. Others will add to the time and cost of the contact with verification (that is a GOOD thing because it establishes legitimacy, but the point is that it adds to the time and monetary cost, therefore that must be included in the cost/benefit analysis).
3. Are you setting your own support teams up for an accidental denial of support service? If a malicious actor sees proactive contacts go out, can he clog up your organization’s support by launching a few middling attacks, then doing something truly malicious while you’re at work handling the initial stuff?
Don’t get me wrong; I’m normally quite in favor of proactive notifications or actions. It’s just that, in my organization’s experience, those are the practical issues that come up and must be addressed (well, the first two are; thankfully we’ve never been hit by a planned attack in the way I laid out in point 3). It’s not as simple as just reaching out; complexities add up fast. It may still be worth the trouble, but those issues must be acknowledged and at least accepted, if not planned for.
I like E.M.H.’s answers . I’ll try to add a couple of others:
4. There may be laws which would result in the ISP being prosecutable for such activity (anti-hacking laws are pretty much never well written)
5. If your ISP charges you for bandwidth, you may be able to bring them to court for their inbound connections (essentially they’d be inflating your usage and thus billing)
6. This could easily not be allowed by the contract that you’ve established with your ISP.
This isn’t to say that I’m opposed to this sort of activity. I’m just saying that it’s a legal minefield.
You can read about Microsoft’s efforts to take down the Waledac botnet .
It’s worth considering the efforts necessary to unravel DNS Changer in 2011 .
In short, it requires lawyers, coordination, resources, and will.
There’s also the risk that an ISP which takes action like this could lose its Common Carrier status (a safe-harbor provision that ISPs can’t reasonably afford to lose).
It could be easier than that. Most ISPs already block TCP 25 (SMTP a.k.a. email server) so they could also block telnet. They probably would catch too much flak for blocking HTTP and FTP although blocking HTTP could be justified for the same reason as blocking SMTP; it’s not a business account.
No scanning needed. But since many ISPs won’t even block source IP spoofing, it will never happen.
It would be a real shame if some really evil person would take that code, modify it a bit, and disable all those devices (or change their password to something random).
It would be a real shame if some really evil person would take that code, modify it a bit, and use it to have insecure devices manufactured by company X stream their data at company X’s web site.
Hardwired cable modems are OK? I hope. Out of box wi fi users need a heads up on the box from the makers in BOLD TYPE to customize password assuming they would act on it? What else would work?
They are fine until they are not (when someone discovers that secret undocumented debug backdoor username and password that the vendor thought they hid so well).
That is the worst issue because it relies on the vendor updating firmware to update/lockout/change and that rarely happens.
Users using secure usernames and passwords sure that would help. Part of the problem there is default settings exposing admin interfaces to the web so again, back to the vendor designing things with security in mind.
The largest sign on a package won’t help – users don’t typically care about being a good internet steward, they just want their toy to connect and work no matter how it is done (partly because they have no clue – they plug it in and it works). It needs to be baked into the device and enforced there really…
I have changed the router admin password, and performed a “shields up” check. But I didn’t change the wifi password which I assume is randomly generated and only useful if someone is in my driveway. Is that OK?
Wouldn’t the next step is to require devices that are accessible from the internet to have a secure password entered before they can operate?
If the device has no user interface, then the vendor would have to have an audited process for installing secure passwords at the factory.
What devices do I need to worry about? I have PCs, tablets, mobile phones and some Raspberry Pis connected. The latter can be accessed with Filezilla and TightVNC, but I thought only from inside the home network.
Your boundary device is likely your router or a firewall. If nothing is open inbound through that boundary device, you should be fine.
Don’t forget that uPNP can mess this up on you – disable it!
Anything that can be networked is at risk if exposed since it can be used to send legitimate traffic to a target and be part of that flood.
Shields up is a great way to check if you have any open ports.
Also, changing the router admin password, good job. Don’t forget to ensure management from WAN side is disabled (or do you really need access to your router from the internet…?)
I have 2 IoT devices nest thermostat and another temperature sensors at home, both required only wofi access. there was no admin/password setting. I dont even know if you can access them. Does anybody have any list of actual examples of these devices affected?
@Brian posted a list of some in his next article . But note that any list isn’t really exhaustive, it’s more “a list of devices that someone bothered to catalog”. The exhaustive list is more like “all devices that aren’t running the *latest* version of iOS/macOS/Android/Windows/Ubuntu/Red Hat/OpenBSD/Solaris” (I’m not listing all Linux distributions, it’s pretty easy for a given distribution to fall behind, and it’s easier for a user to fall behind updating a device tied to a Linux distribution, the same applies to Windows and Unixes in general FWIW).
Most hardware has default passwords which are at least used by developers in the development stage (before shipping to customers). Whether they do a good job of removing all such accounts and forcing users to set up secure accounts at deployment varies by vendor, but most fail in this area IME. And that excludes the likely vulnerabilities in all of the code running on the devices which will enable an attacker to set up their own connection (“shell access”).
Offhand, based on reading an article about temperature sensors, I’d be vaguely worried about it.
Given that Nest Labs is maintained by Alphabet , I’d expect it to be fairly secure in general, and to receive security updates as needed.
It seems that new Mirai deployments are talking place as we speak. Here there is a list of locations and domains that we have identified so far. If you know of any others, please let us know using our contact form in the site.
Thanks to those that have reached out to help to work with the samples!.
The latest updates are:
– The domain xf0.pw hosts a CNC and reporter with IP addresses 220.127.116.11 and 18.104.22.168. BlazingFast IO and ATM S.A. Poland.
– santasbigcandycane.cx has moved now to 22.214.171.124, still in AS50673 Serverius
– disabled.racing have been used as CNC and Report domains
Permanent fixes for slightly more technical end users is to reflash your router with open source firmware like DD-WRT or the like.
Another option is to put it all behind a firewall like pf-sense or Sophos UTM.
But that leaves 90% of users in the dark yet…For them, sure they can reset but they get reinfected right away. That leaves ISPs blocking people that appear infected, but that isn’t effective either because now you’re inflicting pain on users that aren’t actually infected (false-positives).
Any rational solution comes back to vendors doing it right in the first place. we’re screwed unless someone comes up with something else.
Who are ‘the vendors’?
Most people think of HVAC companies as vendors (Target). But no one ever seems to consider anything any deeper. Most of this stuff ends up with manufacturers like Foxconn (the makers of the iPhone/iPad). There are others but Foxconn has been making the solid state components for so long and with such broad sweeping arms that they ARE part of what makes all of this such a problem. They have the ability in a very direct way of baking into any IoT device backdoors that can be accessed through those that traffic in malware/botnets at a high enough price (governments and state level hackers). I find it interesting that the world just shrugs their shoulders at Foxconn suicides based on pure statistics.
People are being used. What happened to Krebs and what will happen to others are prime examples. Since the average person refuses to understand anything about the tech the bring into their homes, people end up getting played.
Yes, vendors of a degree of responsibility here. So do ISP’s. So does end users. This problem cannot be fixed by any one thing. Just like the web cannot exist based on any one thing. The Internet as a whole is the greatest gift that man kind has ever given to man. But this gift needs to be maintained. There are those that want to destroy this gift as part of a very real desire to throw the entire human race backward a thousand years.
The “vendors” in this case are the manufacturers of vulnerable DVRs. The base platform (developed by HiSilicon) is vulnerable. All third party devices (Kguard, Zmodo, Rosewill, Night Owl to name a few popular US brands) are vulnerable as well, since the base platform itself is at fault.
It’s purely the vendors here. It is definitely possible to make a device that can be exposed to the internet safely – these devices have zero care on security and ship with unchangeable telnet credentials just as one of the issues.
Ok. So now that we know this, it then falls on consumers to NOT be fooled. It is now on the consumer to NOT buy or use these products. These products are going to be manufactured and sold to anyone gullible enough to think that they are safe simply by virtue of being on the shelf. It is really just an extension of…..”I read it on the internet so it must be true”.
Otherwise, I have to conclude that anyone reading what you just wrote simply does not believe you (or at the very least does not understand something so simple). Most people will just dismiss all this. If not for being ‘conspiracy theory’, then certainly for the idea that all they have to do is ‘update’ the firmware and they will be perfectly safe.
There are plenty of things I have been suggesting for many years that are unsafe to use. Things that are infected ‘out-of-the-box’. Things that I know are flawed by design and that updates will never fix. I have commented about this on this site for a while now. Maybe I’m preaching to the choir. Maybe I’m getting dismissed with a chuckle. Who knows? But with all this idiocy going on and so many people not really knowing what to do or how to do it, one thing is absolutely beyond a shadow of any doubt……..
As my thermostat, my bed, my refrigerator, my toaster, and my tv’s are not IP addressable; they do NOT contribute to any DDOS attack against anyone.
Well, may be the time has come for an enviromental ethics codex for IT. Given the fact it has not been sorted out for the “physical” realm nor the “cultural” one, there are wars ahead with an unpredictable outcome…
Can you rely on consumers not to be fooled?
Surely you should have a kite-mark (US/EU standard) approval before being allowed to sell IP addressable devices.
There are a few kitemarks that count, namely US Federal Approval and EU approved. Even if not enforced in other countries, consumers would look for the kitemark, and developers would aim to get it – just as the EU’s RoHS standards are now followed in most of the world.
Part of the kitemark requirement would the requirement to have a secure password on the device.
I am by no means suggesting that we should “rely” on the consumer not to be fooled. Manufacturers do absolutely have responsibilities here. This really is just like prostitution though. You can blame the prostitute or you can blame the john that pays her. One would not exist without the other. They are both just as guilty.
But if you want to talk about meeting standards as an industry…..well, we have Windows from Microsoft that meets standards (I guess) but it requires constant patching for its never ending line of flaws. Can you imagine the outcry from a security camera maker that forces every camera it makes to undergo monthly updates and patches throughout the entire life of the camera? Cameras like that are things that I would never suggest anyone waste their money on. Now sure, there is a huge difference between a camera and an OS. But think about it for a second. Within the context of your question……what really is the difference?
Does it not strike you as a bad idea to be posting the fact the source code most likely (Almost certainly) behind your recent attack, for other children to get a hold of and launch more attacks?
Responsible journalists do not openly advertise malware to potentially malicious users. Use your head.
I disagree. Children are not going to go the KOS to find “hacking” tips; if they have that predilection at all they will go to better known black hat sites to get their information.
I consider KOS a “white hat” site, where IT professionals can get their news, hopefully unmolested by anti-first amendment views. Fixing the problem requires these details after all.
You again? Should I instead advertise remote access trojans? Would that better? For reference, here’s the background on this “Armada” commenter:
There’s a difference between advertising a product and informing a population. This falls under the latter. And the service provided by informing the readership and getting the news out there beyond the readership (via pass-along methods i.e. word of mouth, reposts, quotes in other media, etc.) far outweighs the problem of informing one new kiddie that there are new exploits out there to play with. That crowd is diminishingly small, given that most will already know where to look, therefore it’s only the “new” inexperienced bad actor with no current resources who’d benefit form discovering this from Brian.
The manufacturers should be responsible to some extent I believe. They have released poor configuration capabilities and made it hard for users to lock down many of these devices or patch them. For example, you should never be able to setup these devices with default credentials. They should require new creds and not allow the defaults beyond initial setup.
There should be some requirement that a device be supported for a certain period of years too. There are many other possibilities as well. I guess that’s were consumers are at fault too. As long as people keep buying insecure devices, manufacturers are going to keep selling them. It is really a shame how difficult it is to properly protect home and mom/pop networks. It requires some Sys Admin skills and a mindset to realize the need for secure configuration and proper maintenance.
If the source code is out there, would it be safe to assume you have seen it? If you, or some other responsible person, has it, could you not go through it to put together a list of the devices it exploits?
I’d love to see a full list of the things it specifically attacks so I could check all of my family’s hardware for vulnerabilities that are baked in. (i.e. hardcoded/can’t be changed)
Would it be bad for someone to release a list of default usernames/passwords, ports, etc. to check your own stuff against? At the very least, it would be nice for someone, with the resources, to check the code against a bunch of common devices (e.g. Zmodo DVRs, webcams, etc.), then put up a list of ones that were vulnerable.
It would be nice if something like ShieldsUp could have this type of check baked in.
Release default usernames and password? Why?
Here is a hint. If you didn’t set a username and password, then your device has the “default”.
The simplest thing I’ve ever thought of for reducing the attack surface of the internet is for devices’ remote administration tools – what is commonly being exploited today – to have a default of sending replies two hops only. This is a single setsockopt to reduce the hopcount(ipv6), or TTL(ipv4) to 2 or 3 in the daemon – or enforced by a firewall on a synack. This would still allow for local configuration and managability while eliminating threats far away.
Unfortunately, IoT devices want to be able to call home or “network”.
Also, manufacturers don’t want to be on the hook for “support calls”, where, e.g., a customer adds an extra router (possibly a repeater) to their configuration and suddenly things mysteriously stop working.
Support calls are pure money-losers for most companies, so their goal is to prevent any such need.
The market also tends to reward vendors for “simplicity” and the fewest steps between “purchase” and “use”. Awkward setup steps frustrate customers and can lead to returns, which are also bad for the vendor.
Looks like it’s time to start installing LaBrea again.
My telnet tarpit is catching a lot these days. If this was done more widely then scanning for vulnerable IoT (and other) devices would be a lot more difficult and less attractive.
I’ve experienced a rise in port 23 netprobes coming into the SOC in the past 6 months. I’ve set up a monitor this week to see if that number increases again (should be interesting to analyse it!).
On another note, I believe that the other IoT malware is called ‘bashlite’ (as opposed to ‘bashlight’).
“Anna” is from:
“Shimoneta to lu Gainen ga Sonzai Shinai Taikutsu na Sekai”
Or “Imagine a World without Dirty Jokes”
Is there a “name and shame” site for tragically unsafe internet connected devices such as the DLINK DWR-932 B LTE router?
For a major manufacturer to be so utterly negligent is totally unacceptable.
Shining a bright light on these poorly made products and the companies that release them to the public should start to negtively impact their profit, which is the only way they will improve.
The Phisher King, you could send a tip to The Consumerist blog, and see if they follow up. They’re affiliated with Consumer Reports, and their bread and butter is news of corporate wrongdoing. They often post stories about what Brian Krebs posts, but a tip from a reader could speed up the process: https://consumerist.com/connect-with-us/
Looks to me like this is a fair description of what Krebs does. But your looking for a concise list that would indicate at a glance what to go for and what to stay away from. I’m sure there are those that are not so afraid of lawsuit that they might publish such a list. I’m sure there are those that might actually be willing to subject themselves to the kind of retaliation from the bad guys that Krebs seems to endure.
Is there any analysis of the code yet detailing what items they’re after? Would be nice to have a quick reference list of things they’re after to be sure if I have one I’ve reset it and can advise friends/family/coworkers on things they might have they should look at.
It’s well and good to tell people generically about default passwords and the need to change them. I find you get a better reaction with, you need to reset your defaults on this device you’re running because it IS being attacked vs it probably is. Why people don’t react, I don’t know, maybe they just htink it’s not their wonderful device they love so much or that their ISP provided. Would be great to see that detail somewhere.
Yes, I plan to publish something along these lines later today.
Outstanding! Thank you very much, can’t wait to see that. I have my suspicions about my cable modem sometimes. I can’t be certain but it sure sounds like that. Odd slowness, reboot and it’s fine. No firmware updates or details about bugs but it’s an older model so I’m near certain this will be in the list. Thanks again!
There are plenty of things I’m concerned about with IoT devices. Take a look at affordable products on Amazon or other larger internet retailer sites. For instance, if you are in the market for an affordable IP camera, and your main concern is finding something of reasonable video quality but don’t want to pay for a well-known brand. Then you settle on an off brand device from China. As you should, you change the default password. However you find out that the password does not allow best practices for passwords. A friend of mine purchased one of these off brand devices from a company name that no one has heard of. And there were less than 20 reviews online for the product. He told me that the password limit is 5 characters and no special characters are allowed. I wasn’t able to find any details on the product manufacturing date and there is no option to deploy a firmware update. Some saving grace is that you can change the default password, but 5 characters limited to only upper and lower case and numbers, that doesn’t make for strong security. Additionally, this friend of mine is not very technically savvy. We decided not to go further with this device, but I’d be interested in knowing what sort of network traffic is routing through the device. I can’t find any specific examples, but have read about hard coded malware being placed into cheap devices like this to call back to an unknown server. If someone isn’t a network person and doesn’t monitor outbound traffic, you might never know what is happening.
My internet provider has been known to notify end users of malware sending callbacks to known malicious IPs, but usually only after a specific threshold has been reached. Something far less intermittent that raises less suspicion is another concern as well.
I thoughts are that there really isn’t a major push from some technology providers to provide reasonable safeguards to their products. Consumers really should push back on manufacturers and demand a better product. Unfortunately when their product doesn’t work as well as intended, they produce a new one and leave the faulty product without updates or support, then your only option is to upgrade.
But where is the IoT going to start leveling off and how much connection and control do we really need in our lives? We’ve got smart light bulbs, thermostats, cameras and security systems, etc. You can now purchase a smart coffee maker to add to your list of IP endpoints in your home. To me this is just another entry point of risk where there is minimal benefit to the consumer. This is more of a novelty.
The consumer really needs to be on guard all the time, do their research and contact the companies regarding their products. But how many of us really do the extra steps to safeguard our homes? You would believe that many more of us would take into account basic safeguards after hearing of all those stories of baby monitor camera’s default passwords not being changed. I believe many of those lesser known companies leave back doors into their products.
All manufacturers should agree that all new firmware should disable the network interface after 5 minutes if default username/password used.
Unfortunately, it could be years before a lot of manufacturers would get around to doing that and there will still be some who won’t.
We have put a small list of tips for network administrators to spot Mirai in their network