Niewidzialne logowanie do Azure: gdy logi milczą, a atakujący działa

Gdy logi przestają być dowodem

Kolejne przypadki pominięcia logów w Entra ID to dobra okazja, by zadać sobie pytanie: czy w naszym środowisku logi w ogóle są źródłem prawdy, na którym możemy polegać?

Wyobraźmy sobie, że ktoś wchodzi do naszego biura, przegląda dokumenty, a potem wychodzi – i nie ma po nim żadnego śladu w rejestrze wejść. Właśnie taki efekt osiągały dwa nowo ujawnione błędy w Microsoft Entra ID: atakujący mógł zalogować się na konto użytkownika i otrzymać w pełni działający token dostępu, a w logach nie pojawiał się żaden ślad tej aktywności.

Cztery podatności, jeden problem systemowy

Odkrycia dokonał badacz znany jako nyxgeek. To już trzecia i czwarta podobna podatność, którą znalazł w ciągu trzech lat – wszystkie w tym samym, krytycznym miejscu: dziennikach logowań Entra ID. Poprzednie dwa błędy pozwalały „sprawdzić" hasło bez zostawienia śladu, ale nie zwracały tokena. Tym razem atakujący otrzymywał pełnoprawny token, który pozwalał mu działać w środowisku ofiary. Oba błędy zostały już naprawione przez Microsoft.

Jak działały podatności?

Nowa podatność, nazwana GraphGoblin, wykorzystywała parametr scope w przepływie OAuth2 ROPC (Resource Owner Password Credentials). Zamiast podawać nieprawidłową wartość, badacz odkrył, że wielokrotne powtórzenie prawidłowej wartości (np. openid openid openid...) kilkadziesiąt tysięcy razy powodowało pomyślne uwierzytelnienie i zwrócenie tokena, bez żadnego wpisu w dziennikach logowań.
Drugi błąd był jeszcze prostszy: ustawienie nagłówka User-Agent na ciąg 50 000 znaków w całości również pomijało rejestrowanie zdarzenia logowania. Ta sama przyczyna i ten sam skutek: parser nie znajdował niczego nieprawidłowego w samej wartości, a następnie próbował ją zapisać do bazy danych, prawdopodobnie przepełniając limit kolumny SQL. Skutkiem było ciche niepowodzenie operacji INSERT, czyli brak logu, przy jednoczesnym pomyślnym uwierzytelnieniu.

Fuzzing zamiast zaawansowanego hackingu

Niepokojący jest szerszy kontekst: żadna z czterech podatności nie wymagała zaawansowanej wiedzy. Wszystkie zostały odkryte z wykorzystaniem metody testowania fuzzing ukierunkowanej na sprawdzanie standardowych parametrów procesu logowania.

Logi jako źródło prawdy – czy na pewno?

Ta historia skłania do szerszej refleksji. Logi traktujemy często jako ostateczne źródło prawdy, szczególnie gdy pochodzą z dojrzałego, szeroko stosowanego produktu. Tymczasem sam mechanizm zapisu logów może zawierać błędy, które są trudne do wykrycia w standardowym procesie zapewnienia bezpieczeństwa.

Błędy, których testy często nie widzą

Problemy tego typu są zwykle niewidoczne podczas pentestów. Tester bardzo często może nie mieć dostępu do logów po stronie testowanego systemu – sprawdza jedynie zachowanie aplikacji od zewnątrz, nie mechanizmy jej wewnętrznego zapisu. Takie błędy wychodzą na jaw dopiero podczas przeglądu kodu (code review), choć i tam nie zawsze są priorytetem. Warto przy projektowaniu i weryfikacji mechanizmów logowania sięgnąć po OWASP ASVS – w wersji 5.0, zagadnieniom tym poświęcony jest rozdział V16.

Złudne poczucie bezpieczeństwa

Logi są trochę jak polisa ubezpieczeniowa – po jej wykupieniu rzadko o niej myślimy, dopóki coś się nie wydarzy. Sama w sobie nie chroni przed incydentem ani jego skutkami, ale daje poczucie bezpieczeństwa – czasem złudne. Dlatego nie warto ślepo ufać zapewnieniom dostawców o bezpieczeństwie ich produktów i skupiać się przede wszystkim na budowaniu wielu warstw zabezpieczeń oraz zmniejszaniu powierzchni ataku.

Analiza logów: kluczowy element obrony

Pamiętajmy również, że samo zbieranie logów nie wystarczy. Żeby miały realną wartość, trzeba je analizować, korelować i aktywnie szukać anomalii. Bez tego logi są jedynie miejscem, w którym – być może – uda się znaleźć informacje o tym, co już się wydarzyło.

Retencja danych – słaby punkt

Osobnym, często pomijanym zagadnieniem jest retencja i przechowywanie logów. Logi nie powinny być trzymane wyłącznie w jednym miejscu – warto je eksportować do odrębnej usługi, gdzie będą przechowywane przez dłuższy czas. Dla przykładu: dzienniki logowań Entra ID nawet przy najwyższych planach subskrypcyjnych są domyślnie dostępne przez 7-30 dni, a w niektórych przypadkach maksymalnie przez 90 dni.

Ukryte ryzyko w Twoim środowisku

W typowej organizacji warto zadać sobie pytanie o własne środowisko: gdzie logi w ogóle nie są zbierane? Kto ma do nich dostęp i czy można je zmodyfikować lub usunąć bez śladu? O niedokładności logów lub ich braku orientujemy się bowiem najczęściej dopiero w trakcie incydentu – a to najgorszy możliwy moment na takie odkrycie.

Źródła

Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found – TrustedSec
OWASP ASVS 5.0, rozdział V16

Partner technologiczny: