Last Updated: 2011-08-24 13:28:00 UTC
by Rob VandenBrink (Version: 1)
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
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.
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
Last Updated: 2011-08-24 09:52:00 UTC
by Rob VandenBrink (Version: 1)
Yesterday's earthquake (centered in Virginia), along with Monday night's earthquake (centered in Colorado), got me to thinking about disaster preparedness (again).
Lots of IT groups would like to do more in the area of BCP (Business Continuity Planning), but can't get budget due to a management philosophy of "disasters happen elsewhere". For many of my clients in this situation, these earthquakes are nice "wedge" to demonstrate that disasters do in fact happen close to home - everyone had a bit of a pause today when the buildings, and us inside them, swayed back and forth for a minute.
If you have a good DR (Disaster Recovery Plan) at work, now might be a good time to dust it off to make sure everything still works, while this is still fresh in everyone's mind. Make sure that your plan truly reflects the needs of your organization. The IT side of DR is relatively simple - a second location, some servers, replication (often SAN or virtualization based), and you're getting there. Oh - and failing back to the production site is important (and often overlooked) as well.
I've seen DR plans go down in flames, where the IT group comes through 100%, all the backup servers are running, but for one reason or another, the company can't do business. Think things like - where does my main 1-800 telephone number go? How will we ship? How will we receive? There are hundreds of non-IT details that go into a working organization and should go into a good BCP strategy.
Don't neglect DR planning at home as well, there are lots of good references on how to kit your house out for common disasters, but I particularly like the CDC guide on surviving the Zombie Apocalypse ( http://blogs.cdc.gov/publichealthmatters/2011/05/preparedness-101-zombie-apocalypse/ ). If you can survive that, I'm thinking you're good for anything.
The whole DR topic is seeing real interest due to recent events - please, use our comment form and let us know if the recent earthquakes have shaken things up in your organization, if you are now stirred to consider changes in Disaster Preparedness at work or at home?
Rob VandenBrink Metafore