Avast’s man in the middle | Hacker News Reader

Avast’s man in the middle

thesafemac.com

211 pointshwdsl277 comments

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.

Microsoft has introduced Antimalware Scan Interface in Windows 10 which tries to accomplish this, idea being that applications with possibly malicious content can feed buffers to be scanned by whichever antivirus programs that have registered themselves as ready to handle such calls. This also means that e.g. a JS engine could feed strings fed to eval() to be scanned.

https://msdn.microsoft.com/en-us/library/windows/desktop/dn8...

This is the right way to do it. Microsoft got AV companies to change for XP SP3 (something to do with Windows Security Center?), maybe they can do it again here.

Security Center was introduced with XP SP2.

This is on OSX though, right?

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.

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

Yeah but at the kernel level the packets are still encrypted, the encryption happens in userland.

AV kernel drivers exist to prevent or harden against tampering, as well as disk access filtering.

Kernel level drivers have access to user space memory and can see the unencrypted data easily.

Yeah but they have to find the data first. Given that Chrome with 10 tabs easily eats 2GB of RAM, not an easy task imho.

And they'd have to be updated for every build of Chrome.

True, hence I wrote "for performance reasons or perhaps out of sheer laziness". There are better ways to handle it but they are not always the easiest.

You could just intercept the syscalls responsible for writing to the filesystem or executing programs, which I believe is standard AV practice. That way you have two points were you can check a file for viruses, regardless of where it comes from: when it is first written to disk and when it's loaded into memory but hasn't started executing. No need to grab it at the network level at all.

It is more likely than the MiTM attack is being added in order to try to catch the traffic generated by an already installed piece of malware. Think a metamorphic trojan who talks to its command and control servers via HTTPS (maybe through a known social networking site). In such case, being able to decrypt the traffic might allow heuristic detection of a piece of malware that would normally avoid file-signature detection.

Windows doesn't allow you to "just intercept syscalls" and hasn't for about eight years.

Huh? Process Monitor works just fine for me... at least for read-only interception. Don't know if blocking/rewriting syscalls works, though.

process monitor doesn't work by intercepting system calls, there's a specific API. it's co-operative.

#TIL, thanks. I had always thought it operated like strace.

intercepting the win32 calls that make the syscall is often enough

Since PTRACE (which is one easy way to do this) is part of POSIX, does this mean Windows no longer has a POSIX subsystem?

Edit: I guess only Server and Enterprise have POSIX: http://brianreiter.org/2010/08/24/the-sad-history-of-the-mic...

ptrace is not an easy way to do this... if you try and make an anti-virus or HIPS system based around ptrace you're going to have a very bad day (it's slow, attackers can detect it)

the "normal" way this was done was to have your kernel driver replace system call implementations with wrappers that check an alternate security policy. this was done so often that linux implemented loadable security modules (LSM) and then SELinux on top of that, while other systems (grsec, rbac) exist as patches. it was also one of the main causes of system instability on windows because the people that wrote the wrapper functions did not understand nearly as much about the operating system as they thought, and introduced at best crashes and at worst outright vulnerabilities.

so microsoft created a technology that stopped people from patching their kernel in that way. okay, in the game of cat-and-also-cat that is systems security in the same kernel-level privilege domain it doesn't "stop" them technically it "deters" them but the protection system is semi-random and silently updates, so if you figure out a way to break it and then later your clever hack is silently broken your customers computer will crash in a way that says "hey this one particular product just broke the rules and you should uninstall it" and why run that risk.

they replaced it with a bunch of mature callback APIs that let you do kinda the same thing but with less chance of fucking everything up.

Cryptographic data has specific signatures. It really wouldn't be that hard to find. I bet there are off the shelf solutions already. As I remember it Heartbleed key finding used this.

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

All major browsers (including firefox) allow MitM for a user installed CA. This is not Chrome-specific.

Do the other browsers support certificate pinning though?

