Hinweise auf das Abfangen von verschlüsseltem Jabber.ru-Traffic bei Hetzner und Linode entdeckt

 (notes.valdikss.org.ru)
1 Punkte von GN⁺ 2023-10-21 | 1 Kommentare | Auf WhatsApp teilen
  • Es wurde bestätigt, dass XMPP-STARTTLS-Verbindungen über Port 5222 auf einem dedizierten Hetzner-Server und Linode-VPS des russischen XMPP-Dienstes jabber.ru/xmpp.ru durch einen transparenten MiTM-Proxy abgefangen wurden.
  • Die Angreifer ließen mehrere TLS-Zertifikate über Let’s Encrypt ausstellen und beendeten die verschlüsselten Verbindungen in der Mitte; sichtbar wurde das Problem, als Hetzners jabber.ru auf Port 5222 ein abgelaufenes Zertifikat auslieferte.
  • Es fanden sich weder Hinweise auf einen Servereinbruch noch auf ARP-Spoofing im selben Netzsegment; die Linode-Instanzen zeigten andere Pfade und Gateway-MACs als normale VMs, was stark auf eine Rekonfiguration des Hosting-Netzwerks hindeutet.
  • Der MiTM wurde mindestens vom 21. Juli 2023 bis zum 19. Oktober bestätigt; möglich ist ein Beginn bereits am 18. April 2023. Betroffen waren 100 % der Verbindungen über Port 5222, Port 5223 jedoch nicht.
  • Die Kommunikation von jabber.ru/xmpp.ru in diesem Zeitraum muss als kompromittiert gelten; Ende-zu-Ende-Verschlüsselung wie OMEMO, OTR und PGP schützte nur dann, wenn beide Seiten die Schlüssel verifiziert hatten.

Durch ein abgelaufenes Zertifikat aufgedecktes Abfangen

  • jabber.ru ist ein russischer XMPP-Dienst, der 2000 gestartet wurde und auch als xmpp.ru bekannt ist.
  • Beim Zugriff auf den Dienst am 16. Oktober 2023 erschien die Meldung „Certificate has expired“, obwohl alle auf dem Server installierten Zertifikate aktuell waren.
  • Das ungewöhnliche Verhalten trat nur auf Port 5222 für XMPP STARTTLS auf und wurde auf anderen Ports wie XMPP TLS über Port 5223 nicht beobachtet.
  • Betroffen waren ein dedizierter Server bei Hetzner in Deutschland und zwei virtuelle Server bei Linode.
  • Im Traffic auf Port 5222 wurde beobachtet, dass der Server nicht das ursprüngliche ClientHello des Clients erhielt, sondern ein ersetztes ClientHello.

Ergebnis der Untersuchung auf eine Kompromittierung des Servers

  • Untersucht wurden die Möglichkeiten eines Server-Hacks und eines lokalen Netzwerk-Spoofings.
  • Auf Serverseite wurden folgende Punkte geprüft, ohne Auffälligkeiten zu finden:
    • Logs insgesamt
    • Änderungszeitpunkte von Binärdateien und Bibliotheken
    • Laufende Prozesse, Memory Maps und dangling file descriptor
    • Vorhandensein von User-Space-LD_PRELOAD-Hijacking-Bibliotheken mithilfe statisch kompilierten busybox
    • Vorhandensein von Hijacking-Modulen auf Kernel-Ebene durch Dump des Kernel-Speichers mit LiME und Analyse mit volatility
  • In den Kernel-Logs des dedizierten Hetzner-Servers wurde nur eine Ausnahme gefunden: Am 18. Juli 2023 war der physische Netzwerk-Link 19 Sekunden lang unterbrochen.
  • Die Linode-Server wurden nur als Tunnel für alternative Routen zum Hetzner-Server genutzt und führten lediglich Basisdienste wie SSH und NTP aus.
  • Innerhalb des Tunnels zwischen Hetzner und Linode war das korrekte ServerHello des Hetzner-Servers sichtbar, wurde jedoch verändert, wenn es über das Netzwerkinterface von Linode an den Client gesendet wurde.
    • Damit trat dieselbe Art des Abfangens verschlüsselter Verbindungen sowohl bei Hetzner als auch bei Linode auf.

