Search this site


Page 1 of 2  [next]

Metadata

Articles

Projects

Presentations

Tracking and Analyzing SSH Bots.

I've posted previously about what can be done about ssh bots. In this same context, I've just finished working on a new idea: Tracking the username/passwords used by the bots.

To track the login attempts, I wrote a new pam module: pam_logfailure. The goal of pam_logfailure is to log the passwords used by bots attempting to bruteforce logins. However, when I installed the module, I found that it wasn't working properly:

Dec 20 12:24:50 kenya2 pam_logfailure: host:125.243.206.194 user:john pass:^H ^M^?INCORRECT
I saw line after line of these, and couldn't figure out why the bots were using this as a password. Turns out they aren't. This password is what OpenSSH forces upon pam for users that do not exist. This is apparently by design:
auth-pam.c: static char badpw[] = "\b\n\r\177INCORRECT";
If you are an invalid user, or are trying to login as root while root login is disabled, the password you sent is replaced with 'badpw' above. This makes it kind of hard to track what passwords bots are using...

Thankfully, I was already one step ahead of myself when I wrote a function injection tool back in September (liboverride). So, all I had to do was inject my own 'getpwnam' function to spoof data when a user did not exist to trick OpenSSH into passing the password through.

After injecting my own getpwnam(), pam_logfailure started working just fine:

Dec 22 11:17:47 kenya2 pam_logfailure: host:218.1.65.233 user:admin pass:admins
So where will I go next with these ssh-bot games?
  • Reverse-hack. I picked 3 random ssh bot hosts from my logs, and all of them run sshd. It would be pretty trivial to take the password attempts used against my machine and try them on the host the bot is coming from. Seems likely that turning the bot's actions on itself will grant me access to the infected machine.
  • Redirect to a honeypot. We could detect when a bot is trying to login, and add a firewall rule that would put future ssh attempts from these hosts into a honeypot which accepts all logins to see what happens.
  • Fingerprint ssh bots by behavior.

The usage of getpwnam.over is like any other liboverride code. 'make getpwnam.so' and then use "LD_PRELOAD=/path/to/getpwnam.so ". In this case, I added this line to /usr/local/etc/rc.d/openssh (my sshd start script):

export LD_PRELOAD=/path/to/getpwnam.so

Here is the code:

Defcon 15 in review

This year's defcon was similar to last years. At the Riviera, black and white ball were split across two night, a few amazingly lame talks were given, some cool talks, and as always Dan Kaminsky's talk was entertaining.

I'm no Vegas expert, but the Riviera casino/hotel is the *worst* casino in town. I had many conversations with fellow attendees reminiscing about how much we missed the Alexis Park. Finding parties at the Alexis was cake - walk outside, follow the people and noise. Parties were everywhere. There were also 3 outdoor pool areas which collected people, booze, and music each night. The only downside to the Alexsis Park was that its conference areas were too small and too few. This downside was mitigated by three-channel closed-circuit TV channels broadcast live and viewable on any hotel room's tv. Watch the talks from your room? Awesome. For parties and community, the Alexis Park ruled. For more plentiful conference space, the Riviera is better. It's a shame we (Defcon) outgrew the Alexis Park.

The Riviera is a giant, old, dirty resort casino. The rooms are not great, the casino smells bad, and the food is horrible. Basically, I can't say much nice about the place other than it does have large quantities of conference space. The casino staff were generally nice folks, but I don't gamble so I didn't interact with them much. Their concierge desk is horrible. Every time I asked where I might find a particular place (pizza, sushi, flare bar, etc) that was not inside the Riviera, they had no answers.

I went to my usual (read: small) number of talks this year. I missed a few that were titled in such a way as to disinterest me that I later found out covered some cool material. Bruce Potter's talk was overflowing with people, so some of us had to leave - sad. If you have his talk on video, please send me a url :)

There were thousands of scene whores at defcon this year. We were drowning in them. So much so, perhaps, that some 0x90 folks made these shirts which showed up during the I/O Active party (which was awesome, btw).

I also found that there were so many super paranoid people at Defcon. Mostly scene whores who really have no idea what a computer is or what security is about. Too many evesdropped conversations where people said "I'm not turning on wireless! I have too much important stuff on my laptop that I can't allow to get out!" Are they that worried about being exploited? Probably. Do they really have shit worth protecting on their laptops? Probably not. One of these people was a student at UCSD and he talked shit about his friends' computer knowledge constantly while his friends were supposedly writing tetris for the defcon badges.

