Podatności Wekan

Wekan przed wersją 9.46 zawiera podatność w mechanizmie logowania przez nagłówek (header-login), gdzie funkcja getRequestIp() ufa nagłówkowi X-Forwarded-For dostarczonemu przez klienta przed rzeczywistym adresem gniazda. Pozwala to nieuwierzytelnionemu atakującemu na podszycie się pod dowolnego użytkownika, w tym administratora, poprzez wysłanie nagłówka HEADER_LOGIN_ID i uzyskanie sesji meteor_login_token.

W Wekan przed wersją 9.32, w hooku Accounts.onCreateUser w server/models/users.js, logowanie przez OIDC jest scalane z istniejącymi kontami, gdy adres e-mail lub nazwa użytkownika OIDC pasuje do istniejącego użytkownika Wekan, bez weryfikacji własności lub sprawdzenia email_verified. Atakujący używający konta OIDC z adresem e-mail lub nazwą użytkownika ofiary może scalić swoje dane uwierzytelniające OIDC z kontem ofiary, a następnie zalogować się jako to konto.

Wekan przed wersją 9.07 zawiera podatność na wstrzykiwanie poleceń w funkcji przesyłania awatarów. Nazwy plików dostarczone przez użytkownika są przekazywane do funkcji child_process.exec() bez odpowiedniego oczyszczenia, co umożliwia wykonanie dowolnych poleceń na serwerze poprzez znaki specjalne, takie jak backticki czy $().

WeKan przed wersją 8.19 zawiera podatność na wstrzykiwanie filtrów LDAP w mechanizmie uwierzytelniania LDAP. Wprowadzona przez użytkownika nazwa użytkownika jest używana w filtrach wyszukiwania LDAP i wartościach DN bez odpowiedniego escapowania, co umożliwia atakującemu manipulowanie zapytaniami LDAP podczas uwierzytelniania.

Wekan (wersje przed 10.38) zawiera podatność w kilku endpointach eksportu, gdzie token authToken jest pobierany z parametru zapytania i używany bez sprawdzenia, czy użytkownik istnieje. Żądanie do prywatnej tablicy z nieznanym tokenem powoduje TypeError i nieobsłużone odrzucenie, co może doprowadzić do zakończenia procesu Wekan i odmowy usługi dla wszystkich użytkowników. Wersja 10.38 dodaje zabezpieczenia 401 i opakowuje handlery funkcją safeRoute().

Wekan to open source'owa tablica kanban zbudowana w Meteor. Od wersji 8.72 do 10.23 funkcja addBoardHTMLToZip() w client/lib/exportHTML.js odczytywała tytuł i treść karty przez textContent, co dekodowało encje HTML, a następnie interpolowało titleText i allText do content.innerHTML w wyeksportowanym index.html. Członek tablicy mógł przechowywać zakodowany encją payload obsługi zdarzeń w tytule karty, który pozostawał nieaktywny na żywej tablicy, ale był ponownie parsowany i wykonywany, gdy odbiorca kliknął kartę w pobranym eksporcie HTML, umożliwiając skryptowi odczytanie i przesłanie wszystkich danych tablicy zawartych w tym eksporcie, w tym treści dodane po usunięciu członkostwa atakującego. Wersja 10.23 buduje modal z węzłami DOM i przypisuje niezaufane wartości przez textContent. Problem został naprawiony w wersji 10.23.

Wekan to open source'owa tablica kanban zbudowana w Meteor. Przed wersją 9.90 funkcja isFileValid() w models/fileValidation.js używała polecenia Unix 'file' do wykrywania MIME na podstawie zawartości, ale detectMimeFromFile() po cichu zwracała undefined, gdy ten binarny plik był niedostępny, a walidacja wracała do kontrolowanego przez atakującego fileObj.type dostarczanego przez server/routes/attachmentApi.js. Na wdrożeniach z WITH_API=true i bez pliku binarnego 'file', uwierzytelniony członek tablicy mógł oznaczyć HTML zawierający JavaScript jako image/png, ominąć niebezpieczne sprawdzenie MIME i przechowywać aktywną treść pod originem Wekan do wykonania, gdy inny użytkownik ją otworzył. Wersja 9.90 dodaje looksLikeDangerousMarkup() do inspekcji bajtów pliku i wymusza skanowanie niebezpiecznej zawartości, gdy wykrywanie MIME jest niedostępne. Problem został naprawiony w wersji 9.90.

