Don't Panic Tech

Defcon 19 Packet Challenge - Level 6

2011-08-28T19:58:00.005-07:00

The last ingredient is stored away in Dr. Creedence Clearwater's private Truecrypt volume. On his hard drive there was a file titled "cipher". Perhaps it contains a clue that you can use to unlock the volume and help Inter0ptic find out the last ingredient.

1) What is the final ingredient?

This one took a short while to figure out what the cipher.txt was telling us.

chester@bluestem:~/DRILL$ cat cipher.txt

1-2 5-1 3-8 4-1 1-3 2-3 1-1 3-5 5-5 4-7

It not-so-quickly dawned on me that the first number in each pair was 1-5, and we had 5 previous answers. So, the second number must be which character from the previous passwords to use.

After working that out, the answer was found to be: 00gmu1rt#?

Using that key to open the Truecrypt volume, you find a file named “133t pill” with the following message:

Dear Inter0ptic,

If you are reading this message, then you must have escaped. Congrats. You didn't think that I was going to let you have the ingredients to the 133t pill, did you? As you have probably guessed, I obtained the creditcard numbers and the ingredients of the 133t pill myself, and sold them for a very nice profit.

Just in case you are curious, the missing ingredient for the 133t pill was "2oz Vodka."

It was great workin with you, my pawn.

XOXO,

Ann

And so the final answer is “20z Vodka”

Defcon 19 Packet Challenge - Level 5

2011-08-28T19:58:00.003-07:00

The network at Factory-Made-Winning had been acting strange all day and Tim was getting very concerned what was happening at his company. He began looking over some traffic....

Use the packet capture in this folder to help Tim find out what's happening:

1) What is the 3rd ingredient on the list from the mysterious file that was transfered?

This is pretty much the same process as the last challenge. The only difference is a new file. In this case the file is “\ingredients-list-133t-pi11.7z”. This time the password is the word that the attacker found on a sticky note : useonce@.

chester@bluestem:~/DRILL/05$ tcpdump -s0 -r Evidence05.pcap -w SMB.cap port 445

chester@bluestem:~/DRILL/05$ tshark -r SMB.cap | grep "Create AndX Request"

12 0.007632 172.30.1.90 -> 172.30.1.214 SMB NT Create AndX Request, Path: \srvsvc

39 3.045251 172.30.1.90 -> 172.30.1.214 SMB NT Create AndX Request, Path:

44 3.060912 172.30.1.90 -> 172.30.1.214 SMB NT Create AndX Request, Path: \desktop.ini

47 3.062061 172.30.1.90 -> 172.30.1.214 SMB NT Create AndX Request, Path:

66 6.659435 172.30.1.90 -> 172.30.1.214 SMB NT Create AndX Request, Path: \Thumbs.db

69 8.996870 172.30.1.90 -> 172.30.1.214 SMB NT Create AndX Request, Path:

73 9.002135 172.30.1.90 -> 172.30.1.214 SMB NT Create AndX Request, Path: \ingredients-list-133t-pi11.7z

chester@bluestem:~/DRILL/05$ tcpxtract -c /etc/tcpxtract.conf -f SMB.cap

Found file of type "p7z" in session [172.30.1.214:48385 -> 172.30.1.90:25280], exporting to 00000000.p7z

Opening the file, you can find the password : 8.4 oz- Red Bull

Defcon 19 Packet Challenge - Level 4

2011-08-28T19:58:00.001-07:00

Inter0ptic arrived to Factory-Made-Winning, and casually made his way past the front security desk. He then slipped into a secure access area by tailgating behind an employee. On the way in he found a sticky note with a password on it "useonce@". The password might come in handy later! With a grin and a chuckle, Inter0ptic found an empty cubical and plugged in his laptop.

Use the packet capture in this folder to learn more about Inter0ptic's adventure at the pharmaceutical company and answer the question below:

1. What is the 16th name inside the mysterious file transfered?

Very early in the pcap you will notice some SMB traffic. I started there. First I created a new pcap with only the port 445 traffic. Then I ran it through tshark to decode and see what we could find. I found a file name CCfiles.7z.

carl@bluestem:~/DRILL/04$ tcpdump -s0 -r Evidence04.pcap -w SMB.cap port 445

reading from file Evidence04.pcap, link-type EN10MB (Ethernet)

chester@bluestem:~/DRILL/04$ tshark –r SMB.cap

48 6.157845 172.30.1.214 -> 172.30.1.90 SMB NT Create AndX Response, FID: 0x8003

49 6.158411 172.30.1.90 -> 172.30.1.214 SMB Close Request, FID: 0x8003

50 6.158476 172.30.1.214 -> 172.30.1.90 SMB Close Response, FID: 0x8003

51 6.163547 172.30.1.90 -> 172.30.1.214 SMB NT Create AndX Request, Path: \CCfiles.7z

52 6.163652 172.30.1.214 -> 172.30.1.90 SMB NT Create AndX Response, FID: 0x8004

53 6.163945 172.30.1.90 -> 172.30.1.214 SMB Trans2 Request, QUERY_FILE_INFO, FID: 0x8004, Query File Internal Info

This time we’ll use tcpxtract by Nick Harbour.

chester@bluestem:~/DRILL/04$ cat /etc/tcpxtract.conf

p7z(5000000, \x37\x7a\xbc\xaf\x27\x1c);

chester@bluestem:~/DRILL/04$ tcpxtract -c /etc/tcpxtract.conf -f SMB.cap

Found file of type "p7z" in session [172.30.1.214:48385 -> 172.30.1.90:4032], exporting to 00000000.p7z

I tried to decompress the 7zip with p7zip, but I got unsupported method error. It appears to be due to a password protection on the file. I copied the file over to windows and used 7zip there to decompress. It opened fine there and prompted me for a password. I first tried useonce@ but failed. Then I tried Romulus password from challenge 3 and it was correct. Inside is an xls file.

chester@bluestem:~/DRILL/04$ p7zip -d 00000000.p7z

p7zip Version 9.04 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,1 CPU)

Processing archive: 00000000.p7z

Extracting CCfiles.xlsx Unsupported Method

Sub items Errors: 1

Scrolling down to the 16^th line inside the XLS file, you get the answer: Jason Wilson

