Podatności Bulwark Webmail

W Bulwark Webmail przed wersją 1.9.2 nieuwierzytelniony endpoint POST /api/fetch-ical waliduje nazwę hosta jednym zapytaniem DNS, a następnie wykonuje osobne zapytanie przy połączeniu. Atakujący kontrolujący autorytatywny DNS może zwrócić adres publiczny podczas walidacji, a następnie przemapować nazwę na adres loopback, prywatny, link-local lub metadanych chmury, powodując zwrócenie do 10 MB wewnętrznej odpowiedzi HTTP/HTTPS.

W Bulwark Webmail przed wersją 1.4.11 funkcja getClientIP() ufa pierwszemu (najbardziej lewemu) wpisowi nagłówka X-Forwarded-For, który jest w pełni kontrolowany przez klienta. Atakujący może sfałszować źródłowy adres IP, aby ominąć ograniczniki szybkości oparte na IP (umożliwiając ataki brute-force na panel administracyjny) lub sfałszować wpisy w dzienniku audytu.

Bulwark Webmail przed wersją 1.4.11 ustawia nagłówek Content-Security-Policy-Report-Only zamiast egzekwującego Content-Security-Policy. Oznacza to, że ataki XSS są logowane, ale nie blokowane, co pozwala na wykonanie dowolnego JavaScript przez spreparowany HTML wiadomości e-mail.

W Bulwark Webmail przed wersją 1.4.11 weryfikacja podpisu S/MIME nie sprawdzała łańcucha zaufania certyfikatu, przez co każdy e-mail podpisany samopodpisanym lub niezaufanym certyfikatem był wyświetlany jako mający ważny podpis.

Bulwark Webmail przed wersją 1.4.10 zawiera podatność w funkcji verifyIdentity(), która zwracała true przy braku ciasteczek sesyjnych. Pozwala to nieuwierzytelnionym atakującym na ominięcie zabezpieczeń i dostęp do endpointu /api/settings, umożliwiając modyfikację ustawień użytkownika.

Bulwark Webmail przed wersją 1.4.10 ujawniał hasło użytkownika w postaci jawnego tekstu w odpowiedzi JSON z endpointu GET /api/auth/session. To narażało dane logowania na przechwycenie przez przeglądarkę, lokalne pamięci podręczne i proxy sieciowe.