Cisco Fixes Three-Year-Old Telnet Flaw In Security Appliances

Trailrunner7 writes "There is a severe remote code execution vulnerability in a number of Cisco's security appliances, a bug that was first disclosed nearly three years ago. The vulnerability is in Telnet and there has been a Metasploit module available to exploit it for years. The FreeBSD Project first disclosed the vulnerability in telnet in December 2011 and it was widely publicized at the time. Recently, Glafkos Charalambous, a security researcher, discovered that the bug was still present in several of Cisco's security boxes, including the Web Security Appliance, Email Security Appliance and Content Security Management Appliance. The vulnerability is in the AsyncOS software in those appliances and affects all versions of the products." At long last, though, as the article points out, "Cisco has released a patched version of the AsyncOS software to address the vulnerability and also has recommended some workarounds for customers."

Comments

Security + Telnet

[MightyYar]

Security + Telnet = My Brain Hurts

Re:Security + Telnet

[3.5 stripes]

Yeah, any sort of security guidelines should have at the top, in the largest boldest letters possible, DO NOT USE TELNET.

Re:Security + Telnet

[silas_moeckel]

I use telnet plenty great for connecting to a tcp port and debugging. It's a horrid thing to run as a service and allow people to login etc.

Re:Security + Telnet

[basketcase]

Use netcat (aka nc) for that. It works just as well and you can just ^C to get out of it.

Re:Security + Telnet

[CaptnZilog]

I use telnet plenty great for connecting to a tcp port and debugging. It's a horrid thing to run as a service and allow people to login etc.

Yeah, the client comes in handy at times to connect to port 80 and 'handcraft' a http request to see a response, etc... but running a telnet server/service on the machine? Especially on a "security" device?!?!? C'mon... that's just ludicrous in all kinds of ways.

Re:Security + Telnet

[TWX]

Depends on how the network is VLANned. I agree, it's not optimal for certain, but in cases where the management team for the devices have one VLAN for just themselves trunked to them, and where they use a common set of credentials to manage (ie, no TACACS/Radius) then it's not really any less secure.

Admittedly if someone makes a mistake and puts the wrong user on that VLAN, or if they need to get to the devices from elsewhere then they may have to traverse the network before getting to that VLAN, so there are issues. I wouldn't use Telnet anymore either if it can be avoided.

Re:Security + Telnet

[bobbied]

Security + Telnet = My Brain Hurts

It should hurt..

However, if memory serves, I think that Cisco provides SSH access and allows you to disable telnet. Even then, suggested practice was to put all your network hardware consoles on a private VLAN and firewall it from general access... So it's understandable that it took some time to fix this given there are multiple work arounds.

Re:Security + Telnet

[camperdave]

Oh? I was unaware that Cisco equipment came with netcat.

Re:Security + Telnet

[sunderland56]

I use telnet plenty great for connecting to a tcp port and debugging.

SSH be plenty greater for connecting to TCP ports and not security problem.

Re:Security + Telnet

[basketcase]

This is about talking to Cisco not from Cisco.

Re:Security + Telnet

[wonkey_monkey]

SSH is for securely connecting to SSH servers. It's not useful, and certainly not "secure", for low level debugging of TCP connections.

Re:Security + Telnet

[Anonymous Coward]

fwiw (I work at cisco) there has been a long-standing bug in sshv2 on most cisco boxes since the heartbleed bug. took me quite a while to find what the problem was in turning on ssh2. ssh1 was easy, but I needed v2 (netconf requires v2, for example).

turns out, openssl was fixed on linux but not quite fixed (right) on cisco. short answer: you have to run ssh -v2 with a command line 'mess' (or edit a .ssh/config file) to reorder the key exchange listing. if you move some of the kex stuff ahead of others, ssh will work to cisco boxes. if not, you get a 'diffie hellman error message' on the system log and it means nothing to 99% of the people out there (including me).

you'd think that cisco would test their boxes with linux ssh client, being the most common ssh client. but for some reason, since april or may (when HB came out) cisco has not truly tested by using a simple xterm on linux and ssh'ing to their box. the fix is in their source tree but has not made its way to many of the product builds (I know this for a fact, seeing the internal emails and questions by employees).

pretty shameful. ssh'ing to a router should be trivial and common, but try setting it up on a modern cisco box with patched linux and you'll find all kinds of issues with that KEX bullshit.

Re:Security + Telnet

[jandrese]

Often times you have to do both, thanks to security policies that prevent user machines from connecting directly with routers/switches. The admin jumps on the box with a serial cable and uses telnet from there to talk to the other equipment.

Re:Security + Telnet

[sunderland56]

SSH is for securely connecting to SSH servers. It's not useful, and certainly not "secure", for low level debugging of TCP connections.