Defcon 19 Packet Challenge - Level 3

2011-08-28T19:57:00.001-07:00

A mysterious call is made to Romulus (a new accounts manager) at Factory-Made-Winning.

Use the packet capture in this folder to learn more about the phone call and answer the following question:

1. What is Romulus' password?

I opened the pcap in Wireshark first, but it did not identify any voip converstaions. I then tried xplico:

carl@bluestem:~$ ./xplico -m pcap -f /home/chester/DRILL/Evidence03.pcap

xplico v0.6.3

Internet Traffic Decoder (NFAT).

Cap. time: Thu Jun 23 13:40:49 2011

Total elaboration time: 4s

carl@bluestem:~$ ls xdecode/172.30.1.101/http/74.125.224.116

http_rs_body_1314482374_0xa51a2a8_1 post

carl@bluestem:~$ cat http_rs_body_1314482374_0xa51a2a8_1

relay.ip=74.125.127.126

relay.udp_port=19295

relay.tcp_port=19294

relay.ssltcp_port=443

stun.ip=74.125.127.126

stun.port=19302

username=1ZUfriXYKVltcU72

password=IyUDFIcH1JL8Ho8N

magic_cookie=rÆKÆ

Not a smoking gun, but the ip 74.125.127.126 is owned by google, so we’re probably looking at googlechat voip call. After some searching I found that xplico can take advantage of a tool called videosnarf to decode VOIP calls. I set up this tool and ran it on its own.

carl@bluestem:~$ videosnarf -i Evidence03.pcap

added new stream. :172.30.1.101(56213) to 74.125.127.126(19295). codec is 00

added new stream. :74.125.127.126(19295) to 172.30.1.101(56213). codec is 00

[+]Stream saved to file G711ULAW-media-1.wav

[+]Stream saved to file G711ULAW-media-2.wav

Bingo. If you listen to the G711ULAW wav files, you can hear both sides of a staged social-engineering call to Romulus. He willingly gives over his password to the caller.

Answer: rom127#

Defcon 19 Packet Challenges - Level 2

2011-08-28T19:56:00.000-07:00

Ann, afraid that someone may be watching her, decides to capture all of her home traffic. She mentions her fear to Mr. X and explains that she has been capturing her home traffic for days and will be sending the packets out for analysis later in the day. She sends her captures to the one person she knows can trust. After their discussion, Mr. X rushes to his lab, to see if he can intercept Ann's outbound message and use her capture to get more detail on her upcoming activities..

1. What is the date, as it appears in the capture, of the cryptographer's speaking engagement? (hint: It isn't at Defcon)

This one was slightly more difficult. The scenario says Mr X. is trying to capture Ann’s message, so I went looking for emails. First I used tcpflow to dump all the network conversations into separate files. This probably could have been easier by using NetworkMiner or NetWitness, but I preferred to work on these on a Linux shell.

carl@bluestem:~$ tcpflow -r Evidence02.pcap

Then I searched for the word “Subject” in the resulting files, since that should be in any Email. One hit stood out:

carl@bluestem:~$ grep -a Subject *

172.030.001.100.51805-205.188.192.001.00080:

From":"ann1smysterious@aol.com","To":"d_tangent@aol.com,","Cc":"","Bcc":"","Subject":"My Trusted Friend","RichBody":"You are the only one that I can trust. I need to know if someone monitoring me. Attached is a capture of my traffic

As the scenario said, Ann sent a pcap to a person she could trust. Let’s get that pcap. Using foremost, the magic number for a pcap is 0xd4c3b2a1.

carl@bluestem:~$ cat /etc/foremost.conf

pcap n 5000000 \xd4\xc3\xb2\xa1

carl@bluestem:~$ foremost -c /etc/foremost.conf -i 172.030.001.100.51805-205.188.192.001.00080

Processing: 172.030.001.100.51805-205.188.192.001.00080

|*|

carl@bluestem:~$ file output/pcap/00000030.pcap

output/pcap/00000030.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)

This is the Help.pcap plus some extra data on the end, since we didn’t specify a specific file size. Tcpdump will still parse the file.

A quick look around this cap and we see the site of a well-known cryptographer (remember we are looking for the date of a cryptographer’s speaking engagement).

carl@bluestem:~$ tcpdump -nn -r Help.pcap -A -s0 port 80 | grep Host | sort | uniq

Host: www.schneier.com

Looking at the pcap, we determine the IP of schneier.com to be 204.11.246.48, so we can focus on that. Once again, tcpflow to break up this pcap into parse-friendly conversations.

carl@bluestem:~$ tcpflow -r Help.pcap host 204.11.246.48

carl@bluestem:~$ grep GET *

172.030.001.100.60176-204.011.246.048.00080:GET /schedule.html HTTP/1.1

Looks promising. So, we’ll use the other half of this file that matches this request to get the response.

carl@bluestem:~$ head 204.011.246.048.00080-172.030.001.100.60176 (server response)

HTTP/1.1 200 OK

Date: Wed, 22 Jun 2011 21:05:31 GMT

Server: Apache

Vary: User-Agent,Accept-Encoding

Last-Modified: Tue, 17 May 2011 01:51:36 GMT

ETag: "e78-4a36f03207a00"

Accept-Ranges: none

Content-Encoding: gzip

Gzipped data. So we’ll use foremost again to carve the gzip file.

carl@bluestem:~$ cat /etc/foremost.conf

gz n 50000 \x1f\x8b

carl@bluestem:~$ foremost -c /etc/foremost.conf -i 204.011.246.048.00080-172.030.001.100.60176

Processing: 204.011.246.048.00080-172.030.001.100.60176

|*|

carl@bluestem:~$ file output/gzip/00000000.gzip

output/gzip/00000000.gzip: gzip compressed data, from Unix

Gunzip it and inside we have an HTML file. And searching the html file, we find:

Global AppSec Latin America 2011 Conference

October 6-7, 2011

Keynote

Answer: October 6-7, 2011

Defcon 19 Packet Challenges - Level 1

2011-08-28T19:50:00.000-07:00

The challenges can be found here: http://forensicscontest.com/2011/08/16/puzzle-9-anns-deception-defcon-2011 THERE ARE SPOILERS ON THIS PAGE.

