Telnet Vulnerabilities
#1
Posted 11 January 2012 - 11:38 AM
#2
Posted 11 January 2012 - 05:32 PM
Can anyone explain to me why Telnet is so vulnerable besides the fact that it's so old? My school has decided that for it's Linux/Unix class students should have to Telnet into a local server, instead of installing Linux on a desktop. This is understandable, but not very safe in my opinion. I've met the college's Network Admin before and he seems like an alright guy, so hopefully I'll be able to talk him into letting me pentest the connection. I can pretty much guess what tools I'd use to do it, I'm just wondering why the service is so vulnerable. Anyone care to elaborate?
Im not a professional pen tester, but from my understanding, the telnet stack is quite secure. It's my understanding that it's not secure because of its design, but rather secure from years of use and audits and revisions in the stack.
Because it was a widely used protocol the stack was hardened. I believe you'd be hard pressed to find exploitable vulns in telnet.
What is NOT secure about it is its lack of encryption. SSH is encrypted and has taken over much of telnets usage. (Edit: also, lack of authentication)
In some ways the setup that your school is having you use is more secure in some ways than a full blown desktop environment. Many cannot handle privileged root access of a linux desktop. Most likely the man-hours put into fixing the operating systems that people break would outweigh the cost of the machines.
Setting up telnet shells on a *nix server is how many of us started our journeys. A *nix shell can be quite powerful depending on how many resources and tools you have access to.
EDIT:
fire up wireshark. After capturing everyones passwords you're sure to show them that ssh is better.
Edited by Afterm4th, 11 January 2012 - 11:19 PM.
#3
Posted 12 January 2012 - 12:48 AM
Telnet, as Afterm4th stated, is not encrypted, nor does it use a challenge/response mechanism like SMB. When a user logs in, their passwd is sent in the clear, The only thing the telnet protocol does to obscure it is send each char of the passwd in a separate packet. Tools like Ace Password Sniffer, Cain & Abel, and dsniff in Unix are made to sniff the telnet packets, and show them in a user friendly way.
#4
Posted 12 January 2012 - 02:04 AM
the only advantage of telnet over SSH is 1) easier to setup (of course now every major distro has an Open SSH package, tho), and two: low overhead on the system. I worked at an ISP in the 90's and we ran a Pentium III storing the users home directories and provided their shell account access. If all our customers logged on using SSH it would really drain the system resources. All root access was done over SSH, tho.
Telnet, as Afterm4th stated, is not encrypted, nor does it use a challenge/response mechanism like SMB. When a user logs in, their passwd is sent in the clear, The only thing the telnet protocol does to obscure it is send each char of the passwd in a separate packet. Tools like Ace Password Sniffer, Cain & Abel, and dsniff in Unix are made to sniff the telnet packets, and show them in a user friendly way.
I havent looked at the RFCs, but I thought SSH was supposed to be low overhead because it uses compression?
#5
Posted 12 January 2012 - 03:30 AM
Exactly. I was referring to the local system resources, not bandwidth. IDK. I once asked the admin there why we did not use SSH for all the customers. He was also the owner, and stated that SSH might require upgrading the CPU. Besides shells the box also hosted a RADIUS service.
the only advantage of telnet over SSH is 1) easier to setup (of course now every major distro has an Open SSH package, tho), and two: low overhead on the system. I worked at an ISP in the 90's and we ran a Pentium III storing the users home directories and provided their shell account access. If all our customers logged on using SSH it would really drain the system resources. All root access was done over SSH, tho.
Telnet, as Afterm4th stated, is not encrypted, nor does it use a challenge/response mechanism like SMB. When a user logs in, their passwd is sent in the clear, The only thing the telnet protocol does to obscure it is send each char of the passwd in a separate packet. Tools like Ace Password Sniffer, Cain & Abel, and dsniff in Unix are made to sniff the telnet packets, and show them in a user friendly way.
I havent looked at the RFCs, but I thought SSH was supposed to be low overhead because it uses compression?
This was about the time when we were reading articles of AMD releasing a 1Ghz CPU in the near future. It might not of even had a PIII.
EDIT: I'm thinking a PIII came in speeds of 300Mhz, 350Mhz, and 400Mhz. So, the box might have had a an AMD K6 at best. It ran Linux w/ no GUI.
Edited by tekio, 12 January 2012 - 03:36 AM.
#6
Posted 12 January 2012 - 05:12 AM
As mentioned by Afterm4th, the telnet stack is pretty hardened. However there are a few vulns which exist such as the one released in 2007 for solaris 10 when sun reused an old branch of code and ressurected a long dead bug http://www.securityf...bid/22512/info. The most important part of any pen test is the recon and understanding your target.
#7
Posted 16 January 2012 - 03:54 PM
I shudder in fear when I see a company using telnet to administer routers the public internet. And it happens far far too often.
BinRev is hosted by the great people at Lunarpages!













