Mass Assignment Leading to (Limited) Password Confirmation Bypasses at UsersController in diaspora/diaspora

Valid

Reported on

Apr 23rd 2022


Description

Hello there! Hope you are having an amazing day! 🤗

Just found out, while testing one of diaspora* open servers, that the /user/edit endpoint has a limited case of "mass assignment", which enables an authenticated user to change their password and disable 2FA (or change its secret) without having to know their password, which is a requirement for doing these operations.

As it requires a user to be already authenticated, it is definitely not common to be explored/exploited, but it may be chained with other possible security issues and may also be used by any bad actors, after getting a victim session, as a way of inhibiting this victim future accesses.

Proof of Concept

First of all, have a way of intercepting and editing requests. I'll assume you are using a MiTM proxy tool such as Burp Suite/OWASP ZAP, but Firefox devtools may also do the trick :)

1 => Authenticate as any user and go to the account settings page (/user/edit);
2 => Click on the Change language button and intercept the POST request that goes to /user/edit;
3 => In the request body, change the user%5Blanguage%5D parameter to user%5Bpassword%5D and set as its value whatever new password you would like to have. Forward the request and boom! Password changed :)

The same could be applied to other user parameters, such as otp_required_for_login. You may define user%5Botp_required_for_login%5D as false and it will disable 2FA with no password confirmation being needed.

Impact

As it requires a user to be already authenticated, it is definitely not common to be explored/exploited, but it may be chained with other possible security issues and may also be used by any bad actors, after getting a victim session, as a way of inhibiting this victim future accesses.

Occurrences

Notice that if there's no change_password in the request, then the controller does no password verifications at all and call update_user()

We are processing your report and will contact the diaspora team within 24 hours. a year ago
We created a GitHub Issue asking the maintainers to create a SECURITY.md a year ago
We have contacted a member of the diaspora team and are waiting to hear back a year ago
diaspora/diaspora maintainer has acknowledged this report a year ago
Dennis Schubert
a year ago

Maintainer


Hi there! Thanks for reaching out and for the report. We agree that this is a valid issue, and we also agree with your assessment that this is not super critical. We're working on a fix that will be released with a minor update soon, and I'll update you as soon as there is progress.

@brenu, are you okay with being mentioned in the changelog and release notes? :)

Dennis Schubert validated this vulnerability a year ago
Breno Vitório has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Breno Vitório
a year ago

Researcher


Sure, I would love to be mentioned!

Jonne Haß marked this as fixed in 0.7.17.0 with commit 1cfe00 a year ago
Jonne Haß has been awarded the fix bounty
This vulnerability will not receive a CVE
users_controller.rb#L27 has been validated
Dennis Schubert
a year ago

Maintainer


As two Rails security issues were reported today, we had to release an update anyway. So this is been released inside version 0.7.17.0 :)

Jamie Slome
a year ago

Admin


Great work all! 👍

Would you like us to assign and publish a CVE for this report? (@maintainers)

Dennis Schubert
a year ago

Maintainer


Unless Breno insists, I don't think that's necessary - we've already publicly announced the release, and there isn't any real gain from having an identifier assigned IMHO.

Jamie Slome
a year ago

Admin


Sure :)

to join this conversation