Un blog de Seguridad Informática, desde un punto de vista tecnológico

Entradas etiquetadas como “conferencias

Write Up 5h311 – Final CTF NCN 2014

Buenas,

Para continuar con la saga de write-up’s iniciada en el anterior post con @julianvilas, hoy os pondremos la solución a otro de los retos que tuvimos el placer de testear.

Se trata de un fichero llamado “5h311”, que al ejecutarlo se abre un servicio en local en el Puerto 6969, que la conectarnos muestra lo siguiente:

Ejecución 5h311

Parece ser un acceso por consola que permite una serie de comandos, concretamente “cat”, “echo”, “env”, “exit”, “help”, “ls”, “set” y “unset”.

Si hacemos ls encontramos que el flag se encuentra en el mismo directorio del binario, pero al hacer un “cat flag.txt” podemos observar que no disponemos de privilegios para accede .

Permission Denied

Bueno pues nos ponemos manos a la obra y abrimos el programa con IDA para ver que es lo que nos esconde.

Buscamos en IDA las ocurrencias del comando “cat” con la búsqueda de Strings (ALT+T), con la finalidad de identificar la sección de código donde se están gestionando los comandos:

String put

Como resultado, en la sección .rodata podemos observar el vector que incluye los comandos que son printados por pantalla.

comandos

Pero observando unas direcciones de memoria más abajo, se pueden observar de nuevo los comandos asignados a unos offsets, pero con la peculiaridad que aparece un nuevo comando que no nos ha listado el comando HELP, el comando “Puts”.

puts command

Miramos las Xrefs del offset correspondiente a “aPuts” (x Key):

xrefs puts

Miramos de analizar la primera ocurrencia, que parece ser que se está empleando dentro de una función.

Antes de nada un apunte, observando el programa desde la View Graph, ya se observa algo raro, como si se hubiera ofuscado con algún tipo de programa, debido a que todos los paths van a parar a un mismo punto como se observa en la siguiente imagen:

graph

Procedemos a analizar el bloque de código que emplea el offset de «puts», y observamos que se realizan una serie de comparaciones:

puts code

Concretamente hace una comparación de dos offsets con una llamada a strcmp y verifica mediante el siguiente cmp si son iguales, en ese caso activa el ZF.

Antes de continuar refrequemos que hace el opcode “setz”:

  • The setz sets the byte in the destination operand to 1 if the Zero Flag (ZF) is set, otherwise sets the operand to 0.

Después mediante la instrucción “setz”, se setea el valor de “bl” a 1 si ZF vale 1, es decir bl valdrá 1 si el resultado del strcmp es que son iguales.

Posteriormente mediante la instrucción “test”, se modifica otra vez el ZF en función del resultado del registro bl. (Empezamos a observar algo de redundancia aquí, por lo que la hipótesis de que se ha empleado algún tipo de programa para ofuscar el código es cada vez más firme :P)

Finalmente se mueven de nuevo los dos valores comparados en el strcmp, y se ejecuta la instrucción cmovz (al parecer sin valor alguno debido a que solo se ejecuta si ZF=1, es decir, si ecx y eax ya son iguales).

Como podéis ver, una locura para al final solo acabar realizando una comparación xD Por lo que antes de ingresar en un psiquiárico, procederemos a realizar un análisis dinámico partiendo del bloque de código identificado.

Cuando el proceso recibe una conexión al puerto 6969, éste crea un nuevo proceso hijo mediante la syscall ‘clone’ y le pasa el control al mismo para que continúe su ejecución. Para poder debugear el proceso hijo sin que el padre nos moleste (al cabo de un tiempo envia un SIGALARM y nos mata el proceso), empleamos la instrucción “catch” de GDB para que, una vez cree el proceso hijo, podamos pausar su ejecución, y de esta forma poder debugear el proceso hijo con calma.

 

gdb debug

 

 

Añadimos un breakpoint a la dirección del bloque de código donde hemos observado el offset del ‘puts’, y ejecutamos la instrucción para ver que ocurre. Observamos que no  se observa ningún cambio, por lo que el flujo de ejecución no pasa por ahí. (ouch!) Continuemos con el análisis pues.

