Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Call for Packets - Unassigned TCP Options - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Call for Packets - Unassigned TCP Options

We had a user over the weekend send us some interesting traffic primarily destineto port 80.  The TCP option used is in an option kind that appears to be in unassigned range, the sequence numbers are not changing, but the source IPs are.  They also throw in a packet here and there to destination ports other than 80 such as ports 21, 22 and 1.   If anyone is seeing something similar and has logs or preferrably packets, please send them to us.  

Lorna

165 Posts
ISC Handler
Yep - been seeing that for a few weeks. I have a small sample pcap I can send you, and just started another one for longer-term collection. What's the preferred way to get it to you? Would prefer not posting an URL in public.
PhilHagen

5 Posts
NM - just found the contact us page. sending now.
PhilHagen

5 Posts
What's the simplest tcpdump filter or snort rule to watch for this?
It's been way too long since I had to create a filter using offsets and if someone else has it, it would save me time and headaches.
Jasey

93 Posts
Hey Jason,

tcpdump -w /storage/dump -s0 -nn -Z pcap 'not src host (yourhostip) and not (port with known traffic) and tcp[tcpflags]&(tcp-syn) !=0 and not tcp[tcpflags]& (tcp-ack) !=0', optionally piped by a `grep opt' should work out of the box.[0]

Kind regards,
srm

[0] man 1 tcpdump
Jasey
1 Posts
Whatever is sending these packets may be based on the source code found here:
http://www.enye-sec.org/en/papers/playing.with.sockets.%28port.scanning%29.txt

The documentation includes examples where the sequence number above appears on every packet. The reason for this is that the programmer forgot to seed the random number generator, resulting in the same "random" number being generated every time the program is launched. Also the line of code that sets the tcp offset does not make sense to me - it looks like a kludge that may work most of the time, or may cause garbage from adjacent memory to be appended to the packet. Also it does not look like the code initializes the ACK number, which could result in garbage data going into that field.
Jasey
8 Posts
Nice catch and bears further investigating. I wonder if someone has used this code in a new tool or as is...you just gotta love a good mystery:) Thanks for sending this in!! Lorna
Lorna

165 Posts
ISC Handler
Looks like this may be the culprit? Or at least a variant of this code?
http://www.koders.com/c/fidB8A4A098EE8F34F898C75AEC374E771CE56767B2.aspx?s=printf#L102
Lorna
1 Posts

Sign Up for Free or Log In to start participating in the conversation!