Auffälligkeiten im Linode-Netzwerk

  • Aus Netzwerksicht wurden folgende Punkte geprüft, ohne Spuren eines Hijackings im servernahen Netzwerk zu finden:
    • ARP-Spoofing der Gateway-MAC-Adresse
    • Ob eine IP im L2-Segment mehrfach auf ARP-Anfragen antwortet
    • Anormale Routing-Regeln, die etwa per ICMP redirect injiziert wurden
    • Netfilter-Regeln
    • Vorhandensein schwer erkennbarer Tunnel wie IPsec
  • Betroffene Linode-Maschinen konnten benachbarte IPs im selben Segment nicht per ARP finden oder anpingen, während diese benachbarten IPs aus externen Netzen normal funktionierten.
  • Eine unbeeinflusste Linode-VM eines Dritten konnte benachbarte Hosts anpingen und war mit einem Router von Cisco Systems verbunden.
  • Die betroffenen VPS waren dagegen mit einem Gateway verbunden, dessen MAC-Adresse keinem Hersteller zugeordnet werden konnte.
  • Dieser Unterschied macht es wahrscheinlich, dass die betroffenen Linode-VMs eine andere Netzwerkkonfiguration als normale Linode-Instanzen hatten oder in einem separaten VLAN isoliert waren.

Gefälschte Zertifikate und Spuren in Certificate Transparency

  • In der crt.sh certificate transparency database wurden rogue certificates gefunden, die nicht von den jabber.ru-Servern ausgestellt wurden.
  • Im normalen XMPP-Dienst wurden zwei Arten von Zertifikaten verwendet:
    • xmpp.ru, *.xmpp.ru
    • jabber.ru, *.jabber.ru
  • Die böswillig ausgestellten Zertifikate unterschieden sich leicht von den regulären Zertifikaten:
    • Entweder fehlte das Wildcard Subject Alternative Name
    • oder jabber.ru und xmpp.ru wurden gemeinsam in einem Zertifikat ausgestellt
  • Die MiTM-Konfiguration auf Linode für die Domain xmpp.ru war teilweise fehlerhaft.
    • Der eigentliche Server war so konfiguriert, dass er je nach angeforderter XMPP-Domain sowohl jabber.ru- als auch xmpp.ru-Zertifikate bereitstellt.
    • Die MiTM-Seite lieferte jedoch nur das xmpp.ru-Zertifikat aus.
  • Der Ausstellungszeitpunkt eines Zertifikats am 18. Juli 2023 fällt nahezu mit dem Zeitpunkt zusammen, an dem der Netzwerk-Link des Hetzner-Servers einige Sekunden unterbrochen war.
  • Ein externer Netzwerkscanner bestätigte, dass der Linode-Server mindestens seit dem 21. Juli 2023 auf Port 5222 das Zertifikat 04:b7:85… auslieferte.
  • Der Scanner erfasste den Hetzner-Adressbereich nicht.

Vorgeschaltete Geräte vor Port 5222 und Unterschiede im Pfad

  • Es wurden zusätzliche Netzwerktests von außen gegen einen Linode-VPS durchgeführt.
  • Benachbarte Hosts im selben Linode-Segment waren über die Internetverbindung eines Laptops bei Hop 13 erreichbar.
  • Auch der abgefangene Port 5222 des Linode-Servers dawn.jabber.ru war bei Hop 13 erreichbar.
  • Nicht abgefangene Ports desselben Servers, etwa SSH über Port 22, waren jedoch erst bei Hop 14 nach einem zusätzlichen nicht öffentlichen Hop erreichbar.
  • Das deutet darauf hin, dass sich die IP-Adresse der Linode-VM hinter einem zusätzlichen Gerät befand, das TCP-Port 5222 direkt verarbeitete und andere Ports an das tatsächliche Ziel weiterleitete.
  • Innerhalb des VPS konnten keine neuen Verbindungen mit Source-Port 5222 aufgebaut werden.
    • Der Router antwortete nicht auf Pakete mit diesem Source-Port.
    • Für ausgehende Pakete mit TTL=0 oder TTL=1 wurden weder ICMP-Fehler noch Time-to-Live Exceeded gesendet.

