Anda di halaman 1dari 16

James Colley

IT443
Lab 3
14 Mar 2018

1. I will be using my own machines while conducting this lab. Here is the Dell Army. On the far left with the
Windows XP background is the “target” machine running Ubuntu. The middle machine will be acting as the
“client” and visit the web page that is being served by the target’s Apache2 web server. The far right machine
cost $80 on Amazon, and is running 32 bit Ubuntu 14. It will be the “attacker”.

In order to conduct this experiment at home, I had to adjust some of the settings in my home router (firewall and
IP Flood Detection).
Here is the target machine’s IP address (192.169.0.18) and “ifconfig” output. The Apache web server is also
started. Again this is the machine on the far left in the photo shown above:

Here is the attacker’s IP address (192.168.0.22) and “ifconfig” output. Again this is the small machine on the far
right in the first photo shown above:

2
The tcpsyn_cookies flag was set to 0/False as instructed on the target:

1. A normal TCP connection uses the 3-way handshake consisting of a SYN, SYN-ACK, and then an ACK. The
entire process takes less than a second. The packet sizes for the SYN, SYN-ACK, and ACK are 74 bytes, 66
bytes, and 66 bytes. The target (192.168.0.18) sends a SYN to the IP address 104.97.14.40. That IP address then
sends back SYN-ACK. The third step of the connection-oriented handshake is when the client sends back one
last ACK to complete the connection. When the connection is terminated, a FIN is sent although not shown
below. Here is a normal TCP connection being created:

The tcp_syn backlog as well as open TCP connections are shown below prior to the SYN Flood attack. Note that
my home computer’s Ubuntu version (the target) has a backlog size of 128. This is different than the size of 512
found in the Ubuntu Seed versions in the UMASS Boston IT Lab. While this size can be adjusted, I decided to
keep the default size of 128. The command “netstat -na” was issued with an additional option “--tcp” to only
show TCP connections:

3
2. Now the attack can begin. I had some issues with “netwox” on my home configuration. I discovered the Linux
tool “hping3” which stands for “hellping”. This tool also does several attacks, including a SYN-flood attack with
spoofed IP addresses. This tool is more current and better maintained than “netwox”: I decided to use it with
Professor Ghinita’s permission:

Note that the “--rand-source” parameter is used to spoof the IP addresses. I had no issues getting this to work
after adjusting the settings in my router.

4
2a. While the attack was occurring, I tried to access the page that was being served from the target via the client
machine (the machine in the middle) at the target’s website IP, 192.168.0.18. The page would not load as shown
here:

However as soon as the command “ctrl-c” is entered on the attacker machine to stop the denial of service, the
web page loaded immediately on the client machine:

5
2b. This screenshot of the target machine shows the number of SYN_RECV before the attack starts, and then the
number of SYN_RECV while the attack is occurring. It also shows the first 30 lines of netstat’s output before
and after the attack:

6
2b/c. The command “netstat -na –tcp | tail -n+3 | wc -l” gives the output of 7 before the attack, and 104 during
the attack as shown above. This command is useful, however not entirely accurate if attempting to count the
number of SYN_RECV/half-opened TCP connections. This command counts all the TCP connections including
the first 7 connections in the “LISTEN” and/or “ESTABLISHED” state. There are many ways to get the count of
SYN_RECV lines. However I decided to write a very small, object-oriented Python script to count the number
of SYN_RECV lines. The script “count_syn_recv.py” can be found in the current working directory. It can be
ran as follows:

netstat -na | ./count_syn_recv.py

It receives Standard Output from any piped Bash command, however it is meant to receive output from “netstat”.
It gets the correct count of half-opened TCP connections, and does not include a TCP connection unless it’s state
is “SYN_RECV”. The code finds 97 entries as shown above. This makes sense as the “netstat -na –tcp | tail -n+3
| wc -l” command yields a total of 104 (a difference of 7). The Python script will give an exact count and will
also help prove the backlog size of 128 in the next part of this lab. Here is a glimpse of the code:

7
2d. A TCP Flood attack takes advantage of a flaw in this handshake process. A half-open connection is a
connection in the SYN_RECV state, and waits a period of time for a final ACK to be sent back. The attacker
never plans on closing this process by sending back the final ACK. The queue gets overloaded causing a denial
of service/unresponsive server because the connection was never completed: The spoofed Source IP cannot
respond back with the final ACK to finalize the handshake. Therefore the backlog of half-opened connections
builds up. Here is a screenshot of the target capturing the attack via Wireshark:

There are many SYN packets being sent to the target (Destination) at 192.168.0.18 from many different spoofed
IP addresses (Source).

3. The backlog is set to a number that will prevent the hosts available memory from being hoarded by the
unfinished connections. My system is set to 128 as previously mentioned. When the flag is set back to 1, some
interesting results become apparent regarding the backlog size.

8
The attack was then again initiated from the 192.168.0.22 machine. These commands were run from the target
(192.168.0.18) as before:

netstat -na –tcp | tail -n+3 | wc -l → results show 135 TCP connections
netstat -na | ./count_syn_recv.py → results show 128 half-opened connections

Now that the tcpsyn_flag is set to 1, the backlog of half-open connections in the “SYN_RECV” state will never
exceed 128. This is apparent when the above commands are run during the second attack:

Again there is a difference of 7 connections as the TCP connections in a “LISTENER” state are excluded in the
Python script, resulting in 128 half-opened connections. Another important occurrence is that there was
absolutely no issues opening up the web browser from the client machine during the second attack (with
tcpsyn_flag set to 1). The default Apache page opened and loaded without issues.

