Dienst achter cryptowallet wijt omleiding naar phishingsite aan dns-hijack

De dienst MyEtherWallet zegt dat een deel van zijn bezoekers dinsdag is omgeleid naar een phishingsite doordat aanvallers een aantal dns-servers hadden gekaapt. Daardoor kwamen sommige gebruikers op de kwaadaardige site terecht en verloren ze ether.

In zijn verklaring rept MyEtherWallet niet van slachtoffers maar schrijft het dat 'getroffen gebruikers mogelijk een ssl-waarschuwing op de kwaadaardige versie van zijn site hebben genegeerd'. Daarmee doelt het erop dat de phishingsite niet voorzien was van een geldig certificaat. Doordat bezoekers alsnog inlogden, was een de aanvaller in staat om ether te stelen, die deze zou hebben verzameld in een eigen wallet. Daaraan is recentelijk 215 ether onttrokken, wat neerkomt op omgerekend ongeveer 115.000 euro.

Volgens beveiligingsonderzoeker Kevin Beaumont gebruikte de onbekende aanvaller bgp om verkeer bestemd voor Amazons Route 53-dns-dienst om te leiden via een server bij Equinix in Chicago. Daardoor zouden gebruikers van MyEtherWallet, dat volgens Beaumont tot nu toe het enige bekende slachtoffer is, omgeleid zijn naar de phishingsite die zich in Rusland bevindt. Volgens Oracles Internet Intelligence duurde de omleiding ongeveer twee uur.

Amazon zegt in een verklaring aan Ars Technica dat 'noch AWS noch Route 53 zijn overgenomen of gehacked'. Het vervolgt: "Een upstream isp was overgenomen door een aanvaller die vervolgens de provider inzette om een deel van de Route 53-ip-adressen aan andere netwerken te announcen waarmee deze isp was gepeered." Daardoor zou een klein deel van het verkeer voor een klant zijn omgeleid naar de kwaadaardige versie van diens site. Op zijn statuspagina toont Amazon meer informatie over het incident bij Route 53.

Equinix reageerde eveneens tegenover Ars Technica en stelt dat het niet om een eigen server ging maar om die van een klant in zijn datacentrum in Chicago. Volgens Beaumont is het onwaarschijnlijk dat MyEtherWallet het enige doelwit van de aanval was. De aanval, die volgens de onderzoeker de grootste is die bgp en dns combineerde, zou bovendien 'de kwetsbaarheid van het internet benadrukken'.

Reacties (40)

[woutertje]

Vanuit mijn werk heb ik toevallig iets meer zicht op wat ze met de Authoritative DNS gedaan hebben.

Gedurende de periode dat de IP prefixes gehijacked waren werden er uitsluitend nog DNS queries beantwoord voor de domeinen waar de aanvallers in geinteresseerd waren. Alle andere DNS queries bleven onbeantwoord (dat zijn er in dit geval heel veel, omdat Route53 erg groot is). De domeinen die ik zag waren myetherwallet.com en www.myetherwallet.com. De aanval lijkt dus, in tegenstelling tot wat Kevin Beaumont beweert, heel doelgericht geweest te zijn.

Je zag ook dat Google's 8.8.8.8 soms niet meer in staat was om het A-record van, bijvoorbeeld, instagram.com te resolven. Instagram is ook gebruiker van Route53.

[Reactie gewijzigd door woutertje op 23 juli 2024 02:19]

[Cerberus_tm]

Weet je toevallig hoe laat dat was? En of Steam ook van deze Amazon-dienst gebruikmaakt? Ik kon vannacht gedurende enige tijd geen losse reviews lezen op Steam, terwijl de gewone winkelpagina's het wel deden, inclusief de reviews op die pagina's, en de andere discussiepagina's het ook gewoon deden.

[woutertje]

De hijack vond (ongeveer) plaats tussen 13:05:00 en 14:55:00 (GMT+2). Voor zover ik weet of kan zien maakt Steam ook geen gebruik van Route53. Waarschijnlijk was dat dus een ander probleem.

