To me, hacking is what Dr. Frankenstein did just before he created his monster.

Today’s creation will glue a few parts together to make a web site that will show the geographical location of an IP address on Google Maps.  This script also lets the user look up the geolocation by DNS hostname.

The advantage of my approach over some others on the net is that this method is totally free and requires no API key.  I’ve also made it portable to shared hosting sites, and it will run just as easily on Linux, OSX or Windows web servers.

Screenshot of iplocate.php in action

First, an ingredients list:

1. A web server or web hosting site that supports PHP.
2. A copy of the latest version of MaxMind’s GeoIP City database, which provides the mappings from IP to map coordinates in latitude and longitude.  You can download the latest free version here.
3. The scripts require two PEAR modules:  Net_DNS and Net_GeoIP.  If you are running this on your own server, just use ‘pear install Net_DNS Net_GeoIP’.  If you are on Dreamhost, you can follow the awesome instructions on David Yin’s blog to get Pear installed first.

Once you have everything ready, all you need to do is download this PHP script, and customize it in a few places:

1. If you are on Dreamhost, and you had to install Pear in your home directory, uncomment the Dreamhost section at the top of the file (and replace the path with the real path to the “php” subdirectory of your Pear installation.  If you followed David Yin’s instructions above, the path will be:
   /home/USERNAME/pear/php
2. Replace the fake path on this line:
   $geoip = Net_GeoIP::getInstance("/FIX-THIS-PATH/GeoLiteCity.dat");
   with the real path to your GeoIP City database file.
3. Replace the fake IP addresses on this line:
   $resolver->nameservers = array('YOUR.FIRST.DNS.HERE','YOUR.SECOND.DNS.HERE','YOUR.THIRD.DNS.HERE');
   with the real DNS servers that you want to use for looking up hostnames.
4. Finally, copy the edited file into the documents folder of your web server (make sure that it has a .php extension) and point your browser at it!

You should now be able to enter an IP address or a hostname and have it pull up a Google Map of the correct coordinates!  If the hostname lookups don’t work off the bat, double-check step 2 above and try uncommenting the two DNS debugging lines in the PHP file.  Remember to give it DNS servers relative to your web server.

At this point, you might be wondering why I’m posting the PHP code instead of simply hosting this page myself. Turns out that Maxmind’s license for the free GeoIP database forbids you from providing a publicly-available interface that allows translating IP addresses into coordinates. The only way to do this (legally) using the free database is to either run this on an internal web server (not accessible to the public) or to password-protect the page using .htaccess files.

Obviously, this could be easily extended to add some stuff like plotting multiple different records from the DNS queries instead of just the first hit. Another idea is to make it spit out KML so that it would just magically work with Google Earth as well. I will leave that to you (or perhaps to some kindly strangers down in the comments).

Also, the hostname lookup feature reveals something interesting when you use it on edge-cached domains or clouds, but I’ll leave that for the home experimenter to explore.

… It lives, my creation LIVES…

Jabbercracky makes use of a two-pass hash cracking method.  In the first pass, the submitted hash is tried against a local collection of rainbow tables.  In the second pass, the hash is passed along to a Cuda-compatable GPU for brute-forcing.

I’ve been hosting a Jabbercracky server with a large collection of rainbow tables on ChaosVPN since January, and I’ve recently done a bit of work packaging it as a Python module, so you can host your own cracking service with your own collection of rainbow tables!

On ChaosVPN, the service is available at: http://hash.colab.hack or http://10.100.23.1

The Jabbercracky module is currently being hosted on the Python Package Index, so all you need to do to install is:

1) easy_install jabbercracky

2) Go to the jabbercracky egg directory in site-packages and follow the installation instructions in INSTALL.txt

In future versions, Jabbercracky will live up to its name and also provide an XMPP-based interface, so you can crack hashes on your beefy hardware at home from the comfort of your mobile phone!

If you have any interest in participating in the development of Jabbercracky, please drop me a line!

Greetings to mc.fly and ryd and Defcon 18!

- awgh

In this article I will show you how you can make a PS/2 keyboard to iPhone converter, including all hardware and software instructions. As the bugs get worked out, or improvements are made, I’ll update this page.

Motivation: The Great Apple-Elf Conspiracy

After using an iPhone for a couple years, I have started to believe that the developers of the iPhone actually hate those of us with broad, round thumbs.  I can’t make very efficient use of the virtual keyboard, even in landscape, and they refuse to add real support for Bluetooth or really any external keyboards.  I have a friend with pointy little thumbs who can type like 36 wpm on the thing.  I’ve also noticed that of all the Apple employees I’ve actually met, they all seem to be relatively nimble and elf-like, with pointy little thumbs.  Coincidence?

My thumbs are round, which is apparently an afront to Steve Jobs and his nimble elven-fingered lackies.

Perhaps if Apple employed more broad-thumbed people, they wouldn’t be so stubborn about actively disallowing using external keyboards on the iPhone.

If you are wondering why someone would want to be typing quickly into an iPhone, I can say with great certainty that you are on the wrong web site. Unless you got here by searching for “Elf Conspiracy”, then you should email me.  Please include a picture of your thumbs for verification.

Prerequisites

• Jailbroken iPhone – The official SDK doesn’t allow access to the serial port due to the Elf Conspiracy, so the jailbreak is required.  All you need to know about jailbreaking is at the iPhone Dev Team Blog.
• Arduino Diecimila or Dumilanove (or clone), available from many places.  This howto assumes that your Arduino is assembled.
• An iPod Breakout board, like this one from Sparkfun.  Any similar product will work.
• A Female PS/2 (Din 6) Keyboard connector.  Pull one off an old computer or buy one from Digikey or similar vendor.
• Wire, preferably several colors and about 24 gauge.  I’m using a spool from RadioShack in the pics below.
• One 500k Resistor.  I’m using an axial through-hole resistor from RadioShack, but you could add this to your Digikey order as well.
• Soldering Iron and Solder.  If you don’t know how to solder, you can learn here and here.
• (Optional) Pin Headers, like these.  I break these off and solder them to the ends of wires, so that they plug nicely into the Arduino.
• (Optional) Sweet 9v Battery harness so your Arduino becomes portable available from the Maker Store.
• (Optional) Stereo Headphone Jack from RadioShack or Digikey.

Wiring Things Up

Once all your ingredients arrive, fire up the soldering iron and have a quick look at the iPod Connector Pin-Out.

We’ll be making use of four of these pins for the keyboard: 11, 13, 16 and 21.  The definition of pin 21 says we need to place a 500k resistor between pin 21 and ground to enable serial communications to the iPhone, so we’re going to stick a resistor between pin 21 and pin 16, which is the serial ground.  We’re also going to be adding pin headers to pins 11 and 13, which will act as the TX and RX pins for serial communications.  Since we’ll ONLY be sending to the iPhone, we only make use of the iPhone’s RX pin, so we’ll also be adding a piece of wire to connect pin 11, the unused TX pin,  directly to the ground at pin 16.

You can also optionally add the stero headphone jack to pins 2, 3 and 4 right now and it will work whenever the breakout is plugged in.  This has nothing to do with the keyboard, but if you have a 1G iPhone with the lame non-standard headphone jack, this will fix it.

iPhone Breakout Wiring - Front

Here is the front of the fully wired-up breakout board.  Click on the image to have a closer look.

The backside is below.

iPhone Breakout Wiring - Back

I’ve put the jumper between pin 11 and pin 16 on the back of the breakout board.  It can be a bit tricky to fit everything on to pin 16, so I recommend first sticking the resistor through the hole, then wrapping the end of the jumper wire around it and soldering them together before clipping off the resistor lead.

Another tactic which may be useful here is to first tin the ends of your wire, then blob a little solder on the hole you want to stick the wire to.  Use the side of the soldering iron to warm your blob of solder and the SLIDE the tinned end of the wire into the blob.  Remove the iron, let blob cool, then let go of wire.

PS/2 Connector Wiring - Front

There is no path you can take through the pin numbering of the PS/2 Connector that makes any kind of sense outside the context of the deranged ramblings of a committee meeting.  Don’t think too hard about the pin numbers, just check out the picture above.

We’ll be making use of four pins here, and connecting all of them to the Arduino.  Ground will be wired to Ground on the Arduino, VCC will be wired to 5V, and the Data and Clock pins will be brought over to two of the Arduino’s digital pins (3 and 4).

PS/2 Connector Wiring - Bottom

The bottom of the PS/2 Connector is even less intuitive than the numbering scheme.  I recommend checking this picture, but also verifying that the pins on the bottom of your connector match the numbered pins you think they do before soldering anything.  You can check for connectivity with a regular multimeter by setting it to measure resistance and connecting one probe to the pin on the bottom and sticking the other in the hole.  If there is any resistance at all, then that pin is connected to that hole.

I’m using the Green wire for the Clock pin, the Red wire for VCC, the White wire for Data, and the Black wire for ground.

Once you’ve got the connectors wired up, strip the other ends of the wires and solder the leads to pin headers.  This will let you plug them in to the Arduino easily.  If you didn’t get the pin headers, you can try carefully tinning the wires to make them stay in the Arduino pin holes better.

I attached some wires to the pin headers on pins 11 and 13 of the iPhone breakout board.  The Black wire is to Ground (pin 11) and the Red wire is to VCC (pin 13).  I’ve then soldered pin headers to the leads for the two wires from the breakout board and the four coming from the PS/2 connector.

I’m using an Arduino Diecimila, since this program doesn’t require a better chip.  This is shown with a 9V battery harness from SparkFun for portability.

Attach PS/2 leads to the Arduino.

Next, we connect the PS/2 Connector to the Arduino.  Connect the Clock wire to Digital Pin 3, the Data wire to Digital Pin 4, and connect the Ground wire to Ground on the Arduino and the VCC wire to the 5V pin.

Attach iPhone leads to the Arduino.

