Podatności jshERP

jshERP w wersji do 3.6 zawiera lukę braku autoryzacji w endpointcie POST /user/batchSetStatus, która pozwala uwierzytelnionym użytkownikom o niskich uprawnieniach zmieniać status kont innych użytkowników. Atakujący mogą przesłać spreparowane identyfikatory i wartości statusu, aby wyłączyć wszystkie konta niebędące właścicielem w swoim tenancie, blokując administratorów, lub ponownie włączyć wyłączone konta.

jshERP do wersji 3.6 zawiera lukę braku autoryzacji, która pozwala uwierzytelnionym użytkownikom z niskimi uprawnieniami tworzyć dane podstawowe na poziomie całej dzierżawy (tenant) poprzez punkty końcowe add i import, które nie sprawdzają ról. Atakujący mogą wysyłać żądania POST do /account/add, /material/add lub /material/importExcel, aby tworzyć konta rozliczeniowe, produkty z początkowym stanem magazynowym, działy i wpisy słownikowe.

jshERP do wersji 3.6 zawiera podatność ujawnienia informacji, która pozwala każdemu uwierzytelnionemu użytkownikowi odczytać sekrety konfiguracyjne całej platformy przez procedurę getInfoByKey kontrolera PlatformConfigController. Użytkownicy o niskich uprawnieniach z dowolnej dzierżawy mogą żądać dowolnych wartości platformKey, takich jak email_auth_code lub activation_code, aby uzyskać kody autoryzacji SMTP i sekrety aktywacyjne, ponieważ tylko klucze aliOss i weixin są blokowane.

jshERP do wersji 3.6 zawiera podatność masowego przypisania w handlerze aktualizacji UserController, która pozwala uwierzytelnionym użytkownikom nadpisać chronione pola, w tym tenant_id i hasło. Atakujący mogą wysłać spreparowane ciało żądania PUT /user/update, aby przy następnym logowaniu przełączyć się do innej dzierżawy lub nadpisać skróty haseł innych użytkowników w celu przejęcia konta.

jshERP do wersji 3.6 zawiera podatność braku autoryzacji w handlerze updateUser kontrolera UserController, która pozwala uwierzytelnionym użytkownikom przypisać dowolne role dowolnemu użytkownikowi. Atakujący o niskich uprawnieniach mogą wysłać własny identyfikator użytkownika z identyfikatorem roli administratora dzierżawy, aby podnieść uprawnienia lub zmienić role innych użytkowników dzierżawy.

jshERP do wersji 3.6 zawiera podatność nieprawidłowej autoryzacji, która pozwala uwierzytelnionym użytkownikom o niskich uprawnieniach odczytać dowolną księgę kont rozliczeniowych, podając dowolne accountId. Atakujący ograniczeni do zakresu danych osobowych lub działowych mogą wysyłać zapytania GET /account/findAccountInOutList, aby przeglądać numery rachunków, kontrahentów, kwoty i uwagi innych użytkowników w ramach dzierżawy.

jshERP do wersji 3.6 zawiera podatność obejścia autoryzacji, która pozwala uwierzytelnionym użytkownikom tworzyć wstępnie zatwierdzone rachunki, ustawiając status w żądaniach POST /depotHead/addDepotHeadAndDetail. Atakujący mogą podać status 1, aby pominąć kontrole uprawnień audytu i wielopoziomowe procesy zatwierdzania, tworząc rachunki zatwierdzone, które wpływają na stan magazynowy i zapytania raportowe.

jshERP do wersji 3.6 zawiera podatność nieprawidłowej autoryzacji w GET /supplier/exportExcel, która pozwala uwierzytelnionym użytkownikom ominąć ograniczenia zakresu danych ról egzekwowane przez /supplier/list. Atakujący ograniczeni do danych osobowych lub działowych mogą eksportować wszystkie rekordy dostawców, klientów i członków, ujawniając kontakty, numery telefonów, numery podatkowe, konta bankowe i salda.

jshERP do wersji 3.6 zawiera podatność obejścia autoryzacji, która pozwala uwierzytelnionym użytkownikom ograniczonym do danych osobowych lub działowych na listowanie rachunków innych użytkowników poprzez dodanie wartości purchaseStatus. Atakujący mogą dodać purchaseStatus=0 do JSON-a wyszukiwania w GET /depotHead/list, co powoduje, że DepotHeadService.select usuwa filtr twórcy i ujawnia wszystkie rachunki zakupu, sprzedaży i magazynowe w dzierżawie.

