GHSA-2j7r-q3vm-8j34: Incorrect authorization in the devices page bulk move allows view-role members to move devices into another organization and receive its firmware

Summary

Incorrect Authorization vulnerability in the devices page bulk move in nerves-hub nerveshubweb allows an authenticated user with the manage role in one organization and only the view role in another to move devices into the second organization's product via the "Move device(s) to product" action. The target-product event in NervesHubWeb.Live.Devices.Index looks the product up with NervesHub.Products.getbyid/2, which checks that the user is a member of the product's organization at any role, and move-devices-product then changes each selected device's organization and product. The device API's move requires manage in the target organization, and an earlier fix added the check on the organization the devices leave but not on the one they enter.

A moved device keeps its key and certificate, joins the target organization's matching deployment groups, and is sent their firmware with a download URL, which the view role cannot otherwise obtain. The user cannot change or control devices that already belong to the other organization.

This issue affects nerveshub: from 1.0.0 before 2.5.3.

Details

1. Target selection. The bulk actions sidebar (NervesHubWeb.Components.BulkActionsSidebar) lists the products of every organization in currentscope.user.orgs. Choosing one sends target-product to NervesHubWeb.Live.Devices.Index, which requires device:update in the current organization and then calls NervesHub.Products.getbyid/2. That query joins the product's organization to its orgusers rows and filters on the user's id only, so any membership in the target organization satisfies it, including the view role.

2. The move. move-devices-product passes the selected devices, or every device matching the current filter, to NervesHub.Devices.BulkActions.movemany/3, which calls Devices.move/3 for each one and rewrites its orgid and productid. No check of the user's role in the target organization happens on this path, while the API's move in NervesHubWeb.API.DeviceController requires manage there.

3. Effect. The moved device still authenticates with its own certificate. On its next connection it is matched against the target product's deployment groups by platform, architecture and tags, joins one, and is sent that group's firmware with a download URL.

Proof of concept

As a user with manage in organization A and view in organization B, where B has an active deployment group:

1. On A's devices page, give a device you control the tags B's deployment group asks for. A view member can see the group's conditions. 2. Select the device, choose B's product under "Move device(s) to product" and press Move. The page reports the move as successful, and the device is now in B's product. 3. Connect the device, reporting the platform and architecture of the group's firmware. It joins the group and is sent B's firmware with a download URL.

Impact

A user who manages devices in one organization and holds only the view role in another can move their own devices into the second organization. The devices join its matching deployment groups and receive its firmware, which the view role cannot otherwise download, and they report health, logs and alarms into that organization. Devices already belonging to the other organization are not affected.

Solutions

Every move is recorded in the target product's audit log as "User <name> moved device <identifier> to <org> : <product>". After upgrading, review the auditlogs rows with resource type NervesHub.Products.Product and a description containing "moved device" whose actor does not hold the manage or admin role in that organization, and move or remove the devices they brought in. Roles may have changed since a move, and entries older than the retention period are gone when TRUNCATEAUDITLOGSENABLED is on.