To connect the iPhone breakout, simply connect the lead from Pin 13 to the TX Pin on the Arduino (Digital Pin 1) and then connect the lead from Pin 11 to any available Ground on the Arduino.

IMPORTANT: To avoid trouble with flashing the Arduino, please disconnect the TX Pin on the Arduino before flashing.  More on this later.

Putting it all together.

After that, all the soldering is done.  Now it’s time to move on to programming the Arduino!

The Arduino Code

The Arduino software clocks data out of the keyboard, translates the keyboard scan codes to key codes, and handles presses of the shift and caps lock keys.

First off, download and install the Arduino development environment from here.  Follow the directions on the site, but be sure to install the appropriate FTDI driver from the drivers directory in the Arduino installation.

Next, you’ll need an additional Arduino library for PS/2.  Download the file “ps2.zip” from this page.  To install, unzip the download to a folder and move that folder to be a subdirectory of the “hardware/libraries” directory under your Arduino installation.  On OSX, you can go to Arduino.app and “Show Package Contents” first.

Once Arduino and the ps2 library are installed, download the source code from here.  Open the Arduino application, create a new project, and paste the source code into it.  Save, and then go to Sketch->Verify/Compile to make sure that it builds.  If it doesn’t, make sure the library is installed correctly.

On a side note, I actually wrote absolutely no code for this project.  I started out trying to use the PS2KeyboardExt2 library, but that library is based on interrupts and while it can run on an Arduino that is also speaking serial at 9600 bps, once I cranked the serial up to 19200 bps, the interrupts stopped working in a stable way.  So I yanked all of the nice code out of PS2KeyboardExt2, including the key definitions and the nice handling of shifts and caps lock and reworked it into a program that doesn’t use interrupts and makes use of a different, much simpler PS/2 library.  This makes it capable of handling 19200 bps serial in a reliable manner.

Now, to program the Arduino!

Disconnect the lead going to Pin 1 on the Arduino.  Then, connect the Arduino to your computer via USB cable.  You may need to restart the Arduino application so that it detects the new USB serial device correctly.  Load the saved sketch with the source, and then hit the Upload button to program the Arduino.

Once the program is uploaded, plug the keyboard into the PS/2 connector.  You should see the lights flash.  You can open up the Serial Monitor in the Arduino application and try typing some letters on the keyboard.  You should see those letters show up in the Serial Monitor.  Try turning the Caps Lock on and off, the light on the keyboard should go on and off and the characters should come out correctly capitalized.

The iPhone Client

Now to set up the iPhone client program.

For the client code, I’m using a program I found on Anthony Pray’s Google Code page.  This program reads input from the serial port at 19200 bps and then injects the appropriate keyboard event using a VNC client library.  I’ve made a local text-only mirror of the source here, which can be easily fetched with wget.

Since we’ll be injecting keypresses by VNC, you’ll also need to be running a VNC Server on the iPhone.  We’re going to use Veency (which is awesome and you should install anyway).

Go to Cydia or Icy and install the following packages:

• Veency - Provides the VNC Server, configure it to run at startup
• LibVNCServer - Provides libvncclient
• iPhone 2.0 Toolchain - Provides a build environment (gcc, libgcc, ldid, libz are required if you go another route)
• MobileTerminal - So you can access the iPhone terminal
• wget - So you can pull down the source file

Now to download and build the source.  Either open up MobileTerminal or SSH into your phone, and then do the following:

• wget http://awgh.org/files/TouchClient.c
  
• gcc -static-libgcc -o TouchClient TouchClient.c -lvncclient
  
• ldid -S TouchClient

The last step, using ldid, fakes signing the binary.  Without it, the iPhone OS will kill your process immediately.

To start the program, run it from Mobile Terminal with:

./TouchClient

This will cause Veency to pop up a dialog asking if you want to accept the VNC connection.  Hit Accept.

I’ve noticed that running this from MobileTerminal keeps the program alive even when you leave MobileTerminal, but it would be better to use launchd.  I haven’t figured that out just yet.

Finishing Touches and Future Work

To finish up, reconnect the lead from Pin 13 on the iPhone breakout to the TX pin (pin 1) on the Arduino.  Disconnect the USB cable and switch the Arduino to external power.  Plug the iPhone breakout into your iPhone.

If:

• TouchClient is running on your iPhone
• The PS2 software is running on your Arduino
• The Keyboard is plugged into the connector, and the connector wired to the Arduino correctly
• Veency is running and you have accepted the connection from TouchClient
• Nothing else is screwed up

You should be able to type on the PS/2 keyboard and have those keystrokes translated to the appropriate iPhone keystrokes.  This will work anywhere in the iPhone, in any app or native feature.

This solution isn’t perfect, but it’s a general-purpose approach to using the Arduino to add PS/2 keyboard support to almost anything that can read simple serial messages.

Future work:

