Saturday, August 10, 2019

Hacker Jeopardy, Wrong Answers Only Edition

Among the evening entertainments at DEF CON is "Hacker Jeopardy", like the TV show Jeopardy, but with hacking tech/culture questions. In today's blog post, we are going to play the "Wrong Answers Only" version, in which I die upon the hill defending the wrong answer.

The problem posed is:
YOU'LL LIKELY SHAKE YOUR HEAD WHEN YOU SEE TELNET AVAILABLE, NORMALLY SEEN ON THIS PORT
Apparently, people gave 21, 22, and 25 as the responses. The correct response, according to RFC assignments of well-known ports, is 23.

But the real correct response is port 21. The problem posed wasn't about which port was assigned to Telnet (port 23), but what you normally see these days. 

Sunday, August 04, 2019

Securing devices for DEFCON

There's been much debate whether you should get burner devices for hacking conventions like DEF CON (phones or laptops). A better discussion would be to list those things you should do to secure yourself before going, just in case.

These are the things I worry about:
  • backup before you go
  • update before you go
  • correctly locking your devices with full disk encryption
  • correctly configuring WiFi
  • Bluetooth devices
  • Mobile phone vs. Stingrays
  • USB

Sunday, July 28, 2019

Why we fight for crypto

This last week, the Attorney General William Barr called for crypto backdoors. His speech is a fair summary of law-enforcement's side of the argument. In this post, I'm going to address many of his arguments.

The tl;dr version of this blog post is this:

  • Their claims of mounting crime are unsubstantiated, based on emotional anecdotes rather than statistics. We live in a Golden Age of Surveillance where, if any balancing is to be done in the privacy vs. security tradeoff, it should be in favor of more privacy.
  • But we aren't talking about tradeoff with privacy, but other rights. In particular, it's every much as important to protect the rights of political dissidents to keep some communications private (encryption) as it is to allow them to make other communications public (free speech). In addition, there is no solution to their "going dark" problem that doesn't restrict the freedom to run arbitrary software of the user's choice on their computers/phones.
  • Thirdly, there is the problem of technical feasibility. We don't know how to make backdoors available for law enforcement access that doesn't enormously reduce security for users.

Friday, June 14, 2019

Censorship vs. the memes

The most annoying thing in any conversation is when people drop a meme bomb, some simple concept they've heard elsewhere in a nice package that they really haven't thought through, which takes time and nuance to rebut. These memes are often bankrupt of any meaning.

When discussing censorship, which is wildly popular these days, people keep repeating these same memes to justify it:
  • you can't yell fire in a crowded movie theater
  • but this speech is harmful
  • Karl Popper's Paradox of Tolerance
  • censorship/free-speech don't apply to private organizations
  • Twitter blocks and free speech
This post takes some time to discuss these memes, so I can refer back to it later, instead of repeating the argument every time some new person repeats the same old meme.

Friday, May 31, 2019

Wednesday, May 29, 2019

Your threat model is wrong

Several subjects have come up with the past week that all come down to the same thing: your threat model is wrong. Instead of addressing the the threat that exists, you've morphed the threat into something else that you'd rather deal with, or which is easier to understand.

Tuesday, May 28, 2019

Almost One Million Vulnerable to BlueKeep Vuln (CVE-2019-0708)

Microsoft announced a vulnerability in it's "Remote Desktop" product that can lead to robust, wormable exploits. I scanned the Internet to assess the danger. I find nearly 1-million devices on the public Internet that are vulnerable to the bug. That means when the worm hits, it'll likely compromise those million devices. This will likely lead to an event as damaging as WannaCry and notPetya from 2017 -- potentially worse, as hackers have since honed their skills exploiting these things for ransomware and other nastiness.

To scan the Internet, I started with masscan, my Internet-scale port scanner, looking for port 3389, the one used by Remote Desktop. This takes a couple hours, and lists all the devices running Remote Desktop -- in theory.

This returned 7,629,102 results (over 7-million). However, there is a lot of junk out there that'll respond on this port. Only about half are actually Remote Desktop.

Masscan only finds the open ports, but is not complex enough to check for the vulnerability. Remote Desktop is a complicated protocol. A project was posted that could connect to an address and test it, to see if it was patched or vulnerable. I took that project and optimized it a bit, rdpscan, then used it to scan the results from masscan. It's a thousand times slower, but it's only scanning the results from masscan instead of the entire Internet.

