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 https://isc.sans.edu/diary.html?storyid=7393, 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 ==> http://isc.sans.edu/port.html?port=23

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 cert.org team has formally recommended using something other then plain text authentication due to potential network monitoring attacks ( http://www.cert.org/advisories/CA-1994-01.html ). 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