InputOutput.io

Using cerealbox to create a colorful visualization of your TCP/UDP connections.

Inspiration

At Defcon in 2011 I attended a talk by Steve Ocepek over at Spider Labs introducing a neat little project he was working on. I recommend you watch the talk, but here’s the jist of it. Basically, he was using the Arduino with an 8×8 LED board (each coordinate having an RGB value) to visualize the current established connections on a given network interface. Each coordinate of the matrix was color-coded based on country code, so you could differentiate connections based on region. As you made an outbound connection, lights would suddenly appear on the board, indicating where you are connecting to. And when those connections dropped or you disconnected, the lights disappeared. Network monitoring was done with libpcap, and a list of the active connections were sent to the Arduino using the serial interface and a perl script he coded. He called it cerealbox. I thought it was really neat to have a display of network connections always visible, without exhausting valuable screen real estate. Not only was it really useful for network admins, it was also really pretty! I mean, who doesn’t like shiny bright LEDs? And he provided the source for it, so you could buy the boards and set this up yourself.

I’d never worked with Arduino before, but I was inspired enough by this proof of concept to at least get his demo working for myself, and maybe make a few modifications. But suiting the project to my needs required a few additional considerations.

Requirements

Continent Codes, not Country Codes

Getting the demo set up was the easy part. But the color-coding was randomized based on country code. I wanted something a bit more useful – something that I could clearly see what region a connection was coming from, rather than a randomized color. The problem is that there’s a lot of countries in the world. Like, almost 200. With so many countries, the variations of color would be too slight for me to figure out at a glance which region a connection is coming from. So I wanted to code it based on continent code instead, with higher contrast between indicators. Here’s my schema:

• Blue = Europe
• Orange = Asia
• Purple = Oceania
• Yellow = Africa
• White = South America
• Teal = North America
• Pink = Antarctica & Local
• Green = United States
• Red = Special IPs (My VPSes)

Okay, so I cheated – not each one of those is a continent. US is it’s own color, and it seems a little weird to have Antarctica grouped with local connections. But connections coming from Antarctica seemed like such an extreme edge case, and I didn’t want to give up an entire color for a continent with no permanent r. So there are those exceptions, and then red for my own VPSes.

Client-Server Architecture

One of the things I really wanted to do was be able to visualize the connections of any machine, not just the one connected to the Arduino. The original project bundled the packet sniffing and serial connection to the Arduino in one neat little perl script, but I wanted to separate the part that monitors the network connection and the part that sends it to the arduino. The former will belong to the client, and the latter to the server.

I originally considered just using the Arduino standalone, with the color shield chained directly on top of a WiFly shield, and sending network connections to a server hosted directly on the Arduino. I even modified the Colorduino library to use different pins from the WiFly. But in the end I wanted to ensure that the connection to the Arduino was secure. This would be difficult to implement with the 32k space limitations of the Uno I was working with.

Secure Transport Layer

Between the client & server, I wanted to add a secure network layer. I decided on having the client/server negotiate an SSL connection with a simple password authentication.

Python, not Perl

Not to start a religious war, but I’m more comfortable in Python, so I’d have to rewrite the network monitoring and serial communication components of the script Steve had written.

RasPi

I wanted the server to run on the Raspberry Pi. Actually this was the easiest part – with Raspbian, it was just a matter of installing pip with python 2.7 and installing everything else with pip. No assembly required!

Implementation

Client

Since the geolocation lookup happens immediately as a connection is read on the client-side, I needed to use a few geoip libraries: pygeoip to perform a lookup on the country code, and incf.countryutils to then fetch the continent code. Additionally, a packet sniffer was needed. I considered using scapy for this task, which I’ve had a lot of fun with in the past and I highly recommend as a versatile tool for python packet-slicing. However, scapy seemed a bit heavyweight for the task at hand, so I decided on pcapy for sniffing and imapacket for dissecting packets.

As packets come across the wire, we keep track of them, keeping a hash (in python parlance, a dict) of udp and tcp connections. For the TCP connections, we look for the syn + ack flags, indicating a connection is established. Conversely, a fin or rst flag indicates the connection has been severed. Since UDP packets are stateless, we immediately record that a connection is established when we see any UDP traffic. Periodically, we have a sweeper to handle timed out connections.

