Exploit dla nginx+fcgi

[atsuki 0]

Oryginalny post: http://www.80sec.com...nx-securit.html

po "ingliszu": http://www.webhostin...475#post6807475

 

a po naszemu, jest możliwość wykonania dowolnego kodu php (jak z innymi backendami?).

 

możliwy model ataku:

1) prowadzimy hosting obrazków/plików, jest możliwość uploadu plików ogólnie;

2) ktoś wgrywa plik, plik to obrazek.jpg (nazwa czy rozszerzenie nie istotne) z kodem php;

3) dowolne wywołanie bezpośrednie pliku http://domain.tld/pl...cosdowlnego.php spowoduje wykonanie spreparowanego pliku;

 

w zasadzie 99,99% konfiguracji jest podatnych, jak nie cale 100%, np taka:

location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
} 

 

która jest.. wszędzie, w każdym how to itp.

 

Możliwe formy zabezpieczenia się? Polecam lekturę: http://forum.nginx.o...ead.php?2,88845

 

// się pośpieszyłem... może miły mod przenieść do działu traktującego o bezpieczeństwie? :>

[p 3]

Jeżeli ktoś pozwala na wgrywanie plików do katalogu, w którym znajduje się kod wykonywalny lub jego podkatalogów, to sam prosi się o problemy.

 

Powtarzałem to już dzisiaj X razy, ale jak widać muszę jeszcze raz:

To nie jest ani błąd nginx'a, ani PHP (per se). To jest błąd po stronie osób projektujących w głupi sposób serwisy internetowe.

 

jest możliwość wykonania dowolnego kodu php (jak z innymi backendami?).

Inne backend'y (python via wsgi, ruby via rack) nie uruchamiają kodu na podstawie informacji podanych przez zwykłego użytkownika (czyt. URL), tak więc są odporne na ten konkretny atak.

[atsuki 0]

true - ale to nie zmienia postaci rzeczy, że informacja może się przydać

 

a dodanie:

 

 	location ~ \..*/.*\.php$ {
	return 403;
	}

 

Nie zaszkodzi

 

to tak samo jak z windowsem xp i używania go na koncie z prawem administratora... też proszenie się o problemy, a procent domowych pecetów z xp nie chodzi na administracyjnym koncie jest niewielki.

[lazy 33]

Jeżeli ktoś pozwala na wgrywanie plików do katalogu, w którym znajduje się kod wykonywalny lub jego podkatalogów, to sam prosi się o problemy.

 

Powtarzałem to już dzisiaj X razy, ale jak widać muszę jeszcze raz:

To nie jest ani błąd nginx'a, ani PHP (per se). To jest błąd po stronie osób projektujących w głupi sposób serwisy internetowe.

 

w takim razie praktycznie wszystkie fora internetowe sa zaprojektowane w głupi sposób (avatary), serwer www nie powinien pozwalac na takie kwiatki

i nie dotyczy to nie tylko tresci uploadowanej przez urzyszkodników, mozliwe ze w ten sam sposob mozna by sobie np. zrodla skryptow cgi wyciagac

/skrypt.pl/aa.php

 

--

Lazy

[p 3]

w takim razie praktycznie wszystkie fora internetowe sa zaprojektowane w głupi sposób (avatary)

E? Chyba nie do końca zrozumiałeś na czym ten "błąd" polega. Sama możliwość wgrywania pliku przez użytkownika nie jest tutaj warunkiem wystarczającym. Problemem jest brak jakiejkolwiek separacji kodu wykonywalnego od treści.

 

serwer www nie powinien pozwalac na takie kwiatki

Że niby na co nie powinien pozwalać? Serwer www przekazuje URL (lub jego część) po FastCGI do PHP. PHP następnie wykonuje skrypt, bazując na danych otrzymanych poprzez FastCGI (co samo w sobie jest już głupie). PHP szuka najlepszego dopasowania, czyli jeżeli jeżeli otrzyma URL w postaci "/pliki/obrazek.jpg/index.php", a taka ścieżka nie istnieje w systemie, to zostanie wykonany "/plik/obrazek.jpg". Tyle.

 

i nie dotyczy to nie tylko tresci uploadowanej przez urzyszkodników, mozliwe ze w ten sam sposob mozna by sobie np. zrodla skryptow cgi wyciagac

/skrypt.pl/aa.php

Jeżeli ktoś skonfigurował serwer tak, aby skrypty perla były obsługiwane przez PHP, to zgadza się, można.

[lazy 33]

E? Chyba nie do końca zrozumiałeś na czym ten "błąd" polega. Sama możliwość wgrywania pliku przez użytkownika nie jest tutaj warunkiem wystarczającym. Problemem jest brak jakiejkolwiek separacji kodu wykonywalnego od treści.

 

wiekszosc for internetowych trzyma uploadowane obrazki w katalogu potencjalnie dostepnym dla fcgi w tym wht np. http://www.webhostin...ile/photo-2.jpg

 

 

Że niby na co nie powinien pozwalać? Serwer www przekazuje URL (lub jego część) po FastCGI do PHP. PHP następnie wykonuje skrypt, bazując na danych otrzymanych poprzez FastCGI (co samo w sobie jest już głupie). PHP szuka najlepszego dopasowania, czyli jeżeli jeżeli otrzyma URL w postaci "/pliki/obrazek.jpg/index.php", a taka ścieżka nie istnieje w systemie, to zostanie wykonany "/plik/obrazek.jpg". Tyle.

 

inne implementacje weryfikuja zmienna SCRIPT_FILENAME wysylana do fcgi, sprawdzaja czy taki plik istnieje co w wiekszosci przypadkow (kiedy fcgi dziala na tej samej maszynie i interpretuje jakies tam pliki) jest wystarczajace by zabezpieczyc sie przed takimi problemami, lepsza jest oczywiscie sytuacja kiedy wszystko jest ladnie rozdzielone, ale z popularnych skryptow bardzo malo jest takich spelniajacych takie wymagania

 

 

Jeżeli ktoś skonfigurował serwer tak, aby skrypty perla były obsługiwane przez PHP, to zgadza się, można.

 

kazdy serwer ktory uzywa

