It's obviously running in a container. I'm not sure your code really shows anything too concerning if they are taking precautions outside of the container to mitigate things like DDoS etc.
What specifically are your concerns? What about what you've learned will create an exorbitant bill?
Abusing the containers to send large amounts of outgoing traffic would do just that. Downloading files would do that too. How about sending a "while(true) { }" to hog some CPU? It doesn't take much to cause significant monetary damage.
Depending on their set-up, those containers could contain credentials or some other means to compromise the rest of the website. Perhaps it is possible to re-use the containers across different "sessions", serving multiple clients with malicious traffic. Those are plausible scenarios.
I'm not carrying out a full PT right now. Demonstrating the platform has been compromised is more than enough. Any other questions?
Running ps shows the timeout command as PID 1, and evidently an infinite loop gets killed after some point. In fact, there aren't any other processes besides sh, node, and the Python interpreter, and I'm not familiar with containers to know how this is possibly implemented (because obviously, timeout cannot be PID 1, so ps is wrong here).
What do you mean? It's an arbitrary RCE - a scenario that's generally treated as game over. What specifically are the concerns you don't have if that happens to a system of yours?
Now, I'm not saying that containers are super tight by default. It is entirely possible this particular container env is wide open, but I didn't really see anything too concerning from the parents analysis.
It means pretty much everything. Have you ever heard of someone reporting an RCE in a major service and it being treated as no big deal? They're invariably treated as catastrophic compromise because it is. The jump from RCE to privilege escalation, escape, etc is nothing compared to the actual RCE-ing.
It's very tricky to create and maintain those kinds of container systems, but there are services (for instance, the cloud CI providers) that do it.
On applications like these, where the premise is that you give them some kind of code and they evaluate it for you, escaping the "user interface" sandbox isn't game over; you'd have to finish the exercise of escalating to the container host or getting access to an internal network with internal APIs on it.
It's a little like getting SQL injection, but confined to some kind of SQL view. Chances are the application is doomed, but you still have to prove it.
They have a "Register" button at the top right where you can enter a username and password. If you have shell access to the box (no matter how virtual the box is), there's a good chance you can alter the site's code and capture the passwords people enter. And knowing that, in the real world, people do reuse passwords, this could easily lead to compromising accounts on other sites.
They also have a privacy policy (linked at the bottom) in which they make all kinds of promises about not leaking your personal data. If someone can take over their machine, and they know it, and they don't shut it down, it seems like that would violate the promises made in that privacy policy.
Also, of course, an attacker could alter the site to exploit any vulnerabilities in the users' browsers, so it opens up an attack vector there. Obviously users need to keep browsers patched, but people expect the risk to be lower when visiting legitimate sites.
I didn't mention anything about docker, seeing that containers are a linux kernel feature, but if you know of container escape vulnerabilities in the kernel you should publish them.