Podatności Budibase

Budibase w wersjach od 3.39.4 do 3.40.0 zawiera regresję autoryzacji w punkcie końcowym przesyłania załączników S3, która pozwala użytkownikom BASIC na uzyskanie podpisanych URL-i S3 PutObject poprzez wysyłanie żądań POST do punktu końcowego załączników. Trasa została zmieniona z kontroli uprawnień BUILDER na kontrolę TABLE/WRITE, którą użytkownicy BASIC mają domyślnie. Atakujący mogą określić dowolne zasobniki S3 w treści żądania, aby wygenerować podpisane URL-e do zapisu w dowolnym zasobniku dostępnym dla przechowywanych poświadczeń IAM, co umożliwia nieautoryzowane przesyłanie plików.

Budibase to otwartoźródłowa platforma low-code, która przed wersją 3.39.0 miała luki w zabezpieczeniach związane z dostępem do tras GET i PUT dla pojedynczego źródła danych. Użytkownicy z rolą Basic mogli uzyskać dostęp do poufnych informacji, takich jak sekrety autoryzacji, poprzez manipulację danymi konfiguracyjnymi.

Budibase to otwartoźródłowa platforma low-code, która przed wersją 3.38.3 nie maskowała poprawnie wrażliwych danych w integracji z Snowflake. Użytkownik z autoryzacją BASIC mógł uzyskać pełny klucz PEM w formacie tekstowym.

Budibase to otwartoźródłowa platforma low-code. W wersjach przed 3.38.2, punkt końcowy przesyłania plików POST /api/attachments/process nie egzekwuje ograniczeń dotyczących aktywnej zawartości dla uwierzytelnionych użytkowników, co pozwala na przesyłanie niebezpiecznych plików przez uwierzytelnionych budowniczych.

Budibase przed wersją 3.38.1 ma lukę w REST API, która pozwala uwierzytelnionym użytkownikom aplikacji na modyfikację konfiguracji źródła danych. Użytkownicy z rolą BASIC lub wyższą mogą wysyłać żądania PUT do zmiany ustawień, co może prowadzić do nieautoryzowanego dostępu do wrażliwych danych.

Budibase to platforma open-source low-code, która przed wersją 3.38.1 miała lukę w zabezpieczeniach w punkcie końcowym POST /api/global/users/onboard. Umożliwia to użytkownikom z uprawnieniami budowniczego dostęp do tworzenia nowych kont globalnych administratorów, co prowadzi do eskalacji uprawnień.

Budibase to platforma open-source do niskokodowego tworzenia aplikacji. W wersjach przed 3.34.8 funkcja processUrlFile w pliku extract.ts nie weryfikowała adresów IP, co umożliwiało uwierzytelnionym użytkownikom wysyłanie żądań do wewnętrznych adresów sieciowych.

Budibase przed wersją 3.41.3 zawiera podatność na zdalne wykonanie kodu w obsłudze wtyczek, która pozwala uwierzytelnionym administratorom wykonać dowolny kod poprzez przesłanie złośliwego pakietu wtyczki. Serwer wywołuje eval() na plikach JavaScript wtyczki bez sandboxa w głównym procesie Node.js, umożliwiając atakującym kradzież zmiennych środowiskowych i poświadczeń z uprawnieniami roota w domyślnych instalacjach.

Budibase przed wersją 3.39.30 ma podatność w przepływie OIDC, gdzie adres e-mail nie jest weryfikowany pod kątem email_verified, a konta są łączone na podstawie adresu e-mail. Atakujący, który może uwierzytelnić się przez dostawcę tożsamości z niezweryfikowanym adresem e-mail ofiary, może przejąć konto ofiary i odziedziczyć jej role.

Budibase przed wersją 3.40.0 zawiera nieuwierzytelnioną podatność na wstrzykiwanie SQL w automatyzacjach wyzwalanych webhookiem z krokami EXECUTE_QUERY. Atakujący może wysłać JSON do endpointu webhooka, aby wstrzyknąć ładunki SQL wykonujące się z poświadczeniami bazy danych skonfigurowanymi przez buildera, umożliwiając eksfiltrację, modyfikację i trwałość danych w połączonych źródłach danych.

Budibase przed wersją 3.40.0 nieprawidłowo sanityzuje klucze obiektów S3, umożliwiając uwierzytelnionym builderom przesyłanie plików z sekwencjami traversal, które są zachowywane podczas eksportu. Atakujący mogą tworzyć nazwy plików zawierające segmenty .., które wychodzą poza katalog tymczasowy podczas eksportu obszaru roboczego, zapisując dowolną treść w dowolnej ścieżce zapisywalnej przez proces Budibase.

