Sunday, April 26. 2015
How Kaspersky makes you vulnerable to the FREAK attack and other ways Antivirus software lowers your HTTPS security
Lately a lot of attention has been payed to software like Superfish and Privdog that intercepts TLS connections to be able to manipulate HTTPS traffic. These programs had severe (technically different) vulnerabilities that allowed attacks on HTTPS connections.What these tools do is a widespread method. They install a root certificate into the user's browser and then they perform a so-called Man in the Middle attack. They present the user a certificate generated on the fly and manage the connection to HTTPS servers themselves. Superfish and Privdog did this in an obviously wrong way, Superfish by using the same root certificate on all installations and Privdog by just accepting every invalid certificate from web pages. What about other software that also does MitM interception of HTTPS traffic?
Antivirus software intercepts your HTTPS traffic
Many Antivirus applications and other security products use similar techniques to intercept HTTPS traffic. I had a closer look at three of them: Avast, Kaspersky and ESET. Avast enables TLS interception by default. By default Kaspersky intercepts connections to certain web pages (e. g. banking), there is an option to enable interception by default. In ESET TLS interception is generally disabled by default and can be enabled with an option.
When a security product intercepts HTTPS traffic it is itself responsible to create a TLS connection and check the certificate of a web page. It has to do what otherwise a browser would do. There has been a lot of debate and progress in the way TLS is done in the past years. A number of vulnerabilities in TLS (upon them BEAST, CRIME, Lucky Thirteen, FREAK and others) allowed to learn much more how to do TLS in a secure way. Also, problems with certificate authorities that issued malicious certificates (Diginotar, Comodo, Türktrust and others) led to the development of mitigation technologies like HTTP Public Key Pinning (HPKP) and Certificate Transparency to strengthen the security of Certificate Authorities. Modern browsers protect users much better from various threats than browsers used several years ago.
You may think: "Of course security products like Antivirus applications are fully aware of these developments and do TLS and certificate validation in the best way possible. After all security is their business, so they have to get it right." Unfortunately that's only what's happening in some fantasy IT security world that only exists in the minds of people that listened to industry PR too much. The real world is a bit different: All Antivirus applications I checked lower the security of TLS connections in one way or another.
Disabling of HTTP Public Key Pinning
Each and every TLS intercepting application I tested breaks HTTP Public Key Pinning (HPKP). It is a technology that a lot of people in the IT security community are pretty excited about: It allows a web page to pin public keys of certificates in a browser. On subsequent visits the browser will only accept certificates with these keys. It is a very effective protection against malicious or hacked certificate authorities issuing rogue certificates.
Browsers made a compromise when introducing HPKP. They won't enable the feature for manually installed certificates. The reason for that is simple (although I don't like it): If they hadn't done that they would've broken all TLS interception software like these Antivirus applications. But the applications could do the HPKP checking themselves. They just don't do it.
Kaspersky vulnerable to FREAK and CRIMEHaving a look at Kaspersky, I saw that it is vulnerable to the FREAK attack, a vulnerability in several TLS libraries that was found recently. Even worse: It seems this issue has been reported publicly in the Kaspersky Forums more than a month ago and it is not fixed yet. Please remember: Kaspersky enables the HTTPS interception by default for sites it considers as especially sensitive, for example banking web pages. Doing that with a known security issue is extremely irresponsible.
I also found a number of other issues. ESET doesn't support TLS 1.2 and therefore uses a less secure encryption algorithm. Avast and ESET don't support OCSP stapling. Kaspersky enables the insecure TLS compression feature that will make a user vulnerable to the CRIME attack. Both Avast and Kaspersky accept nonsensical parameters for Diffie Hellman key exchanges with a size of 8 bit. Avast is especially interesting because it bundles the Google Chrome browser. It installs a browser with advanced HTTPS features and lowers its security right away.
These TLS features are all things that current versions of Chrome and Firefox get right. If you use them in combination with one of these Antivirus applications you lower the security of HTTPS connections.
There's one more interesting thing: Both Kaspersky and Avast don't intercept traffic when Extended Validation (EV) certificates are used. Extended Validation certificates are the ones that show you a green bar in the address line of the browser with the company name. The reason why they do so is obvious: Using the interception certificate would remove the green bar which users might notice and find worrying. The message the Antivirus companies are sending seems clear: If you want to deliver malware from a web page you should buy an Extended Validation certificate.
Everyone gets HTTPS interception wrong - just don't do it
So what do we make out of this? A lot of software products intercept HTTPS traffic (antiviruses, adware, youth protection filters, ...), many of them promise more security and everyone gets it wrong.
I think these technologies are a misguided approach. The problem is not that they make mistakes in implementing these technologies, I think the idea is wrong from the start. Man in the Middle used to be a description of an attack technique. It seems strange that it turned into something people consider a legitimate security technology. Filtering should happen on the endpoint or not at all. Browsers do a lot these days to make your HTTPS connections more secure. Please don't mess with that.
I question the value of Antivirus software in a very general sense, I think it's an approach that has very fundamental problems in itself and often causes more harm than good. But at the very least they should try not to harm other working security mechanisms.
(You may also want to read this EFF blog post: Dear Software Vendors: Please Stop Trying to Intercept Your Customers’ Encrypted Traffic)
Comments
Display comments as
(Linear | Threaded)
I am also concerned, both about the technical dangers, and the ethical ones. But if unauthorized traffic is encrypted, what technical solution can we (the security community) use instead?
Solely relying on connection metadata (source/dest IP, port, time of day, source user, destination domain, etc.) is no longer sufficient. Attackers move quickly to emulate legitimate metadata in order to to avoid detection. And relying on IP whitelisting is hard in the new cloud era.
Direct inspection -- at the application layer, and the payload itself -- is a way to differentiate between "good" encrypted traffic (legitimate, authorized use) and "bad" encrypted traffic (exfiltration, command and control traffic, etc.)
If we cannot intercept, what else can we do?
Solely relying on connection metadata (source/dest IP, port, time of day, source user, destination domain, etc.) is no longer sufficient. Attackers move quickly to emulate legitimate metadata in order to to avoid detection. And relying on IP whitelisting is hard in the new cloud era.
Direct inspection -- at the application layer, and the payload itself -- is a way to differentiate between "good" encrypted traffic (legitimate, authorized use) and "bad" encrypted traffic (exfiltration, command and control traffic, etc.)
If we cannot intercept, what else can we do?
The first question is: What do you want to do and is that legit at all? It's the point of encrypted connections to guarantee authenticity of the data. You need a damn good reason to change that.
For the antivirus applications: I think the approach to security is wrong to begin with. Fix security vulnerabilities in the browser/OS, don't try to filter malicious software later on. You'll always loose on that.
When you want to do filtering like ad-blockers etc.: Create a browser plugin and filter at the endpoint.
For the antivirus applications: I think the approach to security is wrong to begin with. Fix security vulnerabilities in the browser/OS, don't try to filter malicious software later on. You'll always loose on that.
When you want to do filtering like ad-blockers etc.: Create a browser plugin and filter at the endpoint.
I do not disagree with you in principle. What you are describing works well for personal users in a home environment. But in a larger organization or company, I am unsure how to fully resolve the conflict between protection of individual privacy and the obligation to protect the assets and reputation of the organization, without at least some use of SSL intercept.
Internal actors, or attackers with stolen credentials, can avoid exploiting vulnerabilities or using malware. They can use only the tools already available to the user whose credentials they have stolen. Fixing security vulnerabilities is insufficient.
Without SSL intercept, DLP is very difficult. Vast amounts of PII, credit card numbers, or intellectual property can leave the environment undetected. And if you cannot prove which information was accessed and exfiltrated, then by law in some jurisdictions, you must assume the worst case (that *all* of the information was exfiltrated). This can have significant legal, financial, and reputational consequences.
One partial solution is to create a separate network for personal Internet use while at work. For the internal network, enable SSL intercept, and build an explicit whitelist of all connections that are allowed to use encryption from the organization's internal network, disallowing *all* other encryption or personal site use there.
This is a compromise that is an inconvenience for users, but it may be the only currently practical method to avoid tampering with authenticity and invasion of privacy, while still protecting the organization.
Internal actors, or attackers with stolen credentials, can avoid exploiting vulnerabilities or using malware. They can use only the tools already available to the user whose credentials they have stolen. Fixing security vulnerabilities is insufficient.
Without SSL intercept, DLP is very difficult. Vast amounts of PII, credit card numbers, or intellectual property can leave the environment undetected. And if you cannot prove which information was accessed and exfiltrated, then by law in some jurisdictions, you must assume the worst case (that *all* of the information was exfiltrated). This can have significant legal, financial, and reputational consequences.
One partial solution is to create a separate network for personal Internet use while at work. For the internal network, enable SSL intercept, and build an explicit whitelist of all connections that are allowed to use encryption from the organization's internal network, disallowing *all* other encryption or personal site use there.
This is a compromise that is an inconvenience for users, but it may be the only currently practical method to avoid tampering with authenticity and invasion of privacy, while still protecting the organization.
If I understand it correctly your concern is that you have internet-connected machines with people working on them that you don't trust and they have access to sensitive data.
Now I would question if this is an especially wise setting. But given what you say I assume you have full control over the machines and the users ony have limited control. Because if the latter wouldn't be the case you have lost already.
What you could do is implement some kind of browser-plugin based solution. I'm not sure how feasible it is to implement a browser plugin that the user can't disable, but there probably is a way.
But I really find your scenario hard to imagine in practise. You'd also have to prevent people from bringing cameras with them or use any software that they could use to obfuscate data and hide it in other data.
Now I would question if this is an especially wise setting. But given what you say I assume you have full control over the machines and the users ony have limited control. Because if the latter wouldn't be the case you have lost already.
What you could do is implement some kind of browser-plugin based solution. I'm not sure how feasible it is to implement a browser plugin that the user can't disable, but there probably is a way.
But I really find your scenario hard to imagine in practise. You'd also have to prevent people from bringing cameras with them or use any software that they could use to obfuscate data and hide it in other data.
I checked my certificate manager, shocked to see root CA certificate installed by my anti-ads software - Adguard!
It looks to be working as what you wrote, a MITM attack software to block ads but there was no warning or asking me for permission during the install.
Much thanks if you can do a quick analysis to see how good or bad it works.
It looks to be working as what you wrote, a MITM attack software to block ads but there was no warning or asking me for permission during the install.
Much thanks if you can do a quick analysis to see how good or bad it works.
Had a look at it. It's bad. It's bad in a very interesting and creative way.
If you have adguard installed: Remove it together with its cert immediately. It's a huge security risk. I'll post details later.
If you have adguard installed: Remove it together with its cert immediately. It's a huge security risk. I'll post details later.
> What do you want to do?
Parental control.
> Is that legit at all?
It is actually required by the applicable laws in some jurisdictions for schools, and blocking all HTTPS traffic, or all HTTPS traffic to some domains, is not an option.
In my opinion, the real problem is the lack of the way to both do the MITM and to give the browser a chance to make negative decisions based on the original certificate (of course, with the knowledge that the connection is MITMed by this particular party).
Parental control.
> Is that legit at all?
It is actually required by the applicable laws in some jurisdictions for schools, and blocking all HTTPS traffic, or all HTTPS traffic to some domains, is not an option.
In my opinion, the real problem is the lack of the way to both do the MITM and to give the browser a chance to make negative decisions based on the original certificate (of course, with the knowledge that the connection is MITMed by this particular party).
If there is a law that requires you to compromise your IT security that's just stupid. I refuse to make any suggestions how technology can fix that. I don't see this as any kind of argument for a broken approach.
Simple: browsers should support traffic scanning, providing anti-virus software access to the decrypted data before using it in any way.
I wouldn't worry to much about cyber criminals buying an EV certificate to deliver malware; the Extended Validation ceritificates are quite costly to come by, only work for a single (sub)domain (no wildcard) and requires an extensive validation (hence the name) that a company is really existant and has requested the certificate.
Save hacking a web server with an EV certificate, using EV to conceal malicious traffic is just too costly. And if some of the few domains with EV certificates are hacked, they should be easy enough to blacklist; it isn't like you can obtain a new EV certificate instantly. (At least, I hope so.)
Using obfuscation techniques to conceal malware and exploits will be more cost-effective for cyber crimials in most (if not all) cases.
Save hacking a web server with an EV certificate, using EV to conceal malicious traffic is just too costly. And if some of the few domains with EV certificates are hacked, they should be easy enough to blacklist; it isn't like you can obtain a new EV certificate instantly. (At least, I hope so.)
Using obfuscation techniques to conceal malware and exploits will be more cost-effective for cyber crimials in most (if not all) cases.
It breaks DANE (DNS-based Authentication of Named Entities) or makes it impossible to use.
As Hanno said, the right approach for signaturebased- and heuristic antivirus products is to examine local content and not traffic. A browser-plugin can inspect without breaking TLS. The plugin may introduce other vulnerabilities into the browser too, btdt - that is another story.
If you try to rely on antivirus products, your security won't work and will break, because antiviri even with heuristics only work against known threats and provide no other security or mitigation options.
Speaking of most browsers, Firefox and Chrome have integrated databases (bloomfilters) for malicous sites and webforgeries and apis (plugins and extensions) that let you intercept content at any point.
Intercepting into a certificate based a trust-model like TLS is the wrong way. It doesn't work on a standalone networked computer, it barely works in a separated networked setting.
For parental controls in schools, the kids nowadays have smartphones. There is a reason it is called parental control, because parents should be involved in it.
If you like to filter content, there are ratings and dns-services available that provide a white internet. As a concerned parent you are better off to educate your kid/s as to censor or spy on them.
The pricing of certificates provides no additonal security, neither does the review process.
As Hanno said, the right approach for signaturebased- and heuristic antivirus products is to examine local content and not traffic. A browser-plugin can inspect without breaking TLS. The plugin may introduce other vulnerabilities into the browser too, btdt - that is another story.
If you try to rely on antivirus products, your security won't work and will break, because antiviri even with heuristics only work against known threats and provide no other security or mitigation options.
Speaking of most browsers, Firefox and Chrome have integrated databases (bloomfilters) for malicous sites and webforgeries and apis (plugins and extensions) that let you intercept content at any point.
Intercepting into a certificate based a trust-model like TLS is the wrong way. It doesn't work on a standalone networked computer, it barely works in a separated networked setting.
For parental controls in schools, the kids nowadays have smartphones. There is a reason it is called parental control, because parents should be involved in it.
If you like to filter content, there are ratings and dns-services available that provide a white internet. As a concerned parent you are better off to educate your kid/s as to censor or spy on them.
The pricing of certificates provides no additonal security, neither does the review process.
ESET is aware of the issue with TLS 1.2 support and a fix will be available soon.
But anyway this only affects Firefox users. Other browsers should be able to use up to TLS 1.2 without any issues.
More information: https://forum.eset.com/topic/4234-ssl-inspection-tls-12-support/
Also EV certificates are scanned by ESET. More information here: https://forum.eset.com/topic/4806-ways-anti-virus-software-lowers-your-https-security/
But anyway this only affects Firefox users. Other browsers should be able to use up to TLS 1.2 without any issues.
More information: https://forum.eset.com/topic/4234-ssl-inspection-tls-12-support/
Also EV certificates are scanned by ESET. More information here: https://forum.eset.com/topic/4806-ways-anti-virus-software-lowers-your-https-security/
Regarding school filtering and MITM.. I just found out today that fortinet fortiguard does no https certificate checking whatsoever.
Sigh...
Sigh...
This kind of proves your point:
https://docs.google.com/a/wimdu.com/spreadsheets/d/1t5GXwjw82SyunALVJb2w0zi3FoLRIkfGPc7AMjRF0r4/edit#gid=1053404143
That's a list with Android apps failing to validate SSL correctly. Among those are about 34 anti virus apps.
https://docs.google.com/a/wimdu.com/spreadsheets/d/1t5GXwjw82SyunALVJb2w0zi3FoLRIkfGPc7AMjRF0r4/edit#gid=1053404143
That's a list with Android apps failing to validate SSL correctly. Among those are about 34 anti virus apps.
Quicksearch
About me
Informationen über meine Arbeit als freier Journalist finden Sie hier.
Hanno Böck
mail: hanno@hboeck.de
jabber: hanno@hboeck.de
GPG/OpenPGP key
Hanno on Twitter
Impressum
Hanno Böck
mail: hanno@hboeck.de
jabber: hanno@hboeck.de
GPG/OpenPGP key
Hanno on Twitter
Impressum
Creative Commons
Unless noted otherwise, all content is CC Zero / public domain
Tracked: May 01, 21:53
Tracked: May 04, 12:13
In February the discovery of a software called Superfish caused widespread attention. Superfish caused a severe security vulnerability by intercepting HTTPS connections with a Man-in-the-Middle-certificate. The certificate and the corresponding private ke
Tracked: Aug 13, 00:45