Search the Community

Microsoft has blacklisted a phony SSL certificate that’s been making the rounds and is in the process of warning the general public that the certificate could be leveraged to stage man-in-the-middle attacks. In a security advisory published yesterday the company stressed that an improper certificate for the domain “live.fi” could also be used to spoof content or carry out phishing attacks, but stopped short saying it could issue other certificates, impersonate other domains, or sign code. The certificate, which corresponds to one of the company’s Live entities, was revoked by its issuer, certificate authority Comodo, and Microsoft has updated its Certificate Trust List (CTL) to reflect the instability. The company maintains an often in-flux Certificate Trust List as a running tally of trusted entities that are rooted to verifiable certificates. Microsoft blamed the botched certificate on a misconfigured privileged email account on the live.fi domain. It sounds like unauthorized third party was able to register an email account on the domain with a “privileged username,” and in turn used it to request a bogus certificate for live.fi. In a FAQ on its site, Comodo claims that all of its certificates must pass through Domain Control Validation (DCV) before they’re issued. It appears the aforementioned third party used an email (admin@, administrator@, postmaster@, etc.) to prove ownership of the domain and subsequently the certificate. Windows 8, 8.1, RT, RT 8.1, Server 2012 and Server 2012 R2 all contain an automatic updater that takes note of revoked certificates. The company warns that users who either opt not to run that automatic updater or run older setups, including Server 2003, should run the manual update KB2917500 to blacklist the certificate. It’s expected both Google Chrome and Mozilla Firefox will block the certificate over the next several days or so. In the very near future Firefox is expected to loop in a new feature, OneCRL, that will supersede the dated Online Certificate Status Protocol (OCSP) and improve upon the process in which the browser reviews and revokes certificates. Source

The shoddy state of SSL certificate validation on the Internet again floated to the surface, this time by the Superfish mess, which continues to get worse. The Electronic Frontier Foundation on Wednesday released a report based on data scoured from the Decentralized SSL Observatory which it maintains shows the number of certificates that were improperly validated by the Komodia library at the core of the Superfish fiasco has climbed to over 1,600. While it’s impossible to determine, EFF researchers say it’s probable that Komodia software did enable some real-world man-in-the-middle attacks. The Komodia software, which was built into the Superfish adware pre-installed on Lenovo computers, contains a vulnerability that breaks HTTPS connections and allows an attacker to pull off man-in-the-middle attacks. EFF staff technologists Jeremy Gillula and Joseph Bonneau said that some of the domains affected by Komodia include Google’s mail domain, Yahoo log-in domains, Bing, Windows Live Mail, Amazon, eBay checkout and Superfish.com among many others. “While it’s likely that some of these domains had legitimately invalid certificates (due to configuration errors or other routine issues), it seems unlikely that all of them did,” Gillula and Bonneau wrote in their report. “Thus it’s possible that Komodia’s software enabled real MitM attacks which gave attackers access to people’s email, search histories, social media accounts, e-commerce accounts, bank accounts, and even the ability to install malicious software that could permanently compromise a user’s browser or read their encryption keys.” Komodia’s behavior of adding a new root certificate and dubious alterations to a computer’s network stack, validates certificates that should otherwise raise a browser warning. “This means that an attacker doesn’t even need to know which Komodia-based product a user has (and thus which Komodia private key to use to sign their evil certificate)—they just have to create an invalid certificate with the target domain as one of the alternative names, and every Komodia-based product will cause it to be accepted,” they wrote. Gillula told Threatpost that contextually the situation is not surprising given that the certificate system has been teetering on disaster for some time, a situation that’s complicated by the sheer number of Certificate Authorities at work on the Internet, many of which could also be interdicted by law enforcement or repressive government. “The most egregious thing is the idea that companies think it’s OK to interfere with people’s encrypted traffic even on their own machines,” Gillula said. “That they think it’s OK to install a root cert and go to town on it.” Gillula said he was compelled by reports related to Superfish that pointed out that an attacker would have a relatively easy time sliding an invalid certificate into legitimate traffic by inserting the domain they wanted to use in a man-in-the-middle attack into the Subject Alternative Name field. “It would go right on through,” Gillula said. Searching for that scenario in the Decentralized SSL Observatory was also relatively simple, Gillula said. It required a query that searched for certificates that contained a unique string called verify_fail[domain name] in the Subject Alternative Name field used by one of the software applications identified as running the Komodia SSL Digester proxy. “Lo and behold, we discovered that a lot of these certs when they hit the proxy are invalid, but Komodia changes them and because of the alternative name, ended up being valid when they hit the browser,” Gillula said, adding that Komodia wipes away any traces of a potential man-in-the-middle attack making it impossible to determine whether an attack occurred or a merely a misconfigured certificate popped up in the search. The real problem, however, are the practices of third-party vendors such as adware purveyors like Superfish who build tools to intercept traffic and manipulate certificate validation, moving it outside the browser. “The lesson for vendors is that they should stop trying to man-in-the-middle SSL connections on customer machines,” Gillula said. “Unless they’re willing to put in a lot of significant engineering effort to verify they are doing things correctly, chances are there’s going to be a bug and it’s a dangerous thing to do.” Source

