Security tools versus SSL hijackers with root certs

Discussion in 'other anti-malware software' started by BoerenkoolMetWorst, Feb 26, 2015.

  1. 142395

    142395 Guest

    Well, I know browser can operate FTP but not sure about FTPS. Maybe SFTP is not available as it uses SSH.
    You make a good point.
    PKI.js which uses Webcrypto API can verify cert chain. I don't know how IETF (or other? like CASC?) thinking about next TLS.
    Read the article and still have many questions.

    -What encryption/cypher and protocol does Avast use in e.g. default IE11 on Win7?
    -How do/did you confirm Avast checks cert correctly (considering past bugs in Apple, GnuTLS, etc.)
    -Does Avast use OS cert store when using Firefox too?
    -What if when OCSP request failed. By default browser just continue to connect but in Firefox and its derivation user can force hard-fail so that if OCSP failed connection will be blocked.
    -Does Avast block TLS fall back?
    -Does Avast use TLS compression?
    -Does Avast support HSTS?
    -Does Avast support OCSP stapling?
    -I think Avast doesn't support channel ID, right?
    -Does Avast applied all TLS patches e.g. 3Shake (KB257591 for IE) and will do ASAP?

    No need to reply all of them but if you can answer even part of them, I'm very happy. Thanks!
     
  2. vlk

    vlk AV Expert

    Joined:
    Dec 26, 2002
    Posts:
    621
    Thanks for the questions, Yuki. These are some very good questions, and I'm happy to answer them here.

    Encryption cipher is negotiated during the HTTPS Handshake. Avast offers the same set of ciphers offered originally by the client (if they are also supported by latest OpenSSL version 1.0.2 - i.e. the version used in Avast 2015 R2) and the actual cipher is always selected by the server side of the handshake. You can check selected cipher and other connection properties e.g. here: https://www.ssllabs.com/ssltest/viewMyClient.html

    Avast verifies the certificates using Windows System API - Crypto API with revocation list enabled (CLR, OCSP), you can check against any online available site providing certificates with various flaws. That is, feel free to test with https://revoked.grc.com/ or https://testssl-expire.disig.sk/index.en.html etc.

    The level of security check in this case is bound to the current state of Windows - so updating windows and applying patches is important.

    Yes. This also means that certificates stored in Firefox cert store are not used with Avast.

    Avast to continues to connect.
    However, the behavior you're describing with Firefox is a good idea, we're writing it down for consideration as an option in future versions.

    TLS_FALLBACK_SCSV is forwarded from client to server. If the client (browser) adds TLS Fallback to the handshake, it will remain there with Avast. (Avast 2015 R2)

    No.

    HTTP Strict Transport Security (HSTS) is mirrored in the connection, it's up to the client to enforce it - Avast presence does not change anything with regard to HSTS.

    Currently, no. Support for this is being added in the internal versions and will be included in the public versions in the next couple of months though.

    Not at the moment, mainly because it is currently not supported by OpenSSL. However, it has been added by a patch to the Chromium project, so we might add this in some future versions.

    3Shake patch is addressed by an extended master secret patch, currently prepared in the pre-release version of OpenSSL 1.1.0. Avast currently uses ver 1.0.2 of OpenSSL and will apply the patch (upgrade to the newest version ) as soon as it is promoted to stable.


    Again, thanks much for the great question. Our aim is to be totally transparent about this feature, and discussion like this certainly helps.

    If you have any more questions please don't hesitate to ask.

    Thanks,
    Vlk
     
  3. 142395

    142395 Guest

    Thanks for reply, I'm impressed by your transparency as I didn't expected such full reply. It's second time as I was also impressed when you brought counterargument against HowToGeek for their claim "Avast is spying on you", you essentially emaschlated their claim as most important point was URL sending which all of us know it's for malicious site blocking and necessary cloud function.
    I was not clear, but I meant client-side priority for cypher suites. As you know, it's less important than server-side priority but some geeks here modify default priority. Anyway so Avast's priority is same as OS which is used in IE.

    From other replies, okay I got Avast try to be as transparent as possible to TLS, but some technologies are still in development or consideration.

    I'm happy to see Avast takes security seriously, as some well-known competitor only looking at malware prevention and fails to see whole user protection.

    Maybe only thing left is, as itman suggested, user defined exclusion for TLS scanning...well, I thought Avast had exclusion for web shield, is it works for TLS scanning too?

    Oh, and one more question now arose...does TLS scan also enabled for Safezone browser when visiting not whitelisted sites?
    And tho it is off topic... did you take some measure for Safezone's Chromium version which was behind latest?
     
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
  6. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
  8. 142395

    142395 Guest

    Chrome's HPKP is by default only for some major websites, and if you want to add other websites you have to add command line parameter w/ BASE64 encoded thumbprint which tend to be extremely long, so not usable at all.
    I use DNSSEC validater as well as TLSA for Firefox. I tried Chrome version w/ their plugin + addon, but somehow it didn't work (I'll try it again).
    So far, DANE is not available for most sites. But I think this is quite promising, maybe first attempt of TLS not relying CA.
     
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Found a web site/project that maintains a blacklist of fraudulent SSL certificates. The "aggressive" .csv download that lists sites by IP is very interesting; 755 in count presently. IPs could be imported into whatever you are currently using for IP blocking.

    https://sslbl.abuse.ch/blacklist/
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Now that I have Eset Smart Security installed, I decided to re-visit this article I had posted previously about Eset's SSL protocol checking: https://device5.co.uk/blog/do-not-use-eset-ssl-protocol-filtering.html .

    First, the issue about the downgrade to TLS 1.0. Yes, at first glance that is a no-no. Especially, if it's one of your financial web sites that most likely support a higher TLS value. However, this filter was designed to check all HPPS web sites and ISP e-mail servers using SSL/TLS protocols, the later for many only supporting TLS 1.0, for filtering of malware.

    As it turns out, the SSL protocol checking feature does have a number of ways to exclude web site SSL certificates from being scanned.

    The first is an "Ask about non-visited web sites" option. This is probably the easiest way to prevent your financial web sites from being scanned. You can set an exclusion for that site's SSL certificate using this option. Repeat for each web site you want excluded.

    When all excluded certificates have been created, you can then set on the "Apply created exceptions based on certificates option" which will activate the bypass of SSL certificate for the previously excluded web sites. You will also have to set on the "Always scan SSL protocol" to enable the filtering of all HTTPS web sites.

    Note: Doing the above means that those excluded certificates will not be validated for MITM attacks and the like. So, you will have to use something like EMET's certificate pinning for the excluded web sites.

    Also as an option, you can manually create a custom list of trusted SSL certifcates e.g. self-signed certificates, in addition to those present in the Trusted Root CA store . In this section, you can like add like certificates to be excluded from all of Eset's SSL certificate scanning. Obviously, you would only want add excluded certificates here due to the TLS 1.0 downgrading issue.

    Summary - given the widespread existence of malware on HTTPS we sites, you do want to filter these for these threats. You just want to ensure you are "not shooting yourself in the foot" when it comes to securing your sensitive financial data.

    I will be playing around with this and posting back my findings.

    -UPDATE- There is a much easier way to accomplish the above. You can exclude by url including the wildcards of "*" and "?"; probably not a good idea to use those. Also by IPv4 and IPv6 address.

    Now I am pondering my incoming e-mail traffic via IMAPS using Thunderbird from my ISP's e-mail server. I have that set to TLS encryption. So I guess I will have to allow Eset SSL protocol scanning of it. Otherwise there is no way to check it for malware. No one sends me real encrypted e-mail.

    -UPDATE 2- I could not get the "*" wildcard option to work. So at this time, I would say that only single domain exclusion is possible.

    I also did export Eset root cert. into Thunderbird and modified it to check web sites and it appears to be working fine.
     
    Last edited: Apr 17, 2015
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    This is an eye opener! Appears my bank's home page is doing some type of man-in-the-middle-activity for who knows what reason.

    Methodology

    I used Eset's SSL protocol scanning in exclude mode to build a listing of all certs. my bank uses. Unbelievable as it is, it uses at least 11+ certs. i.e. one per web page directly related to itself plus additionally certs. assigned to places like *.vo.msnmd.net, *.carlytics.com, etc.. I did not exclude the later since God knows what they are doing and decided to let Eset scan those with it's root cert. One thing I really like about the Eset feature is that it will also show the intermediate CA cert. associated with the base web site certificate.

    Next I pinned those 11+ directly related bank certs using EMET's certificate pinning feature. Not a real big deal since they all use the same VeriSign G5 trusted root certificate.

    Then I tested the bank web site. All was fine except for one hidden cert associated with the bank's home web page. So using Quals SSL web site checker and the SSL Test from www.networkingforall.com, I verified the dodgy site certificate validation path to the trusted root CA certificate. Low and behold, the intermediate CA cert. shown was not the same as that excluded in Eset.

    So I disabled EMET's cert pinning rule for the questionable cert and repeated the Eset SSL protocol excluded process. This time, Eset did register the correct intermediate CA. So I assumed that Eset just flaked off or something. Next I re-enabled EMET pinning for the questionable web site. Then retested by accessing the bank's home web page where the dodgy certificate existed. Again, I was receiving pinning alerts from EMET. WTF?

    Additionally for all these tests, IE was alerting me of certificate errors for the dodgy cert itself although both Quals and the above other validation sites I used showed the cert OK.

    Bottom Line

    At this point, I don't believe my bank's home logon web page is hacked although that is possible. What I believe the bank is doing some under the table activities that violate the concept of SSL certificate authorization.
     
  12. Victek

    Victek Registered Member

    Joined:
    Nov 30, 2007
    Posts:
    6,219
    Location:
    USA
    Why not call their support and talk with them? You might be doing them a favor...
     
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I just retested the bank site and I am no longer receiving cert validation errors related to the dodgy cert. Possibility, they detected my test activities yesterday?

    In any case, I can't think of a better example for using EMET's cert pinning feature.
     
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    An argument can be made that Eset SSL protocol checking is verifying that a web site's root certificate is legit, so why to I need EMET's certificate pinning? Note the key word here is "pinning."

    Eset will transverse the certificate signing path and ensure that the web site's root certificate is stored within the trusted root certificate store in Windows, but it has no way of determining if indeed that root certificate is indeed the correct one. Any software using a variant of Komodia Redirector or like software can install a "bogus" signed certificate in your root certificate store. Hence, Eset will just use that certificate for it's SSL checking as best as I can determine. -EDIT- As shown in my previous bank episode posting, I actually was pointed to two different certificates in IE's intermediate CA cache by the bad web site certificate. To make matters worse, both intermediate CA certs were valid. However because of the deviation from the "approved" intermediate CA certificate, it was a clear indication that something was tampering with the chain of authority path.

    The only way that a certificate path can be accurately verified is by using a web site such as Quals to verify the root certificate from a 100% malware free PC. Once the root certificate has been verified, you have two choices. Compile a list of these certificates and manually verify the root cert by clicking on the lock symbol in your browser toolbar(note: I believe there are documented instances where this has been hacked) for each critical SSL secured web site you frequent or pin the manually acquired root certificate to the web site domain name using EMET's certificate pinning.

    Note that the above Eset SSL protocol checking or EMET's certificate pinning are mutually exclusive due to Eset's use of it's own root certificate to decrypt communication. Since I adhere to the principle that nothing no way should be decrypting communication to my sensitive financial web sites, this set up works just fine for me. I use Eset SSL protocol checking for any non-critical SLL web sites and EMET certificate pinning for my critical SSL web sites.

    My hope is Eset will add a certificate pinning feature to it's software. Then I can stop using EMET's certificate pinning which is problematic on X64 browsers using various forms of sandboxing including IE's EPM mode. Better yet would be AV/AM software that would allow you to pin the entire certificate path including the intermediate CA cert. Then using it's servers, independently verify the pinned certificate path to that given on a SSL path verification web site! Of course, an option would have to be provided to opt out of their decryption processing.

    Finally note that certificate pinning is a laborious process; certs expire, root and intermediate CAs change, etc..
     
    Last edited: Apr 18, 2015
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Came across this doctoral thesis that is an interesting read. Below is the abstract and one interesting excerpt.

    Abstract—The SSL man-in-the-middle attack uses forged SSL certificates to intercept encrypted connections between clients and servers. However, due to a lack of reliable indicators, it is
    still unclear how commonplace these attacks occur in the wild. In this work, we have designed and implemented a method to detect the occurrence of SSL man-in-the-middle attack on a top global website, Facebook. Over 3 million real-world SSL connections to this website were analyzed. Our results indicate that 0.2% of the SSL connections analyzed were tampered with forged SSL certificates, most of them related to antivirus software and corporate-scale content filters. We have also identified some SSL connections intercepted by malware. Limitations of the method and possible defenses to such attacks are also discussed.


    We observed 330 instances of forged certificates issued by a company named Sendori. This company offers a browser add-on that claims to automatically correct misspelled web pages. However, using Google Search to query the string “Sendori” revealed alarming discussions about the add-on actually hijacking DNS entries for the purposes of inserting advertisements into unrelated websites. This form of adware actively injects content into webpages, and could possibly be detected using Web Tripwires or CSP (as described in Section II-D).

    https://www.linshunghuang.com/papers/mitm.pdf
     
    Last edited by a moderator: Apr 22, 2015
  16. BoerenkoolMetWorst

    BoerenkoolMetWorst Registered Member

    Joined:
    Dec 22, 2009
    Posts:
    4,868
    Location:
    Outer space
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Great idea! However, it sounds like it's an on/off thing. If you do chose to use a security vendor's root CA, all you will receive is constant wanings? He didn't provide any exclusion ability that I could find in the article?
     
  18. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
  19. BoerenkoolMetWorst

    BoerenkoolMetWorst Registered Member

    Joined:
    Dec 22, 2009
    Posts:
    4,868
    Location:
    Outer space
    Yes, I also checked with Opera developer, but it seems there is no exclusion ability, maybe it will come in a later version. Though the question is probably how to do it securely, otherwhise malware might add itself to the whitelist.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.