If you have a clue and have something on your laptop worth protecting so much so you physically turn off wifi, then you don't bring it to defcon. Clearly these people haven't got a clue and are just whoring up the scene. [*]

[*] One exception is reporters and other press types, who I won't require to have security or computer clue. Of the people I overheard freaking out about wireless, all of them were normal attendees, not press.

I flew into SFO on Monday morning. Wendy was due to land in a few hours, so I sat at the airport so we could go home together. After signing on for wireless, I remembered a project I've been meaning to do for a while - masquerade as a known-valid MAC and IP combination to bypass captive portals. It's easy to do, but I wanted it automated. Now I have a script. I'll post more on this later, but the typical configuration of "captive-portal authentication == your mac+ip is allowed through the firewall" is not a good way to run your pay-for wireless network.

One final notable event is that we took a limo ride to In-n-Out again this year.

I went to more than the talks listed below, but they weren't worth commenting on or I don't remember them.

    Mike Schrenk - "The Executable Image Exploit"
    Before going, I thought this talk was going to be on a new twist to recent image library exploits. It wasn't. His <sarcasm>amazing</sarcasm> content covered something known for years, that hot-linked images (wikipedia calls them deep links), could be used to track users or reveal information by tracking the referrer url or *gasp* setting a cookie!

    Mike also talked about using php to serve images and that you can set cookies using php, but myspace filters images ending with '.php' apparently. His workaround was to tell apache to process .jpg files as php, and he presented this as if he was breaking some kind of new ground and that this was the coolest thing ever: "You can fool apache into running php code on jpegs!" Clearly by "fool" we really mean "configure the same way you do with .php except you put .jpg". Who's fooling who? ;)

    Around this time I was realizing that by "executable image" he really meant that he was executing php code on his own server whenever someone requested an image, again, from his server. This would have been a good presentation for 1998, perhaps, not 2007.

    Zac Franken - Biometrics and Token access control systems
    This talk was great. My knowledge of rfid, biometrics, and other physical access token systems is limited and this talk gave me lots of good information. Furthermore, Zac gave a live demo that worked well. The tool he made, which he called "Gecko", was really neat. Practical and cheap.

    A short summary is that he was performing MITM on physical access systems. As it turned out, most centralized security systems (biometrics, rfid locks, etc) all talk the same protocol to the central authorization server. Gecko simply man-in-the-middles these transactions. MITM is not new, but this application was pretty neat and the small size of his prototype made this kind of physical hacking practical.

    He gave a live demo, which went smoothly, using a few RFID badges. Being minimalist, the interface to his Gecko tool once it was installed was via standard badges. He had made special "control" badges that the Gecko tool understood to be commands such as a replay command, which would replay a previously-intercepted, known-valid, badge read to the server.

    He also talked about future versions of Gecko which might include bluetooth or GSM, which would let you access the reader device from far away. Very neat.

    Dan Kaminsky - Design Reviewing the Web
    Oh Dan. I love you. I went to Dan's talk last year and saw the same attributes this year. His talk covered some interesting things, but he's so full of himself. Watching him talk makes it seem like he is the security industry. One person only, not the thousands of security professionals and underground hackers around the world. Just Dan.

    He did demo his hack of SLIRP over the web browser (flash+http) which was pretty neat, though. Tunneling traffic through the browser into your network. He also ported his dotplot thing from last year to winamp for fun and profit, which wasn't very impressive but made for a good screensaver.

    Jesse D'Aguanno - Arp Reloaded
    Jesse's description of this talk was that it would "build on the previous research in this field and introduce new, more reliable attacks against the ARP protocol which are much less identifiable and able to protect against."

    He lied.

    He covered exactly what is already known, and nothing more. Like Mike's talk above, this talk would belong in 1995, or earlier, not 2007. Who's reviewing these talk submissions?

    It is almost like Jesse lives in a black box. Not only did he cover decades-old exploits, he reinvented the wheel. There are many many tools that will let you easily craft packets and dump them on the network. Netwox, nemesis, and scapy are just 3 I can name off the top of my head. Ignoring the years of developing packet crafting tools, he wrote his own crappy tool to dump crafted arp packets onto the network which he calls "arpcraft" which does exactly the same thing as netwox, nemesis, and scapy, in more or less the same amount of typing. Weak sauce. I call shenanigans.

    This lame presentation is from the same person who made headlines about his blackberry hackery last year. Was this blackberry research really his own work, or is he just a front for someone elses work?

    He also demoed a remote shell tool using arp. Seems useless to me since arp only goes over layer 2 and won't leave the local layer 2 network. Wxs joked that you would better off beating the owner of your exploit target machine with a bat to wrest the password out of him than using a remote shell via arp, since layer 2 means your target almost guaranteed to be physically close.

    David Gustin - Hardware Hacking for Software Geeks
    The title of this talk grabbed me immediately. The content was great!

    Unfortunately, early in the talk, the speakers mentioned that sparkfun.com was a great howto site. I spent the rest of the talk reading tutorials on that website. Oops.

