jueves, 11 de diciembre de 2014

BlackSEO Detector

Sé que uno no escribe en estos lares tanto como debiera.

Por otro lado, me resisto a poner eso de "a partir de ahora publicaré cosas aquí más a menudo". Demasiadas veces he sido testigo de como un blog o una página desaparecían algunos años después de un último post en el que se decía precisamente eso.

En fin, que mientras tenga algo que contar seguiré pasando por aquí y dejando unas líneas. Hoy vengo con un proyecto que me ha tenido ocupado últimamente: Se llama BlackSEO Detector y es heredero de una cosa antigua a la que llamé en su día Bluefinder.

¿Tienes un sitio web? Entonces tendrías que tener también un montón de preocupaciones. Y una de ella es el de los ataques motivados por el posicionamiento en buscadores.

Dicho en pocas palabras: hay quien considera que cuantos más enlaces apunten a sus páginas web, mejor posicionadas quedarán éstas en las páginas de resultados de Google, Bing y otros buscadores. Y hay gente que para consegirlo no repara en los medios: si hay que entrar a un sitio web y modificarlo sin autorización para colarle los enlaces... se hace y listo.

Las técnicas utilizadas en estos ataques son variadas y a veces curiosas. Hace algún tiempo, Chema Alonso y yo publicamos un artículo llamado Técnicas SEO para gente de moral relajada en el que se presentaba una serie de ejemplos. Entre las cosas que más llamaban la atención estaba el uso de cloaking forzado: hacer que las páginas se comporten de forma distinta o varíen sus contenidos dependiendo de quien la visita y cómo lo hace.

Para detectar el uso de estas técnicas es necesario buscar en los sitios web por cosas que no deberían estar ahí: quizá referencias a ventas irregulares de fármacos o réplicas de productos de marca, quizá ventas de productos no relacionados con el sitio web, quizá juego online o porno.

Si se encuentra algo, habría que mirar (eso sí, con mucho cuidado que quizá el sitio, aunque no sea de ellos, esté bajo control de ciberdelincuentes) si los contenidos aparecen cuando se pide la página de la forma habitual. Y también si se usa el User-Agent o el referer de un buscador. Incluso puede ser de ayuda hacer el acceso a través de un traductor de un buscador para que la petición llegue desde una IP perteneciente a éste.

Es un proceso que puede resultar largo y lento. Además es de esas cosas que un programa puede hacer con poca intervención humana. Y ahí está BlackSEO Detector para encargarse de ello.

Ahí os dejo el enlace al microsite donde se puede obtener más información sobre la herramienta y descargarla:
https://sites.google.com/site/blackseodetectortool

El sitio está aún en elaboración y la documentación de la herramienta todavía está poco elaborada. Espero poder ir publicando ejemplos de uso que sirvan de ilustración.

Una última cosa: si alguien quiere usar BlackSEO Detector, necesitará tener Ruby. Yo hice las pruebas con la versión 2.1.3p242 para Windows del intérprete de este lenguaje.

Saludos.

jueves, 20 de noviembre de 2014

HeartBleed. Siete meses y pico después

Había un par de experimentos que tenía ganas de realizar desde hace tiempo. Cosas de esas que vas dejando siempre para otro día porque van saliendo otras más urgentes o llamativas. Cosas que, por otro lado, te resistes a olvidar.

Y ayer, 19 de noviembre de 2014, pude dedicarle un rato a una de ellas.

Como si se tratara de una broma de ese Fools Day que varios países celebran, fue a principios de abril de 2014 cuando se supo de una vulnerabilidad en OpenSSL a la que se denominó HeartBleed (CVE-2014-0160). Dicho en pocas palabras y sin demasiado rigor: era posible robar información de los servidores afectados mandando un paquete cuyo campo de tamaño tenía un valor incorrecto.

Fue algo que causó gran revuelo. Había que parchear los sistemas y, además, puesto que no se sabía si los certificados usados para operar con SSL habían sido comprometidos, sustituirlos por otros nuevos.Salieron herramientas no sólo para proteger los sistemas sino también para detectar aquellos que eran vulnerables. Y listas de equipos que habían sido objeto de análisis, con sus correspondientes resultados.

Una de ellas fue subida a PasteBin el 8 de abril. Eran 1312 servidores. Todos vulnerables. Si alguien le quiere echar un vistazo, ahí va su dirección:
http://pastebin.com/Kbzr3DFv

