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 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 …
- https://domain.com we know the version control server location, we can attack that later
- https:// is not an encrypted protocol, easy to sniff for if you get access to the server / company lan
- joe.blogs we have a known username we can attempt to access using dictionary / brute force / social engineering
- https:// the server could be vulnerable to CVE-2011-1921
- we know that config.php exists we can target that later for other crednetials
So assuming a worst case scenario,
- Webapp is compromised and we managed to deploy a remote shell
- Sniffing for https:// hiding silently in the background we find a site update / commit, and snag joe.blogs user credentials
- 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 …)
- Inject backdoors into all projects committing changes as joe.blogs
- Wait for co de to be deployed to production …
- 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.