bugtraq - Attacking the local LAN via XSS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Fri, 4 Aug 2006 00:35:48 +0100
From: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	pen-test@...urityfocus.com, webappsec@...urityfocus.com
Subject: Attacking the local LAN via XSS

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