Wekan to open source'owa tablica kanban zbudowana w Meteor. Przed wersją 9.89 druga reguła Boards.allow({ update }) w server/permissions/boards.js wywoływała canUpdateBoardSort w server/lib/utils.js, która autoryzowała każdego członka tablicy, gdy fieldNames zawierało 'sort'. Ponieważ Meteor łączy reguły allow z semantyką OR i stosuje kompletny modyfikator, członek z uprawnieniami tylko do komentarzy lub tylko do odczytu mógł wysłać jedno Boards.update z wartościami $set dla sort, members, permission i title, uczynić siebie jedynym administratorem tablicy, ujawnić prywatną tablicę i usunąć prawowitego właściciela; reguła deny dotycząca ostatniego administratora sprawdzała tylko $pull i nie blokowała całkowitego $set członków. Wersja 9.89 wymaga, aby 'sort' był jedynym modyfikowanym polem i odrzuca tablice $set członków, które usuwają ostatniego aktywnego administratora. Problem został naprawiony w wersji 9.89.

Wekan to open source'owa tablica kanban zbudowana w Meteor. Przed wersją 9.75, models/fileValidation.js interpolował przesłany fileObj.path do skonfigurowanego przez administratora externalCommandLine w miejscu {file} i wykonywał wynik przez asyncExec, który jest promisify(exec) i wywołuje `/bin/sh -c`. Na wdrożeniach ze skonfigurowanym zewnętrznym skanerem, uwierzytelniony użytkownik mogący przesłać załącznik mógł umieścić metaznaki powłoki, takie jak podstawienia poleceń, w nazwie pliku i wykonać polecenia jako proces serwera Wekan. Wersja 9.75 dodaje shellQuote() i przekazuje ścieżkę pliku jako argument w pojedynczych cudzysłowach POSIX, aby metaznaki powłoki nie mogły uciec z miejsca {file}. Problem został naprawiony w wersji 9.75.

Wekan (wersje od 9.57 do 9.74) zawiera podatność w trasie /api/boards/:boardId/exportExcel, gdzie funkcja autoryzacyjna exporterExcel.canExport(user) nie jest oczekiwana (brak await). Zwracana Promise jest zawsze prawdziwa, więc exporterExcel.build(res) wykonuje się nawet gdy board.isVisibleBy(user) odmawia dostępu. Pozwala to każdemu uwierzytelnionemu nie-członkowi na pobranie tytułów kart, opisów, list, swimlanes, członków i metadanych prywatnych tablic. Poprawka w wersji 9.74.

Wekan to open source'owa tablica kanban zbudowana w Meteor. Od wersji 8.36 do 9.74, walidator URL Integration URL w models/integrations.js sprawdzał tylko dosłowny URL.hostname względem wyrażeń regularnych, więc nazwy DNS takie jak 169-254-169-254.nip.io przechodziły pierwszą linię kontroli. Zabezpieczenie fetchSafe w ścieżce dostarczania już blokowało zgłoszone miejsce docelowe IPv4, ale jego oddzielny resolver tylko dla IPv4 i zduplikowana lista blokowania tworzyły niespójne egzekwowanie dla wszystkich rodzin adresów i ryzyko dryfu między walidacją przy wejściu a połączeniem. Wersja 9.74 sprawia, że server/lib/ssrfGuard.js rozwiązuje wszystkie adresy za pomocą `dns.lookup({ all: true })`, waliduje każdy wynik przez wspólną logikę isIpBlocked, przypina połączenie i blokuje przekierowania. Problem został naprawiony w wersji 9.74.

W Wekan przed wersją 9.37 reguły DDP update w plikach cards.js, lists.js i swimlanes.js autoryzują na podstawie przechowywanego źródłowego boardId, nie walidując nowego boardId w modyfikatorze aktualizacji. Uwierzytelniony użytkownik z prawem zapisu do swojej tablicy może przenieść karty, listy lub pasy pływackie do prywatnej tablicy, do której nie ma dostępu.

Wekan do wersji 9.34 zawiera podatność w metodzie cloneBoard, która pozwala uwierzytelnionemu użytkownikowi na sklonowanie dowolnej tablicy (znając jej ID) bez sprawdzania uprawnień. Umożliwia to odczyt kart, komentarzy, załączników, informacji o członkach i aktywności z tablic prywatnych.

W Wekan przed wersją 9.32 adresy URL webhooków przechowywane z danych wejściowych użytkownika nie są weryfikowane pod kątem połączeń do sieci wewnętrznych. Administrator tablicy może skonfigurować webhooki prowadzące do żądań serwerowych do wewnętrznych lub metadanych usług.

W Wekan przed wersją 9.32 metoda DDP copyBoard w server/publications/boards.js kopiuje tablicę na podstawie identyfikatora podanego przez wywołującego, bez sprawdzania this.userId, członkostwa ani uprawnień administratora. Każdy uwierzytelniony użytkownik może skopiować prywatną tablicę, której nie jest członkiem, wraz z jej kartami, listami kontrolnymi, polami niestandardowymi, etykietami i regułami.

W Wekan przed wersją 9.32 metody Meteor związane z OIDC są globalnie wywoływalne bez sprawdzania uprawnień administratora. Uwierzytelnieni użytkownicy mogą tworzyć lub modyfikować organizacje i zespoły, a także przyznawać globalne uprawnienia administratora, gdy włączona jest opcja PROPAGATE_OIDC_DATA.

