Decreasing Security for Perceived Security — all in the name of compliance
Today I ran into a little setback for an issue I did not foresee. For the past several months, I’ve been on a PCI remediation project, of which one of my tasks was to implement a web application firewall to address PCI requirement 6.6. Now, for everyone out there who has been following our posts, knows us dealing with WAFs is worse than pulling teeth.
So, in creating a secure Apache standard build, I seemed to have over-engineered and made our build too secure. How? Well, one of the lines in our httpd.conf included the following SSLCipherSuite directive:
SSLCipherSuite HIGH:MEDIUM:+TLSv1:!LOW:!EXP:!ADH:!aNULL:!eNULL:!NULL:!SSLv2
With support for the following ciphers:
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
Looks good right?
This directive, included the Diffie-Hellman ciphers, which I was reminded by blatant error messages of unsupported ciphers in the management console, that it was not susceptible to MITM attacks due to the nature of the key-exchange. Doh! What’s this mean? Our WAF, was rendered useless for monitoring and protecting our application because our SSL encryption strengths being negotiated were the most secure, and thus, the WAF had no visibility into our application. The most common SSL cipher being negotiated was TLS_DHE_RSA_WITH_AES_256_CBC_SHA — the most secure of all.
So to comply with PCI Requirement 6.6, I had to step down our list of available SSL ciphers with the following SSLCipherSuite directive:
HIGH:MEDIUM:+TLSv1:!DH:!LOW:!EXP:!ADH:!aNULL:!eNULL:!NULL:!SSLv2
which at least provided support for the following ciphers:
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
So much for PCI Requirement 4.1, which requires the use of strong cryptography and security protocols such as SSL/TLS to safeguard sensitive cardholder data. This post is just a little FYI for those in the same boat. Turns out we can be “too secure,” :P
As my manager likes to sometimes put it, “How do you like ‘dem apples?”
Would it help to have a WAF that doubles as SSL offload? :)
We’ve strategically positioned the WAF to listen on traffic directed to the load balancers. Reason being, is that then, we’re only looking at about 10 IP addresses, versus 100 IP addresses of all the backend servers. Also, all of our SSL sessions terminate at each individual backend server — we do not terminate at the load balancer. If we did, there would be that portion of unencrypted network traffic which we did not want to allow for.
Fair enough, and it really depends what devices you have at your disposal. For instance mine terminates SSL, does LB, and has a WAF as well, so I can terminate SSl and reinit another backend SSL session while still seeing inside the traffic.
But your version has merit, of course.
And I might still be making the poor assumption that I am using similar strong ciphers, which I truly doubt I am. Maybe with stronger ones I can’t terminate it? I don’t know.
FYI, I have several Citrix Netscalers at my disposal.
DH is susceptible to MITM, from the same wikipedia entry:
In the original description, the Diffie-Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. A person in the middle may establish two distinct Diffie-Hellman key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing the attacker to decrypt (and read or store) then re-encrypt the messages passed between them.
@Marcin: 2 quick comments… both of which you’re probably expecting:
1) This has to be the ultimate irony: You on a PCI remediation project, implementing WAF… maybe Karma?
2) If I understand you right, this is exactly what you get for trying to implement a WAF from scratch :)
I’m amused- hey, Merry Christmas (Wesolych Swiat)
Rafal, I thought we talked about this back in September. So yah, it is ironic, but instead of just theory, I have practical experience not only working with WAFs but implementing them from the ground up, and also working with developers to get code fixed.
And yes, this is a “from scratch” WAF implementation. It is not easy, and for anyone who thinks they can just “throw a WAF in front of an app” is in for a heart-wrenching world of pain.
I will be on an upcoming OWASP Podcast with Jim Manico, in which I’ll talk about a whole bunch of interesting things I learned from the project. Very worthwhile experience, even though I dreaded everyday WAF issues.
I love this! It reminds me of complying with the DoD’s PPS by using a less secure but authorized protocol.