How does it work - ARP spoofing

To understand ARP spoofing one must first understand what ARP is and how packets are transmitted in ethernet-networks.

The Address Resolution Protocol (ARP) is a communications protocol for resolving Internet layer addresses into data link layer addresses. When another host's IP address is known, and its MAC address is needed, a broadcast packet is sent out on the local network. This is the case, for example when both devices - the sender and the receiver - reside in a corporate network where layer 2 switches do the routing instead of layer 3 routers. This kind of a broadcast packet is known as an ARP request, which can be demonstrated as a question "who has this <IP-address>?" The host that is using the IP-address then responds with an ARP reply, which contains the hosts MAC address - "I have that IP. My name is <MAC-address>."

There is no method in the ARP protocol by which a host can authenticate the peer from which the packet originated. Furthermore, hosts will automatically cache any ARP replies they receive, even if they have not requested them. Even ARP entries which have not yet expired will be overwritten when a new ARP reply packet is received. This behavior creates the vulnerability which allows ARP spoofing to occur.

When attacker does ARP-spoofing, he will usually reply to the ARP requests that are directed to the default gateway. Simply, he will claim that his IP is that of the default gateways and then reply with his own MAC-address. So in ARP spoofing the MAC address is not actually spoofed. The attacker does not change his MAC-address into the default gateways MAC-address. Instead, when a device in the network asks "who has this <default GWs IP-address>?", the attacker responds with his own MAC-address. Now the traffic meant for the default gateway will be directed to the attacker. Similarly, the attacker lies to the default gateway that he possesses the IP of the original sender. Then he may choose to inspect the packets and forward the traffic in between the original sender and the actual default gateway (Man-In-The-Middle attack). He could also modify the data before forwarding it, or launch a denial-of-service attack by causing some or all of the packets on the network to be dropped.

This behavior is illustrated in the two pictures below. Because the attacker sends his ARP reply after the default gateway has sent his, that information will be updated to the ARP cache and used for the transmission of the data.

How does it work - traceroute

Traceroute is used to track the internet nodes your data packet travels through on it's way to it's destination. A few days ago I was asked how traceroute works. Even though I use it quite often I was not able to answer. So I did some studying and here are the results. 

When you give the command

traceroute www.example.com

traceroute starts sending packets to the server hosting www.example.com. For the first packet it will set the TTL (Time To Live) value to 1, and then increase it by one for the next packet. It will keep doing this until a packet finally reach the destination. 

Every packet travelling in the Internet has a TTL value. This value is decreased every time a router forwards a packet in a network. It prevents the packets from getting into an infinite loop and congesting the network. When the TTL value is reduced to zero the packet is discarded.

Traceroute is able to give a detailed hop-count and some information about the nodes, because when a router discards a TTL=0 packet, it will send ICMP "time exceeded in transit" message to the sender. Packets are sent, by default, using UDP protocol and they are destined to a random port in the normally unused port range between 33434 - 33534. When the TTL value has increased enough and the packet finally reaches its destination, the destination server will reply with ICMP "UDP port unreachable" message. This is completely different compared to the "time exceeded in transit" messages so traceroute will know a packet has reached the destination.

Below is a screen capture of UDP port unreachable messages my test machine received from a server on the same network.

This data was captured with tcpdump. You can test your traceroute and inspect the sent and received packets with the following command in linux:

sudo tcpdump -ni wlan0 -vvv 'udp or icmp'

• "-n" flag tells tcpdump not to convert addresses into names
• "-i" flag tells tcpdump which interface to use. I used wlan0 because I connect to the network using WLAN
• "-vvv" flag tells tcpdump to be very verbose
• 'udp or icmp' tells tcpdump to capture only UDP and ICMP traffic. Note that if you change the traceroute default protocol you have to change this command too.
• As a default the packets are sent as UDP, but the replys always come as ICMP.

When you inspect the traffic sent by traceroute, you will notice that it is actually sending three packets per every TTL value. This is because it will measure the round trip time to the node as an average of three packets to be more precise.

Sometimes traceroute can't get a reply from a router. This is because some of the routers are set not to reply to UDP/ICMP requests. You can change the protocol used by traceroute from UDP to TCP with "-T" flag. I have been able to get much more accurate results using TCP. If that doesn't work, you can also try "-I" flag for ICMP.

Penetration testing tools - Nmap

Nmap is THE network scanner. You can download it for free for Linux and Windows. In my opinion it is the first tool to learn for all wanna-be penetration testers (like myself). Nmap can be used to scan large networks, or even the whole Internet, but in this example we will consider a simple hypothetical home LAN to which we are presumed to be connected. This way it is also easy for you to test these commands. In this article I will first present a command and then go into detail to explain what it actually does.

