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

Haking On Demand_WireShark - Part 5

Detect/Analyze Scanning Traffic Using Wireshark “Wireshark”, the world’s most popular Network Protocol Analyzer is a multipurpose tool. It can be used as a Packet Sniffer, Network Analyser, Protocol Analyser & Forensic tool. Through this article my focus is on how to use Wireshark to detect/analyze any scanning & suspect traffic. Let’s start with Scanning first. As a thief studies surroundings before stealing something from a target, similarly attackers or hackers also perform foot printing and scanning before the actual attack. In this phase, they want to collect all possible information about the target so that they can plan their attack accordingly. If we talk about scanning here they want to collect details like: • Which IP addresses are in use? • Which port/services are active on those IPs? • Which platform (Operating System) is in use? • What are the vulnerabilities & other similar kinds of information. • Now moving to some popular scan methods and ho...
Read more

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...
Read more

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 ...
Read more