Impact

This vulnerability impacts anyone running the affected versions of Wings. The vulnerability can potentially be used to access files and directories on the host system. The full scope of impact is exactly unknown, but reading files outside of a server's base directory (sandbox root) is possible.

In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings. Details on the exploitation of this vulnerability are embargoed until March 27th, 2024 at 18:00 UTC.

Resolution

In order to mitigate this vulnerability, a full rewrite of the entire server filesystem was necessary. Because of this, the size of the patch is massive, however effort was made to reduce the amount of breaking changes. While tests were written to ensure security and functionality, there may be some semantic differences of certain operations, such as different errors being returned for example. If you notice any major semantic differences, please open an issue on our issue tracker so it can be resolved. <https://github.com/pterodactyl/panel/issues/new/choose>

Patches

This vulnerability has been resolved in version v1.11.9 of Wings.

Everyone should update to Wings v1.11.9 (or newer).

Workarounds

None.

Wings is Pterodactyl's server control plane. This vulnerability can be used to delete files and directories recursively on the host system. This vulnerability can be combined with GHSA-p8r3-83r8-jwj5 to overwrite files on the host system. In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings. This vulnerability has been resolved in version v1.11.4 of Wings, and has been back-ported to the 1.7 release series in v1.7.4. Anyone running v1.11.x should upgrade to v1.11.4 and anyone running v1.7.x should upgrade to v1.7.4. There are no known workarounds for this issue.

Summary

A missing authorization check in multiple controllers allows any user with access to a node secret token to fetch information about any server on a Pterodactyl instance, even if that server is associated with a different node. This issue stems from missing logic to verify that the node requesting server data is the same node that the server is associated with.

Any authenticated Wings node can retrieve server installation scripts (potentially containing secret values) and manipulate the installation status of servers belonging to other nodes. Wings nodes may also manipulate the transfer status of servers belonging to other nodes.

This vulnerability requires a user to acquire a secret access token for a node. We rated this issue based on potential worst outcome. Unless a user gains access to a Wings secret access token they would not be able to access any of these vulnerable endpoints, as every endpoint requires a valid node access token.

Details 1. The Remote API endpoint GET /api/remote/servers/{uuid} fetches a server by UUID and returns its complete configuration without verifying that the requesting node owns the server. 2. Both failure() and success() methods in ServerTransferController fetch servers by UUID without verifying node ownership. 3. Missing authorization checks in ServerInstallController allow any authenticated Wings node to retrieve egg installation scripts (containing deployment secrets) and manipulate the installation status of servers belonging to other nodes.

Impact A single compromised Wings node daemon token (stored in plaintext at /etc/pterodactyl/config.yml) grants access to sensitive configuration data of every server on the panel, rather than only to servers that the node has access to. An attacker can use this information to move laterally through the system, send excessive notifications, destroy server data on other nodes, and otherwise exfiltrate secrets that they should not have access to with only a node token.

Additionally, triggering a false transfer success causes the panel to delete the server from the source node, resulting in permanent data loss.

Impact

This vulnerability impacts anyone running the affected versions of Wings. This vulnerability can be used to gain access to the host system running Wings if a user is able to modify an server's install script or the install script executes code supplied by the user (either through environment variables, or commands that execute commands based off of user data).

Patches

This vulnerability has been resolved in version v1.11.6 of Wings, and has been back-ported to the 1.7 release series in v1.7.5.

Anyone running v1.11.x should upgrade to v1.11.6 and anyone running v1.7.x should upgrade to v1.7.5.

Workarounds

Running Wings with a rootless container runtime may mitigate the severity of any attacks, however the majority of users are using container runtimes that run as root as per our documentation.

SELinux may prevent attackers from performing certain operations against the host system, however privileged containers have a lot of freedom even on systems with SELinux enabled.

TL;DR: None at this time.

Extra details

It should be noted that this was a known attack vector, for attackers to easily exploit this attack it would require compromising an administrator account on a Panel. However, certain eggs (the data structure that holds the install scripts that get passed to Wings) have an issue where they are unknowingly executing shell commands with escalated privileges provided by untrusted user data.

Wings is Pterodactyl's server control plane. Affected versions are subject to a vulnerability which can be used to create new files and directory structures on the host system that previously did not exist, potentially allowing attackers to change their resource allocations, promote their containers to privileged mode, or potentially add ssh authorized keys to allow the attacker access to a remote shell on the target machine. In order to use this exploit, an attacker must have an existing "server" allocated and controlled by the Wings Daemon. This vulnerability has been resolved in version v1.11.3 of the Wings Daemon, and has been back-ported to the 1.7 release series in v1.7.3. Anyone running v1.11.x should upgrade to v1.11.3 and anyone running v1.7.x should upgrade to v1.7.3. There are no known workarounds for this vulnerability.

Workarounds

None at this time.

Impact

If the Wings token is leaked either by viewing the node configuration or posting it accidentally somewhere, an attacker can use it to gain arbitrary file write and read access on the node the token is associated to.

Workarounds

Enabling the ignorepanelconfigupdates option or updating to the latest version of Wings are the only known workarounds.

