Che cos'è l'XML Signature wrapping?
L'XML Signature wrapping (wrapping della firma XML) (XSW) è una classe di attacchi informatici che sfruttano il modo in cui le firme XML vengono convalidate nelle applicazioni che utilizzano protocolli di sicurezza basati su XML, in particolare in Security Assertion Markup Language (SAML), Simple Object Access Protocol (SOAP) e Web Services Security (WS-Security o WSS).
Gli attacchi di signature element wrapping mirano a bypassare l'autenticazione e a ottenere accessi non autorizzati manipolando la struttura di un documento XML senza invalidarne la firma digitale.
Un attacco XML Signature wrapping utilizza il divario tra il processo di convalida della firma e il trattamento dei dati. L'aggressore inietta un elemento duplicato o manipolato (come un'asserzione SAML contraffatta o un corpo SOAP) all'esterno della parte firmata e l'applicazione finisce per elaborare i dati dannosi.
Newsletter di settore
Le ultime notizie nel campo della tecnologia, supportate dalle analisi degli esperti
Resta al passo con le tendenze più importanti e interessanti del settore relative ad AI, automazione, dati e altro con la newsletter Think. Leggi l'Informativa sulla privacy IBM.
L'abbonamento sarà fornito in lingua inglese. Troverai un link per annullare l'iscrizione in tutte le newsletter. Puoi gestire i tuoi abbonamenti o annullarli qui. Per ulteriori informazioni, consulta l'Informativa sulla privacy IBM.
Extensible Markup Language (XML) è un formato di dati basato su testo utilizzato per strutturare e memorizzare i dati in modo leggibile sia dall'uomo che dalla macchina. Viene utilizzato nei servizi web, nei sistemi di identità e nello scambio di dati tra applicazioni.
Come HTML, anche XML è strutturato con tag progettati per rappresentare i dati. Supporta elementi e attributi nidificati, supportando gerarchie complesse.
XML è spesso utilizzato nei protocolli SOAP, SAML e WS-Security.
Esempio di XML
Una firma XML è una firma digitale applicata ai dati XML, definita dalla specifica W3C XML Signature. L'elemento XML Signature consente di garantire l'integrità dei dati affermando che i dati sono attendibili, verificabili e non sono stati manomessi.
- Una parte del documento XML viene selezionata per la firma utilizzando un
<Reference> con un ID (ad esempio, #ID123).
Su tali dati viene calcolato un hash o un digest.
L'hash è crittografato con la chiave privata del mittente per dare vita alla firma.
A
<Signature> viene aggiunto al documento con SignedInfo, che contiene l'URI di riferimento, SignatureValue con l'hash crittografato e KeyInfo, ad esempio la chiave pubblica o il certificato.
Esempio di sintassi della firma XML
<!-- Altri dettagli come DigestMethod, CanonicalizationMethod -->
Gli attacchi di firma XML utilizzano la flessibilità strutturale dell'XML per utilizzare le applicazioni a elaborare dati non autenticati mentre superano la convalida della firma. Gli aggressori creano una mancata corrispondenza tra l'elemento firmato e l'elemento effettivamente elaborato (in genere duplicando o riposizionando gli elementi). Il risultato è che l'applicazione utilizza contenuti non firmati, anche se la firma sembra valida.
Ecco come funzionano solitamente gli attacchi XML Signature Wrapping (XSW):
Gli utenti malintenzionati iniziano con un messaggio XML reale e attendibile, ad esempio una risposta di accesso valida con firma digitale (ad esempio una risposta SAML legittima).
Spostano la parte firmata (quella a cui si fa riferimento nel
<ds:Reference URI=”#ID123”/> ) in un punto diverso del documento in cui è ancora tecnicamente presente ma non utilizzato.
Hanno inserito dati falsi nella posizione originale. Questi dati contraffatti non sono firmati, ma sono creati per sembrare legittimi.
La maggior parte delle applicazioni cerca i dati in base al nome del tag o all'espressione XPath, senza controllare se si tratta della versione firmata e finendo quindi per utilizzare i dati falsi.
La firma digitale è comunque valida perché verifica la parte firmata originale (ora nascosta), non la parte falsificata utilizzata dall'app.
Quindi, l'applicazione pensa che funziona con un documento firmato sicuro, ma in realtà agisce su dati manipolati e non autorizzati.
Passaggio a piedi: Un attacco XSW in pratica
Questo esempio dimostra come un utente malintenzionato può manipolare un'asserzione SAML firmata per ottenere l'accesso non autorizzato di amministratore utilizzando una debole logica di analisi e convalida XML.
SAML è un protocollo basato su XML utilizzato per lo scambio sicuro di informazioni di autenticazione tra due sistemi: l'identity provider (IdP) e il service provider (SP). Abilita il single sign-on (SSO), che consente agli utenti di autenticarsi una volta e accedere a più servizi senza accessi ripetuti.
1. Richiesta SAML originale
Si tratta di una richiesta SAML autentica acquisita da uno strumento come SAML Raider in Burp Suite. Include una sezione con firma digitale, nota come asserzione SAML, che contiene i dettagli dell'identità dell'utente. All'interno di questa affermazione c'è
La richiesta contiene anche una firma digitale valida (
2. Osservare l'utente che ha effettuato l'accesso
Nella risposta dell'app, mostra che l'utente ha effettuato l'accesso con l'identità originale
3. Asserzione SAML modificata (attacco XSW eseguito)
L'utente malintenzionato modifica segretamente la richiesta SAML spostando l'asserzione originale con firma digitale in un'altra parte del documento XML, consentendo alla firma di rimanere valida e superare la verifica.
Un falso
Questa attività illustra il concetto fondamentale di un attacco XSW: la firma digitale sembra valida, ma i dati elaborati dall'applicazione sono falsi e non affidabili.
4. Accesso amministratore riuscito
Di conseguenza, l'applicazione concede l'accesso all'amministratore in base alla falsa asserzione iniettata dall'aggressore. Non riesce a Verify se l'assertion elaborata era quella effettivamente firmata digitalmente. Questo errore consente all'aggressore di impersonare con successo un utente amministratore. Il sistema che consente all'utente di accedere come admin@libcurl.so dimostra chiaramente che l'attacco di wrapping della firma XML è riuscito.
Questo esempio mostra come un controllo debole della firma XML possa essere indotto a fidarsi di dati falsi. L'aggressore non viola la firma digitale. Invece, i dati firmati vengono spostati altrove e le informazioni false vengono collocate dove l'app si aspetta i dati reali. L'applicazione elabora quindi erroneamente i dati falsi, ritenendoli sicuri.
Gli attacchi XSW generalmente rientrano in alcuni sottoinsiemi o tipi principali, ognuno dei quali utilizza il modo in cui vengono implementate la verifica e l'analisi delle firme XML.
Ecco una ripartizione di quelli più comuni:
1. Attacco wrapping semplice
Metodo: L'aggressore sposta l'elemento firmato in una parte diversa del documento XML e inserisce un elemento dannoso nella sua posizione originale.
Obiettivo: la firma ancora verifica (perché i dati firmati sono invariati), ma l'applicazione elabora invece i dati iniettati dall'aggressore.
Esempio: firmato
2. Avvolgimento basato su ID
Metodo: l'aggressore utilizza l'uso degli attributi ID XML per fare riferimento ai dati firmati.
Obiettivo: l' aggressore crea un elemento duplicato con lo stesso ID ma lo colloca in una posizione che l'applicazione elabora per primo.
Esempio: la firma fa riferimento a #ID -1234, ma il parser utilizza l'elemento falso dell'aggressore con quell'ID anziché quello firmato.
3. Wrapping dell'iniezione dello spazio dei nomi
Metodo: l'aggressore manipola gli spazi dei nomi XML per confondere la convalida della firma.
Obiettivo: modificare l'interpretazione degli elementi o aggirare i rigidi controlli dello schema, mantenendo la firma valida.
Esempio: inserimento di un elemento <Assertion> dannoso in un nuovo spazio dei nomi, in modo che la convalida abbia esito positivo ma la logica di elaborazione lo accetti.
4. XSW con abuso di firma imbustata
Metodo: modifica il posizionamento di
Obiettivo: fare in modo che il validatore pensi che tutto sia firmato, escludendo però le parti controllate dagli aggressori dalla copertura della firma.
Esempio: sposta l'originale
5. Avvolgimento a iniezione XPath
Metodo: manipola le query XPath utilizzate durante la convalida della firma in modo che puntino a nodi controllati dall'aggressore anziché al nodo firmato.
Obiettivo: indurre il signature verifier a controllare dati innocui mentre l'applicazione elabora dati dannosi.
Esempio: modifica l'XML in modo che l'XPath del verificatore (ad esempio,
Gli attacchi XSW possono portare a gravi conseguenze nel mondo reale, in particolare quando sono coinvolti dati sensibili o operazioni critiche. Questi scenari ipotetici evidenziano il potenziale impatto di tali attacchi.
Scenario 1: esclusione dell'autenticazione in SAML SSO
Scenario: un'applicazione aziendale utilizza il Single Sign-on basato su SAML per autenticare gli utenti. Ogni risposta di accesso include un'asserzione SAML con firma digitale che identifica l'utente.
Attacco XSW: un utente malintenzionato acquisisce una risposta SAML legittima, sposta l'asserzione firmata in una parte diversa del documento XML e inserisce al suo posto un'asserzione falsa che afferma di essere un amministratore.
Impatto: il sistema convalida la firma sull'asserzione originale ma elabora l'asserzione non firmata e iniettata dall'attore delle minacce, dando all'attore delle minacce l'accesso come utente privilegiato.
Scenario 2: escalation dei privilegi nei servizi Web
Scenario: un servizio Web application programming interface (API) utilizza SOAP e WS-Security per elaborare le richieste. Il corpo del messaggio SOAP è firmato digitalmente per garantire che il comando sia attendibile.
Attacco XSW: l'aggressore racchiude il testo SOAP originale e firmato in un elemento wrapper innocuo e lo sostituisce con un nuovo testo non firmato che contiene privilegi elevati o azioni non autorizzate.
Impatto: se il servizio elabora il corpo non firmato, l'utente malintenzionato può aumentare i privilegi o eseguire azioni limitate come la visualizzazione o la modifica di dati sensibili.
Scenario 3: accesso non autorizzato a funzionalità critiche
Scenario: un'interfaccia amministrativa consente agli utenti di inviare comandi basati su XML, come l'eliminazione dell'account o la reimpostazione della password, protetti da firme digitali.
Attacco XSW: l'aggressore sposta il comando firmato in una posizione secondaria e inserisce al suo posto un comando non firmato (come l'eliminazione dell'account di un altro utente o la reimpostazione della password di un amministratore).
Impatto: se l'applicazione elabora il comando non firmato, può eseguire operazioni critiche per conto di un utente non autorizzato.
Scenario 4: modifica delle richieste di pagamento con firma digitale
Scenario: una banca protegge le sue operazioni di trasferimento di fondi utilizzando firme XML. Ogni richiesta contiene i dettagli della transazione, come l'importo del trasferimento e i numeri di conto del mittente e del destinatario. Le richieste sono firmate digitalmente per garantire l'autenticità.
Attacco XSW: un utente malintenzionato acquisisce una richiesta di trasferimento valida, trasferisce i dati firmati in una sezione non critica del documento e inserisce una transazione falsa con un importo maggiore e un account destinatario diverso.
Impatto: se l'applicazione non verifica strettamente che la transazione elaborata sia quella firmata, potrebbe eseguire la transazione falsificata dell'aggressore, con conseguenti trasferimenti non autorizzati e perdite finanziarie.
Scenario 5: Manomissione dei token di autenticazione firmati
Scenario: una piattaforma online protegge i suoi token di autenticazione utilizzando firme digitali XML. Ogni token contiene informazioni sull'identità dell'utente e i diritti di accesso ed è firmato crittograficamente per evitare manomissioni.
Attacco XSW: un utente malintenzionato acquisisce un token di autenticazione valido, sposta la parte firmata in un'altra posizione all'interno dell'XML e inietta un nuovo segmento non firmato che include privilegi elevati o non autorizzati.
Impatto: se il server elabora la sezione manipolata anziché quella firmata, l'aggressore può ottenere un accesso non autorizzato o eseguire operazioni privilegiate, compromettendo la sicurezza dell'applicazione.
Per analizzare se un'applicazione è vulnerabile agli attacchi XML Signature wrapping, è importante capire come analizza ed elabora i dati XML. È particolarmente importante comprendere l'analisi e l'elaborazione XML in contesti sensibili alla sicurezza, come l'autenticazione SAML o la messaggistica SOAP.
Ecco alcune tecniche e strategie di test per identificare tali vulnerabilità in ambienti reali:
1. Analizzare il modo in cui l'applicazione analizza XML
Controlla se l'applicazione estrae elementi come
2. Usa Burp Suite SAML Raider o proxy personalizzati
Utilizza Burp Suite con SAML Raider per iniettare un elemento falso non firmato e racchiudere quello firmato. Se l'app elabora i dati falsi mentre la firma è ancora convalidata, è vulnerabile a XSW.
3. Verifica la presenza di elementi duplicati con lo stesso tag
Inserisci un'asserzione firmata in una sezione nascosta e una falsa in un punto visibile. Se l'app elabora i dati falsi, è vulnerabile a XSW.
4. Controlla il comportamento del riferimento della firma
Riposiziona l'elemento firmato (quello a cui si fa riferimento in
Se l'applicazione elabora la versione non firmata anziché quella effettivamente firmata, l'applicazione è vulnerabile a un attacco XSW. L'app sta convalidando la firma correttamente ma non garantisce che stia utilizzando il contenuto firmato, consentendo agli aggressori di inserire dati non autorizzati.
5. Verifica la gestione degli errori e il comportamento di registrazione
Invia asserzioni malformate e osserva errori verbosi o risposte incoerenti. Queste risposte possono evidenziare punti deboli nella logica di sicurezza e convalida XML dell'app.
6. Utilizza le tecniche di sfruttamento XSW note per i test
Utilizza strumenti come SAML Raider, SoapUI o test harness XML personalizzati per applicare i modelli di attacco XSW. Se l'applicazione accetta ed elabora uno qualsiasi dei payload, indica una vulnerabilità XSW.
7. Ispeziona il codice dell'applicazione
Se l'app legge i dati XML selezionando elementi in base al nome del tag senza assicurarsi che stia utilizzando l'elemento firmato e affidabile, può essere indotta a elaborare dati falsi.
Per proteggere un'applicazione dagli attacchi XSW, gli sviluppatori possono implementare una rigorosa elaborazione XML, convalidare correttamente le firme e garantire che vengano utilizzati solo dati affidabili e firmati.
Ecco alcune contromisure specifiche che possono aiutare a difendersi dagli attacchi XSW:
Assicurati che l'esatto elemento XML utilizzato per l'autenticazione o l'autorizzazione sia lo stesso con firma digitale. In questo modo si impedisce agli aggressori di iniettare una seconda asserzione non firmata che l'applicazione potrebbe elaborare erroneamente invece di quella legittima e firmata.
Una firma incapsulata è una firma posta all'interno dell'elemento che firma. L'enveloping rende più difficile per gli aggressori inserire elementi dannosi all'esterno del contenuto firmato senza rompere la struttura, contribuendo a prevenire il wrapping o la sostituzione.
Utilizza un parser XML sicuro configurato per rifiutare i documenti con ID duplicati, riferimenti a entità esterne o struttura imprevista. XSW si basa sulla manipolazione della struttura XML, ad esempio inserendo tag duplicati o più asserzioni. L'analisi rigorosa riduce questa superficie di attacco imponendo input ben formati e conformi allo schema.
Collega la logica di elaborazione dell'applicazione direttamente all'elemento XML a cui si fa riferimento nella firma (utilizzando l'attributo ID o la firma
Rifiuta le risposte SAML che contengono più di una a meno che <Assertion> non sia esplicitamente richiesto. Gli attacchi XSW spesso iniettano una seconda asserzione. Garantire che ne venga elaborato solo uno aiuta a eliminare l'ambiguità e a ridurre i rischi.
Utilizza librerie ben gestite e attente alla sicurezza per la convalida della firma digitale XML (come Apache Santuario o OpenSAML) con configurazioni predefinite sicure. Queste librerie spesso includono una protezione integrata contro il wrapping delle firme se configurate correttamente.
Convalida le asserzioni SAML in entrata rispetto alla SAML XML Schema Definition (XSD) ufficiale. La convalida impedisce agli aggressori di iniettare elementi o attributi inaspettati che aggirano la logica aziendale o confondono il parser XML.
Assicurati che ogni attributo ID utilizzato nell'XML firmato (come le asserzioni) sia univoco e che i riferimenti corrispondano a un solo elemento. Gli exploit XSW possono avere successo facendo riferimento a un elemento nella firma e iniettandone un altro con lo stesso ID o nome tag. L'applicazione dell'univocità consente di evitare questa confusione.
Queste pratiche possono ridurre il rischio che gli aggressori utilizzino le strutture XML e la logica di elaborazione delle firme, chiudendo efficacemente la porta a molti attacchi XSW.