Once a connection is established or severed, perform a geoip lookup on the remote IP, and immediately send that data to the server via an ssl socket.

Server

The server is super simple. It just receives signals coming in over the ssl bind socket, and forwards that signal directly to the arduino. Serial communications are handled by the pyserial module. Several other standard library modules are used by both the client and the server, such as ssl and socket to instantiate a secure communication.

By the time we write to the serial interface, the message we send contains the following information: [Connection Closed or Opened],[Remote Mac Address],[Remote ipv4 IP],[Remote Port],[Country Code],[Continent Code]

Arduino

I didn’t change what Steve wrote a whole lot here, except for reading the continent code and setting the colors appropriately. I did separate out a file for IP addresses I wanted to specially highlight.

Challenges

One of the challenges I’ve had is when to determine when a timeout on a TCP connection has occurred. Some connections (for example, SSH), can stand for several hours before timing out. Others (HTTP, for example) time out very quickly. From my understanding, it’s impossible to tell from the transport layer if a connection has timed out in a given period of time. We can infer the timeout from the application layer, but it seems a bit inelegant of a solution. I have yet to find a good way of dealing with this problem. If you know of a solution, please contact me.

On the client, the sniffing of packets by pcapy is a blocking call. Sending a ctrl-c doesn’t throw a KeyboardInterrupt exception until a new packet is actually read. In order to ensure that users can kill the client immediately, I had to use the multiprocessing module and actually use a separate process to determine if a KeyboardInterrupt was issued, which killed both itself and the sniffing loop process. This seems a bit silly to me, but I’m not sure if there’s any better way to do this. Again, if you have any suggestions, let me know.

Left: cerealbox visualizing http(s) connections. Right: bittorrent traffic

Outcome

There’s still a few bugs to squash. But it works, it’s pretty, and it’s useful! Check out colorduino on my github and let me know what you think!

In a nod to the history of cryptography, the folks over at Marvel Studios included a modified replica of the Enigma Machine in one scene for the 2011 film Captain America: The First Avenger. If you don’t know, the Enigma Machine was a tool used by the German army and navy to encipher and decipher messages during WWII. The breaking of the cipher by the brilliant cryptographer Alan Turing gave the allies vital information on land movements of axis troops. In this scene, it was even used in the correct context: decrypting messages of the Nazi train system. I commend Marvel for their thoroughness on this one!

A modified replica enigma as seen in the film

An actual enigma machine from a picture I took last year at the Computer History Museum in Mountain View, CA

Swinedroid v0.20 has been released is now available on the Android Market. If you haven’t read my previous post about it, here’s the low down. Swinedroid is a remote Snort monitoring application for Android. Currently, it allows you to view server threat statistics, display the latest alerts, search alerts (by alert severity, signature name, time frame) and view alert details (including a hex dump if available). It consists of two components: the client – which runs on your Android device, and the server – which runs on the system you wish to monitor (or a third party server that can access the snort server db port). The server provides statistics requested by the client over a secure and authenticated SSL link.

Since the last (non-market) release, I’ve introduced a server threat graph (thaks to AChartEngine), alert detail breakdown, SSL authenticity negotiation, functional alert browsing, a more helpful launcher screen, and crash fixes.

Having an Android Snort monitoring application can prove handy for a variety of situations where access to web-based clients is either unavailable or inconvenient. Since this is a monitoring tool that runs natively in Android, it will also be possible to recieve notifications based on alert statistics – a feature I plan to implement at some stage. Also upcoming is alert tagging and deleting functionality, more advanced alert statistics, attacker profiling (including reverse DNS / location information), and more. If you have suggestions, please post your feedback.

Download the client app here.

Download the server here.

If you’ve ever been on the go when crisis strikes, you know how convenient it is to have a mobile application for dealing with the problems you might face. For instance, I’ve found it really convenient that there’s an application that interfaces with the API for my Virtual Private Server, Slicehost. I no longer have to fumble around with the browser trying find the page which reboots the VPS, I simply load the Slicehost application. This stores my API key, and I’m able to manage my servers in a more streamlined fashion.

It is in this spirit that I began development on Swinedroid. Swinedroid is an Android Snort monitoring and management application. In its current state it allows you to view server alert statistics, display latest alerts, and search alerts based on severity, signature name, and time frame. In the coming months, I plan to add support for viewing alert details (such as the hex dump and whois information), sorting alerts, managing alerts (e.g. tagging or deleting them), and interpreting a variety of Snort log formats.

Here’s the way it works. There are two components: the server and the client. The server runs on any machine that you want to monitor. In order for the Swinedroid server component to work, you need to have Snort installed and logging alerts to MySQL. The client you install on your Android device, and configure it to communicate with the server component. This communication is done over SSL in a secure (but not authenticated) fashion.

The project is still very much in the beginning stages, and there are exciting features to come. Everything is free and open source. I invite you to try it out, and give me your feedback.

Git Repository (Client): git://github.com/Hainish/Swinedroid.git

Git Repository (Server): git://github.com/Hainish/Swinedroid-Server.git

Client Component: http://www.inputoutput.io/files/swinedroid-client_0.10.apk

Server Component: http://www.inputoutput.io/files/swinedroid-server_0.10.tar.gz

Update:
Swinedroid has been released on the Android Market. See this post for more info.

2009’s Beating on SSL, Round One

Hot on the heels of the Microsoft Crypto API patch comes another SSL vulnerability. The last round of attacks on SSL relied on a problem with the deployment of SSL on the web, as the research of Moxie Marlinspike shows. To sum up the crucial point in their research in a nutshell: just because the x509 protocol in web certificates accepts strings such as www.paypal.com\0.thoughtcrime.org without terminating the string, that doesn’t mean your web browser will do the same. We’re able to actually create a certificate signing request (.csr) with www.paypal.com\0 as the subdomain to a domain which we genuinely control. Because of the automated nature of today’s domain (and subdomain) verification process, this will go unnoticed by most Certificate Authority signing processes. Once we get the certificate back from the CA, we’re able to pose ourselves as a man-in-the-middle. Until recently, most browsers would terminate the string at the null character, leaving “www.paypal.com” as the domain for which we’ve been authenticated. Not only is this a theoretical possibility, but Moxie has released tools for it, available at thoughtcrime.org, which are probably still quite effective for unpatched systems.

Round Two: The K.O.

Whereas the null character vulnerability was an issue with web deployment of SSL and certificate chaining, the latest flaw (released on November 5th) seems to be a severe problem with the protocol itself. While there’s been a fair degree of hype surrounding a number of supposed vulnerabilities in SSL, this seems to be the real deal. Specifically, the flaw is in SSL 3.0/ TLS 1.0 – and has something to do with inserting unverified traffic into the renegotiation process of SSL sessions. Marsh Ray of PhoneFactor discovered the vulnerability, which seems to be severe, and “In certain circumstances this flaw could be used in MITM attacks, allowing an attacker to inject attacker-chosen plain text prefix into a secure session of the victim.” The bug has been being worked on for several months, and OpenSSL has released a patch to deal with the bug in its 0.9.8l release, available at www.openssl.org. Again, this is not a problem with deployment, or (as with last year’s Debian SSL vulnerability) distribution-specific forking, it is a fundamental problem with the way SSL renegotiates sessions. Also unlike last year’s Debian vulnerability, which can be retroactively exploited, this exploit requires foreknowledge of the vulnerability and situating oneself as a man-in-the-middle. Exploits are in the wild as of this writing. Kudos to OpenSSL for releasing a patch so quickly.

Note: I was first inspired to write this post based on the great coverage of deep packet inspection by the Security Now (SN) podcast.  For more detailed information than I could ever provide, please listen to Security Now, especially episodes 149, 151, and 153.

What is deep packet inspection?

