-----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
This archive was generated by hypermail 2b30 : Mon Oct 21 2002 - 17:48:11 PDT