I have been focused on vulnerability research against WordPress Plugins and more recently Joomla Extensions. During my talk at Defcon 24, I spoke about my research processes and results, I didn’t cover the pros and cons of researching against different software products.
One of the things I admired while researching WordPress plugins were how they were stored. They each have their own source code repositories uniformly accessible from the main plugins.wordpress.org site. They keep download stats, plugin author contact information, plugin version and you can get a list of every plugin wordpress.org has hosted by pointing your browser at http://plugins.svn.wordpress.org/.
For a researcher this makes life much easier, the source code is easily accessible and downloadable using command line utilities. This allows some easy automation if you’re examining big chunks of code for specific vulnerabilities. What throws a monkey wrench into the whole thing (and this I did discuss at Defcon 24) is WordPress changed its core code a few years ago to escape the global variables GET, POST, REQUEST, COOKIE, SERVER. I didn’t expect any developers to mess with the basic input modes of the PHP language. What I did expect is something more along the lines of WordPress creates its own functions that process user input and they do some form of sanitization there, for example:
$id = wp_request->get(‘id’);
While the method employed by the WordPress core team makes it more difficult to exploit possible vulnerabilities in WordPress code it could also confuse a plugin developer when they’re wondering why the user input is being changed behind the scenes.
Joomla isn’t as popular as WordPress but has a decent chunk of the CMS market with two and a half million sites using it to manage their content. Joomla like WordPress has the ability to load third party plugins called extensions. Unfortunately, these extensions aren’t hosted locally by Joomla’s servers. Extension pages link to the 3rd party sites themselves for information and downloads. The lack of consistency allows for tedious amounts of work when doing vulnerability research. Instead of being able to pull code from consistently structured URLs and allowing for some ease of automation, the researcher must click through pages to find the vendor’s site to download the source code. Joomla doesn’t track download stats or have an easy place to contact 3rd party vendors.
On the plus side, Joomla leaves its global variables unmolested allowing the researcher the normal expected behavior of PHP user input processing. It also has the VEL the Vulnerable Extensions List where researchers can easily report vulnerabilities if they’re unable to contact an extension vendor themselves. While I’ve enjoyed researching vulnerabilities against both WordPress and Joomla, I wish there were a hybrid. My hybrid would have both easy 3rd party code accessibility and revision history along with the core code base not messing with its parent languages basic functionality. I now wonder how Drupal is organized.
Conclusion
I really enjoy security research, even more so when the environment I’m working with is organized as well. This generally forces me to keep a more organized environment which I tend to let slip when focused on bug hunting. I also suspect making code easy to access, track and attribute might lure more researchers to willingly examine it for flaws. Which is a good thing?
