CVE-2025-47812 w Wing FTP Server: RCE jako root lub SYSTEM

CVE-2025-47812 to krytyczna podatność Wing FTP Server umożliwiająca zdalne wykonanie kodu z uprawnieniami usługi — domyślnie root w Linuksie lub SYSTEM w Windows. Luka ma CVSS 10.0, dotyczy wersji wcześniejszych niż 7.4.4, może zostać wykorzystana również przez włączone konto anonymous, a CISA umieściła ją w katalogu Known Exploited Vulnerabilities po potwierdzeniu rzeczywistych ataków.

Najważniejsze działanie: zaktualizuj Wing FTP Server do 7.4.4 lub nowszego wspieranego wydania, ogranicz interfejsy HTTP/HTTPS i nie zakładaj, że wyłączenie zwykłych kont rozwiązuje problem. Dla wcześniej osiągalnych serwerów wykonaj analizę session files, procesów potomnych i ruchu wychodzącego.

Potwierdzone informacje

Parametr	Wartość
Produkt	Wing FTP Server
Podatne wersje	wszystkie przed 7.4.4
Wersja naprawiona	7.4.4 i późniejsze
CVSS	10.0 — krytyczna
Przyczyna	nieprawidłowa obsługa bajtu NULL w nazwie użytkownika
Dostęp	przez webowy interfejs użytkownika lub administratora; możliwe konto anonymous
Skutek	wstrzyknięcie Lua i wykonanie poleceń jako konto usługi
CISA KEV	tak, dodano 14 lipca 2025 r.
Aktywne wykorzystanie	tak, obserwowane od 1 lipca 2025 r.

Zakres i ocenę potwierdzają rekord CVE oraz NVD. Według Huntress próby wykorzystania pojawiły się dzień po publicznym ujawnieniu szczegółów.

Jak bajt NULL prowadzi do RCE

Wing FTP Server łączy komponenty napisane w różnych technologiach. Nazwa użytkownika trafiała przez kod natywny i logikę Lua, które inaczej interpretowały znak końca ciągu \0. Jedna warstwa mogła potraktować tekst przed bajtem NULL jako nazwę konta, podczas gdy dalsza część kontrolowanego wejścia pozostawała dostępna dla mechanizmu zapisującego dane sesji.

W wyniku rozbieżności napastnik mógł wstrzyknąć kod Lua do pliku sesji użytkownika. Kiedy aplikacja później wczytywała ten plik jako część obsługi uwierzytelnionej funkcji, zapisany kod był wykonywany. Jeżeli dozwolone było logowanie anonymous, nie trzeba było znać danych zwykłego konta.

Mechanizm łączy trzy niebezpieczne właściwości:

niespójną walidację na granicy C++ i Lua;
zapisywanie kontrolowanej treści w wykonywalnym formacie sesji;
uruchamianie usługi z bardzo wysokimi uprawnieniami.

To ostatnie wyjaśnia pełny wpływ. RCE w usłudze plikowej działającej jako root lub SYSTEM zapewnia dostęp nie tylko do udostępnianych plików, ale potencjalnie do całego hosta i poświadczeń używanych przez automatyzacje MFT.

Publiczny PoC i odpowiedzialna walidacja

Oryginalny badacz opublikował szczegółową analizę „What the NULL?! Pre-Auth Wing FTP Server RCE”, zawierającą techniczny dowód koncepcji. Materiał ma wartość dla obrony, ale nie powinien być odtwarzany na produkcji: zapisuje kontrolowaną treść sesji i może doprowadzić do wykonania poleceń.

Bezpieczna walidacja obejmuje:

sprawdzenie wersji w panelu, plikach instalacyjnych i inwentarzu pakietów;
identyfikację opublikowanych portów HTTP/HTTPS, nie tylko FTP/SFTP;
ustalenie, czy dostęp anonymous był włączony w dowolnym momencie ekspozycji;
kopię forensic katalogu plików sesji przed czyszczeniem lub aktualizacją;
test poprawionej wersji w laboratorium z nieszkodliwym markerem;
retest z perspektywy Internetu i sieci wewnętrznej.

Nie uruchamiaj przypadkowego repozytorium PoC na stacji analityka. Kod exploitów bywa modyfikowany tak, by atakować osobę go uruchamiającą.

Patch i ograniczenia tymczasowe

