Vyhledávače byly vytvořeny k indexování obsahu. Útočníci je však používají k indexování vašich chyb. Dotaz allintext:login typ souboru:log může vypadat neškodně. Ve skutečnosti je to jeden z nejjednodušších způsobů, jak odhalit odhalené soubory protokolů obsahující ověřovací toky, přihlašovací údaje, tokeny a data interní infrastruktury.
Pokud Google může tyto protokoly vidět, mohou je vidět i útočníci. Jakmile jsou indexovány, je odhalení nevyhnutelné. Navíc, když se přihlašovací údaje objeví ve veřejně dostupném souboru, je narušení již v plném proudu.
1. Proč allintext:login typ souboru:log je nebezpečnější, než vypadá
Google dork je vyhledávací dotaz, který používá pokročilé operátory k nalezení citlivého nebo chybně nakonfigurovaného obsahu indexovaného vyhledávači. Nezneužívá Google. Místo toho zneužívá vaši publicitu.
Tento dotaz kombinuje dva operátory:
- allintext: vrátí stránky, kde se všechny výrazy objevují v textu
- typ souboru:log omezuje výsledky na
.logsoubory
Proto:
Znamená: „Zobrazit soubory protokolu, které obsahují slovo login. "
Na první pohled se to zdá triviální. V praxi to však často vrací:
- Veřejně zveřejněné protokoly webového serveru
- CI/CD protokoly nahrané jako artefakty
- Omylem došlo k ladění protokolů commituloženo do repozitářů
- Protokoly aplikací s přihlašovacími údaji v prostém textu
Nejedná se o chybu vyhledávače. Spíše o zranitelnost v oblasti úniku dat způsobeno špatnou konfigurací. Google jednoduše indexoval to, co bylo veřejně dostupné.
2. Co útočníci skutečně najdou v odhalených souborech protokolu
Když útočníci utíkají allintext:login typ souboru:log, neprocházejí náhodně. Hledají stopy ověřování.
2.1 Přihlašovací údaje v prostém textu
Protokoly často obsahují položky, jako například:
or
Nebo dokonce přihlašovací údaje SMTP:
Protokolování ověřovacích dat je jedním z nejrychlejších způsobů úniku přihlašovacích údajů v produkčním prostředí. V důsledku toho může jediný odhalený soubor protokolu zneplatnit celý váš model řízení přístupu.
2.2 Tokeny relací a JWT
I když se hesla nezaznamenávají, tokeny se často zaznamenávají.
Například:
Platný soubor cookie JWT nebo relace uvnitř .log soubor může povolit:
- Únos únosů
- Zvyšování oprávnění
- Boční pohyb napříč vnitřními systémy
Jinými slovy, tokeny v protokolech přeměňují ladicí výstup na vektor pro obcházení ověřování.
2.3 CI/CD Artefakty
Záznamy o stavbě jsou obzvláště nebezpečné. Ve skutečnosti CI/CD Systémy často během kroků sestavení vypisují proměnné prostředí.
Útočníci často objevují:
Obsahující řádky jako například:
If CI/CD Pokud jsou artefakty veřejné, pak jsou tajemství veřejná. Ten blbec z Googlu prostě urychluje objevování.
2.4 Cloudová a infrastrukturní data
Zveřejněné protokoly často odhalují:
- Přístupové klíče AWS
- Připojovací řetězce úložiště Azure
- URL adresy interních služeb
- Přihlašovací údaje k databázi
- Koncové body Redisu
I když se přihlašovací údaje později otočí, útočník nyní má:
- Mapování infrastruktury
- Konvence pojmenování
- Cílové informace pro budoucí útoky
Odkryté protokoly proto poskytují jak přístup, tak i průzkum.
3. Jak se tyto protokoly vůbec stanou veřejnými
Záznamy se v Googlu neobjeví jen tak magicky. Indexují se, protože byly veřejně dostupné.
3.1 Nesprávně nakonfigurované webové servery
Mezi běžné vzorce patří:
/logs/adresáře přístupné bez ověřování- Výpis do adresáře povolen
- Nginx nebo Apache zobrazující surový obsah
.logsoubory
Pokud je protokol dostupný přes HTTP, je indexovatelný.
3.2 CI/CD Expozice artefaktů
Typické chyby:
- Veřejné artefakty povoleny v Akce GitHub
- Protokoly nahrané do otevřených S3 kontejnerů
- Pipeline stopy přístupné bez ověřování
A pipeline který ukládá protokoly do veřejného kontejneru, efektivně zveřejňuje svá tajná data.
3.3 Režim ladění v produkčním prostředí
Výchozí nastavení frameworku může být nebezpečné:
Nadměrné protokolování požadavků může navíc vytisknout:
- Záhlaví
- žetony
- Úplné tělo žádosti
Protokolování ladění v produkčním prostředí transformuje vaši aplikaci na exportér pověření.
3.4 Protokoly Dockeru a kontejnerů
Kontejnerizovaná prostředí zavádějí nové cesty expozice:
- Protokoly připojené do sdílených svazků
- Export protokolů do nezabezpečených koncových bodů pomocí sidecarů
- Log dashboards veřejným přístupem
Pokud jsou protokoly kontejnerů zpřístupněny přes HTTP nebo otevřené úložiště, lze je prohledávat. Nakonec jsou indexovány.
4. Realistický postup útoku: Od Dorka k průniku
Typický řetězec útoků vypadá takto:
Útočník běží:
- Nálezy odkryté
.logsoubor - Extrakty:
- Token JWT
- Základní hlavička ověřování
- Řetězec pro připojení k databázi
Pokusy o ověření proti:
- Koncové body API
- Administrační panely
- Interní služby
Pokud je ověření úspěšné, útočník může:
- Eskalace oprávnění
- Pohybujte se do stran
- Získat přístup CI/CD
- Ohrožení dodavatelského řetězce
Co začalo jako vyhledávací dotaz, se stává:
- Únos únosů
- Interní vyplňování přihlašovacích údajů
- Pipeline převzetí
- Otrava artefakty
Vše z veřejně indexovaného souboru protokolu.
5. Proč je „příliš mnoho“ protokolování problémem AppSec
Protokolování není neutrální. Místo toho vytváří sekundární úložiště dat.
Pokud zaznamenáváte citlivá data, v podstatě vytvoříte druhou kopii svých tajných dat.
Protokoly jsou však z modelování hrozeb často vyloučeny. V rámci STRIDE to jasně odpovídá:
Informace o zveřejnění
Proto Zabezpečené SDLC postupy by měly zacházet s protokoly jako s:
- Artefakty relevantní pro bezpečnost
- Citlivá aktiva
- Součásti infrastruktury vyžadující ochranu
Pokud váš model hrozeb ignoruje protokoly, je neúplný.
6. Jak zabránit úniku přihlašovacích údajů v souborech protokolu
6.1 Zastavení protokolování tajných kódů
Nikdy se nezaznamenávat:
- Hesla
- žetony
- API klíče
- ID relací
- Autorizační hlavičky
I v ladicím režimu.
Kdykoli je to možné, implementujte automatickou redakci.
6.2 Strukturované a bezpečné protokolování
Používejte strukturované protokolování s maskováním a filtrováním.
Příklad (Node.js):
Příklad (Python):
Klíčový princip je jednoduchý: tajemství se nikdy nesmí dostat do dřezu.
6.3 Uzamčení úložiště protokolů
Bezpečnostní opatření by měla zahrnovat:
- Zakázat výpis adresáře
- Chránit
/logs/cesty s ověřováním - Omezit přístup k kontejneru
- Použít zásady uchovávání informací
- Šifrovat protokoly v klidovém stavu
Protokoly nesmí být nikdy veřejně dostupné přes HTTP.
6.4 CI/CD Guardrails
Manuální kontroly nestačí. Místo toho implementujte automatizované kontroly:
- Tajné skenování protokolů před zveřejněním artefaktu
- Selžení sestavení, pokud jsou detekovány tokeny
- Zabránit nahrávání artefaktů obsahujících přihlašovací údaje
- Ověření haše pro artefakty
CI/CD by měl blokovat expozici před indexováním.
7. Jak Xygeni zabraňuje allintextu:login typ souboru:log Incidenty
Problém není v Googleově blbci. Problém je v odhalení. Proto je nutné před indexováním provést prevenci.
7.1 Detekce tajných prvků v protokolech a artefaktech
Skeny Xygeni:
- Protokoly aplikací
- CI/CD stopy úloh
- Vytvářejte artefakty
- Vrstvy Dockeru
- Serializované výstupy
Pokud se v .log soubory, Xygeni je okamžitě označí příznakem.
7.2 CI/CD Guardrails To blokuje expozici
Místo spoléhání se na manuální kontroly, Xygeni dbá na bezpečnost na pipeline úroveň:
Tento:
- Selžení sestavení, když se v protokolech zobrazí tajné kódy
- Publikace artefaktů bloků
- Zabraňuje náhodnému vystavení veřejnosti
- Zastaví nebezpečné sloučení před dosažením hlavního
Pokud úloha CI vytiskne token, pipeline nezdaří.
Žádné indexování.
Žádná expozice.
Žádný incident.
7.3 Ochrana proti Shift-Left, než ji Google uvidí
Načasování je důležité.
Místo reakce na:
Xygeni problém zastaví:
- At commit čas
- Během pull request validace
- Během pipeline provedení
- Před publikací artefaktu
Pokud se protokol nikdy nezveřejní, Google ho nikdy neindexuje.
Závěrečné shrnutí: Pokud to Google dokáže indexovat, útočníci to už udělali.
Protokoly nejsou neškodné. Ve skutečnosti jsou jen zřídka dočasné. Ve výchozím nastavení nejsou soukromé. Proto by se s každým souborem protokolu mělo zacházet jako s bezpečnostním aktivem, nikoli pouze jako s ladicím výstupem.
Pokud se citlivá data dostanou k .log soubor a stane se veřejně přístupným, okamžitě se promění v útočnou plochu. Navíc, jakmile je vyhledávač zaindexuje, expozice se vymkne vaší kontrole.
Řešením není zastavit protokolování. Spíše jde o zodpovědné protokolování a vynucování přísných kontrol ukládání a distribuce. Jinými slovy, zabezpečení musí sahat i za hranice samotné aplikace a do vrstvy pozorovatelnosti.
Namísto:
- Zastavit protokolování tajných dat
- Uzamčení úložiště protokolů
- vynutit pipeline guardrails
- Automatizujte detekci a vynucování zásad
Nakonec, Prevence je o načasování. Protože jakmile allintext:login typ souboru:log vrátí vaši doménu, incident již začal.
