Atacando un BusyBox, la pequeña aldea gala

Fecha de publicación 05/09/2019
Autor
INCIBE (INCIBE)
Busybox

Cada vez es mayor el número de dispositivos que usan Linux en el entorno industrial. El aumento de sistemas embebidos o empotrados con este sistema operativo, en este entorno, se debe a la posibilidad de disponer de un sistema de pequeño tamaño, pero también a la capacidad de funcionar de manera ininterrumpida sin estar atendido y a la posibilidad de modificar el sistema dependiendo de la necesidad del proceso. Es aquí donde entra en escena BusyBox, un software que se sitúa en una capa superior a la del sistema operativo y aglutina programas en un ejecutable de llamada múltiple, ofreciendo, mediante una lista de comandos, la ejecución de diversas tareas.

¿Qué es BusyBox?

Las características de BusyBox dependerán de las necesidades de cada sistema embebido y las opciones que le quiera proporcionar el desarrollador, no obstante, todos comparten algunos parámetros comunes:

  • BusyBox carece de la funcionalidad completa de comandos de bash y otras shells. En su lugar, hace uso de la denominada Almquist shell.
  • La funcionalidad depende de las opciones de compilación elegidas por los desarrolladores.
  • La implementación y, por lo tanto, la capacidad de la mayoría de los comandos tiene una operatividad ligeramente diferente respecto a la versión propia de Linux.

En cuando a la seguridad, los sistemas operativos que llevan integrado un BusyBox, suelen ser bastante seguros, pero pueden tener vulnerabilidades, algunas de las cuales se encuentran documentadas.

Arquitectura de SSOO con BusyBox

- Arquitectura de sistema operativo con BusyBox -

Vulnerabilidades y ataques

Como casi todo software, BusyBox también ha sido objetivo de los atacantes. Desde su creación, se han identificado varias vulnerabilidades, que se han solucionado con parches y actualizaciones pero, en algunos casos, los atacantes han podido explotarlas, tomando el control de los equipos que utilizan esta herramienta.

Las vulnerabilidades más importantes que han afectado a este software están relacionadas con el acceso a la memoria, como por ejemplo las siguientes:

  • Lectura fuera de límites: problema existente hasta la versión 1.30.0. Afectaba a componentes udhcp y podría permitir que un atacante remoto filtre información confidencial de la pila al enviar un mensaje DHCP, especialmente diseñado. Este problema apareció debido a una solución incompleta para otra vulnerabilidad anterior que afectaba a la versión 1.25.0, que permitía a un posible atacante remoto tener un impacto en el software a través del parámetro OPTION_6RD, mediante un desbordamiento de búfer en el cliente DHCP, y podía provocar la fuga de información confidencial o ejecución de código de manera remota.
  • Desbordamiento de búfer basado en memoria dinámica: el software de BusyBox realiza operaciones en un búfer de memoria, pero puede leer o escribir en una ubicación de memoria que esté fuera del límite deseado del búfer. En algunos casos, se permite el direccionamiento directo de las ubicaciones de la memoria, que no garantizan automáticamente la validez de estas ubicaciones para el búfer de memoria al que se hace referencia. Esto puede hacer que las operaciones de lectura o escritura se realicen en ubicaciones de memoria que pueden estar asociadas con otras variables, estructuras de datos o datos internos del programa.

Ahora que hemos visto diversas vulnerabilidades, vamos a ver cómo sucedieron los ciberataques más conocidos a un BusyBox, que son Mirai, Brickerbot y Bashlite.

El primer ataque, Mirai, se aprovechaba de hosts que implementaban Telnet dentro de BusyBox, además de hacer uso de contraseñas débiles, para obtener acceso a los dispositivos.

Una vez dentro, el malware se instalaba y establecía conexión con el servidor de comando y control (C&C), donde esperaba más instrucciones. Al atacar, el servidor Mirai C&C instruye a todos los bots bajo su control para lanzar una avalancha de varios tipos de tráfico, inundando al host objetivo. Mirai afectó, principalmente, a cámaras de CCTV, que utilizó para llevar a cabo el ataque de inundación de objetivos finales.

