Podatności FrontAccounting

FrontAccounting przed wersją 2.4.20 zawiera podatność na wstrzykiwanie SQL w module raportu audytu. Uwierzytelnieni atakujący z uprawnieniami SA_GLANALYTIC mogą wstrzykiwać złośliwy kod do parametrów POST PARAM_2 i PARAM_3, wykonując dowolne zapytania SQL.

W FrontAccounting przed wersją 2.4.20 występuje podatność na wstrzykiwanie SQL w module raportu wyciągu bankowego. Uwierzytelniony atakujący może wstrzyknąć złośliwe zapytania UNION SELECT do parametru PARAM_0 POST, co pozwala na wyodrębnienie dowolnych danych z bazy, w tym nazw użytkowników, skrótów haseł i adresów e-mail, które są renderowane w raporcie PDF.

Wielokrotne podatności na wstrzykiwanie SQL w FrontAccounting (FA) przed wersją 2.3.21 umożliwiają zdalnym atakującym wykonywanie dowolnych poleceń SQL za pomocą nieokreślonych wektorów.

FrontAccounting do wersji 2.4.20 przechowuje i weryfikuje hasła użytkowników jako niesolone skróty MD5. admin/users.php przekazuje md5($_POST['password']) do add_user() i update_user_password(), admin/change_current_user_password.php robi to samo, gdy użytkownik zmienia własne hasło, ścieżka zapomnianego hasła w includes/current_user.inc haszuje nowo wygenerowane hasło w ten sam sposób, a uwierzytelnianie wywołuje get_user_auth($loginname, md5($password)). Kod nie stosuje soli per hasło i nie zawiera wywołań password_hash(), password_verify() ani żadnego innego adaptacyjnego haszowania, więc identyczne hasła dają identyczne skróty, a atakujący, który uzyska tabelę użytkowników, może odzyskać hasła w postaci jawnej za pomocą prekomputerowanych tablic lub szybkiego łamania na GPU.

FrontAccounting do wersji 2.4.20 generuje token CSRF w end_form() w includes/ui/ui_controls.inc i osadza go jako ukryte pole _token w każdym formularzu, ale tylko admin/users.php i admin/change_current_user_password.php wywołują check_csrf_token() w celu jego walidacji. Żaden moduł obsługi transakcji finansowych nie waliduje tokenu, w tym gl/gl_journal.php, gl/gl_bank.php, purchasing/supplier_invoice.php, sales/customer_invoice.php, sales/customer_payments.php i admin/company_preferences.php, więc te punkty końcowe działają na danych POST bez sprawdzania pochodzenia. Atakujący, który sprawi, że uwierzytelniony użytkownik załaduje stronę pod kontrolą atakującego, może automatycznie wysłać formularz z innego pochodzenia do dowolnego z nich i spowodować zapisanie sfałszowanego wpisu księgowego, faktury, płatności klienta, transakcji bankowej lub zmiany konfiguracji firmy w sesji ofiary.

FrontAccounting przed wersją 2.4.20 zawiera podatność na wstrzykiwanie SQL w funkcji get_gl_transactions(), gdzie parametr filter_type jest bezpośrednio konkatenowany do klauzuli SQL IN() bez parametryzacji. Atakujący z uprawnieniami SA_GLANALYTIC mogą wstrzyknąć dowolny SQL, dostarczając zamykający nawias i złośliwe warunki, aby wyodrębnić poufne dane wpisów księgowych poprzez ślepe wstrzykiwanie SQL oparte na różnicach w rozmiarze odpowiedzi.

Podatność path traversal w FrontAccounting przed wersją 2.4.20 pozwala uwierzytelnionym atakującym na zdalne wykonanie kodu poprzez przesyłanie plików z sekwencjami nawigacji w parametrze unique_name. Atakujący mogą zapisać plik PHP poza katalogiem załączników do katalogu głównego serwera WWW, co umożliwia wykonanie dowolnego kodu.