bugtraq - Re: ICMP spoofed source tunneling

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] [thread-next>] [day] [month] [year] [list]

Date: Thu, 23 Sep 2004 00:50:35 -0700 (MST)
From: sin <lists@...ocence-lost.net>
To: Max Tulyev <maxtul@...an.parkline.ru>
Cc: bugtraq@...urityfocus.com
Subject: Re: ICMP spoofed source tunneling


I am reposting my reply just because I noticed I originally replied with
an email address that is not on the list.

I could be wrong here-but I was under the impression that not all (?most?)
OS's did not comply w/ rfc 792 in that they do not reply with the full
data- in fact I thought part of that was the basis for OS detection via
icmp (The same reply w/ the whole message, some reply with part, some
mangle the reply, etc). So I thought in the end you may find that it
doesn't work very well on live network's, however I could be wrong here. I
briefly checked the rfc's as I couldn't remember if a host was required to
respond with the full data or not.

Either way it's still interesting, however I think overall many routers
would just silently drop your packets, and some hosts would mangle them.

just my four peso's.





On Tue, 21 Sep 2004, Max Tulyev wrote:

> Date: Tue, 21 Sep 2004 20:55:04 +0400 (MSD)
> From: Max Tulyev <maxtul@...an.parkline.ru>
> To: bugtraq@...urityfocus.com
> Subject: ICMP spoofed source tunneling
>
> ICMP spoofed source payload tunneling
>
> I. ABSTRACT
>
> Almost any device having IP stack with enabled ICMP can be used to
> be a tunnel redirector.
>
> II. DESCRIPTION
>
> Let's imagine in Net a hacker having his source server(S), destination
> server(D), and a ip-capable device - victim(V). S sends to V spoofed ICMP
> echo request packet containing IP source address of D, and the data in
> Payload.
>
> When V receiving that packet, it sends ICMP echo-reply packet to D, AND
> FORWARDS TO D ALL DATA IN PAYLOAD!
>
> Backward is the same.
>
> I spent an only hour to write working exploit attaching this to Linux
> tuntap
> device...
>
> III. ANALYSIS
>
> Where it can be used?
>
> 1. Hacker have a victim traffic to that one cost lesser than to the World.
> That way Victim will pay for traffic with other hacker's server.
>
> 2. Hacker have no access to the world at all, but have external server
> (D). For Victim can be used any neighbour device (I tried IP phone - it
> works!) or even firewall or gateway! This can make a tunnel through a
> server with completely disabled IP forwarding at all.
>
> Very high probability of their attacks is in ISPs that gives a free access
> to some networks (I know that situation exists in Ukraine - to UA Internet
> Exchange access often is free and/or at higher speed, and in home Ethernet
> networks almost all ISPs provides free access to their clients and local
> resources).
>
> IV. DETECTION
> This can be detected by observing an anomally ICMP activity, and if you
> have more than one network interfaces - by presence of spoofed packets
> that can't be in certain interfaces. Or maybe by viewing your Internet
> bill ;-)
>
> V. WORKAROUND
>
> Turning On reverse-path filtering and other antispoofed
> mechanisms. Limiting rates or even denying ICMP type 8 at all.
>
>
>
>