COMMAND
WWWBoard
SYSTEMS AFFECTED
Systems running wwwboard.pl
PROBLEM
David Weins found following. By following WWWBoards install
instructions exactly, you can leave yourself open to the risk of
possible abuse through the wwwadmin.pl script. Matt Wright was
at least smart enough to include some type of username/password
checking, but he didn't have the idea to force the wwwboard
administrator to pick/create a password for the webadmin account
before the board would work. Instead he created a default
account:
Username: WebAdmin
Password: WebBoard
Well, at least he does suggest that you change this password the
first time you login into wwwadmin. Now most people are smart
enough to change the default password to something at least
halfway more secure, but thanks to Matt Wright your new password
is written into passwd.txt and it has to remain readable/writeable
for the server to change the file. The password in this file is
at leasted encrypted with crypt, but just being able to view the
file will allow a cracker to sit down and run a dictionary crack
against it.
SOLUTION
If you haven't looked over the scripts or at least read the entire
ADMIN_README file to begin with (which you should do when you
download any program) you can see that there is a variable to
where to store/name the password file. This variable is called
$passwd_file. Since the file needs to be open to writings and
readings your best bet would be to move the file into a directory
where it cannot be access from via the world wide web. You can
do this easily by changing the $passwd_file variable from
passwd.txt to "/path/to/non-web/dir/brdpass.txt" -- then rename
passwd.txt to brdpass.txt and move into that directory. It at
least provides you with a little more security than this insecure
program does for you, or even suggests for you.
Sometimes you won't be able to do this - for example if your home
directory is your htdocs directory, which is the case for some
ISPs. A workaround is to prevent the web server from returning
the passwd.txt file, whilst still permitting the file to be
read/written by the CGI script. In Apache you'd configure this
as follows:
<Files passwd.txt>
deny from all
</Files>
or put it in some directory inside your web home and configure
<Limit GET>
deny from all
</Limit>
<Limit POST>
deny from all
</Limit>
for this directory. It's more safe, because some text editors
leave backup copy of the file, for example passwd.txt~. In this
case you are safe even if you forget to remove this file.
However, you should not use <Limit...> unless for some reason you
want your security to only apply to GET and POST methods.
The CyberArmy webmaster has patched most of WWWBoard's holes and
added some of his own features. You can find it at:
http://www.cyberarmy.com/search/jump.cgi?ID=698
http://www.cyberarmy.com/search/Programming/Releases/CyberArmy/Mr_Fong_Device/
It seems most of the wholes resulted in denial of service attacks.