OVH NEWS | AKTUALNOŚCI, INNOWACJE I TENDENCJE W IT


Najnowsze informacje o OVH









29/03/2018
Podziel się z innymi

Autor artykułu: Sébastien Meriot


Atak o przepustowości 1,3 Tbps zneutralizowany przez OVH dzięki systemowi VAC: analiza zagrożenia Memcached


W czwartek 1 marca, około godziny 2 rano (GMT+1), firma OVH, dzięki systemowi VAC, zablokowała atak DDoS skierowany na infrastrukturę jednego z jej klientów. W trakcie ataku wykorzystano ruch sieciowy o łącznej przepustowości przekraczającej 1,3 Tbps, był on zatem silniejszy od rekordowego dotychczas ataku wygenerowanego przez botnet MIRAI (1 Tbps). Zaledwie kilka godzin wcześniej celem ataku, również o przepustowości 1,3Tbps, stał się popularny serwis programistyczny Github. W wyniku ataku strona Github była niedostępna przez kilka minut.



Wspólnym mianownikiem w obydwóch wypadkach jest technologia wykorzystana do wygenerowania tych ataków – podatności i błędy w konfiguracji usług Memcached oraz mechanizm zwielokrotnienia i odbicia (amplification).



Rysunek 1: Atak o przepustowości 1,3 Tbps skierowany na jednego z klientów OVH zniwelowany dzięki systemowi VAC.


Memcached - winna domyślna konfiguracja


Memcached jest open source’owym systemem rozproszonej pamięci podręcznej typu « key/value store ». Jest to oprogramowanie używane głównie do przyspieszania stron WWW, aplikacji internetowych oraz buforowania wyników zapytań do baz danych w celu zmniejszenia czasu odczytu danych. Narzędzie to jest powszechnie używane przez webmasterów oraz producentów oprogramowania. Dlaczego ta popularna usługa nagle zaczęła stanowić zagrożenie?



W 2017 r. analitycy bezpieczeństwa sieci z chińskiej spółki 360 odkryli możliwość wykorzystania błędu w konfiguracji Memcached do generowania ataków DDoS “przez odbicie i zwielokrotnienie”. Okazuje się, że w czasie instalacji Memcached nasłuchuje w trybie domyślnym na interfejsie publicznym. Jeżeli dodamy do tego brak reguł ograniczających ruch na zaporze sieciowej, Memcached jest dostępny dla każdego użytkownika Internetu korzystającego z publicznego adresu IP. Gdyby usługa nasłuchiwała, wykorzystując jedynie protokół TCP, problem ograniczony byłby do ryzyka utraty poufności danych, jako że w Memcached nie istnieją mechanizmy uwierzytelniające. Niestety usługa nasłuchuje również przy użyciu protokołu UDP, co znacznie komplikuje sytuację, ponieważ podczas ataku DDoS daje to możliwość zwiększenia 51 000 razy ilości przesyłanych danych. Dla porównania współczynnik zwielokrotnienia w przypadku ataku wykorzystującego protokół NTP wynosił zaledwie 557.



Co to jest atak „przez odbicie i zwielokrotnienie”?


Zwielokrotnienie polega na wygenerowaniu znacznie większej odpowiedzi niż otrzymane zapytanie. Rysunek 2 przedstawia przykład, w którym współczynnik zwielokrotnienia wynosi 2. Oznacza to, że odpowiedź jest dwa razy większa niż zapytanie.



Rysunek 2: Schemat ukazujący dwa razy większą odpowiedź niż zapytanie (współczynnik zwielokrotnienia 2).


Aby zwiększyć moc ataków DDoS, hakerzy łączą mechanizm zwielokrotnienia z mechanizmem odbicia. Odbicie polega na skierowaniu zapytania do podatnego serwera z zafałszowanego źródłowego adresu IP (wykorzystanie IP spoofing), a następnie wysłaniu odpowiedzi do adresu, pod który serwer inicjujący się podszywa. W efekcie serwer będzie wysyłał odpowiedzi do źródłowego adresu IP, choć źródłem zapytania był serwer inicjujący atak.



Rysunek 3: Mechanizm odbicia połączony z efektem zwielokrotnienia.


