Friday, August 18, 2017

Announcement: IPS code

So after 20 years, IBM is killing off my BlackICE code created in April 1998. So it's time that I rewrite it.

BlackICE was the first "inline" intrusion-detection system, aka. an "intrusion prevention system" or IPS. ISS purchased my company in 2001 and replaced their RealSecure engine with it, and later renamed it Proventia. Then IBM purchased ISS in 2006. Now, they are formally canceling the project and moving customers onto Cisco's products, which are based on Snort.

So now is a good time to write a replacement. The reason is that BlackICE worked fundamentally differently than Snort, using protocol analysis rather than pattern-matching. In this way, it worked more like Bro than Snort. The biggest benefit of protocol-analysis is speed, making it many times faster than Snort. The second benefit is better detection ability, as I describe in this post on Heartbleed.

So my plan is to create a new project. I'll be checking in the starter bits into GitHub starting a couple weeks from now. I need to figure out a new name for the project, so I don't have to rip off a name from William Gibson like I did last time :).

Some notes:

  • Yes, it'll be GNU open source. I'm a capitalist, so I'll earn money like snort/nmap dual-licensing it, charging companies who don't want to open-source their addons. All capitalists GNU license their code.
  • C, not Rust. Sorry, I'm going for extreme scalability. We'll re-visit this decision later when looking at building protocol parsers.
  • It'll be 95% compatible with Snort signatures. Their language definition leaves so much ambiguous it'll be hard to be 100% compatible.
  • It'll support Snort output as well, though really, Snort's events suck.
  • Protocol parsers in Lua, so you can use it as a replacement for Bro, writing parsers to extract data you are interested in.
  • Protocol state machine parsers in C, like you see in my Masscan project for X.509.
  • First version IDS only. These days, "inline" means also being able to MitM the SSL stack, so I'm gong to have to think harder on that.
  • Mutli-core worker threads off PF_RING/DPDK/netmap receive queues. Should handle 10gbps, tracking 10 million concurrent connections, with quad-core CPU.
So if you want to contribute to the project, here's what I need:
  • Requirements from people who work daily with IDS/IPS today. I need you to write up what your products do well that you really like. I need to you write up what they suck at that needs to be fixed. These need to be in some detail.
  • Testing environment to play with. This means having a small server plugged into a real-world link running at a minimum of several gigabits-per-second available for the next year. I'll sign NDAs related to the data I might see on the network.
  • Coders. I'll be doing the basic architecture, but protocol parsers, output plugins, etc. will need work. Code will be in C and Lua for the near term. Unfortunately, since I'm going to dual-license, I'll need waivers before accepting pull requests.
Anyway, follow me on Twitter @erratarob if you want to contribute.





Tuesday, August 15, 2017

Why that "file-copy" forensics of DNC hack is wrong

People keep asking me about this story about how forensics "experts" have found proof the DNC hack was an inside job, because files were copied at 22-megabytes-per-second, faster than is reasonable for Internet connections.

This story is bogus.

Sunday, August 06, 2017

Query name minimization

One new thing you need to add your DNS security policies is "query name minimizations" (RFC 7816). I thought I'd mention it since many haven't heard about it.

Right now, when DNS resolvers lookup a name like "www.example.com.", they send the entire name to the root server (like a.root-servers.net.). When it gets back the answer to the .com DNS server a.gtld-servers.net), it then resends the full "www.example.com" query to that server.

This is obviously unnecessary. The first query should be just .com. to the root server, then example.com. to the next server -- the minimal amount needed for each query, not the full query.

The reason this is important is that everyone is listening in on root name server queries. Universities and independent researchers do this to maintain the DNS system, and to track malware. Security companies do this also to track malware, bots, command-and-control channels, and so forth. The world's biggest spy agencies do this in order just to spy on people. Minimizing your queries prevents them from spying on you.

An example where this is important is that story of lookups from AlfaBank in Russia for "mail1.trump-emails.com". Whatever you think of Trump, this was an improper invasion of privacy, where DNS researchers misused their privileged access in order to pursue their anti-Trump political agenda. If AlfaBank had used query name minimization, none of this would have happened.