Patches

https://github.com/pterodactyl/wings/commit/5415f8ae07f533623bd8169836dd7e0b933964de

Summary Websockets within wings lack proper rate limiting and throttling. As a result a malicious user can open a large number of connections and then request data through these sockets, causing an excessive volume of data over the network and overloading the host system memory and cpu.

Additionally, there is not a limit applied to the total size of messages being sent or received, allowing a malicious user to open thousands of websocket connections and then send massive volumes of information over the socket, overloading the host network, and causing increased CPU and memory load within Wings.

Summary Wings does not consider SQLite max parameter limit when processing activity log entries allowing for low privileged user to trigger a condition that floods the panel with activity records

Details After wings sends activity logs to the panel it deletes the processed activity entries from the wings SQLite database. However, it does not consider the max parameter limit of SQLite, 32766 as of SQLite 3.32.0.

If wings attempts to delete more than 32766 entries from the SQLite database in one query, it triggers an error (SQL logic error: too many SQL variables (1)) and does not remove any entries from the database. These entries are then indefinitely re-processed and resent to the panel each time the cron runs.

https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/activitycron.go#L81 https://github.com/pterodactyl/wings/blob/9ffbcdcdb1163da823cf9959b9602df9f7dcb54a/internal/cron/sftpcron.go#L86

PoC Any method that can create the required 32767+ activity entries can trigger this vulnerability. It can (and has) been triggered by normal (non-malicious) use. I attached a simple PoC I used while verifying this that uses sftp to quickly create many small files, thus creating activity entries in the SQLite database. https://ptero.co/mococesoca.go

Impact By successfully exploiting this vulnerability you can trigger a situation where wings will keep uploading the same activity data to the panel repeatedly (growing each time to include new activity) until the panels’ database server runs out of disk space.

Pterodactyl is an open-source game server management panel built with PHP 7, React, and Go. A malicious user can modify the contents of a confirmationtoken input during the two-factor authentication process to reference a cache value not associated with the login attempt. In rare cases this can allow a malicious actor to authenticate as a random user in the Panel. The malicious user must target an account with two-factor authentication enabled, and then must provide a correct two-factor authentication token before being authenticated as that user. Due to a validation flaw in the logic handling user authentication during the two-factor authentication process a malicious user can trick the system into loading credentials for an arbitrary user by modifying the token sent to the server. This authentication flaw is present in the LoginCheckpointController@invoke method which handles two-factor authentication for a user. This controller looks for a request input parameter called confirmationtoken which is expected to be a 64 character random alpha-numeric string that references a value within the Panel's cache containing a userid value. This value is then used to fetch the user that attempted to login, and lookup their two-factor authentication token. Due to the design of this system, any element in the cache that contains only digits could be referenced by a malicious user, and whatever value is stored at that position would be used as the userid. There are a few different areas of the Panel that store values into the cache that are integers, and a user who determines what those cache keys are could pass one of those keys which would cause this code pathway to reference an arbitrary user. At its heart this is a high-risk login bypass vulnerability. However, there are a few additional conditions that must be met in order for this to be successfully executed, notably: 1.) The account referenced by the malicious cache key must have two-factor authentication enabled. An account without two-factor authentication would cause an exception to be triggered by the authentication logic, thusly exiting this authentication flow. 2.) Even if the malicious user is able to reference a valid cache key that references a valid user account with two-factor authentication, they must provide a valid two-factor authentication token. However, due to the design of this endpoint once a valid user account is found with two-factor authentication enabled there is no rate-limiting present, thusly allowing an attacker to brute force combinations until successful. This leads to a third condition that must be met: 3.) For the duration of this attack sequence the cache key being referenced must continue to exist with a valid userid value. Depending on the specific key being used for this attack, this value may disappear quickly, or be changed by other random user interactions on the Panel, outside the control of the attacker. In order to mitigate this vulnerability the underlying authentication logic was changed to use an encrypted session store that the user is therefore unable to control the value of. This completely removed the use of a user-controlled value being used. In addition, the code was audited to ensure this type of vulnerability is not present elsewhere.

Wings is the server control plane for the Pterodactyl game-server management panel. In versions up to and including 1.13.2, the SFTP write path does not enforce a server's disk quota during a transfer, allowing a tenant with SFTP write access to a single server to exhaust the host node's physical disk and take down every server on it. Wings checks available space only once, as a boolean, when the write handle is opened, using a stale cached usage value and without knowing the size of the incoming data, and it then returns a raw, unaccounted file handle that is never re-checked as the transfer proceeds. A single upload can therefore be written without bound, far beyond the configured disk limit, until the node's disk is full, and because a server stopped for exceeding its limit is not treated as suspended, SFTP writes are still accepted even after the quota is already exceeded. This issue is fixed in version 1.13.3.

Summary Pterodactyl does not revoke active SFTP connections when a user is removed from a server instance or has their permissions changes with respect to file access over SFTP. This allows a user that was already connected to SFTP to remain connected and access files even after their permissions are revoked.

