XSSing the Lan
I didn’t go to BlackHat but since a lot of people are becoming interested in XSS (Cross-site Scripting) attacks, I will try to put in theory how border routers/gateways can be trivially compromised over the web. For the purpose of this exercise three prerequisites needs to be met: a page that is controlled by the attacker, lets call it evil.com; border router vulnerable to XSS; user attending evil.com
Once the user visits evil.com a malicious JavaScript code executes to find what machines are alive on local LAN and where the border router is located. This is usually achieved in a way similar to how the JavaScript port scanner works.
Once the router is identified, the malicious script needs to figure out the software version. This step can be skipped but it is definitely a good thing to do if the attacker wants to be as stealth as possible. Keep in mind that modern browsers have cross domain restrictions which means that fancy AJAX techniques such as the XmlHttpRequest object simply wont work here. The attack vector explained by SPI Dynamics though, should work on all browsers. As discussed in the SPI Dynamics’ paper, the malicious JavaScript code fires several requests against the router looking for common image files. Different types of routers have different images, so it is obvious that this is a way of identifying the server software.
Depending on the results collected by the scanning process, an already disclosed XSS flow is flagged. This XSS flow is used by the malicious JavaScript to propagate its code to the border router domain. This step is crucial since, again, as we mentioned before, modern browsers wont allow you to perform cross domain requests unless a forth prerequisite is introduced - a buggy browser. This however, is not very clean approach.
Anyway, the malicious JavaScript creates an invisible iframe inside evil.com that carries the attack. The iframe src (source) attribute contains a URL that exploits the XSS flow in the border router. Since the code is executed on the router domain, which is some kind of internal IP, no cross domain restrictions are applied. This means that the the rest of the attack can be constructed out of XMLHttpRequest objects which provide greater control on the input and the output.
In the final stage, the code transported by the border router XSS flow performs a login and retrieves the user credentials which after that are submitted to a remote collection point that is controlled by the attacker. Furthermore, in corporate environments the attacker might wish to put down the security level of the exploited device so they can go back to it whenever they want.
It is quite simple and it is less complicated then it sounds.