Budibase przed wersją 3.40.1 nie weryfikował, czy docelowy adres żądania odpowiada źródłu danych, przez co nieuwierzytelniony użytkownik mógł wysłać zapytanie do publicznego punktu końcowego i przechwycić zapisane poświadczenia (bearer, basic lub statyczne nagłówki). Problem został naprawiony w wersji 3.40.1.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.40.0 komponent integracji MySQL w Budibase jest skonfigurowany z multipleStatements: true, co umożliwia wykonanie wielu instrukcji SQL w jednym zapytaniu. Atakujący mogą wstrzykiwać złośliwe polecenia SQL przez pola wprowadzania danych użytkownika, co prowadzi do całkowitej kompromitacji bazy danych. Podatność została naprawiona w wersji 3.40.0.

Budibase przed wersją 3.39.9 zawiera podatność polegającą na nieprawidłowej walidacji dowiązań symbolicznych podczas przetwarzania plików ZIP. Atakujący na poziomie builder może wstrzyknąć dowiązanie symboliczne wskazujące na dowolny plik w systemie, który zostanie odczytany i przesłany do MinIO, a następnie udostępniony przez API.

Budibase przed wersją 3.39.12 zawiera podatność, która pozwala nieuwierzytelnionemu użytkownikowi na odczytanie wszystkich dokumentów z kolekcji MongoDB, CouchDB, Elasticsearch, DynamoDB-PartiQL lub REST-with-JSON-body, a w przypadku publicznych zapytań typu write również na modyfikację wszystkich dokumentów za pomocą jednego żądania HTTP. Problem wynika z nieprawidłowego walidowania danych wejściowych w funkcji validateQueryInputs, która odrzuca tylko znaczniki Handlebars, ale nie escapuje metaznaków JSON, co umożliwia wstrzyknięcie dodatkowych pól do obiektu filtra.

Budibase przed wersją 3.39.0 zawiera podatność, która pozwala anonimowemu atakującemu na uzyskanie podpisanej URL do zapisu do dowolnego zasobnika S3, do którego ofiara ma dostęp. Atak wymaga znajomości identyfikatora przestrzeni roboczej i źródła danych S3, ale nie wymaga uwierzytelnienia.

Budibase to platforma niskokodowa, która przed wersją 3.39.0 miała lukę w zabezpieczeniach w punkcie końcowym /api/public/v1/roles/assign. Umożliwia ona użytkownikom z rolą budowniczego podniesienie swoich uprawnień do globalnego administratora, co prowadzi do eskalacji uprawnień w całym środowisku najemcy.

Budibase przed wersją 3.33.4 umożliwia nieuwierzytelnionemu atakującemu zdalne wykonanie kodu (RCE) na serwerze poprzez wyzwolenie automatyzacji zawierającej krok Bash za pomocą publicznego endpointu webhook. Proces wykonuje się jako root w kontenerze.

Budibase przed wersją 3.33.4 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w łączniku danych REST. Mechanizm ochrony SSRF (czarna lista IP) jest nieskuteczny, ponieważ zmienna środowiskowa BLACKLIST_IPS nie jest domyślnie ustawiona w żadnej oficjalnej konfiguracji wdrożeniowej. Gdy zmienna jest pusta, funkcja czarnej listy bezwarunkowo zwraca false, przepuszczając wszystkie żądania.