• The scan code mapping could be moved entirely to the iPhone, and the hardware part of this project could be reimplemented on a much cheaper and lower power consumption chip, like a PIC.  This would reduce the cost of the unit by about $30, although it would require a PIC programmer.
• Not all special keys are correctly mapped, but if you look in the Arduino code and then at the iPhone code, you’ll see that this is an incredibly simple process.  Please post any changes you make back here as a comment!
• Rather than being a crazy wire hack, I’d like to see this fit into a snug little enclosure for real portability.  Any ideas in this department would be appreciated.
• I would like to give TouchClient a password for Veency so that there isn’t that annoying Accept/Decline pop-up.
• This exact method could be used to add a Bluetooth keyboard.  Simply add a Bluetooth-Serial module to the iPhone breakout and keep using TouchClient & Veency.

That’s it.  I hope you enjoyed the howto!  Looking forward to your comments.

Regards,

-awgh

Java vulnerabilities are most commonly found in places where unsanitized user input is passed, directly or indirectly, on to an underlying library or service.  To put it another way, vulnerabilities aren’t found in the Java code itself, they are found by following user input through the Java source and out the other side.

The tendency of Java to hide implementation details from the developer actually creates these vulnerabilities in places where it might not otherwise exist.  Java developers use wrapper libraries for backend services, such as SQL or LDAP, and assume that they automatically sanitize their inputs, when usually they do not.  In most cases, Java wrapper libraries themselves are simply classes that store and manipulate strings which are just passed directly on to the wrapped service.  In many of these implementations, such as the ORM library Hibernate, there are architectural reasons why this behavior can not be changed.

In this post, I will describe a class of extremely common Java vulnerabilities, specifically these “pass-through” bugs, characterized by user input passing directly through Java unexamined.

For our first example, we’ll look at one of the most commonly used (and misused) constructs in the Java programming language:

The File Class Constructor

The File class has several constructors, but the most common takes a single string argument, which is the full path to a file.  The second most commonly used constructor takes two string arguments, which are effectively appended together and treated the same as the single string argument.

The Java documentation uses the word ‘Canonicalization’ all over the place.  All paths fed in to the File constructor are canonicalized.  Many people understand this as “All the dot-dot-slashes are removed.”

While this is technically true, a canonicalized path has no path meta-characters, canonicalization doesn’t simply remove them – it resolves them correctly!

For example, the path “/www/hosts/mydomain.org/docs/../../../../etc/” would be “/etc/” after canonicalization.

This confusion over what canonicalization means commonly leads to directory traversal vulnerabilities in Java-based services.

Imagine a simple web server in Java, which does the following:

1. Accept an HTTP request for a particular URL:  “http://www.mydomain.org/PATH”
2. Calls the File constructor with the web root and path:  File f = new File( “/www/hosts/mydomain.org/docs”, PATH );
3. Simply opens the file and returns it to the requester as an HTTP response.

Perhaps the assumption is that somehow the File constructor filters out path meta-characters such as “../”, which it doesn’t.  Some developers assume that the first argument to the file constructor will somehow act like a chroot and prevent “../” in the second argument from traversing to a higher directory.  This is not the case, as both arguments are simply appended and treated as one big path string.

Whatever the developer assumptions, this error appears in different variations across a surprisingly large percentage of Java code.

This category of errors comes from the fact that Java can’t interact with the file system directly – it has to pass path information through to the operating system.  In fact, the specific path meta-characters that can lead to injection will vary from platform to platform – even though Java tries to be “platform independent”!  An obvious example:  “../” on a Linux system is the same as “..\” on Windows.

To find these errors, simply search for places where user-controlled input is passed directly in to the File class constructor, without any additional logic to remove path meta-characters such as “../” or “..\”.

Our next example of a “pass-through” bug is in the use of a common Java logging library:

Log4J Javascript Injection

The most commonly used Java logging library is Log4J from Apache.  Log4J provides a number of different methods that write data to a log file,  for example:

Logger log = Logger.getLogger("mylogger");
log.error("This is an error message");
log.warn("This is a warning message");
log.debug("This is a debug message");

Log4J does not do any sanitization of strings passed in to it by the various logging methods, it simply takes the string it is given and writes this directly to the log file.

Most web applications that use Log4J will commonly include user-supplied values in at least some of their logging messages, for example:


protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
// do stuff, then on error something like:
Logger logger = Logger.getLogger("GetLogger");
logger.error( "Invalid value for parameter fnord: "+ request.getParameter("fnord"));
}

This makes some kind of sense – an error condition has been caused by invalid input, so the developer wants to see what the bad input was.

Web developers are also in the habit of viewing their web application log files directly from the web server, sometimes they even include HTML formatting tags in with their calls to Log4J methods so that the logs will be formatted nicely in the browser.

Imagine the following common scenario:

• The production web server is on the domain http://somesite.com and the QA server is on http://qa.somesite.com.
• Developers working on the QA server routinely view the Log4J logs through the browser by visiting http://qa.somesite.com/logs/mylog.
• The subdomain www.somesite.com redirects to somesite.com, so all of the regular sites domain cookies are for somesite.com.

