¿Los websockets representan un problema de seguridad para mi máquina local?

2

Para solucionar un problema con IntelliJ, se me recomendó configurar mi demonio Docker local para que funcione en el puerto 2375 sin autenticación TLS. Sin embargo, me preocupa que un sitio web malintencionado pueda conectarse al servicio Docker y lanzar contenedores.

He leído entradas de la lista de correo de 2015 que dicen que, en algún momento, a Chrome no se le permitirá conectarse a localhost por defecto, pero no sé si esto ya ha sucedido.

Nunca he oído hablar de este ataque, así que quizás no sea posible. ¿Hay algo autoritario que pueda leer para tranquilizarme?

    
pregunta Steve Rukuts 14.06.2017 - 11:40
fuente

3 respuestas

0

Actualización : parece que ahora hay un prueba de ataque concepto . Es 100% una vulnerabilidad de seguridad. Gracias rjdkolb por detectar eso.

Después de pasar un tiempo con la consola de Chrome puedo ver que es posible adjuntar a websockets y recibir eventos sobre contenedores. No estoy seguro de qué más puede hacer esta API, ya que no puedo encontrar mucho en términos de referencia, pero es lo suficientemente malo como para que pueda filtrar información confidencial sobre su estación de trabajo.

Recomiendo encarecidamente que nadie exponga su demonio Docker sin autenticación TLS. El manual de Docker dice que esto no es recomendable, ¡y esta es una razón por la cual!

    
respondido por el Steve Rukuts 14.06.2017 - 17:24
fuente
2

En una palabra, SÍ, los websockets SÍ representan un problema de seguridad para su máquina local.

En primer lugar, hay algunas aclaraciones sobre la diferencia entre el enlace a 127.0.0.1 y 0.0.0.0 ... ya que uno solo permitirá que su computadora se conecte y la otra permitirá que cualquier computadora de su red se conecte. AMBOS de estos son peligrosos, sin embargo, el enlace a 127.0.0.1 es un poco más seguro.

La mayoría de los navegadores web actuales (¿todos?) tienen limitaciones en lo que se conoce como scripts entre sitios. Esto significa que si una página alojada por foo.com intenta realizar una solicitud ajax a bar.com, fallará a menos que se permita explícitamente a través de CORS . Dicho esto ... websockets están NO limitados por CORS y, por lo tanto, no están disponibles. com podría, teóricamente, abrir una conexión websocket a 127.0.0.1 ... y tomar el control de su servicio docker.

Observaré que este no es un vector de ataque común, ya que requiere que el objetivo esté utilizando activamente un navegador web en un dispositivo que ejecuta la ventana acoplable con esta opción habilitada (rara) ... pero aún es una superficie de ataque.

Lectura adicional:

respondido por el CaffeineAddiction 14.06.2017 - 17:45
fuente
-1

Escenario 1: Atar a tu demonio docker a 0.0.0.0:2375 es una muy mala idea. Un atacante podría obtener acceso de root en su máquina host accediendo a la ventana acoplable. Caer a la raíz es mucho más difícil en estos días, pero es más seguro que lamentarlo. Un poco más de información aquí

El enlace a todas las interfaces permite que un atacante se conecte a tu demonio docker desde una máquina remota. Así que ellos pueden

EXPORT DOCKER_HOST=tcp://YOURIP:2376
docker ps
docker stop

Solución: Agregar a su usuario al grupo docker es una solución mucho mejor para protegerse.

Escenario 2: Enlace a localhost: 2375 no permite que su navegador acceda al puerto. Como se informa aquí: enlace , esto puede ser posible en Windows

Desde el enlace: "El ataque es multietapa. El primer paso, consiste en atraer al desarrollador que ejecuta Docker para Windows a una página web controlada por un atacante que aloja un JavaScript especialmente diseñado. Entre otras cosas, el JavaScript puede omitir la seguridad de la Política del mismo origen de un navegador, una protección de datos. característica encontrada en los navegadores modernos ".

En mis pruebas, esto es posible:

curl http://localhost:2375/info

Esto no es:

<!DOCTYPE html>
<html>

<body>
    <button onclick="myFunction()">Click me to get docker info</button>
    <p id="result"></p>

    <script>
function myFunction() {
    var xmlHttp = new XMLHttpRequest();
    xmlHttp.open( "GET", 'http://127.0.0.1:2375/info', false ); // false for synchronous request
    xmlHttp.send( null );
    document.getElementById("result").innerHTML = "It did not work";
    document.getElementById("result").innerHTML = xmlHttp.responseText;
}
</script>
</body>
</html>

El navegador devuelve: Solicitud de origen cruzado bloqueada: la misma política de origen no permite leer el recurso remoto en enlace . (Motivo: falta el encabezado CORS ‘Access-Control-Allow-Origin’).

Accediendo al demonio docker desde Java

Supongo que desea ejecutar la ventana acoplable como un usuario no root en un complemento de Maven o Gradle como docker-maven-plugin . La mejor manera de hacerlo es agregar su usuario al grupo de docker y, a continuación, no necesita enlazar con el puerto TCP.

    
respondido por el rjdkolb 14.06.2017 - 16:32
fuente

Lea otras preguntas en las etiquetas