HAMMERTOSS: New Russian Malware

Fireeye has a detailed report of a sophisticated piece of Russian malware: HAMMERTOSS. It uses some clever techniques to hide:

The Hammertoss backdoor malware looks for a different Twitter handle each day -- automatically prompted by a list generated by the tool -- to get its instructions. If the handle it's looking for is not registered that day, it merely returns the next day and checks for the Twitter handle designated for that day. If the account is active, Hammertoss searches for a tweet with a URL and hashtag, and then visits the URL.

That's where a legit-looking image is grabbed and then opened by Hammertoss: the image contains encrypted instructions, which Hammertoss decrypts. The commands, which include instructions for obtaining files from the victim's network, typically then lead the malware to send that stolen information to a cloud-based storage service.

Another article. Reddit thread.

Posted on July 31, 2015 at 11:12 AM0 Comments

Back Doors Won't Solve Comey's Going Dark Problem

At the Aspen Security Forum two weeks ago, James Comey (and others) explicitly talked about the "going dark" problem, describing the specific scenario they are concerned about. Maybe others have heard the scenario before, but it was a first for me. It's centers around ISIL operatives abroad and ISIL-inspired terrorists here in the US. The FBI knows who the Americans are, can get a court order to carry out surveillance on their communications, but cannot eavesdrop on the conversations because they are encrypted. They can get the metadata, so they know who is talking to who, but they can't find out what's being said.

"ISIL's M.O. is to broadcast on Twitter, get people to follow them, then move them to Twitter Direct Messaging" to evaluate if they are a legitimate recruit, he said. "Then they'll move them to an encrypted mobile-messaging app so they go dark to us."


The FBI can get court-approved access to Twitter exchanges, but not to encrypted communication, Comey said. Even when the FBI demonstrates probable cause and gets a judicial order to intercept that communication, it cannot break the encryption for technological reasons, according to Comey.

If this is what Comey and the FBI is actually concerned about, they're getting bad advice -- because their proposed solution won't solve the problem. Comey wants communications companies to give them the capability to eavesdrop on conversations without the conversants' knowledge or consent; that's the "back door" we're all talking about. But the problem isn't that most encrypted communications platforms are security encrypted, or even that some are -- the problem is that there exists at least one securely encrypted communications platform on the planet that ISIL can use.

