Re: Linux Kernel Exploits / ABFrag

[Erik Sperling Johansen <erik () sperling no>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 21 October 2002 18:16, Curt Wilson wrote:

> I'm wondering if there is any way to determine the burneye options used by
> analyzing the encrypted file? I doubt it, but does anyone have any
> experience with this?

To a degree that will be possible. Not the password ofcourse, but whether the 
file uses a host fingerprint e.g. could be determined. 

> Looks like we need to get brute forcing that password (could be nearly
> impossible), or perhaps find a good reverse engineer. I recall reading
> material by Dave Dittrich about trying to reverse engineer the x2 SSH
> exploit that had been protected with burneye. I also came across an
> article somewhere, perhaps on the teso website, that talked about the
> sorry state of the "white hat" reverse engineers. Personally, I could not
> reverse engineer myself out of a wet paper bag.
>
> I'm very curious to learn more about this exploit, and would enjoy seeing
> the IDS activity discussed in the first message in this thread. Do we have
> enough to make a snort signature? Did you get an image of the systems
> memory at the time of the exploit? Perhaps there is a snowballs chance in
> hell that the password used to run the executable could be recovered.

I've been working on reversing this "exploit" and burneye itself a few days 
now, but as far as I can see there's no logic flaws nor backdoors in burneye, 
thus leaving the option of bruteforcing.

Burneye basically did this to ABfrags:
- - SHA1 hash the password
- - Grab 20 bytes from /dev/urandom, xor with password hash
- - SHA1 this new 20-byte value and get a new hash
- - Use this new hash to RC4 encrypt the interesting parts of the binary
- - Apply an obfuscation layer using a 4-byte key (from /dev/urandom) embedded 
in the encrypted file.

When decrypting, the binary runs through the same process except it decrypts 
data. Decrypted data is run through a SHA1, and the 4 first bytes of this 
hash is compared to a value embedded in the binary, to avoid running junk 
code in case the password is incorrect.

The outer obfuscation layer and the debugger check (int 3 with signal handler) 
is easily removed, but from that point on it's a question of finding a 
160-bit key, which isn't really an option.

I have still got some work left to do on this tool, looking for possible 
backdoors/logic glitches, or keyspace limiting factors, but at the moment it 
appears that burneye does the job it's intended to do.


A memory dump would definitely help though, as there's no "on-demand" 
encryption/decryption, and a working binary could be reconstructed from a 
memory dump. But given only the binary I tend to belive It'll be very hard 
getting past this one.


- --Erik S. Johansen

- -- 
PGP Key: http://www.sperling.no/erik.key / pgpkeys.mit.edu
Fingerprint: 0745 BF47 DFCD 8A1F 1432  DCF3 76CF 66F6 E840 A1B0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9tIvSds9m9uhAobARAoSVAJ9NLA8yFTlUkheUyJd6Ip4teq3rqQCguXPa
epgpVJdMJP56lkqhyND4BFI=
=6X3k
-----END PGP SIGNATURE-----

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com