Shmoocon 2007

While Shmoocon doesn't start until Friday, I'm flying out tonight. I haven't been to DC in 10 years, so I'll probably tourist it up atleast for a few hours. This week is taking me far away from any work-related activities. I turned off my pager a few minutes ago, so my vacation has officially begun.

See you in DC.

ShmooCon '07

I'm going to be attending ShmooCon '07. If you're going, and I don't know you're going, let me know.

I'm helping out with HoH. Beware.

Video of my SSH Tunneling talk at Barcamp Stanford

I got A.D.D. tonight while working on Pimp and decided to Google myself and see what came up. I do this once very few months. Normally the results aren't terribly interesting. However, since I'd recently attended a few barcamps, I noticed that some folks had written about some of the talks I'd given.

I found a video of my 'firewall bypass/ssh tunnel/encrypt-your-traffic' session I held at BarCamp Stanford. Thanks to ValleyGeek for posting this. I'm assuming the author recorded it.

Towards the end of the talk I start rambling about nat traversal. Hopefully I got the point across that nat<->nat traversal isn't easy, and that tunneling is a way to do it.

http://video.google.com/videoplay?docid=-3694684117834367516

Along with that video, I found my urban-dictionary entry for 'Fo Shizzle Friday'. I can't remember why I created that.

Routing all traffic through VPN

So, I have a pptp vpn server running in my apartment. I desire this setup:
I VPN to my apartment. *All* traffic will go through this vpn
PPP has features to negotiate IP-level information such as DNS and "Here's your IP" using IPCP. However, it doesn't seem to be able to share routes. However, my local ppp.conf can say add default HISADDR and suddenly all my traffic wants to go through the vpn. However, once I do this, I lose all connectivity to the vpn because it is off-subnet - my machine forgets how to route data to the vpn, oops!

Is there a way to have ppp add an additional route that I want? Specifically, I want to take the existing known gateway (say, my wifi gateway) and do: add [vpnhostname] [currentroute] and then add a default route for the tunnel. This will allow all traffic to want to go through the tunnel, but still allow the OS to know how to *get* to that tunnel.

A hacky solution involves some pre-vpn discovery. I need to figure out what my default route is. Once I know that, I can simply add a single line in my ppp.conf and I have all traffic routing through my apartment.

 add myvpnhostname mycurrentdefaultroute
 add default HISADDR
These two lines create 2 routes. The first keeps the system aware of how to reach the vpn server. The second ensure a default route to the vpn gateway.

While this is suboptimal, it is easy to automate. My vpn script can simply generate a new ppp.conf and grab the default route with:

nightfall# netstat -rn -finet | awk '/^default/ { print $2 }'
192.168.55.254

Random thoughts on wifi and vpn.

Being that we can't really control all of the hops between ourselves and every end point on the internet, can we really be sure our traffic is secure?

Food for thought: My home vpn is a very simple poptop setup. It does not use certificates. How do I verify that my vpn connection is untainted? How difficult would it be to intercept my vpn connection request with a rogue vpn?

Let's say I'm on Google's free wifi here in Mountain View, and someone's being naughty by putting up the following rogue services: dhcp, dns, and vpn. It is trivial to advertise a route on the network and redirect vpn connections to a rogue vpn service. This vpn service could use the intended vpn as an authentication service. In doing so, the "bad guy" can quite easily join the two vpn tunnels such that the victim has no idea he has been victimized.

