Podatności FUXA

W FUXA (wersja 1.3.2-2809) występuje luka polegająca na obejściu autoryzacji w funkcjonalności /nodered. Specjalnie spreparowane żądanie HTTP może doprowadzić do wykonania dowolnego kodu, a atakujący może je wysłać bez uwierzytelnienia.

FUXA w wersji 1.3.2 i wcześniejszych ma podatność w mechanizmie autoryzacji allowDashboard, która pozwala zdalnemu nieuwierzytelnionemu atakującemu uzyskać podpisany token gościa i uzyskać dostęp do edytora Node-RED oraz API wdrażania przepływów. Atakujący może wdrożyć złośliwe węzły lub wykonać skrypty, przejmując kontrolę nad danymi projektu, konfiguracją i potencjalnie systemem operacyjnym.

W funkcjonalności /api/runscript w FUXA (wersja 1.3.2-2809) występuje luka pozwalająca na obejście autoryzacji. Specjalnie spreparowane żądanie HTTP może doprowadzić do wykonania operacji o podwyższonych uprawnieniach, a atakujący może wywołać je bez uwierzytelnienia.

W funkcjonalności /nodered/fuxa/scripts w FUXA (wersja 1.3.2-2809) występuje luka ujawnienia informacji. Specjalnie spreparowane żądanie HTTP może doprowadzić do wycieku informacji, a atakujący może wywołać ją bez uwierzytelnienia.

FUXA to webowe oprogramowanie do wizualizacji procesów (SCADA/HMI/Dashboard). Przed wersją 1.3.3, usunięcie definicji roli przez DELETE /api/roles nie usuwa identyfikatora roli z tablicy info.roles użytkowników ani z pamięci podręcznej usersMap. Może to prowadzić do zachowania uprawnień po ich cofnięciu przez administratora.

FUXA w wersji 1.3.2 i wcześniejszych nie sprawdza autoryzacji isSocketAdminAuthorized dla niektórych zdarzeń Socket.IO (DEVICE_BROWSE, DEVICE_NODE_ATTRIBUTE, HOST_INTERFACES, DEVICE_TAGS_REQUEST), gdy secureEnabled jest włączone. Zdalny nieuwierzytelniony lub gość może zbierać informacje o systemie, które nie są wymagane do normalnego przeglądania HMI.

FUXA w wersji 1.3.2 i wcześniejszych pozwala uwierzytelnionemu użytkownikowi niebędącemu administratorem na kontrolowanie property.address w handlerze device-webapi-request, co umożliwia serwerowi FUXA wysyłanie żądań HTTP/HTTPS do wewnętrznych usług i zwracanie odpowiedzi atakującemu. To prowadzi do podatności SSRF.

FUXA w wersji 1.3.2 i wcześniejszych nieprawidłowo obsługiwał odświeżanie sesji, co pozwalało atakującemu z wcześniej wydanym uprzywilejowanym ciasteczkiem lub tokenem na kontynuowanie generowania uprzywilejowanych tokenów JWT nawet po usunięciu konta, dezaktywacji, usunięciu roli lub degradacji. Umożliwiało to utrzymanie nieautoryzowanego dostępu do zarządzania użytkownikami, projektami, konfiguracją i tworzeniem kont backdoor. Problem naprawiono w wersji 1.3.3.

FUXA to webowe oprogramowanie do wizualizacji procesów (SCADA/HMI/Dashboard). Przed wersją 1.3.2, endpointy POST /api/scheduler i DELETE /api/scheduler nie egzekwują spójnie uprawnień administratora. Uwierzytelniony operator bez uprawnień administratora może tworzyć lub modyfikować akcje urządzeń, które wywołują onSetValue lub onRunScript, lub usuwać harmonogramy, uzyskując dostęp do zmian wartości urządzeń i wykonywania skryptów po stronie serwera.

FUXA to webowe oprogramowanie do wizualizacji procesów (SCADA/HMI/Dashboard). Przed wersją 1.3.2, funkcja escapeTdString w łączniku magazynu TDengine nie poprawnie escapuje backslashy. Zdalny nieuwierzytelniony atakujący może przesłać spreparowany identyfikator tagu sids przez GET /api/daq lub zdarzenie Socket.IO DAQ_QUERY, co pozwala na wstrzyknięcie SQL i odczytanie wszystkich wierszy z tabeli fuxa.meters, ujawniając historyczne wartości tagów PLC i nazwy urządzeń.

FUXA przed wersją 1.3.2 ma podatność na zdalny atak SSRF (Server-Side Request Forgery) przez nieuwierzytelnionego atakującego. Poprzez manipulację danymi w handlerach Socket.IO DEVICE_WEBAPI_REQUEST i DEVICE_PROPERTY, atakujący może zmusić serwer do wykonania żądań HTTP/HTTPS do dowolnych adresów, w tym do wewnętrznych usług, metadanych chmury, usług OPC UA lub ODBC. Problem naprawiono w wersji 1.3.2.

FUXA to webowe oprogramowanie do wizualizacji procesów (SCADA/HMI/Pulpit). Gdy ustawienie `secureEnabled=true`, FUXA w wersji 1.3.0-2773 nadal pozwala żądaniom gości i z nieprawidłowymi tokenami na odczyt interfejsów API projektów, alarmów i harmonogramów. Wersja 1.3.1 naprawia ten problem.

FUXA to webowe oprogramowanie do wizualizacji procesów (SCADA/HMI/Dashboard). W wersji fuxa-server 1.3.0, endpoint GET /api/project ujawnia wrażliwe dane konfiguracyjne projektu żądaniom w kontekście gościa, nawet gdy włączona jest opcja secureEnabled. Wersja 1.3.1 naprawia ten problem.

Brak uwierzytelnienia w aplikacji FUXA do wersji 1.3.3 pozwala nieuwierzytelnionemu zdalnemu atakującemu na odpytywanie wszystkich historycznych danych z czujników przez zdarzenie Socket.IO DAQ_QUERY. Gdy secureEnabled=true, inne wrażliwe zdarzenia Socket.IO (DEVICE_BROWSE, HOST_INTERFACES, DEVICE_TAGS_REQUEST itp.) wywołują isSocketAdminAuthorized w celu weryfikacji tokenu połączenia, ale procedura obsługi DAQ_QUERY w server/runtime/index.js całkowicie pomija tę kontrolę.

FUXA w wersji 1.3.0 zawiera nieuwierzytelnioną podatność na zdalne wykonanie kodu, gdy secureEnabled jest ustawione na true. Endpoint POST /api/runscript sprawdza autoryzację na podstawie ID skryptu, ale gdy ustawiono test: true, kompiluje i wykonuje kod dostarczony przez atakującego zamiast kodu przechowywanego skryptu. Nieuwierzytelniony atakujący znający prawidłowe ID i nazwę skryptu może wykonać dowolny kod.

FUXA w wersji 1.3.0 ma lukę w punkcie końcowym /api/getTagValue, która pozwala nieuwierzytelnionym użytkownikom na odczyt wartości tagów, gdy referencjonowany skrypt nie istnieje. Wersja 1.3.1 naprawia problem.

W FUXA (oprogramowanie do wizualizacji procesów SCADA/HMI) w wersjach od 1.2.11 do 1.3.1 występuje podatność umożliwiająca nieuwierzytelnionemu zdalnemu atakującemu pełne zdalne wykonanie kodu (RCE) jako root. Atak udaje się nawet w najbezpieczniejszej konfiguracji (tryb bezpieczny włączony i uwierzytelnianie Node-RED włączone). Wersja 1.3.1 naprawia problem.

FUXA w wersjach 1.3.1 i wcześniejszych zawiera podatność na ominięcie uwierzytelniania poprzez normalizację ścieżek z segmentami kropkowymi w REST API. Router API nie normalizuje sekwencji segmentów kropek przed zastosowaniem middleware uwierzytelniającego, co pozwala nieuwierzytelnionym żądaniom na dostęp do chronionych punktów końcowych poprzez poprzedzenie ścieżek segmentami kropkowymi, takimi jak /api/./users, /api/./roles i /api/project/../users. Żądania te omijają kontrole uwierzytelniania i zwracają wrażliwe dane użytkowników i ról bez poświadczeń.