Aktywnie wykorzystywana krytyczna podatność w wirtualnej centrali FreePBX

Ataki na rozwiązania używane do świadczenia usług VoIP nie są niczym nowym. Wielokrotnie pisaliśmy też na łamach sekuraka na temat (nie)bezpieczeństwa wszelakich interfejsów webowych. Tym razem mamy połączenie jednego i drugiego.

TLDR:

– Wykryto krytyczną (CVSS 10.0) podatność w FreePBX, interfejsie webowym dla Asterisk

– Podatność jest aktywnie wykorzystywana przez atakujących

– Stanowczo zaleca się możliwie jak najszybszą aktualizację, a w sytuacji, kiedy nie jest to możliwe ograniczenie dostępu do panelu administratora

Sytuacja jest bardzo poważna i dotyczy FreePBX, webowego interfejsu graficznego (GUI), będącego nakładką rozszerzającą możliwości Asteriska. Ten popularny PBX jest powszechnie wykorzystywany w większych i mniejszych organizacjach, np. w call centers, czy jako wewnętrzna centrala telefoniczna. Niestety korzyści, jakie może dawać kontrola nad taką centralą telefoniczną będącą najczęściej bramą do sieci PSTN dostępną z internetu sprawiają, że jest ona łakomym kąskiem dla cyberprzestępców. FreePBX dając interfejs graficzny oraz moduły rozszerzające jego funkcjonalność znacząco ułatwia zarządzanie Asteriskiem.

Opis podatności i zalecane postępowanie

Zespół ds. bezpieczeństwa Sangoma FreePBX poinformował o możliwej eksploitacji podatności typu authentication bypass prowadzącej do SQL Injection i RCE. Z informacji przekazanych przez twórców oprogramowania dowiadujemy się, że luka będąca początkowo 0-dayem jest aktywnie wykorzystywana co najmniej od 21 sierpnia. W ramach systemu CVSS 4.0 podatność oznaczona identyfikatorem CVE-2025-57819 otrzymała najwyższą możliwą ocenę 10.0 (critical). Jak można dowiedzieć się z raportu bezpieczeństwa na GitHubie FreePBX:

„(…) an unauthorized user began accessing multiple FreePBX version 16 and 17 systems that were connected directly to the public internet — systems with inadequate IP filtering/ACLs — by exploiting a validation/sanitization error in the processing of user-supplied input to the commercial „endpoint” module. This initial entry point was then chained with several other steps to ultimately gain potentially root level access on the target systems.”

Aby mogło dojść do eksploitacji atakujący musi uzyskać dostęp do modułu ACP (Administrator Content Panel). Krok ten ułatwia wystawienie panelu w niezaufanej sieci, np. Internecie. Niewystarczająca sanityzacja (oczyszczanie) wysyłanych przez użytkownika danych umożliwia wysyłanie odpowiednio spreparowanych żądań, które następnie prowadzą do ataku SQL Injection i manipulacji bazą danych, co finalnie skutkuje zdalnym wykonaniem kodu (Remote Code Execution). Jak dotychczas PoC (Proof of Concept) exploitu nie został opublikowany, jednak wskaźniki IOC oraz relacje użytkowników sugerują, że atakujący umieszcza na zaatakowanym serwerze plik modular.php, z którym potem nawiązuje kontakt wysyłając żądania POST. Obecność skryptu .clean.sh może oznaczać próbę zatarcia śladów wrogiej działalności na zaatakowanym systemie.

Wkrótce po opublikowaniu komunikatu udostępniona została poprawka z linii edge. To specjalny rodzaj szybkich aktualizacji, które w przeciwieństwie do tych z linii stable nie przeszły pełnego procesu QA (Quality Assurance). Obecnie dla linii 15, 16 i 17 dostępne są już stabilne wersje zawierające wspomnianą wyżej poprawkę. Aby skorzystać z aktualizacji należy z uprawnieniami konta root wydać polecenie:

fwconsole ma upgradeall

Aktualizacji można dokonać także przy pomocy modułu Admin w ACP.

W tym miejscu warto zauważyć, że nie każdy użytkownik może otrzymać aktualizację. Aktywna licencja oznacza, że mamy prawo do używania naszego EPM-a, jednak nie jest to tożsame z prawem do otrzymywania aktualizacji (posiadaniem aktywnego wsparcia). Ci, którzy nie mogą zainstalować nowej wersji powinni niezwłocznie zablokować dostęp do swojego ACP. Wersje, które utraciły wsparcie (poniżej linii 15) nie zostały przetestowane pod kątem możliwości eksploitacji, co oznacza, że nie są znane możliwości wykorzystania ich pod kątem CVE-2025-57819.

W komunikacie opublikowanym na stronie producenta podkreślono, że aktualizacje nie usuwają skutków ataku w zaatakowanych już systemach. Administratorzy, którzy podejrzewają swoje systemy o to, że mogły paść ofiarą ataku powinni zapoznać się z opublikowanymi przez zespół FreePBX zaleceniami. W szczególności warto zwrócić uwagę na konieczność zachowania kopii zapasowych sprzed ataku, czyli sprzed co najmniej 21 sierpnia. W miarę możliwości powinno się rozważyć zachowanie migawki zainfekowanego systemu w celu późniejszych analiz.

Co robić?

Wszystkim administratorom FreePBX zalecamy zapoznanie się ze wskaźnikami IOC:

– plik /etc/freepbx.conf ostatnio został zmodyfikowany lub brakuje go w systemie

– występowanie pliku /var/www/html/.clean.sh (ślady pozostałości po exploicie)

– żądania POST do pliku modular.php w logach serwera WWW

– połączenia telefoniczne kierowane na wewnętrzny numer 9998 w rejestrach połączeń i rejestrach połączeń przychodzących w Asterisk mające swój początek najczęściej 21 sierpnia

– użytkownik ampuser w tabeli ampusers w bazie danych MariaDB/MySQL lub inni nieznani użytkownicy

Zapraszamy do zapoznania się ze stale aktualizowanymi informacjami na stronie internetowej FreePBX. Warto zajrzeć także do raportu bezpieczeństwa zamieszczonego na githubowym profilu projektu.

Podsumowanie

Wszelkie dobre praktyki bezpieczeństwa zalecają stałe śledzenie nowych wersji posiadanego przez nas oprogramowania. Niestety nawet kiedy „jesteśmy aktualni” musimy liczyć się z możliwością wykorzystania w naszych systemach podatności, które nie są jeszcze znane twórcom użytkowanego przez nas oprogramowania i tym samym nie ma dla nich odpowiednich poprawek. Niezwykle rzadkie są sytuacje, kiedy na dużą skalę wykorzystywane są błędy typu 0-day, jednakże przypadek ten pokazuje, że bez względu na poziom krytyczności systemu, występowanie takiego zagrożenia nie powinno być pomijane w naszej polityce bezpieczeństwa.

Źródło: FreePBX, GitHub

~pu