[OWASP Top 10] A6

Cześć!

To 6 odcinek z serii OWASP TOP 10, w której opisuję najpopularniejsze grupy błędów.

Jeżeli to pierwszy z materiałów na który natrafiłeś, polecam zapoznać się także z pozostałymi.

Opowiadam w nich między innymi o SQL Injection, XXE, czy też głębokim ukryciu.

Ten film natomiast poświęcony jest w całości różnego rodzaju miskonfiguracjom, które sprawiają, że nasze strony nie są takie bezpieczne jak by mogło się wydawać.

Temat ten jest bardzo szeroki. Miejsc gdzie można popełnić błąd jest wiele - tak samo jak wiele jest różnego rodzaju serwerów, platform, frameworków i języków.

Nie sposób opisać i scharakteryzować każdy z nich w tak krótkim materiale.

Postaram Ci się jednak dać pewien pogląd na to, jak takie błędy mogą wyglądać.

Ten punkt jest nieco podobny do kategorii dziewiątej - czyli używania komponentów ze znanymi podatnościami.

Tam jednak nie mamy większego wpływu na pojawienie się danej podatności - wszak to nie nasz kod, a zewnętrznej firmy bądź też organizacji i umieszczając go w naszym produkcie niejako ufamy, że jest bezpieczny.

Przy błędnej konfiguracji natomiast to sami popełniamy jakiś błąd - albo nie stosując się do dobrych praktyk, albo pomijając jakieś mechanizmy, albo po prostu nie zdając sobie sprawy z tego jak dana opcja działa.

Czasami wystarczy malutka zmiana w konfiguracji, włączenie lub też wyłączenie jakiegoś jednego malutkiego przełącznika, aby nagle całe bezpieczeństwo aplikacji było zagrożone.

Każda strona internetowa musi być uruchomiona na jakimś serwerze, który będzie obsługiwał żądania pochodzące od użytkowników.

Większość tych serwerów pozostawia ślady swojego istnienia w swoich odpowiedziach.

Zazwyczaj chodzi o nagłówek Server albo Powered by, gdzie znajdują się informacje o nazwie serwera lub używanego frameworka a czasami również o jego wersji.

Można pomyśleć, że to nic złego - wszak ta wiedza niewiele daje potencjalnemu atakującemu.

Ale czy aby na pewno? Istnieje przynajmniej kilka serwisów, które nieustannie łączą się ze wszystkimi komputerami na świecie - pobierając wszystkie informacje jakie te zwracają.

W taki sposób powstają wyszukiwarki serwerów. Myślę, że jedną z najpopularniejszych jest Shodan.

One to działają podobnie do zwykłych wyszukiwarek, tylko że zamiast przeszukiwać treść stron - sprawdzamy nagłówki.

Takie sprawdzanie wersji nazywamy Fingerprintingiem.

Wyobraźmy sobie zatem, że nagle odnaleziono jakiś poważny błąd w jednym z serwerów.

Jeżeli ten serwer w standardzie zwraca informacje na swój temat wraz z numerem wersji, atakujący szybko może stworzyć listę potencjalnych miejsc, które warto przetestować.

Istnieje bowiem spore prawdopodobieństwo, że któraś z tych stron dalej nie uaktualniła odpowiedniego oprogramowania.

W przypadku serwerów warto również sprawdzić, które pliki są traktowane jako wykonywalne.

Chodzi tutaj głównie o języki skryptowe.

Nie chcemy bowiem doprowadzić do sytuacji, gdy nagle serwer zaczyna traktować pliki z rozszerzeniem txt jako takie, które zawierają kod i zamiast wyświetlać ich treść zaczyna wykonywać skrypt tam zawarty.

W większości przypadków manual danego rozwiązania to jedno z istotniejszych miejsc dla pentestera.

Zwłaszcza te miejsca, oznaczone czerwonym kolorem i różnej wielkości ramką.

Większość rozwiązań istniejących już na rynku od dłuższego czasu posiada specjalną podstronę powiązaną z bezpieczeństwem, na której znajdują się informacje na temat najpopularniejszych miskonfiguracji.

Tam to zazwyczaj znajdują się informacje o teoretycznych błędach popełnianych przez nieświadomych użytkowników.

Każda aplikacja przechodzi fazę projektowania i testowania, kiedy to jest uruchamiana na środowisku deweloperskim i testowym.

Wtedy to też posiada wiele udogodnień - takich jak debugger, pozwalający na sprawniejsze wyszukiwanie błędów.

Warto pamiętać, aby opcję te wyłączyć podczas przenosin na serwer produkcyjny.

I tyczy się to również wyświetlania błędów, które na produkcji powinny być bardzo lakoniczne.

