Security Ripcord

Once again, on a weekend trip to Las Vegas, I found myself perplexed by the challenging mind of LosT.  I started a little late this year.  The team I was on took care of the registration before I even knew it was up.  I basically became involved when the team put out a call for tools.  Tools to use for programming, decryption, lockpicking, curcuit board manipulation, wireless analysis, and general smashing and bashing if ultimately necessary.

From the beginning we knew we were going to have our work cut out for us.  Not only did we have to deal with LosT’s mind, we also had to deal with the fact that two of our team members could not make it out to DefCon 17.  Gluttons for sleepless nights, however, they elected to make themselves available during the contest.  So we set up a team account via Google Sites and included Picasa access because we knew pictures of each stage would be very important.  Our team, Security Catalysts, consisted of Jon, myself, Ellen, Q, Travis, and Tim (last names withheld to protect the innocent, and so forth).  We had worked together last year and we were hoping to make up for some of the things we could have done better at DefCon 16.

Stage 1

As usual the Mystery Challenge started out simple enough, a single envelop with instructions and a picture.  This time LosT decided to play a little trick on us all.  It started with tips in the DefCon Forums and Ten-Five-Seven which recommended that teams make alliances.  The instructions provided in the envelop made clear why it was important.  The twelve teams participating in the competition were split into three groups each designated by a picture and a list of characteristics that defined their activities.  The groups consisted of Humans, Vampires, and Vampire Slayers.  A picture of the Vampire Slayer can be found in LosT’s post Team Reactions, Reflections, Responses.  Our team was designated as Humans.

Our instructions basically boiled down to being able to lie about who and what we were designated.  As we did not know the instructions provided to the other groups we did not know what to expect.  The only thing we were certain of was spelled out in the instructions.  Vampires want to kill humans, Vampire Slayers kill Vampires, and Human do not trust Vampire Slayers.

LosT’s desire was for all of the teams to interact, mingle, talk to each other about their groups capabilities and, ultimately, split into groups that they should naturally want to gravitate to for survival.  Of course, he was asking some of the most introverted personality types, people who are primarily use to accomplishing things by themselves or via tight-knit groups, to break out of their shells and participate in conversations with people they don’t want to trust out of an overwhelming desire to keep the other teams at a disadvantage. Of course the majority of the teams kept to their nature and interacted only grudgingly.  Interestingly enough, after about 20 minutes, another portion of their nature came out during the brief and guarded interactions.  The majority of the teams decided to hack the contest.  Instead of acting as they had been designated by LosT they created their own designation.  They decided that the best policy was to act as zombies.  They chose to not answer questions and when called to select other groups they agreed to congregate together as zombies always do.  LosT got a kick out of this approach and in the end the strategy worked to the advantage of the humans.

Stage 2

Next came the shoebox.  A simple box filled with simple objects and a note.  The objects in the box, as usual, didn’t appear to mean much.  Some candy, a band pin, some army men, a few other knickknacks, and a card for a passcode.   The note contained several backwards letters that said “Some Place, grey, facility, when, where”.  LosT also provided each team with a transparent sheet with some interesting characters on it.

We started off looking at this sheet.  It didn’t take long to figure out what all of this meant because we noticed a lot of quick movement by Mouse, Renderman, and Dragorn.  We hung around a few minutes before running off and we were rewarded with a translation of these Japanese and Korean characters (I may be mistaken about the languages).  The top line, if you haven’t figured it out yet, is 1057.  The second line is 421.  The third line is 2041.  The lines on the right hand side are two different sayings.  One facing forward and the other facing the back of the paper.  The top line reads, “When people are watching you” and the bottom line reads “When attackers learn the shadow play.”  Or, so we were told.

As this sheet didn’t provide us with very much useful information we decided that the information it provided was to be used during another stage.  A little frustrated, we reviewed everything that LosT had provided us again.  After staring at everything for a while we started branching out to include other things that we thought might be clues.  After searching the badge and not finding anything we turned to the DefCon program.  This had several interesting clues from LosT in it.  The one that interested us the most at first was on page 9.  The image in the center of the picture turned out to be an encryption technique known as Gray Code.

Because of the obvious connections to the note, we spent quite a bit of time figuring it out and applying it to all of the number sequences.  For those of you that are not completely familiar with Gray Code (as I was not) you can think of it as a substitution method for numbers.  In the US Marines we often used “Scubadiver” in a similar manner to disguise numbers such as grid coordinates or radio frequencies.  But, after running through all of the number we could find, nothing really popped out as useful.  Next we moved onto page 25.

Luckily, Ellen had already recognized this as a transposition cipher (Hint: there is a 1, 7, and : in there which gives it away) and had translated it (Thank you, Ellen).  As it turns out, the clue we needed was the very last two words of this decrypted text: BADGE FACADE.  Now, those of you who are good at math might have already noticed something about these two words.  For those of us who are not good at math we struggled through trying to figure out what other clues meant.  After a while, and a bunch more clues by LosT we realized that we were looking for a Base 17 number that needed to be converted to Base 10.  Back to math.  Base 16 -> 0123456789ABCDEF but Base 17 0123456789ABCDEFG.  G, is the key. BADGE FACADE == 23459422056522.  This was the Passcode we needed to move on.  It was definitely harder to figure out that this one paragraph describes, but at least at this point we could move on.

Stage 3

Last year LosT made the 2 GB MicroSD card difficult to find because he hid it inside the binding of a book.  This year he passed it to me during a handshake as he congratulated us for completing Stage 2.  He told us that we could take the rest of the night off to enjoy the DefCon festivities because even if we determine what was necessary to move onto Stage 4 he would not be able to move us to the next stage until the following morning.  So, we immediately started working on the puzzle.  Quick review of the MicroSD card showed us that we had 1 GB worth of audio files, the majority of which were MP3s.  There was one ReadMe.txt file that contained the following information:

So I know you’ve been working hard.
Here is some music to work by.
Put it on, set it to random play, and enjoy!
(It’s quite the mix…I know, I have weird taste~)

Now I know you are asking yourselves,
Why did he give this to us?

Well- I could have copied my M.O. from other years,
and there could be something sneaky-  but that would be
LAME.  I wouldn’t have the audacity to do that to you
again.

Enjoy!

Ryan “1o57″

Of course “Audacity” and “LAME” popped out to us and we figured that LosT modified one of more of the files using Audacity.  We started reviewing the files when we remembered that LosT had placed a few CD-Roms on his table.  We decided to take a look at the songs on this album and see if it was a clue for this stage.

A quick search showed us that the first song on the album had a similar file name to one of the songs on the MicroSD card.  The file MarchofProgress1.mp3 turned out to not be a song at all.  When played with Audacity it was just a bunch of noise.  Bingo….now, what to do with the file to figure out what LosT had done to the file.  Not knowing much about the things you can do with audio files I just started looking at different settings as well as viewing the hexdump of the file.  Fortunately some of our team members did know some of the things that could be done with an audio file and before I knew it I was instructed to download FooBar2000 and play the file as a Spectrogram (not spectrograph).  This produced the following image with the passphrase necessary to move onto the next stage.

We interpreted this as:

The route you get your kicks on
taken away from the devil
Bauds well when you are
focused
Pass Phrase:
Hangook

Stage 4

Our reward for the passphrase Hangook were two slips of paper.  One contained some encrypted text, and the other contained the clues.

