Thursday, April 16, 2015


The government's zealous War on Hackers threatens us, the good hackers who stop the bad ones. They can't tell the good witches from the bad witches. When members of our community get threatened by the system, we should probably do more to stand in solidarity with them. I mention this because many of you will be flying to SFO this coming week for the RSA Conference, which gives us an opportunity to show solidarity.

Today, a security researcher tweeted a joke while on a plane. When he landed, the FBI grabbed him and confiscated all his stuff. The tweets are here:

Chris Roberts' area of research is embedded control systems like those on planes. It's not simply that the FBI grabbed him because of a random person on a plane, but specifically because he's a security researcher. He's on the FBI's radar (so to speak) for things like this Fox News interview.

I suggest we all start joke tweeting along these lines,  from the airplanes, like:

DFW->SFO. Playing with airplane wifi. I hope the pilots enjoy the Rick Astely video playing on their EICAS system. 
LGA->SFO. Note to self. Don't fuzz the SATCOM unit while on Twitter. Takes GoGo an hour to come back up. 
NRT->SFO. Yup, the IFE will grab corrupt MP3 from my iPhone and give a shell. I wonder if nmap will run on it. 
PDX->SFO. HackRF says there's a strong 915 MHz qpsk 64k symbol/second signal. I wonder what'll happen if I replay it.
The trick is to write jokes, not to actually threaten anything -- like the original tweet above. Those of us with technical knowledge and skills should be free to express our humor without the FBI confiscating all our stuff when we land.

BTW, I know you can all steal in-flight WiFi easier than you can pay for it, but do pay for it :)

Wednesday, April 15, 2015

Masscanning for MS15-034

So Microsoft has an important web-server bug, so naturally I'd like to scan the Internet for it. I'm running the scan now, but I'm not sure it's going to give any useful results.

The bug comes from adding the following header to a web request like the following
Range: bytes=0-18446744073709551615
As you can see, it's just a standard (64-bit) integer overflow, where 18446744073709551615 equals -1.

That specific header is harmless, it appears that other variations are the ones that may cause a problem. However, it serves as a useful check to see if the server is patched. If the server is unpatched, it'll return the following error:
HTTP/1.1 416 Requested Range Not Satisfiable
From the PoC's say, a response that looks like the following means that it is patched:
The request has an invalid header name
However, when I run the scan across the Internet, I'm getting the following sorts of responses from servers claiming to be IIS:

HTTP/1.1 200 OK
HTTP/1.1 206 Partial Content
HTTP/1.1 301 Moved Permanently
HTTP/1.1 302 Object moved
HTTP/1.1 302 Found
HTTP/1.1 302 Redirect
HTTP/1.1 401 Unauthorized
HTTP/1.1 403 Forbidden
HTTP/1.1 404 Object Not Found
HTTP/1.1 416 Requested Range Not Satisfiable
HTTP/1.1 500 URL Rewrite Module Error.
HTTP/1.1 500 Internal Server Error

I suspect the biggest reason is that the "Range" header only is parsed when there is a static file being served. If a script generates the page, then it'll ignore the range. I also suspect that virtual-hosting gets in the way -- that unless the correct DNS name is provided, then it'll reject the request.

Thus, the testing is inconclusive. While I can find some vulnerable responses, just because a server gives me some other response doesn't mean it's not also vulnerable. Thus, I can't really say anything about the extent of the vulnerability.

It's an important message for companies using various tools to see if they are completely patched. Just because the tools can't find vulnerable systems doesn't mean you aren't vulnerable.

Saturday, April 11, 2015

Should billionaires have to disclose their political contributions?

The Intercept has a story about a billionaire sneaking into a Jeb Bush fundraiser. It points out:
"Bush’s campaign operation has taken steps to conceal the names of certain big-money donors. ... Bush’s Right to Rise also formed a 501(c)(4) issue advocacy wing, which, like a Super PAC, can raise and spend unlimited amounts of money — but unlike a Super PAC, never has to reveal donor names."
This leads me to ask two questions:

  1. Should billionaires be allowed to spend unlimited amounts of money promoting their politics?
  2. If they can spend unlimited amounts, should they be forced to disclose them?

If you know me, you know that I'm asking a trick question. I'm not referring to venture capitalist Ron Conway, the billionaire mentioned the story. I'm instead referring to Pierre Omidyar the billionaire founder of eBay who funds The Intercept, which blatantly promotes his political views such as those on NSA surveillance. Can Omidyar spend endless amounts on The Intercept? Should he be forced to disclose how much?

