Pterodactyl Panel — The Next Generation of Free Multi-Server Management. (Now with WHMCS Support)

Discussion in 'Systems Administration' started by Fishfish0001, Jan 6, 2016.

  1. I'm pretty sure I modified the right files. However, where in an interesting situation here with our machine. We have a domain for site which runs in PHP 5.5 because of ionCube, but a subdomain which inherits PHP 5.5 (where we would want PHP 7.1) for the panel. So how would we work this out? My business partner mentioned a VM, but we want to see if something could be worked out here before jumping to that potential solution.
  2. You would need to configure your web server to handle multiple versions of PHP. That is outside the scope of support for this project, but there are potentially people on the discord server who would be able to help in the general linux help channels.
  3. Okay. I will give this a shot. Also we do use WHMCS. Do we still need to setup our webserver to handle multiple versions of PHP before setting up the WHMCS module?
  4. Issue has been solved. I ended up upgrading to PHP 5.6 for the panel and set PHP 5.6 as the default PHP in WHM.
    #184 xSinclare, Jun 9, 2017
    Last edited: Jun 9, 2017
  5. Hey,
    I tried registering on your website to ask this question, but registration seems to be broken (I haven't received my verification email).
    But anyway, where are servers stored? I can't find it anywhere...
  6. ATTN: Critical Security Vulnerability affecting all versions of Daemon from 0.4.0-pre.1 to 0.4.1

    This is a critical security release to address a bug in the implementation of the daemon. You should update immediately.

    Upgrade Guide:

    Due to an oversight in how the websockets were configured in the daemon, the last person to load the console socket would apply their permissions for anyone who had the console loaded. This caused anyone who should not have had permissions to send commands to the console to suddenly have permissions to do so.

    The root cause of this exploit was setting the authentication token on line 34 of socket.js which applied it globally to the socket, rather than locally to the connected client. This issue has been rectified to read the token passed on each call to the Socket, and removes the global token apply which should not have existed.

    This exploit required a valid user authentication token to be provided in order to even authenticate with the websocket, as such any non-subusers would not have been able to access data from or send data to the websocket. However, due to the structure of the code, a user could spam the websocket connection and cause all other authenticated users to be de-authenticated with the spammed invalid token. This method would still have required a user to know a server's UUID, which is generally not public information unless the user already had some type of access to that server. Users who had both a valid server UUID and authentication token would have been able to bypass their own lower permissions if a user with higher permissions loaded the websocket in their browser.

    This was a fairly unique "edge" case, but is none-the-less something that should not have been introduced. Moving forward we will be sure to include this type of dual-user load testing on the application and daemon to ensure that permissions are not overwritten when a new user loads the page.

    Thank you to Mohron#9350 who discovered this issue and reported it to us on Discord. This vulnerability was disclosed on June 14, 2017 at 20:44 U.S. Central Time and a fix was pushed to Github at 21:34.

    Affected Versions
    This bug was introduced in c73056ff; this exploit is present in all versions of the Daemon from 0.4.0-pre.1 to 0.4.1 and is patched in 0.4.2.
    #186 Fishfish0001, Jun 15, 2017
    Last edited: Jun 15, 2017
    • Like Like x 1
  7. Security Vulnerability Disclosure: June 26th, 2017

    On June 26th, 2017 we made an immediate hot-fix security release to address a critical application bug that allowed unauthenticated users the ability to execute arbitrary code aganist any server running on Pterodactyl Panel. At the time this incident was determined to be too significant to warrant an immediate full-disclosure and we made only basic detail available encouraging all users to update immediately. As we have now passed our cut-off date that we announced, a full disclosure will be happening in this post.

    Due to an implementation in the jQuery based terminal we were using, anything that was passed inside of double square brackets was determined to be a new command, and was executed as such. This exploit hinged on a user loading the web-console within Pterodactyl to execute any commands sorrounded by brackets. As soon as this bug was reported I took immediate action to narrow down the exact scope of the bug, and determine if it was isolated to specific games and if it required specific knowledge to execute. Unfortunately it quickly because clear that all software running via the Panel was at risk, and that no special knowledge was required in order to execute commands. The full attack vector quickly became more obvious as any commands in the server's console history would also be executed, even if the console was not open at the time of the command execution.

    This exploit did not require any access to the panel, and any user who could send input to the server that was rendered in a log would be able to execute arbitrary commands aganist the game server. Commands simply needed to be sorrounded in square brackets, and it did not matter where in the line they were. An example of this exploit is below.

    Code (Text):
    this is my [[op Username]] text
    In this instance, the output would be parsed by the web terminal to execute `op Username` as a second command as the currently authenticated panel user. This execution also caused the original message to be lost in most cases. Because of the way the terminal loaded messages on page load, any commands in the console buffer history were also executed. This allowed a malicious user to send a command, and even if the terminal was not currently open, as long as the message remainined in the scrollback history, it would be executed when the page was loaded.

    Narrowing down the scope of this bug to determine which versions of the Panel were affected it discovered that the bug was introduced in `v0.4.0` resulting in a significant vulnerability that affected nearly every panel that was being operated.

    Upon discovery I attempted to find a solution that would allow us to continue using the web-console that we were already using, but all solutions hinged on client-side JS, and were not something I felt comfortable pushing onto production environments, nor was I positive that it would cover all edge cases. The jQuery terminal plugin in use did provide functionality to escape brackets, however that caused color formatting to be escaped which made it impossible to filter ANSI codes. Because of these issues, I made the decision to completely strip the web-terminal from the project and a few hours later pushed up a hot-fix using a custom written terminal that did not execute any commands, it simply took the output and pasted it to the browser (escaping code as necessary, and handling ANSI color codes).

    This fix was pushed later that night, and a subsequent patch to address residual JS issues and formatting a few days later.

    In all previous software bugs, some level of Panel access has been required, and the bugs had been deemed to be something that could be disclosed at the time of the bug-fix release. This bug highlighted a danger in relying on external software to handle different actions, and also highlights a danger in not fully reading the documentation for software being used. During the review phase of this incident, I discovered a small amount of documentation for the web terminal that indicated this behavior was possible that was not seen during the initial implementation.

    One of the core principals of this software is to be transparent about any security issues that arise in the course of development. I aim to never make these notifications, unfortunately that has not been the case in recent months. I welcome any questions, comments, or concerns that you might have about this announcement.

    June 26th @ 15:00 CST — Support Team member is alerted to the presence of a vulnerability in command handling process. Project team is notifed immediately, basic testing performed to verify legitimacy of bug.

    18:00 CST — Full investigation into source of bug is launched, patching begins immediately.

    22:36 CST — Bug is patched in `develop` branch, and releases are prepared.

    23:08 CST — `v0.6.3` release is pushed to GitHub and made available to all users, minutes later notification is made in Discord to alert all inidividuals on the server of the urgency. CDN files updated to reflect a new update that began propigating to all active Panels.

    July 27th — Second notification made in Discord to alert users during more active peak times of the security disclosure, and to urge them to update immediately.

    July 30th — `v0.6.4` released with a memo at the bottom to encourage updates. An email was sent to the mailing list to reach out to more individuals.

    July 8th — Additional notification made in Discord to alert users to update pending this announcement.
    • Like Like x 2
    • Informative Informative x 2
    • Optimistic Optimistic x 1
  8. Isn't that SweetAlert2? :)
    • Agree Agree x 1
  9. I don't know anything about Docker. Is there some way to point it at the existing server directory? Part of the problem is that I have two disks that are too small individually to fit the server. Rather than set up some nice tool to split the data, I ended up manually splitting the worlds between the two disks and symlinking them all into one directory.
  10. Am i able to install this on MCprohosting??
  11. You can set the daemon's data directory to be one drive, and once the base folder for the server is created, I believe you could symlink your other world parts into that folder. Untested and not really a standard setup, but I suppose it would work.

    No, this cannot run on shared hosting.
  12. To bad it does not worok on windows...
  13. i'm really happy with using this! <3
  14. Has somebody managed to get this running from a raspberry pie? Would it be possible to host the web panel itself from my raspberry pie and the gameservers from a diffrent server?
  15. I've never tried it, but running the panel from the Pi and the servers from a separate machine is what this panel was designed to do, so that should be no problem.
    • Like Like x 1
  16. Thank you for the fast reply.:) I think i will give it a try and i will let you know if it worked.:D
  17. this panel support is ***** !!!! do not use this panel !!!
  18. Whats the reason?
  19. Could you give us some examples of why its bad?


    Works fine for me, I had some install problems but now it's working perfectly!
  20. I'm guessing this is the guy that was banned from our Discord for continually ignoring suggestions and links people were posting to assist him, and seemed to think we were there to sit and hold his hand for every command he needs to run.
    • Agree Agree x 1
    • Winner Winner x 1