Phorum 3.07 web discussion software contains several remotely exploitable bugs. Exploit descriptions included.
cf490e7895b940713553a4fd62059908660ec4bb33612ba41f669aa211443eed<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<HTML>
<HEAD>
<META CONTENT="text/html; charset=iso-8859-1" HTTP-EQUIV="Content-Type">
<META NAME="GENERATOR" CONTENT="Mozilla/4.5 [es] (Win95; I) [Netscape]">
</HEAD>
<BODY BGCOLOR="#000000" VLINK="#66FFFF" TEXT="#33CCFF" LINK="#66FFFF" ALINK="#FFFFFF">
<TABLE WIDTH="90%" COLS="2" CELLSPACING="0" BORDER="0" CELLPADDING="0">
<TR>
<TD WIDTH="10%"></TD>
<TD WIDTH="90%">
<CENTER><B><U><FONT SIZE="+2">Phorum 3.0.7 vulnerabilities</FONT></U></B>
<BR><B><U><FONT SIZE="+1">by Jfs</FONT></U></B></CENTER>
<P> 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...
<P> 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 (<I><A HREF="https://www.phorum.org/">https://www.phorum.org</A></I>),
which uses PHP and an SQL backend.
<P> 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.
<P> 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.
<P> My test box was a Linux Slackware 4.0, running
Apache 1.3.9 with the PHP 3.0.12 module.
<P>Let's get to it...
<P><B><U><FONT SIZE="+1">Admin.php3</FONT></U></B>
<P> 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:
<P>e.g. to change the master password to 'flow':
<P>https://www.example.com/admin.php3?step=4&option=pass&confirm=flow&newPssword=flow
<P> 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:
<P>../../../../../../../../../../../file/to/view
<P>e.g.:
<BR>../../../../../../../../../../../etc/passwd
<P>reload the admin.php3 page and the file you have specified will be displayed
on screen.
<P> 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.
<P>Go into the "Master Settings" function and change the "down page name"
field to:
<P>https://site.to.redirect.to?
<P> 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? :)
<P> Then we just put Phorum down using the admin
interface and the redirection is in effect.
<P><B><U><FONT SIZE="+1">Auth.php3</FONT></U></B>
<P> 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
<BR>any user called "boogieman" to override the authentication process,
thus allowing the user access to any restricted webpage without a valid
password.
<P>We just need to append the "PHP_AUTH_USER=boogieman" value pair to the
restricted webpage URL we are tying to access, e.g:
<P>www.example.com/index.php3?PHP_AUTH_USER=boogieman
<BR>www.example.com/admin.php3?PHP_AUTH_USER=boogieman
<BR>...
<P>As we can see, it is pointless to protect the admin.php3 scripts using
the facilities of auth.php3.
<P><B><U><FONT SIZE="+1">Code.php3</FONT></U></B>
<P> 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
<BR>case she's probably removed the code.php3 script], other files that
reside on the same directory (for mkdir afraid admins :)), etc.
<P>www.example.com/code.php3?file_to_view
<P>e.g.
<P>www.example.com/code.php3?common.inc
<BR>www.example.com/code.php3?index.shtml
<P><B><U><FONT SIZE="+1">Upgrade.php3</FONT></U></B>
<P> 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.
<P><B><U><FONT SIZE="+1">Read.php3 (et al.)</FONT></U></B>
<P> 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.
<BR> 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.
<P>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.
<P>So, to run the SQL command "DROP TABLE x", we will use:
<P>www.example.com/read.php3?num=1&action=3&sSQL=DROP%20TABLE%20x
<P>To run this command the Phorum needs to have (at least) one active Phorum.
<P><B><U><FONT SIZE="+1">Violation.php3</FONT></U></B>
<P> 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
:?
<P>The syntax will be:
<P>www.example.com/violation.php3?Mod=address@to.spam&ForumName=text_to_sam
<P><B><U><FONT SIZE="+1">Workarounds</FONT></U></B>
<P>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
:)
<P>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.
<P>1.) Remove the files you don't need (code.php3,), and restrict the ones
that aren't public (admin.php3, stats.php3, upgrade.php3).
<P>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 :)
<P>3.) Apply the patch you will find at the end of this document.
<P>4.) Wait till a fixed version of Phorum is available and upgrade.
<P><B><U><FONT SIZE="+1">How could this happen?</FONT></U></B>
<P> 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
<BR>so in a way that doesn't stop us from sticking our own arbitrary values
in those variables.
<P>Check the "PHP" article at https://hispahack.ccc.de for an extensive
explanation on how this works and how to assign arbitrary values to PHP
variables.
<P>For the backdoor problem... well, in a perfect world you should read
the source code of anything you install in your machine :)
<P>Cheers,
<P>Jfs jfs@gibnet.gi
<BR>https://hispahack.ccc.de/
<BR>.
<P><B><U><FONT SIZE="+1">Appendix: phorum patch</FONT></U></B>
<P>These patch doesn't fix the admin.php3 or upgrade.php3 problems, restrict
access to these files.
<P>Run the following command inside the directory where your phorum scripts
are:
<P>$ patch -p1 < phorum.diff
<P>Download path "<I><A HREF="https://hispahack.ccc.de/en/phorum.diff">phorum.diff</A></I>"
<BR>
<BR>
<BR>
<BR>
<TABLE WIDTH="100%" COLS="1" CELLSPACING="0" BORDER="0" CELLPADDING="0">
<TR>
<TD></TD>
</TR>
</TABLE>
<CENTER><FONT SIZE="-1"> (C) 1997-2001 by !Hispahack </FONT>
<BR><FONT SIZE="-1">
Para ver el web en las mejores condiciones, usa una resolución de
800x600 y Netscape Navigator</FONT></CENTER>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed