//Blogs - 12 Jul 2017
How to check if your site is vulnerable to a POODLE attack
How to check if your site is vulnerable to a POODLE attack
Following the introduction of AusCERT’s new Member Security Incident Notifications (MSINs), some members have asked us how they can confirm the accuracy of the POODLE reports. This is the incident type with the highest occurrence rate among AusCERT members.
The Padding Oracle On Downgraded Legacy Encryption or POODLE attack can lead to decryption of HTTPS connections between clients and servers by exploiting a weakness in SSL 3.0 with cipher-block chaining (CBC) mode ciphers enabled.
While we’re confident that our data sources are high quality, you can use the methods below to manually check your publicly facing services for poodle exposure if you wish. If you believe the information we have provided in the report is incorrect then please let us know.
Manual methods for testing poodle exposure
Note that as at 23 September 2015, the information contained in the SSL Labs report requires careful analysis to interpret correctly.
The “Summary” section may indicate “This server uses SSL 3, which is obsolete and insecure” when a poodle attack is possible.
Later in the report a line entry may indicate “poodle (SSLv3): No, mitigated” if the service supports a secure protocol upgrade. However, since this relies upon the client correctly negotiating one of the secure protocols, the service should still be considered vulnerable to poodle attacks.
OpenSSL and nmap
Use the command-line OpenSSL client and an nmap scan to attempt connection using SSL 3.0 and enumerate available ciphers. The OpenSSL command just checks if SSLv3 is enabled; nmap returns all possible ciphers with SSL v3, TLS1.0, TLS1.1 or TLS1.2. OpenSSL can be used to check each individual cipher but it would take more time.
~$ openssl s_client -ssl3 -connect your.domain.here:443
A successful connection indicates that SSL 3.0 is enabled and that a poodle attack is possible.
~$ nmap --script ssl-enum-ciphers -p 443 your.domain.here
A server should be considered vulnerable to a poodle attack if CBC ciphers are offered while using SSLv3. Please note that CBC ciphers, AES128-SHA and AES256-SHA, often don’t mention CBC in their names, but their presence does indicate a poodle vulnerable service.
If no CBC ciphers are offered then it wouldn’t be vulnerable to a poodle attack (but most other ciphers are vulnerable to different attacks like RC4:BEAST).
As you’ll already be aware, there is currently no fix for the vulnerability SSL 3.0 itself therefore disabling SSL 3.0 support is the most viable solution currently available. This means that even with up-to-date patches applied, it is possible to fail a poodle vulnerability scan if SSL 3.0 is still enabled.