Imagine that Comey got what he wanted. Imagine that iMessage and Facebook and Skype and everything else US-made had his back door. The ISIL operative would tell his potential recruit to use something else, something secure and non-US-made. Maybe an encryption program from Finland, or Switzerland, or Brazil. Maybe Mujahedeen Secrets. Maybe anything. (Sure, some of these will have flaws, and they'll be identifiable by their metadata, but the FBI already has the metadata, and the better software will rise to the top.) As long as there is something that the ISIL operative can move them to, some software that the American can download and install on their phone or computer, or hardware that they can buy from abroad, the FBI still won't be able to eavesdrop.

And by pushing these ISIL operatives to non-US platforms, they lose access to the metadata they otherwise have.

Convincing US companies to install back doors isn't enough; in order to solve this going dark problem the FBI has to ensure that an American can only use back-doored software. And the only way to do that is to prohibit the use of non-back-doored software, which is the sort of thing that the UK's David Cameron said he wanted for his country in January:

But the question is are we going to allow a means of communications which it simply isn't possible to read. My answer to that question is: no, we must not.

And that, of course, is impossible. Jonathan Zittrain explained why. And Cory Doctorow outlined what trying would entail:

For David Cameron's proposal to work, he will need to stop Britons from installing software that comes from software creators who are out of his jurisdiction. The very best in secure communications are already free/open source projects, maintained by thousands of independent programmers around the world. They are widely available, and thanks to things like cryptographic signing, it is possible to download these packages from any server in the world (not just big ones like Github) and verify, with a very high degree of confidence, that the software you've downloaded hasn't been tampered with.


This, then, is what David Cameron is proposing:

* All Britons' communications must be easy for criminals, voyeurs and foreign spies to intercept.

* Any firms within reach of the UK government must be banned from producing secure software.

* All major code repositories, such as Github and Sourceforge, must be blocked.

* Search engines must not answer queries about web-pages that carry secure software.

* Virtually all academic security work in the UK must cease -- security research must only take place in proprietary research environments where there is no onus to publish one's findings, such as industry R&D and the security services.

* All packets in and out of the country, and within the country, must be subject to Chinese-style deep-packet inspection and any packets that appear to originate from secure software must be dropped.

* Existing walled gardens (like IOs and games consoles) must be ordered to ban their users from installing secure software.

* Anyone visiting the country from abroad must have their smartphones held at the border until they leave.

* Proprietary operating system vendors (Microsoft and Apple) must be ordered to redesign their operating systems as walled gardens that only allow users to run software from an app store, which will not sell or give secure software to Britons.

* Free/open source operating systems -- that power the energy, banking, ecommerce, and infrastructure sectors -- must be banned outright.

As extreme as it reads, without all of that the ISIL operative will be able to communicate securely with his potential American recruit. And all of this is not going to happen.

Last week, former NSA director Mike McConnell, former DHS secretary Michael Chertoff, and former deputy defense secretary William Lynn published a Washington Post op ed opposing back doors in encryption software. They wrote:

Today, with almost everyone carrying a networked device on his or her person, ubiquitous encryption provides essential security. If law enforcement and intelligence organizations face a future without assured access to encrypted communications, they will develop technologies and techniques to meet their legitimate mission goals.

I believe this is true. Already one is being talked about in the academic literature: lawful hacking.

Perhaps the FBI's reluctance to accept this is based on their belief that all encryption software comes from the US, and therefor is under their influence. Back in the 1990s, during the First Crypto Wars, the US government had a similar belief. To convince them otherwise, George Washington University surveyed the cryptography market in 1999 and found that there were over 500 companies in 70 countries manufacturing or distributing non-US cryptography products. Maybe we need a similar study today.

This essay previously appeared on Lawfare.

Posted on July 31, 2015 at 6:08 AM41 Comments

Comparing the Security Practices of Experts and Non-Experts

New paper: "'...no one can hack my mind': Comparing Expert and Non-Expert Security Practices," by Iulia Ion, Rob Reeder, and Sunny Consolvo.

Abstract: The state of advice given to people today on how to stay safe online has plenty of room for improvement. Too many things are asked of them, which may be unrealistic, time consuming, or not really worth the effort. To improve the security advice, our community must find out what practices people use and what recommendations, if messaged well, are likely to bring the highest benefit while being realistic to ask of people. In this paper, we present the results of a study which aims to identify which practices people do that they consider most important at protecting their security on-line. We compare self-reported security practices of non-experts to those of security experts (i.e., participants who reported having five or more years of experience working in computer security). We report on the results of two online surveys -- ­one with 231 security experts and one with 294 MTurk participants­ -- on what the practices and attitudes of each group are. Our findings show a discrepancy between the security practices that experts and non-experts report taking. For instance, while experts most frequently report installing software updates, using two-factor authentication and using a password manager to stay safe online, non-experts report using antivirus software, visiting only known websites, and changing passwords frequently.

Posted on July 30, 2015 at 2:21 PM18 Comments

The NSA, Metadata, and the Failure of Stopping 9/11

It's common wisdom that the NSA was unable to intercept phone calls from Khalid al-Mihdhar in San Diego to Bin Ladin in Yemen because of legal restrictions. This has been used to justify the NSA's massive phone metadata collection programs. James Bamford argues that there were no legal restrictions, and that the NSA screwed up.

Posted on July 30, 2015 at 6:13 AM28 Comments

Fugitive Located by Spotify

The latest in identification by data:

Webber said a tipster had spotted recent activity from Nunn on the Spotify streaming service and alerted law enforcement. He scoured the Internet for other evidence of Nunn and Barr's movements, eventually filling out 12 search warrants for records at different technology companies. Those searches led him to an IP address that traced Nunn to Cabo San Lucas, Webber said.

Nunn, he said, had been avidly streaming television shows and children's programs on various online services, giving the sheriff's department a hint to the couple's location.

Posted on July 29, 2015 at 1:43 PM14 Comments

Bizarre High-Tech Kidnapping

This is a story of a very high-tech kidnapping:

FBI court filings unsealed last week showed how Denise Huskins' kidnappers used anonymous remailers, image sharing sites, Tor, and other people's Wi-Fi to communicate with the police and the media, scrupulously scrubbing meta data from photos before sending. They tried to use computer spyware and a DropCam to monitor the aftermath of the abduction and had a Parrot radio-controlled drone standing by to pick up the ransom by remote control.

The story also demonstrates just how effective the FBI is tracing cell phone usage these days. They had a blocked call from the kidnappers to the victim's cell phone. First they used an search warrant to AT&T to get the actual calling number. After learning that it was an AT&T prepaid Trakfone, they called AT&T to find out where the burner was bought, what the serial numbers were, and the location where the calls were made from.

The FBI reached out to Tracfone, which was able to tell the agents that the phone was purchased from a Target store in Pleasant Hill on March 2 at 5:39 pm. Target provided the bureau with a surveillance-cam photo of the buyer: a white male with dark hair and medium build. AT&T turned over records showing the phone had been used within 650 feet of a cell site in South Lake Tahoe.

Here's the criminal complaint. It borders on surreal. Were it an episode of CSI:Cyber, you would never believe it.

Posted on July 29, 2015 at 6:34 AM45 Comments

New RC4 Attack

New research: "All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS," by Mathy Vanhoef and Frank Piessens:

Abstract: We present new biases in RC4, break the Wi-Fi Protected Access Temporal Key Integrity Protocol (WPA-TKIP), and design a practical plaintext recovery attack against the Transport Layer Security (TLS) protocol. To empirically find new biases in the RC4 keystream we use statistical hypothesis tests. This reveals many new biases in the initial keystream bytes, as well as several new long-term biases. Our fixed-plaintext recovery algorithms are capable of using multiple types of biases, and return a list of plaintext candidates in decreasing likelihood.

To break WPA-TKIP we introduce a method to generate a large number of identical packets. This packet is decrypted by generating its plaintext candidate list, and using redundant packet structure to prune bad candidates. From the decrypted packet we derive the TKIP MIC key, which can be used to inject and decrypt packets. In practice the attack can be executed within an hour. We also attack TLS as used by HTTPS, where we show how to decrypt a secure cookie with a success rate of 94% using 9*227 ciphertexts. This is done by injecting known data around the cookie, abusing this using Mantin's ABSAB bias, and brute-forcing the cookie by traversing the plaintext candidates. Using our traffic generation technique, we are able to execute the attack in merely 75 hours.

News articles.

We need to deprecate the algorithm already.

Posted on July 28, 2015 at 12:09 PM12 Comments

Stagefright Vulnerability in Android Phones

The Stagefright vulnerability for Android phones is a bad one. It's exploitable via a text message (details depend on auto downloading of the particular phone), it runs at an elevated privilege (again, the severity depends on the particular phone -- on some phones it's full privilege), and it's trivial to weaponize. Imagine a worm that infects a phone and then immediately sends a copy of itself to everyone on that phone's contact list.

