.oO Phrack 50 Oo. Volume Seven, Issue Fifty 3 of 16 // // /\ // ==== // // //\\ // ==== ==== // // \\/ ==== /\ // // \\ // /=== ==== //\\ // // // // \=\ ==== // \\/ \\ // // ===/ ==== ------------------------------------------------------------------------------ ----<>---- =--=--=--=--=--=--=--= Portable BBS Hacking by: Khelbin =--=--=--=--=--=--=--= This hack basically has little to do with the BBS software itself but with the archiver which is being used. I've used this technique on a mock Renegade setup and with pkzip/pkunzip as the archiver. I'm sure that this same type of technique will be successful on many other BBS platforms and with other archivers as well. While explaining this, I will use Renegade and pkzip/pkunzip as my example. A Renegade setup is most likely vulnerable if it will pkunzip any user supplied zipfile. This is because Renegade's default command to unzip files is "pkunzip -do ". The -d flag unzips the file retaining any directories which were included into the zip file and the -o flag will automatically overwrite any file. Suppose the remote system is also setup in a normal Renegade fashion. Let's use this file tree as an example: C:\RENEGADE\ C:\RENEGADE\TEMP\ C:\RENEGADE\DATA\ The other subdirectories are unimportant for our discussion. Suppose that C:\TEMP is where our uploaded file will go for it to be unzipped and then scanned for viruses. C:\RENEGADE\DATA\ is where the USERS.DAT file is stored, containing all the users login information. Wouldn't it be nice if we could put our own USERS.DAT in there instead? To do this, you must first generate a USERS.DAT file. This is easy enough. Just download a copy of Renegade which is the same version as the target machine and then use the user editor to make a "SYSOP" account with the password "SYSOP" (this should be the default anyway on the USERS.DAT file). Here's how we prepare the zipfile on our own machine: C:\>md tmp C:\>md c:\tmp\ddsdata C:\>copy c:\renegade\data\users.dat c:\tmp\ddsdata C:\>cd tmp C:\TMP>pkzip -pr evil.zip Now we get out our trusty hex editor and edit evil.zip. Change every occurrence of "ddsdata" in evil.zip to read "../data" and make sure that the slash is a forward-slash and not a back-slash. Now when you upload evil.zip to this particular BBS, it will expand to "../data/users.dat" and your USERS.DAT file will overwrite their USERS.DAT file since the -od flag is default on Renegade. Now you can login as SYSOP with a password SYSOP and do as you please. You could also overwrite virtually any file on a BBS like this and believe me, many do have this vulnerability or something very close to it. You are only limited in how much you can traverse up and down directories by DOS's maximum file length of 12 (8 plus "." plus 3 = 12). I quickly tried inserting a few blocks into the zipfile in order to produce a limitless amount of traversing which but it seemed to corrupt the file for some reason. Removing the -o flag is not a fix for this bug. Without the -o flag, you can "hang" the system in a denial of service attack. By again hex editing the names of the files within your evil.zip, you can make it have two files with the same name. When it tries to unzip the second file, it will prompt locally whether to overwrite the file or not and "hang" the board. Instead, the -d flag is what should be removed. This is just an example as I'm sure many other BBS systems do this same type of uncompressing. I'd also bet that arj, lha, and several others, can also be hex edited and yield similar results. Either way, it's either take out the "restore/create directories within archive" option or pay the price.