Hulp
Boekenmaker (uitschakelen)

SoftwareSecurity2014/Group 9/OWASP ASVS Level2B Analysis of phpBB

Uit Werkplaats
Ga naar: navigatie, zoeken

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 Level2B analysis is performed which focusses manual code verification with the assisted help of several verification tools.

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 level2B 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

During manual verification, we discovered several security practices found throughout the codebase. Those security practices are used in a consistent manner and provide reliable security for their intent purposes. We will provide a brief overview of the security architecture of phpBB and how it is enforced through their security practices/patterns.

Security Architecture

PhpBB's codebase consists of PHP scripts where each script either contains a webpage, a module or functions for use in other scripts. phpBB was not developed with a large framework in mind, but rather using an ad-hoc approach of functionality. Wherever a new page is required, it simply calls and includes the appropriate functions and helper classes (like a user object) to retrieve the required functionality; this is not really an approach a well thought out code-platform should have.

Because phpBB's webpages are generally maintained in a single script file, all the required functionality is contained within this file. This is not a good security approach since there is no form of encapsulation. Wherever a user is able to do a PHP code injection he effectively has access to the entire application's structure like user data or database access.

Aside from the regularly occuring functions that provide ad-hoc security to the individual scripts, there is not really a consistent security architecture found in phpBB. (Erik: This somewhat contradicts the claim in the paragraph above that "security practices are used in a consistent manner...") The security phpBB has is all obtained from a few security classes and general security functions defined in scripts all over the codebase. To still give a decent overview of how phpBB's security is maintained we will discuss the common security patterns found throughout the code files:

IN PHPBB

In every script file a global variable called IN_PHPBB is defined if the file (and its included files) should be visible to the public; this is done as follows: define('IN_PHPBB', true);. Wherever a page is visited that is not supposed to be public this variable is not defined and at the start of the script the following code fragment is called: 

if (!defined('IN_PHPBB'))
{
	exit;
}

Thus whenever a file is not defined to be publicly available; the application exits. This is a re-occuring pattern found in each script, ensuring us that public files are indeed public and our private files stay private. This pattern is found at the start of each script in the codebase so no code is allowed to run before checking if the file's public or private.

Authentication setup

Another common security pattern is the authentication setup where a user object is first created after which an authentication object is created and linked to the user object. This gives us an $auth object we can query for permissions throughout the application. The initialization is typically done as follows: 

// Start session management
$user->session_begin();
$auth->acl($user->data);
$user->setup('viewforum');

Wherever a specific permission is required the $auth object is queried as follows: $auth->acl_gets('permission_name') returning either true if allowed or false if the user is not allowed a certain permission. The authentication and user objects were extensively verified in Fortify and by manual analysis and no security vulnerabilities were found that could exploit the authentication mechanisms.

Catch all

The application queries for certain permissions and if that query fails it triggers an error ensuring the application won't continue executing the script; thus safely exiting the application whenever something fishy is going on. This is a catch all mechanism in that it checks for certain requirements and if it fails, it stops executing the script by calling trigger_error. The trigger_error function is a built-in PHP function that stops executing the script and displays an error message provided as its first parameter. We queried several PHP resources and came to the conclusion that there are no known vulnerabilities in the trigger_error function. An example of its usage is: 

if (!$auth->acl_get('a_'))
{
	trigger_error('NO_ADMIN');
}

It checks if the user has any admin permissions and if not, triggers an error, halting any further script executions. The user is thus safely removed from the critical operations.

Logging in

We also came across several instances of a function called login_box (found in ./includes/functions.php at line: 2781). This function is called whenever we need authentication of a user by asking for its credentials. The login_box function is typically used in the following pattern: 