9
2. For the ARP-poisoning/man in the middle attack, I used the same setup. However there was no need for the
machine in the middle. The machine on the far left was again the target (192.168.0.18), and the machine on the
far right was still the attacker (192.168.0.22):

Here is the target machine’s ARP table after pinging the attacker at 192.168.0.22 and the unused client (middle
machine) at 192.168.0.7. The router’s gateway is also visible at 192.168.0.1, however I censored my public IP
address:

10
Next on the attacker machine at 192.168.0.22, IP forwarding was then enabled (in order to get this command to
save properly, I had to pass the command as an argument to Bash):

Then etter.conf was edited for Linux on the attacker machine. Here is confirmation that the file has been edited
correctly. ** The color of my bash console changed (shown below) as it was my second console window to be
opened concurrently as root. I used the following command to verify the four lines after editing the file:

cat /etc/ettercap/etter.conf | grep -i “redir_command_on = \”ip” | head -2


cat /etc/ettercap/etter.conf | grep -i “redir_command_off = \”ip” | head -2

11
Then within Ettercap unified sniffing for the wireless card was selected, a scan for hosts was ran, the
192.168.0.18 target was added to “Target 1”, Mitm/ARP poisoning was chosen, and then finally sniffing was
started (the router’s public IPv6 address has been censored):

12
Here is the ARP table on the target machine (192.168.0.18):

1. For ARP-poisoning to work, the router’s MAC address has to be spoofed as well (Fouant 1). Ettercap sends
out gratuitous ARP messages to all hosts on the private network resulting in the spoofed MAC address for each
host (1). The router especially needs to be “poisoned” or else the entire exchange will not be captured on the
attacker’s machine (1). Therefore all hosts in the target’s ARP table have the attacker’s MAC, and this is visible
in the screenshot above. The target’s ARP table has been poisoned with the MAC address of the attacker. For this
reason it may also be a good idea to spoof the attacker’s MAC address prior to beginning an ARP-poisoning
attack (1). When accessing the web browser from the target machine, http://cs.umb.edu was visited and the
packets were captured. Data was received in Wireshark on the attacker machine, however since I was forced to
add the exception for SSL, I could not see plain-text/strings within Wireshark on the attacker.

13
I then decided to visit a different web-page that did not require https/SSL. I visited htmldog.com and entered my
name into the search bar on the form (james loye colley). When the form sent on the target machine, the attacker
was able to see the http message in Wireshark.

On the target machine:

On the attacker machine:

My name was sent on the form from the target machine while visiting htmldog.com, and was clearly visible on
the attacker machine as shown above. The packet capture is saved in the current working directory as
“Lab3_packet_cap.pcapng”.

14
Here is a Wireshark capture from the target machine displaying only ARP packets :

2a. In the Wireshark capture above, there are several ARP requests from the router beginning with “who has”
such as lines 183 and 184. The target/client also makes a request on line 234. It asks the router who has the
default gateway of 192.168.0.1. Then on line 236 a reply is sent that is not a poisoned MAC address. The source/
Netgear router tells the target/Destination/TCP-Link (my external WIFI card) the correct MAC address for the
192.168.0.1 gateway (b0:7f:b9:67:b8:cb). However following line 236 all the replies sent back to the client are
from the attacker at 192.168.0.22. This is evident from the source which is listed as HonHaiPr_46:8b:fb. The
“46:8b:fb” being the second half of the attacker machine’s MAC address.

2b. The client/target’s ARP request on line 234 was first answered with a correct MAC address. However
following this line, all the responses are sent from the HonHaiPr attacker machine. There are about 35 responses
after line 234 sent from the attacker to the target, all containing the attacker’s MAC address.

2c. As mentioned before there are spoofed replies and valid replies. The main valid reply comes as soon as the
target asks the router “who has 192.168.0.1?” on line 134. The following reply from the router is the router’s
correct MAC address. But after that all replies back contain spoofed MAC addresses. They can be identified by
the attacker’s MAC address found in the reply: “192.168.0.1 is at 7c:e9:d3:46:8b:fb”. The attacker’s MAC
address is “7c:e9:d3:46:8b:fb”. One can also tell by looking at the Source field. “HonHaiPr_46:8b:fb” is the
attacker. The “46:8b:fb” is the second half of the attacker machine’s MAC address/OUI.

2d. The attacker gratuitously sends the same false MAC address for each host on the network to the target. This
seems like it is attempting to combat any real MAC address replies that are broadcast to the target. Also this
makes the target unable to send messages to anyone on the network except the attacker. As far as the target and
the compromised network are concerned, the default gateway of 192.168.0.1 now uses the attacker’s MAC
address. From line 241 and downward the attacker (Source) is telling the target (Destination) that each and every
host on the network “is at” the attacker’s MAC address; the default gateway is the attacker. The gratuitous
replies are sent in the same order/group repeatedly after the router (Netgear_67:b8:cb) replies to the target with
its correct MAC. The gratuitous replies arrive repeatedly in this order: 254.128.0.0, 192.168.0.21, 192.168.0.7,
254.128.0.0, 192.168.0.5, 192.168.0.1.

15
Works Cited

1. Fouant, Stefan. “Man in the Middle (MITM) Attacks Explained: ARP Poisoining.”
ShortestPathFirst, 18 Nov. 2010, http://www.shortestpathfirst.net/2010/11/18/man-in-the-
middle-mitm-attacks-explained-arp-poisoining/. Accessed 13 Mar 2018.

16

Anda mungkin juga menyukai