Podatności Kestra

W Kestra przed wersjami 1.0.45 i 1.3.21 filtr uwierzytelniania REST API pomija sprawdzanie poświadczeń dla żądań kończących się na '/configs'. Niezalogowany atakujący może wykorzystać to do tworzenia przepływów z zadaniami Shell lub Process, które wykonują się jako root w kontenerze, a przez zamontowany /var/run/docker.sock uzyskują dostęp do demona Dockera na hoście.

W Kestra OSS przed wersjami 1.0.45 i 1.3.21, filtr AuthenticationFilter używa metody endsWith("/configs") do sprawdzenia, czy żądanie dotyczy publicznego endpointu konfiguracji. Ponieważ jest to dopasowanie sufiksu, a nie dokładnej ścieżki, każdy interfejs API, którego ostatni segment to "configs", omija uwierzytelnianie. Niezautoryzowany atakujący może wykorzystać tę lukę do tworzenia i wykonywania dowolnych przepływów pracy bez poświadczeń.

Kestra w wersji 1.3.3 i wcześniejszych jest podatna na wstrzykiwanie SQL. Podatność wynika z bezpośredniego konkatenowania danych wejściowych użytkownika z parametru GET do zapytania SQL bez odpowiedniego oczyszczania lub parametryzacji.

Kestra przed wersją 1.3.7 zawiera podatność na iniekcję SQL w endpointzie GET /api/v1/main/flows/search, która umożliwia uwierzytelnionemu atakującemu zdalne wykonanie kodu poprzez PostgreSQL COPY ... TO PROGRAM.

Kestra przed wersją 1.3.24 zawiera podatność na przechowywany XSS w niestandardowym parserze Markdown. Użytkownik z uprawnieniami do tworzenia lub aktualizacji opisu Flow może wstrzyknąć atrybuty obsługi zdarzeń JavaScript przez składnię [[link]], co powoduje wykonanie skryptu, gdy inny użytkownik otworzy opis lub panel informacyjny.

Kestra przed wersją 2.0.0 przekazuje kontrolowany przez użytkownika argument uri funkcji http() do URI.create() i serwerowego klienta HTTP bez ograniczania miejsc docelowych prywatnych, pętli zwrotnej lub link-local, co pozwala nieuwierzytelnionemu atakującemu zaimportować i wykonać przepływ, który uzyskuje dostęp do wewnętrznych usług lub metadanych chmury.

Kestra przed wersją 2.0.0-rc6 udostępnia punkt końcowy GET /worker bez uwierzytelnienia i serializuje kompletny obiekt Task, co może ujawnić polecenia, zmienne środowiskowe, nagłówki HTTP, dane połączeń, poświadczenia w postaci jawnego tekstu oraz identyfikatory wykonania, podczas gdy główne API na porcie 8080 pozostaje chronione. Problem został naprawiony w wersji 2.0.0-rc6.

Podatność w Kestra przed wersją 2.0.0-rc6 polega na tym, że endpointy zarządzania Micronaut na porcie 8081 są dostępne bez uwierzytelnienia, nawet gdy Basic Auth chroni /api/v1/** na porcie 8080. Umożliwia to nieuwierzytelniony odczyt zmiennych środowiskowych i zmianę poziomów logowania.

Podatność w komponencie BasicAuth platformy Kestra OSS przed wersją 1.3.24 umożliwia atakującemu z dostępem do bazy PostgreSQL odzyskanie hasła administratora offline dzięki szybkości obliczeniowej SHA-512. W środowiskach Kubernetes pozwala to na eskalację uprawnień do odczytu tokena ServiceAccount i wszystkich sekretów klastra.

W Kestra przed wersjami 1.0.45 i 1.3.21 endpoint previewFileFromExecution (GET /api/v1/{tenant}/executions/{executionId}/file/preview) zawiera obejście kontroli dostępu, umożliwiając każdemu uwierzytelnionemu użytkownikowi odczyt plików wyjściowych z dowolnego wykonania w obrębie tego samego dzierżawcy, z pominięciem izolacji na poziomie wykonania i przestrzeni nazw.

W Kestra przed wersjami 1.0.45 i 1.3.23 lokalny backend przechowywania wewnętrznego nieprawidłowo waliduje ścieżki użytkownika, umożliwiając atakującemu przemycenie sekwencji przejścia do katalogu nadrzędnego za pomocą ukośników odwrotnych (..\..\..\) przed konwersją na ukośniki zwykłe. Uwierzytelniony użytkownik z najniższymi uprawnieniami może odczytać dowolny plik w systemie plików serwera, w tym bazę H2, przechowywane sekrety i dane uwierzytelniające.

W Kestra przed wersjami 1.0.43 i 1.3.19, kilka endpointów API akceptuje URI kestra:// od klienta i przekazuje je do funkcji StorageInterface.parentTraversalGuard przed odczytaniem pliku z lokalnego backendu pamięci masowej. Ochrona sprawdza tylko literalny URI.toString(), więc zakodowany URL .. zapisany jako %2E%2E przechodzi przez nią. Następnie kod wywołuje URI.getPath(), który dekoduje %2E%2E z powrotem na .., a wynikowa ścieżka jest przekazywana do Paths.get(...) bez normalizacji. System operacyjny rozwiązuje segmenty .. w momencie wywołania open(2), więc uwierzytelniony użytkownik z pojedynczym wykonaniem może odczytać dowolny plik, do którego proces Kestra ma dostęp w systemie plików hosta (/etc/passwd, zamontowane sekrety, wyniki wykonań innych dzierżawców itp.).

Kestra to platforma orkiestracji oparta na zdarzeniach, która przed wersjami 1.3.19, 1.2.19, 1.1.19 i 1.0.43 miała problem z zadaniem `inputFiles`. Umożliwiało to zapisanie nazw plików bezpośrednio w katalogu roboczym zadania, co mogło prowadzić do nadpisania plików poza tym katalogiem.