Summary

Improper Authentication vulnerability in Google sign-in and email confirmation in nerves-hub nerveshubweb allows an attacker who registers another person's email address to share that person's account once they sign in. NervesHub.Accounts.updateorcreateuserfromueberauth/1 signs a Google user in to any account carrying the same email that is not yet linked to a Google account, links it and marks the email confirmed, without the account's owner ever having proved they own the address. NervesHubWeb.SessionController.confirm/2 likewise signs in whoever follows a confirmation link. An attacker registers the address from the sign-up form, changes their own account's email to it, or registers it as an organization admin from an invite link, and keeps the password; when the address's owner signs in with Google or follows the confirmation link, they land in that account.

The Google path also creates accounts with registrations closed and never checks Google's emailverified claim, and the API's password sign-in in NervesHubWeb.API.UserController issues tokens to accounts whose email was never confirmed. The attacker gains only what the victim is granted afterwards, and nothing on accounts whose owners never use either path.

This issue affects nerveshub: from 2.3.0 before 2.5.3.

Proof of concept

With Google sign-in turned on and registrations open:

1. Register an account with victim@example.com and a password you choose. Do not confirm it. 2. The owner of victim@example.com signs in to NervesHub with Google for the first time. They are signed in to your account, and its email is now marked confirmed. 3. An organization invites victim@example.com and the victim accepts while signed in. 4. Sign in with victim@example.com and your password. You are a member of the organization at the role it gave the victim.

Without Google sign-in, as an admin of an organization:

1. Invite victim@example.com, copy the invite link from the members page, and register from it with a password you choose. 2. Try to sign in with victim@example.com and your password. NervesHub refuses, since the email is not confirmed, and emails victim@example.com a confirmation link. 3. The victim follows the link and is signed in to your account. Keep using your session or sign in with your password.

Impact

An attacker who registers someone else's email address before that person first signs in with Google, or before they follow a confirmation link, ends up sharing that person's account: the attacker keeps signing in with the password they chose and sees and does whatever the victim can, in every organization the victim joins, at the victim's role. On an account linked to Google the victim cannot reset the password to lock the attacker out.

Workarounds

Turn off Google sign-in by unsetting GOOGLECLIENTID until the upgrade; users who only sign in with Google cannot sign in while it is off. This does not close the confirmation link path. Turning off registrations stops strangers using the sign-up form, but not an organization admin registering from an invite link.

Solutions

Upgrading does not undo links already made. Review the users rows that carry both a passwordhash and a googleid; most are one person signing in both ways, but an account registered for someone else's address was usually created well before its first Google sign-in, so compare insertedat with googlelastsyncedat. For one its owner did not set up, set its googleid to NULL, delete its usertokens rows to end its sessions and revoke its API tokens, and have the address's owner reset the password. An account taken through a confirmation link looks the same as one its owner set up; its owner can end anyone else's access by resetting the password, which ends every session and revokes every API token. Before upgrading, check how your instance lets people sign up: SIGNUPMETHODS replaces OPENFORREGISTRATIONS, and instances that relied on Google sign-in to create accounts while registrations were off need SIGNUPMETHODS=google.

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.

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.