Trywialna podatność w FortiWeb Fabric Connector pozwalająca na obejście uwierzytelniania – FortMajeure

W tym tygodniu, na sekuraku, ogłaszamy tydzień fortinetowy. Przybliżamy już drugą podatność w oprogramowaniu tego producenta. Tym razem chodzi o FortMajeure (w wolnym tłumaczeniu: siła wyższa), która otrzymała identyfikator CVE-2025-52970. Wyceniona na 7.7 w skali CVSS, FortMajeure pozwala na obejście procesu uwierzytelniania. Atakujący jest w stanie uzyskać dostęp do panelu FortiWeb, preparując odpowiednio zapytanie.

TLDR:

• @0x_shaq, badacz bezpieczeństwa, który ostatnio równolegle do @SinSingology odkrył lukę w FortiWeb Fabric Connector opublikował szczegóły podatności FortMajeure. (CVE-2025-52970)
• Podatność pozwala na obejście uwierzytelniania poprzez spreparowane ciasteczko sesyjne i dotyka FortiWeba.
• Błąd tkwi w zbyt pochopnym zaufaniu do danych pochodzących od użytkownika.

Nie napiszemy nic szczególnego stwierdzając, że błędy w uwierzytelnieniu są szczególnie niebezpieczne. Po pierwsze sam dostęp do funkcjonalności przeznaczonej dla niewielkiej grupy autoryzowanych użytkowników jest poważnym naruszeniem ujawniającym poufne informacje. Zalogowani użytkownicy zwykle mają dostęp do szerszej funkcjonalności, która może skrywać kolejne podatności. W rozwiązaniach bezpieczeństwa, uwierzytelnianie musi być zrealizowane nad wyraz poprawnie.

W przypadku opisywanej luki, rozwiązanie, które miało być niemal kuloodporne, okazało się dziurą w płocie, która powoduje, że przestaje on pełnić jakąkolwiek funkcję. Aby dobrze oddać ideę błędu, z którym mamy styczność, oddajmy na chwilę głos badaczowi:

> Fort-Majeure represents the kind of silent failure that wasn’t meant to happen — where a system built to protect ends up trusting nothing as everything.

Podatność występuje, ponieważ dochodzi do sytuacji out-of-bound read (odczytu spoza założonego miejsca w pamięci). Aby zrozumieć o co chodzi dokładnie, trzeba wiedzieć, że ciasteczko sesyjne składa się z trzech elementów:

1. Wartości Era
2. Części właściwej (payload), która zawiera informacje o użytkowniku 
3. Podpisanego przy pomocy sekretu i algorytmu HMAC-sha1 – szyfrogramu części 2 czyli payloadu. Szyfrowane wykorzystuje ten sam sekret co podpis. 

Przykładowe ciasteczko przedstawione przez badacza wygląda następująco:

APSCOOKIE_FWEB_8672793038565212270=Era=0&Payload=WBMi/LiqL9kMv5cas1WGGllbY2ehe9N98VN6szVLYhAfcAC+SFOpkVw5AbY2SgKP%0aEmAhJuYrSgJOaIPBUmz2rk/+fDhHldpZ8SGBG3NaeB2Rajs2rcsHwQ==%0a&AuthHash=Bnbx+Plvdm9anOc2zabqhFZR36U=%0a

Kryptografia, zwłaszcza ta bardziej skomplikowana powinna rozwiązać niemal każdy problem bezpieczeństwa, prawda? No tak nie bardzo. 

> If you think cryptography will solve your problem, either you don’t understand cryptography, or you don’t understand your problem. (Peter G. Neumann)

Zwłaszcza, jeśli do walidacji poprawności podpisu wykorzystuje się klucze, których indeks podaje użytkownik. A potem ten indeks nie jest nigdzie walidowany. 

To doprowadza do sytuacji, w której atakujący może wskazać miejsce w pamięci wykraczające poza przewidziane przez programistów obszary. 

Jak można zaobserwować na rysunku 2, odpowiednia manipulacja parametrem Era doprowadzi do wczytania bajtów zerowych i wykorzystania ich do walidacji ciasteczka. To efektywnie eliminuje jakąkolwiek entropię kluczy (i IV), która jest konieczna do bezpiecznego działania mechanizmów kryptograficznych. Innymi słowy, podając Era z zakresu [2,9] atakujący może trafić na sytuację, w której zna klucz wykorzystany do zaszyfrowania i podpisania payloadu – składa się on… z samych zer.

@0x_shaq zaprezentował działanie pełnego eksploita PoC, który wykorzystuje fakt możliwości podrobienia ciasteczek z wykorzystaniem zerowego klucza. Na razie jego kod nie został opublikowany, ale pewnie wydarzy się to w nieodległej przyszłości. Korzystając z endpointu /ws/cli/open był on w stanie uzyskać połączenie z konsolą:

Należy wspomnieć jeszcze o ograniczeniach – atakujący musi odgadnąć jedną z wartości w przesyłanym ciasteczku (ale nie wykracza ona poza 30). Drugi problem, znacznie ograniczający działanie eksploitu, to fakt, że celem musi być użytkownik posiadający aktywną sesję na urządzeniu. Ten drugi czynnik znacznie obniża przydatność tego błędu.

Chociaż prezentowana podatność nie jest skomplikowana, doskonale pokazuje jak bardzo rozbudowane mechanizmy bezpieczeństwa mogą zostać pokonane przez jeden brak sprawdzenia zakresu. A przecież tak trywialny błąd zostałby odkryty nawet poprzez wykorzystanie naiwnego i niezbyt skomplikowanego mechanizmu fuzzingu, korzystającego np. z algorytmów genetycznych. Badaczowi jak zwykle gratulujemy ciekawego odkrycia, a Czytelnikom zalecamy aktualizację do poprawionych wersji. 

~Black Hat Logan