As we have several team members who have been coming to DefCon for years now, the clue was easy to figure out.  We needed to find the DefCon Goons, Roamer, Pyro, or Russ (not sure if I got the spelling of those names correct).  We also thought that we might need to get one or more of them a Rolling Rock beer, but that did not turn out to be the case.  When we asked Pyro for some advice he stated “What would I need if I wanted to play Blackjack?”  After thanking him we walked over to LosT and requested a deck of cards.  He provided us with a sealed deck of cards.  Once again I had no idea what to do.  Luckily we had several team member that had read Cryptonomicon.  In this book Bruce Schneier outlines the Solitaire Encryption Algorithm.  We figured that we needed to pull the cards out, maintain the order, and record the card positions for future use.  Of course, it was not until I had pulled out all of the cards that I realized one of the cards was still in the box.  I recorded the card order and then started looking into how to use it to decrypt the cipher text.  After reviewing several tools we decided to go with the C++ GUI Solitaire Encryption/Decryption Tool.  Downloading this tool was the easiest part of using this tool.  The order of the cards is very important, and being sure to have all the cards in your list is also important.  We ended up creating several card decks (which the tool let us save) because we did not know which card was the first card and which Joker was the high or low Joker card.  Once we had the tool figured out we  checked with Mouse, Renderman, and Dragorn to determine where the Ace of Spades was placed in the deck.  Of course, it was our forth deck that decrypted the cipher text.  We were rewarded with the following text.

ASKFO RREDW EDGEU SEINN ARDSS ENDLO STINB YTESR EPEAT EDLYX

Actually, I almost missed the fact that this was the result we were looking to find because of the five character blocks.  Spaced properly it says:

ASK FOR RED WEDGE USE INNARDS SEND LOST IN BYTES REPEATEDLY

Not sure what the Red Wedge could be, we set off to ask LosT for it.  One piece of the puzzle I forgot to mention is that the deck of cards also contained an RFID card.  As we did not have an RFID reader we never determine the information that was contained on the card.  Actually, we never determine what the card was used for and, unfortunately, we ended up losing the card as we moved onto the next stages.

Stage 5

The Red Wedge turned out to be a heavy metal triangle box with two locks on one end a some writing on the base.  Although there were two locks on the box it was only necessary to open the keyed lock to get into the Red Wedge.  The other lock was a combination lock that had its numbers set at “1057″.

I have to say that LosT must have done something to the keyed lock.  Because I was able to pick it in less than a minute.  Next we set Deviant loose on the combination lock and he had it solved in less than 5 minutes.  Its combination was “5151″.

Quick work by Ellen determined that the saying on the base of the Red Wedge was referring to a picture on the Internet.  Specifically, it was a piece of artwork by Eddie The Yeti titled 1057.  The text in the comments for this artwork looked very important, so we noted it for future use.  However, if it did actually mean anything we do not know.  We were unable to find any significants during the rest of the challenge even though we tried all of the tricks used in the previous stages.

For my Friend LostboY

1001110101111000101000001111010111101
0001101010111111010010101011101101010

n0t 4ll m4gn3t5 4ttr4ct

When robots die are their bodies consumed by magnets?

Since we had the Red Wedge open, we all started looking at its contents.  Here is a basic list of items (I may be missing some things or have them listed wrong as I am not a hardware guy.)

