Multiple vulnerabilities in PHPKIT

Advisory Content :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hardened PHP Project
www.hardened-php.net

-= Security Advisory =-

Advisory: Multiple vulnerabilities in PHPKIT
Release Date: 2005/11/07
Last Modified: 2005/11/04
Author: Christopher Kunz <christopher.kunz (at) hardened-php (dot)
net [email concealed]>
Application: PHPKIT 1.6.1 R2 and prior
Severity: Cross-Site Scripting, SQL injection and information
disclosure, password hash disclosure, local file
disclosure, arbitrary code execution
Risk: High / Critical (depending on server configuration)
Vendor Status: No fix available
References: http://www.hardened-php.net/advisory_212005.80.html

Overview:

PHPKIT [1] is a combined content management, homepage building and
community
software written in PHP. Although it is available as open source, it has
to be licensed for any other than private use. PHPKIT has the usual
feat-
ures for that kind of product (content editing, forums, user management,
etc.). Typically for content management and portal systems, there are
multiple vulnerabilities in several places in the front- and backend.
The install base for PHPKIT can only be estimated - Google shows about
25,000 results for the query "powered by phpkit" [2].
Since we did not perform a full audit, there is no guarantee that the
de-
scribed vulnerabilities are the only ones in the product.

Details:

1) XSS
Although the PHPKIT team seems to have made an effort to mitigate
attacks
with cross-site scripting, this was only partially successful. We
found
a number of critical XSS holes that can be exploited by any third
party
to steal admin cookies, change HTML code, launch CSRF attacks and so
on.

1.1) login/profile.php and login/userinfo.php
Two fields in the profile settings - those for AIM and Yahoo!
screen
names - are inserted into the database without any input
validation.
Thus, an XSS attack can be performed that is launched on any user
who
looks at the offending profile.
The same attack can be launched on an administrator viewing a profile
via the administrator back-end.

1.2) admin/admin.php (with register_globals On)
Since the variable $site_body is not properly initialized, an
attacker
can launch an XSS attack against the administrator login screen.
This
attack can utilize DOM to steal the administrator's credentials in
cleartext as long as they have some kind of "password safe"
function
in their browser. Since script code can be executed on load, all
that
an attacker has to do is get the administrator to click on a
manipula-
ted link.

1.3) Referrer statistics
By launching a HTTP request with the Referer set to some script
code,
e.g. <script>alert('foo')</script>, an attacker prompts this code
to
be included in the administrative backend, and executed as soon as
an administrator views the referrer statistics. This comes in handy
since it is a quasi-anonymous way of obtaining the administrator's
session cookies.

1.4) Forum
Although input filtering takes place in the subject and content of
a forum postings, no such filtering is performed when constructing
the HTML <title> tag and the logo's <img alt> attribute - both con-
tain the thread subject in unfiltered HTML, and script code is
execu-
ted twice per page.

1.5) imcenter.php
PHPKIT's own instant messaging system does not perform input
validation
on the subject line, so any user can IM the admin and contain
script
code in the subject.

1.6) Guestbook
The "Homepage" input field in the guest book is not properly
sanitized
and any guest (no logged-in users, because their home page is not
dis-
played by default) can enter script code. As usual, this is
displayed
as soon as the guestbook is viewed.

2) SQL Injection
Same as above: Although many places inside the PHPKIT software are
not
prone to SQL injection, some are. This leads to information
disclosure
and possibly deletion of arbitrary data in the database.

2.1) SQL injection in profile pages (with magic_quotes_gpc Off)
Using a simple injection, any user of the PHPKIT-powered web site
can
disclose the administrator's password hash. This is done via the
$id
parameter in login/userinfo.php which is not properly sanitized.
With
a crafted UNION statement, the attacker can obtain arbitrary data,
in-
cluding but not limited to any user's password hash. A simple cast
into
an int would have prevented this problem.
Example:
include.php?path=login/userinfo.php&id='%20UNION%20SELECT%201,

1,user_pw,1,1,1,1,1,1,1,1,1,1,1,1,user_pw,1,1,1,1,1,1,1,1,1,1,1,1,1,1,

1,1,1,1,1,1%20FROM%20phpkit_user%20where%20%20user_id=1%20and%20'1'='1

