SoftwareSecurity2014/Group 9/OWASP ASVS Level1B Analysis of phpBB

Introduction

This document reports on the findings of a security analysis using the OWASP Application Security Verification Standard. This verification is done in the context of the Software Security course of the Radboud University Nijmegen. During this phase a Level1B analysis is performed which focusses on the issues yielded by various tools and scripts.

The Target of Verification (TOV) for this audit is phpBB, which is bulletin board software. An older version of the application is investigated: 3.0.7 where 3.0.12 is the current (as of 23 april 2014) stable release.

Normally a verification process is preceded by a risk analysis pointing out the points of interest. However, this part is intentionally skipped since it falls beyond the scope of the Software Security Course. Also, during this verification only the Authentication Verification Requirements (V2) and Cryptography Verification Requirements (V7) are subject of the audit.

Because we were able to find violations of our security requirements we conclude that phpBB3 is not OWASP level1B compliant.

Chapter 2 will provide a short overview of the TOV, providing a high level description about its operations and the environments that it operates in. Chapter 3 describes the security related architecture of the TOV. Finally in Chapter 4 a detailed overview of the findings will be presented together with a verdict about the security level of the application.

Application Description

The TOV for this project is phpBB; a dynamic web-based forum application, that offers extensive user management, styling configurations and powerful controls for managing posts and reactions. The software is free and open-source. Since phpBB is one of the most popular bulletin boards around it has an extensive code-base and should have a good focus on security.

PhpBB is, as its name suggests, written in PHP and runs on a webserver such as the Apache HTTP Server. Some noteworthy requirements are that the minimum supported PHP version is v4.3.3 and, the software relies on one of many supported SQL database implementations for storage.

The targeted version of phpBB for this project is version 3.0.7 (GitHub), which has been released on February 2010.

Application Security Architecture

PhpBB does not contain a very well developed architecture. Most of phpBB's functionality is derived from standalone page files that include large collections of functions and helper classes that are spread all over the source code of phpBB. Although most of them can be found in the folder ./includes/.

Based on phpBB's documentation and generated class documentation via the phpDocumenter tool several classes can be marked as points of interest with regards to authentication and cryptography:

1. acp_* classes: ACP stands for Administration Control Panel. Classes with a acp_ prefix are used for the administration pages and contain functionality which is restricted for a select group of users. There are different acp_* classes for different functionalities (i.e. acp_email, acp_users and acp_ban).
2. mcp_* classes: MCP stands for Moderator Control Panel and is similar to the acp_* classes. The MCP classes contain the functionality for moderating content on the forums.
3. auth class: The auth (authentication) class contains all the functionality required for authentication. It takes user-specific data as its input and then determines all the permissions and access rights for the phpBB system.
4. session class: The session class has all the functionality required for session management. Once a user is logged in, a session object will maintain that user's session state.
5. user class: The user class is an extension of the session class and represents the logged-in user containing the relevant functionality for user management.

PhpBB has several other important classes, but the aforementioned classes were most relevant for the scope of this audit.

Verification Results

In order to grade the TOV Level1B compliant it has to fulfil all the requirements stated in the ASVS. This chapter lists all those requirements and checks whether the application complies with the requirements.

To do this, a testing approach is defined for each requirement. The toolset consisting of Fortify, RIPS, RATS and some unix scripting is used to execute these tests. The test results will be reported and are used to judge if the application meets our requirements.

Finally an overall verdict for the audit is given.

Requirement V2.1

Requirement V2.1 states: Verify that all pages and resources require authentication except those specifically intended to be public.

---

The first step is to determine which files can be considered as a page or a resource. Only PHP files are considered for this part since those are the only files interpreted on the server. Due to the dynamic authentication system that looks up permissions and access rights in a database it is hard to perform an automated scan to see if those files can only be accessed by the users who are granted to see the page. (Erik:Yes. More fundamentally, it will always require some human insight (or detailed specifications) to determine what is "intended to be public") The available tools are not able to yield a evident conclusion here. To check whether authentication is implemented we fall back on semantic analysis by verifying the presence of certain code patterns. Along with this semantic scan a static analysis is performed on the authentication class to check for implementation errors.

To determine which files may be invoked by a user, phpBB starts all PHP files with a check whether or not a file should be publicly readable or only accessible through a PHP include. To do this all files that may be invoked by a user contain the line define('IN_PHPBB', true);. All files that should not be invoked have the check where the constant IN_PHPBB is set to true. If not, the file execution will be terminated.

To find all user-invokable files it is possible to make use of this mechanism by searching all files for the line which set the constant IN_PHPBB by running the following line of code on a UNIX shell in the root folder of the project.

find .  -type f -print0 | xargs -0 grep -l "define('IN_PHPBB', true);"

(Erik: Nice to see the command line being put to good use.) This yields the following list of files:

./adm/index.php
./adm/swatch.php
./cron.php
./download/file.php
./faq.php
./feed.php
./index.php
./install/database_update.php
./install/index.php
./mcp.php
./memberlist.php
./posting.php
./report.php
./search.php
./style.php
./ucp.php
./viewforum.php
./viewonline.php
./viewtopic.php

With this list of public files available the next step is to check whether there is an authentication mechanism in place. The semantics in phpBB allow for an easy check. All pages follow a certain pattern for authentication: an auth object is created (see Architecture), then the user data is passed to the auth object and from that point on the auth object can be used for checking permissions of a certain user. Checking if authentication is initialised can be done by searching the public files for the string $auth->acl($user->data);. This can be done by the following command where accessible_files.txt contains the result from the previous step.

cat authenticated_files.txt | xargs fgrep -Fl "\$auth->acl(\$user->data);"

This yields the following list of files:

./adm/index.php
./adm/swatch.php
./cron.php
./download/file.php
./faq.php
./feed.php
./index.php
./mcp.php
./memberlist.php
./posting.php
./report.php
./search.php
./style.php
./ucp.php
./viewforum.php
./viewonline.php
./viewtopic.php

It should be noted that we basically check if there is some form of authentication used in our public files. This does not guarantee that the public files will not have their private content available to the public. It merely guarentees that some' part of the code is kept from the public view, so the results we receive from semantic checks are useful, but we should not take the authentication guarantees for granted.

Also interesting to note here is the absence of the two files in the installation directory, meaning that the authentication system is not initialised when these files are accessed. This means that the installation scripts can be accessed and run by anyone. However, the installation instructions of phpBB dictate that you have to delete the installation scripts after installation. This would remove the vulnerability. However, this could possibly lead to serious security issues if the administrator simply fails or forgets to delete the install directory completely, which is not an unlikely scenario. PhpBB did provide countermeasures though for this specific issue. Whenever an administrator keeps the installation folder, phpBB will fail to run, so the issue thus becomes a non-issue.

The main authentication object is found in auth.php. We want to verify using Fortify that auth.php with all its possible includes is thoroughly verified with Fortify for any authentication faults. Auth.php includes the following files:

• auth_apache.php
• auth_db.php
• auth_Idap.php

Running Fortify on the auth.php file all its included code in the ./auth/ folder only yielded false positives.

So, to summarise, the tools provide limited options to scan for issues specifically related to authentication. By the means of semantic analysis all files were scanned for the initialisation of the authentication system. (Erik: I would still call your scanning a syntactic analysis: grep and find are about syntax, not semantics.) However, it is questionable that this provides enough certainty about whether only the rightful users are allowed to view certain resources. Each resource has its own implementation to determine the access rights and most resources depend on a database to look up these privileges.

To come to a universal conclusion is hard due to many uncertainties. Running and verifying the security tools with our requirements in mind did not yield any positive results, but a semantic analysis devised by ourself provided issues that the tools could not provide, although even those results do not completely guarantee a lack of authentication errors. Also, the verifications done by our tools did not verify visibility regarding authentication of private data so a good security judgement requires manual code verification, which is out of the scope of our 1B analysis. Therefore we leave this requirement to be undetermined.

Requirement V2.2

Requirement V2.2. states: Verify that all password fields do not echo the user’s password when it is entered, and that password fields (or the forms that contain them) have autocomplete disabled.

---

This requirement covers the password handling of the application. The requirement consists of two parts. The first part requires that user-passwords will not appear in a readable format on any page. The second part requires that autocompletion is disabled on all password fields in the application. To verify this requirement, two analysis tools are used: RIPS and Fortify.

First the results from the RIPS scan are considered. For this scan, the verbosity level has been set to Show secured and the vulnerability types to All. None of the security types really suit our verification requirements, so we inspect all vulnerabilities. All subdirectories have been scanned as well, scanning a total of 270 files.

The resulted scan gave a total of 56 errors in the following categories:

Category	No. Issues
Code Execution	6
Header Injection	1
File Disclosure	12
File Inclusion	10
File Manipulation	18
SQL Injection	1
Cross-Site Scripting	7
HTTP Response Splitting	1

Based on the scan results, RIPS detected the object-oriented nature of the source code and reported that it does not know how to properly verify object-oriented results, which could lead to false negatives. The resulting categories do not really apply to our verification requirement. A manual inspection of all those issues is thus required and resulted in no findings. All problems focussed more on active attacks.

