Podatności Red Hat Quay

W Red Hat Quay znaleziono wadę w API zarządzania triggerami budowania, które nie weryfikuje, czy żądany trigger należy do określonego repozytorium.

W Red Hat Quay użytkownik z włączoną funkcją FEATURE_BUILD_SUPPORT i dostępem do zapisu w repozytorium może wykorzystać podatność SSRF w API budowania, wysyłając złośliwy URL, co powoduje, że builder wykonuje żądania do wewnętrznych adresów sieciowych.

W Red Hat Quay funkcja eksportowanych logów umożliwia nieuwierzytelnionemu atakującemu z ważnym ID pliku pobranie wyeksportowanych logów akcji bez odpowiedniej autoryzacji. ID plików mogą być przechwycone z e-maili lub webhooków.

W Red Hat Quay obsługa webhooka płatności Stripe jest podatna na atak polegający na fałszowaniu zdarzeń billingowych. Nieuwierzytelniony atakujący może wysyłać spreparowane żądania JSON do punktu końcowego /webhooks/stripe bez weryfikacji nagłówka Stripe-Signature.

W Red Hat Quay, gdy klucz SECURITY_SCANNER_V4_PSK nie jest ustawiony, zdalny nieuwierzytelniony atakujący może wysyłać żądania POST do punktu końcowego powiadomień skanera bezpieczeństwa, co pozwala na zalewanie kolejki powiadomień i wstrzykiwanie znaków ścieżki do URL-i API Clair.

W Red Hat Quay administrator dowolnego repozytorium, znając lub zgadując UUID powiadomienia, może odczytać konfigurację powiadomień, w tym wrażliwe dane, takie jak URL-e webhooków, tokeny Slack i adresy e-mail. Może również wyzwalać testowe powiadomienia dla innego repozytorium.

W Red Hat Quay obsługa zewnętrznego uwierzytelniania LDAP nieprawidłowo escapuje nazwę użytkownika, gdy zwracane jest odwołanie LDAP. Atakujący może wstrzyknąć metaznaki filtra LDAP, co umożliwia ataki typu wyrocznia istnienia użytkownika w DN odwołania.

W Red Hat Quay walidacja JWT dla kont robotów federacyjnych i uwierzytelniania SSO ma wiele problemów związanych z weryfikacją grupy odbiorców oraz egzekwowaniem roszczeń azp i sub. Atakujący z ważnie podpisanym tokenem od tego samego dostawcy tożsamości może ominąć skonfigurowane ograniczenia bezpieczeństwa.

W Red Hat Quay funkcja webhook powiadomień Slack i ogólnych nie waliduje URL pod kątem SSRF. Administrator repozytorium może zmusić Quay worker do wysyłania żądań POST do wewnętrznych adresów sieciowych lub punktów końcowych chmury.

Podatność SSRF w Red Hat Quay w konfiguracji mirror repozytorium. Administrator repozytorium może podać spreparowaną nazwę hosta, powodując, że Quay mirror worker wykonuje żądania do wewnętrznych usług sieciowych.

W Red Hat Quay monit ponownej weryfikacji hasła przy operacjach wrażliwych, takich jak generowanie tokenów czy tworzenie kont robotów, można obejść. Użytkownik z wygasłą sesją lub atakujący mający dostęp do bezczynnej uwierzytelnionej sesji przeglądarki może wykonać uprzywilejowane działania bez podania ważnych poświadczeń, mimo że interfejs wyświetla błąd nieprawidłowych danych.

W Red Hat Quay funkcja konfiguracji proxy cache nie weryfikuje, czy wskazany host rejestru upstream jest prawowitym serwisem zewnętrznym. Administrator organizacji może podać spreparowaną nazwę hosta, zmuszając serwer Quay do wysyłania żądań do wewnętrznych usług sieciowych, punktów końcowych infrastruktury chmurowej lub innych zasobów, które nie powinny być dostępne z poziomu aplikacji Quay.

W Red Hat Quay wykryto podatność w obsłudze wznawialnych przesyłania warstw obrazów kontenerowych. Proces przesyłania przechowuje dane pośrednie w bazie danych w formacie, który po manipulacji może umożliwić atakującemu wykonanie dowolnego kodu na serwerze Quay.

W procesie przesyłania obrazów kontenerowych w Red Hat Quay wykryto lukę, która pozwala uwierzytelnionemu użytkownikowi z prawem push do dowolnego repozytorium na ingerencję w trwające przesyłanie obrazów przez innych użytkowników, w tym w repozytoria, do których nie ma dostępu. Atakujący może odczytać, zmodyfikować lub anulować przesyłanie obrazu innego użytkownika.

W Red Hat Quay i mirror registry dla Red Hat OpenShift znaleziono podatność Server-Side Request Forgery (SSRF) w funkcji eksportu logów. Uwierzytelniony użytkownik może podać dowolny adres URL wywołania zwrotnego, a proces backendowy wykonuje żądania HTTP po stronie serwera do tego adresu. Atakujący może wykorzystać to do wysyłania żądań z wewnętrznej sieci aplikacji, co może prowadzić do ujawnienia poufnych informacji.