How To Assess a Third Party Web Site or Cloud Service with the OWASP ZAP Attack Proxy When You Don’t Have Permission to Pentest As a security professional, you will often be asked to give your opinion or assessment on the security of a third-party web site or cloud service. The person asking the question will usually have no authority to give you permission to run a penetration test on the remote site, and the chances that you can secure permission from the remote site’s owner will also be remote. If this happens to you, are you stuck? Actually, the answer is no. There is plenty of reconnaissance you can perform on a third-party service without requesting special permission, as long as you have a solid attack proxy and a plan. Introducing the OWASP ZAP Attack Proxy One of the top free tools in application security and pentester toolboxes these days is the OWASP ZAP attack proxy. (“ZAP” stands for “Zed Attack Proxy.”) In pentest mode, this tool can map a site, attempt exploits and fuzz input, but using these capabilities against a third-party site without the owner’s permission can be an invitation for trouble. Fortunately, third-party site owners usually grant permission during trial and demo periods to try out their site and service using normal web browsers and mobile devices. The trick to good (and legal) reconnaissance is to only capture and analyze the traffic available in the trial period, and this happens to be another application at which OWASP ZAP excels. Setting Expectations and Getting Internal Permission Before you do anything technical, however, you should set expectations and get some cover from the person who requested the assessment. In the process of doing this, you will also lay out your plan, request access to a demo account, and explicitly tell the requester what you are not going to do (i.e., “hack” or run a “pentest”). After you do more of these evaluations you will surely develop your own template, but the following message will get you started: For your own protection, please do NOT begin your research until you get: A positive acknowledgment to your “Is this OK?” question in writing. A working demo account, which you have tested using a regular Web browser. Planning Your Reconnaissance If you don’t get to hack, what can you do? Actually, the list of items you can investigate from normal traffic is often long enough to make a judgment call on the security posture of the target service. In this article we’ll cover “just” nine, but you could certainly look at many more. Use of HTTPS to protect traffic Quality of SSL certificate Avoids client-side secrets or authentication Up-to-date software Secure site headers Proper location and protection of vital assets Avoids information leakage through “extra” fields Access controls on web APIs (sometimes) Evaluation of legal and privacy policy Preparing OWASP ZAP and Your Browser To use OWASP ZAP in a noninvasive, passthrough mode, you need to set ZAP up as a proxy. From ZAP’s main menu, select “Tools | Options”. In the “Local Proxy” section, set the address and port your browser will use (The defaults are an address of “localhost” and a port “8080”). In the “Dynamic SSL” section, click the “Generate” button to create a CA certificate to use to facilitate your HTTPS connections. Still in the “Dynamic SSL” section, click the “Save” button to save a copy of this CA certificate as a *.cer file (You will want to import this CA into your browser soon to avoid “untrusted SSL certificate” blocks). Pick the Web browser you want to use to examine the remote site. Since I use Chrome for my daily browsing, I usually use Firefox as my secondary browser for Web analysis. Open your selected Web browser and set up its proxy settings, located here in current versions of Firefox (“Options” dialog, “Network” tab, “Connection” section, “Settings” button): …IE (“Settings” icon, “Internet Options” option, “Connections” tab, “LAN Settings” button) …and Chrome (“Settings” dialog, “Slow advanced settings…” link, “Network” section, “Change proxy settings…” button, then see “IE” entry above because it uses the same “Internet Properties” dialog as IE). Once you have configured your proxy, you should also import the proxy’s SSL CA certificate so your browser will not warn you about a bad certificate (the proxy’s certificate) every time you contact an HTTPS server. In Firefox, the list of trusted CA certificates is available from the “Certificates” tab in the program options. In IE and Chrome, the list of trusted CA certificates is also available through each browser’s options, but is actually saved in the local Windows operating system, not the browser itself. To test all this, restart your selected browser, make sure OWASP ZAP is running, and contact an HTTPS-protected site like https://www.google.com. You may immediately see a certificate warning page like this: …because the certificate presented by the proxy does not match the target, but you should have an option to “Add Exception” or “Proceed” because you already added the proxy’s certificate to your list of trusted CAs (E.g., you get a yellow warning you can ignore instead of a red error that stops you from proceeding). To proceed, click the available link and inspect the provided certificate. If you performed your steps correctly you will “OWASP” all over it. Click the “Permanently store this exception” box and then click the “Confirm Security Exception” button (or similar controls) to dismiss the error and proceed with your connections. Bypassing the Proxy for Certain Sites As you perform research on various sites, you may also want to set up a list of sites that will not be queried through the proxy. These settings are usually near your browser’s other proxy settings. For example, in Firefox, they are immediately below the proxy host and port settings. Performing Your Reconnaissance Now that you have OWASP ZAP and your browser set up, let’s proceed with some reconnaissance. Our sample target today will be a web services company called EventMobi, which hosts a public demo at MFG 2015. (Remember, we’re being non-invasive, so public resources are best!) Use of HTTPS to protect traffic To get started, simply open up the public demo link in your browser. (Do NOT enter it into the inviting little “URL to attack” field in OWASP ZAP!) Since we’re going through a proxy that may tie things up, you may need to refresh your browser (or perform the “Resolving Missing Images” procedure below) a few times to get all the content you want, but in less than a minute you should see a valid web page in your browser: …and some folders will start to appear in ZAP under the “Sites” list. Notice that pages are already listed as coming from “http” or “https.” In the case of our sample site, it’s clear that all content is being served from http, and that we haven’t been pushed to https automatically. To research this further and see if https is an option if we want secure transport, we can go back to the browser and simply change the main URL from MFG 2015 to https://eventmobi.com/mfg2015/attendees/76204. In this case, the site doesn’t load (there is an eternally spinning “loading” circle), so we switch to a “normal” browser (not going through the proxy) to confirm the lack of HTTP support. Since the behavior is the same with our proxied and normal browsers, we reach an unfortunate conclusion: this site doesn’t use HTTPS by default, and won’t support HTTPS if we ask for it. Resolving Missing Images To resolve images and other resources that come from other sites, you may need to perform the following procedure, especially if they are being served from HTTPS resources. Right-click the non-resolving resource (such as an image) and right-click “Copy Image Location” (or similar). In a new tab, paste the URL from the previous step. Click through any certificate resolution or other site-specific errors until the specific resource resolves. Go back to the tab with the main application and refresh it to resolve all resources from the same site. Assessment of Sample Site For “use of HTTPS to protect traffic,” we conclude that this site is weak because it doesn’t use HTTPS by default, and won’t support HTTPS if we ask for it. Quality of SSL certificate While we’re on the subject of HTTPS, we should step out out of our proxied browser again and inspect the real X.509 certificate being offered up by our target site. We can usually do this by clicking the lock or certificate icon near our page URL. Here is what that looks like in Chrome (my daily, non-proxy browser). To get even more information, click “Certificate information.” There are generally three things you want to look for here. First, make sure that there is a fully trusted path to a legitimate CA. This certificate is in good shape. Next, check the “CN” on the certificate (usually in the “Subject” field). In this case, the certificate looks like a “wildcard” certificate because the CN is for the entire domain rather than a specific server. This is often a good sign, because wildcard certificates indicate that a company is large or stable enough to spend the extra money on a site-wide certificate. Finally, take a look through the other fields on the certificate. In this case, there is an interesting list of what appears to be customer-specific sites in the “Subject Alternative Field.” If you plan on using your own domain name through the provider, having this list broadcast to anyone who connected to the provider’s Web site might or might not make you nervous. Assessment of Sample Site For “quality of SSL certificate” we conclude that this site is OK because it uses a valid X.509 certificate, but could be better since the certificate seems to be leaking the URLs of some other customer sites. Avoids client-side secrets or authentication Now that we’re done with SSL and certificates, let’s look at the application itself. To see how it works, click throughout the application in your proxied browser. (In other words, try to go everywhere you can through links, buttons and forms.) Once you have a nice set of data, return to the ZAP console and open the tree that corresponds to our target site (in this case, “http://evenmobi.com“). Then drill down into a particular request and click the “Response” tab to see what the target site is telling us. What we are mostly looking for here is JavaScript or other client code that is performing authentication requests, especially passwords accidentally sent to the client. (To help detangle hard-to-read JavaScript, remember to use a JavaScript Beautifier.) Our target site has a lot of its resources in a “webapp/view/high/js” tree, so we can drill down there to look at individual files. Another place to look for potential exposure is the history of requests at the bottom of the ZAP console. In this case, ZAP has highlighted a “*.js” file that contains the word “password” and warrants further inspection. A complete analysis of client code, authentication routines and unsafe password handling is beyond this article (and could take more time than the rest of the steps combined), but suffice it to say that our target site passed its inspection. Assessment of Sample Site For “avoids client-side secrets or authentication” we conclude that this site is fine because it doesn’t do client-side authentication and keeps its passwords safe on the server. Up-to-date software Most Web sites depend on a variety of third-party libraries and applications, and many sites lag behind the most current and secure versions of these components. This problem is so widespread that OWASP continues to track it as #9 in its Top Ten Web Vulnerabilities. Fortunately ZAP can help us look for these in three ways. First, we can look at Web site headers for Web software version numbers. Unless it’s suppressed by the target server or intervening firewall, this information will be displayed in any content response from the site. In this case we see that the site is claiming to run version 1.1.19 of the nginx Web server. Checking the nginx release history, we see that that version was released in April 2012 – almost three years ago. We can also look up nginx security vulnerabilities to see that our target server may have a number of “medium” severity vulnerabilities (fortunately no “major” vulnerabilities), including: SSL session reuse vulnerability Request line parsing vulnerability Memory disclosure with specially crafted HTTP backend responses Vulnerabilities with Windows directory aliases Second, we can use ZAP to look for application environment versions. These may be displayed if we access “Web application” files like *.php, *.aspx, etc. (Hiding this information is a best practice, so it may not appear on all sites.) n this case we see that the remote site is running PHP version 5.3.10, and is also probably running Ubuntu with a Linux kernel version of 3.15. That suggests that the operating system was updated at least once in the past year (OK), but that the PHP environment has been deprecated (all support, including security support, terminated in mid-2014). Finally, we can also use ZAP to check standardized JavaScript libraries and other includes for vulnerable versions. These may be easy to find in the list of downloaded assets: …or may be buried in inline page includes (which requires looking through downloaded content). In this case, we can check at least three standard libraries for known vulnerabilities: socket.io (version 0.9.11) – current version is 1.3.3; this version appears safe jquery (version 1.7) – current version is 1.9; this version appears safe keen (version 2.1.0) – current version is 3.2.2; this version appears safe etc… Assessment of Sample Site For “up-to-date software” we conclude that this site is worrisome because it is running a pretty old version of its Web server software with several known vulnerabilities and an out-of-support version of PHP. (The application JavaScript components appear fine, but the Web server and PHP issues are enough to cause concern.) Secure site headers A sign that a service takes security seriously is the use of special Web site headers designed to prevent XSS and related exploits. Many of these headers are detailed on other sites, but some of the best ones to look for are: X-Frame-Options: SAMEORIGIN or X-Frame-Options: DENY X-Content-Type-Options: nosniff (Missing) X-Powered-By… Strict-Transport-Security Content-Security-Policy Using ZAP, these would show up in the Response section of most file requests. Unfortunately, none of the secure headers we would like to see are used by our target site, and as we saw above, the target site quite happily uses an “X-Powered-By” header to tell us about the underlying application (PHP) and OS (Ubuntu Linux) environment. Assessment of Sample Site Our target site does not use any “secure site headers,” and does not suppress headers that may provide helpful information to hackers. Proper location and protection of vital assets One of the many things ZAP does well is organize detected assets by site of origin. This makes it easy to see where a target site stores its assets and runs its application. In the case of our target site we can see resources come from newrelic.com, linkedin.com, amazonaws.com and google-analytics.com, among other places. For now we will ignore the tracking and advertising sites and zero in on resources pulled from Amazon’s S3 storage service. To see these, open up the related tree until you can drill down to an asset. Notice that the full URL of each asset is available in ZAP. To see whether or not an asset is accessible without any access control, copy its URL into an “incognito” browser window in a non-proxy browser. (ZAP provides a right-click “Copy URLs to Clipboard” option for this exact purpose.) If you can pull up the resource in a fresh, incognito browser session, there is generally no access protection and anyone with the URL to the resource can access it. In some cases this is OK, but if confidential information is ever accessible in this way you could have a leak on your hands. Assessment of Sample Site In terms of “proper location and protection of vital assets” there are a number of company-specific assets that are stored on publicly-accessible storage at Amazon. Since all the information we plan to store in this application is public anyway, this is OK, but we would need to see a different storage mechanism in place with enforced access controls if we planned to use the service with any confidential information. Avoids information leakage through “extra” fields It is common for Web applications, particularly Web services, to provide “extra” information with requests that client-side (usually JavaScript) code will filter out. However, all this information is easily accessible to interested parties, including you. To look for this type of information using ZAP, look for large page or Web service requests in your history, then dig into the fields provided. Remember to cut/paste data in JSON prettifiers and other tools if you need help visualizing it. For example, here is an abbreviated response from our sample site: { "response":{ "id":"76204", "name":"Attendees", "items":[ { "id":"1812359", "first_name":"James Avery", "about":"", "image50":"50mfg-m-01.jpg", "image100":"100mfg-m-01.jpg", "title":"Support Specialist", "company_name":"Metropolitan Financial Group", "website":"http://www.eventmobi.com", "facebook":"http://www.facebook.com/eventmobi.com", "twitter":"http://twitter.com/eventmobi", "linkedin":"http://www.linkedin.com/in/eventmobi", "url":"http://api.eventmobi.com/en/api/v1/events/MFG2015/sections/76204/items/1812359" }, { "id":"1812360", "first_name":"Joe Baker", "about":"", "image50":"50crop_547c946dd931f_128_(1).jpg", "image100":"100crop_547c946dd931f_128_(1).jpg", "title":"CEO", "company_name":"Metropolitan Financial Group", "website":"http://www.eventmobi.com", "facebook":"http://www.facebook.com/eventmobi.com", "twitter":"http://twitter.com/eventmobi", "linkedin":"http://www.linkedin.com/in/eventmobi", "url":"http://api.eventmobi.com/en/api/v1/events/MFG2015/sections/76204/items/1812360" }, This is a block of JSON that shows that the target site will happily dump a complete attendee list, including self-provided contact information. Assessment of Sample Site In terms of “Avoids information leakage through “extra” fields” the target site is OK. Although interesting fields such as “linkedin” are revealed, they must be added by individual users and are probably easy to find through other publicly available sources. Access controls on web APIs After you have identified a few key API service calls in ZAP, copy the URLs out and try them in your incognito Web browser to see if they are protected by any access controls. In the case of our sample site, there do not appear to be any access controls on the API. Assessment of Sample Site In terms of “access controls on Web APIs” there do not appear to be any access controls. This may be OK for public information, but if information such as lists of attendees is sensitive, then we may be concerned. Evaluation of legal and privacy policy Finally, you can put ZAP down for a minute and read some legalese. Go back to the target site using a non-proxy Web browser and find its legal terms, privacy or security policy. For our target site, a privacy policy can be found at http://www.eventmobi.com/legal/privacy-policy/ At a high level, you are looking for promises of privacy or security made in the legal policy that do not seem to be backed up with technical controls. As it turns out, our target’s privacy policy is weak, but accurately describes what they do or do not do. In a section about the type of information collected and its use, our target accurately lists what they collect and states that the information of participants is “publicly available online” (as we saw while looking at Web service access controls). In the “Security” section we see a statement about “suitable procedures” to protect information collected online. This is vague enough to encompass what we saw in our investigation (e.g., no encryption for public information), but without more inspection we have to take our target on its word. Finally, another “Security” section contains a vague promise of “security measures,” and then honestly puts the onus of not posting anything confidential on the users. Assessment of Sample Site Our “evaluation of legal and privacy policy” did not give us great confidence in the security of the site, but it agrees with our overall technical assessment. For that reason, it strikes us as an honest policy. Filing Your Report Now that you have completed your analysis, it’s time to provide a recommendation based on your limited information. Remember that your requester is primarily looking for a simple answer to this question: “Is this service safe enough for the job?” A typical results report might resemble the following template. For example, an evaluation of our sample target might yield the following report. Source