putsdoesnotork

Observando más detenidamente el código y continuando con la búsqueda de cadenas de texto interesantes como los comandos encontramos una zona de memoria donde se definen los offsets de las funciones asociadas a cada comando de la shell analizada:

commands

En la imagen se muestran los offsets de las funciones ya renombrados.

Usando la funcionalidad de cross-reference vemos que el primero de estos offsets es llamado desde otro punto del código:

xrefs

 

 

En ese punto se aprecia el acceso a este offset con un desplazamiento dinàmico con el valor almacenado en [eax*8]. Esto permite con el valor de eax recorrer la zona de memoria que contiene los punteros a las funciones de cada comando. Más tarde este offset guardado en el registro eax será llamado con call eax.

Captura de pantalla 2014-10-31 a la(s) 11.40.01

 

Tirando del hilo veremos que el valor de eax viene condicionado supuestamente por el valor del comando introducido por el usuario, mediante el offset «off_804E848».

Captura de pantalla 2014-10-31 a la(s) 11.46.07

Vemos que este valor parece venir de la función _fgets. Aunque de momento, debido a que el flujo del código esta ofuscado con la implementación de una máquina de estados, no podemos estar seguros de todas estas conjeturas. Deberemos por lo tanto ejecutar el análisis de forma dinámica para estar seguros.

Captura de pantalla 2014-10-31 a la(s) 12.08.57

Para analizar todos los valores comentados anteriormente de forma dinámica, utilizaremos gdbserver para debuggar cómodamente  de forma remota y poder indicar los breakpoints directamente desde IDA.

GDBServer

Luego en IDA seleccionamos el Debugger de tipo GDB server y configuramos la ip y el puerto:

IDA GDB Config

 

Ya podemos a priori centrarnos en el comportamiento de los comandos que más nos interesen, en este caso ‘cat’, ‘set’, y el misterioso ‘puts’. Para ello prepararemos el entorno para debuggar y pondremos breakpoints en los puntos más interesantes.

Focalizando en las funciones cat, set, i puts vemos que todas están implementadas ofuscando el flujo del código con una máquina de estados. Por lo tanto buscaremos las llamadas mas interesantes para poner breakpoints. Para verificar que no se nos escapa nada y por donde podemos empezar a mirar, sacamos un grafo de llamadas desde cada función que nos interesa con Graphview.

Captura de pantalla 2014-10-31 a la(s) 12.27.40Captura de pantalla 2014-10-31 a la(s) 12.28.17Captura de pantalla 2014-10-31 a la(s) 12.27.57

 

 

 

 

 

 

 

 

Ponemos los breakpoints en las llamadas empleadas en cada una de las funciones anteriormente mostradas en los callgraphs (strcmp, fopen, fgets, strncpy), con la finalidad de identificar, por ejemplo, las comparaciones realizadas en cada una de las llamadas a “strcmp”,  y empezamos a jugar.

En la función «cat» observamos se emplea una llamada a fopen para abrir el fichero a leer y que el valor de dicho fichero esta hardcodeado a “flag.txt”, por lo que solo se podrá abrir un fichero con dicho nombre.

Captura de pantalla 2014-10-31 a la(s) 12.30.13

Captura de pantalla 2014-10-31 a la(s) 12.31.24

En la función «set» observamos que las variables de entorno se guardan en memoria empezando en el offset dword_804e8a8 sumando un desplazamiento de 0x100 bytes (por lo que resulta en 804e9a8) y que el numero de variables de entorno se guarda en el offset dword_804e8a4.

Captura de pantalla 2014-10-31 a la(s) 12.32.00

 

Podemos ver como en las direcciones de memoria anteriormente comentadas se almacenan las variables de entorno seteadas con el comando «SET», (variable en 0x804e8a8 y valor en un offset de 0x100, concretamente en 0x804e9a8).

EnvVars

 

EnvVars_command

 

En la función “puts” observamos que recorre las variables definidas con set (incluso recorre las que se han “eliminado” con unset pero que aún siguen en la memoria pero sin la primera letra) y compara su valor con la cadena “puts”.

