WordPress CSRF Exploit kit – A novel approach to exploiting WordPress plugins

[Nytro]

[h=2]WordPress CSRF Exploit kit – A novel approach to exploiting WordPress plugins[/h]

Over the last few weeks I’ve been on roll with finding CSRF vulnerabilities in WordPress plugins. That’s all nice and good, but when you’ve got 30 of them, it’s a shame to not take it a step further and show the dangers of them! This project is solely designed to show off a few random thoughts of mine, and most importantly to hopefully inspire others to think along these lines. This project is solely meant for educational purposes, not attack against running services or people.

https://github.com/CharlieEriksen/WP-CSRF-POC

The project shows a few basic concepts in regards to the process of pulling off a CSRF attack against a large number of WordPress sites. Some things worth pointing out:

• It’s not designed to simply spray and pray. You define the target URLs you want to hit and then you have an unique URL for each blog you can go phishing with.
  
• Then it will use the onload function of an img or script tag to detect the presence of the vulnerable plugin on the target blog on request through the unique URL pre-defined
  
• We generate the payload on request with an uniquely identifying URL to ensure it’s not easy to extract the exploits.
  
• You get max 2 requests to the script per IP. That is all a compromise needs. After that, you get nothing back. Makes it harder for researchers life
  
• We deliver a beef hook. Because beef is cool and god damn tasty
  

I want to stress especially the “novel” use of the onload function of img/script tags. People in the past have used it to detect the presence of different host-names/”port scanning” internal systems by vectoring through a hooked browser. I say that’s cool and all, but you can take that further and use it to detect the presence of a plugin on a target on demand, making you able to be much more sneaky. When the markup detects a plugin present on the target, it redirects the browser to the exploit, and no further requests can be made by that IP to the script.

A normal series of events would be:

1. An attacker sets up this script with pre-defined targets(targets variable) with an unique URL for each target blog
   
2. The attacker then spams out a link to the running script with the unique URL for each target blog
   
3. When a target clicks the link to this script, we validate that the URL contains the unique identifier that resolves to a blog URL
   
4. The script the generates a random URL for each exploit we have with the target blog URL put in that can then be requested
   
5. We output to the user a series of img/script tags with onload attributes that redirect to the unique URL generated in step 4. These tags look for specific plugins on the targeted blog
   
6. If none of the plugins are detected on the blog, we redirect to google
   
7. If any of the plugins are detected, we redirect to the uniquely generated URL made in step 4
   
8. The exploit is now written out to the user, submitting the CSRF with a XSS payload pointing to our beef instance
   
9. We now delete all cached exploits made for the requesting IP
   

There’s a number of improvements that could be made to this. It could be designed to spray and pray through iframes, but that is much much dirtier, and not the goal of this proof of concept. I urge anybody who finds the concept to be useful to run with it if they so desire. I’ll be adding more exploits as advisories are published. Otherwise, I’m curious to hear people’s thoughts on this.

Sursa: Wordpress CSRF Exploit kit – A novel approach to exploiting Wordpress plugins | ceriksen.com