Well,
There's something to the traffic that I am seeing. The payloads are
always changing and contain significantly different data. of the
payloads was packed full of X'es, the other was packed full of |'s.
Check it out.

Event: ICMP Destination Unreachable Port Unreachable
Category: misc-activity
Level: 3

Sensor: IDS-1 (1)
Date / Time: 08/15/2006 14:14:41

Module: xxx

Event ID: 5907
Event ID: 5864

Source: 82.246.252.214 : 0
Destination: xx.xx.xx.50 : 0

Dude,

In case you've failed to notice, this is an ICMP port unreachable message.
It's sent in response to a UDP packet destined for an unavailable UDP port.
The port '0' referenced in the event source/destination is meaningless as
ICMP doesn't use source and destination ports (it is always '0').

The payload of the ICMP unreachable message contains original IP header (of
the initial UDP packet) and at least 64 bits (8 bytes) of original data
datagram. The size of data echoed will vary depending on the implementation.

8/15/06, Dude VanWinkle <dudevanwinkle (AT) gmail (DOT) comwrote:

8/15/06, Julio Cesar Fort <julio (AT) rfdslabs (DOT) com.brwrote:
Dude VanWinkle,

<snip>

Looks to me like they are using port 0.
http://www.grc.com/port_0.htm
-JP

*NEVER TRUST* Steve Gibson. I bet he smokes crack. See
#gibson for more details.
--
thanks for the tip!

Still, I cant seem to help but think there is something to this port 0
thingy

<snip>

3. Port 0 S Fingerprinting

As port 0 is reserverd for special use as stated in RFC 1700. Coupled
with the fact that this port number is reassigned by the S, no
traffic should flow over the internet using this port. As the
specifics are not clear different S's have differnet ways of handling
traffic using port 0 thus they can be fingerprinted.

I guess that is just a reaction to traffic and not actual traffic via
port 0, but still nifty info

-JP

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Darren,
I did notice what type of packet it was and I also know what the
packet signifies. The issue that I am having is that there has never
been any outbound UDP activity to the host that is replying to this
network. The payloads of the ICMP packets are a bit weird too,
containing either X'es or |'s or encoded strings. What I am trying to
figure out is if anyone here recognizes these types of payloads and
knows what could be generating them?

so just to be clear

I want info about the payload not about ICMP!

Darren Bounds wrote:
Dude,

In case you've failed to notice, this is an ICMP port unreachable
message.
It's sent in response to a UDP packet destined for an unavailable UDP
port.
The port '0' referenced in the event source/destination is meaningless as
ICMP doesn't use source and destination ports (it is always '0').

The payload of the ICMP unreachable message contains original IP
header (of
the initial UDP packet) and at least 64 bits (8 bytes) of original data
datagram. The size of data echoed will vary depending on the
implementation.
>
>
>
>
8/15/06, Dude VanWinkle <dudevanwinkle (AT) gmail (DOT) comwrote:
>>
>8/15/06, Julio Cesar Fort <julio (AT) rfdslabs (DOT) com.brwrote:
>Dude VanWinkle,
>>
><snip>
>
>Looks to me like they are using port 0.
>http://www.grc.com/port_0.htm
>-JP
>>
>*NEVER TRUST* Steve Gibson. I bet he smokes crack. See
>#gibson for more details.
>>
>>
>thanks for the tip!
>>
>Still, I cant seem to help but think there is something to this port 0
>thingy
>>
>
>>
><snip>
>>
>3. Port 0 S Fingerprinting
>
>As port 0 is reserverd for special use as stated in RFC 1700. Coupled
>with the fact that this port number is reassigned by the S, no
>traffic should flow over the internet using this port. As the
>specifics are not clear different S's have differnet ways of handling
>traffic using port 0 thus they can be fingerprinted.
>>
>
>>
>I guess that is just a reaction to traffic and not actual traffic via
>port 0, but still nifty info
>>
>-JP
>>
>
>Full-Disclosure - We believe in it.
>Charter:
>Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
>

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Adriel,

I was replying to Dude VanWinkle, who's been chasing down the src/dst port 0
unnecessarily.

8/15/06, Adriel T. Desautels <simon (AT) snosoft (DOT) comwrote:

Darren,
I did notice what type of packet it was and I also know what the
packet signifies. The issue that I am having is that there has never
been any outbound UDP activity to the host that is replying to this
network. The payloads of the ICMP packets are a bit weird too,
containing either X'es or |'s or encoded strings. What I am trying to
figure out is if anyone here recognizes these types of payloads and
knows what could be generating them?