Wykorzystanie tego mechanizmu pozwala na wysyłanie do zaatakowanego serwera pakietów, będących odpowiedziami na nigdy nie wysłane z serwera zapytania.
Zjawisko odbicia jest bardzo często stosowane w przypadku ataków UDP, gdyż jest to protokół działający w trybie „bezpołączeniowym”. Oznacza to, że w przeciwieństwie do TCP nie posiada mechanizmu « three-way handshake ». Wystarczy zatem wysłać tylko jeden pakiet, aby otrzymać odpowiedź odbiorcy, podczas gdy w przypadku TCP potrzeba wymiany co najmniej czterech pakietów między klientem a serwerem, aby ustanowione zostało połączenie. Jeżeli IP źródłowe byłoby zafałszowane (za pomocą IP spoofing), odpowiedź serwera (SYN-ACK) dotarłaby do celu ataku, a inicjator połączenia nie mógłby potwierdzić ustanowienie połączenia (ACK), co spowodowałoby, że połączenie nie zostałoby rozpoczęte, a zafałszowanie IP nie przyniosłoby zamierzonego efektu.



Na straży bezpieczeństwa infrastruktury


Nietypowy wzrostem liczby ataków „przez zwielokrotnienie” wykorzystujących Memcached został szybko zauważony i firma OVH podjęła działania mające na celu skuteczne zabezpieczenie swojej infrastruktury. Zwielokrotnienie jest mechanizmem, który łatwo rozpoznać, gdy ma miejsce w monitorowanej sieci. Wprowadzając środki bezpieczeństwa w sieci, należy bezwzględnie upewnić się, że łącza wymiany ruchu z innymi operatorami (peering) nie są wysycone, a jakość usług nie ulegnie pogorszeniu. Strategia bezpieczeństwa OVH zdała już wcześniej egzamin podczas ostatniego ataku o przepustowości ponad 1,3 Tbps (patrz rys. 1). Za pomocą technologii VAC został on zneutralizowany, a ciągłość usługi nie została zachwiana.



Tym razem plan działania miał również na celu ochronę klientów OVH, którzy mają nieprawidłowo skonfigurowaną usługę Memcached, i których serwery mogą zostać wykorzystane podczas generowania ataków. Aby temu zapobiec OVH podjęła następujące kroki:



• wysłała do potencjalnie zagrożonych klientów komunikat dotyczący właściwej konfiguracji usługi Memcached wraz z dokumentacją techniczną;



• nie czekając na wprowadzenie poprawek w konfiguracji przez klientów, zidentyfikowała adresy IP OVH służące do odbicia oraz podjęła interwencje bezpośrednio w sieci.



Najprostszym środkiem zaradczym, blokującym możliwość wykorzystania serwerów naszych klientów do przeprowadzania ataków przez zwielokrotnienie i odbicie, byłaby blokada portu UDP/11211 (używanego przez Memcached). Firma OVH jednak nie zdecydowała się na ten krok ze względu na ryzyko pogorszenia jakości usług, takich jak gry online, VOIP czy streaming, które korzystają z protokołu UDP i mogą wykorzystywać ten port do połączeń klienckich.

OVH zastosowała inne rozwiązanie. Firma uruchomiła stałe filtrowanie ruchu dla adresów IP otrzymujących zwiększoną ilość zapytań do usług Memcached i tym samym zidentyfikowanych jako mogące przyczyniać się do generowania ataków. Dzięki mitygacji niepożądanego ruchu już na wejściu do sieci, OVH udaremniła wykorzystanie serwerów swoich klientów do przeprowadzenia ataków DDoS typu „zwielokrotnienie i odbicie”.



Przeprowadzone dochodzenie


26 lutego 2018 specjaliści ds. bezpieczeństwa OVH zaobserwowali pierwsze ataki, które były generowane przez zapytania typu « gets » (patrz rys. 4). Podobnie jak Cloudflare, odkryli, że komenda ta umożliwia odczytanie klucza zawierającego plik „zip” chroniony hasłem i zawierający plik „gif”.



Rysunek 4: Zapytania na porcie UDP/11211 (Memcached) przechwycone przez pułapki „honeypot” 27/02/2018.


W jaki sposób plik „zip” znalazł się w pamięci podręcznej? Eksperci OVH postawili tezę, że usługi wykorzystywane do mechanizmu zwielokrotnionego odbicia zostały przygotowane wcześniej tak, aby mogły zostać użyte w czasie ataku. OVH pracuje nad ustaleniem źródła plików zip w pamięci podręcznej. Tymczasem wiadomo, że Memcached był używany od kilku dni do zwielokrotniania. Grafika na rysunku 5 ukazuje przepustowość serwera jednego z naszych klientów, który był wykorzystywany od dnia 24 lutego 2018 do kierowania ataków na chiński adres IP „59.56.19.xxx ” (ostatnie cyfry zostały ukryte ze względów bezpieczeństwa).



Rysunek 5: Ataki przez zwielokrotnienie na porcie UDP/11211 wygenerowane przez serwer jednego z naszych klientów 24/02/2018 (GMT+1).


Ten adres IP był regularnie atakowany przez maszyny z sieci OVH w sposób zsynchronizowany z wykorzystaniem mechanizmu zwielokrotnienia w połączeniu z różnymi protokołami, takimi jak LDAP, NTP, SNMP, etc. Istnieją różne hipotezy wyjaśniające to zjawisko. Przykładowo pod adresem tym hostowana jest usługa wzbudzająca dużą niechęć konkurencji albo też adres miał posłużyć jako testowy w trakcie przygotowań do ataków przez zwielokrotnienie z wykorzystaniem Memcached.



Specjaliści OVH zaobserwowali, że ataki kierowane na ten adres są zazwyczaj bardzo krótkie: trwają od kilkudziesięciu sekund do kilku minut, podczas gdy inne ataki trwają o wiele dłużej (najdłuższy odnotowany atak trwał 3 godziny). Wiele elementów wskazuje, że możemy mieć do czynienia z adresem IP pełniącym funkcję „dstat”, czyli narzędziem mierzącym w czasie rzeczywistym skuteczność ataku DDoS.



To z kolei nasuwa przypuszczenia, że administratorzy platformy sprzedającej ataki DDoS („booter”) chcieli prawdopodobnie porównać różne ataki przez zwielokrotnienie ze zwielokrotnieniem Memcached. Wśród ataków wykrytych w tym samym czasie pojawiły się ataki bazujące na protokołach NTP (UDP / 123), LDAP (UDP / 389), SSDP (UDP / 1900) i BitTorrent.



Kontynuując poszukiwania źródeł ataków, OVH trafiła na ciekawy wątek na forum, w którym jeden z użytkowników zdradził, iż jego platforma sprzedaży ataków DDoS jako pierwsza udostępniła zwielokrotnienie Memcached.



Rysunek 6: Użytkownik forum ogłasza publicznie, że jest autorem skryptu umożliwiającego zwielokrotnienie Memcached.


Wzrost zagrożenia


W ciągu tygodnia sytuacja znacząco się zmieniła: na początku zjawisko zwielokrotnienia Memcached zdawało się mieć jedno źródło, jednak po kilku dniach administratorzy innych platform sprzedaży DDoS zaimplementowali tę samą funkcję i zaczęli udostępniać ją swoim klientom. Od momentu pojawienia się pierwszych przypadków ataków, pułapki „honeypot” OVH wykryły liczne sposoby wykorzystywania dostępnych w Internecie usług Memcached (patrz rys. 7).



Rysunek 7: Komendy Memcached otrzymane przez pułapki honeypot OVH.


W niektórych usługach plik „zip” zawarty w kluczu „a” zastąpiony został ciągiem „abcdefghij”, powtórzonym tysiące razy, którego nie postrzegamy jako próby zapisu:



Rysunek 8: Przykład Memcached z kluczem „a” zawierającym wielokrotnie powtórzony fragment alfabetu.


Firma OVH zaobserwowała również klucze zawierające wiadomości z żądaniem zapłaty 50 XMR (popularna wirtualna waluta znana również pod nazwą Monero). Czyżby byłaby to próba wyłudzenia okupu od właścicieli baz danych, które z definicji przechowują tylko dane tymczasowe? A może to kolejny sposób na zapełnienie pamięci podręcznej, aby wzmocnić współczynnik zwielokrotnienia?



Rysunek 9: Klucz „a” usługi Memcached zawierający wiadomość z żądaniem zapłaty 50 XMR.


Do tej pory niewielka liczba otwartych usług Memcached została zabezpieczona, wiele z nich wciąż pozostaje podatnych na ataki, pomimo kampanii informacyjnej, jak ta przeprowadzona przez OVH.
Wydaje się, iż podobnie jak miało to miejsce w przypadku ataków NTP, z zagrożeniem Memcached będziemy się zmagać przez dłuższy czas. Nawet jeśli wdrożone przez firmy hostingowe zabezpieczenia istotnie zmniejszyły wielkość ataków (większość ma obecnie przepustowość mniejszą niż 100 Gbps), kluczowa dla rozwiązania problemu pozostaje zmiana konfiguracji Memcached, przeprowadzona indywidualnie przez użytkowników. Przypadek NTP pokazuje, że nawet po 5 latach od ogłoszenia podatności, mimo dostępnych poprawek i aktualizacji, nadal istnieją serwery podatne na to zagrożenie.