Page MenuHomePhabricator

Process for granting wmf LDAP access is vulnerable to impersonation (after creating a Wikitech account with an unconfirmed email address)
Closed, ResolvedPublicSecurity

Description

When a developer account is added to the wmf LDAP group, they have access to a variety of restricted services such as Kibana, Superset, Turnilo, and Icinga (however, as far as I'm aware it doesn't grant access to any truly confidental data like reader IP addresses or editor emails).

The normal process for granting this access is that the user creates a developer account on Wikitech and then files a ticket in the LDAP-Access-Requests project requesting access. The wmf group is intended for Wikimedia Foundation employees and the normal process for verifying that the requestor is indeed an employee is to check that the email address listed for the user in developer LDAP system matches an email listed in the "corp" LDAP system, which is tied to Wikimedia Foundation G Suite accounts.

However, it seems that when a user creates a Wikitech account, the email address they provide is passed to developer LDAP without waiting for it to be confirmed. Then, during verification of WMF status, that unconfirmed email address is compared with corp LDAP. That means the process verifies that the given email address is a valid WMF address, but not that the WMF employee was the one who provided it on Wikitech.

Here's a concrete example: a new WMF employee has been having trouble getting access to Superset, so my team has been trying to handle the access request process on her behalf (T259159).

I created a Wikitech account for her (which has precedent), providing her wikimedia.org email address and creating a strong, random password using my password manager. I then emailed her to ask her to confirm her email and use it to reset the password. At the same time, I requested the account to be given access on Phabricator (T259615). The access was quickly granted, even though she had still not confirmed the email or reset the password. As a result, I was able to sign into Superset using her account:

Screenshot_2020-08-05 Superset.png (1×2 px, 86 KB)

(After taking that screenshot, I signed out of Superset, idp.wikimedia.org, and Wikitech and deleted the password from my password manager, so the account can now only be accessed by the intended user if she uses her wikimedia.org email to reset the password. It is not necessary to revoke its access.)

It would be quite easy for a malicious actor to exploit this if they understood the vulnerability. There's a public list of WMF employees, including their email addresses. There's also a public list of users in the wmf LDAP group, which also includes email address. It's unlikely that the request being made by a totally new Phab account with no other activity would raise any red flags; after all, this would be a new employee.

One immediate way to address this would be to check Wikitech's user database before granting access to ensure that the wikimedia.org email address has been confirmed. Or the SRE handling the request could confirm the request out of band using Google Chat. I'm sure there are many others.

Event Timeline

sbassett triaged this task as Medium priority.Aug 10 2020, 3:13 PM
sbassett moved this task from Incoming to Watching on the Security-Team board.
sbassett added a subscriber: sbassett.

@nshahquinn-wmf - The Security-Team plans to chat about this at our team meeting this week and offer some guidance. Some additional checks prior to authorization, like your recommendation to check the wt user db, are likely warranted.

@nshahquinn-wmf - After discussing this in our team meeting, the Security-Team had a few more questions:

  1. @MoritzMuehlenhoff - we wanted to confirm that your automation around account management didn't include any pieces for onboarding wmf staff to privileged groups like this. Or if that's on any kind of roadmap.
  2. The Security-Team is happy to sit down and recommend some better controls for this process, if SRE or other groups are interested. Given the level of access to potentially sensitive services and data a group like wmf LDAP provides, this process might warrant something like live-person verification with HR data, etc.

this process might warrant something like live-person verification with HR data, etc.

See T244792 and T255750 for how this was solved in the past and why it might be a problem in the future.

@sbassett my team is concerned about the implications of this security vulnerability, although we also want to balance a more secure process with making sure employees get access to the resources they need in a timely manner. Is there someone I should follow up with for next steps?

@nshahquinn-wmf - After discussing this in our team meeting, the Security-Team had a few more questions:

  1. @MoritzMuehlenhoff - we wanted to confirm that your automation around account management didn't include any pieces for onboarding wmf staff to privileged groups like this. Or if that's on any kind of roadmap.

