Black Hat Europa, 2 day briefings

En su segundo día, la Black Hat Europa comenzó con la presentación de Thai Duong y Juliano Rizzo sobre Crypto ataques a aplicaciones web. Su investigación se ha dirigido a cryptoanalizar el modo de cifrado por bloque Cipher-Block Chaining. CBC fue inventado por IBM en 1976. En este cifrado, a cada bloque de texto plano se le aplica una operación XOR con el resultado del bloque anterior. De esta manera el resultado de un módulo es dependiente de los anteriores, excepto para el primero que se utiliza un vector de inicialización IV. La siguiente imagen es muy ilustrativa:

El tamaño de bloque suele ser de 8 bytes con un cifrado DES/triple DES o 16 bytes para AES. Por lo que respecta a la clave de cifrado se utiliza 56 bits para DES, 168 bits para triple DES y 128, 192 o 256 para AES. Pero, ¿qué ocurre si el último bloque de texto plano no es del tamaño requerido? Pues que es completado con información arbitraria, normalmente 0’s por seguridad. Esta última afirmación es justamente una de las debilidades del sistema.

Thai Duong y Juliano Rizzo presentaron el ataque Padding Oracle, el cual requiere que el atacante pueda interceptar mensajes con padding y a su vez tenga acceso al sistema que lo comprueba a modo de oráculo. El proceso que un atacante podría realizar para comprobar si el rellenado de bits es correcto es el siguiente:

  • Se remite la cadena cifrada al oráculo.
  • El oráculo mediante la clave de cifrado comprueba si es correcto el padding
  • El oráculo contestará al atacante con un 0 si es incorrecto o un 1 si es correcto.

Si el lector quiere ampliar conocimientos en cuanto al proceso completo recuperación de la trama de bytes original puede consultar su paper, disponible online.

Como caso práctico de implementación del ataque, Thai y Juliano presentaron la rotura de un captcha que utiliza este modo de cifrado. El sistema utiliza CBC para albergar el texto detrás de la imagen difuminada, lo que han denominado ERC.

<img src=”/captha?token=ERC”/>

El ERC se guarda en un campo oculto del formulario o en una cookie. Cuando el usuario remite el código introducido por teclado, el servidor compara la cadena con el resultado de descifrar el ERC. Si son iguales el resultado del captcha es correcto. De esta forma el servidor que recibe el ERC es susceptible a ataques de Padding Oracle siempre y cuando respondan ante rellenados de bits incorrectos. En la mayoría de sistemas, cuando se modifica el ERC y el rellenado es correcto el servidor devuelve una imagen con un código difuso, pero el problema viene cuando el servidor ha inicializado el IV con información aleatoria dificultando la obtención de P0. Para solventarlo, Thai y Juliano proponen obtener P0 y el IV de una imagen introducida por un usuario normal.

Otros sistemas que utilizan CBC e identificados por los autores del ataque, son las View States de JavaServer Faces. Nuevamente, un 10 para estos chicos.

Black Hat Europa 1 day briefings (IV)

La BH Europa, en general nos ha dejado muy buen sabor de boca, aunque no todo fueron peritas en dulce. La única nota negativa la trajo James Arlen, que a través de un seductor titulo SCADA and ICS for Security Experts tuvo a la audiencia expectante, esperando las últimas novedades sobre seguridad SCADA. Nada mas allá de la realidad, detrás de un gran orador —todo hay que reconocerlo— la conferencia no aportó novedad alguna, vertiente técnica, o aplicación interesante.

Por el contrario, Manish Saindane de Attack and Defense Labs acudió con una propuesta sobre como atacar aplicaciones que utilizan objetos serializados en Java. Manish ha desarrollado un plugin para Burp que permite al Pentester editar objetos Java on the fly. La serialización de objetos Java es un protocolo implementado por Sun para convertir objetos en tramas de bytes, con el objetivo de guardarlos en disco o transmitirlos por la red. Este flujo de datos contiene la suficiente información para reconstruir el objeto original. A título informativo, la clase que puede instanciar objetos de este tipo son ObjectOutputStream y ObjectInputStream, cuyos métodos serializables son: readObject(), writeObject().

Cuando un objeto serializado es transmitido por la red se puede identificar por su cabecera con los bytes 0xac 0xed, aunque es posible que viaje comprimido en formato zip. Si el objeto es de tipo String, por ejemplo, éste vendrá codificado en UTF-8 modificado. El ataque funciona de la siguiente manera:

[Read more…]

Black Hat Europa 1 day briefings (III)

Continuando con la crónica de la BH Europa que estamos realizando estos días, en la cuarta exposición Paul Stone de Context (empresa de seguridad del Reino Unido) vino con una propuesta muy interesante sobre nuevas técnicas de ClickHacking, presentándonos una nueva herramienta que permite implementar este tipo de ataques. Destacar que ésta se puede descargar y juguetear con ella.

El ClickHacking es un término relativamente nuevo (sobre 2 años), que básicamente consiste en hacer que el usuario pinche (clickee) en cierto contenido oculto a través del uso de iframes, permitiendo a un atacante realizar acciones como un usuario lícito. Un ataque típico contra versiones de Flash antiguas permitía a un usuario mal intencionado tomar el control de la cámara y el micrófono de la víctima habilitando la configuración de seguridad.

Este tipo de nuevas técnicas presentan las siguientes características:

  • Se evita la protección Anti-CSRF
  • Se inyectan Clicks no datos
  • No funciona el ataque si la distribución de la página cambia
  • Requiere de la interacción con el usuario
  • Se puede evitar con Anti-Framing

Pues bien, vamos a ver un ejemplo de cómo utilizar esta fantástica herramienta, aunque para aquellos interesados, nada mejor que probar la aplicación directamente. En primer lugar cargamos el Framework abriendo con el navegador el recurso cjtool.html. En el frame izquierdo tenemos el menú de acciones y en el derecho el entorno de acción.

En el cuadro de texto URL introducimos la dirección de la página que queremos que interactúe con el usuario de forma oculta. En el marco derecho por tanto y tras pinchar en “Go”, identificamos los campos donde queremos inyectar el Click. En este caso vamos a hacer la prueba con un entorno phpLDAPadmin. Nuestro objetivo será que cuando el usuario realice un primer Click se rellene el campo contraseña con un valor arbitrario, y en una segunda pulsación del ratón se producirá un evento sobre el botón enviar. Este ejemplo es meramente ilustrativo de cómo utilizar la herramienta, ya que no se pretende autenticarse con las credenciales del usuario legítimo. Un escenario real donde se pudiera aprovechar esta vulnerabilidad sería por ejemplo, un site bancario donde el atacante mediante una serie de acciones sobre la página pudiera completar una transacción bancaria a favor del atacante.

Volviendo al ejemplo, en el menú izquierdo encontramos las acciones que se pueden “programar” sobre la página: Cargar URL, hacer un Click, introducir texto, arrastrar contenido, o extraer contenido. Introducimos en primera instancia una cadena de texto arbitraria en el campo contraseña. Hacemos click en Enter Text, arrastramos la cruz verde desde el menú izquierdo al campo contraseña del frame derecho, y por último introducimos la cadena deseada.

Lo siguiente es establecer la acción de presionar sobre el botón “Entrar”. Pulsamos sobre el botón “Click” y nuevamente arrastramos la cruz sobre “Entrar”.

Una vez establecidas las acciones que queremos que realice el usuario, podemos simularlo con Replay Steps. Inmediatamente en el marco derecho vemos como el puntero se sitúa sobre el campo contraseña movamos donde movamos el ratón. Tras hacer click, la cadena programada es copiada en el formulario, pasando el puntero nuevamente al botón “Entrar”. Una última pulsación permite entrar en la aplicación sin que el usuario lícito se entere.

Sin ninguna duda, un gran trabajo de Paul Stone y el equipo de Context, ¡un 10!

Black Hat Europa 1 day briefings (II)

Continuando con la crónica de la BH Europa, un magistral Christopher Tarnovsky vino a presentarnos Hacking Smartcards, un trabajo de más de seis meses que ha comenzado a dar sus frutos durante este último mes y que ha expuesto en exclusiva para la Black Hat.

