Podatności FOSSBilling

FOSSBilling w wersjach od 0.6.0 do 0.7.2 zawiera podatność umożliwiającą ominięcie płatności bez uwierzytelnienia. Atakujący może oznaczyć dowolną niezapłaconą fakturę jako opłaconą i zasilić konto klienta, wysyłając jeden spreparowany request HTTP do endpointu IPN.

FOSSBilling w wersjach 0.7.2 i wcześniejszych posiada podatność w API gościa, która pozwala na tworzenie nowych kont administratorów mimo istnienia już jednego administratora. Błąd w sprawdzaniu istnienia administratora umożliwia atakującemu ominięcie zabezpieczeń.

FOSSBilling przed wersją 0.8.0 ma podatność na wstrzykiwanie szablonów po stronie serwera (SSTI) w systemie renderowania szablonów. Administratorzy mogą wstrzykiwać dowolne wyrażenia Twig, co prowadzi do ujawnienia informacji i zdalnego wykonania kodu.

FOSSBilling w wersjach od 0.5.4 do 0.8.0 ma lukę w autoryzacji w obsłudze ról API, co pozwala na nieautoryzowany dostęp do uprzywilejowanych punktów końcowych `/api/system/*`. Atakujący mogą wywoływać metody API administratora bez ważnych poświadczeń.

W FOSSBilling przed wersją 0.8.1 pliki produktów do pobrania są przechowywane pod ścieżką deterministycznie zależną od nazwy pliku (hash MD5). Dwóch różnych produktów lub plików zamówień o tej samej oryginalnej nazwie nadpisuje się nawzajem, co prowadzi do dostarczenia klientom lub administratorom nieprawidłowego pliku.

W FOSSBilling w wersjach od 0.5.3 do 0.7.2, endpoint API `serviceapikey/get_info` dla gości jest dostępny bez uwierzytelniania. Każdy posiadacz ważnego klucza API może odczytać wszystkie niestandardowe parametry konfiguracyjne (`custom_*`) przechowywane w rekordzie bazy danych klucza.

W systemie FOSSBilling w wersjach od 0.5.6 do 0.7.2 istnieje podatność polegająca na tym, że przy wielokrotnym żądaniu resetowania hasła przez tego samego klienta, nie jest generowany nowy token, a wykorzystywany jest istniejący, ważny przez 15 minut od pierwotnego żądania. Atakujący, który przechwycił pierwszy link resetujący, może go użyć nawet po tym, jak ofiara zażąda nowego resetu, ponieważ oryginalny token nie jest unieważniany.

FOSSBilling przed wersją 0.8.0 zawiera podatność, która pozwala pracownikowi z niskimi uprawnieniami na eskalację swoich uprawnień poprzez API administracyjne. Użytkownik z uprawnieniem `staff.create_and_edit_staff` może wywołać endpoint `/api/admin/staff/permissions_update` dla własnego konta i ustawić dowolne uprawnienia, omijając kontrolę dostępu opartą na rolach.

FOSSBilling w wersjach 0.5.3 do 0.7.2 umożliwia uwierzytelnionym klientom odczyt i resetowanie kluczy API dla zamówień, które nie są już aktywne (np. zawieszone, anulowane). Brakuje walidacji stanu zamówienia w dwóch punktach końcowych API klienta, mimo że istnieje pomocnicza funkcja `isActive()` w module `Serviceapikey`, a interfejs użytkownika poprawnie blokuje dostęp dla nieaktywnych zamówień.

FOSSBilling w wersjach przed 0.8.0 umożliwia kontom personelu o niskich uprawnieniach wykonywanie nieautoryzowanych działań poprzez punkty końcowe API administratora. Problem wynika z połączenia flagi modułu `can_always_access` (przyznającej dostęp wszystkim pracownikom) oraz niewystarczających kontroli uprawnień lub niebezpiecznego przetwarzania parametrów na poszczególnych punktach końcowych.

W FOSSBilling w wersjach od 0.5.6 do 0.7.2, gdy włączone jest ustawienie „Wymagaj potwierdzenia e-mail”, zalogowany klient z niepotwierdzonym adresem e-mail może uzyskać dostęp do wszystkich stron strefy klienta, takich jak saldo portfela czy historia transakcji. Ograniczenia po stronie API działają poprawnie, ale po stronie stron są zbyt liberalne, przepuszczając każde żądanie zaczynające się od „/client”.

FOSSBilling w wersjach od 0.6.0 do 0.7.2 zawiera podatność na trwałe skrypty między witrynami (XSS) w widokach historii e-maili widocznych dla klientów. Treść HTML e-maili jest renderowana w szablonie JavaScript bez odpowiedniego kodowania, co pozwala atakującemu z dostępem administracyjnym na wstrzyknięcie złośliwego kodu JavaScript.

FOSSBilling przed wersją 0.8.0 zawiera podatność, w której konta personelu o niskich uprawnieniach mogą odczytywać wrażliwe dane poprzez punkty końcowe API administratora pozbawione kontroli dostępu. Punkty końcowe do zapisu poprawnie egzekwują uprawnienia, ale odpowiadające im punkty odczytu nie mają żadnych zabezpieczeń autoryzacyjnych.

