Concurrent Vulnerability scanning with Erlang

Background

Following the recent series of major vulnerabilities, a trend that's become popular has been the online scanner. It was far easier to test a service using and online Shellshock scanner, or an online Heartbleed scanner, or in this case, the MShttp.sys vulnerability. This scanner was inspired by this particular scanner.

Scanning larger amounts of machines has however, been historically quite slow. If any of the listed scanners simply iterated across a list of machines, it could take quite some time to run across reasonably large networks.

Concurrent scanning

That introduction is a perfect place to introduce the concurrency capabilities of Erlang. Concurrency has been a huge trend lately, mostly in relation to the (stupid) argument that argues Node.JS has concurrency and therefore it's the ony platform that can scale to handle a personal blog.

A much more powerful use of concurrency exists in this snippet of code, which I see myself using regularly.

Pid = spawn(fun() ->
        receive
        {From, execute} ->
            From ! {N, function(N)) }
        end 
    end),
Pid ! {self(), execute},

Which, in short, tells Erlang to run a particular function concurrently, and send the results back to the parent. In this example, I've written a scanner for CVE-2015-1635. By utilising this loop, I've found you can perform such a scan incredibly fast.

The time I've quoted is 200ms, which accounts for a certain amount of network latency, in scanning an entire /24 of network hosts. Without that, let's see the below:

$ time wget http://erlvulnscan.lolware.net:8080/?network=127.0.0.0 -O -

2015-06-12 10:15:48 (152 MB/s) - written to stdout [12593/12593]


real    0m0.062s
user    0m0.003s
sys     0m0.007s

Yes, that's less than one second to:

  • Make an HTTP connection to each server from 127.0.0.1 to 127.0.0.254
  • Run the vulnerability check
  • Format the results nicely in JSON and render to the user

That's an impressive time. I look forward to being told it should be done in JS.

Implementation

Source code for a complete implementation can be found here:

erlvulnscan on Github

A key design goal is to allow the project to easily forked and run new types of vulnerability scans, which I am likely to do at some point. A functional implementation can be seen here:

erlvulnscan demonstration

Although the project is scheduled for aesthetic improvements, the backend is now stable.

Design

erlvulnscan is an Erlang OTP application built using Cowboy and Jiffy, and managed by rebar.

Rather than play with Cowboy routes for static data, assets such as the front page are intended to be served using nginx, with a routing rule to forward the API.

Code is intended to be dialyzer and edoc friendly.

The frontend uses ReactJS, although at this stage it is largely a copy of the React tutorial. Starting using this base will allow it to be rapidly improved however.

TODO

In the coming weeks, the project should see the following. Hopefully in time for a new major issue to scan for. This roadmap exists here both to serve as my own roadmap, and avoid the inevitable situation where the only contact someone makes about my this page is point me in the direction of something like Grunt.

  • Properly modularise the scanner, so replacement of a single file can facilitate management of a new vulnerability
  • Fully dialyze and tidy up all warnings
  • Frontend aesthetic overhaul ~~ and implementation ~~
  • Route changes, entire project should be able to be served on one port!!
  • Frontend code overhaul. Many function names are straight out of ReactJS tutorial. JSX should be converted and minified on the backend.
  • Learn and implement EUnit
  • Implement Elvis
  • Implement Grunt for the frontend
  • Hot code load implement and test

Fuzzing nginx - Hunting vulnerabilities with afl-fuzz

No 0day here

If you were looking for it, sorry. As of 48 hours of fuzzing, I've got 0 crashes.

AFL - successful fuzzing

American Fuzzy Lop has a very impressive history of finding vulnerabilities. The trophy case is gigantic. An ELI5 of the design of the product is: Give it a program a valid input file, and it will mess with that input file until using it crashes the example program. My first attempt at using it almost immediately found a crash situation in lci - Lolcode interpreter.

Unfortunately, successful use against something which is not a command line application that runs and quits is more difficult.

Compile and build

Our first step here will be to compile afl. I'm going to assume you can already do this. When building nginx, I used the following commands:

export CC=/path/afl-clang
./configure --prefix=/path/nginxinstall --with-select_module

The use of the prefix is simple - we don't want to install this as root, as a proper service, or run it as such. The select module, I'll get back to. With nginx built and installed, there are some very helpful config options:

master_process off;
daemon off;
events {
    worker_connections  1024;
use select;
multi_accept off;

}

By starting your config file like this, nginx will helpfully avoid forking to background, and start itself at a console where it belongs.

Your first server section should look like this:

server {
    listen       <ip>:8020;
    ...
}

We do this because:

* We want the parser to decide it's happy to run as non-root
* Without specifying the IP, something doesn't bind properly in our later process.

Operate with stdin/stdout

