Aislando las aplicaciones web

En este post me gustaría explicar la solución que he encontrado a uno de los problemas que me plantea el hecho de utilizar de Apache como servidor web por defecto, ya es que Apache no permite la ejecución de distintos VirtualHost con diferentes usuarios, lo cual puede suponer un grave problema de seguridad. Imaginemos que tenemos la siguiente situación en el mismo servidor:

  • Los Wookies tienen desplegada una aplicación cuyo funcionamiento consiste en incluir el contenido de un fichero del sistema especificado en un campo GET y mostrarlo al usuario. Por la sencillez de la aplicación y la no-criticidad de la misma, no se realiza ningún tipo de comprobación.
  • En el mismo servidor, Darth Vader tiene desplegada una aplicación que consulta de una base de datos, planos de infraestructuras críticas, como por ejemplo, el de la Estrella de la Muerte. Para ocultar el fallo de diseño de la misma, la aplicación se audita varias veces por un organismo externo sin encontrar ni un fallo de seguridad.
  • La fuerza Rebelde aprovecha el LFI de la web de los Wookies, y lee ficheros de sistema, entre los que se encuentra la configuración de la página web de Darth Vader.
  • Utilizando las credenciales obtenidas del fichero de configuración, son capaces de conectarse a la base de datos y obtener los planos de la Estrella de la Muerte, provocando la explosión que pudimos ver en Star Wars I (N.d.A.: no, no me he equivocado) – Una nueva esperanza.

[Read more…]

Descubriendo vulnerabilidades tradicionales en sistemas ICS

Recordarán que en un post anterior, titulado La odisea de (intentar) hacer las cosas bien…, les daba los detalles del tortuoso camino que he tenido que atravesar desde el descubrimiento de una vulnerabilidad hasta su publicación. Dado que la vulnerabilidad ya es pública (véase Advisory (ICSA-14-203-01), Omron NS Series HMI Vulnerabilities), es el momento de hablarles de ella. Aunque lo cierto es que la publicación de esta entrada, tras unos 10 meses de espera, estaba ya previamente planificada.

Las vulnerabilidades que les comento fueron encontradas en el NS15 versión 3.19 (aunque desconozco si otras versiones están afectadas), un HMI de la marca OMRON.

La primera de ellas es un XSS persistente que permitiría inyectar código malicioso a través del formulario de configuración, concretamente en el parámetro “Page Title”, que se encarga de modificar el título de las páginas web del sistema. No obstante, para aprovecharse de ella, el atacante deberá estar autenticado en el sistema. Sin embargo…

Cuando el sistema almacena todas las opciones y sus valores, se puede comprobar como los valores introducidos en el formulario de configuración se transmiten mediante método “GET”, apareciendo todos los parámetros en la barra de navegación. Como no existe ningún parámetro que haga de token, un atacante podría aprovechar esta vulnerabilidad de tipo CSRF y crear una URL que permitiese cambiar la configuración del sistema HMI.

Aunque en un primer lugar ambas vulnerabilidades pueden parecer más bien simples e incluso irrelevantes, de explotarse en un sistema crítico los resultados podrían ser devastadores.

Imaginemos que un atacante decide realizar un ataque dirigido contra el operario que se encarga de controlar el sistema HMI. Para ello, el atacante le enviará un enlace que, aprovechándose del CSRF, inyecte un payload que aproveche la vulnerabilidad XSS. En este caso, la finalidad del payload será la de suplantar la página web de control por otra.

De este modo el atacante podría conseguir que el operario modificase el estado del sistema a partir de una información falsa (escogida por el atacante para sus propios propósitos). En otro escenario, si el atacante consiguiese atacar con éxito el sistema, el ataque resultaría invisible para el operador, a cuyos ojos todo estaría en perfecto estado. Algo, que si no recuerdo mal, también realizaba Stuxnet en su día.

La odisea de (intentar) hacer las cosas bien…

Hace unos días, Antonio Sanz comentaba en su post “He descubierto una vulnerabilidad: ¿Y ahora qué?” las distintas opciones que existen cuando se encuentra una vulnerabilidad de seguridad.

En este post, pretendo contar mi experiencia acerca de un responsible-disclosure que llevo coordinando desde octubre de 2013. Para situar al lector en contexto, decir que en dicho mes encontré un par de fallos de seguridad en un dispositivo HMI (Human-Machine-Interface) perteneciente a un sistema de control industrial. Explotando las dos vulnerabilidades de manera simultánea, la situación se puede volver algo “peliaguda” para el operador del sistema, lo que no es ningún tipo de consuelo si tenemos en cuenta la finalidad de los sistemas que son vulnerables.

Nada más encontrar la vulnerabilidad, realicé una pequeña búsqueda de buzones de contacto de la empresa, para ponerme a hablar directamente con ellos y agilizar el trámite. A día de hoy, todavía espero respuesta.