[Cerberus_tm]

OK toeval dan inderdaad. Het viel me op omdat ik nog nooit zoiets had meegemaakt bij Steam. Gelukkig minder erg dan een hack van een cryptowallet!

[djiwie]

Klopt, wij zagen gistermiddag ook diverse issues bij het resolven van domains die door AWS gehost werden. AWS domains die onze services wilden resolven werden inderdaad niet beantwoord (of vrijwel niet) omdat 3 van de 4 servers geen antwoord gaven.

[Mrten]

Het is aangeraden om MyEtherWallet lokaal te gebruiken, zodat je niet afhankelijk bent van derde partijen. Hiervoor zijn instructies te vinden op hun knowledge base.

[tomvleeuwen]

Als het waar is dat de gebruikers de SSL waarschuwing genegeerd hebben, vind ik dat eigenlijk wel een beetje hun eigen schuld. Maar misschien gebruikte ze een oude browser die de onveilige SSL protocollen nog accepteert (ook niet handig met cryptocurrency)

[Devaqto]

Dan heb je nog geluk dat de aanvallers geen LetsEncrypt certificaat hadden aangevraagd op hun eigen server, dan had je het niet zo snel kunnen zien.

Een simpele HSTS-header had ook kunnen helpen (geen oplossing): https://www.owasp.org/ind...port_Security_Cheat_Sheet
"HSTS does not allow a user to override the invalid certificate message."

Uiteraad ook DNSSEC, het lijkt alsof het bedrijf weinig maatregelen heeft genomen om de beveiliging van informatie te waarborgen...

[Reactie gewijzigd door Devaqto op 23 juli 2024 02:19]

[cakemasher]

Dan zouden de Letsencrypt servers ook gespoofed moeten worden in de zin dat ook zij naar de malafide website gestuurd zouden worden. Alleen dan zou er een 'geldig' certificaat aangevraagd kunnen worden.

Wat een simpele oplossing zou kunnen zijn is DNSSEC, wat zich eigenlijks focust op het voorkomen van zoon DNS man-in-the-middle attack. Hier wordt een publieke sleutel op de servers van het root domeinnaam (bijv. voor .nl, bij SIDN) opgeslagen, en worden de records ondertekend op de DNS- / Nameserver zelf d.m.v. een private key. Hier zou vervolgens door de client een check op uitgevoerd moeten worden.

Simpele DNSSEC uitleg hier en hier.

Deze check laat zien dat DNSSEC niet geactiveerd is op myetherwallet.com.

[Reactie gewijzigd door cakemasher op 23 juli 2024 02:19]

[Verwijderd]

Spijtig genoeg ondersteunt Route53 nog steeds geen DNSSEC:

"Amazon Route 53 supports DNSSEC for domain registration. However, Route 53 does not support DNSSEC for DNS service, regardless of whether the domain is registered with Route 53. If you want to configure DNSSEC for a domain that is registered with Route 53, you must use another DNS service provider."
https://docs.aws.amazon.c...ain-configure-dnssec.html

[CAPSLOCK2000]

Als je wil weten of jouw DNS-resolver al geschikt is voor DNSSEC dan kun je deze zelftest doen.


Als je ooit vermoed dat er een DNSSEC-probleem is dan is de website DNSviz goud waard om het probleem te debuggen. Door gewoon naar het grote rode kruis te kijken kun je meestal in één oogopslag zien waar het fout gaat.

Voor een algemeen overzicht van status van de belangrijkste moderne beveilingsfeatures kan ik Hardenize aanbevelen.

[Verwi159]

Vanuit ons bedrijf kan ik zien dat ze na de aanval gisteren, de website beter beveiligd hebben, maar DNSSEC staat nog niet enabled. (zie nu ook de reden van sithlord2) HSTS staat wel dicht op het hoofd domein. Verder is er kans om het domain te hijacken. Zaken als transfer/deletion protection staan niet aan.

