Tuesday, September 25, 2012

Carving BUPs By Hand

By Tony Lee.

We released a couple of tools aimed at reversing a McAfee Quarantined BUP file in the previous article titled: UnBup – McAfee BUP Extractor for Linux. However, we recently ran into a strange BUP that could not be dissected with our tool. This article outlines the strange behavior we saw and the steps used to overcome the issue.

The Problem

While investigating a Global Threat Intelligence (GTI) hit, we wanted to break down the binary—thus we tried to use our trusty tool provided in the UnBup blog. However, the tool threw the following error which we had never been seen before:
 [root@localhost folder]# ./UnBup.pl 1234567890abcdef.bup
Extracting encoded files from Bup
Creating the Details.txt file
cut: option requires an argument -- f
Try `cut --help' for more information.
Extracting the binary
Input file "File_0" does not exist

We checked the size of the Details file (which is used to create the Details.txt file) that was extracted by our UnBup tool. To our surprise it was 0 bytes:
 [root@localhost folder]# ls -al Details*
-rw-r--r-- 1 root root 0 Aug 21 15:03 Details
-rw-r--r-- 1 root root 0 Aug 22 07:54 Details.txt

The first assumption was that there is something wrong with the UnBup tool, so we tried to decompress the file manually with 7zip:
 root@localhost folder]# 7z e 1234567890abcdef.bup
7-Zip 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Processing archive: 1234567890abcdef.bup
Extracting  Details
Everything is Ok
Size:       0   <--  Whoa...
Compressed: 49152

To our surprise, 7zip also had a problem decompressing the file. It extracted the Details file, but it was 0 bytes. Our guess as of right now is that the file is malformed and not a readable Microsoft Compound Document Format. It will be necessary to dig deeper on this issue later—but it would be interesting to see if anyone else has experienced this same problem. In the meantime, we still needed to analyze the binary.

Preliminary Analysis

Since we still needed to investigate the detection we decided to pull the BUP apart manually; First, we performed a quick preliminary analysis, then extracted the Details.txt file out and finally the suspicious file.

In order to take a quick glance at the BUP, you might be tempted to try a hexdump –C “BUP_Name”, but remember this file is xor’d.

Reviewing the binary operation XOR from the previous article, a truth table is provided below:

To decode the file, you could use our xor.pl script that we posted in the UnBup tool blog post. You can find our code here: https://github.com/OpenSecurityResearch/unbup/blob/master/xor.pl

Now XOR the BUP:
 [root@localhost folder]# ./xor.pl
Simple xor script
  Usage: ./xor.pl <Input File> <Output File>
[root@localhost folder]# ./xor.pl 1234567890abcdef.bup 1234567890abcdef.xor

Now you can use hexdump –C on the .xor file that you created. Notice that you can read the Details.txt and the start of the suspected file. You will have multiple streams within one file – hence the premise behind Microsoft’s Compound Document Format. As ugly as it is, you can glean lots of information from this view. You can also use strings on the file in order to pull out the text from the Details file as well as the strings from the binary in one shot. Below are snippets from the xor file. Notice that the top portion is the file header, the middle portion is the details section, and the last portion is the suspected malicious file:

 hexdump -C 1234567890abcdef.xor | less

00000000  ba a5 7b 8a cb db 70 8b  6a 6a 6a 6a 6a 6a 6a 6a  |..{...p.jjjjjjjj|
000005c0  6a 6a 6a 6a 95 95 95 95  95 95 95 95 95 95 95 95  |jjjj............|
000005d0  6a 6a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |jjjjjjjjjjjjjjjj|

00000800  0d 0a 5b 44 65 74 61 69  6c 73 5d 0d 0a 44 65 74  |..[Details]..Det|
00000810  65 63 74 69 6f 6e 4e 61  6d 65 3d 41 72 74 65 6d  |ectionName=Artem|
00000d40  31 5d 0d 0a 4f 62 6a 65  63 74 54 79 70 65 3d 35  |1]..ObjectType=5|
00000d50  0d 0a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |..jjjjjjjjjjjjjj|
00000d60  6a 6a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |jjjjjjjjjjjjjjjj|

00000e00  4d 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |MZ..............|
00000e10  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000e20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000e30  00 00 00 00 00 00 00 00  00 00 00 00 d0 00 00 00  |................|
00000e40  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 54 68  |........!..L.!Th|
00000e50  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
00000e60  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |

Extracting the Details

If we still want the actual Details.txt file, we will need to work a little bit for this. We can use DD to carve it out of this file, but first we need to know three things:
  1. Starting address of the Details section
  2. Ending address of the Details section
  3. The length of the Details section (#2 - #1)

Find where Details starts: Using hexdump –C. and look for 0d 0a 5b 44 or “..[D”. Note the hex offset to the left side. In our example, it is 0x800:
 hexdump -C 1234567890abcdef.xor | less

000005c0  6a 6a 6a 6a 95 95 95 95  95 95 95 95 95 95 95 95  |jjjj............|
000005d0  6a 6a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |jjjjjjjjjjjjjjjj|
00000800  0d 0a 5b 44 65 74 61 69  6c 73 5d 0d 0a 44 65 74  |..[Details]..Det|
00000810  65 63 74 69 6f 6e 4e 61  6d 65 3d 41 72 74 65 6d  |ectionName=Artem|

Now look for where Details ends: Using hexdump –C, try to find where the ASCII text ends (hint: look for 0d 0a which is carriage return (CR) and line feed (LF) respectively just before the next section MZ in our case). In our example, it is 0xd51 as shown below:
 hexdump -C 1234567890abcdef.xor | less

00000d40 31 5d 0d 0a 4f 62 6a 65 63 74 54 79 70 65 3d 35 |1]..ObjectType=5|
00000d50 0d 0a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a |..jjjjjjjjjjjjjj|
00000d60 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a |jjjjjjjjjjjjjjjj|
00000e00 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 |MZ..............|
00000e10 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |........@.......|
00000e20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000e30 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 00 00 |................|
00000e40 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 |........!..L.!Th|
00000e50 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f |is program canno|
00000e60 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 |t be run in DOS |

To find the length of the Details section we can use a "Programming" calculator that understands hex – For example, calc.exe -> View -> Programmer:
 0xd51 - 0x800 = = 0x551 + 1 = 0x522 = 1,362 bytes (decimal)

It is finally time to extract the Details section into Details.txt
 Start of Details.txt = 0x800 = 2,048 (decimal)
Length of Details section = 0x522 = 1,362 (decimal)

You will use the dd command for extraction and the .xor file we created as input. Plug the starting address of the Details section into the skip parameter and the length of the section into the count parameter.
 dd if=1234567890abcdef.xor bs=1 skip=2048 count=1362 of=Details.txt

[root@localhost folder]# file Details.txt
Details.txt: ASCII text, with CRLF line terminators

Extracting the suspicious file

Now we want to extract the suspicious file. We will need to know where the suspicious file begins. Assuming that is an executable which it was in our case—it will start with MZ. Use trusty hexdump to find the offset:
 hexdump -C 1234567890abcdef.xor | less
00000d40  31 5d 0d 0a 4f 62 6a 65  63 74 54 79 70 65 3d 35  |1]..ObjectType=5|
00000d50  0d 0a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |..jjjjjjjjjjjjjj|
00000d60  6a 6a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |jjjjjjjjjjjjjjjj|
00000e00  4d 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |MZ..............|
00000e10  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000e20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000e30  00 00 00 00 00 00 00 00  00 00 00 00 d0 00 00 00  |................|
00000e40  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 54 68  |........!..L.!Th|
00000e50  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
00000e60  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |

In our case, the binary starts at 0xe00 which is 3,584 bytes into the xor’d file. Use dd to carve out the original binary by skipping that number of bytes:
 [root@localhost folder]# dd if=1234567890abcdef.xor bs=1 skip=3584 of=orig.exe
45568+0 records in
45568+0 records out
45568 bytes (46 kB) copied, 0.718273 seconds, 63.4 kB/s

[root@localhost folder]# file orig.exe
orig.exe: PE32 executable for MS Windows (native) Intel 80386 32-bit

In our case, we were able to compare the MD5 hash with the original Artemis name to prove that this is an exact match. Now you can strings the binary or drop it into Olly, IDA, or Immunity and have some fun!


One thing that made this analysis and manual breakdown “easy” is that both the description and suspicious file were relatively short and did not break across multiple streams. Since large files are often broken up in the xor’d BUP (Microsoft Compound Document Format), you will have to account for these gaps if processing anything that is split.

Feel free to post back—we would be interested to see if anyone else has run into this situation.

Tuesday, September 18, 2012

Simple Cross Site Scripting Vector That Webkit XSS Auditor Ignores

By Tushar Dalvi.

Google Chrome has a lesser known feature named “XSSAuditor” that was added to help mitigate reflective XSS. Its contained as a part of the Webkit and works very similarly to NoScript and XSS filter in Internet Explorer 8 and above.

The Chromium Blog’s security features page describes the behavior of XSSAuditor as:
“The XSS filter is similar to those found in Internet Explorer 8 and NoScript. Instead of being layered on top of the browser like those filters, our XSS filter is integrated into WebKit, which Google Chrome uses to render webpages. Integrating the XSS filter into the rendering engine has two benefits: (1) the filter can catch scripts right before they are executed, making it easier to detect some tricky attack variations, and (2) the filter can be used by every WebKit-based browser, including Safari and Epiphany”

How it works

XSSAuditor works by taking note of the user-provided input when a web page is requested and then evaluating it before the page is rendered. The user-provided input is first inspected to identify if it contains malicious input, and if it does, XSSAuditor blocks it.

XSSAuditor also tracks where the user input is reflected in the rendered page. Every HTML page contains elements that fall into one of the 5 output contexts: HTML entity, HTML attribute, JavaScript, CSS, and URL. Since output contexts have different structures and formatting, XSSAuditor evaluates the context the user input falls within and then sanitizes it appropriately for that context.

Sounds good right? Well, maybe - now that we have an idea what XSSAuditor does and how it works. Let's look at where it fails!

Bypassing XSSAuditor

The problem is that XSSAuditor only checks for the escape sequences that apply to the HTML entity and HTML attribute output contexts, but not the others! This means if a XSS vulnerability is present within the JavaScript context (a very common occurrence), then XSSAuditor only checks it for known malicious input and as long as it doesn't match, the XSS gets executed.

Lets look a simple case where this might happen. Consider the following code:
 <html><head><title>Test Page</title></head>
var foo = "<%= request.getParameter("foo") %>";
document.write("<text>Welcome "+ foo + "</text>");

This is a classic XSS example. If we direct our browser to http://www.domain.com/test.jsp?foo=2"; alert(document.cookie); var a="1 our JavaScript is executed:

Wait - that shouldn't happen - and this is with Google Chrome version 22.0.1229.12

Browser Results

The same URL was tested against different browsers which implement similar filters to block XSS attacks. The following observations were made:

  • Internet Explorer 8.0 with XSS filter enabled, detected and blocked the attack.
  • Mozilla Firefox 14.0.1 with Noscript 2.4.8, detected and blocked the attack.
  • Safari 5.1.7, failed to detect the attack and executed the script. (This is because Safari and Google Chrome contain the same implementation of XSS Auditor)

This bug affects all versions of Google Chrome (4 and above), Safari (5.1.7, lower versions not tested yet) on all platforms and was reported to Webkit Bugzilla (https://bugs.webkit.org/show_bug.cgi?id=92692) on 07/30/2012.

Tuesday, September 11, 2012

Getting Started With LORCON

By Brad Antoniewicz.

Loss Of Radio CONnectivity (LORCON) is an IEEE 802.11 packet injection library. It was originally created by Joshua Wright and Michael Kershaw ("dragorn") - I think Johnny Cache was an early contributor as well. As of now, dragorn maintains it, however it doesn't seem that there have been many updates in the last year or so.

One of the biggest issues in wireless tool development was that tools needed to be driver-specific, so if the author didn't take into account a specific driver, the tool didn't work. Additionally, many tools implemented their own functions for packet capture and injection, resulting in lots of code duplication. These issues were first brought up in a talk called "The Need for an 802.11 Wireless Toolkit" by Mike Schiffman at Blackhat in 2002. Schiffman released a proof of concept library called "libradiate" which offered a solution to these problems. Unfortunately libradiate fell off the edge of the earth and wireless hackers everywhere found themselves in a deep void surrounded by sadness. A few years later, in 2007, LORCON emerged. It eased development issues by creating standard function calls for injection and capture, and added a layer of abstraction such that tool developers wouldn't need to worry about the wireless driver or adapter in use.

There have been two major releases: LORCON (defunct) and LORCON2 (current). We'll use the terms LORCON and LORCON2 interchangeably throughout this post when referring to the current version. LORCON2 supports the Linux mac80211 wireless drivers. The release also includes a Ruby extension to facilitate Ruby development.

Although LORCON hasn't been updated all to often, it still works well, is extremely powerful, and is very easy to use. For whatever reason, people seem to have forgotten about it, so this post will hopefully kick everyone in the butt and provide a quick intro into using the library.

Installation and Setup

As usual, I'll be using BackTrack (BT5R3 to be specific) as my Linux distribution, and I've created a couple of code examples and patches which can be found on github repo here:

The first step is to clone the the repo:
 root@bt:~# git clone https://github.com/OpenSecurityResearch/lorcon_examples.git

Core Installation

LORCON has supposedly been moved from its original location (http://802.11ninja.net/) to a fancy new Google Code repo (https://code.google.com/p/lorcon/), however I noticed the Google Code version doesn't include the packet forging functionality that I think is really useful, so we'll stick to the older release for the sake of this article.

I made a couple of small changes to make the packet forging functionality work and enable a couple of other useful functions. The handful of changes are summed up in this patch. Overall, the installation is pretty basic:

 root@bt:~# apt-get update
 root@bt:~# apt-get upgrade
 root@bt:~# apt-get install libnl-dev
 root@bt:~# svn co http://802.11ninja.net/svn/lorcon/trunk lorcon2
 root@bt:~# cd lorcon2
 root@bt:~/lorcon2# patch -p1 < ../lorcon_examples/lorcon.patch
 root@bt:~/lorcon2# ./configure --prefix=/usr
 root@bt:~/lorcon2# make depend
 root@bt:~/lorcon2# make
 root@bt:~/lorcon2# make install

Ruby Installation

In a previous blog post Robert Portvliet detailed how to handle LORCON's Ruby extensions on BT5R2, specifically for Metasploit integration. That article details most of the specifics, so I'll just repeat the major points here for completeness. Note that the lorcon.patch includes the STR2CSTR() fixes.

To install:

 root@bt:~# cd lorcon2/ruby-lorcon/
 root@bt:~/lorcon2/ruby-lorcon# ruby extconf.rb
 root@bt:~/lorcon2/ruby-lorcon# make
 root@bt:~/lorcon2/ruby-lorcon# make install

Then to test:

 root@bt:~/lorcon2/ruby-lorcon# ruby test.rb wlan1
Checking LORCON version

Fetching LORCON driver list
   "description"=>"Linux madwifi-ng drivers, deprecated by ath5k and ath9k"},
  {"name"=>"tuntap", "description"=>"Linux tuntap virtual interface drivers"},
    "Linux mac80211 kernel drivers, includes all in-kernel drivers on modern systems"}}

Resolving driver by name 'mac80211'
  "Linux mac80211 kernel drivers, includes all in-kernel drivers on modern systems"}

Auto-detecting driver for interface wlan0
  "Linux mac80211 kernel drivers, includes all in-kernel drivers on modern systems"}

Created LORCON context

Opened as INJMON: wlan1mon

Channel: 11

Python Bindings

There are actually two projects that extend LORCON into the Python world:

  • pylorcon - Based on its change history, this project was the first, starting in 2007. pylorcon started out with a Google Code page which now redirects users to a GitHub repository. Looking at its source, the Google Code page appears to be written to support LORCON1 while the github page supports LORCON2. The GitHub repository is titled "pylorcon2" which confusingly enough, is the same name as the second project that extends LORCON2 to python.

  • pylorcon2 - In 2010 a couple of guys from Core Security created pylorcon2. This project consists mainly of a Google Code Page. It supports all of the basic functionality of LORCON2, but doesn't support advanced functions such as capture loops.

For the purpose of this article, I'll use the Google Code pylorcon2. Although the GitHub pylorcon2 actually has more functionality, I stumbled upon the Google Code one first and so I've grown more comfortable with it. If you have a good reason to choose one over the other, please let me know in the comments below.

To install:

 root@bt:~# apt-get update
 root@bt:~# apt-get upgrade
 root@bt:~# apt-get install libnl-dev
 root@bt:~# wget http://pylorcon2.googlecode.com/files/PyLorcon2-0.1.tar.gz
 root@bt:~# tar -zxvf PyLorcon2-0.1.tar.gz
 root@bt:~# cd PyLorcon2-0.1
 root@bt:~/PyLorcon2-0.1# python setup.py build
 root@bt:~/PyLorcon2-0.1# python setup.py install

If you try to use the test.py of the Google Code pylorcon2 it'll fail when trying to set the MAC address. Everything else works fine though, so you can either comment out the def testMAC(self) function or just ignore it. I haven't spent any time tracking down the root cause of the issue since it doesn't impact me much.

To test (with def testMAC(self) commented out):
 root@bt:~/PyLorcon2-0.1# python test.py
testAutoDriver (__main__.PyLorcon2TestCase) ... ok
testChannel (__main__.PyLorcon2TestCase) ... ok
testFindDriver (__main__.PyLorcon2TestCase) ... ok
testGetDriverName (__main__.PyLorcon2TestCase) ... ok
testGetVersion (__main__.PyLorcon2TestCase) ... ok
testInjection (__main__.PyLorcon2TestCase) ... ok
testListDrivers (__main__.PyLorcon2TestCase) ... ok
testTimeout (__main__.PyLorcon2TestCase) ... ok
testVap (__main__.PyLorcon2TestCase) ... ok

Ran 9 tests in 0.011s


Program Structure

The sample code I created within the lorcon_examples GitHub provides a couple of simple examples to get you started with LORCON. The code is broken up into blocks so that you can use them as templates to make your own packet injection tools. These examples all follow a basic structure, breaking the program up into three main blocks:

  1. Context setup
  2. Injection/Capture
  3. Context cleanup

Context setup

At the heart of LORCON is the "LORCON context" which is more or less representative of the wireless interface you're interacting with. The context adds a layer of abstraction between your program and the wireless driver. Instead of dealing with the driver directly, you deal with the context. This way your program doesn't need to worry about any driver specifics and thus can work with any drivers LORCON supports.

The context needs to be configured though. First LORCON needs to figure out what driver is being used. The lorcon_auto_driver() function automatically determines this based on the interface provided. Here's some example C code that determines the driver for a provided interface:
 // Automatically determine the driver of the interface
        if ( (driver = lorcon_auto_driver(interface)) == NULL) {
                printf("[!] Could not determine the driver for %s\n",interface);
                return -1;
        } else {
                printf("[+]\t Driver: %s\n",driver->name);

Now that we've determined the driver, we can set up the LORCON context. In C, the lorcon_create() function handles that for us:
 // Create LORCON context
        if ((context = lorcon_create(interface, driver)) == NULL) {
                printf("[!]\t Failed to create context");
                return -1;

Next we'll need to enable monitor mode on the interface using the lorcon_open_injmon() function. This creates a Monitor Mode VAP on the interface provided to handle monitoring and injection.
 // Create Monitor Mode Interface
        if (lorcon_open_injmon(context) < 0) {
                printf("[!]\t Could not create Monitor Mode interface!\n");
                return -1;
        } else {
                printf("[+]\t Monitor Mode VAP: %s\n",lorcon_get_vap(context));

Finally, we'll just need to set a specific channel to listen/transmit on with the lorcon_set_channel:
 // Set the channel we'll be injecting on
        lorcon_set_channel(context, channel);
        printf("[+]\t Using channel: %d\n\n",channel);


We'll focus specifically on injection for this article. Injection is handled with the lorcon_send_bytes() and lorcon_inject() functions. lorcon_send_bytes() is as basic as it gets, taking in a array of bytes and simply sending it:
 // Raw packet bytes (from capture_example.c included within LORCON)
        unsigned char packet[115] = {
        0x80, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, // dur ffff
        0xff, 0xff, 0x00, 0x0f, 0x66, 0xe3, 0xe4, 0x03,
        0x00, 0x0f, 0x66, 0xe3, 0xe4, 0x03, 0x00, 0x00, // 0x0000 - seq no.
        0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, // BSS timestamp
        0x64, 0x00, 0x11, 0x00, 0x00, 0x0f, 0x73, 0x6f,
        0x6d, 0x65, 0x74, 0x68, 0x69, 0x6e, 0x67, 0x63,
        0x6c, 0x65, 0x76, 0x65, 0x72, 0x01, 0x08, 0x82,
        0x84, 0x8b, 0x96, 0x24, 0x30, 0x48, 0x6c, 0x03,
        0x01, 0x01, 0x05, 0x04, 0x00, 0x01, 0x00, 0x00,
        0x2a, 0x01, 0x05, 0x2f, 0x01, 0x05, 0x32, 0x04,
        0x0c, 0x12, 0x18, 0x60, 0xdd, 0x05, 0x00, 0x10,
        0x18, 0x01, 0x01, 0xdd, 0x16, 0x00, 0x50, 0xf2,
        0x01, 0x01, 0x00, 0x00, 0x50, 0xf2, 0x02, 0x01,
        0x00, 0x00, 0x50, 0xf2, 0x02, 0x01, 0x00, 0x00,
        0x50, 0xf2, 0x02};

 // Send and exit if error
                if ( lorcon_send_bytes(context, sizeof(packet), packet) < 0 )
                        return -1;

The lorcon_inject() function requires the use of a lorcon_packet_t structure which contains the raw bytes plus a bunch of other information about the packet you're injecting. This comes in handy when you use LORCON's built-in packet forging capabilities which we'll talk about later on.

Context cleanup

Finally, once our program has completed, we'll just need to close the interface we've created, and free up the context using the lorcon_close() and lorcon_free() functions:
 // Close the interface

 // Free the LORCON Context

Your First Flooder

Using the examples, lets see what a basic beacon flooder looks like using LORCON.

Using C

beacon_flood_raw.c is broken up into the three main parts as described above. It leverages the lorcon_send_bytes() function to send the packet defined in the packet[] array. I've added a slight delay in between sending packets, and also some friendly output for the user.

To compile:
 root@bt:~/lorcon_examples# gcc -o beacon_flood_raw -lorcon2 beacon_flood_raw.c

To run:
 root@bt:~/lorcon_examples# ./beacon_flood_raw -i wlan1 -c 11

Using Python

beacon_flood_raw.py is pretty much the minor image of beacon_flood_raw.c but in Python - same output and all.

To run:
 root@bt:~/lorcon_examples# python beacon_flood_raw.py -i wlan1 -c 11

Using LORCON for Packet Creation

One feature that I absolutely love is the LORCON's packet forging capabilities. Rather than using a byte array for your frame, LORCON allows you to create a frame on the fly within a structure called a metapack. Once you've built your frame, you transform it into a lorcon_packet_t then send it using lorcon_inject(). There are a bunch of functions to create any type of frame you'd like:
  • lcpf_80211headers()
  • lcpf_80211ctrlheaders()
  • lcpf_qosheaders()
  • lcpf_beacon()
  • lcpf_add_ie()
  • lcpf_disassoc()
  • lcpf_probereq()
  • lcpf_proberesp()
  • lcpf_rts()
  • lcpf_deauth()
  • lcpf_authreq(()
  • lcpf_authresp()
  • lcpf_assocreq()
  • lcpf_assocresp()
  • lcpf_data()

Following our previous examples, lets create a beacon frame with lcpf_beacon() and add various Information Element(IE) tags to it with lcpf_add_ie():
 lcpa_metapack_t *metapack; // metapack for LORCON packet assembly
 lorcon_packet_t *txpack; // The raw packet to be sent

 // Initialize the LORCON metapack
 metapack = lcpa_init();

 // Create a Beacon frame from 00:DE:AD:BE:EF:00
 lcpf_beacon(metapack, mac, mac, 0x00, 0x00, 0x00, 0x00, timestamp, interval, capabilities);

 // Append IE Tag 0 for SSID
 lcpf_add_ie(metapack, 0, strlen(ssid),ssid);

 // Most of the following IE tags are not needed, but added here as examples

 // Append IE Tag 1 for rates
 lcpf_add_ie(metapack, 1, sizeof(rates)-1, rates);

 // Append IE Tag 3 for Channel
 lcpf_add_ie(metapack, 3, 1, &channel);

 // Append IE Tags 42/47 for ERP Info
 lcpf_add_ie(metapack, 42, 1, "\x05");
 lcpf_add_ie(metapack, 47, 1, "\x05");

Next we'll convert it to a LORCON packet (lorcon_packet_t):
 // Convert the LORCON metapack to a LORCON packet for sending
 txpack = (lorcon_packet_t *) lorcon_packet_from_lcpa(context, metapack);

and send:
 // Send and exit if error
 if ( lorcon_inject(context,txpack) < 0 )
            return -1;

To put the entire picture together, this is all shown in beacon_flood_lcpa.c.

To compile:
 root@bt:~/lorcon_examples# gcc -o beacon_flood_lcpa -lorcon2 beacon_flood_lcpa.c

To run:
 root@bt:~/lorcon_examples# ./beacon_flood_lcpa -s brad -i wlan1 -c 11


Now its your turn - try to take one of the examples and create a tool to de-authenticate users from an access point!

What do you use LORCON for? Let me know in the comments below!

Tuesday, September 4, 2012

Manually Exploiting Tomcat Manager

By Tony Lee.

Apache Tomcat is a very popular open source implementation for handling JavaServer Pages. However, Apache Tomcat is often deployed with default or weak credentials protecting the web accessible Tomcat Manager functionality. Tomcat Manager allows administrators (and attackers) to upload and publish Web application ARchive (WAR) files remotely.

A very common initial foothold for attackers is to take advantage of weak or default Tomcat Manager Credentials and use this to remotely deploy and execute a payload to gain a backdoor to the host.

Vulnerability scanners will pick up this particular finding as:

McAfee Vulnerability Manager (MVM): Tomcat Manager Default Or Blank Login Password
Nessus: Apache Tomcat Manager Common Administrative Credentials

The Metasploit exploit (tomcat_mgr_deploy) is the de facto exploit for this vulnerability and is usually rock solid, however I have seen a few occasions where it will fail with little-to-no explanation. Additionally, the host may have A/V or HIPS that catches the payload and it may be necessary to upload a custom binary or extra special treat manually instead of using MSF to deploy it. The information below is just one possible manual workaround if you don’t have the time to troubleshoot the issue.

Assess the situation

In my scenario:
  • Windows 7 (32-bit) development box
  • Default Tomcat manager credentials running on port 8081
  • UAC enabled
  • Tried setting target 2 (for Windows) and we were getting a “500 Internal Server Error” with all payloads <- frustrating…. :|
  • Tried automatic target and java payloads—nothing worked!!

The steps and screenshots below illustrate how to deploy an alternative shell and provide a few ideas of what to do—note: these are only ideas; your plan of attack may be different depending on the circumstance.

Download and extract an alternative shell

Download the Laudanum files (which contains the cmd.war file) from here:
(props to Kevin Johnson, Tim Medin, and John Sawyer)

According to the SourceForge page:
“Laudanum is a collection of injectable files, designed to be used in a pentest when SQL injection flaws are found and are in multiple languages for different environments. They provide functionality such as shell, DNS query, LDAP retrieval and others.”

Extract and understand the code

This is always a best practice to try to understand the code. Even if you are not familiar with the language, use Google and try to understand what the code is doing to the best of your abilities. It will help you learn how to effectively use the tool and may identify limitations or areas of concern.

Upload the cmd.war

Upload the cmd.war file to the remote server in the “WAR file to deploy” section shown in the screenshot below:

Utilize the JSP shell

Utilize the shell (found at /cmd/cmd.jsp) to run various situational awareness commands

Remember, many commands you are used to running are a function of the command shell and are not individual binaries—such as dir. In this case, execute them by first specifying “cmd.exe /c [whatever]” (as shown below).

Get file transfer capabilities

Luckily the developer enabled the tftp client on this Windows 7 host. Wooot!

Upgrade your shell

We could not get a meterpreter shell to execute for some reason. I believe this had to do with UAC and the particular user’s permissions. So we settled for hex edited netcat (which is a step up from the jsp shell).

To transfer (transfer an alternate backdoor to the remote host -- this is a hex edited version of netcat):

Start listener and receive callback (the first command is starting a local listener and the second command is executed on the remote host after the callback succeeds.):

Get creative

This pivot host can now be used to not only attack the host itself, but also others in the network. You are only limited by the privileges that you can gain and your own imagination. For example, you could upload gsecdump in order to dump hashes, fpipe to portforward other protocols to bypass firewalls, or use Windows native commands in order to datamine and propagate to other hosts. Not the sexiest hack, but it is quite effective.

This article and hack utilized and expanded on an idea from the following blog entry (props and thanks to the author):


Metasploit is a powerful framework that simplifies the attacks and adds fantastic functionality, but knowledge of the manual methods is a must—especially when your trusty tools fail and in-depth troubleshooting is not an option. This often comes up in our classes when students ask why we show multiple ways to accomplish a task... If you want to hack, you gotta learn how things really work and be able to bounce back if your tool fails.