
Avast’s man in the middle - hwdsl2
http://www.thesafemac.com/avasts-man-in-the-middle/
======
jimrandomh
This reports that Avast, an antivirus program, inserts itself as a man-in-the-
middle on all SSL connections on computers it's installed on. This actually
makes sense; if it wants to scan for malware in web pages and file downloads
coming from https sites, it has to either do this or mess with the internals
of web browsers, and MitM is easier and less likely to cause technical
problems.

The problem is, making a secure SSL endpoint is really hard; if you aren't
very very careful in how you distinguish good from bad SSL certificates, then
users are vulnerable to having their connections tampered with by things like
untrusted Wifi routers. Web browsers put a lot of work into distinguishing
good and bad SSL certificates, and Avast's MitM interferes with this working
correctly. In particular, this article reports that Avast will accept revoked
SSL certificates, which is a problem.

What ought to happen here, is that Avast (and other AV vendors) should be
coordinating with Chrome (and other browser makers) to provide an API for
antivirus software to get access and scan, in a way that doesn't interfere
with the normal SSL authentication machinery. I suspect that browser vendors
are hesitant because an API created for that purpose would likely also get
hijacked and used by malware and adware.

~~~
Laforet
Avast installs its own kernel drivers (on windows at least) so it already has
access to everything in userland without requiring a special API.

The MITM part was probably added for performance reasons or perhaps out of
sheer laziness judging from how they managed to mess up certificate
validation. Although this seems to be a common issue with web filters in
AV/DPI products.

It is also worth noting that certificate pinning in Chrome was deliberately
weakened to accept a self signed CA certificate in order to maintain
compatibility with the aforementioned corporate web filters. DropBox, in
contrast, has strict pinning policies that it is essentially MITM-resistant
without compromising the client first.

~~~
revelation
Dropbox is a self-contained program, why would it use the public CA
infrastructure in any case? Only negatives all around.

~~~
giovannibajo1
Because they might want their API to be accessible from JS (maybe through
CORS) and that's only possible if you go through a CA.

------
maxhou
> Suppose, for example, that you go to the Bank of America site to transfer
> some funds or pay a bill. As with Google, and as would happen with any other
> secure site, it turns out their certificate gets replaced with the Avast
> certificate. I doubt anyone needs me to lecture them on the potential
> security issues involved in having a third-party watching their banking
> transactions without permission!

Antivirus software runs with the highest level of privileges, divert system
calls...

They could theoretically log everything you type on the keyboard, no need to
MITM SSL connections

> Avast is replacing certificates with its own without bothering to check the
> validity of those certificates!

This is a far bigger issue

------
adrtessier
Avast is not the only antivirus program that does that these days; ESET does
it, and Symantec's Norton products do as well IIRC. As everything moves toward
TLS, this is pretty much a required step on the client for "Internet
Security", and the average person doesn't know or doesn't care.

Largely, you probably should not either if you are trusting the AV client with
the rest of your computer. Yes, it can be fucked up and break TLS, but there
are a thousand other ways a privileged executable like an AV program could
fuck up a lot more of your system. For example, a bunch of CVEs were found in
Kaspersky's product by Tavis Ormandy in September, and it appears that a few
found in Avast have been made public within the past few days. [1]

