Skip to main content

Exploit Development Windows Part - 4


Finding Vulnerability in Application (practice demo)


Basic Requirements

What you need to cover this module is the prior reading of the previous three modules and a virtual lab setup at your side in order to practice this workshop thoroughly.

Exploit Development Lifecycle
Analyzing Application

      How does it work? In the previous modules, we have been highlighting the fact that you need to first understand the normal behavior of the application. If you know how the application works normally, only then can you detect the abnormal activity. So I believe that you have now installed and configured
the lab setup into your machine.

Let’s play with the Free Float FTP Server.

 
     In the above figure, FreeFloat FTP Server is running normally on IP Address 172.20.10.14 and the port it is listening on is 21 TCP.

   Let’s have a look at the exploit development life cycle we explained in the previous module.

 As this is a very basic application, you don’t need to put much effort into understanding the normal behavior of the application, however, it’s a key step in exploit development.

Fuzzing

       Here begins the actual fun, let’s start fuzzing the application and reach the level where we will be able to notice the abnormal behavior of the application.
We will use Metasploit Framework to quickly use a fuzzer available in the framework for both pre and post methods to fuzz ftp servers.

The below figure explains the configuration of this fuzzer both pre and post configuration settings.


  Let’s configure this fuzzer module and start the fuzzing and notice if we can see anything abnormal in the application.


   We have increased the “startsize” and “stepsize” values in order to get the results quickly. And we have noticed that when we run the exploit, the FTP server crashes, as shown in the figure side by side for your better understanding.

 
       This really doesn’t mean that we will be able to successfully exploit the application, however, we have discovered something which can lead to a successful discovery of the vulnerability in the FreeFloat FTP Server.

   You can see that the FTP server crashes shortly after we start the fuzzing and the error shows that exception handling has not been implemented properly in the application and it looks like a buffer overflow.

  Let’s run the FTP server once again and this time, we will attach the server with Immunity Debugger to understand this more and get some more information.


Let’s attach and re-run the fuzzer to see the results.


    Once this is attached with Immunity debugger, we will run the FTP server in debug mode with Immunity and then will note the EIP value while it is normally running.


Notice the EIP value at this stage.

 
     During normal behavior, the EIP value is “7C90E514”. Let’s again crash the server and see if something changed.

 
    Great, you can see that Immunity Debugger stopped, the application is paused and EIP value is now 34694133”, which means that something has happened and we can try controlling the EIP value.

Discovering Bugs


  It’s not easy to control the EIP at this stage, so let’s do some manual coding and confirm the crash. You can see that the size of the buffer sent by fuzzer was 610 when the application crashed. Let’s do it manually and see what happens.

  For this we have written a simple fuzzer in the python programming language, as shown below.

 

        This fuzzer will send 1000 bytes of data which will be all “A”. If the fuzzer succeeds, the EIP value should be “AAAA”. So, let’s rerun the FTP server and attach it with Immunity Debugger and fuzz the server with our python fuzzer.

 
     Here you go, you can see that we have executed the fuzzer we have written EIP value with “41414141”, which is “AAAA”, as we said.

This now clearly shows that you can control the flow of the application as we have successfully overwritten the EIP Value.

     However, we don’t know out of 1000 “A” we have sent which of these 1000 “A” has gone into the EIP register? What to do now? We have the solution for this.

Popular posts from this blog

Bypassing Web Application Firewall Part - 2

WAF Bypassing with SQL Injection HTTP Parameter Pollution & Encoding Techniques HTTP Parameter Pollution is an attack where we have the ability to override or add HTTP GET/POST parameters by injecting string delimiters. HPP can be distinguished in two categories, client-side and server-side, and the exploitation of HPP can result in the following outcomes:  •Override existing hardcoded HTTP parameters  •Modify the application behaviors   •Access and potentially exploit uncontrollable variables  • Bypass input validation checkpoints and WAF rules HTTP Parameter Pollution – HPP   WAFs, which is the topic of interest, many times perform query string parsing before applying the filters to this string. This may result in the execution of a payload that an HTTP request can carry. Some WAFs analyze only one parameter from the string of the request, most of the times the first or the last, which may result in a bypass of the WAF filters, and execution of the pa...

Bypassing Web Application Firewall Part - 4

Securing WAF and Conclusion DOM Based XSS DOM based XSS is another type of XSS that is also used widely, and we didn’t discuss it in module 3. The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie, and it is also a security feature that limits scripts on different domains from obtaining cookies for other domains. Now, the XSS attacks based on this is when the payload that we inject is executed as a result of modifying the DOM environment in the victim’s browser, so that the code runs in an unexpected way. By this we mean that in contrast with the other two attacks, here the page that the victim sees does not change, but the injected code is executed differently because of the modifications that have been done in the DOM environment, that we said earlier. In the other XSS attacks, we saw the injected code was ...

Hacking - Best OF Reverse Engineering - Part7

How to Disassemble and Debug Executable Programs on Linux, Windows and Mac OS X? The Interactive Disassembler Professional (IDA Pro) is an extremely powerful disassembler distributed by Hex-Rays. Although IDA Pro is not the only disassembler, it is the disassembler of choice for many malware analysts, reverse engineers, and vulnerability analysts. The program is published by Hex-Rays (http://www.hex-rays.com), which provides a free version for noncommercial uses that is one version less than the current paid version. It is now version 5.0. IDA Pro will disassemble an entire program and perform tasks such as function discovery, stack analysis, local variable identification, and much more. IDA Pro includes extensive code signatures within its Fast Library Identification and Recognition Technology (FLIRT), which allows it to recognize and label a disassembled function, especially library code added by a compiler. IDA Pro is meant to be interactive, and all aspects of its disasse...