Co to jest atak RCE (Remote Code Execution) i jak się przed nim bronić?

Atak RCE (Remote Code Execution) to technika hakerska pozwalająca napastnikowi na zdalne uruchomienie dowolnych poleceń w systemie operacyjnym ofiary. Wymaga to najpierw znalezienia odpowiedniej podatności w kodzie aplikacji webowej, serwerze lub usłudze sieciowej, by przemycić tam złośliwy ładunek (payload).

Zarządzamy infrastrukturą IT od lat i widzieliśmy dziesiątki takich przypadków. Włamujący się uzyskuje dostęp do powłoki systemowej z uprawnieniami procesu, który uruchomił podatną aplikację. Przejmuje serwer. Kradnie dane. Uruchamia koparki kryptowalut. Prawda jest zresztą absolutnie taka, że jeśli ktoś wbije ci się przez RCE na produkcję, całą misterną konfigurację infrastruktury szlag trafia w ułamku sekundy.

Pamiętam wdrożenie wewnętrznego systemu dla lokalnej hurtowni na warszawskich Włochach w 2021 roku. Serwer fizyczny stał w małej, dusznej kanciapie. Ktoś z zewnątrz wrzucił prosty skrypt w PHP omijając filtry przesyłania plików, bo deweloper zapomniał zablokować rozszerzenia .php5. Wystarczyło jedno żądanie HTTP. Cała baza klientów wyciekła zanim ktokolwiek zdążył dopić kawę. To u nas w sumie chyba hipoteza z wczoraj, bo pewności do tych konkretnych logów nikt obecnie nie ma, logi rotowały się co 24 godziny. Mimo to, wniosek jest jasny. Zwykła ludzka pomyłka w kodzie kosztuje biznes setki tysięcy złotych.

Jak dokładnie działa atak RCE w praktyce?

Najpierw napastnik skanuje zasoby w poszukiwaniu luk. Szuka starych wersji bibliotek. Testuje formularze wejściowe. Sprawdza parametry w adresach URL. Kiedy znajdzie dziurę, preparuje ładunek. Wysyła go do serwera. Serwer interpretuje ten ciąg znaków nie jako zwykłe dane, ale jako komendę do wykonania.

W zdecydowanej większości przypadków cel to uzyskanie tzw. reverse shella. Atakujący zmusza twój serwer, żeby połączył się z jego maszyną. Omija to zapory sieciowe blokujące ruch przychodzący. Twój serwer sam nawiązuje to połączenie. Banalne. A jednak niszczycielskie.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Narzędzia do automatycznego skanowania sypią fałszywymi alarmami. Programiści je ignorują. I to jest bez mała najgorsza opcja z wszystkich. Zmęczenie alertami powoduje, że prawdziwe zagrożenie przechodzi niepostrzeżenie.

Czym różni się RCE od wstrzykiwania komend (Command Injection)?

Te dwa pojęcia często się mieszają. Nawet inżynierowie z wieloletnim stażem wrzucają je do jednego worka.

• Command Injection: Aplikacja już wykonuje jakieś systemowe polecenie (np. ping) i pozwala użytkownikowi dokleić do niego własne argumenty. Atakujący dopisuje średnik i dorzuca polecenie `rm -rf`. System posłusznie kasuje pliki.
  To zazwyczaj błąd w walidacji wejścia na poziomie funkcji wywołujących powłokę (np. `system()` w PHP). Wynika z lenistwa programistów, którzy zamiast użyć wbudowanych API, wolą oddelegować robotę do systemu operacyjnego z poziomu interpretera.
• Remote Code Execution (RCE): Kategoria o wiele szersza. Wstrzykiwanie komend to podzbiór RCE. Zdalne wykonanie kodu może nastąpić przez deserializację niezaufanych danych. Przez przepełnienie bufora w pamięci. Przez błędy w ewaluacji kodu (`eval()`). Tutaj napastnik często wstrzykuje kod w języku samej aplikacji (Java, Python, Ruby), który dopiero potem daje mu dostęp do systemu.