so just to be clear

I want info about the payload not about ICMP!

Darren Bounds wrote:
Dude,

In case you've failed to notice, this is an ICMP port unreachable
message.
It's sent in response to a UDP packet destined for an unavailable UDP
port.
The port '0' referenced in the event source/destination is meaningless
as
ICMP doesn't use source and destination ports (it is always '0').

The payload of the ICMP unreachable message contains original IP
header (of
the initial UDP packet) and at least 64 bits (8 bytes) of original data
datagram. The size of data echoed will vary depending on the
implementation.
>
>
>
>
8/15/06, Dude VanWinkle <dudevanwinkle (AT) gmail (DOT) comwrote:
>>
>8/15/06, Julio Cesar Fort <julio (AT) rfdslabs (DOT) com.brwrote:
>Dude VanWinkle,
>>
><snip>
>
>Looks to me like they are using port 0.
>http://www.grc.com/port_0.htm
>-JP
>>
>*NEVER TRUST* Steve Gibson. I bet he smokes crack. See
>#gibson for more details.
>>
>>
>thanks for the tip!
>>
>Still, I cant seem to help but think there is something to this port 0
>thingy
>>
>
>>
><snip>
>>
>3. Port 0 S Fingerprinting
>
>As port 0 is reserverd for special use as stated in RFC 1700. Coupled
>with the fact that this port number is reassigned by the S, no
>traffic should flow over the internet using this port. As the
>specifics are not clear different S's have differnet ways of handling
>traffic using port 0 thus they can be fingerprinted.
>>
>
>>
>I guess that is just a reaction to traffic and not actual traffic via
>port 0, but still nifty info
>>
>-JP
>>
>
>Full-Disclosure - We believe in it.
>Charter:
>Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
>

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/
--
--

Regards,
Adriel T. Desautels
SN Research Team
: 617-924-4510 || Mobile : 857-636-8882

Vulnerability Research and Exploit Development
>
>
>
>
>
BullGuard Anti-virus has scanned this e-mail and found it clean.
Try BullGuard for free: www.bullguard.com
>
>
>

I'm confused about a couple things:

1) You say you knew the nature of the packet yet in your original message
you stated "Neither the source IP or the target IP have any ports associated
with them in this event. Any ideas would be appreciated.".
- The packet you dumped was an ICMP port unreachable. There will never be a
port associated with an ICMP packet.
- ICMP unreachable messages contain a payload with the IP header of the
packet generating the error and at least 64 bits (8 bytes) of original data
datagram. There are ports associated with UDP and therefore inspection of
the embedded UDP packet tells you quite a bit. i.e. It was using ports 16229
and 2597 as source and destination.

2) You * out the first 3 octets of the destination IP address in the event
but leave the IP address in the ICMP payload (70.91.131.49). Why?

Darren, my apologies. ;]

Darren Bounds wrote:
Adriel,

I was replying to Dude VanWinkle, who's been chasing down the src/dst
port 0
unnecessarily.

8/15/06, Adriel T. Desautels <simon (AT) snosoft (DOT) comwrote:
>>
>Darren,
>I did notice what type of packet it was and I also know what the
>packet signifies. The issue that I am having is that there has never
>been any outbound UDP activity to the host that is replying to this
>network. The payloads of the ICMP packets are a bit weird too,
>containing either X'es or |'s or encoded strings. What I am trying to
>figure out is if anyone here recognizes these types of payloads and
>knows what could be generating them?
>>
>so just to be clear
>>
>I want info about the payload not about ICMP!
>>
>Darren Bounds wrote:
>Dude,
>>
>In case you've failed to notice, this is an ICMP port unreachable
>message.
>It's sent in response to a UDP packet destined for an unavailable UDP
>port.
>The port '0' referenced in the event source/destination is meaningless
>as
>ICMP doesn't use source and destination ports (it is always '0').
>>
>The payload of the ICMP unreachable message contains original IP
>header (of
>the initial UDP packet) and at least 64 bits (8 bytes) of original
>data
>datagram. The size of data echoed will vary depending on the
>implementation.
>>
>>
>>
>>
>8/15/06, Dude VanWinkle <dudevanwinkle (AT) gmail (DOT) comwrote:
>>>
>>8/15/06, Julio Cesar Fort <julio (AT) rfdslabs (DOT) com.brwrote:
>>Dude VanWinkle,
>>>
>><snip>
>>
>>Looks to me like they are using port 0.
>>http://www.grc.com/port_0.htm
>>-JP
>>>
>>*NEVER TRUST* Steve Gibson. I bet he smokes crack. See
>>#gibson for more details.
>>>
>>>
>>thanks for the tip!
>>>
>>Still, I cant seem to help but think there is something to this
>port 0
>>thingy
>>>
>>
>>>
>><snip>
>>>
>>3. Port 0 S Fingerprinting
>>
>>As port 0 is reserverd for special use as stated in RFC 1700. Coupled
>>with the fact that this port number is reassigned by the S, no
>>traffic should flow over the internet using this port. As the
>>specifics are not clear different S's have differnet ways of
>handling
>>traffic using port 0 thus they can be fingerprinted.
>>>
>>
>>>
>>I guess that is just a reaction to traffic and not actual traffic via
>>port 0, but still nifty info
>>>
>>-JP
>>>
>>
>>Full-Disclosure - We believe in it.
>>Charter:
>>Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>>
>>
>>
>
>>
>
>Full-Disclosure - We believe in it.
>Charter:
>Hosted and sponsored by Secunia - http://secunia.com/
>>
>>
>--
>>
>Regards,
>Adriel T. Desautels
>SN Research Team
>: 617-924-4510 || Mobile : 857-636-8882
>>
>
>Vulnerability Research and Exploit Development
>>
>>
>>
>>
>>
>BullGuard Anti-virus has scanned this e-mail and found it clean.
>Try BullGuard for free: www.bullguard.com
>>
>>
>>
>
>

Darren,
My responses are below:

Darren Bounds wrote:
I'm confused about a couple things:

1) You say you knew the nature of the packet yet in your original message
you stated "Neither the source IP or the target IP have any ports
associated
with them in this event. Any ideas would be appreciated.".
I wasn't very clear was I, my apologies again. I understand that ICMP
packets
have no port per-sae. The ideas that I was interested in were with
regards to
the payload of the packets. In the same email I also mention that I
haven't looked
through this very extensively, I was crammed with other work. ;]

- The packet you dumped was an ICMP port unreachable. There will never
be a
port associated with an ICMP packet.
right.
- ICMP unreachable messages contain a payload with the IP header of the
packet generating the error and at least 64 bits (8 bytes) of original
data
datagram. There are ports associated with UDP and therefore inspection of
the embedded UDP packet tells you quite a bit. i.e. It was using ports
16229
and 2597 as source and destination.
Right, someone said the same thing earlier (maybe it was you). I've
taken the l
iberty of blocking "any" traffic going to all of the IP addresses which
are involved
in this particular incident. Likewise I've also blocked "any" traffic
for those IP
addresses going to the affected network. Yet, the traffic keeps coming
to the
affected network.

I did run a sniffer for a while and I saw no traffic leaving the
affected network
headed for the IP addresses in question, yet they continue to send traffic
back to the affected network.

The two IP addresses are in Amsterdam and they are still sending the ICMP
packets with the interesting payloads. I'm wondering if anyone can identify
what generated those payloads. Has anyone seen similar payloads before?

The two offending IP's are:

81.99.46.113
and
82.246.252.214

2) You * out the first 3 octets of the destination IP address in the
event
but leave the IP address in the ICMP payload (70.91.131.49). Why? \
Force of habit. ;]

--
--

Thanks,
Darren Bounds

8/15/06, Adriel T. Desautels <simon (AT) snosoft (DOT) comwrote:
>>
>Darren,
>I did notice what type of packet it was and I also know what the
>packet signifies. The issue that I am having is that there has never
>been any outbound UDP activity to the host that is replying to this
>network. The payloads of the ICMP packets are a bit weird too,
>containing either X'es or |'s or encoded strings. What I am trying to
>figure out is if anyone here recognizes these types of payloads and
>knows what could be generating them?
>>
>so just to be clear
>>
>I want info about the payload not about ICMP!
>>
>>
>

starting to think that, there's an awful lot of traffic tho.

Valdis.Kletnieks (AT) vt (DOT) edu wrote:
Tue, 15 Aug 2006 18:53:09 EDT, "Adriel T. Desautels" said:

