7:59
7/5/2012

Sposób w jaki CGI i PHP komunikują się między sobą umożliwia atakującemu na zdalne uruchomienie kodu na web serwerze. Exploity na tę podatność są już publicznie dostępne. Błąd istniał od 8 lat…

Dziura w PHP i CGI

Podatność wnika z tego, że interpreter PHP nie do końca dokładnie podąża za wytycznymi standardu CGI i czasem parametry URL mogą zostać przekazane do interpretara PHP i zinterpretowane jako argumenty linii poleceń. W internecie dostępne są już exploity, które przy pomocy tej podatności otwierają atakującemu shella na webserwerze…

Warto odnotować, że powyższa dziura dotyczy serwerów z PHP pracujących w trybie CGI, instalacje FastCGI PHP nie są podatne na ten atak.

Czy twój serwer PHP jest dziurawy?

Aby sprawdzić, czy twoja konfiguracja webserwera jest podatna na ten atak dołącz parametr “?-s” do dowolnego URL-a. Jeśli zobaczysz kod źródłowy PHP, jak najszybciej zabezpiecz swój serwer, korzystając z rad poniżej.

Jak zabezpieczyć swój serwer PHP?

Dostępne są także patche do PHP (do wersji 5.3.12 i 5.4.2) ale nie usuwają one w pełni tego błędu. Najlepszą ochroną pozostaje więc odpowiednie ustawienie odpowiednich reguł filtrujących na web serverze — ale uwaga, nie tych z PHP.net, bo one również nie w pełni zabezpieczają nas przed skutkami tej dziury. Najlepiej podążyć za tymi wskazówkami:

RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]

Jeśli samodzielne łatanie Cię przerasta, albo chcesz się upewnić, że twoja webaplikacja nie ma żadnych innych błędów bezpieczeństwa, możesz nas wynająć do wykonania testów bezpieczeństwa.

PS. Warto także zauważyć, że tego typu błędy (de facto mieliśmy przez chwilę do czynienia z 0day’em) należy zgłaszać developerom, a nie pisać o nich publicznie. Odkrywcy błędu tak też postąpili, ale opis podatności wyciekł poprzez bazę błędów PHP i został nagłośniony na serwisie Reddit…


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

50 komentarzy

