Terrorist Risks by City, According to Actual Data

https://www.schneier.com/blog/archives/2015/05/terrorist_risks_1.html

I don't know enough about the methodology to judge it, but it's interesting:

In total, 64 cities are categorised as 'extreme risk' in Verisk Maplecroft's new Global Alerts Dashboard (GAD), an online mapping and data portal that logs and analyses every reported terrorism incident down to levels of 100m² worldwide. Based on the intensity and frequency of attacks in the 12 months following February 2014, combined with the number and severity of incidents in the previous five years, six cities in Iraq top the ranking. Over this period, the country's capital, Baghdad, suffered 380 terrorist attacks resulting in 1141 deaths and 3654 wounded, making it the world's highest risk urban centre, followed by Mosul, Al Ramadi, Ba'qubah, Kirkuk and Al Hillah.

Outside of Iraq, other capital cities rated 'extreme risk' include Kabul, Afghanistan (13th most at risk), Mogadishu, Somalia (14th), Sana'a, Yemen (19th) and Tripoli, Libya (48th). However, with investment limited in conflict and post-conflict locations, it is the risk posed by terrorism in the primary cities of strategic economies, such as Egypt, Israel, Kenya, Nigeria and Pakistan that has the potential to threaten business and supply chain continuity.

A news article:

According to the index, which ranks world cities by the likelihood of a terror attack based on historic trends, 64 cities around the world are at "extreme risk" of a terror attack.

Of these, the majority are in the Middle East (27) or Asia (19).
Some 14 are in Africa, where the rise of Boko Haram and al-Shabaab as well as political instability have increased risk.

Three are in Europe -- Luhansk (46) and Donetsk (56) in Ukraine, and Grozy (54) in Russia -- while Colombia's Cali (59) is the only South American city on the list.

No US city makes the list.

Race Condition Exploit in Starbucks Gift Cards

https://www.schneier.com/blog/archives/2015/05/race_condition_.html

A researcher was able to steal money from Starbucks by exploiting a race condition in their gift-card value-transfer protocol. Basically, by initiating two identical web transfers at once, he was able to trick the system into recording them both. Normally, you could take a $5 gift card and move that money to another $5 gift card, leaving you with an empty gift card and a $10 gift card. He was able to duplicate the transfer, giving him an empty gift card and a $15 gift card.

Race-condition attacks are unreliable and it took him a bunch of tries to get it right, but there's no reason to believe that he couldn't have kept doing this forever.

Unfortunately, there was really no one at Starbucks he could tell this to:

The hardest part -- responsible disclosure. Support guy honestly answered there's absolutely no way to get in touch with technical department and he's sorry I feel this way. Emailing InformationSecurityServices@starbucks.com on March 23 was futile (and it only was answered on Apr 29). After trying really hard to find anyone who cares, I managed to get this bug fixed in like 10 days.

The unpleasant part is a guy from Starbucks calling me with nothing like "thanks" but mentioning "fraud" and "malicious actions" instead. Sweet!

A little more from BBC News:

A spokeswoman for Starbucks told BBC News: "After this individual reported he was able to commit fraudulent activity against Starbucks, we put safeguards in place to prevent replication."

The company did not answer questions about its response to Mr Homakov.

More info.

Stink Bombs for Riot Control

https://www.schneier.com/blog/archives/2015/05/stink_bombs_for.html

They're coming to the US:

It's called Skunk, a type of "malodorant," or in plainer language, a foul-smelling liquid. Technically nontoxic but incredibly disgusting, it has been described as a cross between "dead animal and human excrement." Untreated, the smell lingers for weeks.

The Israeli Defense Forces developed Skunk in 2008 as a crowd-control weapon for use against Palestinians. Now Mistral, a company out of Bethesda, Md., says they are providing it to police departments in the United States.

[...]

The Israelis first used it in 2008 to disperse Palestinians protesting in the West Bank. A BBC video shows its first use in action, sprayed by a hose, a system that has come to be known as the "crap cannon."

Mistral reps say Skunk, once deployed, can be "neutralized" with a special soap ­ and only with that soap. In another BBC video, an IDF spokesman describes how any attempt to wash it via regular means only exacerbates its effects. Six weeks after IDF forces used it against Palestinians at a security barrier, it still lingered in the air.

Why the Current Section 215 Reform Debate Doesn't Matter Much

