Re: Cisco Security Advisory: IOS HTTP authorization vulnerability

["David Hyams" <david.hyams () kmu-security ch>]

I'm pleased to see that Cisco finally issued this security advisory. I
reported this problem on April 3rd., although it seems that somebody else
also reported this independantly.

I'd like to make a few comments:

I was surprised that Cisco released exploit details within the advisory.
Fortunately routers normally have HTTP disabled by default, so there
shouldn't be too many break-ins on the Internet. Unfortunately HTTP is
normally enabled on switches by default. Even worse, many network
administrators don't realise this, so I expect a number of internal networks
are now in serious trouble. In practice many administrators use the same
password for all networking devices, so if you exploit this vulnerability to
get the password on one of the switches you've probably got THE network
password... (and probably the enable password too, why do so many network
admins use the same passwords for vty and enable access?)

If you're serious about security then you shouldn't be using HTTP to access
your Cisco devices at all. Most people don't realise that the browser sends
the enable password in cleartext on every HTTP request. (OK, it's base64
encoded but that's cryptographically the same as cleartext). I used to think
that session management was performed using cookies, i.e. enter the
username/password of  the device in the browser, after which a cookie is
used to maintain the user session. This way, the password is only sent once.
Out of curiosity I once used a packet sniffer to try to identify the cookie.
I was surprised to see that no cookie is used - instead, the password is
sent cleartext in an HTTP header on every HTTP request. Oh dear.

Note that Cisco does warn against using HTTP, see "Improving Security on
Cisco Routers" ( http://www.cisco.com/warp/public/707/21.html ). However,
HTTP is usually enabled on switches, not routers. Maybe Cisco should write
another document "Improving Security on Cisco Switches"? Also, how about
implementing SSL on networking devices? Just an idea.

One of the basic rules of security is strength in depth. If one security
barrier fails, then additional barriers should be present to make the
attackers task more difficult. This security advisory illustrates that the
first barrier can be bypassed, and an attacker has an easy way to access the
device configuration ( http://ip-address/level/NN/exec/show/config ).
Unfortunately, device configurations are often pretty awful:

* It would appear that many devices still don't use the option "service
password-encryption", so the attacker can see your passwords in cleartext. I
suspect that the default is "NO service password-encryption". Shouldn't the
default be set to ENABLE encryption?

* It's well known that the encryption algorithm for vty passwords is very
weak. Numerous software tools exist to decrypt the vty password. Isn't it
time to abandon this algorithm and implement a real encryption algorithm for
ALL passwords (not just the "enable secret" command)? If an attacker can get
the device config, then it's far too easy to decrypt the password (assuming
of course that it is encrypted! See above)


regards

David Hyams
--
david.hyams () kmu-security ch
http://www.kmu-security.ch