[Tarnkappe] MyEtherWallet: 115.000 € gestohlen durch Phishing-Angriff

Trolling Stone · 25 Apr. 2018

Tarnkappe.info schrieb:
Um sich vor Angriffen dieser Art zu schützen, wird empfohlen, immer sicherzustellen, dass das SSL-Zertifikat grün ist. Ist das Zertifikat rot und durchgestrichen, handelt es sich um eine kompromittierte Website. Zudem sollte man MyEtherWallet lokal auf dem Computer installieren und von dort ausführen.

Auch die Verwendung einer Hardware-Wallet hätte davor geschützt, da der Private Key nicht preisgegeben wird.

Dr. Julian Hosp hat ein Video dazu gemacht:

Abul · 25 Apr. 2018

Bei Grün darfst du gehen, bei Rot bleibst du stehen.

Novgorod · 26 Apr. 2018

interessant wären mehr infos, wie ausgerechnet der google DNS-server (8.8.8.8?) anfällig für so eine attacke sein konnte :confused:

.. es kann doch nicht sein, dass ein provider (von zigtausenden?) auf einmal beschließt, z.b. den DNS-eintrag für google.com zu ändern und es dann einfach so von google selbst übernommen wird? :eek:

wäre das mit cloudflare (1.1.1.1) nicht passiert?

Metal_Warrior · 26 Apr. 2018

@Novgorod: Der wurde gar nicht angegriffen - eigentlich ist die Meldung diesbezüglich irreführend. Das zu erkennen muss man aber DNS grundsätzlich verstehen:

Hast du eine Domain, wählst du einen DNS-Server, der für diese Domain und alle Subdomains autoritativ ist. Das könnte der Google-DNS sein (und wird es für Google-Dienste auch sein), aber in der Regel ist er es nicht. Ich hab für zwei Netzwerke hier eigene autoritative DNS-Server für die Subdomains, geb das nur nicht nach außen/upstream weiter. Auch das NGB ist bei einem DNS-Provider, bei dem die Einträge www.ngb.to, ngb.to, ... verwaltet werden. Nun haben wir aber ein Problem: Der DNS-Server, den unsere User nutzen (Google, CCC, Provider, FoeBuD...) ist sicher nicht der, den wir für die Verwaltung verwenden. Lösung: Die DNS-Server reden miteinander. Und zwar nicht chaotisch, sondern geregelt:

Nehmen wir die Anfrage "server.struktur.beispiel.de" und schicken sie an 8.8.8.8. Der Google-Server wird das anfangen zu zerlegen:

server.struktur.beispiel.de -> kenn ich nicht
struktur.beispiel.de -> kenn ich nicht
beispiel.de -> kenn ich nicht
de -> kenn ich, dafür ist die DENIC zuständig -> Weiterleitung der Anfrage an die DENIC-Rootserver

Der DENIC-Server guckt dann nach, wer für beispiel.de autoritativ ist - nehmen wir an, das wäre der Server selbst noch.
Danach wird geschaut, wer für struktur.beispiel.de autoritativ ist - nehmen wir an, das wäre der Server "beispiel.de" selbst -> Weiterleitung der Anfrage an eben den.

beispiel.de schaut dann nach, wer für server.struktur.beispiel.de autoritativ ist - nehmen wir an, das wäre (weil Amazon Cloud) der Server dns.amazon.de (dann wird erst der Name wieder aufgelöst, analog zu oben), und dann der eigentliche server.struktur.beispiel.de aufgelöst. Die Antwort bekommt dann beispiel.de, der sie cached (falls in zwei Minuten der nächste den Server haben will) und an DENIC weiterleitet, der wieder (kurz) cached (könnte ja in den nächsten 10 Sekunden...) und an Google weiterschickt. Der cached wieder, und antwortet dir.

Jetzt hast du eine IP von einem Server bekommen, den Google gar nicht verwaltet. Das ganze System baut einzig und allein darauf auf, dass alle Server vertrauenswürdig sind und die richtigen Daten suchen und weiterleiten. Das war offenbar nicht der Fall. Irgendein Schlingel hat also bei einem DNS-Server in der Kette die Anfrage falsch weitergeleitet (an einen kompromittierten DNS-Server) und damit ne falsche IP zum Domainnamen rausgegeben. Da kann Google nix dafür. Dass sowas geht, ist aber schon länger bekannt und der Grund, warum langsam DNSSEC eingeführt wird (also signierte DNS-Daten). Das ist aber noch recht am Anfang, und es wird wohl ähnlich lang dauern wie der flächendeckende Umstieg auf HTTPS.