• Parallax 433.92 MHz RF Receiver (#27981)
• Parallax BASIC Stamp BS2-IC
• Parallax SERIAL LCD
• Battery connector
• Solderless Breadboard
• USB Cable
• various other components (light, capacitors, etc)

Now, I could start going into detail about all of the things we did to try and figure out what LosT had in mind.  But that would be tedious for me to write and you to read.  The basic gist of everything is that LosT wanted us to build something to interact with several devices on his table.

This image is just one of the boxes containing hardware on LosT’s table.  The other box had an antenna (that we assumed was for transmitting) and a light input sensor (I don’t know that actual name for the sensor so forgive me if I am wrong.).  The plexi-glass on this box was badly scratched, so no good pictures are available (from our archives).  Basically, we spent a full night trying to detect radio transmissions from the transmitter.  We ended up going to sleep after spending most of the night finding nothing.

The next morning all of the teams gathered around LosT’s table to try out their theories.  It was readily apparent that the other teams were leaning towards interacting with the light sensor rather than the radio transmitter.  So, we set about to do the same.  Several team members started working on getting the hardware working while I started looking into the code to “SEND LOST IN BYTES REPEATEDLY”.  After a bunch of trial and errors, spilled beer, team interactions, and some help from LosT we finally found the solution.  Basically most of our problems really boiled down to the code we were using to send our information.  I was using the following code.

DO
serout 7, 18030, [10,57]
LOOP

Our light emitter was connected to pin seven.  From watching other teams we determined that they were using a Baud rate of 600.  Initially we tried using a setting of 1646 in our code, but then we realized that we needed to send our information without parity which meant that we needed to use the 18030 setting.  Finally we determined that we needed to send LosT as data.  So we opted for sending an array of data which included the bytes 10 and 57.  This didn’t work and we were at a loose for what to try next other than mix up the bytes we were sending.

It took everybody a while to figure what to send for some reason.  So, after a while of trying LosT provided the code so send the proper bytes.  His code looked a little like ours but with one significant difference.

DO
serout 7, 18030, [10]
serout 7, 18030, [57]
LOOP

Apparently, when data is sent as an array via the light emitter only the first byte really gets sent.  But, when sent separately the light receiver understands the information it is being sent and thereby initiates the code that its BASIC stamp has been coded to perform.  The result that we received as a statement on the LCD screen that indicated that it was transmitting some information.  So, the team started working on methods to receive the transmission.

Stage 7

While we were working on the code to make the BASIC Stamp receive and display information LosT started walking back and forth between the DefCon contest area and the DefCon vendor area.  We didn’t think anything of this because LosT is a very popular person at DefCon with many things going on.  However, it soon became apparent that we should have noticed his behavior.  It was soon pointed out to us that something very important was occurring in the vendor area.  At one of the tables a strobe light would periodically start flashing and then a Mannequin Wig Display with a missing eye started flashing light.  When I stood in front of the light it projected a square outline onto my shirt that was followed by a series of flashing square blocks at different locations within the square outline.  These flashing squares were followed by the words “Passphrase: Mustang”.

After a bit of thinking and watching other teams we realized that LosT intended us to place the transparent sheet we received in Stage 2 in front of the light.  It also took us a few minutes to realize that the projector in the head was triggered every time a team successfully used their light emitter to cause LosT’s box to transmit.  So, we worked with Mouse, Renderman, and Dragorn again.  They activated with projector and we used an iPhone to record how the lights flashed across the transparent sheet.  It took us several tries but in the end we had a good video of the lights flashing across both sides of the transparent sheet.  After reviewing the recordings it didn’t take very long for both of our teams to figure out that the flashing lights represented numbers and that these numbers, once combined, resembled a phone number.  We watched LosT as we dialed the number and sure enough his cellphone rang and he answered.  We told him the passphrase, he asked us to text it to him along with our team name, and we were done.

Final Thoughts

As usual the Mystery Challenge was excellent.  A true test of knowledge, abilities, observation, and team work.  After doing this challenge for the past three years I can say I was never bored during any of them.  Although the types of challenges are similar they are sufficiently different to keep us coming back for more.  However, there has always been enough consistency to allow teams to improve and to let  new teams who have done their research understand the challenges they will be presented with during the competition.

I know that I speak for our whole team when we say thank you to LosT for an excellent time.  If he is thinking about making DefCon 18 the final challenge then we will definitely be there to rise to the challenge again.  I honestly am going to have a hard time imagining DefCon without the Mystery Challenge.  I know that the talks this year were suppose to have been outstanding, but the reason I go to DefCon is to learn and do things that I might not usually be exposed to during my work and personal projects.

LosT, keep up the great work.  We really do appreciate it.

Team Security Catalyst, thank you for working together, not getting frustrated, and raising to the occasion again.  I have to say that Ellen turned out to be our most valuable team member again this year.  Great job, Ellen.

We also need to thank Mouse, Renderman, and Dragorn for being open to sharing information and solutions when we needed input during several difficult stages.  Team work really paid off this year.

For those of you who are fans of LosT and the Mystery Challenge, be sure to check out Ten-Five-Seven.  Please do LosT and the Mystery Challenge teams a favor and send an email to the organizations that helped sponsor the Mystery Challenge.  It takes more than just time and ingenuity to get this competition to occur so successfully.  Donations made by these sponsor allowed LosT to develop a diverse and challenging competition.  So, your support is very much appreciated.

See you next year.

Go forth and do good things,

Don C. Weber

While at Defcon 16 I had the chance to sit down with Monty McDougal.  It started out more as a quick lunch to catch up with Monty as I had not seen him in quite a while.  But after catching up with him he told me that he had made some significant modifications to his WINDOWS FORENSIC TOOLCHEST™ (WFT).  The last time I had worked with WFT it was at version 1.01 and Monty did not have time to devote to updating the tool with some of the new features that were rolling around in his head.  I knew that this disappointed him at the time because the tool had received such a good response from the SANS community.  Well, after speaking with Monty and looking at some of the updates that he has implemented I can see that he has been able to devote more than a little time to this excellent tool.

If you are not familiar with WFT, here is a brief overview from Monty’s website FoolMoon.net.

The Windows Forensic Toolchest™ (WFT) is designed to provide a structured and repeatable automated Live Forensic Response, Incident Response, or Audit on a Windows system while collecting security-relevant information from the system. WFT is essentially a forensically enhanced batch processing shell capable of running other security tools and producing HTML based reports in a forensically sound manner.

Actually, WFT is a lot more developed than this description.  WFT provides the user with a repeatable method to deploy many security and administrative tools designed to gather information about a Windows Operating System (OS).  These tools include tools present on specific OSes, tools provided through Windows Resource Kits, third-party tools, and even some tools (or soon to be) that Monty has written to include within WFT.  Monty goes to great lengths to respect all user agreements and licensing associated with each tool employed by WFT.  In version 3.0 the ability to automatically download tools and validate integrity is built directly into the toolchest’s functionality.  Updates to locations and code modifications are handled by an automated toolchest update process.  Although these methods of acquiring tools work when Internet access is available it is not always the case that connectivity will be available.  Monty has taken this into considetion and provided the WFT update capabilities to utilize the Helix Incident Response & Computer Forensics CD-ROM as a source for the tools.

I was very surprised when Monty mentioned that he is now charging for the use of WFT.  In the FAQ on his site, Monty explains why he has moved to the commercial model.

What happened to the free version of Windows Forensic Toolchest™ (WFT)?

After providing WFT for free to the security community for nearly 4 years, I have decided to make version 3.x a commercial product. WFT is still available for download, but the downloaded version is restricted to specific uses identified within its license. WFT has consumed several hundred hours of development and support over the last few years, and while $100 is a modest amount, it will help motivate me to continue to develop and support WFT (since the donation model did not work out at all). There is also a new WFT Pro version in development which will include several additional features useful in an enterprise environment along with a new GUI. Pricing for this version will be slightly higher, but will also include WFT. Paid WFT users will of course receive 100% upgrade credit towards the upcoming Pro version. I have no plans of supporting the 1.x or 2.x code bases in the immediate future and will instead be focusing on bringing new features to version 3.x.

At the time I am writing this post the restricted version is no longer available for download and I can only assume that WFT has gone completely commercial at this time.  This means it is very likely that it will no longer be available via the Helix CD-ROM which was one of the original ways to obtain this tool.  Persons who have versions of WFT on their current Helix CD-ROMs will also find out that their version is broken due to a WFT update script.  When I questioned Monty about this he told me that the Helix update script was necessary to force Helix users to up-to-date versions of WFT because he could not support the questions he was getting about out-of-date versions.  He did assure me, however, that although the script on the current version of Helix is broken, he will be releasing a patch soon, which should be available on his website.  If you do not find it there (I did not at the time of writing this post) you can attempt to contact Monty and I am sure he will get back to you as soon as his busy travel schedule permits.  Unfortunately, it may be the case that he has dropped support for Helix altogether, but this has not been confirmed.

One of the things that Monty did show me while we were talking about WFT was the new Graphical User Interface (GUI).  This GUI will be provided as a part of a PRO version of WFT.  Currently the toolchest is controlled via a detailed configuration file.  The GUI will give the user complete control over which tools are run and how/when the tools are updated.  He was very excited that he was nearing the conclusion of this milestone as it was going to permit him to pursue some other key features that he has been considering.  These features include reporting tool outputs to a remote system, rewrites of certain tools so they do not have to be downloaded, and new tools that provide unique features.

It is unfortunate that I did not get a chance to test drive the new version of WFT before writing this article.  I am hoping that I can convince my new colleagues to consider putting WFT into our toolkit for Live Response.  Having this tool would simplify so many aspects of scripting, tool maintenance, and tool and output hashing for verification and validation.  Yes, most of what WFT can do can be done by hand, but as I have mentioned before, having a repeatable process that is the same everytime is critical to providing a consistent and professional incident response.

I would like to wish Monty and WFT the best of luck in the future.  I am looking forward to their continued success.

Go forth and do good things,

Don C. Weber

As I have mentioned before, I and several other Security Catalysts were willing participants in the Mystery Box Challenge (MBC) hosted by LostboY at DefCon 16.  First of all I would like to thank LostboY for all of his hard work, extra time, and mountains of money that he devotes to the challenge each year, both before and DURING DefCon.  If you had participated in this year’s competition you could not have helped but wonder how much of all three he put in himself.  It is definitely impressive and I am definitely appreciative.

I was thinking about how I could best describe the MBC while demonstrating just how hard it really is to participate.  I decided that one of the best ways is to walk you through one of the problems that we had to solve.  This will not be a complete walk-through for two reasons. 1) I don’t have all the original documentation or pictures of them, and 2) the confusion due to misdirection (which is really LostboY’s favorite game) would get a little boring.  So, lets give it a shot.

To start everyone off LostboY gave each team an envelope with an Infared (IR) transmitter attached to the outside.  The IR transmitter has nothing to do with the initial portion of the challenge but keeping track of it while running around from place to place did take some effort.  The envelope contained a letter, which is one of the items I did not copy or take a picutre of, with a riddle.  Basically the text told us that we already had everything we needed and that we should look to tomes of knowledge and other traditions we had been given.  To make a long story short (by about 5 hours) the clues we needed were in the DefCon program and on our DefCon badges.  It turns out that LostboY decided to enlist the DefCon staff and Kingpin this year which should not have surprised us as we were looking in the DefCon 15 program (sorry, this year’s is not up yet) for clues last year.