Following the suggested build gets you halfway there, but the remaining problem is that nginx wants to take input from a network port, not from stdin. Fortunately, this project exists:

Preeny on Github

Preeny almost solves our issues. I say almost because of two things:

  • Preeny intercepts accept(), but, where it exists (my system), nginx uses accept4()
  • nginx's default polling mechanism simply doesn't recognise connections that have been redirected and never triggers the event loop

For the first of these, I wrote this patch. Given accept() and accept4() are equivalent enough for our purposes, this patch just pushes accept4() to the intercepted accept().

Update: @floyd_ch points out this patch is more correct than my original one

diff --git a/src/desock.c b/src/desock.c
index 36b3db7..4b267ef 100644
--- a/src/desock.c
+++ b/src/desock.c
@@ -209,6 +209,11 @@ int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen)
        else return original_accept(sockfd, addr, addrlen);
 }

+int accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags)
+{
+      return accept(sockfd, addr, addrlen);
+}
+
 int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
 {
        if (preeny_socket_threads_to_front[sockfd])

Again, compile as per the Preeny instructions, I won't walk you through this.

Running it

With this in place, you can run nginx from the command line, and have it take HTTP syntax from stdin.

$ LD_PRELOAD="/home/technion/attack/preeny/Linux_x86_64/desock.so "  ./nginx
--- Emulating bind on port 8020
GET / HTTP/1.0

HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Tue, 28 Apr 2015 09:18:51 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 27 Apr 2015 08:45:32 GMT
Connection: close
ETag: "553df72c-264"
Accept-Ranges: bytes

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
                width: 35em;
                       margin: 0 auto;
                               font-family: Tahoma, Verdana, Arial, sans-serif;
                               }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

This is successful.. almost. The problem you now see is that nginx never actually exits. To get around this, we had to patch nginx itself. Specifically, at line 262, I added this:

static int first_fd = 0;
    if (first_fd == 0)
            first_fd = max_fd;

    if(max_fd > first_fd) {
            printf("Exiting cleanly\n");
            exit(0);
    }

I'm sure there's a better place to patch, but this seemed to be the easiest for me to find. Specifically, when it knows it's been through the event loop once before and actually accepted a connection already, it'll log as such and exit.

Now, let's get a proper test case up and running. I created testcases/in.txt, based on a standard HTTP connection:

GET / HTTP/1.1
Acceptx: text/html, application/xhtml+xml, */*
Accept-Language:en-AU
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: lolware.net
DNT: 1
Connection: Keep-Alive
Cookie: A=regregergeg

Now let's execute it and see how that looks:

$ LD_PRELOAD="/patch/preeny/Linux_x86_64/desock.so "  ./nginx < testcases/in.txt
--- Emulating bind on port 8020
HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Tue, 28 Apr 2015 09:43:26 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 27 Apr 2015 08:45:32 GMT
Connection: keep-alive
ETag: "553df72c-264"
Accept-Ranges: bytes

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
Exiting cleanly
$

That right there is perfect. It takes the input file from stdin, and passes it to nginx, outputs the HTML web content, then quits.

Now all that's neccessary is to run it under afl-fuzz:

$ LD_PRELOAD="/home/technion/attack/preeny/Linux_x86_64/desock.so " /home/technion/afl-1.61b/afl-fuzz -i testcases -o findings ./nginx

Now hang on, this'll run for a while.

nginx - Built against LibreSSL

CentOS

For some time, I've been managing a CentOS RPM of LibreSSL built against nginx. You can still get that at the below link if you're interested, but as of April 2015, I've moved to Arch as my preferred OS.

Nginx LibreSSL RPM Source

Nginx built against LibreSSL

I don't currently recommend, unless you are running OpenBSD, using LibreSSL. There are too many untested applications. Testing nginx, is something I wanted to take on.

Regardless of whether you want to use by build or anything else, the fact remains: This page used to contain a set of instructions regarding how to patch up nginx and get it running with LibreSSL. At the present time, due both to smarter integration on the nginx side, and compatibility patches I've submitted to LibreSSL, things currently "just work".

Linking nginx against LibreSSL gives you a very reliable method of implementing Chacha20/Poly1305 cipher in nginx. I've been using this string:

    ssl_ciphers "ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-CHACHA20-POLY1305 EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA  !aNULL !eNULL !LOW ! 3DES !MD5 !EXP !PSK !SRP !DSS !RC4";

This gives A+ on the SSL labs test, and negotiates with Chacha20 when possible.

The move to Arch

A reasonably high component of my contribution to the open source community has related to identifying compatibility issues with current versions of CentOS. I didn't ask for that. I just wanted to try these applications, and found I couldn't. After spending a solid three hours with oclint, I'd had enough and made a platform move.

One of the great things about this is I can submit my build to the AUR without it being a big deal.

Get it here