Budibase przed wersją 3.41.3 nie egzekwuje autoryzacji opartej na rolach na punktach końcowych zarządzania licencjami, co pozwala każdemu uwierzytelnionemu użytkownikowi na usuwanie kluczy licencyjnych lub manipulowanie tokenami offline. Atakujący z podstawowymi uprawnieniami użytkownika mogą uzyskać dostęp do /api/global/license/*, aby wyłączyć funkcje premium i zdegradować wdrożenia dla wszystkich użytkowników.

Budibase przed wersją 3.41.3 zawiera podatność braku autoryzacji w punkcie końcowym POST /api/resources/duplicate, która pozwala uwierzytelnionym builderom wstrzykiwać tabele, automatyzacje, zapytania i ekrany do dowolnej innej aplikacji bez posiadania roli w docelowym workspace. Atakujący mogą wstrzykiwać zasoby, podając dowolny identyfikator docelowego workspace w treści żądania, a następnie uruchamiać wstrzyknięte automatyzacje z wychodzącymi webhookami, aby eksfiltrować dane z aplikacji ofiary.

Budibase przed wersją 3.41.3 nie waliduje przypisań ról buildera w zakresie aplikacji w publicznych punktach końcowych tworzenia i aktualizacji użytkowników, co pozwala uwierzytelnionemu builderowi w zakresie aplikacji przyznać dostęp buildera do niepowiązanych aplikacji. Atakujący mogą wysyłać spreparowane żądania do API aktualizacji użytkownika z polami builder.apps, aby eskalować uprawnienia i uzyskać nieautoryzowany dostęp buildera do innych aplikacji w tym samym tenant.

Budibase przed wersją 3.41.3 nie egzekwuje ograniczeń ról per tabela na punkcie końcowym POST /api/datasources/query, co pozwala użytkownikom z niskimi uprawnieniami BASIC odczytywać, tworzyć, aktualizować lub usuwać wiersze w dowolnej tabeli niezależnie od skonfigurowanych uprawnień. Atakujący z rolą BASIC mogą wysyłać spreparowane żądania zapytań z identyfikatorami docelowych tabel, aby ominąć kontrolę dostępu na poziomie tabel i manipulować ograniczonymi danymi.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.40.0, w packages/backend-core/src/utils/outboundFetch.ts przypinano zweryfikowany adres przez agenta Node, ale integracja REST używała getDispatcher z packages/backend-core/src/utils/fetch.ts, co powodowało, że undici ignorował tego agenta i ponownie rozwiązywał nazwę hosta. Konstruktor mógł użyć DNS rebinding, aby sprawić, że packages/server/src/integrations/rest.ts połączy się z wewnętrznym adresem po tym, jak publiczny adres przeszedł walidację, z pełnym dostępem do odpowiedzi i dowolnymi metodami REST. Poprawka dodaje obsługę createPinnedLookup do dyspozytora undici i przekazuje zweryfikowany adres do niestandardowych implementacji fetch. Problem został naprawiony w wersji 3.40.0.

Budibase przed wersją 3.39.19 zawiera podatność w łączniku PostgreSQL, gdzie pole konfiguracyjne schema jest interpolowane do instrukcji SET search_path bez odpowiedniego escapowania podwójnych cudzysłowów. Uwierzytelniony administrator może wykonać dowolny kod SQL.

Budibase przed wersją 3.41.3 zawiera podatność w punkcie końcowym POST /api/attachments/:datasourceId/url, gdzie uwierzytelniony użytkownik opublikowanej aplikacji z rolą BASIC może podać kontrolowane wartości bucket i key, uzyskując podpisane adresy URL oparte na zapisanych poświadczeniach S3.

Budibase przed wersją 3.41.3 zawiera podatność w krokach automatyzacji (outgoingWebhook, zapier, n8n, slack, discord), gdzie używają one node-fetch na adresach URL dostarczonych przez użytkownika bez egzekwowania BLACKLIST_IPS, co pozwala uwierzytelnionemu użytkownikowi na wykonywanie żądań po stronie serwera do metadanych chmury i wewnętrznych usług.

Budibase przed wersją 3.39.18 zawiera podatność na wstrzyknięcie SQL w integracji MySQL, gdzie nazwa tabeli nie jest poprawnie escapowana w zapytaniu DESCRIBE. Atakujący może utworzyć tabelę z nazwą zawierającą backtick i dodatkowe zapytanie, które zostanie wykonane podczas skanowania schematu przez administratora. Problem naprawiono w wersji 3.39.18.

Budibase przed wersją 3.39.24 zawiera podatność w punkcie końcowym POST /api/public/v1/roles/assign, gdzie brakuje walidacji appBuilder.appId lub role.appId. Użytkownik z uprawnieniami buildera w jednej aplikacji może przypisać sobie uprawnienia buildera lub dowolną rolę w innej aplikacji, uzyskując dostęp do jej danych, konfiguracji źródeł danych i automatyzacji. Problem naprawiono w wersji 3.39.24.

Budibase przed wersją 3.39.25 ma podatność w endpointach GET /api/users/metadata i GET /api/users/metadata/:id. Odpowiedzi zawierają obiekty użytkowników bez usunięcia pól oauth2.accessToken i oauth2.refreshToken. Użytkownik z rolą POWER może pobrać dane uwierzytelniające dostawcy tożsamości użytkowników SSO i użyć tokenów odświeżania do trwałego dostępu do połączonych usług.

Budibase przed wersją 3.40.0 nie maskuje poświadczeń źródeł danych przechowywanych w polach typu STRING, co pozwala uwierzytelnionym użytkownikom na odczytanie w postaci jawnej ciągów połączeń MongoDB i kluczy prywatnych Firebase. Atakujący z uprawnieniami odczytu tabel mogą pobrać konfiguracje źródeł danych przez API, uzyskując dostęp do poświadczeń baz danych i kluczy kont usług.

Budibase przed wersją 3.40.0 zawiera podatność w punkcie końcowym PUT /api/global/users/tenant/owner (changeTenantOwnerEmail), która pozwala każdemu uwierzytelnionemu użytkownikowi, nawet z najniższymi uprawnieniami BASIC, na zmianę adresu e-mail właściciela konta na adres kontrolowany przez atakującego. Atakujący może następnie użyć publicznego mechanizmu resetowania hasła, aby przejąć konto administratora, uzyskując pełny dostęp administracyjny.

Budibase przed wersją 3.40.0 zawiera podatności typu Server-Side Request Forgery (SSRF) w imporcie zapytań OpenAPI i wykonywaniu zapytań REST, które pozwalają uwierzytelnionym użytkownikom z uprawnieniami buildera na obejście ochrony DNS pinning poprzez ataki DNS rebinding. Atakujący mogą skonfigurować nazwy hostów, które podczas walidacji rozwiązują się na adresy publiczne, ale podczas rzeczywistego połączenia na adresy pętli zwrotnej lub prywatne, umożliwiając dostęp do zablokowanych wewnętrznych usług HTTP.

Budibase przed wersją 3.40.0 zawiera podatność na wstrzyknięcie SQL w łączniku Oracle, w wyszukiwaniu wierszy po zapisie, gdzie nazwy tabel nie są poprawnie escapowane. Atakujący z uprawnieniami zapisu na tabeli z cudzysłowem w nazwie może wstrzyknąć SQL, który wykona się jako użytkownik bazy danych, umożliwiając odczyt lub modyfikację dowolnych danych.

Budibase przed wersją 3.40.0 zawiera podatność na Cross-Site Request Forgery (CSRF) w punkcie końcowym handoff linku czatu, która pozwala atakującym na powiązanie zewnętrznej tożsamości czatu z kontem ofiary. Atakujący mogą stworzyć stronę phishingową, która automatycznie wysyła żądanie POST z przeciekiem tokena potwierdzającego, aby powiązać swoją tożsamość czatu z kontem ofiary, umożliwiając podszywanie się w operacjach agenta i dziedziczenie uprawnień ofiary.

Budibase przed wersją 3.40.0 zawiera podatność na wstrzyknięcie NoSQL w integracji z MongoDB, gdzie parametry dostarczone przez użytkownika są wzbogacane za pomocą handlebars z noEscaping: true i parsowane bez filtrowania operatorów. Atakujący mogą wstrzyknąć operatory MongoDB przez parametry zapytania, aby ominąć kontrolę dostępu per użytkownik, odczytać dowolne dokumenty, wykonać JavaScript przez operatory $where lub modyfikować kolekcje przez operacje update i delete.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.40.1, w packages/server/src/integrations/mongodb.ts przekazywano kontrolowane przez buildera wartości tlsCertificateKeyFile i tlsCAFile bezpośrednio do MongoClient w Budibase Cloud. Builder mógł przesłać bezwzględne ścieżki serwera przez /api/datasources/verify i odróżnić czytelne istniejące pliki od brakujących, porównując błąd sterownika, co ujawniało istnienie i czytelność plików na współdzielonym serwerze. Problem został naprawiony w wersji 3.40.1.

Budibase przed wersją 3.39.32 udostępnia endpoint GET /api/global/users/tenant/:id w PUBLIC_ENDPOINTS, a funkcja tenantUserLookup zwraca pełny dokument PlatformUser. Nieuwierzytelniony atakujący może sprawdzić istnienie użytkownika, uzyskać identyfikatory dzierżawy, identyfikatory użytkowników, adresy e-mail, identyfikatory SSO i metadane rewizji dokumentów.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.39.25, packages/server/src/api/controllers/automation.ts zwracał wyniki testów automatyzacji zawierające trigger.outputs.user.oauth2, broadcastował BuilderSocketEvent.AutomationTestProgress do pokoju aplikacji i przechowywał postęp w packages/server/src/automations/testProgress.ts bez zakresu użytkownika. Współbudowniczy mógł otrzymać lub odpytać test innego buildera uwierzytelnionego przez SSO i uzyskać tokeny dostępu i odświeżania OAuth2. Poprawka dodaje sanitizeAutomationTestResult i izoluje postęp według użytkownika. Problem został naprawiony w wersji 3.39.25.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.39.4, uploadUrl w packages/server/src/utilities/fileUtils.ts używał surowego fetch po stronie serwera dla wartości załączników przekazywanych przez processAttachments w packages/server/src/sdk/workspace/ai/helpers/rows.ts. Builder z funkcją generowania tabel AI mógł spowodować, że wartość załącznika odnosi się do wewnętrznej usługi lub punktu końcowego metadanych chmury, a odpowiedź byłaby przechowywana jako załącznik bez walidacji fetchWithBlacklist. Problem został naprawiony w wersji 3.39.4.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.39.25, POST /api/global/auth/:tenantId/login zwiększał licznik nieudanych prób w packages/worker/src/api/controllers/global/auth.ts tylko dla istniejących użytkowników, podczas gdy packages/worker/src/middleware/emailLockout.ts zwracał X-Account-Locked i Retry-After tylko dla zablokowanych identyfikatorów. Nieuwierzytelniony atakujący mógł porównać odpowiedź po powtarzających się niepowodzeniach, aby wyliczyć prawidłowe adresy e-mail i tymczasowo zablokować prawidłowe konta. Problem został naprawiony w wersji 3.39.25.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.40.0, endpoint POST /api/v2/email na account.budibase.app akceptował kontrolowany przez klienta identyfikator accountId bez powiązania go z uwierzytelnioną sesją, sprawdzając tylko bieżący adres e-mail. Uwierzytelniony atakujący, który zdobędzie identyfikator konta ofiary, może rozpocząć proces zmiany adresu e-mail dla ofiary, otrzymać i przesłać kod weryfikacyjny przez POST /api/v2/email/verification, przenieść adres e-mail ofiary na adres kontrolowany przez atakującego i ukończyć reset hasła jako ofiara. Problem został naprawiony w wersji 3.40.0.

W Budibase przed wersją 3.39.25, endpoint GET /api/global/groups nie wymagał uprawnień buildera ani administratora, co pozwalało uwierzytelnionemu użytkownikowi z rolą BASIC na wyliczenie grup, mapowań ról, członkostw użytkowników, uprawnień buildera i flag grup domyślnych.

Budibase przed wersją 3.38.1 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w integracji źródła danych REST, która nie waliduje przekierowań HTTP względem czarnej listy IP. Atakujący z rolą Builder może skonfigurować źródło danych REST wskazujące na zewnętrzny serwer, który zwraca przekierowanie na wewnętrzne adresy IP, omijając ochronę czarnej listy i uzyskując dostęp do punktów końcowych metadanych chmury oraz wewnętrznych usług.

Budibase przed wersją 3.39.9 zawiera podatność na atak SSRF z wykorzystaniem DNS rebinding. Uwierzytelnieni użytkownicy z uprawnieniami automatyzacji mogą ominąć czarną listę adresów IP, ponieważ walidacja hosta przed wysłaniem żądania nie jest powiązana z rzeczywistym połączeniem.

Budibase przed wersją 3.39.9 zawiera podatność w punkcie końcowym webhooka, który jest publicznie dostępny i przekazuje pełne ciało żądania HTTP do parametrów automatyzacji. Atakujący może nadpisać wewnętrzną właściwość appId, co pozwala na wykonanie automatyzacji w kontekście ofiary i uzyskanie pełnego dostępu do jej bazy danych.

Budibase przed wersją 3.39.3 udostępnia nieuwierzytelniony endpoint generujący podpisane URL-e S3 PutObject przy użyciu poświadczeń z datasource przestrzeni roboczej. Trasa jest chroniona tylko przez middleware recaptcha i nie wymaga uwierzytelnienia, uprawnień do tabeli, datasource ani dostępu budowniczego.

Podatność w Budibase przed wersją 3.39.0 umożliwia atakującemu trwałe powiązanie konta ofiary z zewnętrzną tożsamością czatu (Slack/Discord/MS Teams) bez zgody użytkownika. Publiczny endpoint nie wymaga uwierzytelnienia ani ochrony CSRF, a atak polega na nakłonieniu uwierzytelnionego użytkownika do odwiedzenia spreparowanego URL.

Budibase przed wersją 3.33.4 zawiera podatność na path traversal w endpointcie uploadu plików wtyczek (POST /api/plugin/upload). Atakujący z uprawnieniami Global Builder może przesłać plik z nazwą zawierającą ../, co pozwala na usunięcie dowolnych katalogów i zapis dowolnych plików w systemie plików.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.33.4 krok automatyzacji bash wykonuje polecenia dostarczone przez użytkownika za pomocą execSync bez odpowiedniej sanityzacji lub walidacji. Dane wejściowe użytkownika są przetwarzane przez processStringSync, co umożliwia interpolację szablonów, potencjalnie pozwalając na wykonanie dowolnych poleceń.