I didn't attempt these challenges while at the conference, but I finally sat down to do them this weekend. They were pretty straightforward and didn't give me too many WTF moments. I intentionally used Linux tools and avoided some tools that could have made this challenge very easy, namely NetworkMiner and Netwitness. These are both great tools but I wanted to get some practice with a few others.

After Mr. X learns that Ann has been in contact with Inter0ptic, he begins to wonder about their relationship, and decides to monitor Ann's network traffic.

1. What is the name of the Company being attacked?

This one is an easy one. Luckily I picked the word “company” pretty early in my guessing and came to the answer quickly.

carl@bluestem:~$ strings Evidence01.pcap | grep -i company

nt-size%3A%2010pt%3B%20color%3A%20black%3B%5C%22%3E-----Original%20Message-----%3Cbr%3E%5CnFrom%3A%20Ann%20Imal%20%26lt%3Bann1smysterious%40aol.com%26gt%3B%3Cbr%3E%5CnTo%3A%20inter0pticon%20%26lt%3Binter0pticon%40aol.com%26gt%3B%3Cbr%3E%5CnSent%3A%20Fri%2C%20Jul%2015%2C%202011%202%3A45%20pm%3Cbr%3E%5CnSubject%3A%20Re%3A%20Tip%3Cbr%3E%5Cn%3Cbr%3E%5Cn%5Cn%5Cn%5Cn%5Cn%5Cn%5Cn%3Cdiv%20id%3D%5C%22AOLMsgPart_1_e7a3f7f4-b5d1-49c1-b77e-d4d8f5388d6c%5C%22%3E%5Cn%5Cn%3Cfont%20color%3D%5C%22black%5C%22%20face%3D%5C%22arial%5C%22%20size%3D%5C%222%5C%22%3E%3Cfont%20color%3D%5C%22black%5C%22%20face%3D%5C%22arial%5C%22%20size%3D%5C%222%5C%22%3E%5Cn%5Cn%5Cn%3Cdiv%3E%20%3Cbr%3E%5Cn%5Cn%5Cn%3C%2Fdiv%3E%5Cn%5Cn%5Cn%5Cn%5Cn%5Cn%3Cdiv%3E%20%3Cfont%20color%3D%5C%22black%5C%22%20face%3D%5C%22arial%5C%22%20size%3D%5C%222%5C%22%3E%3Cfont%20size%3D%5C%222%5C%22%3E%3Cfont%20face%3D%5C%22Arial%2C%20Helvetica%2C%20sans-serif%5C%22%3ENext%5Cn%20week%2C%20you%20will%20travel%20to%20Metropia%2C%20where%20%5CnFactory-Made-Winning-Pharmaceuticals%20is%20headquartered.%26nbsp%3B%20You%20will%20break%20%5Cninto%20the%20company's%20customer%20credit%20card%20database%20and%20retrieve%20the%20card%20%5Cnnumbers.%26nbsp%3B%20%3Cbr%3E%5Cn%5Cn%5Cn%3Cbr%3E%5Cn%5Cn%5CnAnn%3C%2Ffont%3E%3C%2Ffont%3E%3C%2Ffont%3E%5Cn%3C%2Fdiv%3E%5Cn%5Cn%5Cn%5Cn%5Cn%5Cn%3Cdiv%20style%3D%5C%22clear%3A%

Answer: Factory-Made-Winning-Pharmaceuticals

Ghostintheshellcode Stage 14 TootsieRoll Packet 175 pts

2011-02-21T13:20:00.000-08:00

Stage 14
Question: TootsieRoll
175 Points
What is the password?

File: tootsieroll-4fafc83198440078a616080e3d44419c

carl@b:~/tootsie$ file tootsieroll-4fafc83198440078a616080e3d44419c
tootsieroll-4fafc83198440078a616080e3d44419c: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)

Dump the payloads with tcpflow:

carl@b:~/tootsie$ tcpflow -r tootsieroll-4fafc83198440078a616080e3d44419c
carl@b:~/tootsie$ ls -al
-rw-r--r-- 1 carl carl 180 2011-02-21 16:20 127.000.000.001.01337-127.000.000.001.50451
-rw-r--r-- 1 carl carl 676 2011-02-21 16:20 127.000.000.001.50451-127.000.000.001.01337

carl@b:~/tootsie$ file 127*
127.000.000.001.01337-127.000.000.001.50451: ASCII text, with no line terminators
127.000.000.001.50451-127.000.000.001.01337: ASCII text, with very long lines, with no line terminators

carl@b:~/tootsie$ more 127.000.000.001.01337-127.000.000.001.50451
WGB6bWljNw==UWd9KHxgYWZjKHxgbXEvem0ob2dhZm8ofGcoan17fCh9ezc=XGBtKHhpe3t/Z3psKHxgaXwoe3xpenx7KH9hfGAoNGNtcTZdO0pkUTpkYGpLSkpS
Ol59bEs0J2NtcTYkKGp9fChhKG5nem9nfCh8YG0oem17fDc=R2YoYXwp

carl@b:~/tootsie$ more 127.000.000.001.50451-127.000.000.001.01337
R2p2Iy9meyh8L2JqIQ==RihiL2l9am5kZmFoLi9FYGp2L3hufGEoey9ibmRmYWgvZnsven8uL0dqL31qbmNjdi9nbmxkamsvZmF7YC9KY2NmYWh8YGEuL0dqL2hu
eWovYmove2dqL2tmfGwveGZ7Zy9uL2lmY2ovZ2ovbGB/ZmprL25hay9hYHgvRihiL2ZhL2VuZmMuL1tnanYofWovbGdufWhmYWgvYmoveGZ7Zy98YGJqL3xqfWZg
enwvfGdmey4vTmFrL3tnan1qKHwvfHt6aWkvRi9rZmthKHsvanlqYS9rYCMvY2Zkai9mYXxqfXtmYWgvfGBiai95Zn16fC9sbmNjamsvS24vWWZhbGYjL25hay97
Z2p2L2Rqan8vbnxkZmFoL25tYHp7L3Zgei9oenZ8IQ==VmpuZy4vVmB6L21qe3tqfS9pZmh6fWovYHp7L3hnbnsofC9gYS97Z257L2tmfGwjL2xuenxqL3hqKH1q
L21qZmFoL2l9bmJqayEvRnsofC9mYS97Z257L39jbmxqL3hnan1qL0Yvf3p7L3tnbnsve2dmYWgve2duey97ZmJqL3hme2cve2duey9/bnx8eGB9ay4=S3pnIy9m
ey9qYWt8L3hme2c1LzNkanYxTnZCW0Z7QVtaPkNbZD9AW14yMyBkanYx

Looks like base64:

carl@b:~/tootsie$ cat 127.000.000.001.50451-127.000.000.001.01337 | base64 -d
Gjv#/f{(|/bj!F(b/i}jndfah./E`jv/xn|a({/bndfah/f{/./Gj/}jnccv/gnldjk/fa{`/Jccfah|`a./Gj/hnyj/bj/{gj/kf|l/xf{g/n/ifcj/gj/lfjk/nak/a`x/F(b/fa/enfc./[gjv(}j/lgn}hfah/bj/xf{g/|`bj/|j}f`z|/|gf{./Nak/{gj}j(|/|{zii/F/kfka({/jyja/k`#/cfdj/fa|j}{fah/|`bj/yf}z|/lnccjk/Kn/Yfalf#/nak/{gjv/dj/n|dfah/nm`z{/v`z/hzv|!Vjng./V`z/mj{{j}/ifhz}j/`z{/xgn{(|/`a/{gn{/kf|l#/lnz|j/xj(}j/mjfah/i}nbjk!/F{(|/fa/{gn{cnlj/xgj}j/Fz{/{gn{/{gfah/{gn{/{fbj/xf{g/{gn{n||x`}k.Kzg#/f{/jak|/xf{g5/3djv1NvB[F{A[Z>C[d?@[^23 djv1carl@b:~/tootsie$ cat 12ls -al^C
carl@b:~/tootsie$ cat 127.000.000.001.01337-127.000.000.001.50451 | base64 -d
X`zmic7Qg}(|`afc(|`mq/zm(ogafo(|g(j}{|(}{7\`m(xi{gzl(|`i|({|iz|{a|`(4cmq6];JdQ:d`jKJJR:^}lK4'cmq6$(j}|(a(ngzog|(|`m(zm{|7Gf(a|)carl@b:~/tootsie$ cat 127.000.000.001.50451-127.000.000.001.01337 | base64 -d > file.out
carl@b:~/tootsie$ cat 127.000.000.001.01337-127.000.000.001.50451 | base64 -d > file2.out

XOR is pretty common. Didier Stevens tool XORSearch makes it easy to look for text that might be XORed. You can find it here: http://blog.didierstevens.com/programs/xorsearch/
The word "pass" was a lucky first guess:

carl@b:~/tootsie$ xorsearch file.out pass
Found XOR 0F position 01BD: password!Duh, it ends with: AyMTItNTU1LTk0OTQ
carl@b:~/tootsie$ xorsearch file2.out pass
Found XOR 08 position 002E: password that starts with U3BlY2lhbCBBZ2VudC<

Cat those two strings together and you get a base64 encoded string that you can decode:

carl@b:~/tootsie$ echo "U3BlY2lhbCBBZ2VudCAyMTItNTU1LTk0OTQ" | base64 -d
Special Agent 212-555-9494

The key is "Special Agent 212-555-9494"

Ghostintheshellcode Stage 1 apd Forensics 100pts

2011-02-21T13:09:00.000-08:00

Stage 1
Question: apd
100 Points

Who?
File:apd-d54c4e84df46239dd

carl@b:~/apd/$ file apd-d54c4e84df46239ddd453f19909468c3
apd-d54c4e84df46239ddd453f19909468c3: gzip compressed data, from Unix, last modified: Sun Dec 26 14:06:22 2010

carl@b:~/apd/$ tar zxf apd-d54c4e84df46239ddd453f19909468c3

carl@b:~/apd/$ ls -al | more
total 9668
drwxr-xr-x 2 carl carl   20480 2011-02-21 15:36 .
drwxr-xr-x 3 carl carl   20480 2011-02-21 15:34 ..
-rw-r--r-- 1 carl carl   19354 2010-12-26 14:06 0002abbac6e704c7196509c2bdfc61c6
-rw-r--r-- 1 carl carl   19772 2010-12-26 14:06 01149038c6aac54204c2850f5f8104c9
-rw-r--r-- 1 carl carl   19772 2010-12-26 14:06 01bf66971ba7601dc9bd99b2e9c38c90
-rw-r--r-- 1 carl carl   19354 2010-12-26 14:06 023326ab4a8cbcc4494485bb2d4997c9
-rw-r--r-- 1 carl carl   19355 2010-12-26 14:06 0390f811e8ed5846d3cac7f8b4c8ad23
-rw-r--r-- 1 carl carl   19772 2010-12-26 14:06 03ced4264f06a6e2a35e5fa950bece65
-rw-r--r-- 1 carl carl   19354 2010-12-26 14:06 04869a26051364f0c308eefd562ab8e4
-rw-r--r-- 1 carl carl   19354 2010-12-26 14:06 06966a475ca30d06421f1e662dad4fda
-rw-r--r-- 1 carl carl   19354 2010-12-26 14:06 08bf0534c5168bfc2e020269e90bf9b3
-rw-r--r-- 1 carl carl   19355 2010-12-26 14:06 09aa52fff54918a33c397e44efcf4339
-rw-r--r-- 1 carl carl   19354 2010-12-26 14:06 09ed6bd70d00ef97e6a4c8bc89249613

[...]

MP3s.. rock out!

carl@b:~/apd/$ file *
0002abbac6e704c7196509c2bdfc61c6:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
01149038c6aac54204c2850f5f8104c9:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
01bf66971ba7601dc9bd99b2e9c38c90:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
023326ab4a8cbcc4494485bb2d4997c9:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
0390f811e8ed5846d3cac7f8b4c8ad23:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
03ced4264f06a6e2a35e5fa950bece65:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
04869a26051364f0c308eefd562ab8e4:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
06966a475ca30d06421f1e662dad4fda:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
08bf0534c5168bfc2e020269e90bf9b3:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
09aa52fff54918a33c397e44efcf4339:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
09ed6bd70d00ef97e6a4c8bc89249613:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
0bfc1634806148c28b7a375b85b95e44:     MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, Stereo
[...]

So obviously we had a bunch of really short mp3s. It was obvious they were spliced up from the same sample. So, we had to reconstruct them. Lets check the metadata:

carl@b:~/apd/$ exiftool 107deef8d71148a6f2d27d82918fd5fe
ExifTool Version Number         : 8.15
File Name                       : 107deef8d71148a6f2d27d82918fd5fe
Directory                       : .
File Size                       : 19 kB
File Modification Date/Time     : 2010:12:26 14:06:20-05:00
File Permissions                : rw-r--r--
File Type                       : MP3
MIME Type                       : audio/mpeg
MPEG Audio Version              : 1
Audio Layer                     : 3
Audio Bitrate                   : 128000
Sample Rate                     : 44100
Channel Mode                    : Stereo
MS Stereo                       : Off
Intensity Stereo                : Off
Copyright Flag                  : False
Original Media                  : True
Emphasis                        : None
ID3 Size                        : 128
Title                           : R2hvc3RJblRoZVNoZWxsY29kZSAK
Artist                          : VElNRTogMTQ6MDY6MjAK
Album                           : V2UgYXJlIHdhdGNoaW5nIHlvdSAK
Year:
Comment                         : R2l0cy0wNDUK
Genre                           : None
Date/Time Original              :
Duration                        : 1.20 s (approx)

Title, Artist, Album and Comment are all encoded. They happen to be base64. Looking at all of the files, the Title and Album are the same. The artist varies only slightly.

carl@b:~/apd/$ exiftool * | grep Title | sort | uniq -c
    250 Title                           : R2hvc3RJblRoZVNoZWxsY29kZSAK

carl@b:~/apd/$ echo "R2hvc3RJblRoZVNoZWxsY29kZSAK" | base64 -d
GhostInTheShellcode

carl@b:~/apd/$ exiftool * | grep Album | sort | uniq -c
    250 Album                           : V2UgYXJlIHdhdGNoaW5nIHlvdSAK

carl@b:~/apd/$ echo "V2UgYXJlIHdhdGNoaW5nIHlvdSAK" | base64 -d
We are watching you

carl@b:~/apd/$ exiftool * | grep Artist | sort | uniq -c
     91 Artist                          : VElNRTogMTQ6MDY6MjAK
     94 Artist                          : VElNRTogMTQ6MDY6MjEK
     22 Artist                          : VElNRTogMTQ6MDY6MjIK
     43 Artist                          : VElNRTogMTQ6MDY6MTkK

carl@b:~/apd/$ echo "VElNRTogMTQ6MDY6MjAK" | base64 -d
TIME: 14:06:20
carl@b:~/apd/$ echo "VElNRTogMTQ6MDY6MjEK" | base64 -d
TIME: 14:06:21
carl@b:~/apd/$ echo "VElNRTogMTQ6MDY6MjIK" | base64 -d
TIME: 14:06:22
carl@b:~/apd/$ echo "VElNRTogMTQ6MDY6MTkK" | base64 -d
TIME: 14:06:19

Though the comments are all different:

carl@b:~/apd/$ for i in `ls`; do exiftool $i | grep Comment; done
Comment                         : R2l0cy0wNTcK
Comment                         : R2l0cy0wMjEK
Comment                         : R2l0cy0yMDAK
Comment                         : R2l0cy0wNDMK
Comment                         : R2l0cy0yNDEK
Comment                         : R2l0cy0wNTkK
Comment                         : R2l0cy0wODQK
[...]

carl@b:~/apd/$ for i in `ls`; do exiftool $i | grep Comment | awk '{print $3}' ; done
R2l0cy0wNTcK
R2l0cy0wMjEK
R2l0cy0yMDAK
R2l0cy0wNDMK
R2l0cy0yNDEK
R2l0cy0wNTkK
[...]

Decode the comments and we get some numbers that we can sort:

carl@b:~/apd/$ for i in `ls`; do exiftool $i | grep Comment | awk '{print $3}' |base64 -d ; done
Gits-057
Gits-021
Gits-200
Gits-043
Gits-241
Gits-059
[...]

carl@b:~/apd/$ for i in `ls`; do mv $i `exiftool $i | grep Comment | awk '{print $3}' |base64 -d `; done

carl@b:~/apd/$ ls
Gits-020 Gits-040 Gits-060 Gits-080 Gits-100 Gits-120 Gits-140 Gits-160 Gits-180 Gits-200 Gits-220 Gits-240
Gits-001 Gits-021 Gits-041 Gits-061 Gits-081 Gits-101 Gits-121 Gits-141 Gits-161 Gits-181 Gits-201 Gits-221 Gits-241
Gits-002 Gits-022 Gits-042 Gits-062 Gits-082 Gits-102 Gits-122 Gits-142 Gits-162 Gits-182 Gits-202 Gits-222 Gits-242
Gits-003 Gits-023 Gits-043 Gits-063 Gits-083 Gits-103 Gits-123 Gits-143 Gits-163 Gits-183 Gits-203 Gits-223 Gits-243
[...]

We got stuck here for a minute, but then figured out that you could cat each of these individual mp3s together and end up with a playable mp3.

carl@b:~/apd/$ cat Gits-* > full.mp3
carl@b:~/apd/$ ls -al full.mp3
-rw-r--r-- 1 carl carl 4865279 2011-02-21 16:09 full.mp3

If you open the song in an mp3 player, you should quickly identify that it is Prodigy - One Love, from the Experience album, and also from the Hackers sound track. If you listen through the song you will get to some dialogue from the movie where Cereal is talking about the Da Vinci virus. At ~ 3:50 you'll hear the quote "The password for this hungry little sucker belongs to Margo Wallace". "Margo Wallace" is repeated a number of times and "Wallace" is distorted. Presumably they wanted us to look up the movie script and confirm.. easy stuff.

Margo Wallace is the key.

Ghostintheshellcode Stage 5 CCTV Forensics 250pts

2011-02-21T12:19:00.000-08:00

Stage 5
Question: cctv
250 Points
File: cctv-88cbfd616c1ce146ca6b738772c10bea

The CCTV page has 9 animated gifs. Collect them all!

carl@b:~/cctv$ ls
code.gif davinci.gif destroycard.gif game.gif gibson1.gif gibson2.gif gibson3.gif hops.gif otv.gif

This took a long time while we tried a bunch of useless ideas.
-All of the gifs were exploded into single frames and each was checked for any watermarks or interesting information.
-We tried to find any hidden data stored between the frames. I hear you can append a zip file to the end of a gif file and each can be opened with native tools.
-Looked for something interesting based on the timing of each frames.
-Loaded them into gimp and noticed the timing was between 0-70ms per frame, which made me think hidden octal numbers, but this was a dead end, for now.

We massaged each of the files through imagemagick over and over with no results. At one point, I came across this page: http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=11988 which led me to look for "ticks". Imagemagick's identify command can show ticks if you use %T.

carl@b:~/cctv$ info="%T"
carl@b:~/cctv$ identify -format "$info" *.gif

1531521641211231061411441461531541461521411631460120001101211051441441661701721261011071011061460120014616116414516116410112310410610110614716116414401200001031621411631501451441011561441021651621561451440120014114711010712116114116314414614112413111011014101201461411231071241211041431701411471461611470120000147131121161145141146144163166170147141141147012012114514114114614116314414612110513112210516301214612116414414717112514114416614217210114614614101200

I'm pretty certain the only reason this looked interesting to me was because I saw the file in gimp earlier and 0-70ms made me think "octal". Otherwise, I probably would have missed it.

carl@b:~/cctv$ identify -format "$info" *.gif > file.out
carl@b:~/cctv$ more file.out
1531521641211231061411441461531541461521411631460120001101211051441441661701721261011071011061460120014616116414516116410112310410610110614716116414401200001031621411631501451441011561441021651621561451440120014114711010712116114116314414614112413111011014101201461411231071241211041431701411471461611470120000147131121161145141146144163166170147141141147012012114514114114614116314414612110513112210516301214612116414414717112514114416614217210114614614101200

Break up the string into sets of 3 digits:

carl@b:~/cctv$ egrep -o "[0-9]{3}" file.out > file2.out
carl@b:~/cctv$ more file2.out
153
152
164
121
[...]

carl@b:~/cctv$ perl octa -a file2.out
carl@b:~/cctv$ more file2.out.as
kjtQSFadfklfjasf
NULHQEddvxzVAGAFf
SOH !1 1PNULCrashedAndBurned
SOHA9AAPfaSGTQDcxagfqg
NULFFJNLLFFLL))Q P

The key is in octal in the ticks inside game.gif. The key is "CrashedAndBurned".

The octa file is octala.pl from Mike Golvach: http://linuxshellaccount.blogspot.com/2008/05/perl-script-to-do-lame-encryption-with.html. Thanks to him for his script.

Ghostintheshellcode Stage10 Forensics 400 points.

2011-02-21T11:45:00.000-08:00

Stage 10
Question: Hackerlife
400 Points

John doesn't see a problem.

File: hackerlife-0b8724a229d81bbb727d27d735eaca86

The file is pretty large by itself. It is a bzipped tarball. Extract it out.

carl@b:~/hackerlife$ file hackerlife-0b8724a229d81bbb727d27d735eaca86
hackerlife-0b8724a229d81bbb727d27d735eaca86: bzip2 compressed data, block size = 900k

carl@b:~/hackerlife$ bunzip2 hackerlife-0b8724a229d81bbb727d27d735eaca86
bunzip2: Can't guess original name for hackerlife-0b8724a229d81bbb727d27d735eaca86 -- using hackerlife-0b8724a229d81bbb727d27d735eaca86.out

carl@b:~/hackerlife$ ls -al
total 73560
drwxr-xr-x 3 carl carl     4096 2011-02-21 11:00 .
drwxr-xr-x 38 carl carl    69632 2011-02-20 22:53 ..
-rw-r--r-- 1 carl carl 75243520 2011-02-21 11:00 hackerlife-0b8724a229d81bbb727d27d735eaca86.out
drwxr-xr-x 3 carl carl     4096 2011-02-21 11:00 new

carl@b:~/hackerlife$ file hackerlife-0b8724a229d81bbb727d27d735eaca86.out
hackerlife-0b8724a229d81bbb727d27d735eaca86.out: POSIX tar archive

carl@b:~/hackerlife$ tar xf hackerlife-0b8724a229d81bbb727d27d735eaca86.out

carl@b:~/hackerlife$ file 6661024a3d7bbe441f8930e761a138f4
6661024a3d7bbe441f8930e761a138f4: ASCII text, with CRLF line terminators

carl@b:~/hackerlife$ ls -al 6661024a3d7bbe441f8930e761a138f4
-rw-r--r-- 1 carl carl 75231938 2010-12-31 00:42 6661024a3d7bbe441f8930e761a138f4

Looking at the file, it looks like an oddly formatted passwd dump. Looking through the list, it's obviously the well-publicized dump of gawker.com users.

carl@b:~/hackerlife$ more 6661024a3d7bbe441f8930e761a138f4
nicka ::: NULL ::: NULL ::: naster@gawker.com
Lisanti ::: NULL ::: NULL ::: tips@defamer.com
Choire ::: NULL ::: NULL ::: choire@gawker.com
Defamer ::: NULL ::: NULL ::: tips@defamer.com
gabriela ::: NULL ::: NULL ::: gabriela@gawker.com
trackbacker ::: NULL ::: NULL ::: trackbacker@gawker.com
wonkette ::: NULL ::: NULL ::: tips@wonkette.com
lev ::: NULL ::: NULL ::: tips@gizmodo.com
[...]

So, I got a hold of the actual list and compared them.

carl@b:~/hackerlife$ more gawker.passwd
nicka:NULL:NULL:naster@gawker.com
Lisanti:NULL:NULL:tips@defamer.com
Choire:NULL:NULL:choire@gawker.com
Defamer:NULL:NULL:tips@defamer.com
gabriela:NULL:NULL:gabriela@gawker.com
trackbacker:NULL:NULL:trackbacker@gawker.com

carl@b:~/hackerlife$ wc -l gawker.passwd
1247893 gawker.passwd

carl@b:~/hackerlife$ wc -l 6661024a3d7bbe441f8930e761a138f4
1247912 6661024a3d7bbe441f8930e761a138f4

Those are pretty close. Lets find what is different.

carl@b:~/hackerlife$ awk -F"[: ]" '{print $1}' gawker.passwd > gawker.users
carl@b:~/hackerlife$ awk -F"[: ]" '{print $1}' 6661024a3d7bbe441f8930e761a138f4 > 666.users

carl@b:~/hackerlife$ diff -y --suppress-common-lines gawker.users2 666.users
             > havlarflake
             > dragosr
             > dino
             > dakami
             > 41414141
             > ChrisPaget
             > 0xcharlie
             > taviso
             > ero
             > thedarktangent
             > hdm
             > invisig0th
             > alexsotirov
             > mdowd
             > dionthegod
             > evilcazz
             > scarybeasts
             > egyp7
             > s7ephen

Those guys look familiar.

carl@b:~/hackerlife$ cat users
havlarflake ::: UtTv7enb7F7eo ::: NULL ::: Rmd4@gmail.com
dragosr ::: /3EK9FFao4Pg6 ::: NULL ::: aD92@gmail.com
dino ::: V2ImDfHvvzeGM ::: NULL ::: L3d3@gmail.com
dakami ::: HH1Ib3DcdRGSk ::: NULL ::: IGtl@gmail.com
41414141 ::: S8/2fLdvnSKM. ::: NULL ::: bS93@gmail.com
ChrisPaget ::: aRHvyiutiwz3A ::: NULL ::: PThp@gmail.com
0xcharlie ::: NVDC2543t.EKw ::: NULL ::: eSBp@gmail.com
taviso ::: 6vqZ23UFznzuc ::: NULL ::: czog@gmail.com
ero ::: Alj6D38tP79g6 ::: NULL ::: YXRj@gmail.com
thedarktangent ::: 0dOYtkSGSMR4. ::: NULL ::: LmNv@gmail.com
hdm ::: TxuDvnUnk94wU ::: NULL ::: VGhl@gmail.com
invisig0th ::: hBYhGy4dotTCc ::: NULL ::: TGY4@gmail.com
alexsotirov ::: oMCKEbmr9Kcx6 ::: NULL ::: ZHZH@gmail.com
mdowd ::: TGW6yISW/Ezzo ::: NULL ::: b3V0@gmail.com
dionthegod ::: 79mrBN2Qrejrk ::: NULL ::: dWJl@gmail.com
evilcazz ::: L6D79o81B8rL6 ::: NULL ::: cDov@gmail.com
scarybeasts ::: 6/gvMSbzDN1a. ::: NULL ::: aHR0@gmail.com
egyp7 ::: boREOx6UFvQF. ::: NULL ::: Lg==@gmail.com
s7ephen ::: m4bjrTwr9hbt6 ::: NULL ::: dy55@gmail.com

Those email addresses look suspicious, especially "Lg==@gmail.com". Anytime I see ==, I assume base64 padding.

carl@b:~/hackerlife$ cat users-original-order | egrep -o ".{4}@gmail.com" | cut -c1-4 | tr -d '\n'
Rmd4aD92L3d3IGtlbS93PThpeSBpczogYXRjLmNvVGhlTGY4ZHZHb3V0dWJlcDovaHR0Lg==dy55

carl@b:~/hackerlife$ cat users-original-order | egrep -o ".{4}@gmail.com" | cut -c1-4 | tr -d '\n' | base64 -d
Fgxh?v/ww kem/w=8iy is: atc.coTheLf8dvGoutubep:/htt.w.y

Rearrange the parts of the base64 string and you end up with:

carl@b:~/hackerlife$ echo "VGhlIGtleSBpczogaHR0cDovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PThpZHZHRmd4TGY4Lg==" | base64 -d
The key is: http://www.youtube.com/watch?v=8idvGFgxLf8.

If you visit that link, and you should. You'll also find somebody has beaten you to it:
"Wow, this URL is totally the key. Seriously. The key. The url. The key. realnamehere 1 month ago "

Ghostintheshellcode Stage 26 BeatBoxing Packet 75pts

2011-02-21T07:07:00.000-08:00

Stage 26
Question: BeatBoxing
75 Points
File: beatboxing-da09c691e2613581f1f4db70810c6e5c

carl@b:~/beatbox$ file beatboxing-da09c691e2613581f1f4db70810c6e5c
beatboxing-da09c691e2613581f1f4db70810c6e5c: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)

