The monkey in the middle attacks
Denis Ducamp 12 february 2001
against
SSH
and
HTTPS
Monkey In The Middle
(tm)
Dug Song
by Denis Ducamp
Denis.Ducamp@hsc.fr
Denis.Ducamp@groar.org
http://www.groar.org/ ducamp/
dsniff, the tool box
Dug Song
webmitm
sshmitm
dsniff
Other tools
Libraries
Why does this work ?
Signs of an attack ?
How to protect himself ?
SSH / HTTPS
What doesn't work against sshmitm / webmitm
Conclusion
a collection of tools permitting:
to audit a network,
to perform penetration testing.
two categories of tools:
to passively monitoring the network
to catch interesting data,
to facilitate the interception of network traffic
normally non-available to an attacker.
great tools to:
educate users and administrators
,
obtain security budgets
:
show his password and his e-mail to your boss
;-)
But especially
do not abuse these tools!
even if they are portable: *BSD, Linux, Solaris, Win32.
University of Michigan:
Center for Information Technology Integration
http://www.citi.umich.edu/
Hacker
Personal coordinates:
dugsong@monkey.org
http://naughty.monkey.org/ dugsong/
Other projects:
Check Point FireWall-1 vulnerabilities
Patches:
popa3d: APOP / Kerberos v4
John the Ripper: S/Key / Kerberos v4 TGT
SSH: AFS / Kerberos v4
OpenBSD ports and audits
OpenSSH
fragrouter
The Honeynet Project
relays and saves SSH traffic redirected by dnsspoof
catches SSH access passwords
hijacks interactive sessions
only version 1 of the protocol is supported
and this will ever be the only one to be supported,
this program is far too evil already.
transparently relays and saves:
the HTTP/HTTPS traffic redirected by dnsspoof,
catches:
webmail accesses:
form submissions:
credit card numbers, etc.
even the more "secured" by a SSL encryption!
require that the client is HTTP/1.1 compatible:
emission of the Host: command in the HTTP header.
allows to catch passwords traveling in clear text,
supports more than 30 standardized / proprietary protocols:
FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase et Microsoft SQL.
strong items:
full TCP/IP reassembly,
support of asymmetrical routes,
auto-magic protocol detection,
storage in a Berkeley DB,
HTTP: QUERY_STRING and x-www-form-urlencoded parsing.
arpspoof, dnsspoof, macof:
permit interception of network traffic.
filesnarf, mailsnarf, msgsnarf, urlsnarf, webspy:
catch interesting informations:
files transfered by NFS v2/v3 with UDP/TCP
be careful about your private keys,
messages transfered by POP/SMTP, IRC/ICQ/AOL/MSN/Yahoo,
visited URL:
in a CLF log file,
live in Netscape.
tcpkill, tcpnice:
facilitate data catching.
Many libraries are needed:
libpcap - ftp://ftp.ee.lbl.gov/
capture and filter packets on the network
libnet - http://www.packetfactory.net/libnet/
generate packets on the network
libnids - http://www.packetfactory.net/libnids/
reassemble packets and sessions
libdb - http://www.sleepycat.com/ (for non-BSD/Linux systems)
saves unique authentications in a database
which permits to limit abuses :)
but a RPM package is available :(
Cryptography in HTTPS and SSH is based on
public keys cryptography
HTTPS adds trust of public keys certificates
Use of these methods is strongly constraining:
to be more acceptable, degraded modes are available
the client may "blindly" accept the server's key
the client may accept that server may have changed his key
sshmitm and webmitm use those vulnerabilities thus introduced
the session key is generated by the client
then sent it ciphered with the server's public key he just received
attacker just have to use any public / private key pair
and wait the client accept to use that public key.
password client authentication:
sent in "clear text" in the ciphered tunnel
RSA client authentication:
server sends to client a ciphered challenge with an authorized public key
client proves he knows the private key by unciphered the challenge
sshmitm imposes authentication by password in sshv1.
the session key is generated by the Diffie-Hellman protocol:
the server authenticates by signing a fingerprint of exchanged messages
client authentication uses same methods as sshv1
the attack is always possible by a mitm attack against the DH protocol
sshmitm doesn't implement sshv2
The server's key is accompanied by a certificate:
this certificate has been signed by a "known" authority,
the browser accept the certificate only if intended to the visited site,
but the user may accept it.
this certificate may be signed by an "unknown" authority,
the browser doesn't accept the authority,
but the user may accept it.
Signs of the attack are perfectly visible in all the cases:
SSH
the public key has changed
HTTPS
the certificate is destined to another server
the certificate is signed by an unknown authority
$ ssh -p 2222 groar
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
Please contact your system administrator.
Add correct host key in /home/ducamp/.ssh/known_hosts to get rid of this message.
With an OpenSSH client:
Password authentication is disabled to avoid trojan horses.
Permission denied.
With a SSH client:
Agent forwarding is disabled to avoid attacks by corrupted servers.
X11 forwarding is disabled to avoid attacks by corrupted servers.
Are you sure you want to continue connecting (yes/no)? yes
ducamp@groar's password:
Bad certificate
the certificate doesn't match to the requested domain name,
this certificate may have been signed by a known authority.
Unknown authority
the certificate have been signed by an unknown authority,
this certificate may correspond to the asked domain name.
This certificate has been get accessing to www.groar.org ...
... whereas it has been generated for sos.groar.org
The certificate is signed by an unknown authority...
...and risks of fraud are indicated by Netscape.
Do not use degraded modes
always know the key of its interlocutor as a preliminary
systematically check the key of the other party
immediately stop the connection in the event of anomaly
Caution:
numerous recommendations
aren't serious
!!!
except for slashdot readers, a quotation of Dug Song:
argh! it's amazing how silly some people are. Slashdot readers are especially numb-skulled, if their insistence that SSH2 would prevent such attacks is any indication.
i'll add compression support when i get a free second.
Before the first connection the client must:
recover the server's public key
eventually make deposit its public key on the server
At each connection the client always must:
force a strict check of the server's key
mandatory condition for a password authentication
hoax #1 : use sshv2
today
only the v1 protocol have been implemented
in the case of a
password authentication
:
sshv2 is
as vulnerable as
sshv1
private versions have / will be implemented
hoax #2 : use compression in ssh
today
compression haven't been implemented yet
which may prevent the attacker to monitor the session and to hijack it
but not to catch the password
private versions have / will be implemented
An authority is known only at this single condition:
the authority's public key must be entered in the browser.
Do not accept keys signed by a known authority,
if the key isn't intended to the visited site.
Do not accept keys signed by an unknown authority,
even if the key is intended to the visited site.
even if the authority's name corresponds to a known authority.
hoax #3 : use old browser without the Host: command
today
needed functionalities haven't been implemented yet
this ask for specific code to each platform
private versions have / will be implemented
The main problem is user's education:
signs of the attack are visible,
but their consequences are ignored.
Must follow the set up of an organization permitting:
distribution of public keys
servers' keys to users
a web server with signatures of public keys
users' keys on accessed servers
a mailing-list permitting deposit of keys
Thanks to Dug Song for the work he achieved
and for the conscientiousness those tools permit.
Thanks to Ghislaine Labouret for review
:)
Original site:
http://naughty.monkey.org/ dugsong/dsniff/
FAQ (Frequently Asked Questions):
http://naughty.monkey.org/ dugsong/dsniff/faq.html
Mailing list:
echo subscribe | mail dsniff-request@monkey.org
French translation
of manuals and FAQ (Frequently Asked Questions):
http://www.groar.org/ ducamp/#sec-trad
You may ask your questions...
and make know your remarks...
then discretely wake up those sleeping ;-)
Bye, bye...
(c) 02/2001 Denis de service
:)
[tm]
