Getting started with bug hunting is hard.
Platforms such as Hackerone and BugCrowd provide ample legal targets. However, those platforms are also quite competitive. If this is your first time you can pretty quickly fall into the mental despair we likely all know of “I’m not good enough”. At least that was what myself and Misha felt when we first decided to team up and find out first bugs as a team.
Our solution to this was to start with WordPress Plugins. We’ve all heard that WordPress Plugins are *the* way that WordPress sites become vulnerable and that Plugins are ripe for the picking when it comes to vulnerabilities. So we decided to put that to the test and see if we could come up with at least one of our own.
Fast forward a few days, and luckily enough, Misha had found a vulnerability in a backup plugin that caused SQL database backups to be exposed (and google dork-able). However, after this lucky quick win we rather rapidly discovered that choosing a plugin to probe was pretty hard. It seemed to come down to whether you happened to pick the right one to install from the WordPress store.
That’s when we decided to automate.
I’ll give you the TLDR upfront. I wrote a tool that I’m calling Echidna (Echidna’s are Australian and hunt for bugs you see). The tool, when ran, will start scanning every single plugin in the WordPress store and perform static code analysis on any PHP file in those plugins to look for vulnerabilities. If it finds any it will move the plugin, and some information about the vulnerability it found into a “inspect” folder that is created wherever you run the tool from.
Alright, let’s go into more detail than that.
Echidna is a program that is written in Go. It essentially has two main roles: Downloading plugins and Scanning plugins.
Once Echidna it started it will do the following:
- Create a “Current” folder and an “Inspect folder
The current folder is where it will store downloaded plugins that its currently scanning. The inspect folder is where it will move potentially vulnerable plugins for later analysis by you.
- Reach out to the WordPress Plugin store and scan every single page of the store to gather information about all of plugins that currently exist.
- Begin spawning GoRoutines that will download plugins at random (so we don’t all start with the same plugins to look at) and saving them inside the “current” folder.
- Once a plugin appears in the “current” folder a separate GoRoutine will grab it, open it in memory and begin scanning any php it finds.
The PHP files will be scanned by every vulnerability module that exists (XSS, LFI, SQLI, CMDEXEC, etc)
- If no vulnerabilities are found that GoRoutine will delete the plugin from disk and grab the next plugin in the “Current” folder to scan
- If vulnerabilities are found the GoRoutine hands off the plugin to another Goroutine which will move the plugin to the “Inspect” folder and save the .txt file with information about the vulnerabilities found
- This will occur until Echidna has scanned every single plugin in the store. This usually takes somewhere between 30-90 minutes for me but your network speed will be the judge for you.
Now that you have a general idea of how Echidna runs, lets talk about using it.
There are two pre-requisites that you’ll need to have sorted out first to get started:
- A computer to run the tool on. It’s written in Go so its already go cross platform compiled binaries, so OS choice isn’t too strict.
- A WordPress instance to install your plugins on. I used a subdomain on this website but you can install a local WordPress instance if you like. There’s plenty of how-to’s for WP installs out there.
With those pre-req’s out of the way lets get into what you should do.
Download Echidna and start running it
First step is to go to Github and download Echidna (it’s here). Once it is downloaded you can just double click it or run it from the command line to start it. There’s no switches needed.
Echidna should start scanning plugins fairly quickly and you will start to see your inspect folder start to fill. Speaking of which..
Examine your Inspect folder
When Echidna starts running it will automatically create a couple of folders. One of those is the “Inspect” folder. The inspect folder is where Echidna will store anything it thinks you should take a closer look at. Meaning that plugins matched against atleast one of the vulnerability modules Echidna has.
Open your inspect folder (its in your current directory that Echidna is running in) and you’ll be met with a bunch of vulnerability types.
Echidna will automatically sort vulnerable plugins into folders based on the potential vuln that was found. Use this to help you choose whether you’d like to go for SQL injection vulns or XSS vulns and dive into that folder.
Inside the vulnerability folder you will find a bunch of .zips and .txts. Let’s use the first one from the picture above as an example.
We are in the XSS folder, so Echidna believes it found a potential XSS vulnerability in the woocomerce-gateway-paypal… plugin.
The .zip file is the plugin itself, it’s saved here so you can drag and drop it into your WordPress instance to quickly start poking and proding at it.
The .txt file is Echidna’s little information dump around where it found the vulnerability in the plugin.
For example, opening up this .txt file shows us:
This means that Echidna found one potential XSS vuln in the plugin. If it found more, then they would also be displayed here.
It found that the sv_wc_framework_deactivate_newer GET parameter is being echoed straight back out to the user. This is happening in the class-sv-wc-framework-bootstrap.php file in the plugin.
Is this definitely a XSS vulnerability? well, no not necessarily. You need to test it now, or open that PHP file and verify for yourself if the rest of the line negates the vuln or not.
But already we have picked a plugin, a file, a line in a file and a specific vulnerability that line might have without any effort at all on our part. sweet!
From here you can install the plugin into your WordPress instance and verify the vulnerability. Not every result will be a vuln, there are False Positives, however with some determination I was able to find around 1 vuln every night for just under 2 weeks before deciding to stop (there was still plenty of targets).
Before I wrap up, you might be wondering about the numbers in the filenames of plugins in the inspect folder. The naming convention is as follows:
<Active installs count>_<days since updated>_<Plugin name>.zip/txt
This lets you quickly identify whether you want to even bother looking at a plugin or not. Maybe you want to aim for a bigger win? sort by Active installs and choose a plugin with lots of current installations. Or maybe you want an easier first go? chose a plugin with lower active installs that hasn’t been updated in a long time. It’s up to you!
Finally, if you use this tool and find some bugs that you submit for CVEs then please reach out to me (@pyth0n2 on twitter) so I can put your achievement in the tools README 🙂
Happy Bug Hunting!