06.08.2018 | 19:18

Adam Haertle

Ruch operatorów płatności skradziony na serwery w okupowanej Ukrainie

Ataki polegające na przejęciu cudzego ruchu sieciowego należą naszym zdaniem do najciekawszych incydentów. Na liście zarówno sprawców, jak i ofiar, mieliśmy już polskie podmioty – tym razem ofiarami zostali globalni operatorzy płatności.

Ataki wstrzyknięcia błędnych tras BGP do protokołów routingu znane są od wielu lat. Czasem są błędem operatora, często jednak złośliwym działaniem, mającym na celu przejęcie cudzego ruchu internetowego. Jeśli chcecie zrozumieć, jak działają i na czym polegają, to polecamy Wam nasz artykuł na ten temat z roku 2013. Opisywaliśmy już wiele podobnych incydentów. Mieliśmy np. rosyjskiego operatora, który przejął ruch wielu banków, w tym polskiego BZ WBK, ukraińskiego operatora przejmującego ruch firm zbrojeniowych, indonezyjskiego operatora, który przejął ruch połowy internetu (a przynajmniej próbował), polskiego operatora INEA przejmującego ruch amerykańskiego Departamentu Obrony czy analogiczne ataki na kryptowaluty.

Najnowszy incydent, którego historią chcieliśmy się z Wami podzielić, to seria ciekawych ataków na operatorów płatności kartowych.

Cel – firmy przetwarzające płatności kartowe

W pierwszej połowie lipca doszło do kilku incydentów wstrzyknięcia złośliwych tras BGP. Incydenty te, choć miały miejsce w różnych sieciach, były ze sobą silnie powiązane – ich celem byli amerykańscy operatorzy płatności kartowych.

Do pierwszego ataku doszło 6 lipca. Indonezyjski operator rozgłosił perfiksy 5 sieci spoza swojej adresacji. Po pół godzinie konfigurację zmieniono, a błędne trasy nie rozeszły się zbyt szeroko. Cztery dni później te same 5 prefiksów sieci rozgłosił błędnie operator malezyjski. Ponownie atak trwał pół godziny i błędne trasy trafiły tylko do kilku innych sieci. Po kilku godzinach atak powtórzono, tym razem jednak z większym rozmachem – prefiksy trafiły do sieci 48 operatorów.

W tych atakach najciekawsze były sieci, których dotyczyły. Należały one do firm Datawire i Worldpay, a obejmowały swoim zasięgiem adresację ich serwerów DNS – obsługujących domeny odpowiedzialne za przetwarzanie płatności kartowych.

Kilka godzin później ten sam operator zaatakował w identyczny sposób kolejne cztery sieci – także powiązane z rynkiem płatności kartowych, obejmujące kluczowe serwery DNS. W kolejnej dobie powtórzono atak na pierwsze pięć sieci, które były wcześniej już dwukrotnie na celowniku napastników. Tym razem ataki trwały kilka godzin. W ostatniej fali ataków, pod koniec 12 lipca ofiarami napastników padły między innymi sieci, w których znajdują się popularne serwery UltraDNS.

Dlaczego celem napastników były serwery DNS?

Atak wstrzyknięcia złośliwej trasy BGP może trwać kilkadziesiąt minut, może kilka godzin. Jak można przedłużyć jego efekt do kilku dni? Metoda jest dość prosta i skuteczna. Trzeba przejąć kontrolę nad adresem IP serwera DNS, podstawić swój własny serwer w jego miejsce i udzielać pytającym o adres IP klientom nieprawidłowych odpowiedzi z długim czasem ważności. Tak właśnie postąpili przestępcy. Rejestry odpowiedzi serwerów DNS pokazują, że ok. 11-13 lipca domeny *.datawire.net nieprawidłowo wskazywały na adres IP 45.227.252.17. Zazwyczaj parametr TTL, czyli okres ważności odpowiedzi serwera DNS, wynosi ok. 10 minut – w tym wypadku TTL ustawiony był na 5 dni, zapewniając, że wiele godzin po ustaniu ataku BGP część klientów nadal łączyła się z serwerem przestępców. Podobny atak, lecz wymierzony w usługi związane z kryptowalutami, miał miejsce w kwietniu, a celem przestępców był serwer DNS Amazona.

