Jak prawie zepsułem portal Albicla – polską alternatywę dla Facebooka

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 oprogramowania musimy pamiętać o tym, że 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.

HakerW idealnym świecie serwisy internetowe powinny przechodzić audyty bezpieczeństwa. Realia niestety wyglądają tak, że 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ę, że 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
Kilka przykładowych afer opisanych na wykop.pl

Sami twórcy przekonywali, że 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
ź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, że omawiany kod jest dostępny dla każdego 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
Przykład włączonych notyfikacji w PHP

Trafiony! Widzimy tu kilka interesujących rzeczy. I to jest właśnie jeden z problemów, że „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 właściwe miejsce. Widzimy również jak tworzone są avatary (o tym za chwilę).

Jak wyłączyć wyświetlanie błędów w serwisach PHP?

Problem należy rozwiązać. Przedstawiamy 3 różne metody.
  • Plik php.ini
display_errors =  Off
  • Plik .htaccess
php_flag display_errors off
  • Aplikacja PHP
error_reporting(E_ALL ^ E_NOTICE );
error_reporting(E_ERROR | E_PARSE);

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, że 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 nawet 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, że to właśnie tak się dzieje. Skąd to wiemy?

Dzięki wyświetlaniu błędów dedukujemy, że do skalowania obrazków używana jest PHPowa biblioteka GD a wygenerowane obrazki zapisywane są na dysku za pomocą 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ć, że 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 za pomocą 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 8000

Z jednego obrazka możemy wygenerować 64 000 000 kolejnych (8000 x 8000). Użyjemy do tego 2 prostych pętli.

for ($i = 0; $i <= 8000; $i++) {
    for ($y = 0; $y <= 8000; $y++) {
        //generate image here $i x $y
    }
}
Uruchamiamy skrypt i czekamy.

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ć, że 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 MB

Wielkość 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, że 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, że „atak na zdjęcia” jest jak najbardziej możliwy.

Co robić, jak żyć?

Na podstawie naszej analizy możemy wyciągnąć 3 wnioski:

  1. Wyłącz wyświetlanie błędów.
  2. Waliduj otrzymywane dane.
  3. Zabezpiecz serwis przed atakami DDOS.
 
Są to podstawowe błędy. Typowe dla początkujących programistów.
 
Jestem przekonany, że poświęcając więcej czasu na analizę Albicli tych punktów mogłoby być znacznie więcej, ale nie o to w tym wszystkim chodzi.  Pragnę zwrócić uwagę, że nie wszystko co odgórnie określane jako jedyne właściwe, najlepsze takie rzeczywiście jest.
 
Parafrazując szczecińskiego rapera Łonę aż chce się rzec „miej wątpliwość„. 
 
Natomiast jeśli jesteś programistą – dbaj o jakość i bezpieczeństwo swojego kodu. Nigdy nie wiesz gdy ktoś zastosuje „sprawdzam”.

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ł.

Marek Golan

Założyciel Dogtronica. Specjalista IT z kilkunastoletnim stażem. Miłośnik elektroniki oraz technologii blockchain. Pamięta czasy IE6 jakby to było wczoraj :)

12 komentarzy

Zostaw komentarz

dwa × jeden =

Top