ChargenChargenhttp://chargen.matasano.com/chargen/2010-03-03T21:31:19ZSquarespaceExercises for a burgeoning Army of Ninjashttp://chargen.matasano.com/chargen/2010/1/20/exercises-for-a-burgeoning-army-of-ninjas.htmlstephen2010-01-20T23:36:00Z2010-01-20T23:36:00ZAt SourceBoston 2009 fellow New Yorker Dan Guido did a talk entitled “So You Want to Train an Army of Ninjas”. Dan’s talk was on his experience organizing the CSAW competitions at NYU:Polytechnic. If you are unfamiliar with the annual awesomeness that the ISIS program at NYU:Poly puts together, you can read more about the whole event here. To quote someone on twitter “If all of school was like [the program at NYU:Poly] maybe I wouldn’t have dropped out.”

This is an excellent little video summary of the competition:

CSAW 2009 - The Judge’s Perspective from NYU-Poly on Vimeo.

The competition portion of the event is loosely modeled after the Defcon Capture the Flag competitions of recent years. This past year, the CSAW-CTF competition brought talent from all around the world together during the National Cyber Security Awareness Month which is celebrated at NYU:Poly as CSAW (Cyber Security Awareness Week) 

In 2008 when I was asked by Dan to help out I was very eager. That year, my involvement with CSAW-CTF was limited to just a few small challenges (instead I focused on teaching a Reverse Engineering class at NYU that year which Aaron Portnoy took over for this year). This year (2009) however, I went a little more “head down” and spent a bit more time designing, coding, and building reverse engineering challenges for the CSAW-CTF.  This blog post is about those challenges.

Times have changed, and these competitions have evolved and matured much like the rest of our “industry”.  They are no longer about who can whip out their graffiti’d laptops, mount their sticker laden Zip drives from linux, and use gcc to compile stuff from their packetstorm, rhino9, rootshell.org, or hack.co.za archives. Times have changed. The games are different now and don’t so much deserve to be the target of smug self-righteous vitriol from jaded old security folks.

This became really obvious to me in 2005 when Kenshoto premiered a new kind of Capture the Flag for Defcon that year. Players that year said that they could really tell that despite Kenshoto’s showmanship (and at times, ostentatiousness), all the members (mostly invisig0th, who is responsible for really spear-heading the whole effort) really loved what they did and wanted to share in the fun of software exploitation and reversing.  All the challenges were custom made and well documented. They required source auditing skill, custom shellcode payloads, and reverse engineering skill. During the qualifying rounds (a month or so before Defcon) there was also an interactive scoreboard, MUD and IRC channel for all the players and organizers to use. This drew players in to world of the game a bit more and allowed teams and organizers to “hang out” all in one place and keep up-to-date on scores and rankings. 

That year, and in the following years following, some big hitters came out to play: Mark Dowd and John McDonald (who ruxxed the quals round in 2005); Chris Eagle and the Naval Post-Graduate Warfare College; Giovanni Vigna and the UCSB team; the SAIC team, the Novell Team, some great international teams; and number of Fortune 500 technology companies (and government agencies) that wished to remain nameless ;-) Kenshoto and John Viega (a Kenshoto member) even got an article in Popular Science that year.

Having been a member of Kenshoto, I really wanted to bring a bit of that spirit to the NYU:Poly CSAW-CTF. The NYU-Poly competitions had a number of different competition categories which included Web Security, Application Security, Forensics, and  Embedded Systems. 

Myself, Dino Dai Zovi (who blogged briefly about his CSAW experience and even talked about it on the local news), and Dean DeBeer were all responsible for judging and organizing the “Application Security” parts of the competition. Dino Dai Zovi (an alumnus of Matasano and fellow New Yorker) designed all the Software Exploitation challenges and I designed all the Reverse Engineering challenges.

You can read about the full format of the competition online at the csaw website, but essentially the competition happened in two waves: (1) a qualifying round where anyone could participate, and (2) a final round where all the top teams that qualified and were enrolled at universities within the US would be flown to New York and put up in a fancy hotel to participate in the final round held on the NYU:Poly campuses.

The Scoring System:

First things first. How to keep track of scores? A stupid web app? The honor system? Email based submissions?Due to the sheer number of participants I decided that any kind of manual or qualitative scoring system would be a nightmare. Reverse engineering challenges seemed to lend themselves nicely  to “token” based scoring so I decided to go that route and to build an automated scoring system. The scoreboard was written in Python and ran as the default shell for an “open” user account to be shared amongst all participants. Competitors were dropped into the BBS-style scoreboard system when they ssh’d into the box.They would then authenticate to the scoreboard system itself (which maintained it’s own credentials).

The scoring system internally used a client/server model. The server ran at a higher privilege level than the client and communication between the two was all done using python RMI. This was intended to localize the damage if anyone had a clever way of breaking out of the python interpreter. If they were, it would be harder to directly access the scoring database files directly, because all those operations were performed by the server on behalf of the client who made requests via RMI. The scoring system allowed competitors to check scores, read about flags and challenges, and submit/check their answers.

Other than that there isn’t anything really noteworthy about the scoring system. Source code for that is all available online here. Now let’s get on to the Reversing challenges.

For the qualifying round of the competition I put together 8 challenges. The 9th and final challenge would be completely different than all the others and was saved for the Final Round which took place on the NYU:Poly campuses. Each of the 8 challenges were framed as forensics based malware challenges, each having its own fictional “backstory”. Every challenge was distributed in binary form and it was up to the competitor to extract tokens from the binary by reversing or otherwise modifying execution of the executable. Each binary employed what I hoped to be progressively more difficult anti-debugging and anti-reversing techniques and combinations thereof. Let’s individually review each technique before summarizing how they were combined to form each challenge.

The Tricks and Techniques:

Premature Exit:

Before a critical call is made a call to ExitProcess is made. Thus normal execution of the binary will seem to just cause the program to run and exit. Debugging the process however will reveal that more code exists after the call to ExitProcess.

BeingDebugged (custom):

Traditionally this technique involves having the process make a call to IsDebuggerPresent() to see if it is being debugged.  This is the standard way to do this using the Microsoft APIs. However many anti-anti-debugging patches for debuggers such as OllyDBG have modules that will intercept this call by setting a breakpoint on it down in kernel32.dll. So instead of using the Microsoft API I wrote some inline assembly that pulled this boolean value directly out of PEB. This way, the only way to catch that “Being Debugged” was being checked was to set a Break-on-Access in PEB itself, something I don’t think any of the common debugger plugins do. My hope was that this would make the process a bit more manual for the competitors.

String Obfuscation:

  Many strings that get statically compiled into binaries sit in the BSS section of the executable. You can use canned tools like unix “strings”, IDA, or even simple shell scripts to pull this stuff out. Even simple string obfuscation like XOR is easily spottable in disassembly. So what I wanted to do was to write a string obfuscater that would “raise the bar” high enough that reversing the scheme itself would be more difficult than doing the challenge itself, so I settled on some simple encryption.  To achieve this I was originally going to use RC4 and execute it as a shellcode buffer, so I wrote RC4 in NASM. 

 The reason I chose to do this as shellcode originally is because I thought it would be easier to polymorph the algorithm as shellcode than it was to polymorph it as compiled C code. I eventually found out a way to achieve this with C code (as you will read below) and abandoned the shellcode idea. Instead I wrote (*ahem* stole) an RC4 implementation written in C that I vainly called sa7ori-encode. I generously borrowed from the infamous cipherpunks mailinglist ARC4 leak to write this code. With the crypto scheme implemented, the challenge then became how to make the algorithm look “different each time”. For this I used a combination of Inlining, Call Obfuscation, “Polymorphic” C Code Blobs, and “Here Strings” (all described a bit more below).

Inlining:

  Inlining (for those of you who are un-familar) is a way for a C developer to specify (using the compiler directive __forceinline) that when a function is called that execution is not redirected into it using the traditional “call” instruction. Instead, with inlining wherever a function would normally have been called, the full body of code for that function is “pasted” into the place where it is referenced. This is extremely inefficient because it makes binaries MUCH larger but for that reason it also makes reversing a bit more painful.

