Motorët e kërkimit u ndërtuan për të indeksuar përmbajtjen. Megjithatë, sulmuesit i përdorin ato për të indeksuar gabimet tuaja. Pyetja allintext:login lloji i skedarit: log mund të duket i padëmshëm. Në realitet, është një nga mënyrat më të thjeshta për të zbuluar skedarë log të ekspozuar që përmbajnë rrjedha vërtetimi, kredenciale, tokena dhe të dhëna të infrastrukturës së brendshme.
Nëse Google mund t’i shohë këto regjistra, edhe sulmuesit mund ta bëjnë këtë. Pasi të indeksohen, ekspozimi bëhet i pashmangshëm. Për më tepër, kur kredencialet shfaqen në një skedar të aksesueshëm publikisht, shkelja është tashmë në lëvizje.
1. Pse allintext:login filetype:log është më i rrezikshëm nga sa duket
Një pyetje kërkimi Google dork është një pyetje kërkimi që përdor operatorë të avancuar për të gjetur përmbajtje të ndjeshme ose të konfiguruar gabimisht të indeksuar nga motorët e kërkimit. Nuk shfrytëzon Google. Në vend të kësaj, shfrytëzon ekspozimin tuaj.
Kjo pyetje kombinon dy operatorë:
- allintext: kthen faqet ku të gjithë termat shfaqen në tekstin kryesor
- lloji i skedarit: log kufizon rezultatet në
.logfotografi
Prandaj:
Do të thotë: “Më trego skedarët e regjistrit që përmbajnë fjalën login".
Në shikim të parë, kjo duket e parëndësishme. Megjithatë, në praktikë, shpesh rezulton kështu:
- Logjet e serverit të internetit të ekspozuara publikisht
- CI/CD regjistrat e ngarkuar si objekte
- Regjistrat e debugimit aksidentalisht commitu drejtua në depo
- Regjistrat e aplikacionit me kredenciale të thjeshta
Ky nuk është një gabim i motorit të kërkimit. Përkundrazi, është një cenueshmëria e ekspozimit ndaj të dhënave shkaktuar nga konfigurimi i gabuar. Google thjesht indeksoi atë që ishte e arritshme publikisht.
2. Çfarë gjejnë në të vërtetë sulmuesit në skedarët e regjistrit të ekspozuar
Kur sulmuesit ikin allintext:login lloji i skedarit: log, ata nuk po shfletojnë rastësisht. Ata po kërkojnë gjurmë vërtetimi.
2.1 Kredencialet e Tekstit të Thjeshtë
Regjistrat shpesh përmbajnë shënime të tilla si:
or
Ose edhe kredencialet SMTP:
Regjistrimi i ngarkesave të vërtetimit është një nga mënyrat më të shpejta për të zbuluar kredencialet e prodhimit. Si pasojë, një skedar i vetëm regjistri i ekspozuar mund ta zhvlerësojë të gjithë modelin tuaj të kontrollit të aksesit.
2.2 Tokenët e Sesionit dhe JWT-të
Edhe kur fjalëkalimet nuk regjistrohen, tokenët shpesh regjistrohen.
Për shembull:
Një cookie JWT ose sesioni i vlefshëm brenda një .log Skedari mund të aktivizojë:
- Rrëmbimi i seancës
- Shkallëzimi i privilegjit
- Lëvizja anësore nëpër sistemet e brendshme
Me fjalë të tjera, tokenët në regjistra e shndërrojnë rezultatin e debugging-ut në një vektor anashkalimi të autentifikimit.
2.3 CI/CD Objekte
Trungjet e ndërtimit janë veçanërisht të rrezikshme. Në fakt, CI/CD Sistemet shpesh shtypin variablat e mjedisit gjatë hapave të ndërtimit.
Sulmuesit shpesh zbulojnë:
Përmban rreshta të tillë si:
If CI/CD Artefaktet janë publike, atëherë sekretet janë publike. Budallai i Google thjesht përshpejton zbulimin.
2.4 Të dhëna të reve dhe infrastrukturës
Regjistrat e ekspozuar shpesh zbulojnë:
- Çelësat e qasjes në AWS
- Vargjet e lidhjes së ruajtjes Azure
- URL-të e shërbimit të brendshëm
- Kredencialet e bazës së të dhënave
- Pikat fundore të Redis
Edhe nëse kredencialet ndërrohen më vonë, sulmuesi tani zotëron:
- Hartimi i infrastrukturës
- Konventat e emërtimit
- Inteligjenca e objektivave për sulmet e ardhshme
Prandaj, shkrimet e ekspozuara ofrojnë si akses ashtu edhe zbulim.
3. Si bëhen publike këto regjistra që në fillim
Regjistrat nuk shfaqen magjikisht në Google. Ato indeksohen sepse ishin të arritshme publikisht.
3.1 Serverë Web të konfiguruar gabimisht
Modelet e zakonshme përfshijnë:
/logs/drejtoritë e arritshme pa autentifikim- Renditja e direktorisë u aktivizua
- Nginx ose Apache që shërbejnë si të papërpunuara
.logfotografi
Nëse një regjistër është i arritshëm nëpërmjet HTTP-së, ai është i indeksueshëm.
3.2 CI/CD Ekspozimi i Artefakteve
Gabimet tipike:
- Artefakte publike të aktivizuara në Veprimet GitHub
- Logjet e ngarkuara për të hapur kova S3
- Pipeline gjurmë të arritshme pa vërtetim
A pipeline që ruan trungjet në një kovë publike në mënyrë efektive publikon sekretet e saj.
3.3 Modaliteti i Debugimit në Prodhim
Parametrat e parazgjedhur të kornizës mund të jenë të rrezikshme:
Për më tepër, regjistrimi i tepërt i kërkesave mund të printojë:
- Headers
- argumentet
- Trupat e plotë të kërkesave
Regjistrimi i debug-eve në prodhim e transformon aplikacionin tuaj në një eksportues kredencialesh.
3.4 Regjistrat e Docker dhe Container
Mjediset e kontejnerizuara prezantojnë shtigje të reja ekspozimi:
- Logjet e montuara në vëllime të përbashkëta
- Karroca anësore që eksportojnë trungje në pika fundore të pasigurta
- Identifikohu dashboardme akses publik
Nëse regjistrat e kontejnerëve ekspozohen nëpërmjet HTTP ose hapësirës së hapur të ruajtjes, ato janë të kërkueshme. Përfundimisht, ato indeksohen.
4. Rrjedha reale e sulmit: Nga Dork në Breach
Një zinxhir tipik sulmesh duket kështu:
Sulmuesi vrapon:
- Gjetjet e ekspozuara
.logskedar - Ekstraktet:
- Simbol JWT
- Titulli i Autorizimit Bazë
- Vargu i lidhjes së bazës së të dhënave
Përpjekje për vërtetim kundër:
- Pikat fundore të API-t
- Panelet e administratorit
- Shërbime të brendshme
Nëse vërtetimi ka sukses, sulmuesi mund të:
- Përshkallëzo privilegjet
- Lëviz anash
- Qasja CI/CD
- Kompromentoni zinxhirin e furnizimit
Ajo që filloi si një pyetje kërkimi shndërrohet në:
- Rrëmbimi i seancës
- Mbushje e brendshme e kredencialeve
- Pipeline marrjen
- Helmim nga artefaktet
Të gjitha nga një skedar regjistri i indeksuar publikisht.
5. Pse Regjistrimi i Shumëfishtë i të Dhënave është një Problem i AppSec
Prerja e të dhënave nuk është neutrale. Përkundrazi, ajo krijon një ruajtja e të dhënave dytësore.
Nëse regjistroni të dhëna të ndjeshme, në fakt krijoni një kopje të dytë të sekreteve tuaja.
Megjithatë, regjistrat shpesh përjashtohen nga modelimi i kërcënimeve. Nën STRIDE, kjo lidhet qartë me:
Zbulimi i informacionit
Prandaj, i Sigurt SDLC Praktikat duhet t'i trajtojnë regjistrat si:
- Artefakte të rëndësishme për sigurinë
- Asete të ndjeshme
- Komponentët e infrastrukturës që kërkojnë mbrojtje
Nëse modeli juaj i kërcënimeve i injoron regjistrat, ai është i paplotë.
6. Si të parandaloni rrjedhjen e kredencialeve në skedarët e regjistrave
6.1 Sekretet e Ndërprerjes së Regjistrimit
Mos u regjistro kurrë:
- fjalëkalimet
- argumentet
- Çelësat API
- ID-të e sesionit
- Titujt e autorizimit
Edhe në modalitetin e debugimit.
Sa herë që është e mundur, zbatoni redaktimin automatik.
6.2 Regjistrim i Strukturuar dhe i Sigurt
Përdorni regjistrimin e strukturuar me maskim dhe filtrim.
Shembull (Node.js):
Shembull (Python):
Parimi kryesor është i thjeshtë: sekretet nuk duhet të arrijnë kurrë në lavamanin e drurit.
6.3 Mbyllja e ruajtjes së regjistrave
Kontrollet e sigurisë duhet të përfshijnë:
- Çaktivizo listën e direktorive
- Protect
/logs/shtigje me autentifikim - Kufizo aksesin e kovës
- Zbatoni politikat e mbajtjes së të dhënave
- Enkripto regjistrat në qetësi
Regjistrat nuk duhet të jenë kurrë të arritshëm publikisht nëpërmjet HTTP-së.
6.4 CI/CD Guardrails
Rishikimet manuale janë të pamjaftueshme. Në vend të kësaj, zbatoni kontrolle të automatizuara:
- Skanim sekret i regjistrave para publikimit të artefakteve
- Ndërtime të dështuara nëse zbulohen tokena
- Parandaloni ngarkimet e artefakteve që përmbajnë kredenciale
- Validimi i hash-it për artefaktet
CI/CD duhet të bllokojë ekspozimin përpara se të ndodhë indeksimi.
7. Si e parandalon Xygeni të gjitha tekstet:login filetype:log Incidente
Problemi nuk është budallai i Google. Problemi është ekspozimi. Prandaj, parandalimi duhet të ndodhë përpara indeksimit.
7.1 Zbulimi i Sekreteve në Logje dhe Artefakte
Skanimet Xygeni:
- Regjistrat e aplikacioneve
- CI/CD gjurmë pune
- Ndërto objekte
- Shtresat e Docker
- Daljet e serializuara
Nëse shfaqen kredenciale, tokena ose vlera të ndjeshme në .log skedarët, Xygeni i sinjalizon ato menjëherë.
7.2 CI/CD Guardrails Që bllokon ekspozimin
Në vend që të mbështetesh në rishikime manuale, Xygeni zbaton sigurinë në pipeline niveli:
Kjo:
- Dështon ndërtimet kur sekretet shfaqen në regjistra
- Bllokon publikimin e artefakteve
- Parandalon ekspozimin aksidental në publik
- Ndalon bashkimet e pasigurta përpara se të arrijë te kryesore
Nëse një punë CI printon një token, pipeline dështon.
Pa indeksim.
Asnjë ekspozim.
Asnjë incident.
7.3 Mbrojtje me Shift-Majtas përpara se Google ta shohë
Koha ka rëndësi.
Në vend që të reagoni ndaj:
Xygeni e ndalon problemin:
- At commit kohë
- Gjatë pull request sanksionim
- Gjatë pipeline ekzekutim
- Para publikimit të artefaktit
Nëse regjistri nuk bëhet kurrë publik, Google nuk e indekson kurrë atë.
Përfundimtar: Nëse Google mund ta indeksojë, sulmuesit e kanë bërë tashmë
Logjet nuk janë të padëmshme. Në fakt, ato rrallë janë të përkohshme. Si parazgjedhje, ato nuk janë private. Prandaj, çdo skedar log duhet të trajtohet si një aset që lidhet me sigurinë, jo vetëm si rezultat i debugging-ut.
Nëse të dhënat e ndjeshme arrijnë në një .log skedar dhe bëhet i arritshëm publikisht, Ai shndërrohet menjëherë në një sipërfaqe sulmi. Për më tepër, pasi indeksohet nga një motor kërkimi, ekspozimi shkallëzohet përtej kontrollit tuaj.
Zgjidhja nuk është ndalimi i regjistrimit. Përkundrazi, është regjistrimi me përgjegjësi dhe zbatimi i kontrolleve të rrepta rreth ruajtjes dhe shpërndarjes. Me fjalë të tjera, siguria duhet të shtrihet përtej vetë aplikacionit dhe në shtresën e vëzhgueshmërisë.
Në vend të kësaj:
- Ndalo regjistrimin e sekreteve
- Mbyllni ruajtjen e regjistrave
- zbatoj pipeline guardrails
- Automatizoni zbulimin dhe zbatimin e politikave
në fund të fundit, parandalimi ka të bëjë me kohën. Sepse një herë allintext:login lloji i skedarit: log kthen domenin tuaj, incidenti ka filluar tashmë.
