Improper Access Control in zulip/zulip
Reported on
Feb 15th 2022
Description
According to the current design of the application, when the user wants to get value of api_key, API /json/fetch_api_key will require password to authentication. However, the application exists another API routed at /json/users/me/api_key/regenerate that allows regenerating api_key value and doesn't requiring password authentication. Attacker who gets the user's valid session can call vulnerable API to extract the api_key value without user's password.
Proof of Concept
I'm using online service at https://testingnnnn.zulipchat.com.
- Step 1: Login as normal user, go to https://testingnnnn.zulipchat.com/#settings/account-and-privacy, click "Show/change your API key", application will ask for password to perform the action.
- Step 2: In current session, call this request to regenerate and get value of api_key
POST /json/users/me/api_key/regenerate HTTP/2
Host: testingnnnn.zulipchat.com
Cookie: [YOUR_VALID_COOKIE]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: vi-VN,vi;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
X-Csrftoken: [VALID_CSRF_TOKEN]
X-Requested-With: XMLHttpRequest
Referer: https://testingnnnn.zulipchat.com/
Connection: close
- PoC:
Show api_key: https://drive.google.com/file/d/1_A7KQeoyByA3xYwIyJ1k9ZTywabwlEMM
Regenerate api_key: https://drive.google.com/file/d/1Ob96FTju4irz2Hn2sXBXz_JtMlEAmAp0
Impact
Bypass the protection mechanism in the design of the application. Attackers can get the api_key value without knowing user's password.
Thank you for the report! We can confirm that this endpoint should either not return the new key, or require additional protections.
We need to discuss the precise shape of the fix we want here. Please hold off on disclosing this vulnerability publicly until we can decide on the right fix, and have prepared a release containing it. There's another security issue that we need to coordinate with in that release, so it may not be immediate; we'll keep you appraised as we get a better sense of the timeline.
@admin: Can you allocate this a CVE?
@alexmv - I have assigned a CVE to the report. Once you are happy to publish the CVE, just give me a ping, and I will be happy to get it published for you!
Hi @admin,
I would like to ask why the CVE of this vulnerability has 2021?
Regards.
As a CNA, we are encouraged to use all CVE IDs that are reserved. These are CVE IDs that we have previously reserved but did not end up getting used/published.
I have checked the CVE rules and I cannot find any rules against using CVE IDs with a different year identifier.
@nhiephon, how would you like to be credited in our release notes?
We expect the release to go out in the next couple days; I'll update here to confirm the fix once the release is complete and the commit with the fix is public.
Great, keep me posted and I will publish the CVE once you are ready as well! 🎊
@Maintainer,
Please credit with my nickname and twitter. nhiephon (twitter.com/_nhiephon)
Regards.
We've just released Zulip 4.10, which resolves this vulnerability; d5db254ca8167995a1654d1c45ffc74b2fade39a is the fix on main.