Dodaj komentarz
  1. Wystarczy wpisać “adres/strona.php?-s” ?

    • tak, tylko strona musi być podatna

    • Żeby sprawdzić czy konfiguracja serwera jest podatna – tak. Żeby wykonać swój kod, nie. Należy skorzystać z “innych parametrów”.

    • Serwer “zwrócił” to samo co bez parametru. Uff. ;-))

  2. Masakra ten PHP …

  3. Dostępny są także -> Dostępne są także

  4. https://www.facebook.com/?-s :D

    • YMMD. :) Facebook wie jak się bawić. :)

    • LOL!

    • W sumie bardzo ciekawy sposób werbowania pracowników d/s bezpieczeństwa :)

    • Oczywiście facebook został przez mnie poinformowany o zaistniałej sytuacji, dlatego już podatność facebooka została zniwelowana, a w dodatku zostajemy teraz przekierowani z https://www.facebook.com/?-s na https://developers.facebook.com/opensource/ ;) Nic nie może wiecznie trwać :D

    • @Com
      Ale ty ciemny jesteś :]
      Było pierwsze trzeba było sprawdzić gdzie przekierowuje link z include_once.
      [no comment…]

    • @qwerty
      Owszem sprawdziłem :P
      Co z tego że było tam w include_once: https://www.facebook.com/careers/, skoro po zastosowaniu ?-s pojawiało się źródło, to znaczyło, że to nie było celowe działanie, bo tak by dali przekierowanie na https://www.facebook.com/careers/, a nie odsłaniali kod źródłowy, a kto wie czy pod innym adresem w domenie facebook, może można by to jednak wykorzystać do niecnych celów, wiec najpierw się zastanów zanim coś głupio skomentujesz kimkolwiek jesteś :P a choćby świadczy o tym, że to nie było zamierzone, fakt, że facebook na to zareagował i dokonał zmian, a tak by to zignorowali.

  5. Warto jednak zauważyć ze wina nie do końca leży po stronie php – Apache jest dziurawy leczwiele innych serwerów nie jak wspomnieli odkrywcy błędu.

  6. Apache zachowuje się zgodnie z RFC CGI. Trudno więc go winć. ;[

  7. PERL <3

    • PHP </3

    • Perl 3<

    • Ruby <3

    • O tak ruby!!! <3 <3 <3

    • PERL! i koniec! :D

    • python, nasm, brainfuck.
      Java 4 ever

    • ( . )v( . ) <3

    • Obawiam się, że Mystiq wygrał.

    • dobre “oczy” to podstawa :)

  8. :(

  9. Tylko i tak większość serwisów nie używa CGI.

  10. a moze lepiej w skrypcie wywlolujacym php-cgi dac tak

    #!/bin/bash
    exec /usr/bin/php-cgi — “$@” -c php.ini

    i bez koniecznosci wstawiania regul w apache-u

    • ale to nie zmienia faktu, że php-cgi jest przestarzałe i powinno się używać fastcgi.

    • tylko wtedy parametry przekazujesz bashowi, co też można wykorzystać

  11. Nie znasz się! RUBY!! <3

    • Sam jesteś ruby. :<

  12. Jak wygląda przykładowa odpowiedź podatnego serwera (po użyciu ?-s) ?

  13. https://niebezpiecznik.pl/-s
    :)

    • lepsze niz facebook :D

  14. Najlepiej to walić Apache’a i zainstalować Lighttpd albo Nginx’a + php-fpm….

    • a ja nie rozumiem dlaczego ktoś odpala PHP jako CGI pod Apache. przecież jest mod_php. natomiast co do php-fpm + nginx/lighttpd to mam z tym trochę doświadczenia i osobiście uważam, że Apache jest lepszy i daje więcej możliwości (chociażby możliwość podpięcia mod_security). oczywiście mówię tu tylko o serwowaniu kontentu dynamicznego.

    • Powstaje WAF dla nginx… opisany po prawej stronie bloga, w *ptr.

    • @Piotr – wiem, czytałem o nim parę miesięcy temu. nie miałem okazji niestety przetestować. natomiast dobrze zauważyłeś – dopiero powstaje. trzeba mieć jaja, żeby taką wersję alpha wrzucić na produkcję ;) druga sprawa to trochę inne założenia niż mod_security. czy lepsze czy gorsze – nie będę oceniać dopóki sam tego nie potestuję.

      tak czy siak mam o nginx+FPM złe zdanie, bo naprawdę trochę w tym siedziałem i mogę kiedyś napisać dłuższy wywód na temat dlaczego wolę Apache+mod_php, może kogoś przekonam, a może ktoś przekona mnie – kto wie ;)).
      a przy okazji – sorry, że tyle OT ;) sam nginx też ma fajne kwiatki i pokrętną logikę – taki fajny przykład tutaj – jeśli ktoś nie zna tego to warto przeczytać :) http://wiki.nginx.org/IfIsEvil

  15. Blad to ja widze raczej w adminie ktory takie php stawia. Jak uzywa sie $* czy $@ bez double quotes to sie ma potem takie kwiatki, ze ? sie gubi i zostaje -s.

    Robicie troche widly z igly. To tak, jakbyscie sie teraz rozprawiali nad tym, ze jest blad w nginksie, bo jak sie nie sprawdzi urla przed przekazaniem do php, to mozna wykonac kod php np. z obrazka (say jakis awatar uploadowany na forum).

    Szalu nie ma panie Piotrze z tym contentem ostatnio.

    • Aha, czyli mamy nie pisac o takich bledach, bo na pewno nikt, ale to nikt, sie nie zdarzy kto moglby cos takiego popelnic. Podobnie jak nikt juz nie popelnia bledow typu csrf/sqli, prawda? To co, usunac post i napisac do metasploita, zeby sie wstydzili, bo po co udostepniaja takie exploity na — jak to nazywasz — sprawy typu “z igly widly”?

      My staramy sie nie osadzac, co kto ma na serwerach i dlaczego – po prostu informujemy o bledach :)

    • Jak często się zdarzają błędy sqli w “średnich i dużych” firmach?
      Pytam z ciekawości.

    • To nie jest pytanie na które łatwo można odpowiedzieć. Jeśli korzystają z frameworków, rzadko – jeśli mają jakiś stary, rozwijany przez siebie/zewnętrzną firmę kod pisany na zamówienie (i bez frameworka) często. Średnia/Duża firma to często tak naprawdę skupisko n małych firemek (i tworzonego przez nich softu, który ma działać i robić X oraz zarabiać nie mniej niż Y, a bezpieczeństwo to …koszt).

    • @zzz1986@o2.pl : Patrz ataki LulzSec…. niby to tylko male firmy rzadowe, Sony.. w sumie nic waznego.. czy jakies tam nic nie warte strony policji amerykanskiej… lub nie LulzSec, a nasze podworko.. podczas protestow ACTA…:)

  16. no ale w tym bashu to chyba wywolujesz parametry binarki /usr/bin/php-cgi

  17. Jak się jaracie bugami to https://github.com/php/php-src/commit/c58168b79baa8a86f9c3ab66aaf1f6cdd910ee00 no i za chwilę będzie kolejna wersja PHP

  18. Bardzo szybko (bo nie całą dobę) zajeło nim zobaczyłem pierwsze próby ataku w access logu. Niestety (dla tych łobuzów) moja wersja php nie jest na to podatna, a dodatkowo wszyscy którzy psuli dostali po ban(an)ie :)

    • jaki adres? :D

  19. [quote]zzz1986@o2.pl 2012.05.08 09:57 | # |

    Jak często się zdarzają błędy sqli w “średnich i dużych” firmach?
    Pytam z ciekawości.
    [/quote]

    bardzo czesto. zeby bylo smieszniej – ogromna liczba stron .gov jest podatna na sqli…. sady prokuratury MW etc

    • Mam gdzieś liste 70 podatnych stron .gov i 15.edu, mozna znalezc na HF ;]

Odpowiadasz na komentarz Grzegorz

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: