phar:// czyli zło w PHP, które czai się już 10 lat. Pierwsze exploity…

28 lutego 2019, 11:37 | W biegu | komentarzy 6
Tagi: ,
: oglądaj sekurakowe live-streamy o bezpieczeństwie IT.

Temat problemów bezpieczeństwa formatu plików phar, został uznany tutaj za jeden z 10 najbardziej innowacyjnych hacków 2018 roku.

W czym problem? Sam dostęp do pliku złośliwego phar, np. w ten sposób: file_get_contents('phar:///tmp/phartest.jpg/'); powoduje wykonanie złośliwego kodu po stronie odczytującej.
Dlaczego? W pliku phar, można umieścić zawartość zserializowaną, która przy odczycie jest automatycznie deserializowana. Takie zachowanie często prowadzi właśnie do wykonania kodu w OS.
Co więcej, plik phar może mieć dowolne rozszerzenie (nawet .jpg .txt) i co więcej można spokojnie tworzyć poligloty (pliki które są prawidłowymi .jpeg-ami i phar-ami). Obsługa formatu phar jest domyślnie włączona w PHP (pierwszy raz phar pojawia się w PHP 5.3.0 – 2009 rok!).

Idealnym kandydatem do wykorzystania problemu wydaje się być podatność XXE (gdzie kontrolujemy jakim protokołem odczytamy plik – może być to phar://). Akcja na diagramie poniżej:

SSRF phar

Pierwsze skowronki tutaj czy tutaj.

–ms

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. asdasd

    I dlaczego jest to bardziej niebezpieczne od np.
    include(unserialize(’/tmp/phartest.jpg/'));
    ?
    Sorry ale problem z wykonaniem kodu podczas deserializacji to zupełnie inny problem.

    Odpowiedz
    • z prostego powodu: żeby wykorzystać podatność via phar, w ogóle nie musisz robić żadnego unserialize()
      samo odczytanie phar zwykłą funkcją php-ową powoduje automatyczną/cichą deserializację, o czym prawie nikt nie wiedział…

      Odpowiedz
      • Archiwa PHAR mają charakter wykonywalnych aplikacji lub bibliotek wykonywalnego kodu. To nie jest ukryte w postaci drobnego druku na 30-tej stronie manuala: to jest w pierwszym zdaniu pierwszej strony. Powinny być traktowane dokładnie tak samo, jak skrypty shella czy binarki. To nie gołe unserialize, po którym faktycznie możnaby się nie spodziewać, że wykona jakiś kod. PHAR w swojej podstawowej funkcji jest związany z odpalaniem/dołączaniem programów.

        Niewąpltiwie jest to nowo odkryty wektor ataków. Ale to są bugi w oprogramowaniu, które dopuszcza do użycia dowolnego URL-a w kontekście, gdzie nie powinno do tego dojść. Żadne czające się zło czy bug w PHP. Równorzędnym twierdzeniem byłoby, że zło czai się w przeglądarkach z obsługą JavaScriptu, bo istnieją aplikacje, które pozwalają zrobić XSS.

        Odpowiedz
        • „Archiwa PHAR mają charakter wykonywalnych aplikacji lub bibliotek wykonywalnego kodu. To nie jest ukryte w postaci drobnego druku na 30-tej stronie manuala: to jest w pierwszym zdaniu pierwszej strony. ”

          Podrzucisz to pierwsze zdanie pierwszej strony manuala? I nie chodzi o coś takiego: include 'phar:///path/to/myphar.phar/file.php';

          tylko o funkcje typu file_exists(’sciezka_do_pliku_phar').

          Jak znasz jakiś inny format, który daje automatyczne wykonanie kodu zaszytego w tym pliku przez odpalenie funkcji typu file_exists() – to daj znać :) Staniesz się sławny (patrz ostatni link w tym komentarzu).

          Jeszcze inne obrazowe porównanie – to tak jak byś dostał plik exe w załączniku w zipie e-mailem. I oczywiście ten plik jest wykonywany, ale przez samo pokazanie Ci tego pliku
          program pocztowy tego przecież nie wykonuje. W przypadku phar jest inaczej…

          Nie bez powodu temat znalazł się na liście najbardziej innowacyjnych researchów z webappsec (2018 rok, 6. pozycja), mających potencjał na kolejne lata:
          https://portswigger.net/blog/top-10-web-hacking-techniques-of-2018

          Odpowiedz
          • > Podrzucisz to pierwsze zdanie pierwszej strony manuala?

            Drugi link w tym artykule, pierwsze zdanie: „The phar extension provides a way to put entire PHP applications into a single file called a „phar” […]”.

            I taki właśnie obraz tej technologii jest utrzymany w całej dokumentacji do PHAR-ów. Zatem nie wyobrażam sobie, by komuś programującemu w PHP i pracującemu z PHAR-ami mogło się wydawać, że może bezpiecznie dopuścić URL w układzie phar:// podawany z niezaufanego źródła.

            Rzeczywiście można dyskutować, czy po pewnych wybranych operacjach — jak przytoczone file_exists — można się spodziewać wykonania kodu. Jednak do tych szczególnych przypadków dochodzimy od strony „uruchamiamy program” (w granicy: istnieją operacje, które mogą niczego nie uruchamiać), a nie — jak np. w przypadku wyświetlenia obrazka — „nie wykonujemy niczego” (w granicy: istnieją operacje, które mogą coś wykonać). Widać różnicę, o której mówię?

            Gdybym dostał binarkę w mailu, to nie spodziewam się jej uruchomienia przez to, że odczytuję maila. I tutaj umieszczenie samego PHAR na serwerze również nie pociąga za sobą negatywnych skutków. Szkodę wyrządza dopiero operacja, którą lepiej zobrazowałoby wywołanie ldd na tej binarce z maila.

            Bez obietnicy sławy mogę podpowiedzieć, że w PHP można definiować własne stream wrappery, więc sama idea wykonania kodu z file_exists to nie byłoby z mojej strony żadne osiągnięcie. Lekko przerysowując sytuację w celu zobrazowania sytuacji: jeśli potrzeba przykładu innych URLi, które mogą *gdzieś* (nie w PHP) wykonać kod: „javascript:alert(’foo')”. Jeśli chodzi o rzeczy wbudowane w PHP: „http://127.0.0.1:/executeSomethingBlehBleh”. O co mi chodzi? O zauważenie, że bug leży w aplikacjach, które dopuściły użycie dowolnego adresu przez niezaufane źródło, a nie w samym schemacie phar://.

            Innowacyjności klasy exloitów nie odrzucam. Faktycznie są ładne.

          • No więc właśnie: „The phar extension provides a way to put entire PHP applications into a single file called a „phar” […]”.

            Patrz wyżej, to tak jak masz plik exe – oczywiście jest on wykonywalny. Ale magicznie się nie wykona dopóki go nie klikniesz. W phar jest inaczej (można powiedzieć, że samo zobaczenie że exe istnieje na listingu plików już go wykonuje (!)) i o tym jest tekst.

            Przeczytaj proszę jeszcze raz tekst – tu nie chodzi o to że do phara możesz wpakować pliki PHP – bo to jest normalne i powiedzmy bezpieczne.

            Hint: http://php.net/manual/en/phar.fileformat.manifestfile.php (pierwsza tabela, ostatni wiersz)

            „Bez obietnicy sławy mogę podpowiedzieć, że w PHP można definiować własne stream wrappery”.

            W PHP to można definiować wszystko, to jasne. Ale chodzi o to co jest w *domyślnej* konfiguracji, bez żadnego dodatkowego „definiowania” i znowu wracamy do istoty tekstu u nas.

            PS
            Generalnie naprawdę nie mamy ambicji żeby Cię przekonywać, że coś z punktu widzenia security jest istotne :-) Kto chce skorzystać – skorzysta, oby tylko nie w niecnych celach.

Odpowiedz