Moving right along, what we needed were a block of encrypted text and a key to decrypt it.  Last year LostboY had used a One Time Pad to encrypt a clue and he decided that we would all understand if he used the same trick this year.  Of course, we had the same problem as last year, “Where is the @#$%ing key???”  It was pretty easy to find the cipher text.  It had LostboY’s name written all over it.  LostboY often refers to himself as 1057.  1057 in binary is 10000100001.  As you can see, this was included in the DefCon 16 program.

The picture of winged man is the image of The Monarch from the Venture Brothers (a recurring theme throughout the competition).  When we confronted LostboY about this he told us that Monarch plus the key means, well, Monarch-key.  It’s a joke, son.  Of course, nothing in the competition is a joke to the competitors, so we spent a good while think about what it could all mean.  The kanji at the bottom turns out stands for “1507″ which does not have any mean at this stage.  Nope, the only thing we needed at this stage was the block of text in one long line.  “XUQSITYPZYCYSHQDJBWPJPJTVTGJRCUARYVLQHJOKIDRAGIVWMQUSUPDNHJFITHOLPSBIUPYISMQJ
FOTXJEKLQBIBTPJXBNLVTHOFATHNSUFUFPFMNITHLRHPGIZL” this is the cipher text.  But where is the key?

After many hours of back and forth and many hints from LostboY on his projected screen of shame….I mean hints, we figured out that the key was also in the DefCon 16 program.  As it turns out, LostboY did an interview for the program to explain the thought process behind the competition.

Of course, in true LostboY fashion, it turns out that the first paragraph of the interview is the key for the cipher text.  This paragraph reads:

I get asked to explain the Mystery Challenges quite frequently. More frequently than that I am asked what the hell it is in the first place. I find it interesting that nobody ever asks why the Mystery Challenge (which has really come to be called ‘Mystery Box’). Why I spend months of my life, thousands of dollars and all my time at Defcon creating ciphers that are meant to be broken, strong boxes that are supposed to be breached, and circuits that are designed to be destroyed.

Which, when converted to work with a One Time Pad encryption scheme, for the supplied cipher text, turns into: “IGETASKEDTOEXPLAINTHEMYSTERYCHALLENGESQUITEFREQUENTLYMOREFREQUENTLYTHANTHATIAM
ASKEDWHATTHEHELLITISINTHEFIRSTPLACEIFINDITINTER”

Now, you can take the supplied cipher text and the supplied key and input these values into any One Time Pad program that you have available.  Luckily enough there is a PHP version in the Braingle’s Codes and Ciphers Website.  This website makes decryption easy as pie.  Just put the encrypted text and the key in the appropriate text boxes and you receive your answer “POMZIBOLWFOUVSFDBODIFDLBCPPLPVUPGUIFMPTUCPZMJCSBSZXJUIBMJCSBSZDBSEUIBUCFBSTIJTO
BNFBOEQIPUPIFMQFSNBZBMTPCFBCMFUPDIFDLUIJOHTPVU”.

Cool, right.  Read that again.  Does that spell anything to you?  Nope, me neither.

Now, I cannot really say for certain how anybody figured this out.  I currently have an email into LostboY to see if there was a hint about this anywhere since I do not remember one.  It turns out that this is ALMOST the correct answer.  If you take the answer given here and shift it one character to the left you’ll see the actual message: “ONLYHANKVENTURECANCHECKABOOKOUTOFTHELOSTBOYLIBRARYWITHALIBRARYCARDTHATBEARSHIS
NAMEANDPHOTOHELPERMAYALSOBEABLETOCHECKTHINGSOUT”.

Now, I did not figure this out by looking at it.  Indeed, I did not figure it out during the competition.  One of the other team members thought he remembered a shift from the DefCon 15 competition (I don’t remember that shift at all) so we tried it and got the answer.  Still, I couldn’t just “accept” this answer so I decided to write a One Time Pad program in Python just to satisfy my curiosity.

One Time Pad – Python

It is easy to use.  Although I did originally code a true OTP program, the one attached has been modified to provide the proper output for the challenge.

user@desktop:~/Dev/test_programs/python/crypto$ python otp2.py -d crypt.txt keyfile.txt result.txt
Input: XUQSITYPZYCYSHQDJBWPJPJTVTGJRCUARYVLQHJOKIDRAGIVWMQUSUPDNHJFITHOLPSBIUPYISMQJ
FOTXJEKLQBIBTPJXBNLVTHOFATHNSUFUFPFMNITHLRHPGIZL
Key:   IGETASKEDTOEXPLAINTHEMYSTERYCHALLENGESQUITEFREQUENTLYMOREFREQUENTLYTHAN
THATIAMASKED
Decrypting
Decrypted: ONLYHANKVENTURECANCHECKABOOKOUTOFTHELOSTBOYLIBRARYWITHALIBRARYCARDTHAT
BEARSHISNAMEANDPHOTOHELPERMAYALSOBEABLETOCHECKTHINGSOUT
user@desktop:~/Dev/test_programs/python/crypto$

Once we had the message all we had to do was follow the instructions.  The snag, however, is “what book?”  It turns out that in the original letter LostboY had mentioned ISBN, binary numbers, and palindromes.  We took this to mean that the book required a ISBN that was a binary palindrome like 10000100001.  Of course that was not it.  After some thinking we remembered that LostboY had mentioned the DefCon 16 badge.  Looking at the badge we found plenty of interesting features.  The most important feature was on the back, in the lower right hand corner, between the contact points for the USB adapter.

Clearly LostboY wanted us looking at this.  Once again 10000100001 in the first line is binary for 1057 or LosT.  The second line, if you cannot read it, is “21ADDDEC1024″.  This can be interpreted in several ways but the simplest way is add Hex 21, or 0×21, to decimal 1024.  0×24 = 33.  33 + 1024 = 1057 or LosT.  As we know LosT in binary is 10000100001 but we also know that this is not the ISBN to the book that we are looking to check out.  We know this because LostboY told us so when we did try to check it out.  After thinking on the whole thing long and hard I noticed a statement in the letter.  In not so many words it said to that we had the answer but we needed to add everything together to get it.  So, on a whim I decided on the following equation: 0×2 + 0×1 + 0xA + 0xD + 0xD + 0xD + 0xE + 0xC + 0×1 + 0×0 + 0×2 + 0×4.  This equals 0×55 which is 1010101 in binary.  Yes, that is a binary palindrome.  It was the ISBN for the book that we needed. And after all of that work, one full day of DefCon, several gray hairs, and some choice cuss words at LostboY’s expense, we had what we needed to move onto the next phase of the competition.

The rest of the MBC will very hard to explain and so I probably will not even try.  Needless to say, LostboY sent us on even more wild goose chases that boggled our minds for another 30 hours.  Most of the answers were right under our noses and the winning teams obviously were able to sift through the mis-directions faster than the other teams.  My hat goes off to them.

Go forth and do good things,

Don C. Weber

Well, I think it is pretty well known now that l@stplace is now being affectionately referred to as 3@stplace after this year’s DefCon Capture The Flag (CTF) competition.  I will not have a detailed write-up like I did last year as most of my time was spent banging my head on LosT’s challenges.  If you want to know more about what happened you should check out @tlas’ recap, swing over to the Daily Dave Archives for input from several team members, or check out the write-up at NOSRUS.  These sources say it better than I ever could.