[Reactie gewijzigd door Verwi159 op 23 juli 2024 02:19]

[Verwijderd]

Die vermeld geen bedrijfsnaam, premium certificaat dus wel.

[Devaqto]

Dan nog, krijgen bezoekers geen melding over een ongeldig certificaat. En ik denk dat het tegenvalt hoeveel mensen letten op een EV-certificaat.

[Yggdrasil]

De waarde van EV certificaten is minimaal, o.a. omdat mensen in dit geval dan bijv. hadden moeten reageren op het ontbreken van de specifieke eigenschappen van EV. Als je nu ziet dat mensen al doorklikken bij een ongeldig certificaat terwijl dat moeite kost, dan is het effect van EV werkelijk verwaarloosbaar.

Duidelijkere uitleg van dit probleem in: https://scotthelme.co.uk/...-paper-theyre-written-on/

[Reactie gewijzigd door Yggdrasil op 23 juli 2024 02:19]

[.oisyn]

Dan heb je nog geluk dat de aanvallers geen LetsEncrypt certificaat hadden aangevraagd op hun eigen server

Dat had alleen gekund als het verkeer van LetsEncrypt's validator ook was omgeleid.

[Tozz]

Nouja, het "omleiden" van verkeer is precies wat er gebeurt is. Dus waarom zou de LE validator niet ook gewoon naar de neplocatie kunnen valideren?

[.oisyn]

Als ik het artikel en Amazon's statusupdate lees was het probleem dus niet voor iedereen merkbaar.

[djwice]

AWS heeft geen dnssec, je moet dit via een andere provider regelen.
Op AWS kun je HSTS op AWS CloudFront is alleen aan te zetten via Lambda@Edge en ondanks dat dit vrij makkelijk te doen is en niet veel kost (paar cent per maand), merk ik dat dit nog niet veel wordt gebruikt.
Ik zie nog minder vaak dat mensen de preload functie van HSTS configureren.

DNS CAA is ook op Route53 in te stellen wordt nog minder vaak gedaan dan HSTS, maar omdat hier de DNS overgenomen was, vraag ik me af of dat effect zou hebben gehad.

[Reactie gewijzigd door djwice op 23 juli 2024 02:19]

[matthewk]

Ik heb inderdaad een melding gekregen dat het certificaat niet geldig was, en toen ben ik ook niet verder gegaan. Jammer dat je aan een myetherwallet geen dynamische 2-factor auth kan hangen zoals de pinpas authenticator...

Maar goed, hiervoor bestaan de fysieke wallets ook...

[Reactie gewijzigd door matthewk op 23 juli 2024 02:19]

[Tozz]

Wat zou dat oplossen dan? De "nepsite" kan gewoon elke 2-factor code accepteren.

2FA is een methode om de client te authenticeren, niet de server.

[Aikon]

Ik weet de details van deze 'hack' niet maar als het doel is om inloggegevens te stelen, dan is dat wellicht minder effectief met 2FA? Dan zal er iig direct (binnen de vervalperiode v/d code) op de andere site moeten worden ingelogd, dat kan op zich wel. Maar als er vervolgens bij een transactie weer om 2FA wordt gevraagd komt de 'hacker' niet verder.

[djiwie]

Deze dienst implementeert een client-side wallet en heeft sowieso geen inloggegevens, maar mensen slaan hun keys zelf op. Dus het is zelfs nog erger, als mensen die gegevens hebben weggegeven is effectief hun hele portemonnee leeggeroofd.

[psycho202]

De nepsite kan die 2FA accepteren, maar kan er verder niets mee.
Deze hack was zo successvol doordat zoveel man ingelogd heeft op de fake site, waardoor ze mooi een pak logins hebben kunnen verzamelen om te kunnen bestelen.
Moest er 2FA aanwezig zijn op MyEtherWallet zou dit nu eenmaal wat moeilijker geworden zijn voor de hackers om verder iets met de logins te kunnen doen, tenzij ze zware automatisatie gebruiken die tegelijk met de login poging op de phishing site inlogde op de echte site.