W Wekan przed wersją 9.32, REST-owe procedury obsługi w server/models/customFields.js używają sprawdzania dostępu na poziomie odczytu (Authentication.checkBoardAccess) zamiast zapisu (Authentication.checkBoardWriteAccess) dla tras modyfikujących pola niestandardowe. Członek tablicy z uprawnieniami tylko do odczytu może wywoływać procedury POST, PUT i DELETE dla /api/boards/:boardId/custom-fields oraz elementów list rozwijanych pól niestandardowych, aby tworzyć, aktualizować lub usuwać niestandardowe pola tablicy.

Wekan do wersji 9.31 zawiera podatność umożliwiającą odczyt dowolnych plików i atak DoS. Zalogowany członek tablicy może wstawić załącznik z kontrolowaną ścieżką pliku, a serwer odczytuje go bez sprawdzania, czy znajduje się w dozwolonym katalogu.

W Wekan przed wersją 9.64 wykryto podatność polegającą na obejściu autoryzacji między tablicami w regułach dostępu dla list kontrolnych i elementów list kontrolnych. Uwierzytelniony użytkownik z niskimi uprawnieniami, mający dostęp do zapisu na jednej tablicy i znający identyfikator docelowej prywatnej karty, może utworzyć dane listy kontrolnej na dostępnej karcie i przenieść je do prywatnej tablicy, do której nie ma dostępu.

WeKan przed wersją 8.35 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w obsłudze adresów URL webhooków. Pole schematu URL akceptuje dowolny ciąg znaków bez ograniczeń protokołu lub walidacji docelowego adresu.

WeKan przed wersją 8.35 zawiera brak autoryzacji w punktach końcowych REST API integracji, co pozwala uwierzytelnionym członkom tablicy na wykonywanie działań administracyjnych bez odpowiedniej weryfikacji uprawnień. Atakujący mogą enumerować integracje, w tym adresy URL webhooków, tworzyć nowe integracje, modyfikować lub usuwać istniejące oraz zarządzać aktywnościami integracji, wykorzystując niewystarczające sprawdzanie uprawnień w procedurach REST JsonRoutes.

W Wekan przed wersją 8.20 użytkownicy niebędący administratorami mogą uzyskać dostęp do funkcji migracji z powodu niewystarczających kontroli uprawnień, co może prowadzić do nieautoryzowanych operacji migracyjnych.

W WeKan przed wersją 8.19 występuje luka w logice autoryzacji, gdzie ustawienie konfiguracji instancji allowPrivateOnly nie jest wystarczająco egzekwowane podczas tworzenia tablicy. Gdy allowPrivateOnly jest włączone, użytkownicy mogą nadal tworzyć publiczne tablice z powodu niekompletnego egzekwowania po stronie serwera.

Podatność IDOR w API tworzenia komentarzy w WeKan przed wersją 8.19 umożliwia uwierzytelnionemu użytkownikowi podszycie się pod innego użytkownika poprzez podanie jego identyfikatora w żądaniu. Atakujący może fałszować autora komentarza, co narusza integralność danych.

WeKan w wersjach przed 8.19 zawiera podatność autoryzacyjną w logice przenoszenia kart. Użytkownik może określić docelową tablicę/listę/tor pływacki bez odpowiednich kontroli autoryzacji dla miejsca docelowego i bez walidacji, czy obiekty docelowe należą do docelowej tablicy, co potencjalnie umożliwia nieautoryzowane przenoszenie kart między tablicami.

Podatność w WeKan przed wersją 8.19 polega na nieprawidłowej walidacji uprawnień w API aktualizacji kart. Niektóre ścieżki API sprawdzają jedynie dostęp do odczytu tablicy, zamiast wymagać uprawnień do zapisu.

Podatność IDOR w WeKan przed wersją 8.19 umożliwia manipulację identyfikatorami między tablicami podczas tworzenia list kontrolnych. Brak weryfikacji, czy podane cardId należy do podanego boardId, pozwala atakującemu na dostęp do list kontrolnych w innych tablicach.

Podatność IDOR w WeKan przed wersją 8.19 umożliwia manipulację identyfikatorami między tablicami podczas tworzenia list kontrolnych. Brak weryfikacji, czy podane cardId należy do podanego boardId, pozwala atakującemu na dostęp do list kontrolnych z innych tablic.

Podatność w WeKan przed wersją 8.19 umożliwia nieautoryzowany dostęp do metadanych załączników. Brak odpowiedniego ograniczenia zakresu wyników do tablic i kart dostępnych dla żądającego użytkownika może prowadzić do ujawnienia informacji.

Podatność w WeKan przed wersją 8.19 wynika z niewystarczającej walidacji identyfikatorów (boardId, cardId, swimlaneId, listId) w API do przesyłania załączników. Brak spójności tych identyfikatorów umożliwia atakującemu przesyłanie załączników z nieprawidłowymi relacjami między obiektami.