Once the whole IDP setup is more complete (we're still ramping up services and extending the underlying infrastructure), the next piece on the roadmap is an identity management system with a more established workflow (which will includes features like a service owner signing off on access). That's something that we'll start working on next (calendar) year.

That said, LDAP access requests currently need to be requested/filed in Phabricator and these accounts need to be linked to a (WMF) SUL account (which should include a challenge response against the email address (since a mail needs to be replied to)). So I don't think the impersonation angle exists per se, but maybe I'm missing some detail here?

LDAP access requests currently need to be requested/filed in Phabricator and these accounts need to be linked to a (WMF) SUL account

If "these accounts" means "these Phabricator accounts", then (while I strongly agree) this would be news to me.
I see a lot of (new WMF staff) user accounts in Phab created which are linked only to LDAP but not to SUL. (Likely because each WMF team has their own onboarding docs stored in random places, lacking org-wide overview. That's probably a request for Technical Program Management to make things consistent, discoverable, and reviewable).
Could you point to some docs stating that Phab accounts need to be linked to a SUL account, in case I understood correctly and you're aware of any docs?

That said, LDAP access requests currently need to be requested/filed in Phabricator and these accounts need to be linked to a (WMF) SUL account (which should include a challenge response against the email address (since a mail needs to be replied to)). So I don't think the impersonation angle exists per se, but maybe I'm missing some detail here?

Actually, Phabricator accounts can be linked to SUL accounts or developer accounts. So an impostor could easily create a developer account using the name of an employee, use it to log in Phabricator, and make the request.

I looked through the requests for the past several months, and almost all requesting staff members do use their WMF SUL accounts to log into Phabricator. But that's not required; for example, if you look at T256412, although both Aaron Halfaker and Chris Albon were staff at the time, neither of them had a WMF SUL account linked to their Phabricator account.

If SREs start to check that the requestor has linked a WMF SUL account, that will increase security somewhat. But as far as I can tell, the restriction on creating accounts with "WMF" in the name is enforced by the global title denylist. That can be bypassed not just by IT Services and Trust and Safety but also by any administrator, bureaucrat, or steward on Meta. Those are all trusted users, but that's still a pretty big attack surface. Generally, this isn't an issue because having the WMF tag doesn't actually grant any special permissions.

Moreover, I don't think SUL account are automatically created for all WMF staff; I believe the hiring manager has to request it as part of the onboarding since many staff don't need to do anything on public wikis.

To me, it sounds like the easiest and most resilient way to confirm WMF status would just be for the requestor (after filing the ticket) to send the SRE a Google Chat message confirming they made the request (not an email, since it's a bit more vulnerable to spoofing). This confirms they have a wikimedia.org G Suite account, which can only be created by IT Services and requires two-factor authentication, and eliminates any vulnerabilities that might be introduced by intermediate services like SUL accounts or Jumpcloud.

Yes, this would a little bit of extra work for the SRE but it's really very minimal. It doesn't require either the SRE or the requestor to have any special access (since both will be able to access Google Chat just by going to chat.google.com) or communicate synchronously (since the SRE can just request the message on Phab and then check Google Chat after the requestor replies on Phab).

If SREs start to check that the requestor has linked a WMF SUL account, that will increase security somewhat. But as far as I can tell, the restriction on creating accounts with "WMF" in the name is enforced by the global title denylist. That can be bypassed not just by IT Services and Trust and Safety but also by any administrator, bureaucrat, or steward on Meta. Those are all trusted users, but that's still a pretty big attack surface.

As a Phab admin who sometimes grants access to WMF-NDA restricted tasks, I usually 1) check which SUL account is linked to the Phab account which is requesting permissions, then 2) via https://www.mediawiki.org/wiki/Special:CentralAuth/SULusername on which site that SUL account was created, and then 3) via https://accountcreationsite/wiki/Special:Log?page=User:SULusername how the SUL account was created. If it was created by WMF ITS (Office IT) I grant access.
This chain obviously fails whenever folks only link their Phab user account to an LDAP account and not to a SUL account, which makes things more cumbersome.

As a Phab admin who sometimes grants access to WMF-NDA restricted tasks, I usually 1) check which SUL account is linked to the Phab account which is requesting permissions, then 2) via https://www.mediawiki.org/wiki/Special:CentralAuth/SULusername on which site that SUL account was created, and then 3) via https://accountcreationsite/wiki/Special:Log?page=User:SULusername how the SUL account was created. If it was created by WMF ITS (Office IT) I grant access.
This chain obviously fails whenever folks only link their Phab user account to an LDAP account and not to a SUL account, which makes things more cumbersome.