Timing Tricks:

   I had always heard about these timing tricks but the most interesting use of them was in Kostya Kortchinsky and Fabrice Desclaux’s EXCELLENT presentation entitled Vanilla Skype where they discussed some of the anti-debugging tricks they encountered while completely reverse engineering Skype. (This, by the way, among my favorite presentations of all time.) The idea is simple, x86 CPUs since the Pentium support an instruction called RDTSC which reads a time value from a timer that started inside the CPU when it was powered on. This can be used as a “stopwatch” to measure the time delta between bits of code.

This is particularly useful if you want to detect if there is a debugger attached. By starting the proverbial “stopwatch”, then throwing an exception that only a debugger can handle, and then checking the “stopwatch” after the exception is handled, a program can essentially time how long the debugger (and thusly the human operating the debugger) took to handle the exception. By setting the threshold for this time impossibly low for a human to react to you can effectively detect if there is a “man in the loop”.  The RDTSC instruction is wrapped by the Microsoft API function “GetTickCount()”.

Self-Caught Exceptions (to cause code branching):

This technique involves using registered exception handlers to redirect execution in your application. Instead of just calling a function by name, you register the function you wish to call as an exception handler, and then trigger an exception. If a debugger is attached, it catches the exception before the exception handler (which is actually a function critical to the normal operation of the program) executes and thus the program does not continue properly when the debugger has handled the exception and resumed execution.

Debugger Required Exceptions:

  This simple technique caused an exception (division by zero, “call 0”, etc.) that required the reverser to have his debugger attached so he could jump over or NOP out the exception. This is effectively like the premature exit. In the VM supplied to the competitors (which had remote Kernel debugging enabled) this had the unintended consequence of freezing the entire VM if they didn’t have a debugger attached ;-).

Call Obfuscation (AntiDisassembly, kinda):

  To obscure the area around a function call  I decided to use a combination of inline assembly and a property of C include files. C include files (.h) files essentially just “paste” in the code from the .h wherever it is referenced in the C code. In this case I put inline assembly in the .h.

The inline assembly uses the _emit macro to build a large blob of seemingly random bytes that could not be disassembled properly. Using the __COUNTER__ Visual Studio Macro. Stephen Lawler gave me the idea for this trick, unfortunately it can only be used once per function. You can see an example of how I implemented it here. This code was further modified to make it “polymorphic” which is discussed below. 

Polymorphic C code (kinda….well, ok not really :-):

 My CS vernacular stinks, so I couldn’t really think of a way to describe what I was doing here. To replace my idea to use polymorphic shellcode as the string obfuscater I instead found (what I think to be) a neat way to do this in C. The main use for this was to make the blob generated by the “Call Obfuscation” trick (see above) pseudo-random and thus a little more difficult to “eyeball” in disassembly.  Visual Studio has a very useful feature that allows you to create  variables at compile-time with the /D compile option for cl.exe. This will create a variable with a value specified (at compile time) that is then accessible from within code. For example, take the line of C code: 

#define MYCTR (__COUNTER_ _ + MYOFFSET)

The variable MYOFFSET is not defined anywhere within the source code. Instead it is actually defined at compile time with this:

cl /nologo /Ob2 /Z7 /DMYOFFSET=251 6.cpp /c

I then modified the “Call Obfuscation” code (from the previous section) to use this trick. This made the anti-disassembling blob “polymorphic” between compiles as long as the seed value for “MYOFFSET” was modified accordingly. 

 Annotated visual of polymorphs between compiles

In the end it came out something like this which could be used in the code like so: #include “evil.h” to screw up disassembly of the compiled code. An annotated visual screenshot of this process is here.

TLS Execution:

I learned about this Thread Local Storage (TLS) execution trick some years ago in one of Ilfak’s blogposts. It is a way (on Windows) to have a piece of your code execute before the main part of your executable (the entry point) is jumped into. The impact of this is that the code will even execute before a debugger can attach to it even if it starts the target program! Combined with anti-debugging tricks this can be really useful. It requires using an awesome custom linker though.

Use of “Here Strings”:

  My name for these probably sucks, but once again language fails me and I don’t know the correct term for this (if they even have one). In languages like Ruby or Python they are called “here strings” or “doc strings”. However, in languages like C even static strings get squirreled away in the BSS and then a pointer to them is used in the code. What I wanted was a way to reference a string buffer DIRECTLY where it was or as a really small relative offset. The reason I wanted this was to change the way the call into the string obfuscation functions looked, and to confuse disassembly. To achieve this I used a combination of inline assembly and _emit bytes. I wrote a small python script to take a string as input.It would generate a random key for my encryption scheme and then generate the ciphertext (based on the plaintext input and the generated key).

It would then generate a bit of inline assembly that represented the string as inline asm _emit bytes that exposed pointers to these buffers in the ebx and eax registers respectively. I could then just cut and paste the output of this Python script into my C code and use the “strings” by referencing pointer variables that referenced labels in the inline assembly. Instead of defining my ciphertext and key buffers like this (as I would normally in C):

I could access them as inline assembly “here strings” like this:

If you dont get what I mean, sample output of this Python script is here.

The Challenges:

Now that you have an understanding of the collection of anti-debugging and anti-reversing tricks I was pulling from, let’s take a look at how I combined and mixed them together to create different reversing challenges. The challenges themselves I thought were pretty neat.

Challenge #1: “JumpIt”

The backstory for for this challenge you can read here. (In fact, each challenge name in this post will link directly to the backstory if you want to read them.) The first of these challenges was intended to be fairly simple. The “key” for the challenge was just a static string that was popped up in a User32 MessageBox(). The trick was that the reverser had to jump over a call to ExitProcess to get the popup. Simple stuff. A guy named LordParody made a video tutorial of it even.

Tricks Employed: Premature Exit

Challenge #2: “BeingDebugged”

This executable checks to see if it is being debugged before and after it causes itself to crash. If the reverser subverts it, the flag is displayed to them.

Tricks Employed: String Obfuscation, Being Debugged (custom), Debugger Required Exceptions, Inlining

Challenge #3: “Hey I know you!”

When it starts, this executable checks to see if a process of a specific name is running, if it isn’t it exits. The reverser must find the name and start a process of this name to be displayed the key. One think you might find interesting about this one is that I did not use EnumProcesses() instead I parse structures directly from ZwQuerySystemInformation. I borrowed this from TheMina. This was a good exercise.

Tricks Employed: String Obfuscation, Here Strings

Challenge #4: “Hey I know you too!”

This is the same as Challenge #3 except with some more tricks thrown in and different keys.

Tricks Employed: String Obfuscation, Inlining, Being Debugged (custom), Here Strings, Polymorphic C Code, Call Obfuscation

Challenge #5: “Are You My Mama?”

This is a DLL that exports several functions. These exports are irrelevant because the DLL (upon being loaded) checks to see if the process loading it matches a name it expects, if not, it kills the process entirely. Reversers must satisfy or subvert this check to get the flag.

Tricks Employed: String Obfuscation, Here Strings, Inlining, Polymorphic C Code, Call Obfuscation

Challenge #6: “Timing Matters”

This executable checks if it is being debugged before and after it rides a sled of software breakpoints. The reverser must satisfy or subvert these checks to get the flag.

Tricks Employed: String Obfuscation, Being Debugged (custom), Timing Tricks, Here Strings, Inlining, Polymorphic C Code, Call Obfuscation

Challenge #7: “Spin Lock”

A DLL contains 5 exported functions (each called “tumblers”). Each function takes a character buffer as input and outputs an obfuscated version of the same buffer.

Exported DLL functions

