Results tagged “testing” from Just Another Hacker

Internet Explorer and the .NET Framework are hardcoded not to send requests for "" or  "localhost' through a proxy. So if you're testing an application that communicates with a service bound to the loop back interface it's not straight forward to intercept the traffic using Burp or another intercepting proxy. In IE9 they fixed this, by adding <-localhost> to the "do not use proxy" list will override this behavior. However if you're testing on an older version of IE you will have to use a work around.

Most articles on the web will tell you to use the IP address or machine name of the server you are testing. Which works fine if the service is bound to or the public interface. However, if the service is bound to you cannot reach the service via the machine name or the public interface IP. One option is to setup a tunnel using netcat, stunnel, socat, etc to forward requsts from the public interface to the loopback interface. Or you can use dns. The hardcoded restriction only triggers if the url has the string or localhost in it. Requests to or a domain that resolves to are sent through the proxy.

So depending on your level of access to the system, you can add an entry in c:\windows\system32\drivers\etc\hosts for l0calhost , like this: l0calhost
Or you can create a dns entry for a domain you control that resolves to If you are running bind that should look like this (remember to update the serial number too): IN A

You can now intercept the traffic for the service through the proxy by using http://l0calhost/ or

securing and accessing your lab

Now that construction of your lairs have completed you might want to visit and inspect the marvels you have created. If you paid attention in part 1 you might have noticed that we used the fictional .lair top level domain. As this is not a valid domain you will have to set your own dns. You can run your own dns server (in which case you shouldn't need thisw guide), or we can override it using the hosts file. On unix like systems (linux, mac os) you will find this file located at /etc/hosts and on windows it is c:\windows\system32\drivers\etc\hosts (You'lll need administrative/ or root privileges to change this file). I added my labs like this: localhost.localdomain localhost
# Auto-generated hostname. Please do not remove this comment. moon.lair vulcano.lair is off course the IP of my server. After changing this file you can browse to http://moon.lair and http://vulcano.lair in your browser. Once you have established access you should check that your lab embodies the characteristics you gave it, the quickest and easiest way to do this is with phpinfo. As root on your server, create a phpinfo file in the appsec lab webroot.
root@localhost$ echo "" > /var/www/appseclab/webroot/secrit.php
Now you can verify you php_flag settings by visiting the phpinfo url. Although it is the same file, the php_ directives in each virtual host allows you to change the php behaviour of each virtual host, but you knew that already. So now that you have verified that you can access the lairs and they have the special features you requested there is but one small problem, they are accessible by anyone. Sure, you've hidden them away using tricky domains and hopefully, no-one bothers to look. You could set some henchmen to monitor the apache logs and launch an all out assoult on any unfamiliar IP accessing the lair, but since hencmen are unreliable I recommend a more consistent approach. Passwords! We'll start by creating the password file using the htpasswd utility.
root@localhost$ htpasswd -m -c /var/www/appseclab/etc/.htpasswd drevil
New password:
Re-type new password:
Adding password for user drevil
root@locahost$ cat /var/www/appseclab/etc/.htpasswd
Next we add authentication to our common config.
AuthType Basic
AuthName "Beware of sharks with lazors on their headz!"
AuthUserFile /var/www/appseclab/etc/.htpasswd
Require user drevil
Now restart apache to activate your cunning password protection scheme! What could ever go wrong!?!?!?

Like all supervillan plots, there is a gaping flaw which will allow the hero to seize the day and ensure your defeat.Your lab is still exposed to the internet and the only protection offered is a password which is transmitted in cleartext over the wires. You could always enable SSL on the virtual hosts, but that only solves half the problem and could affect the behaviour of some web apps when testing them in your lab.
A better option would be to bind the virtual host to a private or internal interface and connect to it using VPN or SSH port forwarding. This will encrypt the traffic and keep your lab away from the internet.
So you want to hack the planet? Whether you want to validate the latest exploit, or do your due diligence in vulnerability research you will need a test lab. Installing, configuring and maintaining a test lab can be a serious time sink. I always aim to make repeatable tasks as simple as possible and web application security is no exception. So in the hope of making someone else's life better I have decided to share my aprroach to lab design.

Getting started

You will need the following items
  • Server/VPS/VM image running a suitable OS (LINUX IMO!)
  • Apache
  • php
  • root access
