Nove vulnerabilità CrackArmor in Linux AppArmor espongono oltre 12 milioni di sistemi enterprise

Ricercatori Qualys hanno identificato nove falle di sicurezza nel modulo AppArmor del kernel Linux, permettendo escalation di privilegi e isolamento container…

Contenuto

Nove vulnerabilità CrackArmor in Linux AppArmor espongono oltre 12 milioni di sistemi enterprise

Scopri anche

Nove vulnerabilità CrackArmor in Linux AppArmor espongono oltre 12 milioni di sistemi enterprise

Nove vulnerabilità CrackArmor in Linux AppArmor espongono oltre 12 milioni di sistemi enterprise

In questo articolo:

Il Threat Research Unit di Qualys ha divulgato nove vulnerabilità nel modulo di sicurezza Linux AppArmor, collettivamente denominate CrackArmor, che permettono a utenti locali non privilegiati di bypassare le protezioni del kernel, escalare i privilegi a root e compromettere l'isolamento dei container. Secondo Qualys, queste falle esistono dal 2017, a partire dalla versione 4.11 del kernel Linux, e interessano sistemi che integrano AppArmor per impostazione predefinita, tra cui Ubuntu, Debian, SUSE e le loro derivate.

I dati di gestione degli asset di Qualys indicano che oltre 12,6 milioni di istanze Linux enterprise operano con AppArmor abilitato di default. La diffusione di AppArmor come meccanismo di controllo degli accessi obbligatorio in ambienti enterprise, piattaforme cloud, Kubernetes, dispositivi IoT e deploy edge amplifica significativamente la superficie di attacco.

Il problema del confused deputy

⬆ Torna su

Al centro di CrackArmor vi è quello che Qualys definisce un problema di "confused deputy", una classe di vulnerabilità in cui un processo privilegiato viene indotto a eseguire azioni non autorizzate per conto di un utente non privilegiato. Nell'advisory, Qualys paragona il meccanismo a un intruso che convince un responsabile di edificio in possesso di chiavi master ad aprire vault riservati che l'intruso non può aprire da solo.

Nella pratica, un account utente locale standard è sufficiente per manipolare i profili di sicurezza di AppArmor, ovvero le regole che governano le azioni permesse alle singole applicazioni su un sistema Linux. Attraverso comandi instradati tramite strumenti di sistema fidati, un attaccante non privilegiato può caricare, sostituire o rimuovere interamente tali profili.

Gli attaccanti possono sfruttare pseudo-file come /sys/kernel/security/apparmor/.load, .replace e .remove per disabilitare le protezioni per servizi critici, bloccare tutti gli utenti dall'accesso remoto prendendo di mira il demone SSH, o bypassare le restrizioni di Ubuntu sugli user namespace non privilegiati, anche dopo la chiusura di tutte le soluzioni alternative precedentemente note.

Vettori di attacco e impatto operativo

⬆ Torna su

Le vulnerabilità CrackArmor consentono molteplici vettori di attacco. Un attaccante può caricare profili "deny-all" contro servizi critici come SSH, impedendo le connessioni remote legittime. La rimozione di sottoprofili annidati può esaurire lo stack del kernel, potenzialmente innescando un kernel panic e un riavvio forzato sui sistemi x86-64.

I ricercatori Qualys hanno sviluppato proof-of-concept che dimostrano una catena completa di escalation dei privilegi su un'installazione Ubuntu Server predefinita con il server di posta Postfix. Caricando un profilo di sicurezza appositamente creato che blocca una specifica capacità di riduzione dei privilegi in Sudo, i ricercatori hanno forzato Sudo in una condizione "fail-open": incapace di abbandonare i propri privilegi root prima di invocare l'agente di posta del sistema, Sudo esegue il processo come root preservando l'ambiente dell'attaccante.

Qualys ha identificato anche quattro vulnerabilità a livello kernel all'interno del codice stesso di AppArmor. Una permette di far crashare l'intero sistema forzando un riavvio. Un'altra consente a un attaccante di leggere memoria kernel protetta, esponendo indirizzi interni che le mitigazioni di sicurezza sono progettate per nascondere e rendendo più facili da eseguire gli exploit successivi. Altre due vulnerabilità sono state dimostrate come percorsi indipendenti per ottenere accesso root completo, anche su sistemi con mitigazioni di exploit moderne abilitate per default.

Container escape e isolamento compromesso

⬆ Torna su

Le vulnerabilità CrackArmor interessano in modo particolare gli ambienti containerizzati. AppArmor funziona come boundary di trust per il confinamento dei servizi, l'applicazione del least-privilege e l'isolamento dei container. Se un attaccante locale può riscrivere o rimuovere i profili, il sistema può perdere parte del layer di sicurezza che gli amministratori si aspettano sia presente per default.

