IP Fragmentation Overlapping v2.0

La pasada semana estuve en el evento organizado entre el SANS Institute y VASS en Madrid donde compartí cartel con Raúl Siles en las charlas.

Mi charla, titulada "IP Fragmentation Overlapping v2.0" fue un remake de la charla que ya di en la No cON Name en Barcelona hace unos meses, pero prestando menos atención en el ataque en sí y más en el análisis, poniéndome en la piel de un analista de intrusiones o forense.

La presentación en PDF la podéis descargar de aquí, aunque se pierde mucha información al no ver las transiciones, así que también la he subido en formato video:

Si os interesa ver los videos que se grabaron para le edición de la No cON Name, podéis hacerlo aquí (parte 1) y aquí (parte 2).

¡Gracias a todos los asistentes!

Explotando SMB NTLM

Hace unos días, los investigadores Hernán Ochoa y Agustín Azubel, publicaron una vulnerabilidad en la implementación de NTLMv1 de Microsoft, el protocolo que utilizan los sistemas operativos Microsoft para la autenticación a través de la red.

A pesar de que Microsoft ya ha publicado un parche que corrige la vulnerabilidad, existe un riesgo muy alto para aquellos usuarios que no se encuentren al día con sus actualizaciones. La vulnerabilidad afecta a TODOS los productos Microsoft que soporten NTLMv1, es decir, absolutamente TODOS los sistemas operativos Microsoft que existen en el mercado. La vulnerabilidad existe, por tanto, desde hace 17 años.

La vulnerabilidad consiste en una debilidad en la elección del Reto en el mecanismo Reto-Respuesta utilizado para realizar la autenticación. Según se ha publicado en el advisory de la vulnerabilidad, realizando un número suficiente de conexiones a un servicio SMB, los Retos este envía al cliente para realizar la autenticación comienzan a repetirse en un corto espacio de tiempo.

Esta vulnerabilidad puede ser explotada de varias formas, teniendo como consecuencia la autenticación en un sistema con los privilegios de un usuario sin conocer la contraseña de dicho usuario, algo similar a lo que conseguirías como las técnicas de Pass-The-Hash pero mucho más terrorífico, sin necesidad de tomar el control de ninguno de los equipos.

Uno de los posibles vectores de ataque consiste en recolectar de un equipo tantos Retos como podamos, comprobando que efectivamente comienzan repetirse.

Una vez hecho esto, si conseguimos de alguna manera que algún usuario que pueda autenticarse en ese sistema visite un HTML especialmente preparado para hacerle acceder a un servicio Samba que hemos dejado a la escucha para la ocasión, podemos proporcionar a cada una de esas conexiones uno de los Retos que hemos obtenido, con lo que el usuario legítimo nos devolverá las Respuestas adecuadas a cada reto.

Ahora que ya tenemos un montón de Retos y sus respectivas Respuestas de un usuario legítimo, solo tenemos que volvernos a ir al servidor que queríamos atacar y lanzarle la conexión que queramos (escribir un fichero, ejecutar un comando, etc). Si el Reto que nos manda el servidor no lo tenemos en nuestra lista de Reto-Respuesta, lo descartamos y realizamos otra conexión. En el momento que el servidor nos envíe un reto que tengamos en nuestra lista, nosotros le devolveremos la Respuesta que nos devolvió el usuario, por lo que quedaremos autenticados en la máquina con sus privilegios, ejecutándose nuestra acción.

Podemos ver todo esto en vivo en un pequeño video que hemos preparado. Siento la marca de agua, queda un poco cutre pero no encuentro ningún software free para Mac para hacer ScreenCast, pero como me parece que es una vulnerabilidad interesante y de actualidad he preferido poneros el video así y cambiarlo por otro sin marca de agua en cuanto pueda. Perdón por las molestias. Os dejo con el video:

Los script ruby utilizados están contenidos el propio advisory.

Parche (propio) para SSLStrip

