WiFiKill: Ataque D.o.S. a conexiones WiFi desde Android

Como parte de un estudio sobre los riesgos de seguridad en redes WiFi explotables por aplicaciones publicadas en el market oficial del Google Play para Android, hoy voy a hablaros de una otra app que pone al alcance de cualquier usuario realizar ataques de Denegación de Servicio (DoS: Denial of Service). En un artículo anterior os hablé de Intercepter-NG, una herramienta que es como una navaja suiza para hacer ataques en una red WiFi al estilo de cómo se pueden hacer con DSploit. Hoy toca hablar de WiFiKill, por petición de uno de los lectores.

Figura 1: WiFiKill - Ataque D.o.S. a conexiones WiFi desde Android

WiFiKill es una herramienta para Android que nos permite inhabilitar la conexión a Internet a otros dispositivos que estén conectados a nuestra misma red y que también nos permite conocer las páginas que se están visitando durante su sesión de navegación. Podremos obtenerlo por medio de Play Store bajando una aplicación que nos dará acceso a la descarga de la APK, o directamente buscando la APK por Internet. Si elegimos buscarla por Internet directamente debemos ser conscientes del aumento del riesgo de ejecutar alguna copia maliciosamente manipulada con malware. Eso sí, para que la aplicación funcione correctamente nuestro dispositivo Android deberá estar rooteado.

Figura 2: WiFiKill en Play Store

Uno de los objetivos de la aplicación es conseguir “echar” de la red a todos los dispositivos que se encuentran en ella. Se podrá elegir qué dispositivos son los que son expulsados, provocando una denegación de servicio solo sobre los dispositivos elegidos.

Usando WiFiKill

Tras descargar la aplicación y darle permisos de root podremos comenzar a usarla. Al abrirla accederemos al menú principal , en el que podremos observar cinco iconos en la parte superior. El primero de ellos es el botón de “Play”, el cual pulsaremos para analizar la red a la que estemos conectados en búsqueda de usuarios. En el momento en el que sea pulsado comenzara la búsqueda cambiando el símbolo de “Play” a “Stop” y nos aparecerá el icono de WiFiKill en la barra de tareas con la frase “WiFiKill is running”. Esto nos indicara que la aplicación está ejecutándose correctamente. Una vez finalizada la búsqueda nos aparecerán en pantalla todos los dispositivos conectados a nuestra red WiFi, indicándonos su dirección IP y su dirección MAC.

Esto es posible gracias a que la aplicación realiza un broadcast con ARP Request, esto consiste en enviar un ARP Request a todas las direcciones IP del mismo rango; los equipos conectados a la red contestaran a esta petición con un ARP reply indicando cuál es su dirección física o MAC, confeccionando así una tabla ARP.

Figura 3: Descubrimiento de equipos con WiFiKill

A continuación seleccionaremos los objetivos de nuestro ataque pulsando sobre ellos. Podremos ponerles nombre para identificarlos posteriormente. Al pulsar sobre “Grab” comenzaran a aparecernos en pantalla las rutas de las páginas visitadas por la víctima, pulsando sobre ellas nos mostrará algunos detalles sobre la sesión.

Esto se debe a que estamos realizando un ataque ARP Spoofing clásico, que al final es el esquema de Man In The Middle más famoso. Por medio de un ARP Spoofing envenenaremos las tablas ARP de los equipos conectados a la red y así podremos interceptar los paquetes enviados entre el router y el equipo de la víctima sin ser detectados. ¿Cómo funciona esto? Sencillo, nuestro dispositivo Android enviará un ARP Reply a las direcciones IP que le indiquemos indicando que la dirección MAC del router ha cambiado. En esta respuesta ARP se indica la dirección IP origen del router original y la dirección MAC de nuestro dispositivo. De esta forma quién reciba esta información actualizará su caché ARP envenenándola. En este instante, cuando el dispositivo spoofeado consulte la tabla para enviarle información al router, por ejemplo una petición hacia Internet, dicha petición pasará por nosotros.

Si pulsamos sobre “Kill” inhabilitaremos la conexión a Internet del dispositivo seleccionado. En este caso lo que ocurre es que se desactiva la función forward (reenvío) para esa dirección de origen en el equipo del atacante - que está haciendo de man in the middle -  provocando que todos los paquetes interceptados sean desechados. Al desecharse los paquetes la comunicación entre el Gateway y el equipo se cortará el tráfico de y hacia Internet provocando la denegación del servicio sin que el cliente se haya desconectado de la red WiFi.

Figura 4: Interceptación de conexión. Se puede grabar o cancelar

Otra forma de obtener el mismo resultado sería realizando un Ataque 0. Este tipo de ataque consiste en el envío de paquetes deauth (paquetes de desautentificación) a uno o más usuarios que estén asociados a un punto de acceso. Si estos paquetes se siguiesen enviando de manera indefinida el usuario no podría conectarse a la red. También podremos realizar un ataque múltiple utilizando las funciones “Grab all” y “Kill all”

El segundo icono - Refresh - nos servirá para detectar nuevos dispositivos que hayan podido conectarse a nuestra red desde que comenzamos nuestro ataque, volviendo realizar un ARP Request. El tercer icono - Lupa - nos sirve para buscar palabras clave dentro de la aplicación. Al pulsar sobre el cuarto icono – Llave inglesa - podremos configurar las opciones generales del programa, opciones como la de activar el modo de pantalla completa o decidir si queremos que nos muestre el fabricante de la tarjeta de red, la dirección IP y la dirección física. El último icono - Tres puntos - corresponde a los apartados de ayuda e información de la aplicación.

Figura 5: Opciones de visualización de WiFiKill

Para finalizar nuestro ataque solo tendremos que volverá pulsar el botón “Stop” y automáticamente finalizarán todos los ataques en curso con lo que desaparecerá el icono de WFiKill de la barra de tareas. En caso de no pulsar el botón de "Stop” la aplicación seguirá funcionando en segundo plano aunque hayamos salido de ella.

