A mediados de esta semana se ha hecho público un fallo de seguridad, al que se ha llamado ShellShock, en la popular interfaz de comandos Bash que afecta a todas las versiones lanzadas desde Bash 1.14.0 hasta Bash 4.3, o lo que es lo mismo, a todas las versiones desde el año 1994 hasta el reciente parche que se ha publicado dentro de las últimas 48 horas. El bug, que realmente son dos, tienen los CVE-2014-6271 y CVE-2014-7169 y afectan a sistemas UNIX, Linux y OS X que tienen instalada esta herramienta en sus plataformas.
 |
| Figura 1: ShellShock bug en Bash 1.14 hasta Bash 4.3 |
Comprobar la versión de tu sistema es fácil, solo necesitas usar el comando help y te dirá la versión de la bash que estás usando. En el caso de los usuarios OS X la versión que se distribuye con la última versión es la 3.5.2, así que todas las versiones de sistemas operativos de Mac OS X desde su concepción están afectados por ShellSock.
La forma de comprobar con una prueba real si tu sistema es vulnerable es bastante sencilla, solo debes irte a tu interfaz de comandos Bash y probar a declarar una función como una variable de entorno, pero añadiendo después de la definición un comando a ejecutar. En este ejemplo un comando para que muestre el mensaje de Owned. Luego se invoca bash para que cargue las variables de entorno y la ejecute el comando.
 |
| Figura 2: Test de ShellShock en Bash de OS X |
Explotar este bug tiene muchas posibilidades, pero es especialmente peligroso en los servidores web que utilizando el motor CGI (Common Gateway Interface) se apoyan en el sistema operativo para dar sus servicios web. Es decir, a diferencia de las aplicaciones .NET, JSP o PHP que se basan en la interpretación por parte de un motor de scripting de las programas que forman la web, las aplicaciones CGI se tiran directamente con ejecuciones desde el sistema operativo, lo que permite interactuar con el interfaz de comandos, sea SH, KSH o Bash.
Recordaréis que hace unos años hubo un bug casi igual de serio con PHP corriendo en modo CGI, donde se podían inyectar comandos en la llamada de PHP, y eso podría permitir ejecutar una Shell en el sistema para controlar todo desde una WebShell. Esto mismo se puede hacer ahora, aprovechando la definición de variables que se haga en la aplicación CGI ya sea llegando a ella por cualquiera de los parámetros que se envíen por GET o por POST, o por cualquiera de los datos de entrada, como por ejemplo el USER-AGENT o las Cookies.
 |
| Figura 3: Test de variables de entorno en webs CGI |
El valor de USER-AGENT es un campo de entrada que habitualmente se usa en las aplicaciones CGI para definir variables, tal y como te puedes encontrar en muchos test.cgi por Internet. Manipulando el valor del USER-AGENT es posible meter una webshell con el bug ShellSock, tal y como se ha publicado en el blog de Eleven Paths para explicar la peligrosidad del sitio.
 |
| Figura 4: Subida de una WebShell a un servidor web vulnerable a ShellShock |
En nuestro sistema de pentesting persistente Faast, metimos un plugin de detección de ShellShock - al igual que tiene el de PHP en modo CGI, HeartBleed y cientos más - a las horas de que se hiciera público el bug, para avisar a nuestros clientes que están siendo monitorizados de en qué servidores se encuentra. Tuvimos que afinar bastante para poder resolver el Error 500 del que tanto se habla por ahí, pero conseguimos un plugin de detección de lo más estable.
a que este bug te lo puedes encontrar en el sitio menos inesperado de tu infraestructura, como por ejemplo el panel de administración de un router, un switch o un punto de acceso WiFi que, tan comúnmente, cuentan con este tipo de paneles de administración web.
 |
| Figura 5: Plugin de ShellShock en Faast ejecutnado shell |
a que este bug te lo puedes encontrar en el sitio menos inesperado de tu infraestructura, como por ejemplo el panel de administración de un router, un switch o un punto de acceso WiFi que, tan comúnmente, cuentan con este tipo de paneles de administración web.
 |
| Figura 6: Búsqueda de paneles web CGI en Shodan |
En ellos, con el objeto de reducir al máximo el software a instalar, la mayoría de los paneles están corriendo en CGI. Basta con darse un paseo por Shodan y con las consultas adecuadas localizar paneles de administración web expuestos a Internet, corriendo con una Bash vulnerable que da soporte a webs funcionando en modo CGI suficientes como para que la NSA y su programa de hacking de routers, switches y electrónica de red se ponga las botas, pero que si no tienes cuidado puede poner en riesgo también tu red WiFi a visitantes no deseados. No te olvides de ellos.
Saludos Malignos!
El test que pones en la imagen no prueba la vulnerabilidad, para ello tiene que haber comandos detras de la definción de función, por ejemplo:
ResponderEliminarx='() { xxx; }; /bin/ls' bash -c 'echo hello'
@Anónimo, hay varias formas de probar el bug. Al final necesita que se ejecute la bash y cargue las variables. para que se ejecute. Solo eso.
ResponderEliminarCon "env var='() { void;}; echo owned' bash -c echo"
es suficiente.
Saludos!
'echo owned' es tan comando como el 'ls'.
ResponderEliminarNo entiendo el comentario del Anónimo.
Lo que tiene que haber es un comando detrás de la definición de la función, pero dentro de la definición de la variable. Eso es lo que se pasa al parseador para que lo ejecute.
Parche vulnerabilidad SHELLSHOCK. Linux
ResponderEliminarhttp://jesusaf.com/parche-vulnerabilidad-shellshock/
Anónimo, la cuestión no es esa, bash no sólo lee la variable x o como la quieras llamar, si no que ejecuta el código que le sigue, echo owned, en el caso que pone Chema.
ResponderEliminarEse es el punto clave, como bien te aclara, hay varias maneras de probarlo, por poner otro ejemplo:
env Var='() { :;}; echo Vulnerable' bash -c "echo esto es un test"
donde digo variable, quise decir función pero se comprende :P
ResponderEliminar