First just reviewed the dump file to see if anything stood out. I went down a few paths checking the delay between packets and any variance in the packet size, but they didnt lead me anywhere. The source and destination ports didn't seem to be of note either.

carl@b:~/beatbox$ tcpdump -nnn -r beatboxing-da09c691e2613581f1f4db70810c6e5c
carl@b:~/beatbox$ tcpdump -nnn -A -r beatboxing-da09c691e2613581f1f4db70810c6e5c

I extracted the payload using tcpflow. The only thing I noticed was the file was exactly 65535 bytes. That didn't lead me to any conclusions other than it was likely custom generated.

carl@b:~/beatbox$ tcpflow -r beatboxing-da09c691e2613581f1f4db70810c6e5c
carl@b:~/beatbox$ ls -al 127.000.000.001.42405-127.000.000.001.04242
-rw-r--r-- 1 carl carl 65535 2011-02-20 15:18 127.000.000.001.42405-127.000.000.001.04242
carl@b:~/beatbox$ file 127.000.000.001.42405-127.000.000.001.04242
127.000.000.001.42405-127.000.000.001.04242: data

After reading some other CTF write ups, it dawned on me to look for the number of occurrences of specific characters, which led me to this:

carl@b:~/beatbox$ egrep --binary-files=text -o "[A-Za-z0-9]" 127.000.000.001.42405-127.000.000.001.04242 | sort | uniq -c | sort -n