These “tumblers” must be strung together to decrypt the contents of a packet capture file (which contain the flag). Additionally (like Challenge #5) this DLL will not be loaded by just any executable, it needs to be loaded by an executable of a specific name!

Tricks Employed: Inlining, Polymorphic C Code, Call Obfuscation, challenge specific string obfuscation

Challenge #8: “You have bad BHO!”

This was a Browser Helper Object. For those unfamiliar with these, it is another term for “Internet Explorer Plugin“.This particular one was intended to simulate the basic functionality of a banking trojan, watching which sites you surfed to.

The Browser Helper Object is watching…

To unlock the flag you needed to reverse it to find out which site it wanted you to surf to!

Tricks Employed: String Obfuscation, challenge specific string obfuscation

The Final Challenge: “The Fin”

loading the driverThis final challenge (unbeknownst to the competitors until the day of the competition) was a Windows Kernel Driver. The kernel driver (installed on XP SP2 machine) needed to be reversed to locate the IOCTLs it was listening for. Even a few of the IOCTLs it was listening for resulted in some taunting messages (like custom blue screens of death). Since this challenge as given on-site at NYU:Poly it was evaluated qualitatively.

Solution.

 

Some kernel reversing materials were provided that demonstrated all the techniques needed. Additionally, during the course of the challenges incremental hints were given.

Tricks Employed: String Obfuscation, Here Strings, Call Obfuscation, Inlining, Polymorphic C Code

 

The Outcome:

Many of the teams solved many of the first 8 qualifying challenges. Unfortunately, no one was able to solve the Final Challenge entirely. The listing of all the final rankings are here. A number of teams were able to obtain some points for explaining their process and providing some cursory information they obtained while reversing. Alex Radocea (of RPI) eventually solved it a month or so later and messaged me online ;-).

The competition was closed out with a big awards ceremony. (If you chose to watch the video below, the “Application Security” awards begin at 15:25).

CSAW 2009 - Awards Ceremony from NYU-Poly on Vimeo.

There are also photo galleries of the awards ceremony here.

We at Matasano are particularly proud of the team RPISEC (http://rpisec.net/) who ranked 2nd place behind the Carnegie Mellon Team. The RPISEC team had (Alexandru Radocea, Ryan Govostes, and Adam Comella) who are all Matasano interns. (Inquire about the Matasano internship program by emailing careers@matasano.com)

Conclusions:

In conclusion, the whole experience of building these challenge for CSAW was a good one. In hindsight, I wish I had done a better job on making the difficulty progression a bit more even. In other words, I  don’t think I mixed and matched the different “Tips and Techniques” (summarized earlier) well enough to achieve an good gradient of difficulty.  For example, I spent so much time on writing the string obfuscator/encryptor but I forgot to use it in one or two places that could have really benefitted from it, such as the executable names in Challenge #3. Likewise, I spent a lot of time building the “polymorphic call obfuscator” and did not use it in some of the earlier challenges like Challenge #2. Another huge oversight on my behalf was not obscuring the call to MessageBoxA well. I could’ve used my call obfuscator or made an indirect call, but I simply forgot to add this. A few people recognized this pattern and just jumped to the MessageBoxA call. :-( I guess these are all things you can only learn in retrospect.

Nonetheless, a lesson well learned, all of which I can take into my experience for CSAW-CTF 2010.  Feel free to try your hand at any of these challenges. The binaries are posted in github. Everything you need is in there along with the source (which the contestants obviously didn’t have so ignore it if you are doing the challenges ;-). Just download onto a Windows XP SP2 machine. Drop me a line to let me know what you think, or if you needs help. Thanks for reading.

 

 

]]>Protecting the Laptop Herdhttp://chargen.matasano.com/chargen/2009/12/21/protecting-the-laptop-herd.htmlCraig Brozefsky2009-12-21T21:26:19Z2009-12-21T21:26:19ZGreetings from the Playbook Development team, deep in the Ruby Mines of Matasano. I’m Craig Brozefsky, lead developer, and senior curmudgeon. Back when OSX was still called NeXTStep, but after the fall of suck.com, I was an ObjC hacker. I have fond memories of the time, despite the daily SpaXewars beatings at the hands of my co-developer, Jesse. So, when Tom informed the team we would be adding support for OSX Host Firewalls and needed to whip up a native OSX application, I saw my chance to pretend I was 10 years younger.

Playbook as Border Collie

Back then, developers used workstations — I had a Sun E1 and a NeXTCube. They heated your office, irradiated your head with giant CRT tubes, and had keyboards so big you could take naps under them!

Now it is customary to issue employees a laptop so they can work from bed. This is a great advance. They are small, make your thighs sweaty, ruin your eyesight, and torque your wrists — in bed. A single modern laptop can run the half-dozen virtual machines needed for modern web development using portable standards like CSS and HTML.

This proliferation of machines which move in and out of the office present a challenge to the company’s Hall Monitors, or network security ops as they like to call themselves. If Bob uses the company laptop at home, in bed, then we can’t enforce company web surfing policy at all times. That machine could have anything on it when it plugs back into the office network!

Luckily, the laptop has its own firewall built in, we just need a way for the Hall Monitors to manage the rules. Provided such a mechanism, they could key protect laptops with blacklists of drive-by malware sites, limit incoming connections to known services, limit outgoing connections to specific services. Then the next time Bob is getting cream cheese and sesame seeds all over the keyboard while checking email at the cafe, his host firewall is blocking the SMB attack launched by the unemployed financial analyst turned greasy-haired hacker in the corner. This is the stuff Hall Monitor dreams are made of.

Chaos Breeds Requirements Docs

An employee’s laptop is somewhat sacred, so we didn’t want to have creds for each laptop in some central database. Eric threatened mutiny at such a prospect anyways, perhaps out of fear we would use the creds to scan his laptop and find the pirated set of Little House novels in his ~/.snekrit directory.

Since I only arrive in the office on time on prime Julian dates or when Tom is buying dinner, we could not realiably schedule a push from our dogfood Playbook instance to each laptop. Inspired by NCSA Mosaic and the awesome power of HTTP technology, We opted to write a client that would run under each user’s account and pull rules down from a Playbook server.

As Cory mentioned, Matasano has been an Apple shop since 1925, so it was natural that we added support for OSX’s ipfw first. We could torture our own employees with the early releases, all under the guise of protecting them.

Keep Talking

We worked up a list of requirements for the client and server communications.

  1. Client and Server must be authenticated
  2. Comms must be encrypted
  3. Laptops should not require a Playbook login
  4. Enrolling a new laptop should be easy
  5. Revoking a laptop should be easy

We wanted the authentication to be automated, not dependent upon user password choice, and verifiable in both directions. The obvious solution here is SSL with certificate-based authentication on both sides. Since Playbook is accessed via an Apache instance, using Phusion Passenger, we can rely on Apache to verify the client certificate.

To manage the client certificates we built our own CA based on the QuickCert Gem. We create a key and certificate for each client.

We need to tell Apache to require a valid client certificate for requests to the pull controller, and to only accept one signed by our Playbook CA. Also, in order to allow us to manage Client Certificates without dealing with revocations, we pass along the certificate in the request headers.

<Location /pull>
  SSLVerifyClient require
  SSLOptions +StrictRequire +StdEnvVars +ExportCertData
  RequestHeader set X-Client-Cert %{SSL_CLIENT_CERT}e
  SSLVerifyDepth  1
</Location>

We don’t want to require a valid client certificate when the laptop is enrolling, aka downloading, the native client.

<Location /pull/enroll>
  SSLVerifyClient none
</Location>

Lastly, we tell Apache were the CA Certificate for our client pull subsystem is located.

<IfDefine production>
  SSLCACertificateFile "../../data/client_pull_ca_production/cacert.pem"
</IfDefine>

Our controller needs to make sure the client certificate supplied to us is the same one we have on file for the host in question. The HTTP_X_CLIENT_CERT entry in the envrionment table contains the certificate, so we normalize it and generate an SHA1 checksum. That is compared with a normalized SHA1 checksum of our certificate on file.

Here is the relevant method:

def check_cert(fw)
  cert = request.cgi.env_table['HTTP_X_CLIENT_CERT']
  if cert.blank?
    raise "No client certificate provided"
  end
  if fw.client_pull_certificate.blank?
    raise "Firewall does not have a client pull certificate"
  end

  cc = cert.gsub(/\s/,"")
  fc = fw.client_pull_certificate.gsub(/\s/,"")

  if SHA1::sha1(cc).to_s != SHA1::sha1(fc).to_s
    raise "Client pull certificate does not match."
  end
end

Ragel Rock

Before I came to Matasano, I was a Java hacker at the Center for Connected Learning an Computer-Based Modeling, where my job was working on NetLogo. This involved work on lexers, parsers, interpreters, compilers, and other aspects of programming language design. I liked that alot. In Playbook, we’re interested in the lexing and parsing, and some analysis of a range of firewall languages.

