Full account takeover in phpfusion/phpfusion
Reported on
Aug 19th 2022
POC:
Step 1: Use a normal user account

Step 2: Change user password in edit profile function

Step 3: Enter data fields that change normally

Step 4: Use burp suite to intercept requests to update profile

Step 5: Change id from 2 to id 1 and send request

The result of logging in with the new username and password is usertest/Aa@123456

Successfully logged into the super admin account, the data in the database is changed

Impact
Attacker Can hack all users account using his own app access token, and he has full control over that account.
I sent an email yesterday at 22:11(GTM+7), Aug 18, 2022, but so far no reply
I checked and found the fix 14 hours after I sent the mail. Afterward that I continued to email again but still no response.

Please allow some time for the maintainer to respond. We send out three nudges/reminders by e-mail to the maintainers, and do usually hear back from them after a couple of nudges.
I have seen them fix the error but no response for me @admin T.T
the bug has been fixed, so can you open the public report so i can request the cve? Please @admin
Are you able to attach the commit SHA that fixes the issue?
Here is it @admin: https://github.com/PHPFusion/PHPFusion/commit/57c96d4a0c00e8e1e25100087654688123c6e991
I've dropped a comment here and will wait to hear back from the maintainer :)
Hello, I'm the lead developer. Sorry for the late replies.
Yes, I've patched it under 9.10.30 latest release.
I have made a newer version of the User Fields.
// edit profile has no lookup, however admin edit will use a lookup $_GET var.
if ($lookup = get('lookup', FILTER_VALIDATE_INT)) { // must have a get
// check access and tampering proof.
if (($this->admin_panel && $this->admin_user) || fusion_get_userdata('user_id') == $lookup && fusion_get_userdata('user_password') == post('user_hash')) {
if ($this->user_data['user_id'] == $lookup) {
return $this->user_data['user_id'];
}
}
} else if ($this->_method == 'validate_update') {
return $this->user_data['user_id'];
// as such, we will not rely on user_id $_POST value any further.
}
return 0;
}```
By the way, thanks for the call @Jamie Slome
No worries @Frederick :)
If possible, can you resolve the report by marking it as valid and fixed if you perceive this to be a legitimate vulnerability?
Happy to assign a CVE once we get the go-ahead from the maintainer 👍
@frederickchan - are you happy for me to assign and publish a CVE for this report?
Hello. yes I am fine with it. Thanks for all the good work folks.