Captura de pantalla 2014-10-31 a la(s) 12.35.58

 

Si una de las variables se llama “puts” entonces compara su valor con “printf”.

Captura de pantalla 2014-10-31 a la(s) 12.36.48

 

Probamos el comportamiento creando una variable de entorno que se llame puts y que su valor sea printf y luego invocamos a puts. Como podemos ver, parece que se hemos conseguido una escalada de privilegios o algo parecido.

Captura de pantalla 2014-10-31 a la(s) 12.37.36

 

Probando ahora el comando cat con un fichero cualquiera del directorio desde donde ejecutamos la shell vemos que nos devuelve “error: permission denied”

Captura de pantalla 2014-10-31 a la(s) 12.38.58

Pero si recordamos que el valor de «flag.txt» está hardcodeado en el binario, miremos de probar pues de modificar el fichero de nuestro entorno local a dicho nombre. Volvemos a provar y ya podemos mostrar el contenido de flag.txt!

Captura de pantalla 2014-10-31 a la(s) 12.51.08

 

En este caso esta prueba no logramos resolverla dentro del tiempo del CTF. Pudimos resolverlo con calma luego desde casa 😛

Solo queda dar gracias al staff de las NCN por la originalidad de los juegos!

 

Post escrito con la colaboración de «Pau Rodriguez», miembro activo de 0xb33r$ 🙂


Solución HIDDENtation – Final CTF NCN 2014

Buenas,

hoy hemos tenido el placer de participar en la final del CTF de las No cON Name por segundo año consecutivo y, antes de explicaros nuestra solución a uno de los retos (que no conseguimos terminar a tiempo ;( ), nos gustaría dar las gracias a la organización; ya que se han currado un montón las pruebas (tanto las de la final como las de las quals) con el único objetivo de hacernos pasar un buen rato. Gracias de verdad, porque ha sido muy divertido! 🙂

El reto que vamos a explicaros se llama HIDDENtation, y el texto que describía el reto decía tal que así: «Dig deep into the file and find the flag.». Este texto venía acompañado por un archivo, que es en el que se centra el juego.

En un primer vistazo al archivo vemos algo tal que así:

hexdump

 

 

Por lo que parece que se trate de una imagen de un volumen cifrado con LUKS (estándar de cifrado de discos duros en Linux). El tema es que el comando «file» no ha identificado el fichero como tal, así que procedemos a analizar si la estructura del archivo es correcta. Para ello utilizamos una plantilla para el «010 Editor» para analizar el format de volúmenes LUKS.

Al ejecutar la plantilla vemos que nos da un error que dice que el archivo no es LUKS, ya que no se corresponde su firma. Así que pasamos a mirarnos el estándar de LUKS para ver cual es su firma, donde nos dice que la cabecera de la partición empieza con el siguiente magic: «{’L’,’U’,’K’,’S’,0xBA,0xBE}», y en nuestro caso en vez de una ‘S’ había una ‘s’ minúscula. Una vez modificada esa letra, volvemos a aplicar el template y vemos como ahora sí lo reconoce:

Cabecera LUKS

 

curioseando un poco el fichero vemos que en la sección de padding de caracteres aparece el siguiente texto: «Try … most common passwd in …», donde los «…» son dos números hexadecimales: 0x19 (25) y 0x07dd (2013). Así que nos vamos a preguntarle a Google y encontramos esto.

Utilizando el siguiente comando

cryptsetup luksOpen hiddentation volume1

 

intentamos descifrar el volumen con los 25 passwords sin éxito :(. Así que parece que tocaba trabajar más en los headers.

Después de pelearnos con el estándar vemos que nos faltaría arreglar las secciones de los key-slots en el header.

Key-slots

 

En este caso vemos :

  1. que los ocho que hay están desactivados («00 00 DE AD»), cuando tendría que haber al menos uno activo (en el que supone que está la clave con la que se cifran los datos protegida con la passphrase correspondiente a uno de los 25 passwords más comunes en 2013),
  2. que los campos donde se indican los offset de los KeyMaterials no parecen estar correctamente calculados. Para estar bien calculados deberían cumplir la fórmula round_up(key_length * stripes / sector_size); en este caso: (32*4000) /512 = 250, por lo que tomamos 256 (0x100).

Así que ya que parece que el key-slot8 es «el bueno», pues marcamos este slot como ENABLED (0x00AC71F3) y retocamos los 8 offsets, quedando algo tal que así:

LUKS OK

 

Ahora nos disponemos a probar otra vez los 25 passwords y tenemos éxito con el número 18: «shadow».

Así que ahora vemos qué pinta tiene el disco:

fdisk

 

 

Y vemos que la tabla de particiones es GPT, y que fdisk no soporta GPT. Procedemos a utilizar parted:

Gparted

 

Y aparecen tres particiones, una XFS, una EXT2 y una FAT32. Haciendo uso de los dispositivos de loop las vamos montando una a una. Por ejemplo:

losetup -o 44040192 /dev/loop2 /dev/mapper/volume1

donde indicamos el offset de la partición, el dispositivo de loop a utilizar y el volumen de disco. Este caso concreto es el de la tercera partición (tras buscar en la primera y la segunda no encontramos el flag).

Y al montar la tercera nos aparece un fichero que se llama «flag.txt». Quedaba un minuto para que se acabase el CTF y con toda el ansia procedemos a abrir el fichero para encontrarnos un «It’s inside this partition, but hidden ;)». Agggggggghhhh xD

Bien, después de analizar la partición con el autopsy, no vimos nada relevante en cuanto a ficheros borrados. Utilizando el comando testdisk vemos que en el mismo volumen hay una partición NTFS borrada previamente.

NTFS

 

La extraemos del siguiente modo:

dd if=/dev/loop2 of=ntfs2 skip=69632 count=34816

la montamos y vemos que hay un «readme.txt». Abrimos y…. «You are very near, but it’s even more hidden!». Mekagüen!! esta gente está loca! ;***, jajaja

De nuevo autopsy, esta vez sobre la partición NTFS y encontramos esto:

ADS

 

Un fichero flag.txt borrado (que no contiene el flag) pero con un Alternate Data Stream que contiene esa secuencia codificada en ROT13. La decodificamos y voilà, ahora sí tenemos flag «NCNd986942b809daa32a6987a7422771a53f59e5a1f02ed700cce43c5196aba749e» (pero el CTF ya ha acabado xD).

Pues parece que si que había que «Dig deeper» para encontrar la bandera ;).

