P

omimo upłynięcia 7 lat od ataków DDoS (ang. Distributed Denial of Service) za pomocą protokołu XMLRPC CMS WordPress – ilość podatnych serwerów nadal stanowi zagrożenie. Badacz bezpieczeństwa Andrea Menin przeszukując na początku top listę stron według rankingu Alexa, a później archiwum Common Crawl uzyskał dostęp do 7.500 instalacji, które aktywnie odpowiadają na metodę pingback.ping. Umożliwia to stworzenie botnetu, który będzie w stanie przeprowadzać wzmocnione ataki DDoS. W dodatku utrzymując stronę opartą o WordPress – jeśli nie posiadamy ograniczonej komunikacji do tego protokołu lub przynajmniej metody pingback:

add_filter( 'xmlrpc_methods', function( $methods ) {
   unset( $methods['pingback.ping'] );
   return $methods;
} );

a nasz serwer znajduje się za dostawcą typu Cloudflare – musimy mieć świadomość że otwarta komunikacja za pomocą XMLRPC może doprowadzić do wycieku oryginalnego adresu IP serwera i ominięcia warstwy ochronnej serwisu (jeśli dopuszczamy do ruchu inne serwery niż te, z których pochodzi ruch przefiltrowany przez WAF). Jeśli nie prowadzisz witryny opartej o WordPress lub nie jesteś zainteresowany otrzymywaniem komunikatów typu pingback od innych webaplikacji WordPress (a ponadto chcesz zapobiec atakom typu DDoS) – możesz zablokować żądania pochodzące z funkcji WordPress, filtrując nagłówek aplikacji klienckiej np.:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "^WordPress.*verifying pingback" [NC]
RewriteRule . - [F,L]

lub

if ($http_user_agent ~* "^WordPress.*verifying pingback") {
    return 403
}

Więcej informacji: Make WordPress Pingback Great Again, WordPress Pingback Attacks and our WAF

C

iasteczka DNS zostały przedstawione w RFC 7873. Są opcją rozszerzonego DNS (ang. EDNS – Extended DNS), która próbuje zaadresować wiele problemów, które próbował rozwiązać DNSSEC np. zatruwanie pamięci podręcznej (ang. Cache Poisoning), czy ataki polegające na wzmocnieniu odpowiedzi DNS (ang. DNS Amplification Attack) z sfałszowanymi adresami źródłowymi (ang. Spoofed Source Queries), którym DNSSEC nie zapobiegał, a nawet w niektórych przypadkach je pogarszał. Ciasteczka są znacznie łatwiejsze do wdrożenia niż DNSSEC, a bezpieczeństwo zapewniane przez nie można porównać do bezpieczeństwa uzyskiwanego dzięki użyciu TCP zamiast UDP.
[ czytaj całość… ]

R

PC Portmapper (znany również jako: portmap lub rpcbind) jest usługą typu Open Network Computing Remote Procedure Call (ONC RPC) zaprojektowaną do mapowania numerów usług RPC na numery portów sieciowych. Procesy RPC powiadamiają rcpbind, gdy startują rejestrując porty na których będą nasłuchiwać. To samo tyczy się ich numerów programów, które mają obsługiwać. Wówczas usługa rpcbind przekierowuje klienta do właściwego numeru portu, aby mógł komunikować się z żądanym serwisem. 3 lata temu usługa ta została wykorzystana do wzmacniania rozproszonych ataków DoS. Gdy portmapper jest odpytywany rozmiar odpowiedzi jest zależny od ilości usług RPC obecnych na hoście. W 2015 roku badacze z firmy Level 3 w swoich eksperymentach uzyskali odpowiedzi na poziomie od 486 bajtów (współczynnik wzmocnienia 7.1) do 1930 bajtów (ww = 28.4) dla 68-bajtowego zapytania. Średni rozmiar wzmocnienia w przeprowadzonych testach wynosił 1241 bajtów (ww = 18.3), podczas gdy w rzeczywistych atakach DDoS zaobserwowana wartość wynosiła 1348 bajtów, co daje wzmocnienie na poziomie 19.8 raza.
[ czytaj całość… ]

J