Writing lexers and parsers is, well, boring and rewarding at the same time. It’s a tedious cataloging of the “parts of speech” and grammar rules of a language. If you have good documentation for your target language, it is mind-numbing. With poor or no documentation it is maddening. Pray to whatever gods or old ones you believe in that the language is regular and not just “defined by implementation”. Despite this, it is rewarding when done, because you have a really useful tool for analyzing the target language.

This is precisely the kind of task where a good tool for building your lexers and parsers can save you thousands of dollars in time and prescription sedatives.

Adding IPFW rules support to Playbook took an afternoon thank to Ragel and our own lexer toolkit built on top of it, Ralex. Ragel lets you define reusable finite state-machines — it’s like regular expressions turned inside out with hooks all over. Or, as the projct site says:

Ragel compiles executable finite state machines from regular languages. Ragel targets C, C++, Objective-C, D, Java and Ruby. Ragel state machines can not only recognize byte sequences as regular expression machines do, but can also execute code at arbitrary points in the recognition of a regular language. Code embedding is done using inline operators that do not disrupt the regular language syntax.

Ralex is our own class which includes a set of Ragel state-machines that match tokens common to firewall rule languages, and then some book-keeping code that takes a string and a set of keywords, and gives you a token stream usable as RACC input.

When we want to write a rule tagger and parser for a new rule language, we start with the base Ralex clss:

class RalexIpfw < Ralex

%%{ 

 machine ralex_ipfw;
 include ralex_base "ralex_base.rl";

Next then we define any new lexemes needed for this specific rule language. Usualy this is limited to idiosyncratic representations of percentages/bandwidth limits or port/IP ranges. 

hexnumber = '0x' @collect_token hexdigit+
  @collect_token
  >{ start_token(:HEXNUMBER) }
;   

probability = '.' >collect_token digit+
   @collect_token
  >{ start_token(:NUMBER) }
;


ipwithmask = ipaddr ":" @collect_token ipaddr
  %{ start_token(:IPWITHMASK)}
;

macwithmask = macaddr "/" @collect_token digit+ @collect_token
  >{ start_token(:MACWITHMASK)}
;

portset = ( alnum | '\-' | digit )+ '-' @collect_token ( alnum | '\-' | digit )+
  @collect_token    
  >{ start_token(:PORTSET) }
;

slashcomment = '/' '/' >collect_token >getcomment ;


bandwidth = digit+ @collect_token ('K' | 'M') @collect_token ('bit' | 'Byte') @collect_token '/s' @collect_token    
  >{ start_token(:BANDWIDTH) }
;

Lastly we identify which state-machines we want to use when parsing a rule:

token = ( id
         | ipaddr
         | ipnet
         | ipwithmask
     | macaddr
         | macwithmask
         | portset
         | bandwidth
         | hexnumber
         | number
         | percentage
         | bytecount
         | ralex_specials
         | slashcomment
         | hashcomment
         | probability
         | quote ) %{ finish_token; };

After we have our Ralex class for the new firewall language, we then build two RACC parsers on top of that. One tags significant rule elements, like addresses and ports, which drives our rule indexing engine. The second one does full rule parsing and performs syntax checks and generates a ASTish representation of rules for use in or analysis tools.

Since we have a bunch of these written for other rule languages already, it’s pretty easy to put a new one together. The most time consuming, mind-numbing bit is encoding all the keywords in the rule languages, which we currently have to triple code cause I’ve been to lazy to refactor.

This whole process is driven by a bunch of test macros we have for taking examples rules and deriving tests for the tokenizer, tagger, and parser classes.

it "should handle ip address representations" do

    token_test("from 192.2.2.2 to any",
               [[:FROM, "from"], [:IPADDR, "192.2.2.2"],
                [:TO, "to"], [:ANY, "any"]])
    # masklen
    token_test("from 192.168.1.0/25 to me",
               [[:FROM, "from"], [:IPADDR, "192.168.1.0/25"],
                [:TO, "to"], [:ME, "me"]])

....

it "should tag addresses and ports " do
    parse_test("add deny ip from 123.45.67.0/24 to my.host.org",
               ["add", "deny", "ip", "from", IPAddr.new("123.45.67.0/255.255.255.0"),
                "to", Hostname.new("my.host.org")])

    parse_test("add deny ip from 123.45.67.0/24 to my.host.org 80",
               ["add", "deny", "ip", "from", IPAddr.new("123.45.67.0/255.255.255.0"),
                "to", Hostname.new("my.host.org"), PortNumber.new(80)])

At the end of the afternoon I had my tokenizer, and a tagger. We don’t have a full parser yet, so there are no syntax checks for IPFW in the 3.0 release. After defining a new Firewall and Line (as in rule line) class for IPFW, I had working models, and was ready to start on the controller and the OSX client.

Back to the salt mines, for now.

That concludes the server portion of our program, in the next episode I’ll gush a bit about ObjC, and reveal the inner secrets of our OSX client.

]]>Introducing Playbook 3.0http://chargen.matasano.com/chargen/2009/12/17/introducing-playbook-30.htmlThomas Ptacek2009-12-17T20:15:02Z2009-12-17T20:15:02ZLet me tell you how good at marketing we are. We are so good at marketing that we are releasing a product right in time for the Christmas holidays —- in fact, just 7 days before Christmas break! As students of IT products know, the week before Christmas is an ideal time to capture the attention of enterprise buyers.

And on that note, allow me to introduce Playbook 3.0!

What’s Playbook?

New to Playbook? Here’s the elevator pitch: Playbook is the last product you’d think a vulnerability research team would build. It doesn’t decompile MIPS C code. It can’t spot vulnerabilities in VOIP implementations. It doesn’t harden the Flash runtime. It barely contains any compiler code at all! Instead, it takes the working lives of people who have to deal with firewall rules and tries to make them better.

If you write code, you’re familiar with things like Trac and Github. You check your code into version control, you browse and review it in a web interface, you document it in a wiki, and you file tickets for bugs. Every dev team uses something like it.

Playbook takes the same workflow and bends it to firewall management.

Playbook is a web interface to versioned-controlled firewall configurations, which it can slurp up straight out of running firewalls. It parses and understands firewall rules, detects errors, and (most importantly) indexes rule terms so you can find addresses and networks across large numbers of firewalls. It handles end-user requests for rule changes so you don’t have to pick up the phone to talk to the Sharepoint admin. It provides for peer review and approval. And when rules are staged and ready, it offers push-button deployment so you don’t have log in to 100 remote devices.

What’s New?

Playbook 3.0 does these things better: it has a better UI, it’s faster, the rule editor gracefully handles huge rulesets without dumping you into a big text edit window, and (here’s a big feature we’ll talk about later) it now handles host rules for OS X desktops and laptops.

We’re beta testing 3.0 right now. Interested? Our first three qualified beta testers (you qualify if you have production firewalls) get a permanent free starter license. Sign up here. Questions? Start here with the FAQ.

We’ve been quiet on the blog lately, and here’s one of the reasons. Craig will have more to say about Playbook 3.0 shortly, and then we’ll have another major announcement about products early in January. Stay tuned!

]]>Ninja Threat Modelinghttp://chargen.matasano.com/chargen/2009/11/2/ninja-threat-modeling.htmlCory S.2009-11-02T21:38:00Z2009-11-02T21:38:00ZConquer your fear

Like it or not, developing an attack plan for a penetration test requires standing up a rudimentary threat model. Not surprisingly, threat modeling often produces discomfort in the stomach and uncertainty in the heart of many testers, but you’ve got to cowboy up and do it.


You need to determine where you’re going to spend your limited testing time, which tools you want to pull out of your arsenal, and how to prioritize your findings after the test is complete. Testing an application while blind to the context of how it could be abused in a real world environment is a sure-fire recipe for disaster and embarrassment.

Start with an application overview sitting peacefully on your desk. A sudden bang, a quick diversion, a cloud of smoke - and a test plan appears in its place. Fear no more, for the guide to ninja threat modeling is here.

SDL: This isn’t the threat model you’re looking for

You’ve probably heard of threat models before, especially in traditional security development lifecycle circles. In that context, the threat models are generated in the requirements/design phase, which is much earlier in the process. It has spawned not just one, but two, Visio-driven tool sets from Microsoft and countless data-flow diagrams, attack trees, consulting engagements, and perplexed developers. When performed by a skilled and experienced team member, the model can be used to identify architectural weaknesses, guide default application behavior, and outline functional requirements for the product.

