Ang mga search engine ay ginawa para i-index ang nilalaman. Gayunpaman, ginagamit ito ng mga attacker para i-index ang iyong mga pagkakamali. Ang query allintext:login uri ng file:log maaaring magmukhang hindi nakakapinsala. Sa katotohanan, ito ay isa sa mga pinakasimpleng paraan upang matuklasan ang mga nakalantad na log file na naglalaman ng mga daloy ng pagpapatotoo, mga kredensyal, mga token, at panloob na datos ng imprastraktura.
Kung nakikita ng Google ang mga log na iyon, makikita rin ito ng mga umaatake. Kapag na-index na, hindi maiiwasan ang pagkakalantad. Bukod dito, kapag lumalabas ang mga kredensyal sa isang pampublikong file na naa-access, nangangahulugan ito na may nangyayari nang paglabag.
1. Bakit allintext:login Ang filetype:log ay Mas Delikado Kaysa sa Mukhang Ito
Ang Google dork ay isang search query na gumagamit ng mga advanced operator upang mahanap ang sensitibo o maling pagkakaayos ng nilalaman na na-index ng mga search engine. Hindi nito sinasamantala ang Google. Sa halip, sinasamantala nito ang iyong pagkakalantad.
Pinagsasama ng query na ito ang dalawang operator:
- allintext: nagbabalik ng mga pahina kung saan lumalabas ang lahat ng termino sa body text
- uri ng file:log nililimitahan ang mga resulta sa
.logfile
Samakatuwid:
Ibig sabihin: "Ipakita sa akin ang mga log file na naglalaman ng salita login. "
Sa unang tingin, tila walang gaanong halaga iyon. Gayunpaman, sa pagsasagawa, madalas itong nagbabalik:
- Mga log ng web server na nakalantad sa publiko
- CI/CD mga log na na-upload bilang mga artifact
- Hindi sinasadyang na-debug ang mga log commitnaka-ted sa mga repositoryo
- Mga log ng aplikasyon na may mga kredensyal na plaintext
Hindi ito isang bug sa search engine. Sa halip, ito ay isang kahinaan sa pagkakalantad ng datos sanhi ng maling pag-configure. Ini-index lang ng Google kung ano ang maaaring ma-access ng publiko.
2. Ano Talaga ang Nakikita ng mga Attacker sa mga Exposed Log File
Kapag tumatakbo ang mga umaatake allintext:login uri ng file:log, hindi sila basta-basta nagba-browse. Naghahanap sila ng mga bakas ng pagpapatotoo.
2.1 Mga Kredensyal sa Plaintext
Ang mga log ay kadalasang naglalaman ng mga entry tulad ng:
or
O kahit na mga kredensyal ng SMTP:
Ang pag-log ng mga authentication payload ay isa sa pinakamabilis na paraan upang mabunyag ang mga credential ng produksyon. Dahil dito, ang isang nakalantad na log file ay maaaring magpawalang-bisa sa iyong buong modelo ng access control.
2.2 Mga Token ng Sesyon at JWT
Kahit na hindi naka-log ang mga password, kadalasan ay naka-log ang mga token.
Halimbawa:
Isang wastong JWT o session cookie sa loob ng isang .log Maaaring paganahin ng file ang:
- Pag-hijack ng session
- Pagtaas ng pribilehiyo
- Paggalaw sa gilid sa mga panloob na sistema
Sa madaling salita, ginagawang isang authentication bypass vector ng mga token sa mga log ang debugging output.
2.3 CI/CD Artifacts
Ang mga troso ng gusali ay lalong mapanganib. Sa katunayan, CI/CD Kadalasang nagpi-print ang mga sistema ng mga environment variable sa mga hakbang ng pagbuo.
Madalas na natutuklasan ng mga umaatake ang:
Naglalaman ng mga linyang tulad ng:
If CI/CD Pampubliko ang mga artifact, saka pampubliko rin ang mga sikreto. Pinapabilis lang ng Google dork ang pagtuklas.
2.4 Datos ng Cloud at Imprastraktura
Ang mga nakalantad na talaan ay kadalasang nagpapakita ng:
- Mga access key ng AWS
- Mga string ng koneksyon sa imbakan ng Azure
- Mga URL ng panloob na serbisyo
- Mga kredensyal sa database
- Mga endpoint ng Redis
Kahit na ang mga kredensyal ay iikot sa ibang pagkakataon, ang umaatake ngayon ay nagtataglay ng:
- Pagmamapa ng imprastraktura
- Pagpapangalan ng mga kombensiyon
- Target na katalinuhan para sa mga pag-atake sa hinaharap
Samakatuwid, ang mga nakalantad na log ay nagbibigay ng parehong access at reconnaissance.
3. Paano Nagiging Pampubliko ang mga Log na Ito sa Unang Lugar
Ang mga log ay hindi basta-basta lumalabas sa Google. Nai-index ang mga ito dahil naaabot ito ng publiko.
3.1 Maling Pagkakaayos ng mga Web Server
Kabilang sa mga karaniwang pattern ang:
/logs/mga direktoryo na maa-access nang walang authentication- Pinagana ang listahan ng direktoryo
- Nginx o Apache na nagseserbisyo nang hilaw
.logfile
Kung ang isang log ay maaabot sa pamamagitan ng HTTP, ito ay maaaring i-index.
3.2 CI/CD Pagkakalantad ng Artipakto
Mga karaniwang pagkakamali:
- Pinagana ang mga pampublikong artifact sa Mga Pagkilos ng GitHub
- Mga log na na-upload sa mga bukas na S3 bucket
- Pipeline mga bakas na maa-access nang walang pagpapatotoo
A pipeline na nag-iimbak ng mga log sa isang pampublikong bucket ay epektibong naglalathala ng mga sikreto nito.
3.3 Debug Mode sa Produksyon
Maaaring mapanganib ang mga default ng framework:
Bukod pa rito, maaaring mag-print ang labis na pag-log ng kahilingan:
- Header
- Mga Token
- Mga kumpletong katawan ng kahilingan
Ang pag-debug logging sa produksyon ay nagbabago sa iyong aplikasyon tungo sa isang credential exporter.
3.4 Mga Log ng Docker at Lalagyan
Ang mga kapaligirang naka-container ay nagpapakilala ng mga bagong landas ng pagkakalantad:
- Mga log na naka-mount sa mga shared volume
- Mga Sidecar na nag-e-export ng mga log papunta sa mga hindi secure na endpoint
- Log dashboardmay pampublikong access
Kung ang mga log ng container ay makikita sa pamamagitan ng HTTP o open storage, mahahanap ang mga ito. Kalaunan, mai-index ang mga ito.
4. Makatotohanang Daloy ng Pag-atake: Mula sa Dork Patungo sa Paglabag
Ganito ang hitsura ng isang tipikal na kadena ng pag-atake:
Tumatakbo ang umaatake:
- Mga natuklasang nakalantad
.logfile - Mga Extrak:
- Token ng JWT
- Pangunahing header ng Awtorisasyon
- String ng koneksyon sa database
Mga pagtatangka sa pagpapatotoo laban sa:
- Mga endpoint ng API
- Mga panel ng admin
- Mga serbisyong panloob
Kung magtagumpay ang authentication, magagawa ng attacker na:
- Palakihin ang mga pribilehiyo
- Ilipat sa gilid
- daan CI/CD
- Ikompromiso ang supply chain
Ang nagsimula bilang isang query sa paghahanap ay nagiging:
- Pag-hijack ng session
- Panloob na pagpuno ng kredensyal
- Pipeline pagkuha sa kapangyarihan
- Pagkalason sa artifact
Lahat mula sa isang naka-index na log file sa publiko.
5. Bakit ang Pag-log nang "Sobra" ay Isang Problema sa AppSec
Hindi neutral ang pagtotroso. Sa halip, lumilikha ito ng imbakan ng pangalawang datos.
Kung magtatala ka ng sensitibong datos, epektibong makakagawa ka ng pangalawang kopya ng iyong mga sikreto.
Gayunpaman, ang mga log ay kadalasang hindi kasama sa pagmomodelo ng banta. Sa ilalim ng STRIDE, malinaw na tumutugma ito sa:
Impormasyon sa Pagbubunyag
Samakatuwid, Ligtas SDLC dapat ituring ng mga kasanayan ang mga log bilang:
- Mga artifact na may kaugnayan sa seguridad
- Mga sensitibong asset
- Mga bahagi ng imprastraktura na nangangailangan ng proteksyon
Kung hindi kumpleto ang mga log ng iyong threat model, hindi ito kumpleto.
6. Paano Pigilan ang Pagtagas ng Kredensyal sa mga Log File
6.1 Mga Sekreto ng Paghinto sa Pag-log
Huwag kailanman mag-log:
- Ang mga password
- Mga Token
- Mga API key
- Mga ID ng Session
- Mga header ng pahintulot
Kahit nasa debug mode pa.
Hangga't maaari, ipatupad ang awtomatikong pag-edit.
6.2 Nakabalangkas at Ligtas na Pag-log
Gumamit ng structured logging na may kasamang masking at filtering.
Halimbawa (Node.js):
Halimbawa (Python):
Ang pangunahing prinsipyo ay simple: ang mga sikreto ay hindi dapat makarating sa lababo ng troso.
6.3 Imbakan ng Lock Down Log
Dapat kasama sa mga kontrol sa seguridad ang:
- Huwag paganahin ang listahan ng direktoryo
- Ipagtanggol
/logs/mga landas na may pagpapatunay - Paghigpitan ang pag-access sa bucket
- Ilapat ang mga patakaran sa pagpapanatili
- I-encrypt ang mga log habang nakatigil
Ang mga log ay hindi dapat kailanman maging maaabot ng publiko sa pamamagitan ng HTTP.
6.4 CI/CD Guardrails
Hindi sapat ang mga manu-manong pagsusuri. Sa halip, ipatupad ang mga awtomatikong kontrol:
- Lihim na pag-scan ng mga log bago ang paglalathala ng artifact
- Nabigo ang mga build kung may mga natukoy na token
- Pigilan ang mga pag-upload ng artifact na naglalaman ng mga kredensyal
- Pagpapatunay ng hash para sa mga artifact
CI/CD dapat harangan ang exposure bago mangyari ang indexing.
7. Paano Pinipigilan ng Xygeni ang allintext:login filetype:log Mga Insidente
Hindi ang kalokohan ng Google ang problema. Ang problema ay ang exposure. Kaya naman, dapat munang iwasan bago ang pag-index.
7.1 Lihim na Pagtuklas sa mga Tala at Artipakto
Mga scan ng Xygeni:
- Mga log ng application
- CI/CD mga bakas ng trabaho
- Gumawa ng mga artifact
- Mga layer ng Docker
- Mga serialized na output
Kung ang mga kredensyal, token, o sensitibong halaga ay lumalabas sa .log mga file, agad na minamarkahan ng Xygeni ang mga ito.
7.2 CI/CD Guardrails Ang Pagkakalantad ng Block na Iyon
Sa halip na umasa sa mga manu-manong pagsusuri, Nagpapatupad ng seguridad ang Xygeni sa pipeline antas:
Ito:
- Nabibigo ang pagbuo kapag lumalabas ang mga sikreto sa mga log
- Hinaharangan ang publikasyon ng artifact
- Pinipigilan ang aksidenteng pagkakalantad sa publiko
- Pinipigilan ang mga hindi ligtas na pagsasama bago pa man makarating sa pangunahing
Kung ang isang trabahong CI ay nag-imprenta ng isang token, ang pipeline nabigo.
Walang pag-index.
Walang pagkakalantad.
Walang insidente.
7.3 Proteksyon ng Shift-Left Bago Ito Makita ng Google
Mahalaga ang timing.
Sa halip na tumugon sa:
Pinipigilan ng Xygeni ang isyu:
- At commit oras
- Sa panahon ng pull request pagpapatunay
- Sa panahon ng pipeline pagpapatupad
- Bago ang paglalathala ng artifact
Kung hindi kailanman magiging pampubliko ang log, hindi ito kailanman ii-index ng Google.
Pangwakas na Puntos: Kung Kaya Itong I-index ng Google, Ginawa Na Ito ng mga Attacker
Hindi naman nakakapinsala ang mga log. Sa katunayan, bihirang pansamantala ang mga ito. Bilang default, hindi ito pribado. Samakatuwid, ang bawat log file ay dapat ituring bilang isang asset na may kaugnayan sa seguridad, hindi lamang bilang debugging output.
Kung ang sensitibong datos ay umabot sa isang .log file at magiging accessible sa publiko, agad itong nagiging isang lugar na kalabanin. Bukod dito, kapag na-index na ng search engine, ang exposure ay lalala nang lampas sa iyong kontrol.
Ang solusyon ay hindi ang paghinto sa pag-log. Sa halip, ito ay ang responsableng pag-log at pagpapatupad ng mahigpit na mga kontrol sa pag-iimbak at pamamahagi. Sa madaling salita, ang seguridad ay dapat lumampas sa mismong aplikasyon at hanggang sa observability layer.
Sa halip:
- Itigil ang pag-log ng mga sikreto
- I-lock down ang imbakan ng log
- ipatupad pipeline guardrails
- Awtomatikong pagtuklas at pagpapatupad ng patakaran
sa huli, Ang pag-iwas ay tungkol sa tiyempo. Dahil kapag allintext:login uri ng file:log Kung ibabalik mo ang iyong domain, nagsimula na ang insidente.