There is a lot of information about Nmap here. This article is not meant to be a comprehensive guide. Rather, I will explain how the underlaying technologies work and what is their purpose. You can then apply this knowledge to fit different situations. I will only present few essential commands here. However, you can get pretty far with just these...

First command - Finding hosts

nmap -sP 192.168.1.1/24

This basic ping scan (-sP) will show you all the devices that are connected to the network and are set to reply to ICMP echo requests.

ICMP (Internet Control Message Protocol) was designed as the debugging, troubleshooting, and error reporting mechanism for IP. Such network layer protocols are not normally used by end-user applications, but ping and traceroute are diagnostic tools that make an exception to this rule. Because of their purpose, ICMP messages are very valuable. Nevertheless, in some cases network administrators want to disable these replays in order to hide servers from ping scans. In these cases you will not be able to find those servers with this command.

The part that tells Nmap to scan the whole network is the "/24" notation. Usually the home LANs have a subnet mask of 255.255.255.0, which basically has the same meaning as "/24" when it is added after an IP-address. If you are not sure of your network mask, you can type "ifconfig" into your command line, or "ipconfig" in Windows, to find out.

Let me clarify the meaning of subnet mask, because it is important to understand it here. Subnet mask divides the IP-address into two parts; the network address and the usable addresses. In our example, the subnet mask of 255.255.255.0 tells that the first three sections of the IP-address are part of the network address, and the last section contains the freely distributable addresses.  So when I tell Nmap to scan 192.168.1.1/24, it will scan all the distributable addresses of network 192.168.1.0, ie. from 192.168.1.1 to 192.168.0.255.

Okay, let's create some ground for the next command. Let's presume that with our ping scan we discovered three hosts. The first one is 192.168.1.1, which we know that is our router, because that is the norm, and because it is our default gateway (you can check your default GW in Ubuntu by typing "route -n" and in Windows with ipconfig). The other two hosts up are 192.168.1.2, and 192.168.1.3. Next we will find out more...

Second command - Comprehensive port scan

nmap -sS -sU 192.168.1.2-3 -p1-65535

Before you start this scan understand that it will take a LONG time (for me it took about 24 hours for one target). Rather than execute this fully, apply it to your situation and remove the redundant part. If you, for example, take the "-p1-65535" part off, Nmap will scan only 1000 most commonly used ports. If you were doing penetration testing on a corporate network, you would just execute something like this, and leave it running while using another computer to perform other tasks. This is the case if you want to be extremely confident that you find all open ports. Still, should be noted that normally on corporate networks the public services are running on some of the well-known ports and can be found more quickly with less comprehensive scans.

Related pro tip - when the scan is in progress and you want to know how much is left, press "t" or <enter>.

To understand the above command, it is essential to understand the three-way handshake used by TCP - the Transmission Control Protocol. When forming a TCP connection, the parties go through these three steps:

1. Opening the connection - performed by the client by sending a SYN-packet to a server
2. Reply - the server replies with a SYN-ACK-packet.
3. Confirmation - the client sends an ACK-packet back to the server. 

After this a full-duplex connection is established and the server and the client can send data to each other. With SYN scan (-sS) Nmap shrewdly takes advantage of servers responsibility to always reply to SYN-packets. If this would not be the case no service would work, because no one would be able to establish a connection... So with SYN scan you can find out if there are any services open on a host, because if there is, you will definitely get a reply.

Unless, the service is using UDP instead of TCP. UDP stands for User Datagram Protocol. Simply, it is just another way of sending packets over a network. Some services, like DNS, SNMP, and DHCP, use UDP instead of TCP. I briefly described the difference between those two in my setting up OpenVPN article, but the here the important point is that UDP has it's own set of ports. You can scan those with Nmap using the -sU command. UDP scan is much slower than the TCP SYN scan, but if you dont do it, you might miss some vulnerable services. Basically when executing UDP scan Nmap sends an empty UDP packet to a port, and based on the reply or lack of it, deduces the state of the port.

Let me quickly recall what ports are. They are the end points of connections through which data flows into operating systems. Ports are not physical, but logical constructs in sofware that identify processes and their connections. There are 65 535 ports in total, but only a fraction of them are used. The 1024 "well known" ports are reserved for protocols like HTTP, SMTP and SSH. Ports outside the well-known range are also used, but more randomly. So... If there is a public service, like FTP, running on a host the service is listening to a specific port. This means the port is open and could be exploited to gain access to the system. This is the goal we have in mind when scanning for open ports with Nmap.

