Podatności phpMyFAQ

phpMyFAQ przed wersją 4.1.7 zawiera podatność brute-force w kroku uwierzytelniania dwuskładnikowego, gdzie licznik nieudanych prób jest powiązany z sesją i resetowany po każdym pomyślnym ponownym uwierzytelnieniu hasłem. Atakujący z ważnym hasłem może ominąć limit pięciu prób, uzyskując nowy ciasteczko sesji i wielokrotnie ponownie uwierzytelniając się, aby zresetować licznik, co umożliwia nieograniczone zgadywanie kodów TOTP.

phpMyFAQ w wersjach 3.1.0 do 4.1.6 zawiera podatność obejścia uwierzytelniania w funkcji AuthLdap::create(). Gdy uwierzytelnianie LDAP jest włączone, po pomyślnym wiązaniu LDAP kod wywołuje User::setStatus('active') bezwarunkowo, co nadpisuje kolumnę account_status istniejącego lokalnego konta z 'blocked' na 'active'. W rezultacie użytkownik, którego lokalne konto phpMyFAQ zostało administracyjnie zablokowane, może przywrócić swoje konto i zalogować się, uwierzytelniając się przez LDAP. Zmiana stanu nie jest logowana, więc administratorzy nie mogą wykryć, że blokada została nadpisana. Poprawiono w wersji 4.1.7.

phpMyFAQ przed wersją 4.1.7 zawiera podatność na ominięcie uwierzytelniania w SetupController, która pozwala nieuwierzytelnionym atakującym na uruchamianie migracji bazy danych i tworzenie kopii zapasowych konfiguracji, gdy tryb konserwacji jest włączony. Atakujący mogą wywołać punkty POST /api/setup/update-database i POST /api/setup/backup, aby wykonać aktualizacje bazy danych, wyłączyć tryb konserwacji i wyodrębnić dane uwierzytelniające bazy danych z wygenerowanych archiwów ZIP.

Podatność w phpMyFAQ przed wersją 4.1.5 pozwala nieuwierzytelnionym atakującym na odczyt nieaktywnych (wersje robocze lub tylko do recenzji) treści FAQ poprzez niespójne filtrowanie w publicznych punktach końcowych API.

phpMyFAQ przed wersją 4.1.5 zawiera podatność na ścieżkowy atak typu path traversal w funkcji concatenatePaths() w pliku Wrapper.php. Użytkownik z uprawnieniami do edycji FAQ może przechowywać HTML z spreparowanymi ścieżkami obrazów, które są przetwarzane podczas generowania PDF. Brak kanonizacji ścieżki i walidacji ograniczenia do katalogu głównego może pozwolić na odczyt plików poza zamierzonym katalogiem treści.

phpMyFAQ przed wersją 4.1.3 zawiera podatność na nieautoryzowane resetowanie haseł w API aktualizacji haseł użytkowników, co pozwala atakującym na zmianę haseł kont bez walidacji tokenów.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na przechowywane ataki typu cross-site scripting w funkcji Utils::parseUrl(). Umożliwia to uwierzytelnionym użytkownikom wstrzykiwanie JavaScriptu za pomocą źle sformatowanych URL-i w komentarzach.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na ujawnienie informacji w metodzie getIdFromSolutionId(), która nie stosuje filtracji uprawnień. Umożliwia to nieautoryzowanym atakującym enumerację zastrzeżonych wpisów FAQ oraz odczyt ich tytułów przez punkt końcowy /solution_id_{id}.html.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na wstrzykiwanie SQL w funkcji CurrentUser::setTokenData, która pozwala uwierzytelnionym atakującym na wykonywanie dowolnych zapytań SQL poprzez wstrzykiwanie złośliwych roszczeń tokenów OAuth.

W phpMyFaq przed wersją 2.9.9 występuje podatność typu CSRF w pliku admin/ajax.config.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność na Cross-Site Request Forgery (CSRF), która umożliwia modyfikację glosariusza.