It's also critical for not exposing internal resources. Even when you do "split DNS", when the .com record expires, you resolver will still forward the internal DNS record to the outside world. All those Russian hackers can map out the internal names of your network simply by eavesdropping on root server queries.

Servers that support this are Knot resolver and Unbound 1.5.7+ and possibly others. It's a relatively new standard, so it make take a while for other DNS servers to support this.





Monday, July 31, 2017

Top 10 Most Obvious Hacks of All Time (v0.9)

For teaching hacking/cybersecurity, I thought I'd create of the most obvious hacks of all time. Not the best hacks, the most sophisticated hacks, or the hacks with the biggest impact, but the most obvious hacks -- ones that even the least knowledgeable among us should be able to understand. Below I propose some hacks that fit this bill, though in no particular order.

The reason I'm writing this is that my niece wants me to teach her some hacking. I thought I'd start with the obvious stuff first.

Saturday, July 29, 2017

Is DefCon Wifi safe?

DEF CON is the largest U.S. hacker conference that takes place every summer in Las Vegas. It offers WiFi service. Is it safe?

Probably.

The trick is that you need to download the certificate from https://wifireg.defcon.org and import it into your computer. They have instructions for all your various operating systems. For macOS, it was as simple as downloading "dc25.mobileconfig" and importing it.

I haven't validated the DefCon team did the right thing for all platforms, but I know that safety is possible. If a hacker could easily hack into arbitrary WiFi, then equipment vendors would fix it. Corporations widely use WiFi -- they couldn't do this if it weren't safe.

The first step in safety is encryption, obviously. WPA does encryption well, you you are good there.

The second step is authentication -- proving that the access-point is who it says it is. Otherwise, somebody could setup their own access-point claiming to be "DefCon", and you'd happily connect to it. Encrypted connect to the evil access-point doesn't help you. This is what the certificate you download does -- you import it into your system, so that you'll trust only the "DefCon" access-point that has the private key.

That's not to say you are completely safe. There's a known vulnerability for the Broadcom WiFi chip imbedded in many devices, including iPhone and Android phones. If you have one of these devices, you should either upgrade your software with a fix or disable WiFi.

There may also be unknown vulnerabilities in WiFi stacks. the Broadcom bug shows that after a couple decades, we still haven't solved the problem of simple buffer overflows in WiFi stacks/drivers. Thus, some hacker may have an unknown 0day vulnerability they are using to hack you.

Of course, this can apply to any WiFi usage anywhere. Frankly, if I had such an 0day, I wouldn't use it at DefCon. Along with black-hat hackers DefCon is full of white-hat researchers monitoring the WiFi -- looking for hackers using exploits. They are likely to discover the 0day and report it. Thus, I'd rather use such 0-days in international airpots, catching business types, getting into their company secrets. Or, targeting government types.

So it's impossible to guarantee any security. But what the DefCon network team bas done looks right, the same sort of thing corporations do to secure themselves, so you are probably secure.

On the other hand, don't use "DefCon-Open" -- not only is it insecure, there are explicitly a ton of hackers spying on it at the "Wall of Sheep" to point out the "sheep" who don't secure their passwords.



Wednesday, July 26, 2017

Slowloris all the things

At DEFCON, some researchers are going to announce a Slowloris-type exploit for SMB -- SMBloris. I thought I'd write up some comments.

Sunday, July 23, 2017

Defending anti-netneutrality arguments

Last week, activists proclaimed a "NetNeutrality Day", trying to convince the FCC to regulate NetNeutrality. As a libertarian, I tweeted many reasons why NetNeutrality is stupid. NetNeutrality is exactly the sort of government regulation Libertarians hate most. Somebody tweeted the following challenge, which I thought I'd address here.


The links point to two separate cases.
  • the Comcast BitTorrent throttling case
  • a lawsuit against Time Warning for poor service
The tone of the tweet suggests that my anti-NetNeutrality stance cannot be defended in light of these cases. But of course this is wrong. The short answers are:

  • the Comcast BitTorrent throttling benefits customers
  • poor service has nothing to do with NetNeutrality

The long answers are below.