Celem artykułu jest omówienie jak zabezpieczyć swój serwis www przed niepożądanymi działaniami, które prędzej czy później mogą dotknąć każdego kto tworzy oprogramowanie. Przy budowaniu systemu musimy pamiętać o tym, iż w każdej chwili możemy zostać celem ataków nieprzychylnych nam osób. Wady w naszym systemie mogą zostać wykorzystane nie tylko przez osoby trzecie. Oprogramowanie może być samo dla siebie zagrożeniem.
W idealnym świecie serwisy internetowe powinny przechodzić audyty bezpieczeństwa. Realia niestety wyglądają tak, iż z audytów korzystają nieliczni. W zasadzie tylko popularne serwisy, które są na tyle dojrzałe by być świadomymi zagrożeń. Zwykle są to serwisy, które gromadzą wrażliwe dane. Czy w przypadku tytułowego serwisu społecznościowego można mówić o gromadzeniu wrażliwych danych? Owszem. Mowa tu o danych osobowych 80 tys. użytkowników. Co prawda zdajemy sobie sprawę, iż co 3ci może mieć na imię Karol, ale to nie powinno w żaden sposób usprawiedliwiać autorów Albicli.
Sam audyt oczywiście niczego nie zmienia. Wskazuje jedynie podatności na ataki. Wskazane błędy należy jak najszybciej naprawić. Tym zajmiemy się w tym artykule – wskażemy błędy i zaproponujemy jak naprawić.
Za przykład posłuży nam serwis znajdujący się pod adresem albicla.com.
Albicla - pogromca facebooka
Tym którzy nie kojarzą Ablicli przyda się krótkie wprowadzenie. Czym jest Ablicla? Jest to dość kontrowersyjny portal społecznościowy, który powstał jako odpowiedź na szerzące się “lewactwo”, cenzurę itd na portalach typu Facebook czy Twitter.
Albicla nie miała najlepszego startu. Musiała borykać się wieloma poważnymi wpadkami. Niedoskonały a zarazem buńczuczny portal nie mógł zostań niezauważony przez społeczność internetową.
Kilka przykładowych afer opisanych na wykop.pl
Sami twórcy przekonywali, iż z serwisem jest wszystko w porządku. Albicla ma się świetnie a jej problemy to nie problemy tylko spisek zazdrosnych użytkowników sieci.
Podczas wypływania kolejnych mniejszych lub większych afer internauci nie szczędzili krytyki wobec jego Twórcy. Przy okazji powstało wiele memów na ten temat.
źródło: wykop.pl
Za powstanie portalu Albicla.com odpowiada Tomasz Sakiewicz – publicysta i dziennikarz, redaktor Gazety Polskiej i Gazety Polskiej Codziennie oraz Telewizji Republika. Jak czytamy w regulaminie – Serwis jest własnością spółki Słowo Niezależne. A ta z kolei jest wydawcą gazety Nowe Państwo oraz portalu Niezalezna.pl jak i wielu innych.
Z kolei w grupie Słowo Niezależne 140 udziałów posiada słynna już spółka “Srebrna”, której większościowym udziałowcem jest Instytut Lecha Kaczyńskiego. Ten z kolei sterowany jest przez jego brata. Tak więc drodzy Państwo, w poniższym artykule będziemy analizować rządowy portal społecznościowy.
Jakie ma to znaczenie? Ano żadne – podaję to jako ciekawostkę z przymrużeniem oka. Władza patrzy nam na ręce? Spójrzmy na kod, który wyszedł spod palców władzy.
Display All PHP Errors
Wstęp mamy za sobą, pora na krótką analizę kodu. Zaznaczam, iż omawiany kod jest dostępny dla wszystkich użytkownika sieci. Wystarczy kliknąć prawym przyciskiem myszy na stronie albicla.com i zaznaczyć „Wyświetl źródło strony„.
Przeglądając owe źródło zauważyłem interesującą rzecz.
Link do obrazów prezentuje się w ten sposób:
Avatary:
https://albicla.pl/imgcache/150x150/c/uploads/1000060870/avatar/1000060870_1613073659.jpg
Okładki artykułów:
https://albicla.pl/imgcache/800x800/w/uploads/images/tmp/100004506116613986127f509c252fd3.jpg
Niby nic nadzwyczajnego ale pobawmy się odrobinę tymi linkami. Zamieńmy nazwę pliku na losową.
Przykład włączonych notyfikacji w PHP
Trafiony! Widzimy tu kilka interesujących rzeczy. I to jest właśnie jeden z problemów, iż „widzimy”.
W aplikacjach wdrożonych na produkcję (udostępnionym użytkownikom) nie możemy zostawiać włączonego wyświetlania błędów. W tym przypadku widzimy ścieżkę, na której została zainstalowana aplikacja. Dzięki tej wiedzy przy ewentualnych planowanych atakach możemy precyzyjnie uderzać we adekwatne miejsce. Widzimy również jak tworzone są avatary (o tym za chwilę).
Jak wyłączyć wyświetlanie błędów w serwisach PHP?
- Plik php.ini
- Plik .htaccess
- Aplikacja PHP
Wszystkie te sposoby powodują wyłącznie wyświetlania błędów użytkownikowi. Błędy aplikacji należy zapisywać do pliku, do którego dostęp ma wyłącznie administrator serwera.
Generowanie obrazków
Analizując link do obrazków zauważyłem, iż są generowane dynamicznie na podstawie przesyłanych parametrów. Wystarczy zmienić atrybut odpowiadający za rozmiar i otrzymujemy nowe zdjęcie w dowolnym rozmiarze:
https://albicla.pl/imgcache/800x800/w/uploads/images/tmp/100004506116613986127f509c252fd3.jpg
Możemy podać praktycznie każdy rozmiar. Nie zastosowano tutaj żadnej walidacji!
Skrypt powinien ograniczać możliwość generowania obrazków wyłącznie do tych rozmiarów, które są stosowane w serwisie.
A jak jest?
Dla przykładu avatar o rozmiarze 150px / 150px
https://albicla.pl/imgcache/150x150/c/uploads/1000060870/avatar/1000060870_1613073659.jpg
Może być Avatarem o wielkości 1500px / 1500px
https://albicla.pl/imgcache/1500x1500/c/uploads/1000060870/avatar/1000060870_1613073659.jpg
Czy choćby 2500px / 2500px
https://albicla.pl/imgcache/2500x2500/c/uploads/1000060870/avatar/1000060870_1613073659.jpg
Czy to niebezpieczne? Samo w sobie nie. O ile obrazki nie zapisywałby się na serwerze. Z tym, iż to właśnie tak się dzieje. Skąd to wiemy?
Dzięki wyświetlaniu błędów dedukujemy, iż do skalowania obrazków używana jest PHPowa biblioteka GD a wygenerowane obrazki zapisywane są na dysku dzięki funkcji „copy()„.
Czy to rozwiązanie jest bezpieczne? Nie! Za każdym razem gdy wchodzimy na odpowiednio zmodyfikowany link tworzony jest nowy obrazek na dysku. Co może spowodować, iż dysk serwera zostanie zapchany. Serwis zostanie zablokowany, sesje użytkowników nie będą miały gdzie się zapisać, przez co będą podatne na kradzież. Możemy również narazić serwis na gigantyczne koszty utrzymania takiej ilości danych.
Sprawdźmy czy możemy to zrobić…
Testy obciążeniowe
Znając „obrazkową” podatność Albicli spróbujmy zasymulować okoliczność gdyby ktoś chciał tę lukę wykorzystać.
Przeprowadzanie naszego eksperymentu bezpośrednio na serwisie Albicla.com byłoby działaniem celowym na szkodę w/w podmiotu więc na potrzebę naszego testu stworzymy bliźniacze środowisko w ramach własnego serwera.
Możemy użyć pierwszego lepszego skryptu PHP do zmiany rozdzielczości obrazka dzięki biblioteki GD, możemy użyć każdego innego sposobu (np. ImageMagic). Nie ma to większego znaczenia.
Mając gotowy program spróbujmy wygenerować obrazki w rozmiarze od 1 x 1 do 8000 x 8000. Zobaczymy ile wszystkie zajmą miejsca na dysku.
Potrzebujemy generować obrazki o rozmiarach:
1 x 1 1 x 2 1 x 3 1 x 4 ... 1 x 8000Z jednego obrazka możemy wygenerować 64 000 000 kolejnych (8000 x 8000). Użyjemy do tego 2 prostych pętli.
Po 20 minutach mamy już 2.8GB nowych obrazków.
A wygenerowało nam się zaledwie 1 000 obrazków! Chcąc oszczędzić czas i nasz serwer spróbujmy obliczyć co by się wydarzyło gdybyśmy wygenerowali wszystkie 64 000 000 nowych obrazków.
Musimy pamiętać, iż obrazek obrazkowi nie równy. Przyjmijmy proste założenia reprezentanta każdego rozmiaru.
1000px - 0.1 MB 2000px - 0.4 MB 3000px - 0.7 MB 4000px - 1.2 MB 5000px - 1.8 MB 6000px - 2.4 MB 7000px - 3 MB 8000px - 3.7 MBWielkość poszczególnej rozdzielczości została zbadana na podstawie przykładowego avataru:
https://albicla.pl/imgcache/150x150/c/uploads/1000060870/avatar/1000060870_1613073659.jpg
Po kilku obliczeniach wiemy, iż naszą metodą zajmiemy 13 300 000 MB miejsca dysku. Mowa tylko o jednym zdjęciu!
13 300 000 MB to 12.68 TB!
Proszę sobie wyobrazić co by się wydarzyło gdyby uruchomić 100 podobnych skryptów na 100 różnych zdjęciach…
Jak się przed tym uchronić? Przede wszystkim należy załatać omawianą dziurę. Dodatkowo należy wdrożyć usługę chroniącą przez atakami DDOS np. CloudFlare.
Czy Alibcla jest podatna na ataki DDOS? Jak najbardziej. Przetestowaliśmy odpytywanie serwera. Po 15 min wysyłania tego samego zapytania serwer nas nie zablokował. Co oznacza, iż „atak na zdjęcia” jest jak najbardziej możliwy.
Co robić, jak żyć?
Na podstawie naszej analizy możemy wyciągnąć 3 wnioski:
- Wyłącz wyświetlanie błędów.
- Waliduj otrzymywane dane.
- Zabezpiecz serwis przed atakami DDOS.
Przed publikacją artykułu zgłosiliśmy Albicli nasze zastrzeżenia co do bezpieczeństwa. Do tej pory nie otrzymaliśmy odpowiedzi. Błędy nie zostały naprawione. Od tamtego czasu minęło 14 dni więc z czystym sumieniem publikujemy ten artykuł.