W phpMyFAQ przed wersją 2.9.9 występuje podatność na atak Cross-Site Request Forgery (CSRF) w pliku admin/stat.main.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność na atak Cross-Site Request Forgery (CSRF) w plikach admin/ajax.attachment.php oraz admin/att.main.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność typu Cross-Site Request Forgery (CSRF) w pliku admin/news.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność typu Cross-Site Request Forgery (CSRF) w pliku admin/stat.adminlog.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność typu Cross-Site Request Forgery (CSRF) w pliku admin/stat.ratings.php.

W phpMyFAQ przed wersją 2.9.9 występuje podatność typu Cross-Site Request Forgery (CSRF) umożliwiająca dodawanie haseł do glosariusza.

phpMyFAQ przed wersją 4.1.6 zawiera podatność na zdalne wykonanie kodu w API konfiguracji. Uwierzytelniony administrator z uprawnieniami CONFIGURATION_EDIT i ATTACHMENT_ADD może manipulować ustawieniem upgrade.lastDownloadedPackage, aby zapisać dowolny plik PHP i uzyskać wykonanie kodu jako użytkownik serwera WWW.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na nieautoryzowany atak SQL injection w metodach BuiltinCaptcha::garbageCollector() i BuiltinCaptcha::saveCaptcha(). Atakujący mogą wykorzystać publiczny punkt końcowy GET /api/captcha, wstrzykując złośliwe nagłówki User-Agent, co prowadzi do wycieku wrażliwych danych.

phpMyFAQ przed wersją 4.1.2 zawiera podatność na niewłaściwe ograniczenie nadmiernych prób uwierzytelnienia w punkcie końcowym /admin/check, który akceptuje dowolne parametry user-id bez powiązania sesji lub limitowania prób. Nieautoryzowani atakujący mogą przeprowadzić atak brute-force na sześciocyfrowy kod TOTP dowolnego użytkownika, omijając uwierzytelnianie dwuskładnikowe i uzyskując pełny dostęp administracyjny.

phpMyFAQ w wersjach przed 2.9.8 nie zabezpiecza odpowiednio przed atakami typu brute-force, które polegają na szybkim próbowaniu wielu haseł podczas logowania.

phpMyFAQ przed wersją 4.1.7 nie stosuje kontroli widoczności nadrzędnych wpisów FAQ przed zwróceniem zasobów podrzędnych, takich jak komentarze i załączniki. Niezalogowani atakujący mogą pobrać treść ograniczonych komentarzy, adresy e-mail komentujących oraz nazwy plików załączników dla wpisów FAQ, do których nie mają bezpośredniego dostępu, poprzez zapytania do endpointów API komentarzy i załączników.

phpMyFAQ przed wersją 4.1.7 nie zapisuje wygenerowanego wyzwania logowania WebAuthn, co pozwala atakującemu na przechwycenie udanej asercji WebAuthn i jej wielokrotne odtwarzanie, aby uwierzytelnić się jako użytkownik bez interakcji z nim.

phpMyFAQ przed wersją 4.1.7, gdy jest skonfigurowany do korzystania z PostgreSQL przez natywne rozszerzenie PHP pgsql, deklaruje nieprawidłowy znak ESCAPE dla LIKE ('=') w backendzie Search/Database/Pgsql.php, podczas gdy escapeLikeWildcards() poprzedza dane wejściowe użytkownika prefiksem '|'. W rezultacie escapowanie znaków wieloznacznych jest nieskuteczne, a znaki % i _ dostarczone przez użytkownika pozostają aktywnymi znakami wieloznacznymi LIKE. Niezalogowany atakujący może przesłać takie znaki w publicznym formularzu wyszukiwania FAQ, aby wymusić maksymalnie szerokie dopasowania wzorców i kosztowne skanowania sekwencyjne, co prowadzi do odmowy usługi. Backend PDO PostgreSQL nie jest dotknięty, a cudzysłowy pozostają escapowane, więc nie umożliwia to wstrzyknięcia SQL przez złamanie cudzysłowów ani eksfiltracji danych.

