[English]Momentan werde ich bzgl. des AnyDesk-Hacks von der Entwicklung mal wieder rechts überholt. AnyDesk hat vor wenigen Stunden bestätigt, dass der Cybervorfall "Ende Dezember 2023" stattgefunden habe. Zudem dürfte das alte Zertifikat der "philandro Software GmbH" nun bemängelt werden. Hintergrund ist, dass eine dritte Stelle das "Revoke" bei DigiCert beantragt hatte und diesem Antrag stattgegeben wurde. Hier eine aktualisierte Übersicht, was sich die letzten 24 Stunden so getan hat.
Anzeige
Die Informationspolitik der AnyDesk GmbH zum stattgefundenen Cybervorfall, Details nur Schritt-für-Schritt herauszugeben, wenn es nicht mehr zu leugnen ist, scheint einigen Leuten arg auf den Senkel zu gehen, wie ich einigen Mails an mich entnehmen kann. In meiner Artikelreihe (siehe Beitragsende) hatte ich ja vom Verdacht eines Hacks im Januar 2023 (siehe AnyDesk und die Störungen: Es ist womöglich was im Busch) bis zur Bestätigung des Angriffs (siehe AnyDesk wurde im Januar 2024 gehackt, Produktionssysteme betroffen – Teil 1) und im Nachgang das Thema begleitet. So lässt sich gut verfolgen, wie der Informationsstand hier im Blog war, was das Bundesamt für Sicherheit in der Informationstechnik (BSI) kommuniziert hat und was vom betroffenen Unternehmen wann offen gelegt hat. Im Rückblick wurden viele meiner hier im Blog geäußerten Vermutungen bestätigt. Nun gibt es neue Entwicklungen.
Bestätigung des Angriffs im Dezember 2023
Ich hatte ja bereits im Beitrag AnyDesk-Hack – Weitere Informationen (FAQ) vom 5. Februar 2024 -Teil 8 darauf hingewiesen, dass ich über Informationen bzw. Indizien verfüge, dass der Cybervorfall bei AnyDesk nicht "Mitte Januar 2024", wie in der ersten Ausgabe der FAQ zum "Inzident" angegeben erfolgt sein dürfte.
Nun hat AnyDesk seine FAQ am 7. Februar 2024 aktualisiert und schreibt, dass nach einer Untersuchung der Vorfall "Ende Dezember 2023" begann. Die betreffende Ergänzung lautet (danke an den Leser für den Hinweis):
Diligent forensic investigation revealed that the incident had started in late December 2023.
Es wird also bestätigt, was ich bereits am 6. Februar 2024 auf Grund von Leserhinweisen und CERT-FR-Dokument in AnyDesk-Hack – Weitere Informationen (FAQ) vom 5. Februar 2024 -Teil 8 angedeutet und in AnyDesk-Hack bereits zum 20. Dezember 2023 bemerkt? – Teil 9 präzisiert habe.
Anzeige
Zudem findet sich nun noch der Hinweis (siehe auch diesen Kommentar) in der FAQ, welche Kunden vom Vorfall betroffen waren: "Affected customers were limited to users based in continental Europe, with the exception of Spain and Portugal." Ob das hinreichend präzise für die Kundschaft ist, muss jeder selbst beantworten.
Altes Zertifikat zurückgerufen
Und noch eine neue Entwicklung gibt es: Es dürfte Nutzern der AnyDesk-Clients, die mit dem alten "philandro Software GmbH"-Zertifikat signiert sind, nun Warnungen oder Fehler aufweisen. Michael schreibt in diesem Kommentar:
Scheinbar hat nun MS durch ein Update für SmartScreen alle philandro Zertifikate als potentiell bösartig eingestuft, das trifft nun auch alle mit Custom Clients, die immer noch bei 7.0.14 festhängen da es immer noch keine 7.0.15 gibt. Somit werden die Custom Clients unbenutzbar/nicht installierbar werden.
Das alte Zertifikat der "philandro Software GmbH" wurde zurückgerufen. Der Geschäftsführer eines mir bekannten Unternehmens hat sich vor wenigen Minuten bei mir gemeldet und schrieb, dass erDigiCert gebeten habe, dass das alte Zertifikat der "philandro Software GmbH" zu revoken. Der Schriftverkehr mit DigiCert liegt mir vor – die haben den Vorgang seit dem 6. Februar 2024 geprüft und den Widerruf des Zertifikat zum 7. Februar 2024 (Nachricht ist von 17:37 Uhr) bestätigt.
Wer die Zertifikatsprüfung aufruft, sollte dann die obige Anzeige mit dem Status "revoked" erhalten. Lasst sich das bereits bestätigen? Hab keine alten Versionen und keine Zeit, das zu testen. Aber jemand schrieb auf Mastodon, dass die neuen Clients das Zertfikat als "revoked" anzeigen, die alten Clients aber ein gültiges Zertifikat der "philandro Software GmbH" melden (siehe folgender Screenshot).
Wer noch mit Customs-Clients arbeitet, die mit dem alten Zertifikat digital signiert sind, sollte den Client also dringend aktualisieren. In meinen Blog-Beiträgen gibt es diesen Kommentar und diesen Kommentar mit Hinweisen (danke an die Leser), wie der Client 8.0.x bei Custom-Build ggf. erzwungen werden könnte.
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 (FAQ) 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
Anzeige
Warum ist SmartScreen dafür zuständig und nicht der Defender?
SmartScreen soll doch eigentlich den Browser schützen bzw Internetsurfing im Allgemeinen.
Für Dateien ist doch Defender zuständig.
Werden die neuen Malware-Signaturen zur Erkennung der alten philandro-Zertifikate auch als Defender-Update für Windows 7 oder 8 freigegeben, denn da gibt es kein SmartScreen?
Es wäre auch besser, wenn man die Signaturen zusätzlich in die Registry einträgt, damit der Schutz selbst dann noch funktioniert, wenn der Defender abgeschaltet bzw durch einen anderen Virenscanner ersetzt worden ist.
–
Die "Nachlese" des AnyDesk-Vorfalls war in Teil 5 der Artikelserie und jetzt sind wir schon in Teil 10.
Gut so, das geschieht den Fernwartungsazubis recht, die so eine Fernwartungswaffe nicht hätten anbieten dürfen, angesichts von deren verantwortungslosen Inkompetenz.
Ab Windows 10 wird Smartscreen unabhängig vom Browser verwendet für Reputation Protection. Apps werden so vor der Ausführung/Installation einer Reputationsüberprüfung unterzogen, schlägt die Alarm, wird die Ausführung blockiert sobald Admin Rechte nötig sind (im Fall von Anydesk bei Installation des Clients oder Sicherheitsrelevante Settings, die normalerweise Adminrechte benötigen zB unattend access pw und dergleichen)
Interessant finde ich, dass hier scheinbar potentiell jeder an die Zertifikatsstelle einen Revoke beantragen kann und dass da nicht zumindest eine Stellungnahme vom eigentlich betreffenden Unternehmen eingeholt wird.
Das zeigt uns wie kaputt das System der CAs ist. Mit den verbindlichen EU QWACS wird das alles noch viel schlimmer werden.
Man könnte auch sagen, es wird alles immer einfacher abschaltbar bzw. unbenutzbar, wenn eine Zertifikatverwaltung das möchte oder von Dritten dazu ausgenutzt wird.
"Interessant finde ich, dass hier scheinbar potentiell jeder an die Zertifikatsstelle einen Revoke beantragen kann und dass da nicht zumindest eine Stellungnahme vom eigentlich betreffenden Unternehmen eingeholt wird."
Ich bin derjenige der das bei Digicert gemeldet hat. Ob eine Stellungnahme eingeholt worde kann ich nicht sagen. Die CA legt ja in ihren Richtlinien fest, wie in solchen Fällen zu verfahren ist. Ich gehe davon aus, das "Private Key leacked" ein Grund für einen Revoke ist.
Musste zwischenzeitlich zum Sport, sonst hätte ich früher was geschrieben zu den zwei Aussagen:
– das hier scheinbar potentiell jeder an die Zertifikatsstelle einen Revoke beantragen kann
– und Festessen für Anwälte wegen unberechtigtem Revoke.
Nur aus der Lameng: DigiCert ist eine Stelle, die bescheinigt, dass Software, die mit diesem Zertifikat digital signiert ist, zu einem Anbieter gehört, den man in einem Kontext als vertrauenswürdig klassifiziert hat.
Sobald der Verdacht besteht, dass ein Zertifikat unsicher ist (weil der private Schlüssel zum Signieren entwendet werden sein könnte), kann die Cert-Stelle das Zertifikat revoken. Das BSI hat bestätigt, dass Zertifikate zurückgerufen werden – und von AnyDesk gibt es den Hinweis, dass das alte Zertifikat zurückgerufen werden soll.
Zum "kann jeder": Wieso nicht? Wenn ich mal den Fall konstruiere, dass ich mir ein Zertifikat ausstellen ließ, welches von x Softwarefirmen verwendet wird. Im März 2015 hatte ich einen schweren Sportunfall, und war über 7 Wochen komplett weg vom Fenster und 18 Monate arbeitsunfähig. Man stelle sich vor, mein privater Schlüssel mit Zertifikat wäre in falsche Hände gefallen und für die Signierung von Malware missbraucht worden. Jeder wüsste das, aber DigiCert könnte nicht revoken, weil ich nicht anhörbar war. So läuft das nicht.
Es reicht der begründete Verdacht für ein Revoke – und DigiCert hat das (ausweislich der E-Mail, die mir vorliegt) vor dem Revoke geprüft. Also mal schnell einen unberechtigten Revoke zum Lahmlegen eines Konkurrenten veranlassen, wird nicht möglich sein.
Im Übrigen hatten wir nicht Fälle, wo Zertifikate nicht rechtzeitig zurückgerufen wurden und dann die Cert-Stelle ziemlich im Feuer stand? Irgendwo habe ich CA oder Symantec im Hinterkopf, kriege es aber nicht mehr richtig zusammen.
ich habe ja nicht kritisiert, dass es zurückgerufen werden kann von Dritten, das ist ja auf jeden Fall legitim, und das ist auch gut so. Aber ob da jetzt Gefahr in Verzug ist oder nicht wirkt halt etwas konstruiert Aufgrund von Spekulationen.
Eine angemessene Frist für eine Stellungnahme um den Softwarehersteller um sein Statement hätte es auch getan.
Und Mal ehrlich wenn wir jetzt jedem Unternehmen die Zertifikate entziehen, dass irgendwie/irgendwo Mal unseriös gearbeitet hat, und irgendwo Vertrauen verspielt hat, müsste man den Großteil des Internets leerfegen.
MS war vor Kurzem gehackt über ein Testsystem, das lächerliche Schutzvorkehrungen und sogar gegen eigene Regeln verstoßen hat – demnach müssten wir ihnen ja auch die Zertifikate entziehen, weil nicht mehr vertrauenswürdig/Vertrauensverlust oder nicht?
Symantec hatte Zertifikate an Dritte für Google Domains ausgestellt, was genauso höchst fragwürdig ist und natürlich optimal für Spionagezwecke missbraucht werden kann. Deshalb hatten sie ihre CA verspielt damit.
"MS war vor Kurzem gehackt über ein Testsystem, das lächerliche Schutzvorkehrungen und sogar gegen eigene Regeln verstoßen hat – demnach müssten wir ihnen ja auch die Zertifikate entziehen, weil nicht mehr vertrauenswürdig/Vertrauensverlust oder nicht?"
Viel Spaß dabei – die haben ihre eigene CA. Das dürfte dann schwer werden ;)
"Und Mal ehrlich wenn wir jetzt jedem Unternehmen die Zertifikate entziehen, dass irgendwie/irgendwo Mal unseriös gearbeitet hat, und irgendwo Vertrauen verspielt hat, müsste man den Großteil des Internets leerfegen."
Bitte lasse doch solche Rabulistik.
Hier:
Versuchen durch Übertreibung die Gegenseite lächerlich zu machen.
Es bringt einer sachlichen Diskussion nichts.
Bei mir wird in Windows zum Zertifikat für die philandro GmbH weiterhin angezeigt, dass das Zertifikat gültig sei. Ich kenne mich damit aber auch nicht aus und weiß nicht, wie ich eine Zertifikatsüberprüfung anstoße. Windows bietet mir hier nur die Möglichkeit, dass Zertifikat anzuzeigen
"Interessant finde ich, dass hier scheinbar potentiell jeder an die Zertifikatsstelle einen Revoke beantragen kann und dass da nicht zumindest eine Stellungnahme vom eigentlich betreffenden Unternehmen eingeholt wird."
Was soll da noch eingeholt werden, wenn dieses Szenario öffentlich bekannt ist? Ich finde es eher absolut unverantwortlich, dass bei so einer Entdeckung nicht UMGEHEND(!!) der Revoke vom Unternehmen sofort selbst veranlasst wurde! Denn DAFÜR sind ja diese Revokes da, um sofort Schaden abzuwenden.
Und dass so ein Zertifikat nicht auf einem Server gelagert werden darf, der öffentlich zugänglich ist, lasse ich jetzt mal ausser Acht. So ein Unternehmen dürfte nie mehr ein Zertifikat von einer CA bekommen, wenn SO damit umgegangen wird.
welches Szenario? Öffentlich bekannt und offiziell bestätigt ist nur, dass das Zertifikat Aufgrund des Incident Response plan routinemäßig getauscht wurde, es aber nach offiziellen Aussagen keinen Hinweis dafür gab, dass es abgegriffen wurde.
Wo steht, dass das Zertifikat auf einem öffentlich erreichbaren Server gelagert wurde?
Jedenfalls hat das jetzt nun potential für Schadenersatzforderung würde ich sagen, da werden sich jetzt sicher wieder ein paar Anwälte freuen, wenn Anydesk nun einen ungerechtfertigten Revoke nachweisen kann (da offiziell nur als Vorsichtsmaßnahme getauscht wurde und somit keine Gefahr im Verzug ist)
Wo steht denn bitteschön, dass es nicht abgegriffen wurde? Gibt es da ein Statement vom Unternehmen? Wozu sonst der Wechsel? Routinemässig – wirklich? Hier würde ein Statement, dass das Zertifikat nicht abgegriffen wurde, für mehr "Vertrauen" sorgen.
AUCH wäre es mehr als wünschenswert, wenn das Unternehmen seinen Kunden VERSICHERN würde/könnte, dass jegliche automatische Updates, welche die Clients selbstständig im Dezember 2023 / Januar 2024 durchgeführt haben, mit sauberen Binaries von AnyDesk versorgt wurden, die original von AnyDesk stammen und NICHT kompromittiert wurden. Dies kann man wohl als Kunde erwarten – oder?
Denn selbst wenn diese Binaries mit einem AnyDesk Cert. (egal ob neu oder alt) signiert wurden, fehlt mir hier ein Statement, welches mir versichert, dass Kunden-Systeme zu KEINER ZEIT durch automatische Updates in Gefahr waren.
UND es fehlt auch noch MINDESTENS eine E-Mail an die Kunden, damit die überhaupt über diesen Vorfall Bescheid wissen!!
Und wo steht von Anydesk, dass das code signing cert abgegriffen wurde? Mir fehlt auch immer noch deine Quelle, dass das Cert auf einem public Server war. Ich stimme dir auch vollkommen zu, dass die Mail an alle Kunden fehlt, das steht aber auch nicht zur Debatte.
Anydesk offizielles statement bestätigt "The situation is under control and it is safe to use AnyDesk."
https://anydesk.com/en/faq-incident
da steht übrigens auch:
Do I need to download new software update?
Yes. Even though all AnyDesk versions obtained from our official sources are safe to use, we will shortly be issuing software updates for all version and custom clients with a new certificate.
Therefore, we are asking customers to update their AnyDesk version as soon as the updates are available. Once the new software updates have been rolled out, current certificates will be revoked.
das mag nun stimmen oder nicht, ich kritisiere niemanden der aktuell Anydesk von seinen Systemen verbannt hat. Aber die offiziellen Aussagen zumindest widersprechen dem "Gefahr in Verzug" Gedanken. Jedenfalls werden das dann wohl die Gerichte klären müssen, falls Anydesk hier dann rechtliche Schritte erwägt.
Mag auch jeder für sich selbst das Risiko einschätzen, Risk Management gehört ja zur IT auch. Aber wie wild zu spekulieren bringt einem in so einer Situation auch nicht weiter vor Allem wenn man darauf aufbauend weitreichende Konsequenzen verursacht.
"Mir fehlt auch immer noch deine Quelle, dass das Cert auf einem public Server war"
Nun ja, das liegt Nahe, sonst wären die Custombuilds nicht innerhalb von Milisekunden Downloadbar. Aber man könnte das natürlich auch anders lösen, einen Beleg kenne ich auch nicht.
Weiterhin liegt es SEHR nahe, das der Codesigninprozess ein Problem hat, sonst hätte man das neue Zertifikat ja innerhalb von Minuten einsetzen können.
Ich zumindest bin sehr damit einverstanden, dass es nun revoked wurde, das darf sich gerne in der Branche rumsprechen, dass es ggf. Nebenwirkungen hat, wenn man so dämlich und ungenügend bei so einer wichtigen Sache kommuniziert.
Und alle Admins, die so ein Produkt auf "wichtigen" Servern installieren, dürfen auch gerne bei der nächsten Risikoabschätzung so etwas mit einbeziehen, täte der Branche m.E. gut.
Das alles ändert natürlich nichts an der Sache, das Codesigning ansich schon nicht wirklich was bringt.
Also ich habe immer nur gelesen, das es keine Hinweise auf einen Missbrauch des Code Certs gegeben hat und das sämtliche AnyDesk Software sicher sei.
Das der Virus der bei Virustotal gefunden wurde, wurde durch zusammenkopieren erzeugt.
Das kann jeder der Zugriff auf das .exe hat.
Aber AndyDesk hatte Besuch auf seinen "Produktiv Systemen, was immer das ist. Und darum wollen die vorsorglich das Code Cert zurück ziehen.
Damit haben sie natürlich keine Eile, weil es nicht sicher ist, das es wirklich gestohlen wurde,nebst SourceCode.
Es wurde schon öfters klar gestellt:
AnyDesk muss erstmal bei allen Kunden draußen die Binaries mit dem neuen CodeCert ausgeliefert haben
Einige Kunden werden den Client auf headless Rechnern irgendwo im Keller/Rechenzentrum stehen haben. Würde das CodeCert revoked, so würden das AnyDesk auf diesen Rechnern nicht mehr starten.
D.h. der Rechner bekommt kein Update mehr und kann auch nicht mehr vom Support geupdatet werden.
Welcher Teufel da DigiCert geritten hat, das OdeCert auf Hinweis eines Dritten zu teboken wird wohl noch geklärt werden. Es war absolut nicht OK, da keine konkrete Gefahr in Verzug war.
Natürlich hat AnyDesk das mit ihrer Geheimistuerei verbockt. Wer vertraue braucht, darf keine Geheimnisse haben.
@Michael: wg. der Frage nach der Quelle bzgl. der Zertifikats-Geschichte… https://www.quorumcyber.com/threat-intelligence/anydesk-code-signing-certificate-compromised-and-revoked
da steht: "AnyDesk, a leading remote desktop software provider, has confirmed a significant security breach in its production systems. Detected following suspicious activities, a security audit revealed the compromise, leading to the theft of source code and code signing certificates."
Ausserdem habe ich jetzt selbst eine Anfrage an AnyDesk direkt gestellt, mit der Bitte, mir zu versichern, dass die automatischen Updates im Zeitraum Dezember 2023/Januar 2024 sauber und nicht kompromittiert waren. Mal sehen, was und ob da überhaupt was kommt.
ok irgendwie ist mein Kommentar weg, ich sehe es zumindest nicht mehr, evtl. wegen dem Anydesk URL im Kommentar.
das ist aber keine offizielle Quelle und referenzieren auch nur wieder weitere Artikel, die dann die Info auch nicht aus offizieller Quelle habe – ist das nicht Spekulation?
Ist Dir BleepingComputer genehmer, wenn auch nicht offiziell?
https://www.bleepingcomputer.com/news/security/anydesk-says-hackers-breached-its-production-servers-reset-passwords/
da steht: "AnyDesk did not share details on whether data was stolen during the attack. However, BleepingComputer has learned that the threat actors stole source code and code signing certificates."
nur weil ein Blog vom Anderen abschreibt machen die Spekulationen nicht wahrer. Ohne offizielles Statement sind das zwar alles realistische Schlussfolgerungen, aber keine Fakten.
Offizielle Statements dienen heutzutage zu 90% der Verzögerung und Vernebelung und Verharmlosung und Verantwortungabschieberei, das dürfte doch wohl jedem aufgefallen sein, der 1 und 1 zusammenzählen kann. Ja, man darf auch selbst denken, Danke an Herrn Born, dass er das als einer der wenigen vorlebt.
Offizielle Quelle? Das BSI? Der Wirtschaftsminister? Das Innenministerium? Oder gar der US-Präsident? Der Hersteller selbst wird ganz sicher alles nur möglichst keine Fakten verlautbaren lassen.
Das von Günter schon erwähnte Malware-Sample (OKJhBah6.exe), das auf VirusTotal hochgeladen wurde, ist lt. VT am 2023-11-09 07:48:00 UTC mit dem jetzt gesperrten Zertifikat signiert worden. Hier nochmal der Link: https://www.virustotal.com/gui/file/ac71f9ab4ccb920a493508b0e0577b31fe547aa07e914f58f1def47d08ebcf7d/details
Habe hier einen alten 7er AD-Client vom Sommer 23. Seriennummer und Fingerabdruck sind mit dem der OKJhBah6.exe identisch. Somit hatte jemand am oder auch vor dem 09.11.23(!) bereits Zugriff auf das AD-Zertifikat. Nur mal so von wegen "…keine Gefahr im Verzug".
Und BTW: wenn ich schon ein neues Zertifikat beantrage (als "Vorsichtsmaßnahme"), dann lasse ich das alte Zertifikat ebenfalls als Vorsichtsmaßnahme direkt sperren. Das hat AD aber nicht gemacht. Und der Grund ist doch sehr wahrscheinlich, dass denen klar war, dass dann schlagartig alle Custom-Clients lahmgelegt werden.
Dieses exe ist m.W. nicht mit dem CodeCode signiert worden.
Sondern irgendein Scherzkeks hat ein Virus.exe genommen und da per "copy /b", den Öffentlichen Teil des Certs ran kopiert.
Er bräuchte dazu nicht den Privaten Teil des Certs.
Wenn anydesk aus Sicherheitsgründen umgehend ein "revoke" beantragt hätte, dann hätten die Nutzer ja sehr zeitnah mitbekommen, dass etwas Vorgefallen ist. Diese Tatsache wollte man bei anydesk ja auf jeden Fall verhindern.
Mich würde mal interessieren was sie zu dem Fund bei virustotal sagen, der auf die Signierung einer Malware (OKJhBah6.exe) mit den CodeSignCert von anydesk (philandro Software GmbH) am basiert und das Datum 2023-11-09 06:48:00 UTC trägt ???? Hat mal bei anydesk einer nachgefragt???
Ich könnte mir da so eine Antwort vorstellen…
"Die Signierung hat nichts(!) mit dem "incident" zu tun. Das war wahrscheinlich ein entlassender Mitarbeiter, der das "CodeSignCert" unrechtmäßig entwendet hat und einen neuen, illegalen Einkommenszweig etablieren wollte."
Der Blog wird wahrscheinlich genau beobachetet und nur so viele weiteren Info herausgegeben als nötig, das ist die sog. "Salamitakit"
Zitat aus wikipedia:
"Eine weitere Verwendung für Salamitaktik beschreibt die Vorgehensweise, die Wahrheit nur scheibchenweise zu „servieren". Eine in Bedrängnis geratene Person verrät nur so viel von ihrem (vermeintlichen) rechtlichen oder moralischen Fehlverhalten, wie ihr bereits nachgewiesen werden kann oder wie sie es für als taktisch sinnvoll erachtet."
Wenn man die Versionen der verstecken FAQ, dann miteinander Vergleicht, dann steht man fest, das durch die "Salamitakit", sie sich in Widerspruche verstricken.
Und damit absichtlich "Lügen" vertreiben, so einer Firma sollte man vertrauen?!?
Auf englisch nennt man das "limited hangout" (statt Salamitaktik).
"Mich würde mal interessieren was sie zu dem Fund bei virustotal sagen, der auf die Signierung einer Malware (OKJhBah6.exe) mit den CodeSignCert von anydesk (philandro Software GmbH) am basiert und das Datum 2023-11-09 06:48:00 UTC trägt ???? Hat mal bei anydesk einer nachgefragt???"
in der neuen FAQ gehen sie auch darauf ein.
Ganz am Ende.
(Die lurken hier, sei sicher).
das hat nix mit vertuschen zu tun, wenn keine Gefahr in Verzug ist, dann revokest du nicht dein Zertifikat und legst damit gleich Mal alle Clients lahm sondern schaust erst Mal, dass deine Kunden upgedated sind und nach einer gesetzten Frist das Zertifikat revoken.
So ist es natürlich viel besser, wenn dadurch höchst wahrscheinlich das auto update auch nicht mehr funktioniert, damit die Clients das richtige Zertifikat verwenden können. Nicht alle Personen, die Anydesk verwenden, sind IT affin und können das selbst updaten.
Mit dem ersten Absatz sind wir schlicht auf dem spekulativen Ast. Niemand von uns weiß, was intern bei AnyDesk abläuft, ob Gefahr in Verzug ist oder nicht. Möglicherweise brauchen die einfach 2 Wochen, um ihre internen Prozesse umzustricken.
Der Punkt: Die haben erklärt, die Zertifikate zur digitalen Signierung zu revoken. Die französische ANSSI war da gegenüber der Öffentlichkeit rigoroser: "Klärt, wo AnyDesk eingesetzt wird, macht einen Inventarisierung, stellt eine Risikoanalyse auf und deaktiviert alle AnyDesk-Instanzen anhand dieser Risikoklassifizierung und geht auf Alternativen. Geht eure Logs bis mind. 20. Dez. 2023 auf ungewöhnliche Ereignisse durch". Und hier wird diskutiert "wenn keine Gefahr im Verzug ist". Also, ich verstehe es nicht …
… oder doch. Gerade heute noch den Seufzer eines Sicherheitsverantwortlichen im KITIS-Bereich auf den Tisch bekommen, in dem sich dieser über "gelebte Verantwortungslosigkeit" in diesem Bereich aufregt. Cybersicherheit in Deutschland? Gute Nacht. Aber hey, wir feiern die Inbetriebnahme des Nationalen IT-Lagezentrum mit der Presse (siehe obiger Screenshot). So geht Cybersicherheit, nicht.
Ich würde behaupten Handlungen/Äußerungen auf Basis von bloßen Schlussfolgerungen sind Spekulation so lange das nicht offiziell irgendwo bestätigt wird.
Fakten kann hier nur Anydesk schaffen – in der Kommunikation haben die ganz klar versagt, völlig klar.
"Fakten kann hier nur Anydesk schaffen – in der Kommunikation haben die ganz klar versagt, völlig klar."
Wenn nur das "Opfer" selbst hier klare Fakten schaffen kann, dann "Gut' Nacht und kein Bett!".
Du darfst auch selbst denken.
Und geh dabei einfach davon aus, dass Du nie alle "Fakten" bekommen wirst, nirgends. Wer darauf wartet lebt in Traumwelten und nicht in der Realität.
Das ist in anderen Ländern nicht anders.
@Günter Born
Danke für die Beurteilung! Manchmal ist das BSI zum Fremdschämen.
"macht einen Inventarisierung, stellt eine Risikoanalyse auf und deaktiviert alle AnyDesk-Instanzen anhand dieser Risikoklassifizierung und geht auf Alternativen."
Das kann aber auch ganz leicht zum Beißreflex führen á "Warum fordern denn die Franzosen, unser AnyDesk auszutauschen?"
Der BSI-Neubau ist übrigens 2023 gescheitert: "Kein Neubau für das BSI in Bonn-Plittersdorf", Radio Bonn
Ob das die letzte Neueröffnung des Lagezentrums in diesem Jahrzehnt gewesen sein wird? Ich denke nicht! Der Personalaufwuchs war enorm. Trotzdem ist die "Cybernation" so nicht machbar.
Habs grad getestet.. Neue Custom-Clients welche man aktuell über my.anydesk.com generiert verwenden noch das alte Zertifikat und scheinen damit in Windows direkt als ungültig auf.
Bei früher erstellten Custom-Client sehe ich in den erweiterten Informationen des Zertifikats:
Sperrstatus : OK.
Effektives Datum Donnerstag, 8. Februar 2024 04:03:02
Nächste Aktualisierung Donnerstag, 15. Februar 2024 03:03:02
Somit scheint der alte Custom-Client noch bis 15.02. zu funktionieren und dann ist Schluss..
Hab mir gerade mal die Custom-Version unseres IT-Dienstleisters angeschaut und kann das bestätigen.
Sperrstatus : OK. Effektives Datum Nächste Aktualisierung
AD Version 7.0.14
Ob man das jetzt wirklich noch so verbreiten muss…
also hier:
http://crl3.digicert.com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
ist das Zertifikat noch nicht drin …
bei
http://ocsp.digicert.com
steht es auf revoked (siehe oben …)
Als der "jemand von Mastodon" hier noch mein Senf dazu:
Neuer Client erstellt unter my.anydesk.com, Zertifikat mit dem "DigiCert Certificate Utility" geprüft, Zertifikat wird als "revoked" angezeigt.
Unser alter Client (ebenfalls v7.0.14) wurde im 2022 im gleichen Portal heruntergeladen. Dort zeigt das Certificate Utility keine Fehler an und das Zertifikat ist bis 09.Januar 2025 gültig.
Das Utility zum Check der eigenen Clients gibt es hier zum Download:
https://www.digicert.com/support/tools/certificate-utility-for-windows
Jap, so ist es auch bei uns.
Zusätzlich sind bei uns manche Builds bei myanydeskII defekt (können nicht mehr heruntergeladen werden).
schau mal in das Log deiner Firewall.
Vielleicht blockt die den Download weil das Cert revoked wurde?
Ich hatte auch mal so ein Teil.
Aber besser als die, die die Fehlermeldung irgendwie ins Binary schreiben. Da sucht man auch lange warum es nicht geht.
Darum ist "strings" fast mein Lieblings Befehl geworden…
Nein, die Builds sind in myAnydesk defekt sobald man auf Download drückt erscheint "Oops, something went wrong… We are working on getting the issue resolved. Please try to reload.".
Aber Danke für die Tipps.
Der Windows-Defender bzw dessen SmartScreen-Funktion blockieren das Speichern der runterzuladenden Datei, weil die Signatur wegen des zurückgezogenen Zertifikats ungültig ist und deswegen die Datei als Schädling eingestuft wird.
Time to say goodbye
Bezüglich Custom-Clients muss man wohl warten, bis Anydesk die Version 7.0.15 veröffentlicht. Laut Anydesk-FAQ.
"AnyDesk Custom Client: The current version is 7.0.14. We will release a new version for Custom Clients with our new certificate very soon. We will communicate how to update with the new release"
Mit dem Umweg Konfigurationsschalter "_module=XXXX" kann ich zwar auch andere Versionen (< 7.0.15/7.1.15/8.0.8) erstellen, aber nur mit dem alten, zurückgezogenen Zertifikat.
Die CodeCert Version hängt nicht mit der Versions Nummer der Software zusammen.
Schon klar. Das System bei Anydesk verwendet momentan (gestern) noch das alte Zertifikat für alle Versionen.
und ist das wirklich upgrade tauglich, so dass man seine Version plötzlich anheben kann? Ich glaube mit dem Mod lässt sich eher nur die Funktionalität downgraden. Also 7.0.14 und alles darunter.
Es gibt halt gem. Changelog neuere Versionen als 7.0.14 aus dem 7.1.x-Zweig, die sich nur mit dem Schalter generieren lassen.
Ich vermute mal, das ist ein anderer Release-Kanal (nicht stabil?).
Offiziell wird 7.0.14 (11.08.2022) als letzter Custom-Client genannt. 7.1.16 (06.09.2023) wäre aktueller.
Ich tendiere halt dazu, möglichst aktuelle Software einzusetzen, finde aber bei Anydesk keine konkreten Infos zum 7.1.x-Zweig.
Es gibt halt noch aktuellere Versionen als 7.0.14 aus dem 7.1.x-Zweig, ich vermute mal das ist ein anderer Release-Kanal (nicht stabil?).
Finde bei Anydesk leider keine konkreten Infos dazu.
Für die von Anydesk-Tools abhängigen Kunden entwickelt sich die Sache gerade zum Gau, ganz unabhängig davon was wirklich passiert ist. Dass jetzt ein Dritter das problematische Zertifikat revoken lassen konnte, ist die Krönung. Wars evtl. Teamviewer?
Habs weiter oben schon geschrieben: Ich habe das nicht revoked, ich habe freundlich bei DigiSign eine Mail geschickt: Hey, zwei Regierungen haben das Zert als kompromitiert in offiziellen Reports, besteht da Handlungsbedarf?
Die Entscheidung hat Digicert getroffen, und die ist aus meiner Sicht auch richtig. Wenn man das nicht macht, dann kann man sich den ganzen PKI-Kram auch sparen.
Was mich echt ärgert, ist die Kommunikation. Fehler passieren, die Materie ist komplex. Das würde ich niemandem vorwerfen, auch dann nicht wenn es richtig schief geht. Aber klare Ansage was Sache ist muss sein.
ja, ich denke da an diesen PKI Server, der auch kein Revoke kennt und völlig zugemüllt wurde.
Anyway, seltsam das AndyDesk es nicht gebacken bekommrn scheint OEM Versionen mit einem neuen Cert auszuliefern. So sieht es jetzt aus.
Die neuen Clients bleiben jetzt in der Firewall hängen, weil das CodeCert revoked ist, oder,
Und Kunden von AnyDesk haben jetzt die absolute A-Karte, weil die Fernwartung nicht mehr funktioniert.
Herzlichen…
Für mich sieht's so aus, das Anydesk unbestellen Besuch auf irgendwelchen "produktiv Systemen" festgestellt hat.
Wie ich hier gelernt habe, wird jede OEM (custom) Version einzeln signiert.
Das kann bedeuten, dass der Private Key auf den "Produktiv Systemen" liegen könnte, die diesecOEM Versionen erzeugen, "produzieren".
Nicht ganz klar wird mir aus der Beschreibung, ob das auf einem der vermutlich hunderten Relayservern erfolgte, oder auf dem "my.anydesk".
Da AnyDesk auf vermutlich my.anydesk die Passwörter zurückgesetzt hat (und dabei wohl auch 2FA gelöscht hat,klar) ist das vielleicht kompromittiert worden.
Wenn dort auch die OEM Version erzeugt wurde,weil man sich dazu ja anmelden muss, liegen dort evtl. Zugänge zu Passwörtern und das Code signing Certificate nebst privaten Schlüsseln.
Es könnte sein, das das neue Cert nur auf einem HSM geliefert wurde und nur damit/darin genutzt werden kann. Vielleicht muss AnyDesk das OEM built ändern, was länger dauert als erwartet.
Kein Kunde hätte etwas dagegen eine 7.x neuzuinstallieren nur um ein neue signiertes zu bekommen.
Soweit ich verstanden habe sollen die Kunden zur 8.x wechseln. Diese kostet aber viel mehr als die 7.x, was manche Kunden nicht möchten.
man könnte sich natürlich eine wilde, absurde Verschwörungs Theorie ausdenken, das das ganze nur dazu dienen könnte die Kunden zu motivieren auf die 8.x zu wechseln …
Aber es ist wohl auch nicht möglich mit der 8.x eine OEM Version zu erzeugen, oder?
Also nix Verschwörung…
Jeder von Dritten abhängiger Software Nutzer lebt unter ständigem Risiko eines vergleichbaren GAU, wenn er Software nutzt, die jederzeit über Revokes von Dritten deaktiviert werden kann. Und jetzt mal kurz nachdenken, wo das überall zutrifft und warum man trotzdem fleissig weiter mitmarschiert.
Windows updated seine Zertifikatdatenbank nur 1 mal pro Woche.
Man kann aber ein Windows-Update installieren, damit diese Zertifikatdatenbank alle 24 Stunden erneuert wird:
"Support for urgent Trusted Root updates for Windows Root Certificate Program in Windows"
support[.]microsoft[.]com/en-us/topic/support-for-urgent-trusted-root-updates-for-windows-root-certificate-program-in-windows-a4ac4d6c-7c62-3b6e-dfd2-377982bf3ea5#bkmk_prerequisites
Gilt für Windows 7, 8, 8.1, Server 2008 R2, Server 2012, Server 2012 R2.
"Simon" hat hier um 15:34 Uhr auch genau diesen Wochenrhythmus in der Zertifikatüberprüfung gezeigt.
Ich nehme an, er benutzt Windows 10 oder 11, also gibt es dieses Problem dort auch.
Gibt es aber einen Patch, wie man dieses Zertifikatupdate bei Win10 auf 24 Stunden umstellen kann oder einen Registry-Schlüssel zur Konfiguration oder eine GPO-Regel?
Man kann auch manuell diese Zertifikatupdates anstoßen:
Certutil -syncWithWU -f \\fr-dc01\\SYSVOL\\woshub.com\\rootcert\\
(der erste Backslash nach dem "-f" soll ein doppelter Backslash sein, die anderen nur einfache Backslashes)
https://www.virustotal.com/gui/file/ac71f9ab4ccb920a493508b0e0577b31fe547aa07e914f58f1def47d08ebcf7d/details
da steht (jetzt?)
"The digital signature of the object did not verify"
manchmal ist ein Screenshot doch hilfreicher
Das stand da schon von Anfang an ("The digital signature of the object did not verify").
Ist ja auch korrekt so.
Der öffentliche Teil des Zertifikats ist halt nur von einer anderen Datei kopiert und an den Schädling dran kopiert worden und nicht wirklich zertifiziert, wozu ja ein neuer Hash nötig wäre.
ACK.
Dann ist das so Zusagen Fake.
Denn das CodeCert liegt ja jedem Programm von AnyDesk bei. Da muss man nirgends einbrechen.
Stellt sich die Frage, wer so etwas tun sollte?
Follow the money?
Kann die CA das Cert wieder frei geben?
Wenn bei uns ein Yubikey abhanden kommt, sperre ich auch als erstes das Zertifikat für den Domainlogon und VPN, warum soll ich warten, bis das Mißbraucht wird?
Taucht der Stick wieder auf, wird das Zertifikat wieder freigegeben, fertig ist.
Oder ist bei Codesgining eine Revoke für immer?
Mal abgesehen von der Tatsache, das manchmal ie Cleints nur alle X Tage aktualisieren.
Du willst warten, weil Deine Kunden gelakmeiert wären wenn Du den Schlüssel sperrst. Deine Kunden könnten due die gekaufte Software nicht mehr verwenden und die Software ist kein Email-Programm sondern eine Fernwartungs Software.
Und es gibt Computer die laufen ohne Tastatur und Bildschirm und werden nur per Fernwartung bedient. Wenn die sich selbständig die revoke Liste geholt haben war's das mit der Fernwartung.
Dann muss irgendwer in den Keller und einen KVM over IP an die Hardware anschließen oder irgendwie erreichen, das die Kiste ein altes Imagestarter oder man irgendwie an die Registry kommt oder…
Wird klar was der Unterschied zu einem verloren RSA-Token ist am
Es besteht ja erst dann eine Gefahr, wenn jemand böse Binaries damit signiert und in die Wildnis trägt.
"Es besteht ja erst dann eine Gefahr, wenn jemand böse Binaries damit signiert und in die Wildnis trägt."
Nein, es ist für mich nicht hinreichend von Anydesk belegt worden, dass von der Software ansich keine Gefahr ausgeht. Und deshalb begrüße ich die Tatsache, dass die Software auch ohne mein Zutun nicht mehr funktioniert.
Das tue ich auch unter dem Gesichtspunkt, dass igendein Spezialexperte die Software auf einem Server installiert hat auf dem persönliche Daten von mir liegen.
Wenn ich einen wichtigen Server mit Anydesk (oder andere Cloudanbieter) als Fernwartungssoftware austatte, habe ich die Kontrolle über meine IT verloren und es nicht besser verdient.
Wenn es ein unwichtiger Server war, hab ich halt pech gehabt.
Es hindert niemanden Anydesk endlich transparent mit der Sache umzugehen, dazu wäre eine aktive Information an Kunden das Minimum.
Die haben ERNEUT die Kontrolle über Ihre Software aufgegeben. Zuerst durch den Hack und jetzt durch eine Sperre von Dritten.
Sie haben es m.E. nicht besser verdient.
Das ändert natürlich nichts an der Sache, dass mir alle tatsächlich Leid tun, die das jetzt ausbaden, wir sind davon auch betroffen, aber nur für den Ad Hoc Support und da wars schon zäh genug.
"Nein, es ist für mich nicht hinreichend von Anydesk belegt worden, dass von der Software ansich keine Gefahr ausgeht."
Dann kann ich Dir nicht helfen, wenn Du die Zusammenhänge nicht erfassen kannst. Dafür ist hier nicht der Platz.
@Günter
kommen hier jetzt immer mehr Sockenpuppen die die Diskussion stören wollen?
"Dann kann ich Dir nicht helfen, wenn Du die Zusammenhänge nicht erfassen kannst."
Ich denke schon, dass ich die Zusammenhänge sehr gut erfasse. Nur weil Du andere Schlussfolgerungen als ich aus den spärlichen Informationshappen, die Anydesk zur Verfügung stellt ziehst, würde ich Dir niemals unterstellen, dass Du die Zusammenhänge nicht erfasst. Du wertest sie halt anders, das ist Dein gutes Recht.
Ich denke auch nicht, dass das die Diskussion stört, sondern schlicht ein Bestandteil eines diskurses ist.
Wenn ich das für mich zusammenfasse kommt dabei raus:
Du möchtest lieber, dass eine Zertifizierungsstelle wartet, bis es verlässliche Informationen zur Zuverlässigkeit eines Zertifikatsbenutzers gibt und erst tätig wird, wenn das Kind in den Brunnen gefallen ist und baust darauf, dass es nicht passiert, was ja auch sehr gut sein kann.
Ich möchte lieber, dass eine Zertifizierungsstelle bei einem Verdacht auf Unzuverlässigkeit sofort tätig wird.
Ich finde schon, dass beide Sichtweisen durchaus ihre Berechtigung haben, von Deiner kann ich das für mich durchaus sagen.
Hier jetzt aber persönlich zu werden, ist dann doch weit unter meinem Niveau. Ich bitte um Entschuldigung, dass ich dich offenkundig auf dem falschen Fuß erwischt habe, war nicht meine Absicht.
Und wozu braucht man dazu AnyDesk und Konsorten?
Warum nicht per RDP?
Wie kommst du von Außen von deinem eigenen Netz per RDP in ein anderes internes Netzwerk? Portforwarding von RDP auf die öffentliche IP-Adresse des Gateways des Netzes?
Also ich nutze RDP über SSH-Portforward, der SSH-Server natürlich sandboxed und firewalled.
Ist bestimmt nicht unsicherer, als ein gleichermassen exponierter AD/RD-Rendezvouzserver oder gar den public Server eines Dritten zu nutzen.
Ok, das kann man machen, bedeutet aber, dass man im Zielnetz erstmal einen SSH-Endpunkt installieren muss. Das ist kein reines Öffnen von mstsc und Eingabe einer Ziel-IP in einem fremden Netz. So ein SSH-Endpunkt könnte auch mal kompromitiert sein.
weil Du mit RDP nicht durch Fenster Systeme kommst.
Die weiteren Nachteile hatten wir hier so xa. im Teil diskutiert.
Software wie AnyDesk macht den Fernzugriff sehr einfach. Und wenn es schief geht kann man auf wen anders zeigen..
Teamvierr erlaubt auch die Verbindung der Netze auf Ebene. Es gibt nämlich auch andere Computer auf dieser Welt als Windows.
Ob Anydesk so ein seltenes Feature hat weiß ich nicht. Irgendwoher muß ja der Preisunterschied kommen
irgendwie hat mein Browser ein Problem mit dem Scrollen und das Smart Keyboard ist nicht so smart und leider musste Günter wohl die Editierfunktion deaktivieren?
das sollte sein
"weil Du mit RDP nicht durch Firewall/Natting Systeme kommst.
Die weiteren Nachteile von RDP hatten wir hier ca. im 4. Teil diskutiert."
Die Editierfunktion funktioniert.
Allerdings dar man keinen Scriptblocker wie uMatrix im Browser aktiv haben.
ublock und AdGuard sind hingegen kein Probem.
Ich habe in uMatrix lediglich www.borncity.com 'freigeben' müssen, habe keine Probleme mit Post oder Edit (FF 115.7).
@ Hr. Born:
wenn ich den String "www.b.com" kommentiere wird das in einen Link umgewandelt und mit "https://…" angezeigt. Wär schön, wenn Sie das abschalten könnten.
Abschalten kann ich nicht – soll auch so bleiben, alleine wegen der Filterung gegen SEO-Spam. Man kann das so lösen, indem *ttps://www.b.com verwendet wird.
Ich musste gerade aus irgendwelchen unerfindlichen Gründen an den Bezahldienstleister-Vorfall im April 2023 denken.
https://www.borncity.com/blog/2023/04/06/anydesk-probleme-stellungnahme-des-herstellers-und-weitere-insights/
Und dann wie in so einer schlechten Serie, beep, boop, beep, boop…
"5 Monate bis zum BSI-Vorfall"
Den linken Screenshot mit dem Sperrtext
"Dieses Zertifikat wurde durch seine Zertifizierungsstelle gesperrt."
erhält man auch dann, wenn man manuell den Fingerabdruck ( 9CD1DDB78ED05282353B20CDFE8FA0A4FB6C1ECE ) in die Registry unter SystemCertificates\\Disallowed\\Certificates eingetragen hatte (sowohl unter HK_Local_Machine als auch unter HK_Users).
Diese Registry-Einträge muss man also erstmal entfernen, wenn man die Sperre durch DigiCert testen möchte.
Da ja nun das Cert geblockt ist, müsste AndyDesk nicht die Erzeugung der OEM versioen stoppen?
Die Kunden vertun ja Zeit.
Jetzt mal eine ganz blöde Frage… wenn einer von den Anwendern von Anydesk diesem Produkt wirklich vertraut, warum signiert er die EXE nicht einfach selbst neu mit seiner internen CA? Nur zu dem Zweck natürlich, dass dieses nicht durch die Zertifikatsprüfung von Windows rauscht.
PS: Foxit Reader z. B. meckert , wenn auch nur eine PDF-Datei durch ein unsigniertes Programm gestartet werden soll (Aufruf einer PDF-Datei aus einem ZIP-Archiv mit 7-Zip). Tatsächlich "genervt" hat das nur aus einer uralten Fachanwendung fürs Einwohnerwesen in einer Kommunalverwaltung (EXE war ebenfalls nicht signiert. Die Software wurde mittlerweile in Rente geschickt).
Gute Idee.
Das wird der Geschäftsführer meines Kunden gewiss gerne machen. Er spielt ja den Hilfsadmin.
Außerdem hat er natürlich solche Zertifikate rumliegen, wie mein Opa auch.
Vielleicht doch nicht so gut die Idee?
Das war auch kein Vorschlag für deinen Opa oder den Hilfsadmin. Dafür sollte man schon
– wissen, was eine CA ist
– selbst eine betreiben (können)
– selbst ein Code-Signing-Zertifikat ausstellen und entweder das Root- (als Stammzertifizierungsstellenzertifikat) oder das Code-Signing-Zertifikat (als vertrauenswürdigen Herausgeber) an die Endgeräte verteilen können.
Die Idee ist natürlich nur dann gut, wenn man AnyDesk immer noch vertraut, seinen alten Client weiterbetreiben will und entsprechend Ahnung von Zertifikaten und Signierung von Anwendungen (und dem ggf. nötigen Neupacken des Installers) hat. Ansonsten ist das nix, was Hans, Franz, der GF aka Hilfsadmin deines Kunden oder dein Opa können dürften.
Ich habe mir gerade die aktuelle "certificate revocation list" (CRL) von Digicert runtergeladen.
Die URL der CRL-Datei steht im Detail-Dialog des Zertifikats der anydesk.exe drin.
Anleitung für Windows 7:
Rechtsklick auf Anydesk.exe
Eigenschaften, Reiter "Digitale Signaturen",
Zertifikat "philandro Software GmbH" anklicken,
"Details"-Button anklicken,
"Zertifikat anzeigen" anklicken,
Reiter "Details" anklicken,
runterscrollen bis "Sperrlisten-Verteilungspunkte" und dieses anklicken,
unten im Feld erscheinen dann 1 oder 2 URLs (Mirror):
crl3[.]digicert[.]com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
crl4[.]digicert[.]com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
(eckige Klammern entfernen)
Diese URLs einfach in die Adresszeile eines Browsers kopieren oder an einen Downloadmanager übergeben und so diese CRL-Dateien runterladen.
Die runtergeladene CRL-Datei mit Doppelklick öffnen:
Gültig ab: 8. Februar 2024 16:21:14
Nächste Aktualisierung: 15. Februar 2024 16:21:14
Klickt man auf den Reiter "Sperrliste", dann findet man viele gesperrte Seriennummern und das Sperrdatum, aber die Seriennummer des Anydesk-Zertifikats steht da nicht drin oder ich habe sie übersehen.
Wenn man die CRL-Sperrliste mit certutil importiert (Pfad anpassen):
certutil -addstore -f "Root" C:\\cert\\DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
und anschließend das Zertifikat der anydesk.exe anschaut, dann ist es immer noch nicht gesperrt.
Wo liegt der Fehler?
Falsche Sperrliste?
Die URL ist aber im Zertifikat selber hinterlegt, also müsste die auch stimmen.
Hat Digicert die Seriennummer heute noch nicht gesperrt, sondern das erfolgt erst bis zum 15.Februar?
Du sorgst dich um eine potentiell unsichere Softweare, unter Windows 7?
Windows 7 ist sicher, bekommt noch bis Oktober 2024 Sicherheitsupdates!
Voraussetzung:
BypassESU v12 installiert und den Win7_WU_ESU_Patcher installiert.
Korrekt. Aber Dein Vorposter lebt in einer anderen Welt, für ihn ist Telemetrie und Cloud viel sicherer.
Wobei Windows 7 auch schon per Update vor vielen Jahren etwas Telemetrie eingetrichtert bekam.
Kann man aber abstellen.
Aber sicherlich auch nur weil es noch eine kompatible Version gibt, für die noch Sicherheitsupdates herausgegeben werden:
*ttps://learn.microsoft.com/en-us/lifecycle/products/windows-embedded-posready-7
Das dürfte nach Oct 8, 2024 dann zuende sein. Spätestens dann sollte man die Kiste vom direkten Netz trennen oder von dem Gaul absteigen und in Rente schicken.
Server 2008 R2 ist ürigens laut lifecycle seit Jan 9, 2024 raus.
*ttps://learn.microsoft.com/en-us/lifecycle/products/windows-server-2008-r2
Der Custom-Client der Compugroup Medical trägt übrigens zwar immer noch die Version 7.0.14, ist allerdings schon mit dem neuen Zertifikat der "Anydesk Software GmbH" (0a8177fcd8936a91b5e0eddf995b0ba5) signiert. Signaturzeitpunkt war am Abend des 08.02. (Donnerstag, also ganz frisch). Also irgendwie scheint es ja doch schon möglich zu sein, den alten Custom-Client mit neuer Signatur zu erzeugen.
Ich schrieb ja oben was, dass man sich seinen Client ja auch "einfach" selbst signieren könnte.
Hat die Compugroup Medical vielleicht ein paar Münzen bei Anydesk eingeworfen, damit die das "mal eben" von Hand signieren?
"Wo liegt der Fehler?
Falsche Sperrliste?
Die URL ist aber im Zertifikat selber hinterlegt, also müsste die auch stimmen."
Das fragliche Certificate (Serial: 0DBF152DEAF0B981A8A938D53F769DB8) ist mit Revocation Date 19. Dezember 2023 widerrufen worden.
Ich gehe davon aus die ueberpruefte Datei wurde vor dem 19. Dezember 2023 signiert. Das wuerde die nach wie vor gegebene Gueltigkeit erklaeren.
Die CRL kann z.Bsp. mit openssl ueberprueft werden.
Serial Number: 0DBF152DEAF0B981A8A938D53F769DB8
Revocation Date: Dec 19 00:00:00 2023 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Auch ein check via OCSP kommt zum selben Resultat:
0x0DBF152DEAF0B981A8A938D53F769DB8: revoked
This Update: Feb 8 03:03:02 2024 GMT
Next Update: Feb 15 02:03:02 2024 GMT
Reason: keyCompromise
Revocation Time: Dec 19 00:00:00 2023 GMT
Die Code Signging WG des cabforum definiert wie das Revocation Date anzuwenden ist:
4.9.6 Revocation checking requirement for relying parties
A Certificate MAY have a one‐to‐one relationship or one‐to‐many relationship with the signed
Code. Regardless, revocation of a Certificate may invalidate the Code Signatures on all signed
Code, some of which could be perfectly sound. Because of this, the CA MAY specify the time at
which the Certificate is first considered to be invalid in the revocationDate field of a CRL entry
or the revocationTime field of an OCSP response to time‐bind the set of software affected by the
revocation1
, and software should continue to treat objects containing a timestamp dated before the
revocation date as valid.
D.h saemtlicher Code welcher vor dem 19. Dezember 2023 mit dem besagten Certificate signiert wurde bleibt weiterhin vertrauenswuerdig.
Danke für den Tipp mit dem 19.Dezember 2023.
In der CRL-Liste crl3[.]digicert[.]com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
steht die Seriennummer 0DBF152DEAF0B981A8A938D53F769DB8 tatsächlich drin.
Aber da frage ich mich, wie dieses Sperrdatum zu Stande kommt.
Da muss doch jemand am oder vor dem 19.12.2023 eine Revoke-Anforderung an DigiCert gestellt haben oder demjenigen war bekannt, dass am 19.12.2023 etwas bei anydesk passiert ist und die Sperranforderung wurde erst später gestellt. Da muss es Insiderwissen geben, also von anydesk selber.
Die Sperre wurde doch erst gestern oder vorgestern beantragt.
Wie bekommt man jetzt diese CRL ins System, so dass de anydesk.exe gesperrt wird?
Wie lautet der certutil-Befehl?
Heißt das jetzt, das Zertifikat wird ab einschließlich 19.Dezember 2023 als ungültig eingestuft und bis einschließlich 18.Dezember 2023 als gültig?
Heißt das, dass Software, die bis einschließlich 18.Dezember 2023 signiert wurde, weiterhin als gültig eingestuft wird?
Das würde Sinn machen und es würde auch erklären, warum die alte anydesk.exe 7.0.14 trotz importierter CRL weiterhin nicht gesperrt ist, denn sie wurde am 8.12.2022 signiert und das Datum ist vor dem 19.12.2023.
Es werden also nur die exe gesperrt, die ab einschließlich 19.12.2023 mit dem alten Zertifikat signiert worden sind?
Habe ich das so richtig verstanden oder nicht?
So würde es Sinn ergeben.
Die bereits installierten Anydesk dürfen noch laufen, alles (nicht nur anydesk) nach dem 20.12. nicht.
Fragt sich:
Warum hat Anydesk das nicht gleich so gemacht?
So haben sie alle, nicht nur Kunden, dem Risiko ausgesetzt, bösartige Software zu starten, die durch den geklauten Key signiert worden war.
-Wenn das cert ab dem 20. gesperrt worden wäre, wäre ja klar gewesen, das der Vorfall nicht Ende Januar war. Also haben die es gelassen.
-Sie haben schlicht und ergreifend nichts von dieser Möglichkeit gewusst und gefürchtet den Kunden die Stiefel auszuziehen.
-Das Sperren erfolgte ohne Zutun von AnyDesk sondern war eine Aktion von DigiCert. Und die haben das Datum das in der Warnung des Franz. BSI stand genommen.
BTW.
Diese Probleme mit dem Support korrelieren anscheinend zeitlich mit dem Wechsel im Management, bei dem der ursprüngliche Gründer ausgestiegen ist. Seit dem gibt es auch keine Bilanzen mehr bei Bundesanzeiger.de (oder northdata).
Den Screenshot mit dem OCSP-Checker kann ich bestätigen.
Ich habe das Zertifikat der anydesk.exe exportiert (Base-64-X.509 codiert) und dann diesen exportierten Text auf der Webseite des OCSP-Checker per copy und paste eingefügt.
certificatetools[.]com/ocsp-checker
Nach dem Klick auf den "Validate"-Button wurde das Zertifikat als "revoked", also zurückgezogen angezeigt.
Also ist in der Online-Datenbank das alte "philandro Software GmbH" Zertifikat gesperrt ( ocsp[.]digicert[.]com ).
In den runterladbaren Sperrlisten von DigiCert ist es allerdings noch nicht gesperrt.
Das kommt dann vermutlich am 15.Februar
crl3[.]digicert[.]com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
Warum gibt es diese Sperrlisten nicht tagesaktuell zum Runterladen?
Auf Wikipedia steht:
"Vorteile:
Im Gegensatz zu Sperrlisten, die nur in bestimmten Intervallen erstellt werden und damit nicht immer aktuell sind, können OCSP-Responder sekundengenaue Sperrinformationen liefern, sofern sie eine aktuelle Datenbasis verwenden"
de[.]wikipedia[.]org/wiki/Online_Certificate_Status_Protocol#Vorteile
Neuigkeiten:
hier http://crl3.digicert.com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.cr
gibt es nun eine neue Sperrliste, gültig ab 8.2.2024, 16:21:14
darin ist ein Sperrvermerk:
Seriennummer: 0dbf152deaf0b981a8a938d53f769db8
Sperrdatum: Dienstag, 19. Dezember 2023 01:00:00
Sperrlistengrundcode: Schlüsselkompromittierung (1)
damit sollte die 8.0.6 noch als gültig, die 8.0.7 und alle Custom Clients welche nach dem 19.12.23/01:00 erstellt wurden als ungültig angezeigt werden
Wie bekommt man diese CRL jetzt ins System mit dem certutil-Befehl?
Der Befehl den ich weiter oben angegeben hatte scheint keine Wirkung zu haben.
Ich habe eine neue Custon Version erstellt (altes Portal, V7.0.14 – MSI Version). Die EXE, die ja als Dienst auf dem Zielrechner läuft, hat aber keinerlei Zertifikat Infos mehr. Die "alte" Version von 09/2023 hat diese Infos noch. Was ist da passiert?
Die Win32 Exe Version wurde ebenfalls neu erstellt und enthält folgende Infos. Signiert am 09.02.2024 10:22Uhr gültig bis 09.01.2025
Verwechsle ich da etwas?
Ich dachte, man muss jede Exe signieren.
Wenn nicht, gibt's Rückfragen beim Start.
Bei einer Exe die im Hintergrund laufen soll gibt's dann ein Problem, da ja der Bildschirm detached ist, oder wer gibt das OK?
Von Microsoft gibt es auch zwei CRL Sperrlisten:
crl[.]microsoft[.]com/pki/crl/products/CodeSignPCA.crl
crl[.]microsoft[.]com/pki/crl/products/CodeSignPCA2.crl
Befehl zum einbauen ins System (Pfade der runtergeladenen CRL-Dateien anpassen):
certutil -addstore CA c:\\cert\\CodeSignPCA.crl
certutil -addstore CA c:\\cert\\CodeSignPCA2.crl
certutil -addstore CA c:\\cert\\DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crl
Alle 3 Befehle wurden erfolgreich ausgeführt.
Dennoch bleiben die Zertifikate der alten anydesk.exe 7.0.14 und 7.1.16 weiterhin gültig.
Ist das so, weil diese VOR dem Sperrdatum 19.12.2023 signiert worden sind?
Oder muss man da den Computer erstmal neustarten, bevor die CRL-Listen gültig werden?
Im certmgr.msc kann man die Zertifikate im System anschauen.
Bei mir steht die gesperrte Seriennummer jetzt drin im Pfad:
"Vertrauenswürdige Stammzertifizierungsstellen",
"Zertifikatsperrliste",
auf "DigiCert Trustet G4…" doppelklicken,
Reiter "Sperrliste",
In der Tabelle runterscrollen bis 19.Dezember 2023 um 01:00:00 Uhr
Da steht die Seriennummer 0DBF152DEAF0B981A8A938D53F769DB8
Es gibt sogar einen zweiten Eintrag mit dieser Seriennummer.
Unter "Zwischenzertifizierungsstellen",
"Zertifikatsperrliste",
auf "DigiCert Trustet G4…" doppelklicken,
Reiter "Sperrliste"
Die Seriennummer ist also definitiv 2 mal im System.
Sperrdatum 19.Dezember 2023 um 01:00:00 Uhr.
Das Zertifikat der alten Anydesk.exe wird aber dennoch nicht als ungültig angezeigt.
Ich vermute weil die exe vor dem Sperrdatum signiert wurde.
Aber immerhin weiß ich jetzt, dass der certutil Befehl korrekt arbeitet und die CRL ins System einträgt.
certutil -addstore CA PFAD_zur_CRL_Datei
In der Registry stehen übrigens weder die Seriennummer noch der Fingerabdruck drin.
Über den Fingerabdruck könnte man das Zertifkkat komplett sperren, ohne Sperrdatumsgrenze.
Dann würden auch die vor dem Sperrdatum signierten exe gesperrt.
Die Unterschiede zwischen den certutil-Parametern ROOT und CA sind dort beschrieben:
www[.]serverbrain[.]org/certificate-security-2003/publishing-certificates-and-crls-to-the-local-computer-store.html
Bei ROOT wird die CRL-Sperrliste im certmgr.msc unter
"Vertrauenswürdige Stammzertifikatstellen" eingetragen.
Bei CA wird die CRL-Sperrliste im certmgr.msc unter
"Zwischenzertifizierungsstellen" eingetragen.
Ich habe beide Varianten des certutils Befehls ausgeführt, also einmal mit Parameter ROOT und einmal mit Parameter CA, und deswegen habe ich die Seriennummer auch an diesen beiden Stellen im System.
Hi,
"… Über den Fingerabdruck könnte man das Zertifkkat komplett sperren, ohne Sperrdatumsgrenze…."
Geht das via GPO/Intune/Powershell. Finde dazu so gar nichts im Netz…
Problem:
Die Malware, die bei VirusTotal das selbe alte Zertifikat von "philandro Software GmbH" drankopiert hatte, die wird aktuell weiterhin nicht als gesperrt eingestuft, obwohl die Seriennummer des Zertifikats in der Sperrliste im System drin steht.
Das liegt vermutlich an dem Datum 9.November 2023 der Malware, was ja auch vor dem Sperrdatum 19.Dezember 2023-01:00:00 Uhr liegt.
Was also nützt die Sperrliste konkret, wenn sowas gar nicht verhindert wird?
Die selbe AgentTesla-Malware mit der identischen Checksumme wie bei VirusTotal kann man sich dort unter "Download Sample" runterladen, zum Testen der Signatur (Passwort: infected):
bazaar[.]abuse[.]ch/sample/ac71f9ab4ccb920a493508b0e0577b31fe547aa07e914f58f1def47d08ebcf7d/#iocs
(auf keinen die exe starten!)
Es klingt vernünftig, dass ein Revoke erst ab einem bestimmten Datum wirksam wird.
Erst nachdem es gestohlen wurde, würde es nicht mehr vertrauenswürdig.
Es besteht ja auch keine Notwendigkeit alles bisher existierende mit diesem Cert zu sperren. Denn die alten Binaries werden ja nicht auf einmal böse nur weil das Cert geklaut wurde.
Das bedeutet:
Es besteht keine Notwendigkeit mit dem Revoke zu warten bis alle Kunden das neue Binaries haben.
Es erklärt warum Anydesk immer noch OEM binaries mit dem alten Cert unterschreibt.
Es erklärt nicht, warum Anydesk nicht schon neue Certs verwendet.
Ist denn sicher, dass das Datum der Dateierstellung und insb. -signierung nicht gefälscht werden kann?
Der Nachbar meines Friseurs hat früher gelegentlich einfach das Systemdatum verändert, bevor er eine Datei ausführte oder kompilierte, um Lizenzabläufe zu umgehen oder das gewünschte compile-Datum zu haben.
gute Frage. Hatte ich mich auch gefragt.
Es müsste ein Abgleich der Systemzeit mit der Zeit beim Certificates Geber erfolgen.
D.h. das das signierten nur bei bestehender Online Verbindung möglich wäre.
Die Frage ist halt, was mit dem revoke nach Datum bezweckt werden soll.
Es wäre schön blöd wenn ein Dieb einfach das Datum der Signatur ein paar Monate zurück stellen könnte.
Das Datum und die Uhrzeit wird beim Signieren mit dem Signtool mittels Parameter //t oder //tr (1 Slash) und dann über die angegebene URL eines Zeitstempeldienstes ( ts.ssl.com ) erzeugt.
Durch diesen online-Zeitdienst-Zwang beim Signieren ist die eventuell umgestellte eigene Systemzeit des Malware-Erzeugers nicht relevenat und beeinflusst das Signierdatum nicht.
learn[.]microsoft[.]com/de-de/dotnet/framework/tools/signtool-exe
www[.]ssl[.]com/de/wie-man/Verwenden-Sie-Ihr-Codesignaturzertifikat
Vielleicht kann ein Hacker aber auch seinen eigenen Zeitstempelserver betreiben und dann damit signieren?
Vermutlich darf man nur sauber registrierte und verifizierte Zeitstempelserver benutzen?
Vielleicht ist dieser Zeitstempel aber auch gar nicht zwingend erforderlich.
Da wurde schon auch daran gedacht. Versuche das hier mal verstaendlich aber nicht allzu technisch darzulegen. Das Stichwort lautet Timestamping
Grundsaetzlich kann auch ohne Timestamp signiert. Wurde "früher" auch so gemacht. Das heisst zum Zeitpunkt der Ueberpreufung einer Signature gibt es nur 3 gesicherte Zeitpunkte.
1. Der aktuelle Zeitpunkt (man muss sich "selber vertauen" dass man weiss welche Zeit es ist (da kann man natuerlich seine lokale Zeit beliebig faelschen…))
2/3 Der Anfang und das Ende der Gueltigkeit des Signing Certificate.
Das hat zur Konsequenz das ein Signature nur waehrend der Gueltigkeit des zur Signierung verwendeten Certificates gueltig ist da man nicht feststellen kann wann die Signature erstellt wurde. D.h wenn das Certificate heute ablaeuft ist der damit signierte Code morgen nicht mehr gueltig signiert. (Ausser man bescheisst sich selber mit der aktuellen Zeit…). Auch im Falle eines Revokes hat das natuerlich auch die entsprechenden Konsequenzen.
Da kann man erahnen, dass dies in der Praxis gewisse unschoene Probleme bereiten kann. Gestern lief es noch – heute nicht mehr.
Aus diesem Grund wurde das Timestamping eingefuehrt. Dadurch existiert nun ein vierter gesicherter Zeitpunkt. Der Zeitpunkt zu welchem signiert wurde. Wie wird das gemacht. Vereinfacht laeuft das wie folgt. Waehrend dem signieren wird ein Hash der zu signierenden Daten (hier der Code) erzeugt. Dieser wird an einen Timestamping Service gesendet und der schickt eine Signatur zurueck welche diese Hash und den aktuellen Zeitpunkt enthaelt. Diese Signature muss natuerlich durch ein Certificate geschehen welchem vertraut wird (man vertraut diesem Timestampservice dass er korrekt die aktuelle Zeit verwendet). Diese Signature wird nun an den Code angehaengt und das ganze dann signiert. Natuerlich muss dieser Timestamp innerhalb der Gueltigkeitsspanne des Signing Certificates liegen. Damit ist erreicht das eine Signatur auch ueber den Ablauf (oder hier nun den Revokezeitpunkt) des Signing Certificates gueltig bleiben kann da jetzt der Zeitpunkt der Erzeugung der Signatur zweifelsfrei feststeht. Auch kann nicht mehr durch das Verstellen der lokalen Uhr die Gueltigkeit beeinflussen.
Die neuen OEM binaries sind jetzt aber nach dem Sperrdatum mit dem alten key signiert und sollten deswegen ein gesperrtes ungültiges Zertifikat haben und Windows weigert sich dann die Datei zu starten.
Ich habe es nicht getestet. Das muss jemand machen, der sich gerade eine neue custom anydesk.exe bauen lässt.
Also heute versucht auf div. Systemen die Custom-Clients(win) zu installieren – SmartScreen und WD Blockt ab. Selbst die 8.x Clients mit Flag in den Einstellungen.
Edit: Selbst bei 8.x Custom's noch das alte Zert. aufgeführt.
gute Frage. Hatte ich mich auch gefragt.
Es müsste ein Abgleich der Systemzeit mit der Zeit beim Certificates Geber erfolgen.
D.h. das das signierten nur bei bestehender Online Verbindung möglich wäre.
Die Frage ist halt, was mit dem revoke nach Datum bezweckt werden soll.
Es wäre schön blöd wenn ein Dieb einfach das Datum der Signatur ein paar Monate zurück stellen könnte.
Wenn das Datum online bestätigt werden muss, ist das Zertifikat seit dem Revoke ja wertlos. (für alle)
Der Timestamp ist ja wohl mit dem Zertifikat verkoppelt und wird nun nicht mehr geliefert, oder?
Hat mal wer 'rausbekommen, wem AndyDesk inzwischen gehört?
Offensichtlich tut sich was bei AnyDesk. Wir können seit gestern späten Nachmittag keinen Custom Client im Portal (I) erzeugen, da die Funktion deaktiviert wurde (die betreffende Ansicht ist aktuell ausgegraut).
Kann ich bestätigen. Sowohl im Portal I wie auch im Portal II.
Ich schreibe gleich noch was dazu. AnyDesk-Hack: Revoke-Chaos bei alten Zertifikaten? – Teil 11
20.12.: Hack von AnyDesk
Mitte Jan.: Meldung ans BSI und anschließende Zusammenarbeit mit BSI und Crowdstrike
Mitte Jan – 28.01.: Bereinigung der AnyDesk Systeme
29.01.: BSI informiert ANSSI
02.02.: Pressemitteilung AnyDesk
05.02.: BSI-Warnung TLP:clear und ANSSI-Warnung
Vermutlich hatte das BSI ab Mitte Jan erst einmal selbst ihre Leute bei den Behörden und in der kritischen Infrastruktur informiert, bevor sie dann später ANSSI und sogar erst nach der Hersteller-Pressemitteilung die Öffentlichkeit informierten. Was läuft bei denen denn falsch?
Wollte AnyDesk nicht, dass überhaupt etwas an die Öffentlichkeit gerät und hat es versucht, die TLP:clear-Warnung zu verhindern?
Hat Frankreich Informationen genannt, die das BSI bisher nicht genannt hatte? Hat das BSI deshalb ihre TLP:clear-Warnung veröffentlicht?
Wurden neben Frankreich auch andere Partner informiert?
Welche Rolle spielt Frankreich bei dem ganzen? Steckt mehr dahinter? Ist es ein APT-Angreifer (Supply-Chain-Angriff "This incident is not related to ransomware.")?
Das mögliche Abfließen von Source-Code und Zertifikaten ist dann vermutlich doch ein wenig mehr als "möglich"?!
Was war in Spanien/Portugal passiert?
Warum werden keine Bilanzen mehr veröffentlicht?
(Falls sich wer gefragt hat, warum 48 Angestellte gemeldet wurden? Das könnte an einer Grenze für die Veröffentlichungs Pflicht liegen die 50 ist. Aber kann ja Zufall sein und die kamen mit 48 Angestellten aus.