Podatności Ech0

Ech0 przed wersją 4.4.3 nie egzekwuje autoryzacji opartej na zakresach na dziewięciu endpointach panelu administracyjnego komentarzy, co pozwala tokenom dostępu z minimalnymi zakresami na wykonywanie pełnych operacji moderacji komentarzy. Atakujący z tokenem o ograniczonym zakresie może listować, zatwierdzać, odrzucać, usuwać komentarze oraz modyfikować ustawienia systemu komentarzy, bezpośrednio uzyskując dostęp do niechronionych endpointów panelu.

Ech0 przed wersją 4.4.3 nie posiada kontroli autoryzacji na endpointach dzienników systemowych, co pozwala każdemu uwierzytelnionemu użytkownikowi niebędącemu administratorem na odczyt i strumieniowanie wszystkich logów serwera. Atakujący mogą uzyskać dostęp do historycznych logów i strumieni logów w czasie rzeczywistym przez GET /api/system/logs, GET /api/system/logs/stream oraz WS /ws/system/logs, aby zebrać dane rozpoznawcze, w tym wewnętrzne ścieżki plików, ślady błędów i stan aplikacji.

Ech0 w wersji 4.3.4 i wcześniejszych nie egzekwuje w sposób niezawodny ograniczeń zakresu tokenów dostępu (najmniejszych uprawnień) na kilku uprzywilejowanych trasach administracyjnych. Wiele punktów końcowych (np. /api/inbox, /api/panel/comments, /api/backup/export) pomija sprawdzanie zakresu i autoryzuje tylko na podstawie roli administratora, a moduł eksportu kopii zapasowej całkowicie ignoruje metadane zakresu tokena. Atakujący posiadający celowo ograniczony (niski zakres) token administratora może uzyskać dostęp do szerszej funkcjonalności, w tym do skrzynki odbiorczej i eksportu pełnej kopii bazy danych ZIP. Poprawiono w wersji 4.4.3.

Ech0 przed wersją 4.5.1 zawiera podatność na obejście autoryzacji, gdzie tokeny sesji pomijają walidację zakresu w oprogramowaniu pośrednim RequireScopes, umożliwiając zalogowanym nie-administratorom dostęp do punktów końcowych administratora. Atakujący mogą czytać logi systemowe, statystyki odwiedzin, e-maile użytkowników i subskrybować na żywo logi WebSocket, wysyłając uwierzytelnione tokeny sesji do niechronionych punktów końcowych.

Ech0 przed wersją 4.7.3 nie unieważnia poprawnie tokenów dostępu utworzonych z opcją nigdy nie wygasają, umożliwiając atakującym utrzymanie ciągłego uwierzytelnionego dostępu po kradzieży tokena. Trzy niezależne mechanizmy unieważniania zawodzą: wylogowanie powoduje panikę przy polu ExpiresAt równym nil, RevokeToken pomija, gdy remainTTL wynosi zero, a usunięcie przez administratora nie umieszcza JTI na czarnej liście, pozostawiając skradzione tokeny kryptograficznie ważne aż do rotacji sekretu JWT.

Ech0 do wersji 4.5.6 zawiera podatność w walidacji URI przekierowania OAuth w funkcji parseAndValidateClientRedirect (internal/service/auth/auth.go), która porównuje tylko schemat i host URI redirect_uri dostarczonego przez klienta z listą dozwoloną skonfigurowaną przez administratora, ignorując ścieżkę, zapytanie i fragment. redirect_uri jest osadzane w podpisanym JWT stanu podczas logowania bez walidacji. Atakujący może skonstruować redirect_uri, którego host pasuje do dozwolonego pochodzenia, ale ścieżka jest kontrolowana przez atakującego; po wymianie OAuth ofiara jest przekierowywana na tę ścieżkę z jednorazowym kodem wymiany w ciągu zapytania. Jeśli kod wycieknie (np. przez Referer, analitykę lub otwarte przekierowanie na tym hoście), atakujący może go wymienić na publicznym punkcie końcowym POST /api/auth/exchange na tokeny dostępu i odświeżania ofiary. Poprawiono w wersji 4.7.3.

Wersje Ech0 przed 4.7.3 ujawniają adresy e-mail komentatorów-gości poprzez publiczne endpointy API z powodu nieprawidłowych tagów serializacji JSON w modelu Comment. Nieuwierzytelnieni atakujący mogą zebrać wszystkie e-maile komentatorów, wywołując endpointy /api/comments i /api/comments/public bez uwierzytelnienia.

Ech0 przed wersją 4.7.3 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w funkcji fetchPeerConnectInfo, która używa niezweryfikowanych żądań HTTP zamiast bezpiecznych metod z walidacją URL. Uwierzytelnieni atakujący mogą podać dowolne adresy URL, aby uzyskać dostęp do wewnętrznych usług i punktów końcowych metadanych chmury, wyzwalając kontrole stanu połączenia lub operacje połączenia peer.

