Git hooks i malware w rekrutacji

TL;DR

Fałszywa rekrutacja IT nie musi polegać na zwykłym mailu z załącznikiem. Atakujący może dać kandydatowi repozytorium z zadaniem technicznym, które wygląda jak normalny etap rozmowy o pracę. Problem zaczyna się wtedy, gdy projekt zawiera złośliwe Git hooks, czyli skrypty uruchamiane automatycznie przy pracy z kodem.

W kampaniach z rodziny Contagious Interview atakujący wykorzystują naturalny workflow developera: klonowanie repozytorium, instalację zależności, otwarcie projektu, uruchomienie testów i commit. Malware nie musi wystartować po kliknięciu w plik EXE. Może uruchomić się wtedy, gdy developer wykona rutynową czynność.

Dla polskich software houseów, startupów, zespołów DevOps, freelancerów i kandydatów do pracy to realny scenariusz. Stacja developerska często ma klucze SSH, tokeny, konfiguracje chmury, pliki .env i dostęp do repozytoriów. Atak na kandydata może więc stać się incydentem obecnego pracodawcy albo problemem supply chain.

Fałszywa oferta pracy jako punkt wejścia

Kampanie Contagious Interview wykorzystują kontekst rekrutacji. Atakujący kontaktują się z developerem, często przez kanał zawodowy, i proponują zadanie techniczne. Repozytorium wygląda jak projekt do oceny umiejętności. Kandydat ma pobrać kod, uruchomić aplikację, naprawić błąd albo odesłać commit.

To działa, bo developerzy regularnie pracują z obcym kodem. Klonują repozytoria, instalują pakiety, uruchamiają testy i sprawdzają build. Zadanie rekrutacyjne nie budzi takiej samej czujności jak podejrzany dokument w poczcie.

W tym sensie to nadal phishing, ale przeniesiony z wiadomości na workflow zawodowy. Przynętą nie jest fałszywy formularz logowania. Przynętą jest zadanie, które wygląda jak normalna praca.

Git hooks są legalne, ale automatyczne

Git hooks mają sens w legalnym projekcie. Mogą uruchamiać formatowanie, testy, kontrolę jakości, blokować sekrety albo wymuszać standard commitów. Ich siła polega na automatyzacji. W złośliwym repozytorium ta sama automatyzacja staje się mechanizmem uruchomienia malware.

Pre-commit hook działa tuż przed zapisaniem commita. Jeśli atakujący przygotuje złośliwy hook, skrypt może uruchomić loader, rozpoznanie systemu, pobranie kolejnego payloadu albo kradzież danych dokładnie w chwili, która dla developera wygląda rutynowo.

W opisywanym wariancie malware jest cross-platform, czyli dostosowuje działanie do systemu operacyjnego. To ważne, bo developerzy często pracują na macOS, Linuxie, Windowsie, WSL, lokalnych kontenerach i własnych konfiguracjach narzędzi. Standardowe zasady dla użytkownika biurowego nie wystarczą.

Dlaczego to problem firmowy

Na pierwszy rzut oka ofiarą jest osoba szukająca pracy. W praktyce ryzyko może dotyczyć także jej obecnego pracodawcy. Laptop developera często zawiera prywatne klucze SSH, tokeny GitHub lub GitLab, dostęp do chmury, konfiguracje CI/CD, pliki .env, konta npm, PyPI, Docker Hub, repozytoria klientów i narzędzia wewnętrzne.

CI/CD oznacza continuous integration i continuous delivery albo deployment, czyli automatyczne budowanie, testowanie i wdrażanie kodu. To jeden z najcenniejszych obszarów dla atakującego, bo dostęp do pipeline może oznaczać możliwość kradzieży sekretów, modyfikacji kodu albo wejścia głębiej w środowisko firmy.

Supply chain w bezpieczeństwie oznacza łańcuch dostaw oprogramowania, narzędzi, bibliotek, zależności i procesów, które prowadzą od kodu do gotowego produktu. Jeśli atak zaczyna się na stacji developera, może później przenieść się na repozytorium, pipeline albo produkt klienta.

Samo skanowanie linku nie wystarczy

W klasycznym phishingu pytamy często, czy link jest podejrzany. W tym scenariuszu to za mało. Link może prowadzić do legalnej platformy, projekt może wyglądać wiarygodnie, a kod może działać. Problem może siedzieć w miejscu, którego kandydat nie sprawdza: hookach, konfiguracji IDE, skryptach instalacyjnych, zależnościach albo zadaniach automatycznych.

