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, 20 de noviembre de 2014
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)