In bygone days, the role of an Internet Service Provider (ISP) had been that of a passive provider of content.  The ISP provided the necessary infrastructure to connect your computer with the larger global network of computers, the internet.  When you pay your monthly bill to the ISP, you are paying a usage charge, effectively ‘renting’ their infrastructure to get yourself on the grid.  They did not disrupt, filter, or sell your private information, and life was good.
In 1994, Congress passed the Communications Assistance for Law Enforcement Act (CALEA).  This act required all digital telecommunications carriers to enable wiretapping of their digital switches.  In 2005, CALEA was extended, at the behest of the DOJ, FBI, and DEA, to include the tapping of all ISP traffic.  Prior to this extension, the FBI had relied on court order or voluntary cooperation of individual ISPs, engaging in packet sniffing with programs such as Carnivore.  So the government spying on your net usage is nothing new.
Recently, however, a very disturbing friendship has developed between advertising agencies and ISPs.  Particularly nefarious advertising companies such as NebuAd have been approaching ISPs and offering them sums of money if they will install devices that monitor and even modify the on-the-fly communications to place ads on websites that you visit.  Earlier on, these ads were just crudely inserted JavaScript, sometimes causing a rendering error in the page.  Recently, some companies such as Phorm in Britain have gotten smarter and are using the devices they’ve bribed the ISPs into installing to monitor each and every website you visit.  This is frightening because your browsing habits reveal an enormous amount of information about the type of person you are, and in fact in many cases pinpoint exactly who you are.  So these advertising agencies are effectively logging and storing everything that you do across the web, to build a profile of you for the supposed intent of providing more targeted advertising.  Luckily, there is a way to protect yourself from these invasive policies.

Using SSH to create a secure SOCKS proxy tunnel

Note: My experience in subverting these practices is largely based in using SSH within a bash environment.  You can perform the same actions with Windows using putty as well, but the syntax is quite different, and not my area of expertise.  I suggest using the howto on this page if you are using putty.

Requirements:

• Remote shell account on a machine running an SSH server
• An SSH client
• Programs that allow you to proxy traffic with SOCKS

One very effective way to subvert deep packet inspection is to create a secure, encrypted tunnel that you send all of your traffic through.  The ISPs cannot modify the content of the packets if they are point-to-point encrypted, since they have no way of seeing what the content actually is.  The idea is to wrap the packets with encryption only so far as to get them out of the reach of your ISP, and once they arrive at a remote server that you have shell access to, that server unwraps the traffic and sends it out on its merry way.  Be sure that the remote server that you have access to is secure and trusted.  If it is not, you may effectively be opening yourself to a man-in-the-middle attack or packet sniffing.  If you have access to a remote shell, you can use SSH to create a secure SOCKS proxy on a specific port of your local machine, which forwards all traffic to the remote machine before reaching its final destination.  Simply type:

ssh -D localhost:port -f -C -q -N user@host.tld

where port is the local port you want to open.  When this command is issued for the first time, make a note of the hex fingerprint that is displayed.  If at any time in the future you get a warning stating that there is a fingerprint mismatch or that the fingerprint does not match your known_hosts file, your traffic may be being intercepted.  This fingerprint acts as verification that you are indeed opening a connection to the remote server you intend to communicate with.  Now, if you issue the command “netstat -antp” and if everything went well you will see a new local port being provided by ssh.  If under the ‘local address’ field, your output looks like the following: “127.0.0.1:port” then this port is only accessible locally.  You can now configure programs such as x-chat, pidgin, and firefox to use the ip address “127.0.0.1” with the port you have specified to enable this proxy.

Word of warning #1: What you gain in privacy on the ISP side, you may lose in anonymity on the remote server side.  For instance, if your remote server has a static IP and your ISP doesn’t, it may be easier for the websites you access to track your browsing habits over time.  One way to counter this is to have a multitude of people use this server as their primary proxy; that way there is no way of pinpointing who exactly is accessing what.

Word of warning #2: When configuring certain programs to use the SOCKS proxy, there is a potential for DNS leakage.  What this means is that even though the traffic between yourself and the remote server is encrypted, the name resolution may not be.  This may present a problem, but certain programs such as firefox allow you to ensure that there is no DNS leakage.  In firefox, browse to “about:config” and make sure the setting for “network.proxy.socks_remote_dns” is set to true.  Certain extensions of firefox such as FoxyProxy take care of this for you in their plugin settings.

Complete SSH encapsulation: the tun module

Requirements:

• Root access to a remote machine running an ssh server
• An SSH client
• The tun module installed both locally and remotely

