David Eade is a web developer and web security consultant, based in Billingshurst, West Sussex, UK. Most security vulnerabilities are privately reported to the respective vendor. This blog includes only publicly disclosed issues.
A man-in-the-middle attack on HTTPS traffic is made possible by Avast Antitrack.
9 March 2020
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.
Disclosure Date: 9 March 2020
Affected Product(s): Avast Antitrack below 22.214.171.124, AVG Antitrack below 126.96.36.199.
Vendor acknowledgement: Researcher David Eade reports AntiTrack bug to Avast
Avast Antitrack and AVG Antitrack share core code. This report refers to Avast Antitrack but applies equally to both products.
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.
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).
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.
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.
|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 188.8.131.52 and anticipates AVG Antitrack patch will be released next week.|
|9 March 2020||AVG Antitrack 184.108.40.206 released.|
|9 March 2020||Coordinated public disclosure at davideade.com and avast.com.|