Schneier on Security

Friday Squid Blogging: Jurassic Squid Attack

It's the oldest squid attack on record:

An ancient squid-like creature with 10 arms covered in hooks had just crushed the skull of its prey in a vicious attack when disaster struck, killing both predator and prey, according to a Jurassic period fossil of the duo found on the southern coast of England.

This 200 million-year-old fossil was originally discovered in the 19th century, but a new analysis reveals that it's the oldest known example of a coleoid, or a class of cephalopods that includes octopuses, squid and cuttlefish, attacking prey.

More news.

As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.

Read my blog posting guidelines here.

Tags: squid

Posted on May 8, 2020 at 4:17 PM • 59 Comments

Used Tesla Components Contain Personal Information

Used Tesla components, sold on eBay, still contain personal information, even after a factory reset.

This is a decades-old problem. It's a problem with used hard drives. It's a problem with used photocopiers and printers. It will be a problem with IoT devices. It'll be a problem with everything, until we decide that data deletion is a priority.

Tags: cars, data loss, data retention, hardware, identification, Internet of Things, leaks

Posted on May 8, 2020 at 9:46 AM • 11 Comments

iOS XML Bug

This is a good explanation of an iOS bug that allowed someone to break out of the application sandbox. A summary:

What a crazy bug, and Siguza's explanation is very cogent. Basically, it comes down to this:

• XML is terrible.
• iOS uses XML for Plists, and Plists are used everywhere in iOS (and MacOS).
• iOS's sandboxing system depends upon three different XML parsers, which interpret slightly invalid XML input in slightly different ways.

So Siguza's exploit ­-- which granted an app full access to the entire file system, and more ­- uses malformed XML comments constructed in a way that one of iOS's XML parsers sees its declaration of entitlements one way, and another XML parser sees it another way. The XML parser used to check whether an application should be allowed to launch doesn't see the fishy entitlements because it thinks they're inside a comment. The XML parser used to determine whether an already running application has permission to do things that require entitlements sees the fishy entitlements and grants permission.

This is fixed in the new iOS release, 13.5 beta 3.

Comment:

Implementing 4 different parsers is just asking for trouble, and the "fix" is of the crappiest sort, bolting on more crap to check they're doing the right thing in this single case. None of this is encouraging.

More commentary. Hacker News thread.

Tags: cybersecurity, iOS, malware, vulnerabilities

Posted on May 7, 2020 at 9:56 AM • 16 Comments

ILOVEYOU Virus

It's the twentieth anniversary of the ILOVEYOU virus, and here are three interesting articles about it and its effects on software design.

Tags: cybercrime, cybersecurity, history of computing, history of security, malware

Posted on May 6, 2020 at 6:47 AM • 6 Comments

Malware in Google Apps

Interesting story of malware hidden in Google Apps. This particular campaign is tied to the government of Vietnam.

At a remote virtual version of its annual Security Analyst Summit, researchers from the Russian security firm Kaspersky today plan to present research about a hacking campaign they call PhantomLance, in which spies hid malware in the Play Store to target users in Vietnam, Bangladesh, Indonesia, and India. Unlike most of the shady apps found in Play Store malware, Kaspersky's researchers say, PhantomLance's hackers apparently smuggled in data-stealing apps with the aim of infecting only some hundreds of users; the spy campaign likely sent links to the malicious apps to those targets via phishing emails. "In this case, the attackers used Google Play as a trusted source," says Kaspersky researcher Alexey Firsh. "You can deliver a link to this app, and the victim will trust it because it's Google Play."

[...]

The first hints of PhantomLance's campaign focusing on Google Play came to light in July of last year. That's when Russian security firm Dr. Web found a sample of spyware in Google's app store that impersonated a downloader of graphic design software but in fact had the capability to steal contacts, call logs, and text messages from Android phones. Kaspersky's researchers found a similar spyware app, impersonating a browser cache-cleaning tool called Browser Turbo, still active in Google Play in November of that year. (Google removed both malicious apps from Google Play after they were reported.) While the espionage capabilities of those apps was fairly basic, Firsh says that they both could have expanded. "What's important is the ability to download new malicious payloads," he says. "It could extend its features significantly."