Novgorod · 26 Apr. 2018

mir ist schon klar, dass nicht "google gehackt" wurde und dass DNS eine baumstruktur hat.. mir ist nur nicht klar, wie ein (offenbar?) legitimer DNS-server in der kette attackiert werden konnte - wäre das nicht ähnlich aufwendig wie die zielseite (hier myetherwallet.com) selbst zu "hacken"? und warum hat es sich nur (?) auf den google DNS-server ausgewirkt? sollten nicht alle möglichen "end-user"-DNS-server (von providern etc.) am ende (ggf. über umwege) mit dem kompromittierten autoritativen DNS-server von myetherwallet.com kommunizieren und dann die falsche IP geliefert bekommen?

darksider3 · 26 Apr. 2018

@Novgorod: Es wurde weder ein DNS noch Google/Amazon gehackt, sondern das BGP-Protokoll gehijackt: https://en.wikipedia.org/wiki/BGP_hijacking. Man nennt es auch IP Hijacking: Wenn Du einen ISP hast der Rotz ist(wie die Angreifer anscheinend), kannst Du den überreden das dessen Backbones Dir IP-Ranges(-routen) zuteilt die eigentlich jemand anderem gehören, was dazu führt, das die schnellere Antwort/Meldung der zugeteilten Routes als gesetzt genommen werden(wenn also der legitime Eintrag schneller gewesen wäre, wäre das nicht passiert). Das führt dann zu dem, was wir jetzt gerade durchexerziert gesehen haben. (siehe zum Vertrauensteil hier bei Metal_Warriors antwort)

