ICMP spoofed source tunneling

[Max Tulyev]

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.

[Dave Paris]

At the risk of possibly sinking my foot firmly into my mouth, it appears
that you've implemented an unimplemented feature of LOKI2 (circa 1997).
ref: http://www.phrack.org/show.php?p=51&a=6

If you look in the source at the link referenced, specifically the
help() function, you'll find:

%s dest\t- redirect to another client [ UNIMPLIMENTED ]\n",

Nifty none-the-less.

Kind Regards,
-dsp

Max Tulyev wrote:

> 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.
>
>
>
>
>

[sin]

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@titan.parkline.ru>
> To: bugtraq@securityfocus.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.
>
>
>
>

[fenfire@abwesend.de]

On Wed, Sep 22, 2004 at 10:06:40AM -1000, Tim Newsham wrote:
> How does this give anonymity? When sending to the server, I must use the
> servers address as a source address. When the server replies to me, it
> must use my address as a source address.

Yes - you cannot use this in both directions:

- In the server->client direction, the server can spoof IP source
addresses.

- In the client->server direction, you need to use multi-level "anonymous
proxying", as used by several current P2P implementations (Gnutella for
queries, Freenet, GNUnet etc).

The advantage of this is that the available bandwidth can be fully utilized
in the server->client direction, but at the same time the server IP address
can remain unknown to the client. With current P2P systems, server->client
proxying significantly reduces the download bandwidth.

In practice, implementing this will be fairly complicated because you end
up re-implementing TCP over a highly asymmetric connection.

[Tim Newsham]

> On Tue, Sep 21, 2004 at 08:55:04PM +0400, Max Tulyev wrote:
> > 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!
>
> This could also be used by peer-to-peer networks to achieve sender
> anonymity. (Of course you could also directly send UDP packets with forged
> source addresses...)

How does this give anonymity? When sending to the server, I must
use the servers address as a source address. When the server replies
to me, it must use my address as a source address. Maybe the two
addresses dont appear in the same packet at the same time, but they're
there. This might fool a few people when used a few times, but it
will hardly fool everyone when it is in widespread use.

Tim N.

In-Reply-To: <20040922203047.GA16153@nenya.lan>

>On Wed, Sep 22, 2004 at 10:06:40AM -1000, Tim Newsham wrote:
>> How does this give anonymity? When sending to the server, I must use the
>> servers address as a source address. When the server replies to me, it
>> must use my address as a source address.
>
>Yes - you cannot use this in both directions:
>
> - In the server->client direction, the server can spoof IP source
> addresses.
>
> - In the client->server direction, you need to use multi-level "anonymous
> proxying", as used by several current P2P implementations (Gnutella for
> queries, Freenet, GNUnet etc).
>
>The advantage of this is that the available bandwidth can be fully utilized
>in the server->client direction, but at the same time the server IP address
>can remain unknown to the client. With current P2P systems, server->client
>proxying significantly reduces the download bandwidth.
>
>In practice, implementing this will be fairly complicated because you end
>up re-implementing TCP over a highly asymmetric connection.

I remember a discussion (in German) about this some time ago, also discussing congestion problems. See http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=2617169&forum_id=36041

Babelfish translated: http://babelfish.altavista.com/babelfish/trurl_pagecontent?url=http%3A%2F%2Fwww.heise.de%2F newsticker%2Fforen%2Fgo.shtml%3Fread%3D1%26msg_id% 3D2617169%26forum_id%3D36041&lp=de_en

Enjoy!

Hugo

[Calum]

On Wednesday 22 September 2004 11:33, fenfire@abwesend.de wrote:

> > When V receiving that packet, it sends ICMP echo-reply packet to D, AND
> > FORWARDS TO D ALL DATA IN PAYLOAD!
>
> This could also be used by peer-to-peer networks to achieve sender
> anonymity. (Of course you could also directly send UDP packets with forged
> source addresses...)

A few people started work on this. We built a crude program that would
transfer files over UDP with spoofed addresses.

http://udpp2p.sourceforge.net/ (We haven't worked on it in ages.)

Main problems? ISPs filter outbound on their routers, which can cause
problems, and the other big problem was the handshaking/acking/resending. How
can you tell the guy that you missed a packet if you have no way of
contacting him.
We used a broadcast method to perform the searches, and "ttl"s to stop it
going on for ever but we weren't sure how it would scale.

Also the ICMP is a great way of transferring data - just bounce a stream of
ICMP echo-requests off any host that returns them and has a lot of bandwidth
- google, bbc.co.uk, cisco, etc, and if you set the source address as the
target address, no-one knows who you are.

--

Random russian saying: The horse may run quickly, but it can't escape its own
tail.

pgp: http://gk.umtstrial.co.uk/~calum/keys.php
Linux 2.6.7-hardened-r7 14:42:33 up 9 days, 2:46, 1 user, load average: 2.33,
2.11, 1.94