Some interesting CTF stuff that did happen to me, however, is that I got to speak with Invisigoth again, @tlas for the first time in person, and I actually met Mezzendo on the shuttle ride to the Riv.  Getting to speak with these guys is like somebody from the deep South having a conversation with a NASCAR driver or WWE wrestler.  I try not to get all geeked out by other people because, after all, they are just other people.  But it was great to get to interact with them in person rather than virtually.  They were all very personable and seem glad to talk to me.  Unfortunately, although DefCon is a great place to met these guys, their extra time is definitely limited.  Maybe next year I’ll get into a few of the parties and have a better chance to interact with them.

So, congratulations to Sk3wl0fr00t for their domination of so many outstanding teams.  Of course, from reading @tlas’ recap it looks like they have lit the fire under l@stplace and I’m willing to bet that we have not heard the l@st of them.  I do think, however, that this just means that the competetion is going to become stiffer each year that passes.  This will also put pressure on Kenshoto to keep coming up with outstanding and ground-breaking scenarios for these competitions.

One thing that did catch my eye while I was walking around DefCon was a flier for a $100,000 CTF in South Korea.  For some reason I cannot find the flier now but I guess it is similar to the April competition that was written up on The Dark Visitor back in March.  I have a feeling that we are going to see this turn into big competitions like we have seen with console gaming.  Imagine a circuit where you just do CTF for a living.  It seems like a good way to quickly base and build up your skills.  And, when all is said and done, back to the corporate world for damn fine consulting fees.  Well, we can all dream, right?!!!!

Go forth and do good things,

Don C. Weber

Another DefCon has been completed and, as I suspected, it lived up to its expectation.  I was able to catch up with a bunch of my blogging friends, meet a few new ones, and even have lunch with a few old co-workers.  As usual, the majority of my experience was dominated by The Mystery Box Challenge (MBC) in which I and my team got completely p0wn3d by LosTBoy, which was completely expected.

The weekend started out with ominous undertones as my primary computer (which I was not about to bring to DefCon) suddenly had boot errors.  Of course it didn’t turn out to be a problem such as a bad hard drive as I expected, it was merely GRUB trying to include a removable storage device and erroring out.  This “problem in plain sight” would prove to be the overall trend in the MBC.  I’ll go into the MBC in a following post as I want to provide a few tools to help people understand the solutions.

My first evening in Las Vegas started out like last year.  I met up with Jon Squire and we caught up with his past year and his turbo talk at this years Black Hat.  Although it did have some laptop issues apparently it went very well and was well received by those who attended.  He is doing some scary things with UPnP and vendors should start doing as he suggests by disabling UPnP by default and putting up a BIG RED WARNING label to try and keep them from enabling it.  This won’t help everything but at least it would be a start.

After a few beers with Jon I linked up with Chris Hoff, Alan Shimel (still down as of this typing), Mitchell Ashley, Jennifer Jabbusch, and a few others.  It was good to see Alan and Mitchell again.  I have always liked Alan because he is always helpful, generally happy, and very personable.  It was a same to see that he was subject of a “blog compromise” and I hope all goes well for him.  It was my first opportunity to meet Chris and Jennifer.  Chris and I have had a few conversations so it was good to hook up with him face-to-face.  I don’t think that Jennifer had heard of me before (I guess I have been in the weeds a little too much lately) but we had a good time getting introduced.  The first night ended with a long walk to the Microsoft party where I was promptly denied access since I did not have a pass.  This resulted in a long walk back to the Riv.  No big deal as it was already late in Texas where my body and mind thought we were.

The next three days were just a flurry of activity.  It started off with all of the DefCon Badges getting stuck in US customs.  Apparently they were being shipped disassembled and even when Kingpin got them out of quarantine they still had to be assembled.  After that the MBC started and I was basically consumed until the noon of the last day.  This meant that I couldn’t have dinner, lunch, and even drinks with many of my friends.  To all of you who tried to pull me away, thank you for trying, we’ll definitely get together some time this year.  I did, however, get a chance to met up with my friends Monty McDougal and Jesse.  We had a good time catching up and I even managed to wrangle an interview out of Monty.

That is pretty much the extent of my experience with DefCon.  I’ll have a better write up on MBC and my interview with Monty about his project Windows Forensic Toolchest™ (WFT) in the next few days.

Go forth and do good things,

Don C. Weber

Although I have never met atlas personally, I was originally made aware of him at RSA 2007 while speaking with Ed Skoudis. I was talking to Ed about my interest in the DefCon CTF and he mentioned that his company InGuardians was working with altas on several projects because, among other reasons, of his outstanding performances at DefCon. The next time I heard about atlas was during last year’s DefCon CTF 2007 when invisigoth mention how impressed he was with altas’ leadership qualities during the intense competition as he lead his team, l@stplace, to a second, consecutive, victory. All of this peeked my interested and I was very keen on getting an interview to augment my post on last years DefCon CTF, DefCon 15 CTF – WarGamez, but time quickly passed and I went ahead with the post without the interview as I was not aware at the time of altas‘ blog, atlas wandering. After the post I mentioned my disappointment to my good friend Lara and she said, “Oh, he’s a great guy. I’ll drop him a note tomorrow.” For those of you who know Lara, she always comes through.

Sure enough altas emailed me several days later. We quickly agreed to an interview but because of constant battles with SPAM filtering, multiple projects on both sides, and several conference presentations by atlas, we just did not get it completed until a few days ago. During one of the emails I asked atlas to mention some of the things that he was working on to help me write some pointed questions directed towards his interests. He mentioned a few:

I have been doing some fun stuff with 16-bit real mode, kernel module play in
Linux, BIOS hacking, and of course disassembly and programmatic debugging.

My first thought was “Uh, oh.” Sure, I have heard of all of this but if you followed my failings with writing exploits for a simple buffer overflow you know that I am not going to be able to dig very deeply into these topics. I did some quick research on the topics. Then I reviewed his latest posts on his toolkit, atlasutils and reviewed his presentation on Vulncatcher. I started to get a little frustrated. After all, I did not want to waste the excellent opportunity just because I do not have a grasp of the integrate details of complex software and hardware relationships. Ahhh, bingo. I hit the nail on the head. Looking over everything that I can find on altas I realized that he has one of those special eyes for detail. He can see the integrate relationships within complex systems and understand how to research them. Or, at least, he understands it enough to try and manipulate the relationship. Hacking at its finest, its very core. Excellent. I might not be able to delve deeply into his research, but I can at least find out his opinions on this complexity.

First, a little Bio on altas stolen from his ShmooCon 2008 introduction.

atlas is an average joe who spends his time learning new ways to make computer systems dance. When he’s not slicing and dicing windows and unix binaries, he’s writing tools to make vulnerability research simpler and more enjoyable. His hobbies include deadlisting (opcode disassembly), vulnerability research, and lately he’s been working on processor emulation and kernel-mode internals. atlas leads the capture-the-flag team, 1@stplace, who recently won back-to-back victories at defcon, which he blames on his teammates. “I surround myself with brilliant people,” he quips.

So, without further ado, atlas.

---

DefCon CTF

1. You have lead your team to two straight victories in the DefCon CTF.
Has this part of your life run its course or is it still challenging enough
to give it another run?

