Jak hackerzy wykorzystują popularne ciasteczka do ukrywania backdoorów?

Identyfikacja backdoorów w witrynie nie zawsze jest łatwym zadaniem. Ponieważ podstawową funkcją backdoorów jest ukrywanie się podczas zapewniania nieautoryzowanego dostępu, często są one opracowywane przy użyciu różnych technik, które mogą utrudniać ich wykrycie. Pisaliśmy na przykład o backdoorach w AD w artykule tutaj.

Dzisiaj chcielibyśmy omówić prosty przykład ingerencji w powłokę PHP w celu ukrycia backdoora w aplikacji internetowej. Osoba atakująca może wstrzyknąć do pliku witryny jeden wiersz kodu zawierający mniej niż 130 znaków. Chociaż może wydawać się, że nie jest to dużo, ten krótki ciąg może zostać użyty do załadowania powłok internetowych PHP w witrynie zgodnie z kaprysem atakującego, jednocześnie uniemożliwiając odwiedzającym i administratorom wykrycie złośliwego zachowania.

Autor: Kapitan Hack Data dodania: 14 sty 2021 08:00 4 min czytania

PHP Cookie

Fragment złośliwego kodu, który został wykryty i przechwycony przez analityków SucUri przedstawia się następująco:

Atakujący musi tylko dodać go do dowolnego pliku ładowanego wraz ze stroną internetową – na przykład coś takiego jak wp-load.php lub aktywny plik motywu/wtyczki byłyby idealne dla witryn WordPress.

Działanie złośliwego kodu jest proste. Hacker dostarcza żądanie z dwoma oddzielnymi plikami cookie – woofig i wp_config – które następnie są wykonywane w następujący sposób:

Kod sprawdza przychodzące żądanie pod kątem pliku cookie HTTP o nazwie woofig.
Jeśli istnieje, wartość skrótu MD5 jest generowana na podstawie jego zawartości i porównywana z istniejącą wartością skrótu (w tym przypadku: 393c853c183af6327116dd773b8f9c11). Jeśli skróty są różne, kod nie jest kontynuowany. Przypomina to zwykłe zabezpieczenie hasłem.
Kod sprawdza to samo żądanie HTTP pod kątem drugiego pliku cookie o nazwie wp_config, który zawiera sformatowany kod PHP i używa klauzuli eval do jego wykonania.

Pliki cookie HTTP zwykle muszą mieć mniej niż 4096 bajtów, więc osoba atakująca ma ograniczoną liczbę znaków, których może użyć w swoim kodzie PHP w pliku cookie wp_config. Domyślnie dzienniki dostępu HTTP nie rejestrują danych plików cookie od odwiedzających, ponieważ drastycznie zwiększa to rozmiar logu. Nie wiadomo więc, czego używa atakujący w tym przypadku.

Przykład konstrukcji złośliwego pliku Cookie

Przykładowy plik wp_config może wyglądać następująco:

Używając file_get_contents do pobierania danych z adresu URL, PHP tego pliku cookie wykorzystuje następnie funkcję eval do wykonania dodatkowego kodu PHP z pobranej zawartości.

Ta technika pozwala atakującemu na selektywne ładowanie powłoki internetowej za pośrednictwem dowolnej strony WordPress w witrynie. Atakujący musi tylko dodać dwa pliki cookie woofig i wp_config do swojego żądania, a webshell zostanie załadowany, uruchomiony z pamięci i nie przechowywany w pliku. Jedynym złośliwym oprogramowaniem, które zostało faktycznie dodane do witryny, jest pojedyncza linijka kodu PHP, która przeprowadza warunkowe sprawdzenie woofig plików cookie przed oceną kodu w pliku cookie wp_config.

Poniżej krótkie demo z dodaniem złośliwego kodu do pliku wp-load.php. Oto akcja:

Aby w pełni zrozumieć złośliwe działanie, tłumaczymy poniżej co się dzieje na demonstracji:

Witryna wczytywana jest bez włączonej obsługi plików cookie, co powoduje załadowanie normalnej strony witryny WordPress.
Za pomocą narzędzi przeglądarki dodawane są dwa pliki cookie woofig i wp_config, a strona jest odświeżana.
Ładuje się powłoka internetowa PHP.
Wprowadzane są testowe komendy w celu pokazania złośliwej działalności.
Po zakończeniu autor wyłącza pliki cookie i odświeża stronę.
Witryna powraca do oczekiwanego zachowania i ładuje zwykłą stronę WordPress.

Ponieważ ten krótki fragment złośliwego kodu to backdoor PHP, najlepiej wykryć go za pomocą skanera po stronie serwera webowego, który może zidentyfikować niezgodność w plikach. Możesz także użyć wtyczki WordPress do skanowania w poszukiwaniu zmian wprowadzonych w podstawowych plikach WordPress, które zwykle nie powinny być zmieniane, z wyjątkiem aktualizacji. Skaner ten całkiem dobrze radzi sobie z wykrywaniem nieautoryzowanych zmian w plikach .php.