[English]Nachdem die Bestätigung vorliegt, dass der Anbieter von Fernwartungssoftware, AnyDesk, Opfer eines Hacks wurde, bei dem auch die Produktivsysteme betroffen waren, habe ich einiges in Teil 1 und Teil 2 meiner Artikelreihe (AnyDesk wurde im Januar 2024 gehackt, Produktionssysteme betroffen) an Informationen aufbereitet. In Teil 3 greife ich Themen auf, die durch die Leser an mich herangetragen wurden. Es gibt um Fremdzugriffsversuche und plötzliche Kommunikation des Client mit fremden URLs. Stufe ich inzwischen zwar als "falsche Alarme" ein – die Diskussion hilft aber möglicherweise dem einen oder anderen Leser bei der Interpretation weiter. Und es gibt wohl einen ersten Malware-Fund. Nachfolgend findet sich eine Zusammenstellung dieser Punkte.
Anzeige
Verdachtsfälle aus der Leserschaft
Mein Blog-Beitrag Störung bei AnyDesk, jemand betroffen? von Januar 2024 wirkt geradezu als Honeypot, der mir erste Hinweise auf einen Vorfall, aber auch Rückmeldungen des damals betroffenen Lesers, einbrachte. Nach der Offenlegung des Vorfalls haben mich in den vergangenen Tagen eine Reihe Informationen aus dem Kreis der Leserschaft erreicht – und mit zwei Lesern stehe ich seit dieser Woche (und vor der Offenlegung durch AnyDesk) in Kontakt, um "ungewöhnliche Beobachtungen" zu diskutieren.
Fall 1: Versuchter Fremdzugriff
Als ich diese Woche erste vage Hinweise auf einen Cybervorfall bei AnyDesk erhielt, habe ich in meinen Communities (X, BlueSky, Mastodon, Facebook-Gruppen) nachgefragt, ob jemand mehr weiß. In diesem Kontext hat sich ein Leser in einer privaten Nachricht gemeldet, weil ihm im Vorfeld des Sachverhalts ein versuchter Fremdzugriff aufgefallen war. Ich habe mit dem Leser letzten Freitag, vor der Offenlegung durch AnyDesk, telefoniert und kenne einige Hintergründe. So viel: Er arbeitet u.a. auch schon mal für Auftraggeber im KRITIS-Bereich und hat auf einem seiner Notebooks, die er von den Entwicklungsrechnern getrennt betreibt, am 4. Januar 2024 plötzlich einen Fremdzugriffsversuch beobachtet.
Das betreffende System lief nach seinen Aussagen mit permanentem Dauerzugriff durch AnyDesk, wobei dieser aber durch ein komplexeres Passwort geschützt sei. Es bekam dann auf einem zweiten Rechner die Aufforderung zur Authentifizierung des Zugriffs. Hätte er diese bestätigt, wäre der unbekannte Dritte im System gewesen. Da der Leser nach seinen Aussagen bereits einen Ransomware-Fall mitgemacht hat, fuhr er sein NAS herunter und kappte die Internetverbindungen. Dann fing er mit der Prüfung auf einen Angriff an.
Die Prüfung war zwar ergebnislos, aber der Leser schrieb mir dazu "Ich hatte den unbeaufsichtigten Zugang mit Passwort konfiguriert und es wirkte so, als hätte jemand dieses mit Brute-Force geknackt – und es war ein wirklich komplexes Passwort." (Nach meinen Informationen handelt es sich wohl um ein privates Notebook, das von den Entwicklungsgeräten getrennt ist, aber am Internet hängt.
Anzeige
Der Leser teilte mir mit, dass er dem AnyDesk-Support die Logs geschickt habe. Hier die Nachricht an den AnyDesk-Support:
Unterstützung bei LogFiles
Ich bin noch kein Kunde bei ihnen und hatte "AnyDesk Kostenlos" benutzt.
Heute morgen hat sich augenscheinlich jemand in meinen unbeaufsichtigten Zugang eingeloggt.
Zumindest war das Fenster dazu offen und ich bin der einzige der das Passwort kennt.
Ich habe den Trace an die Mail angehangen und würde mich freuen wenn sie mir bestätigen können ob und wie lange jemand auf meinem Arbeitsplatz war.
Der Leser sagte, dass er aber keine Rückmeldung erhielt – ich tippe darauf, weil er kein Kunde ist. Mir liegt die log-Datei vor und der Leser hat mir auch die ID des fremden Nutzers mitgeteilt. Dieser forderte erstmals einen Zugriff am 29. Dezember 2023 über anynet.any_socket (via relay) an. Diese Session wurde aber schnell durch diesen fremden Benutzer beendet. Die Remote AnyDesk Client-Version war die 8.0.6, wenn ich den Log korrekt interpretiere. Im log findet sich dann ein zweiter Versuch vom 4. Januar 2024 mit der gleichen ID, wo jemand versucht, eine Background-Verbindung mit Zugriff auf Screen, Tastatur, Mikrofon etc. (wenn ich es richtig interpretiere) aufzubauen. Wurde durch den Leser aber nicht zugelassen.
Das Ganze muss als ungeklärter Verdachtsfall stehen bleiben. Ich habe nicht die Expertise, die Einträge in der Logdatei komplett zu analysieren – von AnyDesk fehlt die Rückmeldung. Ich hatte dann im Vorfeld dieses Artikels beim Leser nachgefragt, ob der Request auf einen Vertipper eines Fremdnutzers zurückgehen könnte. Das kann nicht ausgeschlossen werden. Ich würde diesen Vorfall momentan vage unter "Fehlalarm" einsortieren.
Schwank am Rande, da wir ja in Teil 1 und Teil 2 Diskussionen über die TLP Amber-Strict klassifizierte Warnung des BSI haben. Im Telefonat am Freitag, den 2. Februar 2024 mit dem Leser, wo es um obige Beobachtung ging, erwähnt ich auch die BSI-Warnung mit beschränktem Teilnehmerzugriff. Erste Reaktion des Lesers "da gibt es nichts, ich habe KRITIS-Freigabe". Mein Hinweis, mal genauer nachzuschauen endete dann damit, das der Leser nach 10 Minuten anrief und meinte "Ja, es gibt eine Warnung, aber wegen TLP darf ich nicht mitteilen, was drin steht."
Fall 1a: Versuchter Fremdzugriff
Nachtrag vom 5.2.2024: Im Nachgang dieser Artikelreihe hat mich ein Leser angerufen, der ebenfalls einen versuchten Fremdzugriff auf einem Linux-System feststellte. Ich habe die log-Datei vom Leser bekommen. Der Leser schrieb an den AnyDesk-Support:
Am 13.12.23 gegen 19 Uhr gab es einen unauthorisierten Zugriff auf meinen Computer.
Angeblich von "Support (424119529)" an 946984361 (meine ID). Siehe Zeile 2003 im "anydesk.trace".
Ich bitte um Rückmeldung und Aufklärung wie das passieren konnte. Mich besorgt das massiv.
Mein Stand ist, dass es nie eine Rückmeldung gab. Im anydesk.trace-Protokoll sehe ich (wie auch im Trace-Protokoll des obigen Falls), dass es eine Anforderung gab, die in diesem Fall auch gestattet wurde. Es gab einen kurzen Zugriff auf die Zwischenablage, aber die Verbindung wurde binnen einer Minute wieder geschlossen. Zielsystem war ein Linux Mint mit einem AnyDesk-Client Version 6.3.0. Ich würde das jetzt vom Bauchgefühl auch als Vertipper klassifizieren – ein mulmiges Gefühl bleibt aber.
Ergänzung: Der Nutzer hat mir aber berichtet, dass er die Sitzung geschlossen habe, weil die Maus sich angefangen habe, zu bewegen. Da war jemand auf dem System.
Fall 2: AnyDesk-Client mit connect zu playanext.com
Auf Grund der Berichterstattung hier im Blog schauen Administratoren nun wohl genauer, was AnyDesk verbindungsmäßig so treibt. Georg hat sich gestern gemeldet und schrieb, dass man die anydesk.exe durch die Endpoint-Lösung zur Ausführen erst einmal blockiert und einen externen Security Dienstleister aktiviert habe. Denn die Kontrolle der log-Dateien der letzten 10 Tage habe zu einem Fund geführt.
Zum Hintergrund, der ganz interessant ist, und einige Leser tangieren dürfte: Das Unternehmen selbst setzt AnyDesk nicht ein, ist also kein Kunde dieses Anbieters. Aber im Unternehmen kommt eine ausländische ERP-Software zum Einsatz, wo AnyDesk zur Fernwartung mit ausgerollt wird.
Der kontaktierte Security-Dienstleister hat dann in diesem Kontext in den log-Dateien Funde für Verbindungen mit der URL playanext.com (konkret api.playanext.com) gefunden und an den Kunden gemeldet. Da läutetet wohl alle Alarmglocken, da ein Command & Control Server vermutet wurde. Es wurden alle Verbindungen geblockt und die Ausführung von AnyDesk unterbunden.
Später ergänzte der Leser noch, dass die Systeme, auf denen das aufgefallen ist, die Anydesk-Version 8.0.7 und 8.0.6 aufweisen. Zu einer anydesk.exe schreibt er, dass diese den SHA-1 Hash: 0B82B980EEA1E8D2BE9E70E01FE1421AA38ABC7D besitzt und am 16.01.24 14:10:29 übersetzt wurde.
Dieser Client wurde am 17.1.2024 erstmals von der Endpoint-Lösung der Unternehmensumgebung detektiert. Dazu schrieb mit der Leser, dass die Version 8.0.7 am Abend des 17.01.24 wohl schon wieder entfernt wurde (es ging wohl auf die 8.0.6 zurück). Das geht aus den AnyDesk-Log-Files hervor, und der betroffene Server steht in der Türkei, teilt mit der Leser mit. Und er ergänzte: "Die 8.0.7. wurde entweder dem AutoUpdater gar nicht zur Verfügung gestellt oder direkt wieder zurückgenommen."
Durch Sysmon wurde protokolliert, dass die anydesk.exe direkt diese URL aufgeruft. Der Leser meinte in der Folgemail, dass playanext.com den Anschein einer Softwareverteilung erweckt. Eine Google Suche nach "playanext.com reputation" hinterließ aber eher ein gemischtes Gefühl beim Leser.
Ich hatte das kurz in Teil 2 angerissen und geschrieben, dass Fortigate die URL bzw. das Produkt auf jeden Fall als Riskware aufführt. Hat irgend etwas mit Tracking zu tun. Die Schwarmintelligenz der Leserschaft funktioniert aber, denn Leser THunter hat sich mit diesem Kommentar gemeldet (danke dafür) und schrieb:
Hallo Günther,
die URL api.playanext.com wurde von früheren Anydesk Versionen < 7.x angesprochen. Dies war eine Rest-API zur Lizenzabfrage, Telemetriedaten und Downloadsteuerung, das war zu Zeiten noch von philandro Software GmbH.
In diversen SandboxReports von Joes, HybridAnalyse oder AlienVault findest Du Anydesk.exe Samples aus den Jahren 2019-2021, die damals schon nach api.playanext.com telefoniert haben.
Die URL api.playanext.com wird oftmals mit Malware in Verbindung gebracht, weil diese auch zur Telemetrie zweckentfremdet wird. Ein BinaryDownload von dieser URL erfolgt aber nicht.
Der Leser hat mir noch den Link auf die Reports von urlscan.io gepostet, wo diese URL mehrfach gelistet und Entwarnung gegeben wird. Ich habe dem Leser das auch so mitgeteilt, verorte das Ganze nun als "falscher Alarm". Die Ausführungen des oben erwähnten Leser legen aber nahe, dass die URL playanext.com auch in den Clients der 8er-Version von AnyDesk verwendet wird.
Ergänzung: Ein Leser wies mich per Mail darauf hin, dass der AnyDesk 8.0.7-Client nur für 48 Stunden online gewesen sei, und zwar vom 16. Jan. 2024 15:39 GMT bis zum 18 Jan. 2024 15:31 GMT.
Wechsel der Infrastruktur im Januar
Blog-Leser Daniel, der in einem IT-Unternehmen mit AnyDesk betraut ist, hatte mich ja auf die Störungen im Januar 2024 hingewiesen und ich hatte daraus dann den Beitrag Störung bei AnyDesk, jemand betroffen? veröffentlicht. Daniel liest natürlich im Blog mit und schrieb mit in einer Mail.
Ich habe seit die Störung aufgetreten ist, die Netzwerkverbindungen zu und von AD genau beobachtet und dabei einen mehrfachen Wechsel in der Infrastruktur festgestellt.
Schon beim Auftreten des Problems habe ich an «Böse Buben» gedacht und genau so etwas wird wohl in Bälde rauskommen denke ich. Beobachte jedenfalls weiter und bin am vorbereiten entsprechender Maßnahmen. AD ist nicht mehr vertrauenswürdig für mich.
Die Mail erreichte mich vor der Offenlegung des Hacks durch AnyDesk. Bezüglich "Wechsel in der Infrastruktur" bedeutet, dass Netzwerkanfragen jeweils an andere Netzwerkadressen wie am Vortag gehen. Das war für ihn der Hinweis, dass da im Hintergrund was im Busch ist und der Anbieter die Infrastruktur neu strukturiert und umbaut.
Passwortänderung bei AnyDesk
In der Verlautbarung von AnyDesk heißt es, dass man die Kennwörter der Kunden-Zugänge zu den Portalen vorsorglich zurückgesetzt habe. Es scheint wohl zwei Portale My Anydesk I und My Anydesk II zu geben. Bei Konten, die unter My Anydesk I geführt werden, ist keine Passwortwechsel erforderlich, während dieser bei My Anydesk II wohl erzwungen wird. Ich kann aber nicht beurteilen, welche Kunden wo geführt werden und warum nur bei einem Portal ein Passwortwechsel erforderlich ist.
Probleme mit Client-Download
Mark hat mich heute früh per Mail kontaktiert und schrieb, das man flächendeckend AnyDesk einsetzt und meist bei den Kunden einen eigenen Client nutzt, den die Firma über my.anydesk.com generieren kann. Er wollte am Sonntag Morgen alle Clientversionen aktualisieren (auch ein neues festes Passwort setzen), damit die Firma den Client als Vorsichtsmaßnahme überall austauschen kann.
Nach dem Login unter my.anydesk.com wurde er zur Passwortsetzung aufgefordert (siehe oben). Nachdem er aber nun die Clientversion angepasst hatte und das Ganze speichern wollte, funktionierte dies nicht. Die Schaltfläche zum Speichern wird grau und dreht vor sich hin, gespeichert werden die Änderungen jedoch nicht.
AnyDesk Custom Client Generator, Zum Vergrößern klicken
Der Leser ergänzte dann in einer zweiten Mail: Das Speichern der eigenen Clientversionen klappt, wenn kein Passwort für den Vollzugriff hinterlegt wird. Aber genau das verwenden wir ja bei Server, damit keiner auf "Annehmen" drücken muss.Sobald ich ein Passwort eingebe (ein aus KeePass generiertes als auch selbst ausgedachtes) dreht der Speicherbutton und es passiert nichts. Vielleicht hilft es Lesern weiter, die ebenfalls Clients generieren.
Fehlalarm beim Download von AnyDesk 8.0.8?
Auf Facebook hat sich ein Nutzer gemeldet und schrieb, dass das aktuelle Update "gestern" (Freitag, 2.2.2024) sofort blockiert von seinem System blockiert wurde, da es laut AV-Software kompromittiert sei.
-> performed mit winget upgrade –all
< 8.0.6 auf Version 8.0.8
AnyDesk [AnyDeskSoftwareGmbH.AnyDesk] Version 8.0.8
Der Download erfolgte von download.anydesk.com/AnyDesk.exe. Dürfte aber ein Fehlalarm sein, schätze ich mal – braucht aber kein Mensch.
Verdächtige Aktivität auf Virustotal
Ein Blog-Leser hat mir gestern diesen Link auf Virustotal geschickt. Jemand hat bereits Ende Oktober 2023 eine mit .NET erstellte Datei OKJhBah6[dot]exe auf Virustotal zum "Testen" hochgeladen. Diese wird von 48 Scannern als Malware erkannt, was gut ist.
Weniger gut ist die Erkenntnis, dass diese Datei mit einem Zertifikat von "philandro Software GmbH" signiert wurde. Ich konnte jetzt nicht die Details (Seriennummer des Zertifikats) vergleichen (Bleeping Computer hat hier die Informationen). Aber die alten AnyDesk-Clients waren mit einem Zertifikat von "philandro Software GmbH" signiert. So ganz naiv vermute ich mal, dass da jemand an einer Malware entwickelt und testet, ob das Ergebnis von Virenscannern erkannt wird. Ist zwar auch kein "Smoking Gun" – aber es ist schon merkwürdig, dass da Malware mit einem Zertifikat von "philandro Software GmbH" signiert wurde.
Nachtrag: Ein Leser informierte mich per Mail, dass es sich auf Grund des obigen Virustotal-Funds eine aktuelle Datei [mit dem Client] aus seinem Account beim My Anydesk 1-Portal heruntergeladen habe und sich die Signatur angesehen hat. Aussage ist, dass die beiden Seriennummern identisch sind. AnyDesk hat immer noch diese Signatur in den 7.0.14 Clients, der am heuten 4.2.2024 heruntergeladen wurde. Was dem Leser aufgefallen ist: Im Gegensatz zu der normalen Version des Clients fehlt in dieser Datei die Signatur mit sha1-Algorithmus. Eine neu erstellte Client-Datei enthält auch noch immer genau die gleiche Signatur. Ist etwas merkwürdig.
Ansonsten hat mich ein Leser per Mail darauf hingewiesen, dass die Malware-Datei nicht mit dem Zertifikat aus dem AnyDesk-Umfeld signiert wurde.
Abschließende 2 Cents
Was bleibt vom ganzen Fall, der mal, ausgehend vom Beitrag Störung bei AnyDesk, jemand betroffen?, als vager Verdacht meinerseits gestartet ist? Es hat mindestens über eine Woche, von der Warnung des BSI an einen selektiven Kreis bis zur Bestätigung des Hacks durch AnyDesk, gebraucht, bis das Thema öffentlich war. Ob der "move" vom BSI so glücklich war, muss jeder selbst beantworten – die Informationen, die sich so ansammeln, werfen kein gutes Licht auf die Angelegenheit. O-Ton eines Kommentars von 43rtgfj5 bei Golem: "Ich hab die Meldung am Montag erhalten (Beruflich bedingt), diese gelesen und laut gelacht. Die Meldung war inhaltlich absolute 0815 News ohne wirklichen Mehrwert. Um so erschrockener war ich von der Einstufung laut TLP. Für mich absolut unverständlich, warum die so eingestuft war."
Die Mitteilung von AnyDesk von Freitag-Nacht (2.2.2024) lautet ja, dass man die Kompromittierung überwunden habe und keine Gefahr mehr bestehe, AnyDesk als Client zu verwenden. Bisher liegt mir keine Informationen vor, dass dem nicht so sei. Die obigen Fälle zeigen aber, dass jetzt jede Menge Unsicherheit bei den Kunden besteht und immer neue Fragen aufkommen. Ich denke, am Montag, den 5.2.2024 wird das erst richtig losgehen, weil Administratoren entscheiden müssen, wie sie vorgehen.
An dieser Stelle zwei Hinweise: In Teil 2 hatte ich ja die diesen GitHub-Beitrag verlinkt, wo jemand eine Yara-Regel für das kompromittierte AnyDesk-Zertifikat eingestellt hat. Bei meinen Recherchen bin ich nun auf den Sentinel One-Beitrag Customer Guidance on Emerging AnyDesk Cybersecurity Incident gestoßen, wo deren Spezialisten erste Hinweise geben, aber schreiben, dass die Situation "noch unklar sei". Dort heißt es, dass man auf den Client v 8.0.8 gehen soll.
Alles, was bisher von AnyDesk kommuniziert wurde, bleibt zu vage – wir wissen nicht mal, wann die Kompromittierung stattgefunden hat. Laut Anbieter hat man den Vorfall ja mit Crowdstrike aufgearbeitet – es müsste also eine Analyse vorliegen. Ob man mir diese, wie im Fall der Südwestfalen IT bereitstellt (siehe Ransomware bei Kommunal IT-Dienstleister Südwestfalen-IT (SIT): Nachlese IT-Forensik-Bericht Teil 2), sei mal dahin gestellt. Ich sehe aber die Notwendigkeit, dass AnyDesk sehr viel mehr an Details auf den Tisch legt, als das, was bisher eingestanden wurde. Wer die Berichterstattung in den Fachmedien oder hier im Blog nicht verfolgt, hat das Ganze bisher nicht mitbekommen. Es ist in meinen Augen ein Beispiel, wie nicht unbedingt auf einen Cybervorfall reagiert werden sollte.
Nachtrag: Ich schreibe gerade Teil 4, AnyDesk-Zugangsdaten von Kunden zum AnyDesk-Portal werden schon im Darknet angeboten. Es scheint sich aber um Daten aus einem alten Leak zu handeln.
Artikelreihe:
AnyDesk wurde im Januar 2024 gehackt, Produktionssysteme betroffen – Teil 1
AnyDesk-Hack Undercover – weitere Informationen und Gedanken – Teil 2
AnyDesk-Hack Undercover – Verdachtsfälle und mehr – Teil 3
AnyDesk-Hack Undercover – Zugangsdaten zum Verkauf angeboten – Teil 4
AnyDesk-Hack – Eine Nachlese – Teil 5
AnyDesk-Hack – Nachlese der BSI-Meldung – Teil 6
AnyDesk-Hack – Hinweise zum Zertifikatstausch bei Customs-Clients 7.x – Teil 7
AnyDesk-Hack – Weitere Informationen vom 5. Februar 2024 -Teil 8
AnyDesk-Hack bereits zum 20. Dezember 2023 bemerkt? – Teil 9
AnyDesk-Hack zum Dezember 2023 bestätigt; Altes Zertifikat zurückgerufen – Teil 10
AnyDesk-Hack: Revoke-Chaos bei alten Zertifikaten? – Teil 11
AnyDesk-Hack: Es gibt wohl neu signierte Clients; wie sind eure Erfahrungen? – Teil 12
Ähnliche Artikel:
Störung bei AnyDesk, jemand betroffen?
AnyDesk und die Störungen: Es ist womöglich was im Busch
Leidiges Thema AnyDesk, die Lizenzen und deren 7.1-Client …
AnyDesk-Probleme: Stellungnahme des Herstellers und weitere Insights
Nach AnyDesk Ärger nun RustDesk offline?
Fernwartungssoftware-Anbieter Anydesk gehackt (Artikel bei Golem)
Anzeige
Warum wird beim Build-Prozess eines Custom-Clients denn das Passwort für den Vollzugriff mit übergeben?
Wenn das hart in die Binärdatei codiert wird (selbst als Hash), dann ergeben sich aus meiner Sicht gleich mehrere Probleme:
– Extraktion des Passworts / Hashes aus der Datei
– Passwort kann nicht einfach geändert werden
– Für jedes System müsste ein Client gebaut werden, um individuelle Passwörter zu gewährleisten
– Das Passwort läuft durch die Systeme von Anydesk, welche gerade komprimiert wurden
Klingt für mich nicht besonders sicher, oder habe ich das etwas falsch verstanden?
das Problem ist die Verteilung der Softwarepakete, natürlich kann man überall einen Client installieren und dann per Hand individuell ein pw setzen, das macht's aber ab einer gewissen Anzahl von Clients unrealistisch.
Dennoch muss ich Singlethreaded da beipflichten, so etwas gehört nicht in die Binärdatei und schon gar nicht in das Build System des Anbieters. So eine Einstellung bzw. Passwort kann man bei der Installation mitgeben, gerne per Parameter oder per Konfig.-Datei.
Jetzt nur mal rumgesponnen und die Passwörter gehen wirklich durch das Build System bei Anydesk. Und nur mal "aus Spaß" nehmen wir an, dass unglücklicherweise durch ein Bug der Build Prozess samt Passwort auf dem Build System geloggt wird. Die Produktivsysteme, das hat anydesk bestätigt, gelten/galten als kompromittiert. Wenn das so sein sollte, dann gäbe es ein gewaltiges Problem.
nein, nein, nein und wieder nein.
"bei Installation" ist es Klartext in einer Textdatei oder Klartext über das Netzwerk. es sehr gute Gründe, das in die exe/dll Datei zu verpacken.
Deployment ist ein permanenter Job, du installierst jeden Monat X Rechner in einer großen Firma, die Datei mit Klartext-Passwort liegt ewig in der Share
Genauso wäre das Passwort ja auch bei manueller Eingabe am Client als hash gespeichert.
Eine andere Möglichkeit, autark auf Systeme zuzugreifen, als für jedes ein Passwort zu setzen, bot AnyDesk lange Zeit nicht. Was darin resultiert, dass man zur einfachen Verwaltung bei AnyDesk oft identische Passwörter über mehrere Kunden hinweg nutzt und sie auch an seinem Rechner speichert.
Die Trennung von Konfig und Binärdatei hat aber den Vorteil, dass ich den Client per Patch-Managemet recht einfach aktualisieren kann. Auch ein Auto-Update des Clients wäre einfacher realisierbar.
Gleiche Passwörter über mehrere Kunden sind schon sehr bedenklich. Das sollte nicht mal innerhalb der eigenen Infrastruktur so sein.
ja, aber … siehe cpassword Problematik der GPP.
wähle das kleinere Übel …
logischerweise vertraust Du deiner Technik. das Kennwort lässt sich leicht durch ein Update ändern.
du musst die Datei schon decompilieren um am das Kennwort zu kommen und ob es dann offensichtlich ist oder im code versteckt ist, ist sicherlich besser, als Klartext-Passwort in der batch
Passwörter gehören weder in Exe-Dateien, noch in GPOs oder Textdateien, sondern in einen sicheren Passwortcontainer (Keepass, Powershell Secure-Vault, etc.)
Ok, erkläre das mal einem beliebigen Deployment und einem Rollout von Software "X" an mehr als 10 Systeme.
Gerne auch 1.000 oder 15.000 oder mehr.
Ich akzeptiere deinen Ansatz, aber am Ende willst du nicht zu 15.000 Rechnern laufen, um ein Kennwort per Hand aus dem Keepass zu kopieren.
Als UP KRITIS-Mitglied haben wir (lokales Stadtwerk) nichts erhalten.
Zum UP KRITIS:
"Alle Teilnehmer des UP KRITIS (d.h. alle teilnehmenden Organisationen) werden – … – an die Warn- und Meldestrukturen des BSI angeschlossen und erhalten so regelmäßig Warnmeldungen bei besonderen IT-Vorkommnissen bzw. -Vorfällen sowie allgemeine Lageinformationen zur IT-Sicherheit (z. B. einen monatlichen Lagebericht)."
Da ich gestern dann doch arge Zweifel bekommen habe, nachdem mehrere Leser in den Kommentaren zu Teil 1 schrieben, dass Sie etwas bekommen haben, die E-Mail übersehen zu haben, habe ich die beim UP KRITIS hinterlegte E-Mail-Adresse nochmal überprüft und vom BSI Lagezentrum nichts gefunden:
– 29.01.2024 BSI IT-Tageslagebricht
– 30.01.2024 BSI IT-Tageslagebricht + Aktuelle Ausgabe der IT-Sicherheitslage
– 31.01.2024 etwas zu dem Schund von Ivanti + BSI IT-Tageslagebricht
Ich bin jedenfalls bitterlich enttäuscht vom BSI und UP KRITIS.
Danke u.a. an Herrn Born für die paar spärlichen Informationen, die der Allgemeinheit zur Verfügung gestellt wurden.
Erstens ist Anydesk nicht meldepflichtig gegenüber dem BSI, zweitens hat das BSI keine Kenntnis über unternehmensinterne Vorgänge oder Sicherheitsvorfälle der Privatunternehmen in Deutschland. Wendet sich Anydesk nicht aus Eigeninitiative an Behörden erfahren die auch nichts von Vorfällen.
Also der Fall mit dem vermutlich gebruteforcten Passwort ist Unfug.
Denn die Abfrage zur Annahme der Sitzung würde dann nicht erscheinen.
Die erscheint nur, wenn jemand die richtige ID eingegeben, evtl einfach erraten hat. Das ist kein Hexenwerk. Und steht dort solange kein Passwort eingegeben wird. Um auch die Möglichkeit eines Quick Support ohne Passwort zu bieten.
Die Abfrage zur Annahme der Sitzung wird durch andere Einstellungen geregelt und ist unabhängig von Passwort / 2FA:
"Interactive access:
-Always show incoming session requests
-Only show incoming sesion requests if AnyDesk windows is open
-Never show incoming sesion requests"
Mit der Anzeige von incoming sesion requests kann das Passwort noch so gut sein und auch 2 FA aktiviert, es genügt ein Mausklick eines Nutzers und man ist drin!
Diese Einstellung ist leider auch früher schon zurückgesetzt worden, damals habe ich die selbstständigen Updates als Ursache vermutet). Habe jetzt aber einen Rechner gefunden (8.0.6) der m.W. ohne Update diese Einstellung zurückgesetzt hatte zu 'Always show'.
Wie kommt ein Dritter denn auf einen Rechner der hinter einem Router mit NAT steht?
Niemand hat auf dem Client einen Server gestattet oder per UPnP einen Port forwarding eingerichtet.
Die ID zu erraten reicht doch nicht.
Ein laufendes Anydeskt ist auf den Anydesk-Servern verbunden, darüber wird die Verbindung hergestellt.
Als UP KRITIS-Mitglied haben wir (lokales Stadtwerk) nichts erhalten.
Zum UP KRITIS:
"Alle Teilnehmer des UP KRITIS (d.h. alle teilnehmenden Organisationen) werden – … – an die Warn- und Meldestrukturen des BSI angeschlossen und erhalten so regelmäßig Warnmeldungen bei besonderen IT-Vorkommnissen bzw. -Vorfällen sowie allgemeine Lageinformationen zur IT-Sicherheit (z. B. einen monatlichen Lagebericht)."
Da ich gestern dann doch arge Zweifel bekommen habe, nachdem mehrere Leser in den Kommentaren zu Teil 1 schrieben, dass Sie etwas bekommen haben, die E-Mail übersehen zu haben, habe ich die beim UP KRITIS hinterlegte E-Mail-Adresse nochmal überprüft und vom BSI Lagezentrum nichts gefunden:
– 29.01.2024 BSI IT-Tageslagebricht
– 30.01.2024 BSI IT-Tageslagebricht + Aktuelle Ausgabe der IT-Sicherheitslage
– 31.01.2024 etwas zu dem Schund von Ivanti + BSI IT-Tageslagebricht
Ich bin jedenfalls bitterlich enttäuscht vom BSI und UP KRITIS.
Danke u.a. an Herrn Born für die paar spärlichen Informationen, die der Allgemeinheit zur Verfügung gestellt wurden.
Hmmm… UP KRITIS Kooperation von öffentlichen und privaten Betriebern… Vielleicht ist das nicht gleich KRITIS.
oder der Praktikant hat den Verteiler vergessen.
Warum seit Ihr nicht klassisch KRITIS? Kein Strom oder Gas mit Leitwarte?
Wir sind auch nur ein kleines Stadtwerk und hier ist es, wie letztens schon geschrieben, angekommen.
Evtl. den Spamfilter usw. kontrollieren. Vielleicht wurde die Mail aufgrund der passwortgeschützten PDF gefiltert.
Aber wieso nur UP KRITIS?
Die Größe ist egal, ab dem Moment wo Strom oder Gas per Leitwarte (IT) gesteuert, bzw. kritisch überwacht wird, muss ein ISMS her. Auch wenn das ein Dienstleister macht. Solange die Kabel und Rohre im Boden dem Werk gehören, müssen die das entsprechend bearbeiten.
Unteranderem wird man dann beim BSI als KRITIS registriert.
Naja manche kleine Werke ignorieren das gerne weg, auch wenn schon die Briefe der BNetzA eintrudeln.
die Frage ist auch, kann man anydesk nun noch für ad hoc Fernwartungen einsetzen? Was soll da passieren, kann eine bestehende Session übernommen werden? Dauerhaft laufen lassen für permanenten und unbeaufsichtigen Zugriff würde ich ohnehin eine Absage erteilen, das ist einfach schlechte Praxis, das habe ich nie verstanden (außer aus Bequemlichkeit).
Die AnyDesk.exe kann man sowohl nur bei Bedarf starten als auch zur Installation von AnyDesk verwenden.
Folgendes Szenario:
– Person A benötigt Support. A hat auf dem PC nur Benutzerrechte.
– Supporter B kennt die Zugangsdaten eines Benutzerkontos mit Administratorrechten.
– A startet AnyDesk und teilt B die Adresse mit. B verbindet sich mit dem PC von A. A nimmt die AnyDesk-Anfrage an, damit B sich den PC von A ansehen kann.
Wenn B nun z.B. ein Programm installieren möchte, werden Administratorrechte auf dem PC von A benötigt. Windows zeigt ein entsprechendes Fenster (UAC-Fenster) an, in dem Benutzername und Kennwort eines administrativen Kontos eingetragen werden müssen. Wenn A die AnyDesk.exe nur ausführt, aber AnyDesk nicht installiert hat, dann kann B in dem UAC-Fenster keine Eingaben vornehmen – der Mauszeiger ändert sich zu einem Verboten-Symbol. Ist dagegen AnyDesk auf dem PC von A installiert (es läuft dann ein entsprechender Dienst), dann kann B das UAC-Fenster bedienen.
Möglicherweise kann man das Problem umgehen, in dem man Programme mit "runas" startet. Bei komplexeren Aktionen kann das aber umständlich werden.
(Korrigiert mich, wenn es einfachere Wege gibt!)
Ich habe bei meinen Eltern die Anydesk-App auf zwei Rechnern installiert, und bei mir auf meinem Mac ebenfalls. Es muss doch aber trotzdem die App geöffnet sein, damit ein Verbindungsversuch stattfinden kann, oder? Und dann muss das ja auch jedes Mal bestätigt werden.
Kann da jetzt trotzdem was passieren, bzw. kann da was passiert sein, oder ist bzw. war man in diesem Szenario sicher?
Bei Installation von AnyDesk trägt sich dieses auch in die Autostart-Gruppe ein ("shell:common startup"). Damit taucht ein AnyDesk-Symbol in der Taskleiste auf. Das reicht, um einen Verbindungsversuch anzunehmen. Beendet man die App in der Taskleiste, dann ist der "Arbeitsplatz nicht erreichbar".
Wobei das etwas kurios ist: Wenn man in AnyDesk ein Kennwort einträgt und den "Zugang in Abwesenheit" einrichtet, dann muss niemand an dem fernzusteuernden PC angemeldet sein, um eine Verbindung herzustellen, folglich die Taskleisten-App nicht gestartet wird. Oder werden Programmaufrufe in "common startup" auch ausgeführt, ohne dass ein Benutzer angemeldet ist?
Ich werde morgen die im Artikel genannten URLs und Exe-Dateien bei uns morgen erstmal sperren, und erst dann klären, ob andere Fachabteilungen das für die Wartung durch den Hersteller von bei ihnen eingesetzter Software verwenden. Lizenziert haben wir es nicht, bei uns kommt für einen bestimmten Zweck das "Original" zum Einsatz.
Also das Virustotal Sample hat zwar das alte Anydesk Zertifikat anhängen, ist damit aber nicht korrekt signiert.
Meiner bescheidenen Anfängermeinung nach kann so ein unpassendes Codesigning-Anhängsel jeder produzieren und benötigt dafür keine gestohlenen Daten.
Das riecht für mich eher nach einer Torpedo-Aktion von der Seite.
Schade, dass der Hersteller neben seinem versteckten und nicht normal erreichbaren Incident-Response Plichtartikel immer noch keine Transparenz einbringt und zu den angeblich nötigen Passwortänderungen aufruft.
Sollen diese Maßnahmen etwa nur durch interessierte Sicherheitsfanatiker durchgeführt werden, die die Fachpresse lesen, oder wie?
Das stärkt nicht das Vertrauen und am Ende lässt man auf diese Weise zwar Gras über die Sache wachsen, garniert es aber mit dem eigenen Grabstein.
Was ich sehr betrüblich finde ist das es keine Infos direkt gibt. Auf anydesk.com steht nichts von einen Vorfall.
Der Private Kunde erfährt also nichts über eine Sicherheitslücke
Ich hab ein v1 Konto und wurde nicht gezwungen, mein Passwort zu ändern.
Hab es aber dennoch getan :)
Alle meine AnyDesk-Clients sind aber auch schon immer mit 2Fa abgesichert.
Ein Anfrage zu einer Ayndesk Session kann auch pures durchprobieren von Zahlenkombinationen sein (ich sehe z.B. 7, 9 und 10 stellige Zahlenkombinationen). Die Adresse ändert sich in der Regel nicht sondern ist fest einem PC zugeordnet, antwortet der Client auf die Anfrage wissen die Angreifer da läuft Anydesk und können sich auf diese Adresse konzentrieren.
Die Anfrage zur Annahme erscheint auch dann auf dem Client wenn ein festes Passwort hinterlegt ist. Man kann also durch Annahme der Anfrage durch den Anwender auf den Client oder durch Eingabe des Passwortes. Gibt man das Passwort ein ist verschwindet der Annahmedialog.
Das würde ich jetzt nicht pauschal als Hack von Anydesk interpretieren sondern ist der Art und Weise geschuldet wie das System funktioniert. Man schickt einfach zufällig Anfragen an die Clients in der Hoffnung das der Anwender die Anfrage annimmt da er es so vom IT Support kennt.
Genau das Szenario hatte ich vor einem Jahr auch auf meinen Rechner, auch ich erhielt eine Anfrage, die ich abgelehnt haben. Worauf hin ich das Verbindungsprotokoll im Anydesk Portal geprüft und letztendlich den Zugriff über einen Namensraum definiert habe. Das ganze hatte ich damals auch an Anydesk gemeldet.
Die Frage ist ob Anydesk mittlerweile ein reines durchprobieren der Zahlen erkennt und enstprechende Clients mit x Anfragen in der Minute sperrt.
Interessant auch das anscheinend nur Version 8 bzw. Portal II betroffen zu sein scheint. Das Problem scheint jetzt eher das Zertifikat zu sein und nicht das abgreifen von Anydesk Login Daten.
Angeblich schon Nutzer Daten zum Verkauf
https://securityaffairs.com/158595/cyber-crime/anydesk-credentials-leaked-dark-web.html
Hier wird schon berichtet, dass Zugänge zum Anydesk Portal im Darkweb angeboten werden:
https://securityaffairs.com/158595/cyber-crime/anydesk-credentials-leaked-dark-web.html
https://www.resecurity.com/blog/article/following-the-anydesk-incident-customer-credentials-leaked-and-published-for-sale-on-the-dark-web
Ich sitze an Teil 4 AnyDesk-Hack Undercover – Zugangsdaten zum Verkauf angeboten
Schick, dass in beiden Artikeln bei securityaffairs und resecurity die Emailadressen nicht unkenntlich gemacht wurden. Es sind zwar in den Screenshots nur wenige, aber wäre da zufälligerweise meine dabei, fände ich das trotzdem nicht lustig.
Und aus den Mailadressen ist schön zu sehen, dass Anydesk muter weiter Geschäfte mit russischen Kunden macht. Aber das nur am Rande…
Ja sorry, auch hier: Ist ja gut und richtig, das festzustellen, aber in Teil 4 hilfst Du aktiv bei der Veröffentlichung mit…
Meine Beiträge werden vom Hausmeister moderiert (manuell freigeschaltet), der muss also wissen, was er tut.
Das fragt wer?
Der mit den mehr als drei Gehirnzellen, der beim ersten Mal vor die Tür gehen über einen moralischen Kompass gestolpert ist und dabei vor Schreck seinen Schnuller ausgespuckt hat.
Na dann…
Ich habe einiges verschleiert – und den Betreffenden per Mail kontaktiert – da das Ganze aus einem alten Leak stammt, bleibt zu hoffen, dass da Zugangsdaten geändert wurden.
Die Folgekommentare mit persönlichen "Beharkungen" zwischen zwei Leser habe ich als nicht weiterführend für Mitleser gelöscht.
In den Beiträgen ist zunächst von *Produktions*-Systemen die Rede, jetzt aber auch von *Produktiv*-Systemen. Kann man das vielleicht besser differenzieren?
Die Informationen von AnyDesk sind bedauerlicherweise ausgesprochen sparsam. Es fehlt so gut wie alles, was man sich aktuell als Kunde fragt. Man wüßte schon gerne, auf welche Teile von deren Infrastruktur sich das Problem erstreckt. Ein neues Code-Signing-Zertifikat für die 8.0.8 beruhigt mich keinen Millimeter. Zumals das laut Schilderungen hier wohlmöglich doch noch nicht oder nicht richtig implementiert ist.
AnyDesk läuft bei mir aus. Gekündigt hatte ich schon vor längerer Zeit. Grund war und ist der bescheidene Support (Auskunfts- und Lösungsfähigkeit) und die 'Qualität' von my.anydesk I + II. Die oben beschriebenen Probleme sind also keinesfalls neu, sondern existieren in iterierender Form schon länger. Lösungsversuche mit dem Support sind wie gesagt eher fruchtlos. Hab's dann aufgegeben und Konsequenzen gezogen.
Ist da schon länger was im Busch? Vielleicht nur ein False-Positive, aber: G-DATA hat im Januar auf zahlreichen Systemen, auf denen AnyDesk in unterschiedlchsten Versionen installiert war, folgendes gemeldet:
Host: XXXXXX
Tenant: Standard
Benutzer: XXXXXX
Datum: 02.01.2024 05:43:11
Melder: Wächter
Status: Virus gefunden, Zugriff gesperrt
Datei: C:\Program Files (x86)\AnyDesk-ad_bad5abc4_msi\AnyDesk-ad_bad5abc4_msi.exe
Infektion: Gen:Variant.Zusy.531496 (Engine A)
Programmversion: 15.5.0.206 (27.02.2023)
Datenstand: 02.01.2024 05:49
Engines: AVA 25.37084 / GD 27.34417
—
Host: XXXXXX
Tenant: Standard
Benutzer: XXXXXX
Datum: 02.01.2024 05:47:50
Melder: Wächter
Status: unbekannt
Datei: C:\Windows\Installer\{ED031B44-3EAF-4FCD-9FF4-892295BCF466}\AnyDesk.ico
Infektion: Gen:Variant.Strictor.286401 (Engine A)
Programmversion: 15.5.0.206 (27.02.2023)
Datenstand: 02.01.2024 05:49
Engines: AVA 25.37084 / GD 27.34417
—
Ja und?
Das sind doch wohl Generische Warnungen.
Da läuft vermutlich eine Heutistik Amok.
Und, btw, welche Gefahr geht von einem .ico aus?
Werden solche Meldungen nicht mehr inhaltlich gelesen?
Und mal geguckt was denn überhaupt gefunden wurde?
oh, Viruswarnung. Schlimm. Gehirn abschalten.
"Wechsel der Infrastruktur im Januar"
Das sich die IP Adresse ändert, bei der sich der Client meldet würde mich nicht wundern.
Andydesk wird auch dutzende solcher Vermittlungs Server weltweit verteilt haben und die Last gleichmäßig verteilen.
Man könnte mal die betreffenden DNS Records auslesen und schauen, ob mehrere IP pro Namen und ob diese routiert werden. Das nannte man mal "poor man's load balancer".
Ich finde es erschütternd, das wohl wenig Wissen existiert, wie AnyDesk &Co arbeiten, oder die die es wissen hier nicht schreiben.
@Paul
bezüglich deines letzten Satzes sei angemerkt, dass oftmals Verschwiegenheitsvertrag, NDA. etc. existieren. Das beinhaltet in der Regel alle Informationen und Quellen, welche du durch eine Partnerschaft, Anstellung o.ä. erlangt hast. Solch ein Vorfall entbindet keinesfalls davon. Warum glaubst du sind alle Quellen anonym und sehr bedacht Informationen herausgeben? Eine Verletzung meistens nicht nur ein Abmahnung sondern eine fristlose Kündigung sowie Schadensersatzforderungen mit sich bringen.
Was bitte ist daran geheim wie ein Produkt arbeitet?
Hier werden irgendwie Logfiles gezeigt, aber der AnyDesk Client sitzt I.d.R. hinter einem NAT System.
Da kann man sich nicht anmelden wie bei einem SSG server.
Das ist kein Betriebsgeheimnis, das ist einfach Unwissen.
Interessanter Ansatz "Mich interessiert doch nicht wie das funktioniert. Mein Cheff hat bezahlt, und wenn es schief geht ist es nicht meine Verantwortung." als durch NDA geschützt zu deklarieren.
Wie weit sind wir runtergekommen?
(Ich fand es erschreckend einem Windows Admin erstmal erklären zu müssen, wie SSO und Kerberos funktioniert. Frustrierend und beängstigend)
"Die Prüfung war zwar ergebnislos, aber der Leser schrieb mir dazu "Ich hatte den unbeaufsichtigten Zugang mit Passwort konfiguriert"
Remote-Access ohne timeout? Ich hoffe für die deutsche Bevölkerung, dass es sich nur um einen kleineren KRITIS-Betrieb handelt und nichts wichtiges…
Stopp – ich denke, Du interpretierst das falsch. Ich habe es noch präzisiert – wenn ich den Leser in einem Telefonat (erinnerungsmäßig) richtig verstanden habe, arbeitet er mit zwei, Entwicklungsgeräten, die vom Rest der Systeme komplett getrennt sind. Am Arbeitsplatz steht wohl auch ein privates Notebook – und ein weiterer Rechner. Auf dem privaten Notebook wurde der Zugriffsversuch beobachtet, der dann durch eine Meldung auf einem zweiten Bildschirm bestätigt werden musste. O-Ton vom Schmierzettel, auf dem ich beim Telefonat mit stenografiert habe: "auf dem Schreibtisch steht ganz links ein privates Notebook, und oben gibt es einen zweiten Bildschirm eines Rechners, die aber von den Entwicklungsgeräten für Projekte komplett getrennt sind". Die Entwicklungsgeräte waren imho dadurch zu keiner Zeit involviert.
Zu "Verdächtige Aktivität auf Virustotal"
Die Verlinkte Datei auf VT hat zwar eine Signatur, die einmal mit dem AD Zertifikaterzeugt wurde. Die Signatur passt aber nicht für die bei VT hochgeladene Datei: "The digital signature of the object did not verify."
https://www.virustotal.com/gui/file/ac71f9ab4ccb920a493508b0e0577b31fe547aa07e914f58f1def47d08ebcf7d/details
Das heißt die verlinkte Datei auf VT wurde nicht mit dem (geklauten) Zertifikat signiert. Sondern entweder eine signierte AD Datei im Nachgang manipuliert oder die Signatur einer AD Datei auf eine Malware kopiert.
Zu dem VirusTotal-Fundstück:
Die selben Checksummen passen auch zu diesem Eintrag in der Malware-Datenbank:
bazaar[.]abuse[.]ch/sample/ac71f9ab4ccb920a493508b0e0577b31fe547aa07e914f58f1def47d08ebcf7d
Mit dem Link "download sample" kann man die Datei als verschlüsseltes ZIP runterladen. Packt man es mit dem angegebenen Passwort aus, dann kann man sich auch die Signatur ansehen.
Signiert (bzw die geklaute Signatur drangeklebt) mit dem berüchtigten "philandro Software GmbH"-Zertifikat.
Das ist der "AgentTesla"-Trojaner und Keylogger.
"It is a versatile malware with a wide range of capabilities, including sensitive information stealing, keylogging and screenshot capture."
en[.]wikipedia[.]org/wiki/Agent_Tesla
Die angesprochene Yara-Regel ist leider unvollständig. Sie prüft das Zertifikat nicht zugleich auch auf "philandro Software GmbH", sondern nur auf "AnyDesk Software GmbH". So werden Dateien mit dem entsprechenden Zertifikatsgeber nicht erkannt. Also Vorsicht, da keine zuverlässige Erkennung gegeben ist.
"AnyDesk hat immer noch diese Signatur in den 7.0.14 Clients, der am heuten 4.2.2024 heruntergeladen wurde."
—
Warum wird 7.0.14 runtergeladen bzw angeboten, obwohl die aktuelle Version der 7er Reihe de 7.1.16 ist?
Ist an der 7.0.14 irgendwas essentiell besonderes und inkompatibel zur 7.1.16 oder woran legt das?
Bei den Custom Builds ist offenbar noch immer die Version 7.0.14 die neueste verfügbare Version, gerade nochmals in unserem Kundenportal geprüft…
Das kann ich bestätigen.
In unserem myAnydesk v1 und auch v2 Portal steht für ein custom build weiterhin nur die 7.0.14 Version zur Verfügung.
Wir würden natürlich gerne zeitnah einen neuen Client deployen, was dadurch nun aber verzögert wird.
Habe beim englischsprachigen anydesk-Support einen case aufgemacht.