2. Lo Splitting dei Processi Rompe la Correlazione a Livello di PID

Utilizzando fork + SCM_RIGHTS (passaggio di fd tramite socket Unix domain), la creazione del socket e le operazioni di splice possono essere collocate in processi diversi:

• La correlazione same_field(audit.pid) di Wazuh si rompe — PID del socket ≠ PID dello splice, la regola CRITICAL non scatta
• Il tracciamento dei fd a livello di processo di Falco libsinsp è completamente compromesso negli scenari SCM_RIGHTS

3. Il Riutilizzo dei Socket Bypassa le Regole Basate su Soglie di Conteggio

Il PoC originale crea un nuovo socket per iterazione (producendo 40+ chiamate socket(AF_ALG)). Il riutilizzo dei socket crea un solo socket in ascolto; il loop chiama accept() che non produce nuovi eventi di socket. Le regole basate su count >= N sono completamente sconfitte.

4. La Combinazione di Varianti Più Difficile da Rilevare

Con questa combinazione: gli strumenti basati su syscall sono completamente ciechi, la correlazione a livello di processo è rotta, le soglie di conteggio falliscono. Solo il rilevamento al punto di convergenza con kprobe può intercettare questa combinazione.

5. Il Monitoraggio a Livello LSM Può Rilevare Perfettamente lo Sfruttamento

__sock_create(family=38) è un punto di convergenza non bypassabile per tutti i percorsi (syscall e io_uring) — AF_ALG è l'unica API crittografica userspace nel kernel Linux. Non importa come gli attaccanti varino il loro approccio, devono creare un socket AF_ALG. Monitorare questa funzione a livello LSM fornisce una recall del 100% e non è influenzato da alcuna variante.

Risultati dei Test Specifici per Prodotto

Falco Richiede il Plugin krsi

Il driver nativo modern_ebpf di Falco cattura solo il percorso delle syscall. Il plugin krsi è obbligatorio — utilizza il tracciamento fexit sulle uscite delle funzioni del kernel io_socket() e __sys_socket() per coprire il percorso io_uring per la creazione di socket AF_ALG. Regola di fallback consigliata:

L'approccio di rilevamento della regola consigliata: copre simultaneamente gli eventi socket (percorso syscall, usando il matching di stringa evt.args contains AF_ALG per bypassare la limitazione del tipo ENUMFLAGS32) e gli eventi krsi_socket (percorso io_uring, usando il confronto intero krsi.domain = 38). Nessuna soglia di conteggio (sconfitta dal riutilizzo dei socket), nessuna dipendenza dalla correlazione PID (sconfitta dallo splitting multi-processo).

Nota: I tre livelli di difesa della regola della community ThreatBear sono tutti bypassabili — disallineamento del tipo ENUMFLAGS32 (evt.arg[0]=38 sempre falso), il riutilizzo dei socket sconfigge la soglia di conteggio (count=1 < 40), lo splitting multi-processo rompe la correlazione PID. Vedi Analisi del Bypass delle Regole.

Wazuh / Elastic Security Agent Non Possono Rilevare lo Sfruttamento di io_uring

Wazuh si affida interamente agli eventi di audit delle syscall di auditd. Le operazioni io_uring non passano dall'ingresso delle syscall, quindi auditd produce zero eventi e tutte le 7 regole di Wazuh falliscono. Lo stesso vale per Elastic Security Agent — i prodotti che dipendono dall'ingresso delle syscall sono strutturalmente ciechi al percorso io_uring. Vedi Analisi delle Limitazioni di Wazuh.

Dimostrazione del Bypass

La directory bypass_demo/ contiene descrizioni concettuali degli approcci di bypass del rilevamento. Il codice PoC effettivo è solo per uso interno e non viene distribuito pubblicamente.

Indice della Documentazione

Teoria

Soluzioni di Rilevamento

Hardening