>Darren,
>I did notice what type of packet it was and I also know what the
>packet signifies. The issue that I am having is that there has never
>been any outbound UDP activity to the host that is replying to this
>network.
>
>
Backscatter reply to a spoofed packet source address?

<off list>

Tuesday 15 August 2006 21:45, Dude VanWinkle wrote:
Still, I cant seem to help but think there is something to this port 0
thingy

<snip>

3. Port 0 S Fingerprinting

As port 0 is reserverd for special use as stated in RFC 1700. Coupled
with the fact that this port number is reassigned by the S, no
traffic should flow over the internet using this port. As the
specifics are not clear different S's have differnet ways of handling
traffic using port 0 thus they can be fingerprinted.

Although the port 0 in this case is a red herring and irrelevant. Port 0
itself when used with TCP/UDP (not ICMP!) can actually be used on the
Internet. A while back I modified netcat and my linux kernel so that it would
allow usage of port 0 and was able to connect to a remote machine via TCP
with that port and communicate fine.

A few routers, especially those with firewalling abilities, such as those
commonly used in SH, reject the packets silently.

In short port 0 is "reserved" most Ss use it to mean "random" (but this is
not defined behaviour in an RFC, more of a tradition). If you do send out
port 0 packets though, many routers will allow them.

Well,
After over 100,000 alerts each with very different payloads the
traffic stopped. I do have a list of all of the dropped packets from my
firewall as well and it appears that it was hitting 3 IP addresses which
are public facing, not just one. The weird part, is that two of those
three aren't even live. So I think that this may have been noise from a
different attack

I'd be very interested in decoding the payloads for some of these.
Anyone here have any tools to do such a decode? I'd rather not do it
manual if at all possible.

Valdis.Kletnieks (AT) vt (DOT) edu wrote:
Wed, 16 Aug 2006 12:33:13 BST, Barrie Dempster said:

>Although the port 0 in this case is a red herring and irrelevant. Port 0
>itself when used with TCP/UDP (not ICMP!) can actually be used on the
>Internet. A while back I modified netcat and my linux kernel so that it would
>allow usage of port 0 and was able to connect to a remote machine via TCP
>with that port and communicate fine.
>
>
course, the poor security geek who see a TCP SYN from port 0 to port 0,
and then a SYN+ACK reply back, will be going WTF?!? for the rest of the day. :)

(Another good one to induce head-scratching is anything that does
RFC1644-style T/TCP. Anytime you see a packet go by in one direction with
SYN/FIN *and* data, and the reply has SYN/ACK/FIN and data ;)
data on it ;)

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Also,
I failed to mention that they came in bursts of 3 every 5 minutes on
the dot.

Adriel T. Desautels wrote:
Well,
After over 100,000 alerts each with very different payloads the
traffic stopped. I do have a list of all of the dropped packets from my
firewall as well and it appears that it was hitting 3 IP addresses which
are public facing, not just one. The weird part, is that two of those
three aren't even live. So I think that this may have been noise from a
different attack

I'd be very interested in decoding the payloads for some of these.
Anyone here have any tools to do such a decode? I'd rather not do it
manual if at all possible.

Valdis.Kletnieks (AT) vt (DOT) edu wrote:

>Wed, 16 Aug 2006 12:33:13 BST, Barrie Dempster said:
>
>
Although the port 0 in this case is a red herring and irrelevant. Port 0
itself when used with TCP/UDP (not ICMP!) can actually be used on the
Internet. A while back I modified netcat and my linux kernel so that it would
allow usage of port 0 and was able to connect to a remote machine via TCP
with that port and communicate fine.


>course, the poor security geek who see a TCP SYN from port 0 to port 0,
>and then a SYN+ACK reply back, will be going WTF?!? for the rest of the day. :)
>>
>(Another good one to induce head-scratching is anything that does
>RFC1644-style T/TCP. Anytime you see a packet go by in one direction with
>SYN/FIN *and* data, and the reply has SYN/ACK/FIN and data ;)
>data on it ;)
>
>
>>
>
>Full-Disclosure - We believe in it.
>Charter:
>Hosted and sponsored by Secunia - http://secunia.com/
>
>
>

you could setup a user ip redirect page and just ask the users from
this ip to fill out a form before proceeding

8/15/06, Adriel T. Desautels <simon (AT) snosoft (DOT) comwrote:
Well,
There's something to the traffic that I am seeing. The payloads are
always changing and contain significantly different data. of the
payloads was packed full of X'es, the other was packed full of |'s.
Check it out.