L'interfaccia di loopback può essere dirottata?

Question

L'interfaccia di loopback può essere dirottata?

#1 da (8 voti)
#2 da (3 voti)
#3 da (1 voti)
#4 da (1 voti)

6

Ispirato da questa domanda Mi è venuta in mente questa strana idea di rendere ciò che l'utente in realtà vuole impedire. Quindi, sopportami un po ':

Supponiamo che, per qualche motivo, potremmo fare in modo che il traffico inviato da un'applicazione specifica a un'altra entri in un router / dispositivo di instradamento perché il dispositivo di origine non può determinare da solo dove deve inviare il pacchetto. Ciò significa che anche nomi come "localhost" o indirizzi IP come 127.0.0.1 non funzionano con questo dispositivo sorgente, ma piuttosto devono inviare tutto a un altro dispositivo per inviare le informazioni al suo dispositivo "destinazione" (che, lo sappiamo, è quello stesso server).

Quindi, semplificando e trasformandolo in una domanda reale: c'è un modo, a distanza possibile, di dirottare le tabelle di routing / interfacce di loopback / qualsiasi cosa serva per far sì che una macchina invii il suo traffico quando quelle comunicazioni sono dovrebbe essere interno?

Pensa a quanti server web hanno i loro database e invia richieste "interne" per la connessione con i dati ... i servizi TCP ... e come i firewall sono configurati per bloccare il traffico strano ma non tanto per il traffico . Questo mi ha fatto ticchettare e venire a fare questa strana domanda.

routing network

posta Alpha 19.08.2011 - 01:45

fonte

4 risposte

3

Credo che avresti bisogno di compromettere il kernel per farlo (ovviamente, se puoi compromettere il kernel, puoi fare qualsiasi cosa). Ho appena fatto alcuni test con IPTables e sembra che il traffico loopback elimini le funzionalità di NAT / PREROUTING, quindi penso che sia fuori dal controllo userspace (in Linux). Ovviamente i sistemi operativi varieranno, ma penso che in generale sia necessario compromettere il kernel per fare ciò che si vuole fare.

risposta data 19.08.2011 - 02:13

fonte

1

È un'ipotesi, ma penserei che la maggior parte degli stack di rete nei sistemi operativi aggirerebbe le interfacce esterne nelle richieste localhost. Sicuramente per ragioni di sicurezza, ma più per motivi di prestazioni.

risposta data 19.08.2011 - 02:09

fonte

1

In nessun modo se non si ha qualche grave errore nel codice di rete che può essere attivato da remoto ma anche questo bug può rendere l'host incapace di comunicare tra loro → Bassa probabilità di successo. Inoltre, è troppo complicato rispetto ad altri tipi di attacchi, quindi non è quasi realistico.

risposta data 19.08.2011 - 05:02

fonte

Leggi altre domande sui tag routing network

È una truffa? Se sì, come funziona? È possibile ripetere RSA (o qualsiasi algoritmo di chiave pubblica / privata) per grandi quantità di dati?

score 8 · Accepted Answer

Ci sono molte speculazioni, proviamo.

Assegnazione di 127.0.0.1/8 all'interfaccia di rete

Su Debian funziona come root per assegnare 127.0.0.1/8 all'interfaccia di rete:

# ifconfig lo 10.0.0.1 netmask 255.0.0.0
# ifconfig eth0 127.0.0.2 netmask 255.0.0.0

e risulta in:

lo        Link encap:Lokale Schleife  
          inet Adresse:10.0.0.1  Maske:255.0.0.0
...
eth0      Link encap:Ethernet  Hardware Adresse 
          inet Adresse:127.0.0.2  Bcast:127.255.255.255  Maske:255.0.0.0
...

il ping 127.0.0.1, tuttavia, fallisce con un errore di argomento illegale:

 $ ping 127.0.0.2
 PING 127.0.0.2 (127.0.0.2) 56(84) bytes of data.
 64 bytes from 127.0.0.2: icmp_seq=1 ttl=64 time=0.030 ms

 $ ping 127.0.0.1
 connect: Invalid argument

Quindi questo è qualcosa che deve essere esaminato in modo più dettagliato analizzando il codice sorgente.

Puntare "localhost" a un altro indirizzo IP

Modifica di / etc / hosts come root in modo che punti localhost a un altro indirizzo ip:

ping localhost
PING localhost (209.85.149.147) 56(84) bytes of data.
64 bytes from localhost (209.85.149.147): icmp_seq=2 ttl=57 time=165 ms

Se questo è un problema o meno dipende dalla situazione: il client può inviare una password senza convalidare il server non usando ssl o fidandosi di alcun certificato (ci sono certificati di test per localhost là fuori che sono firmati da CA accreditate ). Questa password potrebbe essere riutilizzata altrove o il server potrebbe accettare connessioni da altre interfacce perché è comunque protetto da password.

Nella configurazione standard il file host ha la precedenza su NIS e DNS, che richiede un accesso root locale e rende questo tipo di attacco inutile. Ma se la priorità è stata modificata, è sfruttabile utilizzando i server DNS o NIS.