Jak można było usunąć czyjeś konto Firefox – podatność IDOR w API Mozilli

W interfejsie API Mozilli wykryto podatność Insecure Direct Object Reference (IDOR), która umożliwiała uwierzytelnionemu atakującemu korzystającemu z OAuth (np. logowania przez konto Google) usunięcie konta innego zarejestrowanego przez OAuth użytkownika, znając jedynie jego adres e-mail. Serwer nie weryfikował, czy sesja wysyłająca żądanie usunięcia należy do konta, które ma zostać usunięte.
TLDR:

• Przypadek pokazuje klasyczny problem między uwierzytelnianiem a autoryzacją użytkownika (OWASP Top 10 2025 #1).
• W API Mozilli wykryto podatność typu IDOR, umożliwiającą usunięcie konta innego użytkownika.
• Endpoint do usuwania konta nie sprawdzał, czy sesja należy do konta, które ma zostać usunięte. Konto było usuwane po podaniu adresu e-mail oraz hasła w formie hasha.
• W przypadku kont OAuth hash hasła nie był weryfikowany. Atakujący musiał jedynie zalogować się przez OAuth i zmienić e-mail ofiary w żądaniu API.
• Luka pozwalała ominąć 2FA i trwale usunąć konto użytkownika. Mozilla oceniła podatność jako High, a badacz otrzymał nagrodę bug bounty.

W maju 2025 badacz zgłosił podatność w interfejsie Mozilli do zarządzania kontami. Mowa o kontach do synchronizacji danych między urządzeniami korzystającymi z przeglądarki Firefox. W tym przypadku możliwe było usunięcie konta dowolnego użytkownika wykonując żądanie do API zawierające adres e-mail ofiary oraz hasło w formie hasha. 

Wynika to z faktu, że przy usuwaniu konta użytkownik proszony jest o potwierdzenie tej czynności poprzez podanie swojego hasła:

Gdzie więc leży problem? Pokazany mechanizm pełni tu funkcję dodatkowego zabezpieczenia na uwierzytelnionym już urządzeniu. Dzięki temu gdy udzielimy komuś chwilowego dostępu do naszego komputera (bądź np. ktoś wykradnie nam cookies z tokenem sesji), mimo dostępu do danych konta i części funkcji, taka osoba nie będzie w stanie usunąć naszego profilu. Nie będzie również możliwe wykonanie takiego żądania z wykorzystaniem podatności CSRF.

Jest to jednak bardziej warstwa autoryzacji niż uwierzytelniania, a uwierzytelniania w tym przypadku nie było – żądanie można było wykonać w ramach sesji dowolnego użytkownika (niekoniecznie tego, którego konto usuwamy). Konto było identyfikowane według podanego adresu e-mail, a nie tokenu sesji wysyłanego przez przeglądarkę. Taka podatność pozwalała więc ominąć uwierzytelnianie dwuetapowe (o ile byłoby skonfigurowane na koncie ofiary).

Gdyby atakujący uzyskał dostęp do samego hasha hasła użytkownika, np. wykorzystując podatność SQL injection, byłby w stanie usunąć dowolne konto bez znajomości oryginalnego hasła i bez konieczności przełamywania takiego hasha. Skoro jednak do serwera wysyłany jest hash, to znaczy że prawdopodobnie proces hashowania odbywa się w tym przypadku po stronie klienta. Ale ten obszar zostawiamy chętnym badaczom bug bounty ;-)

Podatność została już na tym etapie zgłoszona. W procesie triage otrzymała status “Informative” z uwagi na istniejącą mimo wszystko konieczność znajomości hasha hasła ofiary. Jednak tam gdzie dostępu chroni hasło, z “pomocą” może przyjść OAuth. Konta założone przez OAuth same w sobie nie posiadają bowiem… hasła. W nieco podobny sposób udało się ominąć uwierzytelnianie w aplikacji Petlibro, o której pisaliśmy już na sekuraku.

Badacz odkrył bowiem, że parametr authPW, w którym przesyłany był hash hasła ofiary, nie jest weryfikowany jeżeli usuwane konto korzysta z OAuth (np. logując się przez Google). Atakujący musi również zalogować się przez OAuth i rozpocząć proces usuwania swojego konta. Następnie wystarczy skorzystać z narzędzia takiego jak Burp Suite by znaleźć żądanie do API:

Wystarczy zmienić e-mail na adres ofiary (zostawiając bez zmian parametr authPW) i konto zostaje usunięte. Jak się okazało, w przypadku OAuth serwer nie weryfikował zgodności hasha z usuwanym profilem. Badacz ocenił znalezioną podatność na Critical (CVSS 9.3). Zespół Mozilli po krótkim doprecyzowaniu nadał status High, ponieważ luka nie pozwalała całkowicie przejąć konta użytkownika, a jedynie je usunąć. Cała komunikacja trwała niewiele ponad tydzień, a za zgłoszenie podatności badacza nagrodzono w ramach programu bug bounty.

Co ciekawe, podobny problem został odkryty już w październiku 2023 r. i występował pod tym samym endpointem, choć w zgłoszeniu wskazano wtedy inną domenę (api-accounts[.]stage[.]mozaws[.]net). Jako skutek podatności wskazano możliwość ominięcia 2FA (o czym wspomnieliśmy wyżej), ale nie sprawdzono co dzieje się przy koncie stworzonym przez OAuth.

Badacz wykonywał żądania bez żadnego uwierzytelnienia. Możliwość wykorzystania tej podatności wciąż ograniczała jednak konieczność podania hasha hasła użytkownika. Zespół Mozilli odpowiedział, że wprowadzono zmiany, dzięki którym endpoint /v1/account/destroy wymagał już tokenu sesyjnego. Wszystko wskazuje więc na to, że zadbano o uwierzytelnienie, ale nie o autoryzację – stąd zgłoszoną w maju 2025 lukę traktujemy jako IDOR.

W tym przypadku nie istnieje skuteczna możliwość ochrony dla użytkownika. Teoretycznie można dla każdego konta tworzyć unikalne loginy (np. aliasy mailowe), aby utrudnić ich odgadnięcie atakującym. Jest to jednak metoda w stylu defense in depth – wdrożenie dodatkowych (pozornie niepotrzebnych) zabezpieczeń, zakładając z góry że poprzednie (standardowe) nie zadziałają. Taki sposób nie zawsze wystarczy, bo np. przy kontach OAuth zdarza się, że są identyfikowane w inny sposób niż przez adres e-mail. A adresy e-mail też można pozyskać, chociażby wykorzystując potencjalną inną podatność.

Nie oznacza to jednoznacznie, że logowanie przez OAuth jest mniej bezpieczne, bo w niektórych usługach jest to jedyny sposób na skonfigurowanie dwuetapowego uwierzytelniania – jeśli natywnie takiej opcji nie umożliwiają. Skuteczna możliwość ochrony leży po stronie programistów – zawsze oprócz uwierzytelniania istotna jest poprawna autoryzacja – zalogowany użytkownik domyślnie nie powinien mieć dostępu do kont innych użytkowników. Problem z tymi mechanizmami jest obecny, co pokazuje pierwszy punkt listy OWASP Top 10 z 2025 r.

Źródła: 

• hackerone.com
• hackerone.com

~Tymoteusz Jóźwiak