Nuestro director del laboratorio en ElevenPaths, Sergio de los Santos (@ssantosv), ha conducido una pequeña investigación en los sistemas Microsoft Windows 10 para conocer el grado de fortificación contra la explotación de vulnerabilidades con que vienen compilados los binarios que acompañan al sistema que ha terminado en un informe que podéis descargar desde el SlideShare de ElevenPahts.
El estudio está basado en algo muy sencillo y que es clave para la fortificación de los sistemas Microsoft Windows, como ya describió en el libro de Máxima Seguridad en Windows que escribió para 0xWord sobre el mismo tema. Se basa en conocer qué binarios vienen por defecto configurados con la protección DEP (Data Execution Prevention), con la protección ASLR (Address Space Layout Randomization), SEH (Structured Exception Handling) y CFG (Control Flow Guard).
Estas cuatro protecciones ayudan a evitar la construcción de exploits funcionales cuando se detecta una vulnerabilidad en el código. Si quieres más detalle, en el libro de Máxima Seguridad en Windows se explica en detalle, pero a modo de resumen en el documento se han cubierto las explicaciones. Un resumen simplista de ellas sería el siguiente:
- DEP (Data Execution Prevention): Evita que se ejecute código inyectado en zonas de memoria marcadas como "Solo para Datos". Si en algún momento el puntero de ejecución apuntara a una zona de memoria marcada como solo de datos, se produciría una excepción y no se continuaría el procesado de instrucciones, lo que dificulta la inclusión del código de un exploit en el sistema. Por supuesto, existen formas de saltarse DEP usando técnicas ROP, pero hace que sea más complicado el proceso y se limitan los casos en los que pueden crearse exploits funcionales.
- ASLR (Address Space Layout Randomization): Hace que en cada ejecución de un binario este se cargue en una zona de memoria distinta mediante el uso de un valor Random inicial. Esto hace que la creación de un exploit consistente necesite de un bug de Info-Leak, es decir, un bug que permita conseguir una dirección de memoria de una instrucción conocida para a partir de ella hacer los cálculos correctos. Por supuesto, técnicas como Heap Spray que llenan toda una zona de memoria con un código conocido o similares también permiten saltarse esta protección.
- SEH (Structured Excepcion Handling): El uso de esta protección evita que se utilicen las excepciones del sistema para aprovechar el código de este binario para construir un exploit. Es una medida de compilación que añade una capa de protección mayor a las que suponen SafeSEH y SEHOP utilizadas desde hace más de una década por los sistemas Windows.
- CFG (Control Flow Guard): Esta medida creada por Microsoft, en esencia, se parece a las opciones de seguridad de los headers HTTP CSP (Content Security Policies) en las aplicaciones web. Con las directivas CFG se puede establecer desde que partes del binario se puede invocar ejecución de código y desde cuales no. Estas opciones pueden ser configuradas a nivel global o a nivel parcial en distintas zonas del código. Solo disponible a partir de Windows 8.1 Update 3 y en Windows 10.
Conociendo estas opciones, el equipo del laboratorio hizo un pequeño experimento utilizando un script en Python llamado Pesto que ahora puedes descargar desde la web del laboratorio de ElevenPaths. Lo que hace este script, en esencia, es buscar todos los binarios de un sistema - en este caso - MS Windows 10, y extraer de cada uno de ellos los flags de compilación DEP, ASLR, SEH y CFG para ver cuántos de ellos vienen con estas protecciones. Los resultados son guardados en una base de datos - tal y como se puede ver en el código de Pesto - para su posterior análisis.
Figura 3: Pesto disponible para descarga |
Para las pruebas se han hecho tres configuraciones de Microsoft Windows 10 distintas, que es importante conocer para entender las gráficas con los resultados y lo que significan.
- Configuración Base: Ficheros de Microsoft Windows 10 por defecto [18.489 DLL + 2.597 EXE]
- Configuración Ofimática: Ficheros de Microsoft Windows 10 + Office 2016 [20.735 DLLs + 2.716 EXE]
- Configuración Completa: Ficheros de MS Windows 10 + Office 2016 + Google Chrome + Mozilla Firefox + PDF Fox + Paquete Adobe [20.856 DLL + 2.774 EXE]
Si miramos los resultados obtenidos, podemos sacar muchas lecturas. Por ejemplo, si miramos en general las distintas configuraciones, los resultados globales que se obtienen son los siguientes. En la configuración Base, es decir, solo ficheros de MS Windows 10, más del 12% de las DLLs vienen sin alguna medida de protección, pero si lo llevamos a MS Windows 10 + Office 2016, el ratio sube a más del 20% de las DLLs.
Si miramos las protecciones que tienen los binarios de cada una de las compilaciones vemos que los ratios son altos en todas ellas, pero que la que menos se ha activado ha sido CFG en los binarios de las distintas configuraciones, lo que nos deja un ratio de ficheros desprotegidos pequeño en porcentaje, pero alto en número.
Comparando las opciones de seguridad en los binarios de los navegadores Mozilla Firefox y Google Chrome, obtenemos un gráfico como el que sigue, en el que puede verse que Google Chrome implementa medidas de seguridad de forma más natural, mientras que en Mozilla Firefox CFG no está activo en ningún binario y el Safe Exception Handling solo en un porcentaje residual.
Y por último, haciendo lo mismo entre Adobe Acrobat y Foxit PDF el resultado es el que puede verse a continuación con la ausencia de CFG y NO_SEH en los binarios de ambos y una pequeña diferencia en el porcentaje de binarios que aplican DEP y ASLR.
Figura 7: Medidas de seguridad aplicadas a los binarios de Foxit Reader y Adobe Acrobar Reader |
Es solo un estudio, pero da una muestra de cómo se están aplicando las opciones de fortificación anti-exploits en las últimas versiones de sistemas Microsoft Windows. Puedes descargar el estudio desde el repositorio de documentos públicos de ElevenPaths y descargar Pesto para hacer tú las pruebas desde la web del laboratorio.
Saludos Malignos!
Habeis copiado y pegado las primeras lineas y la clase PESecurityCheck de http://reverseengineering.stackexchange.com/questions/9293/how-use-pefile-to-check-for-nx-aslr-safeseh-and-cfg-control-flow-guard-flag?
ResponderEliminar