Unauthorized Privilege Escalation: Gaining Command Line Access on Unpermitted Company Devices $$$$

السلام عليكم

.بِسْم اللَّه الرَّحْمن الرَّحِيم . . اللَّهمَّ صَلِّ وَسلَّم وبارك على نَبِينَا مُحمَّد

Hello, hackers. My name is Mohamed Ashraf(Sp1der0x). Today, I’ll be discussing a bug I recently discovered while hunting a few days ago.

Summary
In my recent vulnerability discovery, I uncovered a serious **Privilege Escalation (PrivEsc)** flaw within the spider.com system. This flaw enables any **Technician** with permissions on one company’s devices to gain command-line access to devices in a separate, unauthorized company by modifying specific request parameters. This access circumvents the permissions and allows unauthorized command-line control, posing a major security threat.

Target and Setup

While conducting an assessment on spider.com, I created a simulated environment with two companies:
- **Company 1**: Full access granted to a Technician.
- **Company 2**: No permissions given to the Technician.

This scenario ensured a controlled test environment to validate the permissions and to see if I could exploit any flaws to breach access on devices outside the Technician’s intended scope.

The Vulnerability

In **Company 1**, the Technician can add **End Users** to devices with specific permissions, including access to the command-line interface for device management. Here’s the breakdown of the exploitation process:

1. **Adding an End User with Command-Line Permissions**:
Within Company 1, I created a new **End User** with a role that includes access to the command-line on the designated company devices.

2. **Intercepting the API Request for Device Permissions**:
When the Technician assigns the End User to a device, the system sends a request that includes device identification information, specifically `deviceId`. The request looked something like this:

POST /ws/end-user/”enduser-id”/devices/addList HTTP/2
Host: spider.com
Cookie: sessionKey=”Technician Session here”
…
{“deviceIds”: [DEVICE_ID_OF_COMPANY_1]}

3. **Modifying the Device ID**:
To test unauthorized access, I intercepted the request and replaced the `DEVICE_ID_OF_COMPANY_1` with the `DEVICE_ID` of a device from **Company 2**. This is a device for which the Technician theoretically had no permissions.

4. **Gaining Unauthorized Access**:
Surprisingly, the system accepted this modified request, and the **End User** was successfully granted command-line access to the **Company 2** device. This action effectively bypassed any restrictions on device access within separate companies, granting unintended command-line privileges.

— -

Technical Analysis and Impact

The flaw arises from a lack of validation on the `deviceId` parameter, allowing users to manipulate it and target any accessible device, even those in separate organizational scopes. This manipulation bypasses the boundaries designed to prevent inter-company access, compromising the isolation between companies and allowing attackers to:
— Execute commands on unauthorized devices.
— Bypass access restrictions designed to safeguard company boundaries.
— Potentially disrupt the operations or compromise the security of the affected devices in Company 2.

This exploit highlights a critical lapse in access control validation. In real-world usage, any **Technician** could leverage this vulnerability to access sensitive information or compromise devices outside their permitted scope.