[Dark_man]

Daarom moet je ook altijd eerst een foutieve 2FA code invoeren.

Dan weet je of je op een phishing site zit of niet.

[Wim-Bart]

Wat zou dat oplossen dan? De "nepsite" kan gewoon elke 2-factor code accepteren.

2FA is een methode om de client te authenticeren, niet de server.

Niet helemaal, wanneer je omgeleid wordt naar een Phising Site en je verwacht een 2FA en je krijgt die niet dan krijg je argwaan, aan de andere kant, wanneer je een 2FA krijgt en je verwacht hem niet dan is dat ook verdacht.

Daarnaast is het ook nog afhankelijk van de wijze van 2FA, is het Authenticator App of is het SMS.

Bij bepaalde site vul ik namelijk bij Authenticator App bewust 1 of 2 keer verkeerde code in als hij dan door zou gaan is dat ook verdacht.

[hcQd]

Geen DNSSEC gebruiken, dan vraag je er ook om.

[Onno]

Dienst achter cryptowallet wijdt omleiding naar phishingsite aan dns-hijack

Nu die omleiding ingezegend is werkt ie vast een stuk beter.

[MrFax]

Ik moest de titel een paar keer lezen voordat ik deze snapte. Er staat naar ipv aan.

[w0nnapl4y]

Het geld leidt overigens naar een ander adres, dat zich inmiddels al in tientallen phishing aanvallen heeft gewurmd. Dit adres is de afgelopen 70 dagen al meerdere keren het eindpunt geweest van 1 van deze aanvallen. Dit adres heeft momenteel rond de 16,000,000$ aan waarde.
https://etherscan.io/addr...f3595c5032ee94b620a583a39

Aangezien tijdens de DNS-aanval er meerdere adressen zijn gemeld, is de omvang niet exact bekend, maar in ieder geval een stuk groter dan enkel van het 0x1D5 adres, ook al was dat in dit geval wel de grootste.

Veel ether is al tijdens en na de aanval direct of indirect naar verschillende exchanges gestuurd in kleine happen (o.a. Binance, Yobit, Kucoin), waardoor het bedrag van 215 Ether op het 0x1D5 adres ook niet klopt, maar een stuk groter uitvalt.

[ViTO_xp]

Het is 'wijten aan'

Dus: Dienst achter cryptowallet wijt omleiding naar phishingsite aan dns-hijack

[19RAW68]

bij Equinix in Chicaco (?)

[McOrmick]

Yup; https://www.sec.gov/Archi...19312511118503/dex211.htm

[cracking cloud]

yes; https://www.equinix.com/l...ion/chicago-data-centers/

[19RAW68]

Inderdaad, Chicago en niet Chicaco. Typo is al aangepast in het artikel.

[daikoko]

Het inloggen met eigen private key kunnen ze jouw wallet leeg roven... Wat gebeurt het dan met mensen die gebruik maakt van Metamask? Je zal toch eerst een bevestiging moeten doen via metamask?

[w0nnapl4y]

Bij het invullen van pivkey of .JSON file + password is het meteen over. Jouw assumptie is verder correct.

Bij gebruik van MetaMask zul je bijvoorbeeld als je enkel 'inlogt' op de phishing site al een transactie maken. Deze transactie zul je dus via MetaMask moeten goedkeuren wil je je geld kwijt raken. Daardoor is het belangrijk om altijd goed te controleren wat je MetaMask (of Hardware wallet) aangeeft bij je handeling.

Helaas gebruiken veel mensen geen Metamask, Hardware wallet of letten ze gewoonweg niet goed op (bijvoorbeeld of het SSL-certificaat wel daadwerkelijk van MEW is).
Ook kijken helaas veel te veel mensen naar hun balans via MEW, terwijl het bekijken van je balans veel veiliger is op bijvoorbeeld Etherscan