Put simply, how hard would it be for me, personally, to do this? Tools that come to mind, are: FreeRadius, Poptop server, isc-dhcp server, BIND 9, pf. Tack on a trivial script to interrupt the normal network services such as DHCP and DNS, and you've got something that can easily be deployed on a laptop.

I'm sure there are technologies to prevent this kind of MITM attack on vpns, right? IPSec, perhaps? I don't know. More research is required.

How secure are you on your favorite wifi hotspot? How secure are the "secure" services we rely on?

Defcon 14

DC14 has come and gone, and with it went several gallons of liqour.

This year's focus seemed to be generally on a debugging technique called fuzzing. Bruce Potter's talk this year was as entertaining as last year's talk, with the exception that he didn't scream out "Bow to my firewall!" - oh well. This year he talked about trusted computing; it was a good presentation. Dan Kaminsky's talk covered a lot of neat things, but I was put off by how full of himself he seems to be, whatever. I made an effort to attend a dns hackery talk, but the speaker was horrible at maintaining focus and presenting, so I left a few minutes into the talk.

Things I need to play with: squid reverse ssl proxy, scapy, some generic tcp proxy thing I don't remember the name of, and a host of other new-to-me technologies. Exploitation for fun and profit, good times!

Is pam_captcha worth using? (Securing your sshd)

In /var/log/auth.log today, I see:
Jul 19 04:37:21 dns sshd[5072]: Invalid user test from 211.154.254.73
Jul 19 04:37:22 dns sshd[5074]: Invalid user guest from 211.154.254.73
Jul 19 04:37:26 dns sshd[5080]: Invalid user user from 211.154.254.73
No authentication failures, just invalid user notifications.

FreeBSD has (for a while?) disabled simple "password" authentication in it's base sshd config. What does this mean? If client connects requesting only "password" authentication, it will be rejected. Period. Example:

dns(~) !255! % ssh -o "PreferredAuthentications password" [email protected]
Permission denied (publickey,keyboard-interactive).
If you check /var/log/auth.log, you'll see:
Jul 19 06:10:32 dns sshd[5403]: Invalid user happytest from 192.168.0.252
However, try the same with a valid user. Nothing is logged (by default). Still, you are denied outright.

The important point, is that I guess pam_captcha is not necessary at this time. Every ssh client I have used has supported both public-key and keyboard-interactive authentication, so disabling 'password' everywhere should be a viable option. FreeBSD disables password auth by default, and no one seems to be complaining.

If you're worried about brute force attacks over ssh, then just disable 'password' authentication. In sshd_config:

PasswordAuthentication no
This probably requires that you use public-key or keyboard-interactive (PAM) to authenticate. Keeps normal users happy, and blocks brute force bots. That is, until the bot scripts are updated to use keyboard-interactive, perhaps? Who knows...

ISTS4 wrapup

This year's ISTS security competition has come and gone. My team was robbed of victory.

Our defensive strategy this year was some trivial security through obscurity combined with some very clever hardening. Using FreeBSD on all of our machines, we ran all of our services on one machine leaving the remaining 3 machines for attacking and forensics.

All services ran inside a single jail. The creation of the jail was done mostly with rsync to copy the freebsd base system. Inside this jail, we ran sshd, ftpd (via inetd), sendmail, popd, and apache. The jail had several mechanisms to limit malicious user activity. These include pseudo-quotas, login.conf user limits, etc.

The Plan

Run all services inside a jail. Use arpd to spoof unallocated addresses in our /24 network. Use a firewall to redirect all connections to any spoofed addresses on any ports to the real SSH server. That means we'll have almost 13 million ssh "servers" that appear to be running. One of these "servers" is the real one you can actually get a login shell for. The plan was wrapped around the assumption that the latest versions of apache, popd, and sendmail are not going to be exploitable. Generally this is a safe assumption especially in a small-scale competition like this one. So, the tools/software we used here were as follows:
  • FreeBSD 6.0
  • Sendmail 8.13.4 (freebsd 6 default)
  • popd 2.2.2a
  • default ftpd run from inetd
  • default sshd (openssh 4.2p1)
  • Apache 1.3.34

The Firewall

I am most familiar with PF, so that's the firewall we used. The pf config was pretty short.
web_ip="10.10.102.97"
mail_ip="10.10.102.143"
ftp_ip="10.10.102.34"
ssh_ip="10.10.102.178"

# Redirect real-service ports first
rdr inet proto tcp to $web_ip port 80 -> 192.168.1.1 port 80
rdr inet proto tcp to $mail_ip port 25 -> 192.168.1.1 port 25
rdr inet proto tcp to $mail_ip port 110 -> 192.168.1.1 port 110
rdr inet proto tcp to $ftp_ip port 21 -> 192.168.1.1 port 21
rdr inet proto tcp to $ftp_ip port 20 -> 192.168.1.1 port 20

# The REAL ssh "server"
rdr inet proto tcp to $ssh_ip port 31975 -> 192.168.1.1 port 29

# Pretend everything else is ssh
rdr inet proto tcp port 1:49152 -> 192.168.1.1 port 22

# Make everything pingable, too
rdr inet proto icmp -> 192.168.1.1
You'll notice the "real ssh server" is directed to 192.168.1.1 port 29. We'll cover sshd next and why this is important.

The SSH Server (inside the jail)

There's nothing *too* special about our ssh config. I set it to listen in port 22 and port 29. Port 29 will be used to verify if you are connecting to the "real" server.
ListenAddress 0.0.0.0:22
ListenAddress 0.0.0.0:29

Network Configuration

The actual machine only had 2 IPs assigned to it. The host address, 10.10.102.145, and the private address that the jail ran from, 192.168.1.1. The rest of the network was spoofed using arpd:
arpd -d 10.10.102.0/24
So now anyone who tries to touch our network will get a response from any ip they hit. This is similar to a honeyd or labrea approach, but better. Labrea can successfully tarpit people who don't know how to tell real hosts from fake ones, but you can almost always easily determine labrea tarpitted (faked) hosts from real ones. Another solution might have involed honeyd, but I wanted a real, usable service. Since the only damage I felt anyone could incur would be from the shell, I wanted to keep users busy by baiting them with working ssh services that they simply didn't have real shells on.

Now, SPARSA's rules stated that no arp poisoning was allowed. I don't consider this arp poisoning because I could easily accomplish the same thing arpd supplied with this one-liner, and without true spoofing:

jot 253 1 | xapply -fv 'ifconfig em0 alias 10.102.1.%1 netmask 0xffffffff' -
It's not spoofing if I actually have all of the IPs on the network, now is it?

The Shell

PORT=`echo "$SSH_CONNECTION"|awk '{print $4}'`
trap - INT

if [ "$PORT" -eq 22 ]; then
        sl -laF
        cat /root/mario
        sleep 3
else
        /bin/tcsh -l

fi
This script was called 'happyshell' and each team's account had this shell. The script looks at SSH_CONNECTION for the port they sshed into the machine with. If it's 22 (the "fake" server), then they get some useless output printed to their screen, and it quits. If they hit the real server, it gives them tcsh. Very simple. If you want to know what '/root/mario' contained, check it out here: mario ascii picture

If you attempted to login via ssh to any IP:PORT other than 10.10.102.178:31975 you would get a message that would annoy you instead of a shell. Perfect, but you could still write a script to attempt to login and find the real ssh server, so we needed something else to slow you down.

Enter pam_captcha

pam_captcha was an idea Rusty, Dan, and I came up as a solution to prevent scripts from attempting logins aswell as to annoy and deter users who wanted to login and be naughty. We needed it to be difficult-to-impossible to script logins to find our real ssh server.

We initially thought a 10 second sleep delay would be sufficient, but as we discussed it further we realized we could ask the authenticating user questions to verify that they were human. The technical term for this kind of challenge-response authenticator is "captcha" - read about captchas on wikipedia.

I spent a few hours the weekend before the competition (last weekend) to write pam_captcha. There are currently 3 kinds of captchas. The first is a identifying a random string that's been run through figlet, turning it into text-ascii art. The second captcha is a simple math problem also run through figlet; users must solve this math problem to continue. The third captcha has no real practical uses, but for the context of the competition would be both annoying to users and hilarious for me. It involves users performing physical activities, such as stealing a competitor's hat, or singing a song. Verification was done by a human who then alerts the computer that this person is a human. I called this 3rd captcha "Dance Dance Authentication" or DDA.

