Possible TCP signature generation issue due to type mismatch

[boazwasserman]

There are many TCP signatures which have the 'T' oddity, for example in the signature below: https://github.com/xnih/satori/blob/063782388e02b1b5bd577ef2e620a42238bf6483/fingerprints/tcp.xml#L1014

By looking at the code that generates these oddities, I noticed that the 'T' oddity is added in one of two cases:

1. The TCP packet is a syn/ack packet and the 'T' option was identified in the TCP options
2. The TCP packet is a syn packet and the tcpTimeStampEchoReply != 0

The potential issue is in the second case: https://github.com/xnih/satori/blob/063782388e02b1b5bd577ef2e620a42238bf6483/satoriTCP.py#L225-L226 where the variable _options_er holds the echo reply value from the TCP options.

The tcpTimeStampEchoReply value is defined to be '' (an empty string) and is only populated if the TCP timestamps option is found within the parsed TCP options. However, the check for syn packets checks whenever this value is != 0 as seen above. So this check will evaluate to true for all syn packets that do not have the TCP timestamps option, because in those cases tcpTimeStampEchoReply == '' != 0.

I wanted to ask and verify whether or not this is the expected and intended behavior, as it affects which packets are parsed to signatures that have the 'T' oddity.

Thanks!

[xnih]

This code was written and initially based off my understanding of p0f v1 back in the early 2000's:

• Quirks section is usually an empty list ('.') of oddities or bugs of this
• particular stack. List items are not separated in any way. Possible values:
• P - options past EOL,
• Z - zero IP ID,
• I - IP options specified,
• U - urg pointer non-zero,
• X - unused (x2) field non-zero,
• A - ACK number non-zero,
• T - non-zero second timestamp,
• F - unusual flags (PUSH, URG, etc),
• D - data payload,
• ! - broken options segment.

T = "non-zero second timestamp" there, but with that said it sounds like it really needs looked at and potentially rewritten to do what was actually desired here. Though with that said the fingerprints still should be accurate here so even with the bug it hopefully isn't causing any actual issues with detection.

Thanks for the deep dive and information here, it gives me some good starting points!