Un informático en el lado del mal: Remote Heartbreak Attack: El ex vice-presidente se...

En el año 2008 en un paper titulado "Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses" se especulaba sobre los riesgos de dotar a los marcapasos o los desfibriladores cardiacos implantados de características de conexión inalámbricas, ante la posibilidad de que un atacante interceptase y manipulase el protocolo para detener el sistema, obtener los datos, o lo que sería peor, enviar ordenes que pudieran ser mortales para el anfitrión del dispositivo.

Figura 1: Paper que describe en 2008 los ataques a Pacemakers & ICD

En la popular serie Homeland, en el capítulo 10 de la segunda temporada titulado "Broken Hearts" el ataque terrorista al vice-presidente de los Estados Unidos se hacía mediante un marcapasos que era manipulado remotamente mediante una conexión inalámbrica.

Figura 2: Temporada 2 de Homeland

El desaparecido Barnaby Jack, trabajando en iOActive, escribió en Febrero de este año un post en el blog en el que comentaba el paper citado y el capítulo de Homeland, viendo cuán de plausible era ese ataque a día de hoy en los dispositivos actuales. En el artículo se dicen cosas como:

"At IOActive, I've been spending the majority of my time researching RF-based implants. We have created software for research purposes that will wirelessly scan for new model ICDs and pacemakers without the need for a serial or model number. The software then allows one to rewrite the firmware on the devices, modify settings and parameters, and in the case of ICDs, deliver high-voltage shocks remotely."
Todo el trabajo que había hecho Barnaby Jack en esta industria iba a ser publicado en la pasada BlackHat USA, pero apareció muerto y fue un shock para todos. La charla no se dio y no se le sustituyo en la agenda, creándose un homenaje en la sala que le correspondía durante su slot de tiempo.

Figura 3: Barnaby Jack con el software y las herramientas para hacer ataques a ICDs

No había información sobre las causas de su muerte, pero se había dicho que en el plazo de un mes se darían más datos. Pero no fue así. A día de hoy en el artículo de la Wikipedia dedicado a Barnaby Jack puede leerse referente a su muerte lo siguiente:

"The coroner's office refuses to release information about the cause of death, which is one more reason to assume Barnaby Jack was murdered."
Esta semana, la noticia ha sido que el ex vice-presidente Dick Cheney que tenía uno de estos ICDs ha decidido quitarle todas las opciones de conexión remota por seguridad, ya que parecía una mala idea que alguien como él pudiera ser atacado remotamente.



Figura 4: El ex vice-presidente Dick Cheney ha tomado medidas con su ICD


La realidad acaba superando a la ficción, y lo que a veces puede parecer la trama de una película o serie de acción, puede acabar siendo una más de las variables cotidianas de nuestras vidas. Sea como fuera, ver este tipo de cosas tienen que hacer que mucha gente se preocupe sobre a dónde vamos a llegar al final si alguien puede matar a otra persona solo por un fallo de seguridad en la conexión WiFi de un dispositivo médico o un vehículo.

http://www.elladodelmal.com/2013/10/remote-heartbreak-attack-el-ex-vice.html

Periódico The Guardian - Entrevista a Edward Snowden

Analizando posibles conexiones secretas

Analizando posibles conexiones secretas:

Como saben, Windows lleva a cabo conexiones en segundo plano a sitios, software que trabaja en segundo plano y, en el peor de los casos, de virus o troyanos. Esto último, ocasiona que nuestra conexión a Internet se reduzca aunque tengamos cerrados los programas que normalmente requieren un gran ancho de banda. Ejemplo: FTP, P2P, etc.

¿Cómo podemos analizar estas posibles conexiones?
El proceso es muy sencillo y lo explico a continuación...Ejecutamos Símbolo del Sistema como Administrador

Dentro de la Línea de Comandos, escribimos "netstat -b 5 > activity.txt" (sin comillas)

Esperamos unos minutos (3 o 4), para que pueda guardar la actividad y presionamos "CTRL+C"

Y escribimos "activity.txt", se abrirá un archivo donde existe un registro de los procesos que estaban haciendo conexión a Internet en los minutos que esperábamos (3 o 4 minutos).

