FBI Won't Tell Me How Much It Paid To Break Into Syed Farook's iPhone, Saying It Might Jeopardize Its Investigation

from the say-what-now? dept

As you probably recall, several months ago, after going to court to try to force Apple to write some software to allow the FBI to hack into Syed Farook's work iPhone, the DOJ and FBI abruptly called off the case, claiming that it had been able to get an exploit that let it into the phone. A few weeks later, FBI Director James Comey suggested that the government paid over $1.2 million to get that exploit from some "hackers." Some later news reports indicated that the FBI quietly tried to talk down those numbers, and suggested that perhaps Comey was just bad at math (rather than name a number, he said that the FBI had paid "more than I will make in the remainder of this job, which is seven years and four months....").

Either way, I sent a FOIA request into the FBI that day asking for either the invoice or any other documentation showing how much the FBI had paid to get into Farook's work iPhone. The FBI has now rejected my FOIA request, arguing that since this is an "ongoing investigation," responding to such a request might somehow "interfere" with the case. This is complete hogwash, for a variety of reasons. First, Farook is dead. Second, what investigation is there left to do? We know that Farook and his wife shot up Farook's office party and killed a bunch of people. We also know that the FBI was so unconcerned about further investigation that it allowed reporters to ransack Farook's townhouse soon after the shooting. Third, how the hell would revealing the price impact the investigation? The answer is that it will not. There is nothing in saying "it cost us $1 million" or "it cost us $653,000" or whatever, that in any way interferes with whatever investigation remains to be done.

This is nothing more than the FBI doing what the FBI frequently does with FOIA requests. Denying them because the FBI doesn't want to answer.

Filed Under: exploit, fbi, foia, iphone, james comey, syed farook, vulnerability

Security Analyst Arrested For Disclosing Security Flaw In Florida County's Election Systems

from the life-lessons dept

A Florida man has been charged with felony criminal hacking charges after disclosing vulnerabilities in the voting systems used in Lee County, Florida. Security analyst David Levin was arrested 3 months after reporting un-patched SQL injection vulnerabilities in the county's election systems. Levin was charged with three counts of unauthorized access to a computer, network, or electronic device and released on $15,000 bond. Levin's first and biggest mistake was to post a video of himself on YouTube logging into the Lee County Elections Office network using the credentials of Sharon Harrington, the Lee County Supervisor of Elections.

That gave prosecutors the ammo they needed to arrest Levin, even if he believed he was doing locals a favor:

"Based on the evidence obtained regarding the SQL injections attack Levin performed against the Lee County Office of Elections on December 19, 2015, probable cause does exist to charge Levin with unauthorized access of any computer, computer system, computer network, or electronic device, a violation of Florida Statute 815.06(2)(a), a third degree felony."

But at least a portion of Levin's crime may be of the political variety. In the video posted to YouTube Levin detailed the SQL injection alongside a man by the name of Dan Sinclair, who just so happens to be running against Harrington for the Elections Supervisor position. In the video, Levin details the relatively simple method of using a SQL injection attack to obtain login names and plain-text passwords belonging to Harrington and at least 10 other account holders:Sinclair has been telling local news outlets that the arrest is politically motivated and the result of "political corruption." Officials at the Lee County Elections office claim however that elections data was never actually at risk:

"The server that was vulnerable to Levin's SQL injection attack, they said, had been retired in October. At the time of Levin's attack, at least two months later, it no longer stored sensitive data and had been replaced by a new server that wasn't vulnerable to the attack, they said. Similarly, the CMS Levin logged into had also been retired and replaced with one that ran WordPress. While the older CMS was allowed to continue running during a transition period, its functionality was limited to storing only historical data, the officials said. People logging into it didn't have the ability to post new pages to the site or to access voter data or tabulation systems, they said."

Granted it's not clear if the data, usernames and passwords used in the attack were also potentially useful in compromising any of the county's other systems, and Levin's currently too busy in the court system to offer additional insight.

