Page MenuHomePhabricator

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor
Closed, InvalidPublicSecurity

Description

I'm writing to you with report about CWE-359: Exposure of Private Personal Information to an Unauthorized Actor / CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

It is connected with my previous report named "Account takeover - Account protection" (common parts).

At this moment there is very simple way to Account takeover (here as an example MediaWiki account).

The current proccess / approach is invalid, dangerous.

Repro steps (PoC):
(victim side)

  1. User (as logged in) wants to change an email, so go to: https://www.mediawiki.org/wiki/Special:ChangeEmail
  1. Type/change email to invalid (for testing purposes you can use your_email and your_email+alias - as another one), which user not own (misspell / mistake)
  1. See message - changed sucessfully:

Change or remove email address
A confirmation email has been sent to the specified email address. Before any other email is sent to the account, you will >have to follow the instructions in the email, to confirm that the account is actually yours.

(bad actor side)

  1. Open email sent to "wrong address" (ie.: with other browser type and with incognito/private mode ; victim made a mistake with email address), see message:

To confirm that this account really does belong to you and reactivate
email features on MediaWiki, open this link in your browser:
https://www.mediawiki.org/wiki/Special:ConfirmEmail/[chars]

  1. Click that link to Confirm (as a Bad Actor)
  1. See info:

Confirm email address
Your email address has been confirmed. You may now log in and enjoy the wiki.

  1. Return to Special:UserLogin. So click Log in https://www.mediawiki.org/wiki/Special:UserLogin - BUT bad actor don't know the password or login, YET.
  1. So click https://www.mediawiki.org/wiki/Special:PasswordReset

Reset password
Fill in one of the fields to receive a temporary password via email.

Add your mail (bad actor's email, from step nr 4; ie.: your_email_example+alias1@gmail.com )

  1. Click Reset password, see message:

You have requested a password reset.
If the information submitted is valid, a password reset email will be sent. If you haven't received an email, we recommend that you visit the reset password help page or try again later. You can only request a limited number of password resets within a short period of time. Only one password reset email will be sent per valid account every 24 hours in order to prevent abuse.
The details you submitted are:
Email address: your_email_example+alias1@gmail.com
Return to MediaWiki."

  1. Log in again to that "wrong / bad actor's email"
  1. See message - with "Username: [real_victim_username] and Temporary password: [temp_pw]"

Additional information:
That informations were used to PoC of my previous report about "Account takeover - Account protection" - the key thing is real_victim_username.

Link - https://phabricator.wikimedia.org/T324322

Sources:
https://cwe.mitre.org/data/definitions/359.html
https://cwe.mitre.org/data/definitions/200.html

Details

Risk Rating
Informational
Author Affiliation
Wikimedia Communities

Event Timeline

What "Private Personal Information" is there to be exposed from having access to someones Wikipedia/MediaWiki account?

This comment was removed by Emicbie22.
This comment was removed by Emicbie22.

Please take a look on this report and mentioned (connected) report https://phabricator.wikimedia.org/T324322
In general I would not report this, BUT in this case it was "KEY" to ATO Account takeover scenario.

This doesn't help. The report is substantially identical, just related to a different purported vulnerability.

Please keep in mind that bad actor in described scenario don't have to make OSINT and so on, and check the user names, just received mistaken email and due the invalid Recovery Mechanism (CWE-640: Weak Password Recovery Mechanism for Forgotten Password) takes control of the account.

https://cwe.mitre.org/data/definitions/640.html

This weakness may be that the security question is too easy to guess or find an answer to (e.g. because the question is too common, or the answers can be found using social media). Or there might be an implementation weakness in the password recovery mechanism code that may for instance trick the system into e-mailing the new password to an e-mail account other than that of the user. There might be no throttling done on the rate of password resets so that a legitimate user can be denied service by an attacker if an attacker tries to recover their password in a rapid succession. The system may send the original password to the user rather than generating a new temporary password. In summary, password recovery functionality, if not carefully designed and implemented can often become the system's weakest link that can be misused in a way that would allow an attacker to gain unauthorized access to the system.

MediaWiki is not being tricked into sending it to another email.

This comment was removed by Emicbie22.
sbassett changed the task status from Open to In Progress.Dec 5 2022, 5:22 PM
sbassett moved this task from Incoming to In Progress on the Security-Team board.
sbassett added a project: SecTeam-Processed.
sbassett moved this task from In Progress to Our Part Is Done on the Security-Team board.
sbassett subscribed.

I'm going to set this to invalid as there is absolutely no way to prevent legitimate users (of any website or web app) from entering an "incorrect" email address as part of their account settings, which may then turn out to be a valid email address for an actor with potentially malicious intentions. There must be some minimal assumption of competency on the part of any user of internet services and applications.

sbassett triaged this task as Lowest priority.Feb 16 2023, 3:45 PM
sbassett changed Author Affiliation from N/A to Wikimedia Communities.
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Informational.
Emicbie22 renamed this task from CWE-359: Exposure of Private Personal Information to an Unauthorized Actor to Errore.Feb 18 2023, 6:27 PM
Emicbie22 updated the task description. (Show Details)
Emicbie22 updated the task description. (Show Details)
JJMC89 renamed this task from Errore to CWE-359: Exposure of Private Personal Information to an Unauthorized Actor.Feb 18 2023, 6:31 PM
JJMC89 updated the task description. (Show Details)