phpMyFAQ przed wersją 4.1.7 nie egzekwuje prawidłowo uprawnienia CONFIGURATION_EDIT na punktach końcowych API odczytu dla konfiguracji LDAP, Elasticsearch, OpenSearch i pulpitu nawigacyjnego, co pozwala każdemu uwierzytelnionemu użytkownikowi na dostęp do wrażliwych danych administracyjnych. Atakujący mogą pobrać topologię serwera LDAP, nazwy kont bind, bazy wyszukiwania, statystyki indeksów i analitykę witryny, wywołując te punkty końcowe z ważną sesją.

phpMyFAQ przed wersją 4.1.6 nie odpowiednio sanityzuje HTML w odpowiedziach FAQ przed generowaniem plików PDF przez TCPDF. Atakujący z uprawnieniami do tworzenia lub edycji treści FAQ może osadzić tag <img> z atrybutem src wskazującym na lokalny plik w katalogu content/ (np. content/core/config/database.php). Podczas generowania PDF, phpMyFAQ próbuje odczytać wskazany plik; ponieważ nie jest to prawidłowy obraz, błąd jest konwertowany na nieobsłużony wyjątek, którego ślad stosu ujawnia część zawartości pliku każdemu użytkownikowi, który wywoła eksport PDF. Domyślnie ujawniona część jest skrócona, ale większa skonfigurowana wartość może prowadzić do ujawnienia całych plików, w tym danych uwierzytelniających bazy danych.

phpMyFAQ przed wersją 4.1.6 nie sprawdza ustawienia security.enableRegistration w punktach API, co pozwala atakującym na tworzenie kont użytkowników, gdy rejestracja jest wyłączona. Atakujący mogą ominąć ograniczenie rejestracji, wysyłając żądania do punktów POST /api/register lub POST /api/v3.1/register, które nie sprawdzają flagi konfiguracyjnej egzekwowanej przez stronę HTML rejestracji.

phpMyFAQ przed wersją 4.1.7 zawiera podatność obejścia uwierzytelniania dwuskładnikowego, gdzie tokeny remember-me są wydawane przed zakończeniem weryfikacji 2FA. Atakujący z ważnymi poświadczeniami może uzyskać ciasteczko remember-me, pominąć wyzwanie 2FA i odtworzyć ciasteczko, aby uzyskać pełny uwierzytelniony dostęp bez weryfikacji drugiego czynnika.

phpMyFAQ przed wersją 4.1.7 nie sprawdza statusu aktywności w punkcie eksportu PDF, co pozwala nieuwierzytelnionym atakującym na pobieranie metadanych szkiców FAQ. Atakujący mogą uzyskać dostęp do publicznej trasy eksportu PDF z sekwencyjnymi identyfikatorami FAQ, aby uzyskać tytuły, identyfikatory rozwiązań, nazwiska autorów i znaczniki czasu ostatniej aktualizacji nieaktywnych lub nieopublikowanych FAQ.

phpMyFAQ przed wersją 4.1.7 zawiera podatność wstrzykiwania SQL w punktach końcowych tworzenia i aktualizacji glosariusza, spowodowaną obcinaniem escapowanego ciągu przed osadzeniem go w literale SQL. Uwierzytelnieni użytkownicy z uprawnieniami dodawania lub edycji glosariusza mogą stworzyć ładunek z wiszącym backslashem, aby uciec z zamykającego cudzysłowu i wstrzyknąć dowolne polecenia SQL w celu odczytania wrażliwych informacji z bazy danych.

