Wprowadzenie do problemu / definicja
W komponencie flyto_core w wersjach do 2.26.7 ujawniono podatność typu Server-Side Request Forgery (SSRF), która umożliwia ominięcie mechanizmu blokującego dostęp do zasobów wewnętrznych. Problem wynika z błędu klasy „resolve-then-connect”, w którym aplikacja najpierw sprawdza wynik rozpoznania DNS, a następnie podczas właściwego połączenia ponownie rozwiązuje nazwę hosta bez powiązania jej z wcześniej zweryfikowanym adresem IP.
Taki model działania otwiera drogę do ataku DNS rebinding. W praktyce oznacza to, że adres uznany początkowo za bezpieczny może przy kolejnym zapytaniu DNS wskazać już na localhost lub inną usługę dostępną wyłącznie z wnętrza infrastruktury.
W skrócie
- Podatność dotyczy flyto_core w wersjach do 2.26.7.
- Problem został usunięty w wersji 2.26.8.
- Luka pozwala obejść ochronę SSRF dzięki technice DNS rebinding.
- Atak może prowadzić do połączeń z adresami wewnętrznymi, w tym 127.0.0.1.
- Ryzyko rośnie w środowiskach z dostępem do wewnętrznych API, paneli administracyjnych i usług chmurowych.
Kontekst / historia
SSRF od lat pozostaje jedną z najgroźniejszych klas błędów w aplikacjach webowych i backendach, szczególnie tam, gdzie system pobiera zdalne zasoby na podstawie danych dostarczonych przez użytkownika. Typowe zabezpieczenia obejmują blokowanie adresów prywatnych, loopback, link-local oraz endpointów metadanych chmurowych.
W praktyce samo sprawdzenie domeny lub pojedynczego wyniku DNS nie zawsze jest wystarczające. W przypadku flyto_core problem polegał na rozdzieleniu etapu weryfikacji od etapu faktycznego zestawienia połączenia. To klasyczny przykład warunków zbliżonych do błędu TOCTOU, gdzie wynik kontroli nie odpowiada temu, co zostaje wykorzystane później przez klienta sieciowego.
Analiza techniczna
Istota podatności sprowadza się do dwóch niezależnych operacji. Najpierw aplikacja rozwiązuje nazwę hosta i ocenia, czy uzyskany adres IP należy do dozwolonej przestrzeni. Następnie klient HTTP lub inny komponent sieciowy inicjuje połączenie i ponownie wykonuje rozpoznanie DNS.
Jeżeli atakujący kontroluje odpowiedzi DNS dla używanej domeny, może sprawić, że pierwsze zapytanie zwróci publiczny, pozornie bezpieczny adres IP. Po przejściu walidacji kolejne zapytanie może już wskazać adres prywatny, loopback albo inny host wewnętrzny. W efekcie zabezpieczenie akceptuje URL, ale rzeczywiste połączenie trafia do celu, który miał być niedostępny.
Udostępniony proof of concept pokazuje bezpieczny scenariusz testowy z lokalnym serwisem nasłuchującym na interfejsie loopback. W demonstracji pierwsze rozpoznanie DNS przechodzi kontrolę bezpieczeństwa, natomiast drugie kieruje połączenie na 127.0.0.1. To potwierdza brak pinningu IP, czyli wymuszenia użycia dokładnie tego samego adresu, który został wcześniej uznany za dozwolony.
Z perspektywy architektury bezpieczeństwa taki błąd jest szczególnie niebezpieczny w funkcjach obsługujących webhooki, import zdalnych danych, integracje HTTP lub pobieranie plików z adresów podawanych przez użytkownika. W tych scenariuszach SSRF może stać się narzędziem do obchodzenia segmentacji sieci i docierania do usług niewystawionych do Internetu.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności jest możliwość wykonywania żądań do zasobów dostępnych wyłącznie z perspektywy serwera aplikacyjnego. W zależności od architektury środowiska może to oznaczać zarówno wyciek informacji, jak i przygotowanie gruntu pod dalszą eskalację.
- skanowanie portów i wykrywanie usług w sieci wewnętrznej,
- odpytywanie lokalnych paneli administracyjnych,
- dostęp do usług działających na localhost,
- próby pobierania danych z endpointów metadanych chmurowych,
- kontakt z wewnętrznymi API, brokerami wiadomości lub bazami danych.
Poziom ryzyka zależy od tego, jakie uprawnienia sieciowe posiada aplikacja oraz jakie systemy są osiągalne z jej segmentu. W środowiskach kontenerowych i mikroserwisowych skutki bywają poważniejsze, ponieważ pojedyncza usługa często ma dostęp do wielu innych komponentów backendu. Jeśli podatny moduł działa w zaufanej strefie, SSRF może stać się punktem wejścia do dalszego ruchu bocznego.
Rekomendacje
Najważniejszym krokiem jest aktualizacja flyto_core do wersji 2.26.8 lub nowszej. Sama poprawka nie powinna jednak zamykać tematu, ponieważ skuteczna obrona przed SSRF wymaga połączenia zabezpieczeń aplikacyjnych, sieciowych i operacyjnych.
- stosować pinning zweryfikowanego adresu IP między walidacją a połączeniem,
- blokować zakresy prywatne, loopback, link-local i adresy specjalne także na etapie finalnego połączenia,
- ograniczyć automatyczne podążanie za przekierowaniami dla nieufnych URL,
- wdrożyć listę dozwolonych hostów lub domen zamiast samej listy blokad,
- analizować rekordy A i AAAA oraz przypadki wielokrotnego rozwiązywania tej samej nazwy,
- monitorować połączenia wychodzące do adresów wewnętrznych i nietypowych segmentów,
- segmentować sieć, aby aplikacje nie miały zbędnego dostępu do systemów administracyjnych i metadanych chmurowych.
Zespoły bezpieczeństwa powinny też przetestować wszystkie funkcje przyjmujące zewnętrzne URL pod kątem DNS rebinding, przekierowań, niestandardowych reprezentacji adresów IP i różnic w parserach URL. To ważne, ponieważ wiele pozornie poprawnych filtrów można obejść właśnie na styku walidacji, DNS i logiki klienta HTTP.
Podsumowanie
Przypadek flyto_core do wersji 2.26.7 pokazuje, że walidacja SSRF oparta wyłącznie na pojedynczym wyniku DNS nie zapewnia pełnej ochrony. Rozdzielenie etapu sprawdzania od etapu wykorzystania adresu tworzy warunki do skutecznego ataku DNS rebinding.
Dla organizacji korzystających z mechanizmów pobierania zdalnych zasobów jest to wyraźny sygnał, że zabezpieczenia muszą obejmować nie tylko analizę wejścia, ale również twarde ograniczenia na poziomie klienta połączeń i polityki sieciowej. W przeciwnym razie nawet poprawnie wyglądająca kontrola może zostać ominięta w praktyce.
Źródła
- Exploit Database – flyto_core 2.26.7 – Server-Side Request Forgery: https://www.exploit-db.com/exploits/52651
- GitHub Advisory / write-up – GHSA-6pm8-6f34-9v3g flyto-core: https://github.com/Pig-Tail/security-research/tree/master/GHSA-6pm8-6f34-9v3g-flyto-core
- GitHub – flyto-core repository: https://github.com/flytohub/flyto-core