GHSA-9vr9-463q-46qp: Session fixation in the CLI login flow allows an unauthenticated attacker to obtain a user's API token

Summary

Session Fixation vulnerability in the CLI login flow in nerves-hub nerveshubweb allows an unauthenticated attacker to obtain an API token for another user's account via a crafted login link. Starting a CLI login with POST /api/auth/clisession needs no authentication and returns a polling token, a confirmation URL that carries that token, and a confirmation code. When a signed-in user opens that URL and clicks Confirm, NervesHub.Accounts.verifyclisessiontoken/2 creates an API token for the user's account and stores it on the login, and the next poll of GET /api/auth/clisession/<token> returns it to whoever started the login.

The confirmation code is only displayed and is never compared with anything, so it cannot show that the person confirming is the one who started the login. The confirm form carries a CSRF token and the page cannot be framed, so the attacker has to persuade the user to open the link and click the button themselves.

This issue affects nerveshub: from 2.5.0 before 2.5.3.

Details

1. Starting a login. nh user login, like any client of this flow, calls POST /api/auth/clisession, which needs no authentication. NervesHubWeb.API.UserController.clisession/2 calls NervesHub.Accounts.generateclisessiontoken/1, which stores a waiting login in the CLI session cache under a random UUID token with a six-digit confirmation code, and responds with the token, the code, and the URL /auth/cli/<token>.

2. Approving a login. GET /auth/cli/<token> requires a signed-in web user. NervesHubWeb.SessionController.cli/2 finds the login by the token from the URL, shows the code, and renders a form that posts back to /auth/cli/<token>. The form carries no code field. cliconfirm/2 passes the signed-in user and the token to NervesHub.Accounts.verifyclisessiontoken/2, which creates an API token for that user with createuserapitoken/2 and stores it on the login. Nothing compares the confirmation code with anything.

3. Collecting the token. GET /api/auth/clisession/<token>, also unauthenticated, returns the stored API token once the login is confirmed. Whoever started the login holds the token from step 1 and can poll until it arrives. The token is an ordinary API token and stays valid until the user deletes it.

Proof of concept

1. With no account, run curl -X POST https://<host>/api/auth/clisession. Note token, url and confirmationcode from the response. 2. Send url to someone with a NervesHub account, with a message such as "Please verify your NervesHub CLI access. Your code is <confirmationcode>." 3. They open it while signed in, see the code they were told to expect, and click "Confirm login". 4. curl https://<host>/api/auth/clisession/<token> returns "status": "ready" and a usertoken. 5. Send API requests with Authorization: token <usertoken>. They run as the person who confirmed.

Impact

An attacker with no account obtains an API token for any NervesHub user they can persuade to open a link and click Confirm. The token acts as that user through the API in every organization they belong to, at their role, until the user deletes it on the account page. Signing out of the web does not revoke it.

Workarounds

Block POST /api/auth/clisession at the reverse proxy until the upgrade. It is the only entry point that creates a CLI login, so no link can be produced while it is blocked. CLIs can still sign in with an email and password (nh user auth, POST /api/users/auth), or use an API token created on the account page.

Solutions

Upgrading does not revoke tokens already handed out. A token from a CLI login is an ordinary API token with a note the client chose, so one an attacker obtained looks like any other. After upgrading, users should review their API tokens on the account page and delete any they do not recognise.