Avast AntiTrack Fails to check web certificate validity ×
Share this:
The consequences are difficult to state. A remote attacker running a malicious proxy could capture their victim’s HTTPS traffic and record credentials for later re-use. If a site needs two factor authentication,even then the attacker can still hijack a live session by cloning session cookies after the victim logs in to the machine.
No special action is necessary by the victim using Avast Antitrack in its default configuration. And the attacker not even required an access to the victim’s machine.
Issue In depth
During installation, Avast Antitrack adds a certificate (named “AvastAntiTrack 2”) to the Windows “Trusted Root Certification Authorities” store.
“By default, the Trusted Root Certification Authorities certificate store is configured with a set of public CAs that has met the requirements of the Microsoft Root Certificate Program.”
Avast Antitrack then proxies its users’ traffic to HTTPS sites and presents the browser with a freshly minted certificate of its own for each site visited. The browser displays a secure padlock icon, but importantly traffic is not secured to the end web server.
Issue 1
Avast Antitrack does not check the validity of certificates presented by the end web server. This makes it trivial for a man-in-the-middle to serve a fake site using a self-signed certificate.
This was confirmed by capturing a victim’s DNS requests on port 53 and responding with a “malicious” IP address for certain queries. The “malicious” web server was configured with a self-signed certificate for http://www.avast.com. Ordinarily this should not work for HTTPS traffic (because the browser would warn of an invalid certificate authority), but Avast Antitrack’s proxy ignores the certificate problem and mints its own certificate to present to the victim (that is trusted by the victim’s browser due to the entry in their Trusted Root Certification Authorities store).
Issue 2
Avast Antitrack downgrades the browser’s security protocol to TLS 1.0.
Internet Explorer and Edge can be configured to use only TLS 1.2 or higher. Ordinarily this should mean these browser cannot reach websites using lower versions of TLS. However, Avast Antitrack ignores this setting and makes connections with TLS 1.0 regardless (if the web server supports it), even if the web server supports TLS 1.2 too.
Issue 3
Browser cipher suites are not honoured and Avast Antitrack’s chosen cipher suites do not support Forward Secrecy.
Microsoft periodically updates the cipher suites available to Internet Explorer and Edge. These are ignored by Avast Antitrack in favour of much older ciphers, considered weak by today’s standards.
Reference from Microsoft https://docs.microsoft.com/en-us/windows-hardware/drivers/install/trusted-root-certification-authorities-certificate-store