Genial la prueba, muy muy currada. Gracias de nuevo staff de las NcN!! 🙂


«Kicking around SCADA!» en RootedCON 2014

Los pasado días 6, 7 y 8 de Marzo se celebró en Madrid la V edición de las RootedCON. En ella, nuestro compañero Juan Vázquez (@_juan_vazquez_) y yo mismo (@julianvilas) tuvimos la oportunidad de presentar el resultado del trabajo de investigación sobre SCADA que llevábamos realizando los últimos meses.

La ponencia se tituló «Tú a Boston Barcelona y yo a California Tejas. A patadas con mi SCADA!», y en ella explicamos las vulnerabilidades que encontramos en el producto Yokogawa CENTUM CS3000, un Sistema de Control Distribuido (DCS/SCADA) desplegado en más de 7.600 instalaciones a lo largo del mundo (según el fabricante), utilizado en refinerías, petroquímicas, sector energético, oil&gas, y un largo etcétera de entornos considerados infraestructuras críticas.

Se encontraron vulnerabilidades a nivel de configuración del entorno / software base, a nivel de diseño de los protocolos (ausencia de cifrado, autenticación, control de integridad, etc.), y a nivel de implementación. Estas últimas se corresponden con los advisories publicados por el fabricante y por el ICS-CERT (CVE-2014-0781, CVE-2014-0783, CVE-2014-0784), vulnerabilidades provocadas por desbordamientos de buffer en el stack y en el heap que permiten ejecución remota de código, para las cuales ya se han publicado tanto parches como pruebas de concepto (exploits) en Metasploit Framework.

