Motoarele de căutare au fost construite pentru a indexa conținut. Cu toate acestea, atacatorii le folosesc pentru a indexa greșelile tale. Interogarea allintext:login tip de fișier:log poate părea inofensiv. În realitate, este una dintre cele mai simple metode de a descoperi fișiere jurnal expuse care conțin fluxuri de autentificare, acreditări, token-uri și date de infrastructură internă.
Dacă Google poate vedea acele jurnale, și atacatorii pot. Odată indexate, expunerea devine inevitabilă. Mai mult, atunci când datele de autentificare apar într-un fișier accesibil publicului, încălcarea este deja în mișcare.
1. De ce allintext:login filetype:log este mai periculos decât pare
Un Google dork este o interogare de căutare care folosește operatori avansați pentru a localiza conținut sensibil sau configurat greșit, indexat de motoarele de căutare. Nu exploatează Google. În schimb, exploatează expunerea ta.
Această interogare combină doi operatori:
- allintext: returnează paginile în care toți termenii apar în corpul textului
- tip de fișier:log restricționează rezultatele la
.logfișiere
Prin urmare:
Înseamnă: „Arată-mi fișierele jurnal care conțin cuvântul login. "
La prima vedere, acest lucru pare banal. Cu toate acestea, în practică, deseori returnează:
- Jurnalele serverului web expuse public
- CI/CD jurnalele încărcate ca artefacte
- Jurnalele de depanare accidental committransferate în depozite
- Jurnalele de aplicații cu acreditări în text simplu
Aceasta nu este o eroare a motorului de căutare. În schimb, este o vulnerabilitate la expunerea datelor cauzată de o configurare greșită. Google a indexat pur și simplu ceea ce era accesibil publicului.
2. Ce găsesc atacatorii de fapt în fișierele jurnal expuse
Când atacatorii aleargă allintext:login tip de fișier:log, nu navighează aleatoriu. Caută urme de autentificare.
2.1 Acreditări în text simplu
Jurnalele conțin frecvent intrări precum:
or
Sau chiar acreditări SMTP:
Înregistrarea sarcinilor utile de autentificare este una dintre cele mai rapide metode de a divulga acreditările de producție. Prin urmare, un singur fișier jurnal expus poate invalida întregul model de control al accesului.
2.2 Jetoane de sesiune și JWT-uri
Chiar și atunci când parolele nu sunt înregistrate, token-urile sunt adesea înregistrate.
De exemplu:
Un cookie JWT sau de sesiune valid în interiorul unui .log Fișierul poate permite:
- Deturnarea sesiunii
- Privilegiul escaladării
- Mișcarea laterală prin sistemele interne
Cu alte cuvinte, token-urile din jurnale transformă rezultatul depanării într-un vector de ocolire a autentificării.
2.3 CI/CD Artefactele
Jurnalele de construcție sunt deosebit de periculoase. De fapt, CI/CD Sistemele imprimă adesea variabile de mediu în timpul pașilor de construire.
Atacatorii descoperă frecvent:
Conținând linii precum:
If CI/CD Artefactele sunt publice, atunci secretele sunt publice. Idiotul de la Google pur și simplu accelerează descoperirea.
2.4 Date în cloud și infrastructură
Jurnalele expuse dezvăluie adesea:
- chei de acces AWS
- Șiruri de conexiune pentru stocarea Azure
- Adresele URL ale serviciilor interne
- Acreditări ale bazei de date
- Puncte finale Redis
Chiar dacă acreditările sunt rotite ulterior, atacatorul deține acum:
- Cartografierea infrastructurii
- Convențiile de denumire
- Țintește informațiile pentru atacuri viitoare
Prin urmare, buștenii expuși oferă atât acces, cât și recunoaștere.
3. Cum devin aceste jurnale publice în primul rând
Jurnalele nu apar ca prin magie în Google. Ele devin indexate deoarece erau accesibile publicului.
3.1 Servere web configurate greșit
Printre modelele comune se numără:
/logs/directoare accesibile fără autentificare- Listare în director activată
- Nginx sau Apache care servesc în format brut
.logfișiere
Dacă un jurnal este accesibil prin HTTP, acesta este indexabil.
3.2 CI/CD Expunerea la artefacte
Greșeli tipice:
- Artefacte publice activate în GitHub Actiuni
- Jurnalele încărcate în compartimentele S3 deschise
- Pipeline urme accesibile fără autentificare
A pipeline care stochează jurnalele într-un bucket public își publică eficient secretele.
3.3 Modul de depanare în producție
Valorile implicite ale framework-ului pot fi periculoase:
În plus, înregistrarea excesivă a cererilor în jurnal poate afișa:
- Anteturi
- indicativele
- Corpuri complete ale cererilor
Înregistrarea în jurnal a depanării în producție transformă aplicația într-un exportator de acreditări.
3.4 Jurnalele Docker și Container
Mediile containerizate introduc noi căi de expunere:
- Jurnalele montate în volume partajate
- Exportarea jurnalelor către endpoint-uri nesecurizate de către sidecar-uri
- Log dashboardcu acces public
Dacă jurnalele containerelor sunt expuse prin HTTP sau prin stocare deschisă, acestea pot fi căutate. În cele din urmă, sunt indexate.
4. Flux de atac realist: De la tocilar la breșă
Un lanț de atac tipic arată astfel:
Atacatorul aleargă:
- Descoperiri expuse
.logfişier - Extrase:
- Jetonul JWT
- Antet de autentificare de bază
- Șir de conexiune la baza de date
Încercări de autentificare împotriva:
- Puncte finale API
- Panouri de administrare
- Servicii interne
Dacă autentificarea reușește, atacatorul poate:
- Creșteți privilegiile
- Mutați lateral
- Fără efort CI/CD
- Compromiterea lanțului de aprovizionare
Ceea ce a început ca o interogare de căutare devine:
- Deturnarea sesiunii
- Umplerea internă a acreditărilor
- Pipeline preluare
- Intoxicație cu artefacte
Toate dintr-un fișier jurnal indexat public.
5. De ce înregistrarea „prea multă” a datelor este o problemă AppSec
Exploatarea forestieră nu este neutră. În schimb, ea creează o depozit secundar de date.
Dacă înregistrezi date sensibile, creezi efectiv o a doua copie a secretelor tale.
Totuși, jurnalele sunt adesea excluse din modelarea amenințărilor. În cadrul STRIDE, acest lucru se corelează în mod clar cu:
Dezvaluirea informatiei
Prin urmare, Secure SDLC Practicile ar trebui să trateze jurnalele ca:
- Artefacte relevante pentru securitate
- Active sensibile
- Componente de infrastructură care necesită protecție
Dacă modelul tău de amenințare ignoră jurnalele, este incomplet.
6. Cum să preveniți scurgerea de acreditări în fișierele jurnal
6.1 Secrete pentru oprirea înregistrării în jurnal
Nu se înregistrează niciodată:
- Parolele
- indicativele
- Chei API
- ID-uri de sesiune
- Anteturi de autorizare
Chiar și în modul de depanare.
Ori de câte ori este posibil, implementați redactarea automată.
6.2 Înregistrare structurată și sigură a datelor
Folosește înregistrarea structurată cu mascare și filtrare.
Exemplu (Node.js):
Exemplu (Python):
Principiul cheie este simplu: secretele nu trebuie niciodată să ajungă la chiuveta de bușteni.
6.3 Depozitarea jurnalelor cu blocare
Controalele de securitate ar trebui să includă:
- Dezactivați listarea în directoare
- Proteja
/logs/căi cu autentificare - Restricționează accesul la găleată
- Aplicați politicile de retenție
- Criptați jurnalele în repaus
Jurnalele nu trebuie să fie niciodată accesibile publicului prin HTTP.
6.4 CI/CD Guardrails
Revizuirile manuale sunt insuficiente. În schimb, implementați controale automate:
- Scanare secretă a jurnalelor înainte de publicarea artefactelor
- Compilări eșuate dacă sunt detectate token-uri
- Preveniți încărcarea artefactelor care conțin acreditări
- Validarea hash pentru artefacte
CI/CD ar trebui să blocheze expunerea înainte de indexare.
7. Cum previne Xygeni allintext:login tip fișier: jurnal Incidente
Problema nu este prostul de la Google. Problema este expunerea. Prin urmare, prevenirea trebuie să aibă loc înainte de indexare.
7.1 Detectarea secretelor în jurnale și artefacte
Scanări Xygeni:
- Jurnalele de aplicații
- CI/CD urme de locuri de muncă
- Construiește artefacte
- Straturile Docker
- Ieșiri serializate
Dacă apar acreditări, token-uri sau valori sensibile în .log fișiere, Xygeni le semnalează imediat.
7.2 CI/CD Guardrails Acea expunere blochează
În loc să vă bazați pe recenzii manuale, Xygeni impune securitatea la pipeline nivel:
Aceasta:
- Eșuează în construcții când secretele apar în jurnale
- Blochează publicarea artefactelor
- Previne expunerea accidentală la public
- Oprește îmbinările nesigure înainte de a ajunge la elementul principal
Dacă un job CI imprimă un token, pipeline eșuează.
Fără indexare.
Fără expunere.
Niciun incident.
7.3 Protecție Shift-Stânga înainte ca Google să o vadă
Momentul contează.
În loc să reacționeze la:
Xygeni oprește problema:
- At commit timp
- În timpul pull request validare
- În timpul pipeline execuție
- Înainte de publicarea artefactului
Dacă jurnalul nu devine niciodată public, Google nu îl indexează niciodată.
Concluzie finală: Dacă Google îl poate indexa, atacatorii au făcut-o deja
Jurnalele nu sunt inofensive. De fapt, sunt rareori temporare. În mod implicit, nu sunt private. Prin urmare, fiecare fișier jurnal ar trebui tratat ca un element relevant pentru securitate, nu doar ca rezultat al depanării.
Dacă datele sensibile ajung la un .log fișierul și devine accesibil publicului, se transformă imediat într-o suprafață de atac. Mai mult, odată indexate de un motor de căutare, expunerea crește în afara controlului dumneavoastră.
Soluția nu este oprirea înregistrării datelor. Mai degrabă, este vorba de înregistrarea responsabilă a datelor și de aplicarea unor controale stricte privind stocarea și distribuția. Cu alte cuvinte, securitatea trebuie să se extindă dincolo de aplicația în sine și să ajungă la nivelul de observabilitate.
In schimb:
- Opriți înregistrarea secretelor
- Depozitare blocată a jurnalelor
- aplica pipeline guardrails
- Automatizați detectarea și aplicarea politicilor
în cele din urmă, Prevenirea ține de momentul potrivit. Pentru că odată ce allintext:login tip de fișier:log returnează domeniul tău, incidentul a început deja.
