Me vino a la mente que hace unos años muchas aplicaciones de iOS donde se infectó por XcodeGhost (especialmente WeChat). Esto me hizo pensar en algunos escenarios posibles:

Código malicioso inyectado en archivos de objetos

Los compiladores producen muchos archivos temporales y, a menudo, esos archivos ni siquiera son analizados por el software AV porque visiblemente ralentiza la compilación, incluso si la amenaza se detecta más tarde, por alguna heurística, en el ejecutable compilado a menudo lo descartaremos. como un falso positivo ( "hey, es MI código" ).

Una aplicación maliciosa (probablemente un troyano) está ejecutando con privilegios bajos pero tiene (¿obviamente?) acceso a los datos del usuario. Una aplicación maliciosa puede inyectar FÁCILMENTE código malicioso en los archivos de objetos intermedios generados por el compilador y el código malicioso será parte de nuestra aplicación compilada. Además, el compilador puede aplicar optimizaciones dentro del módulo, mezclando código malicioso con nuestro código, lo que hace que la detección en el ejecutable producido sea más difícil.

Por supuesto, el atacante tiene que saber el formato de archivo exacto, la arquitectura de destino y la versión del compilador, pero es posible admitir algunas arquitecturas y compiladores populares.

Supongo que nadie inspeccionará el código generado ... ni siquiera cuando es fácil de descompilar como .NET y Java.

Código malicioso inyectado en archivos temporales

Los archivos temporales a menudo se tratan (al menos en mi experiencia) como parte de la aplicación y se consideran seguros . A menos que esté utilizando una herramienta como VERACODE en la que cada entrada externa se considere comprometida , una aplicación malintencionada puede leerlas y cambiarlas, cambiar el comportamiento de otra aplicación y, en algunas circunstancias, incluso inyectar código o explotar a otra. problema de seguridad.

Es cierto que los datos se consideran compartidos pero no es infrecuente (no mencionaré en qué aplicaciones ...) almacenar un caché de código ejecutable como un archivo temporal que puede ser manipulado y obliga a la aplicación host a ejecutar código malicioso. Se abre a tres posibilidades: la aplicación host puede realizar acciones no deseadas , compartir datos que se supone que son confidenciales o ejecutar algo con privilegios elevados.

Una combinación de este enfoque y el anterior: un atacante puede simplemente cambiar el makefile generado por un IDE como archivo temporal para incluir su propia biblioteca (u archivo obj).

Al menos en Windows, los archivos temporales se abren para su inyección incluso por una aplicación no habilitada (porque la protección es por parte del usuario).

La aplicación maliciosa puede leer datos privados

Sorprende la cantidad de datos almacenados en nuestros archivos temporales, algunos no deberían ser visibles para una aplicación con bajos privilegios, pero, nuevamente, la protección es por usuario. Incluso sin inyectar ningún código, una aplicación malintencionada puede leer datos que no tiene los permisos para leer (e hice un escaneo muy rápido en las sobras de mi carpeta temporal de Windows ... todos los archivos temporales correctamente eliminado después de unos pocos cientos de milisegundos puede contener datos aún más confidenciales).

Finalmente, la pregunta

¿Qué podemos hacer (como desarrolladores y como usuarios) para protegernos contra este tipo de ataques?

El primer ataque puede ser mitigado (pero no evitado por completo) usando un servidor de compilación, pero un número sorprendente de aplicaciones se construyen en la máquina de desarrollo (incluso más a menudo cuando se usa Docker). Los AV pueden configurar un honeypot para, al menos, detectar este ataque.

El segundo ataque es el más fácil de evitar, solo debemos considerar los archivos temporales como comprometidos, pero la solución podría no ser tan fácil de implementar ...

Para el tercero, no puedo pensar en una solución (aparte de dejar de usar MUCHAS aplicaciones inseguras ) o ejecutar cada aplicación (o grupo de ellas) como un usuario separado. Necesitaríamos soporte del sistema operativo para almacenar archivos temporales aislados por aplicación.

Ideas?