También hicimos una demostración de posibles acciones de post-explotación una vez comprometido el sistema, en la que troyanizábamos las comunicaciones entre las estaciones de operación (HIS) y el controlador (FCS). Para finalizar la charla contamos también los resultados de escanear internet gracias a la colaboración de Rapid7 y su proyecto Sonar, que realiza este tipo de escaneos.

Podéis ver las slides de la charla en Slideshare, y tan pronto como la organización de RootedCON publique los vídeos actualizaremos el post.

Agradecer desde aquí a la RootedCON y a todos sus asistentes el habernos permitido pasar un tan buen momento.

Saludos!


Solución reto China – Final CTF NcN 2013

Hace unos días tuvimos la suerte de poder participar en la final del CTF de las No cON Name 2013, organizado por el Security Staff de Facebook.

La verdad, estuvo genial organizado y realmente nos divertimos mucho. ¡Felicidades Facebook & NcN staff! Enhorabuena también a los otros participantes, y en especial a los ganadores 🙂

En el concurso se publicaron un conjunto de servidores, cada uno de ellos correspondiente con un país.

Cada servidor/país podía ser una base o un flag:

  • Las bases contenían retos que podían ser resueltos una vez por cada equipo.
  • Los flags contenían algún tipo de vulnerabilidad que permitía a los equipos capturarlo (el flag). Los puntos se otorgaban por el tiempo que el equipo tuviese en su poder el flag. Básicamente los flags consistían en escribir en el fichero «/tmp/SCORE_POINTS» del servidor en cuestión, el nombre del equipo.

En este post os vamos a explicar como pudimos capturar el flag de China! 🙂

Al realizar un escaneo de puertos contra el servidor, éste presentaba abiertos los puertos 80 y 12345. El segundo era el utilizado por la organización para monitorizar los flags, así que procedimos a acceder al puerto 80.

Imagen

Y esto era lo que nos encontramos. Lo primero que hicimos, tirar de google translate para traducir el texto en chino. Básicamente era un formulario de login. Al probar a autenticarse, daba un error en el usuario/contraseña, y las pruebas de inyección realizadas no dieron resultado.

Por lo que procedimos a examinar con más detalle las peticiones y respuestas intercambiadas. Para ir al grano, el punto interesante era el proceso de autenticación:

Imagen

Y ¿qué era lo interesante de este caso?

  1. Un token AntiCSRF en el formulario de autenticación nos pareció un poco raro. Este tipo de tokens se utiliza en formularios que permiten hacer algún tipo de modificación
  2. El token AntiCSRF, tiene pinta de algo codificado (desde luego no de un hash)

Procedimos a su decodificación:

Imagen

Lo que nos indicaba que era un archivo binario, nos revelaba un path con un archivo .py, nos mostraba un hash y la palabra secret. Volcamos el contenido en un fichero y ejecutamos el comando file:

python 2.7 byte-compiled

Por lo que procedimos a decompilarlo:

Imagen

Básicamente lo que contenía era una asignación de una variable, siendo el path un metadato del fichero. Por lo que construimos nuestro propio python:

Imagen

Generamos un fichero byte-compiled (.pyc):

Captura de pantalla 2013-11-07 a la(s) 00.19.04

Lo codificamos en base64:

Captura de pantalla 2013-11-07 a la(s) 00.24.28

Y finalmente hacemos tampering de la petición cambiando el token AntiCSRF por el que hemos generado nosotros, y voilà! habíamos capturado la bandera de China 🙂

Esperamos poder subir en los próximos días alguna solución más 🙂

Un saludo!


BlackHat Europe 2011 – Resumen de Charlas (Parte III)

Buenas gente,

mi turno! 🙂

antes de nada me gustaría hacer una valoración general del evento: ha sido muy positivo, pero con muy poca presencia nacional! No sabemos si ha sido porque las Rooted CON fueron hace muy poquito, si es porque este año ya no ha sido novedad que se celebrasen en nuestro pais o simple casualidad, pero se podían contar con las manos a los paisanos 😦

