Telnet Passwords Leaked For More Than 500,000 Servers, Routers, and IoT Devices (zdnet.com) 60
ZDNet is reporting on a security breach leaking "a massive list of Telnet credentials for more than 515,000 servers, home routers, and IoT (Internet of Things) 'smart' devices."
The list, which was published on a popular hacking forum, includes each device's IP address, along with a username and password for the Telnet service, a remote access protocol that can be used to control devices over the internet... Some devices were located on the networks of known internet service providers (indicating they were either home router or IoT devices), but other devices were located on the networks of major cloud service providers...
According to experts to who ZDNet spoke this week, and a statement from the leaker himself, 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.... To our knowledge, this marks the biggest leak of Telnet passwords known to date.
As ZDNet understands, the list was published online by the maintainer of a DDoS-for-hire (DDoS booter) service... 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.
The list, which was published on a popular hacking forum, includes each device's IP address, along with a username and password for the Telnet service, a remote access protocol that can be used to control devices over the internet... Some devices were located on the networks of known internet service providers (indicating they were either home router or IoT devices), but other devices were located on the networks of major cloud service providers...
According to experts to who ZDNet spoke this week, and a statement from the leaker himself, 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.... To our knowledge, this marks the biggest leak of Telnet passwords known to date.
As ZDNet understands, the list was published online by the maintainer of a DDoS-for-hire (DDoS booter) service... 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.
The 80's want their telnet daemon back (Score:1)
Re: The 80's want their telnet daemon back (Score:4, Funny)
I doubt you have the bandwidth.
Re: (Score:2)
It's not the bandwidth that counts, it's the latency.
Re: (Score:3)
It's not the bandwidth that counts, it's the latency.
Keep telling yourself that.
Uptime wins.
Re: (Score:1)
Seriously, who uses telnet these days?
Companies that are too dumb or too cheap to implement ssh with key only access?
or alternatively 5 fun&geeky things you can do with telnet clients:
https://www.digitalcitizen.lif... [digitalcitizen.life]
Re: (Score:1)
Customers are often too stupid to use something complicated like ssh. They'll just end up misconfiguring something and calling tech support.
Re: (Score:2)
Anyone not knowledgeable enough to disable it on something that has it enabled by default.
Default usernames and passwords need to be outlawed. If you can't take the time to go through a guided setup process on a new device that connects to the internet, you deserve to get 'hacked'. And if you use the same password on everywhere and/or an easy to 'hack' password after all the coverage of the dangers these past 15 or so years, again, you deserve to get 'hacked'. We can cater to the ignorant and stupid only
Re: (Score:1)
Default usernames and passwords need to be outlawed.
https://it.slashdot.org/story/... [slashdot.org]
You read it here first! Latency since Oct 2018 seems about right for Slashdot ;)
The company I work for is scrambling to fix their hard-coded, unchangeable, compiled in passwords in all their software more than 5 years after they marked my first set of security bugs WONTFIX "nobody would ever think of that and it will make the customers life more difficult". It is a thing.
Don't know why I still work there. Wait, I do. Because friends at every other company are telling me the
Re: (Score:3)
IoT makers.
I wish I was kidding.
Re: (Score:1)
Why do you have telnet passwords? (Score:1)
Wtf is the point of putting a password on a telnet connection? It provides pretty much zero security.
Re: (Score:3)
You're confused.
Telnet has no security if the connection packets are snooped. If it is not, or can't be snooped then a password is useful.
On the other hand, if the password is known and that is the only authentication then it doesn't matter if you're running the most secure ssh encryption in the world.
Re: Why do you have telnet passwords? (Score:1)
How is it useful? If you are on a trusted network, then why do you need a password?
Re: Why do you have telnet passwords? (Score:5, Insightful)
What or who is trusted? Maybe the employees aren't 100% trusted.
Common situation in the real world where telnet terminal in thin client access a server and no other devices are allowed on net. The port of the terminal is inside the locked case of the thin client. But, being enterprising trouble maker, let's say you're going to maybe duplicate MAC address and IP settings of a terminal, unplug the other end of the terminal wire in the closet and plug in your snooper. Except we see you on camera doing that and we get port down/up alerts, oops you're busted
Re: (Score:2)
Do you have passwords on screen logins? This is pretty much the same thing.
Re: (Score:2)
Indeed. And, as it turns out, sniffing passwords from the net is basically impossible for most people and organizations, unless they are close to the source or destination of that network connection. Doing this on backbone level is only possible for a few organizations that have enough power to get their devices right into the exchange points or have the expertise or money to sniff directly in the cables, usually underseas.
Re: (Score:2)
But Telnet must arrive "in the clear" so at least one segment of your conversation over telnet will not be encrypted.
Yea, you can hide behind the layer 2 switch fabric and transport the traffic over a VPN when you can't hide, but hey, there is such a thing as in insider threat, the employee who runs the packet sniffer for instance, that you really *should* care about. There is also the hacker who's already inside your network, putting usernames and passwords out on your network just makes their pivot to th
Re: (Score:3)
A lot of equipment comes with it turned on by default. It still runs on most if not all of our Cisco gear although we block inbound telnet from the Internet just to be safe. I have only had one incident with telnet being hacked in the 25 years I have run our ISP and this was back when we were using coax Ethernet, a user had abused their privilege on a game server I let him have root access to and ran a packet sniffer (this wouldn't work now with Ethernet switches). During that time many servers have been co
Re: Why do you have telnet passwords? (Score:2)
Re: (Score:2)
Cisco hasn't shipped any gear with Telnet enabled in almost a decade. It went the way of the default "cisco/cisco" Username/Password (which they *require* you to change if you do any configuration now. If you get a telnet connection now it's because some admin got on the console port and enabled it (against the advice of Cisco and just about any sane network admin).
Re: Why do you have telnet passwords? (Score:2)
Not an issue (Score:3)
Leaked Telnet passwords are not an issue. After all, Telnet is disabled by default and nobody would ever enable it. Right? RIGHT?!
Re: (Score:2)
I have devices with telnet active. I have none where the password could be hacked. Telnet is not the problem here.
Re: (Score:1)
Pretty simple to do (Score:4, Informative)
I estimated about 15 years ago how much effort this would be and the number was surprisingly low, both on the coding and the execution side. This can probably be done in a at most few weeks today with maybe a week of work (depending on how much you have to learn in the process), including the log-in attempts to find the passwords. Scanning the whole IPv4 range for these ports would have been something like 10 days back then (had to be careful to not use too much of the University bandwidth), as estimated form a random 10'000 addresses we actually did scan and immediately disposed the results for after counting.
In short: This is _easy_.
Here's another, # 515,001 (Score:3)
192.168.0.1
Username: admin
Password: admin
Re: (Score:2)
Re:Here's another, # 515,001 (Score:5, Funny)
192.168.0.1
Username: admin
Password: admin
Oh wow, I found the same credentials on 169.254.42.13!
And my luggage!
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Ah,, shit, you got me. How did you do it?
Telnet (Score:2)
Why do so many devices have telnet access in the first place?
Re: (Score:2)
Re: (Score:3)
Why do so many devices have telnet access in the first place?
Modules that basically bridge an ethernet to serial port are very cheap and nearly drop-in devices.
Think of it as the hardware variant of outsourcing.
Doing any more than basic TCP and IP usually needs a more powerful processor than the kHz microcontroller being communicated with through the module.
Those modules do tend to say not to connect them to any network that non-trusted devices or people have access to.
That's for the same reason you should never leave a piece of equipment in a public place where othe
Re:Telnet (Score:5, Informative)
Because microcontrollers or microprocessors have a hard time managing ssh. You can do telnet with a 2 cent, 8 bit microcontroller. ssh requires 32 bit, a bunch of flash, and more RAM than whatever else most embedded devices do.
A typical embedded system with encryption, it is the basic encryption capabilities that drive most of the hardware requirements.
That's why even I use telnet as the remote interface to a lot of my hobby electronics. Of course, in my case these are offline systems with no networking capability and the telnet is over USB serial.
Also, a lot of these devices are intended to be used on a LAN, and the developers don't really feel responsible for your security if you put it on a routeable address. If that is reasonable of them or not depends on the rest of the context, especially when adding security would require more expensive parts.
The only reason I haven't used telnet in a professional setting for 20+ years is that if I'm writing firmware that talks to the world it probably requires X.509 signing anyway. And if it doesn't talk to the world, I don't add debugging crap that does, I stick to JTAG or similar.
Re: (Score:2)
If devices are intended for LAN, they should be safe to work on internet, and have reasonable security. There are very few LANs that are not connected to internet.
Telenet over USB is not the issue here, it is just serial terminal - so that example is irrelevant.
Re: (Score:2)
If devices are intended for LAN, they should be safe to work on internet, and have reasonable security.
I agree, personally, but they're not wrong when they say their device has reasonable security when used according to the instructions. So it isn't realistic to expect products to have security beyond that.
Instead, it is the responsibility of the user to select devices that have the security they want. And they will pay more in most cases.
This is why in a business environment I approve of the practice of having the BOFH institute draconian restrictions on what devices can be connected to the network, where,
Re: (Score:2)
I had the same thought - but then I remembered the networking folks at a client of mine. They telnet to their local switch, then telnet to the next and the next until they get to the one they want to configure. They type in the necessaries, save the changes and then get on with the next job. How the security folks haven't stomped on this is a mystery.
We positively blew one of their minds when we put a cloud router in AWS. He had a steep learning curve to figure out how to SSH to it (I think it was so shocki
Who the f.... (Score:1)
Re: (Score:2)
Re: (Score:2)
Home user addresses are usually not fixed (Score:1)
Re: (Score:2)
I believe a few months is plenty of time to install some malware there which reports the updated IP address to a central server.
May not be a bad thing. (Score:3)
Re: (Score:2)
Switching from telnet to ssh accomplishes absolutely nothing for this type of attack, unless they setup mutual cert based authentication (very unlikely, as most people using ssh today have never even heard of doing this). The hacker here didn't intercept telnet traffic, they just brute forced passwords, which is equally easy to do with ssh as it is with telnet, just change "telnet" to "ssh" in the hacking script.
So, while might be right that some admins will do that and pat themselves on the back for "secur
Wait wait wait... (Score:1)
People are still using Telnet??
Doesn't Telnet send credentials in the clear??
Re: (Score:1)
Re: (Score:2)
Depends you can use telnet-ssl in which case everything is in a SSL tunnel and so no credentials are no in the clear. You could also use a Kerberized version of telnet where authentication is done using Kerberos so again the credentials are not in the clear, though in this case everything in the actual session is so don't log onto anything else using a password.
Telnet service with a password (Score:2)
Telnet service with a password. Wow. That's a true hacker. Finding such odd things on the net.
Re: (Score:1)
I know... Not like using ftp with a username/password. Those telnet suckers...
I remember having arguments with people as late as 2008 about telnet/ssh. "My application won't work." Wouldn't even try until they had to. Guess what? ssh worked just fine.
(Funny... I know ftp is in the clear as well).
Meh (Score:1)