Penetration Test su Adobe AEM

Tempo di lettura: 7 minuti
Data pubblicazione: September 9, 2021

Introduzione

Recentemente mi è capitato un Penetration Test su Adobe Experience Manager, una piattaforma di gestione dei contenuti Web che consente di offrire ai clienti esperienze digitali coerenti su vari canali.*

Poiché non mi era mai capitato sotto mano, ci è voluto un po' di tempo per capirne bene le funzionalità, l’architettura e soprattutto come trovare le vulnerabilità. In questo articolo vedremo come funziona e come poter exploitare l’applicativo.

Adobe Experience Manager (AEM)

AEM è un sistema di gestione di contenuti, una sorta di semplificatore per la creazione di siti web, per la gestione di contenuti di marketing e di risorse. Il vantaggio principale è che semplifica la gestione e la creazione dei contenuti di un sito, e riduce il lavoro di uno sviluppatore dando a persone meno tecniche la possibilità di configurare un sito tramite semplici variabili e drag & drop.

AEM si basa principalmente su progetti open source:

  • Apache Felix
  • Apache Sling
  • Java JCR

AEM viene creato utilizzando Sling, un framework di applicazione web basato sui principi REST che fornisce un facile sviluppo di applicazioni orientate ai contenuti. Sling utilizza un archivio JCR, come Apache Jackrabbit, o nel caso di AEM, il CRX Content Repository, come archivio dati*.

Per la pubblicazione di un articolo utilizza due ambienti:

  1. Autore
  2. Pubblicazione

Per semplificare, l’autore crea e rivede i contenuti (pagine, risorse, etc.) che vengono poi pubblicati sul sito web designato*.

L’istanza dell’autore non viene quindi resa pubblica, ma sarà mostrata solo attraverso le istanze pubblicate, gestite dall’AEM Dispatcher. AEM dispatcher è un sistema front-end che offre un ulteriore livello di sicurezza all’infrastruttura Adobe Experience Manager. AEM dispatcher agirà come reverse proxy e contiene i meccanismi per generare e aggiornare il codice HTML statico in base al contenuto del sito dinamico*.

Vulnerabilità

A meno di trovare 0-day (e l’intento è sempre quello :P), sono principalmente due le categorie di vulnerabilità che si possono trovare durante un’attività su AEM:

  1. Misconfigurazioni non volute
  2. Livello di patching

Misconfigurazioni

Per quanto riguarda la prima, una delle misconfigurazioni più frequenti che avvengono su AEM sono le restrizioni applicate al modulo Dispatch per negare l’utilizzo o l’accesso a una risorsa. La configurazione predefinita del Dispatch contiene un insieme di filtri che operano in modo predefinito sulla regola di deny, ossia se una risorsa non è stata esplicitamente permessa all’interno di un blocco di filtri, le richieste per quella risorsa saranno negate.

Un esempio di regole è la seguente*:

/filter {
    /0001 { /type "allow" /method "POST" /url "/content/[.]*.form.html" }
    /0002 { /type "allow" /url "*.css" } 
    /0003 { /type "deny" /url '*.query*.json' }
}

Il problema risiede nella regola #2 (CVE-2016-0957), poiché blocca la richiesta seguente

/bin/querybuilder.json

ma permette

/bin/querybuilder.json/a.css

AEM ha aggiunto un banner per evitare l’utilizzo di queste regole, ma ciò non implica che esistano ancora istanze di AEM che permettono, tramite regole malconfigurate di accedere a risorse che dovrebbero rimanere private.

Per chi volesse ho pubblicato una lista di path sensibili su Github.

Un’altra misconfigurazione che permette l’analisi e la disclosure di file sensibili è lasciare il pannello di CRXDE Lite disponibile a chiunque, permettendo l’accesso quindi a utenti non autenticati.

Permesso in scrittura

Una volta ottenuto l’accesso a CRX, basta cercare una cartella con i permessi di scrittura con la seguente query

/bin/querybuilder.json?hasPermission=jcr:write&path=/content

e si potrà caricare qualsiasi file si voglia (per eseguire un attacco di Stored Cross Site Scripting, per esempio). Altre query utili sono:

/bin/querybuilder.json?type=nt:file&nodename=*.zip
/bin/querybuilder.json?path=Thome&p.hits=full&plimit=-1
/bin/querybuilder.json?hasPermission=jcr:write&path=/content
/bin/querybuilder.json?hasPermission=jcr:addChildNodes&path=/content
/bin/querybuilder.json?hasPermission=jcrmodifyProperties&pathqcontent
/bin/querybuilder.json?p.hits=selective&p.properties=jcr%3alastModifiedBy&property=jcr%3alast ModifiedBy&property.operation=unequals&property.value=admin&type=n t%3abase&p.limit=1000
/bin/querybuilder.json?pathqetc&path.flat=true&p.nodedepth=0
/bin/querybuilder.json?path=ietc/replication/agents.author&p.hits=full&p.nodedepth=-1

Command Injection

Nel caso in cui abbiate trovato le credenziali dell’admin e (molto probabilmente) abbiate quindi accesso in scrittura sulla cartella /apps c’è una buona probabilità di poter eseguire un attacco di Command Injection. Questo grazie al path /system/console/bundles che permette l’upload di bundle che verranno poi eseguiti da AEM (in maniera molto similare a Tomcat).

Per creare il bundle ho trovato molto utile il tool AEM RCE OSGI bundle.

Conclusioni

Avrei voluto inserire screenshot delle vulnerabilità identificate durante l’attività, ma avrei dovuto oscurare praticamente tutto e ho preferito evitare. Lascio comunque una serie di risorse che sono state molto utili per approfondire l’argomento: