Odkryto krytyczną lukę wtyczki LiteSpeed Cache dla WordPress

Badacze z dziedziny cyberbezpieczeństwa odkryli kolejną krytyczną podatność w wtyczce LiteSpeed Cache dla WordPress, która umożliwia nieuwierzytelnionym użytkownikom przejęcie kont użytkowników. Podatność ta, oznaczona jako CVE-2024-44000 (ocena CVSS: 7.5), wpływa na wersje przed 6.4.1, włącznie, i została naprawiona w wersji 6.5.0.1.
Według badaczy firmy Patchstack: „Wtyczka boryka się z podatnością na przejęcie konta nieuwierzytelnionego użytkownika, co umożliwia dowolnemu nieuwierzytelnionemu gościowi uzyskanie autoryzacji dostępu do dowolnych zalogowanych użytkowników, a w najgorszym przypadku uzyskanie roli administratora, po czym można przesłać i zainstalować złośliwe wtyczki”.
Podatność ta została odkryta podczas obszernego badania wtyczki, które wcześniej doprowadziło do zidentyfikowania krytycznej podatności eskalacji uprawnień (CVE-2024-28000, ocena CVSS: 9.8). LiteSpeed Cache to popularna wtyczka do buforowania w ekosystemie WordPress, używana w ponad 5 milionach aktywnych instalacji.
Nowa podatność wynika z faktu, że plik dziennika debugowania o nazwie „/wp-content/debug.log” jest publicznie dostępny, co umożliwia nieuwierzytelnionym atakującym wyświetlanie potencjalnie wrażliwych informacji zawartych w pliku.
Może to również obejmować informacje o plikach cookie użytkownika zawarte w nagłówkach odpowiedzi HTTP, co efektywnie pozwala użytkownikom zalogować się do podatnej witryny z dowolną aktywną sesją.
Podatność ta ma niższy stopień powagi, ponieważ konieczne jest, aby funkcja debugowania była włączona na stronie WordPress. Alternatywnie, może to również dotyczyć witryn, które w pewnym momencie aktywowały funkcję dziennika debugowania, ale nie usunęły pliku debugowania.
Ważne jest zauważenie, że ta funkcja jest domyślnie wyłączona. Naprawa problemu polega na przeniesieniu pliku dziennika do dedykowanego folderu w folderze wtyczki LiteSpeed („/wp-content/litespeed/debug/”), losowaniu nazw plików i rezygnacji z opcji logowania plików cookie.
Zaleca się sprawdzenie instalacji pod kątem obecności „/wp-content/debug.log” i podjęcie kroków w celu ich usunięcia, jeśli funkcja debugowania została (lub była) włączona.
Zaleca się również ustawienie reguły .htaccess, aby zablokować bezpośredni dostęp do plików dziennika, ponieważ złośliwi aktorzy mogą nadal bezpośrednio uzyskać dostęp do nowego pliku dziennika, jeśli znają jego nową nazwę za pomocą metody prób i błędów.
„Ta podatność podkreśla krytyczne znaczenie zapewnienia bezpieczeństwa procesu dziennika debugowania, danych, które nie powinny być logowane, oraz zarządzania plikiem dziennika debugowania” – powiedział Rafie Muhammad z firmy Patchstack.

Spodobał Ci się ten artykuł? Śledź nas na Twitterze i LinkedIn, aby przeczytać więcej naszej ekskluzywnej treści.