For this scan I determined IP-address range for the two hosts found with the first command. The IPs 192.168.1.2 and 192.168.1.3 will be scanned. The last option "-p" determines the port range. This scan would go through all 65 535 ports on both IP-addresses. This way you can find also those services that are running on a random port number.

Okay, for the next command let's say we found out there is an open port 47291 on 192.168.1.2. Nmap will tell us that the service is "unknown".

Third command - Version discovery

nmap -sV 192.168.1.2 -p47291

If you tried the scan above, you might have noticed that the results gave some detailed information about the services running on those ports. This is because Nmap has a database of about 2,200 well-known services that usually run on their default ports. For example, the default port for SSH is 22. If port number 22 is open, Nmap will deduce it has SSH service running. However, we can find out more because real "OS fingerprinting" has not yet been conducted. Sometimes it could be that, for example, a company has prevented the use of telnet because of it's security flaws, but an employee is running telnet on port 22. In this case Nmap would deduce that SSH service is running, but with version discovery we will find out the real service. We will do that with the -sV command. Notice that we have targeted the scan on a single port on a single host that we found with the earlier scan. You can extend this as much as you like, but you might not need to.

Nmaps version discovery is an extremely clever tool, that connects to open ports and interrogates them using probes tailored for a specific service. Based on the replies it can deduce details of the service (like operating system, specific version and sometimes even the configured hostname).


Notice!
Scanning networks without permission is illegal in many countries. You can be prosecuted by law if you use these scans against wrong targets. I used to work for an Internet service provider and I know they filter their networks for scanning attempts and close down the connections for the source of those scans. In most cases this was due to botnet infection, but it could as well be your Nmap testing.

Reference

I borrowed a great book from my friend. If you want to gain in-depth knowledge about Nmap, I can definitely recommend this (though the same information is probably available at the webpage I provided in the beginning):

 

Setting up OpenVPN

On this blog post I describe how I set up an OpenVPN server on my Raspberry Pi, which is running Arch Linux, and the Open VPN client on my laptop, which is running Kubuntu. If you use different systems, you can find more information on the OpenVPN how to section.

Public Key Infrastructure

OpenVPN uses public key infrastructure (PKI) to encrypt the data traveling inside the VPN tunnel and to verify the parties concerned with the data transmission. Understanding how PKI works will help one to understand the steps in the OpenVPN set up process. Therefore, I will briefly explain the idea behind PKI.

When you want to establish a secure connection, the first thing you need to do is verify that you are "talking" to the right "person". To do this, PKI uses digital certificates. They are used to confirm that the server you are connecting to is the real server and not an impostor. Similarly, they are used to confirm to the server that you are the person you claim to be (or in this case that my laptop really is my laptop). However, these certificates are not valid unless you have a reliable authority standing behind them. That is why one needs to create a certificate authority as a part of the OpenVPN configuration process. Only the certificates verified by your designated CA will be accepted.

So, when attempting an OpenVPN connection, the client and the server will both present their CA verified certificates. If noted valid, the source material for the secret keys is generated and exchanged over SSL/TLS connection (in TLS mode). Both parties use this material to create the keys, which they will use for encrypting and decrypting data.

Installation and initial set up

Okay, let's start working... OpenVPN installing commands:

For Arch Linux:    pacman -S openvpn

For Kubuntu:        apt-get install openvpn 

If you installed OpenVPN 2.3, or newer version, you will need to install easy-rsa separately. This is done by typing

git clone https://github.com/OpenVPN/easy-rsa.git

on both machines (on Arch I had to install git first). Then you have to cd to the right directory, which in my case is /etc/openvpn/easy-rsa/easyrsa3/. Next we will initialize the PKI for the server. Lets run the command

./easyrsa init-pki

on the server machine. Then we need to create the CA using the following command:

./easyrsa build-ca

Now, as I am running these commands on my Pi, it has become the certificate authority that will have to sign all the other certificates. Next, I typed

./easyrsa gen-req OpenVPNServer

to create a request for the CA to create a certificate for the server (I named it OpenVPNServer). In my case Raspberry Pi is the CA, and it will also run the OpenVPN server. Next I typed:

./easyrsa import-req /etc/openvpn/easyrsa3/openvpnServer.req OpenVPNServer

to import the request for signing. The signing will be done with the command:

./easyrsa sign-req server OpenVPNServer

Now we have the server certificate ready. Then we need to create the Diffie-Hellman parameters for the server. Let's run:

./easyrsa gen-dh