Details When a user opens a connection to a server using the Wings SFTP server instance the permissions are checked and returned from the authentication API call made to the Panel. However, credentials are not checked again after the initial handshake. Thus, if a user is removed from a server in the panel or have their permissions modified, those permissions are not updated in the SFTP connection.

As a result, a user that has already gained access to a server's files via the SFTP subsystem will maintain those permissions until disconnected (via Wings restart, or a manual disconnection on their end).

[!NOTE] This issue impacts the SFTP subsystem for server files specifically. There is no exposure of Wings private data, or any data outside of a server's local filesystem. Additionally, a user must have been connected to SFTP at the time of their permissions being revoked in order for this issue to be exploited. If a user was not connected, they would not be able to connect once their permissions were reduced.

Fix Please upgrade to wings@1.12.0 and panel@1.12.0 to resolve this issue. Patches are available via the implementation PRs, but it is recommended to apply by upgrading the entire instance.

Pterodactyl before 0.7.14 with 2FA allows credential sniffing.

Summary When a user signs into an account with 2FA enabled they are prompted to enter a token. When that token is used, it is not sufficiently marked as used in the system allowing an attacker that intercepts that token to then use it in addition to a known username/password during the token validity window.

This vulnerability requires that an attacker already be in possession of a valid username and password combination, and intercept a valid 2FA token (for example, during a screen share). The token must then be provided in addition to the username and password during the limited token validity window. The validity window is ~60 seconds as the Panel allows at most one additional window to the current one, each window being 30 seconds.

Summary Pterodactyl implements rate limits that are applied to the total number of resources (e.g. databases, port allocations, or backups) that can exist for an individual server. These resource limits are applied on a per-server basis, and validated during the request cycle.

However, it is possible for a malicious user to send a massive volume of requests at the same time that would create more resources than the server is allotted. This is because the validation occurs early in the request cycle and does not lock the target resource while it is processing. As a result sending a large volume of requests at the same time would lead all of those requests to validate as not using any of the target resources, and then all creating the resources at the same time.

As a result a server would be able to create more databases, allocations, or backups than configured.

Impact A malicious user is able to deny resources to other users on the system, and may be able to excessively consume the limited allocations for a node, or fill up backup space faster than is allowed by the system.

Wings is the control plane software for the open source Pterodactyl game management system. All versions of Pterodactyl Wings prior to 1.4.4 are vulnerable to system resource exhaustion due to improper container process limits being defined. A malicious user can consume more resources than intended and cause downstream impacts to other clients on the same hardware, eventually causing the physical server to stop responding. Users should upgrade to 1.4.4 to mitigate the issue. There is no non-code based workaround for impacted versions of the software. Users running customized versions of this software can manually set a PID limit for containers created.

Impact

An authenticated user who has access to a game server is able to bypass the previously implemented access control (https://github.com/pterodactyl/wings/security/advisories/GHSA-6rg3-8h8x-5xfv) that prevents accessing internal endpoints of the node hosting Wings in the pull endpoint. This would allow malicious users to potentially access resources on local networks that would otherwise be inaccessible.

Workarounds

Enabling the api.disableremotedownload option or updating to the latest version of Wings are the only known workarounds.

Patches

https://github.com/pterodactyl/wings/commit/c152e36101aba45d8868a9a0eeb890995e8934b8

Impact

Importing a malicious egg or gaining access to wings instance could lead to XSS on the panel, which could be used to gain an administrator account on the panel. Specifically, the following things are impacted: - Egg Docker images - Egg variables: - Name - Environment variable - Default value - Description - Validation rules Additionally, certain fields would reflect malicious input, but it would require the user knowingly entering such input to have an impact.

To iterate, this would require an administrator to perform actions and can't be triggered by a normal panel user.

Workarounds

No workaround is available other than updating to the latest version of the panel.

Patches

All of the following commits are required to resolve this security issue:

https://github.com/pterodactyl/panel/commit/1172d71d31561c4e465dabdf6b838e64de48ad16 https://github.com/pterodactyl/panel/commit/f671046947e4695b5e1c647df79305c1cefdf817 https://github.com/pterodactyl/panel/commit/0dad4c5a488661f9adc27dd311542516d9bfa0f2

Impact A malicious user can trigger a user logout if a signed in user visits a malicious website that makes a request to the Panel's sign-out endpoint. This requires a targeted attack against a specific Panel instance, and serves only to sign a user out. No user details are leaked, nor is any user data affected, this is simply an annoyance at worst.

Patches None.

Workarounds None.

For more information If you have any questions or comments about this advisory please contact Tactical Fish#8008 on Discord, or email dane@pterodactyl.io.

Pterodactyl is an open-source game server management panel built with PHP 7, React, and Go. Due to improperly configured CSRF protections on two routes, a malicious user could execute a CSRF-based attack against the following endpoints: Sending a test email and Generating a node auto-deployment token. At no point would any data be exposed to the malicious user, this would simply trigger email spam to an administrative user, or generate a single auto-deployment token unexpectedly. This token is not revealed to the malicious user, it is simply created unexpectedly in the system. This has been addressed in release 1.6.6. Users may optionally manually apply the fixes released in v1.6.6 to patch their own systems.