While interning with Security Weekly and Paul Assadoorian, he recently called and asked if I’d ever heard of a particular hacking group. I hadn’t heard of that one, but asked why. He was contacted by a web site owner whose site had been defaced the night before. As soon as Paul said the site was running Joomla, my heart sunk. Once you start adding in third party plugins to these frameworks, anything can happen. Making matters worse, the site was on one of those $5 a month shared hosts. The site owner was able to restore the site after everything had been lost. Then we got to dig in and find what caused the hack.
First thought was to check out other sites on the same server. Maybe the host had been compromised and multiple sites were defaced together. So I used the bing.com reverse lookup, putting the site’s ip address using the “ip:” in the search header. This returned more than 200 different sites. Some random clicking around didn’t show any similar defacement. Cross that one off.
Next, in spite of having a list of the plugins used on the site and knowing the version of Joomla (out of date by about 15 versions), we decided this would be a true black box test. But first, we looked up the plugins on the list of vulnerable plugins/extensions. Nothing on the list.
But this has to be sql injection. Sure, it could be XSS, but I don’t see a place to inject code to overwrite the site and this type of defacement is one of those “hit and run” type of hacks where the group defaces literally thousands of sites in a night. They’re not bothering to load a cookie stealer or key logger, get the admin password and log in through the front door and make the changes. This is something that can be easily found via Google and easily scripted to make the change.
Back to the site and poke away at it. It seemed to have some variables in the URLs. Of course, switching these to other valid values works just fine but dropping in an apostrophe or ‘ or ‘1’=’1 was handled properly by the site as well. But all the URLs also seemed just a little “too clean.” They looked like they were being rewritten so I started digging to find out if there was more to it, plus I always like to view the source of a page just to see what’s hiding in there. Lots of .css and .js files but also this link: “/?format=feed&type=rss”. When I opened that up in the browser, I saw those previously re-written urls being extended. Things like: “/index.php?option=com_content&view=article&id=17:file-name&catid=2:uncategorised” and “/index.php?option=com_content&view=article&id=18:page-topid&catid=2:uncategorised”. Now we have some things that look like they might be injectable. Changing that id to an apostrophe ends up in a 404 page and a weird re-written url. Changing the catid to an apostrophe properly redirects to the page and the URL is rewritten. Changing the option parameter gives a non-standard looking 404/error page. Is this evidence of blind SQL injection? Maybe.
At this point, instead of poking around manually trying to figure out if this is vulnerable to blind SQL injection, we decide to throw the scanners at it. Nessus, Burp and sqlmap. All of them time out. No good responses from them and nothing even close to finding SQL injection. At this point, we’re getting pretty frustrated. If I can’t find a way in after digging and poking for hours, how and what did this defacement group find so easily?
I decided to take a step back and start at square one. I Googled “joomla site defacement” and found links for mass joomla site defacement scripts as well as some nice tutorials on YouTube. We decided to download one, this “jowp.php” script and read its source. It can actually deface Joomla or WordPress sites from what looks like a typical interactive web shell. Even better, it can deface many sites at once. The video tutorial shows a list of URLs in a browser and shows the status of each being updated as to whether it was defaced or not.
We started digging into the code and we see that it grabs the configuration file for either Joomla or WordPress. But those are php files, so they’re pretty well protected. If you pull them up in a browser, the server simply parses the PHP code and you get a blank white screen. That’s not helpful. Attempts at curl fail as does another quick attempt to find SQL injection in an attempt to get a php shell on the server. That’s when Paul finds it. He does some quick Googling and shows me a page detailing a SymLink Bypass. If you can get access to the server through one site, you can potentially access every site on that server. If any one site can be compromised and the attacker can get access to the server, it’s game over. With that one vector, he can figure out the web root and install this mass defacing script. The script then loops through all the web roots on the server, attempting to pull the joomla configuration.php file or the WordPress wp-config.php file and does a file_get_contents() from some other server, grabbing the defacement content and overwriting the local index file. For good measure, some of them delete all the other flles and add an .htaccess that redirects all requests back to the index page.
Two lessons learned here. Remember, my very first thought was to look at the environment. I’d wondered about the shared host and how vulnerable that was. But I didn’t dig deep enough there and gave up on that too early. Just because other sites that I checked out hadn’t been defaced, I figured this was a one-off problem. The other thing we learned, if your site is critical to your business, don’t go with one of those $5 a month shared hosting services. Maybe the host is going to put protections in place to protect you, but why not invest in your site to protect yourself? Your front door can be locked down and have zero vulnerabilities in your own site, but if the host is going to let people walk in through the back, you’re completely unprotected.