La semana pasada, Qualys publicó un aviso de seguridad en el que se revelaban las vulnerabilidades (CVE-2016–0777 y 0778) presentes en las versiones 5.4 a 7.1 del cliente OpenSSH. Si se aprovechan, estas vulnerabilidades pueden dar lugar al robo de material de claves privadas. Para eliminar esta vulnerabilidad, los administradores pueden aplicar el parche de OpenSSH con la versión 7.1p2 o configurar los clientes SSH existentes para desactivar la función que puede ser objeto de explotación.
Detectar versiones vulnerables de software como OpenSSH en una empresa de cualquier tamaño supone un grave problema, ya que la mayoría de las empresas carecen de la capacidad básica para identificar todos los dispositivos finales de su red. Cualquier acción que desee realizar en un único sistema —como detener procesos, poner sistemas en cuarentena o aplicar parches— en todos los terminales puede resultar complicado, lo cual es una de las razones por las que Tanium es un recurso excelente.
Investigación inicial
Tras leer el comunicado de Qualys, necesitábamos intentar recabar más información sobre soluciones provisionales, a ser posible de quienes proporcionan el parche. Theo de Raadt, una autoridad en la materia, publicó una directiva de configuración no documentada UseRoaming no que evita que el error se manifieste. A primera vista, parecía que la solución sería sencilla: bastaba con crear rápidamente un script de shell para añadir la entrada al archivo de configuración. En un debate relacionado se señaló acertadamente que añadir la configuración al archivo de configuración podría fallar si dicho archivo define patrones de host. Por lo tanto, el script debe añadir el parámetro de configuración para todos los hosts:
Implementación rápida de un script en equipos vulnerables
Modificar de forma masiva los archivos de configuración activos debería inquietar a cualquier administrador sensato. No es algo que deba hacerse sin cierta precaución y sin un plan de contingencia. Si modificamos el archivo, ¿cómo podemos deshacer los cambios rápidamente en uno o en todos los sistemas? Comenzamos realizando una copia de seguridad de nuestra configuración actual en un nuevo archivo y, a continuación, aplicamos la corrección UseRoaming no al archivo ssh_config:
En las primeras pruebas, descubrimos que la opción -e de echo no está disponible en todos los sistemas, por lo que optamos por utilizar la construcción $’’ para garantizar la portabilidad. Por lo tanto, hemos mejorado el comando de la siguiente manera:
Hemos vuelto a realizar las pruebas en un único sistema. A continuación se muestra una imagen en la que se pueden ver las últimas líneas del archivo antiguo, la aplicación manual de la corrección mediante la línea de comandos y las últimas líneas del archivo de configuración modificado:
Hemos probado el caso extremo de añadir la corrección varias veces al archivo de configuración y hemos comprobado que el cliente SSH sigue funcionando a pesar de la redundancia. Desde el punto de vista operativo, se trata de una buena medida de seguridad, pero lo hemos señalado como algo que habrá que pulir en una fase posterior del desarrollo.
Sistema de seguridad ante fallos
Lo más sencillo es sobrescribir el archivo de configuración con el archivo de copia de seguridad. Lo ideal sería que nunca tuviéramos que hacer esto, pero se trata de una medida preventiva que podría reportar importantes beneficios y aportar una mayor confianza a medida que aplicamos rápidamente las soluciones en toda la empresa.
El guion es sencillo:
Determinar el alcance de la vulnerabilidad de OpenSSH
Ahora que disponemos de scripts para aplicar y eliminar la corrección, es el momento de escribir otro script para determinar si es aplicable. Incorporaremos este script a un sensor de Tanium para poder ejecutar la consulta en toda la red de terminales. Dado que varias pruebas han demostrado que la solución alternativa ha tenido un impacto positivo, el método más sencillo del que disponemos consiste en comprobar que el archivo `ssh_config` contenga el resultado previsto tras aplicar la corrección.
Para garantizar la portabilidad, el método de implementación que elegimos fue una línea única de awk, que muestra las líneas de un archivo que se encuentran entre otras coincidencias de expresiones regulares:
Esto solo se aplica a los casos en los que se haya escrito en el archivo la secuencia completa de corrección de tres líneas. Hemos optado por devolver la cadena «Potencialmente vulnerable» en lugar de «Vulnerable», ya que nuestra solución funciona independientemente de la versión de OpenSSH. Al ampliar el alcance de la búsqueda, independientemente de la versión, no tendremos que actualizar nuestro código en caso de que los investigadores sigan descubriendo nuevas vulnerabilidades en la misma función «Roaming» de OpenSSH. (La función de itinerancia nunca resulta útil en la práctica, por lo que desactivarla mediante la configuración refuerza la seguridad sin afectar negativamente al funcionamiento.) Quizá algunos recuerden , y Shellshock, que requirieron varios intentos y actualizaciones de software antes de que la comunidad lograra resolverlo todo correctamente. Nuestro enfoque garantiza la resiliencia frente a la posibilidad de que este problema se repita con el cliente SSH.
A continuación se muestra el resultado de nuestra prueba con un archivo ssh_config predeterminado:
Y ahora contra uno al que acabábamos de derrotar:
¡Esto tiene buena pinta! A continuación, hemos integrado estos scripts en un sensor de Tanium al que denominaremos «Estado de la solución provisional para la fuga de claves SSH».
Configuraciones de SSH específicas para cada usuario y pulido del contenido
Durante nuestra investigación, no hemos encontrado muchos comentarios en la comunidad sobre equipos en los que los usuarios pudieran haber definido sus propios archivos ~/.ssh_config. Dado que estos ajustes prevalecerían sobre las configuraciones globales, es necesario aplicar las correcciones aquí para subsanar la vulnerabilidad. Esto nos llevó a introducir nuevas mejoras en nuestro contenido, que ahora también recorre los directorios de inicio. Debido a las diferencias entre plataformas, acabamos creando dos versiones distintas de los scripts para dar soporte tanto a OS X como a las variantes de *nix.
Además, hemos mejorado la lógica de nuestros scripts anteriores que aplicaban la corrección, con el fin de evitar que se aplique varias veces y se sobrecarguen los archivos de configuración. Son lo suficientemente largos como para que ya no quepan perfectamente en una entrada de blog, pero siguen teniendo poco más de 40 líneas de código y comentarios.
El resultado final es una solución que identifica en cuestión de segundos los sistemas «potencialmente vulnerables» en entornos *nix y OS X. Si alguno de los archivos de configuración SSH locales no incluye la medida de mitigación necesaria para proteger la empresa, los usuarios pueden aplicar o revertir la corrección en cualquiera o en todos los sistemas de la empresa en tan solo un par de minutos.
Tanium, la plataforma
Tanium facilita la gestión de la vulnerabilidad de OpenSSH, ya que ofrece la única visibilidad en tiempo real del sector sobre el estado de todos los terminales, independientemente del número de equipos. La plataforma es la forma más rápida y sencilla de poner en práctica el enfoque descrito en esta entrada: comenzar con datos procedentes de una fuente fiable, desarrollar scripts, ampliar las pruebas y perfeccionar el proceso, para finalmente implementar por completo lo que, en esencia, se convierte en una nueva funcionalidad de la plataforma.
Háganos saber su opinión o póngase en contacto con su gestor técnico de cuentas si está interesado en implementar este contenido en su propio entorno. Si aún no conoce Tanium y desea obtener más información, póngase en contacto con nosotros en para solicitar una demostración.
Rory Prendergast, director sénior
Peter Oelschlaeger, director sénior
¿Le interesa ver cómo funciona Tanium? Concierte una demostración e individual o participe en nuestro seminario web semanal. Hable con nuestros expertos en Tanium en nuestros próximos eventos « » ().
