14 krytycznych luk, które znaleźliśmy w 3 dni

Poniedziałek, godzina 9:12 – Pierwszy skan

Pracę zaczęliśmy od podpięcia narzędzi do statycznej analizy kodu (SAST) pod repozytorium na GitLabie. Już o godzinie 9:43 system wyrzucił pierwszy czerwony alert. W pliku konfiguracyjnym ukrytym w folderze 'services/auth' znaleźliśmy zahardkodowane dane dostępowe do bazy produkcyjnej. To był klasyczny błąd ludzki – jeden z młodszych programistów wpisał je tam 'na chwilę' podczas testów w lipcu i zapomniał usunąć przed wysłaniem kodu na serwer.

Takie przeoczenie to dla hakera zaproszenie na kawę. Wystarczyłoby, że ktoś uzyskałby dostęp do dowolnego logu z błędem, a miałby login i hasło do wszystkich danych klientów. W The SpyBolt nie bawimy się w wytykanie palcami. Od razu pokazaliśmy Darkowi, liderowi zespołu, jak przenieść te wrażliwe dane do bezpiecznego magazynu haseł. Naprawa tej konkretnej luki zajęła dokładnie 14 minut, a poziom stresu w zespole wyraźnie spadł już pierwszego dnia.

Znalezienie hasła w kodzie zajęło nam mniej czasu niż zaparzenie porannej kawy w biurze na Sienkiewicza.

Wtorek – Dziury w starych bibliotekach

Drugiego dnia skupiliśmy się na zależnościach projektu. Wiele firm myśli, że jeśli ich własny kod jest czysty, to są bezpieczni. To błąd. Analiza wykazała, że aplikacja używa 23 bibliotek open-source, które miały znane i opisane błędy (CVE). Najgorsza z nich, służąca do generowania raportów PDF, pochodziła z września 2021 roku. Pozwalała ona na wykonanie dowolnego polecenia na serwerze przez odpowiednio spreparowany formularz.

Zamiast pisać nudny raport, przygotowaliśmy szybki pokaz. Pokazaliśmy programistom, jak w 3 minuty przejąć kontrolę nad ich serwerem testowym, wysyłając tylko jeden plik. Widok otwartego wiersza poleceń z uprawnieniami administratora zadziałał lepiej niż jakikolwiek podręcznik. Do godziny 16:00 zespół zaktualizował wszystkie krytyczne pakiety. Użyliśmy do tego narzędzia, które teraz automatycznie sprawdza każdą nową bibliotekę, zanim trafi ona do głównego kodu.

Środa – Atak na formularze i baza danych

Ostatni dzień poświęciliśmy na testy dynamiczne. Szukaliśmy luk typu SQL Injection w module wyszukiwania zleceń. Okazało się, że pole filtrujące daty nie miało żadnej walidacji. Wpisując prostą komendę zamiast daty, wyciągnęliśmy z bazy listę ostatnich 47 przelewów wraz z numerami kont. To była jedna z 3 luk tego typu, które znaleźliśmy w module finansowym stworzonym jeszcze w zeszłym roku.

W The SpyBolt wierzymy w proste rozwiązania. Zamiast przebudowywać cały moduł przez miesiąc, wdrożyliśmy parametryzację zapytań i dodatkowy filtr na wejściu. Cała operacja trwała 5 godzin roboczych. Na koniec dnia przeszkoliliśmy zespół z podstaw bezpiecznego kodowania formularzy. Nie był to suchy wykład, ale 45-minutowy warsztat na ich własnym kodzie, gdzie każdy mógł samodzielnie 'załatać' swoją część aplikacji.

Błędy w walidacji danych to najkrótsza droga do utraty pieniędzy z firmowego konta.

Podsumowanie i co dalej?

W czwartek o 15:30 oddaliśmy pełną listę naprawczych kroków. Z 14 krytycznych błędów, 11 zostało naprawionych na miejscu, pod naszym okiem. Pozostałe 3 drobniejsze usterki zespół wpisał do harmonogramu na przyszły wtorek. Koszt całego audytu wyniósł ułamek tego, co firma musiałaby zapłacić jako karę za wyciek danych RODO, który przy tych dziurach był tylko kwestią czasu.

Bezpieczeństwo to nie jest jednorazowy zryw. Dlatego wdrożyliśmy w tym software house automatyczny skaner, który działa w tle. Teraz, jeśli jakikolwiek programista przez pomyłkę zostawi hasło w kodzie, system od razu zablokuje taką zmianę i wyśle powiadomienie. To proste narzędzie, które pozwala im spać spokojnie, a nam daje pewność, że nasza praca przynosi trwałe efekty. Jeśli Twój zespół też pracuje pod presją, warto sprawdzić kod, zanim zrobi to ktoś inny.