Onderwerp: - Cisco IOS HTTP Server code injection/execution vulnerability-

It has been identified a vulnerability in the Cisco IOS Web Server. An attacker can inject
arbitrary code in some of the dynamically generated web pages. To succesfully exploit the vulnerability the attacker only needs to know the IP of the Cisco. THERE'S NO NEED TO HAVE ACCESS TO THE WEB SERVER! Once the code has been inyected, attacker must w
ait until the admin browses some of the affected web pages.

There is a URL in the IOS Web Server:

/level/15/exec/-/show/buffers

where administrators can view the content of memory buffers. There are many options, but we are
interested in:
"all" --> all buffers
and,
"assigned" --> Buffers in use

Following those links will show you those options:

"dump" --> Show buffer header and all data
"header" --> Show buffer headder only
"packet" --> Show buffer header and packet data

The "dump" and "packet" options are clearly affected by the code inyection.

An attacker can buid a packet with HTML code in the payload field. When admin access some of the dump options in the show buffers page of the Cisco, the code is executed in his browser.

Full advisory and P.o.C. exploit that changes the "enable" password at:

http://www.infohacking.com

> It has been identified a vulnerability in the Cisco IOS Web
> Server. An attacker can inject arbitrary code in some of the
> dynamically generated web pages. To succesfully exploit the
> vulnerability the attacker only needs to know the IP of the
> Cisco. THERE'S NO NEED TO HAVE ACCESS TO THE WEB SERVER! Once the
> code has been inyected, attacker must wait until the admin browses
> some of the affected web pages.

Isn't your exploit somewhat complicated? Just put

<img src="http://192.0.2.1/level/15/configure/-/enable/secret/mypassword"/>

on a web page, and trick the victim to visit it while he or she is
logged into the Cisco router at 192.0.2.1 over HTTP. This has been
dubbed "Cross-Site Request Forgery" a couple of years ago, but the
authors of RFC 2109 were already aware of it in 1997. At that time,
browser-side countermeasures were proposed (such as users examining
the HTML source code *cough*), but current practice basically mandates
that browsers transmit authentication information when following
cross-site links.

Such attacks are probably more problematic on low-end NAT routers
whose internal address defaults to 192.168.1.1 and which generally
offer HTTP access, which makes shotgun exploitation easier. So much
for the "put your Windows box behind a NAT router" advice you often
read.

To further aggravate the CSRF/'Session Riding' angle, one may
implement two attack mechanisms against Cisco IOS/HTTP (and any
similar platform) with current browsers/javascript injection:

1) img src=3D[IE only]javascript: and increment through RFC-reserved
IP space; you could focus on .1's and .254's to target common
gateway locations. I presented script targeting Nokia IPSO doing
this at Black Hat Amsterdam 05 that was written in 2003. Further
research revealed a _lot_ of folks have done work here going back
farther than I initially realized...

2) Pop an iFrame and get full browser control. Reference Jeremiah
Grossman's BH Vegas 05 presentation & Anton Rager's XSS Proxy and
05 Schmoocon presentation (you will have to tweak XSS_Proxy's frame
to get it to work transparently). We have similar scripts that can
perform anything from keyboard capture (useful for things like Citrix
nFuse sessions) to payload injection.

More importantly: through #2 iFrame method, you can control the client
browser and use it to scan and effectively fingerprint/map the target
internal network for [Cisco] devices by parsing DOM contents/HTTP =
header.

No one has done a good write-up on this attack vector bit but it's
relatively trivial to execute and doesn't require much coding knowledge
to write a working exploit (a little js and a server-side controller).

If someone wants to flip an ActiveX control in they could wreak
real havoc. Many of these devices (think SSL VPNs) already rely
on ActiveX so users are used to installing them. This has been
talked about for years but no one has released an ActiveX written
for, say, full client disk-control and marked safe for scripting
and initialization with XSS/js injection PoC or proxy toolkits. </hint>

(nota bene: yes these ActiveX *have* been released--reference the
Sony 'Rootkit removal ActiveX control'--but not released in the
sense of a reusable ActiveX purpose built for client-control to
embed on target.site or to host on a malware.site that the attack
code can link to...at least that I'm aware of...)

-ae

> -----Original Message-----
> From: Florian Weimer [mailto:fw@deneb.enyo.de]=20
> Sent: Monday, November 28, 2005 3:55 PM
> To: picardos@terra.es
> Cc: bugtraq@securityfocus.com
> Subject: Re: - Cisco IOS HTTP Server code injection/execution=20
> vulnerability-
>=20
>=20
> > It has been identified a vulnerability in the Cisco IOS Web
> > Server. An attacker can inject arbitrary code in some of the
> > dynamically generated web pages. To succesfully exploit the
> > vulnerability the attacker only needs to know the IP of the
> > Cisco. THERE'S NO NEED TO HAVE ACCESS TO THE WEB SERVER! Once the
> > code has been inyected, attacker must wait until the admin browses
> > some of the affected web pages.
>=20
> Isn't your exploit somewhat complicated? Just put
>=20
> <img=20
> =
src=3D"http://192.0.2.1/level/15/configure/-/enable/secret/mypassword"/>
>=20
> on a web page, and trick the victim to visit it while he or she is
> logged into the Cisco router at 192.0.2.1 over HTTP. This has been
> dubbed "Cross-Site Request Forgery" a couple of years ago, but the
> authors of RFC 2109 were already aware of it in 1997. At that time,
> browser-side countermeasures were proposed (such as users examining
> the HTML source code *cough*), but current practice basically mandates
> that browsers transmit authentication information when following
> cross-site links.
>=20
> Such attacks are probably more problematic on low-end NAT routers
> whose internal address defaults to 192.168.1.1 and which generally
> offer HTTP access, which makes shotgun exploitation easier. So much
> for the "put your Windows box behind a NAT router" advice you often
> read.
>=20

> That's what makes this vulnerability so fun. There's no need of
> trick the victim, and you don't need to know the private address of
> the router, etc,etc... you only must wait until he/her visits the
> buffers dump page.

Visting the buffers dump page is not a common operation, especially
among those who use HTTP to access their routers.

Of course, a BUGTRAQ posting that describes a problem with the buffers
page might have the desired effect. 8-)