საძიებო სისტემები შექმნილია კონტენტის ინდექსირებისთვის. თუმცა, თავდამსხმელები მათ თქვენი შეცდომების ინდექსირებისთვის იყენებენ. მოთხოვნა allintext:login ფაილის ტიპი: ჟურნალი შესაძლოა, უვნებლად გამოიყურებოდეს. სინამდვილეში, ეს ერთ-ერთი უმარტივესი გზაა ავთენტიფიკაციის ნაკადების, ავტორიზაციის მონაცემების, ტოკენებისა და შიდა ინფრასტრუქტურის მონაცემების შემცველი ღია ლოგ ფაილების აღმოსაჩენად.
თუ Google-ს შეუძლია ამ ჟურნალების ნახვა, თავდამსხმელებსაც შეუძლიათ. ინდექსირების შემდეგ, ზემოქმედება გარდაუვალი ხდება. უფრო მეტიც, როდესაც ავტორიზაციის მონაცემები საჯაროდ ხელმისაწვდომ ფაილში ჩნდება, დარღვევა უკვე მიმდინარეობს.
1. რატომ allintext:login filetype:log უფრო საშიშია, ვიდრე ერთი შეხედვით ჩანს
Google dork არის საძიებო მოთხოვნა, რომელიც იყენებს გაფართოებულ ოპერატორებს საძიებო სისტემების მიერ ინდექსირებული მგრძნობიარე ან არასწორად კონფიგურირებული კონტენტის მოსაძებნად. ის არ იყენებს Google-ს. ამის ნაცვლად, ის იყენებს თქვენს ზემოქმედებას.
ეს მოთხოვნა აერთიანებს ორ ოპერატორს:
- allintext: აბრუნებს გვერდებს, სადაც ყველა ტერმინი ტექსტშია მოცემული
- ფაილის ტიპი: ჟურნალი ზღუდავს შედეგებს
.logფაილი
ამიტომ:
ნიშნავს: „მაჩვენე სიტყვაში შემავალი ჟურნალის ფაილები login".
ერთი შეხედვით, ეს ტრივიალურად გამოიყურება. თუმცა, პრაქტიკაში, ხშირად ასე ბრუნდება:
- საჯაროდ გამოქვეყნებული ვებ სერვერის ჟურნალები
- CI/CD არტეფაქტებად ატვირთული ჟურნალები
- გამართვის ჟურნალები შემთხვევით ხდება commitგადატანილია საცავებში
- აპლიკაციის ჟურნალები უბრალო ტექსტური ავტორიზაციის მონაცემებით
ეს არ არის საძიებო სისტემის შეცდომა. პირიქით, ეს არის მონაცემთა ზემოქმედების დაუცველობა არასწორი კონფიგურაციით გამოწვეული. Google-მა უბრალოდ ინდექსი მოახდინა საჯაროდ ხელმისაწვდომი ინფორმაციისთვის.
2. რას პოულობენ თავდამსხმელები სინამდვილეში გამოვლენილ ჟურნალის ფაილებში
როდესაც თავდამსხმელები გარბიან allintext:login ფაილის ტიპი: ჟურნალიისინი შემთხვევით არ ათვალიერებენ. ისინი ეძებენ ავტორიზაციის კვალს.
2.1 უბრალო ტექსტის ავტორიზაციის მონაცემები
ჟურნალები ხშირად შეიცავს ისეთ ჩანაწერებს, როგორიცაა:
or
ან თუნდაც SMTP სერთიფიკატები:
ავტორიზაციის დატვირთვის ჟურნალირება წარმოების მონაცემების გაჟონვის ერთ-ერთი ყველაზე სწრაფი გზაა. შესაბამისად, ერთი ღია ჟურნალის ფაილი შეიძლება მთლიანად გააუქმოს თქვენი წვდომის კონტროლის მოდელი.
2.2 სესიის ტოკენები და JWT-ები
მაშინაც კი, როდესაც პაროლები არ არის შეყვანილი ანგარიშზე, ტოკენები ხშირად შეყვანილია ანგარიშზე.
მაგალითად:
მოქმედი JWT ან სესიის ქუქი-ფაილი, რომელიც შედის .log ფაილს შეუძლია ჩართოს:
- სესიის გატაცება
- პრივილეგიის ესკალაცია
- გვერდითი მოძრაობა შიდა სისტემებში
სხვა სიტყვებით რომ ვთქვათ, ლოგებში არსებული ტოკენები გამართვის შედეგს ავტორიზაციის გვერდის ავლით ვექტორად გარდაქმნიან.
2.3 CI/CD ნივთები
მშენებლობის მორები განსაკუთრებით საშიშია. სინამდვილეში, CI/CD სისტემები ხშირად ბეჭდავენ გარემოს ცვლადებს შექმნის ეტაპებზე.
თავდამსხმელები ხშირად აღმოაჩენენ:
შეიცავს ისეთ ხაზებს, როგორიცაა:
If CI/CD არტეფაქტები საჯაროა, მაშინ საიდუმლოებები საჯაროა. Google-ის იდიოტი უბრალოდ აჩქარებს აღმოჩენას.
2.4 ღრუბლოვანი და ინფრასტრუქტურული მონაცემები
გამოვლენილი ჟურნალები ხშირად ავლენენ:
- AWS წვდომის გასაღებები
- Azure-ის შენახვის კავშირის სტრიქონები
- შიდა სერვისის URL-ები
- მონაცემთა ბაზის ავტორიზაციის მონაცემები
- Redis-ის საბოლოო წერტილები
მაშინაც კი, თუ მოგვიანებით ავტორიზაციის მონაცემები შეიცვლება, თავდამსხმელს ახლა აქვს:
- ინფრასტრუქტურის რუკების შედგენა
- სახელდების კონვენციები
- სამიზნე ინტელექტი მომავალი თავდასხმებისთვის
ამიტომ, გამოვლენილი მორები უზრუნველყოფს როგორც წვდომას, ასევე დაზვერვას.
3. როგორ გახდა ეს ჟურნალები საჯარო თავიდანვე
ჟურნალები Google-ში ჯადოსნურად არ ჩნდება. ისინი ინდექსირდება, რადგან ისინი საჯაროდ ხელმისაწვდომი იყო.
3.1 არასწორად კონფიგურირებული ვებ სერვერები
საერთო ნიმუშები მოიცავს:
/logs/დირექტორიები, რომლებიც ხელმისაწვდომია ავტორიზაციის გარეშე,- დირექტორიის ჩამონათვალი ჩართულია
- Nginx ან Apache ემსახურება ნედლ ვერსიას
.logფაილი
თუ ჟურნალი HTTP-ის საშუალებით არის ხელმისაწვდომი, ის ინდექსირებადია.
3.2 CI/CD არტეფაქტის ექსპოზიცია
ტიპიური შეცდომები:
- საჯარო არტეფაქტები ჩართულია GitHub მოქმედებები
- S3 ბაკეტების გასახსნელად ატვირთული ჟურნალები
- Pipeline კვალი ხელმისაწვდომია ავტორიზაციის გარეშე
A pipeline რომელიც მორებს საჯარო ბაკეტში ინახავს, ეფექტურად აქვეყნებს თავის საიდუმლოებებს.
3.3 გამართვის რეჟიმი წარმოებაში
ჩარჩოს ნაგულისხმევი პარამეტრები შეიძლება საშიში იყოს:
გარდა ამისა, ზედმეტად დიდი რაოდენობით მოთხოვნის ჟურნალირებამ შეიძლება დაბეჭდოს:
- ჰედერისა
- სიმბოლოს
- სრული მოთხოვნის ძირითადი ნაწილები
წარმოებაში გამართვის ჟურნალირება თქვენს აპლიკაციას ავტორიზაციის ექსპორტიორად გარდაქმნის.
3.4 დოკერისა და კონტეინერის ჟურნალები
კონტეინერიზებული გარემო ახალ ექსპოზიციის გზებს შემოიტანს:
- საერთო ტომებში დამონტაჟებული ჟურნალები
- გვერდითი ეტლები, რომლებიც ახორციელებენ მორების ექსპორტს დაუცველ საბოლოო წერტილებში
- შესვლა dashboardსაჯარო წვდომით
თუ კონტეინერის ჟურნალები HTTP-ის ან ღია საცავის საშუალებით გამოვლინდება, მათი მოძიება შესაძლებელი იქნება. საბოლოოდ, ისინი ინდექსირდება.
4. რეალისტური შეტევის ნაკადი: დორკიდან ბრეჩამდე
ტიპური შეტევის ჯაჭვი ასე გამოიყურება:
თავდამსხმელი გარბის:
- აღმოჩენები გამოფენილია
.logფაილი - ექსტრაქტები:
- JWT ტოკენი
- ძირითადი ავტორიზაციის სათაური
- მონაცემთა ბაზის კავშირის სტრიქონი
ავტორიზაციის მცდელობა:
- API-ის საბოლოო წერტილები
- ადმინისტრაციული პანელები
- შიდა სერვისები
თუ ავტორიზაცია წარმატებით განხორციელდება, თავდამსხმელს შეუძლია:
- პრივილეგიების ესკალაცია
- გვერდითი მოძრაობა
- ხელმისაწვდომობა CI/CD
- მიწოდების ჯაჭვის კომპრომისზე წასვლა
ის, რაც საძიებო მოთხოვნის სახით დაიწყო, შემდეგნაირად გადაიქცა:
- სესიის გატაცება
- შიდა სერთიფიკატების შევსება
- Pipeline takeover
- არტეფაქტებით მოწამვლა
ყველაფერი საჯაროდ ინდექსირებული ჟურნალის ფაილიდან.
5. რატომ არის „ზედმეტად ბევრი“ ჟურნალირება AppSec-ის პრობლემა
ხე-ტყის ჭრა ნეიტრალური არ არის. სამაგიეროდ, ის ქმნის მეორადი მონაცემთა საცავი.
თუ კონფიდენციალურ მონაცემებს შეინახავთ, ფაქტობრივად, თქვენი საიდუმლოებების მეორე ასლს ქმნით.
თუმცა, ლოგები ხშირად გამორიცხულია საფრთხის მოდელირებიდან. STRIDE-ის შემთხვევაში, ეს აშკარად შეესაბამება:
ინფორმაციის გამჟღავნება
ამიტომ, უსაფრთხო SDLC პრაქტიკამ ჟურნალები უნდა განიხილოს, როგორც:
- უსაფრთხოებასთან დაკავშირებული არტეფაქტები
- მგრძნობიარე აქტივები
- ინფრასტრუქტურის კომპონენტები, რომლებიც დაცვას საჭიროებენ
თუ თქვენი საფრთხის მოდელი უგულებელყოფს ლოგებს, ის არასრულია.
6. როგორ ავიცილოთ თავიდან ავტორიზაციის მონაცემების გაჟონვა ჟურნალის ფაილებში
6.1 ჟურნალირების შეჩერების საიდუმლოებები
არასდროს არ შეხვიდეთ ჟურნალში:
- პაროლები
- სიმბოლოს
- API გასაღებები
- სესიის ID
- ავტორიზაციის სათაურები
გამართვის რეჟიმშიც კი.
როდესაც ეს შესაძლებელია, დანერგეთ ავტომატური რედაქტირება.
6.2 სტრუქტურირებული და უსაფრთხო ჟურნალირება
გამოიყენეთ სტრუქტურირებული ჟურნალირება ნიღბის გამოყენებით და ფილტრაციით.
მაგალითი (Node.js):
მაგალითი (პითონი):
მთავარი პრინციპი მარტივია: საიდუმლოებები არასდროს არ უნდა მოხვდეს მორის ნიჟარაში.
6.3 ჟურნალის შენახვის დაბლოკვა
უსაფრთხოების კონტროლი უნდა მოიცავდეს:
- დირექტორიის სიის გამორთვა
- დაცვა
/logs/ავთენტიფიკაციის მქონე გზები - შეზღუდეთ კონტეინერზე წვდომა
- შენარჩუნების პოლიტიკის გამოყენება
- ჟურნალების დაშიფვრა უმოქმედობის დროს
ლოგები არასდროს არ უნდა იყოს საჯაროდ ხელმისაწვდომი HTTP-ის საშუალებით.
6.4 CI/CD Guardrails
ხელით განხილვები არასაკმარისია. ამის ნაცვლად, დანერგეთ ავტომატური კონტროლი:
- არტეფაქტის გამოქვეყნებამდე ჟურნალების ფარული სკანირება
- წარუმატებელი აწყობები, თუ ტოკენები აღმოჩენილია
- ავტორიზაციის მონაცემების შემცველი არტეფაქტების ატვირთვის თავიდან აცილება
- არტეფაქტების ჰეშის ვალიდაცია
CI/CD ინდექსირების დაწყებამდე ექსპოზიცია უნდა დაბლოკოს.
7. როგორ აჩერებს Xygeni ყველა ტექსტის გამოყენებას:login ფაილის ტიპი: ჟურნალი ინციდენტები
პრობლემა Google-ის იდიოტი არ არის. პრობლემა ექსპოზიციაშია. ამიტომ, ინდექსირებამდე პრევენცია უნდა მოხდეს.
7.1 საიდუმლოების აღმოჩენა ჟურნალებსა და არტეფაქტებში
Xygeni სკანირება:
- აპლიკაციის ჟურნალები
- CI/CD სამუშაო კვალი
- არტეფაქტების შექმნა
- დოკერის ფენები
- სერიალიზებული გამომავალი სიგნალები
თუ ავტორიზაციის მონაცემები, ტოკენები ან მგრძნობიარე მნიშვნელობები გამოჩნდება .log ფაილებს, Xygeni მათ მყისიერად აღნიშნავს.
7.2 CI/CD Guardrails ეს ბლოკავს ექსპოზიციას
ხელით მიმოხილვებზე დაყრდნობის ნაცვლად, Xygeni უზრუნველყოფს უსაფრთხოებას pipeline დონე:
ეს:
- წარუმატებელი აშენებები, როდესაც საიდუმლოებები ჩნდება ჟურნალებში
- ბლოკავს არტეფაქტების გამოქვეყნებას
- ხელს უშლის შემთხვევით საზოგადოებრივ კონტაქტს
- მთავარ ბმულამდე მიღწევამდე აჩერებს არაუსაფრთხო შერწყმებს
თუ CI დავალება ბეჭდავს ტოკენს, pipeline ვერ
ინდექსირება არ არის.
არანაირი ექსპოზიცია.
არანაირი ინციდენტი.
7.3 Shift-მარცხნივ კლავიშის დაცვა Google-ის მიერ მის დანახვამდე
დროის საკითხი მნიშვნელოვანია.
რეაგირების ნაცვლად:
Xygeni პრობლემას წყვეტს:
- At commit დრო
- დროს pull request დადასტურება
- დროს pipeline შესრულების
- არტეფაქტის გამოქვეყნებამდე
თუ ჟურნალი არასდროს გახდება საჯარო, Google არასოდეს დაინდექსირებს მას.
დასკვნითი დასკვნა: თუ Google-ს შეუძლია მისი ინდექსირება, თავდამსხმელებმა უკვე გააკეთეს ეს
ჟურნალები უვნებელი არ არის. სინამდვილეში, ისინი იშვიათად არის დროებითი. ნაგულისხმევად, ისინი არ არის კონფიდენციალური. ამიტომ, ყველა ჟურნალის ფაილი უნდა განიხილებოდეს, როგორც უსაფრთხოებასთან დაკავშირებული აქტივი და არა მხოლოდ გამართვის გამომავალი.
თუ მგრძნობიარე მონაცემები მიაღწევს .log ფაილი და ხდება საჯაროდ ხელმისაწვდომი, ის მაშინვე თავდასხმის ზედაპირად იქცევა. უფრო მეტიც, საძიებო სისტემის მიერ ინდექსირების შემდეგ, ექსპოზიცია თქვენს კონტროლს სცილდება.
გამოსავალი არ არის ჟურნალირების შეჩერება. პირიქით, საქმე ეხება პასუხისმგებლობით ჟურნალირებას და შენახვისა და გავრცელების მკაცრი კონტროლის დაწესებას. სხვა სიტყვებით რომ ვთქვათ, უსაფრთხოება უნდა გასცდეს თავად აპლიკაციას და დაკვირვებადობის ფენას მოიცავდეს.
ამის ნაცვლად:
- შეწყვიტეთ საიდუმლოებების ჩანაწერების შეტანა
- ჟურნალის საცავის ჩაკეტვა
- აღსრულება pipeline guardrails
- ავტომატიზირება გაუკეთეთ ამოცნობას და პოლიტიკის აღსრულებას
საბოლოო ჯამში, პრევენცია დროის საკითხია. რადგან ერთხელ allintext:login ფაილის ტიპი: ჟურნალი დააბრუნებს თქვენს დომენს, ინციდენტი უკვე დაწყებულია.
