asminject.py

asminject.py è un fork pesantemente modificato del progetto dlinject di David Buchanan. Inietta payload arbitrari in assembly (o binari precompilati) direttamente nei processi Linux x86-64, x86 e ARM32 accedendo a /proc/<pid>/mem invece di agganciarsi tramite ptrace. Utile per manomettere processi fidati, in alcuni scenari post-exploitation, per recuperare contenuti dalla memoria dei processi e per aggirare alcuni controlli di sicurezza. Può iniettare in processi containerizzati dall'esterno del container, purché si abbia accesso root sull'host.

Puoi anche leggere ulteriori informazioni su asminject.py e sulle sue origini nella pagina dello strumento di Bishop Fox, inclusa una descrizione dettagliata del lavoro che ha ispirato lo strumento.

In questo documento:

• Elevator pitches or TLDR
• Origins
• Examples
• But what about Yama's ptrace_scope restrictions?
• Future goals

Documentazione separata e più dettagliata:

• Come funziona asminject.py - una discussione architetturale di livello superiore con approfondimenti su alcuni dettagli tecnici, soprattutto per i lettori che non hanno mai lavorato con strumenti di iniezione in memoria
• Per iniziare
• Differenze rispetto a dlinject.py
• Opzioni specializzate
• Risoluzione dei problemi
• Cronologia delle versioni

Elevator pitches or TLDR

• "asminject.py è come dlinject, tranne per il fatto che consente di iniettare qualsiasi payload si desideri invece di limitarsi a caricare una libreria, e funziona su più architetture."
• "asminject.py è vagamente simile a Frida, tranne per il fatto che non si aggancia tramite l'interfaccia ptrace, quindi i processi non possono bloccarlo applicando ptrace a sé stessi."

Origins

asminject.py è stato scritto per due scenari principali nel penetration testing in ambienti Linux:

• Attaccare i controlli di sicurezza a livello di processo e di container dalla prospettiva di un attacker con accesso root all'host
• Evitare il rilevamento dopo aver sfruttato con successo un'altra vulnerabilità

Ad esempio, si consideri un penetration test in cui il tester ha ottenuto accesso root a un server che ospita molti container. Uno dei container gestisce bonifici bancari e al suo interno è installato un prodotto di sicurezza endpoint molto robusto. Quando il pen tester cerca di modificare i dati dei bonifici dall'interno del container, il software di sicurezza endpoint rileva e blocca il tentativo. asminject.py consente al pen tester di iniettare codice arbitrario direttamente nella memoria del processo del software bancario o persino nel prodotto di sicurezza endpoint dall'esterno del container. Come una vittima del "genio maligno" di Cartesio, il software di sicurezza all'interno del container è impotente, perché esiste in un ambiente interamente sotto il controllo dell'attaccante.

Il dlinject.py originale è stato progettato specificamente per caricare librerie condivise Linux in un processo esistente. asminject.py fa tutto ciò che faceva l'originale e molto di più. Esegue codice assembly arbitrario e include template per una varietà di attacchi. È stato inoltre riprogettato per aiutare a evitare il rilevamento da parte di meccanismi di sicurezza che si basano su attività potenzialmente sospette come gli eventi di caricamento delle librerie.

Examples

La directory practice di questo repository include codice di ciclo di base che stampa un timestamp e l'iterazione del ciclo sulla console, così puoi esercitarti a iniettare vari tipi di codice in un ambiente controllato. Questi cicli di prova vengono richiamati negli esempi rimanenti.

La sintassi di base per chiamare asminject.py è:

# python3 ./asminject.py <target_process_id> <payload> \
  --arch [x86-64|x86|arm32] --relative-offsets-from-binaries --stop-method "slow" \
  --var <payload_variable_1_name> <payload_variable_1_value> \
  # ... \
  --var <payload_variable_n_name> <payload_variable_n_value>

Nella maggior parte dei casi, uno qualsiasi dei payload usati negli esempi funzionerà su tutte le architetture supportate.

• Esempi di base - payload semplici che, ad esempio, fanno sì che un processo esistente copi file per te
• Iniezione di codice Python
• Iniezione di codice PHP
• Iniezione di codice Ruby
• Iniezione di shellcode/stager
• Iniezione di librerie condivise

But what about Yama's ptrace_scope restrictions?

La maggior parte delle distribuzioni Linux include un modulo di sicurezza del kernel chiamato Yama che controlla l'accesso all'uso della capacità ptrace verso altri processi. Sebbene asminject.py non si agganci all'interfaccia del debugger, richiede comunque il permesso di usare la capacità ptrace. Se ricevi errori relativi a questa capacità, controlla il contenuto di /proc/sys/kernel/yama/ptrace_scope. Se è impostato su 2, esegui il seguente comando come root:

echo 1 > /proc/sys/kernel/yama/ptrace_scope

I valori pari o superiori a 3 non possono essere rimossi senza riavviare il sistema. Tuttavia, se sei un amministratore autorizzato di un sistema Linux in cui qualcuno ha accidentalmente impostato /proc/sys/kernel/yama/ptrace_scope su 3, oppure stai conducendo un penetration test autorizzato in un ambiente in cui quel valore è stato impostato, consulta la directory ptrace_scope_kernel_module per una potenziale soluzione alternativa che non richiede un riavvio.

Future goals

• Aggiungere il supporto per ARM64 (Aarch64).
• Consentire di passare lo shellcode tramite stdin oltre all'attuale metodo di lettura da un file.
• Valutare l'uso di Keystone per l'assemblaggio dello shellcode invece di chiamare il comando gcc a livello di sistema operativo.
• Per Python e altri interpreti di script con API per passare bytecode compilato da eseguire (anziché esecuzione in stile eval di codice script leggibile), fornire payload che sfruttino questa capacità per un'ancora maggiore furtività.
• Se fattibile, iniettare codice Java nei processi Java tramite JNI.
• Aggiungere opzioni per agganciare un metodo specifico (o un indirizzo, ecc.) come alternativa all'attuale tecnica "hook della prossima syscall" ereditata da dlinject.py.
• Fornire un modo per usare lo strumento per un'attività di quasi-debugging, ad esempio agganciare una funzione e stampare gli argomenti che le vengono passati ogni volta che viene chiamata.
  • Potrebbe avere più senso trovare un modo per iniettare Frida usando asminject.py - sono necessarie ulteriori ricerche.
• Sviluppare payload interattivi, ad esempio invece di iniettare una specifica riga di codice Python in un processo Python, asminject.py potrebbe chiedere all'operatore una riga di codice da iniettare, iniettarla, restituire l'output risultante e poi chiedere all'operatore un'altra riga di codice.
  • Anche questo potrebbe avere più senso gestirlo usando Frida, se Frida può essere iniettata in un processo usando asminject.py in un modo che eviti la necessità di Frida di invocare temporaneamente l'interfaccia del debugger.
• Fornire un modo per interagire con un processo target in esecuzione su un'architettura di processore diversa da quella in cui gira . Ad esempio, interagire con un dispositivo remoto usando hardware come un PCI leech, sfruttare casi limite estremi come dispositivi con accessibile come root tramite una condivisione NFS, ecc.