Podatności Yamcs

Yamcs przed wersjami 5.12.8 i 5.13.2 ma podatność w LikeExpression.fillCode_getValueReturn, gdzie wzorzec LIKE nie jest poprawnie escapowany i jest wstawiany do kodu Java kompilowanego przez SimpleCompiler.cook. Wzorzec może pochodzić z różnych punktów końcowych API, a cudzysłów we wzorcu może wstrzyknąć kod Java wykonywany jako proces serwera Yamcs.

Yamcs przed wersjami 5.12.8 i 5.13.2 wstawia templateArgs z POST /api/instances i PATCH /api/instances/{instance} do YAML bez escapowania w kontekście YAML. Renderowana konfiguracja jest analizowana przez YamcsServer.createInstance i ładowana przez YamcsServerInstance, co pozwala atakującemu na wstrzyknięcie wpisu usługi dla org.yamcs.ProcessRunner. Udane wykorzystanie wykonuje polecenia jako konto usługi Yamcs.

Yamcs przed wersjami 5.12.8 i 5.13.2 pozwala użytkownikowi z uprawnieniem SystemPrivilege.ControlArchiving na utworzenie nazwy kolumny StreamSQL z podwójnym cudzysłowem, która jest interpolowana do generowanego kodu Java. Poprzez endpoint POST /api/archive/{instance}:executeSql możliwe jest wykonanie dowolnego kodu Java w procesie serwera Yamcs, co może ujawnić dane misji i poświadczenia oraz umożliwić manipulację telemetrią lub odmowę usługi. Problem został naprawiony w wersjach 5.12.8 i 5.13.2.

Podatność w Yamcs przed wersją 5.12.7 pozwala uwierzytelnionemu użytkownikowi z uprawnieniem ChangeMissionDatabase na zdalne wykonanie kodu poprzez nadpisanie algorytmu Python w skryptowym silniku Jython. Brak sandboksowania umożliwia import i wykonanie dowolnych klas Java, w tym java.lang.Runtime.

W Yamcs przed wersją 5.12.7 silnik skryptowy Nashorn użyty do oceny algorytmów JavaScript nie posiadał filtru klas, co pozwalało użytkownikowi z uprawnieniami ChangeMissionDatabase na podmianę algorytmu i wykonanie dowolnego kodu Java, w tym poleceń systemowych. W domyślnej konfiguracji bez pliku security.yaml wbudowany użytkownik gość ma superuser=true, co umożliwia atak bez uwierzytelnienia.

Yamcs przed wersją 5.12.7 zawiera podatność na wstrzykiwanie kodu po stronie serwera w silniku ewaluacji algorytmów. Uwierzytelniony użytkownik z uprawnieniami ChangeMissionDatabase może nadpisać istniejący algorytm przez REST API i wstrzyknąć kod Java, co prowadzi do zdalnego wykonania kodu na hoście.

Yamcs to framework do kontroli misji. Przed wersjami 5.12.8 i 5.13.2, Yamcs przetwarza dane kontrolowane przez atakującego z trasy /ext bez sprawdzania zarejestrowanych identyfikatorów wtyczek przed renderowaniem DOM przez innerHTML. Specjalnie spreparowany URL może wykonać JavaScript po otwarciu przez użytkownika. Skrypt może odczytać dane dostępne dla aplikacji webowej Yamcs i wykonywać działania w kontekście użytkownika. Problem naprawiono w wersjach 5.12.8 i 5.13.2.

Yamcs przed wersją 5.11.13 zawiera podatność w StaticFileHandler.locateFile, która rozwiązuje nieuwierzytelnioną ścieżkę żądania bez użycia Path.normalize i Path.toAbsolutePath, aby potwierdzić, że ścieżka bezwzględna pozostaje w skonfigurowanych staticRoots. Ścieżka zawierająca segmenty traversal może opuścić zamierzony katalog główny i zwrócić dowolny czytelny plik hosta. Wada znajduje się w yamcs-core/src/main/java/org/yamcs/http/StaticFileHandler.java i może ujawnić wrażliwe dane systemu operacyjnego i aplikacji. Problem jest naprawiony w wersji 5.11.13, a linia 5.12 jest naprawiona od wersji 5.12.0.

Yamcs przed wersją 5.9.4 odzwierciedla parametr redirect_uri z GET /auth/authorize do szablonu authorize.html bez odpowiedniego escapowania HTML. Specjalnie spreparowany adres URL autoryzacji może wykonać JavaScript u użytkownika Yamcs, co umożliwia kradzież danych uwierzytelniających i przejęcie konta.

Yamcs przed wersjami 5.12.8 i 5.13.2 nie sprawdza uprawnień SystemPrivilege.ControlAccess w metodach IamApi.listRoles, IamApi.getRole i IamApi.listPrivileges. Każde uwierzytelnione konto może wywołać GET /api/roles, GET /api/roles/{name} i GET /api/privileges, aby wyliczyć dostępne uprawnienia systemowe i mapowania ról.

Yamcs przed wersjami 5.12.8 i 5.13.2 nie egzekwuje uprawnień wymaganych przez równoważne endpointy REST w handlerach subskrypcji WebSocket. Konkretnie, subskrypcje pakietów, statusu algorytmów i zmian bazy misji są dostępne bez wymaganych uprawnień, co pozwala użytkownikowi z niskimi uprawnieniami na otrzymywanie wrażliwych danych.

Yamcs przed wersjami 5.12.8 i 5.13.2 pomija kontrolę autoryzacji w kilku interfejsach API, takich jak IndexesApi, Cop1Api i TimeApi. Uwierzytelniony użytkownik z niskimi uprawnieniami może odczytywać metadane pakietów i zdarzeń, zmieniać stan łącza COP-1 oraz manipulować czasem symulacji.

W Yamcs przed wersjami 5.12.8 i 5.13.2, endpoint PacketsApi.exportPackets nie wymuszał sprawdzania uprawnień ReadPacket na poziomie obiektu, gdy żądanie nie zawierało konkretnych nazw pakietów. Pusta lista nazw powodowała pominięcie filtru WHERE pname IN, co pozwalało uwierzytelnionemu użytkownikowi z niskimi lub zerowymi uprawnieniami na wyeksportowanie całego archiwum surowych pakietów telemetrycznych.

W Yamcs przed wersją 5.12.7 brakuje ograniczenia szybkości, blokady konta lub ograniczania prób logowania w punkcie końcowym uwierzytelniania POST /auth/token. Nieuwierzytelniony atakujący zdalnie może przeprowadzić nieograniczone próby odgadnięcia hasła dla dowolnego konta użytkownika.

W Yamcs przed wersją 5.12.7, endpointy API IAM (listUsers, getUser, listGroups, getGroup) nie sprawdzały wymaganego uprawnienia SystemPrivilege.ControlAccess. Umożliwiało to każdemu uwierzytelnionemu użytkownikowi, nawet z niskimi uprawnieniami, wyliczenie wszystkich kont użytkowników, ich nazw, statusu superużytkownika oraz członkostwa w grupach.

W frameworku Yamcs do kontroli misji kosmicznych wykryto podatność na wstrzykiwanie LDAP w module `LdapAuthModule`. Nazwa użytkownika jest wstawiana bezpośrednio do filtra LDAP bez odpowiedniego escapowania zgodnego z RFC 4515, co umożliwia atakującemu manipulację zapytaniami LDAP.