Jak źli hakerzy atakują internetowe fora? Groźne podatności vBulletin i polski wątek

Fora internetowe, chociaż lata świetności mają już za sobą, wciąż stanowią nieodłączny element krajobrazu Internetu. Mimo olbrzymiej ofensywy przeprowadzonej przez social media, na rynku można znaleźć kilka silników forumowych, znanych od lat. Utrzymanie takich platform z zachowaniem najlepszych praktyk bezpieczeństwa wymaga od administratorów tak oczywistych akcji jak np. przeprowadzanie regularnych aktualizacji. Jednym z najbardziej rozbudowanych komercyjnych silników, który może być wykorzystywany przez internetowe społeczności jest vBulletin.

TLDR:

• Krytyczne luki w vBulletin (CVE-2025-48827 – CVSS 10.0, CVE-2025-48828 – CVSS 9.0) prowadzą do zdalnego wykonania kodu bez uwierzytelnienia. Podatne jest oprogramowanie od wersji 5.0.0 do 5.7.5 oraz 6.0.0-6.0.3; 
• Podatności są używane „in-the-wild” – ruch z honeypotów pokazuje, że pojawiają się ataki wykorzystujące publiczny PoC; aktualizuj forum powyżej wersji 5.7.5/6.0.3 i monitoruj biuletyny bezpieczeństwa producenta

23 maja 2025 badacz bezpieczeństwa – Egidio Romano z karmainsecurity.org – zaprezentował dwie krytyczne podatności: CVE-2025-48827 (10.0 w skali CVSS) oraz CVE-2025-48828 (9.0 w skali CVSS). Luki te dotykają silnika vBulletin w wersjach 5.0.0 do 5.7.5 oraz 6.0.0 do 6.0.3. Producent wydał na te podatności stosowne łatki już jakiś czas temu. 

Pierwsza podatność pozwala na wykorzystanie mechanizmu reflection do wywołania dowolnej metody API przez nieuwierzytelnionego użytkownika. Z kolei druga luka umożliwia zdalne wykonanie kodu )ang. Remote Code Execution) dzięki nadużyciu mechanizmu szablonów (ang. templates). Połączenie tych dwóch podatności daje możliwość zdalnego wykonania kodu bez uwierzytelnienia. 

Dlaczego tak krytyczne podatności znalazły się w kodzie stosunkowo dojrzałego projektu? Wpływ na zaistniałą sytuację może mieć fakt, że zaszły zmiany zachowania PHP od wersji 8.1. Nowsze wydania pozwalają na wywoływanie metod zdefiniowanych jako private/protected poprzez refleksję automatycznie – programiści mogli zakładać, że tak jak w starszych silnikach, próba wykonania takiego działania skończy się rzuceniem wyjątku ReflectionException (chyba, że użyta była dyrektywa setAccessible(true)). Ponieważ API vBulletinu opiera się głównie na mechanizmie refleksji, oraz implementuje kontrolę dostępu na poziomie poszczególnych funkcji, a nie systemowo, to możliwe jest nadużycie braku tej kontroli w jednej z metod wywołujących funkcje API. 

Droga od tego momentu (tj. możliwości wywoływania metod API zdefiniowanych jako private/protected) do zdalnego wykonania kodu bez uwierzytelnienia jest prosta. Dzieje się to dzięki mechanizmowi obsługi szablonów, które implementują logikę potrzebną do obsługi reklam. Silnik forum pozwala na skorzystanie z instrukcji warunkowych, które z kolei umożliwiają zdalne wykonanie kodu, ponieważ szablon jest przekazywany do niebezpiecznej funkcji eval() (konkretnie wykorzystywana jest metoda vB_Template_Runtime::_evalPhp()) podczas renderowania. A ponieważ jedyną ochroną przed wywołaniem niektórych funkcji w vBulletin jest zbiór wyrażeń regularnych, to możliwy jest trywialny bypass. Autor posta wykorzystał payload <vb:if condition='"passthru"($_POST["cmd"])'></vb:if> do wykonania polecenia na serwerze. Udostępnił też pełny PoC. 

Jak podaje KEVIntel, podatności opisane przez Romano są wykorzystywane w praktyce przez cyberprzestępców, czego dowodzi wychwycony na honeypocie ruch.

W atakach wykorzystano oryginalny payload z przytoczonego wcześniej blogposta – chociaż należy wskazać, że istnieją też gotowe szablony Nuclei. 

To, co może zwrócić szczególną uwagę, to fakt, że atak został przeprowadzony z adresu 195[.]3[.]221[.]137, który należy do polskiej firmy. Czy to dowód na to, że za próbą nadużycia stoją polskie grupy sponsorowane przez państwo lub cyberprzestępcy? Atrybucja w świecie cyberbezpieczeństwa jest zadaniem niezwykle trudnym, a nasza sześcienna kostka atrybucji się gdzieś zagubiła (nie ma też Polski na jednej ze ścianek), co nie ułatwia nam odpowiedzi na to pytanie. Patrząc jednak chłodno na specyfikę działania zaawansowanych adwersarzy oraz fakt, że IP należy do firmy oferującej usługi hostingowe, kierujemy się raczej ku prostszemu wytłumaczeniu – atakujący wykorzystuje przejęty serwer VPS (lub podobną usługę) jako proxy do przeprowadzania swoich działań, w celu poprawienia OPSECu. Nie przypuszczamy też, żeby badacze bezpieczeństwa spod znaku białego kapelusza byli na tyle nieroztropni (i dali się złapać w prosty honeypot). 

Jeśli administrujesz forum opartym na silniku vBulletin to upewnij się, że obecnie zainstalowana jest odpowiednia, poprawiona wersja – dla 5.7.5 jest to Patch Level 3 a dla 6.0.3 Patch Level 1. Chociaż autor znaleziska nie potwierdził bezpośrednio, że te wydania są załatane, to informacje opublikowane przez producenta, wskazują, że problem został rozwiązany. Pamiętaj, aby monitorować biuletyny informacyjne wydawcy oprogramowania i przeprowadzać regularne aktualizacje. Wykorzystanie dodatkowej warstwy ochrony w postaci WAFa i wyłączenie zbędnych funkcjonalności nie zaszkodzi. 

~Black Hat Logan