Wow… it’s still challenging! Each year we have been extremely challenged by
amazing talent. There is still immense question of how well we will place
this year, with the outstanding talent the Naval Postgrad School puts forth
each year, Vigna’s team has provided some serious domination in the past, we
have several international teams which are doing very well, and other talent
not yet “displayed” at defcon. We have to go in each year focused on doing
our best, regardless of who and what challenges we face. How many more years
I have left to give is another question. It’s a very consuming weekend, and
quals weekend, even though we don’t currently have to qualify, is challenging
as well.

2. Your team is obviously very skilled but the types of personalities I
imagine that are involved are use to individual performance and behavior.
Was it a challenge to lead them and keep them focused on goals that
benefitted the group as a whole? I.E. tracking down a problem that might
be too difficult for the competition or not worth the effort.

If I’ve done anything really well in CTF it is selecting amazing people. They
have always been an honor to lead, and have actually helped me lead them in
more ways than I can count.

3. Have you or your team members seen benefits develop from the amount of
time and effort you have placed in getting ready for DefCon CTF?

Oh totally. A few of my guys, myself included, have changed career paths
based largely on how well they’ve proven themselves at ctf. I can’t speak
for the others, but I’m quite happy with the results. I think we’ve all seen
improvements in our daily tasks and our abilities to achieve our goals.
We’ve built strong friendships within the team which has been very good.
Management also responds well to our wins, as they are more likely to think
we know what the heck we’re talking about.

4. Are you personally going to give it another run? Will l@stplace return
as the same team or will you select different members to keep the blood
fresh and challenge high?

We’ll return the same team we left. I’ve been fortunate to find such amazing
guys, hand-selected them based on their talent, skill and personality, and
formed lasting friendships that transcend defcon. I’m confident from our
talks offline that we will all be returning this year, Lord willing.

5. Do you believe that there are real world teams, criminal or govenment,
performing detailed and near real-time application analysis to penetrate
businesses and government systems, much in the same manner that the teams
in the last DefCon CTF were doing?

Certainly. Absolutely. No Comment.

Program Research and Exploit Writing

6. What was your background before you started really moving into program
and architecture research?

I had been a coder since I was young, but got a career in sys-admin work, then
moved into data-telecom where I was responsible for many security-related
services, then got drafted into security.

7. To me some of the concepts are difficult to grasp and implement when
there are resources. What did you do to help you get over the hump and
begin to fully understand the intricacies of low level programming and
analysis?

Gave up. Then I redoubled back. I was freaked out at the possibility I’d
fail. So I decided that I couldn’t do it. Once I had finished freaking out
I decided to work it and grow. Some people could and were doing this stuff,
what’s the cost of throwing myself into the learning curve and seeing where
it lead?

8. Your toolset, atlasutils, is a combination of python programs and
script that include a disassembler and other tools that help located and
provide information to exploit vulnerabilities. I have noticed that Dave
Aitel likes to talk about writing his own debuggers as well. Is this
because the tools that are out there are not useful, you have different
ideas that did not go into the usual debugger, or that you just need
something to help fit a specific niche? Or, it is just fun to write your
down debugger?

To quote a very good friend of mine, I write code because I’m lazy. Truth
is, using others’ tools is tiring, since I have to learn to think like
them… Writing my own forces to me to learn how to think about the things
I’m trying to do, then write tools that help me next time I have to do them.
I hope people find my tools useful, but they’re really for my benefit. I
often write my own tools because I’m forced to learn the details better…
and then I can add my own whizbang fun new stuff on from there. For
instance, I’m rewriting disass, because there was an upper-limit in binary
size, above which it simply took forever to process because of inefficient
use of memory. It was also very “dogmatic”, and not agile. Some code I want
to disassemble is packed/encrypted and wrapped with an unpacker/decryptor.
That means the data/code actually changes post-loading. Disassemblers have
to account for that, which means they have to be “agile”, or able to adjust
how they view the memory setup of a binary. I’m also working parts of the
remake of disass into an emulator (no, not complete emulation) which will
allow me to better address certain laborious tasks.

9. When you are developing these tools, how do you pick a program to
analyze? Do you generate your own vulnerable code or find something with
known vulnerabilities to analyze?

When developing tools I try to use them on anything I want to analyze, just to
see them break (and wow they break). Sometimes it’s code I’ve snagged from
ctf, sometimes it’s my own code, sometimes it’s POSIX code or Win32 code, or
<insert-your-fav-commercial-app> code.

10. As I look at the types of research you are performing I start to
wonder if computers are just too complex. Or if the higher level
programming languages that we have just cannot securely support all of the
low level functionality. Then I start thinking about the interactions and
complexity added by software and hardware interaction, BIOS, and firmware
and my head really starts to spin. What are your thoughts on this
complexity and how it is affecting the security of technology as a whole?

Well, you’ve really nailed it. Computers have become very complex indeed…
and continue to do so. In many layers of “synthesis” the computer industry
has striven to group low-level functions into simple-to-use functionality;
for the developers and ultimately the end users.
Each iteration of simplification masks many details from the users/developers,
and with the disappearance of those details comes many assumptions.
Assumptions are inevitable in our industry because you can’t teach *every*
administrator and developer *every* detail about the computer. Some in the
security field have attained a great deal of understanding those details…
and we tend to hail them as deities.
False assumptions and the state of mind induced by details-overload work
together to provide vulnerabilities for attackers to leverage. Sometimes
those vulnerabilities highlight a loss of communication, laziness, lack of
understanding, or simply mistakes.

This dilemma is not going away. We continue to see layered-development and a
push for ease-of-use at every level. Ease-of-use tends to be directly
counter to security, in that we enable users and developers to do mighty
things without realizing the truth of what they are doing. For example,
without proper education and focus on security, thousands of SQL-Servers were
put on the Internet with a blank SA password (the default).

Security must become a baked-in part of the development culture. Developers
need to be screened for how seriously they take security, and continually
trained and updated on new security problems, such as format-string bugs and
buffer overflows in the 90s. When the next new common programming flaw is
identified, those mistakes must be put in front of developers to warn them
and instruct what the computer is actually doing, or how attackers are
leveraging the flaws to do evil things. Each development team needs to have
someone who understands how to think like an evil d00d. I venture to say
that every developer should become that person.

This complexity provides plenty of playground for attackers, but hackers are
rising to the occasion, finding enjoyment in understanding systems better
sometimes than their creators. We insert stop-gap protections like ASLR and
anti-corruption techniques and hackers find ways around them. Worse than the
time lost in the creation and adoption of those protections is the
complacency they allow developers, who wrongfully think they are protected.
With all the complexity of just learning someone else’s API and interacting
with third-party products, as well as designing corporate-wide API’s that
hundreds of developers may use, they are happy to think on the good sides to
such protections, without being able to understand the details or
limitations. Even if they have the base-knowledge to understand, they simply
are seldom given the time.

11. With this complexity, how can developers fix it? I mean, programmers
just do not have the time and resources to think of every little piece of
the puzzle. We cannot expect them to. So, how do developers protect their
projects? Do we just need to realize that we are in a constant state of
possible exploitation and accept that very expensive systems will get
exploited and we better have a good incident response team?

See above… Good incident handling teams are invaluable for an organization.
Teams who understand proactive security and the patching process are equally
important. Consider them “stoppers” and “sweepers” if you like futbol.

