Los autores de este artículo argumentan en contra de los mecanismos estándar de cifrado de claves en OpenSSH.Los atacantes utilizaron recientemente el paquete npm eslint-scope para robar tokens npm de los directorios de inicio de los usuarios. A la luz de este evento, comenzamos a verificar otras vulnerabilidades similares y pensamos en cómo reducir los riesgos y las consecuencias de tales incidentes.
La mayoría de nosotros tenemos a mano una clave RSA SSH. Esta clave le da al propietario una variedad de privilegios: como regla, se usa para acceder al entorno de producción o en GitHub. A diferencia de los tokens nmp, las claves SSH están encriptadas y, por lo tanto, generalmente se acepta que no sucederá nada malo, incluso si caen en las manos equivocadas. ¿Pero es realmente así? Averigüemos
user@work /tmp $ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): mykey
...
user@work /tmp $ head -n 5 mykey
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,CB973D5520E952B8D5A6B86716C6223F
+5ZVNE65kl8kwZ808e4+Y7Pr8IFstgoArpZJ/bkOs7rB9eAfYrx2CLBqLATk1RT/
Esta clave está encriptada, como lo indica una de las primeras líneas del archivo. Además, al principio no hay una clave de codificación MII - base64 utilizada en RSA. Y, por supuesto, ¡AES te llama la atención! Está bien, ¿verdad? Y CBC, a primera vista, con un vector de inicialización aleatorio. No hay código de autenticación (MAC). Bueno, entonces, no habrá ataque de oráculo de relleno, ¿verdad?
Descubrir lo que realmente significa el contenido de DEK-Info no es tan simple. Una búsqueda de la palabra clave "DEK-Info" en el repositorio de openssh-portable muestra solo ejemplos de claves. Pero el punto aquí es que la clave AES no es más que un simple hash MD5 (contraseña || vector de inicialización [: 8]). Y esto es malo, porque las mejores prácticas para almacenar contraseñas dicen que las contraseñas en su forma pura, debido a su baja entropía, son material de cifrado incorrecto. Y para hacerlo mejor, necesita una función costosa como Argon2. Pero MD5, a diferencia de este último, es fácil de calcular.
El único punto positivo en este esquema es que la sal se coloca después de la contraseña, por lo tanto, no funcionará para calcular el estado intermedio MD5 (IV [8:]) y encontrar las contraseñas basadas en él. Pero esto es un pequeño consuelo, especialmente en una era en la que las máquinas que hacen miles de millones de llamadas MD5 por segundo están disponibles para nosotros, más de lo que las contraseñas pueden generar.
Quizás se pregunte cómo vivió OpenSSH para ver esto. Lamentablemente, la respuesta es simple: la herramienta de línea de comandos OpenSSL inicialmente usó este esquema por defecto, y simplemente se convirtió en la norma.
Al final, se hace realidad que las claves cifradas con contraseña estándar no son mejores que las claves no cifradas normales simplemente porque el mecanismo de cifrado no es efectivo. Sin embargo, hablaríamos aún más audaces: son peores. Y es fácil discutir.
Es poco probable que muchas personas usen un administrador de contraseñas para almacenar la contraseña de la clave SSH. Más bien, el usuario simplemente lo recordará. Y, dado que esta es una de las combinaciones memorizadas, es probable que el usuario ya la haya usado en otro lugar. Quizás incluso coincida con la contraseña de usuario del dispositivo. Es bastante posible adivinarlo (su función formativa es demasiado poco confiable), y si se conoce la contraseña, probablemente pueda verificarla con la clave pública.
No hay quejas sobre el par de claves RSA: la única pregunta es los métodos de cifrado simétrico de la clave privada. Es imposible llevar a cabo el ataque descrito anteriormente, conociendo solo la clave pública.
¿Cómo puedo arreglar la situación?
OpenSSH proporciona un nuevo formato de clave para usar. Por nuevo se entiende introducido en 2013. Este formato utiliza bcrypt_pbkdf, que es esencialmente un bcrypt de complejidad fija implementado bajo el estándar PBKDF2.
Convenientemente, usted recibe automáticamente una clave en un nuevo formato cuando genera claves Ed25519, porque el antiguo formato de clave SSH no admite nuevos tipos de claves. Esto es bastante extraño, porque en realidad no necesitamos el formato de clave para determinar cómo funciona la serialización Ed25519, ya que el propio Ed25519 establece el trabajo de serialización. Pero si realmente necesita una buena función formativa, entonces no puede molestarse con tales pequeñeces. Como resultado, una de las respuestas es
ssh-keygen -t ed25519 .
Si, por razones de compatibilidad, debe cumplir con RSA, puede usar ssh-keygen -o. Por lo tanto, se puede obtener un nuevo formato incluso para los viejos tipos de claves. Puede actualizar las claves antiguas con el comando
ssh-keygen -p -o -f key name . Si sus claves viven en Yubikey o tarjetas inteligentes, entonces estas enmiendas ya se han tenido en cuenta.
De una forma u otra, nos esforzamos por una salida más óptima. Por un lado, hay un buen ejemplo de aws-vault, en el que la información de credenciales se movió del disco a los llaveros. Hay otro enfoque: mover el desarrollo a entornos compartidos. Finalmente, la mayoría de las nuevas empresas deberían considerar abandonar el almacenamiento a largo plazo de claves SSH y mudarse a un centro de certificación SSH con un tiempo de almacenamiento de claves limitado junto con un sistema de inicio de sesión único. Desafortunadamente, en el caso de GitHub, este enfoque no es posible.
PD: Es difícil verificar esta información en una fuente autorizada, pero si la memoria nos sirve bien, el parámetro versionado en las claves privadas del formato OpenSSH PEM solo afecta el método de cifrado. Sin embargo, esto no juega ningún papel: el problema es la función de formación de claves, y creemos que este es otro argumento en contra de discutir los protocolos en partes. Habrá una publicación separada sobre este tema en nuestro blog.
Y finalmente, un
enlace a la clave completa. Esto es en caso de que esté configurado para hackear algo hoy.