Hace algunas semanas, durante un pentest, me vi en la situación de tener que usar sslstrip (ya hablamos de él hace unos meses) para intentar hacerme con algunas contraseñas de un formulario de login al que todo el mundo accedía directamente a través de la dirección HTTP que era redireccionada automáticamente a HTTPS de ese mismo servidor, en el que ya se podía acceder al formulario de autenticación.

Sorprendentemente para mi, la herramienta de Moxie no parecía funcionar correctamente, devolviendome un error como el siguiente:

Como podemos ver, sslstrip está cambiando incorrectamente la URL devuelta por el servidor web original de tal manera que nos direcciona a una URL en la que él no está escuchando, y por tanto no puede completar el Man-in-the-Middle.

A la vista de este error, lo primero es ver que está respondiendo el servidor web original para ver si puede haber algo que este provocando el mal funcionamiento de la herramienta:

# nc 172.16.24.142 80
GET / HTTP/1.0

HTTP/1.1 301 Moved Permanently
Date: Thu, 08 Oct 2009 17:23:54 GMT
Server: Apache/2.2.9 (Fedora)
Location: https://172.16.24.142:443/
Content-Length: 308
Connection: close
Content-Type: text/html; charset=iso-8859-1

Como podemos ver, el campo location nos está redirigiendo a la web https://172.16.24.142:443/, lo cual no deja de ser una redundancia ya que el puerto 443 es el puerto por defecto del protocolo HTTPS, pero que puede ser el causante de los problemas que hemos estado teniendo.

Sabiendo esto podemos intuir que Moxie no pensó en esta redundancia, y que por tanto su software sustituye perfectamente los enlaces https por http, pero no realiza ninguna modificación sobre los puertos.

Aprovechando que sslstrip está programado en un lenguaje interpretado como es python, nos vamos al código e intentamos buscar la zona en la que se realiza la substitución, de la siguiente manera:

# pwd
/root/sslstrip-0.6
#
# grep -ri "https" *
setup.py: description = 'A MITM tool that implements Moxie Marlinspike\'s HTTPS stripping attacks.',
sslstrip/ServerConnection.py: from HTTPS to HTTP.
sslstrip/ServerConnection.py: urlExpression = re.compile(r"(https://[\w\d:#@%/;$()~_?\+-=\\\.&]*)", re.IGNORECASE)
sslstrip/ServerConnection.py: urlType = re.compile(r"https://", re.IGNORECASE)
sslstrip/ServerConnection.py: url = url.replace('https://', 'http://', 1)
Binary file sslstrip/StrippingProxy.pyc matches
Binary file sslstrip/ServerConnection.pyc matches
sslstrip/StrippingProxy.py: We then proxy these out using HTTP or HTTPS depending on what information we have about

Según los resultado del comando, el fichero sslstrip/ServerConnection.py parece ser el único encargado de reemplazar en las URLs gestionadas por sslstrip la cadena HTTPS por HTTP. Si abrimos el fichero y buscamos esa misma cadena nos encontramos con el siguiente código:

[...]
url = url.replace('https://', 'http://', 1)
url = url.replace('&', '&')
self.urlMonitor.addSecureLink(self.client.getClientIP(), url)
[...]

Como podemos ver, "url" es una cadena en la que se van guardando las URLs existentes en la comunicació HTTP (previamente detectadas mediante una expresión regular, aunque eso no se ve en este pequeño trozo de código). Dicha cadena es modificada convenientemente para que los enlaces a través de HTTPS sean redirigidos a HTTP, donde estará escuchando sslstrip. Por último, ese enlace es guardado en un objeto "urlMonitor" que parece ser el encargado de las sustituciones posteriores.

Por lo tanto, para hacer que también desaparezca ese ":443" que nos encontramos en nuestro caso, añadimos la siguiente linea resaltada en negrita (sustituye ':443' por '' 1 sola vez):

[...]
url = url.replace('https://', 'http://', 1)
url = url.replace(':443', '', 1)
url = url.replace('&', '&')
self.urlMonitor.addSecureLink(self.client.getClientIP(), url)
[...]