In the end, the ball is the developer’s court. Each person who writes code
needs to learn the details of what they are doing, and accept responsibility
for the security of their work. If format-string bugs seem impossible to
exploit, that developer needs training (SANS SEC504 is generally very good
for that). If XSS doesn’t seem to be a big deal, training is necessary.
Aside from great training, that SANS course will likely provide networking
opportunities with people who think evil all day every day. BlackHat and
defcon are also good venues, but likely less substantive. We need to stop
training our developers only about how to enable things… because that only
enables exploits.

12. Along the lines of complexity, most of the technologies that are put
out there, operating systems and applications, automatically have these
complexities built into them as features. The Center of Internet Security
has long benchmarks to help guide administrators through steps that help
them limit their exposure to some of these complexities, but with each new
release of a product the administrator has to be worried about what is new
or what was modified that exposes the environment to additional risk. What
recommendations can you make to these administrators as they are taking
these complexities into consideration?

Good luck? The truth is that CIS spits out some outstanding documents to help
us get a certain level of security with the least outlay of effort. It’s a
bang-for-your-buck arrangement. Unfortunately no benchmark or security guide
is going to take the place of a solid understanding of the technologies one
is using. Best case, CIS guides serve as a litmus test and a guide to
someone who already has a great understanding and the curiosity to know their
playground well. Someone who knows enough to know how much they don’t know
so they welcome the help, but someone who plays with their tech and groks
it… because they want to. This is the part where I get to piss a lot of
people off… if you don’t love security or IT or IS… get out. There are
many professions where you may be happier and more successful. Computers
have become the next “Doctor” or “Lawyer” profession, where people flood
Computer college programs in hopes of a mighty paycheck. Those people
everyone views as gods in this industry are people who would tinker anyway,
even if they were janitors during the day. And if you *do* tinker and wind
up in the industry… get yourself some security understanding. Learn to
think as your opponent… think about how someone who hates your guts and
your programs would mess with them. Get the training, from an organization
or a friend if you cannot afford formalized training.
And remember, patching is a vital, ongoing process organization-wide.

@

---

Of course you have to love any question that ends in “No Comment.” The Mission Impossible music always seems to kick in at those moments.
I hope all of you enjoyed this as much I as did. Thank you to altas for being so patient and generous with his time.
Of course, thank you to Lara who always pulls through for me and my family.

Go forth and do good things,
Don C. Weber

atlas, exploits, vulnerabilities, defcon, ctf, atlasutils, vulncatcher, InGuardians, skoudis, Security Ripcord, atlas wandering, l@astplace

One of the best parts of wandering around DefCon was periodically sliding through the Capture the Flag room. As I stated in my original Defcon 15 post, Invisigoth of Kenshoto was kind enough to field a few questions and shed a little light on what was happening.

When I first walked into the room it was a bustle of activity. Teams were setting up their systems and their networks. Their equipment hosted a wide variety of computer systems. As I looked around at the different systems the teams were running I could see Windows, Linux, OS X (and possibly BSD but I couldn’t be certain) running on all different types of hardware: Dell, Apple, Alienware, IBM (Levono), HP, Sony, and more. It was already late in the morning so I had wandered in right at the end of their allotted setup time. Invisigoth made an announcement that the teams would be limited to eight team members working at one time and then, a few minutes later, announced the commencement.

Although the scoreboard was running at this point there had not been a lot of noise in the room up until the beginning. With the announcement of the start of the contest I was looking up at a projection of the scoreboard on one of the walls of the room. It showed each team, the number of overwrites, steals, and breakthroughs, and the level of service operation. This screen also flashed through several other statistic screens that compared the teams according to each category. A scrolling text area across the bottom of the screen also provided update information, in this case, the beginning of the competition. What happened next, however, got me to laugh out loud. With the start of the competition the technomusic started and two additional video screens lighted up. Comics, music videos, and other very distracting videos began to entertain the crowd as it filtered through the room and added its own noise contributed via talking, laughing, and applause.

After the start of the competition I asked Invisigoth a little bit about the teams. He was very proud of the fact that approximately 160 teams participated in the pre-qualification round and from that field the eight teams that came out on top provided representation from around the world. Although I did not get a complete breakdown I do know that team “Song of Freedom” were from Korea and team “Osu, Tatakae, Sexy Pandas!” were from Spain. It was about this time, 20 to 25 minutes in, that “Osu, Tatakae, Sexy Panda!” drew first blood. They scored the first breakthrough and quickly followed it with several steals and overwrites. When this happened I looked over at the area where last years winners “l@stplace” were located to see their reaction. I don’t even think that any of them looked up at the score board. Looking around the room I was very impress to see that no more than one or two of the other team’s members were looking up at the board either. In a room full of noise and disruption these teams were hard at work attempting to crush the other teams while keeping their services up and running.

April Dudash of The Independent Florida Alligator described the team objectives in her article “the H@cker Elite: UF engineers compete in Vegas“.

Teams were awarded points for service level, steals, overwrites and breakthroughs, or being one of the first three teams to exploit a particular service. Penalties were given if teams tried anything inappropriate, like illegal-hacking moves or real-life physical violence.

Basically, Kenshoto gave each team a server with twenty services running on them. They used the information they had from these servers to compromise the servers owned by their opponents while at the same time protected the availability of their own services. Uptime played a critical role in the outcome of the game. To better understand the objective, however, here is some of the information provided in a competition flier distributed by Kenshoto.

STEAL – Breaking into a service and getting read access to a secret token. Submit your steal for a point.
OVERWRITE – Breaking in with write access and overwriting the target’s key with yours. Each overwrite will trigger a point.
BREAKTHRU – First team to expliot a new vuln gets mad bonus (auto-scored and scaled for difficulty). Later teams get points, but the value drops exponentially.
SLA – Percentage of time that your services have been up (we have a polling monkey that checks every few minutes). This scales your final score.
PENALTIES – Seriously? You’re reading the definition for ‘penalty’?!?! While you’re at it: there is no Santa Claus.

One of the times that I spoke with Invisigoth I asked him about the services. At first he just smiled at me. The sort of, “Well, kid, get a team and get to the finals and you’ll find out” kind of smile. Relenting only a little, he told me that there were three levels of services: Easy, Hard, and (of course) Kenshoto. The pinnacle process, meaning the one they deemed the most difficult, was named “Manshetwa.” As he described it to me I was quickly confused. So, if I completely botch this description I hope that they forgive me or, at least, correct me in the comments. Manshetwa was a binary program within a program. Actually it was three programs running inside of a parent program that acted like a custom virtual machine. (BTW, all of the services are custom for this contest.) The parent program monitored the three processes and also attached to each of them as a debugger so that no team could attached another debugger to any of the programs. The programs acted, in conjunction, as a service. One of the programs accepted input from the network on a specific port. After accepting the information this program decrypted the input and sent the information to the second program. The second program used this input to generate some custom assembly code which it passed to the third process. After accepting the assembly code the third process ran the code. A little fuzzy? It is to me as well. I don’t have any more answers than that because Invisigoth had other duties as required and to this point I had taken enough of his time. I can only assume that if the third program runs the correct code the team sending the information accomplished a Breakthru. Of course, this service was designed to be almost impossible to exploit. In fact, Invisigoth looked at this service as a time killer. Any team who assigned an individual to work on this service in order to benefit from the massive amounts of points associated with it were merely wasting man power. He mentioned how @tlas, the team leader for l@stplace, had specifically forbade his binary analysis expert from even looking at the service for this very reason.