Ech0 przed wersją 4.4.3 chroni endpoint PUT /user zakresem profile:read, który jest tylko do odczytu, ale pozwala na operacje zapisu, w tym zmianę hasła. Atakujący z tokenem dostępu profile:read administratora może zmienić hasło administratora i zalogować się, uzyskując nieograniczony token sesji, który omija wszystkie ograniczenia zakresów.

Ech0 przed wersją 4.4.3 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w funkcji validateWebhookURL (webhook_setting_service.go), która waliduje tylko dosłowne adresy IP za pomocą net.ParseIP() i nie odrzuca nazw hostów, które rozwiązują się na prywatne lub wewnętrzne adresy IP (np. 169.254.169.254.nip.io). Atakujący z uprawnieniami administratora może utworzyć webhook z taką nazwą hosta, aby ominąć walidację i spowodować, że serwer będzie wysyłać żądania do wewnętrznych usług, punktów końcowych metadanych chmury i zasobów sieci prywatnej. Problem został naprawiony w wersji 4.4.3.

Ech0 przed wersją 4.4.3 zawiera podatność na trwały cross-site scripting (XSS) w endpointcie przesyłania plików, który waliduje Content-Type tylko na podstawie nagłówków dostarczonych przez klienta, bez inspekcji po stronie serwera. Atakujący z uprawnieniami administratora może przesłać pliki SVG lub HTML zawierające JavaScript, który wykonuje się w kontekście aplikacji, gdy uzyska do nich dostęp dowolny użytkownik, umożliwiając przejęcie sesji i eksfiltrację danych.

Ech0 przed wersją 4.7.3 zawiera podatność na ominięcie uwierzytelniania w endpointcie PUT /api/echo/like/:id, która pozwala nieuwierzytelnionym atakującym na zwiększanie wskaźników zaangażowania bez weryfikacji tożsamości lub ograniczeń tempa. Atakujący mogą wysyłać powtarzane żądania, aby sztucznie zawyżyć pole fav_count dla dowolnego znanego identyfikatora echa, co narusza integralność wskaźników zaangażowania i systemów rankingu społecznościowego.

Ech0 przed wersją 4.4.3 nie egzekwuje autoryzacji administratora na endpointach dzienników pulpitu, co pozwala każdemu uwierzytelnionemu użytkownikowi na dostęp do logów systemowych. Atakujący z ważną sesją użytkownika mogą wysyłać zapytania do GET /api/system/logs i subskrybować strumienie logów SSE i WebSocket, aby uzyskać wrażliwe dane operacyjne, w tym ścieżki plików, ślady stosu i wewnętrzne adresy URL.

Ech0 przed wersją 4.7.3 zawiera podatność na trwały cross-site scripting (XSS) w publicznym kanale RSS, gdzie nazwy tagów i treść markdown są renderowane bez escapowania HTML. Atakujący z uprawnieniami administratora mogą wstrzyknąć złośliwe nazwy tagów lub surowy HTML w treści echa, który wykonuje się jako JavaScript w czytnikach RSS renderujących podsumowania typu HTML, co dotyka anonimowych subskrybentów i innych użytkowników.

Ech0 do wersji 4.5.6 rejestruje endpoint PUT /api/echo/like/:id w publicznej grupie routerów bez uwierzytelniania i ograniczeń tempa. Nieuwierzytelnieni atakujący mogą zwiększać licznik fav_count dowolnego echa (w tym prywatnych) poprzez podanie jego UUID, które można zebrać z publicznego kanału GET /api/echo/page. Powtarzane żądania są akceptowane bez deduplikacji, każde wywołuje zapis do bazy danych i unieważnienie czterech kluczy pamięci podręcznej, co pozwala atakującym zawyżać wskaźniki popularności i zwiększać obciążenie bazy danych i pamięci podręcznej. Naprawione w wersji 4.7.3.

Ech0 przed wersją 5.0.1 nie nakłada żadnych ograniczeń na rozmiar lub kształt nagłówka Accept-Language przetwarzanego przez oprogramowanie pośrednie i18n, które działa na każdym żądaniu HTTP. Nagłówek jest przekazywany bez filtrowania do NewLocalizer z go-i18n, który wewnętrznie wywołuje golang.org/x/text/language.ParseAcceptLanguage. Obejście CVE-2022-32149 w x/text ogranicza znaki '-', ale nie znaki '_', które parser aliasuje do '-', umożliwiając wyzwolenie parsowania o złożoności kwadratowej przy użyciu dużego nagłówka (do domyślnego 1 MiB Go) zbudowanego z separatorów podkreślenia. Nieuwierzytelniony atakujący może wysyłać takie żądania, aby zużywać około 1,5 sekundy CPU każde, a równoczesne żądania mogą nasycić serwer wielordzeniowy (odmowa usługi).