Blog on Jon Oberheide

Estimating Google’s Two-Factor (2SV) Adoption with Pen, Paper, and Poor Math

Fri, 15 May 2015 00:00:00 +0000

As a two-factor authentication vendor, reporters often ask us about the state of strong authentication. A common question that comes up is: How many people actually use two-factor authentication? What is the largest two-factor deployment?

Well, the largest scale deployments of two-factor are often consumer use cases. Despite having very low adoption rates in terms of % of total users, large service providers like Google, Microsoft, Apple, etc have hundreds of million of users, dwarfing the 2FA deployments of even the largest enterprise use cases.

ReKey: Fixing Android's Master Key Vulnerability

Tue, 16 Jul 2013 00:00:00 +0000

Safely patch the Master Key vulnerabilities on your rooted Android device.
Avoid waiting months or years for your carrier to deliver a security update.
Created by your friendly neighborhood security experts at NEU and Duo Security.

What is ReKey?

Earlier this month, RFP from BlueBox published a sneak preview of his upcoming BlackHat talk, detailing a vulnerability in the Android platform that affects nearly all Android devices. Soon after, a vulnerability of similar nature and impact was published on Chinese forum. Both of these “Master Key” vulnerabilities allow an attacker to modify the code of an Android package without affecting the signature of the package as verified by the package manager, which has serious implications when considering system-signed packages. From an end user perspective, the vulnerabilities allow an attacker to take full control of a user’s device.

Bypassing Google’s Two-Factor Authentication

Mon, 25 Feb 2013 00:00:00 +0000

TL;DR - An attacker can bypass Google’s two-step login verification, reset a user’s master password, and otherwise gain full account control, simply by capturing a user’s application-specific password (ASP).

(With all due respect to Google’s “Good to Know” ad campaign)

Abusing Google’s (not-so-) Application-Specific Passwords

Google’s 2-step verification makes for an interesting customer story in some of the challenges that go with such a wide-scale, comprehensive deployment of strong authentication. To make 2-step verification usable for all of their customers (and to bootstrap it into their rather expansive ecosystem without breaking everything), Google’s engineers had to make a few compromises. In particular, with 2-step verification came a notion of “Application-Specific Passwords” (ASPs).

Early Results from X-Ray: Over 50% of Android Devices are Vulnerable

Wed, 12 Sep 2012 00:00:00 +0000

Later this week, on Friday, I’ll be presenting the preliminary results from our X-Ray project at Rapid7’s United Summit conference in San Francisco.

X-Ray is Duo’s mobile app that performs “vulnerability assessment” on Android devices. Instead of scanning for malicious apps installed on the device like a mobile antivirus app would do (a nearly-intractable problem), X-Ray can identify known, yet unpatched, vulnerabilities in the mobile platform itself that could be exploited to take full control of users’ phones. As carriers are very conservative in rolling out patches to fix vulnerabilities in the Android platform, users’ mobile devices often remain vulnerable for months and even years.

Announcing X-Ray For Android

Wed, 25 Jul 2012 00:00:00 +0000

The first public of X-Ray is now available! X-Ray 1.0 supports 8 of the most common privilege escalation vulnerabilities that affect the Android platform.

What is X-Ray?

X-Ray allows you to scan your Android device for security vulnerabilities that put your device at risk.

X-Ray was developed by the security experts at Duo Security. We hope that X-Ray will empower users with knowledge of vulnerabilities on their devices and allow them to take action to improve their security. We encourage users to contact their carriers and ask for their devices to be patched.

Exploit Mitigations in Android Jelly Bean 4.1

Mon, 16 Jul 2012 00:00:00 +0000

It’s been a few months since our analysis of the new ASLR support in Android ICS 4.0. Given that ICS 4.0 is old news now with the recent release of Jelly Bean 4.1, I thought it was about time to give an update on the ASLR capabilities as well as cover some of the other improvements in exploit mitigations present in Jelly Bean.

As a quick recap of the current state of ASLR in Android ICS:

Dissecting the Android Bouncer

Thu, 21 Jun 2012 00:00:00 +0000

At SummerCon this year, Charlie Miller and I gave a talk on Android’s Bouncer. Our presentation materials are now publicly available.

The week before our presentation, we also posted a teaser video showing our remote connect-back shell that we used to explore the Bouncer environment:

Enjoy!

Announcing VPN Hunter

Wed, 21 Mar 2012 00:00:00 +0000

Today, we’re excited to announce the public launch of VPN Hunter!

VPN Hunter is a service that discovers and classifies the VPNs and other remote access services of any organization. Given only an organization’s domain name (eg. msu.edu), VPN Hunter can find a wide range of remote access services associated with that organization, such as:

SSL VPNs: VPN Hunter will seek out SSL VPNs from vendors including Juniper, Cisco, Palo Alto, Citrix, Fortinet, F5, SonicWALL, Barracuda, Microsoft, and Array.
Remote Access: VPN Hunter will also discover other remote access services including IPsec, PPTP, OpenVPN, RDP, and SSH.
Email Portals: VPN Hunter will find a handful of web-based email portals including Outlook Web App, Gmail, and Zimbra.
Generic Login Sites: VPN Hunter can also discover in-house web apps and other generic login sites that aren’t tied to a particular third-party vendor or product.

It’s no coincidence that VPN Hunter is able to discover many of the remote access services supported by Duo’s two-factor platform. Given that remote services must be exposed to the public Internet inherently, it’s vital that they be protected with strong authentication. Having a simple username and password (that is easily guessed, phished, or otherwise stolen) as the only barrier between the Internet and your internal corporate network is far from ideal and borderline negligent.

ASLR in Android Ice Cream Sandwich 4.0

Mon, 27 Feb 2012 00:00:00 +0000

When I first saw the release notes for the new Android Ice Cream Sandwich (ICS) platform, I was excited to see that Google mentioned that "Android 4.0 now provides address space layout randomization":

For the uninitiated, ASLR randomizes where various areas of memory (eg. stack, heap, libs, etc) are mapped in the address space of a process. Combined with complementary mitigation techniques such as non-executable memory protection (NX, XN, DEP, W\^X, whatever you want to call it), ASLR makes the exploitation of traditional memory corruption vulnerabilities probabilisticallydifficult.

CSAW CTF 2011 Kernel Exploitation Challenge

Sun, 27 Nov 2011 00:00:00 +0000

My challenge for this year’s NYU Poly CSAW CTF finals was a Linux kernel exploitation challenge disguised as a crypto challenge. The challenge and solution are described below.

The Challenge

Each team is given unprivileged remote shell access to a Linux VM. There is a custom kernel module, SqueamishOssifrage.ko, loaded.The full source code of the kernel module is provided to the team. SqueamishOssifrage.c is reproduced below (and can be downloaded here):

/*
 * SqueamishOssifrage.c
 * CSAW 2011 CTF Challenge Kernel Module
 * Jon Oberheide <jon@oberheide.org>
 *
 * Decrypt the flag...and win?
 *
 * Information:
 *
 *   /proc/csaw/key:     get/set symmetric key
 *   /proc/csaw/encrypt: get/set encrypted payload
 *   /proc/csaw/decrypt: get/set decrypted payload
 *
 * Example usage:
 *
 *   # set a key
 *   $ echo "this is a key" > /proc/csaw/key
 *
 *   # encrypt payload with that key
 *   $ echo "hello world" > /proc/csaw/encrypt
 *
 *   # retrieve encrypted payload
 *   $ cat /proc/csaw/encrypt > payload.enc
 *
 *   # decrypt encrypted payload
 *   $ cat payload.enc > /proc/csaw/decrypt
 *
 *   # retrieve decrypted payload
 *   $ cat /proc/csaw/decrypt > payload.dec
 *
 *   # view decrypted payload
 *   $ cat payload.dec
 *   hello world
 */

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/proc_fs.h>
#include <linux/string.h>
#include <asm/uaccess.h>