At the end of the day there's plenty of fault and lessons to go around. The county obviously shouldn't keep systems with easily-exploitable vulnerabilities online, as such lower-level systems could open the door for attacks on higher-level operations. Levin meanwhile could have taken any number of steps to reveal the flaws without risking prosecution, and step one to not getting arrested for computer crimes usually involves you avoiding posting videos of you breaking the law on YouTube. Following Dan Kaminsky's guide on how to disclose vulnerabilities without getting arrested is a good starting point for anybody that may someday find themselves in Levin's shoes.

Filed Under: cybersecurity, dan sinclair, david levin, disclosure, florida, lee county, voting, vulnerability

DOJ Says That The Crack Of Syed Farook's iPhone Only Applies To That Model Of iPhone

from the that's-not-how-tech-works dept

Update: We've now added to the story that the DOJ is saying that CNN got the quote wrong, and the vulnerability applies to any iPhone 5C, which is more believable, but still raises questions. Original story, with a note appended is below.

So late yesterday the Justice Department told magistrate judge Sheri Pym that it had successfully broken into Syed Farook's work iPhone and therefore no longer needed to continue with the court's order compelling Apple to write a new version of its iOS with security features removed. And then, in talking to the press, the DOJ apparently claimed the method only works for Farook's iPhone:

On Monday, the Department of Justice said the method only works on this particular phone, which is an iPhone 5C running a version of iOS 9 software.

Perhaps the CNN reporter who wrote this really meant "this particular type of phone," in which case the statement would be only marginally more believable, but the idea that it only applies to "this particular phone" makes absolutely no sense, and suggests the DOJ is flat out lying again. The only way in that works with just this phone would be magically finding Farook's passcode (perhaps he left a post-it somewhere?). But if that was the case, the DOJ wouldn't have asked for two weeks to "test" the method (even if they only took one week). Finding the passcode and testing it doesn't take that long. Update: A DOJ spokesperson says that CNN got the quote wrong and that the actual statement was that the crack only applied to iPhone 5C devices.

And if it's any other method, it must have wider applicability to other iPhones. It's possible, if unlikely, that the method in question only works on iPhone 5Cs running iOS 9, but if it's a true vulnerability, it's likely that it impacts much more. It is true that later versions of the hardware include a chip called the Secure Enclave that might get in the way of certain vulnerabilities, but claiming that any such crack is limited to a specific phone is ludicrous.

And, of course, as we mentioned in the original post, if the DOJ really did find a vulnerability and refuses to share it with Apple, then the Justice Department is making us all less safe by refusing to reveal a potential security flaw that may impact tons of people. And then it's also lying about it publicly. Not a good look, but an all too typical one, unfortunately.

Filed Under: crack, doj, fbi, iphone, syed farook, vulnerability
Companies: apple

DOJ To Court: Hey, Can We Postpone Tomorrow's Hearing? We Want To See If We Can Use This New Hole To Hack In

from the oh-really-now? dept

So, this morning we wrote about a new flaw found in the encryption in Apple's iMessage system -- though it was noted that this wouldn't really have impacted what the FBI was trying to do to get into Syed Farook's work iPhone. However, just a little while ago, the Justice Department asked the court to delay the big hearing planned for tomorrow afternoon, because of this newly disclosed vulnerability:

Since the attacks in San Bernardino on December 2, 2015, the Federal Bureau of Investigation (“FBI”) has continued to pursue all avenues available to discover all relevant evidence related to the attacks.

Specifically, since recovering Farook’s iPhone on December 3, 2015, the FBI has continued to research methods to gain access to the data stored on it. The FBI did not cease its efforts after this litigation began. As the FBI continued to conduct its own research, and as a result of the worldwide publicity and attention on this case, others outside the U.S. government have continued to contact the U.S. government offering avenues of possible research.

On Sunday, March 20, 2016, an outside party demonstrated to the FBI a possible method for unlocking Farook’s iPhone. Testing is required to determine whether it is a viable method that will not compromise data on Farook’s iPhone. If the method is viable, it should eliminate the need for the assistance from Apple Inc. (“Apple”) set forth in the All Writs Act Order in this case.

