[English]In Teil 1 meiner Artikelreihe (AnyDesk wurde im Januar 2024 gehackt, Produktionssysteme betroffen) habe ich ja die Informationen, die offiziell von AnyDesk veröffentlicht wurden, sowie einen kleinen Abriss der Historie zusammen getragen. Ich sitze an dem Thema aber seit einigen Tagen dran und in der Zwischenzeit haben mich einige Informationshäppchen erreicht, aus denen sich weitere Erkenntnisse, Fragen und auch Spekulationen ergeben. Nachfolgend findet sich eine Zusammenstellung dieser Punkte.
Anzeige
Offenlegungspolitik des BSI
Als erstes noch einige Zeilen zum Thema, dass es vom BSI eine Warnung an einen begrenzten Personenkreis im KRITIS-Sektor gab, die mit der TLP-Klassifizierung AMBER+STRICT eingestuft war. Es gibt im Blog ja Diskussionen in den Kommentaren (u.a. zu Teil 1), dass es a) keine Meldung gegeben habe, b) dass man, solange nur Spekulationen vorlägen, nichts sagen solle, c) dass der Kreis der Empfänger doch die Info hätte rausrücken können und d) das die Klassifizierung unverständlich sei.
Ich schreibe jetzt nicht, dass wir in Deutschland gut darin sind, die Boten einer schlechten Nachricht zu köpfen (mir geht dar Fall aus meinem Beitrag Amtsgericht Jülich verurteilt Entdecker der Modern Solutions-Schwachstelle zu Geldstrafe (Jan. 2024) durch den Kopf) und festzulegen, dass wenn niemand darüber redet, es auch keine Schwachstellen gibt. Und ich mag auch nicht die Personalie Schönbohm (siehe Ex-BSI-Präsident Arne Schönbohm – Vorwürfe für "Rauswurf" waren unbegründet) und die Fragen im Beitrag Dienstantritt der BSI-Präsidentin: Sind BSI und dessen Präsidentin Spielball des Innenministeriums thematisieren. Denn dann hätten wir in Deutschland ja Cybersecurity nach Wetterlage, oder wie man das bezeichnen mag – aber das wäre der Situation nicht angemessen.
Stattdessen gehe ich davon aus, dass die Verantwortlichen gute Gründe dafür hatten, dass so, und nicht anders zu handhaben. Wurde mir so ähnlich von außerhalb des BSI kommuniziert. Aber ich formuliere es mal positiv: Ich habe Zweifel, ob die Entscheidungen, so, wie sie getroffen wurden, wirklich klug waren. Ich drücke den Verantwortlichen und auch AnyDesk die Daumen (ohne Ironie), dass die Aussagen im Inzidenz-Report halten und alles an Problemen abgeräumt ist. Was ich noch festhalten kann: Die TLP-Klassifizierung scheint wirklich zu halten – ich habe bis heute keinen Einblick in das BSI-Dokument – mein Dank aber an die verschiedenen anonymen Quellen, die wenigstens umschrieben haben, dass was kommen könnte. So konnte ich mir bereits vor der Freigabe des Inzidenz-Reports ein Bild machen und die Augen nach weiteren Informationssplittern aufhalten.
Licht ins Dunkel: Zeitplan des Cyberangriffs
Geht man in den Inzidenz-Report, fällt mir auf, dass dort keinerlei Zeitangaben enthalten sind, wann was passierte. Da ich schon ein paar Tage am Thema recherchiere, versuche ich mal ein paar Daten aufzuschreiben – ist zwar alles spekulativ, hilft AnyDesk-Nutzern aber ggf. beim Nachforschen in den Logs.
Anzeige
- 02. Februar 2024: Am späten Freitag-Abend (ich bekam die versprochene Info von AnyDesk um 22:44 Uhr per Mail) ging der offizielle Inzidenz-Report öffentlich.
- 01. Februar 2024: Ich hatte im Beitrag AnyDesk und die Störungen: Es ist womöglich was im Busch konkret die Frage nach einem Hack gestellt, weil bei mir seit Tagen Informationen über ein Problem vorlagen.
- 30. Januar 2024: Die AnyDesk-Infrastruktur sowie die Dienste gingen für viele Stunden in einen Maintenance-Modus, wo alles abgeschaltet war.
- 29. Januar 2024: Meinen Informationen nach wurde an diesem Tag die vertrauliche Benachrichtigung an diverse KRITIS-Stellen verschickt (Bestätigung auch hier). Zu diesem Datum wurde auch der AnyDesk-Client-Version 8.0.8 veröffentlicht, in dessen Changelog die Information zu finden ist, dass das Zertifikat zur digitalen Signierung ausgetauscht wurde.
- 27. Januar 2024: Das neue Zertifikat zum digitalen Signieren der AnyDesk Binaries (Clients) wurde – für einen Samstag – ausgestellt (siehe diesen Artikel von Bleeping Computer). Das Zertifikat besitzt eine Gültigkeit vom 24. Januar 2024 bis 25. Januar 2027 – die Gültigkeit startet also noch einige Tage früher (siehe auch folgenden Kommentar).
Spätestens zum 29. Januar 2024, eher 27. Januar, ist davon auszugehen, dass AnyDesk bereits sehr klar wusste, dass es ein sehr großes Problem gibt. Aber die Geschichte geht noch weiter, beziehungsweise: Lasst uns noch einige Tage zurückgehen.
- 25. Januar 2024: Ich hatte im Blog-Beitrag Störung bei AnyDesk, jemand betroffen? gefragt, ob die Nutzer Störungen bemerkten. Der Leser, der mich kontaktierte, beklagte Funktionsbeeinträchtigungen und vor allem Lizenzprobleme seit ca. dem 20. Januar 2024. Ab diesem Zeitpunkt muss was im Busch gewesen sein. Obiger Screenshot zeigt den AnyDesk-Statusmonitor, wo es am 22. Januar 2024 einen kompletten Ausfall des Customer Portals gab, in den Folgetagen auch.
- 16. Januar 2024: An diesem Tag wurde der AnyDesk-Client 8.0.7 für Windows freigegeben. Der Changelog lässt sich im Internetarchiv abrufen und sagt noch nichts über Zertifikatwechsel aus.
- 4. Januar 2024: Mir liegt ein log-Protokoll eines AnyDesk-Nutzers vor, der einen Fremdzugriff auf seine AnyDesk-Instanz (ständig offen, aber per Passwort geschützt) beobachtete. Ein zweiter Vorfall ist zum 30. Dezember 2023 passiert, wie mir der Leser mitteilte. Auf das Thema gehe ich in Teil 3 separat ein, obwohl ich es inzwischen eher als "Zufall" oder Vertipper einstufen würde.
In Mails des AnyDesk-Support an den oben zitierten Leser, der Störungen beklagte, wurden "technisch Probleme" kommuniziert. Entweder wusste AnyDesk da noch nichts vom Vorfall, oder die waren bereits mit der Bereinigung befasst. Der Leser, der mir den Fall vom 4. Januar 2024 kommunizierte, gab an, dass der AnyDesk die Log-Dateien mit den Verbindungen schickt habe. Ich kennzeichne des jetzt mal als Spekulation, aber es deutet sich an, dass der Zugriff auf die Produktivsysteme von AnyDesk in diesem Zeitraum oder sogar noch früher passiert sein könnten/bzw. müssen. Aufklärung könnte sicherlich AnyDesk leisten, die ja angeben, dass man mit Crowdstrike das Ganze forensisch aufbereitet habe.
Gerücht: Private Keys und Quellcode abgezogen
Meinen Informationen nach – und Lawrence Abrams von Bleeping Computer, mit dem ich häufiger in Kontakt stehe, so auch gestern Abend, hat die gleichen Informationen (siehe), haben die Angreifer Schlüssel oder Zertifikate, die zum Signieren von Binärdaten verwendet werden, sowie Quellcodes abgezogen.
Die Zertifikatsgeschichte ist insofern plausibel, als der Client v8.0.8 am 29.1.2024 eine neue Digitalsignatur bekommen hat. Den Abfluss dieser Daten hat bisher niemand dementiert. Sollte man im Hinterkopf behalten.
An diese Stelle noch ein Gedanke, den ich nachtragen möchte. Im Blog-Beitrag Sicherheitsrisiko Microsoft? Feuer von der US-Politik nach Microsofts Azure Cloud-GAU und Forderung zum Microsoft Exit – Teil 1 erwähnt, dass Microsoft heftig kritisiert wurde, dass der dort bei Hack abgezogene private Key nicht auf einem Hochsicherheitsmodul (HSM, Hardware Security Module) gespeichert worden war, sondern auf einem Server lag. Das Gleiche gilt natürlich auch für AnyDesk. Dann wäre der Klau des privaten Schlüssels zur Code-Signierung m.M. nicht möglich gewesen.
Ich aktualisiere den Client und gut ist?
Nun hat AnyDesk in seiner Mitteilung ja geschrieben, dass man die Clients mit neuer digitaler Signatur versehen habe und bittet die Kunden, auf den Client 8.0.8 umzusteigen. Nun wird es aller Voraussicht nach so sein, dass einige Kunden weiter mit den alten Clientversionen unterwegs sind. Ich weiß nicht, ob AnyDesk die von Verbindungen abschneiden und so schützen kann.
Wo ein Nutzer mich drauf hingewiesen hat, ist der Umstand, dass der AnyDesk-Client in vielen Anwendungspaketen mit enthalten ist und für die Kunden zur Fernwartung ausgerollt wird. Dort seit der Client in der Version 7.x im Einsatz hieß es von dieser Quelle. Ich habe es nicht verfolgt, vermute aber, dass es auch da einen neu signierten Client 7.x gibt. Aber viele Software-Pakete, die AnyDesk als Client enthalten, müssten jetzt aktualisiert werden. Da schwant mir nichts Gutes.
Mir fällt mein alter Beitrag Festes SA SQL-Passwort bei windata 9-Banking-Software ein, wo ich eine Sicherheitslücke bei der genannten Banking-Software festgestellt habe. Dort war der TeamViewer im Einsatz und ich habe den Entwickler darauf angesprochen, warum da uralte TeamViewer-Clients mit verteilt werden. Antwort war, dass das auf Anforderung der Banken, die das Produkt an Kunden abgeben, so gehalten werden muss.
Dennis weist in diesem Kommentar darauf hin, das das auch ein Thema für das Gesundheitswesen sei, welches mit E-Rezept und Konnektoren kämpft. Die Compugroup setzt laut seiner Aussage fast ausschließlich auf AnyDesk – wenn auch mit eigenen Servern abseits der öffentlichen AnyDesk-Server. Also genau der obige Fall einer in ein Produkt eingebetteten AnyDesk-Variante). Er meint, dass die digitale Signatur bei den Clients dann auch ungültig werden dürfte, sofern nicht durch die CGM signiert. Da bin ich gespannt, ob wir da was hören.
Ergänzung: Dennis hat sich noch per Mail gemeldet, weil er schon mit Kollegen über die in einer Medizinanwendung der Compugroup eingebettete AnyDesk-Variante diskutiert hat. In seiner Mail schrieb er:
Die in den CGM (Medistar) ausgelieferten AnyDesk-Versionen sind alle (ich habe mal 3 unabhängige Installationen untersucht) noch auf Versionsstand 7.
Die in den CGM (Medistar) ausgelieferten Anydesk Versionen sind alle (ich habe mal 3 unabhängige Installationen untersucht) noch auf Versionsstand 7.
Auf administrator.de gibt es einen Thread, wo jemand einen Link auf meinen ersten Blog-Beitrag eingestellt hat – ich habe dann weitere Artikel verlinkt. Dort wird die Aussage, dass CGM eigene Server verwendet hier von Nutzer Dani bestätigt. Dort findet sich von ihm noch folgende Frage, die ich ad hoc nicht beantworten kann:
Moin,
#Zitat: da werden sich ja alle CGM / Medistar-Kunden freuen…. da ist Anydesk fest verdrahtet!#Anwort: CGM hat meines Wissens nach eine Enterprise Lizenz und nutzt entsprechend die eigenen AnyDesk Server Instanzen.
Dementsprechend haben die AnyDesk Clients a) nur dessen FQDN/IP Adresse/n b) es wird hier nicht die Code Signatur von Anydesk verwendet. Was hat es nun für die Kunden für einen direkten Impact?
Es wurde gefragt, ob auch On-Premises-Lösungen betroffen seien (also das, was die Compugroup offenbar nutzt). Es gibt vom "hear say" noch eine, von mir nicht verifizierbare, Aussage eines AnyDesk-Supporters, angeblich die Woche bei einem Kunden vor Ort gefallen, dass On-Premises gehostete Lösungen nicht betroffen wären, nur die "Cloud-Lösungen" – also wohl alles, was den Zugang über AnyDesk-Punkte abwickelt. Die Aussage würde ich persönlich aber sehr mit Vorsicht genießen, da infizierte Clients sich um so etwas nicht kümmern.
Ergänzung: Pau1 weist in diesem Kommentar auf weitere Implikationen der digitalen Signatur der Binärdateien hin, die durch den abgeflossenen privaten Schlüssel (samt Zertifikat) erforderlichen Zertifikats-/Schlüsseltausch auftreten können. In Teil 3 greife ich noch einen Fund auf, wo möglicherweise bereits mit so etwas experiementiert wird.
Erste Verdachtsfälle: Dräut da was?
Kommen wir nun zum noch unangenehmeren Teil der Darstellung. Seit ich herumgefragt habe, trudeln bei mir immer neue Informationen und Fragen ein. Ich habe jetzt aber zwei Meldungen vorliegen, die von einer Zunahme von Betrugsanrufen seit einigen Tagen berichten. Eine Fundstelle findet sich im heise-Kommentarbereich. Die zweite Meldung habe ich gestern vom CISO einer großen öffentlichen Organisation in Österreich erhalten.
Dann habe ich es bereits in meinem Beitrag für Golem thematisiert. Die Nacht bin ich auf den Eintrag How did AnyDesk get on my phone and is it compromised now? bei reddit.com hingewiesen worden. Ein Nutzer eines Android Smartphones stellte nach dem Aufwachen fest, dass eine App namens AnyDesk auf seinem Gerät installiert worden war. Er fragt, wie zum Teufel die App auf das Telefon geraten sein könne, er ist sich sehr sicher, die nicht installiert zu haben. Der Case ist zwar "wackelig", weil der AnyDesk-Client über eine andere App auf das Gerät geraten sein kann. Aber einfach mal im Hinterkopf behalten.
In Teil 3 erfahrt ihr, dass da wohl bereits mit "AnyDesk"-Malware experimentiert wird (es gibt wahrscheinlich Samples, die aber von Virenscannern erkannt werden). Und ich möchte zwei "strengere" Verdachtsfälle (also die beiden obigen Beispiele) aufgreifen, die mit dem obigen Hack zusammen hängen.
- Einmal geht es um einen Entwickler, der auch für den KRITIS-Bereich tätig ist, und bei einem Notebook (der von der gesamten Entwicklung getrennt läuft) einen Fremdzugriffsversuch festgestellt hat. Nachtrag: Inzwischen habe ich einen zweiten Fall berichtet bekommen.
- Und mir liegt konkret seit heute Mittag eine Meldung aus einem Unternehmen vor, die eine Infektion im Client vermuten (es gab Verbindungen zu playanext.com). Ich habe die Freigabe, das anonymisiert zu berichten. Da könnte aber auch was vom OEM mit eingeschleppt worden sein – lasse ich die Leute noch prüfen. Fortigate führt die URL bzw. das Produkt auf jeden Fall als Riskware auf.
Beide Fälle dürften am Ende des Tages harmlos sein – aber aktuell ist Vorsicht die Mutter Porzellankiste. Vielleicht thematisiere ich noch den Verdacht meines ersten Hinweisgebers, der sei Anctive Directory seit den ersten AnyDesk-Vorfällen vorsorglich als "kompromittiert" ansieht.
Vorab noch eine Verlinkung auf diesen GitHub-Beitrag, wo jemand eine Yara-Regel für das kompromittierte AnyDesk-Zertifikat eingestellt hat. Damit kann man mit entsprechenden Lösungen Programmdateien erkennen, die mit dem alten Zertifikat binär signiert sind.
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?
Anzeige
Mich beschleicht ein schlechtes Bauchgefühl, dass da mehr im Busch ist als der Hersteller derzeit weiß oder aber zugibt. Wenn das nicht noch sehr hohe Wellen schlagen wird.
Hab ein ähnlich böses Gefühl!
"Dort war der TeamViewer im Einsatz und ich habe den Entwickler darauf angesprochen, warum da uralte TeamViewer-Clients mit verteilt werden. Antwort war, dass das auf Anforderung der Banken, die das Produkt an Kunden abgeben, so gehalten werden muss."
Kram von Firmen^WKLITSCHEN, die SCHROTT wie TeamViewer, AnyDesk etc. mit ihrem Zeux liefern/installieren, sollte NIEMAND mit klarem Verstand einsetzen!
Falls Remote-Zugriffe wirklich notwendig sein sollten, dann über die vom jeweiligen Betriebssystem bereitgestellten Funktionen, beispielsweise RDP, und über einen per VPN erreichbaren Jumphost geschleust, der als einziger in der Firewall der Clients dafür freigegeben ist.
Alles andere ist ÜBLER Pfusch. PUNKT!
Du kannst mit RDP nicht das machen, was mit dem VNC "Schrott" geht. Es kann bei RDP auf einem Client immer nur einer eingeben oder einer schauen.
Wenn Du immer nur Server nutzt, fällt das nicht auf, weil diese meist headless sind und wenn nicht, für RDP ein neuer Desktop geöffnet wird. Auf dem einfachen Client sieht der User dann nur "sie sind abgemeldet weil ihr Rechner aus der Ferne bedient wird". Oder er bekommt einfach nur einen schwarzen Bildschirm.
Ich vermute Microsoft macht das um teuere Lizenzen verkaufen zu können.(man kann ja auch nicht mit 2 Usern auf dasselbe Netzwerk Laufwerk gehen, war ja auch für ein Rechner Sharing nötig wäre. Unter Linux war und ist das selbstverständlich kein Problem.
Ich gehe mit Dir konform, dass in einem Professionellen Umfeld der Remote Zugriff via DMZ und VPN zu erfolgen hat, und keine unnötigen Server Dritter involviert werden sollten.
Wann du Admin-Tätigkeiten machst, reicht dem User ein schwarzer Bildschirm aus. Wann du Remote-Support machst, schickst du dem User eine RDP-Support Einladung, die dieser annehmen muss und ein zweites Mal bestätigen muss, wenn der Support die aktive Steuerung benötigt. Dann sehen beide alles und beide können die Maus Schupsen und Tippeln. Wieso sollte das mit RDP nicht gehen? Natürlich müssen dafür der User PC und der Support PC in der selben AD Member sein – aber genau dafür nutzt man ja als Supporter einen Jumphost beim Kunden.
Manche User (Kunden) würden sich "bedanken" wenn sie nicht sähen was da remote getan wird.
Auch habe ich nicht immer wen da stehen, der Bestätigungen anklicken kann(headless).
Auch kommt es vor, das der Kunde und Remote auf den gleichen Rechner remote wollen/müssen, weil dem Kunden der KVM nebst Kabalage zu teuer war…VNC reicht ja.
Geht das auch per RDP? (kein Server)
AD gibt's sowieso nicht. Manche Kunden haben das für ihre 1,5 Rechner einfach nicht.
Warum man einen Rechner nicht von mehreren Gleichzeitig Bedienen können sollte und nicht mehrere User von einem Rechner auf ein oder 2 shares gehen können sollen?
Man könnte sich vorstellen, das der Kunde seinen Mitarbeitern nur einfache Rechner hinstellt, ohne Netzwerk-Lizenz. Diese arbeiten dann auf einem anderen gemeinsamen in unterschiedlichen Fenstern.
Nur der eine gemeinsame Rechner hat eine Netzwerk Lizenz. das wäre dann so ein einfacher Terminal-Server zum Nulltarif…
klar das MS da hohe Hürde aufbaut und als Sicherheitsfeature verkauft.
naja, dann kann Anydesk auch noch diverse Spielchen mit eigenem VPN.
irgendwie muss es ja einen Grund haben,dass man die doch inzwischen recht teueren Lizenzen kauft, obwohl alles mit RDP so schniecke läuft.
RDP und die darauf basierende Remotesupportfunktion oder VNC kann man aber nur innerhalb eines LANs machen. Das übers Internet bereit zu stellen wäre fatal!
Daher haben Produkte wie Teamviewer und Anydesk bis vor Kurzem durchaus einen Sinn gehabt, denn mit ihnen kann man über Gatewaygrenzen hinweg sowas machen.
Aber mit Teams, Zoom, Webex usw. ist das eigentlich obsolet.
@1ST1:
*** RDP und die darauf basierende Remotesupportfunktion oder VNC kann man aber nur innerhalb eines LANs machen. Das übers Internet bereit zu stellen wäre fatal! ***
Lässt sich beides via SSH übers Internet tunneln.
Sicher ist eine "Teamviewer" Lösung schicker, aber für Remotezugriffe auf Server sind solche SSH-Zugriffe durchaus machbar.
Wenn du einen SSH-Tunnel hast, bist du virtuell im Zielnetz, ähnlich wie bei einem VPN. Nur musst du so einen SSH-Tunnel erstmal herstellen, dazu brauchst du im Zielnetz einen Endpunkt, an den du dran kommst. Teamviewer und Anydesk brauchen das nicht, genauso wenig wie Teams und co, da wird die Verbindung über externe Systeme hergestellt, denen man allerdings trauen muss.
"Teams, Zoom, Webex" Wenn ich das chon lese, könnte ich kotzen. Das für Remotewartung einzusetzen, ist absoluter Schwachsinn
Kommt drauf an. Unbeaufsichtigt kommt bei uns kein Hersteller auf Systeme. Dann reichen die Webkonferenz-Tools, in denen man die Bildschirmfreigabe selbst macht.
Stimmt nicht, rdp beherrscht sehr wohl das steuern und anzeigen eines remote bildschirms auf der gleichen user session – nennt sich shadow rdp.
Und Netzlaufwerke werden im user kontext geöffnet somit haben andere keine Berechtigung auf das Netzlaufwerk zuzugreifen, das macht auch ein Linux nicht, sonst hättest da ein Sicherheitsproblem. Was Linux und Windows beherrschen ist mehrere user gleichzeitig auf eine Netzwerkfreigabe sofern sie denn berechtigt sind.
Nein. RDP wie du es meinst: ja, aber Remote Unterstützung, die RDP nutzt kann sie Sitzung spiegeln, wie ein RDS session Host.
RU zu aktivieren/konfigurieren sind 2 Richtlinien und es ist 100 betriebsratskonform, da der User zustimmen muss
Anydesk spricht von 170000 Kunden.
Das ist also eine Klitsche?
"Interessante Definition"…
naja Windows hat wieviele aktive User? … also ja 170000 ist da nix!
170.000 Firmen. Nicht Verwaltete Geräte. Die werden in die dreistelligen Millionen gehen.
Das "alles andere ist übler Pfusch" teile ich ganz und gar nicht. Was du beschreibst, ist nämlich eher eine Lösung, die man heute nicht mehr neu aufsetzt und vielleicht auch überdenken sollte, wenn man sie bereits laufen hat. Das bedeutet nämlich, dass z.B. Dienstleister zuerst ggfs. einen VPN-Zugang zu deinem System einrichten müssen (dürfen sie oft nicht), ggfs. sogar noch einen Client installieren (dürfen sie noch weniger). Und dann will man eigentlich für sowas auch gar nicht extra noch ein VPN betreiben und absichern.
Heute läuft das eher über eine PAM-Lösung, die per Browser erreichbar ist. Über diese verschlüsselte Verbindung wird dann ein RDP, SSH oder ähnliches per Proxy durchgereicht. Vorteil ist, dass Einwählende nur einen Link brauchen, die Authentifizierung über die üblichen Kanäle mitsamt 2FA läuft und außer einer https Verbindung zwischen Client und PAM keine weiteren Verbindungen existieren müssen.
Auch wenn das heute so vielfach so läuft, ist und bleibt es Pfusch, Gemurkse und vor allem unsicher. Das Bohren von Löchern aus einem Netzwerk in die weite Welt ist in jedem Falle zu vermeiden. Da sind Zugänge über Tunnel, die zudem noch vernüftigt durch Keys und Zertifikate abgesichert sind, die weitaus bessere und eben auch sicher Lösung. Besonders hier gilt "keep it simple" und das ist mit einem fremden "Proxy" bei weitem nicht der Fall. Ich weiß, daß viele Menschen die Einrichtung eines Tunnels scheuen, entweder weil sie keine Ahnung haben, wie man das richtig absichert, oder weil ihnen das vom Kunden aus gutem Grund nicht erlaubt ist. Dann sollten sie aber gefälligst die Finger von windigen unsicheren Lösungen lassen.
Bei Teamviewer war es so, dass wenn beide Seiten die gleiche Version hatten, alles funktioniert.
Sobald aber ein Kunde auf die neue Version Updatete musste auch der Supporter die neue Version lizenzieren. Danach müssten auch alle Kunden nachziehen…
Leicht vorstellbar, dass Kunden die Version auf einen alten Stand eingefroren haben um horrende Kosten zu sparen "funktioniert doch"
Finanziell für Teamviewer gut, Sicherheitsmäßig natürlich ein gewisser Wahnsinn.
Ich vermute das Anydesk das ähnlich handhabt.
Das läuft doch fast immer so, Menschlich faul…
Der erste Fall geht aber hart zur Sache, bleibst Du dran Günter? Aber irgendwie hat er vielleicht recht, mir ahnt auch übles, weil dieses getuschel nie wirklich aus Nettigkeit passiert.
Die Standard-Fernwartung von Windata ist FastViewer, TeamViewer ist aber als "Alternative" noch an Bord. Es gibt unterschiedliche Versionen der Binärdateien.
Die ältesten Versionen sind Teamviewer 10.0.47484.0 vom 11.09.2015 und FastViewer 3.20.0042 vom 15.09.2016. Angaben beziehen sich auf das Datum der Codesignatur.
Was ist mit "Produkt Integration" gemeint?
Ich kenne das so, das man dem Kunden einen Link vorbereitet hat, den er für eine Fernwartung klicken muss und dann den Client (erstaunlich klein) downloadrn kann.
Bei Teamviewer darf man diesen sogar mit dem eigenen Logo versehen und auf das Installationsmedium legen.
der Client wird mit einem Produkt (ERP, Baramundi etc.) mit ausgerollt
Gibt es eigentlich irgendwo eine vollständige Liste aller Software, welche Anydesk mit ausliefern?
Mir ist nichts bekannt – ich bin aber auch nicht Referenz für so etwas.
Habe gehofft, dass es das irgendwo gibt. Man muss halt einen Ansatz haben, um nach verdächtigen Versionen Ausschau zu halten. Immerhin sind wir in der Lage, auf allen Systemen nach Namen von laufenden Prozessen zu suchen, das wird dann am Montag mein erster Task sein.
Die am Artikelende verlinkte Yara-Regel hilft nicht? Solange noch alte Clients da rum fliegen, sollten die mit Yara doch gefunden werden – oder habe ich das falsch verstanden?
Oder mal schauen, wie die Binärdateien der Clients heißen – mit Wildcards müsste sich was machen lassen.
Eben. Aber warum kompliziert, wenn es auch einfach ginge?
du kannst dir von Windows internal das process viewer tool holen, das alle Programme gegen Virus total prüft und auch die Zertifikate validiert.
Es lässt sich aber auch mit 3 Zeilen Powershell feststellen, ob da irgendwas mit Anydesk zertifiziert worden ist.
Und das machst du mal eben so nebenbei auf 1000++ Windows Systemen im Netz?
Das Ausstellungsdatum des neuen Code-Signierungs-Zertifikats (Samstag, 27.01.2024 19:04 Uhr) ist ein Hinweisfetzen in sich. Spätestens da war denen bewusst, dass das Alte kompromittiert wurde.
Nein, wohl spätestens am 24.1.24 01:00:00 muss es klar gewesen sein (Feld "Gültig ab:" des Zertifikats). Niemand kauft ohne Not ein neues Zertifikat.
Im Rahmen der Laufzeit kann man ein Zertifikat normalerweise kostenlos neu ausstellen lassen. Hat man ein drei Jahre gültiges Zertifikat, kann man also problemlos nach einem Jahr ein "reissue" machen.
Ich gehe mal davon aus, dass da noch einiges kommen wird. Der Inzidenz-Report glänzt ja gerade mit Informationen.
Entweder wissen die noch nicht was Sache ist oder halten die Infos ziemlich weit hinter dem Berg um keine Leute zu verschrecken. Nach dem Motto "Bitte gehen Sie weiter, hier gibt es nichts zu sehen"
Und sowas kommt immer am Freitag Nachmittag um die Ecke…..
Bin gespannt wie Baramundi darauf reagiert. Die haben ja seit neuestem AnyDesk ja mit dabei im Modul Remote Desk.
Ich habe vom Support bisher auf meine Frage kein Antwort erhalten.
Hat den Link zur Stellungnahme von AnyDesk (https://anydesk.com/en/public-statement) schon jemand auf der Webseite selbst aufrufen können weil er dort irgendwo in den Tiefen der Menüführung "versteckt" ist?
Möglicherweise habe ich Tomaten auf den Augen, aber ohne den Direktlink konnte ich diese Stellungnahme nicht finden.
Unter https://status.anydesk.com/#past-incidents findet sich jedenfalls nichts.
Wie also soll das ein "Public Statement" sein, wenn das nicht zu finden ist.
Der Text ist zumindest an die Presse gegangen – heise und Golem, die ich heute früh kontaktiert habe, hatten die Meldung schon. Golem hat dann aber meinen Text veröffentlicht, weil der mehr Informationen beinhaltete.
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.
Siehe dazu auch die Reports von https://urlscan.io/search/#page.domain%3Aapi.playanext.com
Danke für den Hinweis, werde das in Teil 3 berücksichtigen – hatte schon auf dem Radar, dass es irgend etwas zum Tracking sei.
Oh man, definitiv sein Super-Gau. Das ganze wird noch ordentlich Kreise ziehen bei 170000 Kunden (Nutzeranzahl wird wohl um ein Vielfaches höher liegen).
Ich weiß wirklich warum ich auf propritiäre Software so gut es gehr verzichte. Nicht mehr feierlich, wie heftig das erfolgreiche Hacking zunimmt.
Wird mal Zeit Firmen Sicherheitsaudits aufzuzwingen. Vor allem wenn kritische Infrastruktur mitbedient wird.
@derlocke
KRITIS=ISMS=ISO27001=1x Jahr Audit
die nächsten Jahre sogar min. 2x 1-2 Tage
mit der NIS2 kommen nochmal viele Firmen 2025 in den Genuss.
Sag das mal dem Maschinenbau oder Privatwirtschaft. ..
Geprüft und zertifiziert wird aber das Managementsystem, nicht die tatsächliche Sicherheit ;-)
Hä? Dann haben wir aber andere Prüfer im Haus!
Der letzte hat sogar die Prüfetiktten auf den Feuerlöscher kontrolliert und mit Mitarbeitern aus dem scope und Anwendungsbereich gesprochen und abgefragt.
SzA war noch technischer.
Ein Prüfer der nur Dokumente prüft wird irgendwann Ärger bekommen.
du meinst dieses remote assist?
mstsc.exe /v:PC1 /shadow:1 /control
damit kann dann der User und ich (remote) gleichzeitig die Maus bedienen.
Wenn es einen UAC Pop-up gibt, kann ich den auch weg klicken
und wenn mir danach ist kann ich (remote) die Kiste runterfahren?
und ich muss weder Admin auf der Kiste sein noch das Passwort des Users kennen?
das waren so die Probleme an die ich mich bei "rdp" erinnere. (es gab keinen shutdown knopf in der remote session… sehr witzig..)
aber wenn das auf diesem Weg möglich ist, danke für den Hinweis.
Aber warum kaufen die Leute dann Anydesk, Teamviewer, und due die anderen VNC Teile?
Alle keine Ahnung und zu viel Geld?
Was Windows nicht zu lässt ich von *einen* Rechner mit unterschiedlichen Usern auf einem andern Share zu zugreifen hat aber nichts mit remote zu tun.
Es hilft da nur der Hack, für den 2. User die IP des Servers zu verwenden. Aber nach 2 Usern -von einem Rechner zu einem anderen- ist dann unter Windows Schluss.
Klar das man mehrere User von unterschiedlichen anderen Rechner auf einen Share lässt. Jedes Rechte Management Wäre ja sinnlos, wenn alle User gleich wären.
"Aber warum kaufen die Leute dann Anydesk, Teamviewer,"
Versuche mal per rdp auf ein System innerhalb eines fremden Netzes zu kommen. Ohne die öffentliche Adresse des Ziel-Routers und Portforwarding auf dem Router geht das nicht. Zum Glück.
Anydesk und Teamviewer können das.
Die Kiste kannst du in der rdp session runterfahren über die Kommandozeile. (Shutdown -r -t 0) und ist eigentlich absicht damit nicht jemand versehentlich den entfernten computer herunterfährt.
Du brauchst Remotedesktop permission musst dafür aber kein Admin sein für rdp.
Natürlich kannst du mit mehreren usern von anderen computern aus auf ein und den selben share zugreifen und das alles über Hostnamen. Wenn du IP nutzt umgehst du noch dazu Kerberos falls du nicht manuell Workarounds nutzt.
Auf den Clients muss zuvor ein Registryeintrag gemacht werden, sonst funktioniert RDP-Shadowing nicht:
reg.exe ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /d 2 /t REG_DWORD
Folgende Werte gibt es:
0: No remote control allowed
1: Full Control with user's permission
2: Full Control without user's permission
3: View Session with user's permission
4: View Session without user's permission
Wenn du 2 oder 4 setzt, kommst du ohne Bestätigung des Benutzers in die RDP-Schatten-Sitzung, musst aber "NoConsentPrompt" mit angeben:
mstsc.exe /v:PC1 /shadow:1 /noConsentPrompt
Die Sitzungs-ID musst du zuvor mittels quser.exe oder qwinsta.exe ermitteln. Es ist nicht immer die 1.
ah, danke.
Ich hatte vor 1,5 Jahren auch diverse Loginversuche von extern auf unsere AnyDesk Installationen bemerkt, hatte dies auch an AnyDesk gemeldet. Letztendlich habe ich es die durch Definition eines Namensraums unterbunden. Problematisch war es in dem Fall auch nur gewesen wenn der Benutzer vor dem Bildschirm die Anfrage angenommen hätte, denn auf System
wo niemand angemeldet ist und das Anydeks Passwort bekannt ist, steht der Angreifer maximal vor einem Loginfenster. Eine AnyDesk Session entsperrt ja nicht automatisch Windows. Das ganze war aber auch problemlos über das Session Portokoll im AnyDesk Portal nachvollziehbar. Es gab nur Versuche, nie ein wirkliche Verbindung.
Eurec anydesk installationen sind direkt, ohne NAT, aus dem Internet erreichbar?
Irgendwas verstehe ich da wohl nicht.
Ich sah bei einer Anydesk Installation im Wireshark ständige Verbindungen nach außerhalb.
Alle 10sec oder so. Nervig wenn man eigentlich etwas anderes tracken will, und erstmal den Müll filtern soll.
Das waren wohl die Verbindungen zum Lizenz Server?
War ja nicht viel Traffic.
Aber wenn ich mir vorstelle, das dieser Lizenz Server kompromittiert wurde und es im Client irgendwie einen 0day gibt? Wer rechnet schon damit, dass der Lizenz-Server böse sein könnte?
das mit dem Wireshark ist schon länger her und war nicht mein Problem.
Aber das könnte so etwas wie "playanext.com" gewesen sein.
müsste eigentlich jeder in einem Ethernet dump sehen, der auf seinem Client Anydesk installiert hat.
Auch könnte das in der netstat Verbindungs Liste erscheinen.
Jede 10sec oder 60sec.
Ich hätte mich, als Anydesk Kunde, natürlich darüber gefreut, wenn ich von Anydesk direkt informiert werden würde und das nicht aus den Medien erfahre. In meinem Firmen Postfach finde ich aktuell keine Info von Anydesk. Ich kann mich täuschen, aber die Nutzung der 8er Version ist m.W. an einen irgendwie erweiterten Vertrag gebunden und bisheriger Nutzer der 7er kommen nicht in jedem Fall in den Genuss der neuen Version. So etwas wurde zumindest sinngemäß angezeigt, als ich kürzlich die 8er downloaden wollte. Da stellt sich die Frage, ob auch die 7er betroffen ist und was dann zu tun ist. Vielleicht sehen wir uns doch nach einer Alternative um. Der Support ist bei Anydesk nicht wirklich gut. Wir hatten ewig Probleme im Zusammenhang mit der Nutzung eines Squid Servers, bei dem es sich ja mitnichten um etwas besonders exotisches handelt, und hinsichtlich Kommunikation und Dauer der Lösung hatte Anydesk wirklich schwach performed.
Hallo,
was mich an der ganzen Sache stört ist wenn man auf die Ende des Seite geht dann steht dort nichts über diesen Vorfall. dort müsste auf der landing Page als eilmeldung stehen dass die Systeme kompromittiert worden sind. die tun sowas hat nichts gewesen wäre…
Für die (vermutliche wenigen) on-premise Kunden steht auf der Homepage keine aktuelle Version des Clients mit einem Hinweis oder Changelog zur Verfügung. Doch auch hier müsste doch eine aktuelle Version mit einem neuen Code-Zertifikat bereitgestellt werden, oder ? Bin kein Entwickler, aber das wäre logisch. Die Stellungnahme von AnyDesk findet man nur über den Link, ein umschalten auf deutsche Sprache ist auf der Seite nicht möglich. Auf der deutschen Seite findet man nichts, wo ich auf einen Hinweis stoßen würde, das ich updaten muss. Es soll ja Leute geben, die hier nicht mitlesen :-) Das könnte ein rechtliches Thema in den USA sein: Wir müssen das dort veröffentlichen, sonst werden wir verklagt. In Deutschland reicht der Hinweis an die entsprechenden Stellen, die dann alles unter Verschluss halten. Als Kunde bin ich nicht direkt informiert worden. Außer über einen eh schon länger vereinbarten Supporttermin, der auf Nachfrage einen Vorfall bestätigte. Aber positiv gesehen: Die Anydesk repariert das ganze im Hintergrund, bevor es der Großteil mitbekommt ? Die bereits vorhanden Vorfälle aus den Kommentaren lassen natürlich schon auf einen gewissen "Bekanntheitsgrad" bei den bösen Jungs tippen. Bin durchaus gespannt, wie es weitergeht in dem Fall. Leider erinnert mich das immer wieder an Lastpass, die auch den Vorfall heruntergespielt habe und damit Vertrauen verspielt. Transparenz dem Kunden gegenüber wäre hier viel wichtiger.
Ich hab nachdem ich alles deinstalliert habe bei einigen Rechnern noch die connections angesehen. Hat alles eigenen Namensraum und Verbindungen sind dahingehend eingeschränkt. Da war nirgends was auffälliges dabei. War jede Verbindung nachvollziehbar. Die 5 Irrläufer im Monat die geblockt werden nicht mitgerechnet. Da kann sich auch mal wer bei der Nummer vertippt haben. Ist trotzdem alles mal off, sicher ist sicher.
Mich erinnert das immer mehr an die Supply-Chain-Attacke damals bei Solarwinds. Wer weiß wo die Angreifer sich jetzt überall ein Türchen aufgemacht haben!
Habe Zugangsbeschränkung eingerichtet und schon lange 2fA.
Ich stelle mir die ganze Zeit die Frage, was ein neues Cert bringt wenn die Quellcodes kompromittiert sind … dann signiert man doch das was man nicht haben will … was wiederum der Jackpot für die Angreifer wäre ….
Ich für meinen Teil würde wenn ich es nutzte (was ich nicht tue) das ganz Richtung /dev/null schieben solang nicht unabhängig der Quellcode geprüft worde.
Ich gehe mal davon aus, dass die forensische Analyse (auch von Crowdstrike) gezeigt hat, wie die Angreifer ins System kamen und wo die zugegriffen haben. Dann sollte man auch wissen, ob der Quellcode kompromittiert war. Sofern die Prämisse stimmt, kann man schon ausschließen. Aufklären könnte AnyDesk mit Offenlegung von mehr Details. Der Abschlussbericht der Forensiker bei der Südwestfalen IT hat ja sehr viel Insights geliefert, ohne dass man in "Firmengeheimnisse" gestolpert ist.
Ich würde mal sagen, damit man nicht neuen Code mit der "korrekten" Signatur in Umlauf bringen kann. Wenn man den AV Herstellern dann noch die alte Signatur als kompromittiert mitteilt können die alles was die alte Signatur hat gleich mal erkennen. Wäre meine Idee dahinter.
Ja das war mir schon klar aber eine neue Signatur auf Veränderten Code hebelt genau dies aus, dann springt keiner mehr an, weil passt ja.
Na dann warten wir mal den Bericht der Forensiker ab, aber meines Wissens nach können die keine Sektoradressierten Operationen im Nachgang aufspüren aber das muss ja auch nicht stimmen
AnyDesk scheint das private codesigning Cert verloren gegangen zu sein. Der neue Besitzer könnte damit beliebigen anderen Code (Treiber) signieren und Windows würde den ohne murren fressen, weil Anydesk als vertrauenswürdig markiert ist.
Also muss Andydesk das kompromittiertexZertifikat zurück ziehen. Damit würden sie aber auch ihre eigene Software aufsperren. Also erzeugen die einen neuen Privaten Key und signieren damit den alten Code neu. Das sich der Code nicht verändert hat lässt sich anhand von Prüfsumme feststellen.
Also fordern sie alle Kunden auf, den Code mit dem neuen Schlüssel herunterzuladen.
ist das geschehen, erklären sie den alten Schlüssel für ungültig.
Das heißt, das das 8.0.7er vertrauenswürdig ist man aber ein Problem bekommen wird, das Anydesk dessen Schlüssel für ungültig erklären wird.
Es kann sein, das die Schlüsselsperre(revoke) ein fester Teil des Notfallplanes ist.
lieber zu früh als mit bedauern.
Unverständlich ist, das Anydesk das nicht kommuniziert, wenn dem so ist.
Die Einbrecher müssen ja auch erstmal etwas haben, das sie mit dem Schlüssel signieren können und dann unter die Leute bringen. Das muss kein Programm von Anydesk sein.
Vermutlich lagen nur die aktuellen Keys auf dem kompromittieren Server Rum.
Die alten lagen wie es sich gehört, auf einem USB Stick im Tresor oder waren gar gelöscht, weil es ja neue Keys gab. Darum müssen die 7.x binaries nicht erneuert werden, weil deren Key nicht zurück gezogen werden muss.
Aber:
Das wäre Aufgabe von Anydesk das bekannt zu machen. Ich phatasiere ja und Versuche mir einen Reim drauf zu machen, was ich sehe.
Einer unserer Kunden nutzt eine Drittanbieteranwendung, deren Support nutzt dafür einen AnyDesk Host. Mir liegt das Connection Trace des Systems vor. Daraus ergibt sich für mich jedoch nicht wie der Status der Verbindung ist, sprich, war die Verbindung erfolgreich oder nicht. Das ganze sieht dann in etwas so aus:
Incoming 2024-01-16, 06:20 Passwd 123456789 123456789
Incoming 2024-01-29, 07:15 Passwd name@ad 121212121
Kann jemand hierzu etwas sagen?
es ist sehr ungewöhnlich, dass man Passwörter in ein logfile schreibt, auch wenn die falsch sind.
Sie könnten ja woanders richtig sein.
Das sind keine Passwörter. Das steht Passwd als Authentifizierungsmethode und danach entweder 2 mal die ID die den Zugriff versucht oder Name und zugehörige ID des Zugriffs.
Das ist auch mein Gedanke. Aber sagt das Log auch ob die Verbindung zu Stande kam? Das ist für mich unklar.
Die IDs sind aber schon sehr außergewöhnlich – so 123456789
@Günter Born: Bei Golem las ich eben einen recht "aufschlussreichen" Kommentar. Siehe Kommenar #3 – https://forum.golem.de/kommentare/security/cyberangriff-fernwartungssoftware-anbieter-anydesk-gehackt/richtig-uebel-ist-das-bsi/168758,6737136,6737136,read.html
Das würde meine Mutmaßung in Teil 1 bestätigen.
https://www.borncity.com/blog/2024/02/03/anydesk-wurde-im-januar-2024-gehackt-produktionssysteme-betroffen/#comment-171437
So aufschlussreich finde ich den nicht. Das BSI hat nicht die Aufgabe, jeden sofort über jede Lücke vollständig zu warnen. Genauso wie es seit Jahren Usus ist, "responsible disclosure" beim Melden von Sicherheitslücken zu betreiben, ist es auch sinnvoll, bis zur Klärung und Einordnung auch erst einmal nur einen kleinen Kreis von Leuten zu informieren.
Die Mail vom 29.01. des BSI war eine noch relativ knapp gehaltene Information, in der nicht viel mehr zu lesen war als das, was später auch von Anydesk selbst kommuniziert wurde. Halt nur zwei oder drei Tage vorher.
Dass man zuerst einmal den Betreibern kritischer Infrastrukturen die Möglichkeit gibt, auf so etwas zu reagieren, bevor man jedem Script-Kiddie die Info gibt, dass es da ein Problem gibt, ist durchaus legitim und sinnvoll.
Beim Aufruf der folgenden Seite erscheint ein 404 Fehler:
https://www.baramundi.com/de-de/remote-desk-powered-by-anydesk/
Der aktuelle ist wohl: https://www.baramundi.com/de-de/management-suite/module/remote-desk/
Also möglicherweise einfach bei Google veraltet. Finde es schwer aktuell alles wirklich einzuordnen. Man muss sicherlich aufpassen, was man jetzt alles darauf "schiebt". Ist ein unautorisierter Zugriff jetzt auf Grundlage des Angriffs entstanden oder hat derjenige nicht selbst eine Lücke gehabt?
Ich hoffe, dass alles schnell mehr erfahren.
Bei KRITIS horchte ich auf. Meine Stadtwerke sind augenscheinlich nicht tangiert.
Jedoch bietet die Stadtwerke adressierende AIDA ORGA Dortmund GmbH (https://www.aida-dortmund.de/ges/branchen/oeffentlicher-dienst/stadtwerke.php) per https://www.aida-dortmund.de/ges/download/anydesk/AnyDesk_Host.exe die veraltete (https://anydesk.com/en/changelog/windows) Version 7.0.14.0 an. Ist das unkritisch?
Man könnte die alte Version in der AV Datenbsnk als PUA eintragen und so die Kunden vor dem revoke warnen und zum Update zwingen.
Ansonsten wird der geklaute Key in 4 Wochen ungültig und Windows startet das Programm nicht mehr.
Blöde wenn das auf einem remote System passiert in einem Unternehmen ohne jede IT Kompetenz.
Der Schlüssel ist das harnlostete. Das was interessant wäre erzählen sie nicht, z B. was mit den hunderten Proxy- und Lizenz-Servern war. Warum die 48h lang gewartet mussten.
Vielleicht auch nur Notfallplan nach Schema F?
Erstmal alles aus und gucken was los ist?
Diese Kommunikation seitens Anydesk ist nicht gut.
shit happens. Das macht man mit Geheimnis krämetei nur schlimmer weil es vertrauen kostet.
Mein worst case ist derzeit, das die regelmäßig abgefragten Lizenz und Telemetrie server kompromittiert wurden und die Clients einen 0day Bug haben so das 170000 Clients kompromittiert sein könnten. Aber wenn man. das geheim hielte wäre das grob fahrlässig. Passt also auch nicht.
Das Nicht-gesagte ist das interessante…
es ist sehr ungewöhnlich, dass man Passwörter in ein logfile schreibt, auch wenn die falsch sind.
Sie könnten ja woanders richtig sein.
Du verstehst das Problem nicht :-)
ich habe Rechner1 und Server3.
Auf Rechner1 meldet sich User1 an und will etwas von Server3, und verbindet sich mit diesem.
Nun braucht User1 Daten vom Server3,
für die in einem Share von User2 liegen.
Es ist ein anderer Share.
User1 muss sich jetzt von seinem Rechner1 mit den Credentials von User2 bei Server3 anmelden.
Das geht unter Windows nicht. User1 müsste erstmal die bestehenden Verbindung von seinem Rechner1 zum Server3 abbauen. Das kommt manchmal vor, daher ist der Trick mit der IP Adresse gängig.
Aber wie gesagt,das hilft hierbei nicht weiter.
Selbstverständlich wurde bis heute noch keine Technik erfunden, dass Nutzer über das Netzwerk auf ein gemeinsames Gruppenlaufwerk auf einem "Server3" zum Datenaustausch zugreifen. Oh mann.
Klingt schwer danach, als ob die IT-Kompetenzen von dem der das Einrichtet/Administriert auf dem Niveau von Windows for Workgroups 3.11 stehengeblieben sind. Dummy IT mit wöchentlich neuen heissen Optimierungs-Tipps aus der PC-Purzel gepaart mit Geiz. Hauptsache die Registry wurde schon "aufgeräumt" mit dem XYZ-Cleaner-Tool.
verstehe nun was du meinst, weil die Zieladresse die selbe ist, aber unterschiedliche Credentials benötigt werden, die unterschiedlich berechtigt sind. Wenn user 1 Daten braucht auf die nur user 2 berechtigt ist, warum dann nicht user 1 richtig berechtigen statt account sharing?
Na das wird so sein:
User1 = User
User2 = Admin
User1 an User2 brauche dies und das. User2 geht Remote auf die Session von User1 aber dummerweiße liegt das dies und das auf eine Freigabe an die User1 nicht herankommt. Jetzt mach User2 seinen "IP-Trick" um innerhalb der Session von User1 an seine User2 Freigabe heranzukommen.
Ja kann man alles mit vernünftigen Freigaben lösen…
Die modifizierbare Client-Version 7.0.14 vom myAnydesk I Portal hat immer noch die alte Signatur (Seriennummer mit der von Bleeping Computers gecheckt). Allerdings nur mit dem Digestalgorithmus sha256. Die Signatur mit sha1 ist nicht enthalten.
Hat schon jemand ein ETA od Kommentar von Anydesk erhalten, wann endlich Mal die Version 7.0.14 bei den Custom Builds angehoben wird? Die hat seit Jahren kein Update bekommen.
Ich bin gerade etwas verwirrt. Wenn ich bei einem unserer Kunde in das Endpoint-Protection Portal gucke (Panda/Watchguard) und nach Anydesk Software suche bekomme ich für die 8.0.8 Version Rechner Installationen mit zwei verschiedenen Publishern angezeigt:
– AnyDesk Software GmbH
– philandro Software GmbH
Jeweils installiert am 29.01. in Version 8.0.8. Beides Windows 10 22H2
Auch irgendwie merkwürdig?
Die immer noch unbeantwortete Frage ist doch, warum das BSI eine klassifizierte Meldung an handverlesene KRITIS Akteure herausgegeben hat. Wen wollte /mußte das BSI auf Anweisung von wem schützen? Welche Dienste waren bei dem Hack involviert. Bestimmt nicht die Russen, da hätte man bei einer Vermutung, di noch nicht mal ein Verdacht gewesen wäre, schon großflächig informiert. Ich gehe mal davon aus, daß eineige Kunden von Anydesk durchaus im Interesse der westlichen Dienste waren und diese auch für den Hack verantwortlich sind. Irgendwie ist das aber wohl aus dem Ruder gelaufen. Merke: Umfassender Schutz muß auch und gerade gegen ALLE Geheimdienste wirken!
https://xeox.com/blog/anydesk-security-breach/