Firefox does. IE will eventually and it will also ignore errors caused by user install certs when it does (no, I don't have a source on this, but I am very confident that it will).

Firefox does.

http://caniuse.com/#feat=publickeypinning

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

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.

Because running your own CA, on the internet, with correct support for revocation, and correctly securing it, is not easy.

Browser extension APIs already provide a way to intercept and inspect network connections.

All they have to do is write an addon that communicates with the native part of the virus scanner.

What Chrome extensions APIs allow you to do that?

> In particular, this article reports that Avast will accept revoked SSL certificates, which is a problem.

It should be noted that Chrome itself has this problem. Android does as well. Rather odd given Google's generally proactive work on SSL.

The problem is that revocation essentially doesn't work.

What other browsers do is this:

* Connect to OCSP server

* If connection fails certificate is considered valid

At some point the Chrome devs decided that instead of having a stupid, insecure revocation check that does nothing if an attacker knows how stupid and insecure it is they could also disable it.

This could be fixed with OCSP Stapling and Muststaple, but it's still a long way till this will reasonably work.

I raised the OCSP validation issue with the Chromium team in the past:

https://code.google.com/p/chromium/issues/detail?id=439851

While I understand their position, I don't entirely agree with it for one simple reason. I'm not convinced someone will always be on a compromised network. From my own experience, the most likely network man in the middle scenarios occur while traveling like when connecting to an airport or hotel network. Many bad guys know how to evil-twin WiFi and implement transparent TLS proxies.

With this in mind, if a user visits a site frequently and that site revokes their cert, there's a good chance the user will not be on an evil network when the OCSP check is made. Therefore, if Chrome cached the responses and permanently revoked the certs the risk to the user does in fact decrease. As stated in my report, Heartbleed really did make the choice to ignore OCSP a bit more risky because private key material really was stolen from a number of companies.

No. MITM'ing SSL means it can access all communications, not just the ones one browser wants to give it. There are plenty of other things on a system (and increasingly more these days) that can communicate via SSL, and it makes sense for AV to inspect those too; whether you trust AVs is a different issue.

A browser API would defy the purpose of security layering. The browsers for example, doesn't report their internal tracking request to the developer tools, and probably wouldn't provide that info to an API either.

Does anyone have a guide on how to MITM SSL from your own computer!?

> This actually makes sense; if it wants to scan for malware in web pages and file downloads

Since when does Avast concern JS? I would have thought, to intercept file you'd use the systems file API? Everything else is the concern of the browser, because it knows how to mess with the internals of web browsers.

> 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

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

Sophos AV seems to go a step further, intercepting any outbound telnet connection. Good to know if your company uses Sophos and you used to use telnet for basic connectivity testing.

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

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.

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

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.

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.

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

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

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

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.

Host firewalls don't generally do it. Seems AVs can better tolerate the reputation of being invasive and draconian.

I suppose it's different if are focused on trying to win from a starting point of a compromised machine, a kind of Core Wars game. On current systems this can't be reliably recovered from unfortunately, in that situation user should just be alerted to wipe & restore from backups.

Firewalls usually inspect IPs, ports, and processes when deciding to allow or block, but not packet contents.

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

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?

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.

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

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

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

It might not be hard for them to do it, but how is the end user meant to know to ask if they do?

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

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

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

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.

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

http://www.dslreports.com/forum/r24594731-IE-How-do-I-view-c...

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.

I disagree. In my opinion, giving less control to the endpoint user means you still need to rely blindly on what's between two endpoints - although, on this way, you cannot control it. I think the most effective way to combat endpoint infections would be to teach people on how to browse the web securely.

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

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

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

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

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.

You can use the runas command to run something as a different user. Or one of the sysinternals utilities.

Haven't used it much personally though.

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.

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.

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

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

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

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.

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

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.

Avira is German (I don't trust American security products any more). It is also well-ranked [1].

[1] http://www.av-comparatives.org

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

Reply on news.ycombinator.com