Cita

"Those who are willing to pay a penny of security for a penny of usability will eventually have neither"

15 diciembre 2014

#8JornadasCCN_CERT Crónica (y IV)


Enlace permanente de imagen incrustada
Hasta ahora he centrado mi resumen en lo expuesto en el módulo 2 y en la sesión plenaria. Pero también asistí a un par de talleres el miércoles por la tarde, que se enmarcan en el área cubierta por el módulo 1.

El primer taller fue sobre CARMEN, herramienta desarrollada por el CCN, en colaboración con la empresa S2 Grupo, para la detección de APTs. La versión 3.0 tiene muy buena pinta: incluye una nueva pestaña de investigación activa sobre dominios sospechosos, análisis de movimientos laterales por el tráfico cruzado entre las IPs internas de la organización, gestión de honey tokens, de IoCs, sanbox integrada con cuckoo y capacidad de generación de alertas y monitores programados en drools o en python. Además, hicieron una demo sobre cómo utilizarla para perseguir una APT: Carmen es una muy buena ayuda, pero al final una persona tiene que saber interpretar lo que está ofrece y servirse de ella para tratar de deducir el comportamiento malicioso a partir de las consultas realizadas a los log de navegación. En cuanto tenga oportunidad de echarle mano a la nueva versión, escribiré un post al respecto.

El siguiente taller fue sobre la nueva plataforma avanzada de estudio de malware, que pronto estará disponible en el portal del CCN. Está integrada por tres herramientas que trabajan de manera coordinada: MISP (Malware Information Sharing Platform), MARIA (evolución del multiantivirus que tienen ahora) y MARTA (para el análisis de muestras de malware). 

Marta es la parte principal de la plataforma: puede analizar muestras de malware ejecutándolo en una sandbox o enviándoselo al sistema multi-AV de María; mediante unas reglas que envía a MIPS permite compartir la información (solo técnica, no detallada) con la comunidad de analistas. Además, puede generar reglas Snort en función del tráfico de red que salga con la ejecución del "bicho" y tiene un motor de reglas IoC.

S2 también presentó al día siguiente una demo de un ataque a un sistema de control industrial, con su maqueta y todo. Aunque no pude asistir en ese momento (por estar en el módulo 2), ya lo había visto un poco el día anterior, cuando le hicieron la presentación antes del comienzo de sesión al mismísimo SED del CNI. La demo la hicieron con esta maqueta tan chula que podéis ver aquí:


Hubo dos ponencias del módulo 1 sobre las que me han hablado muy bien los que tuvieron la oportunidad de verlas:

Una fue "China y el ciberespionaje: Sun Tzu, APT1 y los tiempos interesantes", de Antonio Sanz, también de S2 Grupo, que ha tenido el detalle de subir ya a Slideshare. Así es que, estoy deseando echarle un ojo.

La otra fue la de Lorenzo Martínez: "Are you the weakest link?", que mostró cómo hacer una APT a una administración pública aprovechándose del eslabón más débil: el funcionario. Si queréis haceros una idea de cómo pudo ser, podéis ver el vídeo de esa misma charla que presentó en la Ekoparty.

[Actualización: en el blog de Security at Work (S2 Grupo) podéis encontrar también la información sobre el Caso práctico APT que expusieron el segundo día]

Y hasta aquí todo lo que tengo. Si alguien asistió a los módulos 1 o 3 y quiere compartirlo con nosotros, yo estaré encantada de cederle sitio en mi blog. Del mismo modo que si alguien quiere añadir o matizar a lo aquí expuesto.

Gracias a todos por lo bien que lo hemos pasado y lo mucho que hemos aprendido, en especial al CCN-CERT, organizador del evento, porque sabemos que les ha llevado mucho trabajo.

Que entre todos sigamos defendiendo nuestro patrimonio tecnológico frente a los ciberataques.

[Actualización: ya se encuentra disponible el contenido de las ponencias en la web del CCN-CERT]

14 diciembre 2014

#8JornadasCCN_CERT Crónica (III)


Enlace permanente de imagen incrustada
Por segundo día acudí a las #8JornadasCCN_CERT, en el madrileño barrio de Atocha. El primer día había sido una delicia, con tanta información, tantas caras amigas a las que hacía tiempo que no veía y tantas cosas ricas de comer.

Ahora me hallaba sentada de nuevo en la Sala Jiménez Díaz, que acogía las ponencias relativas al segundo módulo. ¿Con qué nos sorprenderían en esta ocasión?

La cosa empezó bien, con un tema que parecía sacado de una película futurista, de ciencia ficción, pero que es de rabiosa actualidad: los wearables. Jorge Dávila disertó sobre esta tecnología de vanguardia que permite registrar y enviar información sobre nuestra persona mediante dispositivos en la forma de relojes, gafas, ropa... Así, la gente puede compartir en las redes sociales información tan personal como su estilo de vida, lo que camina, las calorías que consume, la tensión sanguínea, etc.

Ahora bien, estos dispositivos pueden presentar vulnerabilidades que hagan que dicha información sea compartida sin nuestro consentimiento. Otro problema añadido es el hecho de que, no solo el portador puede ser objeto de espionaje, sino que puede ser un espía él mismo: ¿cómo saber si la persona que accede a un recinto no lleva formando parte de su ropa o en algún tipo de implante un dispositivo que permita recopilar y transmitir información confidencial? ¿será necesario obligarle a enfundarse un traje certificado que lo impida?

A pesar de lo cual, no debe desdeñarse un problema que entraba el avance de esta tecnología: el de la duración de la batería, ya que la emisión por radio gasta mucha y la carga por movimiento, aunque factible, es lenta.

Aún así, no deja de ser asombroso cómo evolucionan las cosas. Si alguno de los ilustres médicos que aparecen en las vetustas fotos que adornan los pasillos del Colegio levantara la cabeza y viera cómo han avanzado los tiempos...
Enlace permanente de imagen incrustada

A continuación, Josep Albors habló del famoso #BadUSB, recordando no lo solo afecta a pen drivers, sino a todo lo que se "pinche": discos externos, cámaras de fotos, etc. Entre las diversas maldades que pueden llegar por un puerto USB se encuentran: la suplantación de firmware (hacer ver al ordenador que lo que se pincha es un teclado, para que acepte los comandos que le envíe), falso eth0 (envía datos del equipo a una red controlada por el atacante); y, además, presenta persistencia: se infecta la controladora y, mediante ella, todo lo que se pinche después por eso puerto.

Aunque hay varias compañías afectadas, no considera que sea grave, salvo en el caso de ataques dirigidos. Y la mejor manera de protegerse es desactivando las actualizaciones de firmware.

Posteriormente, el CCN presentó una ponencia sobre las comunicaciones móviles seguras: recordando que código abierto no es equivalente a verificado, porque el examen del mismo es complejo; además, algunos dispositivos vienen con configuraciones de fábrica que los hacen vulnerables (como permitir que se asigne una zona de memoria no segura como segura). Guardar un documento importante en la nube, recurriendo a la autenticación en dos pasos, es un arma de doble filo, ya que quien consiga romperlo, sabrá además a qué persona (móvil) pertenece dicho documento.

Para terminar, mencionó algunas aportaciones del CCN en la seguridad móvil, como el nuevo terminal Tutus, las aplicaciones CCNDroid de borrado y cifrado y próxima aparición de una nueva guía para la arquitectura de referencia.

La última ponencia del módulo 2 corrió a cargo de Arbor Networks y versó sobre cómo mitigar los ataques de DDoS con ayuda de la operadora. Quedó claro que defenderse de un ataque volumétrico no es posible sin la ayuda de la operadora (con un centro de mitigación), pero sí es posible detectar y protegerse de los ataques de agotamiento de conexión. Por otra parte, el tráfico que venga cifrado siempre se tiene que parar en casa, con un dispositivo conectado en linea.

Logstalgia es una utilidad que te permite ver los log de acceso a tu servidor como si fueran una pantalla de arcade. Ayuda a localizar gráficamente los ataques de DDoS.

Tras el café, y de nuevo en la sesión plenaria, pudimos ver cómo Juan Garrido se daba un paseo por el directorio activo del Departamento del Tesoro yanqui con ayuda del Softerra LDAP browser. Y es que, la configuración por defecto del directorio activo de Windows, que se basa en ACL, concede permiso de lectura a usuarios sin privilegios. Navegando y googleando se puede encontrar información bastante interesante sobre los trabajadores. Incluso aunque las passwords de los usuarios estén cifradas, se pueden obtener sin mucha dificultad, ya que MS, por política de transparencia, publica un documento con la clave para descifrar las políticas de grupo.

Localizando al que imprime los billetes

Tras la mesa redonda "¿Qué aportan los proveedores de servicios e integradores a la Ciberseguridad Nacional?", vino la última ponencia, a cargo de ya habitual en estos saraos, Raul Siles que volvió a hablar, como en eventos anteriores, del problema de "congelación" de las actualizaciones iOS que, al parecer, Apple ha resuelto pero no del todo: si modifico la fecha de mi última actualización, poniéndola en un momento posterior a la verdadera, pero inmediatamente anterior al presente (y no del futuro, como hacía anteriormente), el ataque de Regreso al futuro sigue siendo posible. Y mientras Apple no lo arregle del todo (¿habrá un regreso al futuro III?), aquí nos quedan las sugerencias de Siles para protegernos (quien, como podemos ver, tampoco está de acuerdo con la definición de hacker dada por la RAE):


Y con esto y la clausura quedaron terminadas las octavas Jornadas STIC. ¿Queréis saber algo de lo que sucedió en los otros dos módulos? Pues, aunque no asistí a todo personalmente, de algo sí pude enterarme. Os lo cuento en la próxima entrega.

#8JornadasCCN_CERT Crónica (II)


Enlace permanente de imagen incrustada

Continuamos la crónica dando cuenta del resto de las ponencias presentadas en el módulo 2 "Nuevas amenazas, herramientas y tecnologías".


La primera fue una demo basada en el proyecto de fin de carrera de José Vila, dirigido por Ricardo Rodríguez, sobre ataques de relay en tarjetas EMV NFC con dispositivos Android:

Las comunicaciones NFC tienen un alcance práctico de 10m (20 teóricos) y pueden establecerse de manera pasiva (hay un terminal que la inicia con superior potencia) o activa (tanto el receptor como el emisor generan su propio campo NFC. El estandar de comunicación está recogido en la norma ISO 1443 que se compone de cuatro partes. Sin embargo, es solo una recomendación y no todas las tecnologías que implementan NFC lo cumplen por completo. Por ejemplo, MIFARE, ampliamente utilizada en las tarjetas contactless, solo cumple con las tres primeras y, por lo tanto, es vulnerable. Como quizá sepáis, estas tarjetas permiten el pago de hasta 20€ sin introducir un pin de seguridad y dicha operación puede realizarse hasta cierto número de veces, aunque no sin límite. Esto permite que alguien con acceso a nuestra tarjeta pueda hacer compras e incluso quedarse con los datos de la misma (excepto el CV), ya que viajan en claro.

¿Te consideras seguro si no hay un datáfono a menos de 10m de tu tarjeta? Pues los ponentes demostraron que el ataque puede hacerse a más distancia utilizando un terminal que haga de proxy y con una aplicación android llamada NFC Leech, que se puede instalar en cualquier terminal sin rootear, con versiones 4.4 o superior. Es suficiente con que un móvil que esté a menos de 10m de la tarjeta de la víctima se conecte (mediante wifi o bluetooth) con otro que esté cerca del datáfono. La complejidad del ataque puede incrementarse para incluir más terminales y saltos en el camino que dificulten el rastreo.

Enlace permanente de imagen incrustadaLos ataques de relay se realizan en el nivel 2 de OSI, por lo que todas las medidas de seguridad que implementemos en capas superiores no sirven. ¿Lo mejor para protegerse? Una mini jaula de faraday. En muchas tiendas venden billeteros a tal a efecto. Hasta ahora yo utilizaba el método casero del papel albal. Pero dejadme que os enseñe qué es lo que llevo ahora (cortesía de S2 Grupo): 

¡Hasta Félix Sanz tiene una! 

Despues, continuaron Alfonso Muñoz y Sergio de los Santos que nos hablaron de las técnicas de correlación utilizadas en su herramienta Path5 para detectar malware en las apps Android y presentaron un caso de estudio hecho para la botnet Shuabang. Un cosa interesante que aprendí es que no es cierto que a más permisos, más malware: una gráfica realizada con la herramienta mostraba que la mayoría de las apps maliciosas solo tenían cinco. El análisis del lenguaje natural (en la descripción de la app) resultaba más eficaz para detectarlas.

Posteriormente salió Jaime Sánchez (no en camisa, sino con jersey; es verdad que en la sala hacía fresquete) para hablarnos del famoso #ShellShock. Lo cierto es que es mucho lo que se ha hablado ya del tema desde que salió. Pero Jaime nos hizo un buen repaso de los distintos tipos de ataques que se pueden realizar aprovechando dicha vulnerabilidad. Un par de cosas que mencionó que me parecieron interesantes fueron que la mayoría de los ataques detectados parecían venir de Estados Unidos y, sobre todo, la pregunta que lanzó: ¿habéis revisado los logs para comprobar que no habéis sido víctimas del ataque antes de que saliera a la luz y lo parchearais? Me quedé con ganas de preguntarle por el #Winshock; pero como sabía que el horario era muy ajustado...

Enlace permanente de imagen incrustada
Jaime con su jersey, Ghost in the Shell

Y después, Abraham Pasamar desmitificando el AntiVirus. Con el debate existente sobre si los antivirus sirven o no para algo, ante la pregunta "¿debemos instalar un antivirus?" Abraham responde con un claro "Sí". Pero, teniendo en cuenta que tampoco son la panacea. ¿Por qué? Porque pueden evadirse y, de hecho, se evaden. Lo hicieron en Incide (no confundir con Incibe) y su CEO nos mostró cómo lo hicieron, cocinando un Crypter FUD y haciendo pruebas repetidas, hasta que ningún AV lo detectaba:

Como muchos AV escanean los binarios del disco correspondientes al proceso que está en memoria, se puede utilizar una técnica de Dynamic Forking para colocar el virus en una zona de memoria utilizada por un proceso legítimo y que pase desapercibido. Por otra parte, para evadir los sistemas de heurística de los AV, utilizaron una exhausting routine, que, básicamente, consiste en cansar al AV, haciéndole analizar un trozo de código inocuo que dura mucho, para que asuma que todo lo demás es bueno y no siga analizando.

Si queréis saber más sobre AV, encoders, packets, crypters, stubs y demás, tenéis una muy buena serie de artículos escritos por Abraham en SbD. Yo aprendí mucho con ellos.

Y hasta aquí todo lo relativo a las ponencias del módulo 2 del primer día. Continuará...

#8JornadasCCN_CERT Crónica (I)


Enlace permanente de imagen incrustada
Queridos lectores,

Un año más hemos tenido el placer de asistir a las Jornadas STIC, organizadas por el Centro Criptológico Nacional. Os recomiendo descargar la documentación cuando esté disponible en la web. Mientras tanto, haré lo mejor que pueda por resumíroslas, para que tengáis un adelanto.

En esta edición, el CCN-CERT nos ha sorprendido con dos novedades: la primera es ¡su salida a Twitter! (algunos ya lo estábamos deseando). Como se deduce del nombre (Jornadas CCN-CERT), el propósito de la cuenta es dar información sobre las mencionadas Jornadas; y así lo han ido haciendo antes y durante el evento. El tiempo dirá si la siguen usando para más cosas relacionadas con el organismo.

La otra ha sido la división del programa en tres módulos simultáneos, a elegir, que complementaban la sesión plenaria, cada uno centrado en un tema diferente: 1- Ciberespionaje / APTs. 2 - Nuevas amenazas, herramientas y tecnologías. 3 - Estrategia de ciberseguridad. ENS y cumplimiento normativo. La elección era difícil porque todo parecía muy interesante, pero me decanté por el 2.

Enlace permanente de imagen incrustadaMás de mil personas nos hallábamos reunidas en el Gran Anfiteatro del Ilustre Colegio Oficial de Médicos de Madrid, para la inauguración del acto por el SED del CNI-CCN, Félix Sanz.


Tras lo cual, se presentaron las principales novedades del CCN-CERT y se hizo un repaso de la gestión de incidentes en 2014: habrá nuevas guías, nuevos cursos y un nuevo diseño del portal. ¿Recordáis hace poco la noticia sobre los estragos que estaba causando TorrentLocker? Pues, desgraciadamente, también quince organismos públicos se han visto afectados. Otro que ha causado muchos dolores de cabeza ha sido el "Snake / Uroboros / Turla", que han perseguido con la herramienta Carmen, de la que os hablaré posteriormente.

A continuación, David Barroso nos habló de la persistencia en BIOS: dónde pueden esconderse los "bichos". Para mi gusto, hizo un estupendo resumen sobre el funcionamiento de la BIOS y, desde que apareciera en el 2000, la EFI y las distintas capas de ejecución donde puede esconder el malware. El problema de los bootkits es que no dejan trazas en disco, sobreviven a la reinstalación del S.O. y casi ningún AV mira en la BIOS/UEFI. Hablando de AV, ojo: porque algunos AV chinos instalaban drivers maliciosos en el bios.sys para acceder a esa zona de memoria.



Enlace permanente de imagen incrustada
El tipo de ataque va a depender del modelo del fabricante, aprovechándose, muchas veces, de fallos en el diseño; dándose también el caso de que algunos equipos venían infectados de fábrica (¿verdad que no nos sorprende?). Muchos de los ataques se realizan al módulo SMM, infectándolo con tablas ACPI maliciosas.

Otra posibilidad es infectar la PCI expansion ROM, en vez de a la propia BIOS y que el bootkit se cargue cuando ésta lo arranque. Como protección contra los bootkits, que se ejecutan después del arranque de la BIOS, el sistema UEFI implementa el Secure Boot, que comprueba que el código de arranque no haya sido modificado, sirviéndose de la firma digital.

¿Es entonces la UEFI la panacea para los problemas de seguridad de la BIOS? Llegados a este punto, me permitiréis que de un salto a la última ponencia del día en el módulo dos, en la que un miembro del CCN ofreció más explicaciones sobre el funcionamiento de la UEFI. Así guardamos la coherencia lógica, aunque no cronológica:

¿Por qué es la UEFI un arma de doble filo? porque ofrece ventajas al defensor (implementa mecanismos adicionales de seguridad, la estandarización favorece un buen conocimiento del sistema y control del soft instalado...), pero que pueden ser también aprovechadas por un atacante: es más fácil meterse en el código (los punteros a funciones facilitan la labor del atacante), se puede hacer en C, es más fácil añadir un driver DXE malicioso en el módulo NTFS que hacerlo en el MBR/VBR, el formato es PE, hay una mayor superficie de ataque porque se complementa la ACPI con distintos módulos de código según el tipo de arranque.


La firma digital utilizada por Secure Boot no es de tipo PKI. La NVRAM se puede flashear a disco con la herramienta fptw64 o copiándola por hardware, modificar y firmar con las claves que vienen por defecto de fábrica. Se recomienda usar TPM para almacenar la claves y mejorar así la implementación del SecureBoot. También, utilizar la herramienta Copernicus para gestionar la UEFI de un parque informático.

Ya hay ataques especificamente diseñados para UEFI, pero su complejidad y la necesidad de acceso físico a la máquina hace que sean más de temer los propios insiders contra un objetivo escogido, que un "bicho" venido de fuera que se propague por la red.

Espero que os haya parecido tan interesante como a mí todo lo hasta aquí expuesto. Para no cansaros mucho, voy a continuar con el resto del resumen de las jornadas en próximas entregas.


04 diciembre 2014

Correos con TorrentLocker y otros "regalitos"




Desde al menos ayer se está alertando por un envío masivo de falsos correos que simulan provenir de la Sociedad Estatal de Correos y Telégrafos. El propósito es llevar a los usuarios a descargarse una variante del ransonware TorrentLocker que cifra los archivos del equipo afectado y sus unidades de red. Por el momento no se conoce el método de desinfección.

En la página del CSIRT-CV podéis ver un resumen de cómo funciona y las pantallas que saca:

Para prevenirlo, es recomendable bloquear el acceso a los siguientes dominios:

correos24.net
correos-online.org
chooseyourhost.ru

Snort también detecta como maliciosas las peticiones a las IP del tipo 46.161.30.*


Como en otras ocasiones, el equipo de SecuritybyDefault ha sido el primero en dar la voz de alarma. Gracias también a Maite por sus aportaciones. Yo me limito a resumir lo que ido recopilando y retuiteando; para que, viéndolo aquí todo junto resulte más fácil si alguien no estaba al tanto.

Curiosamente, el periodista Brian Krebs también advierte de una campaña de malware que llega como una pretendida confirmación de envío de un paquete. Aunque, en este caso, no se trata de un ransonware, sino del Asprox spam botnet, que intenta quedarse con nuestras contraseñas y convertir nuestro equipo en un zombi; pero, al menos, no cifra su contenido. Al parecer, la campaña empezó por Acción de Gracias.

Por lo anterior, parece que los malos aprovechan que es una época de compras, cuando la gente espera recibir paquetes, para enviarnos un regalo envenenado.

Actualización:

En la nota actualizada del CSIRT-CV nos informan de que está misma campaña de #TorrentLocker  se está dando en otros países, como Holanda e Italia.

Por otra parte, en Security by Default piden a todos aquellos que hayan podido ser afectados que colaboren dando detalles (de forma anónima) para facilitar la investigación de lo que han dado en llamar el #CorreosGate. Tratan de localizar el posible origen del hackeo de listas de correo; ya que, en muchos casos, está llegando a cuentas corporativas que la gente suele usar para registrarse en sitios en los que confía.

Actualizo también las referencias más abajo con un par de apuntes técnicos de INCIDE y Fox It


Seguiremos informando. Toda la actualidad en Twitter: #TorrentLocker

Referencias:

17 noviembre 2014

Sobre este blog y vosotros

Hace mucho que no escribo. La verdad es que he estado muy liada con muchas cosas: buenas y malas. Entre las cosas buenas que me han sucedido últimamente y que tienen relación con la temática de este blog ha estado el estupendo Curso de Especialidades Criptológicas del CCN. En el se trató de todo: recuerdos de las viejas historias que leía cuando era niña sobre tesoros escondidos, mensajes secretos y detectives; se habló de la máquina Enigma, utilizada en el espionaje de la Segunda Guerra Mundial y de los métodos más modernos de cifrado (en flujo, en bloque, clave simétrica, asimétrica...), hasta de la criptografía cuántica. Tres semanas intensas.

    
Tengo que agradeceros a todos los que os acercáis a este blog buscando aprender de seguridad. Yo aprendo con vosotros. Podéis leer mis tuits, mi periódico o los blogs que referencio en éste y seguro que aprendéis más aún. En general, utilizo el blog para contar cosas para las cuales un tuit se me queda corto o para dar mi visión personal sobre asuntos y acontecimientos. Pero considero innecesario repetir lo que está contado en otro lugar (y, posiblemente, mejor). Al menos aquí no encontraréis salidas de tono ni nada que piense que puede ofender a nadie. Vosotros sois los que habéis dado valor a este blog (que empecé más en broma que en serio), honrándolo con vuestras lecturas. Yo solo espero poder estar a la altura. Pretendo seguir haciendo aportaciones interesantes y trataré de hacerlo más a menudo. También quiero empezar a escribir en inglés. Pero no prometo nada.

De momento, os emplazo para nuestra próxima cita: os haré una crónica de las VIII Jornadas STIC del CCN. Esas jornadas a las que muchos quisieran asistir pero no pueden. Una buena razón para volver a encontrarnos aquí. No faltéis. Os espero.

25 septiembre 2014

Vulnerabilidad grave en la Shell (#Shellshock)


Anoche, cuando estaba a punto de irme a dormir, se me ocurrio darle un último vistazo a Twitter y me encontré con esto:

Un artículo haciéndose eco de una grave vulnerabilidad en la shell (intérprete de comandos) de Linux/Unix/OSX. (Así es que, con Windows, todos tranquilos).

A estas alturas del día, es muy posible que ya hayais oído hablar de ella y hasta es posible que haya salido o vaya salir en los telediarios, como ocurrió con #Heartbleed.

El caso es que dicen que es muy grave y fácil de explotar. Aunque, en el momento de redactar este post, aún no se conocen exploits "in the wild". En principio, afectaría a servidores que usen CGI con la shell de Bash. Pero en esto no hay consenso: hay quien lo ha probado con ksh y le ha funcionado igual y he leído también que no es solo CGI.

En cualquier caso, os lo resumo un poco y os doy algunas referencias, por si queréis saber más (y, como siempre, twitter para estar a la última):

El intérprete de comandos bash permite exportar la definición de funciones de una shell padre a shells hijos, asignándolas a una variable de entorno, que envía al parseador antes de que se ejecute el programa principal en la shell hija.

El problema viene cuando, dentro de la asignación de la variable, tras la definición de la función se añade un comando cualquiera. En vez de dar error, al enviarlo al parseador, el comando se ejecuta. Ahí se puede meter de todo; y, por lo visto, permite la escalada de privilegios.


Una sencilla linea de comandos permite hacer la prueba:

$ env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"

Enlace permanente de imagen incrustadaSi la ejecución devuelve:

vulnerable
this is a test

Significa que la shell es vulnerable. 





He encontrado una muy buena explicación del asunto en el blog de lcamtuf (en inglés).

Ya están actualizando las distros más conocidas. Pero ¿qué pasará con el Internet de las cosas y los sistemas embebidos. Varias cosas usan Linux, están conectadas a internet y no se parchean tan a menudo. Supongo que es también por eso que dicen que nos encontramos ante una vulnerabilidad peor que #heartbleed. Otra razón es que con #heartbleed un atacante podía espiar, pero nunca ejecutar cosas en nuestro equipo. 

Se han asignado dos CVS (CVE-2014-6271 / CVE-2014-7169) porque los parches de la primera no lo corrigen totalmente. Recomendación para administradores: actualizar y, cuando el nuevo parche esté publicado, volver a actualizar.

Un ejemplo de cómo se podría explotar, lo podéis ver en el blog de Elevenpaths.

Y, por lo visto, también hay quien se dedica ya a escanear internet en busca de equipos vulnerables.

En fin, veremos en qué queda todo.

Actualización (03-oct): ¿Windows tampoco se salva de estas cosas?


https://twitter.com/FioraAeterna/status/517791046835920897/photo/1

Más referencias: