eskalacja uprawnień

Eskalacja uprawnień to uzyskanie przez użytkownika albo proces wyższego poziomu uprawnień, niż mu przysługuje. MITRE ATT&CK opisuje ją jako taktykę, w której przeciwnik próbuje zdobyć uprawnienia wyższego poziomu, od konta z dostępem do wybranej funkcji po poziom SYSTEM lub root ^[2]. MITRE zaznacza przy tym, że eskalacja jest skutkiem technicznym, a nie przyczyną błędu; przyczyną bywa na przykład niewłaściwe zarządzanie uprawnieniami, opisane jako słabość CWE-269 ^[1].

Jak działa

Aplikacja najpierw ustala, kim jest użytkownik, czyli przeprowadza uwierzytelnianie. Potem przy każdej operacji powinna sprawdzić, czy wolno mu ją wykonać; to autoryzacja. Eskalacja pojawia się, gdy ta druga kontrola jest pominięta, niepełna albo oparta na danych, które użytkownik może zmienić. OWASP wymienia wśród takich błędów działanie bez zalogowania albo z uprawnieniami większymi niż przewidziane dla zalogowanego użytkownika, na przykład z dostępem administratora ^[4]. Innym wariantem jest manipulacja metadanymi, takimi jak token JWT (JSON Web Token), ciasteczko albo ukryte pole formularza, w celu podniesienia uprawnień ^[4].

Według ATT&CK przeciwnicy wykorzystują w tym celu słabości, błędy konfiguracji i podatności systemu ^[2]. Techniki eskalacji często pokrywają się z technikami utrzymania dostępu ^[2]. MITRE podaje w opisie CWE-269 przykład, który dobrze pokazuje mechanizm: funkcja resetowania hasła dopuszcza role administratora i operatora, ale nie sprawdza roli użytkownika, którego hasło jest zmieniane, więc operator może przejąć konto administratora ^[1]. Kontrola istniała, lecz sprawdzała niewłaściwą rzecz. Z tego powodu OWASP zalicza takie błędy do kategorii A01:2025, w której według zestawienia każda z testowanych aplikacji miała jakąś postać błędnej kontroli dostępu ^[4].

RYS. 1Eskalacja pionowa przez wtyczkę

Rodzaje

Ściągawka OWASP o autoryzacji rozróżnia dwa kierunki ^[3].

OWASP pisze, że eskalacja pozioma jest szczególnie częstą słabością, którą może wykorzystać uwierzytelniony użytkownik ^[3]. Typowym przykładem jest błąd IDOR (Insecure Direct Object Reference), czyli podania identyfikatora cudzego rekordu ^[4]. Poza aplikacjami webowymi mówi się też o eskalacji lokalnej w systemie operacyjnym, od zwykłego konta do SYSTEM lub root ^[2]; w hostingu następuje ona zwykle po zdalnym wykonaniu kodu przez stronę.

W WordPressie

WordPress ma sześć predefiniowanych ról: superadministratora, administratora, redaktora, autora, współpracownika i subskrybenta ^[5]. Subskrybent ma tylko uprawnienie read i może zarządzać wyłącznie swoim profilem, a administrator ma dostęp do wszystkich funkcji administracyjnych pojedynczej witryny ^[5]. Rolę innego użytkownika zmienia uprawnienie promote_users ^[5]. Szerzej opisują to role i uprawnienia użytkowników.

Źródłem eskalacji są zwykle wtyczki i motywy; zob. podatność we wtyczce. Podręcznik wtyczek każe sprawdzać uprawnienia za każdym razem, gdy wtyczka przyjmuje dane od użytkownika, w panelu i na stronie publicznej ^[6]. Służy do tego current_user_can() ^[6], czyli weryfikacja uprawnień. Typowe błędy:

• sprawdzenie zalogowania zamiast uprawnienia, przez co akcję może wywołać każdy zarejestrowany subskrybent; to odmiana braku kontroli uprawnień;
• użycie is_admin() jako zabezpieczenia; funkcja sprawdza tylko, czy żądanie dotyczy panelu, a nie czy użytkownik jest administratorem ^[7], i według notatek użytkowników pod dokumentacją zwraca prawdę także dla żądań do admin-ajax.php ^[7];
• zapis pól profilu bez listy dozwolonych kluczy, czyli mass assignment, który pozwala dopisać rolę;
• brak jednorazowego tokenu nonce, co otwiera drogę do CSRF (Cross-Site Request Forgery) wykonanego rękami administratora.

Szczególnie groźne jest połączenie z otwartą rejestracją. Jeżeli nowe konta dostają rolę subskrybenta, a wtyczka ma błąd eskalacji pionowej, atakujący nie potrzebuje żadnych danych logowania. Dlatego warto kontrolować domyślną rolę nowych użytkowników i wyłączać rejestrację, gdy nie jest potrzebna.

Zagrożenia i skutki

MITRE jako skutek CWE-269 podaje uzyskanie uprawnień albo przejęcie cudzej tożsamości ^[1]. W WordPressie eskalacja do administratora oznacza w praktyce pełną kontrolę nad witryną: administrator może instalować wtyczki ^[5], a przez nie uruchamiać dowolny kod. Typowe następstwa to nieautoryzowane konto administratora jako punkt powrotu, wgrany webshell i tylna furtka w plikach.

Jak się bronić

• Zasada najmniejszych uprawnień. CWE-269 zaleca zasadę najmniejszych uprawnień przy nadawaniu praw oraz wymaganie kilku warunków przed udzieleniem dostępu do zasobu ^[1]. OWASP dodaje, że stosuje się ją w pionie i w poziomie ^[3].
• Odmowa domyślna. Poza zasobami publicznymi dostęp powinien być domyślnie zabroniony ^[4].
• Kontrola przy każdym żądaniu. Uprawnienia sprawdza się przy każdym żądaniu, niezależnie od tego, czy wysłał je skrypt AJAX, serwer czy inne źródło ^[3].
• Kontrola po stronie serwera i sprawdzanie własności rekordu w modelu danych ^[4].
• Przegląd kont. Regularne przeglądanie listy administratorów i usuwanie nieznanych kont ^[8].

Historia i przykłady

W 2023 roku atakujący wykorzystywali lukę zero-day CVE-2023-3460 we wtyczce Ultimate Member ^[8]. Singapurska agencja CSA ostrzegła 6 lipca 2023 roku, że błąd pozwala nieuwierzytelnionemu atakującemu tworzyć konta z uprawnieniami administratora, dotyczy wersji 2.6.6 i starszych i ma ocenę CVSS 9,8 ^[8]. Była to więc eskalacja uprawnień połączona z podatnością wykorzystywaną bez uwierzytelnienia. Agencja zaleciła aktualizację, przegląd administratorów z usunięciem nieznanych kont i zmianę haseł wszystkich użytkowników ^[8].