¿Sabías que el protocolo Secure Shell (SSH) se creó en 1995? ¡Sí, seguro que lo fue! De hecho, un investigador de la Universidad de Helsinki inventó el protocolo como resultado directo de presenciar de primera mano un ataque de rastreo de contraseñas. El ataque implicó capturar contraseñas transmitidas a través de la red por usuarios de los sistemas de la universidad. Este incidente destacó las vulnerabilidades en la transmisión de contraseñas y datos no cifrados a través de la red y, para abordar esto, Ylönen desarrolló la primera versión de SSH para garantizar un método seguro para iniciar sesión en otra computadora a través de una red. SSH rápidamente se hizo popular por su capacidad de proporcionar comunicaciones cifradas seguras entre dos hosts que no son de confianza a través de una red insegura.
Pero pensemos en esto… cualquier cosa que se haya creado allá por 1995 (tecnológicamente hablando, por supuesto) es muy susceptible de verse comprometida, aunque no sólo por pura edad. Los piratas informáticos y otros malos actores han tenido literalmente décadas para “descifrar la llave” (juego de palabras totalmente intencionado). ¿No entiendes ese chiste? Es cierto que no es mi mejor material, pero considere esto…
Durante el proceso de autenticación, las llaves SSH a menudo establecen acceso directo, privilegiado o root a una variedad de sistemas críticos, convirtiendo efectivamente estos activos criptográficos en credenciales privilegiadas. Las llaves SSH tienen el mismo acceso que las contraseñas, pero cuando la mayoría de las personas piensan en proteger sus credenciales privilegiadas, se olvidan de las llaves SSH. Como resultado, estas llaves pueden caer fácilmente en las manos equivocadas y, en lugar de proteger nuestros activos más importantes, se convierten en “llaves maestras virtuales”.
Aquí hay algunos ejemplos de ataques e infracciones relacionados con SSH a lo largo de los años…
T-Mobile (2021-Siempre?)
Nuestros amigos de T-Mobile han estado pasando por esto desde hace un tiempo. En 2021, los piratas informáticos pudieron robar la información personal (INCLUYENDO LOS NÚMEROS DEL SEGURO SOCIAL) de más de 54 millones clientes en un ataque de ransomware. Los piratas informáticos obtuvieron acceso a la API y demostraron su conexión SSH mediante una captura de pantalla. T-Mobile dijo en ese momento que estaban comprometidos con “una inversión sustancial de varios años” para impulsar su ciberseguridad luego del hack de 2021, afirmando que había “logrado un progreso sustancial hasta la fecha”. Sí claro. …simplemente volvió a suceder.
Brecha de Seguridad de RSA (2011)
En esta infracción de hace bastante tiempo, los atacantes comprometieron el sistema SecurID de RSA. Si bien el método exacto de entrada inicial no se reveló oficialmente, los informes sugirieron que la infracción podría haber involucrado una mala gestión de llaves SSH, entre otras posibles vulnerabilidades.
Operation Aurora (2009-2010)
Se trató de una serie de ciberataques realizados por actores de amenazas persistentes avanzadas (APT) contra Google y varias otras empresas. Los atacantes utilizaron una combinación de técnicas y, aunque SSH no fue el principal vector de ataque, se identificaron llaves SSH inseguras como una de las posibles debilidades que podrían haber sido explotado.
Incidente de GitLab (2017)
GitLab, una herramienta de ciclo de vida de DevOps basada en web, experimentó un incidente de eliminación de datos debido a un error de un empleado. La causa raíz no fue un ataque malicioso sino una eliminación de datos durante una sesión SSH accidental. Este incidente subraya los riesgos asociados con el acceso SSH potente en entornos críticos.
Incumplimiento del Gobierno Canadiense (2014)
El gobierno canadiense experimentó una infracción en la que el atacante obtuvo acceso no autorizado a la red del Consejo Nacional de Investigación. El método de intrusión no se indicó explícitamente, pero los informes sobre el incidente apuntaron a llaves SSH comprometidascomo vector potencial.
Incumplimiento de la Universidad de Maryland (2014)
La Universidad de Maryland informó sobre un robo de datos que expuso información personal. Si bien el vector de ataque específico no se reveló públicamente, los análisis de seguridad posteriores señalaron que SSH es una de las vías potenciales para los atacantes, particularmente a través de llaves SSH robadas o mal administradas.
Es importante no subestimar este problema al que todos nos enfrentamos en el esfuerzo actual por proteger la autenticación remota. Tenga esto en cuenta… Cuando un atacante obtiene acceso a una clave SSH privilegiada, puede acceder a todas las claves SSH almacenadas en esa máquina. ¿Qué significa esto exactamente? Son capaces de “arañar” toda la red y obtener acceso a todos sus datos. Vaya. Se han realizado investigaciones que indican que tan solo cinco claves SSH únicas pueden otorgar acceso a toda una empresa a través de la confianza de claves SSH transitivas. Cuando realmente lo pensamos, SSH es probablemente el punto más débil de su infraestructura en 2024.
Considerando todo esto, aquí están las 4 cosas principales que creemos que debe tener en cuenta con respecto a las vulnerabilidades SSH:
En una organización grande con más de 10 000 servidores, administrar más de un millón de llaves SSH puede ser un desafío abrumador, que a menudo roza lo poco práctico. ¿Cómo diablos se crean tantas llaves? A diferencia de las contraseñas o los certificados, los usuarios pueden crear (o duplicar) llaves SSH sin ningún control o supervisión central. Con el tiempo, a medida que estas llaves se acumulan, a una organización le resulta cada vez más difícil realizar un seguimiento de ellas. Por ejemplo, es posible que las llaves SSH no se administren adecuadamente cuando los servidores de desarrollo se trasladan a producción, especialmente si no se eliminan las credenciales de desarrollo originales, o cuando un empleado deja la empresa sin que se eliminen sus llaves. El riesgo potencial aquí es significativo: las llaves SSH no monitoreadas podrían otorgar a los atacantes un acceso privilegiado y sostenido a la red de una empresa. Si dicha llave, que no se elimina, cae en las manos equivocadas, podría servir como un punto de acceso permanente a la red, permitiendo a los atacantes hacerse pasar por el propietario legítimo de la llave. …¿recuerdas mi juego de palabras llave de antes? ¿No? …hacia adelante.
Por razones prácticas, es común ver que las claves SSH se comparten o replican entre un grupo específico de empleados, servidores u otros elementos de la infraestructura. Debido a esta práctica de replicación de claves SSH, una cantidad sorprendentemente pequeña de claves únicas, a veces tan solo 5 (¡ay!), puede proporcionar acceso a todos los sistemas de una empresa. Si bien este método podría simplificar las tareas de los departamentos de TI a corto plazo, irónicamente facilita la tarea a los atacantes durante un período más largo. Esta complejidad hace que sea difícil eliminar una sola clave sin interrumpir muchas otras conexiones SSH que dependen de la misma clave. Además, la práctica de compartir claves SSH plantea riesgos adicionales al disminuir la capacidad de rastrear acciones individuales y verificar la autenticidad de las transacciones, comprometiendo aspectos clave de la seguridad como la auditabilidad y el no repudio.
Gestionar la rotación de más de un millón de claves SSH es una tarea desalentadora para cualquiera, incluso para los ingenieros más experimentados. Debido a esto, muchos profesionales de TI y seguridad evitan actualizar y redistribuir estas claves con frecuencia. La renuencia a actualizar a menudo surge del miedo a pasar por alto un sistema o empleado crítico, lo que podría variar desde un inconveniente menor hasta una interrupción significativa en toda la organización. Como resultado, muchas empresas terminan con una gran cantidad de claves SSH sin cambios o estáticas. Esta situación crea una vulnerabilidad evidente. Si los atacantes logran adquirir una de estas claves estáticas, pueden usarla para navegar a través de la red de la empresa sin ser detectados, obteniendo potencialmente acceso continuo y no autorizado a su información y activos más confidenciales. No es ideal.
Si bien SSH es sin duda una piedra angular de la autenticación segura, sus prácticas de gestión y seguridad suelen estar repletas de desafíos. Es por eso que creamos EZSSH, haciendo que la autenticación SSH sin contraseña esté disponible (y asequible) ¡para todo el mundo! Desde la abrumadora tarea de administrar un gran volumen de claves hasta los riesgos que plantean las claves estáticas o integradas, los entornos SSH pueden abrir puertas sin darse cuenta a amenazas a la seguridad. Es esencial que las organizaciones consideren activamente el estado de su infraestructura clave SSH y sus implicaciones en la seguridad general. Dada la complejidad y los riesgos potenciales asociados con la gestión de claves SSH, es muy recomendable buscar más información y orientación de expertos. Ya sea reevaluando sus protocolos existentes o explorando nuevas estrategias de seguridad, consultar con un experto en autenticación SSH puede brindarle información valiosa y ayudarlo a fortalecer sus defensas contra amenazas cibernéticas sofisticadas. No dude en hacer de esto una prioridad; la seguridad y la integridad de su red pueden depender de ello. ¡Mira cómo funciona EZSSH hoy!