Now we construct a standard Cross-Site Scripting cookie-stealing attack by injecting some Javascript into the “fnord” parameter mentioned above.  The program will then save this Javascript into the Log4J logs.

When the developer opens these logs in the browser, the Javascript will execute, and have access to the cookies for the domain qa.somesite.com.

However, the situation is much worse than this.  There is a single exception to the Same Origin Policy which happens to apply to this situation.

A Javascript can set its effective domain by manipulating the “document.domain” variable.  The exception to the Same Origin Policy says that a script can only set its domain to a suffix of its current domain.

This means that an attack script that runs from qa.somesite.com can reset its domain to somesite.com, and then access all of somesite.com‘s cookies!

A successful log-file script injection on a QA, development, or staging server which is a subdomain can result in stealing saved credentials from developers for the main domain!

This category of attacks passes directly through Java into a log file, which is then loaded by a browser.

To find these types of errors, look for calls to Log4J or similar logging functions which include HTML formatting tags and/or unsanitized user input.

Stay tuned for the second exciting installment of “How to Win at Java Code Audit”, including LDAP injection, Null Byte Injection, and ORM injection!

Dehydra is a GCC plugin that allows you to write Javascript that can perform queries on the Abstract Syntax Tree (AST) that GCC generates from source files.  This lets you write a script that can notify you when it sees any type of code construct that you can describe in script.

There are a number of code constructs that might be interesting to a code auditor, for example:

• Calls to asnprintf, malloc, or calloc with unchecked return values.
• Assignment operations where the datatype of the Left Hand Side is signed and the Right Hand Side is unsigned, or vice versa.
• Assignment operations where the datatypes of both sides have different bit-lengths.

The possibilities are much greater than my short list of examples!

I will be the first to admit that static analysis has its faults.  For one thing, it has been proven that static analysis cannot discover all possible bugs in any given program.  Commercial static analysis tools, such as Coverity, are expensive and have not proven to be a particularly effective method of finding bugs by themselves.  I have heard many accounts of nasty bugs discovered by code auditors when looking through source code routinely scanned by Coverity.

That said, on Day One of a code audit, 4 out of 5 code auditors find themselves reaching for Grep.

Grep is great, it lets you search for regular expressions across many files very quickly, but Grep has no awareness of the syntax of the C++ programming language.  I’m really more interested in searching for specific code constructs and less interested in searching for substrings, which is Grep’s purpose.

When looking for vulnerabilities, I’m not interested in searching for the string “malloc”.  What I really want to know is more along the lines of “Where are all the calls to malloc where the return value is not checked”.  I don’t want to know all the locations of the string “int” as much as I want to know every location that a variable of type int is implicitly cast to an unsigned int when passed in as a function argument.

This is the great thing about Dehydra.  It lets you query the parsed syntax tree of C++ source code and ask the kinds of questions that can’t be easily answered by Grep.

Scripts for Dehydra are written in Javascript by way of the SpiderMonkey engine.  Javascript is a nice, small language that is good for operations on tree-like data structures.  In a browser, this would mean the DOM, but in GCC this means the AST!

Dehydra is still in development, but the developers have been extremely responsive to feature requests from security auditors ( well, mine anyway… *grin* ).

It would be great to see a bunch of people contribute scripts and build a big set of security scanning scripts to replace the venerable regular-expression-based FlawFinder as the king of no-budget security-oriented static analysis.

Try it out and get back to me.

Setup and Installation Instructions for Dehydra on Linux or OSX

I’ve included a sample Dehydra script below that logs a message anytime it sees certain assignment operations.

The full sample script, along with a test file, is available here.

function assignVisitor(node) {
   for(var i in node.statements) {
      var loc = node.loc
      var lhs = node.statements[i].type
      var rhs = node.statements[i].assign
 
      if( rhs && lhs ) {
         if( lhs.unsigned ) {
            if(parseInt(rhs[0].value) > 0) {
               print( "ASSIGN: negative to unsigned at:"+loc+"\n" )
            }
            else if(rhs[0].type && !rhs[0].type.unsigned) {
               print( "ASSIGN: signed to unsigned at:"+loc+"\n" )
            }
         }
         else if(rhs[0].type) {// lhs is signed
            if( rhs[0].type.unsigned ) {
               print( "ASSIGN: unsigned to signed at:"+loc+"\n" );
            }
         }
      }
   }
}
 
function process_function(decl,body) {
   iter(assignVisitor, body)
}

I don’t know about the rest of you, but I have an entire room of my house which is simply a huge pile of electronics scrap.  A hacked Tivo, some chipped XBoxes, an old VCR, a pile of PCI video cards, a full shoebox of 64MB Compact Flash cards…  You get the idea.

One day, I decided to put some of this junk to good use and I wandered into the scrap heap looking for inspiration.

Inspiration came in the form of an Atheros wireless card and an old ITX barebones system that had been picked up from a junk table at DefCon for $60 the year before.  The ITX box has a single PCI slot, perfect for a decent Atheros wireless card with an external SMC antenna connector.  It also runs on 12V DC power, so I can run it off the car battery.