2.2) PHPKITSID
Since sessions are contained within the database, an attacker can
craft
a session ID to contain SQL commands (which have to be exactly 32
Bytes
in length, though. The vulnerable code is directly in include.php:
if(isset($_REQUEST['PHPKITSID']))
$session=$DB->fetch_array($DB->query("SELECT session_id,
session_userid FROM ".$db_tab['session']." WHERE
session_id='".$_REQUEST['PHPKITSID']."' LIMIT 1"));
This SELECT yields one result which is then fed to another SQL
query:
$DB->query("DELETE FROM ".$db_tab['session']." WHERE
session_id='"
.$session['session_id']."' LIMIT 1");
Using a carefully-crafted SQL statement, arbitrary data rows can be
deleted from the database.

3) Arbitrary local file inclusion and local code execution
Using the vulnerable path parameter that is used in nearly every
subsys-
tem of PHPKIT, an attacker can include arbitrary files on the local
file
system. This includes uploaded avatars (preferrably in PNG format)
that
can also include PHP code. Uploading avatars is not enabled in the
default configuration, so this attack vector is unlikely to be open
in
every PHPKIT installation in the wild.
Example: echo "<?php phpinfo() ?>" >> avatar.png
/phpkit/?path=../images/avatar/avauser_1.png%00

4) Remote code execution (with register_globals On)
Yeah, we saved the best for last. Since PHPKIT relies heavily on
eval()
for its homegrown template engine, an attacker only needs a way to
inject
a variable in curly braces including PHP code. With register_globals
set
to On (which is still the case in a lot of installations, for
compati-
bility purposes), this can be accomplished via the help function that
makes use of not properly initialized variables. Thus, any PHP code
can
be executed.
There is a number of other places, including the admin backend, that
are
vulnerable to this kind of code injection. These vulnerabilities are
either exploitable via complex syntax (a.k.a. curly braces) or, if
magic_
quotes_gpc is turned Off, with any code that includes "".
The whole template system urgently needs to be rewritten from
scratch,
without relying on unsafe variables and with careful consideration
for
register_globals.

Proof of Concept:

Apart from the examples mentioned above, the Hardened PHP Project is not
going to release any PoC for these vulnerabilities to the public.

Disclosure Timeline:

30. September 2005 - Vendor informed.
05. October 2005 - Vendor contacted via phone. Advisory re-sent
(allegedly
lost in transit).
16. October 2005 - Vendor informed of intended disclosure timeline.
07. November 2005 - public disclosure at the 2005 International PHP
Confer-
ence.

Credits:

Credit for the vulnerabilities listed in 4) goes to Stefan Esser of the
Hardened-PHP team.
Credit for the vulnerability described in 2.2) goes to Stefan Walk.
Credit for the vulnerability named 1.2) goes to Johann-Peter Hartmann.
All other vulnerabilities were investigated by the author.

Recommendation:

With the aforementioned lack in vendor reaction, we currently recommend
avoiding usage of PHPKIT altogether.
If you already use the product, we recommend installing the
Hardening-Patch
for PHP which can be obtained on our website, and deactivating the
"register_globals" setting in php.ini, virtual host configuration or
.htaccess.

References:

[1] http://www.phpkit.de/
[2] http://www.google.com/search?q=%22powered+by+PHPKIT%22

Plug:

You can discuss this and other vulnerabilities in our forum at
http://forum.hardened-php.net/ - an up-to-date list of advisories can be
found at http://www.hardened-php.net/.

GPG-Key:

http://www.hardened-php.net/hardened-php-signature-key.asc

pub 1024D/0A864AA1 2004-04-17 Hardened-PHP Signature Key
Key fingerprint = 066F A6D0 E57E 9936 9082 7E52 4439 14CC 0A86 4AA1

Copyright 2005 Christopher Kunz / Hardened PHP Project. All rights
reserved.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFDcF6uRDkUzAqGSqERAnSjAKDvXQZwnYJdEVtJGtxiFabEnWbqHACgld2G
0BoxQLmlh357rm2Lasz0gXY=
=r2Db
-----END PGP SIGNATURE-----

Security

IT News

Search

SecurityAlert Database

About SecurityAlert

ExploitAlert Database

SecurityReason Research

WLB Database

Send to WLB

About WLB

Security Audit

Schedule

Prices of services

Contact

SecurityReason IT News

SecurityAlert

World Laboratory of Bugtraq

ExploitAlert

Apache

PHP

Contact

About SecurityReason

Multiple vulnerabilities in PHPKIT