Kaspersky went on to find tens of other, similar spyware apps dating back to 2015 that Google had already removed from its Play Store, but which were still visible in archived mirrors of the app repository. Those apps appeared to have a Vietnamese focus, offering tools for finding nearby churches in Vietnam and Vietnamese-language news. In every case, Firsh says, the hackers had created a new account and even Github repositories for spoofed developers to make the apps appear legitimate and hide their tracks.

Tags: espionage, Google, Kaspersky, malware, phishing, spyware

Posted on May 5, 2020 at 6:03 AM • 14 Comments

Denmark, Sweden, Germany, the Netherlands and France SIGINT Alliance

This paper describes a SIGINT and code-breaking alliance between Denmark, Sweden, Germany, the Netherlands and France called Maximator:

Abstract: This article is first to report on the secret European five-partner sigint alliance Maximator that started in the late 1970s. It discloses the name Maximator and provides documentary evidence. The five members of this European alliance are Denmark, Sweden, Germany, the Netherlands, and France. The cooperation involves both signals analysis and crypto analysis. The Maximator alliance has remained secret for almost fifty years, in contrast to its Anglo-Saxon Five-Eyes counterpart. The existence of this European sigint alliance gives a novel perspective on western sigint collaborations in the late twentieth century. The article explains and illustrates, with relatively much attention for the cryptographic details, how the five Maximator participants strengthened their effectiveness via the information about rigged cryptographic devices that its German partner provided, via the joint U.S.-German ownership and control of the Swiss producer Crypto AG of cryptographic devices.

Tags: academic papers, cryptanalysis, GCHQ, history of security, intelligence

Posted on May 4, 2020 at 6:42 AM • 5 Comments

Friday Squid Blogging: Cocaine Smuggled in Squid

Makes sense; there's room inside a squid's body cavity:

Latin American drug lords have sent bumper shipments of cocaine to Europe in recent weeks, including one in a cargo of squid, even though the coronavirus epidemic has stifled legitimate transatlantic trade, senior anti-narcotics officials say.

As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.

Read my blog posting guidelines here.

Tags: COVID-19, drug trade, smuggling, squid

Posted on May 1, 2020 at 4:06 PM • 95 Comments

Me on COVID-19 Contact Tracing Apps

I was quoted in BuzzFeed:

"My problem with contact tracing apps is that they have absolutely no value," Bruce Schneier, a privacy expert and fellow at the Berkman Klein Center for Internet & Society at Harvard University, told BuzzFeed News. "I'm not even talking about the privacy concerns, I mean the efficacy. Does anybody think this will do something useful? ... This is just something governments want to do for the hell of it. To me, it's just techies doing techie things because they don't know what else to do."

I haven't blogged about this because I thought it was obvious. But from the tweets and emails I have received, it seems not.

This is a classic identification problem, and efficacy depends on two things: false positives and false negatives.

• False positives: Any app will have a precise definition of a contact: let's say it's less than six feet for more than ten minutes. The false positive rate is the percentage of contacts that don't result in transmissions. This will be because of several reasons. One, the app's location and proximity systems -- based on GPS and Bluetooth -- just aren't accurate enough to capture every contact. Two, the app won't be aware of any extenuating circumstances, like walls or partitions. And three, not every contact results in transmission; the disease has some transmission rate that's less than 100% (and I don't know what that is).