Over the next few weeks, I built a small embedded Linux system for the sole purpose of cracking WEP keys.

First, I added a USB wireless network card to use as a control interface that I could access from my iPhone.

I also built a small web service that completely automates the process using the Python web framework TurboGears, aircrack-ng, and screen.

The web interface is incredibly simple – it uses only a single combo box.  This makes it ideal for using from the iPhone.

Now, instead of being the sketchy guy sitting in my car with a laptop, I’m just another Seattle-ite staring into my iPhone while the computer doing the WEP cracking is running off my car battery halfway down the block.

Everything in the web interface is fire-and-forget.  You can view a list of available networks, select one for cracking, and it will automatically:

1. Reconfigure the wireless interface to the correct channel
2. Begin dumping packets with airodump-ng in a screen session
3. Begin an ARP replay attack with aireplay-ng in a screen session
4. Automatically kick off the actual WEP cracking by starting aircrack-ng in a screen session
5. Once the crack has succeeded, save the ESSID, BSSID, and cracked WEP key in a SQLite database

Since each of the aircrack-ng tools are running in a separate screen session, you can disconnect from the control interface as soon as the crack starts.  You can also reconnect at any time during the crack and view each screen session separately.

When close enough to a target for the ARP replay attack to work, this script averages only 3 minutes to crack a WEP key.  This is on an ITX box with a wimpy Cyrix C3 processor with only 256MB of RAM!

My scripts and installation instructions available here.

Update:

I have ported these scripts to the EEE pc (I use Ubuntu Netbook Remix on a 900A), available here.

However, I can’t get airodump-ng to actually capture any packets!  I believe this is a problem with my madwifi driver, but I haven’t sorted it out yet.  Hopefully, if I post the scripts one of you can help me out

Another Update (October 2010):

Hello Hackaday!  Since writing this initial version, I’ve since learned a lot about Python job control.  Check out the Jabbercracky project, also on this site.  I’m planning on a much-improved version of Groo, using what I’ve learned from Jabbercracky, which will also add some new tricks, including some available WPA cracks.  I’d also like to improve the installer, and to also provide builds for Ubiquiti networks hardware.  If anyone is interested in helping out, please email me at awgh at awgh dot org.

Stay tuned…

I have noticed a Cross-Site Scripting vulnerability in the way Internet Explorer handles the downloading and opening of HTML files when they are downloaded as an attachment, rather than opened normally. This vulnerability exists in all versions of Internet Explorer, including the latest patch level of IE7 as of 12/23/08.

This vulnerability related to sites serving user-submitted HTML files with “Content-Disposition: attachment”.

When directly opening a downloaded HTML file, Internet Explorer violates the Same Origin Policy by allowing any script inside the downloaded file to access the cookies of the site the file was downloaded from. This script should be restricted to running in a local context, not a domain context.

Firefox exhibits better behavior by first downloading the HTML attachment and then opening it with a file:// URL. When scripts in the downloaded HTML file are executed, they are treated as if run from a local file, not as if run from the domain the file was downloaded from, and they cannot access the source domain’s cookies.

This vulnerability would allow an attacker to execute a Cross-Site Scripting attack on a site that allowed uploading file attachments. An HTML file could be uploaded containing malicious script that could steal user credentials or forge user actions on the site (if downloaded and opened by an IE user).

I have created a screencast reproducing the incorrect behavior in Internet Explorer as well as the correct behavior in Firefox. Additionally, I’ve set up a downloadable HTML file that you can use to reproduce the issue yourself!

The screencast and example are available at: http://www.awgh.org/iebug

Microsoft has addressed this issue in IE8, but their solution leaves me with some questions.  The write-up in their development blog is here, skip down to the section titled “MIME-Handling: Force Save”.  This section acknowledges that this is a potential vector for script injection in IE and describes the solution as implemented in IE8.

The solution in IE8:

The web server can set the response header “X-Download-Options” to the value “noopen”.  This will tell Internet Explorer to only offer the option to save the file or cancel.  It simply removes the “Open” option when this option is set.

I see two problems with this solution.  First, call me a pessimist, but I can see someone actually disabling “noopen” simply to bring back the “Open” dialog option.

Second, I doubt that most web server admins are going to be worried enough about this issue to remember to set this header, or even know they should do it.  It’s a bit of an esoteric bug – it only affects sites that serve untrusted HTML with “Content-Disposition: attachment”.  Even if Microsoft web servers set “noopen” by default, I doubt that most LAMP admins will bother adding this to their server options.

Why force the server to fix this problem?  Why not treat the “Open” option the same way Firefox does, by first downloading the file, then opening it with only a local script context?

This method of script injection will continue to work in Internet Explorer 8, as long as the site has not set the “X-Download-Options” header to “noopen”.

So the moral of the story:  If you are the admin of a site that serves untrusted HTML files with “Content-Disposition: attachment” set, please make sure the “X-Download-Options” header is set to “noopen”.

The ‘Forgot Password’ page exists solely to help unauthenticated users bypass the usual means of authentication.

