Wprowadzenie do problemu / definicja
W projekcie strongSwan, jednym z najczęściej wykorzystywanych otwartoźródłowych rozwiązań do budowy tuneli IPsec VPN, ujawniono poważną podatność umożliwiającą zdalne doprowadzenie do awarii usługi. Problem dotyczy parsera EAP-TTLS AVP i może zostać wykorzystany przez atakującego bez wcześniejszego uwierzytelnienia. W praktyce oznacza to możliwość przeprowadzenia skutecznego ataku typu denial-of-service przeciwko infrastrukturze zdalnego dostępu.
W skrócie
Podatność obejmuje wersje strongSwan od 4.5.0 do 6.0.4 i została usunięta w wydaniu 6.0.5. Źródłem problemu jest błąd typu integer underflow w obsłudze długości pól AVP w mechanizmie EAP-TTLS. Odpowiednio spreparowane dane wejściowe mogą prowadzić do nadmiernej alokacji pamięci, wyczerpania zasobów lub dereferencji wskaźnika NULL, co finalnie kończy się awarią demona charon odpowiedzialnego za obsługę IKE.
- zakres podatnych wersji: 4.5.0–6.0.4,
- wersja naprawiona: 6.0.5,
- wektor ataku: zdalny, bez uwierzytelnienia,
- główny skutek: odmowa dostępu i niedostępność usług VPN.
Kontekst / historia
strongSwan od lat pełni istotną rolę w środowiskach wykorzystujących IPsec zarówno po stronie serwerowej, jak i klienckiej. Oprogramowanie obsługuje wiele metod uwierzytelniania, w tym EAP-TTLS, który służy do przenoszenia danych uwierzytelniających przez tunel TLS z użyciem struktur AVP.
Szczególnie niepokojące jest to, iż wada obejmuje szeroki zakres wersji, co sugeruje wieloletnią obecność błędu w kodzie. Z punktu widzenia zarządzania podatnościami zwiększa to ryzyko, ponieważ wiele organizacji utrzymuje starsze, stabilne wdrożenia VPN i nie aktualizuje ich natychmiast po publikacji poprawek. Ze względu na obecność strongSwan w środowiskach Linux, macOS, Windows i Android wpływ podatności wykracza poza pojedynczą platformę.
Analiza techniczna
Rdzeń problemu znajduje się w parserze EAP-TTLS AVP, który nie weryfikuje poprawnie długości pól przed wykonaniem operacji odejmowania. Gdy atakujący dostarczy wartość długości z zakresu od 0 do 7, może dojść do zjawiska 32-bitowego integer underflow. W efekcie aplikacja wylicza błędnie bardzo duży rozmiar bufora.
Dalszy przebieg zależy od zachowania środowiska wykonawczego i mechanizmu alokacji pamięci. W jednym scenariuszu system próbuje zrealizować żądanie alokacji nadmiernie dużego obszaru pamięci, co może prowadzić do wyczerpania zasobów. W innym przypadku nieudana alokacja skutkuje późniejszą dereferencją wskaźnika NULL i błędem segmentacji. W obu wariantach końcowym efektem jest awaria procesu charon odpowiedzialnego za zestawianie i utrzymywanie tuneli IKE/IPsec.
Analizy wskazują, iż skuteczne doprowadzenie do crashu może wymagać sekwencji co najmniej dwóch pakietów. Pierwszy wpływa na stan sterty, a drugi wyzwala adekwatną awarię przez użycie uszkodzonych struktur lub próbę obsługi nierealistycznie dużej alokacji. Nie zmienia to jednak kluczowego faktu: podatność pozostaje zdalnie osiągalna i nie wymaga logowania.
Poprawka wdrożona w wersji 6.0.5 dodaje walidację długości AVP już na etapie parsowania. To klasyczny przykład błędu walidacji danych wejściowych w kodzie niskopoziomowym, gdzie nieprawidłowe założenie dotyczące rozmiaru danych może przełożyć się na niestabilność całej usługi sieciowej.
Konsekwencje / ryzyko
Najbardziej bezpośrednim skutkiem podatności jest utrata dostępności usług VPN. W środowiskach produkcyjnych może to oznaczać przerwanie pracy zdalnej, brak dostępu administratorów do segmentów zarządzających, zerwanie połączeń site-to-site oraz ograniczenie ciągłości działania systemów zależnych od tuneli IPsec.
Ryzyko jest szczególnie wysokie dla organizacji, które publicznie udostępniają strongSwan w internecie, wykorzystują EAP-TTLS w procesie uwierzytelniania, nie monitorują awarii procesu charon lub nie mają wdrożonych mechanizmów automatycznego restartu i redundancji bram VPN.
Na obecnym etapie publicznie opisywany skutek dotyczy przede wszystkim denial-of-service, a nie zdalnego wykonania kodu. Nie obniża to jednak wagi problemu. W przypadku infrastruktury VPN choćby krótkotrwała niedostępność może mieć krytyczne znaczenie biznesowe, zwłaszcza gdy usługa stanowi jedyny kanał zdalnego dostępu dla pracowników lub administratorów.
Rekomendacje
Najważniejszym działaniem ochronnym jest niezwłoczna aktualizacja strongSwan do wersji 6.0.5 lub nowszej. Organizacje korzystające ze starszych, utrzymywanych gałęzi powinny dodatkowo sprawdzić dostępność backportów oraz poprawek dostarczanych przez opiekunów pakietów w używanej dystrybucji.
- zidentyfikować wszystkie instancje strongSwan w środowisku,
- potwierdzić, czy w konfiguracji wykorzystywany jest EAP-TTLS,
- przeanalizować ekspozycję usług IKE/IPsec do internetu,
- włączyć monitoring restartów i awarii procesu charon,
- skonfigurować automatyczne odtwarzanie usługi po crashu,
- ograniczyć dostęp do bram VPN do zaufanych zakresów adresowych tam, gdzie to możliwe,
- uzupełnić procedury SOC i IR o scenariusze związane z próbami wymuszenia awarii VPN.
Z perspektywy bezpiecznego rozwoju systemu incydent przypomina również o znaczeniu rygorystycznej walidacji pól długości, testów fuzzingowych parserów oraz analizy zachowania kodu dla wartości granicznych i nieprawidłowych struktur danych.
Podsumowanie
Nowo ujawniona luka w strongSwan pokazuje, iż choćby dojrzałe i szeroko stosowane komponenty bezpieczeństwa mogą zawierać długo obecne błędy prowadzące do poważnych zakłóceń operacyjnych. W tym przypadku wada w parserze EAP-TTLS AVP umożliwia nieuwierzytelnionemu atakującemu zdalne wywołanie awarii procesu charon, a tym samym unieruchomienie usług VPN. Dla zespołów bezpieczeństwa priorytetem powinno być szybkie wdrożenie poprawionej wersji, przegląd konfiguracji EAP-TTLS oraz zwiększenie obserwowalności infrastruktury VPN.
Źródła
- SecurityWeek: https://www.securityweek.com/strongswan-flaw-allows-unauthenticated-attackers-to-crash-vpns/
- NVD: https://nvd.nist.gov/
- strongSwan Project: https://www.strongswan.org/
- Bishop Fox: https://bishopfox.com/