Yep, a procedure like this would address my concerns. But, in addition to being pretty cumbersome, it apparently produces false negatives for some older staff accounts: the logs for Mikhail Popov, James Forrester, and me just show our accounts being created normally. I thought ITS created my account, but maybe not?

Not a big problem, since we could easily develop special procedures for these rare cases, but I think it just reinforces my point that Google Chat verification is the easiest option 😊

But, in addition to being pretty cumbersome, it apparently produces false negatives for some older staff accounts: the logs for Mikhail Popov, James Forrester, and me just show our accounts being created normally. I thought ITS created my account, but maybe not?

Yours too, Andre 😂

@kzimmerman - if you wanted to have the Security-Team formally consult on this a bit more, the best way to get it into our backlog and scheduled would be to contact security-team@wikimedia.org. It sounds like there are some possibly-decent ideas being discussed here already including using the confirmation of various GSuite app operations. Some other ideas might be an officewiki edit or some post of a unique identifier to irc:#wikimedia-staff or slack:general. While none of these things guarantee the confirmation of an identity individually, in aggregate they may confer enough authentication so as to satisfy security concerns. Most of these ideas break down for non-wmf-staff/contractors, though the NDA process technical volunteers go through is likely sufficient.

Once the whole IDP setup is more complete (we're still ramping up services and extending the underlying infrastructure), the next piece on the roadmap is an identity management system with a more established workflow (which will includes features like a service owner signing off on access). That's something that we'll start working on next (calendar) year.

Ah, good to know, thanks.

That said, LDAP access requests currently need to be requested/filed in Phabricator and these accounts need to be linked to a (WMF) SUL account (which should include a challenge response against the email address (since a mail needs to be replied to)). So I don't think the impersonation angle exists per se, but maybe I'm missing some detail here?

Actually, Phabricator accounts can be linked to SUL accounts or developer accounts. So an impostor could easily create a developer account using the name of an employee, use it to log in Phabricator, and make the request.

I looked through the requests for the past several months, and almost all requesting staff members do use their WMF SUL accounts to log into Phabricator. But that's not required; for example, if you look at T256412, although both Aaron Halfaker and Chris Albon were staff at the time, neither of them had a WMF SUL account linked to their Phabricator account.

If SREs start to check that the requestor has linked a WMF SUL account, that will increase security somewhat. But as far as I can tell, the restriction on creating accounts with "WMF" in the name is enforced by the global title denylist. That can be bypassed not just by IT Services and Trust and Safety but also by any administrator, bureaucrat, or steward on Meta. Those are all trusted users, but that's still a pretty big attack surface. Generally, this isn't an issue because having the WMF tag doesn't actually grant any special permissions.

Moreover, I don't think SUL account are automatically created for all WMF staff; I believe the hiring manager has to request it as part of the onboarding since many staff don't need to do anything on public wikis.

To me, it sounds like the easiest and most resilient way to confirm WMF status would just be for the requestor (after filing the ticket) to send the SRE a Google Chat message confirming they made the request (not an email, since it's a bit more vulnerable to spoofing). This confirms they have a wikimedia.org G Suite account, which can only be created by IT Services and requires two-factor authentication, and eliminates any vulnerabilities that might be introduced by intermediate services like SUL accounts or Jumpcloud.

AFAICT the GSuite account is one of the first things that happens for onboardings and it applies to anyone independent of role, so that would certainly work.

That said "staff impersonation" can happen for any other Phab action as well and not only for requesting LDAP access, so I think we rather need a standard/user-visible way to flag a Phab account as a staff account (since the current mechanisms are hard to verify and we have lots of exceptions? Maybe there's a way to make this a designated flag in the profile or so? Then we'd only need a process to set this for all newly created accounts and a backfill for existing accounts.

Yes, this would a little bit of extra work for the SRE but it's really very minimal. It doesn't require either the SRE or the requestor to have any special access (since both will be able to access Google Chat just by going to chat.google.com) or communicate synchronously (since the SRE can just request the message on Phab and then check Google Chat after the requestor replies on Phab).

That would work, yes.

Part of this boils down to fixing onboarding docs in WMF to make people always use their WMF SUL account when creating their Phab account.
Checking for some "WMF" account name ending is not enough (as already pointed out), so use Special:Log to check if SUL accounts were created by WMF ITS.
As also already pointed out, this won't work for old staff accounts. But ITS creating SUL accounts for new staff has been standard procedure for a while now.
I don't see why GSuite would be needed (except for old staff accounts not created by ITS, and folks who haven't linked their WMF SUL account to their Phab account).

I would like to resolve this ticket by changing documentation on LDAP modification changes like this (it may not be ideal, but better than what we have now):

  • WMF staff can be added to the "wmf" group on request (not everyone needs that kind of access)
    • to confirm requested user is a staff member do both of these things:
      1. use Ldapsearch to check they have been created on the OIT ldap mirror (i.e. ldap-corp1001.wikimedia.org), ldapsearch -x uid=XXX, where XXX is the wikimedia email handle, or verify it at Namely, and
      2. make sure the Wikitech provided account has a matching verified email by running from mwmaint1002: sql --wiki labswiki -- -e "SELECT user_name, user_email, user_email_authenticated FROM user WHERE user_name='XXX'" changing XXX for the provided Wikitech user name. If correct, it should return 1 result with a matching user name, a @wikimedia.org email and a non-NULL verification date, like this:
+-----------+-----------------------+--------------------------+
| user_name | user_email            | user_email_authenticated |
+-----------+-----------------------+--------------------------+
| Jcrespo   | jcrespo@wikimedia.org | 20150623063200           |
+-----------+-----------------------+--------------------------+
    • Contractors will not appear on Namely, in which case you may ask for the person's manager/point of contact for approval, on the phabricator task.
  • Volunteers and researchers can be added to the "nda" group (this needs a valid NDA, everyone who's WMF staff is covered by the work contract NDA)
  • All other groups need to be approved by the user's manager

[I can create a tools to simplify those checks at a later time.]

For the original reporter, I think in the perticular case, that worked because there was an implied relationship trust from manager -> managee.

For the original reporter, I think in the perticular case, that worked because there was an implied relationship trust from manager -> managee.

Yes, the fact that I was a known WMF employee probably helped the request go through without any questions. But imagine if the request had come not from me but from a brand-new Phab account named "cdunn". That's compatible both with the real Carol making the request and an impostor, so it's not clear that anyone would have checked to make sure that was the real Carol.

In any case, I think your plan is a good one! Thanks for taking the time to propose it.

Contractors will not appear on Namely, in which case you may ask for the person's manager/point of contact for approval, on the phabricator task.

But imagine if the request had come not from me but from a brand-new Phab account named "cdunn". That's compatible both with the real Carol making the request and an impostor, so it's not clear that anyone would have checked to make sure that was the real Carol.

It might be a good idea to state within the proposed documentation that some kind of video call and/or public key or confirmed identity check is better for manager verification than a simple interaction or comment on Phabricator. If those checks cannot be performed, then the Phabricator method would have to suffice.

Volunteers and researchers can be added to the "nda" group (this needs a valid NDA, everyone who's WMF staff is covered by the work contract NDA)

It might be nice to link to the current volunteer NDA policy here and/or point to a recent example since this process does not occur very often AFAIK.

It might be a good idea to state within the proposed documentation that some kind of video call and/or public key or confirmed identity check is better for manager verification than a simple interaction or comment on Phabricator.

Not sure if you are suggesting it in case an "SBasset2" claims to be the manager of a new contractor/volunteer. In that case, the same verification on ldapcorp + wikitech should happen as for the other stuff (we can document that).

Or maybe you are suggesting it that the account has been taken over- in which case, for me a videocall may not be useful, as while I interact with many people on my day to day, I am really bad with faces and I haven't attended the last 3 allhands. This is an anecdote, but I don't think this case is something we can take care of with current technology. I would like to roll in a better procedure but being more sophisticated in the future (as Moritz mentioned above, with helpful sofware and or hw tokens, etc.) rather than keeping the current bad one. Also trying to be practical and reduce overhead, given we have 2-10 access requests a week. Let's fix the reported bug in the original scope (impersonation) and iterate later.

It might be nice to link to the current volunteer NDA policy here and/or point to a recent example since this process does not occur very often AFAIK.

Sure, np. I create a rough draft that we can edit further on the wiki.

Not sure if you are suggesting it in case an "SBasset2" claims to be the manager of a new contractor/volunteer. In that case, the same verification on ldapcorp + wikitech should happen as for the other stuff (we can document that).

Or maybe you are suggesting it that the account has been taken over- in which case, for me a videocall may not be useful, as while I interact with many people on my day to day, I am really bad with faces and I haven't attended the last 3 allhands. This is an anecdote, but I don't think this case is something we can take care of with current technology. I would like to roll in a better procedure but being more sophisticated in the future (as Moritz mentioned above, with helpful sofware and or hw tokens, etc.) rather than keeping the current bad one. Also trying to be practical and reduce overhead, given we have 2-10 access requests a week. Let's fix the reported bug in the original scope (impersonation) and iterate later.

Really either scenario, I suppose. These were more alternative suggestions to the ldapcorp + wikitech method in case that process failed for some reason or was not entirely determinative. While inconvenient, a video call with other Foundation employees who personally know a given individual could work to authenticate said individual by a sort of transitive consensus. Anyhow, these were just meant as additional options to consider, given how trivial it can be to spoof users and various interactions within Phabricator.

Ah, as an alternative, I think it is a good idea, just the original way would be more streamlined if available.

Before you can verify with a manager if the employee who claims they are an employee is actually one .. you need to know who the manager of that person even is. Another "random" user saying "approved" on a ticket does not say a whole lot. Does WMF provide an orgchart that is kept up to date where it can be checked? The current method I would use is to lookup in corp LDAP but that information is only entered once when people are hired and if there are changes later it is not being updated.

I also don't think that video calls are a great fix for the issue for the same reasons Jaime already mentioned. We have not seen people before, wouldn't know who to call, would have to coordinate timezones, invite them via calendar..and that doesn't scale well with multiple requests each week.

The current method I would use is to lookup in corp LDAP but that information is only entered once when people are hired and if there are changes later it is not being updated.

I just noticed that when I added the wrong person on an access ticket. Will make sure to recommend to use some of the HR tools instead- they won't be foolproof, but they will be better.

I will wait for people from operational security to comment on my proposal, and if there is no big blocker, I would like to update the docs and move forward with the improvements + feedback received here from you, and always open for further refinements afterwards.

Does WMF provide an orgchart that is kept up to date where it can be checked?

As mentioned or implied in previous comments, the canonical system for this information, AIUI, is wikimedia.namely.com. Particularly under the "People" tab within the top navigation, once a regular user logs into that system. If one searches for and clicks on an individual, and then clicks upon their "Teams & Allocations" tab, Namely displays "Reports To" information, which I believe Talent & Culture view as authoritative. Though it does not appear that certain contractors are available within this system (looks like only reqID holders.)

Aklapper renamed this task from Process for granting wmf LDAP access is vulnerable to impersonation to Process for granting wmf LDAP access is vulnerable to impersonation (after creating a Wikitech account with an unconfirmed email address).Jul 24 2021, 2:11 PM

I would like to resolve this ticket by changing documentation on LDAP modification changes like this (it may not be ideal, but better than what we have now):

  • WMF staff can be added to the "wmf" group on request (not everyone needs that kind of access)
    • to confirm requested user is a staff member do both of these things:
      1. use Ldapsearch to check they have been created on the OIT ldap mirror (i.e. ldap-corp1001.wikimedia.org), ldapsearch -x uid=XXX, where XXX is the wikimedia email handle, or verify it at Namely, and
      2. make sure the Wikitech provided account has a matching verified email by running from mwmaint1002: sql --wiki labswiki -- -e "SELECT user_name, user_email, user_email_authenticated FROM user WHERE user_name='XXX'" changing XXX for the provided Wikitech user name. If correct, it should return 1 result with a matching user name, a @wikimedia.org email and a non-NULL verification date, like this:
+-----------+-----------------------+--------------------------+
| user_name | user_email            | user_email_authenticated |
+-----------+-----------------------+--------------------------+
| Jcrespo   | jcrespo@wikimedia.org | 20150623063200           |
+-----------+-----------------------+--------------------------+
    • Contractors will not appear on Namely, in which case you may ask for the person's manager/point of contact for approval, on the phabricator task.
  • Volunteers and researchers can be added to the "nda" group (this needs a valid NDA, everyone who's WMF staff is covered by the work contract NDA)
  • All other groups need to be approved by the user's manager

This bug has been open for more than a year now, and this change would fix the problem pretty well! Are there any objections to updating the docs as @jcrespo proposed?

I've also moved these docs to https://wikitech.wikimedia.org/wiki/SRE/Clinic_Duty/Access_requests and protected them so then can only be edited by Wikitech content administrators. This way, a malicious actor can't edit the page to remove important checks.

@nshahquinn-wmf Obviously, as the original proposer, I am in favor to introduce this new policy. With some caveats:

  • I have since been told and checked that corporate ldap can contain outdated information. HR updates Namely but corporate ldap is only updated on hiring, as far as I could check. I think corp ldap is useful, as it is more convenient and it will not have been entered without someone being hired (no randos), but we should stress Namely is the canonical place
  • I have seen more and more contractors asking for access- those relay completely on Manager's promise they have signed a contract with us- they are not on Namely and only sometimes they are in corp-ldap (e.g. person-ctr@wikimedia.org)
  • We should wait for @MoritzMuehlenhoff, our most veteran account handler within SRE, as I believe he mentioned to me he wanted to check personally this at a later time- he is right now on vacation, will return soon.
  • I have since been told and checked that corporate ldap can contain outdated information. HR updates Namely but corporate ldap is only updated on hiring, as far as I could check. I think corp ldap is useful, as it is more convenient and it will not have been entered without someone being hired (no randos), but we should stress Namely is the canonical place

Do we actually need to check Namely or corporate LDAP? If the person has a confirmed wikimedia.org email address on Wikitech, I think it's pretty safe to assume they are staff or a contractor. So perhaps that could be the only check.

If we are worried about former staff pretending they are still staff, we could check that the email confirmation date is relatively recent (within the last 2 weeks?). The requestor can easily remove and reconfirm their address on Wikitech to get an updated confirmation date.

  • I have seen more and more contractors asking for access- those relay completely on Manager's promise they have signed a contract with us- they are not on Namely and only sometimes they are in corp-ldap (e.g. person-ctr@wikimedia.org

Hmm...it looks like Katie Francis from Legal is already available on Phab to confirm NDA status for contractors, volunteers, and WMDE staff (e.g. T283648#7116585). For contractors without email addresses, could we just add the step of asking her?

  • We should wait for @MoritzMuehlenhoff, our most veteran account handler within SRE, as I believe he mentioned to me he wanted to check personally this at a later time- he is right now on vacation, will return soon.

Yes, of course.

Hey, @MoritzMuehlenhoff, I believe (but I may be misremembering) you told me that you wanted to check this task at a later time. Could you please rise issues against @nshahquinn-wmf proposal so we can move forward with some solution (even if not perfect)? I can do a simple bash script to hide the sql complexity to make it simpler, if necessary.

Hey, @jbond, I am about to reward your great work regarding authentication with more work 0:-). Given your recent work on authentication processes and its documentation, could you or @joanna_borun take ownership of the resolution of this ticket?

Just trying to move it forward. We can also merge it or make it a subticket of a documentation ticket, if you have one.

Boldly adding the tag here. Not intending to pressure work, but to make sure we are blocked on the right reasons 0:-).

@nshahquinn-wmf @jbond I've created a proof of concept of the query so that we can escape the email string on sql: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaMaintenance/+/720077 . I honestly don't have enough mediawiki experience to convert that into a proper deployable script, but it works as -well- a proof of concept on my local wiki. Could someone help me getting that into a reasonable state for this?

however, as far as I'm aware it doesn't grant access to any truly confidental data like reader IP addresses or editor emails

It does, turnilo offers sampled webrequests. Not all readers are included, but some will be. It also allows you to +2 any patch in mediawiki/*, which is a dangerous ability in hands of an attacker.

@nshahquinn-wmf @jbond I've created a proof of concept of the query so that we can escape the email string on sql: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaMaintenance/+/720077 . I honestly don't have enough mediawiki experience to convert that into a proper deployable script, but it works as -well- a proof of concept on my local wiki. Could someone help me getting that into a reasonable state for this?

I'll be happy to help with this! I left some preliminary review on the patch -- let me know if you have any questions or issues I could help with.

however, as far as I'm aware it doesn't grant access to any truly confidental data like reader IP addresses or editor emails

It does, turnilo offers sampled webrequests. Not all readers are included, but some will be. It also allows you to +2 any patch in mediawiki/*, which is a dangerous ability in hands of an attacker.

Ahh, thank you—this is a very important point! Thanks also for your help with the script!

@Urbanecm as you might have seen in the Gerrit discussion, @jcrespo isn't able to finish and merge the patch. Could you possibly do that? I would, but I have very little experience with MediaWiki. Please let me know if there's anything not requiring MediaWiki expertise I can do to help 😊

@jbond Thank you so much for getting the script finished! Is there any blocker to updating the process to use the script? I'd be happy to help with updating the documentation if that's the main remaining work.

@nshahquinn-wmf i was just waiting for https://gerrit.wikimedia.org/r/c/720077 to get deployed (which has happened now) so that i could update https://gerrit.wikimedia.org/r/c/720015, ill do that today then update the wiki page

to get deployed (which has happened now)

correction it has only been deployed to group 0, labswiki is in group 1 so should get deployed today

hi all i have deployed an updated version of the script to the cumin hosts, before i update the documentation i could useres on this task (with access to cumin) give the script a test and provided any feedback on weather the output needs to change etc, or if we should add some additional messaging.

below is example output testing against my own account

$ sudo check_user jbond@wikimedia.org
WikiTech Users:
        Username:       Jbond42
        Verified Email: 20190107105404
        Username:       Jbond
        Verified Email: 20190110142649

Gsuit User:
        name:           John Bond
        title:          Senior Site Reliability Engineer
        manager:        fliambotis@wikimedia.org
        agreedToTerms:  True

one thing that has just been mentioned to me is that the gsuite information only outputs the Legal name, i will check with OIT to see if the preferred name is available in Gsuite, otherwise i think it may be better to just drop the name all together, thoughts?

gsuite information only outputs the Legal name
thoughts?

I think it is even worse than that- as fast as I understood, corporate ldap gets updated once- on insertion (and maybe on disabling) by OIT, and many facts there are outdated- so it is not a reliable source of information, I was able to check and suffer from it in the past. E.g. for example, if a contractors is later hired, corp ldap is not always updated. I was told to always use the HR tool for an up to date check of the position and relevant data we may need as account administrators. It may be only useful as an imperfect secondary check to verify affiliation through mail, and focus on non-corporate LDAP/wikitech and Phabricator to verify email identity ownership.

Consider also printing the cn and the uid from non-corp LDAP, as they can be different and some services use only one of them, like https://ldap.toolforge.org/user/jynus does (a nice to have).

gsuite information only outputs the Legal name
thoughts?

I think it is even worse than that- as fast as I understood, corporate ldap gets updated once- on insertion (and maybe on disabling) by OIT, and many facts there are outdated- so it is not a reliable source of information,

Indeed im working with OIT to see if i can get a namely API key

It may be only useful as an imperfect secondary check to verify affiliation through mail, and focus on non-corporate LDAP/wikitech and Phabricator to verify email identity ownership.

Yes right now its more a case of this is the best we have, once/if i get a namely api key will switch to that

Consider also printing the cn and the uid from non-corp LDAP, as they can be different and some services use only one of them, like https://ldap.toolforge.org/user/jynus does.

ack i can look to add that

right now its more a case of this is the best we have

100% agree- my note was to remind us that the scope of this task is to prevent email impersonation. If someone can check that the email corresponds to a real employer (through HR, or secondarily, through corp-ldap), has the confirmation of the manager, and the email has been verified, there is no gap on the chain of trust- unless a 3rd person has taken over the email (in which case, none of these tools will be helpful against this).

What I want to mean with this is that I am all for automation -specially for complex queries, like the one for wikitech, which was not trivial- but we can improve later further, one step at a time. With the email verification we close already the original reported issue of "a random person can file a ticket/register a wikitech account to that email without controlling it". The rest can be improvement on procedure only, and include some semi-manual checks :-). AKA we can file a separate task for full automation, doesn't have to happen here and now.

This was my initial fix proposal, which I think we are almost there- as soon as we update the procedure :-) T259746#6765154

...there is no gap on the chain of trust- unless a 3rd person has taken over the email (in which case, none of these tools will be helpful against this).

We talked about this a bit in previous comments and I agree that a video call with someone you've never met or only vaguely remember isn't sufficient to confirm their identity. But a live, recorded video call, where an individual is sent an email to one of their ldap/namely-confirmed email addresses, with a hash or pass phrase, and then asked to repeat said hash or pass phrase to the sender (the person confirming the identity) would likely be effective in confirming an identity. This would prove the individual on the call is either the legitimate owner of the email address or an attacker who has just incriminated themselves on a recorded video call, which would likely be a big enough disincentive so as to prevent such a scenario from ever happening. Of course this process is possibly too onerous for this level of identity confirmation.

hi all i have deployed an updated version of the script to the cumin hosts, before i update the documentation i could useres on this task (with access to cumin) give the script a test and provided any feedback on weather the output needs to change etc, or if we should add some additional messaging.

@jbond do you think we're ready to update the documentation? As I said, let me know and I would be happy to help with that.

hi all i have deployed an updated version of the script to the cumin hosts, before i update the documentation i could useres on this task (with access to cumin) give the script a test and provided any feedback on weather the output needs to change etc, or if we should add some additional messaging.

@jbond do you think we're ready to update the documentation? As I said, let me know and I would be happy to help with that.

yes, sorry for the delay. I have added something to the access request instructions for the sre clinic duty, please give it a look and update as necessary, thanks

Thanks @jbond! I edited the section you wrote and included references to it in the appropriate places in the instructions. If you agree with the changes, I think we might be able finally close this task!

jbond claimed this task.

thanks @nshahquinn-wmf LGTM, resolving

Very cool! What's the process for making resolved security issues like this public? Is that something we should do now?

@Aklapper are you able to help with how to make this public, i dont seem to have permission to change the view policy, thanks

Very cool! What's the process for making resolved security issues like this public? Is that something we should do now?

I think the Security team has a process for this (after reviewing it again).

Very cool! What's the process for making resolved security issues like this public? Is that something we should do now?

I think the Security team has a process for this (after reviewing it again).

Basically if there's no PII or other sensitive information that could be detrimental to the Foundation or Movement if made public, we can make a task public. I would assume that's likely the case for this task, but I'll re-triage this for review during our next clinic.

sbassett changed the task status from In Progress to Open.
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 Low.
sbassett moved this task from Incoming to Our Part Is Done on the Security-Team board.