#define PROC_CSAW    "csaw"
#define PROC_KEY     "key"
#define PROC_ENCRYPT "encrypt"
#define PROC_DECRYPT "decrypt"
#define MAX_LENGTH   128
#define MAX_ROUNDS   64
#define DELTA        0x9e3779b9

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Jon Oberheide");
MODULE_DESCRIPTION("CSAW 2011 CTF Challenge Kernel Module");

static struct proc_dir_entry *proc_csaw;
static struct proc_dir_entry *proc_key;
static struct proc_dir_entry *proc_decrypt;
static struct proc_dir_entry *proc_encrypt;

static uint32_t key[4] = { 0, 0, 0, 0 };
static uint32_t rounds = 32;
static unsigned char enc_blob[MAX_LENGTH];
static unsigned char dec_blob[MAX_LENGTH];

void encrypt(uint32_t k[], char *buf, int len, int rounds) __attribute__ ((optimize (0)));
void decrypt(uint32_t k[], char *buf, int len, int rounds) __attribute__ ((optimize (0)));
void scramble(uint32_t k[], uint32_t t[], uint32_t *s, uint32_t *d) __attribute__ ((optimize (0)));
void descramble(uint32_t k[], uint32_t t[], uint32_t *s, uint32_t *d) __attribute__ ((optimize (0)));

void
scramble(uint32_t k[], uint32_t t[], uint32_t *s, uint32_t *d)
{
    uint32_t n, sbox[8];
    uint32_t y = t[0], z = t[1];
    uint32_t delta = DELTA, sum = 0;

    for (n = 0; n < 8; n++) {
        sbox[n] = key[n % 4];
    }
    for (n = 0; n < 32; n++) {
        sum += delta;
        y += ((z << 4) + k[0]) ^ (z+sum) ^ ((z >> 5) + k[1]);
        z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]);
    }
    t[0] = y; s = d + n; t[1] = z;
}

void
encrypt(uint32_t k[], char *buf, int len, int rounds)
{
    int i;

    if (rounds >= 0) {
        if (rounds % 3 == 0) {
            k[0] ^= k[1]; k[1] ^= k[0]; k[0] ^= k[1];
            k[2] ^= k[3]; k[3] ^= k[2]; k[2] ^= k[3];
        } else if (rounds % 3 == 1) {
            k[0] ^= k[2]; k[2] ^= k[0]; k[0] ^= k[2];
            k[1] ^= k[3]; k[3] ^= k[1]; k[1] ^= k[3];
        } else if (rounds % 3 == 2) {
            k[0] ^= k[3]; k[3] ^= k[0]; k[0] ^= k[3];
            k[2] ^= k[1]; k[1] ^= k[2]; k[2] ^= k[1];
        }
        encrypt(k, buf, len, rounds-1);
    } else {
        for (i = 0; i < len / 8; i++) {
            scramble(k, (uint32_t *)(buf + (i * 8)), (uint32_t *) 0, (uint32_t *) DELTA);
        }
    }
}

void
descramble(uint32_t k[], uint32_t t[], uint32_t *s, uint32_t *d)
{
    uint32_t n, sbox[8];
    uint32_t y = t[0], z = t[1];
    uint32_t delta = DELTA, sum = delta << 5;

    for (n = 0; n < 8; n++) {
        sbox[n] = key[n % 4];
    }
    for (n = 0; n < 32; n++) {
        z -= ((y << 4) + k[2]) ^ (y + sum) ^ ((y >> 5) + k[3]);
        y -= ((z << 4) + k[0]) ^ (z + sum) ^ ((z >> 5) + k[1]);
        sum -= delta;
    }
    t[0] = y; s = d + n; t[1] = z;
}

void
decrypt(uint32_t k[], char *buf, int len, int rounds)
{
    int i;

    if (rounds >= 0) {
        if (rounds % 3 == 0) {
            k[0] ^= k[1]; k[1] ^= k[0]; k[0] ^= k[1];
            k[2] ^= k[3]; k[3] ^= k[2]; k[2] ^= k[3];
        } else if (rounds % 3 == 1) {
            k[0] ^= k[2]; k[2] ^= k[0]; k[0] ^= k[2];
            k[1] ^= k[3]; k[3] ^= k[1]; k[1] ^= k[3];
        } else if (rounds % 3 == 2) {
            k[0] ^= k[3]; k[3] ^= k[0]; k[0] ^= k[3];
            k[2] ^= k[1]; k[1] ^= k[2]; k[2] ^= k[1];
        }
        decrypt(k, buf, len, rounds-1);
    } else {
        for (i = 0; i < len / 8; i++) {
            descramble(k, (uint32_t *)(buf + (i * 8)), (uint32_t *) 0, (uint32_t *) DELTA);
        }
    }
}

int
key_write(struct file *file, const char __user *ubuf, unsigned long count, void *data)
{
    char buf[MAX_LENGTH];

    printk(KERN_INFO "csaw: called key_write\n");

    memset(buf, 0, sizeof(buf));

    if (count > MAX_LENGTH) {
        count = MAX_LENGTH;
    }
    if (copy_from_user(&buf, ubuf, count)) {
        return -EFAULT;
    }

    sscanf(buf, "%16c\t%d", (char *) key, &rounds);

    return count;
}

int
key_read(char *page, char **start, off_t off, int count, int *eof, void *data)
{
    printk(KERN_INFO "csaw: called key_read\n");

    memcpy(page, key, sizeof(key));

    return sizeof(key);
}

int
encrypt_write(struct file *file, const char __user *ubuf, unsigned long count, void *data)
{
    char buf[MAX_LENGTH];
    uint32_t session[4];

    printk(KERN_INFO "csaw: called encrypt_write\n");

    memset(buf, 0, sizeof(buf));

    if (count > MAX_LENGTH) {
        count = MAX_LENGTH;
    }
    if (copy_from_user(&buf, ubuf, count)) {
        return -EFAULT;
    }

    memcpy(session, key, sizeof(key));

    encrypt(session, buf, sizeof(buf), rounds);

    memcpy(enc_blob, buf, sizeof(buf));

    return count;
}

int
encrypt_read(char *page, char **start, off_t off, int count, int *eof, void *data)
{
    printk(KERN_INFO "csaw: called encrypt_read\n");

    memcpy(page, enc_blob, sizeof(enc_blob));

    return sizeof(enc_blob);
}

int
decrypt_write(struct file *file, const char __user *ubuf, unsigned long count, void *data)
{
    char buf[MAX_LENGTH];
    uint32_t session[4];

    printk(KERN_INFO "csaw: called decrypt_write\n");

    memset(buf, 0, sizeof(buf));

    if (count > MAX_LENGTH) {
        count = MAX_LENGTH;
    }
    if (copy_from_user(&buf, ubuf, count)) {
        return -EFAULT;
    }

    memcpy(session, key, sizeof(key));

    decrypt(session, buf, sizeof(buf), rounds);

    memcpy(dec_blob, buf, sizeof(buf));

    return count;
}

int
decrypt_read(char *page, char **start, off_t off, int count, int *eof, void *data)
{
    printk(KERN_INFO "csaw: called decrypt_read\n");

    memcpy(page, dec_blob, sizeof(dec_blob));

    return sizeof(dec_blob);
}