Accordingly, to provide time for testing the method, the government hereby requests that the hearing set for March 22, 2016 be vacated. The government proposes filing a status report with the Court by April 5, 2016.

This could mean a variety of different things... including that the DOJ is looking for a way "out" of this case without setting the precedent it doesn't want, after discovering that the case and public opinion didn't seem to be going the way the DOJ had hoped it was going to go when it first brought it last month. Either way, there's never a dull moment in this case...

Update: And the judge has accepted the request, meaning the hearing is off. The DOJ put out a statement trying to spin this as being about how they're just really interested in getting into this one phone and not about setting a precedent:

Our top priority has always been gaining access into the phone used by the terrorist in San Bernardino. With this goal in mind, the FBI has continued in its efforts to gain access to the phone without Apple's assistance, even during a month-long period of litigation with the company. As a result of these efforts, an outside party demonstrated to the FBI this past weekend a possible method for unlocking the phone. We must first test this method to ensure that it doesn't destroy the data on the phone, but we remain cautiously optimistic. That is why we asked the court to give us some time to explore this option. If this solution works, it will allow us to search the phone and continue our investigation into the terrorist attack that killed 14 people and wounded 22 people.

Of course, that statement is more misleading bullshit from the DOJ. It's pretty clear that the DOJ is just trying to get out of this case as it's realized that the original plan completely backfired, and they were likely to lose.

Update 2: Okay, the court has officially posted its decision to grant the DOJ's request. You can see it below as well.

Filed Under: all writs act, court, doj, encryption, fbi, going dark, hacking, syed farook, vulnerability
Companies: apple

Child-Monitoring Company Responds To Notification Of Security Breach By Publicly Disparaging Researcher Who Reported It

from the got-a-full-clip-of-'thank-yous'-with-your-name-on-it dept

"Thanks for letting us know about this! We'll get it fixed immediately!" said almost no company ever.

There's a long, but definitely not proud, tradition of companies shooting the messenger when informed of security flaws or possible breaches. The tradition continues.

uKnowKids is monitoring software parents can install on their children's cell phones that allows them to track their child's location, as well as social media activity, text messages and created media. As such, it collects quite a bit of info.

The information on your child collected includes:

• the online profile/screen names, mobile telephone numbers and email addresses associated with the Linked Accounts and the people communicating with the Linked Accounts and devices and in certain situations, the text of the online or mobile phone SMS or MMS conversations themselves;
• the geographic location and time and date associated with a specific geographic location of your Linked Account mobile device;
• your Linked Accounts’ social networking activity and contacts;
• photographs sent, received or uploaded by your Linked Account;
• the websites visited from your Linked Account mobile device; and
• the applications installed on your Linked Account mobile device.

That's a lot of data, all related to children. This should be kept locked up tight. Unfortunately, it wasn't.

Chris Vickery, who now blogs about security over on MacKeeper, alerted this site that a misconfigured MongoDB installation exposed over 6.8 million private child text messages, 1.8 million images (many depicting children, according to Chris), and over 1700 in-depth child profiles.

The data reportedly included full names, email addresses, GPS coordinates, dates of birth, and much more, although Chris tells DataBreaches.net that he did not see payment info or parent details exposed.

Vickery did the right thing and notified uKnowKids. The security hole was closed. But the company wasn't interested in thanking Vickery for his efforts. Instead, as the Office of Inadequate Security notes, the company decided to notify its customers in a rather unusual fashion. A post at the company's site completely misconstrues the chain of events.

Here's the BS headline.


And here's the BS text:

It is with significant personal regret that I share with you the news that uKnow had a private database repeatedly breached by a hacker using two different IP addresses on February 16, 2016 and February 17, 2016.

The hacker claims to be a "white-hat" hacker a "security researcher" or "white hat hacker" or "ethical hacker" which means he tries to obtain unauthorized access into private systems for the benefit of the "public good". Although we do not approve of his methods because it unnecessarily puts customer data and intellectual property at risk, we appreciate his proactive, quick notification as it was helpful to our team.