Pełną naprawą jest Wing FTP Server 7.4.4 lub nowszy. Aktualizacja powinna objąć każdą instancję, w tym zapasowe węzły, środowiska DR oraz serwery testowe z kopiami danych. Po instalacji zweryfikuj numer aktywnego procesu i wykonaj kontrolowany restart.

Do czasu aktualizacji:

zablokuj webowe interfejsy użytkownika i administratora na brzegu;
dopuść panel zarządzający wyłącznie z dedykowanej sieci lub jump hosta;
wyłącz anonymous access, jeżeli nie jest bezwzględnie potrzebny;
uruchom usługę z ograniczonym kontem i minimalnym dostępem do systemu plików;
ogranicz egress, aby utrudnić pobieranie narzędzi oraz komunikację C2;
wykonaj kopię dowodową przed usuwaniem session files.

Wyłączenie anonymous nie usuwa podatności dla innych dostępnych kont. Segmentacja i least privilege ograniczają ryzyko, ale nie zastępują poprawionej wersji.

Co wiadomo o aktywnym wykorzystaniu

Huntress potwierdził próby wykorzystania CVE-2025-47812 od 1 lipca 2025 r. W obserwowanym przypadku napastnicy tworzyli złośliwe pliki sesji i próbowali uruchamiać narzędzia systemowe w celu pobrania dalszych komponentów. Aktywność nie musi być identyczna w każdym incydencie, dlatego pojedynczy hash lub nazwa procesu nie wystarcza jako detekcja.

CISA dodała CVE do katalogu KEV 14 lipca 2025 r. To sygnał, że podatne serwery powinny być traktowane jako pilny przypadek incident response, a nie zwykłe zadanie utrzymaniowe.

Hunting: logi i artefakty

Najbardziej wartościowe dane obejmują:

pliki .lua sesji o nazwach składających się z długich ciągów szesnastkowych;
nietypową treść sesji, odwołania do funkcji systemowych i poleceń;
procesy potomne wingftp.exe albo procesu Wing FTP w Linuksie;
użycie narzędzi pobierających, interpreterów powłoki i narzędzi administracyjnych;
nowe konta lokalne, usługi, scheduled tasks, cron i klucze SSH;
połączenia wychodzące do nowych adresów po żądaniach do interfejsu webowego;
logowania anonymous i nietypowe wartości nazw użytkownika;
modyfikacje plików konfiguracyjnych, certyfikatów i katalogów udostępnionych.

W przypadku potwierdzonego kodu Lua odizoluj serwer, nie kasuj pliku przed zabezpieczeniem kopii, obróć poświadczenia MFT i sprawdź partnerów, do których system miał dostęp. Reinstalacja produktu bez analizy może pozostawić persistence na poziomie systemu operacyjnego.

Walidacja powierzchni ataku bez eksploatacji

Ocena ekspozycji powinna odpowiedzieć na cztery pytania: czy istnieje podatna instancja, czy osiągalny jest interfejs webowy, czy napastnik mógł uzyskać kontekst sesji i jak długo trwało takie okno. Nie trzeba wysyłać ciągu wykorzystującego bajt NULL, aby potwierdzić pilną potrzebę działania.

Zacznij od inwentarza opartego na kilku niezależnych źródłach. CMDB może nie zawierać węzła DR, sklonowanej maszyny testowej albo instalacji uruchomionej przez zespół biznesowy. Porównaj listę pakietów i usług systemowych, rekordy DNS, konfigurację load balancerów, reguły NAT/WAF, certyfikaty TLS oraz obserwacje z zewnętrznego attack surface management. Nazwa produktu w nagłówku HTTP może pomóc, ale nie traktuj jej jako jedynego dowodu wersji.

Następnie odtwórz historyczną osiągalność. Aktualna reguła zapory nie dowodzi, że panel był prywatny 1 lipca 2025 r. Sprawdź historię infrastruktury jako kod, logi zmian security groups, konfiguracje reverse proxy, archiwalne skany i logi żądań. Oddziel porty transferowe od webowego portalu użytkownika i panelu administracyjnego: fakt, że SFTP musi być publiczny, nie uzasadnia publicznego HTTP/HTTPS.