https://www.schneier.com/blog/archives/2015/05/why_the_current.html

The ACLU's Chris Soghoian explains (time 25:52-30:55) why the current debate over Section 215 of the Patriot Act is just a minor facet of a large and complex bulk collection program by the FBI and the NSA.

There were 180 orders authorized last year by the FISA Court under Section 215 -- 180 orders issued by this court. Only five of those orders relate to the telephony metadata program. There are 175 orders about completely separate things. In six weeks, Congress will either reauthorize this statute or let it expire, and we're having a debate -- to the extent we're even having a debate -- but the debate that's taking place is focused on five of the 180, and there's no debate at all about the other 175 orders.

Now, Senator Wyden has said there are other bulk collection programs targeted at Americans that the public would be shocked to learn about. We don't know, for example, how the government collects records from Internet providers. We don't know how they get bulk metadata from tech companies about Americans. We don't know how the American government gets calling card records.

If we take General Hayden at face value -- and I think you're an honest guy -- if the purpose of the 215 program is to identify people who are calling Yemen and Pakistan and Somalia, where one end is in the United States, your average Somali-American is not calling Somalia from their land line phone or their cell phone for the simple reason that AT&T will charge them $7.00 a minute in long distance fees. The way that people in the diaspora call home -- the way that people in the Somali or Yemeni community call their family and friends back home -- they walk into convenience stores and they buy prepaid calling cards. That is how regular people make international long distance calls.

So the 215 program that has been disclosed publicly, the 215 program that is being debated publicly, is about records to major carriers like AT&T and Verizon. We have not had a debate about surveillance requests, bulk orders to calling card companies, to Skype, to voice over Internet protocol companies. Now, if NSA isn't collecting those records, they're not doing their job. I actually think that that's where the most useful data is. But why are we having this debate about these records that don't contain a lot of calls to Somalia when we should be having a debate about the records that do contain calls to Somalia and do contain records of e-mails and instant messages and searches and people posting inflammatory videos to YouTube?

Certainly the government is collecting that data, but we don't know how they're doing it, we don't know at what scale they're doing it, and we don't know with which authority they're doing it. And I think it is a farce to say that we're having a debate about the surveillance authority when really, we're just debating this very narrow usage of the statute.

Further underscoring this point, yesterday the Department of Justice's Office of the Inspector General released a redacted version of its internal audit of the FBI's use of Section 215: "A Review of the FBI's Use of Section 215 Orders: Assessment of Progress in Implementing Recommendations and Examination of Use in 2007 through 2009," following the reports of the statute's use from 2002-2005 and 2006. (Remember that the FBI and the NSA are inexorably connected here. The order to Verizon was from the FBI, requiring it to turn data over to the NSA.)

Details about legal justifications are all in the report (see here for an important point about minimization), but detailed data on exactly what the FBI is collecting -- whether targeted or bulk -- is left out. We read that the FBI demanded "customer information" (p. 36), "medical and educational records" (p. 39) "account information and electronic communications transactional records" (p. 41), "information regarding other cyber activity" (p. 42). Some of this was undoubtedly targeted against individuals; some of it was undoubtedly bulk.

I believe bulk collection is discussed in detail in Chapter VI. The chapter title is redacted, as well as the introduction (p. 46). Section A is "Bulk Telephony Metadata." Section B (pp. 59-63) is completely redacted, including the section title. There's a summary in the Introduction (p. 3): "In Section VI, we update the information about the uses of Section 215 authority described [redacted word] Classified Appendices to our last report. These appendices described the FBI's use of Section 215 authority on behalf of the NSA to obtain bulk collections of telephony metadata [long redacted clause]." Sounds like a comprehensive discussion of bulk collection under Section 215.

What's in there? As Soghoian says, certainly other communications systems like prepaid calling cards, Skype, text messaging systems, and e-mails. Search history and browser logs? Financial transactions? The "medical and educational records" mentioned above? Probably all of them -- and the data is in the report, redacated (p. 29) -- but there's nothing public.

The problem is that those are the pages Congress should be debating, and not the telephony metadata program exposed by Snowden.

EDITED TO ADD: Marcy Wheeler is going through the document line by line.

New Pew Research Report on Americans' Attitudes on Privacy, Security, and Surveillance

https://www.schneier.com/blog/archives/2015/05/new_pew_researc.html

