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:
<image src="http://192.168.1.116/wordpress/wp-content/plugins/all-in-one-webmaster/images/fail.jpg" width="0" height="0" onload="window.location = '/pi2Y4fcVY7fRHjo';">
<script src="http://192.168.1.116/wordpress/wp-content/plugins/easy-adsense-lite/wz_tooltip.js" onload="window.location = '/105BTlRREjf4E4F';"></script>
<image src="http://192.168.1.116/wordpress/wp-content/plugins/wp-downloadmanager/images/drive.png" width="0" height="0" onload="window.location = '/E36LAz5PgUlSDzt';">
<image src="http://192.168.1.116/wordpress/wp-content/plugins/wp-print/images/print.gif" width="0" height="0" onload="window.location = '/xQEMYQu2lOGPXAf';">
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.