Podatności OneUptime

Kontrola celu webhooka w OneUptime odrzuca adresy prywatne i pętli zwrotnej podane w formie IPv4 oraz mały zestaw form IPv6, ale nie obsługuje zakresu IPv4-mapped IPv6. Ścieżka dostarczania webhooka wywołuje SSRFProtection.validateWebhookTargetIsSafe, a sprawdzanie literałów hosta w Common/Server/Utils/SSRFProtection.ts, wykonywane przez isBlockedHostnameLiteral, odrzuca prywatne i pętli zwrotnej zakresy IPv4 i testuje wartość IPv6 przeciwko adresowi nieokreślonemu, pętli zwrotnej, prefiksowi link-local i prefiksom unique-local. Wartość taka jak [::ffff:127.0.0.1] nie pasuje do żadnego z nich. Wartość jest również rozpoznawana jako literał adresu, a nie nazwa, więc ścieżka ponownie sprawdzająca adresy uzyskane z rozwiązywania nazw nie jest wykonywana. Klient HTTP traktuje formę zmapowaną jako osadzony adres IPv4 i łączy się z nim, więc uwierzytelniony członek projektu, który może skonfigurować webhook, może skierować serwer do usług pętli zwrotnej, prywatnych zakresów sieciowych i punktów końcowych metadanych link-local, a odpowiedź jest rejestrowana tam, gdzie można odczytać wynik webhooka. Wersja 12.0.7 dodaje obsługę zmapowanego zakresu.

OneUptime to platforma monitorująca open-source. W wersjach przed 10.0.42 serwis Worker udostępnia endpointy do uruchamiania workflowów bez uwierzytelnienia. Atakujący znający identyfikator workflow może uruchomić dowolny workflow z kontrolowanymi danymi wejściowymi, co umożliwia wykonanie kodu JavaScript, nadużycie powiadomień i manipulację danymi.

OneUptime przed wersją 10.0.42 umożliwia nieuwierzytelniony dostęp do punktów końcowych testowania powiadomień i zarządzania numerami telefonów, co pozwala na nadużywanie SMS-ów, połączeń, e-maili i WhatsApp oraz zakup numerów telefonów.

W OneUptime przed wersją 10.0.42 implementacja SAML SSO oddziela weryfikację podpisu od ekstrakcji tożsamości. Atakujący może dodać niepodpisaną asercję z dowolną tożsamością przed prawidłowo podpisaną, co prowadzi do ominięcia uwierzytelniania.

OneUptime przed wersją 10.0.42 rejestruje wiele endpointów API powiadomień bez middleware uwierzytelniającego, podczas gdy podobne endpointy w tym samym kodzie go używają. W połączeniu z wyciekiem projectId z publicznego API Status Page, nieuwierzytelniony atakujący może kupić numery telefonów na koncie Twilio ofiary i usunąć istniejące numery alarmowe.