Con esta aplicación podremos comprobar si hay inquilinos conectados a nuestra red y, en caso de haberlos, seremos capaces de expulsarlos con un simple clic. Interesante herramienta de monitorización y control del uso de la WiFi. Este tipo de herramientas en manos maliciosas pueden causar también un gran daño, ya que automatizando el ataque se podría denegar el acceso a la WiFi de forma prolongada o afectar a la privacidad de los usuarios de la red, así que no te olvides de fortificar correctamente tu red WiFi.

Autor: Sergio Sancho Azcoitia

Bugs en Windows: Elevación de Privilegios y D.O.S. por usar rutas sin comillas en la creación de servicios

Esta semana, en la popular lista de correo de BugTraq, se produjo un hilo bastante interesante que capturó nuestra atención par aun artículo en Seguridad Apple. El tema principal del mismo era que el software que Apple está distribuyendo en Windows tiene errores de principiantes y puede ejecutar programas maliciosos en el equipo de las víctimas que consigan una Elevación de Privilegios o generen una Denegación de Servicio en el sistema. Al final, el bug se produce por una forma incorrecta de crear los servicios en un sistema Microsoft Windows, como vamos a ver.

Figura 1: Servicios de un sistema Microsoft Windows

Creación de servicios de forma insegura en Windows

El error presentado se produce porque el programador de la aplicación para Windows, en el caso del hilo, Apple Software Update para Windows, ha creado un servicio que corre con permisos de Administración en el sistema y que es invocado a través de una DLL que se encuentra en un fichero, cuya ruta por defecto es C:\Program Files\Apple Software Update\SoftwareUpdateAdmin.dll.

El error se produce porque en vez de seguir las recomendaciones de Microsoft, al pasar a services.exe la ruta del fichero no se ha tenido en cuenta que esta presenta caracteres de espacio en la ruta, por lo que debería ser pasada entre comillas, es decir con "C:\Program Files\Apple Software Update\SoftwareUpdateAdmin.Dll" para que no hubiera ninguna confusión con el archivo que se quiere ejecutar.

Al no hacerlo, Windows busca todas las posibilidades, por lo que probará los siguientes nombres de fichero en el sistema, a ver si es capaz de localizarlos. Si localiza alguno, el primero será ejecutado y el resto no se buscarán:

- C:\Program.exe
- C:\Program Files\Apple.exe
- C:\Program Files (x86)\Apple.exe
- C:\Program Files\Apple Software.exe
- C:\Program Files (x86)\Apple Software.exe
- C:\Program Files\Apple Software Update\SoftwareUpdateAdmin.dll.
- C:\Program Files (x86)\Apple Software Update\SoftwareUpdateAdmin.dll.

Por supuesto, si no existen ningunos de los primeros, como es lo habitual, el programa acabará ejecutando el que debe, y el sistema no debería dar ningún problema. Pero si existe cualquiera de los anteriores, será ejecutado - en este caso - con permisos Administrativos y por supuesto la aplicación de Apple Software Update no funcionará en absoluto.

Es decir, se habría producido una Elevación de Privilegios para los programas maliciosos que utilicen esos nombres y una Denegación de Servicio estúpida y absurda para el sistema de actualizaciones de Apple, dejando a ese usuario sin nunca más poder actualizar su software.

Este problema no es solo de Apple Software Update, y en el hilo se pudo ver que Microsoft Windows Live Mail y el software de iCloud Control Panel de Apple también son vulnerables a este fallo, lo que podría dar mucho juego a usuarios con acceso a servidores que puedan escribir en alguno de los directorios que van a ser invocados.

Buscando más software vulnerable a este bug

Como a mí me había sorprendido lo fácil y absurdo del fallo, ayer en Eleven Paths nos juntamos a jugar un poco con este fallo y ver qué otro software podría ser vulnerable a esta técnica. En lugar de revisarnos todo los archivos, lo que hicimos fue un test bastante sencillo que orquestamos en unos minutos.

Primero hicimos un programa en .NET guardaba en un log los paths de arranque con los que era llamado, lo que nos permitiría saber qué programa había invocado a éste para que se ejecutara. Luego lo llamamos Program.exe y lo pusimos en la raíz del sistema. Después reiniciamos el sistema y vimos qué aplicaciones lo llamaban. Como se puede ver, en un equipo cualquiera fuimos capaces de ver que varios de los programas que corríamos eran vulnerables a este fallo.

Figura 2: Lista de llamadas a Program.exe

Entre la lista que salió se encuentran Btwdins.exe que es el Servicio de BlueTooth de BroadCom Corporation. También salió el software de Microsoft Office 2013, el controlador Synaptics del TouchPad de nuestros equipos portátiles y WiseLinkPro de Samsung. Todos ellos arrancaron nuestro Program.exe en lugar del programa que deberían lanzar.

Por supuesto, todos esos programas dejaron de funcionar en el sistema y hubo que parar el experimento y reinicar el equipo para que todo volviera a la normalidad, porque los servicios que ellos querían crear no fueron los que se crearon.

Comprobándolo con Autoruns de SysInternals

Para verificar que estos programas era vulnerables es posible ir a ver con Autoruns de Sysinternals cuáles son las rutas que se lanzan, donde se puede ver que todos ellos llaman a Services.exe o a un programa externo como SynTPEnh.exe con la ruta de un fichero como parámetro sin entrecomillar. Allí encontraremos muchos servicios creados con la ruta del fichero entrecomillados, tal y como se puede ver en la siguiente imagen. Es la forma correcta de hacerlo.

Figura 3: Un servicio correctamente creado con la ruta del fichero entrecomillada

En el caso de services.exe, Microsoft deja claro en su documentación que los servicios en Windows se crean a bajo nivel a través de la API CreateService de Advapi32.dll y que ésta recibe un parámetro con la ruta del servicio, que si tiene algún un espacio se debe estar entrecomillada.