The passive aggression continues later in the post.

The first IP address that obtained unauthorized access to uKnow's private database was 65.36.124.81. We believe this IP address is associated with Mr. Christopher Vickery in Austin, Texas, but we don't have confirmation of that fact yet.

Mr. Vickery claims to work at a prominent law firm by day and exploit vulnerable technology systems at night. We do not have any additional background information on Mr. Vickery, but we are doing our best to fully identify Mr. Vickery in order to validate his stated "benign" intentions.

The second IP address (209.144.254.123) that accesed uKnow's private database in an unauthorized manner is reportedly associated with Mr. Vickery's full-time employer in Austin, Texas. Again, we don't yet have confirmation on who owns this IP address or the IP address owner's official connection with Mr. Vickery, but this is the early information we have been able to determine so far.

The post goes on to insinuate that Vickery has some sort of malignant interest in holding onto uKnow's code.

The database also included uKnow's proprietary natural language processing engine technology and data including our proprietary algorithms that power uKnow's technology.

We have repeatedly requested that Mr. Vickery permanently delete any and all copies of uKnow's intellectual property including iits proprietary customer data, business data, database schemas and field names, trade secrets, curated data dictionaries and algorithms.

After initial resistance, Mr. Vickery claims to have deleted the downloaded database in its entirety. However, he has reportedly retained an uknown number of screenshot copies of uKnow's intellectual property, and is so far unwilling to permanently delete this information. In an effort to protect our customers and stakeholders, we contine to request the destruction of any and all copies of uKnow's database including screenshots which are, in fact, copies of uKnow's database.

It also suggests Vickery's possession of screenshots might somehow violate COPPA (a law ensuring the privacy of data generated by children) and has apparently reported him to the FTC.

We have contacted the Federal Trade Commission for guidance and to report the breach. uKnow goes to great effort and expense to fully comply with the FTC's COPPA regulations, and we beleive we are in full compliance at this time.