The worst part of this is that it's an Android exploit, so most phones won't be patched anytime soon -- if ever. (The people who discovered the bug alerted Google in April. Google has sent patches to its phone manufacturer partners, but most of them have not sent the patch to Android phone users.)

Posted on July 28, 2015 at 6:37 AM53 Comments

Michael Chertoff Speaks Out Against Backdoors

This is significant.

News article.

EDITED TO ADD (7/28): Commentary, and former Director of the National Counterintelligence Center Michael Leiter's comments.

Posted on July 27, 2015 at 1:16 PM31 Comments

Hacking Team's Purchasing of Zero-Day Vulnerabilities

This is an interesting article that looks at Hacking Team's purchasing of zero-day (0day) vulnerabilities from a variety of sources:

Hacking Team's relationships with 0day vendors date back to 2009 when they were still transitioning from their information security consultancy roots to becoming a surveillance business. They excitedly purchased exploit packs from D2Sec and VUPEN, but they didn't find the high-quality client-side oriented exploits they were looking for. Their relationship with VUPEN continued to frustrate them for years. Towards the end of 2012, CitizenLab released their first report on Hacking Team's software being used to repress activists in the United Arab Emirates. However, a continuing stream of negative reports about the use of Hacking Team's software did not materially impact their relationships. In fact, by raising their profile these reports served to actually bring Hacking Team direct business. In 2013 Hacking Team's CEO stated that they had a problem finding sources of new exploits and urgently needed to find new vendors and develop in-house talent. That same year they made multiple new contacts, including Netragard, Vitaliy Toropov, Vulnerabilities Brokerage International, and Rosario Valotta. Though Hacking Team's internal capabilities did not significantly improve, they continued to develop fruitful new relationships. In 2014 they began a close partnership with Qavar Security.

Lots of details in the article. This was made possible by the organizational doxing of Hacking Team by some unknown individuals or group.

Posted on July 27, 2015 at 6:17 AM29 Comments

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient Systems, Inc.