Iskalniki so bili zgrajeni za indeksiranje vsebine. Vendar pa jih napadalci uporabljajo za indeksiranje vaših napak. Poizvedba allintext:login vrsta datoteke: dnevnik morda izgleda neškodljivo. V resnici je to eden najpreprostejših načinov za odkrivanje izpostavljenih dnevniških datotek, ki vsebujejo poteke preverjanja pristnosti, poverilnice, žetone in podatke o notranji infrastrukturi.
Če lahko Google vidi te dnevnike, jih lahko tudi napadalci. Ko so indeksirani, postane razkritje neizogibno. Poleg tega, ko se poverilnice pojavijo v javno dostopni datoteki, je vdor že v teku.
1. Zakaj allintext:login datoteka:log je bolj nevarna, kot je videti
Googlov dork je iskalna poizvedba, ki uporablja napredne operatorje za iskanje občutljive ali napačno konfigurirane vsebine, ki jo indeksirajo iskalniki. Ne izkorišča Googla. Namesto tega izkorišča vašo izpostavljenost.
Ta poizvedba združuje dva operatorja:
- allintext: vrne strani, kjer se vsi izrazi pojavljajo v besedilu
- vrsta datoteke: dnevnik omeji rezultate na
.logdatoteke
Zato:
Pomeni: "Pokaži mi dnevniške datoteke, ki vsebujejo besedo login«.
Na prvi pogled se zdi to nepomembno. Vendar se v praksi pogosto vrne:
- Javno izpostavljeni dnevniki spletnega strežnika
- CI/CD dnevniki, naloženi kot artefakti
- Nenamerno odpravljanje napak v dnevnikih commitpreneseno v repozitorije
- Dnevniki aplikacij s poverilnicami v navadnem besedilu
To ni napaka iskalnika. Namesto tega gre za ranljivost izpostavljenosti podatkov zaradi napačne konfiguracije. Google je preprosto indeksiral tisto, kar je bilo javno dostopno.
2. Kaj napadalci dejansko najdejo v izpostavljenih dnevniških datotekah
Ko napadalci bežijo allintext:login vrsta datoteke: dnevnik, ne brskajo naključno. Iščejo sledi preverjanja pristnosti.
2.1 Poverilnice v navadnem besedilu
Dnevniki pogosto vsebujejo vnose, kot so:
or
Ali celo poverilnice SMTP:
Beleženje avtentikacijskih podatkov je eden najhitrejših načinov za razkritje produkcijskih poverilnic. Posledično lahko ena sama izpostavljena datoteka dnevnika razveljavi celoten model nadzora dostopa.
2.2 Žetoni sej in JWT-ji
Tudi če gesla niso zabeležena, se žetoni pogosto beležijo.
Na primer:
Veljaven JWT ali sejni piškotek znotraj .log datoteka lahko omogoči:
- Ugrabitev seje
- Stopnjevanje privilegijev
- Bočno gibanje po notranjih sistemih
Z drugimi besedami, žetoni v dnevnikih pretvorijo izhod za odpravljanje napak v vektor za obhod preverjanja pristnosti.
2.3 CI/CD Artefakte
Dnevniki gradnje so še posebej nevarni. Pravzaprav CI/CD Sistemi pogosto izpišejo okoljske spremenljivke med koraki gradnje.
Napadalci pogosto odkrijejo:
Vsebuje vrstice, kot so:
If CI/CD Če so artefakti javni, so tudi skrivnosti javne. Googlov bedak preprosto pospeši odkrivanje.
2.4 Podatki o oblaku in infrastrukturi
Izpostavljeni dnevniki pogosto razkrivajo:
- Dostopni ključi AWS
- Povezovalni nizi za shrambo Azure
- URL-ji internih storitev
- Poverilnice baze podatkov
- Končne točke Redisa
Tudi če se poverilnice kasneje zamenjajo, ima napadalec zdaj:
- Kartiranje infrastrukture
- Imenovanje konvencij
- Ciljne obveščevalne podatke za prihodnje napade
Zato izpostavljeni hlodi omogočajo tako dostop kot izvidnico.
3. Kako ti dnevniki sploh postanejo javni
Dnevniki se v Googlu ne pojavijo kar po čarovniji. Indeksirajo se, ker so bili javno dostopni.
3.1 Napačno konfigurirani spletni strežniki
Pogosti vzorci vključujejo:
/logs/imeniki, dostopni brez preverjanja pristnosti- Seznam v imeniku omogočen
- Nginx ali Apache streže surovo
.logdatoteke
Če je dnevnik dosegljiv prek HTTP-ja, ga je mogoče indeksirati.
3.2 CI/CD Izpostavljenost artefaktom
Tipične napake:
- Javni artefakti omogočeni v Dejanja GitHub
- Dnevniki, naloženi za odpiranje veder S3
- Pipeline sledi dostopne brez preverjanja pristnosti
A pipeline ki shranjuje dnevnike v javnem vedru, dejansko objavi svoje skrivnosti.
3.3 Način odpravljanja napak v produkciji
Privzete nastavitve ogrodja so lahko nevarne:
Poleg tega lahko prekomerno beleženje zahtev izpiše:
- Glave
- Boni
- Celotna telesa zahtev
Z beleženjem napak v produkcijskem okolju se vaša aplikacija spremeni v izvoznik poverilnic.
3.4 Dnevniki Dockerja in kontejnerjev
Kontejnerizirana okolja uvajajo nove poti izpostavljenosti:
- Dnevniki, vpeti v skupne nosilce
- Izvoz dnevnikov v nezaščitene končne točke s pomočjo stranskih vozil
- Dnevnik dashboardz javnim dostopom
Če so dnevniki vsebnikov izpostavljeni prek HTTP-ja ali odprtega shrambe, jih je mogoče iskati. Sčasoma so indeksirani.
4. Realističen tok napada: od norca do preboja
Tipična veriga napadov izgleda takole:
Napadalec teče:
- Najdbe izpostavljene
.logdatoteka - Izvlečki:
- Žeton JWT
- Osnovna glava za avtorizacijo
- Niz za povezavo z zbirko podatkov
Poskusi preverjanja pristnosti proti:
- Končne točke API-ja
- Administratorske plošče
- Notranje storitve
Če je preverjanje pristnosti uspešno, lahko napadalec:
- Povečaj privilegije
- Premakni se bočno
- dostop CI/CD
- Ogrozite dobavno verigo
Kar se je začelo kot iskalna poizvedba, postane:
- Ugrabitev seje
- Notranje polnjenje poverilnic
- Pipeline prevzeti
- Zastrupitev z artefakti
Vse iz javno indeksirane datoteke dnevnika.
5. Zakaj je preveč beleženja problem AppSec
Sečnja ni nevtralna. Namesto tega ustvarja sekundarno shrambo podatkov.
Če beležite občutljive podatke, dejansko ustvarite drugo kopijo svojih skrivnosti.
Vendar so dnevniki pogosto izključeni iz modeliranja groženj. V okviru STRIDE se to jasno preslika na:
Razkritje informacij
Zato je varno SDLC prakse bi morale dnevnike obravnavati kot:
- Varnostno pomembni artefakti
- Občutljiva sredstva
- Komponente infrastrukture, ki zahtevajo zaščito
Če vaš model groženj ignorira dnevnike, je nepopoln.
6. Kako preprečiti uhajanje poverilnic v dnevniških datotekah
6.1 Skrivnosti prenehanja beleženja
Nikoli ne beleži:
- gesla
- Boni
- Ključi API-ja
- ID-ji sej
- Glave avtorizacije
Tudi v načinu za odpravljanje napak.
Kadar koli je mogoče, uvedite samodejno redigiranje.
6.2 Strukturirano in varno beleženje
Uporabite strukturirano beleženje z maskiranjem in filtriranjem.
Primer (Node.js):
Primer (Python):
Ključno načelo je preprosto: skrivnosti nikoli ne smejo priti v ponor.
6.3 Zaklepanje shrambe dnevnikov
Varnostni nadzor bi moral vključevati:
- Onemogoči seznam imenikov
- Zaščitite
/logs/poti z overjanjem - Omeji dostop do vedra
- Uporabite pravilnike o hranjenju
- Šifriranje dnevnikov v mirovanju
Dnevniki ne smejo biti nikoli javno dostopni prek HTTP.
6.4 CI/CD Guardrails
Ročni pregledi niso zadostni. Namesto tega uvedite avtomatizirane kontrole:
- Skrivno skeniranje dnevnikov pred objavo artefaktov
- Neuspešne gradnje, če so zaznani žetoni
- Prepreči nalaganje artefaktov, ki vsebujejo poverilnice
- Validacija zgoščene vrednosti za artefakte
CI/CD bi moral blokirati izpostavljenost, preden se izvede indeksiranje.
7. Kako Xygeni preprečuje allintext:login vrsta datoteke: dnevnik incidentov
Težava ni v Googlovem bedaklu. Težava je v izpostavljenosti. Zato je treba pred indeksiranjem ukrepati preventivo.
7.1 Zaznavanje skrivnih elementov v dnevnikih in artefaktih
Xygeni skeniranja:
- Dnevniki aplikacij
- CI/CD sledi delovnih mest
- Zgradite artefakte
- Dockerjeve plasti
- Serializirani izhodi
Če se poverilnice, žetoni ali občutljive vrednosti pojavijo v .log datoteke, jih Xygeni takoj označi.
7.2 CI/CD Guardrails To blokira izpostavljenost
Namesto da se zanašate na ročne preglede, Xygeni zagotavlja varnost na pipeline raven:
To:
- Gradnje ne uspejo, ko se skrivnosti pojavijo v dnevnikih
- Objava artefaktov blokov
- Preprečuje nenamerno izpostavljenost javnosti
- Ustavi nevarne združitve, preden doseže glavno
Če opravilo CI natisne žeton, pipeline ne uspe.
Brez indeksiranja.
Brez izpostavljenosti.
Brez incidenta.
7.3 Zaščita pred tipko Shift-Left, preden jo Google vidi
Čas je pomemben.
Namesto da bi se odzvali na:
Xygeni ustavi težavo:
- At commit čas
- Med pull request potrjevanje
- Med pipeline izvedba
- Pred objavo artefakta
Če dnevnik nikoli ne postane javen, ga Google nikoli ne indeksira.
Končni zaključek: Če Google lahko indeksira, so napadalci to že storili
Dnevniki niso neškodljivi. Pravzaprav so le redko začasni. Privzeto niso zasebni. Zato je treba vsako datoteko dnevnika obravnavati kot varnostno pomembno sredstvo, ne le kot izhod za odpravljanje napak.
Če občutljivi podatki dosežejo .log datoteka in postane javno dostopna, takoj se spremeni v napadalno površino. Poleg tega, ko iskalnik enkrat indeksira vsebino, se izpostavljenost poveča izven vašega nadzora.
Rešitev ni v tem, da se ustavi beleženje. Gre za odgovorno beleženje in uveljavljanje strogih kontrol glede shranjevanja in distribucije. Z drugimi besedami, varnost se mora razširiti preko same aplikacije in na plast opazovanja.
Namesto tega:
- Nehaj beležiti skrivnosti
- Zakleni shranjevanje dnevnikov
- Uveljavite pipeline guardrails
- Avtomatizirajte zaznavanje in uveljavljanje pravilnikov
Konec koncev, Pri preprečevanju gre za pravočasnost. Ker enkrat allintext:login vrsta datoteke: dnevnik vrne vašo domeno, se je incident že začel.
