Blogs

    Publish
     
      • The FREAK Vulnerability; What You Need to Know

        Oct 20 2017, 8:43 PM

        by Unknown 3

        A new SSL/TLS vulnerability named “FREAK” was identified by several security researchers. It’s a threat because FREAK allows an attacker to get between a client and server and view what is intended to be a secure and private communication. The vulnerability is primarily due to a bug in OpenSSL client software and Microsoft's SChannel library, but only exploitable on poorly-configured web servers. Both clients and servers are at risk. Web site owners can protect their sites by properly configuring their web servers. End users will need to wait for software vendors to release new versions that include a fix.

        Note that this vulnerability is not related to SSL certificates. Your existing certificate will continue to work as intended; no certificate replacement is needed.

        Organizations should evaluate their web servers to determine if they are vulnerable.  Symantec offers an easy-to-use check in its SSL Toolbox to allow customers to easily verify that their web sites are safe or vulnerable. At the time of this writing, Symantec is evaluating its own systems and no Symantec web servers appear to be vulnerable.

        Blue Digital Lock 600X.jpg

        Technical Details:

        It’s relatively easy to determine if a website is vulnerable, and if so, it’s relatively easy to change the configuration to block any possible attacks. Any type of web server (Apache, IIS, nginx, etc.) may be vulnerable if its configuration allows the use of so-called Export Ciphers. In Apache/OpenSSL documentation, for example, the names of these ciphers all begin with EXP (from https://httpd.apache.org/docs/2.4/mod/mod_ssl.html):

        EXP-DES-CBC-SHA

        EXP-RC2-CBC-MD5

        EXP-RC4-MD5

        EXP-EDH-RSA-DES-CBC-SHA

        EXP-EDH-DSS-DES-CBC-SHA

        EXP-ADH-DES-CBC-SHA

        EXP-ADH-RC4-MD5

        If a customer’s web server supports these ciphers, the customer must reconfigure the web server by removing these ciphers from the list of supported ciphers, and restart the web server. Although not related to this vulnerability, customers should also disable null ciphers if they are supported, since such ciphers do not provide any encryption of the SSL stream:

        NULL-SHA

        NULL-MD5

        In Windows, the names of export ciphers contain the string “EXPORT”. Here is a list taken from http://support.microsoft.com/kb/245030:

        SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA

        SSL_RSA_EXPORT1024_WITH_RC4_56_SHA

        SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5

        SSL_RSA_EXPORT_WITH_RC4_40_MD5

        TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

        TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

        TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

        TLS_RSA_EXPORT_WITH_RC4_40_MD5

        NULL

        We advise customers to consult their web server documentation to determine how to view the list of supported ciphers, and how to disable certain ciphers.

        Additional guidance from Symantec

        FREAK is another reminder that website security is not just about certificates. Symantec has numerous articles and white papers on security best practices and technical areas related to SSL/TLS and code-signing issues.  Please stay tuned to our Connect blog site for up-to-date information on this and other critical vulnerabilities, for other topics related to advanced threat protection, and for security industry news.  Please access our learning center for more resources that can help your organization make critical decisions related to web server security.  For technical details to help with troubleshooting please bookmark our SSL/TLS and code-signing knowledge base.

        Update: The FREAK vulnerability was reclassified from LOW to HIGH on March 19, 2015 by the OpenSSL team.

        • Products
        • website security solutions
        • Vulnerability Assessment
        • Symantec Website Security
        • FREAK
        • DigiCert SSL TLS Certificates
        • vulnerability
        • Products and Solutions
      • Superfish

        Feb 24 2015, 11:26 PM

        by Unknown 3

        A security flaw was discovered in software that was pre-installed on some Lenovo laptops. Lenovo has issued the following Press Release.  The story has been reported on multiple sites (for example, here and here). We applaud Lenovo for quickly publishing details on affected models and instructions for removing the flaw. The problem lies in the software from a company called Superfish that was pre-installed by Lenovo on certain computers. The main function of the software was to intervene when the user performed web searches in IE or Chrome browsers, and insert Superfish’s content into the search result page. Lenovo enabled this software to “help users find and discover products visually”, by incorporating relevant search results not offered by the search engine.

        Interjecting content in web pages is not new (for example, via browser add-ons), but Superfish’s approach was novel, and didn’t use a browser add-on. Instead, the software intercepted all traffic between the browser and the network external to the computer. But since most large search engines (such as, Google, Bing, and Yahoo) now serve all content over https, the Superfish software couldn’t read (and more importantly, modify) any of that encrypted traffic. To get around this, an SSL Man-in-the-Middle (MITM) was set up in the computer itself, creating fake SSL certificates with the domain name of the intended web site. These certificates were signed by or chained up to Superfish’s private root certificate. Ordinarily, browsers would display a prominent warning that such a certificate wasn’t trusted, so that was addressed that by injecting Superfish’s root certificate into the Windows trusted root store during manufacture. To make all this work, of course, the private key corresponding to that root certificate had to be pre-installed on all of these computers. Superfish took steps to encrypt that private key, but the encryption was trivial and quickly broken.

        The result is that attackers now have the private key corresponding to a root certificate that is trusted in these Lenovo computers, and that can be abused in too many ways to describe here.

        In some ways, this is similar to the recent incident with Gogo inflight wifi service. Both make use of an SSL MITM technique to insert themselves into the otherwise secure connection between a browser user and the websites they visit. See our recent blog post to learn how SSL MITM attacks work. In Gogo’s case, the MITM (the actor generating certificates on the fly) was in Gogo’s network; in Superfish’s case, the MITM is in the computer itself.

        As we’ve said before, SSL Man-in-the-Middle solutions can be justified within an enterprise, for example, to monitor employees’ web traffic. But the well-intentioned inclusion of Superfish had unintended consequences far beyond web searching, and created a potential for malicious MITM attacks. Pre-installing any root that does not belong to an audited Certificate Authority and marking it as trusted undermines the trust model created and maintained by platform vendors, browser vendors, and Certificate Authorities. Platform and browser vendors go to great lengths to validate the Certificate Authorities whose roots they include in their trusted root store. Microsoft provided the ability for an enterprise to add additional roots to the Windows trusted root store, and Google Chrome explicitly avoids performing public-key pinning checks for such added roots. As a result, Chrome users receive no warning of the MITM, as they did in the Gogo incident.

        If you think you may have an affected Lenovo computer, visit this web site to check. Uninstalling the Superfish software isn’t enough to remove the vulnerability – you must also remove the Superfish root from the Windows trust store. The instructions provided by Lenovo achieve both objectives.

        • Products
        • website security solutions
        • Symantec Website Security
        • DigiCert Code Signing
        • vulnerability
        • Products and Solutions
        • adware
        • Security
      • The SSL 3.0 Vulnerability – POODLE Bug (AKA POODLEbleed)

        Oct 20 2017, 8:27 PM

        by Brook Chelmo 4

        SSLv3_poodle-300px.png

        A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and detailed how it could be exploited through what they called a Padding Oracle On Downgraded Legacy Encryption (POODLE) attack (CVE-2014-3566).

        (Updated Dec. 9, 2014) Recently, a new variant of the POODLE vulnerability (CVE-2014-8730) was found to affect even versions of TLS, the successor to the SSL protocol.  This new vulnerability works against sites that use load balancers that have incorrectly implemented encryption padding checks, and may affect around 10% of servers.  Certain models of F5 and A10 load balancers are susceptible, and as part of best practices we recommend that users apply vendor-supplied patches as they become available.

        It is important to note that this is NOT a flaw in SSL certificates, their private keys, or their design but in the old SSLv3 protocol.  SSL Certificates are not affected and customers with certificates on servers supporting SSL 3.0 do not need to replace them.

        It’s believed to not be as serious as the Heartbleed bug in OpenSSL, since the attacker needs to have a privileged position in the network to exploit the latest.  The usage of Hotspots, public Wi-Fi, makes this attack a real problem. This type of attack falls into the “Man-in-the-middle” category. 

        Background

        While SSL 3.0 was introduced in 1996, it is currently supported by nearly 95% of Web browsers according to Netcraft’s latest report.  Many Transport Layer Socket (TLS) clients downgrade their cryptography protocol to SSL 3.0 when working with legacy servers. According to Google, an attacker that controls the network between the computer and server could interfere with the handshake process used to verify which cryptography protocol the server can accept using a “protocol downgrade dance”. This will force computers to use the older SSL 3.0 protocol to protect data that is being sent. Attackers can then exploit the bug by carrying out a man-in-the-middle (MITM) attack to decrypt secure HTTP cookies, which could let them steal information or take control of the victim’s online accounts.  Although, at the time to writing, webmasters have been disabling SSL 3.0 and moving to TLSv1 and above at a rapid pace, there still remains a lot of work to be done.  If Heartbleed taught us anything, it’s that the largest companies act fast while many small companies drag their heels in patching critical vulnerabilities. 

        What Businesses Need to Do

        In order to mitigate the bug there are a few courses of action:

        1. Check to see if your webservers are vulnerable using our free SSL Toolbox.
        2. Disable SSL 3.0 altogether, or disable SSL 3.0 CBC-mode ciphers
        3. A cloud-based Web Application Firewall can help protect against this kind of vulnerability.  For more information please visit our website.
        4. Be leery of any spam messages from scammers trying to capitalize on uncertainty and a lack of technical knowledge.
        5. If applicable, implement F5’s patch.  For information on A10 Networks, please click here for their patch.

        My fellow colleague Christoffer Olausson gives a few tips on how to fix this on Apache:

        > SSLProtocol All -SSLv2 -SSLv3                   <- Removes SSLv2 and SSLv3

        > apachectl configtest                                   <- Test your configuration

        > sudo service apache restart                      <- Restart server

        At the time of writing Google and Mozilla have either removed SSL 3.0 support from their browsers or are in the process of doing so.

        What End-Users Need to Do

        For end-users accessing websites Symantec recommends:

        1. Check to see if SSL 3.0 is disabled on your browser (for example, in Internet Explorer it is under Internet Options, Advanced Settings).
        2. Avoid MITM attacks by making sure “HTTPS” is always on the websites you visit.
        3. Monitor any notices from the vendors you use regarding recommendations to update software or passwords.
        4. Avoid potential phishing emails from attackers asking you to update your password – to avoid going to an impersonated website, stick with the official site domain.

        More Information

        Symantec has published knowledge base articles on the subject for your reference.  See below:

        Symantec Managed PKI for SSL Users

        https://knowledge.verisign.com/support/mpki-for-ssl-support/index?page=content&id=AR2182

        Symantec Trust Center/Trust Center Enterprise Users

        https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR2183

        Stay Connected

        Stay connected with us for more updates on this vulnerability and others.  Follow us on Twitter, Facebook, or visit our technical forums for issues with managing SSL and code-signing certificates.

        • POODLEbleed
        • SSLv3
        • Poodle bug
        • Products
        • bug
        • website security solutions
        • SSL
        • POODLE Attack
        • SSL 3.0
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • vulnerability
        • Products and Solutions
        • POODLE