int __init
csaw_init(void)
{
    printk(KERN_INFO "csaw: loading module\n");

    memset(enc_blob, 0, sizeof(enc_blob));
    memset(dec_blob, 0, sizeof(dec_blob));

    proc_csaw = proc_mkdir(PROC_CSAW, NULL);

    proc_key = create_proc_entry(PROC_KEY, 0666, proc_csaw);
    proc_key->read_proc = key_read;
    proc_key->write_proc = key_write;

    proc_encrypt = create_proc_entry(PROC_ENCRYPT, 0666, proc_csaw);
    proc_encrypt->read_proc = encrypt_read;
    proc_encrypt->write_proc = encrypt_write;

    proc_decrypt = create_proc_entry(PROC_DECRYPT, 0666, proc_csaw);
    proc_decrypt->read_proc = decrypt_read;
    proc_decrypt->write_proc = decrypt_write;

    printk(KERN_INFO "csaw: created /proc/csaw entries\n");

    return 0;
}

void __exit
csaw_exit(void)
{
    printk(KERN_INFO "csaw: unloading module\n");

    remove_proc_entry(PROC_KEY, proc_csaw);
    remove_proc_entry(PROC_ENCRYPT, proc_csaw);
    remove_proc_entry(PROC_DECRYPT, proc_csaw);
    remove_proc_entry(PROC_CSAW, NULL);

    printk(KERN_INFO "csaw: removed /proc/csaw entries\n");
}

module_init(csaw_init);
module_exit(csaw_exit);

A Crypto Challenge?

Lots of crypto looking stuff, huh? As the header tells you, the kernel module exposes an interface via /proc/csaw to set a key and encrypt/decrypt payloads:

Tool releases: ksymhunter and kstructhunter

Thu, 08 Sep 2011 00:00:00 +0000

I’m releasing a couple tools I use internally for Linux kernel exploit development: ksymhunter and kstructhunter. They’re probably only useful for like ten people on the planet, but oh well, enjoy!

ksymhunter

Kernel symbols are definitely a useful resource when writing Linux kernel exploits. Whether you’re looking for particular structures in kernel memory or pulling the old commit_creds technique for convenient privilege escalation, having access to a kernel symbol table can be incredibly useful for an exploit writer.

Stackjackin' 2: Electric Boogaloo

Wed, 06 Jul 2011 00:00:00 +0000

Last month at SummerCon, Dan Rosenberg and I talked about our stackjacking technique for exploiting kernel vulnerabilities on grsecurity/PaX-hardened Linux kernels, in a presentation titled "Stackjacking and Other Kernel Nonsense."

While we covered a lot of material from our original stackjacking presentation, we also presented on a couple new items extending the original stackjacking technique:

We discussed about how enhancements to the vanilla Linux kernel, such as SMEP, may make stackjacking an effective approach for vanilla kernel exploitation. While an arbitrary write is currently still sufficient for exploiting a vanilla Linux kernel, we may eventually (years?) get to the point where the built-in protection mechanisms begin to approach themitigationsoffered by grsecurity/PaX. Again, not really important in the short-term, but hopefully we'll revive stackjacking for use against vanilla kernels a few years from now. :-)
We also presented a revised stackjacking approach that is effective against the stackjacking mitigations that spender released not-so-quietly after our HES presentation and before our Infiltrate presentation. To top it off, the new technique allows exploitation with even less attackerassumptions!

RSA-Proofing Our Duo Push Two-Factor Authentication

Tue, 21 Jun 2011 00:00:00 +0000

So…RSA happened.

We haven’t commented much on the RSA breach, primarily because, instead of ambulance chasing, we’ve been busy working on some technology to prevent RSA-style attacks from impacting our Duo Push authentication, which is the subject of today’s post.

However, I think there are a couple interesting points that can be drawn from the RSA breach:

First, the RSA breach has shown that two-factor technology is incredibly effective. The attackers targeting Lockheed Martin and company had to plan an entirely separate operation to compromise RSA’s internal secrets to even get their foot in the door of the defense contractors. While RSA’s implementation of two-factor may be suboptimal, the event bolsters the argument for deploying two-factor rather than undermining it.

Duo Push: The Next Generation of Two-Factor Authentication

Wed, 08 Jun 2011 00:00:00 +0000

We’re excited to announce that we’ve officially launched Duo Push, a new authentication method that leverages modern smartphones to provide two-factor authentication that’s both resistant to the latest threats and is actually enjoyable to use!

But first, some background…

When we first started Duo, we set out to create a two-factor authentication platform that was not only secure, but also easy to use and manage. We saw that two-factor authentication technologies were avoided not because they failed to offer an increase in security, but because their cost, management complexity, and user annoyance factor were prohibitively high. In addition, the “one authenticator fits all users” model employed by our competitors (OTP only, phone only, SMS only, etc), just didn’t fit the diversity of the user base needing two-factor authentication.

When Angry Birds Attack: Android Edition

Sat, 28 May 2011 00:00:00 +0000

It’s been about six months since I reported a vulnerability in the Android mobile platform that allowed the unprompted installation of arbitrary applications with arbitrary permissions on a victim’s device. While the vulnerability has long been fixed on Android handsets around the world, I’ve yet to write up any technical details about it, and it’s unlikely you’ve heard of it unless you were present at our ShmooCon presentation earlier this year. So without further ado, let’s dive into "When Angry Birds attack: Android edition."

Stackjacking Your Way to grsec/PaX Bypass

Wed, 20 Apr 2011 00:00:00 +0000

This April at Hackito Ergo Sum in Paris and Immunity’s Infiltrate in Miami, Dan Rosenberg and I presented on a technique to exploit grsecurity/PaX-hardened Linux kernels. Read on for a brief overview of our presentation and a link to the full slides and PoC code.

The Stackjacking Technique

In our slides, we presented a technique to exploit a grsecurity/PaX-hardened Linux kernel (eg. GRKERNSEC_HIGH) given the existence of two exploitation primitives:

How I Almost Won Pwn2Own via XSS

Mon, 07 Mar 2011 00:00:00 +0000

No, seriously.

The good: Google has patched a serious vulnerability I discovered in the Android web market.

The bad: Since the Android web market was launched earlier this year, it was possible to remotely install arbitrary applications with arbitrary permissions onto a victim’s phone simply by tricking them into clicking a malicious link (either on their desktop OR phone). The exploit works universally across all Android devices, versions, and architectures.

Exploiting Stack Overflows in the Linux Kernel

Mon, 29 Nov 2010 00:00:00 +0000

In this post, I’ll introduce an exploitation technique for kernel stack overflows in the Linux kernel. Keep in mind this does not refer to buffer overflows on the kernel stack (whose exploitability is well understood), but rather the improper expansion of the kernel stack causing it to overlap with critical structures which may be subsequently corrupted. This is a vulnerability class in the Linux kernel that I do not believe have been exploited publicly in the past, but is relevant due to a recent vulnerability in the Econet packet family.

CSAW CTF 2010 Kernel Exploitation Challenge

Tue, 02 Nov 2010 00:00:00 +0000

The finals for NYU Poly’s CSAW CTF was this past weekend in New York City. I thought I would post the kernel exploitation challenge I developed for the final round. Feel free to try your hand at solving it!

The Setup

Each team is given unprivileged remote shell access to a Linux VM. There is a vulnerable kernel module (csaw.ko) loaded into memory:

csaw@csaw ~ $ lsmod
Module Size Used by
csaw 1111 0

The kernel module exposes a /proc/csaw interface with which the team can interact with and attempt to exploit the vulnerability contained in the kernel module. Upon successful exploitation and privilege escalation, the team can retrieve the key/flag hidden in the root-readable /root/key.txt file.

Linux Kernel pktcdvd Memory Disclosure

Sat, 23 Oct 2010 00:00:00 +0000

A vulnerability in the pktcdvd driver in the Linux kernel allows for the disclosure of 4 bytes of kernel memory. In this post, I’ll describe the tad bit of magic that’s necessary to exploit the vulnerability on both 32-bit and 64-bit hosts to disclosure an arbitrary amount of kernel memory.

The Vulnerability

The vulnerability was first introduced in 2.6.10 (way back in 2004) and was recently discovered in late September 2010 by Dan Rosenberg. As described by Dan:

