Ayer se anunció una
vulnerabilidad en GNU Bourne Again Shell (Bash) (
CVE-2014-7169) originalmente
encontrada por Stephane Schazelas. La vulnerabilidad
permite la ejecución de código arbitrario en Bash
al establecer variables de entorno específicos. Más tarde Travis
Ormandy lanzó un segundo
exploit que funcionaba en sistemas parcheados
porque los parches lanzados ayer eran incompletos.
Tod Beardsley, administrador de ingeniería en la firma de ciberseguridad
Rapid7,
advirtió de que el error tenía una nota de gravedad "10", lo que
significa que tiene un impacto máximo, y una calificación "baja" en
complejidad de explotación, lo que significa que es relativamente fácil
de utilizar por piratas informáticos para lanzar ataques.
"Al usar esta vulnerabilidad, los atacantes potencialmente pueden
tomar el control del sistema operativo, acceder a información
confidencial, hacer cambios, etc. Cualquiera con sistemas que ocupen
Bash deben aplicar el parche inmediatamente", dijo Beardsley.
Muchos formas de atacar
En las pocas horas que lleva
In-the-Wild, ya han aparecido
exploit y
PoC para lograr (RCE) Remote Code Execution (RCE), ataques web que permiten
subir código y shell a sitios web, y
troyanos que permiten realizar
ataques de DDoS, BruteForce sobre usuarios y contraseñas de la red y
robo de información a distintas direcciones IP que
han ido cambiando durante el día e incluso ya se han visto
gusanos explotando la vulnerabilidad. Basicamente estamos hablando de un troyano ELF que permite
DDoS, Flooder, Scanner, Bot-Backdoor y Login bruter, R00ter.
Uno de los troyanos bautizados como
ELF_BASHLITE, ELF Linux/Bash0day o Shellshock o Bashroot ha sido analizado por TrendMicro.
¿Cuál es el impacto de la vulnerabilidad?
Al principio, la vulnerabilidad no parece tan grave pero la realidad es
que se puede ejecutarse código remoto simplemente establecimiento de una
variable de entorno y sin que el usuario se percate de la situación.
El escenario más problemático parece ser cuando un
Bash scripts es ejecutado mediante cgi-bin. La especificación CGI requiere que el servidor web convierta la solicitud de los
headers HTTP suministrados por el cliente y las transforme en variables de entorno.
Entonces, se puede aprovechar que Apache "transforma" las cabeceras en
variables de entorno: por ejemplo el User-Agent se introducirá como
valor de la variable de entorno HTTP_USER_AGENT de Apache. Si un script
Bash se llama vía
cgi-bin, un atacante puede utilizar estas variables para ejecutar código que el servidor web.
Otros escenarios probables involucran SSH al momento de establecer
variables de entorno, pero tendrían que establecerse en el servidor en
un archivo de configuración. Otra alternativa es mediante
clientes DHCP que en algunos casos ejecutan scripts
Bash y utilizan variables de entorno suministradas por el servidor.
Esta PoC de TrustSec muestra como se puede
insertar código en la opción 114 (default-url)
del servidor DHCP para explotar la vulnerabilidad. Este caso puede ser
explotable si el usuario se conecta a un servidor DHCP no confiable (
"cofeehouse wifi").
¿Debo aplicar el parche?
Sí pero el parche va a arreglar sólo algunos de los aspectos de la
vulnerabilidad y no soluciona totalmente la vulnerabilidad. Aún se
desconocen los efectos secundarios del parche y de las distintas
opciones de ataques que podrían existir.
La mayoría de distribuciones Linux ya han distribuido un primer parche,
aunque está incompleto y no acaba de corregir del todo la
vulnerabilidad.
Por su parte los usuarios de Apple estan expuestos ya que los de
Cupertino no han dado ninguna respuesta aunque estos sistemas suelen
estar menos expuestos a Internet, y en última instancia ya hay
instrucciones para parchear su instalación.
¿Cuáles son mis otras opciones? ¿Qué debo hacer?
Puesto que el parche es incompleto, se debería intentar implementar
medidas adicionales para proteger los sistemas. Algunos vendedores de
sistema de detección de intrusiones (IDS) y Firewall de aplicaciones Web
(WAF) han publicado las reglas para bloquear la explotación pero las
reglas aún podrían estar incompletas porque sólo buscan la cadena
"() {" que estaba presente en la prueba inicial.
Una alternativa sería cambiar la
shell por defecto para una alternativa como
ksh o sh pero esto podría generar errores en algunas secuencias de comandos determinadas.
En sistemas embebidos se podría utiliza la
shell alternativa como
Busybox que no es vulnerable.
¿Cómo puedo encontrar sistemas vulnerables?
Si puede iniciar sesión en el
sistema y se puede
utilizar algunas de las cadenas de test publicadas, como la siguiente:
env x='() { ;;}; echo vulnerable' sh -c "echo this is a test"
Si ya se ha aplicado el parche, se puede utilizar este comando:
env X='() { (a)=>' sh -c "echo date";
Este comando devolverá un error en un sistema totalmente parcheado, pero creará un archivo vacío denominado
"echo".
Existen varios módulos para escáneres de vulnerabilidad que buscan
sistemas vulnerables. También se puede utilizar una búsqueda en Google
para encontrar servidores web vulnerables. Por ejemplo:
filetype:sh inurl:cgi-bin site:[su_dominio].
Además se debe controlar los servidores web en sistemas embebidos como
routers para que no pueden ejecutar secuencias de comandos
bash con privilegios elevados.
Más información
Distintos medios se han hecho eco de la noticia publicando distinto tipo de información e ISC ha
publicado un video al respecto y
slides PDF con más información.
Redhat por su parte mantiene la información permanentemente actualizada.
Además, se puede utilizar
esta herramienta para revisar los servidores propios.
Seguiremos actualizando...
Cristian de la Redacción de Segu-Info