Guardamos el script python que hemos modificado al salir y volvemos a relanzar sslstrip de la misma manera que explicamos en nuestro anterior post, y esta vez...

BINGO! Parece que ese era el problema. Desde luego no es una solución elegante ni perfecta, pero para éste caso me ha valido perfectamente y he podido hacerme con algunas contraseñas :)

He notificado a Moxie del problema pero por el correo que me envió parece que lo ha considerado un problema menor (realmente lo es), así que mientras que saque una versión que corrija este tipo de problemas podeis aplicar la misma solución que yo.

WPA... ¿Roto de nuevo?

Hace unos pocos días por fin conseguí leerme (no lo hice antes por falta de tiempo) el paper "A Practical Message Falsification Attack on WPA", que según leí hace unas pocas semanas afirma haber encontrado un método para romper WPA en 1 minuto, o al menos así se ha publicitado.

El artículo de los japoneses Toshihiro Ohigashi (Universidad de Hiroshima) y Masakatu Morii (Universidad de Kobe) intenta llegar "un poco más allá" de la técnica descubierta por Beck y Tews el pasado año con la que afirmaban que podían llegar a obtener el MIC con la que había sido cifrado un paquete y a partir de ahí inyectar tráfico en la red cifrada sin conocer la contraseña.

Esto era posible unicamente en aquellas redes que tuvieran la funcionalidad de QoS activada, ya que estas implementaciones funcionan con 8 canales diferentes que mantienen sus contadores independientemente, por lo que una vez capturado un IV de uno de ellos es posible realizar el ataque contra el resto de canales a pesar de la verificación del IV utilizado (comparación con el contador).

El artículo de Ohigashi y Morii propone un método para reproducir este ataque en redes que no tengan activada la funcionalidad de QoS empleando el mismo ataque descubierto por Beck y Tews.

La técnica de estos investigadores consiste en la realización de un ataque MitM sobre la red inalámbrica que permita al atacante tener un control de los paquetes que entran y salen del punto de acceso. De esta manera, el atacante es capaz de no permitir la salida o entrada de paquetes que vayan a suponer una actualización del valor del contador una vez el punto de acceso se encuentra utilizando el IV que necesitamos para realizar el ataque.

De esta manera es posible realizar el ataque ChopChop sobre redes WPA con TKIP ya publicado el año pasado sin necesidad de existir funcionalidad de QoS.

No obstante, tanto el ataque propuesto el año pasado como el descubierto por este par de investigadores japoneses, se basa en la inyección de paquetes ARP, partiendo de la base de que estos paquetes, debido a sus características, son conocidos a excepción de el último byte de la dirección IP de origen y destino, por lo que disponemos del plaintext del paquete a excepción de 2 bytes.

Esta limitación es bastante importante a la hora de aplicar este ataque a la realización de pruebas de intrusión o ataques reales de un atacante, puesto que los paquetes TCP incluirían un número mucho mayor de incógnitas que aumentarían el número de bytes desconocidos y por tanto aumentarían en gran medida la complejidad del ataque sino llegan a hacerlo impracticable.

Es por ello que aunque es cierto que los investigadores han conseguido inyectar paquetes en una red inalámbrica protegida con WPA TKIP en un minuto, el ataque es, por el momento, dificilmente extensible a otro tipo de paquetes que puedan resultar más peligrosos para la seguridad. Aún así recordamos que cuando se estudiaron las alternativas a WEP debido a su debilidad, WPA no fue más que una solución transitoria propuesta para ser utilizada en aquellos puntos de acceso que no disponían de la potencia necesaria para los algoritmos de cifrado utilizados en WPA2. En la actualidad, casi cualquier dispositivo inalámbrico minimamente moderno soporta cifrado WPA2, por lo que se recomienda su migración a este cifrado.

