The Gravity Well

Every particle, even dark matter, can bend spacetime.

Part of the reason policymakers are often confused about resistance to many of the items on their wishlist in the cyber domain is that they've already achieved the impossible: Copyright!

If you think about how amazing it is that nowhere on the Internet can you go get Avengers: Infinity Wars for free then it leads you to also ponder the vast array of international agreements, corporate pressure, and technological filtering that makes this possible. Nothing could be more inimical to the nature of the cyber domain than copyright. And yet: governments and industry have made it real.

To paraphrase Bruce, "Bits being copied is like water being wet" - and yet we have somehow made it so in cyberspace all waterfalls all run upwards, to make it possible to remove a single picture of Star Wars from the Internet. Why then, policy people ask, can we not just erase all information about computer exploitation and harmful code from the Internet? How much harder can it be?

Allan Friedman once said to me that he looks at his work at the Commerce Dept as correcting market failures. But the real market distortion is like a massive gravity well all around us. Copyright is what makes it so that a firewall vendor can hide the true nature of their weaknesses by making it illegal to write up a "performance comparisons" or "reverse engineer" their protocols. So many of the systemic vulnerabilities come from a system of our own making. And when we try to address them at the edges by regulating IOT device security or going on and on about vulnerability disclosure or revising the CFAA to add just one more exception it's like trying to chew away a piece of a black hole.

This post is a call for legislation more than my other posts are: We need to address the root of the problem. That means changing what an end-user-license can restrict. It is not just that everyone should be able to write about and patch the code running on their devices, but that we need to acknowledge that copyright has distorted who can even understand the depths of the risks we all face.

---
Links/Resources:

• We're the Saudi Arabia of Copyright
• The Vivid Dream

The Dark Gulf between the FBI and the Technical Community

https://oig.justice.gov/reports/2018/o1803.pdf

I think it's important that we acknowledge and address that each side in the encryption debate does not believe so much that the other side is wrong, but that they are lying liers who will stop at nothing to get their way.

In particular, the contrast between Susan Hennessey/Stewart Baker's take on the FBI documents that got released about the iPhone unlocking debacle and the Risky.biz (and technical community) take are quite telling.

Risky.Biz, when speaking to their audience, essentially assumed that the FBI, while not misleading the court in words, knew that it could have reached out to the contractor base for potential solutions to unlocking Farook's iPhone, and that not doing so was highly dishonest when presenting that there were "no other solutions" other than the nuclear option of forcing Apple to build decryption capability for the FBI.

Susan Hennessey (and others in the national security space) take the FBI at their word: No misleading statements went to the court and "not having the capability in our hands right now" is enough to move forward with the legal case. "Perhaps there is some stovepiping issue but nothing even slightly duplicitous" we hear from that side. "If you only read the whole report, then you'll see!"

Here's what you see when you read the whole report: There are fig leaves of truth covering the massively weird idea that in the highest profile case in the country the FBI didn't ask the head of the ROU to have a contractor maybe look into the problem. It's literally unbelievable. "Oh, I thought we could only work on classified issues" is what's in the report, as if these teams don't have each other's cell phone numbers.

This is a damning two paragraphs in the report and it validates what the technical community thinks of the FBI.

You see the same dynamic with the Ray Ozzie cryptographic proposal. The national security teams that believe the technical community isn't being straightforward about how possible it is to build secure key escrow when clearly public key encryption exists don't believe they are wrong, they simply believe the technical community knows perfectly well how to build PKI and just won't for political reasons.

Matt Green points out the the issue is not "Can we build PKI?" but "Do we want to have companies forced to build PKI and assume the essentially unbounded liability of maintaining it?". Keep in mind, tech people have watched every PKI system they've built over the past 20 years fail in some way and companies have no desire to hold or control any data beyond that which gets them ad revenue.

Of course, Stewart Baker would then say "Unless the Chinese want it, in which case everyone seems to RUSH to find a solution". The technical community, in turn, says "But the USG is supposed to be our friends."

I'm not saying the technical community is right about these issues, although they clearly are: The FBI lied in all but words, and the "going dark" debate is insane when we can identify serial killers from their great grandparent's DNA.

But even if the FBI was right, we have to look strategically at what it means in every dimension of this debate when the US technical community and the FBI both don't trust each other even a tiny bit. Without solving this, how can we move forward on any part of the massive problems we face? How do you have public private partnerships without trust? How do you build cyber war norms? Infragard can only go so far...

