Akamai Security Intelligence Response Team (SIRT) researchers Larry Cashdollar and Chad Seaman have spent months researching vulnerabilities in plug-ins often used with WordPress. The results of that research are outlined in the Q2 State of the Internet Report, and an excerpt on the section can be found in this Akamai Blog post. In the following post, Larry shares some tips for researching WordPress plug-ins.
By Larry Cashdollar, Senior Security Intelligence Response Engineer
I’ve been looking at WordPress plugin code and discovering new vulnerabilities. The vulnerabilities range from Cross Site Scripting, Remote File Inclusion to blind SQL Injection. I’ll admit I’ve enjoyed this research more than my examination of Ruby Gems because with WordPress you can easily test a proof-of-concept exploit by setting up a WordPress installation and testing your code against it.
I’ve realized some short cuts along the way and I’ll document my favorite ones here.
Command Line Exploitation of WordPress plugins
Use of free hosted WordPress sites for testing
By-pass linux anti-virus/malware software when using known payloads
When developing the first few exploits for vulnerabilities I discovered in plugins my process was the following:
Find suspect code
Examine and verify code is exploitable
Spin up wordpress installation on a virtual lab machine
Install & Activate plugin
I wanted to reduce the discovery to proof of concept testing cycle some. I realized some of the exploits looked very similar to previous ones I had developed and based on the vulnerable code should easily work. However I don’t like leaving things to chance and still wanted to test the exploit without going through the work of spinning up a WordPress VM and installing the plugin. What I ended up doing for some (not all*) vulnerabilities is writing a small shell script that set the CGI environment variables and used php-cgi to test my exploit. In the example below the plugin doesn’t check who is requesting a file to be downloaded or what that file is.
The results of successfully exploiting the vulnerable code are below, abusing the coding error in the plugin to send me the contents of /etc/passwd.
This technique would work for testing plugin code that does not rely on WordPress API hooks or exploit payloads that require writing to files. Typically with testing file upload vulnerabilities you’ll need a valid writable path to upload a shell file too, the path may not exist or be writable when you don’t actually have a WordPress instance setup on your test machine. So by testing exploits on the command line with php-cgi I eliminated the need to spin up a WordPress instance to install the vulnerable plugin on. This made vulnerability verification by proof of concept demonstration easier and faster.
Another short cut I used was to test exploits against different WordPress installations by utilizing free hosting sites like the one shown below. Some vulnerable WordPress plugins had specific requirements or assumptions about the local environment to be made. These assumptions may not be guessed as easily when not in a controlled lab setting. For example, determining the WordPress database name or table names when testing SQL injection or web root path when abusing a file upload vulnerability uploading a web shell script.
With free hosting sites you could setup a WordPress instance in order to get a feel as to what other hosted environments might look like, even run into virus and malware mitigation software that removes your known c99.php web shell before you have a chance to execute it. I found modifying a few bytes of the shell script bypassed whatever software had been marking it as malware and removing it, allowing me to continue my testing.
Our research on these plug-ins and other WordPress components are ongoing, and Akamai SIRT remains committed to keeping an eye on things.
Akamai SIRT will continue to search for additional vulnerabilities and advise further in future updates. Our research will include defensive measures users can deploy to protect themselves.