En pocas palabras, no es urgente migrar de cualquier manera ya mismo por el peligro de que nos realicen este tipo de ataques, porque hacerlo tan "a locas" nos puede ocasionar problemas mayores que el propio riesgo, pero tampoco dormirse en los laureles pensando que no pasa nada. Hay que ir planificando y pensando la migración de todas las redes inalámbricas que tengamos a WPA2 o, en caso de no ser posible, establecer medidas adicionales de control para la detección de este tipo de ataques.

Backtrack 4 con Ubuntu Intrepid

Como ya comentamos en una anterior entrada, la nueva versión de la distribución Linux más conocida, BackTrack, ha salido con algunos cambios más que interesantes. Entre ellos, el hecho de que esté basada en Ubuntu Intrepid en lugar de Slax como las anteriores, y que de hecho la gente de Remote-Exploit.org hayan dejado como públicos sus repositorios de APT, cumpliendo con algo que llevaba años queriendo hacer yo mismo, crearme un repositorio binario con las herramientas de seguridad para añadirlo a mis origenes de software y que se pudiera instalar todo este software igual que se instala cualquier otro, mantenerlos actualizados más cómodamente, etc.

Así que allá fui, arranqué la Backtrack 4 recien bajadita y le pegué un ojito a sus repositorios de software, entre los que encontré el siguiente:

Realmente, esta captura es de cuando ya lo puse en mi Ubuntu Intrepid, aprovechando que utilizo la misma versión que Backtrack 4, no debería tener ningún problema de dependencias, así que me añadí el repositorio y recargué el listado de paquetes, sin que me diera ningún problema.

Efectivamente, si ahora abro el Synaptic (aunque yo uso normalmente aptitude, pero la captura del Synaptic quedará más vistosa) me encuentro con todo lo siguiente:

La teoría es que, cuando intente instalar algo de los grupos de paquetes de Backtrack, estos localizarán sus dependencias de mis repositorios Ubuntu originales, y se instalarán sin problemas. Lo pruebo y, realmente, sin problemas, fijaros como se va descargando el software de seguridad del repositorio de Backtrack, y el resto de los repositorios "normales":

Al final el proceso de instalación acaba, y efectivamente ejecuto mi w3af ( /pentest/web/w3af/w3af_gui) o mi webscarab sin ningún problema:

Y todo esto con la ventaja de que cada vez que la gente de backtrack actualice una versión, a mi me aparecerá abajo que hay una versión nueva, por lo que estaré permanentemente actualizado (o esa es la teoría).

Un gran trabajo de los de Backtrack!! Se acabó ir con liveCDs/Máquinas virtuales de backtrack de arriba para abajo! :)

Backtrack 4 Beta

Hace exactamente una semana (10 de Febrero) se libreró la nueva versión de la conocida distribución LiveCD orientada a Seguridad Backtrack, aún en estado beta. Para los que no la conozcais, Backtrack es una herramienta imprescindible para todos aquellos que nos dedicamos a la seguridad y a la auditoría, puesto que contiene un compendio de las herramientas más conocidas en torno a la seguridad.

La nueva versión la podemos descargar tanto en formato ISO como en una imágen vmware (para aquellos que la usamos desde nuestros equipos y no queremos reiniciar).

Como principales novedades según podemos leer en el blog de la release, tenemos los siguientes:

• Cambio de sistema base de Slax a Ubuntu: Algo muy interesante, sobretodo porque parece ser que van a existir unos repositorios públicos apt para debian y ubuntu con todos los paquetes de la estupenda Backtrack ¿podremos incluirla en nuestros repositorios e instalar las herramientas de backtrack en nuestro sistema? Parece que esa es la idea, y promete.
• Herramientas para la utilización de las capacidades de cracking de las GPU NVidia y similares.
• Nuevas versiones de todas las herramientas de siempre.
  

Yo, por el momento, ya la tengo descargando :)
Si alguien lo prueba antes que yo, que comente sus impresiones.

Rogue CA: Solución Fallida