Stealing the Socket for Policy and Profit

One exploit that has fascinated me for more than a couple of years is this one by Yuange of NSFOCUS. When I mentioned this on Twitter, Yuange himself pointed me at this paper, where he describes a bit of his technique and his philosophy. A few things stick out from this exploit:

The first, is he was ahead of his time in adopting the PE parsing technique for writing portable Windows shellcode. He also had a uniquely Chinese style of writing the entire exploit in C, and having the shellcode just "compiled" instead of hand written. Thirdly, he used an entirely new and innovative method of stealing the socket on IIS by using the built in ISAPI handler calls. Fourthly, he built in a micro-backdoor to his exploit shellcode.

I want to highlight the third thing - the socket stealing. But first, I want to look at the work of another well known hacker group: LSD-PL. I can't remember now if their Windows Asmcode paper was the first public example of the PE-parsing technique for Windows shellcode. I remember Oded Horowitz worked in that area before it was public (and also wrote a special purpose linker for Windows which allowed you to write your shellcode in C using Visual Studio).

LSD used a specific technique for their FindSck Asmcode which looks almost exactly like their Unix version. I'll paste it below since a significant portion of the policy community is learning hacker assembly now.

Page 22 of this presentation has the decompilation of this.

In this case they go through every FD from 0 to 0xffff and call getpeername() on it. Then they see if the source port is the one they hardcoded into the shellcode at runtime to look for.

However, compare that technique to the first GOCode in Apache Nosejob from hacker comedy group Gobbles. Apache Nosejob was the second version of Apache-scalp, which exploited an "impossible" bug released by IIS XForce researcher Mark Dowd.

As you can see it's called "GOCode" because on the remote side, the shellcode is going through its FDs and sending "G" to them and the exploit responds to that G with an O as a simple handshake. This technique is obviously noisier (every socket gets a G, like in some weird Oprah show!) but more resilient against certain kinds of networking environments (aka NAT).

But why are all these somewhat contemporary techniques so different? And why even invest this kind of time and energy in stealing sockets?

Here's what Yuange has to say:

And here is what LSD has to say about that same thing:

One key point from the LSD-pl Windows slides is that they implemented a mini-backdoor in assembly partially to solve the problem all Unix hackers had moving to Windows before Powershell was included by default - the OS feels lobotomized.

Shellcode is called "Shellcode" because a Unix shell is a full-featured programming environment. There are thousands of ways to transfer files from point A to point B given shell access to a 1990's Unix system. This is not nearly as easy on Windows 2000. But LSD and Yuange both realized that the path of least resistance on Windows was to build file transfer into your stage-1 assembly code rather than trying to script up a debug.com wrapper.

Yuange's IIS exploit doesn't "pop cmd.exe" - it has this mini-shell for the operator to use.

So now let's go back to the Yuange exploit and talk about the ISAPI-stealing code as if you are 22yo me, puzzling over it. The first thing he does is set an exception handler for all access violations, and then he walks up the stack, testing for a possible EXTENSION_CONTROL_BLOCK.

The ECB has a set size (0x90), which it stores as the first DWORD and then the connID field at ecb+8 will always point...right back at the ECB! Once he has found the ECB he now has a connID and the addresses (stored in the ECB) for function pointers to the ReadClient() and WriteClient() that IIS provides every ISAPI.

This means his exploit is going to steal the socket reliably, no matter what ISAPI he targets, and whether or not it is In_Proc or Out_Proc, using SSL or not, even if he is behind several layers of middleware and firewalls and proxies of various sorts. In that sense it is BETTER and more generic than the LSD-PL and GOCode styles for this particular problem set (IIS Exploits).

Generic shellcode platforms are often derided for not being worth the effort by penetration testers, but I hope by reading this article you have now gained the foresight to see that for real work, by skilled but small teams who cannot afford a room of Raytheon engineers to architect bespoke solutions to every exploit and operation's microclimate, this became a necessary investment. Kostya summed up a lot of Immunity experience with this in a BlackHat talk.

Generally further in time from left to right.

If you're completely non-technical, then the goal of this kind of analysis is difficult to understand, but we wanted to point out that real teams consider their exploit only done when it "Works in the wild" and socket-stealing and post-exploit data transfer is a big part of that. Likewise, there are many ways to solve these problems, and different teams chose different ways which speak in interesting patterns. Historically, the people who were developing these techniques have moved on into interesting places (Yuange is at Tencent I hear) and if you were not impressed with them in 2001, you may not truly understand the modern landscape.