I had to turn off DDA after the first 2 hours due to complaints. This was fine becuase I only wrote it for humor's sake. The other two captchas stayed enabled throughout the competition.

Outside of this competition, pam_captcha will prevent or atleast deter script kiddies from bruteforcing login attempts via ssh. So if you're interested in preventing this, then go ahead and use it. It works in Linux and FreeBSD.

pseudo-quotas

I say 'pseudo' becuase they aren't actual quotas. I used FreeBSD's mdconfig to create several vnode-backed (file-backed) disks. One for each user's home directory. The script I wrote to do this automatically can be viewed here. It created a 30 meg filesystem backed by a file for each team, initialized the file system, and unmounted it for later use. Another script let me mount a user's homedirectory. Quick and simple, this separated every user's home directory from everyone else's aswell as the rest of the file systems on the computer. This means if a user fills his/her homedir, the other file systems don't care.

The Competition: Defense

At this point, we had millions of potentially valid ssh servers and a means by which to prevent competitors from using brute force scripts to find the real server. Perfect.

During the 5-hour setup period of the competition, I installed the primary services on our system and finished some last minute testing before the attack-and-defend section began. 15 minutes before the end of the setup period, we were ready to go. 3 machines left to perform attacks and forensics, 1 to do services. So far so good, right?

Yep. Several teams attempted to find our ssh server and gave up after about 10 login attempts and moved on to easier targets (other teams). No one bothered attacking via web, ftp, or mail. Our series of tricks tied to our SSH server worked extremely well until around 6pm (1 hour left in the competition) everyone got their collective panties in a bunch and demanded that I stop being so tricksy. The rules for the competition did not cover what ports you had to run your services on, so naturally I protested. Finally, after about 20 minutes of hearing people bitch and moan, I updated the firewall rules to direct port 22 on the "real" ssh server to the actual ssh server (192.168.1.1:29, remember?). Only 3 (out of 6) teams attempted to login after that. Two teams attempted to fill fill the file system and failed. Another team attempted to starve CPU, but every team's default nice level was 19, making it only run when nothing else needed to do so.

The Competition: Attack

The only attacks I did were resource starvation: fork bombs, memory hogging, cpu hogging, file system filling, inode exhaustion, etc. My teammates attempted exploits and other attacks, sometimes these were successful.

The inode exhaustion attempts had a somewhat funny side-effect. The one-liner I used to do this was this:

while :; do 
  a=$(($a+1)); 
  touch $a $a$a $RANDOM $RANDOM$RANDOM $RANDOM$a; 
done
I just wanted to create lots and lots of files. I did this typically in my homedir or /tmp on another team's ssh server. After running for a significant amount of time, running ls in the directory became quite sluggish as it read all of the files. At one point, I had created well over 300000 files in /tmp. The team affected finally noticed this and tried to do "rm *" which inevitably failed with an error of "Too many arguments" - even attempting to do "rm 1*" failed due to too many arguments. Wonderful! Eventually they figured it out and ran 'find /tmp | xargs rm' - but this machine was also running X11 which had sockets in /tmp. They got blown away and X crashed. Whoops ;)

Beyond that, I ran multiple resource starvation attacks (that can be easily prevented) on several teams multiple times.

The Problems

