Conditional CSRF – Or how to spray without praying

A part of the goal of my latest project, WordPress CSRF Exploit kit – A novel approach to exploiting WordPress plugins, was to show some novel techniques that I’ve been picking up on in terms of exploitation of web applications and delivering payloads in neat ways. One goal specifically was to deliver an array of different potential payloads depending on specific conditions and not spray and pray. The one that is the most obvious, is whether or not the target has a specific plugin installed. My approach ended up being a somewhat obscure but neat one that others have documented before. Specifically, the onload/onerror attribute on certain HTML elements that pull in outside resources. Lets deconstruct a landing page as you’d see it from the above project:

What we can observe here is a bunch of different image/script tags all pointing to a potential file existing on a remote system which belong to a specific WordPress plugin. In the event that the plugin is not installed on the host, nothing happens. We’re not loading them for display as I’m sure you guessed. Rather, we’re hoping to get the onload attribute invoked, which contains some convenient javascript of ours.

In the event that the vulnerable plugin is detected, in this case we redirect to a page that contains our actual exploit payload. This means we don’t have to send all possible payloads at once, but can have some obscurity until we know we can hit something interesting. Or in other words, you can spray a target and not have to pray that your exploits work, because they won’t trigger unless a target has the plugin you’re targeting.

This approach is not new, as it has been used in the past for things like trying to resolve different host-names/ip/port ranges on an internal network through a hooked browser to scan for other web applications to target. In this case, we’re using this approach to detect the presence of a vulnerable plugin on a, granted that it’s a pre-determined, target. By being able to not have to do up-front poking at a running system, we’re able to achieve a lower turn-around time on delivering a payload that either hits a target or simply just does nothing.

So there you have it. This is probably not an useful approach to take in all cases where you exploit a CSRF vulnerability. But it’s still an interesting approach and hopefully will inspire others to consider thinking about being more sneaky(Don’t spray and pray!) in their exploitation attempts and make full use of the wonderful things HTML and javascript offer you!

One comment

  1. Another example where this may would be useful: Doing a CSRF attack against a company where you’re spraying employees, and the network is heavily segregated(I.e. only the development team may have access).  You’d only want to deliver a payload to people who has HTTP access to a specific server. This would be a good approach for doing that.

Leave a Reply