home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack / bbshacking.txt < prev    next >
Encoding:
Text File  |  1997-09-25  |  4.2 KB  |  94 lines
  1.                                 .oO Phrack 50 Oo.
  2.  
  3.                             Volume Seven, Issue Fifty
  4.  
  5.                                      3 of 16
  6.  
  7.  
  8.                              //   //  /\   //   ====
  9.                             //   //  //\\ //   ====
  10.                            ==== //  //  \\/   ====
  11.  
  12.                        /\   //  // \\    //  /===   ====
  13.                       //\\ //  //   //  //   \=\   ====
  14.                      //  \\/    \\ //  //   ===/  ====
  15.  
  16. ------------------------------------------------------------------------------
  17.  
  18.                                 ----<>----
  19.  
  20.  
  21.                             =--=--=--=--=--=--=--=
  22.                              Portable BBS Hacking
  23.                                   by: Khelbin
  24.                             =--=--=--=--=--=--=--=
  25.  
  26.  
  27.      This hack basically has little to do with the BBS software itself but
  28. with the archiver which is being used.  I've used this technique on a 
  29. mock Renegade setup and with pkzip/pkunzip as the archiver.  I'm sure
  30. that this same type of technique will be successful on many other BBS
  31. platforms and with other archivers as well.  While explaining this, I will
  32. use Renegade and pkzip/pkunzip as my example.
  33.  
  34.     A Renegade setup is most likely vulnerable if it will pkunzip any user
  35. supplied zipfile.  This is because Renegade's default command to unzip files
  36. is "pkunzip -do <filename>".  The -d flag unzips the file retaining any
  37. directories which were included into the zip file and the -o flag will 
  38. automatically overwrite any file. 
  39.  
  40.     Suppose the remote system is also setup in a normal Renegade fashion.
  41. Let's use this file tree as an example:
  42.  
  43.      C:\RENEGADE\
  44.      C:\RENEGADE\TEMP\
  45.      C:\RENEGADE\DATA\            
  46.  
  47.     The other subdirectories are unimportant for our discussion.  Suppose 
  48. that C:\TEMP is where our uploaded file will go for it to be unzipped and
  49. then scanned for viruses.  C:\RENEGADE\DATA\ is where the USERS.DAT file 
  50. is stored, containing all the users login information.  
  51.  
  52.      Wouldn't it be nice if we could put our own USERS.DAT in there instead?
  53. To do this, you must first generate a USERS.DAT file.  This is easy enough.
  54. Just download a copy of Renegade which is the same version as the target
  55. machine and then use the user editor to make a "SYSOP" account with the 
  56. password "SYSOP" (this should be the default anyway on the USERS.DAT file).
  57.  
  58.      Here's how we prepare the zipfile on our own machine:
  59.  
  60.          C:\>md tmp
  61.          C:\>md c:\tmp\ddsdata
  62.          C:\>copy c:\renegade\data\users.dat c:\tmp\ddsdata
  63.          C:\>cd tmp
  64.          C:\TMP>pkzip -pr evil.zip
  65.  
  66.      Now we get out our trusty hex editor and edit evil.zip.  Change every
  67. occurrence of "ddsdata" in evil.zip to read "../data" and make sure that the
  68. slash is a forward-slash and not a back-slash.  Now when you upload
  69. evil.zip to this particular BBS, it will expand to "../data/users.dat"
  70. and your USERS.DAT file will overwrite their USERS.DAT file since the -od
  71. flag is default on Renegade.  
  72.  
  73.      Now you can login as SYSOP with a password SYSOP and do as you please. 
  74. You could also overwrite virtually any file on a BBS like this and believe 
  75. me,  many do have this vulnerability or something very close to it.  You are 
  76. only limited in how much you can traverse up and down directories by DOS's 
  77. maximum file length of 12 (8 plus "." plus 3 = 12).  I quickly tried 
  78. inserting a few blocks into the zipfile in order to produce a limitless 
  79. amount of traversing which but it seemed to corrupt the file for some 
  80. reason.
  81.  
  82.      Removing the -o flag is not a fix for this bug.  Without the -o flag,
  83. you can "hang" the system in a denial of service attack.  By again hex 
  84. editing the names of the files within your evil.zip, you can make it have 
  85. two files with the same name.  When it tries to unzip the second file, it 
  86. will prompt locally whether to overwrite the file or not and "hang" the 
  87. board.  Instead, the -d flag is what should be removed.
  88.  
  89.      This is just an example as I'm sure many other BBS systems do this same
  90. type of uncompressing.  I'd also bet that arj, lha, and several others, can
  91. also be hex edited and yield similar results.  Either way, it's either take
  92. out the "restore/create directories within archive" option or pay the price.
  93.  
  94.