[1] [https://code.google.com/p/google-security-
research/issues/de...](https://code.google.com/p/google-security-
research/issues/detail?id=549#c1)

~~~
magicalist
> _Largely, you probably should not either if you are trusting the AV client
> with the rest of your computer. Yes, it can be fucked up and break TLS, but
> there are a thousand other ways a privileged executable like an AV program
> could fuck up a lot more of your system._

You're right that antivirus software is more or less a sieve of a shield, but
this doesn't really make sense.

If AV exploits are worth fixing, then so are the exploits made available by AV
certificate handling.

~~~
adrtessier
I'm quickly understanding that I need to learn to be more specific as to what
the premise of my statement is before I comment here.

I agree with your point as to fixing all holes; I was making the point more
toward people freaking out that these AV systems are inserting the
certificates and inspecting the traffic in the first place. Sorry for the
confusion.

------
wmt
(The article is almost a year old, but the issues remain)

The AV MITM certs are not exactly Dell- or Lenovo-bad, as they are all
uniquely generated in each installation, so you can only fake traffic on
computers you have Admin access - and then you don't need Avast for that.

However, the real issue is if these MITM-proxies render compromised, expired
or otherwise insecure TLS-connections "secure".

The bare minimum should be to respect the cert storage of the computer,
although that will fail with any application with its own storage, like
Firefox. To me this feels like it has too many points of failure to increase
security instead of lowering it, so you really would focus on detecting
malicious content based on other things, like the host reputation, files that
land on disk, or maybe having a browser plugin that would see at least some of
the decrypted HTTPS content.

------
bitwize
Any sufficiently advanced antimalware program becomes indistinguishable from
malware in its methods. He who fights monsters should see to it that he does
not himself become a monster.

------
bastawhiz
The "well you trust your AV with your computer anyway, you should trust it
with this" argument is a terrible one. It's not about trust. It's about
decreasing footprint.

ESET had a pretty big security vulnerability over the summer. As seen in this
post, Avast isn't properly validating certificates. AV providers aren't bug
free by any stretch of the imagination. Granted, browsers and OSes have their
own vulnerabilities. At the end of the day, though, the fewer people that
touch your encrypted communications, the better. Every time there's some hack
or workaround or other vulnerability, the number of devices affected increases
substantially.

_This isn't okay._ Especially for a security vendor. Security should be done
the right way, every time, period. Taking advantage of hacks or workarounds or
other unsupported ways of intercepting data (e.g., MITMing HTTPS traffic with
a self-signed cert) exposes users to risk. Not to mention, browser or OS
vendors might close those loopholes in the future and break the security
software.

This is like saying, "I'll protect your car from carjackers. Just replace all
your door locks with these ones." How much do you trust the security provider
to not use the same key twice? How much do you trust that they're properly
checking which key is the correct key? How much do you trust them that their
proprietary black-box locks work as advertised? Do you trust them more than
your car manufacturer? Do you trust that they aren't going to be vulnerable to
a malicious key fob?

That said, if encrypted traffic is a blind spot for AV vendors, they should be
working with browser vendors to make sure proper, secure APIs exist to get
around those limitations. Hacky workarounds are not the answer.

------
hannob
I had covered the issue of AV mitm-ware a while ago on my blog:
[https://blog.hboeck.de/archives/869-How-Kaspersky-makes-
you-...](https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-
vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-
HTTPS-security.html)

It is not superfish-bad, but it's still bad. But AVs are full of security
problems, it's really just a broken concept.

------
Animats
One of the big problems with "security" software is that it wants to plug
itself into the system at such a low level that the security software itself
becomes a security risk. Much security software isn't very secure. After all,
if it has online updating, it is a backdoor.

We have to be much more suspicious of software like that now, with the FBI
Director pushing for backdoors and trying to get vendors to install them.[1]

[1]
[http://www.theregister.co.uk/2015/10/09/us_encryption_backdo...](http://www.theregister.co.uk/2015/10/09/us_encryption_backdoor_law_latest/)

------
userbinator
Any sort of network filtering software (including AVs) has to intercept SSL to
be effective, otherwise malware will just use SSL to avoid it. This is
basically the same as the "governments are scared of encryption" issue, except
at a personal level and it's not the governments which are scared, but it
should be you. Encryption can work both for and against you, and so can MITM.
Remember how someone discovered that smart TVs phone home with private data,
because it was not encrypted?

I believe that if you truly own your machine, you must be able to have
complete control over the network traffic that it generates. If you consent to
letting AV inspect it for you, and there would certainly be some phrase in the
EULA which says so, then I see no problem with that. Personally I don't use
AVs for other reasons, but _opt-in consent_ of letting a third-party inspect
all your data is not bad.

In short, the only problem here is Avast has buggy SSL implementation. I don't
know if they use something like OpenSSL, but revocation checking with OpenSSL
has to be done manually. A good SSL/TLS client library that has these features
would make it a lot easier to do it correctly...

disclamer: I run a MITM proxy for adblocking and filtering (yes, SSL too) so I
may be a bit biased.

~~~
kingosticks
My company is about to purchase and install a Palo Alto Networks firewall
which can be configured to intercept outgoing SSL connections. I'm hoping they
won't enable the feature but as soon as management see the "protect
intellectual property" headline they will jump on it. There is an
article/press release on it at
[http://www.networkworld.com/article/2161439/network-
security...](http://www.networkworld.com/article/2161439/network-security/ssl-
decryption-may-be-needed-for-security-reasons--but-employees-are-likely-to--
fre.html)

EDIT: From the above article:

 _The Palo Alto Networks NGFW uses a certificate-copying mechanism to open up
TLS 1.1 sessions (TLS 1.2 for outbound is not yet supported but the process
negotiates down to TLS 1.1) that basically works like a corporate-operated
man-in-the-middle attack._

Does that mean Chrome/Mozilla will detect the negotiation down and block
access to these sites?

~~~
brazzledazzle
Your company is probably going to drop an internal CA certificate into your
operating system certificate store. Chrome uses that and will respect
it–including ignoring pinning. Firefox uses its own internal certificate store
and getting a corporate CA into those can be more difficult than it's worth.

------
0942v8653
An antivirus software that can monitor HTTPS connections should be a non-
issue. Because you're already trusting Avast with full privileges, it can
monitor every keystroke and screenshot every response from the browser, or
read RAM during decryption, or replace your browser with a fake version that
captures data, or any number of things. And it can upload it to some remote
server if it wants to. It would be incredibly easy to get your bank password
without this MITM: just start keylogging when an outgoing connection to
example.com is established, wait for an email[TAB], and capture/upload all
keystrokes until ENTER is pressed.

The only real problem here is not checking the validity certs. (Which is an
incredibly serious problem.)

~~~
venomsnake
> The only real problem here is not checking the validity certs. (Which is an
> incredibly serious problem.)

There are other problems. I am not sure where the third party doctrine will
stand, but you are trusting all of your secure connections to a third party
with full consent.

If avast get subpoenaed and their software has called home, which any
antivirus does - they must collect new samples all the time - this could spell
trouble.

~~~
fidget
It wouldn't be particuarly hard for avast to operate this system without
having the key for the CA leaving your machine.

~~~
venomsnake
That won't help when they send part of the plaintext home. Which any antivirus
program does from time to time

------
unluckier
Even done in the best way possible, SSL inspection puts end users at increased
risk. In the real world, vendors make mistakes, which put them at even higher
risk. [https://insights.sei.cmu.edu/cert/2015/03/the-risks-of-
ssl-i...](https://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-
inspection.html)

~~~
userbinator
In comparison, what is the risk of NOT performing SSL inspection and letting
all encrypted data through?

 _Microsoft Internet Explorer, don 't even allow viewing a certificate until
after you have accepted it_

Incorrect; there is a "view certificate" button on the warning dialog:

[https://docs.oracle.com/html/B12013_03/img/sec_ie_install_ce...](https://docs.oracle.com/html/B12013_03/img/sec_ie_install_cert_popup.gif)

~~~
unluckier
What version of IE is that dialog from? 6? Things have changed quite a bit
since then.

Yes, SSL inspection is a security tradeoff. Whether the folks rolling it out
realize this is another story.

~~~
userbinator
I don't know about that specific picture (just searched for "IE view
certificate" and looked for one that I recognised) but it was there in 5 and
6; I haven't used the newer versions of IE enough to encounter any certificate
errors, but a quick search shows that MS did break this functionality:

[https://social.technet.microsoft.com/Forums/ie/en-
US/e0ec441...](https://social.technet.microsoft.com/Forums/ie/en-
US/e0ec4417-02cd-4670-ba4a-fcb57e0327d6/unable-to-view-ssl-certificate-in-
ie11?forum=ieitprocurrentver)

[http://www.dslreports.com/forum/r24594731-IE-How-do-I-
view-c...](http://www.dslreports.com/forum/r24594731-IE-How-do-I-view-
certificates-that-have-problems)

------
cenal
The bigger question here is the relevance of endpoint security like Avast in
the grand scheme of things. It seems like the effectiveness of these solutions
has waned in the last 10 years. I've read that the most effective way to
combat endpoint infections is to limit the user privileges for the endpoint
user. No local admin nonsense and you mitigate 90% of endpoint issues.

~~~
arthurfm
> No local admin nonsense and you mitigate 90% of endpoint issues.

According to Kaspersky [1] it's possible to mitigate 85% of threats by
restricting administrative privileges, using application whitelisting and
keeping the OS, browser(s) and applications patched.

[1] [https://securelist.com/blog/software/69887/how-to-
mitigate-8...](https://securelist.com/blog/software/69887/how-to-
mitigate-85-of-threats-with-only-four-strategies/)

------
throwaway7767
> However, the issue here is one of trust. Should you trust Avast with this
> kind of access to your private information? Avast has essentially chosen to
> hijack your web browser’s security without your permission, inserting itself
> as a silent watcher into all your secure communications.

If you've installed a program with administrative privileges, it already has
total, unrestricted access to your machine. There may be a reason to be
concerned about this, but it's not that they're getting some access that the
user has not already granted by installing the software.

I'm not a fan of blacklist-based security like AV, I think it's basically
useless. But if the filtering features of Avast are something you want for
some reason, this seems a legitimate way to do it. The alternative is to read
this data directly from browsers memory (they can do this with the access they
already have), which is likely to break at every update and require a huge
amount of programming effort.

------
frik
Microsoft could fix the root problem for classic Windows applications
(majority are WinAPI based applications). All apps should run by default in a
sandbox container, then no Antivirus product would be needed (see Android,
iOS, OSX). Windows would need more fine control permissions UI to like
iOS9/Android6 so that only certain applications can access e.g. your picture
folder. Windows already supports shims and shadow path/registry retranslation
(used in IE and in the backward compatibility layer) - all what is missing is
basically an end user GUI. Also executing applications under a different user
should get easier, a common Unix security measure that is near impossible for
normal users using Windows (except for whitelisted Microsoft Office
applications).

~~~
hirsin
> Also executing applications under a different user should get easier

I'm curious - are you looking for something more command-line oriented or GUI-
driven? I have no idea how to do it via command-line, but shift-right-click on
an icon will give you the Run As Different User option. This may also not
satisfy your needs - it only works for some users (i.e. you can't do Run As
DefApps)

~~~
frik
Like Android, iOS, OSX (or with Sandboxie on Windows) - new applications
should start in a sandbox by default.

The shift-right-click menu offers different entries depending on where desktop
icon come from (the .lnk file is stored either in \Public\ or the users
desktop directory). The run as different user is only shown if the lnk is
stored in the "public" desktop.

------
beck5
We had a very bad experience with from this. When Avast first deployed this
feature they broke all websocket connections. We had a lot of angry users. It
took Avast a good few months to fix it.

------
jarcane
Having a look around on my Windows system running Avast, I don't appear to
have the same issue at the moment, but I have repeatedly of late found myself
seeing security warnings in Firefox which I'd chalked up to my spotty 4G
connection.

Looks like I need to keep an eye on it, which pisses me off because if this is
true of the Windows version, it means at this point there simply isn't a
Windows AV solution that isn't complete garbage from one standpoint or
another.

------
spyder
They also started to insert their ad in e-mails sent from gmail ( something
like "scanned by Avast" and their logo) and even when the e-mail shield wasn't
installed. It wasn't easy to disable because the disable option was only
available in a newest program version and the installation also required a
restart. So bye Avast...

------
smegel
> but in reality, most people don’t care much if someone’s monitoring their
> searches

Says who? Any reliable source to back this claim up?

------
pmoriarty
Does Avast still install the fake certs if you decline to install its "web
shield" during installation?

------
totony
Noticed that when installing Avast, promptly disabled the "web scan" and
"email scan" functionalities.

I assume Avast still offers full functionality without those features, since
they scan program execution and resource loading anyway.

~~~
michael-go
I managed to disable the browser MITM without disabling the whole
functionalities: Settings -> Active Protection -> Web Shield Customize ->
uncheck 'HTTPS scanning'

------
neumino
Hum, this is disturbing. I would be curious to know how much malware is
actually served over HTTPS and what good alternative to Avast is out there for
Windows.

~~~
userbinator
I'd bet that eventually all malware will be served over HTTPS. Movements to
encrypt _all_ traffic, like Let's Encrypt, will only hasten this. (Not saying
LE is bad, but that's just how it works... it's a cat-and-mouse game.)