Were you listening to your iPod? Because you missed the loud whooshing sound.

Re:Security + Telnet

[alex67500]

Hang on... SSL and SSH are not the same! Heartbleed affected OpenSSL!

fwiw (I work at cisco)

In HR? Comms?

Re:Security + Telnet

[Anonymous Coward]

WOW, sorry but you can get many free RADIUS options. There is no excuse for shared creds or using telnet for any access to devices. EVER.

This is why Target and others got breached, poor security models.......

Re:Security + Telnet

[Anonymous Coward]

Use netcat (aka nc) for that. It works just as well and you can just ^C to get out of it.

You mean typing "^]close" isn't blindingly obvious and intuitive?

Re:Security + Telnet

[phantomfive]

Telnet is literally worse than requiring no password for log in.

Re:Security + Telnet

[wonkey_monkey]

If you wanted to people to know you were kidding, you'd have to make it at least 300% more dumberer than that!

Re:Security + Telnet

[AchilleTalon]

The point is: Do not run telnetd on a security device.

Running a telnet client to check a port/connection has not the same implications as using a telnet session to manage a security device.

Re:Security + Telnet

[Anonymous Coward]

Hrm, who do you work for, so I ensure I avoid purchasing any services or goods from your company........

Re:Security + Telnet

[silas_moeckel]

Not really less secure??? How many vulnerability's have there been to inject frames into vlans, Turn access ports into trunks often with the default trunk everything.

Re:Security + Telnet

[Mister Liberty]

You sig enthralls me.
To en tomaten tomaten tomaten to vrat
To en tom aten tomaten tom at en to vrat.
(To and Tom ate tomatoes, Tom ate and To devoured).
(Google Translate: 'To and ate tomatoes tom tom ate and ate to' which is just pathetic).

Re:Security + Telnet

[Anonymous Coward]

WTH, Don't know how to implement ACLs on the VTYs?

I only have '1' switch left that only works with telnet anyways, the rest are done with SSH (and even the telnet one has an ACL to the VTY interfaces restricted to a very few and well isolated VLANs/Subnets)

Often times you have to do both, thanks to security policies that "prevent user machines from connecting directly with routers/switches."

Well that's one way to eliminate problems on the network, don't let users connect at all. (there's only problems when they're around anyway)

Thanks, you just came up with the ultimate, 100% way to eliminate all network security problems. (way better than eliminating users that cause problems and less messy.)

Re:Security + Telnet

[MightyYar]

I lifted it from "The ABC Book" by Dr. Seuss.

Re:Security + Telnet

[jandrese]

Connecting to a device and forwarding packets through it are two different things. It's sensible to have a policy that disallows most users from attempting to ssh to the router's management interface. Often they're on completely different VLANs. It can cause a problem however when the managed connection between the VLANs has an issue and people need to get in there to modify the router settings.

Thank Goodness!

[linuxrunner]

I've been waiting for this fix so I can finally drop SSH

Telnet

[ledow]

Is it just me that wasn't even aware that telnet had an encrypted mode (let alone a horribly-broken one)?

Not been an issue as I always switch it off unless the device is entirely in-house (and, there, someone sniffing the packets is much more of a problem than the fact they might end up with a device password by doing so).

Honestly, we just need to kill this "protocol".

Re:Telnet

[oodaloop]

Is it just me that wasn't even aware that telnet had an encrypted mode

I just called it SSH.

Re:Telnet

[Anonymous Coward]

There is even a kerberized telnet for a long time, however still no advantage over ssh which is also kerberized. Telnet should really die once and for all.

The advantage was time. It was there before ssh. But nobody bothered to set up infrastructure and with ssh kerberos is optional. So it works for the lone desktop linux coder and for complex networks with central kerberos auth.

The funny about Cisco...

[__aaclcg7560]

When I worked at Cisco for nine months as a contractor last year, everyone used telnet to access network devices under development. My boss explained to me that 1) these were default passwords that everyone on the team knew, and 2) the development VLAN is secured from outsiders. That makes sense on one level, but using telnet is a bad habit one shouldn't get into.

Re:The funny about Cisco...

[bobbied]