if (!isset($user->data['session']) // Check if a user session is active (logged in)
{
	login_box('', $user->lang['LOGIN_CONFIRM'], $user->lang['LOGIN_SUCCESS'], );
}

This snippet of code shows a login page if the user is not logged in. The first parameter of login_box is a redirect url that the user is redirected to after a succesfull login; in this case an empty string is given so after a succesfull login the user is returned to this page. The login_box function also allows an admin mode (if set in the configuration) that requires an extra authentication for whenever a user requires admin login credentials.

We analyzed the login_box function extensively (since it is our primary authentication mechanism) but failed to find any security flaws. Its authentication mechanisms are solid and all its queries are executed using a fashion simliar to prepared statements. If any weird behavior is spotted (like false credentials or a normal user trying to login as an admin) a trigger_error is called, halting any further movement.

Verification Results

Following the OWASP guidelines of our 2B security analysis we divided our analysis based on the requirements given for section 2 (Authentication) and 7 (Cryptography). Several requirements were stated, each specifying an individual part of the application's security. Some overlap might occur, but the analysis was divided to the analyzers in such a way that any overlap that might occur stays within the analyzer's domain. To verify that our application is 2B-secure on authentication and cryptography we need to pass all the required requirements. Below we'll list all the requirements and discuss any interesting observations we made before coming to a verdict.

Requirement V2.1

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

In our 1B analysis several files were detected that were publicly available and thus (should) require authentication. The 1B analysis using Fortify and our custom scripts resulted in an undetermined verdict; we will now fucus our efforts on manually verifying the public files to see if they actually do require authentication instead of relying on heuristics. We have manually verified the authentication code on each of the public files listed and we will discuss their authentication efforts below:

  • ./adm/index.php

First a user-check is done to see if the user is admin. If the user does not fit the requirements, a (specialized) login box is shown asking for admin credentials. If the user fails to provide the correct credentials, an error is thrown and the user will not be able to continue. Below a snippet of code is provided that shows this process: 

if (!isset($user->data['session_admin']) || !$user->data['session_admin'])
{
	login_box('', $user->lang['LOGIN_ADMIN_CONFIRM'], $user->lang['LOGIN_ADMIN_SUCCESS'], true, false);
}

The login_box function is described in detail in the Application Security Architecture section. If the user succeeds to provide the required credentials, the page is reloaded; this time with admin user info. Then the file does a Catch all by checking if the user is of any type admin. If it fails, an error is triggered (via Trigger Error>. Using trigger_error to stop users from continuing is a safe method for isolating unwanted users.

The described pattern is something that continually re-occurs throughout the application for all sensitive files. Basically we first check some login information, if it fails we ask for credentials. And usually a catchall is added for extra insurance. The code pattern is a valid pattern for ensuring authentication and we see no issues here. We will ommit the discussion of this pattern in the next files, since there is no need to discuss it more than once, the pattern stays the same.

  • ./adm/swatch.php:

This is a script for styling. Does not require authentication so a discussion is omitted.

  • ../cron.php:

The cron.php script allows for several cron-job-scripts like cleaning the database, checking for spam posts etc. The cron job file requires no authentication and this is a possible cause for concern. A malicious user might be able to exploit this file for a Denial-of-Service (DoS) attack where it continually calls for cron jobs that could overload the server with queued commands. The script does contain a mechanism called a cron-lock that sets a lock whenever a cron-job is activated and releases the lock when the job is finished. This ensures that there are no parallel cron-jobs active, greatly reducing the dangers of a DoS attack. However, a user could still keep activating the cron job in a continous fashion, keeping the server active on (possibly heavy) cron jobs. However, if this really is a matter of concern is unlikely; any decent webserver should be able to handle continous cron jobs alongside its usual operations. However, to improve security: such a file should be restricted by admin-users or server scripts only. (Erik:Indeed!)

  • ./download/file.php:

The file.php script contains many file-related management functions like uploading avatars, adding attachments to posts etc. Just like the cron script, file.php does not require authentication. This is again a possible concern for a DoS attack. This time however, there are no locks in place to prevent a malicious user from continually stressing the server by uploading and downloading arbitrary files. This time, the script can be executed in parallel with a possibly over-stressed server (and/or by eating a lot of bandwidth) as a result. Managing files should be restricted to users with the proper permissions and violations of the file should result in reduced permissions or a ban.

  • ./faq.php:

No authentication required.

  • ./feed.php:

Same patterns as previously discussed. However, this file also adds a debug mode where it shows extra info regarding the site's back-end. Debug mode is only allowed for admin users that have the debug-property set. For the debug statements, authentication is properly checked.

  • ./index.php:

Shows a basic interface for anonymous users, a default set of functions when a user is logged in and extra information whenever an admin user is logged in. Authentication and constraints are properly initialized and enforced.

  • ./install/database_update.php, ./install/index.php:

As mentioned in 1B the install files do not have any authentication, but the install files need to be removed for the application to function so this is a non-issue.

  • ./mcp.php, ./memberlist.php, ./posting.php, ./report.php, /ucp.php, ./style.php, ./viewforum.php, ./viewonline.php, ./viewtopic.php:

Nothing that has not been discussed or is noteworthy is found in these files. Authentication is solid and required wherever necessery.

  • ../search.php:

The search script has the added check that anonymous users may be allowed to search the forum if this is configured in the settings. Otherwise, login is required. It should also be mentioned that searching for authors is a user-only query in the search script. All the other search queries are open to anyone.

Overall, the authentication mechanisms are very solid on the publicly available files and passed the requirements with flying colors. The only two files that did not comply with authentication were the cron.php and the file.php files as both are possible sources for DoS attacks. It is however still questionable at what level these files are dangerous for the application. This is something that should be determined in a stress test on a live environment.

However, due to the fact that file.php looks severe enough for a serious DoS attack we have to fail the current requirement, since not all files that should require authentication have been properly authenticated.

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 already failed on level 1B, it therefore also fails to comply with level 2B. However, manual code scanning did not find more violations.

Requirement V2.3

Requirement V2.3. states: Verify that if a maximum number of authentication attempts is exceeded, the account is locked for a period of time long enough to deter brute force attacks.

Authentication is entirely handled by one function (login_box) in ./includes/functions.php. This function calls the function login from ./includes/auth.php. This function dynamically calls either login_db from ./includes/auth/auth_db.php, login_apache from ./includes/auth/auth_apache.php, or login_ldap from ./includes/auth/auth_ldap.php.

login_db counts login attempts and will show a captcha if a maximum number of attempts is exceeded. On successful authentication it will also reset the counter.

However, the other functions, login_apache and login_ldap, don't count the number of login attempts. This might be a design decision to leave it up to the external server which is used for authentication in these functions, but strictly speaking phpBB3 doesn't enforce a maximum attempt count.

We could argue whether the login_db function itself complies with the requirement. The way phpBB3 enforces a maximum number of attempts (in this function) is by use of a captcha. The requirement calls for a timeout and because captcha's could be solved, a captcha is a less strong method to prevent brute force attacks.

Because of these points we can conclude that this version of phpBB fails to comply with requirement V2.3.

Requirement V2.4

Requirement V2.4. states: Verify that all authentication controls are enforced on the server side.

We looked at the function login_box in ./includes/functions.php, which handles authentication. This function calls login_forum_box to create the html log in form, which is mostly found in the file login_forum.html, either from styles/prosilver/ or styles/subsilver2/.

Neither of these html pages indicate that authentication relies on any client-side security. The functions login_box and login_forum_box neither indicate they rely on any client-side security.

We can thus conclude that phpBB3 complies with requirement V2.4.

Requirement V2.5

Requirement V2.5. states: Verify that all authentication controls (including libraries that call external authentication services) have a centralized implementation.

A centralised implementation infers that the complete project contains only one code block which is responsible for handeling authentication decisions.

All accessible pages within phpBB have, as we noted before, a common pattern as it comes to authentication. First the session is used to construct the current user login state. This state is then used to feed the authentication class. This class is then used to read the access rights and privileges of the current user where needed in the page. Also decisions about whether a user needs to (re-)authenticate himself are made here. 

// Start session management
$user->session_begin();
$auth->acl($user->data);

All these functionality is grouped in (mainly) the authentication class and the user (session) class. Since this is the only place in the project where authentication is handled and that all authentication decisions are made using these parts of the code we can conclude that phpBB complies to this requirement.

Requirement V2.6

Requirement V2.6. states: Verify that all authentication controls fail securely.

For an authentication control function to fail securely we require it to give notion about whether it returned successful or failed. There are many functions which are considered to be an authentication control function in phpBB. We list the most important ones here and check whether or not they satisfy this requirement.

Our most important function is login() in auth.php . This method is quite complex and relies on multiple authentication control mechanisms including different authentication methods such as LDAP or plain Database entries. Then the function alters the user (session) object where access privileges and permissions are stored.

The different authentication methods are all implemented in different files, but follow the same pattern. All methods implement a login_<method>() function, which is called in our main login() function. All these login_* functions return an associative array with three entries: a status field, an error message field, and a user row containing the digital identity of the user. According to how the authentication procedure went, these fields are set to the correct value. This happens quite systematically for each situation, and gives clear feedback wether or not a login attempt was successful. In case of a successful authentication the status LOGIN_SUCCESS with a user row is returned while on a failed authentication attempt a LOGIN_ERROR_X status is returned along with a corresponding error message.

The second part of the login() method is about persisting the fetched login status in a user session by calling the session_create() method of the session object. This message returns a boolean value which indicates success or failure.

When something in this chain breaks trigger_error() is called which terminates the PHP execution immediately and serves an error page to the user.

Finally, if the login() method returns the returned array from the login_* call it is given back as a result.

Furthermore, auth.php contains many functions that are used for the authorization process. All these functions return a boolean true on success and a false value on failure.

So, as a final conclusion about this criterium we state that phpBB perfectly handles failure within the authentication mechanism and thus complies with requirement 2.6.

Requirement V2.7

Requirement V2.7. states: Verify that the strength of any authentication credentials are sufficient to withstand attacks that are typical of the threats in the deployed environment.

Users are created in the function user_add in ./includes/functions_user.php. This function does not check whether passwords comply with any complexity settings. This is probably done because sometimes empty passwords are created as described in Level1b Analysis, Requirement v2.2 under Password Management: Empty Password.

The function user_add is called from several places:

  • includes/ucp/ucp_register.php*
  • includes/auth.php*
  • includes/auth/auth_apache.php
  • includes/functions_convert.php
  • includes/acp/acp_bots.php

The starred files handle actual registration of users, and in auth.php the password is not created by the user.

The file ucp_register checks for minimum length of the password and calls validate_data, which calls validate_password. This function checks whether the password complies with certain complexity settings.

The other place where password complexity should be checked is when passwords are changed. This happens in ucp_profile.php and acp_users.php. Both these functions also call validate_data before updating the password.

We can therefore conclude that phpBB3 complies with requirement V2.7.

Requirement V2.8

Requirement V2.8. states: Verify that all account management functions are at least as resistant to attack as the primary authentication mechanism.

The primary authentication mechanism is the function login_box located at ./includes/functions.php at line: 2781. The function is described extensively in the Security architecture section of this document. The login_box function has no visible security flaws so wherever it is required in account management it should be sufficient. The user account management functions are located at the user control panel found in ./ucp.php.

UCP First checks a few basic modes (like register, login, logout, delete cookie etc.) that are accesible to anonymous users (this functionality should be accesible to everyone) and if none of these modes are set then the normal UCP page is shown that loads all the modules (found in ./includes/ucp/). Users that are not registered are not allowed past this point as seen in the following code fragment: 

if (!$user->data['is_registered'])
{
	if ($user->data['is_bot'])
	{
		redirect(append_sid("{$phpbb_root_path}index.$phpEx"));
	}

	login_box('', $user->lang['LOGIN_EXPLAIN_UCP']);
}

The security in ucp.php was manually verified and verified using our toolset giving no legimate security flaws. Wherever authentication is required, phpBB checks if a user is logged in and otherwise calls the login_box function, basically propagating the management's security to login_box's security which is solid. We can thus conclude that phpBB complies with requirement 2.8.

Requirement V2.9

Requirement V2.9. states: Verify that users can safely change their credentials using a mechanism that is at least as resistant to attack as the primary authentication mechanism.

The mechanisms for users to change their credentials is found in the ./includes/ucp/ucp_profile.php module. Since it is a module of the user control panel access to the module is only possible via the ucp main panel (the ucp_profile.php script is not publicly available). The ucp panel has solid authentication mechanisms so users are not able to access the ucp file; this is done via the primary authentication mechanism (login_box). However, for research purposes we still check the specific authentication mechanisms in place. Authentication for specific functionality (like uploading avatar, checking email notifications etc.) is checked, but general access to the profile panel is not checked for access (this is most likely the case, since it can only be accessed from the authenticated ucp panel). Like the previous examples, authentication for specific functionality is checked as follows: 

if ($auth->acl_get('u_chgname') && $config['allow_namechange'])
{
	... // Code to perform when authentication is allowed.
}

This snippet of code for example checks if the user is allowed to change his name and if the configuration allows this as well. If so, the tools for changing the user's profile name are shown. Another login check is omitted this time (already done at the ucp panel).

We can safely conclude that phpBB complies with requirement 2.9.

Requirement V2.10

Requirement V2.10. states: Verify that re-authentication is required before any application- specific sensitive operations are permitted.

Since application-specific sensitive operatons are scattered throughout the application we first had to search for the relevant scripts:

1. Admin Control Panel

The admin control panel hosts several modules found in the ./includes/apc/ folder. Below we will discuss each of the application-specific sensitive admin modules, but first we will mention two security patterns found througout the modules:

  • Wherever a sensitive operation is about to be confirmed the user is asked for confirmation. This is done via phpBB's confirm_box function. We extensively checked the confirm_box's functionality (it is found in ./includes/functions.php at line: 2678) but all the function does is ask the user for confirmation. The function does not require re-authentication and there are no options to do so. Using the confirm_box is simply not enough.
  • Wherever a setting is about to be changed the function SetConfig is called (found in ./includes/functions.php at line: 142). The function does not ask for re-authentication or any form of confirmation. Just like confirm_box this does not provide good security measures, especially for sensitive operations.

The aforementioned techniques are thus not valid for our requirement. Below we will list the mentioned authentication/security techniques used in each file:

  • acp_bbcodes.php: Confirm_Box is called whenever a sensitive operaetion is performed.
  • acp_board.php: Confirm_Box, Settings are changed via SetConfig.
  • acp_bots.php: Confirm_Box.
  • asp_captcha.php: Confirm_Box, SetConfig.
  • acp_database.php: Confirm_Box.
  • acp_jabber.php: SetConfig.
  • acp_language.php: Confirm_Box.
  • acp_logs.php: Confirm_Box, SetConfig.
  • acp_main.php: Confirm_Box.
  • acp_modules.php: Operations like 'Delete entire module' are done via Confirm_Box. It is clear this is not enough.
  • acp_profile.php: Confirm_Box.
  • acp_search.php: Confirm_Box, SetConfig.
  • acp_update.php: This script updates the forum, but does not have any form of authentication. However, malicious access to this file does not seem like a serious vulnerability. First it can only be accessed from the admin control panel and secondly its functionality is harmless (updates the forums/application).
  • acp_words.php: Combination of Confirm_Box and SetConfig again.
2. There were also a few other application-sensitive files found scattered throughout the codebase.

These files were: ./includes/acm/acm_memory.php and acm_apc.php. These files do not require any authentication or confirmation.

From the data it is clear that this requirement fails horribly. Each and every application-sensitive operation does not require re-authentication.

Requirement V2.11

Requirement V2.11. states: Verify that after an administratively- configurable period of time, authentication credentials expire.

The function login_box, that handles authentication, does not check whether passwords are outdated. We also could not find any other functions or files that handle this. We must therefore conclude that phpBB3 simply misses the functionality of credential expiration.

Because this functionality is absent, phpBB3 fails to comply to requirement V2.11.

Requirement V2.12

Requirement V2.12. states: Verify that all authentication decisions are logged

Authentication decisions are made in the login_box function, where it is checked whether the right username and password have been entered. Whether the authentication succeeds or fails should be logged.

A log is added with the add_log function, which is only used when an admin authentication attempt is made. The log addition shows whether the attempt was a failure or a success. The other authentication attempts however are not logged, so this requirement is not satisfied and thus fails to comply.

Requirement V2.13

Requirement V2.13. states: Verify that account passwords are salted using a salt that is unique to that account (e.g., internal user ID, account creation) and hashed before storing.

This requirement is best described in requirement V7.4. The conclusion is the same, phpBB complies with this requirement.

Requirement V2.14

Requirement V2.14. states: Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a protected location (not in source code).

The only occurence of using external services that we could find is the use of the database. The password for the database is stored in the file config.php which is set during installing. This file is, however, stored plain text on the server and therefore not in anyway safely stored using encryption.

The password is not hard coded, but not safely stored either, meaning phpBB fails to comply with requirement 2.14.

Requirement V7.1

Requirement V7.1. states: Verify that all cryptographic functions used to protect secrets from the application user are implemented server side.

Searching for the occurences of javascript in all html files resulted in a lot of findings. We focussed on the occurences of javascript in the ucp (User Control Panel) range, since this is the main entry point for security for users. All the html files in this range did not use any form of encryption or hashing on the client-side. Besides this, the functions in the php files, in the ucp range that are used for account creation, always use a cryptographic function. This inclines that since the encyption is done server-side, it will probably not happen client-side as well.

This requirement therefore satisfied complies with requirement 7.1.

Requirement V7.2

Requirement V7.2. states: Verify that all cryptographic modules fail securely .

MD5 and SHA-1 are used as cryptoghraphic functions. These are standard functions which return the calculated MD5 or SHA-1 hash of the given string or false if the function fails. With the help of the Foritfy tool all uses of these functions could be easily found. Once found, it is evident that there is never a check to see whether a hash or a false is returned. It is expected that a correct hash is returned, and the hash is immediately used for comparison (for example).

This requirement is therefore fails to comply.

Requirement V7.3

Requirement V7.3. states: Verify that access to any master secret(s) is protected from unauthorized access (A master secret is an application credential stored as plaintext on disk that is used to protect access to security configuration information).

The only master secret that is present is the password of the database which is defined in config.php. This password and file are stored plaintext on the server, meaning that everyone who has access to the config file can also gain access to the database.

It is therefore clear that phpBB fails to comply with requirement 7.3.

Requirement V7.4

Requirement V7.4. states: Verify that password hashes are salted when they are created.

Account creation is done via the function user_add($user_row, $cp_data = false) in the file ./includes/user_functions.php. This function does not do any hashing of the password and therefore assumes the password provided in the user_row is already hashed.

The function user_add is called from 5 different classes. To verify this requirement, all 5 functions must do the hashing of the password prior to the call of user_add. The following classes call user_add:

  • auth.php
  • auth_apache.php
  • functions_convert.php
  • acp_bots.php
  • ucp_register.php

We'll discuss them independently.

auth.php

Probably the most important function is in auth.php. This function is used for login and calls the function user_add with the information received from a function $method. This function $method, is however as already stated in the results above, defined in three different files and included depending on the specific function of the login. The three different files that are included are:

  • auth_db
  • auth_apache
  • auth_ldap

On inspection of the login function of those three files, we see that the password is hashed in two cases (db and ldap) using the function phpbb_hash (more on this function later). The last case (apache), only checks if a password is provided, and tries to receive the user from the database if it exists, or creates a new user with a default password of the apache server. This default password is again hashed by phpbb_hash in the function user_row_apache.

This means that all three files use a hashing function.

auth_apache.php

This file has the function autologin that calls the user_add function. It does this with the arguments from function user_row_apache. As seen above, this function uses the function phpbb_hash to hash its password.

functions_convert.php

This file has a function add_bots that calls the user_add function. The password used in this function is empty, which makes sense since this is used to add a bot which should not have a password.

acp_bots.php

This file also uses the function user_add with an empty password. As the filename implies, this is again used for bots, meaning an empty password is ok.

ucp_register.php

ucp_register.php has the function ucp_register that calls user_add. The password is here again hashed using the phpbb_hash function.

phpbb_hash

As can be read above, the function phpbb_hash is the function used to hash all the passwords. This function can be found in the functions.php file. The function creates a random string based on urandom or the function unique_id. In combination with this random string, password and fixed ito64, it creates the hashed password in a few rounds of md5.

This means that the hashed passwords are salted using a unique string per user, phpBB therefore complies with requirement 7.4.

Requirement V7.5

Requirement V7.5. states: Verify that cryptographic module failures are logged.

We need to check whether the failing of a cryptographic function is logged. Since there are no checks for cryptographic functions failing, the failing of the functions are not logged either.

This makes it easy to conclude that phpBB fails to comply with requirement 7.5.

Requirement V7.6

Requirement V7.6. states: Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module’s approved random number generator when these random values are intended to be unguessable by an attacker.

PhpBB has made it their default to use MD5 or SHA-1 for generating random numbers, strings, filenames, etc. Although MD5 is not secure anymore, it suffices in generating a random file name. A few exceptions on this were found going through the code:

Using phpbb_hash for passwords

As can be read in requirement 7.4, passwords are hashed using the phpbb_hash function. Although the framework from PHPASS is used widely by quite some web applications, no proof could be found of it to be FIPS 140-2 validated.

Using /dev/urandom

/dev/urandom is often used as a random number generator for generating file names, etc., not only in phpBB, but in many other applications as well. Again, no proof could be found stating this is a secure number generator. The documentation does state it to be less secure than /dev/random, due to the fact that urandom does not block. When the fucntion receives too little random noise, random will block and wait for noise, while urandom will use a random number generator to give a full random right away.

We believe that for its required purposes, the random number generation suffices and phpBB thus complies with requirement 7.6.

Verdict

The following table summarizes the results gathered from discussion of our requirements:

Requirement Pass Fail
V2.1   X
V2.2   X
V2.3   X
V2.4 X  
V2.5 X  
V2.6 X  
V2.7 X  
V2.8 X  
V2.9 X  
V2.10   X
V2.11   X
V2.12 X  
V2.13 X  
V2.14   X
V7.1 X  
V7.2   X
V7.3   X
V7.4 X  
V7.5   X
V7.6 X  

Conclusion

We performed a OWASP ASVS Level2B analysis on the phpBB software to check if this forum software is protected against some well known attack vectors. During this assessment we only focussed on issues related to authentication and cryptography. In order to do this we thoroughly looked at the requirements formulated by OWASP. Our findings are summarized in the verdict table above. PhpBB fulfilled 11 requirements, while 9 requirements failed. For an application to be considered OWASP ASVS Level2B compliant it should meet al the requirements defined by the standard. Since this is not the case we cannot grand this level of security to phpBB.

Overgenomen van "https://lab.cs.ru.nl/algemeen/index.php?title=SoftwareSecurity2014/Group_9/OWASP_ASVS_Level2B_Analysis_of_phpBB&oldid=266973"