Jakie są najczęstsze przyczyny powstawania luk RCE w kodzie?

Brak weryfikacji danych wejściowych to główny winowajca. Aplikacja ufa temu, co wysyła użytkownik. Nigdy nie ufaj użytkownikowi. To podstawowa zasada, którą łamie się codziennie.

Często widzę aplikacje napisane w Javie, które używają starych wersji bibliotek do deserializacji. Ktoś wysyła złośliwy obiekt w formacie JSON lub XML. Java próbuje go zrekonstruować w pamięci. W trakcie tego procesu wywoływane są magiczne metody, które uruchamiają złośliwy kod. Tak padł Equifax. Tak padają tysiące firm rocznie.

Kolejna sprawa to funkcje ewaluacyjne. Języki skryptowe mają funkcje zamieniające tekst na wykonywalny kod. Ktoś w zespole wpada na pomysł, żeby użyć `eval()` do parsowania matematycznych równań z kalkulatora na stronie. Ktoś inny wpisuje zamiast cyfr wywołanie systemowe. Mamy RCE. Gwarantowane. Czasem po prostu ROZWALA to całą architekturę, bo proces ma uprawnienia roota.

Mamy też podatności w mechanizmach uploadu plików. Serwis pozwala wgrać awatar. Skrypt sprawdza tylko rozszerzenie na froncie. Napastnik przechwytuje żądanie i zmienia typ MIME. Serwer zapisuje plik `shell.php` w publicznym katalogu. Atakujący wchodzi pod adres `mojastrona.pl/uploads/shell.php` i ma pełną kontrolę.

Co to jest atak RCE (Remote Code Execution) i jak się przed nim bronić na poziomie sieci?

Wiele osób pyta wprost: co to jest atak RCE (Remote Code Execution) i jak się przed nim bronić, skoro kod zawsze będzie miał jakieś błędy? Odpowiedź tkwi w architekturze obronnej i separacji uprawnień.

Zablokuj możliwość wykonywania procesów potomnych przez użytkownika, na którym działa serwer WWW. Twój Nginx czy Apache nie musi mieć uprawnień do uruchamiania basha. Jeśli aplikacja tego nie wymaga, zdejmij te uprawnienia na poziomie systemu operacyjnego. Użyj AppArmor lub SELinux. Wdrożyliśmy to u klienta z branży e-commerce i uratowało im to skórę, gdy wyszła luka zero-day w używanym przez nich CMS-ie.

Izoluj środowiska. Używaj kontenerów Docker z flagą `–read-only`. System plików powinien być tylko do odczytu, poza wyznaczonymi katalogami na pliki tymczasowe. Nawet jeśli atakujący wstrzyknie kod, nie będzie w stanie pobrać dodatkowych narzędzi z sieci ani zapisać trwałego backdoora. Próbował to zrobić u nas jakiś skrypt z rosyjskiego IP. Odbiło się od ściany. Zmieniliśmy te zasady na robocie rok temu i działa to świetnie.

Czy Web Application Firewall (WAF) zatrzyma każdy złośliwy ładunek?

Krótka odpowiedź: nie. WAF to plaster na otwarte złamanie. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku. Ale z doświadczenia wiem, że atakujący potrafią zaciemniać kod (obfuskacja). Zmieniają kodowanie znaków na Base64. Używają znaków Unicode. Dzielą ładunek na mniejsze fragmenty. WAF oparty na sygnaturach tego nie wyłapie.

WAF analizuje ruch z zewnątrz. Jeśli luka RCE ukryta jest głęboko w logice biznesowej, na przykład w asynchronicznym procesowaniu plików PDF generowanych z danych użytkownika, zapora sieciowa nic nie zauważy. Żądanie wejściowe wygląda całkowicie normalnie. Dopiero w tle, na serwerze roboczym, odpala się bomba.

