CMS exploits

A path to experience

CMS exploit development has been running rampant around places like exploit-db for ages. I took to doing a few of my own with positive results a few months back. But why is it so popular? And is it really worth doing?

CMS sploiting for fun '; -- and profit

Content Management Systems (CMS), are used to make developing and running web sites simple. They come fully loaded with useful tools and db plugins, giving a quick, professional look. No wonder they are used in their droves to produce many of the web sites we visit. There are many to choose from and range from the strictly amateur to the professional/expensive.
Exploit development has been a serious past-time for the following reasons:
    - Many of them are open source
    - They can be set up offline, speeding up/legalising the hacking process
    - They are used in real life, so the results of finding vulns are more rewarding

CMSs are therefore a cheap, easy way to get into web exploit development and source code review. No wonder juniors everywhere are using them to cut their teeth on web app pen testing and exploit development.

But surely they have been done to death. Is it still worth it? Are their vulnerabilities out there?

CMS 2012

Certainly finding straight SQL injection on the home page is only going to be the case if you're looking at an old, poorly maintained or infrequently used CMS. Not really rewarding and unless you are just starting out, not very educational. You therefore have two options:
 #1 - Find low risk vulns (reflected XSS, CSRF)
 #2 - Dive into source code

I'm not going to talk about #1 aside from the fact that I'm not a fan. Instead I wanted to run through a better CMS analysis method. I'm afraid you will need to look at the source. This may take the fun out of it for most, but if you want to find a worthwhile vuln that is actually respectable, then you need to broaden your game.
    1. Start by grepping
        You need to know key functions that will give you the big wins. Things like exec(), sql_query() and fopen() are gold. If you can find these in the files, then you have a starting point.
    2. Find out their variables
        Do they take variables? If so start following the breadcrumbs. There are some basic tools for this but they aren't particularly good and may lead to false negatives. In any case, this is a learning process so take the time to do it by hand, at least at first. Are they in functions or classes? Are these functions or classes called anywhere?
    3. Edit the script to make life easier
        The joy of offline analysis is that you can change the code. Add in a few extra echos to help follow through the code as it gets executed. It won't be like that in the end, but then you will have the exploit ready and no longer need them.

That's really it. I wanted to write this because there is so much good development in the CMS community and they're getting stronger and stronger for it. It's also infinitely more rewarding to get code execution from a CMS that is really out there and being used. Far better than dull little unrealistic test sites. Just be ethical with your disclosure!