Once you have your "server" ready we'll start the lab configuration process. I use debian-likes, so if you use something else you will have to adhust the paths as needed yourself. The first thing to setup is the directory structure. Run the following commands, as root:
mkdir -p /var/www/appseclab/public_html
mkdir /var/www/appseclab/etc
mkdir /var/www/appseclab/tmp
mkdir /var/log/apache2/appseclab
chown www-data /var/www/appseclab/tmp

The next step is to create a common apache config file, I called mine /var/www/appseclab/etc/common.conf
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/appseclab/webroot
        ServerSignature Off
                Options ExecCGI FollowSymLinks
                AllowOverride None
                Order allow,deny
                allow from all

                AddHandler cgi-script .cgi

        CustomLog /var/log/apache2/appseclab/access.log combined
        ErrorLog /var/log/apache2/appseclab/error.log
        Include /var/www/
        LogLevel notice

In the /var/www/appseclab/etc directory I created two files, moon.lair and vulcano.lair with the following content:
<VirtualHost *>
        ServerName moon.lair
        Include /var/www/appseclab/etc/common.conf
        php_admin_flag register_globals on
        php_admin_flag allow_url_fopen on
        php_admin_flag allow_url_include on
        php_flag magic_quotes_gpc off
<VirtualHost *>
        ServerName vulcano.lair
        Include /var/www/appseclab/etc/common.conf
        php_admin_flag register_globals off
        php_admin_flag allow_url_fopen off
        php_admin_flag allow_url_include off
        php_flag magic_quotes_gpc on

Next we create a test file and add the lair configs to the apache configuration
echo 'Welcome to the lair!' > /var/www/appseclab/webroot/index.html
ln -s /var/www/appseclab/etc/moon.lair /etc/apache2/sites-available
ln -s /var/www/appseclab/etc/vulcano.lair /etc/apache2/sites-available
Then we enable the hosts, and restart apache
a2ensite moon.lair
a2ensite vulcano.lair
apache2ctl graceful
And then we test that it works by speaking a little HTTP
 telnet localhost 81
Connected to localhost.localdomain.
Escape character is '^]'.
GET / HTTP/1.1
Host: moon.lair

HTTP/1.1 200 OK
Date: Wed, 29 Sep 2010 07:25:26 GMT
Server: Apache
Last-Modified: Wed, 29 Sep 2010 07:19:58 GMT
ETag: "282849d-14-49160c9f4e380"
Accept-Ranges: bytes
Content-Length: 20
Vary: Accept-Encoding
Content-Type: text/html

Welcome to the lair
telnet> quit
Connection closed.
If you get connection refused at this point, there is likely an issue with your apache configuration. Check your apache error.log for details to help you fix this.

Next we move on to securing and accessing your lab.
I attended this months OWASP Melbourne meeting. It's been a while since I attended one and the talks this month were too good to miss.

Matthew Hackling - Australian Prudential Practice Guide 234
I missed the start of this thanks to my reading comprehension which saw me waste $4 on parking at Deloitte's old offices in QV. I'll be following the development on this closely.

The second presentation was
Richard Farrell - Static Source Code Analysis - What, why, when and how?
Although the world of static analysis hasn't had any earth shattering break throughs lately it was very good to see how the enterprise solution integrate and work. I wish I'd had more time to stay around and play, perhaps another time,

Looking to the future with ewts

The recent DeleGate robot.txt User-Agent String Handling Remote Overflow Vulnerability is a perfect example of the type of vulnerabilities that I hope the Evil Website Testing Suite will eventually be able to expose. This particular vulnerability would not be detected with the current version of ewts and writing a robots.txt fuzzer isn't on the top of my todo list, but it is on the list. I just saw the vulnerability release and was happy to see that these type of vulnerabilities do get some exposure.
Since my previous biweekly project has come to a halt I have decided to shelve it for now. In it's stead I have started a new sourceforge project to keep me busy. The new project is called "Evil Website Testing Suite" or ewts for short.. It was initially envisioned as a coverage testing suite for web application vulnerabilities, but after picking apart some commercial crawlers I came to the conclusion that there aren't enough malformed and evil websites out there that will allow any web interfacing code to be thoroughly security tested. This is the gap that ewts aim to fill.
No Clean Feed - Stop Internet Censorship in Australia
Creative Commons License
This weblog is licensed under a Creative Commons License.