La semana pasada, Qualys publicó un aviso de seguridad que expuso vulnerabilidades (CVE-2016–0777 y 0778) en las versiones 5.4 a 7.1 del cliente OpenSSH. Cuando se explotan, estas vulnerabilidades pueden resultar en el hurto de material de clave privada. Para eliminar la vulnerabilidad, los administradores pueden aplicar parches a OpenSSH con la versión 7.1p2 o configurar clientes SSH existentes para deshabilitar la función explotable.
Descubrir versiones vulnerables de software como OpenSSH en una empresa de cualquier escala es un problema importante, ya que la mayoría de las empresas carecen de la capacidad básica de ver todos los puntos finales dentro de su red. Cualquier cosa que desee hacer a un solo sistema, como eliminar procesos, poner en cuarentena sistemas o implementar parches, en todos los puntos finales puede ser difícil, que es uno de los motivos por los que Tanium es un excelente recurso.
Investigación inicial
Después de leer la versión de Qualys, necesitábamos intentar encontrar más información sobre las soluciones alternativas, idealmente de las personas que proporcionaban el parche. Theo de Raadt, una autoridad sobre el tema, publicó una directiva de configuración no documentadaUsarRoaming no que evita que aparezca el error. A primera vista, parecía que la solución alternativa sería trivial: simplemente prepare un script shell para agregar la entrada al archivo de configuración. Una discusiónrelacionada notó astutamente que agregar la configuración al archivo de configuración podría fallar si el archivo de configuración define patrones de host. Por lo tanto, el script debe anexar el ajuste de configuración para todos los hosts:
Implementación rápida de un script en máquinas vulnerables
La modificación de archivos de configuración activos en masa debe poner nervioso a cualquier administrador racional. Esto no es algo que se deba hacer sin una medida de precaución y un plan de retroceso. Si modificamos el archivo, ¿cómo podemos deshacer los cambios rápidamente en uno o todos los sistemas? Comenzamos haciendo una copia de seguridad de nuestra configuración existente en un nuevo archivo y luego aplicandoUseRoaming sin corrección a ssh_config:
En las primeras pruebas, descubrimos que la bandera -e para eco no está disponible en todos los sistemas, por lo que optamos por usar la construcción de $’’ para la portabilidad. Por lo tanto, mejoramos el comando con lo siguiente:
Volvimos a probar en un solo sistema. Esta es una imagen que representa las últimas líneas del archivo anterior, ejecutando manualmente la corrección a través de la línea de comandos y las últimas líneas del archivo de configuración modificado:
Probamos el caso periférico de agregar la corrección varias veces al archivo de configuración y determinamos que el cliente ssh continúa funcionando con la redundancia. Desde el punto de vista operativo, esta es una buena protección, pero notamos que esto es algo que limpiar más adelante en el desarrollo.
Seguridad ante fallas
Lo más simple es copiar el archivo de copia de seguridad sobre el archivo de configuración. Idealmente, nunca tendríamos que hacer esto, pero es una onza de prevención que podría pagar dividendos graves y proporcionar confianza adicional a medida que remediamos rápidamente en toda la empresa.
El script es básico:
Determinar el alcance de la vulnerabilidad de OpenSSH
Ahora que tenemos scripts para aplicar y eliminar la corrección, es momento de escribir otro script para determinar la aplicabilidad. Envolveremos este script en un sensor Tanium para que podamos ejecutar la consulta en toda la red de puntos finales. Dado que varias pruebas demostraron que la solución alternativa tiene un impacto positivo, el método más simple disponible para nosotros es verificar que ssh_config contenga la salida que se pretendía a partir de la corrección.
Para la transferibilidad, el método de implementación que elegimos era una línea única, que imprime las líneas de un archivo que existen entre otras coincidencias de expresión regular:
Esto coincide solo con los casos en los que se ha escrito en el archivo la secuencia de corrección completa de tres líneas. Optamos por devolver una cadena de “Posiblemente vulnerable” en lugar de “Vulnerable” porque nuestras soluciones funcionan independientemente de la versión de OpenSSH. Al lanzar una red más amplia, independiente de la versión, no necesitaremos actualizar nuestro código si los investigadores continúan exponiendo vulnerabilidades adicionales a la misma característica de itinerancia de OpenSSH. (La función Roaming nunca es útil en la práctica, por lo que una desactivación basada en la configuración fortalece la seguridad sin afectar negativamente las operaciones). Algunos podrían recordar Shellshock, que requirió un par de intentos y actualizaciones de software antes de que la comunidad hiciera todo bien. Nuestro enfoque proporciona resiliencia contra este resultado que se repite con el cliente SSH.
Esta es la salida de nuestra prueba contra un archivo ssh_config predeterminado:
Y ahora contra uno que acabamos de arreglar:
¡Esto se ve bien! Luego, envolvimos estos scripts en un Tanium Sensor al que llamaremos “Estado de solución alternativa de fuga clave de SSH”.
Configuraciones de SSH específicas del usuario y pulir el contenido
Mientras investigábamos, no encontramos muchos en la comunidad analizando máquinas en las que los usuarios pueden haber definido sus propios archivos ~/.ssh_config. Debido a que estos ajustes reemplazarían a las configuraciones globales, las correcciones deben aplicarse aquí para cerrar la vulnerabilidad. Esto nos llevó a mejoras adicionales de nuestro contenido que también pasan por los directorios de inicio. Debido a las diferencias de plataforma, terminamos con dos versiones diferentes de los scripts para admitir SO X y *nix sabores por igual.
Además, mejoramos la lógica de nuestros scripts anteriores que aplicaron la corrección para que no la apliquemos varias veces e inflamos los archivos de configuración. Son lo suficientemente largos como para ya no encajar ordenadamente en una publicación de blog, pero aún así son un poco más de 40 líneas de código y comentarios.
Nuestro resultado final es una solución que identifica los sistemas como “Posiblemente vulnerables” en *nix y sistemas OS X en segundos. Si algún archivo de configuración de SSH residente no contiene la mitigación para proteger la empresa, los usuarios pueden aplicar o revertir la corrección a cualquiera o todos los sistemas de la empresa en solo un par de minutos.
Tanium la plataforma
Tanium facilita abordar la vulnerabilidad de OpenSSH porque proporciona la única visibilidad en tiempo real de la industria sobre el estado de todos los puntos finales, independientemente de la cantidad de máquinas. La plataforma es la forma más rápida y fácil de implementar el enfoque descrito en esta publicación: comenzar con información de fuentes de buena reputación, desarrollar scripts, escalar pruebas y refinar y luego implementar completamente lo que esencialmente se convierte en una nueva función de la plataforma.
Háganos saber lo que piensa o comuníquese con su gerente de cuentas técnicas si está interesado en ejecutar los contenidos en su propia implementación. Si no está familiarizado con Tanium y desea obtener más información, comuníquese con nosotros para obtener una demostración.
Rory Prendergast, director sénior
Peter Oelschlaeger, director sénior
¿Le interesa ver a Tanium en acción? Programe una demostración personalizada o asista a nuestro seminario web semanal. Hable con nuestros expertos de Tanium en nuestros próximos eventos.
