Snort Updated today
Thanks for the heads-up to our reader Bill, who pointed out that Snort 2.9.3 is just released, details are here ==> http://blog.snort.org/2012/07/snort-2930-has-been-released.html
A couple of new features, and lots of changes to existing ones, the release notes are well worth the read !
===============
Rob VandenBrink
Metafore
Vote NO to Weak Encryption!
This topic is likely more important than the Weak Key story I published earlier. Unfortunately, we all DO get a vote on weak encryption, and almost everyone votes wrong - - enabling the defaults, which include easily attacked crypto algorithms.
I do a fair number of security assessments, and invariably I find servers that support "weak ciphers". What this means is that encryption using weak algorithms is supported, methods such as the ones below (taken from a recent assessment):
SSLv2
EXP-RC2-CBC-MD5 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
SSLv3
EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-RC2-CBC-MD5 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
TLSv1
EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-RC2-CBC-MD5 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
Note that no matter what the hash (MD5 or SHA1), the encryption is all using symmetrical algorithms with a 40 bit key(!), also the Key Exchange (Kx) is 512 bits for each. And yes, you can still implement weak encryption in SSLv3 and TLS - why we all decided that should be in the default set for these newer protocols is beyond me! We're (mostly) past the days where we need to worry about our customers being subject to the old export regulations that limited them to 40 or 56bit encryption (full disclosure - there are still a few exceptions).
The problem is that until very recently, support for these weak encryption methods was part of the default installation - so if you run setup and press enter or "OK" 15 times, this is what you'll have. An attacker only needs to downgrade your encryption, either during the initial negotiation or by triggering a renegotiation, and they can decrypt your data. With the right tools the decryption of these algorithms can be almost real-time.
The sad thing is that, while it's very easy to disable these algorithms, almost every server you'd care to check still supports them. Mostly because folks don't know that they are there, don't know what they are, or don't know what the risks are. Or don't care (though people are starting to come around on caring about it)
I'm hoping that Microsoft's recent emphasis and patches on weak keys will trigger some interest in what's going on inside our corporate webservers.
... Because if the application and the information is important to your organization, it should be considered important enough to protect properly!
===============
Rob VandenBrink
Metafore
Vote NO to Weak Keys!
OK, so I'm a bit off base with the title - we don't get a vote, but that's a good thing!
As part of the August patch cycle (just 3 weeks away), Microsoft will be pushing out a patch that will block all RSA keys under 1024 bits in length. This will affect the whole fleet - Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. This is being done in the certificate store, so it'll affect all Microsoft encryption services (the most visible being IE).
Their blog entry on this patch is here:
http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx
They highlight the more common issues that folks may see:
- Error messages when browsing to web sites that have SSL certificates with keys that are less than 1024 bits
- Problems enrolling for certificates when a certificate request attempts to utilize a key that is less than 1024 bits
- Creating or consuming email (S/MIME) messages that utilize less than 1024 bit keys for signatures or encryption
- Installing Active X controls that were signed with less than 1024 bit signatures
- Installing applications that were signed with less than 1024 bit signatures (unless they were signed prior to January 1, 2010, which will not be blocked by default).
Those last two I hadn't thought of until I read this article - I could see lots of organizations being vulnerable on application and ActiveX signing and not realizing it. (many companies don't realize that they are even using signed applications or controls!)
Not only does the blog describe the patch, and the possible issues, but they go through the steps organizations should make to assess any internal (or external) web applications and services, to ensure that they'll still work post-patch.
The follow-on blog entry covers how to implement work-arounds to permit continued operation. Their approach uses (of course) certutil.exe, the command line certificate utility that is in all affected versions of windows. Find this follow-on blog here:
http://blogs.technet.com/b/pki/archive/2012/07/13/blocking-rsa-keys-less-than-1024-bits-part-2.aspx
Hopefully the impact of this change will be minimal. Remember that the 1024 bit keys in question are in the certificate, so these are the keys used to secure the initial authentication of an SSL conversation. These keys are not the used in the subsequent cipher that encrypts the actual data. Most of the public CAs (Certificate Authorities) all moved to longer keys quite some time ago, so support for weak keys within the certificates is likely a legacy issue, one that will mostly be seen on poorly implemented internal CA infrastructures.
===============
Rob VandenBrink
Metafore
Comments