You knew SSLv2 was poison, so why was it still there?
In the wake of the DROWN vulnerability, organisations like the Australian Signals Directorate that offer security incident mitigation strategies might consider adding another item to their lists: test your configuration to make sure it’s what you expected.
The DROWN flaw in HTTPS would not be anything to worry about, except that developers working on server-side software made the fatal assumption that since there were no clients left to request a deprecated SSL connection, they didn’t need to update their code to kill older SSL completely.
We now know that assumption was wrong.
DROWN is a cross-protocol attack: the buggy code in SSL v2 implementations is what enables the decryption attack on vastly more secure TLS encryption.
This was compounded by a now-fixed bug that meant admins could configure a system thinking that SSLv2 was off, but have it sitting there still supported anyhow.
In other words: if you believed your configuration was secure without going back to test it, you may have ticked all the boxes in your “best practice” list and remain vulnerable.
Are people going back to run post-configuration tests? All too rarely, it seems.
According to the Australian Communications and Media Authority’s daily publication of a third-party’s scan (Shadowserver, here) of the country’s address space, a stunning 180,000 hosts here are still vulnerable to POODLE.
Similar results are to be expectd around the world.
Those won’t only be important servers – there will be a lot of unpatched broadband modems in the list – but it’s certain that vulnerable Web servers remain in their thousands or tens of thousands.
Here are two documents, both from the Australian Signals Directorate (ASD): its internationally-recognised Strategies to Mitigate Targeted Cyber Intrusions and its Information Security Manual (ISM).
The ASD – and similar government agencies overseas who urge similar standards on their clients – could argue that it has DROWN covered in both documents:
The mitigation list says workstations and servers should use a hardened, standard operating environment “with unrequired functionality disabled” (recommendation 21), and recommends “server application security configuration hardening” (recommendation 24); and
The ISM says simply “agencies must not use SSL”.
It’s easy to blame the user – to say “if you had SSL v3 enabled it’s your fault”.
And sysadmins were already on notice: the POODLE vulnerability of 2014 was a get-rid-of-SSL warning.
However, we also know that users could set their servers not to use SSL, and still get caught.
As Johns Hopkins University crypto-boffin Matt Green notes, OpenSSL “provides a configuration option that’s intended to disable SSLv2 ciphersuites — but which, unfortunately, does no such thing”, and that only got patched in January this year.
There are tools out there to test Web servers and see if they’re running a safe implementation of TLS: if SSLv3 was truly dead everywhere, DROWN would be a curiosity instead of a headline. ®
Bootnote: A reader has pointed us to this: a toolkit for Australian sysadmins who want to check their ISM compliance. ®
Sponsored: 2016 global cybersecurity assurance report card