Und wenn Du Zugriff auf die IP-Adressen hast, hast Du auch Zugriff auf alles andere. Du kannst DNS-Manipulieren(weil die meisten Provider dies nur durch Kontroll(txt)-Einträge oder Dateien kontrollieren), und dadurch kannst Du Traffic Routen. Interessanterweise waren in diesem Angriff keine neuen Certs im Spiel, was dazu führte, das User sich durch invalid-Cert-Warnungen klicken mussten... und das haben die anscheinend bereitwillig getan. Es ist heute einfacher als jemals zuvor sich ein valides Cert zu besorgen, sodass ein User das gar nicht hätte bemerken können(Let's encrypt, anyone?)

Warum nur Google? Das ist relativ einfach. Wenn ein DNS-Server sich Einträge holt, cached der die normalerweise für eine gewisse, Zeit+Zeit, die durch TOL angegeben werden(Time of Life), und Google macht das ein wenig "agressiver". Es waren übrigens auch kleinere DNS-Server betroffen, deshalb stehen in vielen anderen news dazu auch der Zusatz: "betroffen waren vorrangig user des 8.8.8.8"

EDIT2: Mir fällt gerade auf, das ich nur Metal_warriors Antwort kurzgefasst habe. Sorry. :beer:

Novgorod · 26 Apr. 2018

danke für die erklärung - das passiert also auf provider-ebene und diese BGP-advertisements werden offenbwar nicht überprüft? wer entscheidet eigentlich, wer überhaupt BGP-advertisements machen darf und auf welche die eigenen router hören? und wieso ist dann noch niemand auf die idee gekommen, die routen zu google und facebook zu übernehmen?

zum thema certs: würde der browser nicht meckern, dass sich zumindest die CA für die domain geändert hat oder so?

darksider3 · 26 Apr. 2018

@Novgorod: BGP-advertisements werden eigentlich von den Providern überprüft, und nur die "durchgelassen", die auch legitim sind. Leider, und das meinte ich mit "Rotz-Providern", gibt es durchaus Fälle, wo das nicht überprüft wurde.

Das gesamte AS(https://en.wikipedia.org/wiki/Autonomous_system_(Internet)) verläuft auf Vertrauensebene(und damit auch BGP), wie Metal_Warrior bereits anmerkte. Wenn allerdings einer besagter Backbones einfach eine Änderung propagiert, dem getraut wird, dann nehmen das auch alle an. Das funktioniert eigentlich relativ gut, weil BGPs normalerweise durch ISPs und Providern im allgemeinen gefiltert werden(sprich: Überprüft ob legitim). Das scheint hier nicht passiert zu sein.
Es gibt ansätze das Sicher(=mit Krypto abzusichern, Public&Private-keys) zu machen, allerdings ist das bisher noch nicht weitläufig implementiert, und deshalb ... das.
---
Exkurs EDIT3:

advertisements werden offenbwar nicht überprüft? wer entscheidet eigentlich, wer überhaupt BGP-advertisements machen darf und auf welche die eigenen router hören

Entscheiden tut das die IANA, die das an die RIRs(lokalen Authoritäten) weitergibt, die die dann für die jeweiligen Gebiete(Kontinente, glaube ich?) weitergeben. So ist an einer zentralen Stelle geregelt, wer welche IP-Ranges hat und wer verantwortlich zu machen ist, falls etwas ausfällt(in der Infrastruktur). Europa ist die RIPE NCC. Ich meine Amazon hatte dazu sogar schon ein Statement rausgehauen, das einen Provider gerade die Schuld gibt - spricht also dafür, das ein Server im Backbone kompromittiert wurde, bzw. einer der EdgeRouter.

BGP ist im Prinzip das, was dafür sorgt, das dein ISP dafür sorgen kann, dass Du am Ende den kürzesten Weg über verschiedene Netzwerke gehen kannst, um deine Daten(Website? Packets jedenfalls) zu kriegen. Dadurch das aber der Backbone/Edgerouter(ich bin mir da in der Therminologie gerade nicht sicher, sorry) falsche Routen setzt, kann es schnell passieren, das er(wenn die Routen effizienter zu sein scheinen als die vom original), sich alle, die mit besagtem kompromittiertem System kommunizieren um die Routen zu kriegen, sich die falsche Route einfangen. Das nennt sich dann RIB(Routing information base)-poisoning(Da die Daten ausgetauscht werden, steckt der eine EdgeRouter/Backbone den anderen mit dem falschen Eintrag/der falschen Route an).
----

Die andere möglichkeit ist, das ein Server im Backbone kompromittiert wurde. Aber auch hier bedeutet das wieder, das weder Amazon noch Google "gehackt" wurden, sondern nur ein Server eines Providers, der legitime Änderungen am Routing propagieren darf.

zum thema certs: würde der browser nicht meckern, dass sich zumindest die CA für die domain geändert hat oder so?

Nein. Es gibt keine Regel dafür, das die Website ihre Certs nicht ändern dürfte oder es ankündigen müsste(es sei denn, natürlich, man redet über HSTS, aber das ist wieder ein anderes Thema, dann müsste man es vorher bei DNS und Server "einspeichern"): Jede Website kann nach belieben ihre Certs dann ändern, wenn sie es wollen. Und wenn die ausstellende Authorität(Lets encrypt in meinem Beispiel) "vertraut" wird durch die Browserhersteller/Systeme, meckert da normalerweise auch nichts.
Und das ist auch gut so in vielen Fällen... stell Dir vor dein Browser würde alle 6 Monaten rumheulen weil Amazon ihr cert erneuert hat(wie gesagt, mit HSTS funktioniert das dann nochmal ein wenig anders weil man dann Serverzugriff braucht, aber im allgemeinen darf jeder ändern wie er will)

und wieso ist dann noch niemand auf die idee gekommen, die routen zu google und facebook zu übernehmen?

Weil es nicht so einfach ist, wie man gerne tut. Es gab in den letzten 20 Jahren gefühlt 15 erfolgreiche Angriffe, und jeder einzelne kann man auf bestimmte Provider/Anbieter zurückführen(siehe IANA abschnitt oben). Es ist erst DANN einfach, wenn man schon soweit ist, das man eh jede Änderung propagieren kann.
---

Der Artikel an sich ist gut, nur der allererste Satz:" Über eine Google-DNS-Serverweiterleitung".... wirklich? Das ist A) Redundant(DNS=Weiterleitung) und B) würde bedeuten, das jemand Zugriff auf einen Server von Google gehabt hätte.

Ich hoffe das war halbwegs verständlich, hab ein wenig von vorne nach hinten durcheditiert

EDIT 5:// Es ist ein schwieriges Thema, zu dem man viel sagen kann, sorry ;_;

[Tarnkappe] MyEtherWallet: 115.000 € gestohlen durch Phishing-Angriff

Trolling Stone

Troll Landa

Abul

(Threadleser)

Novgorod

ngb-Nutte

Metal_Warrior

Defender of Freedom

Novgorod

ngb-Nutte

darksider3

NGBler

Novgorod

ngb-Nutte

darksider3

NGBler