Secondo Canonical, nei deploy che eseguono container potenzialmente controllati dall'attaccante, le vulnerabilità del kernel AppArmor potrebbero teoricamente abilitare scenari di container escape senza necessità di un'applicazione userspace privilegiata cooperante, sebbene al momento della stesura dell'advisory ciò non fosse stato dimostrato praticamente. Su host che non eseguono workload containerizzati, lo sfruttamento richiede la cooperazione di un'applicazione privilegiata.

Risposta dei vendor e disponibilità delle patch

⬆ Torna su

Al momento della pubblicazione, non sono stati assegnati identificatori CVE alle vulnerabilità. Il processo di assegnazione CVE del kernel Linux ritarda intenzionalmente il rilascio degli identificatori fino a una o due settimane dopo che una correzione è atterrata in una release stabile. Canonical conferma che i problemi sono tracciati internamente come CrackArmor e che le vulnerabilità del kernel AppArmor, il bug sudo correlato e le modifiche di hardening per su non sono ancora collegati a CVE pubblici.

Le patch sono state pubblicate nell'albero kernel upstream di Linus Torvalds il 12 marzo, a seguito di un processo di divulgazione coordinata che ha coinvolto il team di sicurezza di Ubuntu, gli sviluppatori AppArmor di Canonical, Debian, SUSE e il manutentore di Sudo, estendendosi su otto mesi. Canonical ha rilasciato aggiornamenti di sicurezza del kernel per le versioni Ubuntu supportate, insieme a mitigazioni userspace per problemi correlati che coinvolgono sudo e su.

Secondo Canonical, l'aggiornamento del kernel rimane l'unica remediazione completa per le vulnerabilità AppArmor stesse. Le organizzazioni sono invitate ad applicare immediatamente gli aggiornamenti del kernel vendor, scansionare gli ambienti per sistemi vulnerabili utilizzando i QID di Qualys e monitorare le directory dei profili AppArmor per modifiche sospette.

Implicazioni per la sicurezza enterprise

⬆ Torna su

Le vulnerabilità CrackArmor allineano con il modus operandi degli attori di minacce sponsorizzati dagli stati, le cui campagne prioritàzzano la distruzione sull'espionaggio. Un attaccante non necessita di credenziali amministrative o movimento laterale per causare danni significativi: qualsiasi vettore di accesso iniziale che fornisce un account locale non privilegiato è sufficiente per weaponizzare l'host, innescando un kernel panic o negando tutto il traffico.

Il CTO di Qualys Dilip Bachwani ha dichiarato che queste scoperte evidenziano lacune nel modo in cui ci affidiamo alle assunzioni di sicurezza predefinite. Per i CISO, questo significa che applicare le patch da sole non è sufficiente: è necessario riesaminare l'intera assunzione di ciò che le configurazioni "default" significano per l'infrastruttura.

Questo articolo è una sintesi basata esclusivamente sulle fonti elencate.

Implicazioni e scenari

⬆ Torna su

La longeva presenza di queste vulnerabilità suggerisce che le assunzioni di sicurezza predefinite potrebbero essere state sistematicamente violate in ambienti fino ad ora considerati robusti. Il meccanismo di "confused deputy" evidenzia come fidarsi di strumenti di sistema fidati possa ampliare la superficie di attacco senza richiedere credenziali privilegiate.

  • Scenario 1: Escalation dei privilegi. Un utente locale standard potrebbe ottenere accesso root completo sfruttando la condizione "fail-open" di Sudo o manipolando i profili di sicurezza.
  • Scenario 2: Compromissione dell'isolamento. Nei contesti containerizzati, la rimozione dei profili di confinamento potrebbe teoricamente facilitare scenari di container escape.
  • Scenario 3: Denial of Service. Un attaccante potrebbe bloccare l'accesso remoto legittimo (es. SSH) o innescare un kernel panic forzando il riavvio della macchina.

Cosa monitorare

⬆ Torna su
  • Lo stato di applicazione delle patch kernel e degli aggiornamenti userspace per Sudo e su.
  • Le directory dei profili AppArmor per rilevare modifiche non autorizzate o caricamenti anomali.
  • L'accesso ai pseudo-file critici in /sys/kernel/security/apparmor/ da parte di processi non privilegiati.

Nota editoriale: questa sezione propone una lettura analitica dei temi trattati, senza introdurre dati fattuali non presenti nelle fonti.

Fonti

⬆ Torna su

In breve

  • vulnerabilita
  • cybersecurity
  • linux
  • exploit

Link utili

Apri l'articolo su DeafNews