Jon Hart's Blog

Racket 1.0.6 Released

2009-11-28T17:58:00.000-08:00

Over the Thanksgiving holiday and thanks to the fact that I've been trapped indoors for two weeks, I've made some major improvements to Racket, released in version 1.0.6. For those not in the know, Racket is a Ruby Gem used for reading, writing and handling raw packets in an intuitive manner. Between 1.0.2 and 1.0.6, there have been countless changes, including but not limited to:

Full ICMPv6 support
Much improved IPv6 support, thanks largely to Daniele Bellucci
Revamped, more efficient ICMP support (basically copied all the cool things from ICMPv6)
All encoding/decoding classes moved under their respective layer in Racket::L3, etc.
Large documentation, test and example improvements

So, as usual, `gem install --source http://spoofed.org/files/racket racket` to install it and then take a stroll through the docs and examples. Enjoy!

Racket version 1.0.2 released, now in Metasploit

2009-11-14T22:17:00.000-08:00

Many months back I got word that Metasploit would be including Racket to handle much of its reading and writing of raw packets. Racket was selected for its speed and ease of use and I'm glad to see my work pay off. To celebrate this, I'm releasing 1.0.2, which includes:

VRRP
SCTP
EGP
General cleanup so as to not trash namespaces
Various bug fixes
Numerous documentation and examples cleaned up

Give Racket a whirl, I assure you you'll find it useful. I openly encourage testing, bug reports, suggestions or solicitations for additional functionality.

Ubuntu Server on a Soekris

2009-06-22T07:55:00.000-07:00

I've been running the remnants of the non-hosted portions of spoofed.org on an older small form factor computer in a closet for almost two years now. In addition to being a Debian install from ~2006, the box was generally quite a waste and all it really did was make heat, suck power and buzz its fans.

So, this weekend I took a few hours and installed Ubuntu 9.04 (Jaunty Jackalope) Server on one of my trusty Soekris 4801s.

There is plenty of documentation out there that either describes a similar process using significantly older versions of Ubuntu, or involves unnecessarily complicated methods of achieving the same end. Following on a entry I did a few years ago on installing OpenBSD on a Soekris, I once again took the route of using qemu to aid in installation.

OK, lets cut to the chase.

Download the Ubuntu Server ISO
Remove the CF or 2.5" disk from your Soekris and plug it in to the system you'll be doing the install on. Take note of what device it gets assigned -- my 2.5" laptop drive got /dev/sdd.
Fire up qemu. Change your memory (512), hard disk, and cdrom options as necessary. Note that the -no-acpi option is necessary to get the installer to start:
```
sudo /usr/bin/qemu  -m 512 -boot d -hda '/dev/sdd' -cdrom  '~warchild/ubuntu-9.04-server-i386.iso' -net nic,vlan=0 -net user,vlan=0 -localtime -no-acpi
```
Install as you normally would.
After the install has finished, halt qemu and restart, booting directly off your new Ubuntu installation instead of the ISO:
```
sudo /usr/bin/qemu  -m 512 -hda '/dev/sdd' -net nic,vlan=0 -net user,vlan=0 -localtime -no-acpi
```
Optional: if your Soekris does not support PAE -- the Geode processors used in the 48xx and 45xx certainly do not -- you'll need to install a kernel that does not require PAE. The kernel that ships with Jaunty Server -- 2.6.28-11-server -- requires PAE. You can either recompile and remove that requirement, or take the easy/easier route and just install the generic kernel
```
sudo apt-get install linux-image-generic
```

Reconfigure the your system to spawn a login shell on the serial port. Put the following in /etc/event.d/ttyS0:

start on runlevel 2
start on runlevel 3 
start on runlevel 4 
start on runlevel 5 

stop on runlevel 0
stop on runlevel 1 
stop on runlevel 6

respawn
exec /sbin/getty 115200 ttyS0

Somewhere towards the top of /boot/grub/menu.lst, ensure that the following two lines are present. The first just configures the serial port (change speed if necessary), and the second configures terminal I/O to be on that serial port:

serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=5 serial

Next, find the commented out section of /boot/grub/menu.lst that defines defoptions. Leave it commented out, but append the console directive to tie all this serial goodness together:

# defoptions=splash console=ttyS0,115200

Now, run update-grub to regenerate menu.lst :

$  sudo update-grub        
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /vmlinuz-2.6.28-13-generic
Found kernel: /vmlinuz-2.6.28-11-server
Found kernel: /memtest86+.bin
Updating /boot/grub/menu.lst ... done

$  sudo grep console /boot/grub/menu.lst
# defoptions=splash console=ttyS0,115200
# xenkopt=console=tty0
kernel  /vmlinuz-2.6.28-13-generic root=UUID=f48b39a6-020d-46e6-b25d-9210472ba1fd ro splash console=ttyS0,115200 
kernel  /vmlinuz-2.6.28-11-server root=UUID=f48b39a6-020d-46e6-b25d-9210472ba1fd ro splash console=ttyS0,115200

As a last step before you boot your Soekris, it probably wouldn't hurt to update:
```
sudo apt-get update && sudo apt-get -u upgrade
```
Halt your Ubuntu host running in qemu, remove the disk and install it in your Soekris
Now, configure your Soekris so that it'll jive with the serial settings you just configured in Ubuntu. Unless you have already changed it, your Soekris will (likely) come from the factory with its serial port configured at 9600n81. Configure your favorite serial communication program (minicom) to 9600n81, connect your null-modem serial cable to your Sorkris and host system, and then power on the Soekris. Press ctrl-p to get to the Soekris prompt. Set ConSpeed to 115200 (or whatever you configured your kernel to above):
```
set ConSpeed 115200
```
Now your Soekris will be speaking at 115200, so reconfigure your serial communication program as necessary.
Ensure that the boot order is correct (show BootOrder). If it does not begin with 80 81, 81 80 or something similar, use set BootOrder to remedy that. Remember, 80 is the CF, 81 is the first IDE device if present.
Type 'boot'
Enjoy.

Name-based Virtual Hosting and Web Application Security

2009-01-26T22:21:00.000-08:00

Over the past several weeks I've had the privilege of beginning evaluations of the best that the commercial security sector has to offer in the realm of web application security auditing. Arguments about whether simply buying a web application security firewall or pursuing this initiative from a code auditing point of view instead aside, the offerings from the top names in this space run the gamut from extremely impressive to downright depressing.

For purposes of this post, I am just focusing on the tools out there that do your traditional blackbox based approach to auditing. Given an IP address or a URL and some other minimal hand-holding, nearly all of the big names in this arena will do fairly good job of identifying the bulk of the "low hanging fruit."

Being the studious and meticulous geek that I am, one of my first requirements when evaluating these products was that they properly support the auditing of web applications that live on a host utilizing named-based virtual hosting. Simple, right? RFC2616 makes this sort of thing very clear and one would expect that not only would tools currently available be able to employ this knowledge to further leverage their way into a web application, but when asked about these features a given vendor would understand how they are useful. Needless to say, the HTTP/1.1 "Host" header plays a pretty important role on the majority of modern websites.

Well, I hate to break it to you, folks, but this is sadly not the case. Of all the vendors on the market, not a single one fully supports this functionality. Yes, you read that right -- no vendor in the blackbox web application security auditing space truly supports HTTP/1.1's "Host" header.

Pausing here for a second, I can sense the heated emails and comments aimed in my general direction. Please, hear me out.

So, just a hint of background. Many products utilize readily available HTTP client libraries written in their language of choice; rightfully so -- why reinvent the wheel! At least one even manipulates IE or Firefox directly to do their bidding, which I find particularly interesting.

And this is where the problem starts to manifest itself. When a human being makes a web request using a browser, they typically enter the address either using an IP address or a host name of some manner. Under the hood, as many of us know, the host name (if present) is resolved and the IP address that results is used as the destination address of the network socket. Once this connection is established using a modern browser, the host name (and port!) from the original URL is sent along as part of the request in the "Host" header of an HTTP/1.1 request. Simple, right? This allows a number of 1999-esque features such as being able to host more than one website on a single IP address or do fun SEO things like determining what URL a visitor originally used to arrive on your property.

Whats the big problem, right? Of course, all vendors that I've dealt with properly support sending HTTP/1.1 requests with a "Host" header, but they don't exploit all of its beauties. Imagine the following two situations.

One. Imagine two hosts: 192.168.0.1 (PRODUCTION) and 192.168.0.2 (TEST). Both PRODUCTION and TEST webservers contain name-based virtual hosts for www.example.com and seoftw.example.com. DNS for www.example.com and seoftw.example.com point to 192.168.0.1. How do you audit TEST accurately and completely? The obvious and hacky answer that most vendors gave was to diddle DNS before each audit so that the host performing the audit can correctly resolve the target host names to the IP addresses of the particular environment (PRODUCTION or TEST) that you are attempting to audit. If that was your answer, please hold while I drop the >$200k some of these tools cost for a single user into a bag and thwap some sense into you.

Two. Same two hosts as above, but toss a couple dozen other named-based virtual hosts, years of HTTP configurations gone wrong and a little luck into the mix, and you just might hit the proverbial pay-dirt if you grok the Host header. All manner of fun things can be discovered if you play around with it, such as:

Other virtual hosts that you might not have known about. Hint: send a 1.1 request with an invalid Host header.
Previously "protected" areas of the website now exposed by accessing it using a different Host header

Much like many of my other ideas which come while sleeping or in other prominent thinking spots, I've decided to whack together some code to explore these things more. The resulting abomination is vhinfo, which given a URL and/or an IP address will play around with various HTTP/1.1 Host headers and see what other VHOSTs it can find based on information that the server provides or is otherwise freely available. Like I said, its gross, partially unfinished and needs cleanup, but the results are fun:

Looks like Facebook really likes to strip the first portion of the hostname out and replace it with a 'www'.

