Cos'è l'esecuzione remota di codice (RCE)? Come l'IA accelera lo sfruttamento e come limitare i danni

Una falla di esecuzione remota del codice trasforma un server vulnerabile nel computer di qualcun altro. L'attaccante invia un input che l'applicazione avrebbe dovuto rifiutare, e l'applicazione lo esegue come comando. L'IA accelera le parti di questo lavoro che prima richiedevano tempo reale dell'attaccante.

Cos'è l'esecuzione remota di codice (RCE)?

L'esecuzione remota di codice è una classe di vulnerabilità che consente a un attaccante di eseguire il proprio codice o comandi su un sistema target tramite una rete, senza accesso preliminare. È anche chiamata esecuzione arbitraria di codice. In ogni caso, è l'attaccante a decidere cosa fa la macchina. Una vulnerabilità RCE di solito deriva da un'applicazione che inserisce input non attendibili in qualcosa che esegue: un comando shell, un modello, un oggetto deserializzato, un gestore di caricamento file. L'exploit RCE è l'input o la sequenza specifica che attiva la falla.

Come funziona l'esecuzione remota del codice

L'attacco di solito procede in linea retta. L'attaccante trova un sistema esposto che esegue un componente vulnerabile, invia input appositamente creati e fa eseguire codice sotto l'account di servizio. Il primo payload rimane piccolo, solitamente una web shell o un comando che scarica qualcosa. Strumenti più grandi arrivano dopo che l'attaccante conferma che il punto d'appoggio funziona.

Log4Shell (CVE-2021-44228) è un buon esempio di quanto possa diffondersi una singola vulnerabilità. Rivelata nel dicembre 2021 nella libreria di logging Apache Log4j, ha permesso a una singola stringa creata appositamente in un campo registrato di far scaricare ed eseguire codice controllato dall’attaccante su un server vulnerabile. Log4j era integrato in così tante applicazioni che il bug è comparso ovunque.

La maggior parte dei bug RCE inizia in piccolo. La prima funzione qui sotto passa l'input dell'utente direttamente a una shell. La seconda elimina la shell e convalida l'input.

      # Vulnerable: input goes straight to a shell
import os
def ping(host):
    os.system("ping -c 1 " + host)   # host = "8.8.8.8; id" runs a second command

# Safer: no shell, validated input
import ipaddress, subprocess
def ping(host):
    ipaddress.ip_address(host)        # raises ValueError unless host is an IP
    subprocess.run(["ping", "-c", "1", host], check=True)

      

Come l'IA cambia gli attacchi di esecuzione remota del codice

La classe di vulnerabilità è vecchia. Gli aggressori hanno modificato la velocità con cui possono avanzare in ogni fase.

Gli obiettivi vengono classificati

La scansione a livello Internet esiste da anni. L'IA aiuta con l'ordinamento: i risultati della scansione possono essere raggruppati per software e versione e classificati in base alla probabilità che ogni sistema abbia una vulnerabilità nota, così gli attaccanti puntano prima ai candidati migliori.

Le patch diventano tutorial di exploit

I fornitori pubblicano patch e avvisi per aiutare i difensori, e anche gli attaccanti li leggono. Un modello può prendere una differenza di patch o un avviso e descrivere il percorso di codice vulnerabile, riducendo il lavoro di reverse engineering e accorciando il tempo tra la divulgazione pubblica e un exploit funzionante.

Un proof of concept, molte versioni

Una prova di concetto pubblica di solito mira a una versione o a un framework. I modelli possono trasferirla a una versione o lingua diversa e modificare il payload per evitare un pattern di rilevamento noto.

Gli attacchi a più fasi richiedono meno abilità

Molti attacchi web si svolgono in due fasi. Una piccola iniezione dimostra che il codice è in esecuzione, quindi un secondo passaggio scarica strumenti più grandi. I modelli possono progettare quella catena e riprovarla con modifiche quando una fase fallisce, quindi eseguire attacchi multi-step contro un CMS, API o portale richiede meno abilità rispetto a prima.

Il lavoro di follow-up viene eseguito tramite uno script

Dopo l'esecuzione del codice, il seguito è ripetitivo: leggere i file di configurazione, raccogliere chiavi e credenziali, creare un'attività pianificata affinché l'accesso sopravviva a un riavvio e cercare sistemi vicini. Routine scriptate e assistite dall'IA eseguono questi passaggi allo stesso modo ogni volta.

La stessa catena, centinaia di organizzazioni

Una catena che funziona contro un’organizzazione può essere rivolta a centinaia. Ogni fase precedente alimenta quella successiva, e ogni obiettivo aggiuntivo costa all’attaccante meno del precedente.

Cosa fanno gli aggressori nei primi minuti dopo un exploit RCE

I primi movimenti dopo un exploit riuscito seguono uno schema. Gli aggressori inseriscono una web shell o un loader in una directory in cui il servizio può scrivere, quindi aggiungono un'attività pianificata, un servizio o un cron job in modo che l'accesso sopravviva a un riavvio. Successivamente, estraggono le credentials e le chiavi dai file di configurazione e dalla memoria e iniziano a sondare i sistemi vicini.

Ogni passaggio lascia una traccia che puoi controllare. Questi comandi mostrano le modifiche recenti ai file in una web root e le nuove voci cron su Linux.

      # Files changed in the web root in the last 24 hours
find /var/www -type f -mtime -1 -ls

# Recently modified cron entries
ls -lt /etc/cron.d /var/spool/cron 2>/dev/null | head
      

Su Windows, questa query elenca le attività pianificate registrate nell’ultimo giorno. Attiva prima il registro operativo di Task Scheduler, perché è disattivato di default.

      Get-WinEvent -FilterHashtable @{
  LogName   = 'Microsoft-Windows-TaskScheduler/Operational'
  Id        = 106
  StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, Message
      

Controlli manuali come questi funzionano su un server. Su centinaia di sistemi rimangono indietro, e un attaccante veloce può finire prima della prossima revisione programmata.

Come prevenire l'esecuzione remota di codice e limitare i danni

L'applicazione di patch e la gestione sicura degli input sono ancora le principali difese contro una vulnerabilità RCE. Tutto il resto presume che una falla verrà sfruttata prima che la patch venga applicata, quindi l'obiettivo si sposta sul rilevare rapidamente le modifiche e limitare ciò che un servizio compromesso può fare.

Netwrix Change Tracker monitora i sistemi colpiti da un attacco RCE. Imposta baseline di configurazione e utilizza il monitoraggio dell'integrità dei file per segnalare file nuovi o modificati, come una web shell aggiunta a una directory web, oltre a modifiche ai file di sistema critici e alle impostazioni su Windows, Linux, Unix e dispositivi di rete. Il suo modello di cambiamento pianificato confronta ciò che osserva con le richieste di modifica approvate, quindi una modifica non programmata viene segnalata per revisione. La cronologia delle modifiche fornisce agli investigatori una timeline, e l'autenticazione dei file di sistema verifica i file rispetto ai database globali di reputazione per confermare quali sono affidabili.

Netwrix PolicyPak limita ciò che un attaccante può fare una volta che il codice è in esecuzione su un sistema Windows. Il principio del minimo privilegio rimuove i diritti di amministratore locale e imposta regole di elevazione per gli utenti standard, quindi un processo compromesso ha meno permessi con cui lavorare. Con PolicyPak, puoi bloccare l’esecuzione di applicazioni e script se il proprietario del file non è stato precedentemente inserito nella whitelist.

Lista di controllo per la prevenzione dell'esecuzione remota di codice

1. Applica patch al software esposto a internet secondo un programma definito, iniziando con piattaforme CMS, portali VPN e API.
2. Convalidare e sanificare l'input, mantenendo l'input dell'utente lontano da shell, template e deserializzatori.
3. Esegui i servizi con il minimo privilegio e rimuovi i diritti di amministratore locale dove non sono necessari.
4. Monitora directory web, file critici e configurazioni per cambiamenti non pianificati.
5. Blocca l'esecuzione di applicazioni e script non attendibili sui sistemi Windows.
6. Mantieni una cronologia delle modifiche ricercabile in modo che le indagini inizino con una timeline.