Gonzalo Álvarez Marañón En Internet nadie sabe que eres un perro ni aunque uses certificados TLS Te habrás fijado en que la mayoría de las páginas web llevan un candadito. Si haces clic en él, aparecerá una ventana que afirma que “la conexión es segura”....
ElevenPaths Boletín semanal de ciberseguridad 13-19 febrero Vulnerabilidad de elevación de privilegios en Windows Defender El investigador de SentinelLabs Kasif Dekel ha descubierto una nueva vulnerabilidad en Windows Defender que podría llevar activa más de doce años....
ElevenPaths Noticias de Ciberseguridad: Boletín semanal 14-20 de noviembre Campaña de distribución de malware suplanta la identidad de ministerios españoles Investigadores de ESET alertan de la existencia de una campaña de distribución de malware en la que se estaría...
ElevenPaths ElevenPaths de Telefónica refuerza sus capacidades de seguridad en IoT global con Subex Esta colaboración ofrece la detección de amenazas en IoT, un servicio de vigilancia y respuesta a incidentes en entornos de IoT.Esta solución tiene la capacidad de aprender y modelar...
Gonzalo Álvarez Marañón En Internet nadie sabe que eres un perro ni aunque uses certificados TLS Te habrás fijado en que la mayoría de las páginas web llevan un candadito. Si haces clic en él, aparecerá una ventana que afirma que “la conexión es segura”....
ElevenPaths Boletín semanal de ciberseguridad 13-19 febrero Vulnerabilidad de elevación de privilegios en Windows Defender El investigador de SentinelLabs Kasif Dekel ha descubierto una nueva vulnerabilidad en Windows Defender que podría llevar activa más de doce años....
Yaiza Rubio La atribución es sexy pero, ¿para quién es relevante? Resolver la autoría de un ataque es una pregunta que todo analista quiere contestar. Sin embargo, nos encontramos ante una situación en la que los atacantes cada vez más...
ElevenPaths IcoScript, el malware con un sistema de comunicación más que curioso IcoScript es un RAT (sistema de administración remota) descubierto en agosto por G-Data más o menos normal… excepto por su forma de contactar con su servidor y recibir órdenes. La...
Área de Innovación y Laboratorio de ElevenPaths ElevenPaths pasa a formar parte del Atlas de Ciberseguridad de la Comisión Europea El Área de Innovación y Laboratorio de ElevenPaths ha sido incluida como como parte del Atlas de Ciberseguridad de la Comisión Europea, una plataforma de gestión del conocimiento que...
Gonzalo Álvarez Marañón En Internet nadie sabe que eres un perro ni aunque uses certificados TLS Te habrás fijado en que la mayoría de las páginas web llevan un candadito. Si haces clic en él, aparecerá una ventana que afirma que “la conexión es segura”....
Gonzalo Álvarez Marañón Eres menos racional de lo que crees cuando tomas decisiones de riesgo en condiciones inciertas Te propongo el siguiente juego de azar: Opción A: Te doy 1.000 € con un 100 % de probabilidad Opción B: Lo echamos a suertes: si sale cara, te doy 2.000...
ElevenPaths ElevenPaths Radio – 1×10 Entrevista a Ramón López de Mántaras En este episodio hablamos con Ramón López de Mántaras, director del Instituto de Investigación en Inteligencia Artificial del CSIC, pionero de IA en España.
¿Cómo trata (o tratará) Certificate Transparency la privacidad de los dominios?… MalElevenPaths 26 marzo, 2018 Primero fue octubre de 2017 y después abril de 2018, aunque ahora parece que va en serio. Certificate Transparency será obligatorio en Chrome. ¿Están preparados los actores? Respuesta corta: no. Y algo muy importante no resuelto es qué ocurre con la privacidad de los dominios. Tema espinoso que intentamos aclarar. Antes de empezar, recordad qué es eso de Certificate Transparency. Ya era improbable que estuvieran listos todos los “actores” para octubre. Lo confirmó la propia Google con la “patada hacia adelante” anunciada hasta abril de 2018. En la Rooted de Valencia de 2017, presentamos una investigación que analizaban todos estos aspectos que parecían justificar el “retraso”. Y no solo eso, en esa investigación, conseguimos pasar desapercibidos para ciertos monitores de Certificate Transparency y “colarnos” en dos logs de confianza. Pero eso no era ni siquiera lo más relevante. Cabeceras como “Expect-CT” diseñadas para prepararse para octubre de 2017 y “entrenar” los certificados y escenarios, no fueron realmente puestas en producción hasta septiembre de ese mismo año… No es mucho margen cuando se supone que servían de entrenamiento para un evento que se lanzaría en octubre, ¿verdad? Igualmente, el código relativo a Certificate Transparency en Chrome parecía estar en desarrollo, con líneas que parecían más a una zona de DEBUG y funciones que siempre devuelven que todo está bien en las cabezas de los logs… Implementación actual en Chrome sobre algunos aspectos de Certificate Transparency que no ofrece demasiada confianza sobre su madurez También quizás resulte curioso saber que existe una versión 2 de la API Certificate Transparency desde hace muchísimo tiempo… que nadie usa todavía, y CT saldrá a producción apoyado principalmente en la primera versión que ya se detectó como obviamente mejorable. Lo curioso es que, hoy por hoy, a pocos días de pasar a producción… siguen así. Quizás no sean vitales, y no impedirán que el funcionamiento sea correcto, pero desde luego no ofrecen justo lo que pretenden: una sólida confianza. ¿Y qué pasa con la privacidad? En el informe que recientemente hemos redactado, se demuestra que se puede mejorar hasta un 10% la fase de reconocimiento de un pentesting gracias a Certificate Transparency. Quizás este no sea el único problema, sino que también se desvelen dominios que no se desean. Nadie espera que sus subdominios privados se almacenen en los logs. Esto no tiene una fácil solución, ni siquiera una fácil explicación de todas las variantes posibles, por ello iremos paso a paso. Certificate Transparency (CT) se basa en probar que el certificado esté incluido (en principio, parece que tres serían suficientes, aunque luego descendieron a dos) en logs de confianza. El navegador deberá hacer su trabajo a partir de abril y no dejar pasar a los certificados que no se encuentren en los logs. Con los certificados con subdominios privados que provengan de CAs privadas incrustadas a mano en el sistema operativo, no habrá excesivo problema. CT no aplica sobre ellas (para estar en los logs, la cadena debe validar sobre las CA de confianza típicas que puede contener y elegir el log). Pero para los dominios “secretos” que vengan de CAs públicas, existe un doble aspecto de privacidad a tener en cuenta. Para el usuario, porque el navegador, para “chivarse” de algún problema en CT, podría enviar el SCT (la prueba de inclusión, falsa o no) del certificado al propio “fabricante” del navegador para que compruebe si algo falla en sus logs. O sea, se podría enviar a terceros la información de por dónde navega el usuario. Esto ya ocurría con HPKP y su “report-uri” pero tampoco es que le dieran demasiada importancia. Para el dueño de los certificados, que acaba publicitando o necesitando incluir en un log dominios con, potencialmente, subdominios que no quiere que sean conocidos. Para paliar estos problemas, se han propuesto soluciones de protocolos sobre las especificaciones actuales de CT, que ni siquiera han sido implementadas por ahora. ¿Entonces, cómo oculto los subdominios? Tema que todo el mundo se pregunta. En noviembre de 2017 todavía se andaba dando vueltas al asunto en discusiones y recontra-argumentaciones públicas de todos los involucrados. Un debate “apasionante” que ha llevado horas y horas de discusión… y todavía sigue sin estar resuelto. De hecho, solo parece existir un draft que aborde el problema, además del RFC, (una tiempo, estuvieron estas ideas incluidas pero se separaron en un borrador aparte). El draft ha expirado a mediados de 2017, y la discusión, como mencionábamos arriba, sigue viva. Las grandes CA ya se planteaban el problema en 2016… ya ofrecían la posibilidad (la más simple de todas) de no incluir por defecto en los logs los subdominios que el dueño no deseara. Pero, por aquel entonces, se temía incluso que Chrome diera por erróneos sus certificados (así lo indicaron públicamente). Desde entonces, el asunto tampoco ha avanzado tanto. De parte de Mozilla, lo más reciente que encontramos es este draft analizando pros y contras de cada solución, pero sin llegar a ofrecer ninguna solución concreta o dirección. En cualquier caso, repasemos desde el punto de vista técnico las propuestas “oficiales” de la IETF para lidiar con la privacidad de los subdominios: Usar wildcard *.ejemplo.com. Obviamente, no es la mejor solución, nunca lo ha sido pero ahora impide el uso de dominios de tercer nivel, por ejemplo, y no sería válido (no lo son por definición) para certificados EV. Revivir y reutilizar un viejo truco que pocos usan: las CA intermedias “limitadas”. Se ha propuesto añadir a este truco un “flag” OID 1.3.101.76 que indique que los certificados emitidos por esta CA intermedia tienen permitido no estar en logs. Para listar dentro del certificado de la CA intermedia cuáles están exentos, además del flag, se utilizarían las extensiones X.509 permittedSubtrees y excludedSubtrees. Funcionan como una especie de wildcards más específicos, con los que se crea una serie de reglas blancas y negras que hay que satisfacer para indicar qué subdominios de un dominio podrían llegar a estar exentos de Certificate Transparency, y ser emitidos por esa subCA. En principio, se usaban antes de CT para limitar el poder de una subCA pero con el flag mencionado se ha pensado que pueden solucionar esto. Por supuesto, aunque buena idea, está lejísimos de ser soportada por los navegadores. Por si tenéis curiosidad, aquí está el código Python para realizar pruebas de estas cabeceras en el motor de Chronium. Esto tiene más complejidad de la que parece ya que luego, esta modificación en los certificados debe venir acompañada de cómo los navegadores entienden y notifican a los logs de esta exención. Ocultar directamente los subodminios en los precertificados. Como sabéis, CT incluye el “precertificado” como método de inclusión del SCT en la petición de firma. Durante este proceso, se podría crear una extensión específica para X.509 que sea redactedSubjectAltName y que tendrá “ofuscado” los dominios. Se trata de “hashear” ciertos dominios e incrustarlos en el certificado y esto es lo que quedaría en los logs. En el certificado real, habría un subjectAltName con el mismo número de dominios en claro, y el cliente (navegador) podría comprobar el hash de cada uno. Por cierto, estaría codificado en base32 y la función de hash está el aire aún, lo que podría ser inseguro por la facilidad que podría llevar un ataque por diccionario, fuerza bruta o por la posibilidad de deducir dominios (suelen tener pocas letras). ¿Os resulta complejo todo esto? En la propia especificación aclaran que todo el ecosistema podría dañarse si se usa mucho esta opción. Certificado de prueba creado por nosotros mismos con las extensiones (poco comunes) de organizaciones con restricciones Pero entonces, ¿qué hago como administrador de certificados? En el aspecto más mundano, leer a fondo no solo esta entrada de blog, sino todas sus referencias para ver cuál de las múltiples posibilidades se ajusta a cada necesidad. Después, escoger alguna de estas estrategias: Implementar CAs propias Usar CAs públicas pero confiar en que no se envíen los certificados con dominios privados a los logs, por ejemplo desactivando en los empleados la función Usar política de wildcards… Armarte de esperanza y/o palomitas y esperar El problema que subyace de fondo, realmente, es que al ocultar subdominios sensibles se pretende y espera en realidad crear una capa de “ocultación” en un sistema transparente por definición. Ahí está la controversia y el problema fundamental del asunto, y precisamente, por tratarse de un problema “radical” y opuesto a la solución inicial, es difícil de solucionar. A todo esto, ya podréis usar nuestro plugin para FireFox (puesto que aunque están en ello, no llegarán a tiempo) que permite comprobar el SCT incrustado en los dominios. Sergio de los Santos Innovación y Laboratorio ssantos@11paths.com @ssantosv GDPR, la importancia de esta nueva normativaLos autores de Wannacry también quieren sus Bitcoin Cash
Área de Innovación y Laboratorio de ElevenPaths ElevenPaths pasa a formar parte del Atlas de Ciberseguridad de la Comisión Europea El Área de Innovación y Laboratorio de ElevenPaths ha sido incluida como como parte del Atlas de Ciberseguridad de la Comisión Europea, una plataforma de gestión del conocimiento que...
Gonzalo Álvarez Marañón En Internet nadie sabe que eres un perro ni aunque uses certificados TLS Te habrás fijado en que la mayoría de las páginas web llevan un candadito. Si haces clic en él, aparecerá una ventana que afirma que “la conexión es segura”....
ElevenPaths Boletín semanal de ciberseguridad 13-19 febrero Vulnerabilidad de elevación de privilegios en Windows Defender El investigador de SentinelLabs Kasif Dekel ha descubierto una nueva vulnerabilidad en Windows Defender que podría llevar activa más de doce años....
Martiniano Mallavibarrena La nueva fuerza de trabajo digital y los riesgos alrededor de la robótica de procesos (RPA) En estos últimos años, son muchas las empresas de distintos sectores que han optado por basar su transformación digital en la automatización de procesos (RPA – Robot Process Automation),...
ElevenPaths ¿Qué es la VPN y para qué sirve? Las conexiones VPN no son nada nuevo, llevan con nosotros mucho tiempo, siempre unidas al ámbito empresarial. La gran versatilidad y sus diferentes usos ha hecho que cada vez...
Juan Elosua Tomé Nueva versión de FARO: crea tu propio plugin y contribuye a su evolución Hoy venimos a presentaros una nueva versión de FARO, nuestra herramienta open source de detección de información sensible de la que ya os hemos hablado en este mismo blog...