It is amazing that this sort of thing can still happen:
…the list was compiled by scanning the entire internet for devices that were exposing their Telnet port. The hacker then tried using (1) factory-set default usernames and passwords, or (2) custom, but easy-to-guess password combinations.
Telnet? Default passwords? In 2020?
We have a long way to go to secure the IoT.
EDITED TO ADD (7/14): Apologies, but I previously blogged this story in January.
Jeff Hall • July 8, 2020 7:20 AM
So, we’re talking half a million occurrences of ‘123456’? Sorry, could not resist.
Eligius • July 8, 2020 7:34 AM
While this is somewhat usurprising for regular readers of this blog, I wonder how many of them are actual servers (I’d be genuinely amazed if there’s any case), how many of them are routers (on most domestic devices they are administered by the ISP and in some cases the subscriber has little to no control), and how many of them are IoT devices (and for these we should discern between legacy or old devices and ones recently manufactured).
Depending on how are these detailed figures, this will be more or less worrysome.
Eligius • July 8, 2020 7:38 AM
By the way, this is a repeated story:
https://www.schneier.com/blog/archives/2020/01/half_a_million_.html
chris • July 8, 2020 7:59 AM
I read another article on ZDNet this week about how home routers were never patched. And, like this article, it was a little sensational (“WE’RE ALL GONNA GET HACKED!”) with no advice whatsoever about what to do about the problem. In the router story, the advice was, presumably, to buy a new router every so often b which — also presumably — benefits ZDNet’s product review traffic and advertisers.
In this story, there’s no suggestion to disable Telnet, disable that port or even — at the bare minimum — change the default password. No one quoted in the article takes the position that Telnet should be disabled or no longer included in modern IoT products or that we should demand that vendors actually consider security in their products. And here’s a nice buried lede:
“When asked why he published such a massive list of ‘bots,’ the leaker said he upgraded his DDoS service from working on top of IoT botnets to a new model that relies on renting high-output servers from cloud service providers.”
So, in other words, some cloud service providers aren’t preventing DDoS attacks from originating from their data centers and, it seems, anyone can simply resell attacks as a service. I think that’s a bigger problem than leaving Telnet enabled by default.
Vesselin Bontchev • July 8, 2020 8:01 AM
I run a Telnet honeypot. I haven’t seen this list but I’m sure its IP address appears there. (It will allow logging in with almost any password and the username “root”.) It is attacked on average more often than 2 times per second.
Basically, if you connect an out-of-the-box Telnet-capable IoT, it will be compromised much faster than you can change its default password.
The report for the month of April from our honeypot can be found here; the Telnet-related stuff is at the very top, followed by data from our SMB, ADB, and RDP honeypots.
I’d wager one way to diminish this threat would be software liability laws.
Sticky gas pedal? Auto manufacturer recall!
IOT without security? On your own.
The subscription-based software-as-service is about profit, but also about manufacturers making a visible move to alter how we think about software under the UCC.
Clive Robinson • July 8, 2020 4:53 PM
@ chris, ALL,
In this story, there’s no suggestion to disable Telnet, disable that port or even — at the bare minimum — change the default password.
The thing is that many of these devices especialy routers are of a very similar design. The reason is that they tend to use System on a Chip (SoC) silicon, and the manufacturers Tech Sales guys software. Basically all they do is add a few changes that in the main are cosmetic or “style over substance”.
As many know there are Open Source Projects for such SoC based devices. At one point they were very desirable, because they alowed the RF side to be used “out of band” in some cases in Amature Radio bands and in some cases on frequencies reserved for satellites.
The result was the FCC started throwing their weight around in their usuall “bull in a china shop” style. So rather than achieve anthing particularly constructive they just caused FUD and a resulting upset in the market place.
One result of the FCC stupidity was that manufacturers of such devices sensing problems elected to lock down their devices, not just at the RF level but overall. The result was devices that could not be upgraded even if you wanted to do something like disable telnet or upgrade the kernel against new attacks…
Some manufacturers after having their own inhouse issues on the production line and with stock control in the supply chain have for their own reasons gone back to being able to upgrade everytging.
Some might be surprised at just what has been achieved by Amature Radio enthusiasts with such equipment. Have a look at AREDN projects,
@ ALL,
So realy the only reason for no security upgrades on these devices is the lack of will.
If people see a reason to upgrade to repurpose etc, then the Open Sorce community can step in, often producing much enhanced products with greater reliability and availability.
Whilst some manufacturers are happy to “not notice” as we know with the likes of John Deere Tractors, some reach for the DMCA and a poisoned nest of lawyers.
The mentality behind such people is in effect sociopathic and the only way to deal with them is effectively to kill them off, by not buying such products.
Whilst this may happen in the industrial sector, I can not see it happening in the consumer sector, thus that ever present race for the bottom to squease out the last fraction of a dime out of those who buy their products will continue apace.
With the result that the industrial and consumer markets will part company with prices in the industrial sector rising and those in the consumer sector dropping. Obviously there is only so far the price can drop before something has to give.
Thus I predict even less security or ability to add it yourself will be the first area to get targeted, then other areas of software quality along with ever cheaper less reliable components, especially the likes of electrolytic capacitors.
Thus I expect the “Mean Time To Fail” (MTTF) of consumer IoT to drop below that of the legal requirment for warranty, whilst the “Mean Time To Repair” (MTTR) to rise at an ever faster rate.
As some know “availability” is based on the MTTF and MTTR such that it is effectively MTTF/(MTTF + MTTR) so a falling MTTF is detrimental but a rising MTTR even more so.
Steve • July 8, 2020 5:07 PM
Note the dateline on the piece: January 19, 2020.
This story, while “shocking” (for those still able to be shocked by this sort of thing), is over six months old.
JC • July 8, 2020 5:10 PM
I keep thinking an easy fix would be to limit all IOT devices to only operate on RFC1918 addresses. Lots of challenges updating the firmware of the junk that’s already out there, but could at least improve
indiansummerlinen • July 8, 2020 5:26 PM
Hand Embroidered Linens | luxury bedding nz | Cot Bedding Sheets NZ: Indian Summer Linen: Find the finest handcrafted custom linen work, cotton bedding set, and cot sheets in NZ at Indian Summer Linen. We offer a wide variety of products that will complete your linen collection.
Ian Fitzgerald • July 8, 2020 8:53 PM
There is really no distinguishing here the difference between consumer IOT and industrial IOT. If industrial, it truly is mind-boggling how companies can’t run simple vulnerability scans on these devices and close the loops, or even close internet access to many of them all together. At home, this is really not surprising. With our homes beginning to have more IOT devices connected that a small company, and with users never upgrading or patching their IOT, or routers since the first day they bought them, nor having any idea what Telnet even is, the end result is what you are seeing today.
SpaceLifeForm • July 8, 2020 9:34 PM
@ ALL
It is not that difficult.
You just need to understand firewalls, routing, and subnets.
Simple, right?
Dave • July 9, 2020 12:50 AM
For IoT it’s not surprising, as the joke goes “the S in IoT stands for security”, but it’s both surprising and disappointing that routers and servers are still set up this way, I would have thought SSH killed use of telnet twenty years ago.
Peter A. • July 9, 2020 5:46 AM
I still keep telnet access to one of my systems, with one-time passwords set up, just in case I cannot use ssh for some reason. It’s on a non-standard port to limit the volume of bad login attempt log records a bit. I’ve used it a couple of times in the somewhat distant past, to get out of some firewalled environments (they’d block ssh, but allow outgoing telnet), but I can’t remember exactly when. I haven’t used it for years.
Hey, I’ve actually fished the list of OTPs out of my wallet now, and it’s barely readable today. And I seem to have forgotten the fixed passphrase part. Hmmm, should I generate a new OTP list or drop this access altogether? I need to think about it.
Petre Peter • July 9, 2020 6:39 AM
But we want devices that work securely out of the box. How can we make that happen without default passwords?
SpaceLifeForm • July 9, 2020 11:20 PM
@ Clive
As some know “availability” is based on the MTTF
Quick inventory.
May have lost one somewhere, and I know one needs to be un-bricked…
Yep, 5 WRT54G that I can see at the moment.
They are not just sitting on the shelf.
Pretty good MTTF.
Clive Robinson • July 10, 2020 2:39 AM
@ SpaceLifeForm,
Yep, 5 WRT54G that I can see at the moment.
Are they the Version 2 ones with the “Rugby Goal Post antennas”?
They originals are nearly two decades old venerable old beasts, and the early versions usefully had removable antennas, so you could put them in a weather proof box, add a couple of high gain antennas and cover a whole camp site.
Saddly the FCC stomped it’s big old political boots, so later versions just have a bit of wire poked up what could be the empty shell of a cheep ball point pen 😛
Mind you most –but not all– can be “re-flashed” with “OpenWrt” or similar Open Source Linux based software, which in theory alows you to “roll your own” to get a more secure and / or adaptable to your needs solution.
I’ve been thinking about modding one of the newer “Mobile Broadband” devices to do some “fun stuff”. The trouble is even with the COVID-Lockdown there never gets to be enough time to do things you want to do rather than have to do, and my creaky old body is not upto pulling “all nighters” and putting in a full day afterwards 🙁
Anon-kun • July 10, 2020 4:20 PM
Linux is ill-suited for the task, to begin with.
Static scenarios with seL4 would make much more sense. But then they’d need to hire actual experts, instead of unpaid interns.
Clive Robinson • July 10, 2020 5:20 PM
@ Anon-kun,
Static scenarios with seL4 would make much more sense.
There are all sorts of resource issues with seL4 that do not make it a “good fit” for modern SoC devices.
For various reasons MINIX3 would peobably be a better choice, and from what I understand it runs on more machines than Microsoft Win10 does…
alliancemd.us • July 10, 2020 6:51 PM
Suboxone Clinic Lansing | Munster | Schererville: Alliance MD’s suboxone clinic uses time-tested techniques coupled with cutting edge technology to provide its patients comprehensive suboxone treatment. Contact us for more detail on how to enroll.
SpaceLifeForm • July 11, 2020 1:46 AM
@ Clive
Are they the Version 2 ones with the “Rugby Goal Post antennas”?
You betcha! Cheers!
lurker • July 11, 2020 2:02 AM
@PetrePeter
But we want devices that work securely out of the box. How can we make that happen without default passwords?
Is that an oxymoron: secure otb with default passwords?
Default passwords aren’t the problem. It’s simple for you or I to connect the device to a computer with no internet connection, then do the setting up. Can Joe Blow do this? Security is too hard for the average user. Purchase of IoT devices should require proof of competence by the purchaser. After all IoT is not protected by the Second Amendment.
Clive Robinson • July 11, 2020 2:34 AM
@ Lurker, Petre Peter, ALL,
It’s simple for you or I to connect the device to a computer with no internet connection, then do the setting up.
When it comes to the setting of secure passwords, the factory can actually do a better job than most people including most technically oriented staff at large organisations with good ICT budgets.
I’ve mentioned this before as I used to be involved with the design of FMCE and the setting up of manufacturing lines for 250K plus runs on product that had to have unique digital ID’s. I had no trouble doing it last century so a quater of a century later I see no reason why manufacturers do not do it.
All the manufacturer has to do is “flash the passwords” in exactly the same way they flash the device software ROMs. The difference being they include a different random password file with each device and put a printed tear of lable on the device with them printed on.
This leaves the notion of “Random” and “unique” for the password generation. There are two basic ways you can do this. The easy but incorect way is to use a counter and ryptographic algorithm, the counter gives you the electronic serial number and it’s encrypted form gives you the base for generating the password string from. The result is certainly unique random looking passwords, unfortunately if the encryption key becomes known by others then so do all the passwords.
The correct way to do it is to build a database with a TRNG. Each TRNG output is “random” but it is not of necessity unique. To make it unique, you compare each TRNG output it to all the previous outputs, if it matches any you simply disgard it and try again. As long as your random number range is more than ten times the maximum number of units you ever need to manufacture then the process will be efficient enough.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Allen • July 8, 2020 7:14 AM
I saw a good video from Bradley Spengler released this week titled “10 years of linux security”. It is on youtube. Its audience is Linux kernel developers, so it is highly technical and down in the details of kernel development, but a key takeaway is that Linux now has long term support kernels (more than 6 years) designed for IOT devices with almost no plan for security updates. Essentially, the maintainers are admitting security fixes won’t be back ported to IOT products.