However, by the time you’re in the verification phase of the lifecycle, generating a formal threat model starts to yield diminishing returns. We recommend taking a short-cut with a set of assumptions that have served us well over the years.

Software would be great if it wasn’t for the users:
Client-side code assumptions

  • The attacker will have unfettered access to the client and will instrument all of the functionality (this includes the “secret” admin and debug functions), and all of the client-side controls will be removed.
  • If it accesses the network, there’s a man-in-the-middle.
  • All input will be malformed and unexpected - even from the trusted end user: who will happily introduce input from untrusted sources.
  • The source code is completely exposed - including any secrets stored in the code.
  • If the application runs at a privilege level that the attacker desires, he will attempt to abuse it for nefarious purposes.
  • Don’t assume the code you’re testing is the attacker’s final destination in his path of exploitation. If the code weakens the system’s security posture in any way, the attacker will abuse it.

I’m sorry, Dave. I’m afraid I can’t do that:
Server-side code assumptions

  • All of the assumptions for client-side code hold for server-side code as well. This includes the source code disclosure assumption if you’rere shipping product. If you’re running SaaS, it’s more of a question of when, not if.
  • The attacker is going to sit on the same network segment as the application. There’s no firewall or filters. There’s a special place in hell reserved for products that require firewalls or filtering to protect themselves against attack.
  • The naming service that the product relies upon will be compromised.
  • The switching and routing fabrics will be compromised.
  • If you have more than one defined user, one user will want to do things as the other user.
  • If you have more than one defined role, a user in one role will want to perform functions in the other role.
  • An attacker may want to cover their tracks. If he can do it with subtlety, he will take that path if it is easy to do.
  • If it is exposed to the Internet, some yahoo will want to make it crash with an asymmetric attack (think packet of death or attack amplification).
  • If the application runs on a multi-user system, other users on the system will attempt to subvert the application through any and all resources they can access (such as the file system, shared frameworks, IPC, and others) .
  • If the application uses URIs (HTTP/FTP/SMTP/ITMS, whatever), an attacker has compromised the innocent client and has access to the session command channel.

A return to olde SDL land?

With these assumptions in place, you could go ahead and do some basic data flow analysis. You should be able identify key entry points in the application where data and functionality cross trust boundaries. If you want to stay in step with Microsoft, feel free to pull out the STRIDE* model and apply the threat types to each entry point, keeping in mind the assumptions m= entioned above. With the threat landscape outlined, you’ll find the STRIDE process will go faster than simply working from a blank data flow diagram without context.

However, ninja threat modeling uses data flow analysis as a clean-up task, rather than the opening salvo. We’re impatient and want to know the answer to the question, “What entry points should we really care about?” right away.

* As required by the SDL powers-that-be, I am obligated to mention STRIDE threat types (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) in all communications relating to threat modeling at least once.

Where there’s smoke, there’s fire

A heat-seeking approach to drive your test plan is just what you need. When we blather on about entry points, trust boundaries, and threat vectors, what we’re really thinking is “Where can I do the most damage in the shortest period of time?”

The ninja threat model relies on two techniques: incident and vulnerability history and the commission of deadly sins.

Those who cannot learn from history are doomed to repeat it

The first technique examines how the product or similar products have been abused in the past. Don’t just look up old advisories or bug reports - look for incident data. Did a product have a vulnerability that allowed malicious code to spread? Was the vulnerability discovered and abused by a 16-year-old to make lots of friends on the social networking platform of the day?

Examine these abuse cases and make sure you can recreate them against the application you’re testing. At the root of each one, there should be a vulnerability, a threat actor, and an impacted asset. If you’re stuck with dry vulnerability advisories, sometimes the researcher will have a good grasp on the impact of the finding and will document it well. In other cases, you have to watch out for advisories with overreaching statements or extreme speculation.

What’s nice about these types of derived threats is a good amount of the test planning is already done for you and can be lifted wholesale. Watch out for tunnel vision, though - time, platform specifics, or other dependencies may have limited the avenues available to the researcher or intruder. Make sure you’rere looking for the pattern that indicates the flaw is present, not just performing a pattern match on yesterday’s exploit.

Where DIY should be DDIY - Don’t Do it Yourself

The second technique focuses on what developers get wrong most of the time - otherwise known as the “Deadly Sins”. The vulnerabilities introduced by these common flaws are mentioned for a reason: they get abused by threat actors on a regular basis.

Every security outfit has a list of their deadly sins, including Microsoft, SANS, OWASP, and Matasano, because lists are just that cool. We think ours is better for one major reason - our Deadly Sins are features rather than defects. As a result, our work fits into ninja threat modeling much cleaner than a laundry list of vulnerabilities.

It’s an issue of perspective and language. Developers don’t roll out of bed in the morning and say, “I’m going to code up a few SQL Injection vulnerabilities today!” Instead, they say, “I’m going to write the Advanced Search module for the Report Engine today!” When you hear this, your utter lack of faith in your development brethren should kick into overdrive and you should be busily entering “Test for SQL Injection here, here, and here” in your test plan.

We’ve appended our list of Deadly Sins for Web Applications for easy reference. Parts of it also apply to other sorts of applications. When you see these features, get out your red pen, add another page to your test plan, and start outlining how many different ways developers get these things wrong and how to test for it.

Time for the test plan

After wrapping up the heat-seeking exercises, it’s time to sanity check your work with data flow analysis including the selective application of STRIDE mentioned earlier. Hopefully, the overlap should be extensive. If it isn’t, you may be dealing with something that hasn’t been tested extensively and may bear some interesting fruit. On the other hand, you may have been assigned the most boring application known to mankind. Congratulations!

After following this approach, you should have a good definition of the application’s attack surface and the threat landscape which you will be attempting to recreate. As a result, you should be able to produce a meaningful test plan with a threat model that is defensible and sufficient to guide your engagement. You might even get away with doing one without a single Visio diagram.

Deadly Features for Web Applications

 

1. Security

  • Encryption
  • Hierarchical role/privilege management
  • Password storage
  • Password reset


2. E-mail functionality

3. Thick Clients: Web Applications In Name Only (WINOs)

4. File Upload/Download

5. Templating and Content-Controlled Code

6. Advanced Search

More Deadly Features for Applications

 

7. Persistent network sockets that accept arbitrary connections

8. Installers

9. Use of plug-ins or third party software to write directly to the DOM

10. Single Sign-On Authentication Hand-offs

 

]]>A C++ Challenge - The Conclusionhttp://chargen.matasano.com/chargen/2009/10/15/a-c-challenge-the-conclusion.htmlChris2009-10-16T00:04:55Z2009-10-16T00:04:55ZThe contest is over! We got some good submissions and as expected a few security researchers found the bug rather quickly. The sample code had numerous defects, however not all were exploitable. Here are our top 3 correct submissions in order they were received:

1st Drew Yao: With the quickest submission and first exploit. He exploited the bug on OSX Snow Leopard
2nd Kevin Easton: Sent in code that produces an exploit file
3rd Evin Robertson: With a great fuzzing technique for initially finding the bug (valgrind a.out /dev/urandom)

Other correct entries:
Joe Damato - Joe did a great write up on the challenge here
Rachel Blum
Anonymous 1
Anonymous 2

In addition to our contest submissions, we promised we would provide an answer to our vulnerability challenge, and here it is. The example code has a lot of issues. Everything from missing NULL pointer checks to a missing free. The bug we were looking for is the size overflow in the argument to our new operator. Our program opens up a binary file and reads some values out of it using a _stream structure. From those first few values we get an integer ‘s->num_of_streams’, which of course we sanity check before using it as an argument to a memory allocator. Unfortunately our sanity check is broken in the following if statement:

    if(s->num_of_streams >= INT_MAX / (int)sizeof(int)) {
        safe_count = MAX_STREAMS;
    } else {
        safe_count = s->num_of_streams;
    }

The problem with this check is that our Object class is not sizeof(int). We assign safe_count the value of ‘s->num_of_streams’ and go on our way. Following this bad check we call the C++ new operator to allocate an array of class instances representing each stream in our file. Unfortunately g++/libstdc++’s new operator allows for overflow to occur. This happens because we are asking for new to allocate ‘safe_count * sizeof(Obj)’. This a known issue, but more on that later.