TELNET is just the default way to access the equipment. It comes out of the box that way (OK, not really but it's the default way to set up). Think of it as a legacy thing.

There is nothing wrong with using TELNET on a private network but today we understand that security is better served using SSH for this functionality. However, in some environments, legacy dies hard because TELNET is not really that much of a security risk if you have good control over who accesses your network.

Sharing passwords and logins may seem to be a problem too, but again, there can be times when the costs of managing all the necessary accounts out weighs the risks. If you have positive controls on who accesses your network, that may be enough, for you.

Of course, the level of acceptable risk can vary between applications and companies. For your network, what Cisco does in their lab may be totally inadequate on many levels, or it may be overkill having to remember the "cisco" user password. It all depends on what risk is acceptable and what isn't to you.

Re:The funny about Cisco...

[DarkOx]

here is nothing wrong with using TELNET on a private network but today we understand that security is better served using SSH for this functionality. However, in some environments, legacy dies hard because TELNET is not really that much of a security risk if you have good control over who accesses your network.

There is nothing right with it! SSH is not an overhead concern for any contemporary device. Even if the only people with access to the networks the management services accept connections from all have access you still have a problem. If there have been credentials running around in the clear we don't really know / can't prove who has been using them. Also it leaves the door open for MITM possiblities where content is injected. TACS logs show Bob issued the "write erase" but we can't really say it wasn't Jim using Bob's account in one way or another. Lack of attribution is a problem; even in authorization might not be.

Really there is no real world case where cryptography or authentication make sense without there other. Cryptography might not be encryption of the content; it could be something like a digital signature that just provides continuing authenticity and message integrity. Security: Authentication/Authorization/Availability/Integrity (in no particular order).

Re:The funny about Cisco...

[Anonymous Coward]

Telnet is NOT the default way to access AsyncOS systems (ie, the IronPort appliances). In fact, it's off by default, and it would be extremely rare that anyone would ever turn it on which is why this took 3 years to be found.

I worked for Cisco/IronPort for many years, and I don't ever recall anyone having telnet enabled - or even anyone wanting to turn it on.

Re:The funny about Cisco...

[bobbied]

Don't misunderstand me, I'm not advocating TELNET. I'm just not ready to condemn someone for using it for legacy reasons in situations where security is not a huge concern.

Security is really "risk management". This means that you must weigh the implementation costs and consider the risks. Remember that the ONLY secure system is one that's powered off and not plugged in. And then, it's only as secure as the physical security makes it.

In a closed network, like in a development lab, I can imagine that there isn't much risk and running SSH may not be worth bucking the legacy. Who really cares? They are likely using TFTP to load test software images and test configurations anyway, TELNET is the least of their worries if they have a network security concern.

Of course YOUR situation is likely different, as is your assessment of risks and mitigation. Where I would recommend using SSH under almost all situations too, I'm not gong to dump on somebody who chooses to take the risk of using TELNET, especially if they really understand the risks as I'm SURE Cisco does. They decided that TELNET fits their costs/risks assessments, and it's their call.

Three years????

[gstoddart]

How does a major vendor like Cisco take 3+ years to fix a known security hole?

Did they just sit on it? Or were they hoping nobody would notice?

That makes no sense to me at all.

Re:Three years????

[__aaclcg7560]

From what I can tell in recent times, Cisco lays off 10% of their workforce in America and hires 10% of their workforce from India. The development teams are squeezed in the middle as experienced people are let go and new people are still learning the ropes. It's a rotten business model but apporved by Wall Street.

Re:Three years????

[bobbied]

How does a major vendor like Cisco take 3+ years to fix a known security hole?

Work around existed, nobody ever fielded in a configuration that was subject to the problem, so this was LOW risk. If you are working more important issues, LOW risk stuff gets to wait.

That's how.

Telnet has its place

[davidwr]

However, being accessible by even a single machine you don't trust is not one of those places.

A place where it is helpful: Isolated networks such as in a test lab that you control. The fact that it is NOT encrypted can be a great asset in debugging if you are looking at packet-capture logs. Sure, there are other solutions but if telnet/telnetd are readily available and they get the job done without causing any bad side-effects in a particular use case why not use them?

Re:Telnet has its place

[DarkOx]

Because its not what your customers are really going to use! Better to exercise a real world configuration in the lab. Add 'null' cipher to ssh if you need this and make the command to enable it something obviously out of place for normal operations like:

DangerDoNotUse_EnableSSH_NULL_CIPHER
DangerDoNotUse_EnableSSH_NULL_MAC

Workaround list

[Anonymous Coward]

Workarounds:

1) Don't buy network appliances from companies that don't patch them quickly after vulnerabilities are discovered
2) See 1).

Re:Workaround list

[__aaclcg7560]

3) No ever got fired for buying Cisco.

Re:Workaround list

[Anonymous Coward]

You've obviously never seen somebody go over budget.

Better late than never?

[xanthines-R-yummy]

Yes, sooner would have been better but at least they got around to fixing it, right?

A vulnerability IN Telnet ?

[alexhs]

There are vulnerabilities IN Telnet ?
And I thought Telnet WAS a vulnerability...
It's vulnerabilities all the way down, I guess.

Re:A vulnerability IN Telnet ?

[LessThanObvious]

