Security Incidents mailing list archives
Re: Linux Kernel Exploits / ABFrag
From: Erik Sperling Johansen <erik () sperling no>
Date: Tue, 22 Oct 2002 01:20:45 +0200
-----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
Current thread:
- Linux Kernel Exploits / ABFrag daniel . roberts (Oct 16)
- Re: Linux Kernel Exploits / ABFrag eax (Oct 17)
- Re: Linux Kernel Exploits / ABFrag dr john halewood (Oct 17)
- <Possible follow-ups>
- Re: Linux Kernel Exploits / ABFrag Christopher Wagner (Oct 17)
- Re: Linux Kernel Exploits / ABFrag Ali Saifullah Khan (Oct 18)
- Re: Linux Kernel Exploits / ABFrag Benjamin Krueger (Oct 18)
- Re: Linux Kernel Exploits / ABFrag Curt Wilson (Oct 21)
- Re: Linux Kernel Exploits / ABFrag h2g . sec . list (Oct 21)
- Re: Linux Kernel Exploits / ABFrag Erik Sperling Johansen (Oct 21)