So now we’ve allocated a smaller number of class instances than ‘safe_count’ specifies. Following the allocation of our class instances a meta data structure is placed on the heap using malloc(), zeroed out and a function pointer is setup. Now we enter a for loop using our attacker controlled safe_count value. This is where our problems begin, our for loop allocates a temporary buffer with each iteration copying a stream from the file into it, a DWORD is read from the stream and the parse_stream() method is called for each class instance we allocated earlier. The parse_stream() method sets the class member variable ‘type’ to the value of the parse_stream() method ‘t’ argument. The location of class member variable ‘type’ should be in the heap because we allocated the class instance using the new operator. Unfortunately this is done for more class instances then we actually allocated earlier. This allows us to overwrite the function pointer in the ‘imd’ structure, by way of the parse_stream() method, and gain code execution. This happens because the parse_stream() method effectively performs a 4-byte overwrite into heap memory that contains the ‘imd’ structure.

The fix here should start at the sanity check of s->num_of_streams. We should declare num_of_streams unsigned. This value should then be validated such that s->num_of_streams is not greater then MAX_STREAMS.

We originally wanted to share a similar real-world code pattern but that bug isn’t officially patched yet and we wanted to get this post out. But thats OK because we can still talk about the core issue.

As our example showed you can easily misuse the new operator. This is a known issue in libstdc and was mentioned as far back as 2002 in this Blackhat presentation. Using new to allocate some storage space may be common but there is another similarly dangerous but slightly less used code pattern here, and thats using new to allocate an array of class instances. Most developers have learned to carefully inspect the size of an allocation before copying user data to it. But allocating too few classes can result in similar memory corruption and have subtle but exploitable consequences when all the right stars are aligned, and thats what this challenge was all about.

In the real world vulnerability we found exploitation was not as straight forward and may not even be possible. But the reason for that is actually an interesting story in itself (and by interesting I mean dry and boring). If the Obj class in our challenge had a constructor things would have been far different. Let’s add a simple constructor to our example:

    Obj(){ length = 0; }

To understand why this changes things you need to dive down and disassemble the code. Long story short, even though we tricked our application into allocating 8 classes, g++ compiles the code in such a way that constructors are called for every class instance we requested, all 357913943 of them! Now if the constructor does something like set some class member variables to NULL then our chances of exploitation are pretty slim. This is because our process will essentially rip through its own heap writing NULL bytes until it hits the end of the heap and crashes. Thats quite a destructive constructor! When a constructor like this isn’t present our fake class instances become an API for writing into arbitrary memory. Thats how you gain code execution in our challenge.

Some of our commentors made the point that this was not C++, but merely C with classes. To those commentors I would like to say ‘welcome to the real world’. Code patterns like this are why security vulnerabilities exist!

This code pattern raises some interesting areas for exploitation since your non-existent class instance(s) are basically an API for writing into arbitrary memory locations in the heap. Bad allocations from the new operator are a known problem, Michael Howard at MSFT has written about this issue before and MSFT did something about it! MSVC produces better code that doesn’t allow the integer overflow in the new operator to occur. Unfortunately g++ users are stuck with this issue for the forseeable future.

]]>Corporate Pentesters: Fill Out Survey, Get Big Posterhttp://chargen.matasano.com/chargen/2009/10/14/corporate-pentesters-fill-out-survey-get-big-poster.htmlThomas Ptacek2009-10-15T02:20:38Z2009-10-15T02:20:38Z[Update: That was fast! We’re at 97 submissions. 3 more and we go to lottery mode. For the rest of the week, if you fill out the survey, you will almost certainly get a poster. We’d give everyone a poster, but they cost a couple bucks a piece to ship.]

A few weeks ago we ran a survey for firewall operators. The results were a huge win for us. But most of our readers aren’t firewall operators. A lot of you are company pentesters, though. Are you part of a company application security team? Fill out a survey, and we’ll send you a poster. It will look marginally better and be significantly bigger than the picture below.

Poster

Take the survey here. It’ll take you less than 5 minutes.

The first 100 responses will get posters, and we’ll ship 50 more posters by lottery if we go over 100 responses (we’ll let you know in this post if that happens).

]]>Blog-fix-omatron: DH Parameter Tampering Explainedhttp://chargen.matasano.com/chargen/2009/10/14/blog-fix-omatron-dh-parameter-tampering-explained.htmlThomas Ptacek2009-10-15T02:14:16Z2009-10-15T02:14:16ZWhen we moved the blog off Wordpress, the new host had trouble with our XML export. So we’re missing posts, and I’m gradually adding them back.

Here’s one you may have missed back in ‘07. It explains how to beat bad implementations of Diffie Hellman and SRP:

Adam Bozanich Did Not Uncover An NSA IPSEC Conspiracy (but he found a pretty cool bug).

]]>A C++ Challengehttp://chargen.matasano.com/chargen/2009/10/9/a-c-challenge.htmlChris2009-10-09T20:51:13Z2009-10-09T20:51:13ZLet’s say you show up at an interview.

The interviewer asks whether your comfortable reviewing C code.

You say “sure!”, confident in your ability to spot a bad call to memcpy() on the spot.

The interviewer asks you if you have any experience auditing not just C, but C++.

Again, you confidently respond “no problem!”.

The interviewer presses further: “What about the intricacies of C++ templates and class instantiation at the assembly level?”.

This time you pause for a moment to ponder the question …

C++ lends itself to much more complex vulnerabilities then plain old C. From templates to string classes, C++ raises the skill level required to play the memory corruption game. And while the quality of C/C++ code we see has increased dramatically over the years, a lot of developers still don’t understand the more obscure C++ bug classes.

I recently found a vulnerable C++ code pattern that I wanted to share with our readers. But instead of just writing some boring technical blog post, Matasano would like to present a C++ audit challenge to our audience. It consists of a contrived vulnerability that follows the same vulnerable code pattern. Our rules are simple:

1. We give you working C++ source code you can compile with g++

2. You audit the source or binary, find the bug and submit your findings via email to: chris _at_ matasano.com All submissions should include a paragraph explaining where the vulnerability is, why its vulnerable, your exploit it and how you would fix it. A working exploit is required to win, but we will also post correct runner-up submissions that don’t include one.

3. Matasano announces the best three correct submissions and sends them Matasano branded magnet and posters (sorry no cash prizes!)

The quicker you submit, the better. Following the contest’s conclusion we will present a follow-up post that goes over the details of our contrived vulnerability and how to exploit it. More importantly, we will also blog about the real world vulnerability we found with a similar code pattern.

The contest vulnerability is confirmed exploitable on Linux and OS X. If you’re an experienced security researcher you can probably spot the bug in just a few minutes. Maybe seconds! We don’t expect to stump the Mark Dowds of the world, but if we can have some fun and educate a few developers in the process then were all for it.

We also ask that you don’t post any answers in the comments, but we can’t stop you and we certainly aren’t in the business of deleting legitimate comments. So without any further delay, you can download our challenge HERE

]]>Ruby For Pentesters - WIN32OLEhttp://chargen.matasano.com/chargen/2009/9/26/ruby-for-pentesters-win32ole.htmlChris2009-09-26T23:43:53Z2009-09-26T23:43:53ZThis week in our Ruby For Pentesters series I wanted to cover a Ruby library we have used a lot over the past year or so. Using Ruby on Windows is not one of the most exciting things I can think of. But there are times when you have no choice, working with ActiveX controls is one of those times.

