Lucha contra el malware sin archivos, parte 2: contramedidas



¿Por qué persisten los ataques sin archivos? Analicemos las fortalezas y debilidades de las mitigaciones existentes.

A pesar de que el término «malware sin archivos» se acuñó recientemente, los ataques sin archivos existen desde hace más de tres décadas. Es posible que haya oído hablar de los nombres más conocidos, como los ataques de desbordamiento de búfer, desbordamiento de pila y desbordamiento de pila. El primer exploit conocido de esta categoría fue el Gusano de Morris, desarrollado por Robert Morris en 1988 y creado para probar los riesgos de explotar los desbordamientos de búfer.

A medida que los ataques evolucionan en sofisticación, las contramedidas luchan por mantenerse al día: la industria de la seguridad no ha logrado eliminar una sola categoría de ataque. La semana pasada, en la parte 1 de esta serie, examinamos qué son los ataques sin archivos. Aquí, en la parte 2, para entender por qué estas amenazas no se han mitigado, analicemos las contramedidas históricas implementadas para eliminarlas.

Bibliotecas C / C ++ más seguras

Las aplicaciones desarrolladas con las bibliotecas estándar C y C ++ son vulnerables a los ataques de desbordamiento del búfer porque no realizan comprobaciones de límites en las matrices de cadenas de entrada para las funciones estándar. Para mitigar este problema, se crearon versiones más seguras de estas bibliotecas para reemplazar las originales.

Si bien esta es una buena estrategia para reducir las posibles vulnerabilidades de desbordamiento del búfer, la mayoría de las aplicaciones heredadas no utilizan bibliotecas más seguras.

Análisis estático

Las herramientas de análisis estático escanean el código fuente en busca de posibles vulnerabilidades. La integración de escáneres en el proceso continuo de integración y entrega es una buena forma de «desinfectar» el código fuente y lograr prácticas de codificación seguras.

Sin embargo, estas herramientas de análisis estático no son soluciones infalibles, porque no todos los desarrolladores las ejecutan y, a menudo, deben actualizarse cuando se descubren nuevas vulnerabilidades de seguridad. Esto significa que no pueden detectar ataques que nunca antes habían visto, que es la definición misma de exploits de día cero.

Stack Canary

El canario de pila, introducido en 1997, es una protección insertada por el compilador entre la dirección de retorno y los parámetros de entrada a una función. El compilador agrega un valor aleatorio antes de la dirección de retorno y guarda una copia de este valor aleatorio (o canario) en un lugar seguro fuera de la pila.

Antes de que vuelva la función, el canario se compara con el valor guardado. Si la dirección de retorno se modifica a través de un desbordamiento de búfer, esta guardia sería pisoteada. Se supone que, para que se produzca un desbordamiento, el canario también debe sobrescribirse.

Esta contramedida se puede eludir adivinando el valor del canario forzándolo un byte a la vez. Una vez que se determina el canario, se puede desbordar la pila y modificar la dirección de retorno sin detección, y el valor del canario se puede reescribir con un valor de ingeniería inversa.

Pila W ^ X

Otro enfoque para prevenir ataques de desbordamiento de pila es W ^ X stack, que fue introducido en 2003 por Intel y AMD a nivel de chip, y es aprovechado por varios sistemas operativos, incluido Linux.

Marcar la pila como editable y no ejecutable o no editable y ejecutable evita que se ejecute el código malicioso de la pila. Intentar inyectar código ejecutable en una pila donde el código ejecutable está bloqueado activaría la contramedida de la pila W ^ X.

Un atacante puede aprovechar las instrucciones de ensamblaje existentes en la propia aplicación para subvertir el flujo de command de la aplicación. El primer enfoque para eludir una pila W ^ X es el ataque de retorno a libc del experto en seguridad Photo voltaic Designer. Al explotar una vulnerabilidad de desbordamiento de búfer para introducir nuevos marcos en la pila que ejecutan instrucciones de ensamblaje existentes para llamar a funciones libc, un atacante puede ejecutar shellcode.

Dado que las aplicaciones llaman a los recursos del sistema, el atacante puede asumir que es possible que la aplicación de destino cargue la biblioteca libc y luego puede aprovechar las funciones de la biblioteca libc para iniciar un terminal de shell. Una vez que se inicia el terminal de shell, el atacante tiene el regulate del sistema de destino.

Las evoluciones posteriores de este tipo de ataque aprovecharon la tabla de enlace de procedimiento (PLT) para lanzar shellcode, conocido como ataque de retorno a PLT. La última evolución de este tipo de ataque es programación orientada al retorno (ROP). Aquí, el atacante examina el código ensamblador de la aplicación de destino en busca de instrucciones de interés con un código de retorno y reúne estas instrucciones ensambladoras, llamadas devices, para iniciar un terminal de shell. Los ataques ROP han evolucionado aún más en sofisticación y aplicabilidad más general en los ataques Just In Time ROP y Blind ROP, que invito al lector a investigar por su cuenta.

Aleatorización del diseño del espacio de direcciones

La aleatorización del diseño del espacio de direcciones (ASLR), introducida en Linux en 2000, aleatoriza el espacio de memoria en el que se cargan en la memoria las bibliotecas compartidas, como libc. En lugar de que las aplicaciones tengan sus propias copias individuales de la misma biblioteca, estas bibliotecas se comparten entre múltiples aplicaciones como copias de solo lectura, y la dirección en la que estas bibliotecas compartidas se cargan en la memoria se rastrea en el PLT.

ASLR dificulta que los atacantes adivinen la dirección donde se cargan estas bibliotecas compartidas. Sin embargo, solo la dirección base es aleatoria. El desplazamiento de una función certain de su dirección foundation permanece constante. Una vez que se descubre la dirección base de una biblioteca compartida o la dirección de una función con una biblioteca compartida, un atacante puede localizar la dirección de todas las funciones dentro de esa biblioteca.

Cuando se compila, cada aplicación de Linux incluye llamadas de constructor y destructor antes de llamar a primary () y después de llamar a main (). El compilador también agrega automáticamente el código de ensamblaje de la biblioteca del cargador de enlaces a la aplicación compilada. La biblioteca del cargador de enlaces, ld.so, es responsable de cargar libc y otras bibliotecas dinámicas. los volver-a-csu El ataque aprovecha estas instrucciones de ensamblaje adicionales conocidas que se agregan a cada aplicación para eludir ASLR.

Este ataque es un proceso de dos etapas:

  1. Construya un ataque micro ROP para descubrir la dirección de la función produce () en la biblioteca libc cargada por el cargador de enlaces en el PLT.
  2. Con esta dirección conocida de la función compose (), realice otro ataque ROP para abrir un shell remoto.

Al explorar las diferentes contramedidas que la industria del software package ha ideado para combatir el malware sin archivos y al ver la facilidad con que se eluden, está claro que los piratas informáticos están perfeccionando su oficio a un ritmo alarmante.

En la parte 3 de esta serie la próxima semana, discutiremos nuevos métodos que pueden mitigar de manera más efectiva los ataques sin archivos y, finalmente, eliminar toda la categoría de amenazas.

Rui Máximo desarrolló un gran interés en la seguridad durante su programa de maestría en Matemáticas. Después de completar su tesis en criptografía, fue reclutado para roles de seguridad a lo largo de sus 25 años de carrera en la industria del software, y ocupó una variedad de roles de computer software … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia unique