home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hacks & Cracks
/
Hacks_and_Cracks.iso
/
hackersclub
/
km
/
library
/
hack
/
bbshacking.txt
< prev
next >
Wrap
Text File
|
1998-03-25
|
4KB
|
94 lines
.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 <filename>". 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.