Working with COM objects can be tricky, its a complex and sometimes confusing technology. Lucky for us, Ruby provides us with a library called WIN32OLE by default. WIN32OLE can be used for parsing and controlling COM/OLE components from Ruby. For example, we can use the WIN32OLE library to open up and play with Internet Explorer.

    require ‘win32ole’

    ie = WIN32OLE.new(‘InternetExplorer.Application’)
    ie.visible = true
    ie.navigate(‘http://www.runplaybook.com’)

We passed in the ProgID for Internet Explorer and sent it to a URL of our choosing. Pretty standard stuff for a COM interface. But it’s pretty neat how seamlessly it works form Ruby.

Do you subscribe to milw0rms RSS feed? Its full of ActiveX vulnerabilities. But let me fill you in on a little secret, most of them are nothing more then feeding some random ActiveX controls eatAString() method a bunch of A’s. But how are these obscure (it’s called sarcasm people) and seemingly exploitable bugs found?

Well I’m here to show you! And I promise by the end you will be finding bugs in some random ActiveX control on your box. When an ActiveX control is marked ‘Safe For Scripting’ it usually exposes a bunch of methods and properties that the browser can call or set from a scripting language like Javascript or VBScript. This is what makes ActiveX bugs fun: ITS NATIVE CODE. But how can we find these interfaces and start poking at them with Ruby? WIN32OLE of course.

Note: We won’t go too deep into the details of COM/OLE here, check out http://www.cert.org/archive/pdf/dranzer.pdf or http://uninformed.org/?v=9&a=2&t=txt if your interested in a more detailed write up.

WIN32OLE can do a lot more then just control InternetExplorer. We can use it to list all of the properties and methods any ActiveX control exposes. Lets drill down and focus on an individual ActiveX control that we can start fuzzing. Microsoft XP ships with an ActiveX control named ‘htmlfile’. You can read more about it here http://cometdaily.com/2007/11/18/ie-activexhtmlfile-transport-part-ii/ and here http://msdn.microsoft.com/en-us/library/aa752574(VS.85).aspx. This is a good example control because it contains a lot of methods we can play with. Heres some small example ruby code that demonstrates how to get a list of methods the control exposes:

   require ‘win32ole’

   a = WIN32OLE.new(‘htmlfile’)
   methods = a.ole_methods.select { |m| m.visible? }
   methods.each do |meth|
       puts “#{meth.name}(” +
           meth.params.map {|p| “#{p.ole_type} #{p.name}” }.join(‘, ‘) + “)”
   end

You should have seen a bunch of junk scroll up your terminal, junk like:

   cloneNode(BOOL fDeep)
   removeNode(BOOL fDeep)
   swapNode(IHTMLDOMNode otherNode)
   replaceNode(IHTMLDOMNode replacement)
   appendChild(IHTMLDOMNode newChild)

What you saw was WIN32OLE opening the ‘htmlfile’ control by using its ProgID and dumping the methods exposed by the control along with type information. Great, now we know what methods we can call into and what type of arguments those methods are expecting. With this information we can start generating test cases and looking for bugs. But we’re getting ahead of ourselves here, first we need to understand how to instantiate the control in a real-world way. We can use some simple HTML and Javascript for that:

   <html>
    <script lang=’JavaScript’>
       var axobj = new ActiveXObject(“htmlfile”);
    </script>
   </html>

Note: Yes, its possible to fuzz directly into the control via WIN32OLE but were interested in vulnerabilities we can reach via Javascript within Internet Explorer. For this reason we stick with the ‘fake webserver’ technique.

Now if we wanted to call the cloneNode() method within htmlfile our Javascript looks like this:

   <html>
    <script lang=’JavaScript’>
       var axobj = new ActiveXObject(“htmlfile”);
       axobj.cloneNode(1);
    </script>
   </html>

So now we need to use Ruby to automate all of this and find some bugs. Enter AxRub.

AxRub is a tool I threw together and discussed this July at Blackhat 2009 during our Ruby For Pentesters talk. AxRub was inspired by HD Moore’s AXMan, which is an impressive tool, but difficult to use on a targeted penetration test. AxRub makes the process of fuzzing ActiveX controls much more targeted, and fast! It’s very early stage code and needs a lot of improvement, your ideas are welcome. You can grab AxRub here http://github.com/struct/AxRub

Here is an overview of how it works:

   1. Use WIN32OLE to get a list of methods/properties our target ActiveX control exposes
   2. Setup a small fake web server
   3. Listens for connections from IE
   4. Generate test cases and serves them up via HTML

Demo:

   C:/> ruby axrub.rb htmlfile

Now connect to http://localhost:8080 with Internet Explorer and wait for those quality 0days to roll in.

]]>Indie Software Security: A ~12 Step Programhttp://chargen.matasano.com/chargen/2009/9/24/indie-software-security-a-12-step-program.htmlThomas Ptacek2009-09-24T20:02:26Z2009-09-24T20:02:26ZEvery autumn, John “Wolf” Rentzsch holds an indie software development conference for Apple developers in Chicago called C4. It’s really excellent. I’d recommend you attend, but it’s become one of those things that sells out the day he announces the tickets. We don’t get to go this year.

But last year, we did get to go. Because we’re local, Rentzsch asked us to get up on stage and give a talk. So we roped in Nate McFeters, another local, and put together a security talk for indie Mac developers with no budget for security. What does a security talk for Mac developers look like? As it turns out, it’s very much like the talk we think every indie developer, Mac or not, should see, and it’s very much unlike the talk the rest of the security industry is giving. And, without further ado:

Here’s our talk. Here’s the slides.

(But see the bottom of this post for some caveats about this talk.)

Indie Software Security: A ~12 Step Program

You’re launching the first version of your web application. You’re pre-revenue. Your every waking moment is consumed with the backlog of product enhancements you believe will help your app break through. And you’re about to land on the top of Reddit because of a security flaw.

We’re software security people. Our industry is built around breaking software. People like us are the ones putting people like you on the top of Reddit. People like you are the weak, and people like us are the tyranny of evil men.

You’re listening to us because you’ve finally given up trying to control the security of your application. Everything else you’ve tried has failed. The advice the “security industry” has given you has had negligible business value, because you’re not a Fortune-500, and you aren’t shipping shrink-wrap to 1,000 enterprises. And the failure of that advice is partly our fault. This is our response.

Read the advice we’re giving here. See how you’re doing. Honestly, are you on top of these issues? Remember, there is no disgrace in facing up to the fact that you have a problem.

Step 0: Are You Our Audience?

Do you make lots of money? Do you have lots of money? Are you taking credit card numbers? Do you have a formal SDLC? Do you actually employ security researchers? Does anyone in your company have “security” in their title? Answer “yes” to any of these?

You’re not our audience. You have different problems. Some things we say you should do in this post, you should not do. Other things we say not to do, you can go ahead and do.

With that said, critique away.

Step 1: Stop Caring So Much

Here are five things that will kill your startup before software security does:

  1. Slowness
  2. Poor graphic design
  3. XML
  4. The RIAA
  5. Product Marketing Managers

The graveyards in this town are littered with the corpses of startups that pinned their hopes on advanced security. Better engineers than you have tried and failed. Theo de Raadt coordinated the first large-scale security codebase audit. His reward:

Three years without aOnly two remote holes in the default install!

This is not a killer marketing message.

Or, try Daniel Bernstein. qmail shipped for ten years without an exploitable remote flaw. It has the best security track record of any piece of mainstream software, ever. But Bernstein got integer signedness wrong in one place —- resulting a bug that you can’t even exploit on any modern system —- and now every security blurb about qmail is up for debate.

We don’t want you to be the guy in the PG-13 movie, the one everyone’s really hoping makes it happen.

37signals is not bad about software security. They’re incredibly successful. They make millions of dollars on an online contact manager. 37signals has a genius for marketing. They’re so money! It’s like Jedi Mind Shit! They’re not bad about security; they’re just not awesome about it.

We want you to be like the guy in the rated R movie. You know, the one you’re not sure whether you like him yet. Okay? You’re a bad man. You’re a bad man.

Step 2: First, Get Outreach Right

Do this first. Don’t waste time with anything else.

There are a lot of ways to be good at security without being awesome at it. Most of them don’t matter. This one does: you need to be smart about how you interact with people finding and reporting vulnerabilities in your products

Take, for instance, 37signals. There’s been a pretty negative response to their handling of the disclosure of a cross-site scripting vulnerability in their software. Why did that happen? Because if your company doesn’t act as if it knows how to handle security reports, the world will assume the worst of you, no matter how hard you’re trying.