Para que todos nos hagamos una idea sobre que ha versado su trabajo o su impacto, comentar que en nuestra vida diaria vivimos con Smartcarts: monederos electrónicos, gestiones bancarias, soporte para albergar el certificado del DNI-e. Una Smartcard era uno de los dispositivos más seguros y donde fabricantes de tarjetas y entidades bancarias depositaban su confianza. Pues bien, este “monstruo” pensó lo que es obvio, en algún punto de la circuitería interna del chip existe un bus de datos donde la información viaja en claro antes de pasar al módulo de cifrado. Esta frase, que resulta muy fácil decir, es una tarea faraónica dado los millones y millones de transistores, puertas lógicas y buses que puede tener el integrado.

En el mundo existen prácticamente 3 fabricantes de estos tipos de tarjetas que implementan una unidad de proceso 6805 (ST), 8051 (NXP) o AVR (ATMEL). Su estudio ha sido orientado al fabricante INFINEON, aunque como él comentaba el ataque puede ser extendido a otros modelos. Las fases que ha seguido Christopher para llevar a cabo el Hack son:

[Read more…]

Black Hat Europa 1 day briefings

Como era de esperar una de las conferencias de seguridad más importantes del mundo, la Black Hat, no ha defraudado en su vertiente europea. Un gran escenario, el Palau de Congresos de Catalunya, ha servido de perfecto telón de fondo para albergar a la crème de la crème de los profesionales de la seguridad mundial, es por eso que S2 Grupo no podía faltar. Nada más llegar, un dato aportado por la organización resulta a un servidor sensiblemente preocupante, la distribución de asistentes por países refleja un escaso interés por parte del auditorio español (empresas, entidades públicas, I+D) haci las seguridad y la protección de la información. Con una participación entorno a 500 personas, tan solo 28 españoles constaban como inscritos. Por el contrario colegas de la profesión con un importante número de horas de vuelo a sus espaldas el día anterior, como Estados Unidos, aportaban 58 asistentes. Vietnam, la India, Alemania, Argentina, Francia o Rusia hacían presencia de forma significativa.

El evento fue en su primer día inaugurado por Max Kelly, máximo responsable de seguridad del bien conocido portal social Facebook. Éste introdujo los valores de seguridad que son aplicados en su política y que muchos de nosotros en nuestras organizaciones deberíamos seguir. En primera instancia, según palabras de Max, Facebook persigue mediante su equipo legal a todo aquel atacante o intruso que realice acciones ilícitas contra sus sistemas, mediante la CAN-SPAM (15 USC 7701), Computer Security Fraud And Abuse Act (18 USC 1030) y evidentemente los Facebook’s Rights and Responsabilities. Para dar soporte a acciones técnicas se apoyan en la comunidad mundial de la seguridad White-Hats, analizando los ataques recibidos con el objetivo de conocer a tu enemigo. Por último hubo una frase de su presentación que debe incitar a la reflexión colectiva: Compliance isn’t security. Ahí queda eso.

Como entrantes, Joe Grand, presentador del programa de televisión de Discovery Channel Prototype This, presentó la charla Hardware is the new Software. Mientras los pentesters normalmente suelen dirigir sus acciones contra aplicaciones, servidores de correo o páginas web, el hardware es el gran olvidado. Joe comentó que hoy en día la preocupación por la seguridad a este nivel sigue avanzando en menor medida que la relativa al software, pudiendo comprometer los dispositivos mediante simples tipos de ataques que siguen funcionando desde hace años. Esto es debido a la escasa preparación en materias de seguridad de los diseñadores de hardware. Pero, ¿cómo adentrarse en este mundo? Entre otras, sugirió dos paginas donde fundamentalmente se puede adquirir material para ello, www.adafruit.com y www.makershed.com. Es necesario básicamente: ChipQuickSMD (kit de eliminación limpia de integrados), Picoscope (osciloscopio software), microscopio y un soldador claro.

[Read more…]

I Encuentro Internacional CIIP: Taller de Gestión de Incidentes

Como ya hemos comentado en anteriores entradas, el pasado 18 de febrero S2 Grupo estuvo presente en el 1er Encuentro Internacional CIIP para la Ciberseguridad y Protección de Infraestructuras Críticas, organizado por el CNPIC, Centro Nacional para la Protección de las Infraestructuras Críticas.

Como parte de la agenda participé en el Taller “Gestión de Incidentes y Sistemas de detección preventiva / alerta temprana”, orientado a la implantación de las medidas de detección y alerta de incidentes, que permitan monitorizar toda aquella actividad TIC ilícita que pueda suponer un riesgo para las infraestructuras críticas. Al respecto, he de expresar mi descontento con la manera en que se enfocó el taller, compartido por la mayoría de presentes, ya que consistió principalmente en la presentación de un producto comercial, algo para lo cual existen lugares y oportunidades mejores. Esto provocó que el contenido “útil” del taller fuese muy inferior al de otros talleres.

En cualquier caso, uno de los aspectos más interesantes del taller residió en el análisis de la capacidad de las organizaciones para establecer un sistema o motor de correlación que permita aplicar una lógica avanzada a los flujos de información que tienen como origen los agentes de monitorización desplegados. En algunas ocasiones una entidad puede implantar sistemas de monitorización de intrusos, agentes de control de la disponibilidad de los servicios TIC o incluso herramientas de detección de vulnerabilidades, pero, ¿cómo poder obtener información que aporte un mayor valor de los datos cruzados de las diferentes sondas? Aquí es donde entra en acción el motor de correlación. Imaginemos una situación donde un agente de control de autenticación a nivel del SO detecta un acceso de un usuario A, pero no tenemos constancia de que el sistema de control de accesos físico o de acceso por red privada virtual haya detectado una entrada de A o una conexión remota. En este momento el motor de correlación podría deducir que existe, un robo o cesión de las credenciales de acceso al sistema o que simplemente el usuario A no ha pasado por el control de acceso físico, lo ha burlado.

Situaciones como la anterior otorgan un gran potencial a la correlación de eventos; tan sólo hay que identificar que agentes se tienen desplegados y echarle un poco de imaginación para establecer las reglas de correlación que deseemos. Por último, qué duda cabe que la información procesada por el motor de correlación debe tener como output un sistema de alertas capaz de trazar en todo momento el estado de la incidencia, permitiendo consultar toda aquella información aportada por las sondas de seguridad y que permita al gestor de incidentes aplicar las medias de actuación pertinentes.

Hacking RFID, rompiendo la seguridad de Mifare (II)

Tras introducir el pasado viernes algunos aspectos teóricos relevantes de RFID, en esta segunda parte entraremos en cuestiones prácticas que nos darán resultados muy interesantes.

Comencemos profundizando un poco más en como Mifare realiza el proceso de autenticación. En primera instancia el lector le comunica a la tarjeta que quiere realizar una operación sobre un sector de datos determinado N. El tag o tarjeta en ese momento remite un número aleatorio Nc (Nonce del cliente) de 32 bits a modo de reto, para que sea cifrado con la clave privada compartida previamente. Como respuesta, el lector remite el reto cifrado y un número aleatorio Nr (Nonce del lector) para que el tag lo cifre con la clave privada, generando una trama de 64 bits. En última instancia la tarjeta le envía al lector su reto cifrado. En este momento ambos tienen la certeza de que los dispositivos son legítimos. Destacar que los dos últimos intercambios se realizan ya de forma cifrada, permaneciendo en claro tan solo el envío de la petición de lectura y Nc. La figura de la izquerda ilustra el proceso de handshake.

Este proceso de saludo a 4 bandas es importante ya que de él extraeremos la información necesaria para inferir la clave privada del sector.

Procedamos ahora a realizar una prueba de concepto que nos permitirá, a partir de la captura de la información anterior, inferir la clave privada. Pero, ¿cómo podemos capturar una comunicación real entre un tag y un lector? Aquí es donde juega un papel importante el PROXMARK III. Este dispositivo desarrollado por Jonathan Westhues permite realizar sniffing de varias tecnologías RFID desde baja frecuencia (LF 125 Khz) a alta frecuencia HF (13.56 Mhz) y entre ellas la que nos interesa ISO14443 tipo A sobre la que se basa Mifare. En un principio el PROXMARK III supondría el Hardware sobre el cual se pueden implementar diversas capas físicas y de enlace, de diferentes protocolos, simplemente programando sus integrados con la especificación que se requiera.

[Read more…]

Hacking RFID, rompiendo la seguridad de Mifare (I)

(Actualización: Ya tenemos el Esquema Nacional de Seguridad y el Esquema Nacional de Interoperabilidad aquí, recién salidos del horno. Real Decreto 3/2010 y 4/2010, respectivamente. Véase la página del BOE del 29 de enero para acceder a los PDFs)

En este post y los siguientes de la serie vamos a ver cómo conseguir romper la seguridad de las tarjetas de proximidad RFID basadas en tecnología Mifare. Ello conllevará la lectura y modificación interna de sus datos e incluso el clonado de las mismas.

La tecnología RFID (Identificación Mediante Radio Frecuencia), conforma, hoy en día, una solución extensamente utilizada en sistemas de pago en transportes públicos, controles de acceso a edificios u oficinas, pasaportes, monederos electrónicos o sistemas de control de encendido en automóviles entre otras aplicaciones. Existen diversas soluciones como Mifare, Keeloq o RFID EM4102, que permiten al portador interactuar de forma inalámbrica con los sistemas desplegados. La seguridad de este tipo de tecnologías presenta deficiencias que pueden permitir a usuarios malintencionados realizar acciones ilícitas como fraude en sistemas de pago, bypass del sistema de encendido de automóviles, suplantar la identidad de personas o acceder a áreas de acceso restringido, entre otras cosas.

[Read more…]

WWW. Una ventana al mundo, una ventana para los intrusos

A menudo las organizaciones securizan su dominio protegible implantando una serie de controles tecnológicos que permiten impedir o en todo caso minimizar el impacto de actividades ilícitas por parte de terceras personal, o incluso las realizadas por el propio personal corporativo. Instalación de cortafuegos perimetrales, software de detección y eliminación de malware, proxys, sistemas de detección de intrusos y un largo etcétera, serían algunas de las medidas empleadas.

En este momento el responsable de TI de la organización siente una falsa sensación de seguridad, ya que descuida, entre otras cosas, las posibles vulnerabilidades latentes en el software de los servicios de DMZ. Normalmente estos servicios perimetrales (servidores de correo, DNS…) se sustentan en software de amplia distribución y con un soporte de actualizaciones de seguridad pero, ¿qué ocurre con la pagina web corporativa? Estos sites que ofrecen la imagen y la marca de la organización al resto del mundo son desarrollados de forma personalizada, sin un soporte, muchas veces, de actualizaciones de seguridad. Si quieres que corrija estos errores, paga el esfuerzo que requiere ese desarrollo adicional. Sí, esta frase es bastante común, dado que este tipo de situaciones no se contemplaron en el alcance del proyecto, ni se requirió que el desarrollo siguiera un marco de trabajo de desarrollo seguro.

En bastantes de las auditorias y test de intrusión de aplicativos web que S2 Grupo ha realizado, no sólo se obtuvo el control del site auditado (acceso a insertar modificar o eliminar el contenido de la web), sino que se pudo obtener numerosa información confidencial (credenciales de acceso a zonas privadas, números de cuenta bancarias, cuantas de correo electrónico, documentos confidenciales de la organización…), sin comentar la posibilidad de realizar ataques de phishing y robo de sesiones. Todo ello tan sólo a través de la página web de la corporación, esa ventana al mundo accesible desde el sitio más recóndito del planeta.

Para hacerse una idea de los potenciales puntos de entrada que un intruso tendría a través de la web basta con tener en cuenta el conjunto de parámetros POST y GET de los posibles recursos dinámicos (jsp, asp, php, cgi’s…), así como cookies o cualquier otro tipo de información que sea enviada desde el cliente para que el servidor la procese. En un site de tamaño medio donde su funcionalidad sea informativa y presente una zona privada, el total de puntos de entrada del atacante es inmenso.

He aquí el papel relevante que juega la seguridad en este tipo de servicios, y que en general se tiene totalmente descuidados. Pero, ¿cómo es posible mitigar estos riesgos? Pues aplicando principalmente dos estrategias:

  • Usar un Framework de desarrollo seguro que se integre en el ciclo de vida de desarrollo del software.
  • Realizar auditorias de seguridad, preferiblemente con test de penetración, cuyo alcance abarque tanto el análisis de las vulnerabilidades de la web como los permisos de la base de datos que la sustenta (en caso de que use, claro). Este último punto es de vital importancia porque en numerosas ocasiones los permisos del usuario de la BD que la aplicación utiliza son inadecuados, permitiendo obtener información que no tendría porqué ser accesible. Recordar que siempre hay que aplicar la máxima del mínimo privilegio.

A todo esto cabe añadir que las aplicaciones en general tienden cada vez mas a desplegar su interfaz gráfico hacia la web, e incluso programas típicos de edición de texto como Microsoft Word tienen sus homólogos en la web (ver Google Docs). Dado el auge de esta tendencia y la escasa preocupación por la seguridad de estos servicios, nos lleva hacia un panorama desolador e inseguro, haciendo necesaria la aplicación de controles preventivos y reactivos, que mitiguen estas amenazas para las organizaciones y usuarios particulares.

Pero, ¿quién tiene la responsabilidad de que estos fallos permitan al intruso acceder a la información confidencial? Indudablemente para mí, el programador web, que a menudo es contratado sin experiencia, no solo en seguridad sino en cuanto a skill de programación se refiere, por empresas que lo único que quieren es obtener un producto en poco tiempo, bonito y que cumpla las especificaciones requeridas por el cliente; preocupándose por la funcionalidad y descuidado el rendimiento y la seguridad de su plataforma. ¿Sería conveniente aplicar algún tipo de castigo? Una de las medidas que el equipo de auditoria del ACE Team de Microsoft aplica sobre sus proyectos de desarrollo es penalizar a los jefes de proyecto y programadores que desarrollen de forma insegura, reduciendo el presupuesto de sus proyectos según el número y grado de vulnerabilidades encontradas. Sería una opción a considerar.

Al respecto, y en la línea de lo comentado, la encuesta de esta semana es la siguiente:

[poll id=”10″]

* * *

(N.d.E.) En relación con la encuesta anterior, cuyo resultado les muestro debajo, ha quedado claro (siempre teniendo en cuenta el ámbito en el que nos movemos y el público de este blog) que en general, la preocupación por los datos gestionados por las (empresas propietarias de las) redes sociales es legítima y compartida por gran parte de nuestros lectores.

[poll id=”8″]

In-session Phishing

insession.jpgRecientemente ha sido publicado un nuevo vector de ataque de phishing de mayor complejidad que el clásico envío masivo de correos electrónicos, y que podría permitir el robo de credenciales en aplicaciones bancarias, juegos-online, etc. El denominado In-session Phishing se vale de una vulnerabilidad en la mayoría de los navegadores web: Internet Explorer, Firefox, Safari, o Chrome, al hacer uso de ciertas funciones javascript.

Para explotar con éxito este fallo de seguridad es necesario que se den las dos situaciones siguientes:

1. El usuario este autenticado en la aplicación objetivo del robo de credenciales.
2. Un segundo site que alberga cierto código malicioso es visitado por el usuario, mientras en la web objetivo se esta todavía autenticado.

Al parecer el navegador procede a albergar una huella cuando una página web que utiliza ciertas funciones javascript es visitada, funciones muy habituales según sus descubridores, Trusteer. De esta manera es posible desde una segunda página interrogar al cliente con preguntas binarias sobre si se está o no autenticado en un cierto dominio. Si la respuesta es afirmativa, el código malicioso presenta un sencillo pop-up que informa al usuario sobre una falsa caducidad de la sesión y la necesidad de reautenticarse en la aplicación. En ese momento el usuario no percibe ningún comportamiento extraño puesto que hasta el momento confía en que estaba registrado en un site totalmente lícito.

[Read more…]