uKnow's demand for Mr. Vickery to delete ALL copies of uKnow's database was obviously driven by our desire to protect our uKnowKids customers, but also to fully comply with COPPA requirements that we do not knowingly allow any third parties access to child data without first having affirmative, verifiable permission from parents. Mr. Vickery obviously did not and does not have authorization to explore, copy, or control this private child data (or uKnow's intellectual property), and we expect him to comply with our requests immediately.

Nowhere in this long statement questioning Vickery's intent is there an apology for the breach. There are no unqualified statements of gratitude. Vickery's history of finding misconfigured databases is well-documented, as is his standard operating procedure of notifying affected companies immediately and destroying any data he obtained while investigating these leaky databases.

Instead of simply fixing the hole and informing affected customers, uKnow decided to publicly disparage the person who alerted it of the issue. It's responses like these -- along with continual abuse of computer security laws -- that make security researchers leery of informing affected parties. Informing someone of a security hole shouldn't be greeted with antagonism and legal threats. But that's the default operating mode, one that only ensures security holes discovered in the future are less likely to be reported.

Filed Under: chris vickery, disclosure, ethical hacking, security research, shoot the messenger, vulnerability, white hat hacking
Companies: uknowkids

Leading DarkNet Market Agora Temporarily Suspends Service Over Tor Vulnerability Concerns

from the here-come-the-fuzz dept

As the government continues to play Whac-a-Mole with darknet drug bazaars, one of the Silk Road's leading darknet market replacements says it has temporarily suspended service over Tor vulnerability concerns. In an encrypted post to the site's buyers and dealers (copied over to PasteBin and over at the /r/darknetmarkets subReddit), Agora's administrators say the darknet market is nervous about law enforcement's ability to take advantage of recent Tor vulnerabilities, and as such are pulling the market offline for an undisclosed amount of time to protect the site:

"Recently research had come that shed some light on vulnerabilities in Tor Hidden Services protocol which could help to deanonymize server locations. Most of the new and previously known methods do require substantial resources to be executed, but the new research shows that the amount of resources could be much lower than expected, and in our case we do believe we have interested parties who possess such resources. We have a solution in the works which will require big changes into our software stack which we believe will mitigate such problems, but unfortunately it will take time to implement."

While the post doesn't specify which Tor vulnerability the market's responding to, a paper recently published by researchers from Qatar University and MIT (pdf) argued that it was possible to use a Tor vulnerability to identify Tor hidden services with as much as 88% accuracy. Tor director Roger Dingledine responded to these findings in a blog post back in July. Dingledine downplayed the ability of the vulnerability to be exploited in the wild, while pointing out that researchers have long over-estimated the ease of such fingerprinting methods in the real world.

To succeed in the fingerprinting process, the attacker needs to control the Tor entry point for the server hosting the hidden service, and have previously collected unique network identifiers allowing for the fingerprinting for that particular service. Still, Agora itself strongly hints that they've seen some (presumably law enforcement) behavior in the wild already attempting to take advantage of the vulnerability, and wasn't willing to take the risk:

"...We have recently been discovering suspicious activity around our servers which led us to believe that some of the attacks described in the research could be going on and we decided to move servers once again, however this is only a temporary solution. At this point, while we don't have a solution ready it would be unsafe to keep our users using the service, since they would be in jeopardy. Thus, and to our great sadness we have to take the market offline for a while, until we can develop a better solution. This is the best course of action for everyone involved."

Agora's decision to forgo possible revenue for the sake of OPSEC (operational security) resulted in some Reddit posters praising Agora for its "iron testicles". The outfit does appear to be slowly paying funds back to dealers and users (funds for DarkNet markets are usually held in escrow until deals are completed), but payments appear to be taking 24 to 48 hours for Agora to process. Meanwhile, admins for other darknet markets, like Middle Earth, have subsequently proclaimed that they have already covered their bases and aren't worried about the vulnerability:

"We noticed the strange happenings early on. We KNOW that TOR devs are the best of the best. This is only theoretical paper from MIT students. TOR updates daily on a development level, they would fix any vulnerabilities from any theoretical paper. Emphasis: Theoretical Paper, Not Successful Tests. We have covered all bases."

While the Agora shutdown combined with dropping Bitcoin value (due to the potential forking of currency development by those concerned about scalability) have Bitcoin advocates and Darknet market users sweating a bit, Agora's shutdown would seem to be only a temporarily bump in the road to future darknet opsec skirmishes. Agora already had survived last November's Operation Onymous, which took down Silk Road 2 and 400 other websites. It's still debated whether those seizures were thanks to a Tor vulnerability or old-fashioned detective work (law enforcement obviously isn't keen on being illuminating).

Even if Agora doesn't return, there's a half-dozen or more already established Darknet markets happy to fill the void and satiate the globe's inexhaustible supply of drug buyers and dealers, those entertained by the endless game of opsec cat and mouse, and the government's insatiable need to fill its mole-whacking quota.

Filed Under: bitcoin, dark market, security, suspension, tor, vulnerability
Companies: agora

Encryption Backdoors Will Always Turn Around And Bite You In The Ass

from the golden-keys dept

As you may have heard, the law enforcement and intelligence communities have been pushing strongly for backdoors in encryption. They talk about ridiculous things like "golden keys," pretending that it's somehow possible to create something that only the good guys can use. Many in the security community have been pointing out that this is flat-out impossible. The second you introduce a backdoor, there is no way to say that only "the good guys" can use it.

As if to prove that, an old "golden key" from the 90s came back to bite a whole bunch of the internet this week... including the NSA. Some researchers discovered a problem which is being called FREAK for "Factoring RSA Export Keys." The background story is fairly involved and complex, but here's a short version (that leaves out a lot of details): back during the first "cryptowars" when Netscape was creating SSL (mainly to protect the early e-commerce market), the US still considered exporting strong crypto to be a crime. To deal with this, RSA offered "export grade encryption" that was deliberately weak (very, very weak) that could be used abroad. As security researcher Matthew Green explains, in order to deal with the fact that SSL-enabled websites had to deal with both strong crypto and weak "export grade" crypto, -- the "golden key" -- there was a system that would try to determine which type of encryption to use on each connection. If you were in the US, it should go to strong encryption. Outside the US? Downgrade to "export grade."