No true positives were found by RIPS. The tool did warn that object-oriented PHP is not supported, which may have led to those results.

The second tool, Fortify yields a lot of issues. To extract the relevant issues for the verification requirement the groups formed by the 'Category analyser' were used. Two of the generated groups, Password management and Privacy Violations, turned out to be relevant for our requirement. Fortify identified 160 issues, classified in 7 (sub-) groups:

Category	No. Issues
Password Management
Empty Password	14
Hardcoded Password	63
Null Password	1
Password in Comment	54
Password in HTML Form	13
Privacy Violation
(main level)	2
Autocomplete	13

Each of the groups are discussed below:

• Password Management: Empty Password (14 issues)

There are quite some issues where a password is initialised as an empty password (an empty string). This could result in a vulnerability between the empty initialisation and the setting of the new password. On further inspection, several notes can be made:

• Some initialisation of empty passwords are done on purpose. An example is that when creating a new forum, the forum password is set as an empty string. Some fora are not private and don't need a password, so this is a false positive.
• Some passwords are initialised as an empty string and not updated to a new password. This is only done for 'bots'. We assume that this is done on purpose for use of search bots like for example Google's search spiders.

In all cases, the empty password does not effect our verification requirement.

• Password Management: Hardcoded Password (63 issues)

Fortify thinks there are a lot of hardcoded passwords in the code. However, in all issues, there is not really a password hardcoded, but a text used on the website is initialised. An example:

'TOO_LONG_USER_PASSWORD'		=> 'The password you entered is too long.',

It is clear no actual passwords are echoed and all of the issues were false positives.

• Password Management: Null Password (1 issue)

In this issue, a password is initialised as NULL and overwritten if the correct password is found. This can violate the requirement if there are no checks done while the password stays NULL. However, on inspection of the code, one can see that if the password stays NULL, appropriate checks are done in the rest of the function and no harmful code is executed.

• Password Management: Password in Comment (54 issues)

Fortify generates a lot of issues of passwords that are in the comments of the codebase. On inspection of all the issues, one can see that no real passwords are in the comments, but that Fortify simply notifies of all occurrences of the word 'password' in a comment. Those issues are therefore not a violation of the requirement.

• Password Management: Password in HTML Form (13 issues)

Fortify notifies us that some passwords in HTML form are sent to the user. This is of course a very bad idea. However, on investigating the issues, again, the passwords that are in the HTML are not real passwords, but refer to pre-programmed text. (As was also seen in 'Password Management: Hardcoded Passwords')

All the issues originated from the same pattern and thus no true positives were found.

• Privacy Violation (2 issues)

This issue is about a method sending a message over a connection. When sending information over a channel, privacy sensitive data could be included. On inspecting the code, the following happens:

The user initializes jabber which will ask for the username and password for authentication. Those credentials are sent over the jabber connection and are hardly changed (only whitespace etc. are removed). This means the password is send over a connection unchanged. If this connection is unsafe, the password is leaked.

This connection is set in the function open_socket and only uses SSL if this is specified in the call of this open_socket in the arguments. The method can be called and specified to not use SSL, meaning the password is send over an insecure connection. This method therefore seems quite insecure.

• Privacy Violation: Autocomplete (13 issues)

When using password forms, browsers have the option to autocomplete certain fields, but this can be turned off in the HTML. Using this autocomplete on password fields means the browser saves the password, which in a security perspective is a bad idea. All these issues do not specify in the HTML that the autocomplete on password fields must be turned off. These issues certainly violate the requirement.

To summarise, RIPS did not help in finding violations of our security requirements and generated only false positives. Fortify mostly generated false positives as well, but Fortify was able to find specific issues related to privacy violations and leaked passwords that were not false positives. Although many of the issues Fortify found were false positives, it certainly did find some issues related to privacy violations and passwords being leaked. Those issues do violate the verification requirement. Also, what was clearly noticeable on Jabber, is that most credentials are sent clear-text over the web (without any scrambling or obfuscation). This could be prevented by using SSL but is a security issue nonetheless. Therefore, we must conclude that our authentication requirement is not satisfied.

Verdict

As can be read in the sections above, requirement v2.1 was undetermined and requirement v2.2 failed. This can only lead to a conclusion that phpBB3 is not Level1B compliant.

It is only a small fix to improve the autocompletion on the password forms. Doing this will not result in a Level1B compliance, since the requirement 2.1 was undetermined. A level 2 verification may change this verdict.

Requirement	Pass	Fail	Undetermined
V2.1			?
V2.2		X
Level 1: V2		X