También me gustaría enviar un fuerte abrazo a nuevos amigos de Argentina que tuvimos la oportunidad de conocer: Sebastian y Alfredo de Groundworks Technologies (que como ya ha comentado Pau dieron una brillante charla) y unos cuantos amigos más de Core (tenía una foto con Federico Muttis y la chica «anonymous» 😉 pero no la encuentro :P). Grandísimos!

Y ahora sí vamos a las charlas:

Día 1

[Application Dissection] The ABAP Underverse – Risky ABAP to Kernel communication and ABAP-tunneled buffer overflows / Andreas Wiegenstein

Personalmente esta charla me gustó mucho, ya que toca una temática que llevo un tiempo investigando: la seguridad en SAP. En concreto trató de vulnerabilidades en el lenguaje de programación utilizado en este sistema, conocido como ABAP.

Acerca de ABAP (Advanced Bussiness Application Programming):

  • Es un lenguaje propietario, y sus especificaciones completas no están disponibles
  • Es independiente de la plataforma (bytecode sobre ABAP Runtime)
  • La comunicación entre sistemas SAP se realiza mediante RFC (Remote Function Call)
  • El control de versiones y el sistema de transporte (entre entornos de desarrollo, QA, Producción) están integrados
  • Utiliza OpenSQL para el acceso a back-end (independiente del back-end utilizado)

Cosas muy interesantes explicadas durante la charla:

  • ABAP es un lenguaje susceptible a vulnerabilidades de tipo inyección SQL
  • En ABAP se puede inyectar código estático y ejecutarlo posteriormente
  • En ABAP se puede inyectar código dinámico y ecutarlo posteriormente (además este código se ejecuta on-the-fly y no quedan trazas)
  • El código ABAP customizado puede evadir restricciones de seguridad del estándar de SAP (p.e. el sistema de autorizaciones está disponible para su uso pero no es implícito)
  • ABAP es vulnerable a desbordamientos de buffer

Durante la charla se mostraron DEMOS de una inyección SQL que consultaba información en todos los mandantes, de inyección de código y de ruptura del servicio mediante la explotación de un desbordamiento de buffer.

[Keynote] Cyberwar/ Bruce Schneier

El archi-conocido Bruce Schneier nos habló de su visión y reflexiones acerca de la ciberguerra, así de cómo está afectando el creciente uso de este término en los gobiernos de las grandes potencias.

Os dejo los conceptos que más me gustaron:

  • El principal problema de la ciberguerra es que es un término que no está claramente definido
  • En la guerra tradicional, los gobiernos de las naciones tienen el control. La ciberguerra puede ser iniciada por ciudadanos
  • Es difícil saber quién te ataca y cómo, por eso es difícil protegerse
  • En la ciberguerra, el principal objetivo es controlar (por ejemplo como hace un APT), y el peor objetivo es destruir
  • Las tecnologías actuales dificultan la interceptación de las comunicaciones para los gobiernos, y por tanto para las labore de inteligencia. Es más fácil pinchar un teléfono que controlar todas las comunicaciones que puedan realizarse vía Internet (p.e. Skype, el chat de Second Life, etc.)
  • Un país es tan vulnerable en la ciberguerra como dependiente es del ciberespacio. Evidentemente los países más desarrollados suelen ser los más vulnerables.

Ya podéis ver el vídeo y comentar lo que queráis 😉


BlackHat Europe 2011 – Resumen de charlas (Parte I)

Antes de nada y siguiendo la tradición de mis compañeros JuliánJuan, me presento: soy pau ochoa y, como ellos, espero seguir contribuyendo asiduamente en esta iniciativa, testpurposes.net.

Una vez finalizadas las BHeu 2011, durante los próximos días vamos ha publicar diversas entradas haciendo un breve repaso de las charlas a las que asistimos cada uno de nosotros.

Personalmente tuve el placer de poder asistir a un par de charlas del segundo día, siendo finalmente las dos elegidas (no sin dificultades):

Me hacía especial ilusión asistir también a la charla de Sebastian Muniz y Alfredo Ortega, no sólo por la buena pinta que tenía, sino también porque la noche anterior estuvimos charlando con ellos y, a parte de ser muy buena gente, son unos verdaderos cracks.