In the end, out of eight teams from around the world, team l@stplace repeated their victory. The whole team was awarded another DefCon Black Badge and Leather Jacket. You can read what @tlas had to say about it in his post “Play it again, Sam.” He also links to several of his team member sites so you should check out their comments as well.

When it was all said and done I was very happy I spent a little extra time in the CTF area. Invisigoth was more than helpful basically because the competition ran fairly smoothly and because he appeared to be having a great time. I also enjoyed watching the professionalism and drive of all of the teams involved and it made me long for working with a team of elite and dedicated individuals again. I am hoping that I can get a few of the Security Catalyst Community interested in the CTF next year. After our success with the Mystery Box challenge I don’t think that will be very hard. The hardest part will be getting them to pick between the two.

Go forth and do good things,
Cutaway

DefCon15, @tlas, l@stplace, Kenshoto, CTF, WarGamez, Invisigoth, Security Ripcord

Plenty of people have already blogged on the DefCon 15 badge. Joe “Kingpin” Grand did an outstanding job so I thought I would give everybody a taste of each badge running around during the conference.

Lets go in a sort of unofficial rank order from lowest to highest.

1. Press Badge

2. Human Badge

3. Speaker Badge

3. Goon Badge with Ninja Party Invitation

4. Black Badge

Unfortunately I did not get a picture of Kingpin’s badge as I didn’t think about doing this until the last few minutes of the conference. Special thanks to James Costello for the Human badge, Arthur from Emergent Chaos for the Speaker badge, Grifter for the Goon badge with Ninja Party invite, and Priest for allowing me to photo the table full of Black badges. Yes, the Press badge is mine.

Go forth and do good things,
Cutaway

DefCon15, Kingpin, badge, Grifter, Priest, Arthur, Security Ripcord, Joe Grand

Now that I am back from my very first DefCon experience I have two questions. “Why did I miss the previous 15? What was I thinking?”

From the very start the whole trip seemed like it was on a slow and deadly spiral downhill. I got packing late and had to rush. I couldn’t get the Sprint EVDO card running under BackTrack 2.0 installed on a Dell D600. I suddenly had to do actual work while I was on the trip so I had to take my Mac Book Pro but couldn’t get the Verison EDVO card for it because it was locked away in a file cabinet (now that I know a bit about lock picking I could have gotten it). Then, when I finally got to Las Vegas I realized that I had never been here and I had no idea about how to get to the Riviera.

Once I got to the Riviera things started to pick up a bit. I met up with Mike Henry who graciously let me sleep in his room with he and Martin McKeay. We soon met up with Larry Pesce and Jon Squire and we all loaded into a cab for the Accuvant party at Mandalay Bay. This turned out to be a great move because of the open liquor and sushi bar. I also got a chance to met with several of the Accuvant attendees and they were all very knowledgeable and friendly. I can definitely see why Michael Farnum (who did not attend DefCon) likes his job so much. After the party it was back to the hotel for my last real nights sleep for the next couple of days.

In the morning it was on. I had already picked up my Press badge (Thank you very much, Nico!!) so I filtered into one of the sessions. Sean M. Bodmer, the Director of Federal and Military Programs at Savid Technologies, gave a talk on how it is important to extend your incident response plan to include “attack characterization” in order to understand why you are being attacked and by whom. After the presentation I asked him a few quick questions about how much extra time this would cost an incident response team, if he had a common framework the community could leverage, and if there was a central repository so that people could look for similar attack methodologies to help them identify attackers. He told me that once an organization had a framework in place it only takes about 6 to 8 extra hours to detail the attack methodologies and familiarize the rest of the team with the results. The framework that as been developed by Savid is not public as they have not been approached to make it available to anybody else. Same goes for the database of attackers. Although I like his idea I very much doubt that a small or even mid-sized business has the extra funds and manpower to devote to this extra work (I’m not saying it wouldn’t be helpful information, just that it will be hard to promote). Large business including the government, however, could definitely benefit from this type of information. Also, I am surprised that he did not offer a common framework to this approach. Obviously he and his team are very knowledgeable about how to profile attacks and attribute them to specific individuals. I would have like to have seen them take this next step especially since they were presenting this at DefCon.

After this first presentation I decided to wander around a bit. It only took me a few minutes to end up in the WarGamez Capture the Flag room where eight teams from around the world were diligently setting up their systems and preparing for the competition. A few minutes of looking around showed me that Kenshoto was running this event so I quickly cornered one of their members to get a quick introduction and ask him if he was open to answering questions periodically during the con. This person turn out to be “invisigoth” and he was more than happy to help while he was not assisting the competitors. There will be more about his competition in the near future.

By the time I finished up in the CTF room and wondering through the vendor area, it was time to start the Mystery Box Challenge. Volunteering to be a member on the Security Catalyst team was definitely the best move that I could have made. Firstly, the contest is an embodiment of everything that DefCon represents. Break in anyway that you can using any resource that is necessary. Secondly, I couldn’t have been a part of a better team. Although none of us were particularly strong in all aspects necessary to complete the challenge, each one of us brought a necessary skill level. Together we knew how to get it done or somebody who could help us do it. Although we did not win I am very proud of the fact that we kept the amount of outside influence to a bare minimum (basically, we need a lock picker). Although I could write up exactly how we did everything I would rather point you to James Costello post titled “Back from DefCon” which sums it up very nicely.

After 36 hours with 2 hours of sleep I was dead beat. I tried to wander around some of the parties but my body was not up to it. Everybody I talked to told me not to sleep at DefCon but I just couldn’t help myself.

After such a positive and involving experience of the Mystery Box the rest of DefCon was a bit uneventful. The TCP/IP Drinking Game and Hacker Jeopardy were fun (Winn Schwartau is hilarious BTW) but I didn’t get the same sense as trying break into something. As this was my first DefCon, however, I felt it was important to experience some of the things that make it DefCon.

The next day however, it was back to trying to learn new tips and tricks. I spent the day floating in and out of the Lockpick Village, the Wireless Village, the CTF competition area, and one or two talks. The only other talk that I was impressed by was the one given by Marc Weber Tobias and Matt Fiddler titled “High Insecurity: Locks, Lies, and Liability”. They had a very informative presentation that points out some of the inconsistencies of physical security. Oh, yeah, I just remembered Matt Richard and Fred Doyle also gave an interesting talk titled “Beyond Vulnerability Scanning – Extrusion and Exploitability Scanning”. Basically they have created a set of tools that can test an organization’s outbound countermeasures.

Wow, I just realized how long this post has turned out to be. I guess I can really sum up DefCon as a great opportunity to meet new people and participate in competitions that stretch your imagination and skill sets. What more could you as for beside “how do I do this year around”?

Will I return to DefCon next year? I have already started working on the very topic and hopefully my wife and I can negotiate a sufficient exchange of personal vacation time to get me out to DefCon 16.

One thing of interest that I did take way from DefCon was the emphasis to physical security. What I mean is that the Lockpick Village was completely pack from the moment it opened to the moment they closed down the area and asked everybody to leave. What does this mean to your organization? Well, if hackers are looking into this then maybe you should start considering what you are doing and where the weaknesses might manifest themselves within your environment. You might have the best OS hardening skills in the business. But if you cannot limit and protect the physical access to your systems and other resources then you are going to be in serious trouble.

Go forth and do good things,
Cutaway

DefCon15, Kenshoto, invisigoth, CTF, GenesysWave, Security Ripcord, Mystery Box Challenge, James Costello