SimpleSAMLphp
Introduction
SimpleSAMLphp is an award-winning application written in native PHP that deals with authentication. This project is led by UNINETT, which is a state-owned company responsible for Norway’s National Research and Education Network. This open-source PHP authentication application provides support for SAML 2.0 as a Service Provider (SP) or Identity Provider (IdP).
SAML (Security Assertion Markup Language) is often used to implement Web SSO (Single Sign On). SimpleSAMLphp connects to an authentication source which authenticates users against this authentication source before granting access to resources.
After going through the “Issues” page in GitHub as well as running the application in sonarcloud.io, several security vulnerabilities in this application were found as follows:
· Brute force password guessing vulnerability in Admin based logins
· Weak cryptographic hashing algorithms used in functional codes
· Weak Pseudorandom Number Generator used in functional codes
VULNERABILITY 01: Brute force password guessing vulnerability in Admin based logins
In this application, Admin login has countless login attempts allowed. This is mainly because ‘login’ and other implementing classes do not have a mechanism to prevent brute force password guessing.
Affected File: modules/core/lib/Auth/Source/AdminPassword.php
Impact
In an ideal situation where the users are using passwords strong enough to make it impossible for attackers to guess the login credentials, rate limiting login attempts would be a waste of time and resources. But since this is not the case, the application is prone to brute force attacks. This will result in unauthorized personnel gaining the user credentials easily, thus compromising the system.
Recommendations
As a solution to this issue, a limit is set for authentication attempts tied to the session cookies and the same active session cookie. The idea here is to allow a specific number of logins attempts for a session id as well as session-id block. Hence, if this condition is violated, the access to the application will be denied.
Implementation
Since sessions are used, they will be started session using session_start(). If the session’s wrongAttemptCount is not declared, it is set to 0. If the password is wrong or wrongAttemptCount >= 5, users cannot login. If the password is wrong, wrongAttemptCount is incremented by 1. If the password is correct, wrongAttempCount is reset to 0.
VULNERABILITY 02: Weak cryptographic hashing algorithms used in functional codes
Hash functions are not properly implemented in the file lib/SimpleSAML/Metadata/MetaDataStorageHandler.php.
When this application was analyzed using sonarcloud.io, it was found out that this is using sha1 hashing algorithm. This is an extremely critical security issue in handling sensitive data.
Affected Files:
- lib/SimpleSAML/Database.php
- lib/SimpleSAML/IdP/IFrameLogoutHandler.php
- lib/SimpleSAML/Metadata/MetaDataStorageHandler.php
- lib/SimpleSAML/Metadata/Sources/MDQ.php
- lib/SimpleSAML/Store/SQL.php
- lib/SimpleSAML/XHTML/Template.php
- modules/core/lib/Auth/Process/TargetedID.php
- modules/core/www/idp/logout-iframe-done.php
- modules/core/www/idp/logout-iframe.php
- modules/saml/lib/Auth/Process/PersistentNameID.php
- modules/saml/lib/IdP/SAML2.php
- modules/saml/lib/Message.php
- modules/saml/lib/SP/LogoutStore.php
- tests/lib/SimpleSAML/DatabaseTest.php
Impact
If data is not secured properly, an attacker can easily gain access to this data by guessing the hash(e.g., by using a Rainbow Table). As a result, they might also be able to replace legitimate data with false values, thus compromising the system.
Recommendations
For sensitive data, it is recommended to use functions officially provided by PHP (e.g., password_hash, password_verify, password_needs_rehash). Alternatively, the crypt function or hash_pbkdf2 can also be used. Avoid the use of md5, sha1, hash and hash_init whenever possible.
Although it is recommended to use a hash function that generates salts automatically (e.g., password_hash), if salts are generated separately, ensure to:
· generate a cryptographically strong and random salt for every credential being hashed.
· save both the salt and the hashed value in the relevant database record (so that during future validation operations, the salt and the hash can be retrieved from the database).
It is also recommended to rehash data regularly since hashing algorithms become less secure over time. For this purpose, functions like password_needs_rehash can be used.
Implementation
Replace sha1 by cryptographically secure sha256 hashing algorithm.
VULNERABILITY 03: Weak Pseudorandom Number Generator used in functional codes
The file used for database checking is tests/lib/SimpleSAML/DatabaseTest.php. It should be created for test cases to ensure that it will work in a real world environment. This test ensures that the database class can properly query a database.
Affected Files:
lib/SimpleSAML/Database.php
lib/SimpleSAML/Store/SQL.php
lib/SimpleSAML/Utils/System.php
modules/saml/lib/SP/LogoutStore.php
tests/lib/SimpleSAML/DatabaseTest.php
Impact
When a software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated and use this guessed value to impersonate another user or access sensitive information and may pave way for replay attacks.
Recommendations
Avoid the use of rand() and mt_rand functions for protecting sensitive data since they rely on pseudorandom number generators.
Use functions which rely on a cryptographically strong random number generator such as random_int(), random_bytes() and openssl_random_pseudo_bytes().
If openssl_random_pseudo_bytes() is used, check and provide a value for the crypto_strong parameter.
Use the generated random values only once.
If it is necessary to store the generated random value as per requirement, ensure to confirm the security of the database or file.
Implementation
Replace the rand() function with random_int().
This contribution to the open-source project was done as an assignment submission by a group of 3 undergraduates for the 3rd Year — 1st Semester module, Secure Software Systems of Sri Lanka Institute of Information Technology (SLIIT).
