Shell Simulation Via CGI

mischi writes "CGI-Shell simulates a shell using CGI. So everybody who has a CGI-directory on a web-server, also has its own shell on it -- comparable with Telnet or SSH. That's really practical, because most webhosters don't offer a shell (for free) -- but do offer CGI. With CGI-Shell you can execute commands, copy files or just explore your webserver. Even a history and auto-completion with tabulator are included. "

Comments

Backdoors

[TheGreek]

waiting to happen. Expect to see hosting providers outlaw this quickly, if they haven't done so in their ToSes already.

Re:Backdoors

[JonathanX]

Agree. This is one of the most useless things I recall ever seeing. It does have a "cool factor" to it, but I can't think of any legitimate need for it other than circumventing the native restrictions on shared hosting accounts. If you want a shell that bad, get your own server.

Re:Backdoors

[sqlrob]

OK then if it's so easy to use how do you do this?

Directory X:
Group A has read
Group B has read/write
Group C has write
Group D (not owner) can assign permissions
User Z (A member of C) needs read/write

Surprised...

[unborracho]

I'm surprised we haven't seen this come out earlier.. it's always been practical to do, given most free ISPs offer a directory that's flagged executable.

Kudos to these guys who developed this, but I hate to see how this is going to be exploited

Re:Surprised...

[Hanno]

I'm surprised we haven't seen this come out earlier..

I'm surprised this is considered news, since it's an age-old idea.

Friends of mine once used a cheapo ISP who did not offer shell access, but who made the mistake of running Apache with root priviledges. They used a similar script years ago to do remote administration of their site on that mis-configured server. They never exploited the security hole, but they always thought it was funny that they had a "limited web account" yet full access to everything on the server.

UID issues

[Ryu2]

Most webserver setups run under a non-priveleged UID of 'nobody' or the like... which means that normally, the web server user would not be able to access files owned by YOUR own UID. Would there be some sort of set-UID involved here?

I've used something exatly like this for months

[stratjakt]

I use it to add ipfwd lines to an internal router box around here. Runs in cgi under apache, lets me type sh commands and see the output.

This is just a new version of an old product, and has the same major problem: "applications interacting with the user (those that ask for input from the user), e.g. passwd are still a problem. "

So it's good for doing a chmod or ipfwd line, but you cant run vi or the like.

How hard would it be to get full terminal emulation through a browser applet?

Stop whinging - this is a good thing

[cliveholloway]

Any exploits that this allows idiots/script kiddies to do are exploits that a Perl programmer with half a brain can write in about 6 lines of code:

use CGI;
my $q=CGI->new();
my $command = $q->param('command')
$command and print $q->header('text/plain').`$command`."\n" and exit;
print $q->header.$q->start_html.$q->start_form.$q->textf ield('command').$q->end_form.$q->end_html;

If your web server is so badly configured that this creates security issues for you, you seriously need to read up on security.

.02

cLive ;-)

You people are so negative!

[Ayanami Rei]

Whine whine whine script kiddies paradise, whine whine whine backdoor shenanigans

baka.

1) commands run with as much permissions as the perl script itself, including umask. If there just happens to be a local r00t expl0it, well that's too bad. Perhaps it would motivate the server owner to apply some patches. Any damage would be limited to that which can be done with shell access otherwise (which this is supposed to provide). Moreover, it would behoove the owner of said script to make a few simple changes and use a white list of allowed commands or a blacklist of dubious things to prevent shenanigans (IE no eval, command interpolation, or exec, and limiting PATH)

2) htaccess is as secure as telnet (perhaps moreso). I have telnet open to untrusted accounts, and I've not been rooted. The only thing I would complain about is how browsers manage basic auth permissions. I would encourage users to modify the script to remove any weird html and write a user-interface shell script (using curl or something) to provide a pseudo-terminal session. This would prevent the session from being hijacked by browser bugs or by just not closing out of Moz or IE.

3) Finally, there is nothing about this that would prevent you from using SSL... a feature that some sites might provide as a side effect of having a management, ecommerce, or sign-up site hosted on the same machine.

One thing I don't like is the lack of simple console i/o. It would be nice to provide simple console support via HTTP/1.1 streaming and javascript on the client side; it wouldn't be interactive but it could at least emulate things like no-echo with a "password" textbox vs. a normal textbox.
It sounds like a lot of work though.

shellinabox

[idan]

... has supported this for a long time:

sellinabox.com

A pretty neat idea, actually.

[mobiGeek]

What were they thinking?

This tool is meant to be installed by someone who wants shell access to an account that they already have read and execute access to. If their web account is set up correctly (which it should be if the ISP is worth a damn), then the worst that happens is that the account of the web customer gets compromised...and that is the web customer's fault for installing the script when they don't know what they are doing.

I, for one, am considering using this on a couple of my customers' sites. They are hosted on systems where I can't get shell access. This will let me configure some things on the system without having an identical setup on my own box (or running a bunch of "echo `env | sort`" type CGI scripts)

I won't keep this script around in the account. When I need it I can upload it, do my deeds, and then remove it. I can change passwd each time I re-install.

BTW: I don't consider this any less secure than the (clear-text) FTP access I have to the account. The fact that this program exists means that anyone could have written it (or a similar proggy) and uploaded it to the CGI-BIN directory.

Been there, done that

[Kakurenbo Shogun]

I made a script like this a few years back that I called "Telweb". It was mainly an experiment to see if I could make it work (and for use briefly on a server where I didn't have a shell account). I only ever told one person about it, and hesitated even to do that, because the results if it every got into the wild were "too terrible to imagine."

Re:Doesn't IIS Already Have This?

[langed]

As I recall, this was covered here on /. before, under vigilantism, relating to Code Red.

Yeah it works--I got some pretty upset phone calls last year at my university, when my box had shut down an NT "corridor" machine to the scripted, dynamic "student accounts pages"... They pulled my internet connection for 3 days (it happened over a weekend) with an order to fix it before they restored my connection.

They also threatened to bill me for their damages--an estimated $700. (I have no idea where they dreamed up that number.)

I'm just too lazy to go find a link--there has been declared today a "low brain activity advisory" by the National Weather Service. :)

Re:Doesn't IIS Already Have This?

[flonker]

I wrote something that does this (win32 only) way back when. Here it is, complete with source code. It doesn't do much anymore, as the security holes exploited by the worms have by and large been patched, without removing the worm.