For whatever reason, many developers overlook the importance of locking this down, even after the issue of too-easily-guessable questions in Yahoo’s ‘Forgot Password’ procedure got a lot of media attention during the US presidential campaign after Gov. Palin’s webmail was hacked.

Even if the questions were based on specific preferences and more difficult to guess, very few sites will check for brute-force attempts on the ‘Forgot Password’ page, even though protections against brute-forcing have often been implemented in the more prestigious login page.

One other recommendation I usually make is the banning of email addresses from Mailinator, Slopsbox, and similar anonymous email services in registration.

If you’re not familiar with Mailinator, it’s an email server which displays ALL received emails to anyone who visits their web site.  Say you were registering for some web site and they asked for an address to send the validation email to.  You can just enter any email address at Mailinator, for example asdf@mailinator.com, and then go to www.mailinator.com and read the response.  This is great for not having to give out your real email.

What this means, however, is that I can simply go to the ‘Forgot Password’ page, which usually requires only an email address, enter asdf@mailinator.com, and a password reset email will be sent to Mailinator where I can collect it anonymously.  Any user account on any web service which was registered to a Mailinator email address can be compromised simply by guessing the email address.

Here’s where the brute-forcing comes in.  Since most sites let you make as many guesses on the ‘Forgot Password’ page as you’d like, there is nothing stopping an attacker from simply guessing email addresses at full tilt.

To demonstrate the effectiveness of this technique, I’ve written two example scripts, called the Mailinator-nator, which are available here.

The first script is called forgot-pwd-force.py, this script does the following:
1) Brute forces ‘Forgot Password’ forms that only require email addresses on a hardcoded list of sites, using a wordlist of usernames.
2) For each username, tries each of the Mailinator domain aliases (Mailinator has a number of different domain names that point to the same place).

The second script is called mailinator-scan.py, this script does the following:
1) Reads a wordlist of usernames from a file.
2) For each username, connects to Mailinator and logs all emails to that user which contain the word ‘password’.

To use these two together, first add your target sites to forgot-pwd-force.py.  You can use one of my included wordlists or make your own, just be sure to use the same wordlist for both scripts.

Next, run the first script to force the target site to generate password reset emails to Mailinator addresses.

Wait a few minutes, and then run the second script to collect all of the return emails from the Mailinator server.

The second script can also be run as a cron job, which lets you troll Mailinator for password reset emails that you did not trigger yourself!  Mailinator deletes all received emails within an hour or two, so you may have to tinker with it to find a good interval.

I love Mailinator, so I checked and this doesn’t seem to violate their terms of service.  Looking at their site, they don’t seem to have terms of service!  This makes some kind of sense, since all users to the site are anonymous.  That said, actually logging in to a web site with a password recovered in this way is probably illegal in most jurisdictions so don’t do it.

As a site developer, what can you do to prevent these kinds of problems?

1) Ban registration emails to Mailinator and all of its domain aliases.

2) After 10 or so failed attempts to guess an answer on the ‘Forgot Password’ page, ban the IP for 5-15 minutes.

3) Require more than just the email address to send a password reset email.  Consider at least two factors: email address AND one security question.

These three measures will protect your ‘Forgot Password’ page from brute-forcing and dictionary attacks, as well as protecting your users from having their accounts stolen.

As a user of Mailinator, you can reduce your exposure to this risk by making use of the ‘Delete This Email’ feature of Mailinator and by using a long, difficult to guess user name.

The admin in this story made the same mistake that many people do when thinking about their computer – he assumed that all user-modifiable executable code is only stored on the hard drive.

This story is at least 10 years old, and I’ve heard it in various different forms, but the technological culprit was certainly a BIOS-based rootkit.  A BIOS-based rootkit can hide in one of two places: either embedded in the BIOS itself or in a PCI Option ROM.  As part of BIOS start-up, it will load executable code from a special ROM chip on each PCI device and execute this code with Ring 0 privileges, meaning the code can control absolutely anything the computer can do.  PCI Option ROMs are intended to let peripheral developers include some driver code that it wants to be run at BIOS execution time.  This code needs Ring 0 access, because it might need to interact directly with the ICs on the PCI device itself.  This is a feature, not a bug.

Delivering a BIOS-based rootkit is a bit more complicated than a traditional rootkit.  There are two methods for this.  The first involves gaining root privileges on the target machine by some means and flashing a new BIOS using SPI or tools provided by the motherboard manufacturer.  If your rootkit goes on a PCI Option ROM, you can also flash those with root access.  Many devices can also be reflashed over the network via PXE.  Most PCI cards have read-only Option ROMs, so this will only work for high-end network cards, video cards, or any other kind of PCI device that touts upgradeable firmware.

The second method is more interesting, and involves physically accessing the hardware, installing the rootkit, and then selling or giving the modified hardware to the intended victim.  A variation on this would be perhaps simply leaving a stack of shrink-wrapped network cards in the hallway outside a system administrators office with a Post-It saying “For IT”.  An advantage of this method is that you can flash the Option ROMs using a proper EEPROM programmer, so you can alter PCI cards that could not be altered using a software tool.  There can be several different Option ROM data segments on one physical chip, so you don’t necessarily have to stomp the existing driver code – you can just add another segment.

