¿Se puede secuestrar la interfaz de loopback?

Question

¿Se puede secuestrar la interfaz de loopback?

#1 de Hendrik Brummermann (7 votos)
#2 de gowenfawr (3 votos)
#3 de Steve (1 votos)
#4 de poige (1 votos)

5

Inspirado por this question Se me ocurrió esta idea extraña de hacer lo que el usuario realmente quiere evitar. Entonces, tengan paciencia conmigo un poco:

Supongamos que, por algún motivo, podemos hacer que el tráfico enviado de una aplicación específica a otra viaje a un enrutador / dispositivo de enrutamiento porque el dispositivo de origen no puede determinar por sí mismo a dónde tiene que enviar el paquete. Esto significa que incluso nombres como "localhost" o IPs como 127.0.0.1 no funcionan para este dispositivo de origen, sino que tienen que enviar todo a otro dispositivo para enviar la información a su dispositivo de "destino" (que, sabemos, es eso mismo servidor).

Entonces, simplificando y convirtiéndolo en una pregunta real: ¿hay alguna manera, a distancia como podría ser, de secuestrar tablas de enrutamiento / interfaces de bucle de retorno / lo que sea necesario para hacer que una máquina envíe su tráfico cuando esas comunicaciones son ¿Se supone que es interno?

Piensa en cuántos servidores web tienen sus bases de datos allí y envía solicitudes "internas" para la conexión con datos ... servicios TCP ... y cómo los firewalls están configurados para bloquear el tráfico extraño pero no tanto para el tráfico. . Esto me hizo marcar y venir y hacer esta pregunta extraña.

network routing

pregunta Alpha 19.08.2011 - 01:45

fuente

4 respuestas

3

Creo que deberías comprometer el kernel para hacer esto (por supuesto, si puedes comprometer el kernel, puedes hacer cualquier cosa). Acabo de hacer algunas pruebas con IPTables y parece que el tráfico de bucle invertido pasa por alto las capacidades de NAT / PREROUTING, por lo que creo que está fuera del control del espacio de usuario (en Linux). Los sistemas operativos variarán, por supuesto, pero creo que, en general, necesitas comprometer el kernel para hacer lo que quieras hacer.

respondido por el gowenfawr 19.08.2011 - 02:13

fuente

1

Es una suposición, pero creo que la mayoría de las pilas de redes en sistemas operativos omitirían las interfaces externas en las solicitudes de localhost. Ciertamente por razones de seguridad, pero más por razones de rendimiento.

respondido por el Steve 19.08.2011 - 02:09

fuente

1

De ninguna manera, a menos que tenga algún error grave en el código de red que puede activarse de forma remota, pero este error también puede hacer que el host no pueda intercomunicarse en absoluto → Baja probabilidad de éxito. Además, es demasiado complicado en comparación con otros tipos de ataques, por lo que casi no es realista.

respondido por el poige 19.08.2011 - 05:02

fuente

Lea otras preguntas en las etiquetas network routing

¿Versión moderna del archivo de prueba EICAR? ¿Cómo la vulnerabilidad originada en Facebook Origin de Access-Control-Allow-Origin: null permitió el acceso de origen cruzado?

score 7 · Accepted Answer

Hay muchas especulaciones, intentémoslo.

Asignando 127.0.0.1/8 a la interfaz de red

En Debian funciona como root para asignar 127.0.0.1/8 a la interfaz de red:

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

y resultados en:

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
...

ping 127.0.0.1, sin embargo, falla con un error de argumento ilegal:

 $ 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

Por lo tanto, esto es algo que debe analizarse con más detalle al analizar el código fuente.

Señalando "localhost" a otra dirección IP

La edición de / etc / hosts como root para que localhost apunte a otra dirección IP funciona:

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

Si se trata de un problema o no, depende de la situación: el cliente puede enviar una contraseña sin validar el servidor ya sea no utilizando ssl o confiando en ningún certificado (hay certificados de prueba para localhost que están firmados por CA confiables). ). Esta contraseña se puede reutilizar en otro lugar o el servidor puede aceptar conexiones de otras interfaces porque de todos modos está protegida por contraseña.

En la configuración estándar, el archivo host tiene prioridad sobre NIS y DNS, lo que requiere acceso local a la raíz y hace que este tipo de ataque sea inútil. Pero si se cambió la prioridad, esto se puede explotar utilizando los servidores DNS o NIS.