This question is at the heart of the Supreme Court decision in Citezen's United. It comes down to this: the Supreme Court was unable to craft rules that could tell the difference between what Omidyar was doing with The Intercept, and what Jeb Bush is doing with his Super PAC. Yet, restricting Omidyar is also not an option -- despite being clearly political, he's nonetheless acting like a typical press organization. As they opinion says:
Differential treatment of media corporations and other corporations cannot be squared with the First Amendment, and there is no support for the view that the Amendment’s original meaning would permit suppressing media corporations’ political speech. 
As a libertarian, I think Omidyar should be free to use his slush fund for The Intercept as he pleases, without having to report the amounts. However, I still believe it's in the public interest. Nobody wants to live in a plutocracy, so all info about the rich and powerful is of public interest. If Anonymous doxxes it, or an employees leaks it, then the information is fair game, and should be reported on in exactly the same way that The Intercept discloses the Snowden leaks.

Friday, April 10, 2015

Scalability of the Great Cannon

Here is a great paper on China's Great Cannon, which was used to DDoS GitHub. One question is how scalable such a system can be, or how much resources it would take for China to intercept connections and replace content.

The first question is how much bandwidth China needs to monitor. According to the this website, in early 2015 that's 1.9-terabits/second (1,899,792-mbps).

The second question is how much hardware China needs to buy in order to intercept network traffic, reassemble TCP streams, and insert responses. The answer is about one $1000 desktop computer per 10-gbps of traffic. In other words, China can deploy the Great Cannon using $200,000 worth of hardware.

This answer is a little controversial. Most people think that a mere desktop computer could not handle 10-gbps of throughput, much less do anything complicated with it like reassembling TCP streams. However, they are wrong. Intel has put an enormous amount of functionality into their hardware to solve precisely this problem. Unfortunately, modern software like Linux or Windows is a decade behind hardware advances, and cannot take advantage of this.

The first step is to bypass the operating system. This sounds a bit odd, but it's not hard to do. There are several projects (DPDK, PF_RING, netmap) that disconnect the network card from the kernel and connect it directly to your software. They are fairly straight forward to use. My GitHub account has several examples; I ought to produce more. These applications are able to transmit and receive packets with zero overhead. My apps handle 30-million packets/second, Intel has prototypes that do 80-million packets/second. This is far great than the 10-million packets/second you'd need to handle for a Great Cannon.

Another trick is how TCP reassembly is handled. Almost everyone does it the wrong way, which involves buffering every packet that comes in. The correct way is to write parsers as state-machines, buffering the state between packets, and not the packets themselves. Out-of-order packets need to still be buffered, but this is a small percentage of the total. With a zero overhead driver and state-machine parsers, you'll find that you can easily keep up with a 10-gbps stream.

Those are the basics, but there are a bunch of other issues you'll need to solve. For example, consider the issue of jitter, when Linux interrupts your thread. That'll cause whichever packet you are currently processing to be delayed several milliseconds. This is death for a network device. Luckily, you can tell Linux to reserve specific CPU cores as off-limits, allowing you to run threads on those cores without ever getting interrupted. This allows microsecond-scale latency/jitter, which given that traffic to/from China has about a 250-millisecond latency, is meaningless.

I've built such systems. They really do work. Indeed, you could use the product I built (now sold by IBM) and do exactly what China did.

So the deal is this. You'd think with a billion people and terabits of Internet traffic, that such a system would be hard. In fact, in the relative scale of things, it's trivial.

I did a presentation at Shmoocon on this a couple years ago:

So I have a lab at some with a bunch of computers doing 10-gbps. The components are:

  • XS708E 10-gbps switch $840
  • Supermicro half-length 1U $331
  • 3.2 GHz quad Ivy Bridge $199
  • 32-gigs RAM $295
  • 10-gbps dual-port Intel NIC $190

Wednesday, April 08, 2015

Stop making the NSA the bogeyman of privacy

Snowden is my hero, but here's the thing: the NSA is the least of our worries. Firstly, their attention is foreign, not domestic. Secondly, they are relatively uncorrupt. Our attention should be focused on the corrupt domestic law-enforcement agencies, like the ATF, DEA, and FBI.

I mention this because a lot of people seem concerned that the "cyber threat sharing" bills in congress (CISA/CISPA) will divulge private information to the NSA. This is nonsense. The issue is private information exposed to the FBI and other domestic agencies. It's the FBI, ATF, or DEA that will come break down your door and arrest you, not the NSA.

We see that recently where the DEA (Drug Enforcement Administration) has been caught slurping up international phone records going back to the 1990s. This appears as bad as the NSA phone records program that started the Snowden disclosures.