This is literally the simplest security challenge your shop shouldn’t be screwing up:

  • Get your developers in a room, draw straws, and the short straw is now “security@mystartup.com”. She’s the “security contact”. You now have one.

  • Create a “security” page on your main site. It says, in a nutshell, “we’ve thought about security.” It does not talk about AES key sizes or RSA-OAEP.

  • Create a “security reports” page. Link to it from your “security” page. It says, in a nutshell, “here’s how to send us security reports, and we’re not going to be jerks about it.” The one 37signals set up is, we think, an excellent example of the genre.

  • Your “security reports” page needs to link to a PGP key. This is code for “we’ve given a moment’s thought to the idea that we might have a security flaw in our app reported to us”.

  • Fixes for security flaws are not features or enhancements. Don’t call them that. In fact, don’t even call them bugs. Give them “security IDs”. This costs you nothing, and is another subtle signal you can send that you’ve done this before.

  • For the love of god don’t argue about severities. You won’t win. Security researchers have more buzzwords to throw than you do. Even if you’re right, 50-75% of readers will assume that (a) you’re not right and (b) you’re being petulant.

  • Thank the people who submit security flaws to you, even if you don’t feel thankful.

If there’s one thing we want you to understand about vulnerability reporting, it’s this: however hard your startup has had to struggle to get press and attention, no practicing security researcher has had to work 1/100th as hard to get in the mainstream press. For a myriad of reasons, some good, many bad, everything security researchers do is newsworthy. They’ve drawn KK to your A7 suited. Don’t overplay it.

Step 3: Everything You Need To Know About Vulnerabilities In Two Bullets

There’s a sprawling literature about different kinds of security flaws. You can safely ignore it. If you try to stay up to speed, you’ll still lose, but you’ll miss the simple stuff. You only need to know two things, and here they are:

Bullet 1: Counting is scary. Many billions of dollars have been spilled dealing with one basic problem, which is that it’s hard to keep track of memory. If you understand this, you understand stack overflows, heap overflows, integer overflows, integer underflows, uninitialized variables, offset null-pointer attacks, and even that crazy pulseaudio Linux kernel flaw that depends on a compiler optimization.

Bullet 2: Content is scary. Many billions of dollars have been spilled dealing with one basic problem, which is that it’s hard to keep metacharacters out of user-controlled content that moves between different domains. If you understand this, you understand cross-site scripting, SQL injection, shell injection, xpath injection, and Nate McFeters GIFAR attack.

And so:

  • Initialize your variables to 0 or the empty string.
  • Abort your program when malloc fails.
  • Count, using unsigned integers, and don’t let them wrap.
  • Whitelist content to alphanumeric.
  • Swap punctuation for HTML entities.
  • Go live your life.

But, but, but! What about that Black Hat talk that Mark Dowd gave about the plug-in interfaces in all those browsers? What about that crazy Flash exploit he wrote? Those were cool. They made waves in the security industry. But they weren’t about you. His audience is security researchers, not indie startups.

Step 4: Seven Deadly Features Of Indie Software

Here are 7 features that you simply shouldn’t implement yourself.

  1. Encryption, unless it’s GPG for data at rest, or SSL for data in motion.

  2. Password storage, unless it’s bcrypt.

  3. Writing anything directly into the DOM of a browser via a plugin or any third-party software.

  4. Installers.

  5. Things that listen on network ports when your code is running, or (just as likely) all the time. Even —- no, wait, especially —- if it’s a web server.

  6. Content-controlled code. For instance, if you’re designing a web templating system for a PHP app, the templating language cannot be PHP.

  7. File download or, worse, upload.

People hear this list and they think we mean “be really careful when you implement these features”. We do not mean “be really careful”. We mean “don’t do it”. Change your app design so it doesn’t need the feature. If you can’t get dodge the feature, find its best-known, most-beloved implementation, and use that instead.

Step 5: Deploy Rubber Chicken Security

Here are some security features that don’t really do anything for your security, but that you should consider doing anyways:

  1. Big long random URLs. Nothing says “security” like a big long random URL.

  2. SSL. Use it wherever you can, and then you get to put the little graf on your “security” page about how you use “the same kind of security that banks use”.

  3. Little lock icons.

  4. Encoded inputs and outputs. Don’t just stop at Base64; jumble the Base64 character set up, so when people decode it, it looks like it’s been encrypted.

  5. Encryption. Wait, didn’t we just say not to use encryption? Yes. Don’t rely on encryption. Don’t care about the encryption. But do scramble things. And don’t just use AES; add or subtract a couple of rounds (a 1-line change in your AES code), so that a standard AES implementation won’t decrypt things properly.

  6. Write things in a “safe” scripting language instead of C.

  7. Buy “Hacker-Safe” certification, or get PCI certified, so you can put a little seal on your site.

None of these things really protect you. For every item on this list, there’s a domain-specific threat that’s far more important than what that feature is trying to address. Some of these features do nothing for you whatsoever.

But that doesn’t mean you shouldn’t take advantage of them. Some of them improve your marketing. Some of them raise the bar, very slightly, on finding flaws in your site, which may somewhat improve the quality of security researchers you deal with. Just don’t talk about this stuff in arguments with security people, and you’ll be fine.

Step 6: Fuzz

And now it’s time for Secrets of the Security Masters.

Every year, the security industry gets together at Caesar’s Palace in Vegas for Black Hat, the most important conference in software security. A huge chunk of the vulnerability research community submits talks. Most of these talks get significant press. And 50% of them follow a predictable pattern:

  • Here is a new technology that is in the news or that secretly controls our lives.

  • Here is the fuzzer I wrote for this important technology.

  • Here are the horrible flaws I found when I ran that fuzzer.

(Hey, we’re guilty as charged here).

What’s a fuzzer? Very simple. A fuzzer is something that knows how to talk to something else, using a protocol or a file format or an SDK, and that systematically replaces parts of the input with progressively scarier inputs —- long strings, SQL metacharacters, long strings seperated by various forms of punctuation, long strings seperated by SQL metacharacters, the 4 numbers clustered around every bit position in 16, 32, and 64 bit numbers, and so on.

You’re a software developer. You can write this code. For instance, part of your application handles vCard contacts. Write the vCard contact fuzzer. Run it against your application. If you wrote your fuzzer the same way most consultants write theirs, it will take a day or so to run. Fix what it finds.

If you’re a web developer, you’re in luck. Somebody wrote a really good fuzzer you can just go buy for a couple hundred bucks. It’s called Burp Suite. You can about the “Proxy History”, “Repeater”, and “Intruder” tabs. Buy it, run your application through it, and figure out how to use those these Burp features. Cover every input in your application. That’s almost 90% of what every pro web-app pentester is going to do.

(You want the commercial version, not the free version.)

Step 7: Your Code Isn’t A Secret

This last point is easy, and you’re probably already on the same page as us.

A couple years back, Nate Lawson reverse-engineered the Bay Area FasTrak tolling system, which uses an RF protocol to tell tollbooths to debit your toll account. To pull this off, Nate got a FasTrak dongle and reversed the hardware, at one point going as far as decapping the chip to enable the JTAG debugging interface.

Nate Lawson is an extremely smart guy. But he has a bill rate. He’s part of this industry. Any company that wants to work with him can pay him, and he’ll do that same stuff to whatever app they sicc him on.

My point here, and I do have one, is that you are doomed. The state of the art in reverse engineering has advanced to the point where, on general-purpose computers, it’s mostly point-and-click.

Nothing in your software should depend on the security of your source code. Even more importantly, you can’t fetishize your source code. If you communicate to the world that your code is hard to reverse engineer, then it’s a “win” for a security researcher just to have reversed it, whether or not they find anything interesting from doing so.

If you’re shipping code written in anything other than C, you should understand that you have shipped your source code. Even if you ran it through an obfuscation product of some sort (another rubber chicken). An easy way to absolutely convince people who know security that you don’t know anything about security is to make an argument that involves how hard it would really be for an attacker to figure out how your software works.

Step 8: And that’s it.

We’re short some steps, and that’s because for an indie development shop, those steps don’t matter. So few people are getting this stuff right that it seems pointless to talk about the rest of it. And that’s sad, because what our program recommends costs almost nothing, doesn’t involve certification or third-party testing, and immediately improves outcomes in security incidents.

Stop freaking out about security. You’re worrying about the wrong things anyways. Get this simple stuff right, and then get on with your life.

Some quick caveats about the talk itself:

  • We gave this talk a year ago.

  • We went back and annotated the slides, which really don’t stand by themselves, and we know that too.

  • YES I HAVE ARMS. It was the only clean button-up shirt I had that day.

  • Again, this is a talk aimed at indie Mac developers. If you’re a large ISV, a bank, a Fortune 500 company, we know: you do not want, you cannot use.

]]>