Pasados 7 meses y medio aproximadamente desde que la vulnerabilidad fue hecha pública, y con lo popular que fue, es de suponer que todo el mundo la habrá corregido.

¿O no?

Ante la duda, cogí la lista y revisé cada equipo usando una de esas herramientas online que para ello hay en Internet. Ahí van los datos:

TOTAL DE EQUIPOS: 1312

EQUIPOS NO VULNERABLES: 1107
EQUIPOS PARA LOS QUE EL TEST DIO ERROR: 170
EQUIPOS VULNERABLES: 35

Lo de que el test dé error puede ocurrir por las más diversas causas. Desde equipos que ya no existen a otros que están apagados, pasando por firewalls y otras herramientas de seguridad que filtran el tráfico. Quizá sean vulnerables, pero lo más probable es que no.

Me quedan pues, esos 35 servidores, aproximadamente el 2,67% del total. Algunos serán honeypots, diseñados para detectar a quienes intentan realizar ataques. Pero aún así...

Buscando un poco por Internet encontré esta estadística sobre servidores en Internet.
http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html

En abril de 2014 había, según dice la página, 182.138.695 servidores que daban soporte a 958.919.789 nombres de servidores (¿cómo los habrán contado con esa precisión?). Una sencilla regla de tres, con todos las inexactitudes que estadísticamente pueda tener el procedimiento, arrojaría que existen cerca de 5 millones de servidores y alrededor de 25 millones y medio de nombres de servidores afectados por HeartBleed. Aunque sólo fuera la mitad, ya le daría a más de uno para algo de diversión.

Y los servidores son sólo parte de los equipos que pueden tener la vulnerabilidad.

Referencias
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
http://en.wikipedia.org/wiki/Heartbleed
http://es.wikipedia.org/wiki/Heartbleed

jueves, 13 de noviembre de 2014

By Design(4)



By Design (4)

Una página de descargas

En cierta medida, los problemas presentados en los puntos anteriores parten de un enfoque que, mirado desde un punto de vista teórico y alejado de los criterios de seguridad de la información, podria parecer correcto: crear herramientas genéricas que resulevan todo tipo de problemas simplifica enormemente las tareas de desarrollo y permite utilizarlas posteriormente como bloques con los que construir soluciones específicas.

¿No es eso, precisamente, lo que tanto nos gusta a muchos de Linux?

El problema es que no tuvo en cuenta la fuerza de los condicionantes prácticos. Las diferencias entre un programa para uso propio y otro accesible libremente a través de Internet. Las consecuencias de una vulnerabilidad o de un descuido.

Y, por supuesto, tampoco es algo que vaya ligado exclusivamente a las consultas a bases de datos o la visualización de contenidos. Mientras buscaba otras cosas, me encontré con una página en Github donde aparece un ejemplo de código PHP para forzar al navegador a descargar un documento:

https://gist.githubusercontent.com/nikhilben/602332/raw/2a1aa15de7211e9bf3345efa59a63bc8e320f242/.php

Y su contenido es:

<?php

// place this code inside a php file and call it f.e. "download.php"
$path = $_SERVER['DOCUMENT_ROOT']."/path2file/"; // change the path to fit your websites document structure
$fullPath = $path.$_GET['download_file'];

if ($fd = fopen ($fullPath, "r")) {
    $fsize = filesize($fullPath);
    $path_parts = pathinfo($fullPath);
    $ext = strtolower($path_parts["extension"]);
    switch ($ext) {
        case "pdf":
        header("Content-type: application/pdf");
        header("Content-Disposition: attachment; filename=\"".$path_parts["basename"]."\""); // use 'attachment' to force a download
        break;
        default; // Other document formats (doc, docx, odt, ods etc)
        header('Content-type: application/vnd.openxmlformats-officedocument.wordprocessingml.document');
        header("Content-Disposition: filename=\"".$path_parts["basename"]."\"");
    }
    header("Content-length: $fsize");
    header("Cache-control: private"); //use this to open files directly
    while(!feof($fd)) {
        $buffer = fread($fd, 2048);
        echo $buffer;
    }
}
fclose ($fd);
exit;
// example: place this kind of link into the document where the file download is offered:
// <a href="download.php?download_file=some_file.pdf">Download here</a>
?>


Cuando estudiamos Informática nos enseñan que reutilizar código es bueno. Y código para reutilizar tenemos aquí. Una rápida consulta nos permite demuestra que no faltan quienes hicieron caso de este consejo. 