Art der STARTTLS-Terminierung und Erkennungsmerkmale

  • Laut Prüfung mit testssl.sh erlaubte der abfangende Proxy sowohl bei Linode xmpp.ru als auch bei Hetzner jabber.ru anonymous ciphers.
  • Das ist eine seltene Fehlkonfiguration und kann als Erkennungsmerkmal für XMPP-MiTM dienen.
  • Gängige SSL/TLS-Bibliotheken werden in der Regel ohne Unterstützung für anonymous ciphers kompiliert, und selbst bei expliziter Freigabe in der Konfiguration ist es oft schwierig, Dienste zur Nutzung dieser Cipher zu bringen.
  • Auf den ursprünglichen Servern waren keine anonymous ciphers konfiguriert.
  • Mit demselben testssl.sh-Befehl wurden etwa 20 populäre XMPP-Dienste geprüft, ohne Auffälligkeiten wie Unterstützung für Anonymous NULL Ciphers zu finden.

Bestätigte Schlussfolgerungen und Auswirkungen auf Nutzer

  • Die Angreifer ließen seit dem 18. April 2023 mehrere SSL/TLS-Zertifikate für die Domains jabber.ru und xmpp.ru über Let’s Encrypt ausstellen.
  • Ein Man-in-the-Middle-Angriff zur Entschlüsselung des XMPP-Client-Traffics von jabber.ru/xmpp.ru ist mindestens für den Zeitraum vom 21. Juli 2023 bis 19. Oktober 2023 bestätigt.
  • Ein Beginn bereits am 18. April 2023 ist möglich, aber nicht bestätigt.
  • Der Umfang der Beeinträchtigung lag bei 100 % der XMPP-STARTTLS-Verbindungen über Port 5222; Port 5223 war nicht betroffen.
  • Den Angreifern misslang die erneute Ausstellung der TLS-Zertifikate, woraufhin der MiTM-Proxy auf Hetzners jabber.ru-Port 5222 begann, ein abgelaufenes Zertifikat auszuliefern.
  • Der MiTM-Angriff endete kurz nach der Untersuchung und den Netzwerktests am 18. Oktober 2023 sowie nach dem Einreichen von Support-Tickets bei Hetzner und Linode.
  • Auf mindestens einem Linode-Server blieb jedoch zusätzliches passives Abhören in Form eines weiteren Routing-Hops bestehen.
  • Es gab keine Hinweise auf einen Server-Hack; stattdessen scheint das Netzwerk von Hetzner und Linode gezielt für diese Attacke auf die IP-Adressen des XMPP-Dienstes rekonfiguriert worden zu sein.
  • Die Kommunikation von jabber.ru/xmpp.ru in diesem Zeitraum muss als kompromittiert betrachtet werden.
    • Die Angreifer konnten sich so verhalten, als seien sie von einem authentifizierten Konto aus aktiv, auch ohne das Kontopasswort zu kennen.
    • Sie konnten die Konten-Roster herunterladen, auf unverschlüsselte vollständige serverseitige Nachrichtenprotokolle zugreifen, neue Nachrichten senden und Nachrichten in Echtzeit verändern.
  • Ende-zu-Ende-verschlüsselte Kommunikation mit OMEMO, OTR und PGP war nur dann gegen das Abfangen geschützt, wenn beide Seiten die Verschlüsselungsschlüssel verifiziert hatten.
  • Nutzer sollten im PEP-Store prüfen, ob neue nicht autorisierte OMEMO-/PGP-Schlüssel vorhanden sind, und ihre Passwörter ändern.

