Cloaking Your Web Apps - Ninja Vanish

Bad TMNT reference I know but with a reboot coming what do you expect realy?

Right so you have hidden your versions via The Hooded Apache so what now?

Well no matter what you do if your url’s contain .php / .asp / .cfm (Frankly if you are using coldfusion you deserve what you get … just saying …)

You are disclosing what your webapp is using as it’s server side language, now to be clear this hiding is only going to be effective if you are using a bespoke webapp, and not say Joomla / Wordpress as they are easily identifiable via other means (for another post) …


Learn this, I mean seriously not only can it help cloak your server side language but you can do so using SEO urls.

BUT be careful if you think you’re being cleaver by having mod_rewrite change the extension alone …

RewriteEngine On
RewriteRule (.*)\.inc$ $1.php [L]

it will be easy to enumerate the back end language this way … the first 404 that an attacker gets when enumerating your file names will reveal this rule i.e.

“The file /asfasdgasdg.php was not found on this server” … yeh …

Change the extension entirely

Security through obscurity? you bet your ass, just add your new extension onto your AddType declaration, because you are already avoiding the dual extension vulnerability right?

how about .wtf

AddType application/x-httpd-php .php .phtml .wtf

Now just name your files .wtf instead of .php

So your using subversion good for you! you can use subversion as part of PCI 11.5 (iirc) to enforce file integrity assuming of course you have your subversion deploy setup securely just one tiny problem …

curl -s





Seemingly innocent right? oh how wrong you are …

  1. we know the version control server location, we can attack that later
  2. https:// is not an encrypted protocol, easy to sniff for if you get access to the server / company lan
  3. joe.blogs we have a known username we can attempt to access using dictionary / brute force / social engineering
  4. https:// the server could be vulnerable to CVE-2011-1921
  5. we know that config.php exists we can target that later for other crednetials

So assuming a worst case scenario,

  1. Webapp is compromised and we managed to deploy a remote shell
  2. Sniffing for https:// hiding silently in the background we find a site update / commit, and snag joe.blogs user credentials
  3. Exploiting CVE-2011-1921 we enumerate all projects on the svn server (If we even have to … joe.blogs could have access to everything anyway …)
  4. Inject backdoors into all projects committing changes as joe.blogs
  5. Wait for co de to be deployed to production …
  6. And now you have backdoors into multiple projects

You can prevent this by …

<Directory ~ "\.svn">
Order allow,deny
Deny from all

Or using mod_security

SecRule REQUEST_URI "\.svn" phase:1,deny

Ensure you use an ENCRYPTED protocol for your version control https:// / ssh+svn:// for example with subversion.