It's vulnerable from a packet sniffer standpoint, but a remote vulnerability makes it worse. Many companies have old Cisco code that doesn't have the feature set to support SSH. Why Cisco thought you should have to buy "firewall feature set" on a router in order to get SSH, even long ago still baffles me. Using SSH to get to a management host and allowing telnet across your data center management LAN only from said management host isn't ideal, but it isn't the greatest security sin.

I'd worry anyway.

[khasim]

That makes sense on one level, but using telnet is a bad habit one shouldn't get into.

I agree. A better habit is setting up and using SSH.

Not only that but "defense in depth". Do NOT rely upon your perimeter defenses to stop all attacks. It only takes one person with a compromised laptop and you're cracked.

1) these were default passwords that everyone on the team knew

SSH can be set up the same.

2) the development VLAN is secured from outsiders

Until it is compromised.

Remember, in defense you have to be right on everything all the time. An attacker can just stumble into something you missed. Like someone's laptop that was brought in when it should not have been.

Re:I'd worry anyway.

[bobbied]

Then too, it may be that Cisco's development lab is really just there to run test software loads. I imagine that they are using TFTP and TELNET for this purpose. Oh the horror! (sarcasm off)

Where I don't disagree with you, I'm not ready to dump on somebody who chooses to use TELNET for what ever reason. IF they understand the risks and knowingly choose to do it anyway, it's their equipment and their call. You and I might never choose to do it this way, but neither of us are involved so it's not our choice.

Re:I'd worry anyway.

[__aaclcg7560]

Then too, it may be that Cisco's development lab is really just there to run test software loads. I imagine that they are using TFTP and TELNET for this purpose. Oh the horror! (sarcasm off)

The entire building was set up that way and kept separate from the actual labs inside the building, being one router hop away from the production network. That router didn't have the same safeguards as the perimeter routers for the outside world. Telnet was disabled on the router.

The vulnerability *IS* telnet.

[EmagGeek]

FTFY...

telnet?

[Anonymous Coward]

what is this 1982?

Telnet client = great, telnet server = bad idea

[Viol8]

Don't get the server confused with the client. Telnet servers should have been put out to pasture years ago except perhaps on small isolated networks. The telnet CLIENT however is an extremely useful debugging tool for connecting to all sorts of text based servers (FTP, usenet, HTTP etc) and I get really pissed off with some distributions that assume because the server is no longer used neither is the client and so remove it.

Also FWIW , telnet is still the default way to access MUDs and some BBSs.

Re:Telnet client = great, telnet server = bad idea

[Anonymous Coward]

Don't get the server confused with the client. Telnet servers should have been put out to pasture years ago except perhaps on small isolated networks. The telnet CLIENT however is an extremely useful debugging tool for connecting to all sorts of text based servers (FTP, usenet, HTTP etc) and I get really pissed off with some distributions that assume because the server is no longer used neither is the client and so remove it.

Also FWIW , telnet is still the default way to access MUDs and some BBSs.

They should just rename telnet "passwordBroadcast".

"Also FWIW , passwordBroadcast is still the default way to access MUDs and some BBSs" doesn't sound so good does it?

Mostly a non story. ESA & SMA NOT vulnerable.

[Anonymous Coward]

If you read the Cisco KB it looks like this WAS fixed years ago in the ESA & SMA. We use both at work, our ESAs have been on 7.6.3 for some time, well over a year, this was fixed in 7.6.1 which was released in early 2012. See the revision history on the article too, it's mostly in 2012, the one update in 2014 is for the WSA it also says that the telnet daemon is running ONLY to allow initial setup, once you've completed the wizard it's disabled, which doesn't seem that unreasonable i.e. it's there with a default IP to allow you to give it a real IP in the wizard, after which point it's disabled long before you use it for anything of note.

Telnet

[AchilleTalon]

There is even a kerberized telnet for a long time, however still no advantage over ssh which is also kerberized. Telnet should really die once and for all.

Cisco WSA Vulnerable only

[Anonymous Coward]

This vulnerability affects only Cisco WSA Virtual Appliances as Glafkos Charalambous correctly stated in his Advisory. It seems that Cisco has patched Cisco SMA and Cisco ESA appliances since 2012 and this bug was left unpatched for the last 3 years. The telnet is also enabled by default on the virtual appliance in versions >= 8. What worries me though is not that Telnet is enabled by default but why telnetd wasn't patched properly on the FreeBSD OS since 2011.

a lot depends on the custommer

[Anonymous Coward]

yes there is a hole if you enable telnet and you can get to that port.

Most customers wouldn't do that. Also the telnet is only available on the "management port", which is a separate network port, not to be confused with the web-facing data ports. The suggested way of setting these devices up is to have the management port on an internal management only network, so the chances of someone being able to get to your ISP's management network from the outside is vanishingly small.. (what company would put their management port on the OUTSIDE of their firewalls?

Of course they should have taken the patch from FreeBSD, 3 years ago anyhow.