Día 2

[Chip & Code] EAPEAK – Wireless 802.1X EAP Identification and Foot Printing Tool / Matt Neely & Spencer McIntyre

Matt Neely y Spencer McIntyre, de SecureState, presentaron una versión inicial de la herramienta que han estado desarrollando para la identificación de los métodos EAP utilizados en redes 802.11 (Wi-Fi).

En primer lugar realizaron un breve repaso a la evolución de la seguridad en las redes 802.11, para posteriormente hacer también una introducción a 802.1x, al framework de autenticación EAP y a los diferentes tipos de EAP utilizados para autenticar a los usuarios. A continuación resumieron el proceso de pentesting de redes wireless, para acto seguido mostrar como detectar de forma manual (con Wireshark) los tipos de EAP utilizados en una red, a partir de capturas de tráfico.

Finalmente enseñaron la herramienta EAPeak que han desarrollado, principalmente Spencer McIntyre, para automatizar este proceso y poder obtener además de los métodos EAP, de una forma sencilla y rápida, otra información de interés como por ejemplo nombres de usuario que viajan en claro en PEAP, TTLS, EAP-FAST y LEAP. Esta última funcionalidad puede llegar a ser muy útil durante ciertos pentests, ya que permite obtener usuarios de Active Directory, sin ni tan siquiera estar asociado a la red.

La herramienta ha sido incluida en el CD oficial de las conferencias, pero será publicada en breve. Además comentaron una serie de mejoras que están planeando, entre las que destacan:

  • Mover parte del código a Scapy, para que otras herramientas puedan obtener información EAP de forma más sencilla.
  • Incorporar métodos de ataque, para complementar la herramienta y que esta deje de ser exclusivamente de análisis.

Destacar también la aportación de Raúl Siles durante la tanda de preguntas, ya que su propuesta de añadir métodos activos para el descubrimiento de los métodos EAP, tuvo buena acogida por parte de los ponentes.

En resumen, una buena charla con la que nace una herramienta que puede ser de gran utilidad 🙂

 

[Infraestructure rationale] Owning the data centre using Cisco NX-OS based switches George Hedfors

Durante esta charla George Hedfors, del grupo Cybercom, sacó a relucir diversas deficiencias de seguridad que había detectado previamente en un dispositivo Cisco-7020. De una forma muy distendida y amena, fue explicando como a partir de la explotación de una vulnerabilidad detectada hace 9 años, se interesó por estudiar el modelo de seguridad de estos dispositivos, extrañado por explotar una vulnerabilidad tan antigua en un sistema moderno.

De entre los problemas detectados y reportados a Cisco por George Hedfors, destacan:

  • Ejecución de los daemons con privilegios de root y sin chroot ni similares.
  • La command line interface (CLI) de los dispositivos incluye gran cantidad de comandos ocultos, entre los que destaca gdb, mediante el cual es posible llegar a ejecutar una shell del sistema.
  • sudo configurado con la opción «NOPASSWD» para gran cantidad de comandos.
  • Vulnerabilidad a nivel 2 mediante el envío de paquetes CDP especialmente formados (no se valida correctamente el ID del dispositivo). Además el daemon de CDP se ejecuta como root…
  • Usuario FTP con credenciales hardcodeadas no documentado.
  • La shell utilizada en el dispositivo vsh, tiene una opción con la que no hace falta realizar una escalada de privilegios, ya que permite la ejecución de todos los comandos deshabilitando los roles de seguridad.
  • La CLI utilizada permite obtener una shell ejecutando comandos como:
ssh `/bin/bash`

Creo que con todo lo anterior os podéis hacer una buena idea…

Uno de los mejores momentos de la charla fue cuando, desde el público, un representante de Cisco se ofreció a resolver las preguntas de los asistentes. No dio demasiadas explicaciones ni soluciones concretas, más allá de instigar a cualquiera que tenga dispositivos de este tipo a que pida que se solucionen los problemas y a poner presión a Cisco, pero personalmente valoro como muy positiva su actuación ya que aguantó estoicamente  y dio la cara.