Hace unos días os comentaba la posibilidad de incluir en nuestra lista de certificados de servidores de nuestro navegador el certificado del host concreto para evitar que tras conseguir instalarlos el certificado de una RogueCA, un intruso pueda emitir certificados de cualquier host que sean confiables para nosotros.

Pues bien, como dice el título del post, la solución (que os dije que probaría) ha resultado fallida, parece ser que al menos el navegador testeado da más credibilidad a las CA que tiene instaladas que a las excepciones (algo que por cierto no entiendo, se supone que cuanto más "concreto" más credibilidad debería darle).

Las pruebas las realicé montándome una CA en mi equipo a la que denominé RogueCA. Depués de eso generé un certificado para www.banco.com y lo firmé con esta CA. Una vez con el certificado en la mano, lancé un webmitm (herramienta del paquete dsniff) utilizando este certificado y conectando hacia la IP de este banco, tras lo que edite mi propio fichero /etc/hosts para simular un ataque de envenenamiento DNS mediante el cual me hicieran dirigir las conexiones a www.banco.com contra el proxy formado por webmitm.

Efectivamente, conecto y me sale el aviso de que el certificado no está firmado por una CA reconocida. Esto sería lo que pasaría habitualmente si alguien nos quisiera hacer un ataque de MitM a través de HTTPS.

Para "simular" la realización del ataque de RogueCA, incluimos a mano en nuestro navegador la CA que acabamos de crear, haciendo como si, de alguna manera, el intruso consiguiera incluirla (que es lo que hace realmente el ataque), así podemos probar la solución sin tener que buscar ninguna colisión MD5.

Una vez incluida, visitamos de nuevo la web y podemos observar como ya no nos aparece el error, sino que entramos sin ningún tipo de aviso a la web de nuestro banco (como era de esperar). Mientras tanto, podriamos estar grabando todas las transacciones y contraseñas que está realizando el usuario contra su banco.

Ya está comprobado que de esta manera tenemos el mismo efecto que si nos realizaran el ataque. Ahora volvemos hacia atrás hasta el momento en el que aún no se había producido el ataque (eliminamos la línea del /etc/hosts y la entrada de la rogueCA en la lista de autoridades confiables).

Una vez tenemos de nuevo la web auténtica sin MitM de por medio en pantalla, accedemos a su certificado y lo guardamos:

Ya tenemos el certificado .pem de la web de nuestro banco, ahora incluimos este certificado como certificado de servidor aceptado en nuestro navegador:

Una vez hecho todo esto, volvemos a repetir los dos ataques anteriormente mencionados, y volvemos a probar a acceder a la web para comprobar si el certificado de host prevalece sobre el de la CA y estamos a salvo empleando este método.

Por desgracia, seguimos entrando sin ningún tipo de mensaje ni aviso a la web del banco. Observamos el certificado que estamos usando y efectivamente se trata del certificado malicioso.

Esto demuestra que esta solución que en principio parecía que iba a funcionar no lo hace, por lo que habrá que pensar otras soluciones.

Lo que sí funcionó es crearme otro usuario y eliminar absolutamente todos los certificados de las CAs y añadiendome a mano los certificados de los hosts críticos (mis bancos, el correo, etc). Es una solución incómoda pero al menos tenemos la certeza de que estaremos visitando lo que queremos visitar, al menos hasta que todas las CAs dejen de utilizar MD5 o los desarrolladores de navegadores implementen algún tipo de popup avisando que el certificado aceptado está utilizando hash MD5 (es una de las soluciones propuestas por los descubridores de la vulnerabilidad).

Por último, me gustaría comprobar en otros navegadores si esta solución funciona de la misma manera o si puede que resulte efectiva. Estoy pensando en Internet Explorer, Safari, Opera, Chrome, ...

Si alguien lo prueba con alguno de estos navegadores que lo deje como comentario o que nos mandé un correo y lo publicaré (o si lo publicas en tu propia web pondremos el enlace, claro).

Fichero "backdoor" en Netifera

