Avast SSL scanning makes systems vulnerable to POODLE attack

Avast Free Antivirus / Premium Security
1

Hello Avast forum,

Recently I disabled SSLv3 using the instructions on this page: https://poodle.io/
I noticed however, that the page would continually show I was vulnerable, even after following the instructions.

When I disabled SSL scanning in Avast, the page reported I was no longer vulnerable. Why does the Avast scanner allow SSLv3? Am I vulnerable to the POODLE attack if Avast SSL Scanning is enabled?

I am running Avast IS (Latest version) and also am getting this on the Free version of Avast on another system.

2

Anyone have any info on this? Avast devs? Or am I just missing something?

3

It’s worth mentioning that poodle-.-io finds my IE11 to be vulnerable even though I had already done what it says to do, “uncheck SSL3.0 and SSL2.0 in Internet Options>Advanced>Security”. Naturally I have also checked TLS 1.0, 1.1 and 1.2… I will admit I installed IE11 as an indirect update, it made me download and install IE10 over my IE9 first. Maybe Microsoft is confused as to what settings it should use?

So (for Sutieday), regard IE11 as just another Microsoft Bug, and use a secure browser. I use and recommend K-Meleon74.24, which recognises all current TLS, but does not recognise Avast Certificates because they are SSL-based.

Gordon.

4

I don’t want to see this topic get buried… Avast needs to either disable SSLv3 in the ssl scanner, or provide and option to do so.

5

What the OP says is true as I have Firefox 34 which has SSLv3 disabled by default.

If I leave https scanning enabled in Avast the test fails.

If I disable https scanning in Avast the test passes.

6

https://www.ssllabs.com/ssltest/viewMyClient.html is a good place to check for Poodle vulnerability.
If you have JavaScript disabled, the test cannot give the proper results. The extension RequestPolicy must be set so the site can do it’s job.

I have HTTPS scanning enabled, and Firefox as well as Opera and MSIE 11 pass the test.

7

Hello,
yes, thanks for notice the fix is planned.

Milos

8

Hi guys,

Thanks for the reports. We are currently working on some improvements to make HTTPS scanner handshakes and protocol negotiations more transparent.
So, yes, currently HTTPS scanner does support SSLv3 connections. At the same time I believe we are not vulnerable to classic POODLE attack. Since we (HTTP Scanner) does not downgrade the protocol on retries. The only case when we connect with SSLv3 is when the server explicitly requests such connections in the handshake - which is done, disregarding test cases, only by servers that support SSLv3 as their best protocol.

Normaly we use in the handshake the same protocol version as is requested by the client ( TLS 1.2, 1.1,1), in case the client requests (in the Client hello packet) version SSLv3, we even upgrade it to TLS1.

For the SSLv3 servers we are vulnerable to the POODLE attack, where as with SSLv3 disabled the client wouldn’t be able to access the site at all. We will improve this in the future version so that if the client rejects SSLv3-only connections, we do reject them as well.

So how come the https://poodle.io test succeeds in establishing the SSLv3 connection with us? This is because it does specifically request SSLv3 version in the SERVER HELLO packet.

Let me explain the attack:
The so called POODLE vulnerability allows the attacker to leak one BYTE per connection. If the attacker is able to create many (hundreds) varying connections (e.g. via Java script in a infected web), he/she is able to leak different byte every time and eventually get something usefull - such as session cookie.

For this to happen the attacker needs SSLv3 connections. So the attacker will block the handshake packets and hope the client will retry with lower procotol version. Since we never retry with SSLv3 even when blocked, further connections via HTTPS scanner will again be using at least TLS1.

This lead me to the conclusion, that current implementation of HTTPS scanner is not vulnerable to POODLE attack.

However I must admit we are still lacking a few things in the implementation. We do not send the TLS_FALLBACK_SCSV cipher, so connections can be established with lower version (such as TLS1 instead of TLS1.2) in case retry/blocks happen - but not with SSLv3.
We plan to the this in the next update.

I hope this explains it a bit.

Lukas.

9

Thanks for the reponse Avast! team! I’m glad that I’m not actually vulnerable with the SSL Scanning enabled. I do look forward to future improvements to the SSL scanner.