• False negatives: This is the rate the app fails to register a contact when an infection occurs. This also will be because of several reasons. One, errors in the app's location and proximity systems. Two, transmissions that occur from people who don't have the app (even Singapore didn't get above a 20% adoption rate for the app). And three, not every transmission is a result of that precisely defined contact -- the virus sometimes travels further.

Assume you take the app out grocery shopping with you and it subsequently alerts you of a contact. What should you do? It's not accurate enough for you to quarantine yourself for two weeks. And without ubiquitous, cheap, fast, and accurate testing, you can't confirm the app's diagnosis. So the alert is useless.

Similarly, assume you take the app out grocery shopping and it doesn't alert you of any contact. Are you in the clear? No, you're not. You actually have no idea if you've been infected.

The end result is an app that doesn't work. People will post their bad experiences on social media, and people will read those posts and realize that the app is not to be trusted. That loss of trust is even worse than having no app at all.

It has nothing to do with privacy concerns. The idea that contact tracing can be done with an app, and not human health professionals, is just plain dumb.

EDITED TO ADD: This Brookings essay makes much the same point.

Tags: base rate, Bluetooth, COVID-19, false negatives, false positives, GPS, identification, medicine, privacy, surveillance, tracing

Posted on May 1, 2020 at 6:22 AM • 128 Comments

Securing Internet Videoconferencing Apps: Zoom and Others

The NSA just published a survey of video conferencing apps. So did Mozilla.

Zoom is on the good list, with some caveats. The company has done a lot of work addressing previous security concerns. It still has a bit to go on end-to-end encryption. Matthew Green looked at this. Zoom does offer end-to-end encryption if 1) everyone is using a Zoom app, and not logging in to the meeting using a webpage, and 2) the meeting is not being recorded in the cloud. That's pretty good, but the real worry is where the encryption keys are generated and stored. According to Citizen Lab, the company generates them.

The Zoom transport protocol adds Zoom's own encryption scheme to RTP in an unusual way. By default, all participants' audio and video in a Zoom meeting appears to be encrypted and decrypted with a single AES-128 key shared amongst the participants. The AES key appears to be generated and distributed to the meeting's participants by Zoom servers. Zoom's encryption and decryption use AES in ECB mode, which is well-understood to be a bad idea, because this mode of encryption preserves patterns in the input.

The algorithm part was just fixed:

AES 256-bit GCM encryption: Zoom is upgrading to the AES 256-bit GCM encryption standard, which offers increased protection of your meeting data in transit and resistance against tampering. This provides confidentiality and integrity assurances on your Zoom Meeting, Zoom Video Webinar, and Zoom Phone data. Zoom 5.0, which is slated for release within the week, supports GCM encryption, and this standard will take effect once all accounts are enabled with GCM. System-wide account enablement will take place on May 30.

There is nothing in Zoom's latest announcement about key management. So: while the company has done a really good job improving the security and privacy of their platform, there seems to be just one step remaining to fully encrypt the sessions.

The other thing I want Zoom to do is to make the security options necessary to prevent Zoombombing to be made available to users of the free version of that platform. Forcing users to pay for security isn't a viable option right now.

Finally -- I use Zoom all the time. I finished my Harvard class using Zoom; it's the university standard. I am having Inrupt company meetings on Zoom. I am having professional and personal conferences on Zoom. It's what everyone has, and the features are really good.

Tags: AES, encryption, Internet and society, keys, NSA, security engineering, videoconferencing

Posted on April 30, 2020 at 10:24 AM • 28 Comments

How Did Facebook Beat a Federal Wiretap Demand?

This is interesting:

Facebook Inc. in 2018 beat back federal prosecutors seeking to wiretap its encrypted Messenger app. Now the American Civil Liberties Union is seeking to find out how.

The entire proceeding was confidential, with only the result leaking to the press. Lawyers for the ACLU and the Washington Post on Tuesday asked a San Francisco-based federal court of appeals to unseal the judge's decision, arguing the public has a right to know how the law is being applied, particularly in the area of privacy.

[...]

The Facebook case stems from a federal investigation of members of the violent MS-13 criminal gang. Prosecutors tried to hold Facebook in contempt after the company refused to help investigators wiretap its Messenger app, but the judge ruled against them. If the decision is unsealed, other tech companies will likely try to use its reasoning to ward off similar government requests in the future.

Here's the 2018 story. Slashdot thread.

Tags: ACLU, courts, crime, eavesdropping, encryption, Facebook, privacy, surveillance

Posted on April 29, 2020 at 12:29 PM • 14 Comments