In theory, this became obsolete at the end of the first cryptowars when the US government backed down for the most part, and stronger crypto spread around the world. But, as Green notes, the system that did that old "negotiation" as to which crypto to use, known as "EXPORT ciphersuites" stuck around. Like zombies. We'll skip over a bunch of details to get to the point: the newly discovered hack involves abusing this fact to force many, many clients to accept "export grade" encryption, even if they didn't ask for it. And it appears that more than a third of websites out there (many coming from Akamai's content delivery network -- which many large organizations use) are vulnerable.

And that includes the NSA's own website. Seriously. Now, hacking the NSA's website isn't the same as hacking the NSA itself, but it still seems notable just for the irony of it all (obligatory xkcd): But the lesson of the story: backdoors, golden keys, magic surveillance leprechauns, whatever you want to call it create vulnerabilities that will be exploited and not just by the good guys. As Green summarizes:

There’s a much more important moral to this story.

The export-grade RSA ciphers are the remains of a 1980s-vintage effort to weaken cryptography so that intelligence agencies would be able to monitor. This was done badly. So badly, that while the policies were ultimately scrapped, they’re still hurting us today.

This might be academic if it was just a history lesson — but for the past several months, U.S. and European politicians have been publicly mooting the notion of a new set of cryptographic backdoors in systems we use today. This would involve deliberately weakening technology so that governments can intercept and read our conversations. While officials are carefully avoiding the term “back door” — or any suggestion of weakening our encryption systems — this is wishful thinking. Our systems are already so complex that even normal issues stress them to the breaking point. There's no room for new backdoors.

To be blunt about it, the moral of this story is pretty simple:

Encryption backdoors will always turn around and bite you in the ass. They are never worth it.

Let's repeat that last line, because it still seems that the powers that be don't get it:

Encryption backdoors will always turn around and bite you in the ass. They are never worth it.

Whether it's creating vulnerabilities that come back to undermine security on the internet decades later, or merely giving cover to foreign nations to undermine strong encryption, backdoors are a terrible idea which should be relegated to the dustbin of history.

Filed Under: backdoors, encryption, export encryption, export keys, freak, nsa, openssl, ssl, tls, vulnerability

A Bit Late, But Lenovo CTO Admits The Company Screwed Up

from the finally dept

We've had a bunch of posts today (and yesterday) about the "Superfish" debacle, with a few of them focusing on Lenovo failing to recognize what a problem it was -- first denying any serious security problem, and then calling it "theoretical." It appears that Lenovo has now realized it totally screwed up and is finally saying so. Speaking to Re/code, CTO Peter Hortensius has changed his tune from the "theoretical" problem he discussed earlier:

“We messed up,” CTO Peter Hortensius told Re/code. The company now confirms that the way Superfish operates could leave machines vulnerable to a “man-in-the-middle,” or MITM, attack, in which an attacker mimics both sides of a conversation to actively eavesdrop on each one.

[....]

The company has an engineering review that made sure the tool itself didn’t store customer information and had a mechanism for users to opt out, but Lenovo missed that the way the software behaved could create a situation that left machines vulnerable to an attack.

“We should have known going in that that was the case,” Hortensius said. “We just flat-out missed it on this one, and did not appreciate the problem it was going to create.”

He later admits that the company "deserves" to take a beating for missing that. The company has also promised to publicly announce a plan for how it will make sure this sort of thing doesn't happen again.

While we called the company out for its initial terrible reaction, at least the company now seems to recognize the problems it caused and is owning up to it. It should have happened faster, but at least it's happening. Hopefully, the company is better off for it.

Of course, the same can't be said for Superfish, who insisted yesterday that Lenovo would show that there was no security risk at all, and still seems to be standing by that ridiculously wrong statement.

Filed Under: adware, malware, peter hortensius, superfish, vulnerability
Companies: komodia, lenovo, superfish

Superfish Keeps Digging Deeper And Deeper Hole: Still Refuses To Acknowledge Seriousness Of What Its Software Did

from the first-rule-of-holes dept

I pointed out earlier that it was fairly astounding that Superfish was basically remaining mostly quiet on the whole controversy over its software. If you've been under a rock, earlier this week, the security community pointed out how Superfish's software (installed by default on certain Lenovo laptops) created a massive security vulnerability. Superfish itself is adware, but that's the least of the problems. The software doesn't track your behavior like other adware, but instead tries to insert other buying options when you're viewing images of certain products. It tries to find the same or similar products that you can buy for less and tell you about them. I could see how that might be interesting for some people on some shopping sites if they chose to use the software. But, by being a default bloatware install on Lenovo laptops, there was no choice. Furthermore, it apparently was trying to do this on every website. And that's where the real problem came in.

Because many websites these days are encrypted via HTTPS (to better protect privacy), Superfish teamed up with a sneaky company named Komodia, to install a really nasty and poorly implemented "trick." It installed its own, self-signed root certificate, and would then effectively offer up fake security certificates for ANY and EVERY HTTPS connection. And, of course, it used the same key on every install, and that key was easily cracked (password: komodia), meaning that anyone who had this installed, was basically open to a massive and hugely dangerous man-in-the-middle attack on any HTTPS connection. That's HUGE.

And Superfish still won't cop to it. Its website has nothing about this whole thing. Its Facebook page has nothing. Its Twitter feed only has that post from yesterday saying that Lenovo would soon be putting out a statement clarifying things -- but Lenovo's statement (which has changed over time) admits that there were problems and the company is working hard to remove all the damage that Superfish has done. And Superfish still doesn't get it. Its latest press statement shows that the company is in total denial about what kind of mess it helped create. It is still defending the whole "adware" thing, rather than the security hole. And, its only comment on the security hole is "some other company did that."

Superfish Statement from CEO

There has been significant misinformation circulating about Superfish software that was pre-installed on certain Lenovo laptops. The software shipped on a limited number of computers in 2014 in an effort to enhance the online shopping experience for Lenovo customers. Superfish's software utilizes visual search technology to help users achieve more relevant search results based on images of products they have browsed.

This is not the time for your marketing speak. This is the time you apologize for putting many, many, many people at serious risk. Stop with the PR-sanitized "enhance their shopping experience."

Despite the false and misleading statements made by some media commentators and bloggers, the Superfish software does not present a security risk. In no way does Superfish store personal data or share such data with anyone. Unfortunately, in this situation a vulnerability was introduced unintentionally by a 3rd party. Both Lenovo and Superfish did extensive testing of the solution but this issue wasn't identified before some laptops shipped. Fortunately, our partnership with Lenovo was limited in scale. We were able to address the issue quickly. The software was disabled on the server side (i.e., Superfish's search engine) in January 2015.

