miércoles, 31 de diciembre de 2008

Aire Fresco en Information Gathering (Actualización)

Acabo de actualizar el post "Aire Fresco en Information Gathering" que si recordais, una de las herramientas que comentaba no la había podido encontrar.

La web en cuestión se encuentra en el enlace www.usernamecheck.com, pero recomiendo a los lectores que lean el post original para ver una explicación de que se puede hacer con esta web.

miércoles, 24 de diciembre de 2008

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.


martes, 16 de diciembre de 2008

Versión 3 de la Guía OWASP

Acabo de recibir la notificación de la publicación de la OWASP Testing Guide v3 (PDF), que como ya sabreis, es una guía destinada a describir el proceso de test de intrusión en aplicaciones web.

La particularidad de esta guía en contraposición a otras guías que hay por ahí de test de intrusión general o aplicaciones web, es el gran detalle con el que está escrita cada una de sus partes, muy lejos del estilo abstracto de otras guías. En la guía publicada por OWASP, todas las vulnerabilidades a testear están perfectamente explicadas, con ejemplos y con referencias a las herramientas necesarias para que sean explotadas exitosamente.

Sin duda un manual de referencia imprescindible para aquel que se dedica a la seguridad de aplicaciones web y, por supuesto, aquellos que se dedican al desarrollo de este tipo de aplicaciones.

miércoles, 10 de diciembre de 2008

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...?