This process took about 30 minutes to run on my Pi. Diffie-Hellman is an algorithm that can be used to share a "password" between two parties over public communication line so that even if a third party sees every message in plain text, he cannot deduce the password. OpenVPN will need DH parameters when the encryption and decryption key source material is exchanged.

Now we have the CA and the server certificates ready, plus DH parameters set up. All of this was done on my Raspberry Pi, and the initial setup is now completed. Next we need to set up the PKI on the client, and create a request for the client certificate. Let's run command

./easyrsa init-pki

on the client machine. The PKI has to be initialized for all new machines that will be connected to the VPN. Next we will create the request for the certificate:

./easyrsa gen-req ComputerName

Now we need to transfer this request-file to the CA, which in my case means the Raspberry Pi. I did this using the netcat method described below. Then, on the CA, I imported the request using command (check that the file path is correct for you):

./easyrsa import-req ~/ComputerName.req

Next, let's sign the client certificate:

./easyrsa sign-req client ComputerName

Then, we will use the netcat method in reverse to send the certificate back to the client. Plus, we need to send the ca.crt file to the client too. I also used rm to remove the redundant .req files from both of the devices.

Configuration

You can find example configuration-files from /usr/share/openvpn/examples/. Copy the one you need (ie. server.conf or client.conf) to your preferred location. I used /etc/openvpn/. Btw, you can also find the same sample configuration files on the OpenVPN webpage.

We will first configure the server, and then adjust the client accordingly. Generally, the sample configuration files provide good explanations for the settings. However, they don't tell you all. Here are my notes.

•  In case you wondered, ";" and "#" both mark the beginning of a comment on the configuration file.
• TCP or UDP?
• TCP is more reliable, but it can be a little slower. TCP will always make sure the data packet (or multiple packets, depending on the configuration) has arrived to the receiver. Only after confirmation, it will send the next packet. Whereas UDP will just send one packet after another, without confirming if they have arrived. So UDP can be faster, if the connection is reliable. However, if packets are lost, they are lost forever. There will be no retransmission. Whereas with TCP the connection problem will be noticed very quickly, and the lost packets are resent.
• Change the file paths of ca.crt, server.crt, dh.pem and server.key files to match the actual paths.
• I also modified the "push dhcp-options DNS X.X.X.X" settings to match those provided by my ISP (you can check the IP of your DNS by logging into your routers management webpage and checking the status tab). 
• Modify the push redirect-gateway option to "redirect-gateway def1"
• This will direct your traffic through the VPN

Then the following commands need to be executed in order to add the correct rules to your iptables on your server:

iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT

iptables -I FORWARD 1 --source 10.8.0.0/24 -j ACCEPT

iptables -I FORWARD -i br0 -o tun2 -j ACCEPT

iptables -I FORWARD -i tun2 -o br0 -j ACCEPT

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE

Note that these iptables rules are not permanent, but will be reset on reboot. The best way I found to overcome this problem is to first store the configuration in a file

iptables-save > /etc/iptables.conf

Next time when you log in, you can load them from the file using

iptables-restore < /etc/iptables.conf

I had some trouble making this automatic, but was finally able to do it with some help from a friend. First create a script file, eg. iptablesconf.sh, that does the above for you. You will need to insert just this into the script:

"!/bin/bash

iptables-restore < /etc/iptables.conf

Then change the owner and the group of the script

chown root:wheeler iptablesconf.sh

Next you have to edit the /etc/sudoers file. Uncomment the "%wheel ALL=(ALL) NOPASSWD: ALL" line. Now the script has the root privileges it needs to execute iptables commands and it can be run successfully at startup. You just need to add the line

bash /home/cornucopia/iptablesconf.sh

to /etc/bash.bashrc file and the script will be run. Other operating systems have different names for these files so you need to find the right one for your OS.

One more thing, you need to modify net.ipv4.ip_forward using

sysctl -w net.ipv4.ip_forward=1

On Arch Linux you can make this change permanent by adding the line

net.ipv4.ip_forward = 1

into /etc/sysctl.d/99-sysctl.conf. These options allow the data to flow through the VPN. It took a while for me to get this right. First my problem was that I was able connect to the VPN, but my traffic was not routed through it. Once I fixed this, the problem was that I was able to connect to my home network, but not to the Internet. Finally I was able to fix this, too, with the these instructions.

On the client side, you will have to change the settings to match those on the server. The client.conf contains fewer lines, and is much faster to configure. Furthermore, none of the iptables or forwarding settings need to be done there. Just remember to change the file paths to match the real locations of the files (ca.crt, client.crt and client.key).

