Transcript Man in the middle attacks

A current analysis of
man in the middle (mitm)
attacks
Sachin Deodhar <[email protected]>
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
1
The scenario
Server
Attacker
Client
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
2
MITM attack scenarios TOC
Different attacks in different scenarios:
LOCAL AREA NETWORK:
- ARP poisoning
- DNS spoofing
- Port stealing
- STP mangling
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
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
3
MITM attack techniques
The local scenario
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
4
Local attacks (1)
ARP poisoning
ARP is stateless (we all knows how it works and
what the problems are)
Some operating systems do not update an entry if it
is not already in the cache, others accept only the
first received reply (e.g. Solaris)
The attacker can forge spoofed ICMP packets to
force the host to make an ARP request. Immediately
after the ICMP it sends the fake ARP reply
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
5
The scenario
Gratuitous ARP (forged)
Server
Client
Attacker
Gratuitous ARP (forged)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
6
Local attacks (1)
ARP poisoning - Tools
ettercap





(http://ettercap.sf.net)
Poisoning
Sniffing
Hijacking
Filtering
SSH v.1 sniffing (transparent attack)
dsniff (http://www.monkey.org/~dugsong/dsniff)



Poisoning
Sniffing
SSH v.1 sniffing (proxy attack)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
7
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)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
8
Local attacks (2)
DNS spoofing
If the attacker is able to sniff the ID of the DNS request,
he/she can reply before the real DNS server
MITM
HOST
serverX.localdomain.in
DNS
10.1.1.1
10.1.1.50
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
9
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)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
10
Local attacks (2)
DNS spoofing - countermeasures
YES - detect multiple replies (IDS)
YES - use lmhost or host file for static
resolution of critical hosts
YES - DNSSEC
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
11
Local attacks (3)
STP mangling
It is not a real MITM attack since the
attacker is able to receive only
“unmanaged” traffic
The attacker can forge BPDU with high
priority pretending to be the new root of
the spanning tree
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
12
Local attacks (3)
STP mangling - tools
Ettercap (http://ettercap.sf.net)
 With the Lamia plugin
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
13
Local attacks (3)
STP mangling - countermeasures
YES - Disable STP on VLAN without loops
YES - Root Guard, BPDU Guard.
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
14
Local attacks (4)
Port stealing
Attacker floods the switch with forged gratuitous ARP packets with the
source MAC address being that of the target host and the destination MAC
address being that of the attacker.
Since the destination MAC address of each flooding packet is the attackers
MAC 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 switch
will see packets with the same source MAC address on two different ports
and 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 the
attacker is fast enough, packets intended for the target host will be sent to
the attacker’s 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 for
the ARP reply. When the attacker receives the reply, it means that the target
hosts’ switch port has been restored to its original binding.
The attacker now sniffs the packet and forwards it to the target host and
restarts the attack ad naseum …
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
15
Local attacks (5)
Port stealing how to
1
2
3
Layer 2 switch
Gratuitous ARP (forged)
A
Attacker
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
B
16
Local attacks (4)
Port stealing - tools
ettercap (http://ettercap.sf.net)

With the Confusion plugin
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
17
Local Attacks (4)
Port stealing - countermeasures
YES - port security on the switch
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
18
Attack techniques
From local to remote
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
19
Local to remote attacks (1)
DHCP spoofing
The DHCP requests are made in broadcast
mode.
If the attacker replies before the real DHCP
server it can manipulate:



IP address of the victim
GW address assigned to the victim
DNS address
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
20
Local to remote attacks (1)
DHCP spoofing - countermeasures
YES - detection of multiple DHCP replies
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
21
Local to remote attacks (2)
ICMP redirect
The attacker can forge ICMP redirect packet in order to
redirect traffic to himself
T
G1
AT
ICMP redirect to AT
H
LAN
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
22
Local to remote attacks (2)
ICMP redirect - tools
IRPAS icmp_redirect (Phenoelit)
(http://www.phenoelit.de/irpas/)
icmp_redir (Yuri Volobuev)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
23
Local to remote attacks (2)
ICMP redirect - countermeasures
YES - Disable the ICMP REDIRECT
NO - Linux has the “secure redirect” options but
it seems to be ineffective against this attack
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
24
Local to remote attacks (3)
IRDP spoofing
The attacker can forge some advertisement
packet pretending to be the router for the LAN.
He/she can set the “preference level” and the
“lifetime” at high values to be sure the hosts will
choose it as the preferred router.
The attack can be improved by sending some
spoofed ICMP Host Unreachable pretending to
be the real router
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
25
Local to remote attacks (3)
IRDP spoofing - tools
IRPAS by Phenoelit
(http://www.phenoelit.de/irpas/)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
26
Local to remote attacks (3)
IRDP spoofing - countermeasures
YES - Disable IRDP on hosts if the
operating system permit it.
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
27
Local to remote attacks (4)
ROUTE mangling
INTERNET
GW
AT
H
The attacker can forge packets for the gateway (GW)
pretending to be a router with a good metric for a
specified host on the internet
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
28
Local to remote attacks (4)
ROUTE mangling
Now the problem for the attacker is to send packets to
the real destination. He/she cannot send it through GW
since it is convinced that the best route is AT.
AT2
D
INTERNET
Tunnel
GW
AT
H
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
29
Local to remote attacks (4)
ROUTE mangling - tools
IRPAS (Phenoelit)
(http://www.phenoelit.de/irpas/)
Nemesis
(http://www.packetfactory.net/Projects/nemesis/)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
30
Local to remote attacks (4)
ROUTE mangling - countermeasures
YES - Disable dynamic routing protocols in
this type of scenario
YES - Enable ACLs to block unexpected
update
YES - Enable authentication on the
protocols that support authentication
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
31
Attacks techniques
Remote scenarios
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
32
Remote attacks (1)
DNS poisoning
Type 1 attack



The attacker sends a request to the victim DNS
asking for one host
The attacker spoofs the reply which is expected to
come from the real DNS
The spoofed reply must contain the correct ID (brute
force or semi-blind guessing)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
33
Remote attacks (1)
DNS poisoning
Type 2 attack


The attacker can send a “dynamic update” to
the victim DNS
If the DNS processes it, it is even worst
because it will be authoritative for those
entries
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
34
Remote attacks (1)
DNS poisoning - tools
ADMIdPack
Zodiac
(http://www.packetfactory.com/Projects/zodiac)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
35
Remote attacks (1)
DNS poisoning - countermeasures
YES - Use DNS with random transaction
ID (Bind v9)
YES - DNSSec (Bind v9) allows the digital
signature of the replies.
NO - restrict the dynamic update to a
range of IPs (they can be spoofed)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
36
Remote attacks (2)
Traffic tunneling
Server
Router 1
Tunnel GRE
INTERNET
Client
Fake host
Attacker
Gateway
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
37
Remote attacks (2)
Traffic tunneling - tools
ettercap (http://ettercap.sf.net)

Zaratan plugin
tunnelX
(http://www.phrack.com)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
38
Remote attacks (2)
Traffic tunneling - countermeasure
YES - Strong passwords and community on
routers
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
39
Remote attacks (3)
ROUTE mangling revisited
The attacker aims to hijack the traffic between
the two victims A and B
The attack will collect sensitive information
through:



Traceroute
port scanning
protoscanning
Quite impossible against link state protocols
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
40
Remote attacks (3)
ROUTE mangling revisited
Scenario 1 a
(IGRP inside the AS)
A
R1
B
R2
The attacker pretends to be the GW
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
41
Remote attacks (3)
ROUTE mangling revisited
Scenario 1 b
(IGRP inside the AS)
A
R1
R3
B
R2
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
42
Remote attacks (3)
ROUTE mangling revisited
Scenario 2 a
(the traffic does not pass thru the AS)
AS 1
BGP
BG 1
AS 2
BG 2
BG 3
AS 3
RIP
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
43
Remote attacks (3)
ROUTE mangling revisited - tools
IRPAS di Phenoelit
(http://www.phenoelit.de/irpas/)
Nemesis
(http://www.packetfactory.net/Projects/nemesis/)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
44
Remote attacks (3)
ROUTE mangling revisited countermeasure
YES - Use routing protocol authentication
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
45
Conclusions
The security of a connection relies on:
 Proper configuration of the client (avoiding ICMP Redirect,
ARP Poisoning etc.)
 the other endpoint infrastructure (e.g.. DNS dynamic
update),
 the strength of a third party appliances on which we don’t
have access (e.g.. Tunneling and Route Mangling).
The best way to ensure secure communication is the correct
and conscious use of cryptographic systems
 both client and server side
 at the network layer (i.e.. IPSec)
 at transport layer (i.e.. SSLv3)
 at application layer (i.e.. PGP).
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
46
Once in the middle…
Injection attacks
Key Manipulation attacks
Downgrade attacks
Filtering attacks
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
47
Injection attacks
Add packets to an already established connection (only
possible in full-duplex mitm)
The attacker can modify the sequence numbers and
keep the connection synchronized while injecting
packets.
If the mitm attack is a “proxy attack” it is even easier to
inject (there are two distinct connections)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
48
Injection attack examples
Command injection
Useful in scenarios where a one time
authentication is used (e.g. RSA token).
In such scenarios sniffing the password is
useless, but hijacking an already authenticated
session is critical
Injection of commands to the server
Emulation of fake replies to the client
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
49
Key Manipulation in the case of
popular VPN/crypto systems
SSH v1
IPSEC
HTTPS
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
50
Key Manipulation attack
example
SSH v1
Modification of the public key exchanged by
server and client.
start
Server
KEY(rsa)
S-KEY
M
Ekey[S-Key]
Eskey(M)
MITM
S-KEY
Client
KEY(rsa)
Ekey[S-Key]
S-KEY
D(E(M))
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
D(E(M))
51
Key manipulation attack
example
IPSEC
If two or more clients share the same “secret”, each
of them can impersonate the server with another
client.
Diffie-Hellman
exchange 1 –
Authenticated by
pre-shared secret
Client
Diffie-Hellman
exchange 2 –
Authenticated by
pre-shared secret
mitm
De-Crypt
Packet
Server
Re-Crypt
Packet
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
52
Key manipulation attack
example
HTTPS
We can create a fake certificate (eg:
issued by VerySign) relying on browser
misconfiguration or user dumbness.
Client
Fake cert.
MiM
Real
Connection
to the server
Server
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
53
Filtering attacks
The attacker can modify the payload of the
packets 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 to
be adjusted)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
54
Filtering attacks example
Code Filtering / Injection
Insertion of malicious code into web pages
or mail (javascript, trojans, virus, etc)
Modification on the fly of binary files during
the download phase (virus, backdoor, etc)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
55
Filtering attacks example
HTTPS redirection
Let’s see an example
Change form destination
to http://attacker
Http post
(login\password)
Client
Auto-submitting hidden
form with right
authentication data
Http main page with
https login form
MiM
login
password
Server
Real https authentication post
Authenticated connection
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
56
Downgrade attacks for typical
VPN/crypto systems
SSH v2
IPSEC
PPTP
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
57
Downgrade attack examples
SSH v2  v1
Parameters exchanged by server and client can be
substituted in the beginning of a connection.
(algorithms to be used later)
The attacker can force the client to initialize a SSH1
connection instead of SSH2.

The server replies in this way:
SSH-1.99 -- the server supports ssh1 and ssh2
SSH-1.51 -- the server supports ONLY ssh1

The attacker makes a filter to replace “1.99” with “1.51”
Possibility to circumvent known_hosts
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
58
Downgrade attack examples
IPSEC Failure
Block the key material exchanged on the
port 500 UDP
End points think that the other cannot start
an IPSEC connection
If the client is configured in rollback mode,
there is a good chance that the user will not
notice that the connection is in clear text
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
59
Downgrade attack examples
PPTP attack (1)
During negotiation phase



Force 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 tunnels
Perform previous attacks
Force “password change” to obtain password hashes


Hashes can be used directly by a modified SMB or PPTP
client
MS-CHAPv2 hashes are not useful (you can force v1)
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
60
Downgrade attack examples
PPTP attack (2)
Force PAP from CHAP
start
Server
req | auth | chap
MITM
Client
req | auth | fake
nak | auth | pap
nak| auth | chap
req | auth | pap
req | auth | pap
ack | auth | pap
ack | auth | pap
We don’t have to mess with GRE sequences...
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
61
Downgrade attack examples
L2TP rollback
L2TP can use IPSec ESP as transport layer (stronger
than 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
IIT Kanpur Hacker’s Workshop 2004
23, 24 Feb 2004
62