L'exploit recente di Fritz Box

Question

L'exploit recente di Fritz Box

#1 da (4 voti)

6

Informazioni di base:

Circa il 50% dell'accesso a Internet ADSL e via cavo in Germania (e presumibilmente in alcune parti dell'UE) passa ai router AVM Fritz, sia testualmente o rimarchiati come per es. "1 e 1 Home Server" o "T-Online Box".
Questi sono sistemi MIPS incorporati con un paio di porte Ethernet, una ADSL o una spina simile, e altre cose opzionali (DECT, WLan, porte USB) che eseguono un derivato Linux (2.6 ???).

Circa tre settimane fa, è diventato noto un exploit che permetteva di ottenere l'accesso root al router. L'exploit è stato apparentemente usato per chiamare i numeri di servizio sulle Falklands, caricando gli utenti inconsapevoli.

Il primo comunicato stampa di AVM è stato che non si trattava di una minaccia seria (cosa altro direbbero!) perché richiede l'accesso remoto abilitato, che non è il caso per impostazione predefinita e che la maggior parte degli utenti non ha comunque abilitato .

Alcuni giorni dopo, è stato rivelato che l'exploit non ha nulla a che fare con l'accesso remoto e che qualcuno potrebbe prendere il controllo del router se si visita semplicemente un sito Web altrimenti innocuo che contiene una pagina con codice dannoso. Un aggiornamento del sistema operativo è stato rilasciato lo stesso giorno.

Ieri, è stato affermato che una descrizione dettagliata viene pubblicata su "siti specifici di hacker" mentre diversi milioni di router rimangono privi di patch (cioè vulnerabili).

Domande:

1. Come potrebbe un simile exploit, concettualmente e praticamente funzionare? ¹. Quando visiti un sito Web (o esegui praticamente tutto il resto), il browser esegue una query DNS e apre una connessione TCP all'host remoto. Il router inoltra la query DNS e quindi il NAT il pacchetto SYN (e il SYN-ACK e tutti i seguenti datagrammi).
In altre parole, il router copia pressoché i pacchetti da una porta Ethernet a un'altra (aggiornando il checksum IP dopo NAT, ma presumibilmente accade comunque nell'hardware, ma in entrambi i casi le implementazioni software del checksum TCP sono state sottoposte a stress test per 40 anni, sono abbastanza resistenti al rock?). In pratica, come se si stesse facendo un splice da un socket all'altro, tranne che accade nello stack di rete.
Si dovrebbe seriamente sperare che il semplice inoltro di un pacchetto a un'altra porta funzioni al 100% in modo affidabile senza eccezioni e senza alcun mezzo di sfruttamento! Il router non convalida o esegue nulla all'interno dei datagrammi, non c'è motivo per il router di guardare anche il "binario blob" all'interno di ogni pacchetto (... e per quanto ne so, non lo fa fai filtraggio dei contenuti?).
Sono sconcertato su come un simile exploit possa realisticamente funzionare. Qualche idea?

2. Vedere come "il filtro dei pacchetti Linux è bloccato" sembra l'unica spiegazione plausibile (cos'altro potrebbe essere?), ho motivo di iniziare a farmi prendere dal panico sul mio server Debian?

¹ Tieni presente che non sta cercando una ricetta pratica e non voglio eseguire un exploit.

routing exploit

posta Damon 10.03.2014 - 15:04

fonte

1 risposta

Leggi altre domande sui tag routing exploit

Perché un server anonimo non può richiedere un certificato client? Sicurezza della tastiera Bluetooth

score 4 · Accepted Answer

Dopo aver cercato tutto il giorno e scavato attraverso qualche migliaio di post più irrilevanti in diversi forum di utenti e un sito che presumibilmente "verifica" la vulnerabilità (la trascrizione telnet comunque non mostra altro che una pagina HTML in qualche modo rotta), Ho trovato un effettivo sito di exploit.

Risulta che al solito le informazioni disponibili pubblicamente erano ingannevoli.

Che cos'è?

L'exploit, senza i dettagli troppo espliciti , è un attacco combinato di XSRF / iniezione e una sofisticazione di un attacco che è noto da almeno all'inizio del 2009:

L'interfaccia web del router, accessibile sulla LAN (e facoltativamente anche da remoto), ha un'interfaccia utente localizzata.
L'interfaccia web, che ti consente di modificare le impostazioni ed eseguire alcuni comandi, è un vettore di attacco molto ovvio, che può essere (o almeno così penseresti!) ostacolato impostando una password.
L'exploit funziona perché il codice di localizzazione non ne verifica i parametri. La localizzazione, tuttavia, include la pagina di accesso, quindi l'exploit eseguirà prima anche se è necessario autenticarsi. Pertanto, l'impostazione di una password non impedisce l'attacco.
Questa è l'unica spettacolare nuova versione dell'attuale exploit.
Il router passerà la lingua dell'interfaccia richiesta e non verificata a un'utilità che viene eseguita come root (... ed esegue i suoi parametri in una shell).
Una volta che il fatto è noto, l'exploit diventa molto ovvio: selezionare una lingua dell'interfaccia utente seguita da un separatore e qualsiasi comando di shell che si desidera eseguire. Questo è un attacco di iniezione molto tipico (proprio come gli attacchi di iniezione SQL più noti).
Tipicamente questo sarebbe usato per abilitare l'accesso remoto e caricare il file password / config su un altro server via FTP, o scaricare un dialer, o simili.
Nessun "codice dannoso" di per sé è necessario sul sito Web di attacco. L'attacco avviene semplicemente fornendo un URL (per un'immagine o simile) che punta al nome di rete predefinito del router (o al suo indirizzo IP di emergenza) e contiene i comandi da eseguire come POST variabili.
In linea di principio, ciò potrebbe essere fatto su qualsiasi sito altrimenti innocuo tramite un banner pubblicitario, anche senza che il proprietario del sito lo sapesse.
Il browser dell'utente tenta di aprire l'URL e quindi esegue il codice sul router.

Che cosa fare a riguardo?

A parte la cosa ovvia, aggiornando il firmware (si spera che già un mese fa!), si dovrebbe avere un'estensione del browser installata che prevenga richieste / scripting sospetti cross-site, come NoScript o RequestPolicy. Questo è qualcosa che tutti dovrebbero avere comunque.
Inoltre, bloccare i banner pubblicitari è una considerazione certa, se non lo fai già comunque.

Che ne è della domanda 2?

Poiché non è una vulnerabilità router per sé (cioè un bug nello stack di rete), ma semplicemente un exploit di un'interfaccia utente danneggiata (che incidentalmente gira sul router), altri sistemi Linux che non hanno questa interfaccia non sono interessati.