Eseguire il debug di ogni processo per ridurre il rischio di attacchi malware di successo?

Question

Eseguire il debug di ogni processo per ridurre il rischio di attacchi malware di successo?

#1 da (1 voti)

0

Ho visto che un bel po 'di malware (in particolare ransomware) controlla un debugger e un bail se ne viene trovato uno.

Sarebbe (a) pratico e (b) ridurrà il rischio di un attacco malware di successo se uno dei due:

allega un debugger fittizio a ogni processo userspace durante la creazione?
ha un hook che indica ai processi dell'utente che un debugger è collegato, se richiesto? per esempio. LD_PRELOAD su Linux, e credo che dai crack di WGA che Windows abbia alcune API anche per questo.

Suppongo che, in particolare su Windows, potrebbe essere necessario disporre di una whitelist di programmi per non eseguire il debug (ad esempio software commerciale che si attiva anche in caso di debug).

risk malware

posta Mark K Cowan 12.07.2017 - 18:08

fonte

1 risposta

Leggi altre domande sui tag risk malware

Come fermare JS dall'esecuzione quando viene passato come parametro all'URL? (nessun tag script) Giustificazione per la conformità PCI DSS

score 1 · Answer 1

Would it (a) be practical and (b) reduce the risk of a successful malware attack if one either:

attaches a dummy debugger to every userspace process at creation?

has a hook which tells a user's processes that a debugger is attached, if asked? e.g. LD_PRELOAD on Linux, and I believe from WGA cracks that Windows has some API for this too.

Da una prospettiva Linux

LD_PRELOAD può essere utilizzato solo con binari collegati dinamicamente. Non è raro che i binari ELF sviluppati a fini criminali siano collegati staticamente; esempi includono

e così via.

Per quanto riguarda il collegamento di un debugger fittizio a ogni processo dello spazio utente durante la creazione, considerare quanto segue:

approfittando del fatto che un processo non può chiamare ptrace(PTRACE_TRACEME,...) più di una volta è solo uno dei tanti anti- tecniche di debug . Se l'uso di una singola tecnica anti-debug comporta un alto tasso di rilevazione / fallimento, i creatori di malware si adatteranno e la tecnica semplicemente non sarà più utilizzata. Alcuni eseguibili ben noti non si preoccupano affatto dei trucchi anti-debug: Mirai e il suo tipo sono un esempio importante di questo.
la creazione del processo userspace è gestita dal kernel (e se il programma è collegato dinamicamente, anche il linker dinamico). Ciò significa che se si desidera apportare modifiche al modo in cui un programma viene mappato nella memoria virtuale, è necessario apportare modifiche al kernel. Ha senso modificare fondamentalmente il modo in cui il kernel carica i programmi in memoria attraverso tutte le architetture per fare qualcosa come attaccare un debugger fittizio a ogni processo userspace alla creazione, solo per vedere gli autori di malware smettere semplicemente di chiamare ptrace(PTRACE_TRACEME,...) nei loro binari come un risultato?
il collegamento di un debugger fittizio ruoterebbe attorno all'uso della chiamata di sistema ptrace . L'uso di ptrace ha implicazioni di vasta portata per il comportamento dei processi e potrebbe persino rendere il sistema inutilizzabile, a causa del fatto che l'esecuzione di un programma tracciato si interrompe dopo aver ricevuto un segnale:

While being traced, the tracee will stop each time a signal is delivered, even if the signal is being ignored. (An exception is SIGKILL, which has its usual effect.) The tracer will be notified at its next call to waitpid(2) (or one of the related "wait" system calls); that call will return a status value containing information that indicates the cause of the stop in the tracee. While the tracee is stopped, the tracer can use various ptrace requests to inspect and modify the tracee. The tracer then causes the tracee to continue, optionally ignoring the delivered signal (or even delivering a different signal instead).

Quindi no, nessuna di queste proposte è pratica o migliora la sicurezza.