MD5 to fix TCP flaw

[jlcooke]

http://www.eweek.com/article2/0,,1571169,00.asp

Comments. Anyone close to this one?

[jlcooke]

Originally posted by jlcooke
http://www.eweek.com/article2/0,,1571169,00.asp

Comments. Anyone close to this one?

I'm reading this right now. http://www.faqs.org/rfcs/rfc2385.html

[jlcooke]

Originally posted by jlcooke
I'm reading this right now. http://www.faqs.org/rfcs/rfc2385.html

Every segment sent on a TCP connection to be protected against
spoofing will contain the 16-byte MD5 digest produced by applying the
MD5 algorithm to these items in the following order:

1. the TCP pseudo-header (in the order: source IP address,
destination IP address, zero-padded protocol number, and
segment length)
2. the TCP header, excluding options, and assuming a checksum of
zero
3. the TCP segment data (if any)
4. an independently-specified key or password, known to both TCPs
and presumably connection-specific

DigPar - I don't know this BGP stuff too well, but couldn't you forge a single disconnect packet though a replay attack since there is no counter or challange-response system here?

[Digital Parasite]

Originally posted by jlcooke
DigPar - I don't know this BGP stuff too well, but couldn't you forge a single disconnect packet though a replay attack since there is no counter or challange-response system here?

Are you talking to me? DigPar = Digital Parasite = Jeff Gilchrist?

I haven't really looked at BGP either so I will have to take a look and get back to you.

Jeff.

[Digital Parasite]

I'm not sure if you could just replay a disconnect packet or not since the TCP sequence number would be out of whack with the current sequence of packets. That in itself might get it rejected. Any TCP gurus out there?

It looks like they are trying to do HMAC without the MAC part adding a password before hashing the data.

The receiving end looks at the contents of the packet and then applies the "secret" password and hashes to confirm the data was valid so you could break the system by trying to find a matching string that would hash the contents of the TCP packet and itself to the included MD5 hash value. You might not have the "real" password, but you would have found one that works just as well, then you could make whatever kind of connections you wanted.

It is interesting to note that the RFC even points out that the protocol is not very strong, and that another hash algorithm like SHA-1 would be better.

[mattmcp]

Figuring out the sequence number is what this Paul Watson found he was able to do and why he published the vulnerability. The solution that some of the backbone providers used was to throw in MD5 as mentioned.

An overview of the vulnerability is on ArsTechnica

[Digital Parasite]

mattmcp: Yes he can figure out the the TCP sequence number but the question here was, can someone intercept a valid disonnect message with MD5 hashing and just replay it. In that case, you cannot change the TCP sequence number of the packet, you just resend an old packet. So I was wondering how TCP handles receiving an old packet out of the blue that doesn't match with the current sequence.

If the connection will reject an old TCP packet, then an attacker would have to figure out the new sequence number and then find some string that will give the same MD5 collision as what the password would give.

Speaking of which:

Just a quick note to announce that Paul Watson's research paper, slides and code for the much publicized "Slipping in the Window: TCP Reset Attacks presentation are now available for download.

All materials can be found on OSVDB.org at:
http://www.osvdb.org/4030
"

Jeff.