La segunda opción fue contactar con el ICS-CERT, la organización encargada de lidiar con este tipo de problemas en cuanto a sistemas industriales se refiere. Amablemente, al día siguiente nos comunicaron que se iban a poner en contacto con el fabricante para poder solucionar el problema.

Sin embargo, no es oro todo lo que reluce, y tras varios intentos infructuosos de contactar con el fabricante, ICS-CERT decidió gestionar el incidente con otro CERT, ya que sería más fácil para este último ponerse en contacto con la empresa en cuestión. Tras verificar qué versiones del dispositivo son vulnerables, miramos el reloj y nos damos cuenta de que ya estamos en Navidades, con lo que entre vacaciones y fiestas, retomamos las conversaciones un 8 de enero de 2014, cuando nos dicen que van a preguntar al otro CERT para ver el estado de la vulnerabilidad.

La siguiente noticia que tenemos es un 13 de febrero, cuando nos confirman que el fabricante ha verificado la existencia de la vulnerabilidad y nos comunican que van a investigar si ésta afecta a más equipos, mientras trabajan para solucionarla; contactamos con otro CERT, gubernamental, para ver si a ellos les hacen más caso, pero parece que no… Nosotros, por nuestra parte seguimos insistiendo para conocer el estado del incidente, hasta que un 29 de abril nos confirman que el estado sigue siendo el mismo que en febrero.

Más tarde, en mayo nos informan de que el fabricante ha hecho públicas las vulnerabilidades, y que ICS-CERT va a crear un advisory (toma ya, nosotros callados y estos van y…). Ya en junio, el mismo ICS-CERT nos comunica que las vulnerabilidades sólo afectan a los productos vendidos internacionalmente (si yo fuera desconfiado, sospecharía…), y que el fabricante no notificará a sus clientes nacionales, pero sí a los extranjeros; la fecha estimada para ello es mitad de junio o principios de julio (por suerte para ellos, en el correo no dicen si será este julio, o el de dentro de diez años, cuando el producto ya esté obsoleto, y por tanto, nadie lo tenga).

En resumen, llevamos desde octubre de 2013 y hemos llegado a julio de 2014 y la vulnerabilidad es conocida desde hace nueve meses por parte del fabricante. Sin embargo, el cliente final, quien es realmente vulnerable, no lo sabe. Por estos motivos, hemos decidido hacer pública la vulnerabilidad en los próximos días. Seguid conectados. Para animar la espera, podéis comentar vuestras experiencias al reportar vulnerabilidades en los comentarios de esta entrada.

PD Nada que reprochar ni al ICS-CERT ni a ningún otro de los CERT que han intentado, junto a nosotros, hacer las cosas bien… creemos que el principal, y único, problema, lo ha aportado el fabricante…

ICS-CERT: vulnerabilidades de sistemas de control industrial

Hace unos días, el ICS-CERT publicó el análisis de vulnerabilidades de sistemas de control industrial (ICS) durante el año 2013. En dicho análisis, podemos comprobar como la vulnerabilidad que aparece con mayor frecuencia tiene que ver con las medidas de autenticación (33%), seguida por la denegación de servicio (14%). Es decir, si los administradores de estos sistemas desconectasen (o no conectasen directamente) estos sistemas de Internet, y forzasen una política de contraseñas segura, se acabaría con casi el 50% de las vulnerabilidades reportadas.

En el informe ICS-CERT da una serie de consejos que, implementados correctamente, dificultan de manera significativa el hecho de que un ataque resulte satisfactorio:

  • Minimizar la exposición a Internet.
  • En caso de necesitar acceso remoto, hacer uso de VPN.
  • Eliminar credenciales por defecto.
  • Implementar medidas de bloqueo de cuentas.
  • Establecer e implementar políticas que requieran el uso de contraseñas fuertes.
  • Monitorizar la creación de cuentas de administración por parte de proveedores externos.
  • Aplicar parches de seguridad en el ICS.

(Óscar Navarro apunta correctamente que las medidas de bloqueo de cuentas deben utilizarse con mucha cautela en sistemas SCADA, dado que controlan sistemas industriales y un problema de acceso en una situación de emergencia puede ser fatal. La recomendación de utilizar contraseñas fuertes dependerá mucho de las características del SCADA, ya que no todos permiten tales funcionalidades. Por último, también la aplicación de parches de seguridad debe ser tratada con sumo cuidado, dado que puede implicar un mal funcionamiento del SCADA. Es duro, pero es así.)

En el informe también se puede observar como el 65% del total de vulnerabilidades publicadas (93 de 177) tienen un impacto superior a 7.0.

Por último, cabe mencionar que dos de los investigadores que colaboraron durante el año 2013 con el ICS-CERT son españoles. En concreto Rubén Santamarta y Joel Sevilleja Febrer (es decir, un servidor) :)

Gentoo Hardened

En este post voy a hablar sobre una distribución, que por alguna misteriosa razón que no llego a entender, no suele ser utilizada. Hablo por supuesto, de Gentoo en su modalidad “Hardened”.

(N.d.A: Los siguientes párrafos evangelizan hacen una introducción a Gentoo, por lo que si el lector ya la conoce, puede saltar directamente a Gentoo Hardened)

Gentoo es una distribución rolling-release (lo que quiere decir que la distribución se actualiza continuamente con nuevas funcionalidades, además de para solucionar bugs). No obstante, su mayor característica es que los “paquetes” han de ser compilados por el usuario con una herramienta llamada “emerge”, que forma parte del sistema Portage.

Seguramente, el lector debe estar pensando que compilarse los propios paquetes es una pérdida de tiempo y que mejor gastar una Ubuntu / Debian / CentOS que ya te lo dan todo hecho. Pero, estamos en el año 2014 y si bien a comienzos del año 2000 la instalación de un sistema de escritorio podía durar una semana, con una máquina moderna podemos tener un sistema funcional en una noche, siempre y cuando sepamos lo que estamos haciendo. Y fíjense que estoy hablando de un sistema de escritorio, donde suele haber mayor cantidad software (y de mayor tamaño), que en un servidor.

[Read more…]

Crónica Rooted CON – Día 2

El segundo día de este congreso comenzó de la mano de Jose Luis Verdeguer (@pepeluxx) y Victor Seva (@linuxmaniac), que en su charla “Secure Communications System” concienciaron a los presentes de que en un sistema de comunicación, aunque las transmisiones se cifren de extremo a extremo siempre pueden haber mecanismos que permitan realizar técnicas de tipo “man-in-the-middle”, por lo que no es recomendable confiar en infraestructuras de terceros si la privacidad es crucial. Como colofón, presentaron un sistema de comunicaciones libre, basado en VOIP, en el que prima la seguridad, y que estará disponible para su descarga en breve.

A continuación, Joaquín Moreno (@MoxilO), ex-compañero de Security Art Work, realizó una densa charla sobre forense en Mac OS X titulada “Forense a bajo nivel en Mac OS X”. El trabajo realizado por Joaquín es parte de su tesis de máster, y además, prometió publicarlo en cuanto lo presentase, por lo que los interesados podremos asimilar de manera más tranquila todos los conceptos presentados en el breve tiempo del que dispuso. Además, Joaquín está implementando su trabajo a modo de complementos para Plaso, una herramienta para generar líneas temporales cuando se realizan análisis forenses.

Tras un breve descanso en el que pudimos disfrutar de las ya tradicionales conchas Codan, Jorge Ramió (con el que tuvimos una entrevista en Security Art Work), reconocido criptógrafo y profesor de la UPM, realizó una charla denominada “RSA cumple 36 años y se le ha caducado el carné joven” donde tras una breve introducción al algoritmo de cifrado RSA, explicó cómo éste ha sido capaz de afrontar sus 36 años de existencia mediante el aumento de la cantidad de bits necesarios para generar las claves criptográficas. No obstante, Ramió también mostró técnicas de “crackeo” independientes de la longitud de clave y del algoritmo. Estas técnicas, conocidas como ataques de canal lateral consisten, por ejemplo, en escuchar el sonido que emiten los sistemas al realizar los cálculos, o medir la potencia eléctrica que consumen para así poder recuperar la clave criptográfica y poder descifrar los datos.

En la siguiente charla, José Luís Quintero y Félix Estrada, Centro de Operaciones de Seguridad de la Información del Ministerio de Defensa (COSDEF), dieron una charla sobre ciberguerra titulada “Ciberguerra. De Juegos de Guerra a La Jungla 4”, que como su título indica, fue amenizada con referencias a clásicos del cine como Juegos de Guerra.

A continuación, Jeremy Brown y David Seidman, de Microsoft, iban a presentar su charla “Microsoft Vulnerability Research: How to be a finder as a vendor”. No obstante, al no poder asistir David Seidman, fue Jeremy Brown quien finalmente dio un repaso a los programas de compensación para los investigadores de seguridad que deciden colaborar con Microsoft.

Antes del descanso, Chema Alonso (@chemaalonso) habló sobre su ojito derecho, Latch, en una charla titulada “Playing and Hacking with Digital Latches”. Como muchos ya sabréis, esta herramienta permite definir a los usuarios si pueden acceder, o no, a sus redes sociales. De este modo, se garantiza que si un usuario no requiere acceder a un recurso, nadie más puede hacerlo empleando su cuenta.

