634 hasła w 56 sekund

Programista — świadomy kwestii bezpieczeństwa, doświadczony, ktoś, kto aktywnie szuka oszustw — przeszedł wieloetapowy proces rekrutacyjny w fikcyjnej firmie. Rozmowa z HR. Rozmowa techniczna z dwoma inżynierami. Prawdziwa witryna ze zdjęciami zespołu. Prawdziwe profile na LinkedIn. Tygodnie budowania relacji.

Następnie poproszono go o wykonanie niewielkiego zadania programistycznego podczas udostępniania ekranu.

56 sekund później napastnicy mieli 634 zapisane hasła z Chrome, plik pęku kluczy macOS (Keychain), który zawiera klucz umożliwiający ich odszyfrowanie, oraz dane portfela MetaMask.

Jak przebiegł atak

Repozytorium na GitHubie wyglądało na czyste. Kilka plików backendowych, nic podejrzanego. Ale jedna zależność — winston-middleware, pakiet do logowania o zwyczajnie brzmiącej nazwie — miała własną zależność: next-runtimejs.

Tam znajdowała się broń.

W chwili uruchomienia npm install bezszelestnie wykonał się skrypt powłoki. Bez monitów, bez ostrzeżeń. Pobrał backdoora napisanego w Go i zarejestrował go do automatycznego uruchamiania przy każdym starcie systemu.

To nie było narzędzie amatora. Niestandardowy protokół C2 szyfrowany RC4. Polecenia do wykonywania poleceń powłoki, kradzieży plików, wyodrębniania haseł z Chrome, eksfiltracji pęku kluczy oraz atakowania portfeli kryptowalutowych. Zbudowane profesjonalnie.

Backdoor wystartował o 16:16:37. Hasła z Chrome zostały odczytane o 16:17:33. Programista zauważył okno systemu macOS informujące o wychodzącym połączeniu i w ciągu minuty wyłączył WiFi — ale szkody były już wyrządzone.

Dlaczego rozmowa kwalifikacyjna miała znaczenie

Ten atak nie powiódłby się w formie zimnego e-maila. „Uruchom to repozytorium" od nieznajomego zostaje zignorowane.

Ale po dwóch rundach rozmów? Po wspólnym śmiechu z tego, ile fikcyjnych ofert pracy celuje w programistów? Po tym, jak jeden z rozmówców powiedział z uśmiechem: „Śmiało, proszę szukać backdoorów"?

Wtedy opada czujność. Zaufanie jest podatnością wykorzystywaną w ataku. Złośliwe oprogramowanie to jedynie ładunek.

Programista ujął to najlepiej: „Jeśli przydarzyło się mnie, może przydarzyć się każdemu w Pana/Pani zespole."

Co naprawdę oznaczają hasła zapisane w Chrome

Chrome szyfruje zapisane hasła przy użyciu AES. Klucz deszyfrujący jest przechowywany w pęku kluczy macOS (Keychain). Napastnicy skradli oba pliki w niecałą minutę.

Każde zapisane hasło — do banku, poczty, GitHuba, konsol chmurowych — było po ich stronie czytelne. Plik pęku kluczy można złamać offline, bez limitów liczby prób. Programista musiał wymienić wszystkie hasła.

To brudny sekret haseł zapisanych w przeglądarce: są szyfrowane kluczem, który znajduje się na tej samej maszynie. Wystarczy przejąć maszynę, a „szyfrowanie" zamienia się w dekorację.

Wzorzec działań KRLD

Programista wspomniał, że jego poprzednia firma również została zhakowana przez Koreę Północną trzy miesiące wcześniej. To kampania „Contagious Interview" — wspierani przez państwo KRLD napastnicy przeprowadzający fikcyjne rozmowy kwalifikacyjne, aby zainstalować złośliwe oprogramowanie na maszynach programistów.

Nie jest to przypadkowe. Celują w programistów właśnie ze względu na to, do czego programiści mają dostęp: dane uwierzytelniające do środowiska produkcyjnego, klucze podpisujące, infrastrukturę chmurową oraz — coraz częściej — tokeny agentów AI, które dają dostęp do jeszcze większej liczby zasobów.

Skala jest przemysłowa. Fikcyjne firmy z wygenerowanymi twarzami. Dopracowane witryny. Wielotygodniowe procesy rekrutacyjne. Inwestują, bo zwrot z inwestycji jest realny.

„Menedżery haseł nie pomagają"

Programista sformułował w wątku interesującą tezę: „Menedżery haseł nie pomagają, jeśli napastnicy mają dostęp do Pana/Pani komputera przez backdoor tego rodzaju, ponieważ później mogą przesłać dowolny plik, przygotować exploit przygotowany specjalnie pod Pana/Pani, użyć keyloggerów, zrzutów ekranu."

To twierdzenie jest częściowo słuszne, a częściowo błędne.

Menedżer haseł, który przechowuje swój sejf na lokalnym dysku i jest odblokowywany hasłem głównym wpisywanym przez Pana/Panią — tak, backdoor z keyloggerem i dostępem do plików może go przejąć.

Ale menedżer haseł z kluczami powiązanymi ze sprzętem — w którym klucz deszyfrujący jest wyprowadzany z fizycznego uwierzytelniacza i nigdy nie istnieje jako plik na dysku — jest zasadniczo inny. Backdoor może kraść pliki, rejestrować naciśnięcia klawiszy, robić zrzuty ekranu. Nie jest jednak w stanie wydobyć klucza, który istnieje wyłącznie wewnątrz sprzętowego modułu bezpieczeństwa podczas fizycznego dostępu.

634 hasła z Chrome skradziono dlatego, że zarówno zaszyfrowane dane, jak i klucz deszyfrujący były plikami w systemie plików. Jeśli klucz deszyfrujący wymaga fizycznego posiadania urządzenia, kradzież plików daje w efekcie same zaszyfrowane bloki danych i nic więcej.

Co robić

• Proszę nigdy nie uruchamiać kodu z zadań rekrutacyjnych na głównej maszynie. Do tego celu należy używać maszyny wirtualnej lub osobnego urządzenia.
• Proszę uruchamiać npm install --ignore-scripts w każdym nieznanym repozytorium przed wykonaniem kodu
• Proszę używać zapory wychodzącej (Little Snitch, LuLu), która ostrzega o nowych połączeniach
• Proszę przestać zapisywać hasła w Chrome. Kropka.
• Proszę przechowywać kryptowaluty na portfelach sprzętowych, nie w rozszerzeniach przeglądarki
• Proszę traktować każde zadanie rekrutacyjne od rekrutera jako potencjalnie wrogo nastawione, niezależnie od liczby odbytych rozmów

Programista uniknął szerszych skutków dzięki temu, że okno systemu macOS wychwyciło wychodzące połączenie w porę. Większość osób kliknęłaby „Zezwól" bez chwili zastanowienia.

56 sekund. Tyle wystarczy.