n8n: wyciekłe tokeny API nadal otwierały 321 instancji

Do przejęcia automatyzacji nie zawsze potrzebna jest podatność CVE. GitGuardian zidentyfikował 4576 unikalnych tokenów API n8n powiązanych z 1255 nazwami hostów w publicznej historii GitHub. Spośród 896 osiągalnych w czasie badania instancji 321 nadal akceptowało co najmniej jeden ujawniony token.

Tożsamość automatyzacji ma zwykle większy zasięg niż konto pojedynczego pracownika. n8n łączy systemy CRM, bazy, pocztę, chmurę i usługi AI. Ważny token nie daje jedynie wglądu w panel: może pozwolić tworzyć lub uruchamiać workflow, które korzystają z już zapisanych poświadczeń downstream.

Skąd wzięły się tokeny

Badacze wskazują klasyczne pliki .env, skrypty i przykładowe konfiguracje, ale też nowy kanał: pliki uprawnień narzędzi AI. Gdy deweloper zatwierdzi polecenie curl zawierające URL n8n i klucz, kompletna komenda może trafić do .claude/settings.json lub podobnego pliku. Takie pliki nie zawsze są objęte regułami .gitignore przeznaczonymi dla sekretów.

Część starszych kluczy n8n nie miała pola wygaśnięcia. Commit sprzed wielu miesięcy nadal mógł więc działać, jeśli administrator nie usunął tokenu po stronie instancji. Usunięcie sekretu z aktualnej gałęzi też nie pomaga: wartość pozostaje w historii Git i w forkach.

Badanie opisane przez GitGuardian pokazało cztery klasy działań z użyciem udokumentowanego API: enumerację użytkowników i workflow, odczyt danych wykonania, użycie zapisanych poświadczeń oraz eksfiltrację sekretu przez kontrolowany przez napastnika węzeł HTTP. Szyfrowanie credential store w spoczynku nie chroni przed uprawnionym workflow, ponieważ platforma musi odszyfrować klucz, aby go użyć.

Dlaczego pełna aktualizacja nie wystarczy

To nie błąd pamięci ani obejście autoryzacji. Serwer otrzymuje prawidłowo podpisany token i wykonuje dozwolone operacje. WAF i skaner podatności mogą nie zobaczyć niczego nietypowego. Najważniejsze dane detekcyjne to tożsamość klucza, adres źródłowy, tworzenie i aktywowanie workflow, zmiany w credential bindings oraz nowe docelowe hosty HTTP.

Wbudowany endpoint audytowy n8n potrafi wskazać niebezpieczne węzły, otwarte webhooki i słabe konfiguracje. Dla właściciela jest narzędziem naprawczym, ale dla posiadacza wyciekłego uprzywilejowanego tokenu może stać się mapą dalszego ataku.

Plan reakcji

1. Skanuj całą historię repozytoriów, gisty, issues i logi CI pod kątem N8N_API_KEY, adresów instancji oraz pełnych poleceń HTTP.
2. Unieważnij znalezione klucze po stronie n8n; samo wygenerowanie nowego tokenu nie odbiera praw staremu.
3. Przejrzyj dzienniki API od momentu pierwszego publicznego commitu i szukaj zmian workflow, nowych wywołań oraz nietypowych adresów źródłowych.
4. Ustal, do jakich credentials, tabel danych i systemów downstream miał dostęp skompromitowany principal. Rotuj również te sekrety.
5. Wyłącz publiczne API, jeśli nie jest potrzebne, albo ogranicz je VPN-em, mTLS i allowlistą adresów.
6. Wymuś krótkie terminy ważności, osobny token dla każdego procesu i minimalny zakres uprawnień.
7. Dodaj skanowanie sekretów przed commitem oraz kontrolę plików konfiguracyjnych agentów AI.

Jak projektować tokeny automatyzacji

Najbezpieczniejszy model nie opiera się na jednym kluczu właściciela instancji używanym przez wszystkie integracje. Każdy workflow powinien mieć osobną tożsamość, zakres do konkretnych operacji i krótki czas życia. Jeśli zewnętrzny system wspiera OIDC lub workload identity, n8n może wymieniać podpisaną tożsamość na krótkotrwałe poświadczenie zamiast przechowywać długowieczny sekret. Ułatwia to również przypisanie requestu do jednego procesu.

Detekcja musi uwzględniać legalną składnię API. Dobrym sygnałem jest pierwszy dostęp tokenu z nowego ASN, utworzenie węzła HTTP wskazującego nową domenę, masowy odczyt historii wykonań albo workflow uruchomiony poza swoim zwykłym oknem. Log powinien wiązać token z właścicielem, workflow, zakresem, adresem źródłowym i zmianą konfiguracji. Alarm oparty tylko na liczbie błędów logowania nie zobaczy napastnika, który ma prawidłowy klucz.

Fakty i wnioski

Liczby 4576, 1255, 896 i 321 są wynikiem badania w konkretnym momencie, a nie bieżącym licznikiem wszystkich narażonych instalacji. Ważny token potwierdza dostęp, ale nie dowodzi, że został wykorzystany przez przestępcę.

Wniosek Breachroad: token automatyzacji powinien być zarządzany jak uprzywilejowana tożsamość maszynowa. Szkolenia dla zespołów IT i deweloperów pomagają zamknąć nowe miejsca wycieku, a audyt bezpieczeństwa chmury może prześledzić realny zasięg integracji i sekretów.