Hace pocos días que tuve conocimiento de un software llamado Netifera, aún en estado beta, que proporciona un framework para desarrollo de herramientas de seguridad y para la integración con otras herramientas. Sin duda un software al que hay que llevarle un seguimiento muy de cerca.

Del software en cuestión ya hablaré otro día cuando lo tenga probado y pueda valorar con conocimiento de causa, pero de momento me gustaría escribir de algo, cuando menos curioso, que sucede en la instalación.

Tras descargar y descomprimir el paquete para Linux que previamente me he descargado de la web, hago un listado de directorios del paquete y me encuentro con esto:

about_files
about.html
backdoor <----
backdoor_install.sh <----
configuration
features
jre
libcairo-swt.so
netifera
plugins

¿¿¿"backdoor" y "backdoor_install.sh"???? Además miro la documentación y en ella dicen concretamente que debo ejecutar ese fichero como root, lo cual me deja un poco confuso. Si bien es cierto que sería de tontos si quisieran colocar un backdoor en un software dejarlo tan a la vista y con ese nombre, el paranóico que llevo dentro no se pudo resistir a pegarle un vistazo al script:

#! /bin/sh

BACKDOOR=backdoor
[ $# -ge 1 ] && BACKDOOR=$1

die() {
echo $1 1>&2
exit 1
}

[ -f ${BACKDOOR} ] || die "file not found: ${BACKDOOR}"
[ -x ${BACKDOOR} ] && [ -u ${BACKDOOR} ] && [ `stat -c '%g' ${BACKDOOR}` -eq 0 ] && echo "${BACKDOOR} already installed." && exit 0
[ `id -ru` -eq 0 ] || die "You must run that script as root."
chown 0:0 ${BACKDOOR} && chmod 4755 ${BACKDOOR} || die "Installation failed"
echo "Installation successful."

Pues bien, parece ser que el script "backdoor_install.sh" lo único que hace es darle el fichero al usuario root y luego darle permisos de SUID al binario, y lo deja con permisos 755, es decir, ¡¡cualquiera puede ejecutar el binario como root!!. Me quedo realmente alucinado, es realmente peligroso dejar un binario de root con el SUID activo y además dejar permiso de ejecución a todo el mundo, y no solo a un grupo, realmente muy peligroso.

De vuelta a la documentación de Netifera, encuentro buscando por ahí una explicación de porque existe ese fichero. La explicación que da el equipo de netifera es que necesitan ese fichero para que, cuando netifera se ejecuta con privilegios de usuario, pueda abrir los sockets necesarios para hacer sniffing de la red, y eso solo se puede hacer con privilegios de root. El motivo de llamarle de una manera tan peculiar es precisamente alertar sobre los riesgos que implica tener un binario como ese en el sistema.

Realmente, como dicen ellos, es peligroso, el binario podría sufrir alguna vulnerabilidad que permitiera ejecutar código y entonces cualquiera podría ejecutar código con privilegios de root. Como mínimo, cualquiera en el equipo va a poder hacer sniffing de toda la máquina y capturar contraseñas que se envien en claro, obtener información, quizá usarlo para hacer un MitM desde un usuario no privilegiado, en fin, peligroso peligroso.

De todas maneras, para quedarme más tranquilo, aunque se trate de algo muy rudimentario (tampoco quiero ponerme a hacerle la ingeniería inversa al binario) le pego un vistazo a las cadenas dentro del fichero para intentar hacerme una idea de lo que hace y me encuentro lo siguiente:

/lib/ld-linux.so.2
__gmon_start__
libc.so.6
_IO_stdin_used
socket
_exit
__errno_location
strtoul
sendmsg
__libc_start_main
GLIBC_2.0
PTRh
[^_]

Efectivamente parece que cuadra con las explicaciones que da el equipo de netifera, así a vista de pájaro, con lo que el paranóico que llevo dentro se queda razonablemente más tranquilo.

Las alternativas que propone netifera en su documentación son las siguientes:

• Dejarlo como está y asumir el riesgo.
• Ejecutar netifera como root: Todo el entorno se ejecutará como root, por lo que no será necesario activar SUID sobre el backdoor.
• Utilizar los "sudo gráficos" que vienen en muchas distribuciones como el su-to-root con lo que tendriamos algo equivalente a lo anterior, pero mucho más cómodo.
• Esperar a una próxima versión en la que tienen pensado autenticar de alguna manera el acceso a estos privilegios.
  

Realmente yo no pienso dejar ese binario con permisos para escritura para todo el mundo, yo optaría por alguna de las siguientes opciones:

• Dejarlo sin permisos SUID y hacerme root al ejecutarlo. No me gusta 100% esta solución porque implica tener ejecutandose todo un entorno con privilegios de root cuando no es para nada necesario, y eso va completamente en contra del principio de mínimo privilegio, pero sin duda es mucho mejor que dejar el binario expuesto para su ejecución a todo el mundo.
• Darle permisos de SUID pero quitar los permisos para todos los usuarios, dejando únicamente que ejecuten este binario root y los pertenecientes al grupo que pertenezca el fichero. Para ello he creado un grupo "netifera" en mi equipo del que soy el único miembro. De esta manera la ejecución como root ya no está disponible para todos los usuarios, sino solo para los que tienen permiso para ejecutar netifera, en este caso solo yo, reduciendo considerablemente el riesgo.
• Crear un usuario netifera que sea el único que puede ejecutar el software y lanzar el backdoor como root, y configurar para mi usuario un sudo o su-to-root para ejecutar ese binario con esos privilegios, de esta manera no solo basta con que alguien consiguera un acceso con mi usuario, sino que debería descubrir la contraseña de sudo. Esta opción sería probablemente la más segura, pero también la más incómoda, porque quiere decir que no podrías tener acceso con el usuario netifera a tu home y cosas de estas.

De las tres, por proporcionar una seguridad aceptable mientras el equipo de netifera implementa estas medidas de autenticación y una gran flexibilidad en el uso de la herramienta, yo voy a implementar la segunda opción, tengo un grupo "netifera" al que me he añadido y he modificado los permisos del fichero backdoor para que solo los miembros de este grupo pueden ejecutar el binario como root:

# chmod 750 backdoor
# addgroup netifera
# adduser mi_usuario netifera
# chgrp netifera backdoor

Más adelante iré usando la herramienta y si detecto que me da algún problema por haber tomado esta solución ya os lo haré saber, aunque en principio no debería dar ningún problema.

TCP Flood: LetDown

Acaba de llegar a mis manos un paquete de herramientas llamadas "Complemento" de entre las cuales me ha llamado la atención la herramienta LetDown, basicamente por estar inspirada en el famoso post de Fyodor (desarrollador de nmap): "TCP Resource Exhaustion and Botched Disclosure" en el que intentaba dar su teoría sobre Sockstress y la nueva vulnerabilidad de TCP que esta herramienta explota.

Por lo que se dedujo de los posts intercambiados entre Fyodor y los descubridores de la vulnerabilidad, no parece ser que este LetDown sea idéntico que Sockstress, aunque sí que podría ser algo similar.

La sintaxis de la herramienta es sencilla:

Usage:

Usage:
letdown -d destination ip -p port [options]
Options:
-d destination ip address, target
-p destination port
-s source ip address
-x first source port (default 1025)
-y last source port (default 65535)
-i network interface
-t sleep time in microseconds (default 0)
-a max time in second for waiting responses
-f automagically set firewall rules for blocking
rst packet generated by the kernel
examples: -f iptables, -f blackhole (for freebsd)
-P payload file (see payloads directory...)

Los binarios se distribuyen en código fuente o en .deb ,por lo que resultan muy fáciles de instalar. Si no tienes una distribución basada en debian probablemente tendrás que instalar a mano (o con tu gestor de paquetes) las librerías libnet y su correspondiente paquete de headers si es que no lo tienes instalado.

De momento lo he probado para tumbar una máquina Windows y una Linux y no me ha funcionado, quiero investigar un poco un poco más a ver si es que algo no lo estoy haciendo bien.

Lo que sí que he hecho es capturar los paquetes que salen al lanzar la herramienta y efectivamente vemos esto:

11:44:11.885329 IP 192.168.1.21.1025 > 192.168.1.9.22: S 1:1(0) win 1024
11:44:11.885684 IP 192.168.1.9.22 > 192.168.1.21.1025: S 1683795610:1683795610(0) ack 2 win 5840
11:44:11.885730 IP 192.168.1.21.1025 > 192.168.1.9.22: R 2:2(0) win 0

Como podemos ver, tiene pinta de los ataques de Fyodor y Sockstress, manda un único paquete SYN, al que el host atacado responde con SYN/ACK, para que finalmente el host atacante responda haciendo un RESET de la conexión. Esto no parece tener mucho secreto, donde está la chicha es en el Payload de las conexiones.

Si consigo que funcione haré una ampliación del post y pondré que tal me ha funcionado y cual era "el truco".

¿Si a alguien se le ocurre alguna idea...?

Resucita el Ping de la Muerte

Todos recordamos aún el ataque DoS que fue conocido hace años como el Ping de la Muerte, que consistía en aprovechar un error en practicamente todas las implementaciones de las pilas TCP/IP de todos los fabricantes de sistemas operativos y electrónica de red (Unix/Linux, Windows, impresoras, routers, firewalls) para mandar un ICMP de tamaño superior al máximo permitido por el protocolo, pero fragmentado, de tal manera que al ser reensamblado superaba el tamaño máximo permitido y producía una denegación de servicio en la máquina que realizaba el "desfragmentado".

Pues bien, esta vulnerabilidad que fue corregida por los fabricantes a lo largo de 1997 parece que ha vuelto a resucitar, no porque se haya encontrado una vulnerabilidad idéntica, sino por el descubrimiento de una técnica similar que recuerda mucho a este ataque debido a lo difundido que está el fallo y a no necesitar requisitos grandes de ancho de banda ni disponer de un botnet ni nada parecido para realizar el ataque.

La vulnerabilidad fue descubierta por los desarrolladores del conocido escaneador de puertos Unicornscan que, según sus propias palabras, mientras realizaban unas pruebas con la herramienta se dieron cuenta que en determinadas circustancias el sistema escaneado respondía a algunos paquetes continuamente hasta que el sistemas dejaba de funcionar y era necesario realizar un reinicio para que recuperara su correcto funcionamiento.

Por lo que se ha podido saber de la vulnerabilidad entre los datos publicados y un "intercambio de posts" entre Fyodor (desarrollador de nmap) y Robert Lee (uno de los descubridores de la vulnerabilidad) parace ser que se trataría de una especie de "SYN de la Muerte", debido a que parece tener algo que ver con la manera en que almacena las conexiones activas una pila TCP/IP cuando recibe un SYN. Además, por una frase que leo en alguno de estos artículos, la herramienta sockstress desarrollada como prueba de concepto (aunque no ha sido publicada) permitiría entre sus parámetros definir IP de origen y de destino, lo que me lleva a pensar si estos parámetros estarán destinados a realizar Spoofing de IP (con lo cual ya sabemos que el DoS está basado únicamente en el paquete SYN) o si por el contrario el ataque es del tipo Echo-Chargen y consiste en hacer que el sistema se reenvie paquetes hasta que se colapse por si mismo.

En cualquier caso, los fabricantes ya están trabajando para lanzar los parches de seguridad adecuados, que serán publicados el día 17 de Octubre, justo antes de que los descubridores de la vulnerabilidad den los detalles técnicos en la T2 Security Conference de Finlandia.

Estemos todos atentos a la publicación de los parches y apliquemelos cuanto antes, antes de que empiecen a aparecer herramientas DoS "on the wild", recordad que esta vez no hace falta disponer de una botnet, un atacante solo necesita lanzar unas pocas conexiones para detener el servicio de nuestras máquinas.