Wszystkie wrażliwe informacje natomiast powinny być osobno logowanie do odpowiednio zabezpieczonych plików.

Wyświetlanie informacji o braku połączenia z bazą danych wraz z loginem i hasłem nie jest takie rzadkie jak mogłoby się wydawać.

Można to sprawdzić używając Google dorks - czyli specjalnie spreparowanych fraz, które podaje się w oknie wyszukiwarki.

One to mają za zadanie wyszukiwać serwery, które są błędnie skonfigurowane - czyli na przykład takie, które w kodzie błędu podają hasło do bazy danych.

Konta testowe i tymczasowe w stylu "admin/admin" to również coś o czym można zapomnieć.

Warto też pamiętać o usunięciu wszystkich plików z backupami i konfiguracjami.

To samo tyczy się plików kontroli wersji - na przykład katalogu .git w którym znajdują się wszystkie informacje na temat przechowywanych tam plików.

Jeżeli przez przypadek wyślemy je na nasz serwer, a atakujący będzie w stanie znaleźć taki katalog, z łatwością przeglądnie cały kod źródłowy, wyciągnie z niego wszystkie sekrety i tajne wartości i przejdzie z atakiem do dalszej fazy.

Niektóre edytory tekstu podczas edycji plików tworzą tymczasowe pliki swap - tam również mogą znajdować się informacje potencjalnie niebezpieczne i przydatne dla atakującego.

Jak widzisz tych miejsc o których należy pamiętać jest całkiem sporo.

Sprawę może ułatwić korzystanie z tak zwanych checklist - na których punkt po punkcie umieszcza się zadania jakie należy wykonać przed uruchomieniem danej aplikacji.

Spróbujmy prześledzić kilka takich punktów w popularnych produktach używanych na całym świecie.

MongoDB to otwarta, nierelacyjna baza danych charakteryzująca się dużą skalowalnością, wydajnością i brakiem ściśle zdefiniowanej struktury.

Podczas konfiguracji tej bazy warto sprawdzić, czy baza ta dostępna jest tylko dla zalogowanych użytkowników.

Czasami mechanizm ten ma ustawione wyjątki, sprawiające że można dostać się do zasobów jeżeli żądanie pochodzi z lokalnego hosta.

A to nie do końca jest dobre - jeżeli bowiem serwer znajduje się na tej samej maszynie co aplikacja - używając podatności SSRF można wysłać żądanie do takowej bazy i pobrać z niej interesujące rekordy.

To samo tyczy się innych baz danych, dla przykładu MySQL.

W dużej ilości przypadków nie musi być ona uruchomiona z uprawnieniami użytkownika root aby prawidłowo działać.

Taka konfiguracja może doprowadzić do podniesienia uprawnień w przypadku ataku na serwer.

Jeżeli bowiem baza danych ma dostęp do wszystkich plików - atakujący może pobrać dowolny plik z serwera używając składni LOAD FILE oraz zapisać dowolny plik używając INTO OUTFILE.

W serwerze IIS dostępna jest opcja "directory browsing". Jeżeli jest włączona pozwala na wyświetlenie zawartości katalogu.

W przypadku ciasteczek interesującą jest opcja "cookie protection mode”, która odpowiedzialna jest za odpowiednie szyfrowanie i podpisywanie ciasteczek używanych przez całą aplikację.

Razem z Tomcatem standardowo instalowane są przykładowe aplikacje, które mogą stanowić niepotrzebne ryzyko.

Warto je zatem usunąć.

Serwer ten przedstawia się klientom, używając danych z server.info.

Dzięki temu można przeprowadzić fingerprinting - czyli sprawdzić jaka wersja tomcata jest uruchomiona na danym serwerze

Nasłuchuje on również na porcie 8006. Przesyłając tam komendę SHUTDOWN dochodzi do zatrzymania wszystkich uruchomionych aplikacji.

Jeżeli zatem ten port jest wystawiony na zewnątrz, atakujący może doprowadzić do problemów z dostępnością witryny - po prostu zamykając daną aplikację.

W przypadku Apache należy wyłączyć moduły, których nie potrzebujemy.

Chociażby WebDAV, pozwalający na tworzenie, przenoszenie i usuwanie zasobów z serwera albo status - wyświetlający informacje na temat wydajności.

W znakomitej większości przypadków te moduły nie są potrzebne na produkcyjnej maszynie.

Apache obsługuje wiele protokołów - a nie wszystkie z nich są na tą chwilę bezpieczne.

Chociażby SSLv3 uważany za przestarzały i niebezpieczny ponieważ jest podatny na atak POODLE.

Bezpieczeństwo powiązane jest także z dostępnością, a wiec zabezpieczeniem przed wszelkiego rodzaju atakami DOS.