This is interesting:

The surveys find that Americans feel privacy is important in their daily lives in a number of essential ways. Yet, they have a pervasive sense that they are under surveillance when in public and very few feel they have a great deal of control over the data that is collected about them and how it is used. Adding to earlier Pew Research reports that have documented low levels of trust in sectors that Americans associate with data collection and monitoring, the new findings show Americans also have exceedingly low levels of confidence in the privacy and security of the records that are maintained by a variety of institutions in the digital age.

While some Americans have taken modest steps to stem the tide of data collection, few have adopted advanced privacy-enhancing measures. However, majorities of Americans expect that a wide array of organizations should have limits on the length of time that they can retain records of their activities and communications. At the same time, Americans continue to express the belief that there should be greater limits on government surveillance programs. Additionally, they say it is important to preserve the ability to be anonymous for certain online activities.

Lots of detail in the reports.

The Logjam (and Another) Vulnerability against Diffie-Hellman Key Exchange

https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html

Logjam is a new attack against the Diffie-Hellman key-exchange protocol used in TLS. Basically:

The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography. This allows the attacker to read and modify any data passed over the connection. The attack is reminiscent of the FREAK attack, but is due to a flaw in the TLS protocol rather than an implementation vulnerability, and attacks a Diffie-Hellman key exchange rather than an RSA key exchange. The attack affects any server that supports DHE_EXPORT ciphers, and affects all modern web browsers. 8.4% of the Top 1 Million domains were initially vulnerable.

Here's the academic paper.

One of the problems with patching the vulnerability is that it breaks things:

On the plus side, the vulnerability has largely been patched thanks to consultation with tech companies like Google, and updates are available now or coming soon for Chrome, Firefox and other browsers. The bad news is that the fix rendered many sites unreachable, including the main website at the University of Michigan, which is home to many of the researchers that found the security hole.

This is a common problem with version downgrade attacks; patching them makes you incompatible with anyone who hasn't patched. And it's the vulnerability the media is focusing on.

Much more interesting is the other vulnerability that the researchers found:

Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key exchange. Practitioners believed this was safe as long as new key exchange messages were generated for every connection. However, the first step in the number field sieve -- the most efficient algorithm for breaking a Diffie-Hellman connection -- is dependent only on this prime. After this first step, an attacker can quickly break individual connections.

The researchers believe the NSA has been using this attack:

We carried out this computation against the most common 512-bit prime used for TLS and demonstrate that the Logjam attack can be used to downgrade connections to 80% of TLS servers supporting DHE_EXPORT. We further estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime. Breaking the single, most common 1024-bit prime used by web servers would allow passive eavesdropping on connections to 18% of the Top 1 Million HTTPS domains. A second prime would allow passive decryption of connections to 66% of VPN servers and 26% of SSH servers. A close reading of published NSA leaks shows that the agency's attacks on VPNs are consistent with having achieved such a break.

Remember James Bamford's 2012 comment about the NSA's cryptanalytic capabilities:

According to another top official also involved with the program, the NSA made an enormous breakthrough several years ago in its ability to cryptanalyze, or break, unfathomably complex encryption systems employed by not only governments around the world but also many average computer users in the US. The upshot, according to this official: "Everybody's a target; everybody with communication is a target."

[...]

The breakthrough was enormous, says the former official, and soon afterward the agency pulled the shade down tight on the project, even within the intelligence community and Congress. "Only the chairman and vice chairman and the two staff directors of each intelligence committee were told about it," he says. The reason? "They were thinking that this computing breakthrough was going to give them the ability to crack current public encryption."

And remember Director of National Intelligence James Clapper's introduction to the 2013 "Black Budget":

Also, we are investing in groundbreaking cryptanalytic capabilities to defeat adversarial cryptography and exploit internet traffic.

It's a reasonable guess that this is what both Bamford's source and Clapper are talking about. It's an attack that requires a lot of precomputation -- just the sort of thing a national intelligence agency would go for.

But that requirement also speaks to its limitations. The NSA isn't going to put this capability at collection points like Room 641A at AT&T's San Francisco office: the precomputation table is too big, and the sensitivity of the capability is too high. More likely, an analyst identifies a target through some other means, and then looks for data by that target in databases like XKEYSCORE. Then he sends whatever ciphertext he finds to the Cryptanalysis and Exploitation Services (CES) group, which decrypts it if it can using this and other techniques.