I know the FBI is corrupt because I've experienced it personally, when they threatened me in order to suppress a conference talk. We know they are corrupt in the way they hide cellphone interception devices ("stingray") from public disclosure. We know they are corrupt because their headquarters is named after J Edgar Hoover, the notoriously corrupt head of the FBI during much of the last century. 

For all that the FBI is horrid, the DEA and the ATF are worse. These are truly scary police-state style agencies which we allow operate only because their focus is so narrow. Every gun store owner I know has stories of obviously dodgy characters trying to buy guns who they are certain are actually ATF agents doing "sting" operations. One of the many disturbing elements of the "fast and furious" ATF scandal is how they strong-armed gun store owners into complying.

In any case, even if you hate the NSA the most, the NSA's frightening ability to monitor everything outside the United States means they probably don't need the domestic "cyber threat information".

My point is this: stop making the NSA the bogeyman of privacy. Domestic agencies, namely the FBI, are a far greater danger.

Tuesday, April 07, 2015

No, 75% are not vulnerable to Heartbleed

A little-known company "Venafi" is suddenly in the news implying 75% of major systems are still vulnerable to Heartbleed. This deserves a rating of "liar liar pants on fire".

The issue isn't patches but certificates. Systems are patched, but while they were still vulnerable to Heartbleed, hackers may have stolen the certificates. Therefore, the certificates need to be replaced. Not everyone has replaced their certificates, and those that have may have done so incorrectly (using the same keys, not revoking previous).

Thus, what the report is saying is that 75% haven't properly updated their certificates correctly. Naturally, they sell a solution for that problem.

However, even this claim isn't accurate. Only a small percentage of systems were vulnerable to Heartbleed in the first place, and it's hard to say which certificates actually needed to be replaced.

That's why you have the weasely marketing language above. It's not saying 3 out of 4 of all systems, but only those that were vulnerable to begin with (a minority). They aren't saying they are still vulnerable to Heartbleed itself, but only that they are vulnerable to breach -- due to the certificates having been stolen.

The entire report is so full of this same language that I cannot figure out what they are claiming to any technical detail.

The fact is this: most companies patched their systems before their certificates were stolen. For those who did get certificates stolen, it's unlikely that their servers can be breached with that information. Sure, some user accounts may get compromised by hackers doing man-in-the-middle at Starbucks, but the servers themselves are safe. Even if you did everything wrong updating your certificates, you probably aren't in danger. Sure, some of you are, but most of you aren't.

All such glossy marketing PDFs are full of FUD, this one worse than most. I give it a "liar liar pants on fire" rating.

Friday, April 03, 2015

The .onion address

A draft RFC for Tor's .onion address is finally being written. This is a proper thing. Like the old days of the Internet, people just did things, then documented them later. Tor's .onion addresses have been in use for quite a while (I just setup another one yesterday). It's time that we documented this for the rest of the community, to forestall problems like somebody registering .onion as a DNS TLD.

One quibble I have with the document is section 2.1, which says:

1. Users: human users are expected to recognize .onion names as having different security properties, and also being only available through software that is aware of onion addresses.

This certain documents current usage, where Tor is a special system run separately from the rest of the Internet. However, it appears to deny a hypothetical future were Tor is more integrated.

For example, imagine a world where Chrome simply integrates Tor libraries, and that whenever anybody clicks on an .onion link, that it automatically activates the Tor software, establishes a circuit, and grabs the indicated page -- all without the user having to be aware of Tor. This could do much to increase the usability of the software.

Unfortunately, this has security risks. An .onion web page with a non-onion <IMG> tag would totally unmask the user, which would presumably not go over Tor in this scenario. One could imagine, therefore, that it would operate like Chrome's "Incognito" mode does today. In such a scenario, no cookies or other information should cross the boundary. In addition, any link followed from the .onion page should be enforced to also go over Tor. Like Chrome's little spy guy icon on the window, it would be good to have something onion shaped identifying the window.

Therefore, I suggest some text like the following:
1b. Some systems may desire to integrate .onion addresses transparently. An example would be web browsers allowing such addresses to be used like any other hyperlinks. Such system MUST nonetheless maintain the anonymity guarantee of Tor, with visual indicators, and blocking the sharing of identifying data between the two modes.

The Tor Project opposes transparent integration into browsers. They've probably put a lot of thought into this, and are the experts, so I'd defer to them. With that said, we should bend over backwards to make security, privacy, and anonymity an invisible part of all normal products.