Z

acznimy od początku. 28 lutego 2008 roku Brian Aker dodał do kodu memcache ciekawą funkcję, która spowodowała, że daemon memcache w standardowej konfiguracji zaczął nasłuchiwać również w protokole UDP. O kwestiach braku mechanizmów bezpieczeństwa memcached mówił już 2014 roku Ivan Novikov w swojej prezentacji na BlackHat U.S. W 2017 roku chińska grupa cyberbezpieczeństwa o nazwie 0Kee Team ujawniła możliwość wykonywania ataków DDoS o wysokim wolumenie przepustowości. Dni pomiędzy 23, a 26 lutego tym razem 2018 roku odznaczyły się wieloma atakami DDoS wzmocnionymi ruchem właśnie z serwerów memcached. Różne źródła ( Cloudflare, Github, OVH, Arbor, Akamai) potwierdziły bycie ofiarami ataków o dotychczas niespotykanej skali ruchu sieciowego.

Idea tego rodzaju ataków jest bardzo prosta. Zawierają one dwa wektory. Pierwszym z nich jest wektor odbicia: atakujący, który podszywa się pod dany adres IP wysyła żądania do podatnego serwera memcached nasłuchującego w protokole UDP. Serwer nie zdając sobie sprawy, że żądanie jest sfałszowane, grzecznie odpowiada na nie. Problem w tym, gdy wysyłanych jest tysiące żądań do różnych serwerów, a one odpowiadają niczego nie podejrzewającemu jednemu hostowi (adresowi IP, który sfałszował atakujący) – przytłaczając atakiem DDoS jego zasoby – najczęściej łącze sieciowe. Drugim jest wektor wzmocnienia: memcached może mieć współczynnik wzmocnienia wynoszący od 9000 do ponad 500.000, co oznacza, że żądanie (sfałszowane) o wielkości 203 bajtów może wygenerować w odpowiednich warunkach odpowiedź o wielkości 100 megabajtów. Czyli niewielkie łącze atakującego może wygenerować wielki wolumen ataku DDoS.

Identycznie, jak w przypadku zmasowanych ataków DDoS za pomocą urządzeń IoT, aby przeprowadzić tego rodzaju ataki trzeba mieć dostępnych pod ręką bardzo wiele podatnych serwerów. Tych w przypadku memcached nie brakuje. Pod koniec lutego liczba ta wynosiła 92.775 otwartych serwerów. Raz – że bardzo wielu administratorów zapewne nie było świadomych, że ich serwery memcached nasłuchują w protokole UDP i (o ile) zabezpieczyli tylko TCP. Dwa – konfiguracja niektórych dystrybucji Linuksa (np. CentOS) standardowo wprowadza nasłuch tego daemona na wszystkich interfejsach – zamiast tylko na lokalnym. Warto sprawdzić swoje serwery pod kątem tej wadliwej konfiguracji, aby czasami nie okazało się, że sami bierzemy aktywny udział w tego typu atakach. Dobrym pomysłem jest także zablokowanie na swoim firewallu ruchu pochodzącego z źródłowego portu memcached: 11211 (jest bardzo mało prawdopodobne, że z tego portu będzie pochodziła “prawidłowa komunikacja”). Tym bardziej, że są już dostępne narzędzia – wykorzystujące API Shodana, do wyciągania aktualnej listy serwerów i atakowania wybranych celów. Memcached wydał już poprawkę cofającą to zachowanie, ale zapewne trafi ona dopiero do przyszłych wydań dystrybucji. Nie wszystkie serwery też od razu zamkną dostęp do portu UDP lub wyłączą nasłuch na interfejsach publicznych.

Więcej informacji: Memcache UDP Reflection Amplification Attack II: The Targets, the Sources and Breakdowns