[...]
175 H
176 a
177 c
178 k
179 E
180 R
181 s
182 F
183 o
184 r
185 L
186 i
187 f
188 e
190 G
191 I
192 T
193 S
227 h
231 1
238 V
240 6
240 A
243 K
244 U
245 W
246 u
248 p
[...]

and thus the answer: HackERsForLifeGITS

Mental Note on argus

2010-01-15T12:08:00.000-08:00

from #man ra

-n Modify number to name converstion. This flag supports 3 states, specified by the modulus of the number of -n flags set. The first -n will suppress address to hostname lookups. -nn will suppress port number to service conversion and -nnn will suppress translation of protocol numbers to names. -nnnn will return you to full conversion. Because this indicator can be set in the .rarc file, multiple -n flags can be used to specify to a specific state of number to name conversion.

Therefor, when I type 'ra -nnnn ' as I am expected to do, I am actually failing to suppress lookups like I expected.

Always good to RTFM.

Syslog and UDP issues

2009-12-14T16:15:00.001-08:00

Going to use this space to outline an issue I'm currently experiencing and hopefully to later post a resolution as I find one.

I recently helped set up a couple syslog servers to consolidate a lot of data for a client. We ran into a problem where data was not being logged even though logs were being sent to the system. We used tcpdump to confirm that the logs were reaching the server and formatted correctly, but syslog was not writing them to disk. However, other logs were being written.