Prävention und Monitoring für Betreiber

  • Neue Zertifikatsausstellungen werden in Certificate Transparency protokolliert; daher kann ein Certificate-Transparency-Monitoring eingerichtet werden.
  • Mit RFC 8657 zu CAA Record Extensions for Account URI and ACME Method Binding lässt sich einschränken, auf welche Weise Zertifikate ausgestellt werden dürfen und welche Kontokennungen dafür zulässig sind.
  • Änderungen an SSL/TLS-Zertifikaten sämtlicher Dienste können über externe Services überwacht werden.
  • Änderungen der MAC-Adresse des Default Gateways können überwacht werden.
  • Channel binding in XMPP kann MiTM erkennen, selbst wenn die abfangende Seite ein gültiges Zertifikat präsentiert.
    • Sowohl Client als auch Server müssen dafür den Authentifizierungsmechanismus SCRAM PLUS unterstützen.
    • Zum Zeitpunkt des Angriffs war dies auf jabber.ru nicht aktiviert.
  • Weitere Empfehlungen des ACME-Entwicklers Hugo Landau sind unter More recommendations from ACME developer Hugo Landau zusammengefasst.

Antworten von Hetzner und Linode

  • Mit Stand vom 20. Oktober 2023 lag keine ausreichende Antwort von Hetzner und Linode vor.
  • Auch im Update vom 3. November 2023 gaben beide Unternehmen keine angemessene Antwort auf den Vorfall.
  • Hetzner erklärte, für dedizierte Root-Server und Cloud-Server lediglich Hardware, Netzwerkzugang und die notwendige Infrastruktur bereitzustellen, und könne daher keine weitere Lösung anbieten.
  • Linode erklärte nach Erhalt der Logs, keine illegalen Aktivitäten mit Auswirkungen auf den Dienst beobachtet zu haben, und schloss das Ticket.
  • Die Betreiber halten es für am wahrscheinlichsten, dass Hetzner und Linode auf Anordnung der deutschen Polizei zu dieser Konfiguration für eine rechtmäßige Überwachung gezwungen wurden.
  • Als weitere Möglichkeit bleibt ein gezielter Einbruch in die internen Netzwerke von Hetzner und Linode speziell gegen jabber.ru bestehen, gilt jedoch als deutlich weniger glaubwürdig, wenn auch nicht völlig unmöglich.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-21
