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.

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.