Nie powinno być nic do zebrania

Wczoraj zmodyfikowana wersja CLI Bitwarden wykradła klucze SSH, dane dostępowe AWS, tokeny npm, zmienne środowiskowe, historię poleceń powłoki oraz sekrety Git z 334 komputerów deweloperów.

Dziś był to Bitwarden. W zeszłym miesiącu Axios. Wcześniej Checkmarx. Jutro będzie to rozszerzenie VS Code, albo Acrobat, albo formuła Homebrew, albo obraz Docker. Wektor zmienia się co tydzień. Wynik zawsze jest ten sam.

Złośliwe oprogramowanie trafia na maszynę. Czyta ~/.ssh/. Czyta ~/.aws/credentials. Czyta ~/.npmrc. Czyta ~/.git-credentials. Czyta historię powłoki, zmienne środowiskowe, magazyny haseł przeglądarki. Pakuje wszystko i wysyła do serwera C2.

I to działa. Za każdym razem.

Żniwa

Ładunek Bitwarden — 10-megabajtowy, zaciemniony plik o nazwie bw1.js — nie próbował łamać żadnego szyfrowania. Nie musiał. Oto co zebrał, według dokumentacji Socket i Aikido:

• Klucze SSH i odciski palców hostów
• Dane dostępowe do chmur AWS, GCP i Azure
• Tokeny uwierzytelniające npm
• Dane dostępowe Git i adresy URL repozytoriów
• Zmienne środowiskowe
• Historia poleceń powłoki
• Uwierzytelnianie Claude Code i konfiguracje MCP

Następnie wykorzystał skradzione tokeny npm, aby ponownie opublikować inne pakiety utrzymywane przez ofiarę, rozprzestrzeniając się dalej. Ofiary stały się wektorami.

Nic z tego nie wymagało łamania szyfrowania. Każdy z tych sekretów był plikiem w systemie plików, czytelnym dla dowolnego procesu uruchomionego z uprawnieniami użytkownika.

To nie jest historia o Bitwardenie

Szyfrowanie sejfu Bitwarden nie zostało naruszone. Ich architektura zero-knowledge wytrzymała. Złośliwe oprogramowanie nigdy nie dotknęło sejfu.

Nie musiało.

Sejf chroni to, co jest w środku. Ale klucze SSH nigdy nie były w sejfie. Dane dostępowe AWS nigdy nie były w sejfie. Tokeny npm, dane dostępowe Git, klucze API w plikach .env — żadne z nich nie żyją w menedżerach haseł. Żyją w plikach konfiguracyjnych typu dotfile, w postaci zwykłego tekstu, na komputerze każdego dewelopera.

Atakujący to zrozumiał. Sejf to zamknięty skarbiec w domu, w którym każda szuflada jest otwarta.

Rzeczywista powierzchnia ataku

Proszę otworzyć teraz terminal i zobaczyć, co znajduje się na Państwa maszynie.

~/.ssh/id_ed25519 — Państwa klucz prywatny. Plik w postaci zwykłego tekstu.

~/.aws/credentials — Państwa dostęp do chmury. Plik w postaci zwykłego tekstu.

~/.npmrc — Państwa token publikacyjny. Plik w postaci zwykłego tekstu.

~/.git-credentials — Państwa dostęp do repozytoriów. Plik w postaci zwykłego tekstu.

~/.env w kilkunastu katalogach projektów — klucze API, hasła do baz danych, sekrety podpisujące. Wszystko pliki w postaci zwykłego tekstu.

Każdy proces uruchomiony z uprawnieniami użytkownika może to wszystko odczytać. Bez eskalacji uprawnień. Bez exploita. Wystarczy cat.

To jest domyślna konfiguracja deweloperska w 2026 roku. Umieszczamy nasze hasła w zaszyfrowanym sejfie, a wszystko inne zostawiamy na widoku.

Złe pytanie

Po każdym ataku na łańcuch dostaw branża zadaje to samo pytanie: jak zapobiec przedostaniu się złośliwego oprogramowania?

Lepsze zabezpieczenia CI/CD. Podpisywanie kodu. Skanowanie zależności. Odizolowane środowiska uruchomieniowe. To wszystko jest dobre. Nic z tego nie jest wystarczające. Powierzchnia ataku jest zbyt szeroka. Jest zbyt wiele wektorów — menedżery pakietów, rozszerzenia przeglądarki, wtyczki IDE, aplikacje OAuth, przejęte narzędzia budowania. Nie da się uszczelnić każdego punktu wejścia.

Prawidłowe pytanie brzmi: gdy złośliwe oprogramowanie nieuchronnie uzyska wykonanie na komputerze dewelopera, co znajduje?

Jeśli odpowiedź to „setki sekretów w postaci zwykłego tekstu w przewidywalnych lokalizacjach w systemie plików”, żadne wzmacnianie łańcucha dostaw nie ma znaczenia. Grają Państwo w obronie na boisku, za którym bramka stoi otworem.

Nie powinno być nic do zebrania

Rozwiązaniem nie jest lepsze wykrywanie złośliwego oprogramowania. Rozwiązaniem nie jest izolowanie npm install. Rozwiązaniem nie jest szybszy czas reakcji na incydent.

Rozwiązaniem jest: sekrety nie powinny istnieć jako pliki na dysku.

Klucze SSH wyprowadzane ze sprzętu w momencie uwierzytelnienia — nie przechowywane w ~/.ssh/. Dane dostępowe do chmury wydawane na sesję z tożsamości związanej ze sprzętem — nie zapisywane w ~/.aws/. Tokeny API o ograniczonym zakresie, efemeryczne i warunkowane sprzętem — nie leżące w plikach .env.

Gdy dane dostępowe istnieją wyłącznie w module sprzętowym i w efemerycznej pamięci procesu podczas użycia, złośliwe oprogramowanie nie ma czego odczytać. Nie ma pliku do wykradzenia. Nie ma pliku konfiguracyjnego do zeskrapowania. Proces się uruchamia, nie znajduje niczego, idzie dalej.

To nie jest teoria. Dane dostępowe związane ze sprzętem istnieją już dziś. WebAuthn PRF potrafi wyprowadzać klucze kryptograficzne z fizycznego dotknięcia tokena uwierzytelniającego — kluczy, które nigdy nie trafiają do systemu plików. Technologia jest gotowa. Branża po prostu nie przyjęła jej jako domyślnej.

Co zrobić teraz

Jeśli Państwa środowisko zostało dotknięte przejęciem CLI Bitwarden:

• Proszę wymienić wszystkie dane dostępowe na maszynie — klucze SSH, tokeny chmury, tokeny npm, klucze API, wszystko w plikach dotfile i zmiennych środowiskowych
• Proszę sprawdzić, czy któreś z utrzymywanych przez Państwa pakietów npm nie zostało opublikowanych ponownie
• Proszę przejrzeć aktywność GitHub i przepływy CI/CD pod kątem nieautoryzowanych zmian

Jeśli Państwo nie zostali dotknięci, działanie pozostaje takie samo. Proszę spojrzeć na swoją maszynę. Proszę policzyć sekrety w postaci zwykłego tekstu. Proszę zapytać siebie, co się stanie, gdy — a nie jeśli — coś złośliwego uruchomi się z uprawnieniami użytkownika.

Odpowiedź powinna brzmieć: nic. Nie powinno być nic do zebrania.