Jak zidentyfikować podatność RCE we własnej aplikacji przed wdrożeniem?

Poleganie wyłącznie na jednym narzędziu to proszenie się o kłopoty. Potrzebujesz warstwowego podejścia do testowania oprogramowania. Zobacz poniższe zestawienie metodologii.

Zamiast kupować drogie skanery, zacznij od prostej rzeczy. Zablokuj programistom możliwość dodawania nowych bibliotek bez przeglądu bezpieczeństwa. Wprowadź w potokach CI/CD narzędzia takie jak Dependabot. To darmowe, a wycina połowę wektorów ataku na start.

Kto najczęściej pada ofiarą zdalnego wykonania kodu?

Firmy, które zapominają o starych systemach. Zostawiają aplikacje w spokoju, bo „działa, to nie ruszaj”. To najgorsza możliwa filozofia w IT. System nie łatany od dwóch lat to tykająca bomba.

Atakują też małe sklepy internetowe na wtyczkach do WordPressa. Ktoś instaluje darmowy plugin do galerii zdjęć z niepewnego źródła. Wtyczka ma wbudowanego backdoora albo lukę w funkcji wgrywania obrazków. Po tygodniu cały serwer rozsyła spam. Osobiście czyściłem kiedyś taki serwer. Trzy dni wycinania złośliwych skryptów zakopanych w rdzennych plikach systemu operacyjnego. Czysty absurd.

Dobrym pomysłem jest wdrożenie ścisłej inwentaryzacji zasobów. Musisz wiedzieć, co masz w sieci. Jeśli nie wiesz, że na porcie 8080 działa stary panel administracyjny od routera, nie zabezpieczysz go. A botnety skanują cały internet 24 godziny na dobę.

Zostaw czytanie. Zaloguj się teraz na swój serwer, sprawdź dostępność niezałatanych pakietów systemowych i zablokuj wychodzący ruch z procesów WWW.

Często Zadawane Pytania (FAQ)

• Czym jest atak RCE?
  RCE (Remote Code Execution) to atak umożliwiający hakerowi zdalne wykonanie dowolnych poleceń w systemie operacyjnym ofiary z poziomu podatnej aplikacji sieciowej.
• Jakie są główne przyczyny podatności RCE?
  Główne przyczyny to brak walidacji danych wejściowych, używanie starych i dziurawych bibliotek zewnętrznych, błędy w deserializacji danych oraz nadużywanie funkcji ewaluacyjnych kodu, takich jak eval().
• Czy zapora WAF chroni przed RCE?
  WAF zatrzymuje wiele znanych ataków opartych na prostych sygnaturach, ale zaawansowani napastnicy potrafią zaciemnić kod i ominąć zaporę, uderzając bezpośrednio w luki logiczne aplikacji.
• Jak zablokować skutki ataku RCE?
  Należy izolować aplikacje w kontenerach z systemem plików tylko do odczytu, stosować zasady najmniejszych uprawnień dla procesów (odcięcie od basha) oraz używać systemów takich jak SELinux.
• Czym RCE różni się od wstrzykiwania SQL?
  SQL Injection pozwala na manipulację bazą danych, podczas gdy RCE daje dostęp do całego systemu operacyjnego serwera, pozwalając na wykonywanie komend na poziomie procesora.
• Jak testować kod pod kątem RCE?
  Należy łączyć skanowanie statyczne (SAST) z analizą komponentów zewnętrznych (SCA) w procesach CI/CD oraz regularnie zlecać manualne testy penetracyjne infrastruktury.

Bibliografia i źródła

1. CERT Polska – https://cert.pl
2. NASK – https://www.nask.pl
3. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
4. Niebezpiecznik – https://niebezpiecznik.pl
5. Zaufana Trzecia Strona – https://zaufanatrzeciastrona.pl
6. OWASP Foundation – https://owasp.org