Attacking the local LAN via XSS

From: pdp (architect) (pdp.gnucitizen@googlemail.com)
Date: Thu Aug 03 2006 - 19:35:48 EDT


this is my humble opinion
http://www.gnucitizen.org/blog/xssing-the-lan

I didn't go to BlackHat but since a lot of people are getting really
interested in XSS attacks, right now when it is sort of blooming, I
will try to put in theory how border routers/gateways can be trivially
compromised (over the web).

For that purpose three prerequisites are needed:

   1. page that is controlled by the attacker, lets call it evil.com
   2. border router vulnerable to XSS
   3. user attending evil.com

Once the user attends evil.com malicious JavaScript code executes and
tries to figure out what machines are alive on local LAN and where the
border router is located. This is usually achieved in a similar way
the JavaScript port scanner works.

Once the router is identified, the malicious script needs to figure
out the software version. This is not quite trivial task since most
modern browsers have cross domain restrictions which means that fancy
Ajax techniques such as the XmlHttpRequest object wont work. The
attack vector explained by SPI Dynamics though, should work on all
browsers. For that purpose the malicious JavaScript fires several
requests against the router looking for common image files. Different
types of routers have different images, so, obviously this is a way of
identifying the server software.

Depending on the results collected by the scanning process, an already
published XSS flow is flagged. This XSS flow is used by the malicious
JavaScript to propagate its logic to the border router domain. This
step is crucial since modern browsers wont allow you to perform cross
domain requests unless a forth prerequisite is introduced – the buggy
browser.

Anyway, the malicious JavaScript creates an invisible iframe inside
evil.com that carries the attack. The iframe src (source) attribute
contains a URL that will exploit the XSS flow in the border router.
Since the code is executed of the border router domain, no cross
domain restrictions are applied. This means that the malicious logic
can be constructed out of XMLHttpRequest objects which provide greater
control on the input and the output.

At the final stage the logic transported by the border router XSS flow
performs login and retrieves the user credentials which are submitted
to a remote resource that is controlled by the attacker. However, in
corporate environments the attacker might wish to put down the
security level of the exploited device and open a worm hole.

It is quite simple and it is less complicated then it sounds.

-- 
pdp (architect)
http://www.gnucitizen.org
------------------------------------------------------------------------------
This List Sponsored by: Cenzic
Concerned about Web Application Security? 
Why not go with the #1 solution - Cenzic, the only one to win the Analyst's 
Choice Award from eWeek. As attacks through web applications continue to rise, 
you need to proactively protect your applications from hackers. Cenzic has the 
most comprehensive solutions to meet your application security penetration 
testing and vulnerability management needs. You have an option to go with a 
managed service (Cenzic ClickToSecure) or an enterprise software 
(Cenzic Hailstorm). Download FREE whitepaper on how a managed service can 
help you: http://www.cenzic.com/news_events/wpappsec.php 
And, now for a limited time we can do a FREE audit for you to confirm your 
results from other product. Contact us at request@cenzic.com for details.
------------------------------------------------------------------------------


This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:56:32 EDT