Na jaki czas ustawiony jest timeout serwera?

Jeżeli wartość ta jest zbyt duża - atakujący może zainicjalizować wiele połączeń sprawiając tym samym, że w pewnym momencie skończą się zasoby potrzebne do procesowania żądań a strona przestanie odpowiadać.

Ale strony mogą być także uruchamiane w chmurze - chociażby Amazona.

Warto zadbać o odpowiednie ustawienie dwuskładnikowego uwierzytelnienia.

Kluczowa jest także konfiguracja kubełków, w których przechowujemy pliki.

Nie powinny być one dostępne dla osób postronnych.

W przypadku Flaska i konfiguracji deweloperskiej możliwe jest korzystanie z Debuggera - pozwalającego na wykonanie dowolnego kodu.

Jeżeli tryb ten zostanie przez przypadek uruchomiony na produkcyjnej aplikacji - atakujący może przejąć kontrolę nad serwerem.

NGINX również nie jest najprostszym z serwerów do konfiguracji.

Chociażby używanie dyrektywy location może prowadzić do ataków path traversal.

Więcej na ten temat w osobnym filmie z cyklu od 0 do pentestera¹.

Spring Boot staje się coraz popularniejszy - czasami zależy nam na dostępie do pewnych metryk - używamy więc Spring Boot Actuatora.

Jeżeli nie zabezpieczymy odpowiednio endpointów - używając chociażby Spring Boot Security – atakujący odpowiednio je wykorzystując może przejąć czyjeś konto na serwisie.

Osobną kwestią jest odpowiednie ustalanie nagłówków zwracanych przez serwery.

Czy używamy odpowiednich nagłówków, które chronią przed całą grupą różnego rodzaju ataków?

Chociażby X-Frame-Options chroniący przed atakami Clickjacking.

Tutaj należy pamiętać o nagłówkach CORS - które - jeżeli źle ustawione, mogą doprowadzić do pobierania danych z naszego serwera przez zewnętrzne strony.

Jeżeli chcemy się zabezpieczyć przed atakami XSS - nagłówek CSP to coś co powinno nas zainteresować.

Jego wprowadzenie nie jest jednak trywialne - zwłaszcza, jeżeli kod JavaScript na naszej stronie jest przeplatany razem z HTMLem.

Popularnym jest użycie flagi unsafe-inline, co w praktyce sprawia, że rozwiązanie to staje się kompletnie bezużyteczne.

W przypadku Dockera nie powinno tworzyć się tak zwanych priveleged kontenerów.

Udostępnianie wszystkich katalogów do kontenera również nie jest najlepszym pomysłem.

Jeżeli bowiem udostępnimy cały dysk twardy hosta - kontener będzie mógł odczytać hasła przechowywane w /etc/shadow.

Jeżeli pliki nie są zamontowane z uprawnieniami read-only, będzie mógł nie tylko je odczytać ale także zmienić ich treść czy też stworzyć nowe pliki.

Niebezpieczeństwo miskongfiguracji zachodzi również w przypadku zewnętrznych rozwiązań.

Jenkins - czyli serwer continuous integration pozwala na uruchamianie skryptów grooviego, które umożliwiają dostęp do całego serwera.

Jeżeli zatem ta funkcjonalność nie zostanie odpowiednio zabezpieczona - każdy użytkownik może z niej korzystać - co naraża na szwank całą organizację.

To samo tyczy się serwerów Gita - jeżeli dowolna osoba może modyfikować hooki gita wykonywane przez ten serwer - tak naprawdę posiada do niego pełen dostęp.

Więcej na ten temat w filmie, w którym wykorzystuję podatność w serwerze Gogs i Gitea².

Na koniec - błędna konfiguracja DNS może doprowadzić do przejęcia naszej nazwy domenowej, a brak nagłówków SPF prowadzić do możliwości wysyłania maili w naszym imieniu.

I to już wszystko w tym odcinku. Jak możesz się domyślać to tylko kropla w morzu.

Wszystko zależy od technologii jakiej używamy na co dzień.

A już w kolejnym odcinku opowiem o XSS, czyli wykonaniu kodu JavaScript na podatnej stronie.

A w międzyczasie zapraszam do posłuchania podcastu Szurkogadanie, z którego dowiesz się co ostatnio działo się w branży bezpieczeństwa.

Jeżeli ten materiał Ci się spodobał - nie zapomnij o subskrypcji kanału i zostawieniu łapki w górę.

Do zobaczenia.

Cześć!

Free Broll provided by videezy.com

Background vector created by rawpixel.com - www.freepik.com

Icon made by Freepik www.flaticon.com