W systemie FOSSBilling w wersji przed 0.8.0 adapter płatności PayPalEmail akceptuje wywołania zwrotne IPN i uznaje kwotę podaną w IPN (`mc_gross`) na saldo klienta bez weryfikacji z całkowitą kwotą faktury. W połączeniu z tolerancją błędu zmiennoprzecinkowego wynoszącą 0,05 USD w logice kredytowania płatności faktury, umożliwia to klientowi niedopłacenie faktury o maksymalnie 0,04 USD i nadal oznaczenie jej jako w pełni opłaconej.

W systemie FOSSBilling przed wersją 0.8.0 występuje warunek wyścigu w procesie realizacji koszyka, który umożliwia uwierzytelnionemu klientowi wielokrotne użycie kodu promocyjnego pomimo ustawionego limitu. Wysyłając równoczesne żądania finalizacji zamówienia, klient może uzyskać nieograniczoną liczbę zamówień z rabatem lub za darmo.

W systemie FOSSBilling przed wersją 0.8.0 wykryto podatność na masowe przypisanie w punkcie końcowym samorejestracji klienta. Niezautoryzowany atakujący może podczas rejestracji przypisać się do dowolnej grupy klientów, co umożliwia wykorzystanie kodów promocyjnych ograniczonych do danej grupy i uzyskanie nieautoryzowanych rabatów.

FOSSBilling w wersjach od 0.6.10 do 0.7.2 zawiera podatność na wstrzykiwanie kodu PHP w metodzie Config::prettyPrintArrayToPHP(). Atakujący z uprawnieniami administratora może wstrzyknąć dowolny kod PHP do pliku config.php, który jest wykonywany przy każdym żądaniu HTTP.

W systemie FOSSBilling przed wersją 0.8.0 zawieszanie lub dezaktywacja konta nie unieważnia istniejących sesji uwierzytelnionych. Mechanizm ładowania sesji nie sprawdza statusu konta, co pozwala zawieszonemu użytkownikowi zachować pełny dostęp do wygaśnięcia sesji.

W FOSSBilling przed wersją 0.8.0 brakuje autoryzacji w endpointcie Guest API invoice/update, co pozwala nieuwierzytelnionemu użytkownikowi ze znajomością hasha faktury na zmianę bramki płatności dla niezapłaconej faktury. Atakujący może wykorzystać wyciek hasha (np. przez udostępnione URL-e, nagłówki referrer lub linki e-mail) i zmienić `gateway_id` na dowolną skonfigurowaną w systemie bramkę.

FOSSBilling w wersjach od 0.6.0 do 0.7.2 zawiera podatność na wstrzykiwanie SQL w module Massmailer. Uwierzytelniony administrator może dostarczyć spreparowane wartości filtrów podczas aktualizacji wiadomości e-mail, co prowadzi do bezpośredniego wstawienia niezaufanego wejścia do zapytania SQL.

FOSSBilling w wersjach 0.7.2 i wcześniejszych ma lukę w API, która pozwala uwierzytelnionym klientom na dostęp do danych innych klientów poprzez zgadywanie identyfikatorów zamówień. Metoda __call w API nie weryfikuje, czy klient posiada zamówienie, co może prowadzić do ujawnienia danych osobowych.

FOSSBilling, system do zarządzania fakturami i klientami, ma podatność na IDOR w wersjach od 0.6.21 do 0.7.2, umożliwiającą uwierzytelnionym klientom tworzenie zgłoszeń wsparcia, które odnoszą się do zamówień innych klientów. Metoda ticketCreateForClient() nie weryfikowała własności zamówienia, co pozwalało na manipulację rel_id.

FOSSBilling przed wersją 0.8.0 nie stosuje ogranicznika szybkości (rate limiter) do endpointu potwierdzenia resetowania hasła `/client/reset-password-confirm/:hash`, ponieważ ogranicznik dotyczy tylko ścieżek `/api/*`. Umożliwia to atakującemu nieograniczone zgadywanie tokenów resetowania bez ograniczeń IP, prób lub blokady. Endpoint zwraca różne odpowiedzi dla ważnych i nieważnych tokenów (HTTP 200 vs 302), działając jak wyrocznia. Jednakże praktyczne wykorzystanie jest znacznie utrudnione przez generowanie tokenów za pomocą `hash('sha256', random_bytes(32))` (256 bitów entropii) oraz ich 15-minutowy czas ważności. Podobny problem dotyczy innych ścieżek uwierzytelniania, takich jak `/staff/email/:hash` i `/client/confirm-email/:hash`. Wersja 0.8.0 naprawia problem.

FOSSBilling przed wersją 0.8.0 zawiera podatność na otwarte przekierowanie w module Redirect. Moduł nie sprawdza schematu URL w konfigurowanych przez administratora docelowych adresach, co pozwala na ustawienie dowolnych zewnętrznych URL-i jako celów przekierowania.

FOSSBilling przed wersją 0.8.0 ujawnia dokładną wersję systemu poprzez parametry cache buster w zasobach w wyjściu HTML, omijając ustawienie bezpieczeństwa hide_version_public.