¿Cómo mitigamos la vulnerabilidad de código "AtomBombing" de inyección sin parches en las máquinas con Windows?

Hasta donde puedo adivinar (no estoy completamente seguro):

  

¿Puede la vulnerabilidad sin parches llamada Atombombing omitir el sistema de seguridad solo mediante la ejecución de un programa malware.exe, o existen varias formas de inyectar el código malicioso?

Primero debemos considerar cómo funciona el bombardeo atómico:

Funciona al inyectar algún código malicioso en las tablas de Windows Atom. Las tablas Atom son un tipo de tablas en las que cualquier programa puede "guardar" algunas cadenas de datos para usarlas más tarde o compartirlas con cualquier otra aplicación.

Por lo tanto, le da a cualquier atacante potencial la oportunidad de usar este método como un vector de escalamiento de privilegios o secuestro, pero no para un ataque directo o intrusión.

¿Por qué? Bueno, a menos que se use otra vulnerabilidad / error, las Tablas Atom solo pueden modificarse localmente. Eso significa que: solo cuando ya estás dentro, puedes agregar algo a las tablas atom para inyectar código malicioso.

Entonces, hay varias formas de explotar esta vulnerabilidad, PERO, cuando ya estás ENTRADA (usando un malicious.exe , explotando otra vulnerabilidad para ingresar al sistema y luego usando Atombombing para la escalada de privilegios, etc., etc.) ).

  

¿Cuáles son las mejores prácticas para mitigar la vulnerabilidad no parcheada?   bajo las máquinas de Windows?

La única forma en que el equipo de Microsoft puede solucionar esto es eliminando las tablas Atom o agregando muchas medidas de seguridad adicionales.

La forma más fácil de defenderse contra este tipo de amenaza, es simplemente verificar cualquier dato atómico guardado antes de usarlo (en los programas) y / o cualquier sistema / programa / módulo de seguridad, revisando constantemente esas Entradas Atom.

La forma de solucionar esto será mediante el uso de una pieza de software que comprueba periódicamente las entradas de la tabla Atom, en busca de códigos maliciosos. Probablemente lo agregarán algunas firmas antimalware (o antivirus).

Puedes consultar esos artículos para obtener más información:

• Para saber más sobre el ataque: enlace
• Para saber más sobre la "API" de las tablas Atom: enlace

Los otros comentarios olvidan algo. Un atacante puede pasar de un contexto no privilegiado (sin derechos de administrador) a un contexto privilegiado (derechos de administrador) si se ejecuta en una cuenta que en realidad es de un administrador. Esto se llama un bypass UAC.

El ataque

Como es de esperar, este ataque involucra técnicas de inyección de código, como AtomBombombing (pero en realidad, cualquier otro método, incluso el simple CreateRemoteThread funcionará).

Esto se hace en 2 pasos. Lo primero que debe hacer es, efectivamente, inyectar código en ciertos procesos que se ejecutan en modo de usuario. Hay algunos procesos vulnerables, pero hablaré de explorer.exe , que también es el más estable. Este proceso no es como los demás, es especial ya que tiene muchos usos. Es por eso que tiene algunos privilegios especiales. Por ejemplo, la interfaz COM IFileOperation puede elevarse; Esto significa que se ejecutará con algún tipo de privilegios de administrador. Esto puede parecer inútil, ya que solo puede escribir archivos con derechos de administrador. ¡Pero no lo es! Ya que puedes usar eso para realizar otro ataque; Secuestro de DLL. Este es el paso 2. Básicamente, colocaría su evil.dll , que puede estar integrado en el evil.exe , en el mismo lugar donde se encuentran los procesos autoelevados; Los programas o procesos autoelevados son programas que, una vez ejecutados, obtendrán automáticamente los derechos de administrador. En breve, esto lo realiza Microsoft, ya que esos programas deben tener esos privilegios para ejecutarse correctamente y realizar tareas como tareas automatizadas. Finalmente, ejecutaríamos ese programa, que cargará evil.dll y luego aumentará automáticamente, por lo que otorgaremos privilegios de administrador al código del atacante.

Mitigation

Microsoft intentó parchear el segundo paso en el pasado, mediante la inclusión en la lista blanca de archivos .dll y técnicas similares, pero fallaron, ya que podemos omitirlo fácilmente simplemente reemplazando los archivos .dll existentes en algunos casos.

El primer paso no va a ser parchado en absoluto. Microsoft no ha parchado otros métodos de inyección como CreateRemoteThread, ¿por qué parchearían Atombombing? Eso requeriría un gran esfuerzo y una gran modificación del sistema operativo, lo que probablemente no sucederá. La única forma de evitar eso sería eliminar esos derechos especiales de programas como el explorador, pero parece que eso tampoco va a suceder. Entonces, básicamente, depende de los AV para detectar si los programas malintencionados intentarán inyectar código utilizando cualquier método.

Puede ver un POC de la vulnerabilidad arriba aquí

EDITAR: Olvidé algunos puntos de la pregunta. Por lo tanto, estas son las formas técnicas para evitar que Atombombing tenga éxito: -API enganche: una solución antivirus puede interceptar y escanear todos los intentos de modificar la tabla atom. Las funciones GlobalAddAtom () y GlobalGetAtomName () son las utilizadas para realizar este ataque. Podrían interceptar las llamadas y escanear los datos que se agregarán a la tabla Atom, buscando palabras clave o, más probablemente, tratando de analizar los datos, si se trata de un código de shell.

Una revisión rápida de este ataque hizo clic en estos puntos en mi cabeza:

Primer punto

La víctima tiene para ejecutar evil.exe para ser explotada. Incluso si el atacante convence de alguna manera a la víctima para que ejecute evil.exe , debido a la naturaleza de este ataque, evil.exe solo podrá inyectar código en procesos que se ejecutan en el mismo contexto de seguridad que evil.exe se está ejecutando. Por lo tanto, no hay una escalada de privilegios con solo usar este ataque. (¿Tal vez persuadir a la víctima para que ejecute evil.exe como administrador? No es demasiado difícil si la víctima ya está persuadida de ejecutarlo)

Segundo punto

La inyección de código es necesaria porque el antivirus podría bloquear evil.exe debido a una actividad sospechosa. Así, el código se inyecta en procesos legítimos. Pero, los navegadores y otras aplicaciones no están en la lista blanca de los antivirus también. ¿Por qué AV confía en un navegador cuando la fuente # 1 de actividad maliciosa es web? Solo los procesos en lista blanca que he visto son svchost.exe y otros procesos del sistema. Ahora, el ataque requiere un hilo alterable para insertar código en. Pero obtener un hilo alterable en los procesos del sistema (que se ejecutan en el contexto de seguridad del usuario) es difícil. Pero una vez más, no es imposible. E inyectar shellcode a procesos normales también funcionaría. Así que este ataque todavía es posible.

Tercer punto

El corazón de este ataque es ROP chain . No se verificaron los detalles de cómo se implementa la cadena de ROP, pero ASLR está habilitado en la mayoría de los procesos ahora.

Mitigation

La posible mitigación que veo es la instalación de EMET. EMET controla incluso las funciones VirtualAlloc de bajo nivel para detectar posibles ROP. No lo he comprobado, pero estoy bastante seguro de que EMET detendrá la cadena ROP de este ataque.