$  vhinfo  www.facebook.com
HTTP/1.1 Host: www.facebook.com on 69.63.176.140 -> 200: OK
HTTP/1.0  on 69.63.176.140 -> HTTP/1.1 200 OK ()
HTTP/1.0 www.facebook.com on 69.63.176.140 -> HTTP/1.1 302 Found (http://www.facebook.com/common/browser.php)
HTTP/1.1 Host: 69.63.176.140 on 69.63.176.140 -> 200: OK
HTTP/1.0  on 69.63.176.140 -> HTTP/1.1 200 OK ()
HTTP/1.0 69.63.176.140 on 69.63.176.140 -> HTTP/1.1 302 Found (http://www.63.176.140/common/browser.php)
HTTP/1.1 Host: localhost on 69.63.176.140 -> 200: OK
HTTP/1.0  on 69.63.176.140 -> HTTP/1.1 200 OK ()
HTTP/1.0 localhost on 69.63.176.140 -> HTTP/1.1 302 Found (http://www.ocalhost/common/browser.php)
HTTP/1.1 Host: 127.0.0.1 on 69.63.176.140 -> 200: OK
HTTP/1.0  on 69.63.176.140 -> HTTP/1.1 200 OK ()
HTTP/1.0 127.0.0.1 on 69.63.176.140 -> HTTP/1.1 302 Found (http://www.0.0.1/common/browser.php)
HTTP/1.1 Host: www.04.05.sf2p.facebook.com on 69.63.176.140 -> 200: OK
HTTP/1.0  on 69.63.176.140 -> HTTP/1.1 200 OK ()
HTTP/1.0 www.04.05.sf2p.facebook.com on 69.63.176.140 -> HTTP/1.1 302 Found (http://www.04.05.sf2p.facebook.com/common/browser.php)

Sun likes to throw 500's on certain virtual hosts (these should probably actually be 404's):

$  vhinfo www.sun.com                   
HTTP/1.1 Host: www.sun.com on 72.5.124.61 -> 200: OK
HTTP/1.0  on 72.5.124.61 -> HTTP/1.1 200 OK 
HTTP/1.0 www.sun.com on 72.5.124.61 -> HTTP/1.1 200 OK 
HTTP/1.1 Host: 72.5.124.61 on 72.5.124.61 -> 200: OK
HTTP/1.0  on 72.5.124.61 -> HTTP/1.1 200 OK 
HTTP/1.0 72.5.124.61 on 72.5.124.61 -> HTTP/1.1 200 OK 
HTTP/1.1 Host: localhost on 72.5.124.61 -> 500: Server Error
HTTP/1.0  on 72.5.124.61 -> HTTP/1.1 200 OK 
HTTP/1.0 localhost on 72.5.124.61 -> HTTP/1.1 500 Server Error 
HTTP/1.1 Host: 127.0.0.1 on 72.5.124.61 -> 500: Server Error
HTTP/1.0  on 72.5.124.61 -> HTTP/1.1 200 OK 
HTTP/1.0 127.0.0.1 on 72.5.124.61 -> HTTP/1.1 500 Server Error

And Yahoo, not to be outdone, throws standards to the wind and just returns raw HTML text sans HTTP response headers (and breaks my code :().

$  vhinfo yahoo.com
HTTP/1.1 Host: yahoo.com on 206.190.60.37 -> 301: Moved Permanently (http://www.yahoo.com/)
HTTP/1.1 Host: www.yahoo.com on 206.190.60.37 -> 301: Moved Permanently (http://www.yahoo.akadns.net/)
Connection to http://206.190.60.37/ failed! -- wrong status line: "<!doctype html public \"-//W3C//DTD HTML 4.01//EN\" \"http://www.w3.org/TR/html4/strict.dtd\">"
/home/warchild/bin/vhinfo:128:in `check': undefined method `[]' for nil:NilClass (NoMethodError)

In summary, the HTTP/1.1 "Host" header is an important part of accurately and completely performing web application security audits and has a role in any vulnerability assessment that is definitely worth considering.

Hawler, the Ruby crawler, 0.3 released

2009-01-02T00:05:00.000-08:00

I received an email yesterday from ET LoWNOISE, a Metasploit contributor, regarding adding proxy support to Hawler. Apparently the hope is to be able utilize Hawler for the crawling duties within WMAP, the new web application scanning framework in Metasploit.

Since it has been several months since I've had to do anything to Hawler, I figured this was a good time to go in an do some much needed cleanup and improvements. Chief among the changes are:

Proxy support ("-P [IP:PORT]")
Documentation cleanup
Support crawling frame and form tags
Add a useful default banner to calling scripts if none provided
Print out defaults when help is called

Thanks to ET for his proxy contributions.

As usual, the following will get you up and running with Hawler:

gem install --source http://spoofed.org/files/hawler/ hawler

Using Hawler? Comments? Complaints? Suggestions? Drop me a line - I'd like to hear it.

Cisco AnyConnect 2.x Local Privilege Escalation

2008-12-22T10:45:00.000-08:00

I have been holding on to these vulnerabilities for several months now. Cisco's AnyConnect VPN client, which provides VPN connectivity to Cisco's ASA using SSL, suffers from a number of security vulnerabilities that result in local privilege escalation on the Linux and Macintosh platforms. Versions 2.3.0185 and newer reportedly have had these issues remedied, but unfortunately I do not have the time or the resources any longer to validate the fixes.

Exploit code for Linux and Macintosh platforms is available, however the code is in an unknown state. At one point I had attempted to unify the code so that it would work regardless of where it was run, however I never got much further than the thought. Since I cannot validate the exploit code any further, the code is being release "as is".

There are three vulnerabilities on both platforms and the exploit techniques are similar if not identical.

Vulnerability #1: /tmp/routechangesv4.bin is written mode 666 (world readable and writable) every time AnyConnect is launched. Because it is never executed directly by AnyConnect, we must use its world writable goodness to achieve our goal. In this case, a simple symlink-attack to create a world-writable crontab for root into which we inject our commands is any easy approach.

Vulnerability #2: The /tmp/Temp8-Vpn2e8 directory used as part of the Java applet is not checked for existence prior to use and, since there is no randomness in the name, is easily tricked into utilizing our maliciously placed executables. When the Java applet runs, it creates and uses /tmp/Temp8-Vpn2e8 to drop vpndownloader.sh, which in turn (you guessed it!) downloads the remainder of the files needed to utilize the VPN. Exploitation is relatively straight forward -- create /tmp/Temp8-Vpn2e8 with permissions that we control, wait for vpndownloader.sh to be placed by the applet and then swap it out with our payload prior to the applet executing it.

Vulnerability #3: /tmp/vpn-uninstall.log is written mode 666, but I cannot recall if this happens only install, uninstall or at every launch. Exploit method is identical to the first vulnerability.

Thanks to Cisco's PSIRT for their help in getting these issues addressed.

Mitigating DNS cache poisoning with PF

2008-07-14T19:38:00.000-07:00

By now, nearly everyone has heard about the latest round of DNS vulnerabilities, including non-technical people given the massive media coverage. If you have not heard of it, you probably wouldn't be reading this, however on the off chance that I am wrong, please read US-CERT VU#800113 and CVE-2008-1447 and then continue here. Most organizations are scrambling to find and apply fixes while some are still sitting idly debating the merits of the find.

There is nothing to debate. This is, in my opinion, an epic find. Because DNS is (in most cases) based on UDP (connectionless), the "security" is based on a handful of characteristics. Other flaws aside, a proper DNS client will only accept DNS responses that have the following characteristics:

The response contains an answer to a question that the client asked
The response came from a nameserver that the client originally initiated the request to
The TXID of the response matches that of the request
The destination port of the response matches the source port of the original request

Any attacker wishing to forge a DNS response in the hopes of manipulating the behavior of a DNS client could fairly easily guess or otherwise obtain points one and two. Point three has been flawed in the past, but despite the best RNGs this is still just a 16-bit number, which only gives you 65536 possible values. Point four is in theory also a 16-bit number with a few caveats, so it is only slightly less random than a true 16-bit space.

Dan's find, of which the full details are being withheld until BlackHat 2008 this August, nearly eliminates the source port difficulty and likely also tackles or at least reduces the problem space of the TXID issue. I have to be honest here -- anyone who didn't notice this particular anomaly in the past should be embarrassed -- I know I am. If you were to view the state table of a firewall fronting a vulnerable DNS implementation, you'd see that the source port of all outbound DNS requests from that particular DNS implementation would be fixed for an inordinately long time:

sis0 udp a.b.c.d:6489 -> 192.58.128.30:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 192.35.51.30:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 144.142.2.6:53       MULTIPLE:MULTIPLE
sis0 udp a.b.c.d:6489 -> 199.7.83.42:53       MULTIPLE:MULTIPLE
sis0 udp a.b.c.d:6489 -> 192.12.94.30:53       MULTIPLE:MULTIPLE
sis0 udp a.b.c.d:6489 -> 192.153.156.3:53       MULTIPLE:MULTIPLE
sis0 udp a.b.c.d:6489 -> 204.2.178.133:53       MULTIPLE:MULTIPLE
sis0 udp a.b.c.d:6489 -> 192.33.4.12:53       MULTIPLE:MULTIPLE
sis0 udp a.b.c.d:6489 -> 204.74.113.1:53       MULTIPLE:MULTIPLE
sis0 udp a.b.c.d:6489 -> 61.200.81.111:53       SINGLE:NO_TRAFFIC
sis0 udp a.b.c.d:6489 -> 207.252.96.3:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 163.192.1.10:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 192.31.80.30:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 216.239.38.10:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 216.239.34.10:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 64.233.167.9:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 66.249.93.9:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 64.233.161.9:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:6489 -> 206.132.100.105:53       SINGLE:NO_TRAFFIC

As you can see, the source port is identical for all outbound DNS requests. This port will change eventually, and honestly I am not sure what the exact details are regarding its change, however I believe it is sufficient to say that it remains constant long enough for you to be concerned with it.

In addition to my work related duties, I also have my own personal systems to worry about. My client systems were quickly fixed, however they remain vulnerable because of my setup -- all DNS requests from my network are forced to go through an internal DNS server that I control. I use OpenBSD almost exclusively for my routing, firewalling and other common "gateway" type functionality, and it just so happens that my DNS server runs OpenBSD too. So despite my clients being secure from this attack if they were querying external nameservers directly, my internal DNS server put them at risk. I was surprised to find that on the US-CERT announcement that they were listed as "unknown" and now, more than a week later, there is still no mention of the issue on any of the OpenBSD mailing lists or on the website.

Since my DNS server runs on a little, low-power device, the thought of having to rebuild something from source or other disk/CPU intensive operations makes me cringe. Thats what got me thinking -- is there a way I can protect myself until a patch is available from my vendor and I have time to deal with it?

As it turns out, I believe there is. My interim solution is to use PF to provide some randomization to my outbound DNS requests.

If your DNS server sits behind a NATing PF device, the source port randomization is implicit -- see the section titled TRANSLATION in the pf.conf manpage. If your DNS server is also running on the PF device, as it is in my case, you are still vulnerable unless you configure things correctly.

The trick is to force requests coming from your DNS server, which have non-random source ports, to be processed by PF so that they too are subject to the implicit source port randomization. This is actually quite simple, and you may already be doing this without realizing it, depending on your setup. Assuming the outbound address of your DNS server (or PF device itself) is a.b.c.d, the following NAT entry in your pf.conf should be sufficient:

nat on $WAN_IF inet proto { tcp, udp } from a.b.c.d to any port 53 -> a.b.c.d

This results in a dramatically different state table:

sis0 udp a.b.c.d:40783 -> a.b.c.d:59623 -> 192.55.83.30:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:40783 -> a.b.c.d:64916 -> 199.7.83.42:53       MULTIPLE:MULTIPLE
sis0 udp a.b.c.d:40783 -> a.b.c.d:50591 -> 202.12.28.131:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:40783 -> a.b.c.d:60017 -> 192.55.83.30:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:40783 -> a.b.c.d:63472 -> 200.160.0.7:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:40783 -> a.b.c.d:55603 -> 200.189.40.10:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:40783 -> a.b.c.d:50749 -> 192.52.178.30:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:40783 -> a.b.c.d:64190 -> 192.83.166.11:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:40783 -> a.b.c.d:64346 -> 128.63.2.53:53       MULTIPLE:SINGLE
sis0 udp a.b.c.d:40783 -> a.b.c.d:59970 -> 61.220.48.1:53       SINGLE:NO_TRAFFIC

As you can see, the original source port is still fixed in the internal table, however the source port that is used out there on the big bad Internet, where the risk lies, is random. To add even further randomness, if you have multiple addresses at your disposal, you can distribute outbound DNS requests across a pool of those addresses:

nat on $WAN_IF inet proto { tcp, udp } from a.b.c.d to any port 53 -> { a.b.c.1, a.b.c.2, a.b.c.3, ... } round-robin
# or if you have a contiguous space available, use the 'random' modifier
nat on $WAN_IF inet proto { tcp, udp } from a.b.c.d. to any port 53 -> { somenetwork/mask } random

The astute reader will have probably already noticed that it is major overkill to include TCP DNS traffic in these countermeasures, however I cannot think of any adverse side effects of doing so.

The proof is in the pudding. Utilizing the handy service setup by DNS-OARC, you can see that my setup appears "FAIR":

$  dig +short porttest.dns-oarc.net TXT 
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"a.b.c.d is FAIR: 14 queries in 10598.6 seconds from 14 ports with std dev 4249.80"

As usual, YMMV. If I am mistaken in any of my assumptions or suggestions, I would love to hear differently. Otherwise, enjoy.

Netflix Queue Randomizer

2008-07-07T23:27:00.000-07:00

Security is where I spend the bulk of my time, however I have dabbled quite extensively in other areas. So it is no surprise when every once in a while I do something that is not security related. This is one of those times.

Netflix. Love it or hate it, but me not having a TV makes Netflix a lifesaver because I can get my dose of movies while multitasking (current movie: Golden Child). The problem I continually find is that my queue directly follows my particular mood I was in when I was adding to the queue. The result is that the movies in my queue will have this flow to them that is not always appealing. For example, I watched a string of westerns last week, however that was because a week or two prior I watched Tombstone and then went and selected movies that Netflix said I'd like based on my 4-star rating of Tombstone.

Several months I ago I wrote to Netflix asking them for the ability to randomize my queue. Sure, I can do this by hand, however when I have 50 movies in my queue it gets old after the first time you do it. Since I figured this would be useful to others, it would not be unreasonable to ask Netflix to implement this. Furthermore, the queue manipulation stuff is already there and used by the queue manager, so it makes me wonder why it was never implemented. Understandably, they probably have other things on their plate. An API, perhaps?

The result is the following Greasemonkey abomination:

// ==UserScript==
// @name           Netflix Queue Randomizer
// @namespace      http://www.netflix.com/Queue
// @include        http://www.netflix.com/Queue
// ==/UserScript==

function moveToTop(id, from) {
 GM_xmlhttpRequest({
   method: 'GET',
   url: 'http://www.netflix.com/QueueReorder?movieid=' + id + '&from=' + from + '&pos=1&sz=0&mt=true&ftype=DD',
   headers: { 'X-Requested-With': 'XMLHttpRequest' }
 });
}

function randomSort() {
 return (Math.round(Math.random()) - 0.5);
}

function randomizeQueue() {
 var inputs = document.getElementsByTagName('input');
 var idRe = /^OP(\d{8})$/;
 var curIds = new Array();
 var curPoss = new Array();
 var newOrder = new Array();


// find all of the movies in the queue and store their ID and current
  // position in the queue
  for (var i=0; i < inputs.length; i++) {
    if (inputs[i].type == 'hidden' && inputs[i].name.match(idRe)) {
      var matches = idRe.exec(inputs[i].name);
      curIds.push(matches[1]);
      curPoss.push(inputs[i].value);
    }
  }

  // create a new array that is the same size as the movie queue and
  // randomize it.  This has to be done this was because QueueReorder does
  // not support moving to arbitrary positions, only the top.
  for (var i=0; i < curIds.length; i++) {
    newOrder[i] = i;
  }
  newOrder.sort(randomSort);

  // now map the current movies and their positions to their new homes
  for (var i=0; i < newOrder.length; i++) {
    moveToTop(curIds[newOrder[i]], curPoss[newOrder[i]])
  }

  window.location.reload();
}

// Create a new div that contains the 'Randomize Queue' link, and then prove
// that I have nearly zero HTML foo by being unable to place the link to the
// left of the bottom 'Update DVD Queue' button
var qFooter = document.getElementById('updateQueue2');
var rDiv = document.createElement('div');
rDiv.setAttribute('class', 'd1_qt');

var rLink = document.createElement('a');
rLink.addEventListener('click', randomizeQueue, false);

var rText = document.createTextNode("Randomize Queue");
rLink.appendChild(rText);
rDiv.appendChild(rLink);

qFooter.parentNode.insertBefore(rDiv, qFooter);

Obviously for any of this to work you'll need to have Greasemonkey installed, which requires Firefox, an understanding of how to load this (Tools -> Greasemonkey -> New User Script), and a Netflix account.

Enjoy?

Craigslist Posting Security -- Adequate

2008-07-05T21:21:00.000-07:00

If you have not bought or sold something on Craigslist, or at minimum browsed your particular region's Craigslist section, you truly have not experienced the best that the Internet has to offer. I use Craigslist probably half a dozen times per year for legitimate reasons -- to sell something I want to make a buck on or simply cannot bring myself to throw away, or perhaps I need to buy something particularly exotic or maybe something I'm looking to get on the cheap. The remainder of the time I'm cruising Craigslist purely for entertainment purposes. The "Best of Craigslist" and "Free" sections consume the bulk of my time.

Thursday was one of those days where I was posting an item for sale on Craigslist. I received the email that contains a link to publish, edit or delete my post, and at that moment my subconscious tazed me and told me there was something of interest in that link. It was not too unlike other links I have received in the past from sites that require me to verify that I do, in fact, own a particular email address. It contains a link that, among other things, contains some seemingly random garbage either as part of the URI or as part of the query string. This "random garbage" is generally an MD5 checksum or similar mechanism that ensures that it cannot be easily guessed and allows all involved parties to sleep comfortably knowing that posts cannot be tampered with by anyone other than authorized parties. Poor ways of implementing this would include anything that bases the MD5 on anything that can be easily guessed or otherwise obtained. Obviously, if the system in question simply MD5'd the poster's email address and posting title, a little trickery would get an attacker access to the management of that particular post.

When I received the email the other day, I quickly parsed through the past ~3 years or so of Craigslist posting emails and quickly noticed there was a pattern. All posts are of the form https://post.craigslist.org/manage/[8 digits]/[5 lower case letters or numbers]. I legitimately thought I was on to something. A few bogus posts later (which subsequently got flagged. Thanks, Craigslist overlords!) I was wondering, could it really be this easy?

As it turns out, no. It is no simple task to defeat Craigslist posting security. The first 8 digits in the path are easily obtained. In fact, they simply correspond to the posting ID which is freely available from any posting. This brings up two interesting points:

This provides no security, and in reality probably was not chosen for security reasons
Craigslist cannot handle more than 10^8-1 (99,999,999) posts in any one posting window, which is typically 7 days. This presents a curious DoS condition that is probably entirely impractical, however is interesting to consider.

This brings us to the last 5 characters of the URI. Another quick analysis of my posts shows that they are always 5 characters and only ever contain a mixture of numbers and lower-case characters. The mathematicians in the house have already busted out the answer on their pocket calculator, however for those not so inclined that means there are (26+10)^5 possible values for this field (26 lowercase characters, 10 digits, 5 places, which results in just over 60 million possibilities. 60,466,176, to be exact).

If those 5 characters were based on something that could be easily guessed or obtained, there would be cause for concern, however no correlation was determined between the 5 characters and the following characteristics:

Poster's email address
Posting title
Date/time
Post ID

This leads me to believe that it is a randomly generated string of some sort that serves as an index into a database of posts. Anyone that has ever had to develop, enforce or audit a password policy knows that a 5 character password, regardless of content, is prone to failure. In this particular case, however, is it adequate?

In my opinion, yes. Given the nature of how Craigslist posts are managed -- HTTPS -- and the relatively limited time window in which the management URLs can be accessed (7 days for most posts, 30 for a limited few), the chances of someone brute-forcing these seemingly simple 5 characters is virtually 0. Since these require HTTPS posts, even if you can pull off 1 per second, it will still take you nearly 2 years to guess the correct URI ((26+10)^5)/60/60/24) == 699 days). By the time you guess it, the post will have expired or been deleted, and on the off chance that you get lucky and it still exists, you will almost certainly have tripped up something on Craigslist's side and Craig Newark himself will be on his way to your house to slap you around.

Update your bookmarks/feeds -- to Blogger

2008-07-01T21:17:00.000-07:00

In case you have not noticed, things have changed a bit around here.

When it comes to things that can kill me, make me money and/or affect my reputation in one way or another, I'm a firm believer in "If you want the job done right, do it yourself." Those who know me know that there are very, very few individuals I trust with my online presence and fortunately I have never had to call upon them to lend a hand.

How does this relate to Blogger, you ask? Well, for years I had not trusted any third party to host my blog and host it right, however just recently I took at new look at Blogger and they definitely appear to run a tight ship. Whether its the Google strings or not, I have nearly zero problems with their operations.

Most everything has been migrated permanently with the exception of a few random posts from many years ago, however those will come in time. I have a great pile of mod_rewrite foo going on right now to move people, crawlers and the like over to the new site, however it does not appear that RSS readers are going to play along. They'll happily follow the redirect, but the source for the feed remains the same.

So... update your bookmarks, else come this time next week the old blog will be gone and the redirects will be replaced with feeds to something much less pleasant. I'll happily take suggestions of convincing items to put in the old RSS feed to coerce people into moving over.

Thanks, and enjoy!

Defeating Private Domain Registration

2008-06-30T21:47:00.000-07:00

The concept of private domain registration has probably been around longer than I think it has, but if I had to guess its rise in popularity coincides approximately with the rise in identity theft, spam and other Internet-related annoyances. Actually, you can just ask one of the largest providers of private domain registration, domainsbyproxy.com:

$  whois domainsbyproxy.com |egrep " on( |:)"
    Created on: 15-Jan-02
    Expires on: 15-Jan-17
    Last Updated on: 05-Sep-07

The idea, for those who are not familiar with private domain registration, is that you allow a third party to register or take ownership of a domain name that you are interested in, and then they give you some level of control over it. The benefit here is that the various bits of contact information typically associated with WHOIS data -- registrant, technical, billing, administrative -- are now that of the third party who now owns that domain on your behalf. Had you not used a private registration of one form or another, you'd either have to leave your "docs" at the mercy of the general public, or simply put in some bogus data and hope nobody notices. Which is worse? You be the judge.

The risks of not masking your WHOIS data in one way or another are fairly common knowledge, but to summarize, the following will likely become a problem for you at one point or another:

Identity theft
Domain theft or abuse
Stalkers
SPAM
Verne Troyer getting mad at you because you posted his sex tape

Nearly every registrar, no matter how seemingly small or insignificant, is offering private registration as an option lately. Just Google it and you'll see. I have some good news and some bad news, and it just so happens that it is the same bit of news. So whether this is good or bad really depends on what side you are on.

Private domain registration works.

Of course, like many things in security, the devil is in the details and things usually get tripped up in implementation rather than in specification. If you simply want to register a domain and possibly put up some witty content also hosted by the private registrar, then you'll probably be safe. However, in nearly all situations that I know of or have heard about, private domain registration is used because the owner of the domain wants to take full advantage of the domain instead of cowering in a corner. Yes, that means talking shit and/or making a buck.

What this means is that at some point you are going to start offering or utilizing some services that are oh so vital, typically HTTP, SMTP or DNS. You gotta post content, you gotta send/receive email and without a DNS server somewhere to handle all of this for you, you'd be dead in the water.

There are secure and proper ways to utilize private domain registration, offer common services like HTTP, SMTP and DNS and still not leave your goods out there for everyone to ogle. Unfortunately, this means you are probably going to have to limit yourself to the services offered by your registrar. The result is that the services will either be expensive, featureless or both. You'll get some bastardized webmail system with limited functionality and a WYSIWYG HTML editor for your site, maybe PHP-Nuke if you are lucky.

And this is where things go wrong and the point of my post begins. You've got a domain private registered somewhere but decide to actually use it. You stand up an HTTP and SMTP server somewhere and point DNS accordingly and before you know it your efforts to stay private have taken a giant leap back towards square one.

What use to be a relatively private setup is now becoming increasingly more public. The three services that most any domain needs to survive -- HTTP, SMTP and DNS -- are now the soft spot in your otherwise secure underbelly.

Off the top of my head, the following are some potential points of disclosure for each of the above services. This list is by no means comprehensive, and excludes the usual gamut of security best practices for each service. Furthermore, organizations continually find new and rofl-able ways of screwing this up. That said:

HTTP:

Putting sensitive information in your "contact page"
Hosting your web content on a site who's forward or reverse DNS somehow link back to you
Improperly handling non HTTP/1.1 requests and disclosing private information such as the server name

SMTP:

Disclosing your true(r) identity in an SMTP greeting
Sending information-filled NDRs for bounced or otherwise undeliverable email

DNS:

Disclosing your anti-spam efforts by way of SPF TXT records (hint: `host -t txt domain.com`)
Making some DNS server that can be tied back to you (forward or reverse DNS, WHOIS) authoritative for one or more records in your domain
Publishing a DNS record that resolves by way of forward or reverse DNS to something that can be tied to you.

I honestly find DNS related issues the most relevant here, and if you don't have access to something like dnsstuff, your local DNS friends host(1) and nslookup(1) can start getting you some dirt. Of particular interest is anything that has intelligence and or some brute forcing capabilities built into it. Fierce is arguably the best tool for this particular task.

I have seen some organizations that do seemingly everything right, however most of them inevitably have a dirty history that can be had for $39.99 by any number of organizations that offer historical WHOIS or DNS data. If their dirty laundry has been aired in the past, it can be had for a nominal fee. In most situations where this sort of research is warranted, the cost of getting a membership to such a service (if you don't already have one ;)) is insignificant compared to the cost of winning whatever battle it is you happen to be in.

It should be mentioned that there a number of privately registered domains that do seemingly everything correct, however those domains are backed by some combination of well paid and extremely technically savvy staff, a crack legal team and SEO zealots.

Well played, sir.

Temporary files -- yer doin it wrong

2008-05-23T17:54:00.000-07:00

The number of security vulnerabilities I've discovered over the years that have started from casually observing how a particular system operates is a non-trivial amount. I don't recall where i was reading this or what the exact wording was, but it boiled down to the fact that some of the best hacker minds are those that act upon the thoughts that start with "I wonder what happens if I ..". They say that curiosity killed the cat. What about the hacker? I have this great picture of myself when I was probably 6 or 7. I had a dozen D cell batteries taped together in series hooked up to a small DC motor I had ripped out of one of my toys. My desk or the family workbench had met it's maker. And then there was the time I cut the power cord off the back of my broken alarm clock, split the leads and taped them to a dead 9V battery. A poor mans recharger, right? Wrong. A convenient way to splatter battery acid and toxic fumes all over my room.

I have this nervous habit that every time I open a terminal or change directories, I type ls. Besides an overly large bash/zsh history file, this actually led me to stumble up on a number of temporarily files, directories and other things that an application may litter in a directory as part of its normal operations. Right now, list the contents of /tmp. Aside from random files you stashed there for lack of space elsewhere, you'll almost certainly see files that were dropped there by applications that have run recently on your system.

If you have any sort of security background, you can see where this is going. The problem is that these applications don't always handle all situations carefully when it comes to temporary files. What if the file already exists? Symlinks? What if the directory is owned by another user, but is world writable? What if the filename is predictable? These are the breeding grounds for race conditions, symlink attacks and other related security vulnerabilities.

The result is tmpsnarl, a quick little script designed to look for and capture temporary files, directories, sockets, symlinks and the like in the hopes of being able to exploit the above mentioned vulnerabilities. I've used this tool to re-discover some of my past vulnerabilities, as well as find a few 0day race conditions that I was unaware of. I now instinctively run tmpsnarl on all systems I have shells on and the results are amusing. Give it a spin, and shoot any feedback or discovered vulnerabilities back my way.

Temporary files -- yer doin it wrong.

Why SSL?

2008-04-09T19:43:00.000-07:00

Over the years I've been involved in a number of projects where SSL was needed to help secure communications between endpoints. Without fail, every time I was rolling out a certificate authority or installing an X.509 certificate on a particular node I was met with some level of resistance. Encountering someone who was pleased with this effort is truly a rare experience.

A lot of resistance comes from the fact that too many people don't like to do work or do the job right the first time. I'll admit -- a PKI requires work and is not easy. I'd even go as far to say that it is a painful experience. Well, so is getting your authentication credentials or your identity stolen.

This all begs the question, "Why SSL?". I'm glad you asked.

By using SSL, a system is able to provide:

Authentication
Encryption

Authentication allows you, the client, to verify that the server you are speaking to is, in fact, the server you expect to be speaking with. In more complex setups, it also allows you, the client, to prove your identity to the server.

Encryption allows the two endpoints in the conversation to ensure that the data transfered cannot be tampered with and that it cannot be read by unauthorized eyes.

Unfortunately, these two points alone are typically not enough to justify SSL to some people. So, practically speaking, where are the risks? As I see it, the risks are almost entirely network related.

For sake of discussion, we'll ignore the fact that the two endpoints in a conversation could be compromised and, regardless of SSL, the conversation could be compromised. We'll also ignore the fact that it is entirely possible that they way in which the encryption system was designed or implemented could be flawed, thereby exposing any supposedly encrypted communications.

A compromise of any of the following could result in unencrypted communications between two endpoints to be exposed.

En-route Network Equipment

I am sure there is some survey somewhere that measures or attempts to approximate the average number of network hops the average human's network traffic passes through prior to it reaching its destination, but I say that 10 is a good guess. We've all heard the phrase "cut out the middle man", but when it comes to your personal data the saying could never be more true. When I connect to my bank, my traffic hops through at least 11 network devices that I do not control, all of which are owned and operated by at least 3 major, multi-million/billion dollar providers:

$  traceroute -q 1 -n -A  -w 1 nomansbank.com
traceroute to nomansbank.com (a.b.c.d), 30 hops max, 40 byte packets
1  192.168.0.1 [AS28513]  1.455 ms
2  208.127.144.1 [AS19817]  25.108 ms
3  66.51.203.33 [AS19817]  26.738 ms
4  63.209.70.133 [AS3356]  27.904 ms
5  4.68.102.30 [AS3356]  39.692 ms
6  4.69.137.33 [AS3356]  31.824 ms
7  4.69.132.82 [AS3356]  104.852 ms
8  4.69.134.186 [AS3356]  98.615 ms
9  4.68.17.6 [AS3356]  100.826 ms
10  4.68.63.2 [AS3356]  102.223 ms
11  216.140.9.9 [AS3356]  105.364 ms
12  65.88.122.190 [AS3356]  110.851 ms
13  *

As much as I'd like to be able to say that none of these hosts or providers could ever be compromised, they can be compromised and have been in the past. All it takes is one and your bank data, juicy IM conversations or scathing gmail messages are exposed.

At the same time, the world of security is not always about the bad guys out to get your data. In this day and age, it is safe to assume that every bit of data you transmit from your computer is monitored in some way. This monitoring could be fairly innocent in the form performance monitoring or debugging by a network provider along the path of your packets. Or, it could be a true "Big Brother" type situation where a government is monitoring, logging and analyzing all traffic. You will be sorely mistaken if you trust that your data captured during monitoring will never suffer any ill will.

Just as you should fully trust that if you hurl stacks of money into the streets that people will do whatever it takes to get that money, you should also assume that when you send personal data unencrypted over the Internet people will make every effort to intercept it. That is, of course, if they don't already have it.

DNS

The first thing that happens when you attempt to connect to a system by name is that your DNS resolver must do a forward DNS lookup to resolve that name to an internet protocol (IP) address. At that point, a connection is established to the IP address identified in the previous step, and eventually data is transfered back and forth and life is good.

Or not.

Since DNS is (generally) UDP based, forging responses is fairly easy. All you have to know is the source port of the original request and with darn near any programming language you could forge enough fake traffic to eventually accomplish your goal. Fortunately, the designers of DNS implemented a 16-bit transaction ID in order to allow resolvers to match responses with requests. While not cryptographically secure, these 16 bits can make brute force approaches a real bear.

Or not.

Unfortunately, far too many implementations of transaction IDs within DNS resolvers are not only random, but predictable in numerous implementations.

The situation is totally shot to hell if an attacker has the ability to intercept traffic between a DNS client and server. At that point, a transacation id -- cryptographically secure or otherwise -- does not matter. Intercept the original request and forge a response back to the client in the attacker's favor before the legitimate DNS server does and then the sky is the limit.

Dug Song's venerable dnsspoof (part of dsniff) has been exploiting this "flaw" for nearly 10 years now. I wrote an improved knock-off version a while back called dns_spoof that picks up where Dug's tool left off. On a system that has ability to intercept (legitimately or otherwise) DNS requests from your target:

dns_spoof -p "A . A 1.2.3.4"

This will intercept all requests that are A record requests for any name and will return an A record of 1.2.3.4. On the victim system which now attempts to connect to their bank:

$  telnet nomansbank.com 80
Trying 1.2.3.4...

Now if you were in control of 1.2.3.4, you are free to intercept and molest the traffic that the victim believes to be going to nomansbank.com.

ARP

In the previous section, I said that one of the first steps in a connection to host by name is for DNS to resolve that name. This is true, but a bit misleading. The true next step is for the DNS client to arrange for its DNS request to be delivered to the DNS server. In the case where the DNS client and server are on the same broadcast domain, a simple ARP (address resolution protocol) request will return the layer 2 address of the layer 3 address belonging to the requested name server. If the DNS client and server do not have direct layer 2 connectivity, the DNS request must be properly routed. In this case, the ARP request is made by the DNS client for the appropriate next hop router.

If you've done any serious network security work, or this article is tickling the right brain cells, hopefully you already see where this is going. Just as DNS requests can be intercepted and molested, so can ARP requests, except in the case of ARP the situation is much worse. Or better, depending on whose side you are on. If an attacker can forge and ARP response that includes a layer 3 address that they control before the legitimate system(s) respond, then similar attacks to those described above can continue.

So. Again. Why SSL?

Take the super paranoid approach and always assume that the attacks on your unencrypted data are always under way. Protect your communications with SSL and the risks are largely eliminated. This is what other articles or security practitioners will preach. Unfortunately, it is only partially true.

The title of this entry should really be "Why proper SSL?". SSL is nearly useless if the PKI upon which it is built is not properly implemented. I'd actually argue that SSL that is deployed as part of a sloppy PKI implementation is less secure than not implementing SSL at all. Why, you ask? If you train your users to not send sensitive data over unencrypted channels, they become lulled into a false sense of security when they encounter a connection secured with SSL. They then inherently trust SSL connections and send sensitive data over said connection and have little basis on which to judge whether or not that SSL connection is secure aside from the little lock in their browser or the fact that the "S" in "SSL" stands for "Secure".

The power and security of a PKI comes largely from the trusted third party that is the CA (certificate authority). The lack of a CA or lack of a properly implemented CA is exactly what can jack up what would otherwise be a secure and properly implemented PKI.

A PKI that is implemented without a CA isn't really a PKI at all. This results in what is typically called "self signed certificates". This is the security equivalent of a kid getting a report card and, instead of bringing it home to have his parents sign it, simply putting his own signature on it. As I said before, much of the security in a PKI comes from the CA, but how is that? When an X.509 certificate is issued, it is issued by the CA on behalf of the particular participant in the PKI that wants to be uniquely and securely identified. In plain terms, the certificate issued by the CA says that anyone who can display this certificate is in fact who they claim to be. The catch is that merely possessing the certificate is not enough. You must also possess the private key that was used when requesting the certificate in the first place.

OK, so great. You've got an SSL certificate that was given to you by a CA. All is well, right? Sadly, no. The problem all comes back to that little word we call trust. The lack of a trusted CA comes in two forms.

The simplest is that if the CA is not trusted, there is no telling how their ship is run. They could be issuing certificates to any old bloke that wants one without actually validating their identity. They could be issuing certificates that lack some of the most basic X.509 attributes that can tarnish any PKI.

The worst thing that can happen as a result of an improperly implemented PKI is not a technological one, but people problem. We've all seen a browser message warning that a certificate is signed by a CA that we don't trust, or the host that we are connecting to does not match the hostname that the certificate claims to be for. The result is that users get into this habit of blatantly clicking "OK" when their browser warns them of this security issue.

Oh, it gets worse. Recall all those attacks regarding traffic interception and deception using DNS and ARP tricks when trying to intercept unencrypted data? Once your users get into the habit of blindly clicking through browser warnings, these attacks are perfectly valid ways of intercepting data encrypted using an insecure PKI. ARP spoof or forge DNS requests into getting a victim to connect to a host you control, and then the fact that you throw up an invalid or otherwise insecure X.509 certificate is not a problem because these users will blindly click through most any warning message and then their data is yours.

Game. Over.

Racket -- Ruby Raw Packet Fun

2008-03-02T09:41:00.000-08:00

This is one of those projects that I've been sitting on for a good 6+ months. Only over the last 2-3 have things really started to come together. I am happy to release Racket, a Ruby gem designed for crafting and analyzing raw packets.

Towards the end of the initial development of Racket, I caught wind of Scruby because that is what Metasploit 3 is using for much (most?) of its raw packet duties. In the TMTOWTDI spirit, I kept up development and actually think that Racket's purpose is a bit different than that of Scruby.

Installation is fairly simple:

gem install --source http://spoofed.org/files/racket racket

Documentation and examples are published but need some touching up. Among some of the more amusing/useful examples are:

cdp-spew: exactly what it sounds like. Creates and floods the network with random Cisco Discovery Protocol (CDP) packets
hsrp_takeover: passively listens for and actively performs "takeovers" for all discovered Hot Standby Router Protocol (HSRP) instances
tcp2udp: Listens for any tcp traffic and turns the packet back around, sending it back at the source as a UDP datagram. No point

Racket requires that you have Joel VanderWerf's BitStruct and Marshall Beddoe's PcapRub installed.

Enjoy! Comments or suggestions are welcomed.

Things that keep me up at night..

2008-01-29T22:27:00.000-08:00

I've tried to cut back on the amount of personal stuff that I publish here, and limit it just to professional topics. So, no more discussions about politics, what I ate for breakfast or drunken debauchery.

This, however, rides the fine line between personal and professional. The following three things make me lose sleep

Everyone's favorite layer 2 protocol, ethernet, has the destination MAC address before the source MAC address. I've heard and speculated that this is for speed. Instead of having to jump ahead another 6 bytes, small devices that have limited processing power can read in just 6 bytes and be able to make forwarding decisions accordingly. Why, though, does this practice only exist at this layer? Sure, the "source then destination" thing is burned into our brain, but what performance gains could be obtained had, say, destination IP addresses been placed earlier in IPv4?
Why are UDP and TCP checksums so crazily different than, say, IP or ICMP checksums? A checksum exists so that protocols that decide to implement it can be sanity checked -- essentially, has this layer and the stuff it is responsible for been damaged in transit? IPv4, not caring about the payload, only checksums its header values. It is up to higher level protocols to check themselves before they wreck themselves. ICMP takes a slightly more polite approach and checksums its header values and payload. UDP and TCP, however, take this grossly different approach -- in addition to computing a checksum that uses their respective header values and payloads, these two decide to also include the source and destination IP addresses in the checksum. WTF? A protocol should be able to compute its own checksum by utilizing whatever information is available to it. This includes its header values and whatever is in its payload, if anything. Data lower in the stack is simply not available in any sort of simplistic fashion, yet TCP and UDP decide to be special.

Hawler, the Ruby crawler

2008-01-20T10:17:00.000-08:00

Over the years I've thrown together various bits of code that have crawling functionality built into them. There was termite, used to find backup copies, renames or common temporary locations of your entire web site. There was indexfinder, used to crawl your site and find anything that looked like a directory listing. There was also htcomment, used to ferret out all of the comments found in your html.

These tools were all fairly well tested and worked quite well, but everytime I dusted off the code and fixed a bug or added functionality, my CS books would scowl at me. The core crawling code was literally cut and pasted between tools. The problem with this is obvious -- a bug or missing bit of functionality in the core crawler code had to be fixed in numerous places. Design at its worst.

Starting maybe a month ago I decided to fix this problem. The result is Hawler, a Ruby gem that encapsulates all of what I deem to be core web crawling functionality into an easy to use package. The result is that I can now focus more on writing the code that is unique to each particular task and not have to worry as much about the crawler bits. Its usage is quite simple, as described in the README.

As an example of Hawler's usage, I've put together two tools that I've found quite useful so far. First is htgrep. It is exactly what it sounds like: grep for the web. How many times does the word shot occur within 1 hop of www.latimes.com? Lets find out, but sleep 1 second between each request (got to play nice) and utilize HEAD (-p) to only harvest links from pages that are likely to have them in the first place:

$  htgrep shot www.latimes.com -r 1 -s 1 -p  |wc -l  
43

Only 43? A peaceful day in LA! What about the distribution of HTTP error codes on spoofed.org? Use htcodemap:

$  htcodemap spoofed.org -r
Done -- codemap is spoofed.org-codemap.png

The result? Not too shabby:

What about drawing rediculous maps of relationships within a website? Well, assuming you have enough RAM (blame graphviz/dot, not me!), enjoy htmap. An example, here is a fairly deep crawl and mapping of spoofed.org:

$  htmap spoofed.org -r 2
Done, map is spoofed.org-map.png, spoofed.org-map.dot

The image is here.

I expect that a lot of cool tools will be born from Hawler, and I'll be sure to link and post them as they turn up. Until then, enjoy!

Comments and suggestions are very much welcome.

OpenBSD on Soekris -- A Cheater's Guide

2007-12-09T22:17:00.000-08:00

I've been using Soekris devices for quite some time. Basically any time I need to get some routing, firewalling, skullduggery, etc, that doesn't require serious CPU, I toss a Soekris box at the problem. They are great little devices -- low power, dead quiet and rock solid.

The obvious downside of a system like the Soekris is the wimpy CPU. This really is only an issue during installation and during the initial system configuration. After that, the box is a real work horse.

Below are the steps I recently used to get my NET4801 running OpenBSD 4.2 -current. The difference here is that I use qemu to make use of the considerably faster CPU on my desktop to breeze through the install and initial configuration.

Download install42.iso from your local mirror
Plug in your CF card that you'll use in your Soekris. Take note of what device it gets assigned
Start qemu, replacing /dev/sdb with whatever device your CF is:
```
qemu -hda /dev/sdb -cdrom install42.iso -boot d
```
Install as usual. Configure your interface to use DHCP, as anything else won't work inside qemu. Set default console to com0 and set the speed to match your Soekris (9600)
Finish installation. Halt. Stop qemu. Restart without the iso:
```
qemu -hda /dev/sdb
```
Once booted, edit /etc/fstab so that / is mounted with noatime, read-only. My /etc/fstab looks like this:
```
/dev/wd0a / ffs ro,noatime 1 1
```
Now put the volatile stuff into MFS so you won't wear out your CF too fast. Create an MFS directory for /var:
```
mkdir /mfs
cp -rp /var /mfs/var
```

Similarly for /dev:

mkdir /mfs/dev
cp /dev/MAKEDEV /mfs/dev
cd /mfs/dev
./MAKEDEV all

Add the appropriate lines to /etc/fstab to ensure that /dev and /var get mounted as MFS at boot. Change values for -s and -i as you feel necessary. This works for me a on 1G CF:
```
swap /var mfs rw,-P=/mfs/var,-s=32768,noexec,nosuid 0 0
swap /dev mfs rw,-P=/mfs/dev,-s=8192,-i=128,noexec,nosuid 0 0
```
Now symlink /tmp to /var/tmp so that temporary files can be written to:
```
rm -Rf /tmp
ln -s /var/tmp /tmp
```
Install rsync to handle synchronizing /var. This assumes you've set $PKG_PATH to your favorite local mirror:
```
pkg_add rsync
```
Add a cronjob to periodically sync any changes to /var. I prefer a weekly job. Add something like the following to root's crontab:
```
1  0  */7  *  *  /usr/local/bin/rsync -az --delete /var/ /mfs/var/
```
Finally, edit the shutdown script to sync any unsynchronized changes at shutdown time. Add the following to the end of /etc/rc.shutdown:
```
/usr/local/bin/rsync -vaz --delete /var/ /mfs/var/
```

Thats it. Halt your OpenBSD installation, stop qemu and install the CF in your Soekris. Any further configuration can be done by way of sshd or the serial console, but don't forget the / is mounted read-only, so don't forget to mount it read-write if you need to change something.

Enjoy.

Demystifying Craigslist Anonymization

2007-12-01T13:07:00.000-08:00

Craigslist is one of those services that many people could not live without. Where else can you go to get free palm trees, 40 cubic yards of broken concrete sidewalk, AND get rid of that ugly couch and pick up a date all in one visit?

When Craigslist started, if I had to guess there was little expectation of privacy. When you posted, you entered your "real" email address and your dirty laundry was now in the public eye. At one point they added functionality whereby you could anonymize your posting if you so desired. The functionality was quite simple. At the time of your posting, if you opted to remain anonymous, an email address within craigslist was created -- it took the format of -@craigslist.org. Emails to this address would get relayed to your email address of choice. At some point within the last year or so, the options have changed. Previously, you could chose to be anonymous or not, or even not post any email related contact information whatsoever. You now only have two options -- anonymous or none.

As an example of how this anonymization works, I've posted to the Los Angeles Craigslist "items wanted" section seeking the much desired left handed smoke shifter. The email address sale-495545652@craigslist.org will accept and relay messages to my Gmail account which I keep for these purposes. If you email and I reply, by default you would see my Gmail address, thereby ruining my anonymity. Many Craigslisters, however, are savvy enough to properly set their From: when replying to continue to mask their true identity. For example, in my .muttrc, I have the following:

alternates = .*@spoofed\.org|.*@craigslist\.org

This tells mutt that if I get email to either of those domains, it should set the From: to that of the original To:. You can accomplish something similar in Gmail with the "send mail as" setting.

Unfortunately, Craigslist anonymization only provides a minimal amount of anonymity, but I suspect it serves its original purpose -- to protect the addresses of posters from being harvested by spammers. This should not come as a surprise to anyone who is familiar with how SMTP works, but aside from front-line anonymity, this service is rather trivial to abuse.

For example, if you respond to my posting about the left-handed smoke shifter, I see the following in Gmail:

Date: Sat, 1 Dec 2007 12:46:24 -0800
From: Jon Hart 
To: sale-495545652@craigslist.org
Subject: shifter?

That craigslist.org address forwards all correspondence to my Gmail address. When I reply, the untrained eye will see:

Date: Sat, 1 Dec 2007 12:51:33 -0800
From: Test 
To: Jon Hart 
Subject: Re: shifter?

However, with the exception of pretty much all email services except one that is configured exactly for this purpose, the headers will give away my true identity:

Return-Path: 
Date: Sat, 1 Dec 2007 12:51:33 -0800
From: Test 
Sender: 
To: Jon Hart 
Subject: Re: shifter?

As you can see, if you view the full, unmolested headers of my supposedly anonymous response, the From: is my craigslist relayer, but Return-Path: and Sender: give me away. There are other headers that can give away, most notably X-Original-From:.

I have to stress that this is not really anyone's fault. Craigslist did what you asked -- it masked your email address. Gmail and other services did what you asked -- they set your From: to your craigslist address. When you combine these two services, however, your anonymity is broken.

The lesson here is that if you are a disgruntled employee ranting about your boss, a SWF BBW ISO NSA BDSM from a generous SBM, or other forms of depravity, either create a dedicated email address that cannot be trivially traced to your true identity, or simply don't respond to any emails sent to your supposedly anonymous craigslist email.

Event Correlation on a Budget

2007-11-25T22:48:00.000-08:00

Log management and its wiser, old brother, event correlation, are processes that anyone in the security space is likely very familiar with. I've been dealing with them since day 0, but in the past year or more things have taken a more serious turn. Previously, logs had been used as a last resort and the people capable of wrangling them were much revered. Now there are plenty of standards, books, products and companies that attempt to make sense of your logs, and for good reason -- they are important. Logs will alert you to situations that most traditional monitoring systems would be blind to. Proper log management is necessary if legal action is necessary. There is interesting shit in logs. Really. Look some time.

Lets be honest, though. Even wrangling the logs from your little desktop can be a complicated process -- they'll generate hundreds of logs per day. A relatively unused server will generate upwards of a megabyte of logs per day. An active web, mail or shell server? Millions of entries, several gigabytes of logs in a single day. Now combine the logs from across your entire organization. Information overload.

There are plenty of products you can drop a pretty penny on that will, without a doubt, bring you leaps and bounds from where you very likely sit right now. Some organizations have no log management. Some have centralized logging, but very few have anything further. If you are lucky, some hotshot has a script that tails the logs and looks for very specific error messages which will save your tail.

I am a firm believer in the school of thought that before you go out and drop any sort of significant cash on a security product, you have to go out and really get your hands dirty. For me, that often means seeing what free solutions currently exist, or, worst case, roll your own.

In terms of free (as in beer) solutions, swatch, logwatch, SEC and OSSEC are among the top, the later two being the most powerful. Swatch suffers from lacking any real correlation abilities. Logwatch has some of these capabilities but suffers from essentially using a pile of large, horrifically ugly perl scripts to parse the logs. I've written many ugly perl scripts, and I fear for anyone who is not perl savvy and has to maintain a logwatch setup. SEC and OSSEC have very similar capabilities, though OSSEC is more targeted towards host-based intrusion detection (HIDS) by way of correlating security events within logs. It is a great approach, it is just not the solution that I decided to write about.

What follows is an abridged example of how I used SEC to get some very much needed event correlation up and running in an environment that has anywhere between 500M and 50G of logs per day, depending on how you look at things and who you ask :). I say "abridged" because this ruleset is far from complete. In fact, if you take it as is and set it loose on your logs, you will get a metric crapload of emails about things you probably already know of or otherwise don't care about. The reason here is two-fold. One, I don't want to give away all of my secrets. Two, I cannot tell you what log messages you should or should not care about. That is up for you to learn and decide accordingly.

Save the snippet below as you SEC configuration file and then point SEC at some of the logs you are concerned with. It will give you a base from which you can:

Explicitly ignore certain messages
Alert on certain messages
Do minimal correlation on a per-host, per-service basis

Good luck and enjoy!

# ignore events that SEC generates internally
type=suppress
ptype=RegExp
pattern=^SEC_INTERNAL

# ignore syslog-ng "MARK"s
type=suppress
ptype=RegExp
pattern=^.{14,15}\s+(\S+)\s+-- MARK --

# ignore cron,ssh session open/close
# Nov 23 00:17:01 dirtbag CRON[26568]: pam_unix(cron:session): session opened for user root by (uid=0)
# Nov 23 00:17:01 dirtbag CRON[26568]: pam_unix(cron:session): session closed for user root
# Nov 25 16:19:30 dirtbag sshd[13072]: pam_unix(ssh:session): session opened for user warchild by (uid=0)
# Nov 25 16:19:30 dirtbag sshd[13072]: pam_unix(ssh:session): session closed for user warchild
type=suppress
ptype=RegExp
pattern=^.{14,15}\s+(\S+)\s+(cron|CRON|sshd|SSHD)\[\d+\]: .*session (opened|closed) .*

# alert on root ssh
ptype=RegExp
pattern=^.{14,15}\s+(\S+)\s+(sshd|SSHD)\[\d+\]: Accept (password|publickey) for root from (\S+) .*
desc=$0
action=pipe '$0' /usr/bin/mail -s '[SEC] root $3 from $4 on $1' jhart


# ignore ssh passwd/pubkey success
#
# Nov 24 17:09:22 dirtbag sshd[8819]: Accepted password for warchild from 192.168.0.6 port 53686 ssh2
# Nov 25 16:19:30 dirtbag sshd[13070]: Accepted publickey for warchild from 192.168.0.100 port 57051 ssh2
type=suppress
ptype=RegExp
pattern=^.{14,15}\s+(\S+)\s+(sshd|SSHD)\[\d+\]: Accepted (password|publickey) .*



#############################################################################
# pile up all the su, sudo and ssh messages, alert when we see an error
# stock-pile all messages on a per-pid basis...
# create a session on the first one only, and pass it on
type=single
ptype=RegExp
continue=TakeNext
pattern=^.{14,15}\s+(\S+)\s+(sshd|sudo|su|unix_chkpwd)\S*\[([0-9]*)\]:.*
desc=$0
context=!$2_SESSION_$1_$3
action=create $2_SESSION_$1_$3 10;

# add it to the context
type=single
ptype=RegExp
continue=TakeNext
pattern=^.{14,15}\s+(\S+)\s+(sshd|sudo|su|unix_chkpwd)\S*\[([0-9]*)\]:.*
desc=$0
action=add $2_SESSION_$1_$3 $0;

# check for failures.  if we catch one, set the timeout to 30 seconds from now,
# and set the timeout action to report everything from this PID
type=single
ptype=RegExp
pattern=^.{14,15}\s+(\S+)\s+(sshd|sudo|su|unix_chkpwd)\S*\[([0-9]*)\]:.*fail(ed|ure).*
desc=$0
action=set $2_SESSION_$1_$3 15 (report $2_SESSION_$1_$3 /usr/bin/mail -s '[SEC] $2 Failure on $1' jhart)
#
##########

##########
# These two rules lump together otherwise uncaught messages on a per-host,
# per-message type basis.  The first rule creates the context which is set
# to expire and email its contents after 30 seconds.  The second rule simply
# catches all of the messages that match a given pattern and appropriately
# adds them to the context.
#
type=Single
ptype=RegExp
pattern=^.{14,15}\s+(\S+)\s+(\S+):.*$
context=!perhost_$1_$2
continue=TakeNext
desc=perhost catchall starter for $1 $2
action=create perhost_$1_$2 30 (report perhost_$1_$2 /usr/bin/mail -s '[SEC] Uncaught $2 messages for $1' jhart)

type=Single
ptype=RegExp
pattern=^.{14,15}\s+(\S+)\s+(\S+):.*$
context=perhost_$1_$2
desc=perhost catchall lumper for $1 $2
action=add perhost_$1_$2 $0
#
###########


###########
# These two rules catch all otherwise uncaught messages on a per-host basis. 
# The first rule creates the context which is set to expire and email its
# contents after 30 seconds.  The second rule simpy catches all of the messages
# that match a given pattern and appropriately adds them to the context.
#
type=Single
ptype=RegExp
pattern=^.{14,15}\s+(\S+)\s+\S+:.*$
context=!perhost_$1
continue=TakeNext
desc=perhost catchall starter for $1
action=create perhost_$1 30 (report perhost_$1 /usr/bin/mail -s '[SEC] Uncaught messages for $1' jhart)

type=Single
ptype=RegExp
pattern=^.{14,15}\s+(\S+)\s+\S+:.*$
context=perhost_$1
desc=perhost catchall lumper for $1
action=add perhost_$1 $0
#
###########


###########
# These last two rules act simlar to the above sets, the only exception being that
# they are designed to catch bogus syslog messages.
type=Single
ptype=RegExp
pattern=^.*$
context=!catchall
continue=TakeNext
desc=catchall starter
action=create catchall 30 (report catchall /usr/bin/mail -s '[SEC] Unknown syslog message(s)' jhart)

type=Single
ptype=RegExp
pattern=^.*$
context=catchall
desc=catchall lumper
action=add catchall $0
#
###########

Comcast Information Stupidhighway

2007-11-15T08:26:00.000-08:00

Over the past day or two I've been receiving an increasing amount of attention from the suit against Comcast that names their bittorrent throttling and forgery, among other things, as being against Federal computer fraud laws.

As much as I'd like to be getting this sort of publicity, I'll just come right out and say it. I, Jon Hart, am not the Jon Hart that is currently suing Comcast. In fact, I have never been a customer of Comcast's ISP business, nor do I have any intention of doing so. Furthermore, I'd become homeless on the beach here in sunny Santa Monica and just steal wireless from one of the hundreds of homes that leak 802.11 out to the sand prior to ever stooping so low as to become a Comcast customer. I've seen it done. Heck, I don't discriminate -- AT&T/Timewarner, RoadRunner, and Verizon, you know you are not innocent either.

These ISPs make a healthy profit, and can we blame them for some of their practices? Yes and no.

ISPs make money because they oversubscribe. This is the practice of selling more bandwidth than they have available. Even if you ignore the theoretical limits of the physical medium over which Comcast's cable travels, there are some obvious problems. Comcast offers download speeds from 1-16Mbs. If you combine all of Comcast's customers in a given city or region, if they were all pulling 8-16Mbs, Comcast would become a pool of molten silicon fairly quickly. They rely on the fact that most consumers will never push anything near their capacity, much less for an extended period of time. However, once you get enough customers doing enough ungodly things online at 2am, the chances of Comcast's backbone running into issues skyrocket. The right solution to ensure that you still make your profit is just degrade the "offending" customer's services enough that the probability of exceeding capacity is low enough that the risk is acceptable.

Comcast and other ISPs take things to a new level. Its one thing to rate limit, as this just has to happen for a business based on oversubscription to profit. Forging TCP RST packets or, worse yet, injecting fake messages to tear down or prematurely terminate traffic (primarily P2P) is just downright dirty. Their use of Sandvine allows them to continue to profit while continually bringing on new customers at the expense of a healthy, unadulterated Internet experience. Think thats the worst of it? It isn't. There have been plenty of rumors and various bits of proof that Comcast has been deploying its own nasty brand of DNS redirection, a la SIte Finder, over the past year or so.

Are there other options out there? Sure. DSLExtreme and Speakeasy offer no-bullshit connectivity. They give you bandwidth and leave you the hell alone. In fact, they encourage you to share your connectivity with others, run servers off of you DSL connection and filter none of your inbound or outbound traffic. Its like the Wild West and it is great.

Why do Comcast and others continue to exist? Because far too many Americans are easily duped by all of this "triple-play powerplay", "powerboost", "the fastest Internet", candy coated, re-branded bullshit. Aside from the molestation that happens on Comcast, you still connect to the same Internet that I do. None of the features are unique or better than what already exists everywhere else. Comcast's "The Fan"? Its called Youtube. Sharing Photos? Flickr. And for the love of God, if I see one more "portal" that reminds me of AOL's purple-panel-of-doom, I'm going to hurl.

Do yourself a favor. Support lawsuits like this. Voice your concern and rage to your ISP and talk to others about it. If all else fails, ditch Comcast.

SSL Certificates on Sourcefire DC/3D Systems

2007-11-11T17:28:00.000-08:00

I'm in the process of getting an internal CA off the ground, and on Thursday I found myself totally stumped for a good 6 hours with the Sourcefire systems.

I called support and asked if there was a proper, supported way to get a more official SSL certificate on the devices. To my surprise, there isn't. If you are stuck using a self-signed certificate from a CA you have no business trusting, its almost not even worth using SSL to protect the traffic on the web-based management interface. Since its just all Apache under the hood anyway, I asked if I could do it myself. After several minutes I was told that this is fine, but they could not support anything related to SSL after I went down that road.

Easy enough, I thought. Generate a large private key, generate a CSR, submit the CSR, sign the CSR and drop the new key and certificate on the Sourcefire device in /etc/ssl/server.key and /etc/ssl/server.crt, respectively. Restart apache.

To my total surprise this did not work. Re-copy the correct key and certificate, just to be sure. Same deal. Run the usual certificate and key verification:

openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5

Sure enough, the MD5s are the same. What gives? Tweaking the log levels indicated that I had I definitely had the wrong key, but my commands above proved otherwise. I continued to get the following error message:

x509 certificate routines:X509_check_private_key:key values mismatch
unable to set private key

Lies.

What could it be? A private key that was too large? I tried 4096, 2048 and 1024, and oddly enough 1024 seemed to work. I was furious. Did Sourcefire really configure and ship a system that, for whatever reason, would only function with 1024 bit private keys? I took a coffee break, as I could not fathom how this was possible.

Freshly caffeinated, I took another stab at it. I put my original, 4096 bit key and corresponding certificate back in place and then started disabling the various SSL options that Sourcefire had enabled in Apache's config until I had more information. At one point I screwed up the gcache settings sufficiently enough to kill Apache. When I fixed that and started Apache, things mysteriously started working. This was the key clue. Looking at the init script that ships with Sourcefire, a 'restart' simply sends a HUP, whereas on most other systems it does a synced 'stop' followed by a 'start'.

I have not been able to prove this, but I imagine that either Apache or gcache is caching either the private key or the certificate from its last successful start, but not caching the other. The result is that, despite what you see on disk, the key and certificate that are being used do not match. Believe what you are eyes are showing you, but do not believe what Apache is telling you. A stop and a start are needed.

This is not a Sourcefire specific problem, so I hope someone stumbles upon this and it fixes their problem.

Splunk 0+1 Day -- Good vendor relationships

2007-11-01T22:31:00.000-07:00

A few days ago as part of my many responsibilities I stumbled upon what appeared to be a directory traversal. At first I did not believe it, partially because the specific class of vulnerability is quite dated and partially because I couldn't believe that I had been working with this product for so long and hadn't stumbled upon it.

Unfortunately, Splunk is about 170Mb of python, shell scripts and stripped binaries, so debugging this was no easy task. I actually thought I got lucky and traced the problem to an old version of TwistedWeb that Splunk uses to power the web server, but it turns out I was wrong. Furthermore, finding a python HTTP project that used an equally old version of TwistedWeb was basically impossible, so I was stranded.

At around the same time I opened an FYI ticket with Splunk giving them a heads up. Not only did they appreciate the information, they followed the TwistedWeb ticket and quickly determined that this was their bug, not Twisted's. A patch was quickly published and it is an easy update for anyone who is crazy enough to expose their Splunk server to the outside world.

This a great example of two things.

First, old bugs die hard. This was a classic example of a URI encoded directory traversal (%2e%2e%2f %2e%2e%2f %2e%2e%2f, aka '../../../../'), which Wikipedia describes fairly well. Exploiting this requires no authentication and simply requires that you have an HTTP client and the ability to reach the Splunk server.

Second, it is important to have a mechanism within your organization that allows security information to be channeled to the correct people in a timely manner. How many times can you recall where you call or email vendor XYZ and they basically refuse to speak to you unless you are a paying customer? Not addressing security issues in your products not only makes you look bad in the eyes of the security community, it also damages your brand and puts your paying customers at risk. Splunk is a great example of process done right.

Security is you friend.

USPS -- the biggest spammers of all

2007-09-18T23:05:00.000-07:00

Not too long ago I moved into a new apartment. In my previous digs I had lucked out and befriended the daily postman who volunteered to filter out the junkmail and circulars. While I got the occasional flyer from the local supermarket, my mailbox was more or less unmolested.

Fast forward today. I received the following junkmail:

EZ Lube (West Coast Oil change / service facility)
Party America. I forgot. It is now September which means send me some crap about Halloween.
Circulars from Albertsons, Vons, Ralphs, Wild Oats, Smart and Final, and Pavilions. 6 grocery stores.

This happens several times per week and the contents vary. Those large krinkley envelopes with 800 coupons inside are a common occurrence as are things for elderly citizens. Today's bundle was the recycled equivalent of 36 8-1/2"x11" sheets of paper. If you take the bundle, stack it neatly and roll it tightly, it is the rough equivalent of a 12" long, ~1/4-1/2" diameter piece of wood. If I saw some guy walking down the street throwing 3 dozen sheets of paper or lopping a branch off of every tree at every house, it would take about half a dozen houses before I'd bust out some Chuck Norris moves and do the world a favor by running him down in my Jeep.

This has been going on basically since I moved in, and this is not the first place I've experienced this sort of blatant spamming. All it takes is one resident at some point in time to give their address, and all other future tenants at or near that address will be bombarded with every piece of imaginable snail mail spam, 5-6 days per week rain or shine.

I've actually considered submitting a change of address form for "Resident" at my current address, as most of this garbage seems to come addressed to something like that. "Valued Customer", even. I'm not sure where I'd send it to, but I think the local recycling facility would be the equivalent of /dev/null and all of this shit would go directly back to recycling.

"Just unsubscribe", you say. Right. There are dozens of companies contracted to gather data from the USPS almost entirely for the purpose of targeted mailings. Want to send mail to every postal customer in 90210? Sure, the USPS will let you do that, but it'll cost you. All postal addresses with a likely Latino name ending in "ez"? Sure. That'll be $99.95 per 500 addresses. It is a losing battle for those on the receiving end.

Imagine if something similar happened in the electronic world. The offending party would quickly be blacklisted, banned, dropped, slapped about, or otherwise publicly embarrassed within hours of the incident. Why doesn't this happen in the physical mail delivery world? At least in the United States, this is because the USPS has complete control over all aspects of mail delivery. A monopoly, if you will. Checkmate.

The strange thing, at least to me, is that there is no program that I know of that the USPS offers that allows you to enable junkmail filtering. Lets say such a mythical beast cost $5 month. Would you pay it? I would. In a heartbeat. Turn that $5 on its heels -- does the USPS gain $5 from those who send the flyers? Over the course of a month for a single postal address, I'm going to say it cost considerably less than that to send flyers. I would be very surprised if the USPS could not make a considerable profit by enabling customers to filter their incoming snail mail.

Are things in other countries any different? I'd like to think so. Even within the US, you can see vast differences in postal vs. package delivery. When was the last time you received snail mail spam from... DHL, UPS or FedEx? Probably never.

In the short term, I have deployed greylisting on my USPS approved mailbox. Several strips of duct-tape fastened over the entrance with a slit sufficient for your average business letter envelope to be crammed through. Anything else, tough.

Post BlackHat 2007 / DefCon 15

2007-08-08T19:54:00.000-07:00

This is the trendy thing to do. Its the first full week of August and everyone is just getting back from BlackHat and DefCon -- its blogging time. A race to see who gets up the most informative, complete synopsis of the festivities. Me? There is no race because its the same old shit.

OK, thats not completely fair. There was some new and cool things presented at the aforementioned cons, but I've got two gripes.

One, much of the security conference space is very, very incestuous to the point where it is reasonable to assume that 25+% of the presentations that occur at cons in the mainland United States, or make slashdot, have already been presented somewhere else within the past 6 months or will be recycled again before the year is up. If a given presentation doesn't strictly fall within that 25% bracket, there is a very good chance that it is just a modified or updated talk from the past year. I didn't drive 4 hours across the 110 degree desert for you to take $2k of my money only to chew my ear off for approximately an hour on a subject that is, at least among the clued in the security space, almost common knowledge. NAC is broken?! If you transmit cookies in the clear but content encrypted, you will be embarrassed?! Say it ain't so!

Secondly, this presents a unique situation for me with my employer and others like me. Sure, there were more than a few "new things" that we have to worry about in our day to day jobs, but in all honesty, many shops still have yet to master the basics. Many places that I know of or have been in are still struggling with the concept of why "security by obscurity" is a bad idea and plain-text protocols. While this adds more proverbial fuel to the proverbial fire, it does little to help us improve the security of our organization.

Don't get me wrong, I was very pleased with Blackhat this year. DefCon too. 9 days in Vegas can really start to get to you, but that is why god invented Shark Week. I ended up bailing early in the hopes of re-acclimating to Los Angeles before starting work again. To those that I did not see because of my anti-social behavior, I'll make it up to you.

Privacy Guard -- Not so private

2007-06-16T15:46:00.000-07:00

I've been a member of Privacy Guard for longer than I can remember. While some may argue that the $100-200 year fee is too much, what is your privacy and identity worth to you? The biggest value to me has been to track my credit score and do "what if" simulations to see how I can financially better myself.

Over the past several months Privacy Guard has really started to irritate me. Every month or so I'll get something that appears to be a check from Privacy Guard issued to me for some amount, typically $10-20. Upon reading the fine print you'll see that by signing and cashing the check you automatically sign yourself up for an additional year of Privacy Guard service. So instead of paying $199.99 willingly for an additional year of service, you cash the check thinking (stupidly) that it is $10 free, when it actually just gets you $10 off your service.

This is not behavior I would expect from a company that is supposedly dedicated to protecting the privacy and security of one's identity.

Just when I thought things couldn't get any more ridiculous, I get another "check" for $10 with an enclosed "2007 Opinion Poll". This poll blatantly says:

"You are being asked to participate in this opinion poll. Won't you please take a moment to share your opinions? A few minutes of your time WILL ASSIST IN PROVIDING SERVICES THAT MEET YOUR NEEDS AND DESIRES" (emphasis added)

OK, seriously, what gives? Privacy Guard is coming right out and saying that they are going to sell your information.

Some sample poll questions:

How often do you shop online?
How do you usually purchase flowers?
Where do you purchase your music?
What time of year do you prefer to vacation?
What's the MOST you would pay for a hotel room?
How often do you fly?
Do you purchase items from airport gift shops?
Which of the following activities do you enjoy?
Which cuisines do you enjoy?
How much do you pay for a bottle of wine?
About how many hours of television do you watch each day?
What is the model year of your car?
About how many miles do you put on your car each year?
Do you own your home or rent?
Have you ever hired a housekeeper?
Do you have a cell phone?
Do you have a computer?
How many pets do you have?
Do you play golf?
Which area of the country do you consider most desirable for retirement?

This makes me sick. Privacy Guard is not only obviously selling their customer's data, but is also gathering further personal information to allow the people buying my information to target their spam emails, snail mail and phone calls for things I am specifically interested in.

I am officially canceling Privacy Guard today and will be sending a hand written letter to them describing my disgust. I advise others to do the same. That is, of course, if you value the security of your identity. If not, by all means fill this out. Heck, while you are at it, attach a piece of paper with your Mother's maiden name, name of your first pet, year of High School and College Graduation and City in which you were born.