Mirai contenía una lista de servidores que incluían los de varios fabricantes importantes, además de los servidores del Departamento de Defensa de EE.UU.

El segundo ataque, Brickerbot, ocurrió en 2017. El malware realizaba intentos de acceso por fuerza bruta utilizando contraseñas por defecto, usando el protocolo Telnet. Cuando el atacante lograba el acceso a un dispositivo, accedía al BusyBox y posteriormente, bloqueaba el dispositivo dejándolo inutilizable. Este ataque, que producía una denegación de servicio permanente (Permanent Denial of Service, PDoS), se ejecutaba a través de una serie de comandos de BusyBox que eliminaban todo el contenido del almacenamiento interno del dispositivo mediante el uso del comando rm de Unix, junto con comandos que reconfiguraban el kernel. Finalmente, lo reiniciaba, dejando el dispositivo totalmente inservible.

Por último, el malware Bashlite, que tenía como objetivo obtener el control de dispositivos que ejecutasen BusyBox, como algunos routers. Esta versión de Bashlite utilizaba una vulnerabilidad de Shellshock para conseguir el control. Mediante la monitorización de esta vulnerabilidad, se pudo observar que el malware, detectado como ELF_BASHLITE.SMB, escaneaba la red en busca de máquinas o dispositivos que estuviesen ejecutando BusyBox, accediendo a la máquina mediante usuario y contraseña. Cuando el atacante accedía, ejecutaba una serie de comandos de BusyBox para descargar y lanzar unos scripts (bin.sh y bin2.sh) que le diera el control sobre el sistema.

Comandos ejecutados en BusyBox por un atacante

- Comandos ejecutados en BusyBox por un atacante. Fuente: Trend Micro. -

Como muestra la imagen anterior, son varios los comandos que se ejecutan mediante los scripts maliciosos, entre ellos:

  • Cambio de directorio a la carpeta temporal donde puede haber archivos con permisos de escritura.
  • Descarga de un archivo remoto mediante HTTP o TFTP (protocolos sin cifrar).
  • Ejecución del script que se ha descargado.

Protección en BusyBox

Una de las principales recomendaciones para evitar estos ciberataques, es cambiar el usuario y la contraseña por defecto, además de deshabilitar el acceso remoto de los dispositivos.

En general, al ser código libre, las mejoras de seguridad de BusyBox se van mitigando mediante actualizaciones del software, que no suelen ser tan constantes al ser open-source, en comparación con las que recibe el software privativo, aunque también el uso de una configuración robusta dentro del dispositivo que utiliza BusyBox ayudará a reducir el número de vulnerabilidades, y que sea más complicado acceder a este software. Algunas de las características de una configuración robusta son:

  • Implementación de listas blancas.
  • Gestión correcta de usuarios y privilegios.
  • Credenciales robustas.
  • Deshabilitar puertos innecesarios.
  • Actualizar el uso de sistemas de cifrado obsoletos o considerados débiles.

Por otro lado, los servicios o aplicaciones que podemos usar mediante el software de BusyBox deben de ser lo más seguras posibles, y no se deben tener servicios innecesarios o inseguros habilitados. Un ejemplo sería utilizar protocolos cifrados como HTTPS, SSH o SFTP, y no utilizar bajo ningún concepto protocolos sin cifrar, ya que son un canal de entrada para sortear nuestra seguridad.

Además, es recomendable actualizar los módulos de BusyBox siempre que se pueda, mientras se espera una actualización de seguridad.

Conclusión

La función de BusyBox como software suite (paquete de aplicaciones) es bastante completa, ya que tiene una utilidad diversa tanto con programas ejecutables mediante comandos, como con scripts y otros tipos de archivos. Para que BusyBox sea útil y eficiente, es importante que los desarrolladores de este tipo de software vayan incorporando su propio contenido como, por ejemplo, scripts de shell y archivos de configuración, que controlan las herramientas que deben ejecutarse.

Como hemos visto, su seguridad no es perfecta, ya que no está libre de posibles vulnerabilidades, y por ello será necesario aplicar las actualizaciones de seguridad de manera constante para minimizar el riesgo de un posible ciberataque que aproveche cualquiera de sus debilidades.