A pretty shocking thing came to light this evening – Lenovo is installing adware that uses a “man-in-the-middle” attack to break secure connections on affected laptops in order to access sensitive data and inject advertising. As if that wasn’t bad enough they installed a weak certificate into the system in a way that means affected users cannot trust any secure connections they make – TO ANY SITE. We trust our hardware manufacturers to build products that are secure. In this current climate of rising cybercrime, if you cant trust your hardware manufacturer you are in a very difficult position. That manufacturer has a huge role to play in keeping you safe – from releasing patches to update software when vulnerabilities are found to behaving in a responsible manor with the data the collect and the privileged access they have to your hardware. When bad guys are able to get into the supply chain and install malware it is devastating. Often users find themselves with equipment that is compromised and are unable to do anything about it. When malware is installed with the access a manufacturer has it buries itself deep inside the system often with a level of access that often takes it beyond the reach of antivirus or other countermeasures. This is why it is all the more disappointing – and shocking – to find a manufacturer doing this to its customers voluntarily. Lenovo has partnered with a company called Superfish to install advertising software on it’s customer’s laptops. Under normal circumstances this would not be cause for concern. However Superfish’s software has quite a reputation. It is a notorious piece of “adware”, malicious advertising software. A quick search on Google reveals numerous links for pages containing everything from software to remove Superfish to consumers complaining about the presence of this malicious advertising tool. Superfish Features: Hijacks legitimate connections. Monitors user activity. Collects personal information and uploads it to it’s servers Injects advertising in legitimate pages. Displays popups with advertising software Uses man-in-the-middle attack techniques to crack open secure connections. Presents users with its own fake certificate instead of the legitimate site’s certificate. This presents a security nightmare for affected consumers. Superfish replaces legitimate site certificates with its own in order to compromise the connections so it can install its adverts. This means that anyone affected by this adware cannot trust any secure connections they make. Users will not be notified if the legitimate site’s certificate has been tampered with, has expired or is bogus. In fact they now have to rely on Superfish to perform that check for them. Which it does not appear to do. Because Superfish uses the same certificate for every site it would be easy for another hostile actor to leverage this and further compromise the user’s connections. Superfish uses a deprecated SHA1 certificate. SHA1 has been replaced by SHA-256 because attacks against SHA1 are now feasible with ordinary computing hardware. This is insult on top of injury. Not only are they compromising peoples SSL connections but they are doing it in the most cavalier, insecure way possible. Even worse, they use crackable 1024-bit RSA! The user has to trust that this software which has compromised their secure connections is not tampering with the content, or stealing sensitive data such as usernames and passwords. If this software or any of its control infrastructure is compromised, an attacker would have complete and unrestricted access to affected customers banking sites, personal data and private messages. Below is a photo showing Superfish on an affected laptop presenting a fake certificate instead of the legitimate “Bank of America” certificate. As you can see the user is presented with the fake Superfish certificate instead of the legitimate BoA certificate. The only way a user would know this has happened is if they check the certificate’s details. Something most ordinary users are unlikely to do to a certificate which to all other appearances is valid and secure. As mentioned above the certificate used by Superfish is a deprecated SHA1 certificate that uses 1024-bit RSA. This is particularly obnoxious because they have installed into the system certificates as an unrestricted trusted root certificate. To put it into context they gave it the same level of trust and authority as Microsoft’s own root certificate. Users affected by this can go to any site on the internet, and so long as it presents this certificate they will be fooled into thinking they have a secure connection. Since this certificate uses SHA1 it is feasible that an attacker could break it and hijack it. This means an attacker could create a bogus certificate that every one of these users would trust. This is unbelievably ignorant and reckless of them. Its quite possibly the single worst thing I have seen a manufacturer do to its customer base. At this point I would consider every single one of these affected laptops to be potentially compromised and would reinstall them from scratch. Lenvo’s response? Typical of companies caught with their hand in the cookie jar, they try to play it down while at the same time saying they have disabled it until it can be “fixed”: https://forums.lenovo.com/t5/Lenovo-P-Y-and-Z-series/Lenovo-Pre-instaling-adware-spam-Superfish-powerd-by/m-p/1863174#M79882 However its hard to see how they could “fix” this software. It’s core functionality undermines the security of SSL rendering the last decade or so of work making the web secure completely irrelevant. Source