Date: Thu, 3 Aug 2006 22:21:39 -0400
From: "Peter Dawson" <slash.pd@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Attacking the local LAN via XSS

interesting..but forgive my ignorance

can you further articulate ..."a URL that will exploit the XSS flow in the
border router" in a broader context ??


On 8/3/06, pdp (architect) <pdp.gnucitizen@...glemail.com> wrote:
>
> 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
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



-- 
http://peterdawson.typepad.com
PeterDawson Home of ThoughtFlickr's
"This message is printed on Recycled Electrons."

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists