CVE-2021-39115

Iniezione di template nei modelli email porta all'esecuzione di codice su Jira Service Management Server

I) Preparazione

Ho già guidato il deploy e il debug qui, potete consultarlo.

II) Analisi

Nella Descrizione di questa CVE viene già chiarito che il bug si trova nella funzionalità Email Template. Con i permessi di amministratore, l'utente può modificare arbitrariamente i template delle email di notifica. Questo bug richiede i permessi di amministratore per essere sfruttato, quindi anche se consente RCE non è molto grave, ma ho deciso comunque di scrivere questo blog per divertimento :) chi sta studiando SSTI può prenderlo come riferimento.

• Iniziamo: ho deployato la versione atlassian-jira-servicedesk-4.17.0-m0006-standalone e ho provato a fare un diff con la versione 4.18.0 per vedere le differenze:

Quando vedo questa quantità di file,... ovviamente non li leggo uno per uno, sono pigro. Scherzo, ma in realtà oltre alla correzione di sicurezza, le versioni hanno anche aggiornamenti e modifiche nelle funzionalità. Fare il diff di tutto e poi sedersi a leggere richiederebbe molto tempo. Certo, in alcuni casi devo fare il diff completo e leggere, ma in questo caso non l'ho fatto =)))

• Come detto sopra, l'amministratore ha il permesso di modificare il template di tutte le email di notifica. Quindi, il primo passo è capire durante l'analisi delle email di notifica quali contesti vengono utilizzati? Questo è particolarmente importante quando si vuole sfruttare un bug SSTI (che usa una sandbox). Il metodo più efficace è fare debug e saltare nella parte di analisi del template email per vedere il valore delle variabili di contesto.
• Ovviamente ci sono molti tipi di notifiche diverse (SignUp, cambio password, ...), ognuno usa un endpoint diverso. Io uso la funzionalità SendBulkMail per creare un'email di notifica. Per quanto riguarda lo stack delle chiamate di questo endpoint, non lo menzionerò per evitare di dilungarmi, poiché è simile allo stack delle chiamate in CVE-2019-11581

Nella funzione SimpleNote.render posso vedere le variabili di contesto per capire cosa posso sfruttare:

Secondo la mia esperienza, presto attenzione ai contesti/classi che contengono parole chiave come: Utils, Manager, service, ... . Noto che c'è un contesto $jirautils (classe com.atlassian.jira.util.JiraUtils) che contiene il metodo public static <T> T loadComponent(String className, Class<?> callingClass):

Cerco documentazione per capire la sua funzione e come usarlo, poiché l'input accetta una stringa className e l'output è una classe, quindi è possibile che questo metodo carichi una classe arbitrariamente:

• Come dice la documentazione, questa funzione serve per caricare classi :) Inizio subito a vedere se il metodo può effettivamente caricare classi arbitrariamente:

Vado su System -> Email templates e scarico il file template corrente sul computer

Ci sono molti template diversi, ognuno usato per un tipo specifico di notifica, quindi cerco un file che possa essere usato comunemente per molti tipi di notifiche, come email\html\includes\header.vm

Dopo aver caricato il file template modificato e usato SendBulkMail per inviare un'email di notifica, ricevo il seguente output nell'email:

In pratica, questa classe non ha costruttori o non è accettata. Provo a usare un'altra classe con costruttori (costruttore senza input) per vedere:

E il risultato è come previsto. Sono riuscito a ottenere la classe con successo:

• Quindi siamo in grado di caricare classi quasi arbitrariamente, abbastanza buono. Ma come ottenere RCE? Jira usa il template Velocity e ha una sandbox abbastanza completa, con blacklist di pacchetti e blacklist di classi (con blacklist di classi può bloccare tutte le classi che estendono quelle nella blacklist). Usare classi pubbliche disponibili in rete è quasi impossibile. A questo punto devo assolutamente fare un diff tra la versione vulnerabile e la versione patchata per vedere le differenze, ovviamente non farò un diff completo, ma mi concentrerò solo sul file di configurazione di Velocity (\atlassian-jira\WEB-INF\classes\velocity.properties) per vedere se ci sono aggiornamenti:

Vediamo che sono state aggiunte 3 classi alla blacklist:

org.springframework.expression.spel.standard.SpelExpressionParser,\
com.atlassian.jira.component.ComponentAccessor,\
com.atlassian.jira.plugin.ComponentClassManager

Esaminando ciascuna classe, noto che la classe SpelExpressionParser ha il metodo public SpelExpression parseRaw(String expressionString). Dopo una rapida ricerca su Google per trovare come usarlo, ho scoperto che può essere utilizzato così:

#set($SpelExpressionParser = $jirautils.loadComponent('org.springframework.expression.spel.standard.SpelExpressionParser',$i18n.getClass()))
$SpelExpressionParser.parseRaw("T(java.lang.Runtime).getRuntime().exec('calc')")

Come potete vedere, la funzione parseRaw restituisce un oggetto di tipo org.springframework.expression.spel.standard.SpelExpression, ma non esegue ancora l'espressione inserita. Entro nella classe SpelExpression e vedo il metodo getValue: