America's Got Telnet !

Published: 2011-08-24
Last Updated: 2011-08-24 13:28:00 UTC
by Rob VandenBrink (Version: 1)
5 comment(s)

Sorry for the play on words, but really, we do.

I just finished a security assessment engagement, and the pentest part was one of my shortest in history. Part of the morning procedure for the helpdesk was to login to their "corporate critical infrastructure" gear and verify status and history against a daily checklist. This included all the usual suspects - Backups, critical servers, power, HVAC (Heating, Ventilation, AC), generator, the works. Good so far, right? Keep reading .... The client had a mix of some new and some older UPS Controllers (smart PDUs actually), the older ones only supported telnet and http (no ssh or https). Because this gear was "doing the job", the request to upgrade to the latest version of the gear (which *does* support encryption) was put off until the next budget year (2013).

Part of my internal pentest was to sniff for "the easy stuff" - ftp, telnet and the like (using a man-in-the-middle attack against the user VLAN's default router). Starting with this, especially in smaller environments, is almost a sure thing. I caught a telnet login to the UPS PDU's within 10 minutes of starting the session - and guess what? To keep things easy, they had used the same password for:

UPS PDUs and controllers
Domain Administrator
SQL Server SA
Firewall (vty access and enable)
Routers and Switches (vty access and enable)

So, for the want of 5K worth of upgraded hardware, all of the internal infrastructure was compromised - I had a first draft of the pentest section of the report done before my coffee was finished.


We've done a number of diaries on telnet over the years, notably, but this message bears repeating, we see telnet over and over (and over), in big companies, small companies, financial, public sector, healthcare, whatever.

Scans for open telnet services on the public internet have their highs and lows, but even the low values remain consistently high ==>

Just re-iterate - compromising telnet is as easy as looking for it.  It's not something that should be used in a modern IT group.  And yes, Microsoft did us all a great service when they removed it from the default install in Windows 7.


Update 1

I can't believe that I missed this in the initial story, but mainframes and mini computers almost always have telnet enabled.  Even if the clients are mostly using ssh or stelnet, telnet is almost always still running as a service on the host, and you'll still find clients connecting to it.  In many companies, the mainframe or the p-series or i-series box (or the VMS box in some cases) stores "the crown jewels" - the financial systems and all the customer information.  Yet we continue to see these systems as the least protected in many organizations.

(and yes, this graphic is a telnet session)

Important Note - if you plan to run a Man in the Middle (MITM) attack against a busy router, be VERY SURE that you have the horsepower to do this. If you should run out of CPU in this process, you will have ARP Poisoned critical servers in the client's datacenter, potentially making them unreachable by clients. This process can often take up to 4 hours to clear up on it's own (the default ARP timer on many routers and firewalls), depending on the gear. Also, be VERY SURE that you terminate the MITM gracefully when the process is complete (same risk here).

Note 2 - Since 1994, the team has formally recommended using something other then plain text authentication due to potential network monitoring attacks ( ). Disabling telnet (and rlogin, and any clear text authentication for admin) is a key recommendation in just about every hardening guide out there. FTP is another nice target - if you have an FTP server, do not allow any interactive user accounts to start an FTP session, as the credentials are sent in the clear. Similarly, do not host or transfer any sensitive information using FTP. If you plan to transfer any sensitive information over a public internet, consider using strong encryption (commonly implemented via FTPS, SFTP, HTTPS or SCP).



Rob VandenBrink Metafore

5 comment(s)


as an IT auditor I always saw the same password for ssh Cisco access as the telnet password for older Cisco equipment that couldn't support ssh. Same with private comm. strings but that is another story. :-)
Hi, you mention to MITM the busy router... did you mean you setup a SPAN in one of the Ethernet ports in a router? Or you setup ettercap then you choose the router as the victim which usually is the gateway (i.e. Your setup is your connected in LAN without any admin access to any network devices.
The MITM attack was done using ARP poisoning. In this case using Ettercap, but CAIN would have also worked (and was on the agenda for later).

A previous diary shows CAIN in action, compromising RDP ==>
One of your pieces of advice could be that if you have to use telnet, use a unique password that isn't used anywhere else. Of course, that is sound advice for all authentication, but in your assessment it would have made a huge difference in the level of access you were able to achieve.
I was with you until you said "Microsoft did us all a great service when they removed it from the default install in Windows 7."

No, they sure didn't. They removed a valuable troubleshooting tool from the default install; a common use of telnet is to have a user connect to a mail server on port 25 "using telnet", to isolate their issue.

The IT groups should know better and aren't going to be able to use this non-defaultness as an excuse for updating the 5k PDUs against stubborn folks who'll say... "No problem, just open PuTTy, and use that for telnetting".

Many of the small orgs presented with this situation, may even start looking at ways to prevent or detect VLAN MITMs rather than making significant spends on equipment upgrades.

Diary Archives