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) …

mod_rewrite

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 https://domain.com/.svn/entries

10
dir
1234
https://domain.com/PROJECT/tags/1.0
https://domain.com

2011-06-15T11:47:29.153442Z
1234
joe.blogs
has-props

9733698e-0000-0000-abab-ab0000000aba
^L
config.php
file

ddde986004c962d5827ca851403f96d5
2011-05-25T08:13:14.961921Z
1234
joe.blogs

Seemingly innocent right? oh how wrong you are …

  1. https://domain.com 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
</Directory>

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.

Comments