Skutki ataku

Ocena skutków ataku z naszej pozycji nie jest łatwa – ofiary ataku lepiej wiedzą, jakie informacje mogły wpaść w ręce przestępców. Wiele zależy od tego, czy systemy łączące się z przejętymi adresami sprawdzały np. ich certyfikaty SSL, czy połączenia były szyfrowane itd. Bez wątpienia w sieci widać ślady wskazujące, że ataki byłī zauważone przez operatorów płatności i ich klientów – np. ten post na Reddicie czy tweety takie jak ten:

https://twitter.com/glyngh/status/1017796068874915841

Co ciekawe, śledzenie ruchu przekierowanego przez przestępców wskazywało, że serwery, na które trafiały ofiary, znajdowały się fizycznie w okolicach Ługańska, na terenie Ukrainy opanowanym przez prorosyjskich separatystów.

Jak się bronić

Po pierwsze zadajcie sobie pytanie, czy Wasza firma może ponieść straty, jeśli część klientów trafi na fałszywą witrynę. Jeśli tak, to warto upewnić się, że straty zostaną zminimalizowane (np. wymuszając weryfikację certyfikatu SSL po stronie aplikacji klientów), a sam atak odpowiednio szybko wykryty (poprzez monitoring usługi BGP). W przypadku wykrycia ataku można się bronić – na przykład rozgłaszając bardziej specyficzne trasy BGP od atakujących, jak w trakcie opisywanego powyżej incydentu czyniła to jedna z zaatakowanych firm. Bo na to, że nagle wszyscy operatorzy porozumieją się co do rozwiązania problemu, jeszcze pewnie długo liczyć nie możemy. Czasem udaje się odłączyć od sieci operatora, który powoduje najwięcej problemów, jednak to nie wystarcza. Rozwiązania techniczne istnieją, lecz ich wdrażanie przebiega zdecydowanie zbyt wolno.

Powrót

Komentarze

  • 2018.08.07 16:32 HardwareBased

    paradoksalnie dlugi TTL ustawiony pierwotnie na 'legalnych’ DNS’ach powinien ograniczyć rozmiar ataku.

    Odpowiedz
  • 2018.08.07 22:04 Eryk

    Witam, kilka razy na dzień rozłącza mi internet i za każdym razem po rozłączeniu sieci konsola cmd pokazuje mi takie nazwy dns. Czy to jakiś mały atak ddos na mój system?
    http://wklejto.pl/605186

    Odpowiedz
    • 2018.08.07 22:26 adamh

      To polecenie pokazuje jakie domeny i adresy IP zapamiętał Twój system – tzw. cache DNS. O niczym to raczej nie świadczy.

      Odpowiedz
    • 2018.08.09 16:39 Dedal

      Obstawiam jakiś PUP w Twoim systemie…

      Odpowiedz
      • 2018.08.09 17:57 Eryk

        Był robiony format, skanowany system antywirusami nod, malwarebytes, rkill, adwcleaner, tdsskiller, logi były sprawdzane FRST i naprawiane. Jest firewall postawiony, co jeszcze mogę sprawdzić?

        Odpowiedz
  • 2018.08.09 17:23 lolek

    Czy podczas takiego ataku można wygenerować certyfikat przy pomocy Let’s Encrypt? LE pozwala blokować domeny przy użyciu rekordów CAA w DNS ale jeżeli LE odpyta serwer, które są pod kontrolą atakujących to wiele to nie da.

    Odpowiedz

Zostaw odpowiedź

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Ruch operatorów płatności skradziony na serwery w okupowanej Ukrainie

Komentarze