Linux Kernel CAN SLUB Overflow

Fri, 10 Sep 2010 00:00:00 +0000

Ben Hawkes discovered a vulnerability in the Controller Area Network (CAN) packet family in the Linux kernel that results in a controllable overflow of a SLUB-allocated structure. As there’s not a whole lot of modern, public examples of SLUB overflow exploits, I’ll describe my exploit of the CAN vulnerability in detail.

The Vulnerability

Ben provides the full details of the vulnerability in his blog post:

A controller area network is backed by the AF_CAN datagram socket type. This socket is enabled by the CONFIG_CAN kernel configuration option, so any kernel compiled with CONFIG_CAN and CONFIG_CAN_BCM options were vulnerable. This included at least Ubuntu 10.04 and Debian 5.0 (i’m told a pre-release version of Red Hat was also affected).

The bug is an integer overflow in the sendmsg implementation for BCM (broadcast manager) AF_CAN sockets which results in controlled corruption of a kmalloc heap chunk. No physical CAN device is required to trigger the overflow.

The bcm_sendmsg function in net/can/bcm.c reads in a bcm_msg_head structure from a user-supplied iovec:
struct bcm_msg_head {
     __u32 opcode;
     __u32 flags;
     ...
     canid_t can_id;
     __u32 nframes;
     struct can_frame frames[0];
};
The opcode field dictates the type of message processing that should be performed by bcm_sendmsg. The vulnerability is in the RX_SETUP operation, which is backed by the bcm_rx_setup function in net/can/bcm.c (comments marked with BH):
#define CFSIZ sizeof(struct can_frame)