Ross Anderson wrote about this earlier this month, almost certainly quoting Snowden:

As for crypto capabilities, a lot of stuff is decrypted automatically on ingest (e.g. using a "stolen cert", presumably a private key obtained through hacking). Else the analyst sends the ciphertext to CES and they either decrypt it or say they can't.

The analysts are instructed not to think about how this all works. This quote also applied to NSA employees:

Strict guidelines were laid down at the GCHQ complex in Cheltenham, Gloucestershire, on how to discuss projects relating to decryption. Analysts were instructed: "Do not ask about or speculate on sources or methods underpinning Bullrun."

I remember the same instructions in documents I saw about the NSA's CES.

Again, the NSA has put surveillance ahead of security. It never bothered to tell us that many of the "secure" encryption systems we were using were not secure. And we don't know what other national intelligence agencies independently discovered and used this attack.

The good news is now that we know reusing prime numbers is a bad idea, we can stop doing it.

EDITED TO ADD: The DH precomputation easily lends itself to custom ASIC design, and is something that pipelines easily. Using BitCoin mining hardware as a rough comparison, this means a couple orders of magnitude speedup.

EDITED TO ADD (5/23): Good analysis of the cryptography.

EDITED TO ADD (5/24): Good explanation by Matthew Green.

Research on Patch Deployment

https://www.schneier.com/blog/archives/2015/05/research_on_pat.html

New research indicates that it's very hard to completely patch systems against vulnerabilities:

It turns out that it may not be that easy to patch vulnerabilities completely. Using

[Error: Irreparable invalid markup ('<a https://www.umiacs.umd.edu/~tdumitra/blog/old/worldwide-intelligence-network-environment/">') in entry. Owner must fix manually. Raw contents below.]

<p class="ljsyndicationlink"><a href="https://www.schneier.com/blog/archives/2015/05/research_on_pat.html">https://www.schneier.com/blog/archives/2015/05/research_on_pat.html</a></p><p><a href="https://www.umiacs.umd.edu/~tdumitra/blog/2015/04/15/impact-of-shared-code-on-vulnerability-patching/">New research</a> indicates that it's very hard to completely patch systems against vulnerabilities:</p> <blockquote><p>It turns out that it may not be that easy to patch vulnerabilities completely. Using <a https://www.umiacs.umd.edu/~tdumitra/blog/old/worldwide-intelligence-network-environment/"="https://www.umiacs.umd.edu/~tdumitra/blog/old/worldwide-intelligence-network-environment/&quot;">WINE</a>, we analyzed the patch deployment process for 1,593 vulnerabilities from 10 Windows client applications, on 8.4 million hosts worldwide <a href="https://www.umiacs.umd.edu/~tdumitra/blog/2015/04/15/impact-of-shared-code-on-vulnerability-patching/#OAKLAND-2015">[Oakland 2015]</a>. We found that a host may be affected by <em>multiple instances</em> of the same vulnerability, because the vulnerable program is installed in several directories or because the vulnerability is in a shared library distributed with several applications. For example, CVE-2011-0611 affected both the Adobe Flash Player and Adobe Reader (Reader includes a library for playing .swf objects embedded in a PDF). Because updates for the two products were distributed using different channels, the vulnerable host population decreased at different rates, as illustrated in the figure on the left. For Reader patching started 9 days after disclosure (after patch for CVE-2011-0611 was bundled with another patch in a new Reader release), and the update reached 50% of the vulnerable hosts after 152 days. <p>For Flash patching started earlier, 3 days after disclosure, but the patching rate soon dropped (a second patching wave, suggested by the inflection in the curve after 43 days, eventually subsided as well). Perhaps for this reason, CVE-2011-0611 was <a href="http://download.microsoft.com/download/0/3/3/0331766E-3FC4-44E5-B1CA-2BDEB58211B8/Microsoft_Security_Intelligence_Report_volume_11_Zeroing_in_on_Malware_Propagation_Methods_English.pdf">frequently targeted by exploits in 2011</a>, using both the .swf and PDF vectors.</p></blockquote> <p><a href="https://www.umiacs.umd.edu/~tdumitra/blog/2015/04/15/impact-of-shared-code-on-vulnerability-patching/#OAKLAND-2015">Paper</a>.</p>