One thing that Drupal started doing well is masking the version of the core code. Early on, you could simply view the source of each page and right in a meta tag was the Drupal core version. Well, that makes it a little too easy for the bad guys (and pentesters) to get the known vulnerabilities for the site. It takes a little more digging. But when the site had it, it looked a little like:
<meta name=”Generator” content=”Drupal 7 (http://drupal.org)” />
I’m working on one that does not have the version in the meta tag, however the site has not merged, or consolidated the modules’ css files. That means right in the source, it lists all the modules that the site is using. It looks a little like:
<link type=”text/css” rel=”stylesheet” media=”all” href=”/sites/all/modules/cck/theme/content-module.css?Q” />
<link type=”text/css” rel=”stylesheet” media=”all” href=”/sites/all/modules/ckeditor/ckeditor.css?Q” />
<link type=”text/css” rel=”stylesheet” media=”all” href=”/sites/all/modules/ctools/css/ctools.css?Q” />
My thought on that was that the css probably changed a little when the Drupal core code changed and the module needed to be updated. So I downloaded the Drupal 6 and Drupal 7 versions of one of those css files for a module and did a comparison to what is on the site. What I found for one was that the site and Drupal 6 had the following line in the css file:
/** For IE we add the class via js; for other browsers we rely on :hover **/
The Drupal 7 version of this module’s css file does not have that line in it. So maybe the site is running Drupal 6, or maybe it’s just running an outdated version of that plugin. Not that that’s a bad thing either. But if you look a little further, we also see that each of those modules has its own README. Checking those and versions also gives a better idea of the versions.
Still, nothing rock solid, short of checking for SA-CORE-2014-005, which I will be doing too.
657 total views
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.
571 total views
On January 7th, I got to present to the OWASP Boston chapter with my “How Hackers View Your Web Site” talk. And Akamai blogged about it:
And it was listed on Meetup.com for OWASP Boston – http://www.meetup.com/owaspboston/events/219599946/
452 total views, 1 views today