Figura 4: Indicaciones de Microsoft para rutas pasadas por parámetros con espacios

Así que cualquier aplicación que tire de esta API que cargue un fichero desde una ruta con espacios y no haya tenido en cuenta que debe entrecomillar la ruta, tendrá problemas. Tal y como pudimos ver con la lista de programas que salieron en nuestro experimento. 

Figura 5: Microsoft Office 2013 vulnerable a este bug, que Microsoft advierte

Eso sí, hasta el equipo de desarrollo del propio Microsoft Office 2013 olvidó seguir esta recomendación y cayó vulnerable en las pruebas.

¿Y la ejecución de programas de Logon con Explorer.exe?

En las pruebas que realizamos, decidimos mirar si pasaba lo mismo con los scripts que tiran de explorer.exe, pero como se puede ver en la siguiente prueba, tanto si se pone entrecomillada la ruta, como si no, se obtiene el mismo resultado. En nuestras pruebas, nunca se ejecutó C:\Program.exe.

Figura 6: A través de explorer.exe se ejecuta Marmita cuando va entre comillas la ruta

Figura 7: Si va sin entrecomillar, con explorer.exe también se ejecuta Marmita y no Program.exe

A nosotros se nos han ocurrido un buen numero de escenarios en los que podrían ser utilizadas estas técnicas. Evidentemente, escribir en C:\ no está al alcance de todos los usuarios, y menos si han tenido presente la fortificación de un sistema Windows, pero en un sistema en el que haya mucho software vulnerable, el número de carpetas que se pueden utilizar es grande. Por ejemplo, en el caso del software de BlueTooth de Broadcom, la ruta que se invoca es: C:\Program Files\WIDCOMM\Bluetooth Software\Btwdins.exe.

Figura 8: Ejecución insegura en Btwdins.exe de Broadcom Corporation

Con esa ruta, se pueden intentar crear los siguientes tres ficheros para conseguir el mismo objetivo.

- C:\Program.exe
- C:\Program Files\WIDCOMM\BlueTooth.exe
- C:\Program Files (x86)\WIDCOMM\BlueTooth.exe

Esto parece que va a dar bastante juego, así que ya os iré contando más adelante qué se puede hacer, que estamos pensando nuevas pruebas para completar estos resultados.

Saludos Malignos!

¿Se puede Dosear el WhatsApp de alguien?

Hace no demasiado tiempo se generó una buena polémica con el servicio de Apple iMessage al descubrirse que existían formas de fastidiar a los usuarios con diferentes ataques para hacer Spam y Denegación de Servicio. La ventaja para el atacante de Apple iMessage era que podrían utilizarse cuentas no necesariamente asociadas a números de teléfonos, y automatizar el ataque desde equipos Mac OS X con sencillos scripts. Los ataques para hacer un D.O.S. eran tan sencillos como hacer mensajes muy largos, o costosos de renderizar, haciendo uso de codificaciones complejas como Zalgo.

Figura 1: Mensajes D.O.S. para Apple iMessage enviado en Zalgo

Como Apple no tenía la opción de bloquear contactos en iOS 6 - fue introducida en iOS 7 -, decidió poner un sistema antispam bastante curioso: Enviar un correo electrónico a Apple para decir quién te estaba spameando o haciendo D.O.S. por Apple iMessage para que ellos lo comprobaran y tomaran medidas.

Como Apple iMessage y WhatsApp son similares, decidí comprobar si esto era posible hacerlo también de alguna forma en la popular app de mensajería. Sí, sé que todo el mundo quiere saber cómo espiar WhatsApp, pero supongo que el poder hacer un D.O.S. como broma a algún amigo pesado de esos que se pasa todo el día enviándote chorradas podría ser un buen escarmiento, así que perdí un poco de tiempo revisando estas cosas.

Figura 2: ¿Mensajes de tamaño ilimitado en WhatsApp? 

Lo primero fue mirar en Internet a ver si se conocían los límites de los mensajes de WhatsApp, y no resulta fácil encontrarlos, ya que todo el mundo parece pensar que son ilimitados. Evidentemente, el término ilimitado cuando hablamos con tecnología no parece demasiado científico, ya que al final siempre acaba apareciendo un límite.

Si miramos la estructura de una base de datos de WhatsApp con SQLite Data Browser, por ejemplo, se puede ver que los campos que almacenan el contenido de los mensajes son de tipo BLOB y TEXT, así que sólo hay que mirar el tamaño de estos tipos de datos en SQLite, que pueden consultarse en SQLite Limits.

Figura 3: Estructura de la tabla messages de WhatsApp

Como se puede ver, el tamaño de mensaje, salvo que la app haya establecido algún límite por el GUI puede ser mucho más grande que lo que un terminal pueda soportar con soltura, así que decidí probar a crear unos mensajes de gran tamaño a ver cómo se comportaban un iPhone, una Blackberry de las antiguas, y unos terminales con Android con los que contaba a mano.

Figura 4: Máximo tamaño para un BLOB. Para un TEXT el límite lo pone SQLITE_ MAX_SQL_LENGHT

Para hacer el ataque se podría haber creado algún script un poco más elaborado haciendo uso de Yowsup, pero como la idea se me ocurrió mientras andaba tirado en el sofá, lo único que tuve que hacer es crear un mensaje copiando en el portapapeles una frase muy larga y pengándola sucesivas veces durante 10 minutos hasta que construí un mensaje lo suficientemente largo - por supuesto muy lejos de los límites de SQLite -.

BlackBerry con Whatsapp 2.11.528

Tras enviárselo a mi pobre Blackberry e intentar abrir la app de WhatsApp, el terminal se quedó bloqueado totalmente y tuve que reiniciarlo y borrar todos los datos antes de poder volver a abrir WhatsApp. La versión exacta de WhatsApp para BlackBerry que tengo instalada en este terminal, por si alguien quiere probar más, es la 2.11.528.

