Avast AntiTrack does not check validity of end web server certificates

The consequences are hard to overstate. 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 (such as a one-time password), then the attacker can still hijack a live session by cloning session cookies after the victim logs in.

No special action is necessary by the victim using Avast AntiTrack in its default configuration. And the attacker does not need access to the victim's machine.

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.

Three issues were reported to Avast.

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 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.

Disclosure Timeline

7 August 2019	Vulnerabilities reported to Avast.
16 August 2019	"Thank you for the report" from Avast.
20 August 2019	Request for screenshots and steps to reproduce from Avast.
	[David on holiday 19 August to 25 August.]
27 August 2019	Screenshots and steps to reproduce sent to Avast. Telephone conference with demonstration same day.
25 September 2019	Avast says issues fixed internally and will be released in next update.
29 January 2020	David requests updated timescale for release.
29 January 2020	Avast says fix is awaiting release pending final rouding of QA and security review. Avast shares alpha build, supposedly with fix included.
4 February 2020	David shares steps to reproduce. Telephone conference with demonstration same day.
6 February 2020	Avast says issues successfully resolved.
7 February 2020	Avast shares new alpha build, supposedly with fix included.
10 February 2020	David confirms build mitigates issues and asks for timescale for release.
28 February 2020	Avast releases Avast AntiTrack 1.5.1.172 and anticipates AVG AntiTrack patch will be released next week.
9 March 2020	AVG AntiTrack 2.0.0.178 released.
9 March 2020	Coordinated public disclosure at davideade.com and avast.com.