Quite often when you read logs and see examples of scans against a system, those will be from the Acunetix vulnerability scanner. If you watch “how to hack” videos on YouTube, you’ll quite often see the Acunetix icon on the desktop. This is because it’s pretty easy to find cracked versions of the tool on forums that offer these types of tools.
Sometimes when I’m looking through logs, I’ll see some strings that I want to try to attribute to a scanner and will put them in google, looking for hits. I often don’t find any but figured if I put some in here, that might help others to find them too and attribute their log entries to Acunetix.
First, take a look at the request headers. There are a couple that Acunetix sets that are a dead giveaway:
Acunetix-Product WVS/9.0 (Acunetix Web Vulnerability Scanner – NORMAL)
Acunetix-Scanning-agreement Third Party Scanning PROHIBITED
If you see any of these, you were scanned by someone possessing the Acunetix scanner. It was not the Acunetix company scanning your site, so don’t blame Acunetix for scanning your site any more than you’d blame Ford Motor Company if someone driving a Focus rear-ended your car.
You may also find other references to Acunetix in your logs, often with attempts at Cross Site Scripting, or even references to vulnweb.com (a test server Acunetix runs, and is included in some of the scanner’s tests). But for SQL injection, specifically blind sql injection, Acunetix tries some math tests for a true or positive result. Some of those may look like:
id=-1” OR 3*2 >(0+5+905-905)
id=-1’OR 3*2 >(0+5+635-635) —
page=-1′ OR 3*2< (0+5+770-770) --
id=-1'' OR 3*2< (0+5+286-286) --
I'll try to add more examples as I find them in my logs.
Here’s a fun one I got to play with the other day. It’s not so much a vulnerability but some bad coding that could have presented itself to look like a denial of service attack. It triggered rate controls on the WAF, which will often get my attention. Then I looked and saw it was mostly coming from a single IP address. Right there, you can almost immediately rule out DDoS, because the first D is for “distributed”. A single IP isn’t very well “distributed”.
Looking into the IP address, I noticed that it was coming from a media outlet in Latin America. I haven’t seen too many news orgs that want to DoS a site. Plus, all the requests were all going to the same file on a customer’s site, and it was pretty innocuous. It was just a story that was relevant to the news org.
Next, I looked a little more into the file that was being called. I put the URL into a browser and I got a white screen. Nothing. But looking a little more closely, I could see that the page just kept reloading. A “View ->Source” of the page showed nothing. Blankness. Nothing was loading, even though the page was reloading endlessly. What was causing that?
Let’s take a piece out of the transaction. Remove the browser. I opened up terminal and did a curl of the URL and got a response. Included in the response, in the header was:
So why did the media site link to this page if it never loads? I suspect the link was old and the refresh changed after the page had been linked. Then everyone who clicked on the link on the media site, to this reloading site, probably left it running for at least a few seconds or possibly just left it running in a browser tab and waited. You get enough of these at the same time and it can look like a DoS. But as we can see, if it looks like a DoS, smells like a DoS and quacks like a Dos, it might still not be a DoS.
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.