Podatności Grav Login plugin

Wtyczka Grav Login przed wersją 3.8.11 akceptuje zadanie login.regenerate2FASecret przez parametr URI task w żądaniu GET bez wymaganego nonce, kontroli Origin lub Referer. Przy domyślnej polityce SameSite=Lax, nawigacja z innej strony może wywołać taskRegenerate2FASecret() w sesji zalogowanego użytkownika, nadpisać jego sekret TOTP i wymusić ponowną rejestrację 2FA.

Wtyczka Grav Login (grav-plugin-login) w wersjach <= 3.8.11 zawiera lukę w eskalacji uprawnień w uwierzytelnionym handlerze aktualizacji profilu (processUserProfile(), zadanie update_user). W przeciwieństwie do handlera rejestracji, ten handler nie usuwa pól uprawnień ('groups','access') z danych formularza przesłanych przez użytkownika przed ich zapisaniem. Gdy administrator dodał 'groups' i/lub 'access' do plugins.login.user_registration.fields i używane jest domyślne konto 'regular'/DataUser, niskouprzywilejowany uwierzytelniony użytkownik może wysłać spreparowane dane formularza profilu (np. access[admin][super]=true), aby eskalować do super-admina, umożliwiając dostęp do panelu admina, nadużycie schedulera (RCE) i ewaluację Twig. Naprawione w wersji 3.8.12.

Wtyczka Grav Login przed wersją 1.0.16 nie weryfikuje poziomu uprawnień docelowego konta w handlerze onApiUserListRowAction unlock. Atakujący z uprawnieniem api.users.write może wyczyścić liczniki blokady logowania na kontach admin.super, usuwając ochronę przed atakami brute-force na konta o najwyższych uprawnieniach.

Grav to platforma internetowa oparta na plikach. W wersjach przed 2.0.0-beta.2 metoda Login::register() wtyczki Login akceptuje grupy i pola dostępu kontrolowane przez atakującego bez walidacji po stronie serwera.

Wtyczka getgrav/grav-plugin-login Composer przed wersją 3.9.1 (używana przez Grav) porównuje tokeny resetowania hasła i aktywacji konta za pomocą nie-stałoczasowego porównania === zamiast hash_equals() w classes/Controller.php (taskReset()) i login.php (obsługa aktywacji). Ponieważ punkt końcowy przesyłania tokena (taskReset) nie ma również ograniczenia szybkości, atakujący może w zasadzie wysyłać wielokrotne zgadywania tokenów dla znanej nazwy użytkownika i wykorzystać różnice czasowe, aby próbować odzyskać prawidłowy token, chociaż dostawca ocenia praktyczną możliwość wykorzystania jako niską i nie zademonstrowano ataku sieciowego od końca do końca.

Wtyczka Grav Login (getgrav/grav-plugin-login) przed wersją 3.9.1 jest podatna na enumerację adresów e-mail. Metoda register() w classes/Login.php wyrzuca odrębny wyjątek (EMAIL_NOT_AVAILABLE), gdy podany adres e-mail już należy do istniejącego konta, podczas gdy w przeciwnym razie rejestracja przebiega dalej. Ponieważ punkt końcowy rejestracji nie ma ograniczeń tempa, atakujący może enumerować, które adresy e-mail mają konta na stronie, zgadując jedno żądanie na raz.

Wtyczka Grav Login przed wersją 3.8.11 zawiera podatność w zadaniu login.regenerate2FASecret, które sprawdza tylko istnienie użytkownika w sesji oczekującej, a nie wymaga autoryzacji $user->authorized. Po podaniu poprawnego hasła ofiary, atakujący może wywołać taskRegenerate2FASecret() podczas oczekującego wyzwania TOTP, nadpisać twofa_secret, odczytać nowy sekret z odpowiedzi, obliczyć ważny kod i ukończyć uwierzytelnianie bez drugiego czynnika ofiary. Problem naprawiono w wersji 3.8.11.

Wtyczka Grav Login przed wersją 3.8.13 zawiera podatność na niewystarczające wygaśnięcie sesji w pliku TokenStorage.php, gdzie metoda findTriplet() nieprawidłowo waliduje znaczniki czasu tokenów Remember Me. Atakujący z przechwyconym ciasteczkiem Remember Me może uwierzytelniać się w nieskończoność, zamiast przez skonfigurowany okres limitu czasu, ponieważ sprawdzanie wygaśnięcia porównuje tablicę z wartością skalarną, co w PHP zawsze daje nieprawidłowy wynik.

Wtyczka Grav Login przed wersją 3.8.11 zawiera podatność na fałszerstwo żądania międzywitrynowego (CSRF) w zadaniu frontendowym login.regenerate2FASecret. Atakujący może nakłonić zalogowanego użytkownika do odwiedzenia złośliwej strony, co spowoduje wygenerowanie nowego sekretu TOTP bez wymaganego tokena CSRF lub weryfikacji nagłówka Origin/Referer, unieważniając dotychczasowy klucz uwierzytelniania dwuskładnikowego.