So, I often ask myself what makes a good engineer? I ask this both of myself — to improve myself, and additionally I ask it of other engineers when I’m querying during interviews. I’ve written up a short list of what I think is valuable, and I intent to continue to maintaing this list as my view of the world changes. Read the rest of this entry »

When most people think of applications for cars, they think that maybe we’ll introduce Angry Birds, Pandora, Twitter, and Gmail to the main screen on a car. Most people view these as mere toys, and distractions — not actually helping to core driving experience. I personally feel like cars have a much greater potential as the next big platform.

So, some of you might know about the fact that I play Jericho (http://www.meetup.com/San-Francisco-Jericho-meetup-group/). I’ve recently thought about doing a game for classy folks at The California Academy of Science’s Nightlife, or The Exploratorium’s After Dark. Roughly, it goes like

I wrote a simple cookie snarfing attack. The source is available here:http://bazaar.launchpad.net/~sargun/cookiejack/trunk/annotate/head%3A/ergle2.py. It utilized scapy, PyQt4, and multiprocessing. It enables me to hijack most popular websites over a WiFi hotspot. Right now the code only is there for gmail, mail.yahoo.com, facebook.com, and reddit; extending for other sites should be trivial. It works by looking for cookies, and hijacking them for my own session. A video demo is below:

So, at my employer, deCarta, we recently moved from using a Cisco ASA5510 to using Vyatta firewalls. At some point later, I’ll review Vyatta. We did the migration on July 4th, so everything was in a nasty flux. Anyways, because of various reasons, the firewalls implementation was rushed, and that left certain security holes. In most networks, you verify that packets can traverse a particular part of the network. Though, we don’t test our security equipment enough. We often fail to verify that packets are not traversing the network. To look to our programmer brethren, many people are adopting test based development, where you build several unit tests around a particular function, and certain ones are supposed to fail (gracefully), and others are supposed to succeed. The point of checking for graceful failure is to make sure that the application isn’t accepting bad input.

Networks are far more fragile to human error than programs. Programming languages have certain barriers which prevents programmers from making mistakes. On the other hand, most network equipment is made to make ease of use a top priority. This allows someone to accidentally switch around the order of words, or leave out a stanza, opening up a network to attack. We need to verify that our security rules are working, and dropping the proper packets.

There are a few obstacles to this kind of testing. Doing specific SYNs/ACKs between different networks is difficult unless you have some sort of probe sitting in the center of the network, that can touch all portions of it. There are a variety of ways to approach this, which again, I wont cover here. Next, is the more complex part, coming up with the ways to test the rules. You can’t test every possible situation under which the rule should activate, and drop a packet. For example, if you have a rule which says that no system in 192.168.123.0/24 can contact hosts in 10.88.88.0/24, we obviously can’t test every possible combination of this, because that’d be 255^2. Instead, you come up with several different cases under the rules might fail. Firstly, a base case (a very typical one), make sure that 192.168.123.102 cannot send an ICMP request to 10.88.88.101. Next, you come up with a list of typically used numbers, like .100, .254, .1, or any other management hosts you have in your networks. Lastly, think of exceptions to the rule. For example, let’s say 192.168.123.22 is allowed to contact 10.88.88.55. Add these to the probe lists on either side. Now, on either side you have several hosts which you can test between, and that will give you a fairly good idea if your network filtering is active.

192.168.123.0/24 hosts:

192.168.123.55

192.168.123.1

192.168.123.102

192.168.123.254

10.88.88.0/24 hosts:

10.88.88.22

10.88.88.1

10.88.88.102

10.88.88.254

From this you can derive 15 test which should fail to pass packets, and will cover most typical human error. Remember, human error is never typical, so take these as examples, and remember you can never have too many tests to fail.

Anyways, all in all, just remember to make sure that your network is dropping as many packets as it can, and it only takes one packet to compromise your network ;-).