jshERP do wersji 3.6 zawiera lukę obejścia autoryzacji, która pozwala uwierzytelnionym użytkownikom na odczyt danych z nieprzypisanych magazynów poprzez podanie parametrów depotId lub depotIds. Gdy włączone jest ograniczenie magazynów depot_flag, atakujący może wskazać dowolne identyfikatory magazynów w endpointach takich jak /depotItem/getMaterialDepotStockByParam, aby odczytać stany magazynowe, numery partii, dane sprzedażowe i wycenione pozycje faktur w obrębie tenanta.

jshERP do wersji 3.6 zawiera lukę braku autoryzacji w LogController, która pozwala każdemu uwierzytelnionemu użytkownikowi na odczyt dziennika audytu operacji tenanta. Użytkownicy o niskich uprawnieniach mogą wysyłać żądania GET do /log/list lub /log/info, aby wyświetlić nazwy logowania innych użytkowników, adresy IP klientów i wykonywane akcje.

jshERP do wersji 3.6 zawiera lukę braku autoryzacji w LogController, która pozwala każdemu uwierzytelnionemu użytkownikowi na fałszowanie, modyfikowanie lub usuwanie wpisów dziennika audytu. Użytkownicy o niskich uprawnieniach mogą wywoływać /log/add, /log/update, /log/delete i /log/deleteBatch, aby tworzyć fałszywe wpisy, zmieniać pola użytkownika i IP lub usuwać rekordy w celu ukrycia aktywności.

W jishenghua jshERP do wersji 3.5 wykryto podatność w funkcji updateAccountHeadAndDetail w pliku AccountHeadService.java, w komponencie aktualizacji paragonów finansowych. Manipulacja prowadzi do nieprawidłowej autoryzacji. Atak można zainicjować zdalnie, a exploit został publicznie ujawniony.

jshERP do wersji 3.6 zawiera podatność obejścia autoryzacji w endpointach CRUD userBusiness, która pozwala uwierzytelnionym użytkownikom tworzyć, modyfikować lub usuwać wiersze relacji autoryzacyjnych bez sprawdzania uprawnień. Atakujący mogą manipulować mapowaniami użytkownik-rola i kontrolą dostępu, aby podnieść uprawnienia, odebrać dostęp innym kontom lub zmodyfikować relacje rola-funkcja dla dowolnego użytkownika w tenancie.

jshERP do wersji 3.6 nie weryfikuje własności obiektów w endpointach informacji, aktualizacji i usuwania po identyfikatorze w wielu typach zasobów. Uwierzytelnieni użytkownicy mogą odczytywać, modyfikować i usuwać obiekty biznesowe innych użytkowników, podając bezpośrednie identyfikatory obiektów bez sprawdzania autoryzacji.

jshERP do wersji 3.6 nie weryfikuje uprawnień wywołującego w endpointach zarządzania rolami, co pozwala uwierzytelnionym użytkownikom modyfikować zakres danych dowolnej roli lub usuwać role. Atakujący mogą wykorzystać endpointy /role/update i /role/delete, aby podnieść uprawnienia, zmienić widoczność danych na wszystkie dane i uzyskać dostęp do wszystkich rekordów biznesowych w tenancie.

jshERP do wersji 3.6 nie weryfikuje prawidłowo uprawnień użytkownika w SystemConfigService.updateSystemConfig, co pozwala uwierzytelnionym użytkownikom modyfikować konfigurację systemową tenanta. Atakujący mogą przepisać lub usunąć ustawienia obejmujące tożsamość firmy, reguły magazynowe, zachowanie zatwierdzeń i konfigurację drukowania przez endpoint systemConfig.

jshERP do wersji 3.6 zawiera podatność obejścia izolacji dzierżawców, która pozwala uwierzytelnionym użytkownikom odczytywać rekordy innych dzierżawców przez endpoint GET /tenant/info. Atakujący może iterować klucz główny, aby wyliczyć i uzyskać dostęp do danych wrażliwych, takich jak nazwy logowania, daty ważności, limity użytkowników i stan włączenia wszystkich dzierżawców platformy.

