È possibile sfruttare CVE-2015-4852 sui server WebLogic dopo un bilanciamento del carico?

Ok, arriviamo al punto: la vulnerabilità CVE-2015-4852 non riguarda il protocollo T3. Il problema sta nelle routine di serializzazione / deserializzazione utilizzate da WebLogic e nelle librerie sottostanti che compongono il classpath java.

Quindi, per chiarire alcuni punti:

• Il protocollo T3 è citato perché è un punto di accesso a dati serializzati forniti dall'utente.
• WebLogic è citato perché viene fornito in bundle con gli Apache Commons interessati libreria e viene caricato nel classpath quando viene eseguito WebLogic. Deve essere aggiornato in modo che anche la libreria in bundle interessata possa essere aggiornata. Oppure puoi aggiornarlo da solo.
• Il vero problema risiede nella stessa libreria di Apache Commons.

Pertanto, rispondendo alla tua domanda, sì, la tua applicazione potrebbe ancora risentire delle vulnerabilità di deserializzazione se l'utente malintenzionato è in grado di trovare da qualche altra parte l'immissione di dati maligni serializzati . Alcune applicazioni Java si basano pesantemente nella serializzazione. Molti di loro lo inviano anche tramite connessioni HTTP / S con codifica base64 o con qualche altro tipo di codifica. Le applicazioni Java JSP utilizzano anche Viewstates (anche base64, sebbene utilizzi una struttura diversa da ViewState ASP.NET).

Ho persino visto il modulo HCM (Human Capital Management) di Oracle utilizzare la serializzazione codificata in base 64 per definire un titolo di pagina (sì, sono stato in grado di cambiarlo in qualsiasi cosa volessi, ma quando l'ho esaminato, non ero sono molto consapevoli del funzionamento interno dei difetti di deserializzazione)

UPDATE:

C'è stato qualche sviluppo su questo problema. Non in questo CVE stesso, ma alcuni hanno scoperto che ci sono più librerie (anche molto comuni) che sono vulnerabili all'intera questione di serializzazione / deserializzazione.

link

Dalla mia comprensione della vulnerabilità come menzionato qui link , se sei in grado di raggiungere ObjectStream.readObject () della tua applicazione Java, sarà possibile sfruttarlo. Quindi, se hai un url say example.com/sample e sample è riferito al load balancer come link , dovresti essere al sicuro da un weblogic prospettiva per chiunque acceda a example.com e non a host1.

Suppongo che tutto ciò di cui ti devi preoccupare sia se il tuo bilanciamento del carico consente le connessioni T3. In tal caso, richiedi che sia bloccato. Come suggerisce il documento di Oracle (Doc ID 2076338.1) bloccare l'accesso t3 e si dovrebbe essere bravi.

Sei sfruttabile (diverso da 'vulnerabile') se i dati serializzati possono raggiungere la tua applicazione. In questo caso se il traffico T3 non viene passato, allora no, non saresti sfruttabile tramite questa strada.

Attenzione però, qualsiasi altra posizione in cui vengono ricevuti i dati serializzati controllati dall'utente è ugualmente vulnerabile e ciò può avvenire su http.

CVE-2015-4852 è una vulnerabilità specifica nel software Oracle WebLogic . È stato scoperto che il protocollo t3 è vulnerabile perché potrebbe ricevere oggetti serializzati non affidabili da un potenziale aggressore. Se il protocollo t3 non viene canalizzato dai bilanciatori del carico, il traffico dannoso non viene trasmesso al portale Weblogic , evitando la minaccia in questo caso.

Tuttavia, le vulnerabilità serializza / deserializza sono una categoria completa di vulnerabilità . Altri componenti del software Oracle WebLogic potrebbero essere vulnerabili, non solo il protocollo t3. Il fatto è che nessun altro componente di WebLogic è stato identificato come vulnerabile.

D'altra parte, le applicazioni Java standard o personalizzate servite dal server Oracle WebLogic (o da altri server applicazioni) potrebbero essere vulnerabili alle vulnerabilità serializza / deserializza . Sebbene non sia frequente passare oggetti serializzati tramite HTTP ma potrebbe essere possibile includerli in intestazioni, cookie, pubblicare o ottenere dati, ecc.

Il modo consigliato per sapere se la tua applicazione è vulnerabile è:

1. Vai alla directory dell'applicazione
2. grep -R InvokerTransformer.
3. Annota o intercetta il traffico e cerca gli oggetti serializzati dall'utente sull'applicazione:
   • rO0AB (base64)
   • ac ed 00 05 (esadecimale)
4. Sviluppa un proof-of-concept specifico e controlla

Questo non è il modo definitivo di trovare questo tipo di vulnerabilità poiché possono essere scoperti altri modi di sfruttare pericolose chiamate readObject () che non utilizzano InvokerTransformer .