The table of results is as follows:

1447579  UNKNOWN - receive timeout
1414793  SAFE - Target appears patched
1294719  UNKNOWN - connection reset by peer
1235448  SAFE - CredSSP/NLA required
 923671  VULNERABLE -- got appid
 651545  UNKNOWN - FIN received
 438480  UNKNOWN - connect timeout
 105721  UNKNOWN - connect failed 9
  82836  SAFE - not RDP but HTTP
  24833  UNKNOWN - connection reset on connect
   3098  UNKNOWN - network error
   2576  UNKNOWN - connection terminated

The various UNKNOWN things fail for various reasons. A lot of them are because the protocol isn't actually Remote Desktop and respond weirdly when we try to talk Remote Desktop. A lot of others are Windows machines, sometimes vulnerable and sometimes not, but for some reason return errors sometimes.

The important results are those marked VULNERABLE. There are 923,671 vulnerable machines in this result. That means we've confirmed the vulnerability really does exist, though it's possible a small number of these are "honeypots" deliberately pretending to be vulnerable in order to monitor hacker activity on the Internet.

The next result are those marked SAFE due to probably being "pached". Actually, it doesn't necessarily mean they are patched Windows boxes. They could instead be non-Windows systems that appear the same as patched Windows boxes. But either way, they are safe from this vulnerability. There are 1,414,793 of them.

The next result to look at are those marked SAFE due to CredSSP/NLA failures, of which there are 1,235,448. This doesn't mean they are patched, but only that we can't exploit them. They require "network level authentication" first before we can talk Remote Desktop to them. That means we can't test whether they are patched or vulnerable -- but neither can the hackers. They may still be exploitable via an insider threat who knows a valid username/password, but they aren't exploitable by anonymous hackers or worms.

The next category is marked as SAFE because they aren't Remote Desktop at all, but HTTP servers. In other words, in response to our Remote Desktop request they send an HTTP response. There are 82,836 of these.

Thus, out of 7.6-million devices that respond to port 3389, we find 3.5-million that reliably talk the Remote Desktop protocol, of which 0.9-million are vulnerable, and the rest are not.

But, since a lot of those "unknowns" are due to transient network errors, then in theory I should be able to rescan them and get some more results. I did this and go the following update:


  28182  SAFE - Target appears patched
  19991  VULNERABLE -- got appid
  17560  SAFE - CredSSP/NLA required
    695  SAFE - not RDP but HTTP

A third rescan got the following results:


   9838  SAFE - Target appears patched
   7084  SAFE - CredSSP/NLA required
   6041  VULNERABLE -- got appid
   2963  UNKNOWN - network error
     45  SAFE - not RDP but HTTP

Some of these rescans are likely overcoming transient errors that preventing getting results the first time. However, others are likely ISPs with Windows machines moving around from one IP address to another, so that continued rescans are going to get distorted results rather than cleaning up the previous results.

The upshot is that these tests confirm that roughly 950,000 machines are on the public Internet that are vulnerable to this bug. Hackers are likely to figure out a robust exploit in the next month or two and cause havoc with these machines.

There are two things you should do to guard yourself. The first is to apply Microsoft's patches, including old Windows XP, Windows Vista, and Windows 7 desktops and servers. 

More importantly, for large organizations, is to fix their psexec problem that allows such things to spread via normal user networking. You may have only one old WinXP machine that's vulnerable, that you don't care if it gets infected with ransomware. But, that machine may have a Domain Admin logged in, so that when the worm breaks in, it grab those credentials and uses them to log onto the Domain Controller. Then, from the Domain Controller, the worm sends a copy of itself to all the desktop and servers in the organization, using those credentials instead of the vuln. This is what happened with notPetya: the actual vulnerability wasn't the problem, it was psexec that was the problem.

For patching systems, you have to find them on the network. My rdpscan tool mentioned above is good for scanning small networks. For large networks, you'll probably want to do the same masscan/rdpscan combination that I used to scan the entire Internet. On GitHub, rdpscan has precompiled programs that work on the command-line, but the source is there for you to compile it yourself, in case you don't trust I'm tryin to infect you with a virus.