Dla każdej instancji zapisz wersję binarną aktywnego procesu, lokalizację katalogu danych, konto usługi, włączone protokoły, status anonymous, dostępne katalogi i połączenia do systemów wewnętrznych. Taka karta pozwala ustalić blast radius bez uruchamiania PoC. Jeśli wersja jest podatna, web UI był osiągalny i brak pełnej telemetrii z okresu ekspozycji, klasyfikuj przypadek jako „możliwy incydent”, a nie „brak dowodów włamania”.

Triage: zwykły patch czy pełna reakcja na incydent?

W pierwszej godzinie warto przypisać instancję do jednej z czterech ścieżek:

Wersja poprawiona, nigdy nieeksponowana. Zweryfikuj pochodzenie pakietu, retestuj routing i zamknij zadanie po przeglądzie konfiguracji.
Wersja podatna, lecz wiarygodnie odizolowana. Aktualizuj pilnie, zachowaj podstawowe logi i potwierdź, że żaden proxy, VPN partnera ani host w mniej zaufanej strefie nie miał ścieżki.
Wersja podatna i osiągalna, bez IoC. Zabezpiecz dowody przed restartem, zaktualizuj, rozpocznij threat hunting i rotację sekretów adekwatną do dostępu serwera.
Artefakt Lua, proces potomny albo nieautoryzowana zmiana. Izoluj host, uruchom pełny incident response i zakładaj kompromitację systemu operacyjnego.

Brak pojedynczego znanego procesu lub hasha nie obniża automatycznie ścieżki 3 do 2. Huntress opisał konkretną aktywność, ale inny aktor może użyć innych narzędzi albo ograniczyć się do kradzieży danych. Decyzję opieramy na łącznym materiale: wersja, osiągalność, ciągłość logów, sesje, procesy, pliki i egress.

W triage zachowaj kolejność operacji. Izolacja i kopia dowodowa mogą być ważniejsze niż natychmiastowe kasowanie pliku. Jeżeli biznes nie może wyłączyć transferów, skieruj ruch do czystego węzła po sprawdzeniu konfiguracji i odseparuj podejrzaną maszynę. Procedura powinna być częścią planu obrony przed ransomware, ponieważ systemy MFT są naturalnym punktem stagingu danych i dalszego ruchu.

Telemetria: od żądania HTTP do procesu systemowego

Najbardziej wiarygodna detekcja koreluje co najmniej trzy warstwy. Reverse proxy lub WAF pokazuje źródło, czas i żądanie do interfejsu webowego. Log Wing FTP wiąże żądanie z użytkownikiem, sesją i operacją. EDR lub auditd/Sysmon pokazuje zapis pliku, jego późniejsze otwarcie oraz proces potomny usługi.

Zbuduj oś czasu wokół każdego nietypowego logowania anonymous albo błędu parsowania nazwy. Sprawdź identyfikator sesji, powiązany plik .lua, czas modyfikacji i proces, który go wczytał. Następnie przejdź do zdarzeń tworzenia procesu i połączeń sieciowych. Różnica kilku sekund między żądaniem, zmianą sesji i egress jest silniejszym sygnałem niż sam egzotyczny user-agent.

Warto wdrożyć File Integrity Monitoring dla katalogów aplikacji, konfiguracji i sesji, ale baseline musi uwzględniać legalne operacje. Alarmuj na wykonywalną treść, nieoczekiwane funkcje systemowe, zmianę właściciela oraz plik sesji utworzony przez inny proces niż Wing FTP. Na Windows monitoruj relację parent–child dla wingftp.exe; w Linuksie odpowiednik procesu oraz wywołania powłoki, narzędzi transferowych i zmian mechanizmów startowych.

Logi powinny trafiać poza host w czasie zbliżonym do rzeczywistego. Lokalny plik może zostać zmieniony po RCE. Retencja musi obejmować co najmniej cały okres możliwej ekspozycji i cykl transferów partnerów. Ochrona kont analityków oraz zatwierdzanie zmian reguł SIEM powinny być objęte PAM i dostępem just-in-time.

Hardening po aktualizacji: ogranicz skutki kolejnej luki

Aktualizacja usuwa znany błąd, ale nie zmienia faktu, że MFT jest usługą wysokiego ryzyka. Rozdziel publiczną płaszczyznę transferu, portal użytkownika i panel administracyjny na poziomie routingu, zapory i tożsamości. Panel powinien być osiągalny wyłącznie z dedykowanego segmentu albo przez bramę administracyjną z MFA. Zasady Zero Trust wymagają weryfikacji konkretnej tożsamości i urządzenia, nie zaufania do całego VPN.

