SSH: reutilizando claves públicas y hombre conocido en el medio

Finalmente, creo que lo tengo.

En primer lugar, en mi descripción he mezclado los protocolos ssh v1 y ssh v2. La autorización de desafío-respuesta es de ssh v1.

En el cliente ssh v2 simplemente firma un paquete específico con su clave privada y el servidor lo comprueba usando una clave pública almacenada. Este paquete se describe en rfc, aquí :

To perform actual authentication, the client MAY then send a
signature generated using the private key.  The client MAY send the
signature directly without first verifying whether the key is
acceptable.  The signature is sent using the following packet:

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication
  string    signature

The value of 'signature' is a signature by the corresponding private
key over the following data, in the following order:

  string    session identifier
  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication

Por lo tanto, el paquete firmado contiene el "identificador de sesión" que se calcula de la siguiente manera :

  H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)
  <…..>
  mpint     K, the shared secret  

Es decir, la firma depende del secreto compartido, y los secretos compartidos son diferentes para P1 < - > S1 y S1 & lt ; - > S2 túneles.

  

Generalmente, las personas recomiendan usar un solo par de claves público-privadas en todas partes (si no estamos hablando de una posibilidad de comprometer la clave privada)

Tenga en cuenta que hay dos pares de claves involucrados en una conexión SSH:

• uno para identificar el servidor host (el servidor tiene la clave privada);
• uno para identificar al usuario (el cliente tiene la clave privada), si usa una autenticación de clave pública.

Las recomendaciones que cita son sobre las claves de usuario. Tener una única clave privada por usuario es un modelo viable, aunque no lo recomiendo particularmente (el costo de tener pares de claves separados por host o sitio no es tan alto). Las claves del servidor, por otro lado, nunca se duplican. Se generan de nuevo cuando se instala el servidor SSH.

Sobre este tema, más allá de las publicaciones que ha citado en su pregunta, consulte también ¿Cuál es la diferencia entre authorized_keys y known_hosts para SSH?

En el ataque que describe, ha mezclado los roles de las teclas. Estas son las claves de host, ssh_host_rsa , y no las claves de usuario. Esto no es directamente relevante en cómo funciona el ataque que describe, pero puede ser parte de su confusión.

El punto fijo está en el paso 3.3:

  

PC1 acepta la huella digital de S1_id_rsa.pub (como se la conoce)

Hay dos casos.

• Si la PC1 se conectó a S2 anteriormente, entonces la PC1 (o más precisamente la cuenta del usuario en la PC1) ha memorizado la clave pública del host de S2 en su archivo known_hosts . Por lo tanto, si S1 envía la clave de host de S2, el cliente SSH en PC1 detectará que la supuesta clave de host no coincide con la clave de host registrada y abortará la conexión con un mensaje aterrador:

  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that the RSA host key has just been changed.
  

  Por lo tanto, el ataque es imposible en este escenario (a menos que el usuario salga de su camino para evitar la comprobación, OpenSSH lo hace difícil a propósito).

• Si la PC1 nunca se ha conectado a S2, entonces la PC1 aceptará con gusto cualquier cosa que S1 diga ahora que es la clave de S2. Dado que PC1 no tiene conocimiento previo de ninguna asociación entre el nombre S2 y una identidad criptográfica, ni ninguna forma de contactar a un tercero de confianza que conozca dicha asociación (es decir, una infraestructura de clave pública), no hay manera de evitar que esto ocurra. ataque en el medio.

El problema es que el cliente sabría que está hablando con el servidor 1 debido al uso del certificado del servidor 1. Si server1 tiene un certificado válido que indica que son server2, entonces el cliente no sabría si no se había conectado a server2 anteriormente. Sin embargo, la mayoría de los clientes SSH rastrean la huella digital del certificado al que se conectan para un servidor determinado. Cuando el cliente se conecta y termina con una conexión al servidor 1, incluso si el certificado está firmado, es probable que el usuario reciba una advertencia de que la huella digital ha cambiado.

En cuanto a una conexión conocida con S1 que intenta ser s2, si s2 conoce con precisión la clave privada de p1, s si 01 quiere hablar con s2 a s1, entonces debe cifrar para s2 y s2 luego se cifrará para p1 . Cuando p1 no obtiene un intercambio de claves desde s2, sabrá que hay un problema ya que s1 no puede firmar un intercambio con p1 como s2.

En realidad, se trata de una vulnerabilidad conocida con certificados resquebrajados en la lista de confianza y por qué son necesarias las listas de revocación.

Para que este ataque funcione, debe haber 2 agujeros:

1. PC1 debe pensar que se está comunicando con server2 mientras que en realidad se está comunicando con server1.
2. PC1 debe tener S1_id_rsa.pub como certificado de confianza y apunta a la dirección del servidor2 (de otra manera, PC1 sabrá que está hablando con server1 en lugar de server2 en el paso # 4.3).

El # 1 puede suceder en una red que no es de confianza, mientras que el # 2 solo puede suceder cuando ha ocurrido una violación anterior que permitió al servidor1 insertarse como parte confiable.