Todo lo que debe saber sobre Bash

Bash, denominado también con el código CVE-2014-6271, es en realidad el intérprete de comandos más extendido en el mundo UNIX y derivados; sin embargo, una funcionalidad puede ser explotada hasta conseguir ejecutar código arbitrario en sistemas remotos. Un atacante puede simplemente ejecutar comandos a nivel de sistema, con los mismos privilegios que los servicios afectados.

Stephane Chazelas, investigador francés apasionado del mundo UNIX, fue quien difundió los detalles de esta vulnerabilidad. Hace ya varios años que en la página de manual de bash se dio a conocer que esta funcionalidad podría exportar funciones que los subshells definirían automáticamente con la opción –f. La definición de una función puede ser eliminada utilizando la opción –f para desconfigurar el archivo que se exportará (builtin).

En la mayoría de los ejemplos en internet en estos momentos, los atacantes están atacando de forma remota servidores web que alojan scripts CGI que se han escrito en bash o pasan valores a shell scripts. En el momento de la escritura, la vulnerabilidad ya se ha utilizado para fines maliciosos –infectar servidores web vulnerables con malware, así como en ataques de hackers.

De acuerdo con SecureList.com, Bash no está vinculada a un servicio específico como Apache o nginx. Más bien, la vulnerabilidad se encuentra en la cáscara intérprete y permite a un atacante anexar comandos a nivel de sistema para las variables de entorno bash.

¿Cómo funciona?

El problema radica en el mecanismo que exporta las funciones así como en la forma en que interpreta el código que se inyecta en el entorno donde es exportado. Para conseguir esa exportación de funciones, bash recurre a un pequeño "truco". No exporta la función en sí, sino en una variable de entorno donde se interpreta su valor como el cuerpo de una función; sin embargo, no deja de interpretar cuando termina el cuerpo de la función, sino que continúa ejecutando el código que viene detrás del cuerpo.

Esta vulnerabilidad es muy fácil de explotar y el impacto es grave porque no sólo afecta a los servidores web, sino que afecta a cualquier software que utilice el intérprete bash. Los investigadores están tratando de averiguar si otros intérpretes, tales como PHP, JSP, Python o Perl, también se ven afectados. Dependiendo de cómo se escriba el código, a veces un intérprete realmente utiliza bash para ejecutar ciertas funciones; y si este es el caso, podría ser que otros intérpretes también podrían ser utilizados para explotar la vulnerabilidad CVE-2.014-6.271.

La seriedad del impacto se debe a que hay una gran cantidad de dispositivos integrados que utilizan scripts CGI –como routers, electrodomésticos y puntos de acceso inalámbricos– los cuales también son vulnerables y, en muchos casos, difíciles de parchar. Sin embargo, no todos los sistemas son vulnerables. Condiciones especiales deben cumplirse para que un servidor web sea explotado.

Uno de los peligros es cuando un proceso remoto acepta cadenas de entrada y hace uso de ellas a través de variables de entorno, inyectando, por ejemplo, una variable que contenga la cadena ‘(){‘ seguida de código arbitrario, comandos que terminarán siendo ejecutados por el proceso.

De acuerdo con el portal español de seguridad Hispasec, un ejemplo conocido es la mínima expresión de definición de una función en bash ”() { :;};”, donde el bloque de la función definida contiene el carácter ‘:’ que en bash no hace nada, simplemente devolver cero. Su correspondiente en C sería un “return 0;”. A esa cadena se le puede adosar cualquier comando, desde un ‘echo "yo estuve aquí" hasta un devastador "rm –Rf" o un "curl****/mi_shell.php" para depositarla en "/var/www/".

Mecanismos de protección sugeridos

Lo primero que debe hacer, de acuerdo con SecureList, es actualizar su versión de bash. Las diferentes distribuciones de Linux están ofreciendo parches para esta vulnerabilidad, aunque no todos los parches han demostrado ser totalmente eficaces, la aplicación de parches es lo siguiente que debe hacer.

También se recomienda cargar las firmas de los IDS/IPS y revisar la configuración de su servidor web. Si hay algunos scripts CGI que no esté utilizando, sería mejor desactivarlos.
En la reflexión final, el autor del blog de Hispasec cuestiona: “¿Cómo paras una cabecera HTTP que contiene una definición de una función que va a ser exportada y de paso ejecutado el código que viene detrás? ¿Y la funcionalidad heartbeat de OpenSSL? No hay un detector de diseños defectuosos, no lo habrá nunca. Jamás.”

Fuente: SearchDataCenter