location ~ \.php$ {

 

..

 

jest skonfigurowany do obslugiwania przez php wszystkiego co sie znajduje w danym katalogu

 

w sumie sie zgadzam ze nazywanie tego błedem moze byc przesada, bo fastcgi nie musi znajdowac sie na tej samej maszynie i nie musi interpretowac jakis tam plikow

 

rzeczywiscie pierwszym problemem jest tu brak separacji, choc inne implementacje staraja sie chronic urzytkownikow migrujacych z mod_php

gdzie taka separacja nie jest konieczna, przydalo by sie tu ostrzeżenie o skutkach ubocznych takiej konfiguracji oraz opcjonalna

weryfikacja istnienia danego pliku przed wyslaniem go do fcgi ktora zalatwi bezpieczna migracje dla 99% uzytkownikow

 

--

Lazy

[p 3]

wiekszosc for internetowych trzyma uploadowane obrazki w katalogu potencjalnie dostepnym dla fcgi w tym wht np. http://www.webhostin...ile/photo-2.jpg

Nie znam tego skryptu, tak więc ciężko mi się na ten temat wypowiadać.

 

Jeżeli w systemie plików struktura skyptu wygląda tak:

/
|-- /images/
|-- /scripts/
|-- /scripts/index.php
`-- /uploads/

to wszystko jest OK.

 

Jeżeli natomiast wygląda tak:

/
|-- /images/
|-- /uploads/
`-- /index.php

to nie jest

 

inne implementacje weryfikuja zmienna SCRIPT_FILENAME wysylana do fcgi, sprawdzaja czy taki plik istnieje co w wiekszosci przypadkow (kiedy fcgi dziala na tej samej maszynie i interpretuje jakies tam pliki) jest wystarczajace by zabezpieczyc sie przed takimi problemami, lepsza jest oczywiscie sytuacja kiedy wszystko jest ladnie rozdzielone, ale z popularnych skryptow bardzo malo jest takich spelniajacych takie wymagania

Tak, sprawdzanie czy dany plik istnieje w systemie jest pewnym rozwiązaniem, ale sprawdza się jedynie w przypadkach, kiedy serwer www ma dostęp do tego samego systemu plików co skrypt PHP. Chyba nie muszę tłumaczyć, że to nie jest idealne rozwiązanie

 

kazdy serwer ktory uzywa

location ~ \.php$ {

..

jest skonfigurowany do obslugiwania przez php wszystkiego co sie znajduje w danym katalogu

Ale to wymaga przemieszania skryptów perla i PHP

 

gdzie taka separacja nie jest konieczna, przydalo by sie tu ostrzeżenie o skutkach ubocznych takiej konfiguracji oraz opcjonalna

weryfikacja istnienia danego pliku przed wyslaniem go do fcgi ktora zalatwi bezpieczna migracje dla 99% uzytkownikow

Ciche ukrywanie problemu nie doprowadzi do jego rozwiązania.

[atsuki 0]

Nie znam tego skryptu, tak więc ciężko mi się na ten temat wypowiadać.

 

Jeżeli w systemie plików struktura skyptu wygląda tak:

/
|-- /images/
|-- /scripts/
|-- /scripts/index.php
`-- /uploads/

to wszystko jest OK.[/code]

 

Rzadko się zdarza.. poza tym, ciągle chodzi o jedną rzecz, zapis w configu nginxa w postacie location ~ \.php$ {} łapie wszystkie pliki php, nie zaleznie gdzie są. Więc nawet jak masz w /images/obrazek.jpg, a skrypty masz w /scripts/index.php dalej obrazek.jpg sie wykona jako php, bo nginx uzyje konfiguracji \.php$

 

Ale to wymaga przemieszania skryptów perla i PHP

 

wystarczy, ze nginx uzyje konfiguracji \.php$, skrypt perla sie wyswietli, nginx nie ponowi sprawdzenia, i nie zmieni konfiguracji na \.pl$

[kafi 2425]

poza tym, ciągle chodzi o jedną rzecz, zapis w configu nginxa w postacie location ~ \.php$ {} łapie wszystkie pliki php

Nie łapie plików tylko łapie requesty URI. A tu, jak widać to request URI wcale nie jest tożsamy z plikiem.

 

Druga sprawa - przy takiej strukturze, jaką opisał jednoliterowiec p, to wtedy można ustawić parser PHP tylko dla kontekstu

^/scripts/(.*)\.php$

, a nie dla całego docroota.

[p 3]

Rzadko się zdarza.. poza tym, ciągle chodzi o jedną rzecz, zapis w configu nginxa w postacie location ~ \.php$ {} łapie wszystkie pliki php, nie zaleznie gdzie są. Więc nawet jak masz w /images/obrazek.jpg, a skrypty masz w /scripts/index.php dalej obrazek.jpg sie wykona jako php, bo nginx uzyje konfiguracji \.php$

Ale ja doskonale wiem o co chodzi Natomiast Ty źle zinterpretowałeś podany przeze mnie przykład. Jeżeli struktura będzie wyglądała tak jak w moim poprzednim poście, to URL /index.php będzie obsługiwany przez:

location ~ \.php$ {
...
fastcgi_param SCRIPT_FILENAME $document_root/scripts/$fastcgi_script_name;
...
}

a wtedy nie ma możliwości aby PHP wykonało cokolwiek z poza /scripts/.

 

wystarczy, ze nginx uzyje konfiguracji \.php$, skrypt perla sie wyswietli, nginx nie ponowi sprawdzenia, i nie zmieni konfiguracji na \.pl$

Patrz wyżej

[atsuki 0]

Nie łapie plików tylko łapie requesty URI. A tu, jak widać to request URI wcale nie jest tożsamy z plikiem.

 

Mea culpa, o to mi chodziło

 

Druga sprawa - przy takiej strukturze, jaką opisał jednoliterowiec p, to wtedy można ustawić parser PHP tylko dla kontekstu

^/scripts/(.*)\.php$

, a nie dla całego docroota.

 

Można, można też dodać to co napisał na liście autor nginxa

 

location ~ \..*/.*\.php$ { 
return 403; 
} 

 

jak i wiele innych rzeczy... sprawdzanie uploadowanego pliku czy jpeg to jpeg etc. Ale np. Przy wordpressie nie ma żadnego problemu z uploadem pliku i jego wykonaniu.

 

@p

Aha. Ale to nie zmienia jednego podstawowego faktu. ile skryptów - for, blogow, cms ma układ katalogów w taki opisany przez ciebie sposób? Ile osób korzystających z nginxa ma skonfigurowane php w inny sposób niż ten podatny? Sposób dodania obsługi php w ten sposób jest w każdym (?) how to w tym temacie...

 

Więc dlatego jest to niebezpieczne...

[p 3]

Nie łapie plików tylko łapie requesty URI. A tu, jak widać to request URI wcale nie jest tożsamy z plikiem.

 

Druga sprawa - przy takiej strukturze, jaką opisał jednoliterowiec p, to wtedy można ustawić parser PHP tylko dla kontekstu

^/scripts/(.*)\.php$

, a nie dla całego docroota.

Tak też można, natomiast jak już sam zauważyłeś, URI nie musi być tożsame z plikiem, tak więc można to rozwiązać w bardziej elegancki sposób za pomocą SCRIPT_FILENAME.

 

Aha. Ale to nie zmienia jednego podstawowego faktu. ile skryptów - for, blogow, cms ma układ katalogów w taki opisany przez ciebie sposób? Ile osób korzystających z nginxa ma skonfigurowane php w inny sposób niż ten podatny? Sposób dodania obsługi php w ten sposób jest w każdym (?) how to w tym temacie...

Zgadza się. Ja nigdy nie twierdziłem, że skrypciarze PHP tworzą cokolwiek w przemyślany sposób