Jak prosty błąd w API mógł doprowadzić do poważnych zagrożeń finansowych

W trakcie niedawnego testu penetracyjnego natknęliśmy się na szereg podatności, które mogłyby zostać użyte przez osoby z nieuczciwymi zamiarami, stwarzając ryzyko poważnych strat finansowych dla naszego klienta.

Z uwagi na poufność danych, takie elementy jak nazwy systemów, szczegóły technologiczne oraz punkty końcowe zostały zanonimizowane, a opisy podatności nieco uogólnione.

System oferował różne poziomy subskrypcji: podstawowy, rozszerzony i korporacyjny (nazwy zmienione). Subskrypcja korporacyjna pozwalała użytkownikom na tworzenie grup z różnymi uprawnieniami, co nie było dostępne w niższych planach. Zidentyfikowaliśmy endpoint, który umożliwiał tworzenie grup, jednak nie sprawdzał on, czy użytkownik posiada odpowiedni poziom subskrypcji. Proste zapytanie POST zawierające nazwę grupy, takie jak POST /CreateGroupFree ... {"groupName":"<nazwa>"}, pozwalało na nieautoryzowane tworzenie grup, co automatycznie przypisywało użytkownikowi poziom korporacyjny, bez żadnej weryfikacji.

Podczas dalszej analizy okazało się, że użytkownik, który pierwotnie miał plan rozszerzony, po skorzystaniu z tej podatności nie tylko otrzymywał subskrypcję korporacyjną, ale również zwracano mu koszty wcześniejszej subskrypcji. System nie tylko nie naliczał opłat za upgrade, ale faktycznie zwracał środki, co powodowało nieuzasadnione zwroty i nieautoryzowany dostęp do pełnej funkcjonalności.

Najbardziej krytycznym elementem było to, że możliwość darmowej aktualizacji mogła być wykorzystywana wielokrotnie. Każdy mógł tworzyć kolejne darmowe konta i bezpłatnie podnosić je do poziomu korporacyjnego, co skutkowało znacznymi stratami finansowymi dla klienta.

Podczas dalszych testów odkryliśmy również, że można było dodawać nieograniczoną liczbę członków do grup, co generowało dodatkowe opłaty, bez posiadania aktywnej metody płatności. System był narażony na wycieki zasobów, które były wykorzystywane kosztem klienta.

Innym istotnym problemem była podatność, która umożliwiała przejęcie grupy przez użytkownika z niskimi uprawnieniami. Manipulując zapytaniem POST, użytkownik mógł zapraszać inne osoby jako właścicieli grupy, co w normalnych okolicznościach było niemożliwe. Dzięki temu, nowo dodany właścicieli grupy mógł usunąć oryginalnego właściciela grupy, przejmując nad nią pełną kontrolę.

Odkryliśmy również problemy z funkcjami związanymi ze sztuczną inteligencją, w tym niebezpieczeństwo wycieku promptu systemowego oraz podatność na ataki typu "prompt injection". Te podatności wymagały dalszej, szczegółowej analizy, ale mogły prowadzić do eskalacji zagrożeń.

Ostatnim istotnym problemem był słaby algorytm generowania tokenów JWT, który udało się złamać przy użyciu technik brute force. Choć system implementował pewne mechanizmy losowe, które częściowo zmniejszały ryzyko, była to potencjalna ścieżka do fałszowania sesji użytkowników. Niestety, czas testów nie pozwolił na pełne zbadanie dalszych możliwości eksploatacji tej podatności.

Podsumowując, test penetracyjny wykazał kilka krytycznych podatności w zabezpieczeniach, które mogłyby prowadzić do poważnych strat finansowych oraz naruszenia integralności systemu. Kluczowe problemy dotyczyły nieautoryzowanych aktualizacji subskrypcji, zwrotów za subskrypcje, przejęcia grup przez użytkowników o niskich uprawnieniach oraz podatności na ataki związane z funkcjami AI i słabymi tokenami JWT. Wdrożenie odpowiednich mechanizmów kontroli dostępu, walidacji uprawnień oraz wzmocnienie zabezpieczeń na poziomie API powinno stać się priorytetem w celu zabezpieczenia systemu przed potencjalnymi atakami.

Dobrego dnia!