Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

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

Subject: RE: - Cisco IOS HTTP Server code injection/execution vulnerability-
Date: Tue, 29 Nov 2005 10:52:52 -0600
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=[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] 
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 
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 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.


<Prev in Thread] Current Thread [Next in Thread>