Meinungen auf Hacker News

  • Es sieht sehr stark danach aus, als könnte das mit Ermittlungen gegen russische Cyberkriminalität zusammenhängen. Wer Krebs liest oder schon einmal in den dunkleren russischen Foren unterwegs war, dem dürfte xmpp.ru bekannt vorkommen; tatsächlich gibt es diesen Kontext
    Ich will den Betreibern nichts anhängen, sondern meine nur: Wenn man einen anonymen Dienst betreibt, nimmt er eben diesen Charakter an
    https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
    https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
    https://blog.talosintelligence.com/picking-apart-remcos/
    https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
    Der Beitrag selbst ist wirklich interessant und wirkt wie ein praktisches Beispiel dafür, dass alle Dienste für Certificate Transparency Monitoring nutzen sollten

    • Drogenorganisationen nutzen XMPP zusammen mit Tor verbreitet als sicheren Kommunikationskanal. Der Darknet-Marktplatz Hydra wurde 2022 von der deutschen Polizei geschlossen, als er seine „Dienste“ in die EU ausweiten wollte; hier könnte etwas Ähnliches passiert sein oder auch nicht
    • So sehe ich es im Großen und Ganzen auch. Es scheint möglich, dass es mit der Abschaltung von Genesis Market oder Qakbot zusammenhängt

  • Den meisten vorgeschlagenen Gegenmaßnahmen stimme ich zu. Wenn man ein Hochrisikoziel ist, kann man zusätzlich eine Authentifizierungsschicht in Betracht ziehen, die nicht auf vertrauenswürdige Zertifizierungsstellen angewiesen ist: Tor onion services, SSH, WireGuard und Ähnliches
    Ich stimme zu, dass alle ausgestellten SSL/TLS-Zertifikate unter Certificate Transparency fallen, und crt.sh hat auch einen RSS-Feed
    CAA zu verwenden ist im Allgemeinen eine gute Idee, aber ich bezweifle, dass es in diesem Fall hilft. Denn der Angreifer müsste nur exakt die Zertifikatskonfiguration anfordern, die in CAA erlaubt ist; helfen könnte es vielleicht, wenn man bestimmte Validierungsmethoden strenger einschränken kann
    Ich stimme auch zu, dass man Änderungen an den SSL/TLS-Zertifikaten aller Dienste über einen externen Dienst überwachen sollte. Hochrisikoziele sollten jederzeit wissen, welche Zertifikate gültig sind, und das überprüfen
    Die Methode, Änderungen an der MAC-Adresse des Default-Gateways zu überwachen: Bei einem ausgefeilteren Angriff könnte die MAC-Adresse unverändert bleiben
    Mir war neu, dass „Channel Binding“ bei XMPP auch Man-in-the-Middle-Angriffe erkennen kann, bei denen ein gültiges Zertifikat präsentiert wird

    • Ich bin der Autor von ACME-CAA (RFC 8657). In CAA-Records kann man eine eindeutige Kennung des ACME-Kontos hinterlegen, sodass sich ein solcher Angriff abmildern lässt, solange der Angreifer nicht den privaten Schlüssel des ACME-Kontos erlangt oder den ACME-Dienst kompromittiert
      Natürlich setzt das voraus, dass die Nameserver durch DNSSEC geschützt sind. Andernfalls könnten beim Abruf durch die Zertifizierungsstelle auch DNS-Anfragen abgefangen werden
      Die vollständigen Sicherheitshinweise stehen in RFC 8657. Dieser RFC ist so gestaltet, dass er leichter zu lesen ist als übliche RFCs
      Mein Blogbeitrag mit Hintergrundinformationen: https://www.devever.net/~hl/acme-caa-live
    • Was passiert, wenn ein Staat einer Zertifizierungsstelle im eigenen Land befiehlt, Zertifikate ohne CT-Logs auszustellen, und dazu noch eine Schweigeanordnung erlässt? Wenn einem bei Nichtbefolgung Gefängnis droht, wird ein gewöhnlicher Systemadministrator wohl kaum ins Gefängnis gehen wollen, nur um einen russischen Jabber-Server zu schützen
    • Wenn man physischen Zugriff auf den Server hat, würde man einfach dort ansetzen. Mit ein wenig Aufwand kann man bei gewöhnlicher Hardware Disk, Netzwerk und RAM spiegeln

  • Wenn man einen echten Man-in-the-Middle-Angriff perfekt durchzieht und dann vergisst, das Zertifikat zu erneuern, ist das schon ziemlich deutsch :-)

    • Vielleicht hat jemand absichtlich „vergessen“. Es könnte gewesen sein, um die Leute darauf aufmerksam zu machen
      Oder jemand hat einen Befehl einfach sehr gewissenhaft befolgt. Es gab die Anweisung, ein Zertifikat einzurichten, aber keine Anforderung, es automatisch zu erneuern :)
    • Let’s Encrypt verschickt doch ständig Erinnerungsmails; wie kann das passieren?

  • Archiv: https://archive.ph/C0jYJ
    Die Theorien sind interessant und erklären, falls sie stimmen, wie das Zertifikat erlangt wurde. Die Lehre daraus könnte sein, bei mehreren Providern mehrere Probes zu betreiben, alle TLS-Fingerprints zu prüfen und sich benachrichtigen zu lassen, wenn ein unbekannter Fingerprint auftaucht — inklusive Prüfung, ob er in den Certificate-Transparency-Logs vorhanden ist
    openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin
    SHA1 Fingerprint=7E:49:BA:40:86:87:B3:39:66:93:94:9E:9C:45:71:85:3C:8D:95:16

    • Ich habe den Abschnitt „Kann man solche Angriffe verhindern oder überwachen?“ hinzugefügt. Es gibt mehrere Signale, mit denen man den Angriff vom ersten Tag an erkennen kann
      Da alle ausgestellten SSL/TLS-Zertifikate Certificate Transparency unterliegen, ist es sinnvoll, Certificate Transparency Monitoring wie Cert Spotter einzurichten, um per E-Mail benachrichtigt zu werden, wenn für die Domain ein neues Zertifikat ausgestellt wird
      Mit den Erweiterungen für CAA-Records aus RFC 8657, also Account URI und ACME Method Binding, kann man die Validierungsmethode einschränken und die genaue Konto-Kennung festlegen, die neue Zertifikate ausstellen darf; dadurch lässt sich verhindern, dass Domain-Zertifikate über andere Zertifizierungsstellen, ACME-Konten oder Validierungsmethoden ausgestellt werden
      Außerdem sollte man Änderungen an den SSL/TLS-Zertifikaten aller Dienste über einen externen Dienst überwachen und auch Änderungen an der MAC-Adresse des Default-Gateways beobachten

  • Ich fand es etwas merkwürdig, dass die MAC-Adresse keine lokal verwaltete Adresse war. Es sah so aus, als könnte jemand diesen Adressbereich absichtlich ausgewählt haben
    https://www.google.com/search?q=%2290%253Ade%253A01%22+linod...
    Wenn man nach "90:de:01" linode und "90:de:00" linode sucht, sieht es so aus, als seien Adressen aus diesem Block in letzter Zeit auch anderen Linode-VMs zugewiesen worden. Ich habe gerade keine Linode-VM zum direkten Vergleich, aber es wirkt so, als sei der Traffic zu einer anderen VM in der Linode-Infrastruktur geroutet worden

  • Unbelegte Spekulation, aber ich vermute, dass Jabber ins Visier geraten ist, weil es auf Darknet-Marktplätzen bekanntermaßen für Drogenhandel oder andere illegale Aktivitäten genutzt wird
    Das zeigt, dass man sich nicht einfach auf „ist ja verschlüsselt, also ist es okay“ verlassen sollte. Zumindest sollten Nachrichten mit PGP verschlüsselt werden
    Ich frage mich, ob PGP durch Quantencomputer gebrochen werden kann und ob es künftig Härtungen gegen solche Angriffe geben wird. Wenn Nachrichten massenhaft in verschlüsselter Form gesammelt wurden, könnte die Entschlüsselung am Ende nur eine Frage der Zeit sein
    Und so etwas scheint mit fast jedem Web-Traffic zu passieren, an den man herankommen kann. Siehe https://en.wikipedia.org/wiki/Utah_Data_Center

    • Jabber/XMPP hat seit mindestens 10 bis 15 Jahren Ende-zu-Ende-Verschlüsselung. Als Facebook/Google Talk noch XMPP unterstützten, nutzte man das mit pidgin, kopete usw. sogar mit normalen Freunden so
      Natürlich ist es fehleranfällig, im Internet mit anonymen Drogenverkäufern sicher Schlüssel auszutauschen
    • Dieser Man-in-the-Middle-Angriff könnte Teil der Abschaltung von Genesis Market gewesen sein, aber das ist einfach eine aus der Luft gegriffene Vermutung
      https://therecord.media/genesis-market-takedown-cybercrime
    • Eine zweite Verschlüsselungsschicht würde helfen, aber PGP selbst würde ich nicht besonders empfehlen
      PGP hat viele Probleme, und viele raten dazu, es zu meiden. Z. B.: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ / https://news.ycombinator.com/item?id=20455780

  • Ende-zu-Ende-verschlüsselte Kommunikation wie OMEMO, OTR oder PGP schützt nur dann vor Abfangen, wenn beide Seiten die Verschlüsselungsschlüssel verifiziert haben. Ein Angreifer müsste für jede verwendete Ende-zu-Ende-Verschlüsselungsmethode einen eigenen Man-in-the-Middle-Angriff aufsetzen
    Einige XMPP-Clients, die ich gesehen habe, ließen die Nutzung nicht zu, wenn nicht angezeigt wurde, dass eine bestimmte Verschlüsselungsidentität explizit verifiziert wurde
    Trotzdem eine gute Erinnerung: Wenn man nie eine absurd lange Zahl oder etwas Vergleichbares gesehen und verarbeitet hat, ist schwer davon auszugehen, dass Ende-zu-Ende-Verschlüsselung tatsächlich zustande gekommen ist

  • Eine Sache verstehe ich an dieser Geschichte nicht. Wenn es legale Überwachung war, warum hätten Hetzner und Linode dann mit separaten LE-Zertifikaten und Schlüsseln eine Man-in-the-Middle-Überwachung eingerichtet?
    Man hätte doch den privaten TLS-Schlüssel direkt aus dem RAM oder dem Storage des VPS extrahieren können. Selbst bei einem physischen Dedicated Server könnte man nach einem unangekündigten Reboot einen RAM-Dump ziehen und den privaten Schlüssel extrahieren
    Das Extrahieren des privaten Schlüssels taucht nicht in CT-Logs auf, wäre also viel heimlicher und praktisch kaum zu erkennen

    • Vermutlich, weil es einfacher war
      Eine weitere Möglichkeit ist, dass das eine als „Durchsuchung“ und das andere als „Überwachung“ gilt und daher unterschiedliche Genehmigungsstufen nötig waren. Ich kenne die aktuelle deutsche Rechtslage allerdings nicht gut
    • Vermutlich, weil das „illegaler“ wäre. Wenn der Server nicht direkt in Cybercrime-Aktivitäten verwickelt ist, dürfte es wohl nicht erlaubt sein, den Server zu hacken
    • Bei einem physischen Server könnte man doch eine PCIe-Karte hotpluggen und per DMA die gewünschten Daten herausziehen, oder? So etwas müsste mit einer Netzwerkkarte mit speziell angepasster Firmware möglich sein
      Das klingt für Strafverfolgungsbehörden nach einem so standardmäßigen Vorgehen, dass es solche Geräte wahrscheinlich von der Stange gibt

  • Ein Nutzer hatte das schon vor 3 Tagen auf Reddit gepostet: https://www.reddit.com/r/hetzner/comments/17ankoh/does_hetzn...

  • Ich frage mich, ob es eine rechtliche Möglichkeit gibt, Hetzner/Linode zu einem Kommentar zu dieser Situation zu verpflichten. Hinter der Überwachung steckt wahrscheinlich irgendeine Regierungsbehörde oder Polizei

    • Da Hetzner ein deutsches Unternehmen ist, kann man bei legaler Überwachung keine Auskunft verlangen. Ohne zuerst über einen Anwalt zu gehen, dürfte das schwierig sein
      Umgekehrt glaube ich nicht, dass Hetzner es zugelassen hätte, wenn es keine legale Überwachung war. Denn auch das wäre ein Gesetzesverstoß
    • Es ist auch nicht garantiert, dass die Überwachung über Hetzner oder Linode lief. Sie könnte zum Beispiel beim Telekommunikationsanbieter erfolgt sein, und in fast jedem Land werden Telekommunikationsanbieter seit Jahrzehnten zur Mitwirkung an legaler Überwachung verpflichtet