The Origin of Organized WarDriving

 < Day Day Up > 



Human beings are social creatures. Anytime there is more than one person participating in any activity we tend to seek out others that also participate. This gives us insight into how others are doing things, allows us to interact with them, and often results in a meeting of some sort. A good example of this is computer gamers. As broadband Internet became a reality for home users a few years ago, gamers were able to play in online communities with virtually no lag time. There was no longer a need to congregate for LAN parties to play games. But, to this day, gamers will pack up their full-sized desktop computers, monitors, and equipment to get together for LAN parties and play. The exact same thing could be accomplished online with the exception of one aspect—the social aspect. It is fun to be in a room with your friends doing something that everyone enjoys, together.

WarDriving is no different. People began getting together to WarDrive from day one. Why drive around a neighborhood by yourself, when you could e-mail your friend and have him bring his equipment and ride shotgun? Online communities such as the NetStumbler Forums (http://forums.netstumbler.com) and the Kismet Forums (www.kismetwireless.net/forum.php) quickly sprung up. In addition to providing information on setup and configuration of the tools, this gave WarDrivers the ability to talk online with other people that had similar interests. The NetStumbler Forums even started an “Other Stumblers” forum (http://forums.netstumbler.com/forumdisplay.php?s=&forumid=13). This is a place where WarDrivers can post their location and find other WarDrivers in their area. Internet Relay Chat (IRC) channels like #netstumbler on EF Net provide a place for WarDrivers to discuss WarDriving online with others. The natural extension of these online communities is organized WarDriving.

The DefCon 10 WarDriving Contest

In 2002, WarDriving was still a relatively new idea in the hacking and security communities. As is always the case, there was discussion amongst the DefCon staff on how to improve the show. One way that has consistently worked has been to add contests. Contests such as Capture the Flag and Hacker Jeopardy have become mainstays and are two of the most anticipated (and discussed) events at DefCon. I and several other people had talked in the DefCon Forum’s IRC channel (#dc-forums on EF Net) about getting together and WarDriving the entire city of Las Vegas while we were there for DefCon. blackwave immediately ran with the idea and posted information about a coordinated WarDrive of Las Vegas on the DefCon Forums (http://forum.defcon.org).

How the Idea Came About

blackwave wasn’t aware that I had mentioned this to the other DefCon organizers as an idea for a potential new contest. blackwave had already started a thread on the DefCon forums that was soliciting interest in WarDriving all of Las Vegas, and several people had posted that they were interested in participating. Once the idea was approved as something that we wanted to add to DefCon as a contest, a general call went out to the DefCon staff asking for a volunteer to run it. Because WarDriving and wireless security in general were areas of personal interest to me, I immediately volunteered to organize and run the contest.

Choosing the Staff

Once the contest was approved, I contacted blackwave by e-mail to let him know that the DefCon staff had decided to do a WarDriving Contest rather than proceed with an unofficial WarDrive of the city. Because blackwave had taken the initiative to begin putting the WarDrive of Las Vegas together, I asked him to help out with organizing the contest, and he agreed.

All of this was taking place about six weeks before DefCon so we were under some serious time constraints to get things planned and organized before DefCon started. The first thing we needed to do was assemble a staff. We immediately brought Russ Rogers on board to help us coordinate with the DefCon organizers. This was an easy choice as Russ had been a member of the DefCon staff for several years longer than I had and was more likely to get timely responses to issues the contest staff might run into. Next, we brought on FAWCR and FReCKLeS to work the sign-up booth. Sign-ups would be done on site in the Vendor Area at DefCon.

The last piece of the puzzle was scoring. We were about a month away from DefCon and still hadn’t determined the rules for the contest. We decided it would be a good idea to bring a person on to exclusively handle the scoring for the contest. Pete Shipley volunteered to write a script for scoring as well as generate all of the maps that would be needed.

Determining the Rules

Now that we had a staff in place, we needed to determine the rules of the contest. It was imperative that the contest be a WarDriving contest, and not a free for all where people would attempt to gain unauthorized access to wireless networks that were deployed throughout Las Vegas. In order to accomplish this, we needed to state clearly the goals of the contest. We decided to award one point for every access point that each team found. If more than one person on a team found the same access point, it would only be counted once. An additional two points would be awarded for access points that had both a default Service Set Identifier (SSID) and did not have Wired Equivalent Protocol (WEP) encryption enabled. Finally, five more points would be awarded for each access point that was only discovered by one team and no other. This made it possible to get up to eight points for a single access point. Pete quickly wrote the following PERL script, which has become the basis for several other programs (as discussed later in this chapter), to automate the scoring process for the contest:

 #!/usr/bin/perl -w # Sun Jul 28 18:55:00 PDT 2002 # # # this could have been done in one pass with half lines (and run 50% faster) # but I wanted it to be readable, so people can't complain about their  # scores. # #          -Pete Shipley <shipley@dis.org> #           http://www.dis.org/shipley # # # score = #_of_APs + ( #_of_open_APs * 2 ) + ( #_unique_APs * 5) # # Input: # # From Netstumbler: #     Menu -> File -> Export -> Summary # # N 37.8627800\tW 122.2762283\t( linksys )\tBBS\t( 00:04:5a:26:ee:dd )\t03:21:36 (GMT)\t[ 14 66 52 ]\t# (  )\t0001\t0040\t100 # # the Lat & Lon can be signed or have N/W designations. # # # To run: # #     ./score.pl teamA.txt teamB.txt teamC.txt teamD.txt ... # # Teamnames can be the chars a-z0-9 and "-"  # #change this to starting/base location local $home_lat = 37.8645117; local $home_lon = -122.2802733; # a hash of teamnames local %teams; local %ssids; # a hash array of found APs for scoring unique APs local %allaps; # list of default SSIDs local $default_list = "^101\$".                         "|^WLAN\$".                         "|^Default SSID\$".                         "|^Wavelan\$".                         "|^tsunami\$".                         "|^WaveLAN Network".                         "|^Apple Network [0-9a-f]+".                         "|^Air[Pp]ort Network [0-9a-f]+".                         "|^default\$".                         "|^ANY\$".                         "|^any\$".                         "|^linksys\$".                         "|^Wireless\$".                         "|^2\$".                         "|^BRIDGE\$".                         "|^Compaq\$".                         "|^xlan\$".                         "|^intel\$".                         "|^comcomcom\$"; sub main {     my $total;     foreach $i ( @ARGV )  {      my $teamname;      my %teamdata;      my $score;      $i =~ /([\w\d-]*)\.txt/;      $teamname = $1;      $teams{$teamname}->{score} = 0;      $teams{$teamname}->{apcount} = 0;      $teams{$teamname}->{unique_ap} = 0;      $teams{$teamname}->{open_ap} = 0;      $teams{$teamname}->{score} = 0;      $teams{$teamname}->{distance} = 0;      $teams{$teamname}->{withwep} = 0;      $teams{$teamname}->{default_ssid} = 0;      # read in the teams data as an array and save it      # ignoring comments, 0 lat&lon, and invalid lines      &read_team_data($teamname);      # test stuff;      #print "$teamname:  $teams{$teamname}->{score}  APs\n";      #$ha = $teams{$teamname}{data};      #$score =  keys %$ha;      #print "Score = $score\n";     }     # work out unique AP  bonuses     # and store them in the team hash     &calc_team_scores;     # print out the results for each team     foreach $k ( keys %teams ) {      my $j;      my $ha = $teams{$k}{data};      print  "\n$k :\n";      print  "\t $teams{$k}{apcount}\tAPs located\n";      next if $teams{$k}{apcount} == 0;      print  "\t $teams{$k}{unique_ap}\tUnique APs, ";      printf "%3.1f%%\n",               ( ($teams{$k}{unique_ap} / $teams{$k}{apcount}) * 100.0);      print  "\t $teams{$k}{open_ap}\tOpen/Default APs\n";      # some extra stats       printf "\t\t%3.1f%% WEP, %3.1f%% Default SSID, %3.1f%% noWEP & Default SSID\n",           ( ($teams{$k}{withwep} / $teams{$k}{apcount}) * 100.0),           ( ($teams{$k}{default_ssid} / $teams{$k}{apcount}) * 100.0),           ( ($teams{$k}{open_ap} / $teams{$k}{apcount}) * 100.0);      printf "\t\t%2.3f\tMost distant AP (Miles)\n", $teams{$k}{distance};      print  "\t $teams{$k}{score}\tTotal Score\n";      print  "\n\n";      # test stuff; #     print " withwep $teams{$k}{withwep}". #          " default_ssid $teams{$k}{default_ssid}\n";     }     # some more extra stats     $total = keys %allaps;     print "Total APs found $total\n";     $total = keys %ssids;     print "Total SSIDs found $total\n";     return; } # it would be faster and cleaner to do all the math here but then  # people may complain about their scores if they can't see the number add up # in front of them # sub calc_team_scores {     my $team;     my $mac;     foreach $team ( keys %teams ) {      my $aplist = $teams{$team}{data};      # first we have to work out the number of unique APs located      foreach $mac ( keys %$aplist ) {          $teams{$team}->{unique_ap}++     if ( $allaps{$mac} == 1);      }      # then do the math       $teams{$team}->{score} =             $teams{$team}->{apcount} +           ( $teams{$team}->{unique_ap} * 5) +           ( $teams{$team}->{open_ap}   * 2);     }     return; } # Approximate distance in miles is simply:  sqrt(x * x + y * y) # #     where x = 69.1 * (lat2 - lat1) #     and y = 69.1 * (lon2 - lon1) * cos(lat1/57.3)  # sub distance_in_miles {     my ($lat, $lon) = @_;     my ($x, $y);     return 0 if ($lat == 0.0);     $x = 69.1 * ($home_lat - $lat);     $y = 69.1 * ($home_lon - $lon) * cos($lat/57.3);     return( sqrt($x * $x + $y * $y)); } # read in the log, count wep, and ssid stuff.. sub read_team_data {     local ($team) = @_;      local %known_macs;     local $j = 0;     local $dist;     local $distance = 0;     local $total_default_ssid = 0;     local $total_wep = 0;     local $total_open = 0;     unless (open STUMBLE_LOG, $i) {      warn "Failed to open $i: $!\n";      return ;     }     while (<STUMBLE_LOG>) {      my @junk;      local ($lat, $lon, $ssid, $mac, $flag) = 0;      local $has_wep = 0;      local $has_default_ssid = 0;      chomp;      my $line = $_;      next if /^$/;  # skip blank lines      next if /^#/;  # skip comment lines      @junk = split(/\t/);      next if $#junk < 9; # skip short lines      # extract lat & lon      $lat = $junk[0];      $lon = $junk[1];      #extract MAC address          $junk[4] =~ m/([0-9a-f][0-9a-f]:[0-9a-f][0-9a-f]:[0-9a-f][0-9a-          f]:[09a-f][0-9a-f]:[0-9a-f][0-9a-f]:[0-9a-f][0-9a-f])/;      $mac = $1;      next unless defined $mac;     # skip bad mac lines      $mac =~ tr/a-z/A-Z/;      # extract SSID      $junk[2] =~ /\(\s+(.*)\s+\)/;      $ssid = $1;      $has_default_ssid = 1 if ($ssid =~ /$default_list/);      # extract flag for testing for WEP usage.      if ( defined $junk[8]) {          $flag = hex $junk[8];      } else {          $flag = 0;      }      $has_wep = 1 if ($flag & 0x0010);      # convert lat and lon to signed decimal       if ($lon =~ /^[EW]/i ) {          @junk=split(/\s/,$lon);          $lon=$junk[1];          $lon *= -1 if $junk[0] =~ /W/i;          @junk=split(/\s/,$lat);          $lat=$junk[1];          $lat *= -1 if $junk[0] =~ /S/i;      }      # skip AP with out a location (lat = 0)      next unless ($lat != 0.0);      # record each MAC once...      unless (defined $known_macs{$mac}) {          $known_macs{$mac} = $line ;          $allaps{$mac}++;          $j++;          $ssids{$ssid}++;          # calc distance and record greatest distance          # this can be useful for close ties and runner-ups          $dist = distance_in_miles($lat, $lon);          $distance = $dist if ($distance < $dist);          $total_wep++ if $has_wep;          $total_default_ssid++ if $has_default_ssid;          $total_open++ if ( $has_default_ssid == 1 && $has_wep == 0);       }      next;     }     close(STUMBLE_LOG);     # count test.     #print "j = $j\n";     $teams{$team}->{apcount} = $j;     $teams{$team}->{data} = \%known_macs;     $teams{$team}->{distance} = $distance;     $teams{$team}->{open_ap} = $total_open;     $teams{$team}->{withwep} = $total_wep;     $teams{$team}->{default_ssid} = $total_default_ssid;     return; } &main;

Initially, we had considered allowing the contestants to drive at any time for as long as they wanted, but this idea was quickly discarded because it would be completely unmanageable. After a lot of discussion amongst the contest staff, we decided it would be best to have everyone WarDriving at the same time. We also decided to limit it to a two-hour time frame and that a maximum of four people could participate on a team. This included the driver(s) and any direct participants. In order to further standardize the results, all data that was turned in to the contest staff for scoring had to be in wi-scan format with extensions.

Note 

One theme of the DefCon WarDriving Contest that still holds true to this day is the loose wording of the rules. We have always maintained the position that if it isn’t specifically forbidden, it is allowed. We have taken some criticism for this stance, but because it is a hacker conference, we always want to see what new and innovative ideas people will come up with to meet the letter of the law while skirting the spirit of it. This has led to some interesting results, as you will see in the Lessons Learned sections later in this chapter.

Running the Contest

A couple of weeks before the contest, bks from NetStumbler (www.netstumbler.com) contacted me and asked if NetStumbler.com could sponsor the contest. He offered a 5-dBi omni-directional antenna, ten ORiNOCO pigtails, and ten t-shirts as prizes. I was excited at the prospect of associating the contest with NetStumbler and this was the first time that I had considered not paying for the prizes out of my own pocket. This is a good thing, since the winners would probably have just gotten a t-shirt if I had been forced to pay for the prizes. As soon as I posted the rules at the Security Tribe Web site, I started getting e-mails from other people that wanted to donate prizes to the contest. We ended up with several t-shirts, beer steins, 802.11b wireless cards, stickers, a laptop computer, and more. We had enough prizes to give the top five teams some sort of prize; this far exceeded our expectations.

To sign up for the contest, anyone who was interested was required to sign up at the WarDriving contest table in the Vendor area at DefCon. We expected that about 20–25 people would be interested in competing and were prepared for that type of response. On Friday when the vendor area opened, we put FAWCR and FReCKLeS at the sign-up table and both blackwave and I spent some time there as well. Contestants were required to sign up with a team name, and the names or handles of their team members. We had a piece of regular lined paper for people to sign up on, and no sign to alert people of the sign-up location at all. blackwave drew an extremely cheesy-looking “Sign Up for WarDrive Here” sign on a couple of sheets of printer paper and taped it to the wall to tell potential contestants where to sign up. Since a good portion of DefCon attendees either don’t have a car or couldn’t put a complete team together, we took it upon ourselves to assemble teams for those that wanted to compete, but were lacking transportation, a complete team, or both.

To our complete surprise, over 100 contestants on twenty-six teams signed up for the contest. Of those twenty-six teams, about half were teams that signed up together, the other half were teams that we put together on site. This contest would take place throughout the city of Las Vegas as opposed to on the grounds of the Alexis Park Hotel. Because of this, and the overwhelming response to the contest, the organizers started to get nervous. The DefCon lawyer came to me and told me that in order to participate in the contest, each contestant would have to sign a “hold harmless” legal disclaimer (see Figure 8.1).

click to expand
Figure 8.1: The DefCon 10 WarDriving Contest Legal Disclaimer

We had reserved a room at DefCon to meet and kick off the contest. All of the people that had signed up needed to be in the room an hour prior to the start of the contest. Anyone that needed to be assigned to a team received their team assignments at this time. This is also when we passed the disclaimer forms out for signature. We let the contestants know that if they did not sign the disclaimer, they could not participate. Each result that was uploaded would be cross-referenced with the disclaimer to ensure that we had one on file before their results would count. Many DefCon attendees were very privacy- and anonymity-conscious and the disclaimer did not sit well with some of them, especially since it was never mentioned before they were required to sign it. About 20 people on five teams refused to sign the disclaimer and dropped out of the contest. This left us with about 80 contestants on 21 teams.

We immediately experienced two problems. First, it took more than an hour to get the teams assigned and all of the disclaimers signed. Second, because we had about 80 participants, all of whom were scheduled to leave the same place simultaneously, it was no longer feasible to do it this way. With 80 people driving the same area simultaneously, this was the largest coordinated WarDrive that had ever been undertaken (at the time). If we had done a “gentlemen start your engines” type of start, there would have been a massive traffic jam just getting out of the parking lot of the Alexis Park. Since we had limited the contestants to only two hours of drive time, we were afraid that some contestants would spend a good portion of that time just trying to get out of the Alexis Park parking lot. I coordinated with Pete Shipley and we decided that we would modify the rules slightly and start scoring each person’s data at the timestamp of the first access point found rather than at a specific time. Any access points that they found in the next two hours would count. That way people wouldn’t have to worry about getting stuck in a traffic jam and wouldn’t take unnecessary risks while driving.

Once everyone had taken to the streets blackwave, FAWCR, and I organized the disclaimers and turned them over to the lawyer. Pete spent the next hour and a half doing interviews and preparing to score the data. After all of the disclaimers were turned over, blackwave and I began preparation for the data dump. Our intent was for Pete to have an anonymous FTP server on the DefCon wireless LAN. We had a room reserved for the data dump so that if people had any problems uploading their data, we would be there to help out.

The WarDrive itself went off without any incidents. No one had broken any laws, no one warchalked any of the found access points, no one was arrested or detained for traffic violations. About two hours after the start of the WarDrive, teams started to file into the data dump area to upload their results for scoring. We thought that the hard part was over at this point… we were very much mistaken.

The one lesson that any DefCon staff member should always remember is that DefCon is a hacker conference. Nothing ever goes as planned and the data dump was no exception. As people started filing in, we announced, verbally, the IP address of the data dump FTP server. Word spread like wildfire throughout the conference and within a few minutes there were at least 20 fake data dump FTP servers put online. We had to defend against man-in-the-middle attacks, ARP spoofing, data sniffing, and other assaults. The number of attacks we were fending off was staggering, but in the end caused a Denial of Service against our FTP server.

About one third of the contestants actually got their data up to the FTP server without issue. Another third uploaded their data with some assistance from us. Pete and I were furiously tracking down the bogus dump servers that had gone online and got as many as possible shut down. This helped people in getting to the legitimate server, but the ARP spoofing continued throughout the evening. Finally, after about two hours we told the remaining third of the contestants that hadn’t been able to get their data to us that we would allow them to give us their data on floppy disk, CD, or USB drive. We finally had all the data and could begin scoring.

Both Converge and Tim McGuffin had written scripts that would convert Kismet logs into wi-scan format with extensions. These had been put on the contest Web page so that people didn’t have to write their own conversion script. A lot of the contestants seemed to have a hard time using them correctly, however, and many of the data sets were not formatted correctly. Pete and I discussed how to handle this. We wanted as many “scored” results as possible, especially since this was the first contest of its sort and we wanted a good showing. We wanted to make sure all the contestants enjoyed themselves. Not scoring their data would have frustrated a lot of them. Also, a good deal of press interest had been generated in the contest and we wanted a good showing for any stories that were written. Pete decided that he would manually fix the bad data sets so that he could score them. I am sure that he thought this was going to be a short process—probably an hour or two. It ended up taking Pete nearly ten hours to get all of the data sets that were incorrectly formatted into a state where they could be scored.

Once all of the data had been converted into a usable format, scoring itself went relatively smoothly. A total of 1804 unique access points were discovered in and around Las Vegas. Of the 21 teams that submitted data, four had data sets that we were unable to correctly format, so they received scores of zero. The other 17 teams had their data scored. Team WirelessCon won with a total score of 1893. They detected 550 access points, 42 percent of which (231) were unique to their team. One team had either converted their data badly or attempted to cheat (we believe their data conversion script was bad) and all of their access points were in the middle of the Pacific Ocean. We gave them a score of zero. The complete results of the DefCon 10 WarDriving Contest can be found at www.defcon.org/html/defcon-10/dc-10-post/defcon-10-wardrive-post.html.

Lessons Learned

We learned several lessons during the inaugural year of the DefCon WarDriving Contest. One of the biggest hurdles that we ran into was the problem of getting the Kismet data properly converted into wi-scan format with extensions. We knew that we had to address this issue before we could have a truly successful contest and started working on a remedy (which is discussed later in this chapter) about one month after DefCon 10 ended.

The prize situation also needed to be addressed. NetStumbler came through with exactly what they promised and those were some of the most popular prizes. DefCon provided each member of the first place team with a black DefCon badge. This badge entitled the winner to free admission to DefCon 11 and is only given to contest winners. Because there is no way to get the black badge other than winning, it is one of the most coveted pieces of DefCon memorabilia. Unfortunately, some of the prizes donated did not live up to their billing. The best example of this is the laptop computer. It was donated in non-working order with no power supply and a dead battery. This prize was awarded to the second place team who never got it in working order. There were several similar instances with the prizes. Again, we determined that prizes would need to be addressed early in the planning process for the next year. The “bragging rights” of winning a DefCon contest are important, but a tangible prize is also important.

We learned a serious lesson about the DefCon wireless network; don’t rely on it! Because of the nature of the conference, people are going to interfere with the DefCon wireless network. We decided before DefCon 10 ended that we would place the contest data server on the wired network for future contests. As is noted later in this chapter, we still had more lessons to learn in this regard at DefCon 11.

Our sign was sad. We certainly learned that we needed to plan well in advance and get a professional looking sign printed up to let people know where the registration area was located. blackwave did the best he could and even put the )( Open Node warchalking symbol on the sign he drew up. That didn’t change the fact that while Capture The Flag unveiled their most elaborate set up to date, complete with a live scoreboard on a giant screen, we had a hand-drawn sign on blank printer paper. This would be remedied for the next contest.

The idea of loosely defining the rules definitely worked. In the true spirit of following the letter of the law but not the spirit one team, the Shmoo group, attempted an extremely innovative maneuver. They approached a local television news station and offered up a “ride along” on the contest for a news crew. There was one catch to the offer. The news crew had to provide the transportation, their traffic helicopter. They would be able to cover the entire city and more in the two hours allotted with plenty of time to spare. I got wind of this a few hours before the contest started, and was thrilled with the idea. This was the type of idea that would generate buzz about the contest and would be talked about for years to come. Unfortunately, the news crew didn’t show up at the appointed meeting place so the contestants had to resort to more conventional means. Also, because it had now been tried, I implemented “The Shmoo Rule” for future contests: Ground transportation only.

Finally, we learned that the sign-up process we had in place was completely unmanageable. We had virtually no idea how many contestants to expect, and only planned for about one quarter of the actual number of participants. We hadn’t automated many aspects of sign-up and team assignment because we really thought it would be simple to do it once we were at DefCon. We knew that we had to have an online sign-up process in place prior to DefCon 11 in order to know how many people were going to participate, plan for them, and make the contest run more smoothly.

Post DefCon 10 Discussion

Once I got home from DefCon, I monitored the DefCon Forums and the NetStumbler Forums to try to get a feel for the contestants’ opinions of the contest. For the most part, the response was good. The problems that we already knew about were pointed out. Still, the people who participated almost all said that they had a good time and would participate the next year. That was our primary goal, so we considered the contest a success despite the problems we had run into. I found out on the NetStumbler Forums that The Watcher, one of the members of Team WirelessCon, lived very close to me. I contacted him about an idea I had to do a WarDrive of the entire city of Baltimore and asked him if he would be interested in working on this with me. He was interested. I didn’t realize it at the time, but a new phase of organized WarDriving had just begun.



 < Day Day Up > 



WarDriving(c) Drive, Detect, Defend(c) A Guide to Wireless Security
Special Edition Using Macromedia Studio 8
ISBN: N/A
EAN: 2147483647
Year: 2006
Pages: 125

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net