Some of the SPARSA members who were running the event were on the majority very, very stupid and arrogant. I say this in a mean way becuase they've well-earned that label.
  • I made several mentions of teams not providing usable services which were almost all ignored. One particular service a team was running was a 15 line perl script that "served" web pages. It did not conform to any part of the HTTP standard. It responded with a default page, no matter what you requested, immediately after sending the 'GET' request line. Thusly, it ignored headers and the path. I argued that this was not a webserver, and a SPARSA alumni (the fool listed later) asserted that "Well it works for him to serve a webpage, therefore it is a valid webserver." I mentioned that even simple requests like POST and HEAD were reported as invalid, and the path of the request did not change the page served. I was ignored.
  • One SPARSA guy was arguing with me about how ssh is ONLY a "user and password authenticating protocol" and that my "hacked server" was illegal for the competition. He further argued that having users enter any information other than a username and a password was illegal. None of this was in the rules for the competition.
  • Another SPARSA guy, who is an RIT Alumni, began arguing with me that we should follow DNS standards and provide services on the PORTS dns was supposedly advertising for our service. I tried briefly to reeducate him that DNS only provided name-to-address mappings and not port information, but he insisted. Eventually, I said, "Look. It's obvious you have no clue what you're talking about. DNS does not serve ports. Do not argue with me about this, you will lose. Thanks." Another competitor there assisted by asserting that it could indeed not serve port information, and asked SPARSA to provide proof. No proof manifested itself. (Yes, SRV queries serve port information, but no ssh clients use it)
  • Much later in the competition, eventually everyone started complaining that they could not login successfully to our SSH server. This caused a split in the SPARSA group. I asked some of them to confirm that they could indeed login. Half confirmed, the other half said they couldn't login. I replied, "You are attempting to login on the wrong port and/or ip if you do not get a shell after authenticating." Many of the SPARSA guys went crazy with rage insisting that I was breaking rules (that weren't written anywhere?) and that I had to run ssh on the standard port. Others kept quite or commented positively on the strategy. After much arguing, one of the SPARSA folks wrote the port number that the real ssh server could be accessed through. A few minutes later I switched it to port 22, the standard port. The argument obviously enraged many of the SPARSA folks and put me in a bad light with them, I guess.
There were many more incidents that I may document later, but the overal point is that we came for a fun competition and while it was fun I did not expect to have to correct fallacies or arrogance on behalf of the SPARSA group. I do not claim to know everything, but it is ignorance to deny the truth when presented it. Cluelessness is not a fault, becuase you can always learn. Arrogance becomes a problem when I have to deal with it.

The Scoring Conspiracy

The rules stated you had a 2 minute grace period for any downtime before it would be counted against you. Our service machine was only taken down once - by a forkbomb from one of the SPARSA members (a limitation I forgot to place on the sparsa account). A quick reboot and all services came back online within 60 seconds of the down. However, something was strange with the network and Nagios only showed that our web server was online. I tested it, my teammates tested it. All of our services were online, available, and working. One SPARSA member attempted to verify this, and said that our services were down. Another SPARSA member also attempted to verify this, and said that our services were UP. Conflicting answers? Neat. I didn't touch anything, and 5-10 minutes after the first downtime, nagios magically decided our services were back online.

We insisted we be given back points for Nagios' false positives on our downtime, but we were turned away. Other teams complained about Nagios falsely reporting downtime and were awarded points back for false downtime. That's nice. It's good that the judges were fair to all teams.

No other teams were able to take down our services. Nagios, at random times, would determine that one (usually random) of our services were offline. Every time this happened, we verified all of our services and they were indeed online. Thusly, there was only about 60 seconds where any of our services were down during the entire competition. Other teams had critical failures during the competition and were also attacked and taken offline by other teams. Therefore, we had almost 100% availability, other teams were not so lucky. The only point in the competition where you can lose points is for downtime beyond 2 minutes, or so the rules state. You gain points by attacking others and partaking in the SPARSA challenge and the forensics challenge.

Long story short, we did OK with the forensics and OK on the sparsa challenge, but not great.

I'm not angry that we didn't win (or place, for that matter). I'm angry with the behavior of the members of SPARSA who made up random, unsubstantiated rules on the spot for no reason and applied them to some teams and not others. Many of them were entirely unprofessional and down-right rude and arrogant.

Dan, a friend of mine on another team, overheard several of the judges talking about my team and how they should just dock an arbitrary amount of points from us. What kind of crap is that? We paid $40 to attend this competition to get treated like this? I'm considering lobbying for a refund. We'll see. I'm extremely annoyed that there are student organizations seemingly bent around supporting their own arrogant members. If you're at RIT and are looking to join SPARSA, don't. Join CSH instead. We suck less.

At any rate, the competition itself was pretty fun if nothing else than for demonstrating pam_captcha and the better-than-labrea tarpitting-with-real-services tricks. I feel that we should've been given style points for unique solutions so hiding services and for pam_captcha. Style points weren't in the rules, but style should certainly not cause anger. Instead, The SPARSA judges just got angry. Feature? Hate the game, not the player.

Oh well... I'm done with student organizations in May (graduation!).