Authentication Bypass for users with MD5 password hash in froxlor/froxlor
Reported on
Feb 19th 2023
Setup
- OS: Ubuntu 22.04.2 LTS
- Froxlor: 2.0.12
- PHP: 8.1.2
Description
Froxlor still supports logins for passwords that are stored as MD5 hash in the database. The hash comparison is done with "==" instead of "===" which causes a type confusion vulnerability in PHP. For some MD5 hashes it is possible to login with an invalid password.
Proof of Concept
Step 1
Set password for user ID 1 (username: admin) to 240610708 in database:
UPDATE `panel_admins` SET `password` = MD5('240610708') WHERE `panel_admins`.`adminid` = 1;
Step 2
Login via WebGUI with user admin and password: QNKCDZO
Additional Information
This Authentication Bypass won't work for every password. In this example both passwords will result in vulnerable MD5 hashes:
| Password | MD5 |
|---|---|
| 240610708 | 0e462097431906509019562988736854 |
| QNKCDZO | 0e830400451993494058024219903391 |
PHP will interpret the MD5 hashes as numbers (0 * (10 ^ ...)), which results in the number "0". That's why the comparison via "==" returns true.
So in the end every password resulting in an MD5 hash starting with 0e, followed by digits only is vulnerable.
Impact
Authentication with an invalid password is possible
Occurrences
Given that you NEED to do this manually in the database (froxlor does not provide ANY way to set your password using MD5) this is in NO way critical and requires at least authentication to the underlying database which should be considered "high". Also, after the initial login using md5 compatibility, the password for the user will be rehashed with a (modern) hash algorithm from the settings
I completely agree with you that froxlor in the current version doesn't provide any way to store a password as MD5 from the WebGUI or CLI. However older versions of froxlor did store passwords as MD5 hash. The current version of froxlor doesn't prevent logins when the password is stored as MD5 hash, instead it is still actively supported (and rehashing will happen after successful login). So all in all the attack is still possible, if a password was set in an older version (simulated in step 1 in this report) until the user authenticates successfully in the current version. Until this moment an attacker can abuse the vulnerability.
Regarding the critical severity: The severity is calculated based on CVSS specification. Attack vector: can be done remotely via internet -> network Attack complexity: PHP type juggling and magic hashes are well known attacks since multiple years (see references) -> low Privilege required: works as unauthenticated attacker -> none User interaction: not required -> none Scope changed: doesn't change -> unchanged Confidentiality/Integrity/Availability: a user with admin privileges could be affected, which will lead to complete system compromise -> high
This will result in an CVSS score of 9.8 (critical).