Lo malo es que este script PHP parte de otra precepto incorrecto. Está hecho para hacer un trabajo: descargar documentos. Y lo hace tan bien que es capaz de descargarse a sí mismo mediante URLs del tipo:

http://www.example.com/download.php?download_file=download.php

... o, si los documentos a descargar en condiciones normales se ubicaran en un subdirectorio de la raíz del sitio web:

http://www.example.com/download.php?download_file=../download.php

... o cosas similares.

Y lo peor no es que pueda auto-descargarse. Por lo general, y por fortuna, opciones como “open_basedir” de PHP (http://php.net/manual/en/ini.core.php#ini.open-basedir) y similares permiten configurar los servidores de modo que los scripts sólo puedan acceder a ficheros ubicados en ciertos subárboles de directorio. Eso impide que puedan leer, y proporcionar, archivos con información sensible como el “/etc/password” y similares.

Pero la información sensible también puede estar encerrada en los propios scripts. Credenciales con los que la aplicación se conecta a la base de datos, direcciones IP y puertos de los correspondientes servidores, rutas de archivos, etc. están detrás de las páginas web que vemos en nuestros navegadores. Y gracias a los buscadores, tampoco es demasiado difícil obtener las direcciones de los scripts de un servidor:


 Y una vez se saben sus nombres y/o rutas, este “download.php” permite extraer su código fuente:
http://www.example.com/download.php?download_file=configuration.php

Claro que habrá quien diga que eso no es una vulnerabilidad, sino una característica



martes, 11 de noviembre de 2014

By design (3)

By design (3)

Más cosas de la web del oso

Cuando te encuentras con un error de diseño, lo malo no es el error en sí. Es que, muy probablemente, el resto de la aplicación también presentará problemas similares. Y que modificarla posiblemente conlleve un replanteamiento global de la misma.

Y ahí va un ejemplo.

Cuando visitas

http://refbase.wsulibs.wsu.edu/yellowstone/search.php


... la web te redirige a otra página:



Y lo malo no es su apariencia, por otro lado normal, sino su URL que, convenientemente decodificada para su mejor comprensión y una vez eliminados algunos retornos de carro, quedaría:


http://refbase.wsulibs.wsu.edu/yellowstone/error.php?errorNo=1065&errorMsg=Query was empty&headerMsg=Your query:<br><br><code></code><br><br> caused the following error:

Como puede observarse, el código de error, su correspondiente descripción y el mensaje de error inicial forman parte de la URL. Y un usuario malicioso podría modificarlos para insertar contenidos que posiblemente serían más de su agrado que del de los propietarios de la web.

O código JavaScript. O IFRAMEs que incluyan PDFs que infecten con malware.

XSS by design. Si el firewall de aplicación web (WAF) no lo evita, que con demasiada frecuencia no...



lunes, 10 de noviembre de 2014

By Design (2)


By Design (2)



Otros casos parecidos

Quizá pueda pensarse que diseñar los programas para que permitan la ejecución remota de código SQL arbitrario no se le ocurre a cualquiera. Y que, aunque se te ocurra, no es algo que necesariamente querrías hacer. Con un poco de descuido y mala suerte, te arriesgas a que te calcen un "Drop table" y, con mayor probabilidad, a que te extraigan informaciones varias que andan por la base de datos. 

Molesto, cuando menos.

Y, sin embargo, URLs similares pueden ser encontradas en una buena cantidad de sitios. Así, buscando en Google otras webs con el mismo problema...
https://www.google.com/search?q=inurl:"sqlquery=select*from"&filter=0

... aparecen un buen número de referencias.




En todo caso, ésta fue una de esas ocaciones en que Google se vuelve esquivo y reporta diferentes resultados cada vez que se le hace la misma pregunta. Así que, entre otras cosas, probé con otras versiones del buscador. 

¡Incluso me aparecieron resultados de la ONU!




Y no es el único indexado:
 
  

Ejemplos no faltan. Basta con probar en distintos dominios:


... y, si se desea, en añadir “&filter=0” al final de las URLs de Google para obtener más resultados:


Y, claro, aparte de Google siempre es bueno probar con otros buscadores e introducir algunas modificaciones. En Bing se puede probar con:
instreamset:(url):sql=select instreamset:(url):from instreamset:(url):where



O en Yandex con
inurl:”sqlquery=select”
... o...
inurl:"sql=select" inurl:from inurl:where



Por supuesto, la mayoría de estas páginas incorporarán medidas de protección ante posibles entradas maliciosas.O muchas de ellas, digo yo. Bueno, quizá algunas. Pero es que son tantas...