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.
936 total views