jshERP do wersji 3.6 nie sprawdza autoryzacji na endpoincie POST /userBusiness/updateBtnStr, co pozwala uwierzytelnionym użytkownikom modyfikować definicje uprawnień przycisków ról. Atakujący może podać dowolne parametry roleId i btnStr, aby nadpisać konfigurację uprawnień przycisków dla dowolnej roli w dzierżawie bez weryfikacji uprawnień.

jshERP do wersji 3.6 nie usuwa skrótów haseł w endpoincie /user/info, co pozwala uwierzytelnionym użytkownikom pobrać niesolone skróty MD5 haseł dowolnego użytkownika. Atakujący może podać identyfikatory użytkowników, aby uzyskać skróty haseł nadające się do łamania offline lub bezpośredniego obejścia uwierzytelniania.

jshERP do wersji 3.6 zawiera podatność obejścia autoryzacji w endpoincie POST /user/resetPwd, która pozwala uwierzytelnionym użytkownikom zresetować hasło dowolnego innego użytkownika. Atakujący może wysłać żądanie z dowolnym identyfikatorem użytkownika docelowego, aby zresetować hasło tego konta do znanej wartości domyślnej.

jshERP 3.6 zawiera podatność eskalacji uprawnień w endpoincie updateOneValueByKeyIdAndType, która pozwala uwierzytelnionym użytkownikom przyznać sobie dowolne role. Atakujący może wysłać żądanie POST z type=UserRole, własnym identyfikatorem użytkownika i listą identyfikatorów ról, aby awansować z nisko uprzywilejowanego użytkownika tenanta na administratora tenanta.

W jishenghua jshERP do wersji 3.6 stwierdzono podatność na SSRF (Server-Side Request Forgery) w funkcji insertPlatformConfig w pliku PlatformConfigService.java. Manipulacja argumentem platformValue umożliwia zdalne wykonanie żądań po stronie serwera.

W jishenghua jshERP do wersji 3.6, funkcja addAccountHeadAndDetail w pliku AccountHeadService.java jest podatna na path traversal poprzez argument fileName, co pozwala zdalnemu atakującemu na manipulację ścieżką pliku.

Wykryto podatność bezpieczeństwa w jishenghua jshERP do wersji 3.6. Dotyczy ona funkcji getUserByWeixinCode w pliku jshERP-boot/src/main/java/com/jsh/erp/service/UserService.java komponentu endpoint updatePlatformConfigByKey. Manipulacja argumentem weixinUrl prowadzi do server-side request forgery (SSRF). Atak można wykonać zdalnie. Exploit został publicznie ujawniony i może być wykorzystany. Projekt został wcześnie poinformowany o problemie poprzez zgłoszenie issue, ale jeszcze nie odpowiedział.

jshERP w wersji 3.5 i wcześniejszych jest podatny na podatność typu stored Cross Site Scripting (XSS) poprzez endpoint /msg/add. Złośliwy skrypt jest zapisywany na serwerze i wykonywany w przeglądarce użytkownika.

jshERP w wersji 3.5 i wcześniejszych jest podatny na stored XSS. Podatność pozwala atakującemu na przesyłanie plików PDF zawierających ładunki XSS, które następnie są dostępne przez statyczne adresy URL dla wszystkich użytkowników.

W systemie jshERP v3.5 w komponencie PersonController.java występuje nieprawidłowa kontrola dostępu, która umożliwia nieautoryzowanym atakującym uzyskanie wszystkich informacji o osobach obsługujących system poprzez wykonanie metody getAllList.

W systemie jshERP v3.5 w komponencie ResourceController.java występuje podatność polegająca na nieprawidłowej kontroli dostępu. Nieautoryzowany atakujący może uzyskać wszystkie odpowiadające dane ID, modyfikując wartość ID.

W jshERP v3.5 w komponencie RoleController.java występuje nieprawidłowa kontrola dostępu, która umożliwia nieautoryzowanym atakującym dowolną modyfikację statusu dostawcy na dowolnym koncie.

W systemie jshERP v3.5 w komponencie SupplierController.java występuje nieprawidłowa kontrola dostępu, umożliwiająca nieautoryzowanym atakującym dowolną modyfikację statusu dostawcy na dowolnym koncie.

W systemie jshERP v3.5 w pliku UserController.java występuje nieprawidłowa kontrola dostępu, która umożliwia atakującym dowolne resetowanie haseł użytkowników. Podatność ta pozwala na przeprowadzenie ataku polegającego na eskalacji uprawnień w poziomie.