If there are any problems, they will be stated on the command line when you try to run the program. You can create an OpenVPN session by first typing

openvpn server.conf

on the server. This will open the server and make it wait for a connection. Then type

openvpn client.conf

on the client side to establish a connection from your computer to the server.

Notice that in case you want to connect to the VPN from outside of your LAN, you need to implement some port forwarding on your router.

Netcat commands

You can use Netcat to easily transfer text-files over your LAN using two simple commands. On the receiving end type:

nc -l -p <port> -q 1 -v > text.file

This command makes netcat listen for an input, and then stores it in a text.file (the file is created during the process). The -q 1 flag tells the program to wait one second after receiving input and then terminate the connection. The -v flag tells netcat to be verbose, so you will be able to see some information about the connection.

On the sending side the command to use is:

cat text.file | nc <receivers IP-address> <port>

This command reads the text.file and then sends the output to the other device.

References

Some of the sources I used provide additional information, so I will list them here.

https://forums.openvpn.net/topic12708.html
http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
https://wiki.archlinux.org/index.php/sysctl

Pentest hackathlon event

Here is a quick summary of a hackathlon contest I participated in a few days ago. It was organized in co-operation by our university and Accenture.

The goal was to demonstrate why certain (sadly popular) bad practices can be seriously harmful to organizations information security. Additionally, I believe, Accenture screened for prospective future employees. My personal goal was to simply learn more about penetration testing.

Here are the challenges, or "stages", I was mostly involved with. All the employees presented in the following examples are fictional.


Find open ports
With basic nmap scan you could quickly see that there were two very basic ports open on the server - port 22 for SSH connection and port 80 for HTTP connection. Of course, this was too simple and I immediately realized there has to be more. So we did a comprehensive scan on all of the 65535 ports for TCP and UDP protocols. This kind of a scan takes some time to finish, but in the end one extra UDP port was found. 

Find out which operating system is used
Nmap has version discovery function (-sV), which we used to figure out which operating system is running on the server. We concentrated this version discovery on the ports we knew are open, which made the scan quite fast. The operating system was Ubuntu Linux. Additionally, we found out that there is an apache server responding to html requests on port 80, and an openssh service running on port 22.

Find the username of one of the employees
This was quite tricky for me, and we spent a lot of time to find this information. When you studied the source code of the html page displayed by the server, you could see a link to .xls document. You could open that, and notice from the url path that the document is located in "/documents/" directory. By removing the name of the document from the url path, you were able to access the documents folder. There were like five documents available for downloading. When you inspected the metadata of the documents, you found out that in most of the documents the creator was stated clearly with his/hers full name. However, in one of the pdf-documents the creator was not stated with his full name, but with his username "jkorhone".

Find a password of an employee
Before we started our quest to figure out one of the passwords, we wanted to figure out the usernames of the three other employees. This way our changes on gaining access to their server and finding a password for one of the users would be much higher.

Because the employees were introduced on the webpage, we knew that the username "jkorhone" belonged to "Juhani Korhonen". Now we knew the syntax the company used to generate the usernames of the employees. You just take the first letter from the first name and then add 7 first letters of the last name. Using this rule we deduced the usernames of the other three employees, and added all of them on a username list.

The SSH service running on the server was the only login medium we could try our username list on. To do this we used a login cracker called hydra. It tries different passwords on a username(s), and in case finds a match, informs the user. We had received a password list from the organizers, so we guessed that at least one of the passwords on that list will work. However, we did not know if we could find a match for all of the usernames, or even if all of the users are allowed an access through the SSH connection. So we had to try them all.

We provided hydra with a list of usernames and with a separate list of passwords. After running the process for quite a while a match was found. One of the four usernames matched to one of the 17000 passwords. We logged in to the machine through the SSH and gained root access. After this, one could do pretty much anything on the server. We fought the urge to issue the "shutdown now -h" command, which would close the server and prevent anyone else accessing it.
 

In conclusion

There were more challenges, but we were not able to finish those. In addition to the ones mentioned above, my team managed to crack a certain WLAN's WEP encryption using Wifite. Then, after connecting to that network, we found there a server running Windows 2003. My team members used metasploit to exploit a vulnerability on the server software and gained access to the machine.

These accomplishments took us to the second place, which was quite nice. After all, this was my first time in such a competition (and pretty much my firts time trying to hack into a system). As a conclusion, it was very fun! I will definitely practice more, and do better next time! Most importantly, I learned a lot and gained new motivation to keep improving my knowledge. Many thanks to Accenture and our university for organizing such a great event!