Change Request - Additional Options and a better presentation layer for the ICMP prtocol

["Ofir Arkin" <ofir () sys-security com>]

I have compiled a little change request to Snort here. The main goal is
to have a better "presentation" layer for the ICMP protocol and to add
several options to several rule option values.

I promised this to Marty a long time ago :)


ICMP Representation - Query Messages
====================================

ICMP Echo Request and Reply
---------------------------

08/15-15:54:30.331684 172.18.2.200 -> 172.18.1.5
ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:36
Type:8  Code:0  ID:2539   Seq:1  ECHO
06 71 7A 3B 7E 0F 05 00                          .qz;~...

08/15-15:54:30.331835 172.18.1.5 -> 172.18.2.200
ICMP TTL:254 TOS:0x0 ID:53506 IpLen:20 DgmLen:36 DF
Type:0  Code:0  ID:2539  Seq:1  ECHO REPLY
06 71 7A 3B 7E 0F 05 00                          .qz;~...

This is today’s “"presentation" layer for ICMP Echo Request and Reply.


ICMP Timestamp Request and Reply
--------------------------------
08/15-15:55:12.711657 172.18.2.200 -> 172.18.1.12
ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40
Type:13  Code:0  TIMESTAMP REQUEST
17 0A 01 00 02 C5 BA 47 00 00 00 00 00 00 00 00  .......G........

08/15-15:55:12.711797 172.18.1.12 -> 172.18.2.200
ICMP TTL:254 TOS:0x0 ID:59744 IpLen:20 DgmLen:40 DF
Type:14  Code:0  TIMESTAMP REPLY
17 0A 01 00 02 C5 BA 47 02 C6 EC C1 02 C6 EC C1  .......G........

What are we missing here?
First it's the ICMP ID and ICMP Sequence numbers. Sure we have these
values in the data portion, ICMP ID 170A and ICMP Sequence Number 0100,
but it will be faster to represent them as with ICMP Echo Request and
Reply.

ICMP Timestamp mechanism is used to measure network latency.
It has three time value:

* Originate Timestamp
* Received Timestamp
* Transmit Timestamp

The originate time stamp is the time the sender last touched the message
before sending it, the receive time stamp is the time the recipient
first touched it on receipt, and the Transmit time stamp is the time the
receiver last touched the message on sending it.

The time stamp is the number of milliseconds elapsed since midnight UT
(GMT).

Why not representing these values instead of putting up hex values that
nobody really understands their meaning?

So lets add the times as well.


ICMP Address Mask Request and Reply
-----------------------------------
08/15-15:56:17.191648 172.18.2.200 -> 172.18.1.12
ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32
Type:17  Code:0  ADDRESS REQUEST
18 0A 01 00 00 00 00 00                          ........

08/15-15:56:17.191797 172.18.1.12 -> 172.18.2.200
ICMP TTL:254 TOS:0x0 ID:59746 IpLen:20 DgmLen:32 DF
Type:18  Code:0  ADDRESS REPLY
18 0A 01 00 FF FF FF 00                          ........

Here, again we are missing a better representation of the ICMP ID (180A)
and the ICMP Sequence Number (0100) representation (like with the ICMP
Echo Request and Reply messages).

Another item we can represent better is the Address Mask given in the
Reply, FF FF FF 00 which is 255.255.255.0.

This is another representation we can add to both ICMP Address Mask
requests and ICMP Address Mask replies.

It is also a good measure to test what exactly the values given in a
certain ICMP Address Mask request or reply we might see in the network
traffic are.


ICMP Information Request and Reply
----------------------------------
08/15-15:58:33.521689 172.18.2.200 -> 134.210.1.200
ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:28
Type:15  Code:0  INFO REQUEST
1A 0A 01 00                                      ....

08/15-15:58:33.741842 134.210.1.200 -> 172.18.2.200
ICMP TTL:47 TOS:0x0 ID:16501 IpLen:20 DgmLen:28
Type:16  Code:0  INFO REPLY
1A 0A 01 00                                      

The ICMP Information Request/Reply pair was intended to support
self-configuring systems such as diskless workstations at boot time, to
allow them to discover their network address.

The network address is to be given in the sourceIP address (or in both
dst and src IP addresses) with the reply.

Here we are missing representation for the ICMP ID (1A0A) and for the
ICMP Sequence Number (0100).

And of the network address...




ICMP Representation - Error Messages
------------------------------------
With ICMP error messages we have several messages that in order to
determine if they are legit or part of an attack we need decimal
representation of certain values.


Destination Unreachable Fragmentation Needed and Don't Fragment was Set
-----------------------------------------------------------------------
Generated if a router needs to fragment but cannot since the DF flag is
set.

What is important as well is the "link MTU" field value inside the error
message. It is the MTU of the interface with the slower link.

If this message will be used for a DOS attack, for example, this field
value is in need.


Redirect
--------
The field that interests us is the "Router IP Address" field value.
This field holds the IP Address of the router we need to use to route to
our original destination.

It should update our routing tables accordingly.

Again, because of several DOS attacks with this ICMP error message it is
crucial to validate the Redirect error messages. A decimal
representation x.y.c.v of the IP address will help tremendously. 



Signature Matching
==================

TTL
---
I think of the following options:

> (Bigger Than)
< (Lower Than)
< number > (A value between two values)

This is very helpful and useful with Passive Fingerprinting, and with
matching ranges.


IP ID
-----
Multiple *
Divide \

Useful with Passive Fingerprinting especially against MS based systems.


ICMP ID
-------
Multiple *
Divide \

Useful with Passive Fingerprinting especially against MS based systems.


ICMP Sequence
-------------
Multiple *
Divide \

Useful with Passive Fingerprinting especially against MS based systems.



For any of you who wish to learn more about the ICMP protocol please see
Chapter 2 of "ICMP Usage in Scanning" available from
http://www.sys-security.com/html/papers.html. 


Ofir Arkin [ofir () sys-security com]
Founder
The Sys-Security Group
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA



_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
http://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users