Snort: MD5 Hash - Rules Updates - Insecure?
-
I'm new to pfSense & Snort. So far, I've found it to be an excellent resource to provide additional security for my network. And importantly, if this topic has been addressed, then please point me in the direction of the answer.
Surely I can't be the only one who is curious about this issue: why does Snort rely upon MD5 to verify its rules updates? MD5 is a hashing algorithm that is fairly well established to be insecure. For example, man in the middle attacks to subvert a pfSense installation seem like a real possibility. Why not SHA-256? Anyone?
Please, let's not focus on my "man in the middle" example… rather, I'd like to know (and discuss) why the developers consider MD5 appropriate and what the possibility is of getting a stronger hashing algorithm used to verify Snort rules updates.
-
I don't think MD5 is being used for security (in the sense of a malicious action) in this case, rather more for purposes of detecting download corruption.
Regards,
-
I'm new to pfSense & Snort. So far, I've found it to be an excellent resource to provide additional security for my network. And importantly, if this topic has been addressed, then please point me in the direction of the answer.
Surely I can't be the only one who is curious about this issue: why does Snort rely upon MD5 to verify its rules updates? MD5 is a hashing algorithm that is fairly well established to be insecure. For example, man in the middle attacks to subvert a pfSense installation seem like a real possibility. Why not SHA-256? Anyone?
Please, let's not focus on my "man in the middle" example… rather, I'd like to know (and discuss) why the developers consider MD5 appropriate and what the possibility is of getting a stronger hashing algorithm used to verify Snort rules updates.
ivanhoek is correct – the MD5 hash is simply used to validate that the file downloaded correctly without corruption. The hash is also used to "signal" that an updated rules file has been posted on the VRT web site. When the locally calculated hash differs from the posted hash, the Snort package assumes a new updated rules package is available. The rules URL itself is a SSL link (https://).
Bill
-
"ivanhoek is correct – the MD5 hash is simply used to validate that the file downloaded correctly without corruption. The hash is also used to "signal" that an updated rules file has been posted on the VRT web site."
Thank you. This makes perfectly good sense. I've run across corrupted downloads of the rules already in the few weeks I've had my server running.
I had not considered this specific purpose for using a hash. Very clever, actually. However, this being the case, it brings to mind another question: why NOT, then, use a stronger hash (ie, SHA-512) to not only provide the same integrity check against download corruption or to signal the availability of new rules, but to secure the rules from intentional manipulation? I realize that https: (presumably OpenSSL or a similar open source fork?) is used to secure the connection with the client, but given the relatively recent disclosure of pervasive threats (think NSA, German BND, et al), it's not paranoia to consider the possibility of pfSense/Snort being exploited. Especially given the attractiveness of such a target.
Any thoughts?
-
I suppose it could be migrated to another hash algorithm. However, like any development change, one has to weigh the cost-benefit and allocation of resources versus working on something else. The MD5 seems to be meeting the current goals quite well, so this is unlikely to be a high priority. Also, keep in mind that there's legacy reasons associated with the decision. (MD5 was used historically)
Also, SHA and more secure algorithms are much more painful computationally, which may impact on lesser hardware. This, I believe to be a problem that we are probably way past now, at the current hardware levels.
MD5 is pretty nice for what it's being used here.
Regarding Snort rulesets.. what do you envision a malicious actor would do? Create a non-working ruleset? There's not much that they could "exploit" by affecting the ruleset. I can see the point about Pfsense images though, but once again, there's mitigation with regards to using HTTPS and even HTTP which requires a full TCP connection. It's harder than you think to change stuff in a stream over the Internet without either party noticing. It's MUCH more likely that the actual data repository is compromised instead, at which point they'd simply upload another – valid SHA-1 or even SHA-2 hash. Your client will happily validate such a hash and download the compromised image anyway.
-
Thank you. This makes perfectly good sense. I've run across corrupted downloads of the rules already in the few weeks I've had my server running.
I had not considered this specific purpose for using a hash. Very clever, actually. However, this being the case, it brings to mind another question: why NOT, then, use a stronger hash (ie, SHA-512) to not only provide the same integrity check against download corruption or to signal the availability of new rules, but to secure the rules from intentional manipulation? I realize that https: (presumably OpenSSL or a similar open source fork?) is used to secure the connection with the client, but given the relatively recent disclosure of pervasive threats (think NSA, German BND, et al), it's not paranoia to consider the possibility of pfSense/Snort being exploited. Especially given the attractiveness of such a target.
Any thoughts?
Well, you would have to take this up with the Snort VRT (Vulnerability Research Team) at Cisco (formerly Sourcefire). They are the ones that post the MD5 hashes and picked the algorithm. I can't change anything in the Snort package on pfSense until the Cisco Snort guys change things on their end. The Snort package is on pfSense is just a GUI front-end for the regular the old Snort binary which runs behind the scenes. The GUI just builds the snort.conf file for the underlying binary to use.
Bill
-
Anyway, a hash doesn't do what you think it does. All a hash does is provide integrity.
What I think you're after, is something that not only assures you the file is not corrupted, but also that it comes from the right source.
The appropriate security mechanism for that is a digital signature. You'd need a certificate to validate that signature, and a valid trust chain installed. (Just to be clear, not your certificate - but one from sourcefire or pfsense)
-
I can empathize with the issues generated by legacy compatibility concerns as well as with very slow, previous generation hardware (when calculating a more complex algorithm such as SHA-256). I can also see how this so-called 'issue' of using an now-obsolete algorithm (MD5) wasn't placed on the front burner given that the process as a whole was doing the job it was intended to do: to verify the integrity of the download against unintentional corruption.
@IvanHoek - indeed, a digital signature would do the trick to verify the identity. But so, too, should establishing an SSL connection to retrieve the update. In a back-handed way, an SSL connection verifies the identity of the author if you can trust the identity of the server of the author (ie, validate cert fingerprints with another client in another location). And yes, for purposes of this discussion, I envision a malicious actor rendering a ruleset either impotent or subverted. But the more I consider this issue, the more I realize that it's more difficult and more impractical than I first thought. MD5 might just perform the function as well as required for now.
Lastly, I agree that it would be easier to subvert the rules updates at the source rather than through a man in the middle attack which would require not only spoofing the SSL cert, but also the download's checksum. In which case, your client would trust the checksum of the downloaded file, and the legit SSL cert… and yet the rogue update would still be successfully installed. In the end, you have to trust someone.
-
"…But so, too, should establishing an SSL connection to retrieve the update."
->
https://www.schneier.com/blog/archives/2014/07/gchq_catalog_of.html->
find HAVLOCK and MOLTEN MAGMA for HTTPS man-in-the-middle -
Chemlud: Good timing! That news broke within hours of this discussion. And it validates the threat by MITM attacks.
Wondering now, though, if GCHQ or the NSA have access to the certs on file with the big CAs. Very possibly, indeed. If so, then it makes the need for a better hash than MD5 all the more important.
-
You can't defend yourself from the NSA. Hypothetically, even if you managed to defend yourself online, and they wanted something from you… All you've done is move them to act offline. Don't lose track of feasibility and reality. Yes, one can and should take measures to protect oneself, but please keep realistic threats in mind and balance other considerations.
How protected are you against a global thermonuclear war? Meteor hit? Alien invasion? Zombie apocalypse?
Not to say one shouldn't pursue stronger hashes, but just saying... Hashes don't do what you think, and worrying about the NSA is silly. There's literally nothing you could do if they really were after you.
-
i know this is a long dead topic, but to validate the concern raised. A man in the middle attack was used against my firewall to supply blank sort rules which validated as latest version in snort. The attacker stopped some time after i side loaded the real rule set. i believe it was my ISP proxy that was compromised and no i don't believe i was the real target but all of the ISP users.
-
@lost89577 said in Snort: MD5 Hash - Rules Updates - Insecure?:
i know this is a long dead topic, but to validate the concern raised. A man in the middle attack was used against my firewall to supply blank sort rules which validated as latest version in snort. The attacker stopped some time after i side loaded the real rule set. i believe it was my ISP proxy that was compromised and no i don't believe i was the real target but all of the ISP users.
If you have to get to the web through your ISP's proxy, then your security is hosed from the get-go. The Snort rules URL is an SSL-secured site, so without the proxy you can be reasonably certain you are getting to the correct site based on the SSL session setup the CURL code stem uses within the Snort GUI. With the proxy, and you trusting the proxy's certificate, then you are wide open to your ISP and then to anything or anyone that compromises your ISP.
If your ISP won't let you bypass their proxy, then I would be trying to find me another ISP!