¿Sería (a) práctico y (b) reduciría el riesgo de un ataque de malware exitoso si uno de ellos:
- adjunta un depurador ficticio a cada proceso de espacio de usuario en la creación?
- tiene un gancho que le dice a los procesos de un usuario que un depurador está conectado, si se le pregunta? p.ej. LD_PRELOAD en Linux, y creo que a partir de las grietas WGA que Windows también tiene algunas API para esto.
Desde una perspectiva de Linux
LD_PRELOAD solo se puede utilizar con binarios enlazados dinámicamente. No es infrecuente que los binarios de ELF desarrollados con fines criminales estén vinculados estáticamente; los ejemplos incluyen
y así sucesivamente.
En cuanto a adjuntar un depurador ficticio a cada proceso de espacio de usuario en la creación, considere lo siguiente:
- aprovechar el hecho de que un proceso no puede llamar a
ptrace(PTRACE_TRACEME,...) más de una vez es solo uno de varios técnicas de depuración . Si el uso de cualquier técnica anti-depuración única produce una alta tasa de detección / falla, los creadores de malware se adaptarán y la técnica simplemente ya no se utilizará. Algunos ejecutables bien conocidos ni siquiera se molestan con trucos anti-depuración: Mirai y su tipo son un ejemplo destacado. de esto.
- la creación del proceso del espacio de usuario es administrada por el kernel (y si el programa está vinculado dinámicamente, el enlazador dinámico también). Esto significa que si uno desea realizar cambios en la forma en que se asigna un programa a la memoria virtual, debe hacer cambios en el kernel. ¿Tiene sentido alterar fundamentalmente la forma en que el kernel carga los programas en la memoria en todas las arquitecturas para hacer algo como adjuntar un depurador ficticio a cada proceso de espacio de usuario en la creación, solo para ver a los autores de malware simplemente dejar de llamar a
ptrace(PTRACE_TRACEME,...) en sus binarios como un resultado?
-
adjuntar un depurador ficticio giraría en torno al uso de la llamada al sistema ptrace . El uso de ptrace tiene implicaciones de gran alcance para el comportamiento del proceso e incluso podrían inutilizar el sistema, debido a que la ejecución de un programa rastreado se detiene al recibir una señal:
Mientras se está rastreando, el tracee se detendrá cada vez que se envíe una señal.
Entregado, incluso si la señal está siendo ignorada. (Una excepción es
SIGKILL, que tiene su efecto habitual.) El marcador se notificará a
su próxima llamada a waitpid (2) (o uno de los sistemas de "espera" relacionados
llamadas); esa llamada devolverá un valor de estado que contiene información
Eso indica la causa de la parada en el tracee. Mientras que el tracee
se detiene, el trazador puede usar varias solicitudes de seguimiento para inspeccionar y
modificar el tracee. El marcador hace que el tracee continúe,
opcionalmente ignorando la señal entregada (o incluso entregando un
diferente señal en su lugar).
Así que no, ninguna de estas propuestas es práctica o mejora la seguridad.