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

[CaseyB]

If the users currently have the ability to FTP CGI scripts to the server and run them, then how is this is any less secure?

web brower

[Mordac]

I look forward to the first web brower implimented using this CGI Shell :)

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.

Doesn't IIS Already Have This?

[Aix]

GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+ dir

Someone always seems to be trying to run shell commands on my Apache server. I wish they would realize that Apache doesn't have this "shell" feature.

Seriously, though, this is the most hideously insecure thing I have ever heard of.

Re:Doesn't IIS Already Have This?

[Gudlyf]

Put this in your .htaccess file and you might get lucky and give them a taste of their own medicine:

RedirectMatch permanent (.*)c+dir http://127.0.0.1/scripts/..%255c..%255cwinnt/syste m32/cmd.exe?/c+rundll32.exe+shell32.dll,SHExitWind owsEx%201

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. :)

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?

Give me a break

[Anonymous Coward]

This is such old news, these types of CGIs have been around a while. And for those worried about the security of this - give me a break. All CGIs are potentially dangerous. Just because this one happens to offer an interface that's familiar doesn't make it more dangerous than a CGI with a hidden back door or security hole.

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?

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

[acroyear]

Doesn't need to run vi. An experienced Unix user (with a malicious streak) could easily come up with some sed and awk to muck around with just about anything... keep in mind, if a file can be read by "anybody" (/etc/passwd is one of these), it can be read (via /bin/cat) by "nobody". No they can't get passwords, but it allows them to get the list of users on the box and quickly reduce the # of options when it comes to running passwd dictionary scripts for login attempts.

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.

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 ;-)

Re:Stop whinging - this is a good thing

[geekoid]

thus proviong that cLive ;-) is a "Perl programmer with half a brain ". ;)

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.

I had the opposite

[infiniti99]

This 'cgi shell' trick is not new. If you have cgi access, then you pretty much have system access. I don't even see the point of providers restricting shell access. Between that and cgi, there's no difference in power, only in convenience.

I once had the opposite problem. About 10 years ago, my ISP gave shell accounts and a web folder, but did not offer cgi. Again, why bother? I got around it rather easily by running my own http server on a non-standard port from my shell account. Then if I wanted to link to a cgi from my web page, I just had to include the ":port" in the URL.

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.

This is news?

[Kryptolus]

Isn't something like this obvious?

Such "shell" CGIs have been around for a while.

I don't see why this ad...i mean...story deserves to be posted.

Go figure...

[foxtrot]

Crackers've been getting shells via poorly written CGI for years, but now it's news?

Re:How about a Java ssh/telnet applet?

[PunchMonkey]

Yeah, you sure wouldn't find it by googling java ssh or maybe by going to javassh.org.

I mean... that would just be too easy and too obvious.

Re:How about a Java ssh/telnet applet?

[CaptainStormfield]

A very quick and dirty Google search 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.

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.

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.

Is it worse than CGI?

[Zeinfeld]

When Rob and ARI hacked up CGI it was done as an overnight hack in about 18 hours total. It was not a protocol change so it got no security review.

My first response was 'you what?'

Over the next few years we saw countless exploits of the form 'add this to the command line arguments, execute an arbitrary command'.

This is one reason why I so hate 'its only like what we do before' type security arguments. What you are already doing may be braindamaged.

People like to complain about IIS security but they fail to acknowledge that the single architectural issue that has led to those exploits is structurally similar to CGI. The game is to persuade a script to execute an arbitrary command.

Apache has had fewer exploits simply because the bugs are attributed to the braindamaged scripts written by the users.

If you want to run a secure Web server the thing to do is to turn off all scripting. Compiling the scripts and linking them into the server as a plug in is a lot more satisfactory as an architectural approach, especially if you have ways to reduce the privilleges of that module to least priv.

This is what perl's safe mode is for

[addikt10]

Perl's safe mode prevents this from executing on the server. Now, if they aren't running Perl in safe mode for their users' CGI scripts, then they have no business having a server on the net.

They do, however.

Front Doors, not Back Doors. Admin work!

[billstewart]

It's not a back door, it's a front door. The question is where you are once you walk in the door - chrooted jail, or do you have the run of the house? CGI always offered the possibility of doing lots of things that might be unsafe, and requires administration of systems in a way that restricts the options available to the browser to things that are either relatively safe to the system as a whole or only able to bother the user who installed this in his own directory. You should have done this anyway! And of course, if you're a user, you probably shouldn't install this application on a server you actually care much about until the security features get upgraded a bit.

(Obviously if your hosting provider uses a Windows system instead of Unix, the answer to "where are you" is "Probably nowhere interesting", though it can probably be adapted to support Windows command line services as well.)

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.