IDE, czyli integrated development environment, to środowisko programistyczne, na przykład Visual Studio Code, IntelliJ IDEA albo WebStorm. Takie narzędzia mogą podpowiadać instalację zależności, uruchamiać konfiguracje projektu i wykonywać zadania automatyczne. To wygodne, ale przy obcym repozytorium wymaga ostrożności.

Developerzy potrzebują więc innej edukacji niż użytkownicy biurowi. Nie wystarczy mówić, żeby nie klikać w podejrzane linki. Trzeba uczyć, gdzie w projekcie może ukrywać się automatyczne wykonanie kodu.

Co zrobić, jeśli to już się stało

Jeżeli developer sklonował repozytorium, ale nie uruchomił projektu, nie zainstalował zależności i nie wykonał commita, warto przerwać pracę i przejrzeć projekt w izolowanym środowisku. Szczególnie trzeba sprawdzić .git/hooks, .githooks, .vscode, package.json, skrypty instalacyjne, pliki CI/CD, zależności i polecenia startowe.

Jeżeli projekt został uruchomiony albo wykonano commit, urządzenie trzeba potraktować jako potencjalnie naruszone. Należy sprawdzić procesy, połączenia sieciowe, nowe pliki, zadania autostartu, klucze SSH, tokeny, menedżery haseł, historię terminala, konfigurację Git i konta developerskie.

Jeżeli na urządzeniu były firmowe sekrety, trzeba założyć, że mogły zostać ujawnione. Priorytetem jest rotacja tokenów, kluczy SSH, kluczy API, haseł do rejestrów pakietów, poświadczeń chmurowych i dostępów do repozytoriów. Trzeba też sprawdzić, czy nie doszło do zmian w repozytoriach, pipeline, ustawieniach organizacji albo publikowanych pakietach.

Jeżeli kandydat pracuje na sprzęcie firmowym, incydent powinien trafić do IT lub SOC. Nie należy go traktować jako prywatnej sytuacji rekrutacyjnej, jeśli urządzenie miało dostęp do zasobów firmy.

Bezpieczny workflow dla obcych repozytoriów

Obce repozytorium z procesu rekrutacyjnego powinno być uruchamiane w środowisku, które można utracić bez większych skutków. Najlepsza praktyka to maszyna wirtualna, kontener lub osobne konto użytkownika bez zapisanych sekretów, prywatnych kluczy, tokenów, menedżera haseł i dostępu do firmowych repozytoriów.

Przed uruchomieniem warto sprawdzić katalogi z hookami, konfigurację IDE, skrypty package managera, pliki instalacyjne, pliki CI/CD i zależności. Należy uważać na polecenia postinstall, preinstall, prepare, pre-commit, taski automatyczne, skrypty powłoki i instrukcje proszące o wyłączenie zabezpieczeń.

Firmy powinny też określić zasady dla pracowników biorących udział w zewnętrznych rekrutacjach, projektach open source i testach technicznych. To delikatny temat, ale z perspektywy bezpieczeństwa ważne jest jedno: firmowy sprzęt i firmowe sekrety nie powinny być środowiskiem testowym dla niezweryfikowanego kodu.

Jak ćwiczyć ten scenariusz w awareness

Ten scenariusz dobrze nadaje się do awareness dla developerów, DevOps i zespołów bezpieczeństwa aplikacji. W testach phishingowych dla firm można bezpiecznie zasymulować zadanie rekrutacyjne, które nie uruchamia malware, ale sprawdza, czy użytkownik zauważy nietypowe hooki, skrypty instalacyjne i prośby o wykonanie ryzykownych poleceń.

Warto mierzyć nie tylko kliknięcie w link do repozytorium. Ważniejsze jest, czy developer sprawdził projekt przed uruchomieniem, czy użył izolowanego środowiska, czy nie miał w nim sekretów, czy zgłosił podejrzane elementy i czy organizacja umiała właściwie zareagować.

Dla zespołów IT i SOC to także test widoczności. Czy organizacja wykrywa nietypowe uruchomienia skryptów, exfiltrację kluczy, nowe połączenia z nieznanymi hostami, zmiany w repozytoriach i użycie tokenów z nietypowych lokalizacji.

Wniosek

Git hooks pokazują, że phishing developerski nie musi wyglądać jak phishing. Może wyglądać jak zadanie techniczne, commit, test albo konfiguracja projektu. Atakujący nie łamie workflow developera. Wykorzystuje go.

Praktyczna zasada jest konkretna: obce repozytorium nie powinno być uruchamiane na głównej stacji roboczej z sekretami. Najpierw izolacja, potem przegląd hooków, skryptów i konfiguracji, dopiero później praca z kodem. W świecie supply chain bezpieczeństwo zaczyna się jeszcze przed pierwszym commitem.