Złośliwe oprogramowanie podpisane przez Red Hat
W tym tygodniu kod kradnący dane logowania trafił do deweloperów pod szyldem Red Hat. Zagrożenie nie przyszło z zewnątrz Pańskiego kręgu zaufania — przyszło z jego środka. Nie sposób się przed tym zabezpieczyć weryfikacją. Może Pan za to trzymać dane logowania poza zasięgiem.
W tym tygodniu kod podpisany przez Red Hat próbował ukraść Pańskie dane logowania.
Atakujący wdarli się na konto dewelopera Red Hat i opublikowali zmodyfikowane wersje oficjalnych pakietów Red Hat. W chwili, gdy maszyna zainstalowała jeden z nich, ukryty kod uruchamiał się automatycznie i sięgał po wszystko cenne, co znalazł — klucze do chmury, tokeny dostępowe, dane logowania, wszystko, co otwiera drzwi. Następnie wykorzystał to, co ukradł, aby się rozprzestrzeniać.
Proszę zwrócić uwagę na kształt tego ataku. Celem nie był Red Hat — celem był Pan. Ich nazwa, ich zaufane konto, proces instalacji, z którego korzystał Pan tysiąc razy bez zastanowienia: to nie była ofiara. To była broń. Atak nie przemknął obok Pańskiego kręgu zaufania. Wszedł głównym drzwiem z identyfikatorem, który Pan sam sobie wydał. To odróżnia ataki na łańcuch dostaw od wszystkiego innego — niebezpieczeństwem nie jest obcy, którego można zablokować, lecz dostawca, któremu Pan już zaufał, dostarczający ładunek wprost do Pana. A był to Red Hat: jedna z najdojrzalszych pod względem bezpieczeństwa firm na świecie, z realnym przeglądem kodu i realnym budżetem. Wadliwy kod i tak trafił do dystrybucji pod ich nazwą.
Wniosek, od którego nie da się uciec: jeśli Red Hat nie potrafi zagwarantować, że to, co Pan od nich instaluje, jest czyste, nikt tego nie potrafi. Ani Pański framework, ani dostawca CI, ani zależność trzy poziomy niżej, której Pan nigdy nie czytał. Prędzej czy później uruchomi Pan kod, którego Pan nie napisał i nie mógł w pełni zweryfikować. To nie jest porażka procesu — tak po prostu wygląda budowanie na oprogramowaniu innych ludzi.
Proszę dalej skanować. Dalej przypinać wersje. Dalej weryfikować. Wszystko to warto robić — tylko proszę się na tym nie opierać, bo w tym tygodniu nic by to nie dało: złośliwe oprogramowanie przyjechało już wstępnie zaufane. Prawdziwe pytanie nie brzmi, jak trzymać zły kod z dala. Brzmi ono tak: gdy zły kod działa na Pańskiej maszynie, czy zabezpieczył Pan swoje sekrety?
Dla większości osób uczciwa odpowiedź brzmi: nie. Proszę zobaczyć, po co sięgnął ten atak — zmienne środowiskowe, tokeny leżące w plikach, a następnie podszedł do menedżerów sekretów w chmurze i poprosił je o oddanie zawartości. Tak w 2026 roku żyją dane logowania: zgromadzone w jednym miejscu, w zwykłym zasięgu wszystkiego, co akurat się uruchamia. Jeden zły instalacja nie zabiera jednego sekretu. Zabiera wszystkie, po czym się rozprzestrzenia.
Rozwiązanie polega na tym, by nie trzymać danych logowania tam, gdzie może po nie sięgnąć Pański kod. Proszę trzymać je na dystans.
Na tym opiera się sposób działania Clavitor. Pana sekrety nie żyją w środowisku; nic nie czeka w pliku .env na odczyt. Program — lub agent AI — nigdy nie posiada samego poświadczenia. Otrzymuje możliwość jego użycia, pobieraną na świeżo w chwili potrzeby — nigdy nie przechowywaną, nigdy nie buforowaną — z jednej z naszych 21 lokalizacji na sześciu kontynentach, dzięki czemu najbliższa kopia jest zawsze o milisekundy stąd, ograniczona zakresem do jednego sekretu, który został przyznany, z rejestrowanym każdym dostępem. Gdy złośliwy skrypt instalacyjny maca w poszukiwaniu kluczy, trafia na pusty pokój.
Zakładamy przy tym, że prędzej czy później pochwycenie poświadczenia nastąpi, dlatego to, co nosi agent, jest po kradzieży niemal bezużyteczne. Działa wyłącznie z maszyny, na której zostało wydane — skopiowane i uruchomione z serwerów atakującego, zostaje odrzucone. Jest ograniczone liczbowo i monitorowane: kilka sekretów na minutę, więc nie może wyssać całego skarbca, a gdy sięgnie po więcej niż zwykle, wyzwala alert i blokuje się. Cała strategia robaka — chwyć wszystko szybko, użyj wszędzie — rozbija się o mur.
Nie obiecujemy niezawodności: jeśli poświadczenie jest w aktywnym użyciu dokładnie w chwili uruchomienia złośliwego oprogramowania, to jedno może zostać przechwycone — żadna architektura nie zmienia praw fizyki. Ale właśnie o to chodzi. Atak na Red Hat był katastrofalny dlatego, że jedna instalacja mogła opróżnić cały magazyn sekretów i użyć ich jako broni. Dystans plus poświadczenie przypięte do jednej maszyny i ograniczone do strumienia kropel zmieniają „zabrali wszystko i się rozprzestrzenili” w „mogli przechwycić jeden klucz w locie i nie zadziałał nigdzie indziej”. Taka jest różnica między katastrofą a przypisem.
Złośliwe oprogramowanie było podpisane przez Red Hat. Nie wygra Pan z tym weryfikacją. Proszę założyć, że kod wejdzie — i zadbać o to, by w tej chwili Pańskie sekrety nie czekały na niego w zasięgu ręki.
(Śledzone publicznie jako „Miasma", wariant rodziny samorozprzestrzeniających się robaków npm Shai-Hulud. Techniczne opracowania są warte Pana czasu; ten wpis dotyczy tej części, która nie zmienia się między incydentami.)
Źródła: