Para qué sirve el Attack Surface Reduction en EMETElevenPaths 16 junio, 2014 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. Pero Java no es el único culpable de las vulnerabilidades a través del navegador. EMET incorpora ahora una interesante funcionalidad llamada Attack Surface Reduction (ASR) que puede suponer una importante mejora para la seguridad de, no solo Internet Explorer en particular, sino de cualquier programa en general. El origen de la idea Hoy por hoy, el problema con los exploits no se encuentra tanto en los navegadores como en los plugins que utilizan. Suelen ser los culpables de los graves problemas de ejecución de código arbitrario con solo visitar una web. Es cierto que cada cierto tiempo, se encuentran nuevas vulnerabilidades que permiten ejecutar código en el sistema por culpa del navegador en sí, pero incluso para llegar a esta fase, deben eludir ciertas medidas de seguridad. Y para eludirlas se apoyan en los plugins. Por ejemplo, para conseguir eludir ASLR es común utilizar librerías de plugins comunes (Flash, por ejemplo) para «orientarse» en memoria y ejecutar un exploit de forma eficaz en el sistema. O a veces, ocurre que se actualiza el navegador, pero no los plugins asociados. La exposición del usuario sigue existiendo entonces. Pero, por mucho que se aconseje su desactivación, no se puede pretender vivir sin algunos plugins. Las páginas legítimas los necesitan. Así que es necesario utilizar herramientas que permitan crear listas blancas o negras. Y ni aun así se estaría bien protegido. Algún atacante podría perpetrar ataques de tipo watering hole, esperando intentar explotar una vulnerabilidad en una web de uso habitual pero comprometida. ¿Pero no se podía ya evitar los plugins desde las zonas de internet Explorer? No era fácil. En varias ocasiones se demostró que las opciones que parecían lógicas para evitar la ejecución de Java en el navegador, no conseguían de verdad deshabilitarlo en todas las circunstancias. También estaban los kill bits… pero eran difíciles de activar, y no dejaban de estar pensados como sistemas de mitigación. Aunque en los últimos tiempos, muchas de las actualizaciones de seguridad de Microsoft se dedicaban activamente a activar los kill bits de plugins para el navegador permanentemente. Sentadas estas bases, aparece Attack Surface Reduction en EMET para intentar evitar que cualquier programa sea capaz de cargar cualquier plugin, desde sus fundamentos: impidiendo las llamadas a librerías DLL. EMET al rescate Attack Surface Reduction es una nueva funcionalidad de EMET, introducida en su versión 5. Si EMET comenzó como un proyecto para detener los «trucos» usados por atacantes para hacer que funcionasen los exploits, (bloquear los intentos de eludir DEP, ASLR, y otros métodos comunes de explotación) desde hace algún tiempo ha crecido en funcionalidad y potencia: Ya es también una herramienta de certificate pinning para Internet Explorer Es además un sistema de bloqueo selectivo de plugins y DLLs para programas… aunque todavía le queda mucho que mejorar, esto es el ASR. Cómo funciona Visualmente, se debe marcar la opción en el panel de EMET para un programa concreto. Hay que pensar en ASR como un sistema que impide que un proceso cargue ciertas DLL, OCX o cualquier complemento, lo que pueda dar más juego del que en principio se piensa. En esta pantalla se le indica a EMET que vigile un proceso con ASR Luego será necesario ir al registro, y configurar a mano los módulos que se quieren bloquear. La organización habitual de EMET consiste en asignar un CLSID aleatorio a una aplicación. Dentro de ella, la rama contendrá la configuración específica. Se encuentra en HKEY_LOCAL_MACHINESOFTWAREMicrosoftEMET_settings_. Ahí se creará una rama con el nombre del programa y su CLSID. Más arriba (por encontrarse en orden alfabético) se podrá comprobar que existe otra rama con ese mismo CLSID y la configuración correspondiente al programa en su interior. Por ejemplo la de Internet Explorer será: Configuración interna de ASR para Internet Explorer en EMET Ahí se encuentran la cadena «ASR» (con valor 1 si se ha activado en el panel gráfico de EMET) y «asr_modules». Esta puede contener, separados por «;», los módulos que no se quieren cargar cuando se ejecute el programa. EMET ya viene configurado de forma predeterminada con la opción de impedir que Internet Explorer cargue npjpi*.dll, jp2iexp.dll, vgx.dll y flash*.ocx. Pero solo en las zonas 1, y 2, que se corresponden con Local (0), Intranet (1), Sitios de confianza (2), Internet (3), Sitios no confiables (4). O sea, el valor «asr_modules» mantiene una lista de librerías que están prohibidas para ese proceso, mientras que para Internet Explorer, existe el valor «asr_zones» que marca las excepciones según las zonas. Es mejor ver la imagen para entenderlo. Las librerías prohibidas de forma predeterminada son: npjpi*.dll y jp2iexp.dll: Relacionadas con Java. vgx.dll: El procesador de gráficos de vectores VML flash*.ocx: Flash. Así, la configuración por defecto permitiría estas tres tecnologías en las zonas de confianza e internet y las bloquearía en el resto. Sería posible eliminar o añadir tecnologías bloqueadas y hacerlo más granular añadiendo dominios a las zonas tradicionales. Para Office (o cualquier otro programa), es más sencillo aún, porque no se ofrece el concepto de zonas de bloqueo («asr_zones»). Así, por ejemplo solo se indica que a Word se le prohíbe cargar Flash en su interior (con «asr_modules»). Esta es la configuración por defecto: Configuración interna de ASR para Word en EMET Cuando el navegador intente activar una web con un plugin (Flash en el ejemplo) que cae sobre la zona correspondiente y bloqueada, aparecerá un mensaje de este tipo en EMET. Pero esto puede llevarse a cabo con cualquier programa. Lo que abre la posibilidad de bloquear selectivamente la carga de DLLs en cualquier proceso. Sergio de los Santos ssantos@11paths.com @ssantosv Orientando el pentesting hacia un ataque APT: Correos electrónicosLa seguridad en los métodos HTTP
Carlos Rebato Criptografía, una herramienta para proteger los datos compartidos en la red Actualmente, la Ciberseguridad representa un aspecto primordial en las empresas. No obstante, cada día surgen nuevos modos de atentar contra ella. Muchos se han preguntado: ¿de qué manera las...
Roberto García Esteban ChatGPT y Cloud Computing: un matrimonio bien avenido ChatGPT (quizá no sepas que son las siglas de Chat Generative Pre-Trained Transformer) está en boca de todos por su impresionante habilidad para generar textos que parecen escritos por...
David Prieto Marqués La importancia del control de acceso: ¿está tu empresa protegida? Por David Prieto y Rodrigo Rojas En un mundo cada vez más digitalizado y complejo, la seguridad de la información es fundamental para las empresas. A medida que las empresas...
Telefónica Tech Boletín semanal de Ciberseguridad, 22 – 26 de mayo GitLab parchea una vulnerabilidad crítica GitLab ha abordado una vulnerabilidad crítica que afecta a GitLab Community Edition (CE) y Enterprise Edition (EE) en la versión 16.0.0. En concreto, dicho fallo...
David García ¿Salvará Rust el mundo? (II) Segunda entrega en la que descubrimos cómo Rust, el lenguaje de programación de código abierto centrado en la seguridad, mejora el panorama en cuanto a vulnerabilidades basadas en errores...
Sergio de los Santos Cuatro hitos en Ciberseguridad que marcaron el futuro del malware Un recorrido por los 15 años que ha dedicado Microsoft para consolidar una estrategia que ha repercutido en la Ciberseguridad a nivel global
Quillo, muy didáctico como siempre 🙂 A ver si publican ya oficialmente la versión 5. Ah, y revisa el 4º párrafo contando desde el final, hay un baile de zonas ahí. Saludossssssssssssss Responder