There was a purpose to hacking in the 2000's beyond getting on stage somewhere. The early hacker groups were run by strong philosophies. Mendez is not the only hacker who had a political bent driven by a strong-world view. What and/or who was the AntiSec movement, for example? You can't spend all of your spare time obsessively reading secrets without being changed and those twists are evident in modern geopolitics as clearly as glacial troughs, if you have the right eyes for it.

Some CrazyPants ideas for handling Kaspersky

These pants make more sense than some of the ideas posted for handling Kaspersky

So the benefit of being a nation-state, and the hegemon of course, is that you can pretty much do whatever you want. I refer, of course, to last week's LawFare post on policy options for Kaspersky Labs. The point of the piece, written by a respected and experienced policy person, Andrew Grotto, is that the US has many policy options when dealing with the risk Kaspersky and similar companies pose to US National Security. Complications include private ownership of critical infrastructure, the nature of cyberspace, and of course ongoing confusion as to the whether we have punitive or palliative aims in the first place. Another complication is how crazypants all the suggestions are.

He lists six options, the first two dealing with "Critical Infrastructure" where the Government has direct regulatory levers and Kaspersky has a zero percent market share already and always will. The third one is so insane, so utterly bonkers, that I laughed out-loud when reading it. It is this:

Ok, so keep in mind that "deemed export" is an area of considerable debate in the US Export Control community, and not something any other country does. While yes, applying the BIS Export Control rule in this case would immediately cause every company that does business in the United States to rush to uninstall KAV, this is not where the story would end.

Instead, we would have a deep philosophical discussion (i.e. Commerce Dept people being hauled in front of Congress) - because for sure not everyone who works at Azure, every backup provider in the world, or literally any software company, is a US Citizen. Because while Kaspersky has deep and broad covert access to the machines they are installed on, they are not the only ones.

We currently interpret these rules extremely laxly, for good reason.

The next suggestion in the piece is adding Kaspersky to the Entities list - essentially blacklisting them without giving a reason. Even ZTE did not get this treatment and while they paid a fine and are working their way back to good graces if possible, this was highly defensible. I mean, in these cases what about the thousands of US businesses that already have Kaspersky installed? The follow-on effects are massive and the piece ends up recommending against it, since the case against Kaspersky, while logical, is possibly not universally persuasive as a death sentence without further evidence?

Tool number 5 is the FTC doing legal claims against Kaspersky for "unfair or deceptive acts or practices" in particular, for pulling back to the cloud files that are innocuous. Kaspersky's easy defense is going to be "We don't know they are innocuous until we pull them back and analyze them, we make it clear this is what we do, we are hardly the only company to do so, for example see this article." I.E. the idea of FTC legal claims is not a good one and they know it.

The last "Policy Tool" is Treasury Sanctions. Of course we can do this but I assume we would have to blow some pretty specific intel sources and methods to do so.

Ok, so none of the ideas for policy toolkit options are workable, obviously. And as Andrew is hardly new at this, I personally would suggest that this piece came out as a message of some kind. I'm not sure WHAT the message is, or who it is for, but I end with this image to suggest that just because you CAN do something doesn't mean it is a good idea.

What happens if the Russians get false flag right?

There's a lot of interesting and unsolved policy work to be done in the Russian hack of the 2018 Olympics. Some things that stuck out at me was the use of Router techniques, their choice of targeting, and of course, the attempt at false flagging the operation to the North Koreans. I mean, it's always possible the North Koreans, not shabby at this themselves, rode in behind the Russians or sat next to Russian implants, and did their own operation.

There's a lot of ways for this sort of thing to go wrong. Imagine if there had been a simple bug in the router implants, which had caused them to become bricked? Or imagine if the Russians had gotten their technical false flag efforts perfect, and we did a positive attribution to North Korea, or could not properly attribute it at all, but still assumed it was North Korea?

Or what if instead of choosing North Korea, they had chosen Japan, China, or the US or her allies?

What if a more subtle false flag attempt smeared not just a country, but a particular individual, who was then charged criminally, which is the precedent we appear to want to set?

I don't think anyone in the policy community is confident that we have a way to handle any of these kinds of issues. We would rely, I assume, on our standard diplomatic process, which would be both slow, unused to the particulars of the cyber domain, and fraught with risks.

It's not that this issue has not been examined, as Allen points out, Herb Lin has talked about it. But we don't have even the glimmers of a policy solution. We have so much policy focus on vulnerability disclosure (driven by what Silicon Valley thinks) but I have seen nothing yet on "At what point will we admit to an operation publicly, and contribute to cleanup"?  or "How do we prove that an operation is not us or one of our allies to the public". In particular I think it is important that these issues are not Government to Government issues necessarily.

---
Resources:

• Herb Lin: LINK
• Technical Watermarking of Implants Proposal: LINK

The UK Response to the Nerve Agent Attack

Not only do I think the UK should response with a cyber attack, I think they will do so in short order.

It's easy to underestimate the brits because they're constantly drinking tea and complaining about the lorries but the same team that will change an Al Qaeda magazine to cupcake recipes will turn your power off to make a point

The Russians have changed their tune entirely today, now asking for a "joint investigation" and not crowing about how the target was an MI6 spy and traitor to the motherland killed as a warning to other traitors (except on Russian TV). I don't think the Brits will buy it. As Matt Tait says in his Lawfare piece, this is the Brits talking at maximum volume, using terminology that gives them ample legal cover for an in-kind military response. Ashley Deeks further points out the subtleties of the international law terminology May chose to use and how it affects potential responses.

For something like this, sanctions go without saying, but I don't think that ends the toolbox. The US often also does indictments, but that's more message sending than impactful sometimes. The UK could pressure Russia on the ground in many places (by supporting Ukraine, perhaps?) but that takes a long time and is somewhat risky. Cyber is a much more attractive option for many reasons, which I will put below in an annoying bullet list.

• Cyber is direct
• Cyber can be made overt with a tweet or a sharply worded message
• GCHQ (and her allies) are no doubt extremely well positioned within Russian infrastructure (as was pointed out in this documentary) so operational lag could be minimized or negligable
• Cyber can be made to be discriminatory and proportional
• Cyber can be reversible or not as desired
• Sending this message through cyber provides a future deterrent and capabilities announcement

That answers why the Brits SHOULD use cyber for this. But we think they will, because they've sent that as a signal via the BBC and the Russians heard it loud and clear.

Why Hospitals are Valid Targets for Cyber

Tallinn 2.0 screenshot that demonstrates which subject lines are valid in spam and which are not. This page has my vote for "Most hilarious page in Tallinn 2.0". CYBER BOOBY TRAPS! It's this kind of thing that makes "Law by analogy" useless, in my opinion.

So often because CNE and CNA are really only a few keystrokes away ("rm -rf /", for example), people want to say "Hospitals" are not valid targets for CNE, or "power plants" are not valid targets for CNE, or any number of things they've labeled as critical for various purposes.

But the reason you hack a hospital is not to booby trap an MRI machine, but because massive databases of ground truth are extremely valuable. If I have the list of everyone born in Tehran's hospitals for the last fifty years, and they try to run an intelligence officer with a fake name and legend through Immigration, it's going to stand out like a sore thumb.

The same thing is true with hacking United. Not only are the records in and out of Dulles airport extremely valuable for finding people who have worked with the local federal contractors but doing large scale analysis of traffic amounts lets you guesstimate at budget levels and even figure out covert program subjects. People look at OPM and they see only the first order of approximation of the value of that kind of large database. Who cares about the clearance info if you can derive greater things from it?

The Bumble and Tinder databases would be just as useful. If you are chatting with a girl overseas, and she says she doesn't have a Bumble/Tinder account, and you're in the national security field, you're straight up talking to an intelligence officer. And it's hard to fake a profile with a normal size list of matches and conversations... 

And, of course, hacking critical infrastructure and associated Things of the Internet allows for MASINT, even on completely civilian infrastructure. People always underestimate MASINT for some reason. It's not sexy to count things over long periods of time, I guess.

Also, it's a sort of hacker truism that eventually all networks are connected so sometimes you hack things that seem nonsensical to probe for ways into networks that are otherwise heavily monitored.

I highly recommend this book. Sociology is turning into a real science right before our eyes...as is intelligence.

SIGINT was the original big data. But deep down all intelligence is about making accurate predictions. Getting these large databases allows for predictions at a level that surprises even seasoned intelligence people. Hopefully this blog explains why so many cyber "norms" on targeting run into the sand when they meet reality.