static int bcm_rx_setup(struct bcm_msg_head *msg_head, ...
 // BH: the ifindex parameter is set to zero if
 // BH: msg->msg_name is NULL
 ...

 op = bcm_find_op(&bo->rx_ops, msg_head->can_id,
                  ifindex);
 // BH: by setting can_id to 0xdeadbeef, a NULL op
 // BH: is returned
 if (op) {
     ...
 }
 else {
    op = kzalloc(OPSIZ, GFP_KERNEL);

    if (!op)
       return -ENOMEM;

    op->can_id    = msg_head->can_id;
    op->nframes   = msg_head->nframes;
    // BH: nframes is controlled by the attacker

    if (msg_head->nframes > 1) {
       op->frames = kmalloc(
                      msg_head->nframes * CFSIZ,
                      GFP_KERNEL);
       // BH: integer overflow here, large nframes
       // BH: wraps around to cause a small alloc
       ...

    }...

    if (msg_head->nframes) {
       err = memcpy_fromiovec((u8 *)op->frames,
                        msg->msg_iov,
                        msg_head->nframes * CFSIZ);
       // BH: size field overflows to same value as
       // BH: the allocation, no corruption
                      ...
    } ...

    do_rx_register = 1
 }

 ...
 if (do_rx_register) {
    if (ifindex) {
       // BH: ifindex is zero, as noted above
       ...
    } else
       err = can_rx_register(NULL, op->can_id,
                        REGMASK(op->can_id),
                        bcm_rx_handler, op, "bcm");

        // BH: can_rx_register explicitly
        // BH: allows registering to a NULL device

        if (err) {
           ...
        }
    }
...
Now at this point no memory corruption has occurred, but there is a bcm_op structure registered for the NULL device under a can_id of 0xdeadbeef with a large value for nframes (e.g. nframes = 268435458) and a small allocation for the frames buffer (e.g. 32 bytes). If the RX_SETUP operation is called again on this operation structure, but this time with a mid-sized nframes value (e.g. nframes = 512), then the following ‘update’ code in bcm_rx_setup is invoked:
op = bcm_find_op(&bo->rx_ops, msg_head->can_id, ifindex);
// BH: op struct for 0xdeadbeef is returned

if (op) {
   // BH: 512 < 268435458
   if (msg_head->nframes > op->nframes)
      return -E2BIG;

   if (msg_head->nframes) {
      // BH: writes 8192 attacker-controlled bytes
      // BH: in to a 32-byte buffer
      err = memcpy_fromiovec((u8 *)op->frames,
                       msg->msg_iov,
                       msg_head->nframes * CFSIZ);
      ...
   }
}
This means that it’s possible to corrupt any amount of data contiguous to the original ‘frames’ kmalloc chunk with an attacker-controlled value. The tough part from here is finding a good way of normalizing the heap layout to get a consistent (aka exploitable) crash. Needless to say that, with a bit of work, you can get an arbitrary kernel-space write.

Dexcode Teardown of the Android SMS Trojan

Tue, 10 Aug 2010 00:00:00 +0000

I got my hands on a copy of the recent Android SMS trojan that commits toll fraud via SMS messages to premium Russian shortcodes. What follows is a brief teardown of the APK and disassembly of the trojan’s dexcode and description of its malicious functionality. It’s incredibly simple in nature so there’s not much detail to go into.

Package: RU.apk
Package Name: org.me.androidapplication1
Permissions Requested: android.permission.SEND_SMS
Contents:
    ./classes.dex
    ./res
    ./res/drawable
    ./res/drawable/icon.png
    ./res/layout
    ./res/layout/main.xml
    ./resources.arsc
    ./AndroidManifest.xml
    ./META-INF
    ./META-INF/MANIFEST.MF
    ./META-INF/CERT.RSA
    ./META-INF/CERT.SF

There’s not much to this trojan application. In fact, it appears to be hastily built off of the HelloWorld example program distributed in the Android SDK. Even the primary layout file (main.xml) contains nothing but a single LinearLayout with a TextView saying "Hello Android from NetBeans".

A Peek Inside the GTalkService Connection

Mon, 28 Jun 2010 00:00:00 +0000

This posts aims to peek inside the Android GTalkService connection and observe its protocol. In particular, we’re interested in the INSTALL_ASSET message and whether or not it is protected by any additional cryptographic signatures beyond the intended guarantees provided by the SSL transport.

A Brief Introduction to the GTalkService

If you haven’t read the previous post on the GTalkService and INSTALL_ASSET/REMOVE_ASSET, do so first.

In short, the GTalkService is a persistent connection maintained from your Android phone to Google’s servers at all time. It allows Google to push down messages to your phone in order to perform particular actions. For example, when you click to install an app through the Android Market, Google pushes down an INSTALL_ASSET to your phone which causes it to fetch and install that application. When Google wants to remote kill an application from your phone, it pushes down a REMOVE_ASSET message to your phone which causes it to remove the particular application.

Remote Kill and Install on Google Android

Fri, 25 Jun 2010 00:00:00 +0000

In this post, I’ll talk about the REMOVE_ASSET and INSTALL_ASSET mechanisms that can be invoked by Google via Android’s GTalkService to not only remotely remove applications from an Android device but also remotely install new applications.

RootStrap Background

So if you didn’t check out my slides from SummerCon last week in NYC, I talked a bit about a program called RootStrap in the second half of my talk. RootStrap is intended as an example of an application that could be used to bootstrap a rootkit (hence the name). Summed up as briefly as possible, RootStrap phones home periodically to fetch remote native ARM code and executes it outside the Dalvik VM. An attacker could use such an approach to gain a large install base for a seemingly innocent application and then push down a local privilege escalation exploit as soon as a new vulnerability is discovered in the Linux kernel and root the device. Since carriers are fairly conservative in pushing out OTA patches for their devices, an attacker could easily push out their malicious payload before the devices were patched.

SummerCon 2010 Slides

Mon, 21 Jun 2010 00:00:00 +0000

SummerCon was absurdly fun. Thanks for redpantz for putting on a great event and all the NY guys for making it a blast. My talk was on a few random Android topics...slides are available below. I threw everything together about 12 hours before my talk so it’s a little rough around the edges and a few slides have been redacted for now.

SOURCE Boston Slides

Sun, 25 Apr 2010 00:00:00 +0000

Just got back from SOURCE Boston. SOURCE was a great event: a great line-up of speakers, fun social events (thanks to Rapid7 and iSEC for sponsoring), and smooth execution (props to Stacy and Zach). My talk was on the topic of Linux kernel security, slides are available here.

ReiserFS .reiserfs_priv Vulnerability

Sat, 10 Apr 2010 00:00:00 +0000

A vulnerability in the ReiserFS filesystem of the Linux kernel (versions <= 2.6.34-rc3) allows for the unprivileged reading and writing of objects in the .reiserfs_priv path. Leveraging extended attributes and POSIX file-based capabilities, this vulnerability allows for privilege escalation on systems with a ReiserFS filesystem.

The Vulnerability

The vulnerability was introduced in May 2009 in commit 677c9b2. The commit was intended to simplify the logic around ReiserFS’s privroot, a virtual path located at .reiserfs_priv in the root of the fs mount that is used for storing internal filesystem information such as extended attributes. The commit also had the unfortunate side effect of exposing the privroot dentry (even without the expose_privroot mount option enabled), allowing an unprivileged user to read/write the filesystem information stored in .reiserfs_priv.

Linux Kernel x86-64 Register Leak

Sun, 04 Oct 2009 00:00:00 +0000

A recent vulnerability in the Linux kernel (versions <= 2.6.32-rc1) allows the leakage of certain register contents. The x86-64 registers r8-r11 may be leaked to 32-bit unprivileged userspace applications that switch themselves into 64-bit mode.

Introduction

In order to understand this vulnerability, we first need to talk a bit about the x86-64 architecture (aka amd64). One of the key design decisions of x86-64, which fueled its adoption over IA-64, is its backward compatibility with 32-bit code. In x86-64 long mode, there are two sub-modes controlled by the code segment descriptor: compatibility mode and 64-bit mode. Therefore, our 64-bit operating system can execute both 32-bit and 64-bit binaries without issue. Of course, if we’re executing a 32-bit binary, we can access our traditional 32-bit architecture registers and not any of the additional register file added by x86-64.

Disabling Green Dam with Dam Burst

Mon, 28 Sep 2009 00:00:00 +0000

Dam Burst is a simple utility that allows an unprivileged user to disable the censorship functionality of the Green Dam Youth Escort software.

Dam Burst operates by injecting code into a running application and removing the Green Dam hooks that enable it to monitor and block user activity, effectively restoring the running application to its original uncensored state.

Unlike other tools that disable or uninstall the Green Dam software, Dam Burst does not require administrative privileges. Since Dam Burst can be run as an unprivileged user to disable the Green Dam censorware in currently running applications, it is very effective in situations where the user is restricted from obtaining administrator privileges and may wish to avoid censorship (eg. public/internet cafe computers that the user may not own).

Linux Kernel getname() Stack Memory Disclosures

Sat, 29 Aug 2009 00:00:00 +0000

In this post, we’ll look at some kernel stack information disclosures in the getname() functions of several socket AFs recently discovered in the Linux kernel.

The Vulnerability

The getname() function of an address family in the kernel is used to retrieve information about a given socket. This information, in the form of a sockaddr struct, is accessed from userspace through the getsockname(2) and getpeername(2) system calls for bound and connected sockets respectively.

PolyPack at USENIX WOOT '09

Mon, 10 Aug 2009 00:00:00 +0000

We just presented our PolyPack research today at the USENIX Workshop on Offensive Technologies (WOOT ‘09) in Montreal, Canada. Links to the paper and presentation materials are after the jump.

Paper: /files/woot09-polypack.pdf

Presentation: /files/woot09-polypack-pres.pdf

From the PolyPack website:

"PolyPack is a research project at the University of Michigan aimed at understanding the impact of malware packers on modern antivirus products. PolyPack highlights the failure of signature-based antivirus against common, widely available packers, investigates the role that diversity plays in the capabilities of both the packers and antivirus engines, and demonstrates the ease and efficacy with which an attacker could deploy an online packing service for nefarious purposes in a deployment model known as crimeware-as-a-service (CaaS).

Hijacking Tinychat Screencasts

Sun, 12 Jul 2009 00:00:00 +0000

Tinychat is a sweet site that allows for simple chat, video conferencing, and screencasting. In this post, I’ll detail how to hijack Tinychat screencasts by injecting images of your own.

I had played with Tinychat recently and decided to poke at it some more when mubix held a Metasploit-related screencast a couple days ago. Tinychat’s multimedia features operate with a mix of JavaScript, Java, and Flash. Just looking at the initial JavaScript used to set up the screencasting applet set off some alarms:

Analysis of a Trojaned ssh/sshd

Tue, 30 Jun 2009 00:00:00 +0000

Some information about a trojaned ssh client and sshd server discovered in a recent compromise. I didn’t find any details on this particular OpenSSH backdoor via Google, so hopefully this information will be of use to anyone who runs into it on their boxes.

The compromise of a group of small number of Linux boxes in a University unit was first discovered when the attackers began launching ssh brute force attacks from the boxes. Right off the bat, it was clear from the noisy activity that the attackers were not very sophisticated and did not recognize the immediate value of the compromised boxes.

udev Local Privilege Escalation

Mon, 20 Apr 2009 00:00:00 +0000

A recent bug found by Sebastian Krahmer in udev has considerable security impact across a wide range of Linux distributions.

At the core of the vulnerability is the udevd daemon, responsible for receiving and handling various device events from the kernel. These events are delivered to udevd via netlink, a socket family (AF_NETLINK) commonly used for IPC between userspace applications and the kernel. However, netlink is not exclusively for kernel/userspace communication and can also be used to send messages between userspace applications.

Panera Gift Card Security

Wed, 15 Apr 2009 00:00:00 +0000

A bit of information on Panera Bread’s gift card security, or lack thereof.

Traditional gift card security often involves a randomized account number and a scratch-off PIN number. Randomized account numbers prevent attackers from guessing valid accounts numbers to use. Scratch-off PIN numbers prevent attackers from checking/using card numbers and from going in to brick-and-mortar stores to capture numbers of unactiviated cards on the racks (checkout clerks are advised to discard any cards that already have the PIN scratched-off or otherwise tampered with). Online websites also use CAPTCHAs and rate-limiting to avoid attackers attempting to bruteforce card number space.

dpkt Tutorial #4: AS Paths from MRT/BGP

Wed, 25 Mar 2009 00:00:00 +0000

Previously we looked at creating ICMP echo requests, parsing a PCAP file, and doing DNS spoofing with the dpkt framework. Today I will show how to parse the AS paths of BGP messages out of MRT routing dumps.

Parsing BGP routing information is fun. However, before projects like RouteViews were around, getting a global view of Internet routing in real-time simply wasn’t possible. But thanks to RouteViews, we can extract useful routing information from the MRT dumps from a number of providers’ perspectives.

ARBSEC 01 Wrap-Up

Sat, 07 Mar 2009 00:00:00 +0000

ARBSEC 01 was a great success! Thanks for everyone who came out, Bar Louie for hosting, and dugsong for taking some pictures! Be sure to join us for future ARBSEC meetings, the first Wednesday of each month.

jose, grue, steiza, svowels, mattbing, and more.

honey, jono, olga, bfields, nuxi, and more.

Dropping some Barracuda 0-day!

ARBSEC Officially Launched

Thu, 19 Feb 2009 00:00:00 +0000

ARBSEC, a CitySec-style meetup for security professionals in the Ann Arbor area, has been officially launched! Our first meeting, ARBSEC 01, will be at 6:00pm on March 4th at Bar Louie in Ann Arbor.

What

An informal meetup of information security professionals in Ann Arbor. Unlike other meetups, you will not be expected to pay dues, "join up", or present a zero-day exploit to attend.

Where

ARBSEC 01 is held at Bar Louie, located at 401 E Liberty St, on the northeast corner of Liberty and Division. We’ll likely be in the back patio area.

dpkt Tutorial #3: DNS Spoofing

Sat, 20 Dec 2008 00:00:00 +0000

In our first and second dpkt tutorials, we looked at the simple construction and parsing of packets respectively. Our third tutorial combines both parsing and construction of packets in a single utility for performing DNS spoofing (a la dsniff’s dnsspoof).

dpkt is a sweet framework for creating and parsing packets. While dpkt doesn’t have much documentation, once you get the hang of using one module, the rest fall into place fairly easily. I’ll be doing a number of dpkt tutorials with simple tasks in hopes of providing some "documentation by example". If you have any tasks you’d like to see done in dpkt, drop me a line.

VirusTotal Python Submission Script

Thu, 20 Nov 2008 00:00:00 +0000

Here is a simple python script for batch malware submissions to VirusTotal via its email interface. Simply replace the SMTP-related variables at the top of the script and you’re ready to rock!

Download vtsubmit.py

#!/usr/bin/env python

# vtsubmit.py
# VirusTotal Submission Script
# Jon Oberheide <jon@oberheide.org>
# http://jon.oberheide.org

import os, sys, email, smtplib, hashlib

SMTP_HOST = '_HOST_'
SMTP_PORT = 587
SMTP_USER = '_USER_'
SMTP_PASS = '_PASS_'

TO_ADDR   = 'scan@virustotal.com'
FROM_ADDR = '_EMAIL_'

def main():
    if len(sys.argv) == 1:
    print 'please specify files to submit'
    sys.exit(1)

    filelist = sys.argv[1:]
    total = len(filelist)
    progress = 0

    for filename in filelist:
    progress += 1
    data = open(filename, 'rb').read()
    sha1 = hashlib.sha1(data).hexdigest()
    base = os.path.basename(filename)

    print '%d of %d: %s (%s)' % (progress, total, base, sha1)

    msg = email.MIMEMultipart.MIMEMultipart()
    msg['From'] = FROM_ADDR
    msg['To'] = TO_ADDR
    msg['Date'] = email.Utils.formatdate()
    msg['Subject'] = 'SCAN'

    part = email.MIMEBase.MIMEBase('application', 'octet-stream')
    part.set_payload(data)
    email.Encoders.encode_base64(part)
    part.add_header('Content-Disposition', 'attachment; filename="%s"' % base)
    msg.attach(part)

    smtp = smtplib.SMTP(host=SMTP_HOST, port=SMTP_PORT)
    if SMTP_USER and SMTP_PASS:
        smtp.starttls()
        smtp.login(SMTP_USER, SMTP_PASS)
    smtp.sendmail(FROM_ADDR, TO_ADDR, msg.as_string())
    smtp.close()

if __name__ == '__main__':
    main()

dpkt Tutorial #2: Parsing a PCAP File

Wed, 15 Oct 2008 00:00:00 +0000

As we showed in the first dpkt tutorial, dpkt makes it simple to construct packets. dpkt is equally useful for parsing packets and files, so in this second tutorial we will demonstrate parsing a PCAP file and the packets contained within it.

Bash Brace Expansion Cleverness

Thu, 04 Sep 2008 00:00:00 +0000

Brace expansion is a nice feature in the Bash interpreter that happened to be exactly what I needed during an audit. A good thing to log away in memory in case you ever find yourself in a pen-test environment with similar constraints.

Bash Command Injection

During an audit of a popular email appliance, I encountered a scenario where attacker controlled input was improperly sanitized and passed as the argument to a command in a shell interpreter. These vulnerabilities are quite common and most commonly result in the attacker being able to inject his own commands via the input vector which are then executed by the shell.

dpkt Tutorial #1: ICMP Echo

Mon, 25 Aug 2008 00:00:00 +0000

In this dpkt tutorial, I will demonstrate how to construct and send a simple ICMP echo packet.

Hardening DNS with IP TTLs

Sun, 10 Aug 2008 00:00:00 +0000

During Paul Vixie’s talk at WOOT on some of the operational challenges of deploying source port randomization functonality in BIND, I started thinking of a few simple ways to harden DNS infrastructure against VU#800113 by leveraging the IP TTL value.

DNS Cache Poisoning

In order to increase the resilience of DNS against Dan Kaminsky’s cache poisoning attack, source port randomization has been added to recursive DNS resolvers. Now, in addition to guessing the 16-bit TXID, the attacker must also guess the 16-bit source port that the resolver used for the particular query. While this greatly increases the amount of time the attacker must spend to successfully poison a cache, it does not completely resolve the problem.

HotSec 2008 and USENIX Security 2008

Sat, 02 Aug 2008 00:00:00 +0000

I’m back from San Jose finally and while I won’t be breaking down a full review of HotSec and USENIX Security like I did for WOOT, I thought I would point out some of the more interesting presentations I was able to attend.

HotSec 2008

Panic Passwords: Authenticating under Duress
Jeremy Clark and Urs Hengartner, University of Waterloo

Some interesting duress schemes were presented such as 5-dictionary (using 5 distinct words from dictionary to prevent from invalid keys being interpreted as a duress key).

WOOT 2008: The Good, The Bad, and The Ugly

Mon, 28 Jul 2008 00:00:00 +0000

Day one of my trip out to San Jose to attend the WOOT, HotSec, and USENIX Security trifecta is over. The 2nd Workshop on Offensive Technologies (WOOT) took place today and I’ll be breaking it down with "The Good, The Bad, and The Ugly".

I’ll be discussing a few of the presentations at WOOT today: the ones that peaked my interest (The Good), the ones that didn’t meet my expectations (The Bad), and the funny or miscellaneous topics that were discussed (The Ugly). WOOT started off on a good note with an impressive intro video from Tal and Paul Vixie speaking about some of the unexpected operational issues involved when enabling source port randomization for resolvers. The rest of the conference went smoothly and was on par with last year’s WOOT. I had to step out during the session with Giovanni’s phishing study and Elizabeth’s botnet-related paper, so I unfortunately won’t be able to comment on those presentations.

PDPT: Passive DNS Port Test

Mon, 21 Jul 2008 00:00:00 +0000

The Passive DNS Port Test (PDPT) tool acts as a passive DNS monitor to flag resolvers that may be vulnerable to the cache poisoning issue described in CERT VU #800113. Similar to OARC’s porttest, this monitor will judge the source port behavior of resolvers based on the standard deviation of observed source ports.

The Passive Approach

Another VU #800113-related testing tool? Of course, we’ve already seen a number of tools released to help administrators identify and patch vulnerable resolvers: Dan has the DNS Checker tool on his website to allow visitors to test their resolvers. OARC has the porttest service available to test the randomness of a specific resolver using dig. Niels has released a tool to test the randomness of the source ports and query ids of your resolver and an embeddable image to place on a website to test the resolvers of the site’s visitors. Jose Avila has released a tool to periodically dump the cache of a resolver and check for potential poisoning.

UofM-Specific Phishing Campaign

Mon, 21 Jul 2008 00:00:00 +0000

While receiving phishing emails in my University inbox is a common occurrence, a recent email caught my eye due to its increased sophistication and University-specific information.

Email Contents

Dear Umich.edu WEBLOGIN Subscriber

To complete your Umich.edu WEBLOGIN account, you must reply to this email
immediately and enter your password here (*********)

Failure to do this will immediately render your email address
deactivated from our database.

You can also confirm your email address by logging into your
Umich.edu WEBLOGIN account at https://weblogin.umich.edu/

Thank you for using Umich.edu!

THE Umich.edu TEAM

At first, this email appears to be a standard phishing template where the email receipient’s domain name is simply inserted in the appropriate places (eg. "Umich.edu"). These types of phishing email are very common and don’t require any special intelligence about the target.

Beware of Google App Engine SDK

Wed, 09 Apr 2008 00:00:00 +0000

An easily exploited vulnerability in Google App Engine’s SDK can put your development servers at risk. While this bug is trivial to fix, engineers at Google have declined to address the vulnerability, so be cautious when using the SDK to develop your web service.

The Vulnerability

The vulnerability exists in the mail API of the Google App Engine SDK, specifically in google/appengine/api/mail_stub.py:

def _SendSendmail(self, mime_message,
               popen=subprocess.Popen,
               sendmail_command='sendmail'):

 try:
   tos = [mime_message[to] for to in ['To', 'Cc', 'Bcc'] if mime_message[to]]
  sendmail_command = '%s %s' % (sendmail_command, ' '.join(tos))

   try:
   child = popen(sendmail_command,
               shell=True,
               stdin=subprocess.PIPE,
               stdout=subprocess.PIPE)

The code constructs the command line arguments that will be passed to sendmail and executed by the shell interpreter (eg. "/bin/sh -c ‘sendmail_command’"). Unfortunately, since the To/Cc/Bcc entries are not sanitized before the command line arguments are constructed, an attacker could specify a malicious input that causes the shell interpreter to execute any command the attacker desires.

Black Hat DC 2008 Briefings

Fri, 22 Feb 2008 00:00:00 +0000

Just arrived home from Washington, DC where I attended and presented at the Black Hat DC Briefings. I was fairly busy throughout the briefings and didn’t make it to as many presentations as I hoped, but I thought I’d detail a few of the more interesting ones.

Presentations of Interest

Cracking GSM
David Hulton and Steve, Pico Computing, Inc.

David and Steve’s presentation on GSM cracking definitely received the most attention of the briefings. While the A5/1 GSM cipher has seen its share of attacks in the past, the presenters showed how it could be cracked with a price tag accessibile to the average joe. Using about $1000 worth of equipment including a USPR (Universal Software Radio Peripheral) to capture the encrypted streams and FPGAs to do the actual cracking, they demonstrated that the A5/1 cipher could be cracked in about half an hour. Scaling the system up with more FPGAs results in even faster cracking time. Fun stuff, I need to get my hands on a USPR ASAP.

Exploiting Live Virtual Machine Migration

Sun, 10 Feb 2008 00:00:00 +0000

Later this week, I’ll be presenting at the Black Hat DC Briefings on weaknesses in the security of live virtual machine migration as implemented by popular vendors such as VMware and Xen. I thought I’d provide a teaser in advance of my presentation detailing some of the topics that will be discussed.

A Trip Down Memory Lane

If you take a look back at the past few years, we’ve seen a systematic breaking down of isolation boundaries within our computing platforms as new technologies such as virtualization are employed.

Detecting and Evading CWSandbox

Tue, 15 Jan 2008 00:00:00 +0000

CWSandbox is one of the most comprehensive and full featured platforms for automated malware analysis. In this post, we detail how a malware sample being analyzed by CWSandbox may detect and evade the monitoring functionality of CWSandbox in order to disguise its malicious activities.

Introduction to CWSandbox

CWSandbox is a platform developed by Sunbelt Software to automate the analysis of malware samples inside a controlled environment. It generates detailed reports of the runtime behavior of malware by monitoring the Win32 API calls a sample makes during its execution. In order for sandboxed environments such as CWSandbox to maintain their utility and accurately analyze modern malicious threats, it is imperative that they are hardened and resiliant against detection and fingerprinting. To detect the presence of CWSandbox, several vectors of detection of worthy of consideration:

xkcd Malware Visualization

Fri, 30 Nov 2007 00:00:00 +0000

A recent xkcd comic related to malware visualization is eerily similar to a system we’re currently running at the University of Michigan.

The xkcd Comic

Our System

The system pictured is a production version of an architecture we proposed last year at HotSec ‘07 (paper, presentation), essentially a network-based AV service. The backend analysis system consists of Xen-based virtualized containers which host various detection engines. Candidate executables/files are acquired by a lightweight host-agent (hooking CreateProcess on Win32, Dazuko on Linux/BSD, etc) and transmitted to the backend for analysis by a bajillion (ok, maybe only 12) antivirus and behavioral engines. We currently employ antivirus engines from Avast, AVG, BitDefender, ClamAV, F-Prot, F-Secure, Kaspersky, McAfee, Symantec and Trend Micro. We also have two behavior engines, Norman Sandbox Analyzer and CWSandbox, to provide runtime behavioral profiles for candidate executions. This model has numerous advantages including significantly increased detection coverage, centralized management, and post-infection forensics. The photo shows our beautiful 52" LCD screen displaying the output of the various Xen VMs hosting the detection engines and the real-time detection results of the analysis of a malware sample.

Facebook XSS

Wed, 15 Aug 2007 00:00:00 +0000

Facebook’s new-fangled applications functionality seemed like a ripe opportunity for nasty cross-site scripting bugs. As it turns out, multiple XSS vulnerabilities were present in the fb:swf tag of the Facebook Markup Language.

FBML XSS Vulnerabilities

Given that Facebook seems to roll out tons of new functionality all the time without proper security testing and auditing, I was sure there had to be at least a few holes. I finally got the motivation to do some bug hunting while at USENIX Security, where I met a student, Adrienne Felt, from University of Virginia who was presenting at the poster session about an XSS vuln she had found in Facebook. As she wasn’t releasing any specific technical details about the vulnerability since it was not yet patched, I found that motivation enough to head back to my hotel and hack on Facebook for the night to see if I could re-discover the hole she had found. In just a couple hours, I had discovered an XSS vulnerability, which I found out the next day was actually different that the one she had discovered.

USENIX Security, HotSec, WOOT 2007

Fri, 10 Aug 2007 00:00:00 +0000

I recently attended the USENIX Security Symposium in Boston, MA. I also attended two of the co-located workshops: the Workshop on Hot Topics in Security (HotSec), at which I presented a research paper focusing on a new paradigm for antivirus deployment, and the Workshop on Offensive Technologies (WOOT).

HotSec 2007 Workshop

At HotSec, I presented our paper titled "Rethinking Antivirus: Executable Analysis in the Network Cloud". The abstract follows:

Antivirus software installed on each end host in an organization has become the de-facto security mechanism used to defend against unwanted executables. We argue that the executable analysis currently provided by host-based antivirus software can be more efficiently and effectively provided as an in-cloud network service. Instead of running complex analysis software on every end host, we suggest that each end host run a lightweight process to acquire executables entering a system, send them into the network for analysis, and then run or quarantine them based on a threat report returned by the network service. An executable analysis service run inside an enterprise network or by a service provider could integrate antivirus software, behavioral simulation, and other analysis engines from multiple vendors providing better detection of malware and simplify client software enabling deployment on a broader range of devices. To explore this idea we construct a prototype composed of a Windows based host agent and an in-cloud analysis service and evaluate it using a diverse dataset of 5066 unique malicious executables. By correlating information between multiple detection engines, our system provides over 98% detection coverage of the malicious executables using eight antivirus engines and two behavioral engines compared to a 54% to 86% detection rate using the latest commercial antivirus products.

DIMVA 2007

Fri, 20 Jul 2007 00:00:00 +0000

I just got back from Switzerland, and despite numerous flight delays, cancellations, and lost luggage (thanks NWA!), it was a great trip. I presented some of my research at the Fourth International Conference on Detection of Intrusions and Malware and Vulnerability Assessment (DIMVA), and got to spend some vacation time in Zurich, Lucerne, and Milan, Italy.

Characterizing Dark DNS Behavior

The research I presented at DIMVA focused on the measurement of dark DNS, or the DNS queries associated with darknet addresses. Evidence of dark DNS activity has important implications with regards to darknet sensor deployments. Misconfiguration or improperi delegation of reverse DNS authority for darknet monitoring systems may allow evasion by an attacker via DNS reconnaissance. We characterized the dark DNS activity observed on a large operational network and presented a lightweight tool to complement existing network sensors and low-interaction honeypots by providing simple DNS services.

pynids 0.5a Update Released

Mon, 07 May 2007 00:00:00 +0000

pynids is a python wrapper for libnids, a Network Intrusion Detection System (NIDS) library offering sniffing, IP defragmentation, TCP stream reassembly and port scan detection. This release is an update to Michael Pomraning’s 0.5 release to allow control of libnid’s checksumming options.

Checksum Control

Many modern NICs provide both TX and RX checksum offloading for TCP and other protocols. This offloading functionality may cause the BPF tap utilized by libnids to observe packets with incorrect checksums, and drop legitimate packets during their processing, believing them to be invalid due to the incorrect checksum.

Cosign SSO Vulnerability

Thu, 12 Apr 2007 00:00:00 +0000

During an independent audit, I discovered a critical vulnerability in Cosign, a web-based single sign-on (SSO) platform which is currently in use at numerous large universities.

Introduction to Cosign

Cosign is a web-based single sign-on system, written at the University of Michigan as part of the National Science Foundation Middleware Initiative (NMI). Cosign is deployed extensively at the University of Michigan and at educational institutions and other organizations around the world.

T-Mobile WiFi Hotspots

Mon, 12 Feb 2007 00:00:00 +0000

Some random technical notes on the T-Mobile WiFi Hotspots offered at locations such as Starbucks. Since I spend a fair amount of time at the 24-hour Starbucks on Washtenaw, I often end up playing around with the Cisco WAP instead of actually doing work.

Cisco WAP Devices

The T-Mobile hotspots are powered by a WAP and access control device from Cisco. I attempted several times to social engineer my way into the back up a Starbucks to get a picture of the actual equipment, but to no avail. Before authentication, any HTTP requests to port 80 or 8080 are redirected to the T-Mobile hotspot portal via the HTTP 302 Redirect mechanism. After successful authentication, requests originated from an host with an authorized MAC and IP address tuple are allowed through.

RFID on Campus

Wed, 17 Jan 2007 00:00:00 +0000

Given my previous experience with the Mcard identification system at the University of Michigan, I was interested when I heard that RFID technology was being integrated into the Mcards. I will explore the Mcard RFID and other current uses of RFID on campus.

Mcard RFID

The Mcards distributed for the University of Michigan Health System (UMHS) contain RFID technology from HID Corp. HID’s Prox is a proximity-based access control system utilizing identification tags and readers that operate on the 125 khz frequency. The tags, often embedded in PVC ID cards, are passive and become active when entering the RF field of a reader. The range of the reader can vary anywhere from 0.5 inches to 8 feet depending on the model and its power output.

Aimject 1.0 Released

Fri, 24 Nov 2006 00:00:00 +0000

Aimject facilitates man-in-the-middle attacks against AOL Instant Messenger’s OSCAR protocol via a simple GTK interface. This 1.0 release brings Aimject functionality to the masses, being available for Linux, BSD, OS X, and Win32 platforms.

Introduction

Instant messaging and real-time network communication are becoming increasingly prevalent in both personal lives and the workplace. While recent events have brought IM privacy to the attention of mass media, security in most systems has not been properly addressed. Given the growing reliance on IM communication for a wide variety of purposes, focused investigation of potential security attacks is long overdue.

Google Safe Browsing

Mon, 13 Nov 2006 00:00:00 +0000

While Google’s Safe Browsing service has been available for some time via the Google Toolbar, this feature will see wide deployment with the release of Mozilla Corp’s Firefox 2. In this analysis, we will delve into the workings of Google’s Safe Browsing service and its integration with Firefox.

Safe Browsing

Google Safe Browsing (SB) is an initiative to curb malicious phishing activity by warning users when they navigate to a potential phishing site. Obviously, this requires some coordination with the user’s web browser. Currently, Firefox 1.x users can download the Google Toolbar and Firefox 2.x has native SB support. MSIE users cannot currently take advantage of Google’s SB service, but IE 7 has native phishing protection provided by Microsoft.

pybgpdump 0.1 Released

Fri, 22 Sep 2006 00:00:00 +0000

I’m happy to announce the availability of pybgpdump 0.1, a tool to assist in the rapid analysis of BGP routing datasets. It combines the functionality of libbgpdump and the ease of python to parse BGP messages from MRT dumps.

Features

Currently, analysis of BGP routing data is primarily done in C, using either libbgpdump (RIPE) or route_btoa (Labovitz). While effective in their own right, they lack the ease, speed, and simplicity of python development.

Mozilla Auto-Update Vulnerability

Fri, 15 Sep 2006 00:00:00 +0000

Mozilla’s auto-update system is a feature recently added to Firefox and Thunderbird that promises to bring prompt security updates to users without manual interaction. Unfortunately, this feature contains a vulnerability allowing attackers to hijack the update process and deliver malicious updates, resulting in the victim’s host being compromised.

Methodology

To check for updates, Firefox contacts aus2.mozilla.org over HTTPS and requests the following XML file:

/update/1/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/update.xml

This URL template is stored in the app.update.url preference. An example URL with the placeholders replaced with real values:

mPrint Privacy Violations

Thu, 31 Aug 2006 00:00:00 +0000

mPrint is a useful service provided by ITCS of the University of Michigan to allow web-uploaded documents to be printed on campus printers. Unfortunately, the designers of mPrint included several "features" that violate the privacy of its users without their knowledge.

Web Interface

Previously, mPrint consisted of a simple form to upload documents and select a printer to send the job to. This was an extremely useful service if a user had internet access but did not have any University printers locally configured on their computer.

Honeyd Remote Fingerprinting

Wed, 15 Feb 2006 00:00:00 +0000

Honeyd is a low-interaction honeypot developed by Niels Provos designed to emulate services and personalities of virtual hosts and networks. As honeypot deployments must remain undetected to maintain their value, the ability of an attacker to effectively and remotely fingerprint Honeyd is a serious issue.

IP Fragment Reassembly

According to the Internet Protocol specification (RFC 791), a correct IP stack implementation must identify corresponding fragments by matching the source address, destination address, identification number, and protocol number. However, Honeyd does not correctly follow RFC 791 and omits the protocol number when matching corresponding fragments for reassembly. The following code snippet is from Honeyd’s ipfrag.c:

Mcard Vulnerability

Wed, 06 Apr 2005 00:00:00 +0000

After investigating the security of the Mcard magnetic card system at the University of Michigan, which is used for student and faculty identification cards, I discovered that it is trivial to forge anyone’s Mcard given only their UMID/uniqname.

Introduction

The University of Michigan’s student/faculty identication cards, Mcards, are used for a variety of uses such as photo ID, meal plans, Entree Plus, TCF debit card, and access to dorms, computer labs, and other University buildings. Mcards are issued to incoming students and new faculty and staff when they join the University. They possess a magnetic strip on the back that is used by readers across the campus to authenticate the identity of the cardholder.

Wolverine Access Vulnerability

Sun, 25 Jul 2004 00:00:00 +0000

While arranging my class schedule at the University of Michigan, I discovered a vulnerability in Wolverine Access that allowed unrestricted access to the social security numbers, names, and addresses of every student in the University including recent alumni.

Introduction

Wolverine Access (WA) is the University of Michigan’s online records and registration system. It handles academic, financial, employment, and personal information of students, faculty, and staff. It is based on PeopleSoft software and maintained by MAIS. Most students utilize WA for class registration, financial information, and other academic resources.