Tras un breve descanso, Miguel Tarasco presentó AcrylicWifi en su charla “Análisis WiFi de forma nativa en Windows”. AcrylicWifi es una herramienta de análisis de seguridad y monitorización de redes inalámbricas para sistemas Windows desarrollada por Tarlogic. A su vez, Andrés Tarasco presentó en “Ataques dirigidos con APTs Wi-Fi” el protocolo WXP (Wireless exfiltration Protocol), cuyo fin es el de comunicar los sistemas afectados por un APT con su Command & Control a través de los probe request y probe response de la tecnología WiFi.

Roberto Baratta (@RoberBaratta), dio consejos sobre cómo mejorar la seguridad informática con un presupuesto casi nulo en su charla “Monetización de la seguridad”. La última charla del día vino de la mano de César Lorenzana y Javier Rodríguez (@javiover) del Grupo de Delitos Telemáticos de la Guardia Civil (@GDTGuardiaCivil), exponiendo un caso de éxito en su ponencia “Por qué los llaman APT cuando lo que quieren decir es dinero” detallaron un caso que resolvieron sobre APTs.

Metadatos: el algodón no engaña

A raíz de todo el revuelo que hay estos días en torno a los metadatos, he estado revisando las distintas herramientas de borrado de metadatos para ficheros PDF que existen. En principio, las herramientas que analicé funcionan en sistemas GNU/Linux, aunque eso no implica que algunas no puedan funcionar en otros sistemas.

Partí de un PDF que generé yo mismo, y que tal y como se puede ver en la siguiente imagen contiene metadatos:

Metadatos

[Read more…]

Bastionado de servidores ssh

Recientemente adquirí un servidor dedicado que utilizo para, entre otras cosas, compartir ficheros entre amigos. En principio, la compartición de ficheros se iba a hacer mediante HTTPS, por lo que el servidor SSH no tenía ninguna configuración fuera de lo normal. Bastó con algunos cambios de la configuración por defecto para tener algo un poco más robusto:

Port X
Protocol 2
ServerKeyBits 4096
LoginGraceTime 30s
PermitRootLogin no
MaxAuthTries 3
MaxSessions 2
PubkeyAuthentication yes
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers usuario

Sé que me he dejado varias cosas importantes, como toda la gama de los forwardings, y que cambiando el puerto en el que escucha el demonio SSH no se soluciona nada (seguridad por oscuridad)… excepto todos los intentos realizados por bots, que creedme, son bastantes.

[Read more…]

Conferencias Navaja Negra – Días 2 y 3

Continuamos con el resumen de la 3ª edición de Navaja Negra, al que asistimos José Vila (@jovimon) y un servidor los pasados días 3-5 de octubre.

En este segundo día, la primera charla fue a cargo de Marc Rivero (@Seifreed), en la que habló sobre la evolución del fraude en Internet. En ella, Marc comenzó haciendo un breve resumen sobre las amenazas más sonadas: phishing, troyanos, el virus de la Policía… así como de los kits disponibles en el mercado negro para facilitar la creación de los mismos.

Respecto a este tipo de amenazas, Marc también hizo hincapié acerca de las herramientas disponibles en ambos bandos ya sea para verificar que el malware es indetectable o bien para poder neutralizarlo. También se habló sobre las técnicas Man-in-the-Browser, en las que el atacante actúa de árbitro entre el cliente y el servidor, obteniendo en este caso las credenciales de acceso a la cuenta corriente de la víctima, para luego realizar pequeñas transferencias que puedan pasar desapercibidas.

Otros temas que se trataron en la charla fueron los de los muleros y el uso de servidores a prueba de balas, o servidores comprometidos, para alojar el malware y dificultar la identificación de los responsables.

[Read more…]

Review: Social Engineering: the art of human hacking

Ahora que viene el verano, no hay nada como tumbarse al aire libre mientras se lee un buen libro. Y si el libro ayuda a mejorar nuestras habilidades, mejor que mejor. Por este motivo, me gustaría recomendaros “Social Engineering: The Art of Human Hacking”, un libro que si bien ya tiene casi 3 años, no ha perdido un ápice de su significado, ya que las personas (por suerte), no evolucionamos tan rápido como las tecnologías de la información.

Su autor, Christopher Hadnagy, es un reconocido experto en ingeniería social y seguridad física, ha estudiado acerca de las “microexpresiones” (¿a alguien le suena la serie de televisión Lie to me?) y es el desarrollador principal de social-engineer.

Tras leer el libro, he descubierto paralelismos entre el “pentest a humanos” y el “pentest a sistemas”: en ambos existe una fase de recopilación de información, en la que el auditor utiliza tanto información digital como física, incluyendo la interacción con el objetivo, así como en sus desperdicios. Las siguientes fases de un pentest adicional, se podrían englobar en lo que denomina elicitación: consiste en averiguar, con la información de que se dispone, como se comporta el objetivo, de manera que el pentester sea capaz de conducir a la persona hacia un lugar u otro.

[Read more…]