Wcześniej nieudokumentowany implant dla systemu Linux, znany jako Quasar Linux RAT, czyli QLNX, został zaobserwowany w atakach na środowiska programistyczne i DevOps. Złośliwe oprogramowanie ma zapewniać cichy przyczółek w systemach Linux i dawać atakującym szerokie możliwości po przejęciu systemu, w tym kradzież poświadczeń, rejestrowanie naciśnięć klawiszy, manipulowanie plikami, monitorowanie schowka, tunelowanie ruchu sieciowego i długotrwałe ukrywanie się.
Według badaczy Trend Micro, Aliakbara Zahraviego i Ahmeda Mohameda Ibrahima, QLNX jest szczególnie niebezpieczny, ponieważ koncentruje się na łańcuchu dostaw oprogramowania. Zamiast atakować wyłącznie standardowe konta użytkowników, celuje w poświadczenia, których programiści używają do publikowania kodu, uzyskiwania dostępu do platform chmurowych, zarządzania kontenerami i obsługi środowisk CI/CD.
Dlaczego programiści są głównym celem
Maszyny programistów często zawierają bardzo cenne sekrety. Systemy te mogą mieć dostęp do repozytoriów kodu źródłowego, środowisk chmurowych, rejestrów pakietów, klastrów Kubernetes, rejestrów Docker, narzędzi infrastruktury jako kodu oraz wewnętrznych potoków wdrożeniowych.
QLNX został zbudowany tak, aby wyszukiwać i wydobywać sekrety z plików powszechnie spotykanych w środowiskach programistycznych, w tym:
.npmrcdla tokenów npm.pypircdla poświadczeń PyPI.git-credentials.aws/credentials.kube/config.docker/config.json.vault-token- poświadczeń Terraform
- tokenów GitHub CLI
- plików
.env
Jeśli atakujący zdobędą dostęp do tych poświadczeń, mogą być w stanie publikować złośliwe pakiety, przejmować infrastrukturę chmurową, modyfikować kod aplikacji lub przedostawać się głębiej do potoków CI/CD.
Sprawia to, że QLNX to coś więcej niż zwykły trojan zdalnego dostępu dla Linuksa. To bezpośrednie zagrożenie dla łańcucha dostaw oprogramowania.
Ryzyko dla łańcucha dostaw: jeden przejęty programista może wpłynąć na wielu
Największy problem to skutki dla kolejnych ogniw łańcucha.
Jeśli konto opiekuna pakietu, inżyniera DevOps lub programisty zostanie przejęte, atakujący mogą potencjalnie wypchnąć zatrutą wersję legalnego pakietu oprogramowania do npm, PyPI lub innych rejestrów. Takie złośliwe aktualizacje mogą następnie być automatycznie pobierane przez innych programistów, systemy budowania i środowiska produkcyjne.
Tego typu atak może rozprzestrzeniać się szybko, ponieważ wiele organizacji ufa zależnościom, opiekunom pakietów i zautomatyzowanym procesom wdrożeniowym.
Pojedyncza przejęta stacja robocza może więc stać się punktem wyjścia znacznie większego incydentu w łańcuchu dostaw.
Jak QLNX pozostaje ukryty
QLNX został zaprojektowany z myślą o długotrwałym ukrywaniu się. Uruchamia się bezplikowo z pamięci i może maskować się jako wyglądający na legalny wątek jądra Linuksa, używając nazw takich jak kworker lub ksoftirqd.
Malware profiluje też hosta, aby wykryć, czy działa w środowisku kontenerowym. Pomaga mu to dostosować zachowanie i uniknąć wykrycia.
Aby utrzymać trwałość, QLNX stosuje wiele redundantnych metod, w tym:
- usługi systemd
- wpisy crontab
- wstrzykiwanie do powłoki przez
.bashrc - dodatkowe mechanizmy trwałości zaprojektowane tak, aby przetrwać ponowne uruchomienia i próby czyszczenia
Potrafi także wymazywać logi systemowe, aby ukryć ślady włamania.
Możliwości rootkita: ukrywanie się w przestrzeni użytkownika i jądra
Jednym z najbardziej niepokojących elementów QLNX jest dwupoziomowa architektura rootkita.
Po pierwsze, wykorzystuje rootkit w przestrzeni użytkownika, oparty na mechanizmie LD_PRELOAD dynamicznego konsolidatora Linuksa. Pozwala to malware’owi ukrywać pliki, procesy i inne artefakty przed typowymi narzędziami działającymi w przestrzeni użytkownika.
Po drugie, zawiera komponent eBPF na poziomie jądra. Dzięki nadużywaniu podsystemu BPF w Linuksie QLNX może ukrywać procesy, pliki i porty sieciowe przed standardowymi narzędziami, takimi jak:
pslsnetstat
To połączenie znacznie utrudnia wykrycie, zwłaszcza jeśli obrońcy polegają wyłącznie na tradycyjnych narzędziach do inspekcji z wiersza poleceń.
Kradzież poświadczeń przez backdoory PAM
QLNX zawiera również funkcję backdoora Pluggable Authentication Module, czyli PAM.
Pozwala mu to przechwytywać poświadczenia w postaci jawnego tekstu podczas zdarzeń uwierzytelniania. Może także rejestrować dane wychodzących sesji SSH i przesyłać skradzione informacje do infrastruktury kontrolowanej przez atakującego.
Malware obsługuje drugi, oparty na PAM mechanizm rejestrowania poświadczeń, który może być automatycznie ładowany do dynamicznie linkowanych procesów. Pozwala to wydobywać nazwy usług, nazwy użytkowników i tokeny uwierzytelniające.
Dla organizacji korzystających z serwerów Linux, hostów pośredniczących (jump boxów) DevOps lub stacji roboczych programistów jest to poważne ryzyko, ponieważ sama aktywność uwierzytelniania staje się źródłem kradzieży poświadczeń.
Funkcje dowodzenia i kontroli oraz zdalnego sterowania
Gdy QLNX zdobędzie przyczółek, wchodzi w trwałą pętlę operacyjną. Nieustannie próbuje komunikować się z serwerami dowodzenia i kontroli kontrolowanymi przez atakującego, używając surowego TCP, HTTPS i HTTP.
Malware podobno obsługuje 58 odrębnych poleceń, dając operatorom szeroką kontrolę nad przejętym hostem.
Jego możliwości obejmują:
- wykonywanie poleceń powłoki
- zarządzanie plikami
- wstrzykiwanie kodu do procesów
- wykonywanie zrzutów ekranu
- rejestrowanie naciśnięć klawiszy
- monitorowanie aktywności schowka
- tworzenie proxy SOCKS
- tworzenie tuneli TCP
- uruchamianie Beacon Object Files
- zarządzanie siecią mesh typu peer-to-peer
Daje to atakującym zarówno możliwości szpiegowskie, jak i ruchu bocznego.
Dlaczego QLNX jest szczególnie niebezpieczny
QLNX jest niebezpieczny nie z powodu jednej cechy, lecz dlatego, że wszystkie jego możliwości działają razem.
Może pojawić się po cichu, usunąć ślady z dysku, ustanowić wiele metod trwałości, ukrywać się zarówno na poziomie przestrzeni użytkownika, jak i jądra, kraść cenne poświadczenia, a następnie wykorzystać je do przemieszczania się głębiej w środowiska programistyczne i chmurowe.
Dla zespołów DevOps i inżynierii oprogramowania oznacza to ryzyko o dużym wpływie: przejęcie jednej stacji roboczej z Linuksem może prowadzić do szerszego przejęcia repozytoriów kodu, platform chmurowych, rejestrów kontenerów i potoków produkcyjnych.
Zalecenia dotyczące ochrony
Organizacje powinny traktować maszyny programistów i systemy CI/CD jako zasoby o wysokiej wartości, a nie jako standardowe punkty końcowe.
Zalecane działania obejmują:
- natychmiastową rotację ujawnionych poświadczeń programistów i DevOps po podejrzeniu włamania
- monitorowanie dostępu do kont npm, PyPI, GitHub, Docker, Kubernetes, Vault, AWS, Azure i GCP
- unikanie przechowywania długotrwałych sekretów w lokalnych plikach konfiguracyjnych
- stosowanie krótkotrwałych tokenów i, tam gdzie to możliwe, dostępu opartego na tożsamości
- wymuszanie MFA dla systemów kontroli wersji, platform chmurowych i rejestrów pakietów
- monitorowanie podejrzanych zmian w
.bashrc, crontab, usługach systemd, modułach PAM iLD_PRELOAD - stosowanie EDR lub narzędzi bezpieczeństwa działających w czasie wykonywania, zdolnych wykrywać malware rezydujące w pamięci i nadużycia eBPF
- regularny audyt uprawnień potoków CI/CD
- rozdzielenie dostępu programistów, administratorów i produkcji
- przeglądanie aktywności publikowania pakietów pod kątem nieoczekiwanych wydań
Zespoły bezpieczeństwa powinny też weryfikować wykrycia przy użyciu zaufanych narzędzi śledczych, a nie tylko standardowych narzędzi Linuksa, ponieważ funkcje rootkita mogą ukrywać złośliwą aktywność przed zwykłymi poleceniami.
Podsumowanie
QLNX uwidacznia rosnący trend we współczesnych cyberatakach: programiści i inżynierowie DevOps stają się głównymi celami.
Ponieważ organizacje coraz mocniej polegają na platformach chmurowych, pakietach open source, kontenerach i zautomatyzowanych potokach wdrożeniowych, poświadczenia programistów stały się niezwykle cenne. Malware takie jak QLNX zostało stworzone właśnie po to, by wykorzystać tę rzeczywistość.
Ochrona łańcucha dostaw oprogramowania wymaga dziś czegoś więcej niż zabezpieczenia serwerów produkcyjnych. Wymaga silnych mechanizmów bezpieczeństwa na stacjach roboczych programistów, w systemach CI/CD, w procesach publikowania pakietów i na ścieżkach dostępu do chmury.
