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, 11 de diciembre de 2014
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
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...
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!
¡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...
Suscribirse a:
Entradas (Atom)