ElevenPaths #NoticiasCiberseguridad: Boletín de ciberseguridad semanal 9-13 de diciembre Los ataques y vulnerabilidads más destacados de la última semana, recopiladas por nuestros expertos del Security Cyberoperations Center de Telefónica.
ElevenPaths Qué hemos presentado en el Security Innovation Day 2019: Innovación y diversidad en ciberseguridad (IV) Tras hablar del futuro de las SecOps y la automatización gracias a la IA, presentar varias proyectos innovadores de Start-ups y analizar cómo mejorar la resistencia frente a ataques...
ElevenPaths #CyberTricks de ElevenPaths El pasado jueves, 30 de noviembre, se celebró el Día Mundial de la Ciberseguridad. Desde ElevenPaths hemos redactado un decálogo de #CyberTricks con ciberconsejos de algunos de nuestros expertos: Chema Alonso, Pablo...
ElevenPaths GSMA IoT Webinars dedicado a la Seguridad en IoT: “SIM-ply Secure – Leveraging the SIM to Create a Trusted IoT” El próximo 23 de enero a las 16:00h, la GSMA presenta este webinar de IoT en inglés dedicado a la Seguridad en IoT: “SIM-ply Secure – Leveraging the SIM...
ElevenPaths #NoticiasCiberseguridad: Boletín de ciberseguridad semanal 9-13 de diciembre Los ataques y vulnerabilidads más destacados de la última semana, recopiladas por nuestros expertos del Security Cyberoperations Center de Telefónica.
ElevenPaths Qué hemos presentado en el Security Innovation Day 2019: Innovación y diversidad en ciberseguridad (IV) Tras hablar del futuro de las SecOps y la automatización gracias a la IA, presentar varias proyectos innovadores de Start-ups y analizar cómo mejorar la resistencia frente a ataques...
Área de Innovación y Laboratorio de ElevenPaths ¿Te atreves a descifrar estos archivos secuestrados por un malware? Concurso #EquinoxRoom111 Mientras investigábamos un nuevo ransomware en nuestro laboratorio, hemos detonado la muestra en nuestro sandbox, pero, por accidente, también se ha propagado hacia un sistema algo más crítico. En él estudiábamos los efectos...
ElevenPaths Cybersecurity Shot_Fuga de Información de AEDyR Cybersecurity Shot es un tipo de informe de investigación sobre casos de actualidad relacionados con bases de datos filtradas en la red así con algunas recomendaciones que podrían haberlo evitado. Cada entrega trae...
ElevenPaths #NoticiasCiberseguridad: Boletín de ciberseguridad semanal 9-13 de diciembre Los ataques y vulnerabilidads más destacados de la última semana, recopiladas por nuestros expertos del Security Cyberoperations Center de Telefónica.
Sebastián Molinetti 5 maneras en las que los usuarios crean incidentes de ciberseguridad De acuerdo con la Encuesta del Estado Global de la Seguridad de la Información (GISS) 2018, aunque las empresas están gastando más recursos en ciberseguridad para mejorar sus defensas,...
Sergio De Los Santos Fallo en WhatsApp: a grandes errores, peores conclusiones Los sucesos que ocurren (malos o buenos) nos permiten avanzar y mejorar gracias a las conclusiones, enseñanzas o experiencias que podemos extraer de ellos. Sin aprendizaje, los eventos propios...
ElevenPaths Qué hemos presentado en el Security Innovation Day 2019: Futuro de las SecOps, de la automatización a la Inteligencia Artificial (I) El pasado 13 de noviembre celebramos la VII edición de nuestro evento de innovación en seguridad: Security Innovation Day, ambientado esta vez en el futuro distópico que proponía Blade...
La curiosa historia de la vulnerabilidad “cíclica y programada” en HPKP de FirefoxElevenPaths 3 octubre, 2016 Probablemente esta sea una de las historias más curiosas sobre cómo se ha descubierto un fallo de seguridad, además de un fallo de seguridad en sí mismo de lo más rocambolesco. De cómo se descubrió un problema de ejecución de código en Tor Broswer, que en realidad acabó además en un grave agujero de implementación de HPKP en Firefox tras un proceso complejo que ha desconcertado a muchos especialistas intentando aclarar la situación. Ha pasado desapercibida para los medios, pero merece la pena analizarla. El “no fallo” en Tor Browser Movrcx descubrió un fallo muy peculiar a principios de septiembre. Defendía que había encontrado una fórmula en el que podía ejecutar código en cualquier usuario de Tor Broswer (basado en Mozilla Firefox ESR, la Extended Support Release). Y no por un fallo explotable en el navegador, sino por el propio funcionamiento del ecosistema de Tor. Lo “único” que necesitaba el atacante era disponer de un certificado TLS válido del dominio “addons.mozilla.org”. Esto mitiga mucho el alcance de la vulnerabilidad, y pocos se lo tomaron en serio. Pero aunque parezca complicado, lo cierto es que ese certificado ya fue comprometido en su día por iraníes… Y aun así, si lo que se quiere es espiar qué se hace en la red Tor, definitivamente es algo al alcance de un gobierno. Además, Movrcx no argumentaba el fallo en sí como el problema mayor, sino el hecho de que un simple certificado fuese el requisito más complejo para poder potencialmente ejecutar código en cualquier usuario del navegador Tor. Si el atacante podía controlar la url de actualización haciéndole pensar que era addons.mozilla.org, podría redirigir a la víctima a cualquier web para actualizar El fallo consistía en una cadena de errores, como todo buen problema de seguridad con raíces en los procedimientos y no tanto en el código. Se basaba en que el sistema de actualización de plugins de Mozilla (y de Tor Browser), permitía autofirmar extensiones. Además, Tor Browser pregunta cada 24 horas por una actualización de extensiones de forma automática. Si en un nodo de salida (controlado por el atacante) se consigue redirigir a la víctima a una página que parece ser la de “versioncheck.addons.mozilla.org” (falseada gracias al certificado) y que durante la actualización se descargue una extensión que no es el verdadero NoScript (por poner un ejemplo de plugin que viene de serie con Tor Broswer), este sería validado e instalado de forma totalmente transparente para el usuario. Puede parecer un poco rebuscado porque precisamente para evitar esto están los certificados. El descubrimiento fue criticado no solo por eso, sino porque según los más avispados, no solo necesitaba el certificado para consumar el ataque, sino también romper el pinning del navegador, que es precisamente para lo que sirve (y con lo que demuestra su utilidad). El ataque parecía una farsa, irrealizable. Pero Movrcx no mentía, a él le había funcionado incluso con el pinning activo… y podía demostrarlo. ¿Había otro error en la implementación de pinning? No parecía, porque lo curioso es que avanzado septiembre, en fechas diferentes, el ataque ya no funcionaba a quien intentaba reproducirlo. El pinning lo protegía. ¿Qué demonios estaba pasando? Esto ha mantenido a una serie de expertos indagando durante días. Veamos qué pasaba. El “sí fallo” en el “no uso” de HPKP Muchos vieron un fallo fundamental en la conceptualización del ataque: le funcionaba porque en su entorno obviamente no falsificó un certificado real sino que en el laboratorio había usado una CA introducida a mano como raíz en Tor Browser, y por defecto, Mozilla no pinea certificados metidos por el propio usuario. En la vida real, no hubiera funcionado. Esta función se llama security.cert_pinning.enforcement_level en about:config, que está establecido a 1 en Firefox, o sea, no pinear certificados autointroducidos por el usuario. Pero ya nos estábamos equivocando. Tor Browser es Firefox fortificado, y en Tor, security.cert_pinning.enforcement_level está por defecto a 2… pinear siempre. El ataque no tenía que haberle funcionado ni en real ni en laboratorio. ¿Qué pasaba? Compilaron Tor Broswer para ver si tenía algún error al detectar CA propias o ajenas, muchos expertos comenzaron a lanzar teorías… O bien creían la versión de Movrcx o bien no le daban la mayor importancia al ataque. Pero algo no cuadraba… y algunos se quedaron investigando. Finalmente, se desveló un dato curioso: este fallo podía ser cíclico y funcionar durante ventanas de tiempo cambiantes y cada cierto tiempo. Por ejemplo, el ataque sería posible durante algunos días de noviembre en el futuro, o durante 35 días desde diciembre a enero de 2017. Como decía Ryan Duff.. una vulnerabilidad “programada” ya de por sí tiene interés. La raíz del problema Lo que pasaba es que addons.mozilla.org. no utiliza HPKP para pinear su certificado. Usa algo mucho más estático: en cada nueva publicación de Firefox, incrusta el pin en el código con fecha de caducidad. Esto tiene sentido porque así no tiene que recogerlos la primera vez del servidor (están “preloaded”), y esto nos alivia el problema de que esa primera vez que se recogen los pines, exista un hombre en el medio. Los pines, tanto de HPKP como incrustados, tienen que caducar. Si no, se corre el riesgo de que sean comprometidos, deban ser reemplazados, y el navegador que los recuerda nunca los olvide. Ante el miedo a que un usuario no pueda acceder a una página porque por una emergencia el servidor ha cambiado el certificado y el navegador recuerda otro, se utilizan periodos de caducidad relativamente cortos. Si algo pasa, al menos la ventana de tiempo del problema se minimiza. También se corre el riesgo de que un usuario que no actualiza su Firefox (entre otros problemas de seguridad que asume al no hacerlo), pierda acceso al final hacia el sitio donde quiera ir porque nunca renovaría su certificado. En resumen, un pin caducado, deja de tener efecto. Así que es buena idea que caduquen pero… ¿cuándo es lo ideal? ¿cuándo deben caducar los pines incrustados de una página esencial de Firefox y controlada por ellos mismos? Muy sencillo: al menos hasta que aparezca la siguiente versión de Firefox con una nueva fecha. De lo contrario, el pinning no tendrá efecto desde la fecha de caducidad hasta que el navegador sea actualizado. Y aquí es donde justa y sorprendentemente fallaron todos los controles de Mozilla. Por ejemplo (y son datos reales), Firefox ESR 45.3.0 salió el 2 de agosto con la caducidad de los pines incrustada para el 3 de septiembre. Firefox ESR 45.4.0 no salió hasta el 20 de septiembre… así que del 3 de al 20 de septiembre, para todo usuario de Firefox ESR 45.3 y 45.4 (y Tor Browser) incluso actualizando el mismo día, los pines no eran efectivos. Justo en el periodo en el que Movrcx realizó sus pruebas. Simplemente no se hacía certificate pinning. Tor Browser sigue los pasos de las releases ESR de Mozilla y por tanto… Movrcx tenía razón, y sus escépticos detractores que hicieron pruebas más tarde… también. Conclusiones Mozilla ha reaccionado rápido y bien. Una de las contramedidas ha sido no depender solo de pines estáticos, sino introducir HPKP para que el pineo sea también dinámico. Gracias a la extensión de Firefox PinPatrol podemos comprobarlo, además de ver en claro cuándo expiran los pines, por si existiera algún otro problema… (Mozilla sigue sin dar una interfaz a este tipo de datos almacenados en el navegador). Mozilla ha añadido pines HPKP a muchos de sus dominios y subdominios, aunque estuvieran también incrustados en el navegador Ivan Ristic planteaba curiosamente a principios de septiembre una pregunta: “¿Está HPKP muerto?”. Su argumentación es impecable, pero no creo que sea la conclusión adecuada. HPKP es útil, necesario y realiza su cometido. La mayor parte del problema, decía curiosamente, está en que los administradores no conocen qué políticas aplicar para desplegarlo. También en cómo lo implemente cada cliente (sobre esto presentaremos una investigación de ElevenPaths sobre HPKP y HSTS en la Cryptology and Network Security Conference 2016 en Milán en noviembre.). Con este fallo se demuestra que HPKP está vivo (ha resuelto un problema y prevenido un ataque) pero que como suele ocurrir, efectivamente es necesario entender el protocolo o de lo contrario, no servirá de nada. Pero esto ocurre con HPKP y cualquier otra medida de seguridad que se nos ocurra. Sergio de los Santos ssantos@11paths.com @ssantosv Participating in GSMA Mobile 360 LATIN AMERICAElevenPaths Talks: Malware en medios de pago no tradicionales
ElevenPaths #NoticiasCiberseguridad: Boletín de ciberseguridad semanal 9-13 de diciembre Los ataques y vulnerabilidads más destacados de la última semana, recopiladas por nuestros expertos del Security Cyberoperations Center de Telefónica.
ElevenPaths Qué hemos presentado en el Security Innovation Day 2019: Innovación y diversidad en ciberseguridad (IV) Tras hablar del futuro de las SecOps y la automatización gracias a la IA, presentar varias proyectos innovadores de Start-ups y analizar cómo mejorar la resistencia frente a ataques...
Área de Innovación y Laboratorio de ElevenPaths A la caza del replicante: caso de uso de CapaciCard en el Security Innovation Day 2019 Descubre cómo funciona CapaciCard, nuestra tarjeta con propiedas capacitivas, con este caso de éxito del Security Innovation Day ambientado en Blade Runner.
ElevenPaths ElevenPaths Radio – 1×13 Entrevista a Pilar Vila Todo lo que rodea a la figura del perito informático forense en esta entrevista en formato podcast con Pilar Vila, CEO de Forensics&Security.
ElevenPaths #NoticiasCiberseguridad: Boletín de ciberseguridad semanal 2-6 de diciembre Segunda edición de nuestro boletín semana del noticias sobre ciberseguridad. Los ataques y vulnerabilidades más relevantes, analizadas por nuestros expertos del SCC: Strandhogg: vulnerabilidad en Android que permite obtener credenciales...
ElevenPaths Qué hemos presentado en el Security Innovation Day 2019: Mejorando la resistencia entre ataques distribuidos de denegación de servicios (III) La última edición de nuestro evento de innovación en ciberseguridad: Security Innovation Day, dio para mucho. En esta serie de posts analizamos los temas tratados, tras explicar qué se...