The problem that I had with the solution in the previous section is as follows.  There are plenty of programs using my network that do not have the ability to use a SOCKS proxy.  Given the track record of the worst of the advertising companies, I wouldn’t put it past them to start intercepting and modifying all sorts of traffic, not only the traffic with the highest volume or visibility such as web traffic.  What is really needed is an all-encompassing proxy, one that just takes all outgoing and incoming traffic and sends it over that secure encrypted link.  SSH is such a wonderfully flexible and versatile program, and it has built-in support for creating a secure VPN to do just that.  The idea is to make it so that all your traffic is routed through the remote server using a secure VPN link.  This section requires a basic grasp of routing tables, kernel modules, and iptables.

So our first task is to establish the secure VPN.  To do this, both machines must have the ‘tun’ kernel module installed and loaded.  Just issue the comman

modprobe tun

on both the local and remote machines from their respective root shells.  Locally, issue the command:

ssh -w 0:0 -f -C -q -N root@host.tld

This command establishes a new network interface on both sides of the connection, tun0.  Then, type:

ifconfig tun0 10.0.0.200 pointopoint 10.0.0.100

SSH into the remote machine, and issue these commands:

ifconfig tun0 10.0.0.100 pointopoint 10.0.0.200
ping -c 3 10.0.0.200

If you get a ping response, you’ve successfully set up a secure VPN!  This is good, but in order to route your traffic through the remote machine, it must be set up to enable packet forwarding, and also to have iptables configured so that it acts as a gateway.  I’ve modified a small shell script for this purpose.  You may need to modify it further to suit your needs:

wget http://www.inputoutput.io/shareconnection.sh
chmod +x shareconnection.sh
./shareconnection.sh

Your remote server is now configured to act as a gateway.  Locally, you must now set up your routing tables to direct all traffic (except the traffic that is still needed to keep the tun0 interface alive!) through the tun0 interface.  The following commands assume that your default local gateway is a router with the ip address 192.168.0.1, and your default interface is eth0:

route add host.tld gw 192.168.0.1 eth0
route del default gw 192.168.0.1 eth0
route add default gw 10.0.0.100 tun0

And presto!  All outbound and incoming traffic is now routed through your remote machine.  Again, the same concern in the above section regarding anonymity and verification of the remote fingerprint applies in this case as well.  Since the remote server is now acting as your gateway, there is no reason to fear DNS leakage, and no programs to configure.  Now you can rest assured that your connectivity is secure from the prying eyes of the ISPs and their sneaky cohorts, the traffic-shaping advertising companies.

My next article will detail how to connect this tunneled interface with programs such as hostap and dhcpd to create a wireless access point providing an automatically proxified connection to wireless clients.

Alright, so as the topic suggests, I just finished the Offensive Security 101 exam yesterday, and oh man.  I can’t disclose much information about the test itself, but let me tell you this: it was both frustrating, exciting, and triumphant all at once.  Well, only triumphant if you pass, I suppose.  Okay, so this is the first exam I’ve taken since college, and I have to admit, I was pretty nervous for it.  Alright, you could consider my post-college sociology degree job searching a test of some kind.  *Insert inaudible mutterings about the job market here.*

OS101 is unique in its field: it teaches you about software security holes from the perspective of the attacker.  It explains common vulnerabilities in network security, and the attack vectors involved in exploiting them.  It also teaches, among other things, enumeration techniques, Google h4x, and tunneling services through ssl proxies.  And it’s fun!  The Offensive Security team has built a lab environment that you VPN into, with a wide array of machines running different unpatched services.  And they give you access to a windows machine with OllyDbg, a windows debugger that allows you to develop exploits at a very low level using 32-bit assembly language.  Don’t be put off if you’re not familiar with assembly – I don’t even really know it myself, but nonetheless it was a blast learning how things that wind up on milw0rm actually get developed.

The lectures that the course provides are very straightforward and explain things in an easy-to-understand manner, so even if you haven’t coded before, it’s definitely worth it to give it a try.  OS101 assumes a basic understanding of the Linux command line and the bash environment.

This is somewhat tangential, but I have to make another recommendation here.  If you are interested in network security, cryptography, and electronic privacy and want to keep up to date on these and other things, I highly recommend listening to the Security Now weekly podcast.  Security Now features a maverick in the industry and the creator of the data recovery tool SpinRite, Steve Gibson.

Anyway, I really do feel like a walking billboard now, so I’ll leave it at that!