In the old BIOS standard, now referred to as Legacy BIOS, doing anything useful in a BIOS-based rootkit took an insane amount of time and skill.  Since BIOS runs before the operating system comes up, a rootkit developer would have no access to system libraries, filesystem drivers, or a network stack.  If the rootkit needed any of these features, the developer would have to write everything from scratch and interact with all of the involved chips at the lowest level (try to do TCP with only peeks and pokes using numbers gleaned from blueprints of chips, in short: HARD-FREAKING-CORE).

That was the past.

In 2009, AMD will start shipping EFI-compatable chipsets by default.  Intel, the main proponent of EFI, has been using it in the Itanium series, but will be using it in just about everything by the end of 2009.  Apple has already been using EFI in all of their Intel Macs since 2006.

This will spell the end of Legacy BIOS.  Most will say good riddance.

EFI has a couple of shiny new advantages.  The main reason that EFI was developed in the first place was to overcome several limitations of Legacy BIOS, including the use of 16-bit processor mode and having only one megabyte of addressable space.

As EFI has been developed over the years, it’s turned into something slightly different.  Intel has open-sourced almost all of a firmware development kit called the EFI Developer Kit or EDK, available here.

The EDK includes a large amount of sample code as well as a large set of utility libraries, all written in straight C.  The utility libraries include a variety of networking functions, including an optional full TCP/IP stack, as well as filesystem access libraries for FAT and NTFS.

Although the EDK doesn’t come with everything required to build a complete firmware, it does come with enough to build the two items of interest to an attacker: PCI Option ROMs and EFI Modules.  EFI Modules are distinct modules of firmware code that can be easily combined with each other to produce a firmware.  If you’ve ever installed the rEFIt boot menu for Intel Macs, you’ve flashed an EFI module into your BIOS.

All of these new features are designed to make life easier for firmware developers, and they do.  They also make life easier for attackers who wish to use EFI for evil.  Now, you can write a rootkit in C instead of assembler, and you can make use of pre-made network and file system libraries.

The only trick remaining is how to keep your rootkit running once BIOS execution has ended and the operating system is running.  There are a few methods available.  The easiest, and lamest, method is to simply write rootkit code out to the hard drive at every boot.  Cooler than that is using Intel’s System Management Mode (SMM) or ACPI event handlers to stash code to log keystrokes and then send it out on the network.  I have yet to see a working demo of this, and I’m told that a successful implementation requires specific knowledge of the Southbridge chip on a specifically targeted motherboard.

Update:  From talking to people at 25c3, I’ve learned that setting up a keystroke logger for just PS2 keyboards is pretty easy.  According to Peter Stuge of coreboot, to capture PS2 keystrokes you can use SMM to trap reads from io port 60, which is guaranteed to be the same on all platforms.  When the SMM trap triggers, it can run code you set up from, say, an Option ROM earlier.  There are examples of the use of SMM in the coreboot source!

There is also a common misconception that TPMs somehow prevent malicious PCI Option ROMs, but this isn’t so.

Apparently capturing USB keyboard keystrokes would be quite a bit more difficult.  Once I get PS2 working maybe…

I’d like to share two things with all of you.  The first is a dark, personal secret.  The second is a toy I made.

The secret is that for the past few months I have been harboring an unhealthy obsession with the Japanese television series ‘Ghost in the Shell: Standalone Complex.’

What I love about this show the most is one of the recurring bad guys, an impossibly-skilled hacker called the Laughing Man who exhibits a number of extremely bad-ass qualities.

First and foremost, he can hack in to people’s minds and control them.  In the show, he uses this to carry out a series of political assassinations.

During these attacks, he also simultaneously hacks in to all security cameras and news feeds in the surrounding area, and blocks out the face of the person he’s currently controlling with a custom graphic.

This graphic is a smiley face with a baseball cap and a quote from Catcher in the Rye: “I thought what I’d do was, I’d pretend I was one of those deaf-mutes…”

Watching this show the other day, I suddenly realized that I could write a program that did face detection and substitution quite easily.  Once I realized I could do it, I had to.

So I quickly whipped up a program in Processing that does the following:

1)  Opens up a video camera (for example, the web cam in your MacBook).

2) Finds all faces in the frame using the OpenCV library for Processing (installation instructions here).

3) Replaces all faces with the Laughing Man graphic, borrowed from elmex over at ta-sa.org.

Try it out yourself!  It’s minutes of fun for the whole family.  Also, it could be useful in case you ever find yourself in control of some kind of video feed.

The hack-in-to-your-mind thing will have to wait for the time being…

Once you’ve got Processing and OpenCV for Processing installed, download laugh-0.2.tgz.

Update: I’ve merged in changes from the comments!  Text now rotates and the image scales!  Thanks to Josh, Brett, and Deltadesu!