phpMyFAQ przed wersją 4.1.6 zapisuje archiwa ZIP kopii zapasowych treści w katalogu głównym dostępnym przez sieć jako content.zip, ujawniając wrażliwe pliki, w tym dane uwierzytelniające bazy danych. Nieuwierzytelnieni atakujący mogą wykorzystać wyścig współbieżnych żądań, aby pobrać tymczasowy plik ZIP przed jego usunięciem, lub wykorzystać XSS w kontekście administratora, aby wywołać uwierzytelnione kopie zapasowe i pobrać archiwum.

phpMyFAQ przed wersją 4.1.7 przechowuje tokeny resetowania hasła w publicznie dostępnym pliku śledzenia, gdy włączone jest śledzenie użytkowników. Nieuwierzytelnieni atakujący mogą odczytać plik śledzenia w ścieżce content/core/data/trackingDDMMYYYY, aby wyodrębnić tokeny resetowania i odtworzyć je przeciwko API resetowania hasła, przejmując konta użytkowników.

W phpMyFAQ przed wersją 4.1.6 występuje podatność na eskalację uprawnień w funkcji GroupController::updateMembers(). Administratorzy z uprawnieniami do zarządzania grupami mogą dołączyć do grup z wyższymi uprawnieniami bez weryfikacji.

Podatność w phpMyFAQ przed wersją 4.1.6 nie weryfikuje sekwencji ścieżek traversal w polu existing_image podczas aktualizacji kategorii, co pozwala uwierzytelnionym atakującym na usunięcie dowolnych plików poprzez wykorzystanie niedostatecznego oczyszczania w Image::delete(). Atakujący mogą usunąć plik konfiguracyjny database.php, aby wyłączyć bramę instalacyjną i uzyskać dostęp do publicznego kreatora konfiguracji w celu utworzenia nowych kont superadministratora.

phpMyFAQ przed wersją 4.1.5 zawiera podatność na eskalację uprawnień w punkcie końcowym API user/add. Umożliwia ona administratorom delegowanym (niebędącym SuperAdminem) tworzenie kont SuperAdmin, co prowadzi do pełnego przejęcia instancji.

phpMyFAQ przed wersją 4.1.5 zawiera podatność eskalacji uprawnień w metodzie GroupController::updatePermissions, która umożliwia administratorom z uprawnieniami GROUP_EDIT nadawanie grupom dowolnych praw bez weryfikacji, czy sami je posiadają. Delegowany administrator może wykorzystać tę lukę, przypisując grupie, do której należy, wysokowartościowe uprawnienia, dziedzicząc je i eskalując swoje uprawnienia do pełnej kontroli administracyjnej.

phpMyFAQ w wersjach przed 4.1.4 zawiera luki w autoryzacji w punktach końcowych editUser() i updateUserRights(), które pozwalają uwierzytelnionym administratorom na eskalację uprawnień. Użytkownicy, którzy nie są SuperAdminami, ale mają uprawnienia edit_user, mogą ustawić flagę is_superadmin lub przyznać dowolne uprawnienia, co prowadzi do uzyskania dostępu SuperAdmina.

phpMyFAQ przed wersją 4.1.4 używa algorytmu SHA-1 do haszowania haseł załączników. SHA-1 jest kryptograficznie słaby i podatny na ataki kolizyjne od 2017 roku.

phpMyFAQ przed wersją 4.1.1 zawiera podatność na XSS w sanitizerze SVG opartym na regexie. Atakujący z uprawnieniami edit_faq mogą przesłać złośliwy plik SVG, który wykorzystuje kodowanie encji HTML w adresach URL javascript: w atrybutach <a href>, co prowadzi do wykonania dowolnego JavaScriptu i eskalacji uprawnień do pełnego przejęcia konta administratora.

W phpMyFAQ przed wersją 4.1.1 wykryto podatność na ujawnienie informacji w metodzie searchCustomPages(). Funkcja escape() używa real_escape_string(), która nie zabezpiecza przed znakami specjalnymi LIKE (% i _), co umożliwia nieuwierzytelnionemu atakującemu wstrzyknięcie tych znaków i odczytanie nieprzeznaczonych do ujawnienia rekordów.