The problem seems to relate to the UDP recv-q. Here's what we were seeing:

[root@test-lab ~]# netstat -anu | grep 514
udp 110160 0 0.0.0.0:514 0.0.0.0:*

That 110160 as best I can tell, is the number of bytes waiting on the interface's buffer, but syslog has not picked them up and processed them. Watching that number of the course of a few days, it would occasionally rise or fall ever so slightly, but I was unable to determine what it was actually doing.

[root@test-lab ~]# netstat -ansu
Udp:
103235 packets received
58248 packets to unknown port received.
425450 packet receive errors
144175 packets sent

Running this command repeatedly, it looked like the packet receive errors were increasing by 20-30 for every 1 packet received. Strange.

We tried making some tweaks to the buffer size. This did not make an immediate difference, but likely requires a reboot, which we were unable to do at the time. Will update sysctl.conf and reboot when available. If I recall correctly, I've seen this behavior before, but the buffer would fill up close to max regardless of how large we set the rmem_max value. Here it's set to 8MB:

[root@test-lab ~]# sysctl net.core.rmem_max
net.core.rmem_max = 131071
[root@test-lab ~]# sysctl -w net.core.rmem_max=8192000
net.core.rmem_max = 8192000

Also, someone suggested we try offloading some of the work to the hardware using UDP Fragmentation Offload. This is disabled by default in Linux. It sounded like a good idea, and makes sense because some of these log messages are quite large and likely fragmented. Unfortunately, it appears our NICs or drivers do not support this feature.

[root@test-lab ~]# ethtool -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off
[root@test-lab ~]# ethtool -K eth0 ufo on
Cannot set device udp large send offload settings: Operation not supported
[root@test-lab ~]#

So, the current plan is to try an increase the buffers, decrease the amount of UDP data being sent to the server, and possibly a hardware upgrade in the form of new NICS.

UPDATE:
Just wanted to add a few more details to this conversation.

During troubleshooting, we made an attempt to figure out which hosts were causing the most UDP traffic that the socket could not keep up with. To do this, I did the following rough command:

#tcpdump -nnn -c 1000 -i bond0 udp and port 514 | awk '{print $3}' | egrep -o "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" | sort | uniq -c | sort -nr

This command spit captured the next 1000 UDP syslog hits, parsed out the source IP addresses, sorted, counted, and then reverse sorted (highest at the top) the results. The results were that some of the firewalls and some of the DNS servers in the local zone were sending tons of UDP logs. After speaking with the owners, we trimmed some of the 'noise' out of the syslogs and also switched over to TCP. After a few of these changes, the Recv-Q fell to 0, and only rarely accumulated up. It would quickly revert back to zero as the application kept up. Additionally our netstat -ansu command showed that packets were being correctly received and not errored. Neat!

Just to be sure, we also ran #netstat -ant and #netstat -antu to make sure that the TCP recv-q wasn't filling, and there were no packets being dropped on the TCP side. It looks like we were able to resolve the issue.

To do:

2009-11-28T16:19:00.001-08:00

Here's a quick list of NSM things going around my head that I'd like to put some time into:

Know your network & Asset management - Put together documentation on every host/subnet/service/etc that you can. You can craft very explicit alert, firewall and IDS rules, but you NEED this information to make them accurate.
Egress filtering - Don't just block outbound traffic, but set up alerts/review logs to see who/what is making those blocked connections.
Limit the noise - If you can reduce the amount of unidentified traffic in your network, you can focus on these anomalies.
Snort - The easiest way to get into customized deep packet inspection.
Keep netflow and URL history - Invaluable for incident response.
Don't trust AV. If you're spending all your time focusing on your AV alerts, you're missing the real threats.
Honeypots - They don't need to be complex to be effective. The false positive rate is minimal and this is a very very VERY good thing. It's so simplistic, I can't believe it's not standard practice.
User's don't need admin rights. OK, political battle here, but if you can't remove admin rights, how about white-listing sites allowing .exe downloads?
User education doesn't work so well, I like user punishment. Reduce privileges for users who create work for IT staff by infecting themselves.
If you're not going to document your policy exceptions, how can you create/audit rules that you have for those policies?

I'm sure this list will grow as more comes to mind. Hopefully I'll find the time to write more on each of them.

New blog

2009-11-06T17:42:00.000-08:00

Here's what I'm into right now.

Dojocon - The 2 day security conference put together by Marcus Carey. I spent most of the day there today and enjoyed the talks. The whole event is being streamed and archived in quite good quality on Ustream. I most enjoyed Matt Watchinski's talk about managing a security group and some of the things we're doing wrong as an industry. I was considering participating in the CTF event, though I have not done one before and do not know what to expect. However, I've heard it was cancelled.
My FreeBSD sensor - I set up a very bare installation of FreeBSD and am running a few network monitoring tools for the home network. I'll go into these more in a future post: snort, urlsnarf, dsniff and argus.
Punch Out! (Wii) - I remember playing Mike Tyson's Punch Out on the NES, and later Super Punch Out on the SNES. I'm glad I gave this game a shot on the Wii, it's good fun.
Zombieville (Iphone) - This is a fun little game that only costs $.99 and has provided many hours of entertainment. For it's simplicity, it is challenging and fun.

Hopefully more interesting posts to come.