It seems that after we have digested the portal hype, message boards are starting to bloom in nearly any webpage you can think of, as the "cool" way to offer support, get people to flame each other to death, etc. apart from getting your banners more hits than ever before...

     After the wwwboard.pl problems, people started to look for more serious ways of offering message boards, one of which is [supposedly] the widely used Phorum (http://www.phorum.org), which uses PHP and an SQL backend.

     First of all, the phorum distribution comes with a security.txt file, read through it as it is good stuff, not that it covers all of the below outlined attacks, but it does a REALLY good job at protecting your vanilla installation.

     However, the Phorum distribution has some holes open for exploitation. Below you will find a more or less detailed description of some of these problems. This article is based on my findings in a Phorum 3.0.7 installation (latest version as of this writing). Problems could or could not apply to older versions, I haven't tested them, let me know if you check other Phorum releases for these bugs, so this document gets updated.

     My test box was a Linux Slackware 4.0, running Apache 1.3.9 with the PHP 3.0.12 module.

Let's get to it...

Admin.php3

     The admin.php3 script is used to manage the master installation as well as the forums you may create. It requires a password to access its functions, though a trick allows us to change the password to anything we want without requiring any authentication:

e.g. to change the master password to 'flow':

http://www.example.com/admin.php3?step=4&option=pass&confirm=flow&newPssword=flow

     Once we have access to the administrative functions, it is trivial to read any file [the  user running the http server has access to] in the server. Go into the "Master Settings" function and change the "default .langfile name" field to:

../../../../../../../../../../../file/to/view

e.g.:
../../../../../../../../../../../etc/passwd

reload the admin.php3 page and the file you have specified will be displayed on screen.

     The admin interface allows us to shutdown "Phorum", allowing us to specify a file that should be displayed indicating that the forums are down. Whenever it is down, Phorum uses a "Location" http header to redirect the users to the "down" page. The name of this "down" page can be changed using the admin page, as Phorum uses a relative URL by default, it is thus possible to redirect the whole phorum to any arbitrary URL.

Go into the "Master Settings" function and change the "down page name" field to:

http://site.to.redirect.to?

     The question mark is required, as Phorum appends an extension (default .php3) to the file name, and we don't need this on our redirected server, do we? :)

     Then we just put Phorum down using the admin interface and the redirection is in effect.

Auth.php3

     Phorum provides a facility to restrict access to parts of the phorum (posting, reading, whole site...) by means of the auth.php3 file. There is an explicit backdoor in the auth.php3 script, which allows
any user called "boogieman" to override the authentication process, thus allowing the user access to any restricted webpage without a valid password.

We just need to append the "PHP_AUTH_USER=boogieman" value pair to the restricted webpage URL we are tying to access, e.g:

www.example.com/index.php3?PHP_AUTH_USER=boogieman
www.example.com/admin.php3?PHP_AUTH_USER=boogieman
...

As we can see, it is pointless to protect the admin.php3 scripts using the facilities of auth.php3.

Code.php3

     The Phorum distribution comes with a file that probably slipped out of the Phorum website and, I suppose, was never intended to be released in the distribution. This file is code.php3, which accepts a parameter. If the parameter is a filename of the phorum directory, its contents will be shamelessly displayed. The script does a good job at checking that we can't get out of the current directory, so we can only check for any changes the administrator has made to the source of the php scripts [in which
case she's probably removed the code.php3 script], other files that reside on the same directory (for mkdir afraid admins :)), etc.

www.example.com/code.php3?file_to_view

e.g.

www.example.com/code.php3?common.inc
www.example.com/code.php3?index.shtml

Upgrade.php3

     We also find this tiny script, which is used to migrate between Phorum 1.x and Phorum 3.x installations. It allows us to specify (without any kind of authentication) the tables we want upgraded and the destination tables. Haven't played much with this, but it could be possible to mess up the phorum tables.

Read.php3 (et al.)

     Phorum's strongest point is that it uses an SQL backend (PostgreSQL or MySQL) to store the posts, which allows it to scale pretty well (e.g. the best linux distribution website phorum has more than 15k posts and it works fine). The main problem is that Phorum performs nearly no input checking for most of the variables the scripts pass to SQL queries.
     So we can use it to run any arbitrary SQL command on the server. We won't probably receive much output, but we can still  use it to CREATe/DROP tables, do INSERTs, PostGreSQL COPYs, etc. Can't speak much of the MySQL interface, but using PGSQL there's no way [that I can see] to run an arbitrary command on the remote server.

For the examples I'll use the read.php3 script, but there probably are others that will allow you to do the same sort of stuff.

So, to run the SQL command "DROP TABLE x", we will use:

www.example.com/read.php3?num=1&action=3&sSQL=DROP%20TABLE%20x

To run this command the Phorum needs to have (at least) one active Phorum.

Violation.php3

     For completeness, there is another minor bug that allows anyone to send e-mail using the violation.php3 script, without any kind of authentication. However, bear in mind that the e-mail sent has your [proxy] ip and fqdn in it. This could perhaps be used for spam :?

The syntax will be:

www.example.com/violation.php3?Mod=address@to.spam&ForumName=text_to_sam

Workarounds

0.) First of all, please follow the instruction on security.txt fromthe Phorum distribution. Most of the sites I've seen didn't follow them, and stored the configuration inside the web document root (including the password), waiting for anyone out there to download it using their favorite browser :)

Check the "IV) Securing the Admin Script" section, and the section talking on how you should separate your phorum database from the other "critical" databases on your system, as well as using a dedicated username and password for the phorum database.

1.) Remove the files you don't need (code.php3,), and restrict the ones that aren't public (admin.php3, stats.php3, upgrade.php3).

2.) PHP has some built-in security features, like the ability to restrict the files you can access to the ones inside your htdocs directory. Use them :)

3.) Apply the patch you will find at the end of this document. 

4.) Wait till a fixed version of Phorum is available and upgrade.

How could this happen?

     The main problem is that if a PHP script doesn't define a variable that is used in the script, and we pass this variable using a GET/POST method we can set the value of this variable, thus making the script behave in a strange way :) Phorum defines most of the variables it uses in common.inc, but does
so in a way that doesn't stop us from sticking our own arbitrary values in those variables.

Check the "PHP" article at http://hispahack.ccc.de for an extensive explanation on how this works and how to assign arbitrary values to PHP variables.

For the backdoor problem... well, in a perfect world you should read the source code of anything you install in your machine :)

Cheers,

Jfs jfs@gibnet.gi
http://hispahack.ccc.de/
.

Appendix: phorum patch

These patch doesn't fix the admin.php3 or upgrade.php3 problems, restrict access to these files.

Run the following command inside the directory where your phorum scripts are:

$ patch -p1 < phorum.diff

Download path "phorum.diff"