Vulnerabilidad SQL-Injection en PHP-Nuke
Fecha: 11/09/03
Principales módulos afectados: Downloads, Web_Links
Archivos sensibles: mainfile.php, admin.php, auth.php
Parche por: Miguel de la Hoz - IberNuke.org y Spacebom - DesarrolloNuke.org
Versiones afectadas: 5.6, 6.x
Este Bug está basado en la inyección de código SQL haciendo uso de las vulnerabilidades de los módulos Downloads y Web_Links. Para ello el atacante introduce un código SQL haciendo llamadas al nuke_authors para sacar las passwords encriptadas en md5 de los administradores. Una vez obtenidos esos passwords, se codifica en dbase64 esa contraseña y se accede a la administración (por el admin.php) introduciendo la password obtenida en dbase64.
Parche:
Como primera medida a tomar, introduciremos un código en el mainfile.php obligando a pedirnos la autentificación de la cookie del admin, con esto evitaremos que el atacante pueda realizar una ataque directo desde el admin.php con las entradas numéricas.
Después, de por ejemplo la línea ob_start("ob_gzhandler"); en el mainfile.php incluir seguidamente este código:
// Fix falso login del admin por Ibernuke.org y Desarrollonuke.org
if (isset($_COOKIE['admin'])) {
$admin = $_COOKIE['admin'];
} else {
$admin = "";
}
Seguidamente pasaremos a analizar los módulos afectados directamente, tanto el downloads como el web_links permiten que se introduzcan valores numéricos a través de ciertas variables "abiertas", para ello en el index.php de estos dos módulos introduciremos después de los primeros includes las siguientes líneas:
//Security fix by IBerNuke & DesarrolloNuke
if(isset($cid)) $cid = $cid*1;
if(isset($parentid)) $parentid = $parentid*1;
if(isset($lid)) $lid = $lid*1;
if(isset($ratinglid)) $ratinglid = $ratinglid*1;
if(isset($rating)) $rating = intval($rating)*1;
if(isset($ratinguser)) $ratinguser = addslashes(trim($ratinguser));
La explicación de esto, la tomamos de manos de Miguel de la Hoz (Ibernuke&Desarrollonuke):
Si a una variable con un valor numérico la multiplicamos por un número, simplemente nos da el resultado (en este caso lo hacemos por 1, asi que el valor no se altera), pero si esa variable contiene una cadena (que es como realizan el ataque) pueden pasar dos cosas:
- Si el primer caracter de la cadena es un numero (en los casos que hemos estado viendo desde los logs asi lo han hecho), la multiplicación se aplica a ese valor numérico y se elimina el resto del contenido texto de la variable, con lo que el módulo funciona perfectamente
- En el caso de que el primer caracter del valor no sea un número, se elimina todo el contenido de la variable y pasa a tener un tipo INT (numérico entero) debido a la mutiplicación, pero con un valor vacío.
En el otro caso de la variable $ratinguser, simplemente le pasamos un TRIM para eliminar espacios innecesarios y despues un ADDSLASHES que limpiará cualquier comilla y se cargará practicamente cualquier intento de ataque ya que necesitan meter comillas en casi todos los casos para pasar los valores de las variables a hackear.
Resumiendo un poco, asi impedimos, o ponemos las cosas más dificiles cuando se trate de realizar una consulta con un UNION e introducir el SQL quedaría acceso a los datos de la Base de Datos.
noticia sacada de
http://www.desarrollonuke.org un saludo
__________________