akiś czas temu została znaleziona luka / podatność, która może mieć wpływ na większość usług korzystających z protokołu TCP. Jest to nowy wariant ataku Denial of Service, który może zwielokrotnić efektywność jego tradycyjnej formy. Ideą tego ataku jest zamknięcie sesji TCP po stronie atakującego, pozostawiając ją otwartą po stronie ofiary. Zapętlenie tej czynności może spowodować szybkie zapełnienie limitu sesji ofiary, co skutecznie uniemożliwi innym użytkownikom dostęp do usługi ofiary. Jest to możliwe poprzez nadużycie RFC 793 (str. 36), który nie przewiduje wyjątku, jeśli pakiet reset (RST) nie zostanie wysłany.
[ czytaj całość… ]

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.
[ czytaj całość… ]

M

ulticast DNS (mDNS, DNS w trybie rozsyłania grupowego) został stworzony w celu wykonywania operacji DNS w sieciach lokalnych pozbawionych konwencjonalnego serwera DNS działającego w trybie transmisji jednostkowej – unicast. Jako usługa typu zero-config wymaga niewielkiej lub nie wymaga żadnej konfiguracji, aby korzystać z połączenia pomiędzy uczestnikami w sieci. Protokół ten działa, nawet gdy nie ma żadnej infrastruktury lub jest ona w stanie awarii – wymaga jedynie współpracy pomiędzy innymi użytkownikami w sieci.
[ czytaj całość… ]

B

lacknurse jest kolejnym rodzajem ataku typu ICMP Flood. Wystarczy niewielka przepustowość, aby przeprowadzić skuteczny DoS (Denial of Service) na kilku zaporach ogniowych znanych producentów. Czym ten atak różni się od typowego ICMP Ping Flood? Ping używa pakietów ICMP Typu 8, czyli Echo Requests, a pielęgniarka ICMP Typu 3, czyli Destination Unreachable – co powoduje znacznie większe zużywanie zasobów na zaporach w porównaniu do innych bardziej powszechnych ataków. Wystarczy, że firewall zezwala na przyjmowanie pakietów ICMP Typu 3 na zewnętrznych interfejsach, aby atak stał się bardzo skuteczny nawet przy jego niskiej przepustowości. Jak niskiej? Wystarczy około 15 – 18 Mbit/s i wolumen pakietów w przedziale od 40 do 50 tysięcy na sekundę, aby położyć np. 1 Gbit/s łącze ofiary.
[ czytaj całość… ]

P

ozostańmy jeszcze przy shodanie. Tym razem po to, aby przyjrzeć mu się z punktu widzenia pewnych mechanizmów, środowiska rozproszonego i – bardziej niebezpiecznego. Kilka dni temu, pojawiła się wiadomość, że DC/OS stał się dostępny w chmurze obliczeniowej Azure. W praktyce oznacza to, że uruchamiając X maszyn wirtualnych w tej usłudze, będziemy w stanie spiąć je w jeden klaster, oferujący wspólne zasoby obliczeniowe, pamięciowe i dyskowe. Zyskamy także możliwość dowolnego dzielenia tych zasobów, wedle naszych potrzeb i rodzajów aplikacji, które będziemy chcieli uruchomić.
[ czytaj całość… ]

N

o właśnie, co z tymi pakietami SYN? Tutaj ponownie pojawia się problem skalowalności systemu conntrack (tak jak dla stanu listen) dla tworzenia (lub usuwania) połączeń, które spowoduje zalew pakietów SYN. Nawet jeśli uporamy się z blokadą w warstwie conntrack to kolejnym krokiem wędrówki pakietu SYN będzie stworzenie gniazda w trybie “nasłuchu”, czyli kolejną barierą wydajnościową. Normalnym procesem łagodzenia tego typu pakietów w systemie Linux będzie mechanizm SYN-cookies, który również ma ograniczenia.
[ czytaj całość… ]

P

odstawowy problem skalowalności protokołu TCP w jądrze Linuksa jest związany z liczbą nowych połączeń, jakie mogą być tworzone na sekundę. Odnosi się to bezpośrednio do obsługi gniazd powstających w trybie nasłuchu, które są blokowane. Blokady powodowane są nie tylko przez pakiety z flagą SYN, ale także SYN-ACK oraz ACK (ostatni w potrójnym uścisku dłoni). Podczas ataków DoS / DDoS za pomocą tego rodzaju pakietów atakujący ma na celu wysłanie, jak największej ilości spreparowanych pakietów, które mają na celu osiągnąć i spowodować problem z blokowaniem gniazd w trybie nasłuchu. Jedną z metod jest podniesienie bardzo niskiego limitu dla tego typu gniazd oraz kolejki oczekujących połączeń w systemie:
[ czytaj całość… ]