When Security Audits attempt to make your server more vulnerable.

So we host a few servers that have to be scanned for PCI compliance, if a server isn’t passing PCI compliance for some reason we hear about it. It’s usually because they’ve added a new client, setup them on a new IP and not telling us so we can run our firewall setup. It gets scanned and fails miserably because the shared services on the server (Email, Control Panel) etc are exposed when we custom build the firewall for each customer to only allow connections from certain locations.

Then we also have some customers that have some CentOS 5 servers, CentOS 5’s built in version of openSSL only allows SSLv3 and TLSv1. SSLv3 is disabled for security reasons as it should be. But then we get a a security auditor that starts screaming about a BEAST a browser vulnerability that has been mitigated in clients as it should be by using 1/n-1 split. This security auditor was using 3 year old information and failed our customer telling them to instead use:

SSLCipherSuite RC4+RSA:!EXPORT:!LOW

in apache.

This sets up the customer for failure because RC4 has been known broken for a year now. And a scan from Qualys SSL analyzer gives that a fat F. So I told them to reply with this:

=======================================

BEAST stands for Browser Exploit Against SSL/TLS Attack, essentially if someone can get between your customers browser, and your website and listen in on traffic they can attack the browser and get cookies from the browser. This attack has been known since the Early 2000’s and was updated with TLSv1 in 2011 it’s impractical and besides lab proof of concepts hasn’t been seen in the wild, as most of the chain of client exploits required for even the proof of concept to work in a lab environment have been patched by their vendors.

BEAST can be mitigated server-side (by using RC4, a broken, and weak cipher where attacks are just going to get better and easier) or client-side (1/n-1 split, which has been implemented in every major browser for quite some time).

At this time it is better to use strong ciphers and leave TLSv1 enabled (Technically allowing a vulnerability with BEAST) then to disable TLSv1 (making your website inaccessible to ~25% of the browsers in use), or enable RC4 (Making your server vulnerable to the growing number of attacks against a weak cipher that has been known broken for over a year).

BEAST is not considered a relevant attack any longer, and RC4 is widely considered by the security community to not be a workaround worth using:

1.) https://luxsci.com/blog/is-ssltls-really-broken-by-the-beast-attack-what-is-the-real-story-what-should-i-do.html
2.) https://threatpost.com/not-so-fast-on-beast-attack-mitigations/102308
3.) https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
4.) https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf (See section 2)

=========================================

Apparently that did the trick. But with the PCI DSS 3.1 having just came out and with it saying TLSv1 having to be disabled by June 2016 we’re going to see a mad rush of folks needing to move to CentOS 6 or 7 from their previous cushy CentOS 5 havens. Which isn’t a bad thing as CentOS 5 reaches end of life in March of 2017, it’s a bit dated now.

Leave a Reply

Your email address will not be published. Required fields are marked *