[Security] MalaRIA - I'm in your browser, surfin your webs

April 5, 2010 - 12:02 UTC   -   Tags: xsrf flash crossdomain flex silverlight RIA MalaRIA xsrf csrf Unrestricted crossdomain.xml and clientaccesspolicy.xml files can be abused by malicious RIAs - or MalaRIAs - to perform actions on behalf of the user. For this PoC (proof of concept) I setup a malicious RIA to act as a proxy by comibining it with a server side application. This would allow the attacker to use the combined solution as a proxy and surf web sites with unrestricted cross domain policies through the victim's browser.

Update 2010-04-07: Source code now available: http://github.com/eoftedal/MalaRIA-Proxy

Introduction

Unrestricted crossdomain.xml and clientaccesspolicy.xml files can be abused by an attacker. The attacker can setup a rouge RIA app - a malaRIA - on a site, and if he can trick the user to visit the site, the malicious RIA can perform actions on behalf of the user (CSRF). Because the RIA runs in the user's browser, the requests will reuse the user's authentication cookies. Because the RIA is able to both read and request data, normal CSRF protection does not work (nonces/tokens can be read).

Such a RIA can at the same time transfer data back and forth to the server from which it came through a socket. This can allow the attacker to send commands to the RIA, which will then perform these actions.

The MalaRIA proxy

The MalaRIA proxy consists of a silverlight or flex RIA application running in the browser and a java backend. The attack works like this:

1. The victim logs in on site A
2. The victim accesses evil site B and loads the RIA app
3. The RIA app connects back to the java backend
4. The attacker sets his browser to use the java app as a proxy in his browser
5. A request to the proxy, is sent to the RIA app, which on behalf of the victim, gets the resource, and passes it back to the attacker

So the java application listens on port 8080 and acts as a proxy. It will pass any request to the MalaRIA app in the victim's browser. The MalaRIA app fetches the resource and passes it back to the attacker through the proxy. So the attacker can browse the site through the users browser.

Here is a video showing the components in action:

Attacking the intranet

Because the attack goes through the user's browser, the attacker may be able to gain access to an intranet server if that server has an unrestricted crossdomain.xml or clientaccesspolicy.xml. To detect an internal server the attacker can use referer headers, javascript port scanners, CSS history hacks etc. Jeremiah Grossman talked about attacking the intranet using javascript malware at Blackhat'06.

Update 2010-04-12: Adam tipped me about the post "Penetrating Intranets through Adobe Flex Applications" on how to exploit insecure proxy-config.xml through BlazeDS to attack the intranet. The authors have built a tool called Blazentoo to exploit such configs.

Limitations

The current PoC does not support images and documents due to encoding issues. It should be possible to fix this, and thus this could potentially be used to also steal documentation.
Update 2010-04-14: Images and documents now supported.

Protection

Restrict access in your crossdomain.xml and clientaccesspolicy.xml files.

More information

• Why you need to lock down your crossdomain.xml
• Why you need to lock down your Silverlight clientaccesspolicy.xml
• The Dangers of Cross-Domain Ajax with Flash

The diagrams in this post were created with the great online diagram editor at http://www.gliffy.com/