Aktywne ataki na Qinglong: luki RCE wykorzystywane do instalacji koparek kryptowalut

Wprowadzenie do problemu / definicja

Qinglong to samodzielnie hostowana, open source’owa platforma do harmonogramowania zadań, wykorzystywana głównie w środowiskach deweloperskich i administracyjnych. W ostatnim czasie narzędzie znalazło się w centrum incydentu bezpieczeństwa po ujawnieniu dwóch podatności, które po połączeniu umożliwiają obejście uwierzytelniania oraz zdalne wykonanie kodu.

Atakujący wykorzystują te błędy do przejmowania paneli administracyjnych dostępnych z internetu, a następnie do wdrażania koparek kryptowalut na przejętych serwerach. To pokazuje, że nawet niszowe narzędzia operacyjne mogą stać się celem zautomatyzowanych kampanii, jeśli są wystawione publicznie i nieaktualizowane.

W skrócie

• Qinglong w wersjach 2.20.1 i starszych jest podatny na łańcuch ataku prowadzący do nieautoryzowanego dostępu i RCE.
• Problem wynika z błędów logicznych w obsłudze tras, mechanizmach rewrite oraz niespójności między middleware a routerem Express.js.
• Aktywne wykorzystanie luk zaobserwowano już na początku lutego 2026 roku.
• Głównym celem kampanii jest instalacja ukrytych procesów cryptominingu, intensywnie obciążających CPU ofiar.
• Skutki mogą wykraczać poza kopanie kryptowalut i obejmować pełną kompromitację hosta.

Kontekst / historia

Qinglong zdobył popularność jako lekkie narzędzie do automatyzacji zadań, dlatego publicznie dostępne instancje stały się atrakcyjnym celem dla napastników. Według dostępnych analiz exploity były używane operacyjnie od 7 lutego 2026 roku, zanim temat zyskał szeroki rozgłos.

Pierwsze sygnały o incydentach pochodziły od użytkowników, którzy zauważyli nietypowy proces o nazwie „.fullgc”, zużywający od 85% do 100% zasobów CPU. Nazwa procesu została dobrana tak, aby przypominała legalny komponent związany z mechanizmami garbage collection, co mogło opóźniać wykrycie i reakcję.

Dodatkowym problemem okazało się to, że początkowe działania naprawcze nie eliminowały całego wektora ataku. Dopiero późniejsze poprawki usunęły pełną przyczynę obejścia uwierzytelniania, która umożliwiała skuteczne przejęcie paneli administracyjnych.

Analiza techniczna

Incydent dotyczy dwóch podatności, które można połączyć w skuteczny łańcuch prowadzący do zdalnego wykonania kodu. Pierwszy problem wynika z błędnie skonfigurowanej reguły przepisywania ścieżek, mapującej żądania w formacie /open/* do przestrzeni /api/*. W efekcie część operacji administracyjnych mogła być osiągalna przez ścieżkę nieuwzględnioną prawidłowo w warstwie ochronnej.

Druga luka opiera się na niespójności pomiędzy walidacją ścieżki w logice uwierzytelniania a sposobem działania routera Express.js. Middleware traktował ścieżki jako rozróżniające wielkość liter, podczas gdy routing akceptował warianty nieczułe na case. To otwierało drogę do używania zmodyfikowanych wariantów ścieżek /api/, które omijały kontrolę dostępu, ale nadal trafiały do chronionych funkcji aplikacji.

W jednym z opisanych scenariuszy możliwe było wywołanie endpointu inicjalizacyjnego przez ścieżkę /open/user/init, co pozwalało na reset poświadczeń administratora nawet w już skonfigurowanym środowisku. Po uzyskaniu dostępu napastnicy modyfikowali plik config.sh, wstrzykując polecenia służące do pobrania i uruchomienia binariów cryptominera.

Złośliwy komponent był zapisywany w katalogu danych Qinglong pod nazwą .fullgc i uruchamiany w tle. Zaobserwowano warianty przygotowane dla architektur Linux x86_64, ARM64 oraz dla systemów macOS, co sugeruje próbę objęcia kampanią możliwie szerokiego spektrum środowisk.

Technicznie jest to przykład groźnej wady projektowej, a nie klasycznego błędu pamięci czy pojedynczego injection. Niespójności pomiędzy middleware, routerem i regułami rewrite są szczególnie niebezpieczne, ponieważ łatwo przechodzą przez testy funkcjonalne, a jednocześnie mogą prowadzić do pełnego przejęcia aplikacji.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem kompromitacji jest przejęcie panelu Qinglong i uzyskanie możliwości wykonywania poleceń na serwerze. W analizowanej kampanii dominującym celem była monetyzacja przez cryptomining, jednak ten sam wektor może zostać użyty również do wdrażania backdoorów, loaderów malware, narzędzi do ruchu bocznego oraz mechanizmów trwałości.

Dla organizacji ryzyko ma kilka wymiarów. Po pierwsze, intensywne wykorzystanie CPU może obniżać wydajność usług produkcyjnych. Po drugie, kompromitacja systemu automatyzacji może prowadzić do ujawnienia sekretów, tokenów, skryptów operacyjnych i harmonogramów zadań. Po trzecie, jeśli Qinglong działa na serwerze z dodatkowymi uprawnieniami lub połączeniami do innych systemów, incydent może stać się punktem wyjścia do dalszej eskalacji w infrastrukturze.

Szczególnie narażone są instancje wystawione bezpośrednio do internetu, działające za reverse proxy i traktowane jako pomocnicze narzędzia administracyjne. Kampania pokazuje, że również specjalistyczne aplikacje deweloperskie są aktywnie skanowane i wykorzystywane bardzo szybko po odkryciu podatności, a czasem nawet przed ich szerokim publicznym opisaniem.

Rekomendacje

Administratorzy powinni w pierwszej kolejności zidentyfikować wszystkie instancje Qinglong i sprawdzić, czy nie działają w podatnych wersjach. Kluczowe jest wdrożenie pełnych poprawek usuwających obejście uwierzytelniania, a nie jedynie częściowych działań ograniczających objawy problemu.

• Odciąć publiczny dostęp do paneli Qinglong, jeśli nie jest absolutnie konieczny.
• Ograniczyć dostęp przez VPN, listy kontroli dostępu lub segmentację sieci.
• Przeanalizować logi HTTP pod kątem żądań do ścieżek /open/*, nietypowych wariantów wielkości liter w /api/* oraz prób inicjalizacji użytkownika.
• Sprawdzić integralność plików konfiguracyjnych, zwłaszcza config.sh.
• Wyszukać procesy takie jak .fullgc oraz inne nietypowe binaria uruchamiane z katalogów danych aplikacji.
• Przeanalizować anomalia wydajnościowe i nietypowo wysokie użycie CPU na hostach z Qinglong.
• Przeprowadzić rotację poświadczeń administratorów, tokenów i sekretów po każdej podejrzanej aktywności.
• Wdrożyć monitoring EDR lub reguły detekcyjne dla nieautoryzowanych zmian w zadaniach, plikach startowych i konfiguracji.

W środowiskach produkcyjnych warto dodatkowo przeprowadzić hunting pod kątem poleceń pobierających pliki wykonywalne z zewnętrznych źródeł, nowych mechanizmów persistence oraz zmian w harmonogramie zadań. Jeśli kompromitacja została potwierdzona, system należy traktować jako w pełni przejęty i objąć go pełną analizą powłamaniową.

Podsumowanie

Przypadek Qinglong pokazuje, że pozornie niewielkie błędy w logice routingu i autoryzacji mogą prowadzić do pełnego zdalnego wykonania kodu. W tym incydencie napastnicy skutecznie połączyli dwa mechanizmy obejścia zabezpieczeń, aby przejmować panele administracyjne i instalować koparki kryptowalut.

Z perspektywy obrony najważniejsze są szybka aktualizacja, ograniczenie ekspozycji usługi do internetu, kontrola integralności systemu oraz aktywne poszukiwanie oznak kompromitacji. To kolejny sygnał dla zespołów bezpieczeństwa, że narzędzia deweloperskie i automatyzacyjne muszą być chronione z taką samą starannością jak systemy krytyczne.

Źródła

1. BleepingComputer — https://www.bleepingcomputer.com/news/security/hackers-exploit-rce-flaws-in-qinglong-task-scheduler-for-cryptomining/
2. GitHub Pull Request #2941: Fix /open/user/init auth bypass allowing credential reset on initialized systems — https://github.com/whyour/qinglong/pull/2941