webshell

Webshell to skrypt umieszczony na publicznie dostępnym serwerze WWW, który daje atakującemu dostęp do tego serwera i służy mu jako brama dalej, do sieci ^[1]. MITRE ATT&CK opisuje go jako sposób na utrwalenie dostępu, czyli tylną furtkę (backdoor) w serwerze WWW ^[1]. CERT Polska wskazuje, że nawet prosty webshell umożliwia zdalne wykonywanie komend na serwerze ^[2]. Na stronach WordPress jest to najczęściej plik PHP dopisany do katalogu wtyczki, motywu albo przesłanych plików.

Jak działa

Webshell to zwykły plik, który serwer WWW uruchamia jak każdy inny skrypt strony. Atakujący wysyła do niego żądanie HTTP z poleceniem w parametrze, a skrypt przekazuje je do systemu i odsyła wynik. Sekurak zwraca uwagę, że webshelle zwykle korzystają z funkcji danej technologii do wykonywania poleceń systemowych ^[3]. Oprócz skryptu po stronie serwera webshell może mieć program kliencki do komunikacji z nim; MITRE podaje przykład klienta China Chopper ^[1].

Sam webshell nie jest włamaniem, tylko jego skutkiem. Najpierw musi zadziałać inny błąd: wgranie dowolnego pliku (arbitrary file upload), zdalne wykonanie kodu (RCE) albo przejęcie hasła do panelu lub serwera. Słabość CWE-434, czyli nieograniczone wgrywanie plików niebezpiecznego typu, zajęła 10. miejsce w zestawieniu CWE Top 25 za 2024 rok ^[7]. Typowy przebieg pokazuje schemat poniżej.

RYS. 1Od podatności do webshella

Najprostszy webshell ma jedną linię kodu: przekazuje wartość parametru żądania do funkcji, która wykonuje polecenie systemowe. Przykład takiego kodu CERT Polska zamieszcza w swojej ścieżce postępowania ^[2]. Ten artykuł go nie powtarza, bo programy antywirusowe słusznie traktują taki plik jako złośliwy.

Odmiany

Webshelle różnią się rozmiarem i sposobem ukrycia. Sekurak opisuje gotowe narzędzia o różnym stopniu zaawansowania oraz techniki, które omijają wykrywanie po nazwach funkcji ^[3].

Zaciemnianie kodu ma utrudnić przegląd pliku. Sekurak podaje też przykład operatora wykonania PHP (odwrotnych apostrofów), który uruchamia polecenie bez użycia funkcji system czy exec ^[3].

W WordPressie

WordPress jest napisany w PHP, więc każdy plik .php, do którego serwer WWW ma dostęp, może zostać wykonany. Źródłem webshella jest najczęściej podatność we wtyczce albo w motywie, która pozwala zapisać plik na dysku. Drugą drogą jest edytor plików motywów i wtyczek w panelu: kto przejmie konto administratora, może dopisać kod do istniejącego pliku motywu. Dokumentacja WordPressa podaje, że stała DISALLOW_FILE_EDIT w wp-config.php działa jak odebranie wszystkim użytkownikom uprawnień edit_themes, edit_plugins i edit_files ^[5].

CERT Polska zwraca uwagę na niestandardowe żądania POST do plików w katalogach, w których nie powinno być plików wykonywalnych, na przykład /images/ albo /uploads/; mogą one świadczyć o obecności webshella ^[2]. Z tego powodu stosuje się blokadę wykonywania PHP w katalogu uploads. CERT Polska pisze wprost, że ograniczenie katalogów z uprawnieniem wykonywania skryptów PHP ogranicza możliwość wykorzystania webshella ^[2].

Na hostingu współdzielonym znaczenie mają też uprawnienia plików. Dokumentacja WordPressa zaleca, by pliki należały do konta użytkownika, a zapis przez serwer WWW był możliwy tylko tam, gdzie WordPress go potrzebuje ^[5].

Zagrożenia i skutki

Webshell daje atakującemu trwały dostęp, który przetrwa zmianę hasła do panelu. Z jego pomocą można czytać wp-config.php z hasłem do bazy, zakładać konta, dopisywać SEO spam i przekierowania albo wgrywać kolejne narzędzia. MITRE opisuje webshell jako bramę do sieci, co otwiera drogę do lateral movement, czyli przemieszczania się na inne systemy ^[1].

• Kradzież danych z bazy i plików konfiguracyjnych.
• Dalsze infekcje: dopisany kod w innych plikach strony, nowe tylne furtki.
• Wykorzystanie serwera do ataków na innych, np. wysyłki spamu.

Jak się bronić

Podstawą jest usunięcie przyczyny: aktualizacja wtyczek, motywów i rdzenia. CERT Polska zaleca utrzymywanie aktualnych wersji CMS, jego wtyczek, motywów i oprogramowania serwera ^[2]. Dokumentacja WordPressa radzi usuwać nieużywane wtyczki ^[5].

MITRE wymienia jako środki zaradcze zasadę najmniejszych uprawnień dla kont mogących modyfikować katalogi WWW oraz wyłączanie niebezpiecznych funkcji skryptowych ^[1]. W PHP służy do tego dyrektywa disable_functions, ale podręcznik PHP ostrzega, że można ją obejść i nie jest wystarczającym zabezpieczeniem na hostingu współdzielonym ^[6]. Dyrektywa open_basedir ogranicza pliki dostępne dla PHP do wskazanego drzewa katalogów ^[6].

Wykrywanie opiera się na kilku warstwach:

• Monitorowanie integralności plików i porównanie z czystą wersją aplikacji, np. narzędziem diff; Sekurak wymienia AIDE, Tripwire i auditd ^[3].
• Skaner złośliwego oprogramowania (malware scanner). W teście Sekuraka ClamAV wykrył 113 z 237 webshelli ^[3], więc skaner sam nie wystarczy.
• Analiza logów: MITRE zaleca obserwować nowe pliki w katalogach WWW i procesy powłoki uruchamiane przez serwer WWW ^[1].

Znaleziony webshell to wskaźnik kompromitacji (IoC), a nie koniec sprawy. Czyszczenie przejętej strony wymaga ustalenia wektora ataku. CERT Polska zaleca po incydencie zmianę wszystkich haseł i kluczy, do których atakujący mógł mieć dostęp ^[2], a przywrócenie z kopii zapasowej rozważać wtedy, gdy wektor i czas infekcji są jednoznacznie ustalone ^[2].

Historia i przykłady

Webshelle instalowano na serwerach Microsoft Exchange podatnych na lukę ProxyLogon (CVE CVE-2021-26855) ^[4]. W artykule z 14 kwietnia 2021 roku Sekurak opisał operację FBI, która za zgodą sądu usunęła te webshelle, wydając przez nie polecenie skasowania samego pliku webshella ^[4]. Operacja nie łatała podatności; aktualizacja serwerów nadal była konieczna ^[4].