Por último, nos toca revisar el registro para comprobar la existencia de algo sospechoso... Esperemos no tener nada jajaj....

SeguridadDelMal

CRIME: el nuevo ataque a SSL/TLS sucesor de BEAST

CRIME: el nuevo ataque a SSL/TLS sucesor de BEAST:

Juliano Rizzo y Thai Duong ya tuvieron una enorme repercusión cuando anunciaron en 2010 el ataque Padding Oracle (CBC) que afectó ampliamente ASP.NET y en 2011 el ataque a TLS 1.0/SSL 3.0 mediante BEAST que era capaz de descifrar las peticiones cliente 'al vuelo' y secuestrar sesiones hacia sitios tan sensibles como los de la banca on-line.

Ahora en la Ekoparty 2012, han presentado otra nueva técnica bautizada como CRIME para comprometer la integridad de las sesiones HTTP protegidas por SSL. Atentos que la explicación es un poco densa...

La técnica

SSL/TLS opcionalmente soporta compresión de datos. En el mensaje ClientHello, el cliente establece la lista de algoritmos de compresión que conoce, y el servidor responde, en el ServerHello, con el algoritmo de compresión que se utilizará.

Los algoritmos de compresión son especificados por identificadores de un byte y TLS 1.2 (RFC 5246) define únicamente el método de compresión nula (es decir, sin compresión). También hay otros documentos que especifican métodos de compresión. En particular, RFC 3749 define el método de compresión 1, basado en DEFLATE, el derivado de LZ77 que es el núcleo del formato gzip y también de los archivos Zip modernos. Cuando se utiliza la compresión, se aplica en todos los datos transferidos, como un stream largo. En particular, cuando se utiliza con HTTPS, la compresión se aplica en todas las sucesivas peticiones HTTP en el stream, la cabecera incluida. DEFLATE funciona mediante la localización de subsecuencias repetidas de bytes.

Supongamos que el atacante es un código javascript que puede enviar peticiones arbitrarias a un sitio destino (por ejemplo, un banco) y se ejecuta en la máquina atacada; el navegador enviará dichas solicitudes con la cookie del usuario del banco - el valor de la cookie que el atacante tiene después. Además, vamos a suponer que el atacante puede analizar el tráfico entre el ordenador del usuario y el banco (para ello, el atacante debe tener acceso a la misma LAN o al punto de acceso WiFi de la víctima, o se ha apropiado de un router de entre medias, posiblemente cerca del servidor del banco).

Para este ejemplo, supongamos que la cookie en cada solicitud HTTP es la siguiente:

> Cookie: secret=7xc89f+94/wa

El atacante conoce la parte "Cookie: secret =" y desea obtener el valor secret. Entonces, programa su código Javascript para emitir una petición que contenga en su cuerpo la secuencia "Cookie: secret = 0". La solicitud HTTP se verá así:

POST / HTTP/1.1 Host: thebankserver.com (…) Cookie: secret=7xc89f+94/wa (…)

Cookie: secret=0

Cuando DEFLATE vea que, hay repeticiones de secuencias "Cookie: secret =" y representan la segunda parte con un token muy corto (uno que dice "la secuencia anterior tiene una longitud de 15 y se encontraron n bytes anteriormente), DEFLATE tendrá para emitir un token adicional para el '0'.

La solicitud va al servidor. Desde el exterior, el atacante ve un blob opaco (SSL cifra los datos), pero puede ver su longitud (con una granularidad de bytes cuando la conexión utiliza RC4; con cifrado de bloques que hay un poco de relleno o padding pero puede ajustar el contenido de las peticiones por lo que, en la práctica, puede conocer también la longitud de las peticiones comprimidas).

Ahora, el atacante lo intenta de nuevo con "Cookie: secret=1" en el cuerpo de la petición. Luego, "Cookie: secret=2", y así sucesivamente. Todas estas peticiones se comprimen con el mismo tamaño (o casi porque hay matices con códigos de Huffman que se utilizan en DEFLATE), excepto el que contiene "Cookie: secret = 7", que comprime mejor (16 bytes de subsecuencia repetida en lugar de 15), y por lo tanto será más corta. El atacante ve eso. Por lo tanto, en unas pocas docenas de peticiones, el atacante habrá adivinado el primer byte del valor secreto.

A continuación, sólo tiene que repetir el proceso ("Cookie: secret = 70", "Cookie: secret = 71", y así sucesivamente) y obtener, byte por byte, el secret completo.

Impacto

Por lo tanto, para que el ataque CRIME tenga éxito, se requieren algunos aspectos:

- Que la compresión SSL/TLS se utilice en ambos extremos
- Que el atacante pueda ejecutar un agente Javascript en la víctima
- Un sniffer que tenga acceso a la sesión cifrada cliente-servidor

Otros factores facilitarían además el ataque:

- El uso de RC4 en lugar de cifrado de bloques como CBC (irónicamente se recomendó el uso de RC4 como una solución temporal contra BEAST...)
- La proximidad del sniffer al punto final del agente de la víctima podría proporcionar información más rápidamente, acortando el tiempo requerido para completar el ataque.

Contramedidas

Basándose en la información actual, parece que la principal contramedida sería desactivar la compresión SSL/TLS, una verdadera lástima en escenarios de conexiones con poco ancho de banda, especialmente en aquellos sitios que contienen muchas imágenes pequeñas o con Ajax pesados que requieren muchas peticiones pequeñas.

También y debido a que el ataque se centra en descifrar las credenciales de sesión, las mejores prácticas estándar para la protección de estas tokens también podrían limitar el impacto:

- Invalidar las credenciales de sesión al salir/idle para limitar la duración de la exposición.
- Invalidar y volver a emitir tokens de sesión periódicamente para limitar la duración de la exposición.
- Tokens de sesión asociados a una IP de origen específica para evitar su reutilización en otros lugares.
- Regenerar los tokens de sesión enlazados a un origen cuando esa fuente envía una solicitud con un token no válido. Esto limita la capacidad de un atacante de realizar fuerza bruta o adivinar tokens.
- Monitorizar los logs del servidor para identificar a un ataque en curso: al intentar enumerar los tokens de sesión, el agente de la víctima generará un gran número de peticiones al servidor web. Un IPS podría además detener el ataque de una forma proactiva.
- Las actualizaciones de software podrían hacer frente a este ataque y probablemente estarán disponible pronto, y hay algunos indicios de que muchos fabricantes ya han actualizado sus productos de forma silenciosa.

Referencias

- Rizzo, Juliano. "The CRIME attack." http://www.ekoparty.org//2012/juliano-rizzo.php
- Duong, Thai. "The CRIME attack." http://www.ekoparty.org//2012/thai-duong.php
- New Attack Uses SSL/TLS Information Leak to Hijack HTTPS Sessions https://threatpost.com/en_us/blogs/new-attack-uses-ssltls-information-leak-hijack-https-sessions-090512
- How can you protect yourself from CRIME, BEAST’s successor? http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/

Solucionario de SAURON Hard (Dificultad Alta), CTF Challenge por @killr00t ganador del reto

Solucionario de SAURON Hard (Dificultad Alta), CTF Challenge por @killr00t ganador del reto:

Solucionario propuesto por @killr00t al reto SAURON nivel Hard. @killr00t cumplió con el objetivo del desafío: Realizar un solucionario diferente a los publicados en internet (aunque en este solo había público uno para el nivel fácil), hacerse root del server y mostrarlo de manera didáctica.

Como siempre animar y recordar a los recién iniciados y expertos a participar de estos desafíos, pues no hay mejor manera de aprender que enseñando…

Felicitaciones a @killr00t quién se convierte en el ganador de una tarjeta Amazon gift por un valor de $30 usd. Además que fue el único que envió solucionario de los 33 que descargaron el entorno…  Se concluyen varias cosas… Entre ellas que el entorno no estaba fácil, y que muchos acostumbran a realizar los solucionarios basados en los ya publicados (no está mal del todo) Pero el ideal es intentarlo por si mismo… Como vimos que hizo Killr00t

Mucho ánimo, pues en unos días presento otro reto igualmente premiado gracias a la corporación ElHackLab.

Descargar solucionario (pdf) >>

Ver en línea:

Open publication – Free publishing – More challenge