This statement is almost entirely pure bullshit. No one has complained about Superfish storing personal data, but it absolutely does present a security risk. A massive one. A incredibly humungous, cannot be overstated, sized-security risk. And Superfish says it "does not present a security risk"? Bullshit. And then to say "a vulnerability was introduced unintentionally by a 3rd party." That's passing the buck. Yes, it's Komodia (which Superfish doesn't name) who appears to have done this, but it's Superfish who decided to use Komodia's braindead stupid method of breaking HTTPS. Yes, you tested it, but your tests suck if you didn't spot this kind of security mess.

Finally, disabling the software isn't even the main part of the issue, since the dangerous root certificate still remained after that. And, yes, actions are now being taken to fix that, but no thanks to Supefish and its refusal to admit what happened.

Superfish takes great pride in the quality of its software, the transparency of its business practices, and its strong relationship with the Superfish user community. Superfish's visual search technology enables millions of people to explore and learn about the world in an engaging and highly intuitive manner. A positive user experience has been the cornerstone of Superfish's success.

Again, bullshit. If you took great pride in the quality of your software, you'd stop this marketing-speak and admit that you seriously screwed up and put many people at risk. Anyone with a modicum of understanding of how HTTPS and certificate systems work would recognize quickly what a dangerous situation this was, but neither Superfish nor Lenovo did. At least Lenovo now seems to be trying to make things right, while Superfish remains in total denial, hoping that a combination of mostly silence and bullshit "statements from the CEO" written by marketing are the way to solve this mess.

This is not how you solve a mess up of this size. You need to own it. You need to come clean and admit that you messed up, how you messed up, why you messed up and what you're going to do to make sure it never, ever happens again. Superfish didn't do that, and at this point it's probably too late to try to turn that around.

Filed Under: superfish, vulnerability
Companies: komodia, lenovo, superfish

Lenovo Quietly Deletes That Bit About 'No Security Concerns' To Superfish... While Superfish Says 'No Consumers Vulnerable'

from the own-it dept

Wednesday night, the security world blew up with the news (which had actually been out there for a while), that the adware/malware Superfish that Lenovo had been installing by default on many laptops included a massive and dangerous security vulnerability by installing its own, self-signed root HTTPS certificate, and then basically mounting a man in the middle attack on every single HTTPS connection -- and doing so with an easily hacked certificate, creating a giant vulnerability for anyone owning one of those laptops. We were shocked at the tone-deafness of Lenovo's initial response, which didn't even name which laptops Superfish was installed on, and made this blatantly bullshit statement:

We have thoroughly investigated this technology and do not find any evidence to substantiate security concerns.

However, within hours, Lenovo had quietly updated its statement to remove that line. The company is now also (finally) admitting which laptops were infected and put together a page about how to remove the software and the rogue certificate. That's better, but Lenovo should at least apologize, which it has not done, and admit that it was completely full of shit in insisting that there was no security concern.

Speaking of which, Superfish has remained remarkably quiet as well. At the time I write this, there is nothing about this on its website, and it's only given a ridiculously misleading statement to reporters:

Superfish has not been active on Lenovo laptops since December. We standby this Lenovo statement: http://news.lenovo.com/article_display.cfm?article_id=1929.

It is important to note: Superfish is completely transparent in what our software does and at no time were consumers vulnerable—we stand by this today. Lenovo will be releasing a statement later today with all of the specifics that clarify that there has been no wrongdoing on our end.

First of all, at the time it "stood by" the Lenovo statement, that statement was blatantly false in claiming that there were no security concerns. Similarly, it's simply not at all true that Superfish is "completely transparent" because no one knew that it was inserting its own self-signed certificate and using it on every HTTPS connection. Furthermore, consumers absolutely were vulnerable.

Finally, there's Komodia. As Robert Graham discovered when he hacked the Superfish certificate, the password is "komodia" which just happens to be a company that sells a product for... creating these kinds of man in the middle attacks on HTTPS connections, mainly for parental spyware. The company is also entirely silent on this stuff. Its website looks like it hasn't been updated recently. It has various blogs and a Facebook page, none of which appear to have been updated since 2013.

However, as security researchers are discovering, Komodia's tool is being used in other crappy spyware/malware and always in the same terrible manner -- all using the password "komodia." As Marc Rogers notes:

What does this mean? Well, this means that those dodgy certificates aren’t limited to Lenovo laptops sold over a specific date range. It means that anyone who has come into contact with a Komodia product, or who has had some sort of Parental Control software installed on their computer should probably check to see if they are affected.

This problem is MUCH bigger than we thought it was.

The software known to use Komodia are Komidia's own "Keep My Family Secure," Qustodio's parental control software and the Kurupira Webfiler -- all of which likely are very vulnerable thanks to this idiotic implementation.

Lenovo, Superfish and Komodia all have done a piss poor job taking responsibility for the massive security vulnerability they created.

Filed Under: privacy, security, superfish, vulnerability
Companies: komodia, lenovo, superfish