Android con WhatsApp 2.11.152

En los terminales Android, mi Nexus 4, mi HTC Desire y mi HTC One soportaron que la app de WhatsApp, versión 2.11.152, se quedara en un estado de thrashing que hace imposible su manejo. Es necesario esperar durante varios minutos a hacer cada nueva acción y conseguir eliminar el mensaje envenenado, o por supuesto, desinstalar la app y volver a instalarla.

La "gracia" de este mensaje es enviarlo a una lista de amigos que tengan Android, ya que cuando se visualiza la lista de conversaciones intenta hacer una previsualización de 20 caracteres y parece que para ello carga todo el mensaje en memoria del tirón sin hacer alguna lectura con RTRIM o similares. Aún así, la app entra en thrashing pero no cae, aunque los destinatarios con los que he probado han acabado todos desinstalando y volviendo a instalar la app.

iPhone 5 con iOS 7

El que mejor resultado obtuvo fue el terminal iPhone 5, que aunque iba a tirones, podía manejarse con relativa facilidad y conseguir borrar el mensaje, lo que hace suponer que la app de iOS esté mejor diseñada y cuente con algún control a la hora de manejar límites en mensajes de gran tamaño. 

La app de iOS es la que mejor parada sale, bloqueándose durante unos instantes al recibir, pero luego al hacer scroll la app - aunque da algún tirón - consigue moverse sin bloquearse demasiado. Creo que WhatsApp para iOS tiene algún limite de mensaje a la hora de manejarlos por el GUI que Android y Blackberry no tienen.

Con estas sencillas pruebas se puede ver que sí que parece posible hacer un DOS a WhatsApp y molestar a los usuarios normales de este sistema, y que tanto los detalles sutiles de la implementación de las apps en las diferentes arquitecturas, como los sistemas operativos y la calidad del hardware en el que corran, tienen importancia a la hora de diseñar un sistema robusto. De todas formas, si te toda un amigo "guasón" que te hace estas cosas, lo más fácil es que le bloquees en WhatsApp, que se puede hacer fácilmente.

Saludos y.... ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ¡Buen año! ...

Autor: Pau González

Buscando ataques DOS

Una de las pruebas que más preocupa siempre en las auditorías de seguridad es la de los ataques de Denegación de Servicio (DoS). Esta preocupación suele ser porque si el sistema no aguanta, entonces afecta directamente al negocio. Los proveedores de Internet que están dando hosting de servicios profesionales ya tienen obligatoriamente que tener algún servicio serio de mitigación para este tipo de ataques. Como sabéis, uno de los correos que yo leo siempre sobre las cosas que me piden tiene que ver con una petición de este tipo.

Figura 1: Petición de DOS

Mi compañero en Eleven Paths, David Barroso (@lostinsecurity) ha hablado muchas veces de este tipo de ataques, utilizando diferentes medidas de ataque, y de los servicios de CloudFlare para mitigar estas situaciones. Para ilustrar la importancia que cobran hoy en día, siempre pone este vídeo de los servicios DDOS que se anuncian en Internet.

Figura 2: Vídeo de anuncio de servicios DDOS profesionales

Los servicios de una empresa, cuando sean cores, no pueden estar desprotegidos contra este tipo de ataques, y además de las pruebas de pentesting continuo deben realizarse también las pruebas de DDOS. Entre esas pruebas, no solo hay que ver si el sistema aguanta el volumen de tráfico masivo, que para eso ya hay sistemas y soluciones que ofrecen esa protección, sino que hay que buscar los límites de carga de las aplicaciones hospeadas que pueden tirar los servicios.

La idea es tan sencilla como que ciertas operaciones complejas de una aplicación web pueden requerir de mucho trabajo en cuanto a cómputo, memoria o almacenamiento en disco, y con una petición sostenida sin necesidad de que sea masiva, sea posible tumbar el sitio. 

En una instancia de una base de datos configurada sin límites, es decir, con valores unlimited en el tamaño de memoria, el número de threads o el crecimiento de los tablespaces y los datafiles, cae con un ataque de SQL Injection con un simple 'or '1'='1 tras generarse el volcado de una consulta compleja que use varios joins y resulte en varios millones de registros. Si es lanzada cuatro o cinco veces puede conseguir tumbar los límites físico del servidor donde esta siendo hospeda.

Yo sin querer he tumbado alguna instancia haciendo pruebas con las consultas pesadas, y en Marathon Tool fue necesario poner un intervalo de tiempo de descanso para no tumbar las instancias que empezaban a dejar de responder después de tener que merendarse unas consultas de varios milloncejos de registros en consultas con ocho o diez tablas en join. 

Figura 3: Pausas después de consultas en Marathon Tool

En estos ejemplos que estoy contando existen vulnerabilidades de SQL Injection, pero a veces el bug de denegación de servicio es el más que común cuadro de diálogo de búsqueda. En el caso de la página de búsqueda de sitios web hay algunas de ellas especialmente vulnerables a estos tipos de ataques porque:

1.- Permiten búsquedas que devuelven más datos de los que tienen sentido que se proporcionen a un usuario: Hasta los buscadores como Google o Bing ponen límites de resultados ofreciendo como mucho 1.000 por cada consulta - lo que nos obligó por ejemplo en FOCA a tener un tratamiento especial en los huge domains - . Una sitio web que permite consultas de búsqueda que devuelvan 444.000 resultados está cargando innecesariamente de trabajo al sitio web porque ningún usuario va a revisar todos esos resultados.

Figura 4: Buscador de web devulve 444.882 resultados en cada búsqueda

2.- Permiten lanzar consultas de grandes resultados con una única petición: Muchos sitios web permiten que la consulta se haga con una simple petición GET, lo que facilita sobre manera cualquier automatismo, e incluso el uso de los buscadores como arma de destrucción masiva, utilizando sistemas de amplificación de peticiones como los que mostramos allí. 

