Jak budować odpornośc aplikacji na ataki? – Case Study

W maju 2020 roku politechnika warszawska będąca największą techniczną uczelnią w Polsce doznała bardzo bolesnego wycieku danych. Blisko 3 GB plik zawierający dane studentów uczelni w tym dane wrażliwe tj. PESEL, czy numer dowodu został udostępniony w Internecie. Wyciek był związany z podatnością SQL Injection, którą atakujący odnalazł w jednej z podstron aplikacji do zdalnego studiowana na uczelni. Za ten incydent politechnika otrzymała od UODO dotkliwą karę.

Z poniższego artykułu dowiesz się co podczas wytwarzania aplikacji poszło nie tak oraz jak z pomocą testów penetracyjnych uchronić swoją aplikacje przed podobnymi sytuacjami.

Cyberhigiena aplikacji

Każdy doskonale wie, że lepiej zapobiegać, niż leczyć. Podobnie sprawa wygląda z aplikacjami. Zapewne większość z was słyszała o SDCL, czyli cyklu życia oprogramowania. Jednak dołożenie drugiej literki „s” z przodu wciąż potrafi niektórych zdezorientować.

Celem SSDLC (Secure Software Development Life cycle) jest zapewnienie, że oprogramowanie jest projektowane, rozwijane i utrzymywane z naciskiem na bezpieczeństwo, minimalizując luki i zmniejszając ryzyko naruszeń bezpieczeństwa. Podobnie jak w SDCL mamy tu do czynienia z 6 cyklami, zaczynając od planowania, a kończąc na utrzymaniu. W każdy cykl zostały zagnieżdżone procesy lub narzędzia poprawiające bezpieczeństwo wytwarzanej aplikacji.

W przypadku wycieku danych z politechniki, możemy z dużą dozą prawdopodobieństwa stwierdzić, że aplikacja nie była wytwarzana zgodnie z SSDCL. Klasyczna podatność SQL Injection powinna zostać wyłapana już w 3 cyklu procesu, jakim jest implementacja.

Testy penetracyjne jako ostateczny sprawdzian

Co jednak jeśli z braku wdrożonego SSDCL w organizacji, aplikacja nie przeszła modelowania zagrożeń, a kod nie był skanowany pod kątem bezpieczeństwa?

Testy penetracyjne, często nazywane również testami bezpieczeństwa mogą być ostatnią deską ratunku przed wdrożeniem podatnej aplikacji na środowisko produkcyjne lub o ile została już wdrożona, znalezieniem podatności przed atakującymi. Polegają one na kontrolowanej próbie przełamania zabezpieczeń aplikacji w celu oceny bieżącego stanu bezpieczeństwa. Podczas takich testów, aplikacja poddawana jest różnym sprawdzeniom m.in wstrzyknięcia własnego kodu, weryfikacji nadmiernych plików na serwerze czy próbie ominięcia uwierzytelnienia.

Podatna aplikacja politechniki warszawskiej napisana została w języku PHP. Język ten poprzez stosunkową łatwość do przyswojenia jest często wybierany przez początkujących programistów z małą wiedzą o wytwarzaniu bezpiecznego kodu. Dodatkowo PHP, w odróżnieniu od innych języków, takich jak. NET nie posiada wbudowanych mechanizmów bezpieczeństwa wspomagających programistów. Nie oznacza to jednak, że PHP jest językiem niebezpiecznym, aplikacje napisane w tym języku mogą być równie bezpieczne jak Javie czy. NET, jednak wiedza oraz doświadczenie programisty odgrywa tu kluczowe znaczenie.

SQL injection, czyli wiecznie żywa podatność

Z notatki pozostawionej przez włamywacza na publicznym gitlabie należącym do politechniki warszawskiej wynika że podatność została znaleziona w podstronie druk_obliczenia_osoba.php . Strona została usunięta przez administratora serwera aplikacyjnego chwile po wycieku, natomiast po nazwie możemy wywnioskować że służyła do obliczania np. punktacji studentów.

Podatność SQL Injection, nazywana również królową podatności której pierwsze wystąpienia datuje się na rok 1998, wynika z braku odpowiedniej walidacji danych wejściowych dostarczanych od użytkowników. W związku z brakiem sanityzacji takich danych, atakujący jest w stanie wstrzyknąć własne, złośliwe zapytanie SQL.

W przypadku podatnej strony załóżmy że aplikacja wysyłała do bazy danych poniższe zapytanie.

SELECT studentID,imie,nazwisko,punktacja FROM kandydaci WHERE studentID='23123';

Włamywacz przyznał również że zastosował technikę UNION injection. W języku SQL, UNION SELECT jest używany do łączenia dwóch lub więcej zapytań w jedno.
W powyższym zapytaniu dane wejściowe nie są w żaden sposób oczyszczane przed wstawieniem ich do zapytania. Atakujący, modyfikując zapytanie był w stanie określić liczbę kolumn w tabeli.

SELECT studentID,imie,nazwisko,punktacja FROM kandydaci WHERE studentID='' ORDER BY 5--

Znając dokładne liczbę kolumn oraz typ danych jesteśmy w stanie, dodając drugie zapytanie zrzucić dane z bazy.

SELECT studentID,imie,nazwisko,punktacja FROM kandydaci WHERE studentID='' UNION SELECT imie, nazwisko,NULL, password, NULL FROM kandydaci;

 

Fragmenty zrzutu bazy danych Moodle podchodzące z platformy OKNO. Źródlo: Raport CERT Polska 2020

Powyższe zadanie można oczywiście zautomatyzować korzystając z narzędzi tj. Sqlmap.

sqlmap -u https://podatnaStrona.pl/druk_obliczenia_osoba.php?studentid=2321 -p studentid --dbms=mysql --level=3 --tamper=hex2char

Kiedy zdecydować sie na testy penetracyjne?

Czy każda aplikacja wystawiona do Internetu powinna przejść testy penetracyjne? Tutaj odpowiedź nie zawsze będzie jednoznaczna. Oczywiście, osoba która prowadzi Bloga w sieci może nie potrzebować takiej usług. W przypadku, jednak jeśli aplikacja pozwala na zakładanie kont użytkownikom, a dodatkowo jeszcze przetwarza dane wrażliwe tj. PESEL, czy adres zamieszkania lub pozwala na dokonywanie m.in. transakcji finansowych, testy penetracyjne powinny stać się oczywistością, która ochroni biznes przed dotkliwymi stratami wizerunkowymi, czy nawet finansowymi.
Następstwem wycieku danych z politechniki warszawskiej była kara w wysokości 45 000zł nałożona przez UODO na uczelnie.

Podsumowanie

Przeprowadzanie testów penetracyjnych dla aplikacji jest kluczowym elementem strategii bezpieczeństwa. Zapewnia to nie tylko ochronę danych i reputacji firmy, ale również zgodność z regulacjami oraz ochronę przed stratami finansowymi. Testy penetracyjne pozwalają na wczesne wykrywanie i naprawianie luk w zabezpieczeniach, co jest niezbędne w dzisiejszym dynamicznie zmieniającym się środowisku cyberzagrożeń.

Podobne wpisy