Konto procesu nie powinno być rootem ani SYSTEM, jeśli wspierana architektura pozwala ograniczyć przywileje. Nadaj dostęp tylko do wymaganych katalogów i rozważ osobne wolumeny dla partnerów. Oddziel credentiale per workflow, usuń możliwość interaktywnego logowania, kontroluj zapis poza katalogami roboczymi i zabroń wykonywania z obszarów uploadu za pomocą mechanizmów systemowych.

Egress powinien dopuszczać tylko znane usługi: DNS, czas, repozytorium aktualizacji lub konkretne endpointy partnerów. Ogólne wyjście do Internetu ułatwia zarówno pobieranie kolejnego etapu, jak i eksfiltrację. Segmentacja ogranicza również połączenia do AD, backupu i zarządzania; szczegółowo takie zależności warto objąć pentestem chmury i infrastruktury hybrydowej.

Weryfikacja naprawy i bezpieczny retest

Retest zaczyna się od potwierdzenia, że działa nowy proces, a nie tylko że instalator skopiował pliki. Zapisz wersję widoczną w panelu, wersję pliku/binarium, czas startu procesu i wynik kontroli każdego węzła klastra. Sprawdź także obraz DR oraz automatyzację, która mogłaby przywrócić podatny snapshot.

Następnie z zewnątrz potwierdź, że publiczne są wyłącznie wymagane usługi. Panel administracyjny powinien odpowiadać odmową już na warstwie sieciowej lub bramie dostępu. Przetestuj legalny transfer kontem testowym, anonymous zgodnie z polityką, logowanie administratora i alerty po nieszkodliwej, uzgodnionej anomalii.

Nie odtwarzaj publicznego łańcucha RCE na produkcji. W izolowanym laboratorium można porównać zachowanie podatnej i poprawionej wersji przy markerze nieuruchamiającym poleceń, monitorując tworzenie sesji. W produkcji wystarczające kryteria zamknięcia to: poprawiona wersja na wszystkich węzłach, brak niezamierzonej ekspozycji, przejrzany okres historyczny, zrotowane sekrety dla podejrzanych hostów, działające alerty oraz podpis właściciela ryzyka.

Drzewo decyzji dla CVE-2025-47812

Czy wykryto Wing FTP Server przed 7.4.4? Jeśli nie, potwierdź wersję aktywnego procesu i przejdź do retestu ekspozycji. Jeśli tak, natychmiast zachowaj logi i planuj aktualizację.
Czy portal HTTP/HTTPS był osiągalny z Internetu lub niezaufanej strefy? Jeśli tak albo historii nie da się odtworzyć, uruchom hunting. Jeśli nie, potwierdź tę tezę z dwóch niezależnych źródeł.
Czy anonymous było włączone? Jeśli tak, zwiększ priorytet, ale odpowiedź „nie” nie zamyka sprawy — dostępne zwykłe konto również może spełnić warunek.
Czy istnieje nietypowy session file, proces potomny, persistence lub egress? Jeśli tak, izoluj i prowadź pełny IR. Jeśli nie, oceń kompletność telemetrii przed stwierdzeniem braku naruszenia.
Czy serwer miał dostęp do sekretów lub partnerów? Jeśli tak, obróć je według priorytetu i zweryfikuj użycie. W razie ekspozycji danych postępuj zgodnie z procedurą reakcji na wyciek.

Ryzyko biznesowe systemów MFT

Serwery transferu plików łączą organizację z klientami, dostawcami i procesami wsadowymi. Przechowują dane o wysokiej wartości oraz poświadczenia do kolejnych systemów. Z tego powodu od lat są atrakcyjnym celem grup wymuszających okup i kradnących dane.

Właściwy program ochrony obejmuje nie tylko patchowanie, ale też osobną strefę sieciową, MFA dla administratorów, kontrolę kont partnerskich, krótką retencję plików, monitoring integralności i sprawdzony plan reakcji na wyciek danych. Zewnętrzny pentest infrastruktury powinien oceniać zarówno usługę MFT, jak i ścieżki dalszego ruchu po przejęciu hosta.