3.- No limitan el número de consultas por dirección IP y tiempo: Lo que ayuda a que el ataque sea sostenible el tiempo suficiente como para cargar el sitio web. 

Al final, las pruebas de DOS son más que necesarias en cualquier auditoría de seguridad, así que no debes dejarlas fuera de ellas, porque si no el sistema se puede caer en el momento menos deseado e incluso, alguna vez, por torpeza de los mismos usuarios.

Saludos Malignos!

Confusing Acunetix Kiddies & No-Limit Crawlers (2 de 2)

Segundo con Shadow Web Analyzer

Tras ver que el primer objetivo se ha logrado, ¿qué más se podría hacer? Pues los creadores del conocido software de escaneo de vulnerabilidades SSS sacaron a la luz la herramienta orientada a contenido web Shadow Web Analyzer, de cuya página oficial puede descargarse una versión de prueba. Seguimos el mismo procedimiento que aplicamos con Acunetix y observamos las siguientes cabeceras:

GET / HTTP/1.0
User-Agent: ShadowWebAnalyzer (http://www.safety-lab.com/)
Accept: */*
Accept-Language: ru
Range: bytes=0-
Host: www.site-web.org

En este caso el software se publicita a sí mismo a través del User-Agent, pero filtrar por esta cadena no es una idea de largo alcance puesto que en el modo personalizado SWA te permite escoger entre otros cuatro predefinidos o establecer el tuyo a medida. Lo que sí llama nuestra atención es la inusual Range: bytes=0-, en el RFC oficial podemos leer lo siguiente:

14.35.2 Range Retrieval Requests 

HTTP retrieval requests using conditional or unconditional GET methods MAY request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies to the entity returned as the result of the request: 

Range = "Range" ":" ranges-specifier 

A server MAY ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible...

Parece que su objetivo es solicitar una parte en concreto de un recurso, y no todo el fichero en la petición GET. Dado que no interrumpe el funcionamiento normal de nuestro website agregamos lo siguiente a nuestro anterior script:

if ((strpos($header, "Range") !== false) && (strpos($value,"bytes=0-") !== false))
$found = true;

Y el resultado previsible es:

Figura 2: Resultado obtenido con SWA

He configurado la herramienta para pasar a través de un proxy pero éste no elimina la cabecera en cuestión y el resultado obtenido es idéntico. He ahí una contra-idea para los fans de dicha herramienta: instalar un proxy intermedio que elimine la cabecera "Range:" antes de cursar la petición.

Idea Maligna: Que un sitio web contenga sólo una página en blanco es cuanto menos sospechoso. Más interesante todavía resulta lo siguiente: redirigir al escáner hacia una serie de páginas previamente diseñadas (y con apariencia similar a la web original) para contener campos y formularios supuestamente vulnerables pero cuidadosamente controlados, esto es, al estilo wargame, de modo que un listado de falsos positivos por parte del programa mantendrá ocupado al personaje de turno trabajando en ciertas brechas preparadas a tal fin.

No-Limit Crawlers Attack

Lo que aquí muestro no es más que una idea feliz que engaña a los programas sin chequeo de límites para seguir escaneando e indexando páginas hasta el infinito. El concepto que se me ocurrió es sencillo. Primero diseñar una página que cada vez que se visita, crea dinámicamente otra página cuyo nombre de fichero es un número aleatorio más la palabra “crawler” (por ejemplo 382934349crawler.php), y que muestre un link hacia esa nueva página.

Después el código de la página actual será copiado íntegramente en la nueva página. Por último, el mismo script tiene que borrar todos los ficheros en el directorio actual que contengan la palabra “crawler” pero que no sean la página misma ni la nueva creada.

Imaginemos pues que diseñamos el citado fichero con el nombre “734821crawler.php” y en el introducimos esto:

<html>
<body>
<?php
$dir_handle = @opendir(".") or die("No se pudo abrir el directorio actual");
while ($file = readdir($dir_handle))
{
if ((strpos($file, "crawler") !== false) && (strcmp(basename($_SERVER['PHP_SELF']), $file) != 0 ) && (strcmp($file, "734821crawler.php") != 0 ) )
{
unlink($file);
}
}
closedir($dir_handle);
$newFileName = strval(mt_rand(0, mt_getrandmax())) . "crawler.php";
if (!copy(basename($_SERVER['PHP_SELF']), $newFileName))
{
echo "Error al copiar a $newFileName...\n";
}
echo "\n<a href=\"$newFileName\">blackbycode</a>";
?>
</body>
</html>

Esta página la introduzco en un directorio “craw\” dentro del server y añado un enlace en la página principal (index.php), quizás oculto:

<a style="display:none;" href="craw/734821crawler.php">Lastlink</a>

Lo que ocurrirá cuando el web spider haga un request a la página es que esta creará otra página idéntica pero con distinto nombre, borrando otras anteriores si las hubiese de modo que como máximo en el servidor sólo existirán tres archivos del tipo “anticrawler”. El robot interpretaría el siguiente resultado…

Figura 3: Resultado que interpretaría el crawler

…que le diría que tiene que indexar y visitar otro enlace por ejemplo en “/craw/1205516587crawler.php”. Si esto llega a producirse el proceso se repite una y otra vez, creando nuevas páginas de forma dinámica, mostrando el enlace a la nueva creada y borrando las antiguas. Un ciclo infinito. Acunetix no cae en este juego puesto que su configuración por defecto marca los siguientes límites:

Figura 4: Límites del crawler en Acunetix

En el caso que nos ocupa los settings que frenan esta idea feliz son “Link depth limitation”, “Maximum Lumber of files in a directory” y sobre todo “Crawler file limit”.

Figura 5: Crawlers sin límites

Pero en este apartado hablábamos de no-limit crawlers, y bajo esta categoría han caído en la sencilla trampa algunas herramientas como Win Web Crawler o DRK Spider programado en Java.

Esta última parte no es más que una curiosa idea que ha venido a complementar el objetivo principal con el que comenzamos el artículo, entorpecer los escaneos automáticos y sin control profesional de aquellos que navegan sin rumbo fijo, tanto en la red como en la vida. Por lo demás… Happy Hacking!

Autor: blackngel
blackngel@blackbycode.com

*********************************************************************************
- Confusing Acunetix Kiddies & No-Limit Crawlers (1 de 2)
- Confusing Acunetix Kiddies & No-Limit Crawlers (2 de 2)
*********************************************************************************

Un hipervínculo para cerrar las sesiones de Facebook

Como siempre en Facebook, y por esas "casualidades" de la vida que llegan cuando se está enredando un poco - como ya me sucedió en el articulo de Aplicaciones de Facebook y Privacidad -, logré generar una URL que apenas es visitada, si tienes la sesión de Facebook abierta, te la cierra automaticamente. Algo así como si fuera un CSRF a la página logout de Facebook, algo que se bloquea para evitar que se envien enlaces acortados con el link de logout a personas para causar molestias.

Sin embargo, como os contaba,  de pura casualidad - nada de brujería - pude hacer un enlace que realiza el logout automatico de cualquier cuenta. Os cuento a qué se debe esto. ¿Alguno de ustedes tiene dos cuentas en caralibro? Bueno yo soy una de esas personas, pongámosle nombre a las cuentas de la siguiente forma:

- Mi primer cuenta = c1
- Mi segunda cuenta = c2

Estando yo en c1 me diriji a mi correo donde me llegan las notificaciones de c2, y como siempre cada notificación tiene un enlace que lleva a la publicación en Facebook pero primero obviamente a la pagina para logearse en este caso en c2. Ingresamos en c2 y como es de esperarse lleva al login, pero la pregunta es, si ya tenia abierta mi sesión en c1 y estoy apunto de iniciar sesión con c2, ¿qué pasará con c1? La respuesta es sencilla: se cierra la sesión en c1, hayas o no ingresado en c2.

Les dejo una URL para que ustedes mismos prueben - no seaís malvados -, y ojo con el correo que figura en el login, no sea cosa que aparezca en las noticias que el Facebook de Sean Parker - primer presidente de caralibro - fue 'hackeado' o suplantadada su identidad:

http://www.facebook.com/n/?home.php&clk_loc=5&mid=72b01a8G5af400143243G0Gd4&bcode=1.1354826874.AbllucLcWqHQbSNM&n_m=sean%40foundersfund.com

Si navegan a ella se les cerrará su sesión de Facebook. Esto se debe a que tal vez, cómo se observa en la URL hay un código que indica que efectivamente ese hipervínculo no fue generado por nadie ajeno, por lo que es seguro abortar toda conexión al servidor y logearse nuevamente.

De parte de Facebook - estuve en contacto con ellos -, no han hecho nada para arreglar esto, y como siempre,  me dijieron que no es una falla de seguridad - que en parte tienen razón - pero es medio contradictorio que prohiban hacer logout automáticamente y en otros no.

Para terminar, solo comentaros que no es necesario tener dos cuentas para obtener el enlace, pero si para comprobar uno mismo que efectivamente el enlace cierra la sesión, que fue como lo descubrí. 
Podéis buscar tu propio enlace en el correo, y mediante Facebook mandarselo a algun amigo para que pruebe si su sesión se cierra.

Saludos
--
Ariel Ignacio La Cono
Microsoft Student Partner
ignataur@hotmail.com

Hacking Webs en .NET: Trucos para una auditoría

El sábado por la tarde aproveché para leer la Hack In The Box Magazine número 9 en la que hay un artículo sobre Hacking .NET Applications. Esto, cuando estás haciendo auditoría de seguridad aplicaciones web sabes que no es lo que "más mola", ya que en la mayoría de los casos las aplicaciones en PHP o ASP suelen tener muchos más fallos de seguridad. Sin embargo, el artículo me enganchó desde el principio ya que decía justo eso en el título:

Hack an ASP.NET site? It is difficult, but possible!

Evidentemente, el escritor V. Kochetkov se había pegado con una auditoría ASP.NET alguna vez, así que le di una lectura en detalle y me encantó. Así que he decidido resumiros los puntos que cita, los que he podido probar, y los que no me encontrado con ninguno de ellos.

1) El bug del IIS Short Name en 8:3

Este bug se ha hecho muy popular, y permite listar los archivos y directorios de un sitio web en formato 8.3 con IIS si no tiene filtrados los códigos de error. En la FOCA Pro tenéis un plug-in que implementa esta técnica y en la siguiente actualización tendréis un nuevo fuzzer que saca mucho más, ya que hemos estado depurando finamente esta técnica.

Figura 1: Plug-in para listar ficheros en 8:3 en FOCA PRO

2) Corrupción de memoria

En teoría, una aplicación .NET con código manejado no puede corromper la memoria, sin embargo hay varios puntos donde pueden aparecer estas vulnerabilidades como un integer overflow en la librería gdiplus de la implementación .NET de System.Drawing (MS12-025), o el uso de mixed assemblies - que mezclan código manejado y no manejado en implementaciones que puede generarse con C++ sobre .NET - como en el uso de la implementación de SQLite en .NET. Además, el programador siempre puede liarla con la generación de un bloque de código inseguro con memoria no manejada, como el ejemplo siguiente.

Figura 2: Código en .NET inseguro

3) Turkish-I

Este fallo es muy peculiar y se produce cuando la aplicación .NET detecta la cultura usada en la máquina cliente, haciendo la conversión de los strings en el lado del servidor. En casos como la cultura Turca o de Azerbayán, la transformación de strings de un idioma a otro no es siempre posible debido a la ausencia de traducción de todos los caracteres, lo que provoca que ciertas comparaciones queden bypasseadas. Una explicación más detallada de este curioso caso lo tienes aquí: The case of Turkish-I

4) Colisiones de Hashes

La vulnerabilidad no es única de .NET, ya que es la que fue publicada en el CCC y afectaba prácticamente a todos los lenguajes de programación. En determinadas circunstancias es posible realizar un D.O.S. Microsoft lo solucionó en el MS11-100.

5) Depuración de aplicaicones: Trace.axd, Elmah.axd y modo Debug

Esta vulnerabilidad permite acceder a los datos de debugging de las aplicaciones. Si se ha activado la traza, y no se ha bloqueado su acceso externo, es posible acceder a mucha información del servidor. Haciendo un poco de Google, Bing, Shodan Hacking es posible encontrar cientos de servidores con trace.axd o Elmah.axd activado, donde se puede sacar info como ésta:

Figura 3: Información (parcial) accesible desde trace.axd

6) View State

El View State es esa cookie tan larga y cifrada que se envía entre el cliente y servidor en todas aplicaciones .NET. Como está cifrada, muchos desarrolladores confían en el View State para guardar información de la sesión en el client-side, algo que no deberían hacer. Descifrando y viendo el contenido del View State se puede acceder a información útil de la sesión de la aplicación.

Figura 4: ViewState Spy

Algunos ejemplos de lo que se puede hacer con los datos del View State, como ataques XSS, LFI, etc... los tenéis en este documento de Timur Yinusov.

7) Vulnerabilidades LFI

Los programadores en .NET también pueden hacer una aplicación vulnerable a ataques LFI, haciendo uso de tres funciones diferentes en su aplicación:

1. Response.WriteFile(vfilename): El path es virtual y devuelve un fichero.
2. Server.Execute(vfilename): El path es virtual y llama al manejador de un fichero
3. File.ReadAllText(filename): Lee el contenido de un fichero y puede pasarse la ruta del fichero en formato relativo o absoluto.

Si el programador hace uso de esas funciones es posible encontrar LFI en la aplicación .NET.

8) Asignación Masiva

La idea es que se produzca la carga de objetos de forma masiva desde un repositorio de datos a una aplicación .NET. Si no se controlan los parámetros que se están asignando masivamente podrían ponerse asignaciones de parámetros como isPrivileged o WritePermission de forma insegura. Es un caso muy particular, pero como dice el artículo, así hackearon GitHub.

9) LinQ Injection

La última de las vulnerabilidades consiste en algo similar al SQL Injection, en este caso en construir de forma insegura las consultas de acceso a datos LinQ cuando se construyen dinámicamente. Esto quiere decir que los parámetros o los objetos sobre los que se lanzan las consultas cambian dependiendo de un parámetro para lo que el programador puede construir de forma insegura esa comparación usando un string concatenado. Algo como esto:

Figura 5: Código vulnerable a LinQ Injection

El resto sería trasladar SQL Injection en lenguaje LinQ para conseguir saltar validaciones de acceso, por ejemplo.

Algunas cosas más sobre SharePoint y ASP

Además de estos fallos, también os recomendaría mirar si hay alguna aplicación ASP migrada a IIS 7  en la que se hayan dejado los códigos de error 404 sin proteger y mirar si hay algún SharePoint Portal Server [Fingerprinting SharePoint] que pueda tener algún fallo [Auditar SharePoint]. Para ello, en el libro de SharePoint 2010: Seguridad, tienes más información de cómo auditar un SharePoint.

Figura 6: Error 404 en una aplicación ASP migrada a IIS 7

Otra punto importante a revisar es la existencia de controles .NET "escondidos", tal y como se presentó en BlackHat 2013 Europe.

Espero que el resumen os sea útil, y aunque como dice el título auditar una aplicación .NET es difícil, no es imposible porque siempre podemos encontrarnos un administrador que no actualiza los parches de los bugs conocidos o un programador que no programa de forma segura. Si quieres aprender mucho de estas cosas, puedes apuntarte a nuestra Formación Técnica de Seguridad y Auditoría Informática.

Saludos Malignos!

10 cosas que puedes revisar en tu Apache (2 de 2)

Continuando con las 10 cosas que puedes revisar en tu servidor web Apache, hoy os dejo otras 5 cosas más. No son éstas las únicas que se pueden mirar - por supuesto - pero son algunas que son fáciles de comprobar. Si quieres fortificar más Apache, puedes leerte las recomendaciones de fortificación que tienes también en la web del proyecto.

6) Consolas de administración y paneles de administración JBOSS

Hace poco salía a la luz los miles de servidores Apache con server-status abierto sin ninguna contraseña en el servidor - entre los que salían sitios como CISCO -, pero casi más peligroso es tener paneles de administración JBOSS en /web-console o /jnx-console sin password o con credenciales por defecto.

Figura 6: Panel de administración JBOSS

En cualquiera de los dos casos se está pidiendo a gritos un ataque que pueda terminar con la seguridad del sistema.

7) Servicios Proxy configurados en el servidor Apache

El servidor Apache puede funcionar como un servidor Proxy para dar conexión a una red interna que quiere salir a Internet o como un servidor Reverse Proxy que dé acceso a servidores de la Intranet desde Internet. En ambos casos, una mala configuración puede llevar a serios riesgos de seguridad. Para descubrir el servicio de Proxy en un servidor Apache primeramente se busca el módulo mod_proxy o mod_proxy_ajp - módulo de Apache para jserv que necesita usar mod_proxy - que puede aparecer directamente en el banner del servicio HTTP o en los mensajes de error. Se pueden encontrar haciendo hacking con buscadores en Shodan.

Figura 7: Servidores Apache con mod_proxy descubiertos por Shodan

Otra forma de descubrirse ese servicio es mediante el uso del método CONNECT por HTTP, que permite utilizar un servidor Proxy para realizar una conexión a otro servidor web, pero también se pude utilizar un servicio Proxy en modo transparente en donde se pide la URL completa en el método HTTP, por ejemplo GET http://servidor2.com/index.htm y utilizando en el encabezado HOST el nombre del servidor Proxy. FOCA realiza estas pruebas buscando servidores Proxy en las direcciones IP del dominio en los puertos 80, 443, 8080, 8081 y 3128 (Squid Proxy).

Figura 8: Búsqueda de servidores Proxy en FOCA

Si alguien puede conectarse a tu servidor Apache y usarlo como servidor Proxy podría realizar actos maliciosos desde tu dirección IP y lograr que te bloquearan el equipo. Además, podría navegar por la Intranet y hasta por localhost a través del servidor Proxy o conectarse a cualquier servidor de la Intranet incluso si está bien configurado, pero no está actualizado.

8) El soporte PHP de tu servidor

Si tienes instalado PHP en tu servidor Apache, lo primero y más inmediato que debes comprobar es que no sea vulnerable al bug que permite ejecutar comandos en Apache si PHP está en modo CGI. Para solucionarlo lo mejor es que tengas actualizado PHP a la última versión, antes de plantearte cualquier otra alternativa.

Figura 9: Ejecución de código en Apache a través del bug CVE-2012-1823

Después, puedes comprobar que no tienes un info.php en tu servidor, que no tienes Blind SQL Injection de libro en parámetros numéricos y que no tienes ningún bug de type conversion en las aplicaciones PHP.

9) Ataques D.O.S.

Si tienes una botnet atacando a tu servidor Apache la mejor forma de defenderse es tener el portal alojado en un proveedor en la nube que evite este tipo de ataques, pero si desde una única máquina se puede tirar abajo tu Apache, entonces sí hay problemas que pueden ser subsanados. Si revisas la tabla de CVEs de Apache HTTP Server, podrás ver que el número de bugs que permiten hacer una Denegación de Servicio es alto.

Figura 10: CVEs de Apache HTTP Server

No de todos hay herramientas públicas, pero algunas sí se hicieron muy populares, como la del ataque de Slowris que publicó RSnake y que tiene una aplicación para lanzarlo contra tu servidor y comprobar si es vulnerable o no.

Figura 11: OWASP HTTP Post Attack Tool

Otra herramienta que puedes probar para ver la resistencia contra ataques D.O.S. de tu servidor Apache es OWASP HTTP Post Tool. Si una sola máquina es capaz de tumbar tu servidor entonces debes revisar las actualizaciones de tu Apache, las propiedades de tu conexión y las configuraciones de seguridad que puedes aplicar para minimizarlo.

10) ¿Qué más hay allí? Los listeners

La última de las cosas que os voy a recomendar mirar es algo que hace FOCA automáticamente por cada nombre de dominio, y es revisar los listeners HTTP y HTTPs de tu dominio. Para ello conéctate a http://www.tudominio.com y https://www.tudominio.com. Luego consulta la dirección IP de tudominio.com y conéctate a http://tuIP y https://tuIP, a ver si sale todo lo que tu esperabas y no aparezca una página por defecto o un portal de administración de un router con una password por defecto.

Figura 12: Modificador IP en Bing

Si quieres analizar un poco más lo que hay allí, puedes usar el modificador IP de Bing para ver con qué otros sitios webs compartes dirección a ver si pudieras ser atacada por alguno de ellos, aunque eso exigiría que estuvieran en la misma máquina.

Saludos Malignos!

************************************************************************************************
- 10 cosas que puedes revisar en tu Apache (1 de 2)
- 10 cosas que puedes revisar en tu Apache (2 de 2)
************************************************************************************************

fc00::1 (Algunos) Ataques en IPv6

Este es el título que utilicé para la charla que impartí ayer en la NoCONname 2012. En ella recojo todo lo que he empezado a escribir en la serie Hacking en redes de datos IPv6 - continuaré con ella - e hice una demo con la Evil FOCA explicando los ataques de man in the middle con Evil FOCA, como usarlos para capturar ficheros de datos transmitidos por SMB, cómo hacer man in the middle en redes de datos IPv4 con IPv6 o cómo funciona el ataque D.O.S. SLAAC.

FC00::1 (Algunos) Ataques en IPv6 de Chema Alonso

Todos ellos los iré desarrollando en detalle, pero mientras ya sabes que te puedes comprar el libro de Ataques en redes de datos IPv4 & IPv6.

Figura 1: Momento de presentación de la charla en la NCN 2012

Actualización: Tenéis la reseña del primer día de la NCN 2012 en Security By Default.

Saludos Malignos!

***************************************************************************************************
- Hacking en redes de datos IPv6: Conceptos básicos IPv6 (1)
- Hacking en redes de datos IPv6: Conceptos básicos IPv6 (2)
- Hacking en redes de datos IPv6: Te hackearán por IPv6 por pensar que no lo usas
- Hacking en redes de datos IPv6: Neighbor Spoofing
- Hacking en redes de datos IPv6: Captura de SMB con Neighbor Spoofing
- Hacking en redes de datos IPv6: FC00::1 (Algunos) Ataques en redes de datos
- Hacking en redes de datos IPv6: Man in the middle en redes IPv4 usando IPv6
- Hacking en redes de datos IPv6: Desactivar IPv6 para evitar D.O.S. SLAAC
- Hacking en redes de datos IPv6: Topera - Scanner de puertos sobre IPv6
- Hacking en redes de datos IPv6: Predecir direcciones IPv6 Local-Link de OS X
- Hacking en redes de datos IPv6: Ataques en redes de datos IPv 4 e IPv6
- Hacking en redes de datos IPv6: Evil FOCA: Ataque SLAAC
- Hacking en redes de datos IPv6: Evil FOCA: Bridging HTTP(IPv6) - HTTPs (IPv4)
- Hacking en redes de datos IPv6: Pasar de IPv4 a IPv6 con una respuesta DNS
- Hacking en redes de datos IPv6: Cómo activar IPv6 en Google Chrome
- Hacking en redes de datos IPv4: Ataque DHCP ACK Injector
***************************************************************************************************