14

I've had a long running conversation with a client where they perform a Rapid7 security scan which then warns about TCP MD5 checksums missing on port 80. This is what I think I know:

  • RFC 2385 was designed to protect BGP, and by extension BGP-type protocols (i.e. long running TCP connections).
  • BGP uses long-running TCP connections, HTTP does not.
  • Encryption/IPSec has superseded RFC 2385 for protecting BGP.
  • The TCP RST attack is against long running TCP connections because the attack relies on probability.
  • The impact against resetting a HTTP kept-alive connection is that the next request would restart it.
  • Most connections transfer data in milliseconds, the window of attack is too small for HTTP to effectively targeted. The attack depends on the window size and bandwidth of the attacker against the server and seem to take seconds even under good conditions according to page 25 of Slipping in the window: TCP reset attacks)
  • A web view is typically made up of multiple connections for each connected client making this type of denial of service unattractive compared to alternatives.
  • Linux (specifically RHEL or Debian) has support for rfc2385 but can't be globally enabled.
  • Neither NGINX nor Apache has configuration options to open sockets with tcp-md5-checksums enabled.
  • Even if rfc2385 was active for HTTP, it wouldn't solve a problem, but would increase load on the server. Which is only a minor side point.

I've attempted to explain that rfc2385 isn't relevant to web servers, but they are saying it's an issue with TCP which while true, simplifies that it's an attack against a specific nature of the TCP connection.

I've resorted to explaining that neither Apache and nginx can enable what they're asking for. They keep sending me knowledge base documents mentioning Windows, Cisco, NetBSD, BGP, but never anything relating to apache nor nginx.

Beyond the linked documents I've sent them LWN explaining it:

It would be hard to use this technique to shut down a web server; HTTP connections tend to be short-lived to begin with.

There is a patch available on Windows that fixes the warning which they are sending through as a suggestion, but it's clearly doesn't accomplish anything for linux.

Am I speaking nonsense? What would be your suggestion of getting the client that have security compliance to worry about to get on the same page as me?

boleslaw.smialy
  • 1,627
  • 2
  • 15
  • 25
Kit Sunde
  • 241
  • 2
  • 7
  • 1
    It sounds like you have sent the right information. There is only so much you can do with a client who just doesn't understand differences between Microsoft and other platforms... – Rory Alsop Oct 23 '14 at 09:27
  • @RoryAlsop They understand that it's not Windows the solution is just included when they re-send the proposed solution. What I'm failing on is getting them to understand both that it's not an actual problem it's a false positive and that it's not something that I can just silence. Normally I will silence anything the client asks for, no matter how petty or relevant because it's easier than having the discussion. – Kit Sunde Oct 23 '14 at 09:32
  • Does Rapid7 not let you blacklist a particular output on a specific platform (ie remove all MS vulns from the report on this server because it is Linux) – Rory Alsop Oct 23 '14 at 09:54
  • @RoryAlsop I don't know, I will look into it. After posting this I posed the question to rapid7 as well over at https://community.rapid7.com/message/15015#15015 in trying to get an official answer out of them on how to proceed. – Kit Sunde Oct 23 '14 at 10:37
  • 1
    I found (with other tools) that either I could set a config option to remove obviously invalid false positives, or else remove them manually. Both options do require the discussion with the client though, so they understand about the limitations of automated scanning tools. – Rory Alsop Oct 23 '14 at 10:43
  • If it was the right thing to do, then wouldn't google, amazon, microsoft and facebook do it? – Jonathan Jan 29 '15 at 19:13

3 Answers3

5

Using MD5 for consistency checking is a clear violation of CWE-327: Use of a Broken or Risky Cryptographic Algorithm. Any protection that RFC-2387 provided, is voided by the use of an outdated, and insecure algorithm.

Rapid7 is making the internet less secure with this recommendation. This BS "vulnerability" is more pointless noise that drowns out real findings. Rapid7's blind recommendation of RFC-2385 makes HTTP request more difficult to process, thereby making the web server more pone to DDoS attacks.

I would complain to Rapid7, and encourage them to seriously reconsider this cargo-cult security recommendation. Just because its easy to test for, doesn't mean it is relevant. Ask Rapid7 to tell your client that this isn't a concern.

rook
  • 46,916
  • 10
  • 92
  • 181
  • The use of MD5 is not a security risk in this case. MD5 is only broken against collision attacks, while attacking RFC2385 requires a preimage attack. – Mark Nov 30 '14 at 23:00
  • 1
    @Mark md5 is vulnerable to a 2nd pre-image attack. This attack is directly applicable to RFC2385, in that a malicious TCP packet could have the same checksum as an observed packet. – rook Nov 30 '14 at 23:48
  • the only preimage attack I'm aware of has a complexity of 2^123.4, which is only trivially better than brute-force. – Mark Dec 01 '14 at 01:29
2

Your depth of experience with vulnerability scanners is no doubt far beyond mine, and your experience with the intricacies of TCP even vastly more so. But perhaps I can share my general method of dealing with clients who look at a vulnerability scan result, see a yellow/orange/red icon next to an item, and have a reaction of great concern without realizing that no real problem exists there.

  1. Explain that while vulnerability scanners can sometimes be remarkable in detecting subtle-but-vital issues, they can also sometimes be absolutely idiotic about seeing problems that aren't backed by any substantive risk at all.

  2. Explain why in this case there is no substantive additional security risk at all caused by this item. (Note: This whole thing obviously assumes there isn't, of course.) In other words, explain why the scanner is wrong to pay any attention to it.

  3. Either (a) explain how you're nevertheless going to go about correcting the non-problem anyway so they can feel good about getting an (ostensible) clean bill of health from the scanner, or (b) if that's not practical, explain both why the issue can't really be practically "fixed" and how they can document (for compliance stuff, their bosses, whoever/whatever) that after through investigation & contemplation they are confident the issue is basically just a kind of false positive.

Sounds like perhaps you've got a "But ...but... the expensive tool says there's a vulnerability there!" client. Maybe try a tactic of emphasizing that even if you could implement this checksum behavior in a way the scanner would like that would take a good bit of your time (ie. their money) and potentially even require some downtime for the server. In my experience, mentioning those considerations is somehow usually enough to get a client to come to a new sense of acceptance about living with a non-vulnerability vulnerability. My two cents, anyway.

mostlyinformed
  • 2,715
  • 16
  • 38
2

My answer is would be a toned down version of this: "They are suggesting we use an unencrypted shared key authentication scheme designed for another use case. Their recommendation is bizarre and useless. There are no web browsers that are able to generate the required keyed hash for each TCP segment."

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86