موتورهای جستجو برای ایندکس کردن محتوا ساخته شدهاند. با این حال، مهاجمان از آنها برای ایندکس کردن اشتباهات شما استفاده میکنند. allintext:login نوع فایل: لاگ ممکن است بیضرر به نظر برسد. در واقع، این یکی از سادهترین راهها برای کشف فایلهای لاگِ در معرض خطر است که حاوی جریانهای احراز هویت، اعتبارنامهها، توکنها و دادههای زیرساخت داخلی هستند.
اگر گوگل میتواند آن لاگها را ببیند، مهاجمان نیز میتوانند. پس از ایندکس شدن، افشای اطلاعات اجتنابناپذیر میشود. علاوه بر این، وقتی اطلاعات احراز هویت در یک فایل قابل دسترسی عمومی ظاهر میشوند، نقض امنیتی از قبل در حال انجام است.
۱. چرا allintext:login filetype:log خطرناکتر از آن چیزی است که به نظر میرسد
یک «گوگل دورک» (Google dork) یک عبارت جستجو است که از عملگرهای پیشرفته برای یافتن محتوای حساس یا دارای پیکربندی نادرست که توسط موتورهای جستجو ایندکس شده است، استفاده میکند. این کار از گوگل سوءاستفاده نمیکند. در عوض، از میزان دیده شدن شما سوءاستفاده میکند.
این پرسوجو دو عملگر را با هم ترکیب میکند:
- allintext: صفحاتی را برمیگرداند که تمام اصطلاحات در متن بدنه آنها ظاهر شدهاند
- نوع فایل: لاگ نتایج را محدود میکند به
.logفایل ها
از این رو:
یعنی: «فایلهای لاگی که حاوی این کلمه هستند را به من نشان بده login"
در نگاه اول، این موضوع بیاهمیت به نظر میرسد. با این حال، در عمل، اغلب نتیجهی زیر را برمیگرداند:
- لاگهای وب سرور که در معرض دید عموم قرار دارند
- CI/CD لاگها به عنوان مصنوعات آپلود شدهاند
- اشکالزدایی سیاههها به طور تصادفی commitبه مخازن منتقل شد
- گزارشهای برنامه با اعتبارنامههای متنی ساده
این یک اشکال موتور جستجو نیست. در عوض، یک ... است. آسیبپذیری افشای دادهها ناشی از پیکربندی اشتباه. گوگل به سادگی آنچه را که به صورت عمومی قابل دسترسی بود، فهرست بندی کرد.
۲. مهاجمان واقعاً چه چیزی را در فایلهای لاگ افشا شده پیدا میکنند؟
وقتی مهاجمان فرار میکنند allintext:login نوع فایل: لاگآنها به صورت تصادفی در حال مرور نیستند. آنها به دنبال ردپای احراز هویت هستند.
۲.۱ اعتبارنامههای متن ساده
لاگها اغلب شامل ورودیهایی مانند موارد زیر هستند:
or
یا حتی اعتبارنامههای SMTP:
ثبت دادههای احراز هویت یکی از سریعترین راهها برای نشت اطلاعات احراز هویت در محیط عملیاتی است. در نتیجه، یک فایل لاگ افشا شده میتواند کل مدل کنترل دسترسی شما را بیاعتبار کند.
۲.۲ توکنهای نشست و JWTها
حتی وقتی رمزهای عبور ثبت نمیشوند، توکنها اغلب ثبت میشوند.
مثلا:
یک JWT یا کوکی جلسه معتبر درون یک .log فایل میتواند فعال کند:
- هواپیماربایی جلسه
- افزایش امتیاز
- حرکت جانبی در سیستمهای داخلی
به عبارت دیگر، توکنهای موجود در لاگها، خروجی اشکالزدایی را به یک بردار دور زدن احراز هویت تبدیل میکنند.
2.3 CI/CD مصنوعات
کندههای ساختمانی به طور ویژه خطرناک هستند. در واقع، CI/CD سیستمها اغلب متغیرهای محیطی را در طول مراحل ساخت چاپ میکنند.
مهاجمان اغلب موارد زیر را کشف میکنند:
شامل خطوطی مانند:
If CI/CD آثار باستانی عمومی هستند، پس رازها هم عمومی هستند. این احمق گوگل به سادگی کشف را سرعت میبخشد.
۲.۴ دادههای ابری و زیرساختی
لاگهای افشا شده اغلب موارد زیر را نشان میدهند:
- کلیدهای دسترسی AWS
- رشتههای اتصال ذخیرهسازی Azure
- آدرسهای اینترنتی خدمات داخلی
- اعتبارنامههای پایگاه داده
- نقاط پایانی Redis
حتی اگر اعتبارنامهها بعداً تغییر داده شوند، مهاجم اکنون موارد زیر را در اختیار دارد:
- نقشه برداری زیرساخت
- نامگذاری کنوانسیون
- هدف قرار دادن اطلاعات برای حملات آینده
بنابراین، لاگهای افشا شده هم دسترسی و هم شناسایی را فراهم میکنند.
۳. چگونه این گزارشها در وهله اول عمومی میشوند
لاگها به طور جادویی در گوگل ظاهر نمیشوند. آنها به این دلیل ایندکس میشوند که به صورت عمومی قابل دسترسی بودهاند.
۳.۱ سرورهای وب با پیکربندی نادرست
الگوهای رایج عبارتند از:
/logs/دایرکتوریها بدون احراز هویت قابل دسترسی هستند- فهرست دایرکتوری فعال شد
- Nginx یا Apache که به صورت خام سرو میشوند
.logفایل ها
اگر یک گزارش از طریق HTTP قابل دسترسی باشد، قابل فهرستبندی است.
3.2 CI/CD قرار گرفتن در معرض مصنوعات
اشتباهات معمولی:
- مصنوعات عمومی فعال شده در اقدامات GitHub
- لاگها برای باز کردن سطلهای S3 آپلود شدند
- Pipeline ردیابیها بدون احراز هویت قابل دسترسی هستند
A pipeline که لاگها را در یک سطل عمومی ذخیره میکند، عملاً اسرار خود را منتشر میکند.
۳.۳ حالت اشکالزدایی در محیط عملیاتی
پیشفرضهای چارچوب میتوانند خطرناک باشند:
علاوه بر این، ثبت درخواستهای بیش از حد ممکن است موارد زیر را چاپ کند:
- سرآیندهای
- نشانه
- نهادهای درخواست کامل
ثبت اشکالزدایی در محیط عملیاتی، برنامه شما را به یک صادرکننده اعتبارنامه تبدیل میکند.
۳.۴ گزارشهای داکر و کانتینر
محیطهای کانتینری مسیرهای جدیدی برای مواجهه معرفی میکنند:
- لاگهای نصبشده در والیومهای مشترک
- سایدکارها لاگها را به نقاط انتهایی ناامن صادر میکنند
- ورود dashboardبا دسترسی عمومی
اگر لاگهای کانتینر از طریق HTTP یا فضای ذخیرهسازی باز در معرض دید قرار گیرند، قابل جستجو هستند. در نهایت، ایندکس میشوند.
۴. جریان حمله واقعگرایانه: از حملهی تهاجمی تا حملهی تهاجمی
یک زنجیره حمله معمولی به این شکل است:
مهاجم میدود:
- یافتههای در معرض
.logپرونده - عصاره:
- توکن JWT
- سربرگ مجوز پایه
- رشته اتصال پایگاه داده
تلاش برای احراز هویت در برابر:
- نقاط پایانی API
- پنلهای مدیریتی
- خدمات داخلی
اگر احراز هویت موفقیتآمیز باشد، مهاجم میتواند:
- افزایش امتیازات
- حرکت جانبی
- دسترسی CI/CD
- به خطر انداختن زنجیره تامین
چیزی که به عنوان یک عبارت جستجو شروع شد، به این صورت میشود:
- هواپیماربایی جلسه
- پر کردن اعتبارنامه داخلی
- Pipeline تصاحب
- مسمومیت با مصنوعات
همه از یک فایل لاگ با نمایه عمومی.
۵. چرا ثبت «بیش از حد» اطلاعات یک مشکل امنیتی در AppSec است؟
قطع درختان خنثی نیست. در عوض، باعث ایجاد ... میشود. انبار داده ثانویه.
اگر دادههای حساس را ثبت کنید، عملاً یک نسخه دوم از اسرار خود ایجاد میکنید.
با این حال، گزارشها اغلب از مدلسازی تهدید حذف میشوند. تحت STRIDE، این به وضوح به موارد زیر نگاشت میشود:
افشای اطلاعات
بنابراین، ایمن SDLC شیوههای کاری باید با لاگها به عنوان موارد زیر رفتار کنند:
- مصنوعات مرتبط با امنیت
- داراییهای حساس
- اجزای زیرساختی که نیاز به حفاظت دارند
اگر مدل تهدید شما لاگها را نادیده میگیرد، ناقص است.
۶. نحوه جلوگیری از نشت اطلاعات کاربری در فایلهای لاگ
۶.۱ توقف ثبت اسرار
هرگز وارد سیستم نشوید:
- کلمه عبور
- نشانه
- کلیدهای API
- شناسه های جلسه
- سربرگهای مجوز
حتی در حالت اشکالزدایی.
هر زمان که امکان دارد، ویرایش خودکار را پیادهسازی کنید.
۶.۲ ثبت وقایع ساختاریافته و ایمن
از گزارشگیری ساختاریافته با قابلیت ماسکگذاری و فیلترینگ استفاده کنید.
مثال (Node.js):
مثال (پایتون):
اصل کلیدی ساده است: اسرار هرگز نباید به سینک کنده چوب برسند.
۶.۳ قفل کردن محل ذخیرهسازی لاگها
کنترلهای امنیتی باید شامل موارد زیر باشند:
- غیرفعال کردن فهرست دایرکتوری
- حفاظت از
/logs/مسیرهای دارای احراز هویت - محدود کردن دسترسی به سطل
- اعمال سیاستهای حفظ حریم خصوصی
- رمزگذاری لاگها در حالت استراحت
گزارشها هرگز نباید از طریق HTTP به صورت عمومی قابل دسترسی باشند.
6.4 CI/CD Guardrails
بررسیهای دستی کافی نیستند. در عوض، کنترلهای خودکار را پیادهسازی کنید:
- اسکن مخفیانه لاگها قبل از انتشار مصنوعات
- در صورت شناسایی توکنها، ساخت با شکست مواجه میشود
- جلوگیری از آپلود مصنوعات حاوی اطلاعات احراز هویت
- اعتبارسنجی هش برای مصنوعات
CI/CD باید قبل از اینکه ایندکس شدن اتفاق بیفتد، جلوی نمایش را بگیرد.
۷. چگونه Xygeni از allintext جلوگیری میکند:login نوع فایل: گزارش رویدادها
مشکل، آن احمق گوگل نیست. مشکل، افشا شدن است. بنابراین، قبل از ایندکس شدن، باید پیشگیری انجام شود.
۷.۱ تشخیص مخفی در لاگها و مصنوعات
اسکنهای Xygeni:
- لاگ های برنامه
- CI/CD ردپای شغلی
- ساخت مصنوعات
- لایههای داکر
- خروجیهای سریالی
اگر اعتبارنامهها، توکنها یا مقادیر حساس در ... ظاهر شوند .log فایلها، Xygeni بلافاصله آنها را علامتگذاری میکند.
7.2 CI/CD Guardrails که قرار گرفتن در معرض را مسدود میکند
به جای تکیه بر بررسیهای دستی، شیگنی امنیت را در ... برقرار میکند. pipeline سطح:
این:
- وقتی اسرار در سیاههها ظاهر می شوند، ساخت ها با شکست مواجه می شوند
- انتشار مصنوعات را مسدود میکند
- از قرار گرفتن تصادفی در معرض دید عموم جلوگیری میکند
- ادغامهای ناامن را قبل از رسیدن به مسیر اصلی متوقف میکند.
اگر یک کار CI یک توکن چاپ کند، pipeline شکست می خورد
بدون فهرست بندی.
بدون قرار گرفتن در معرض.
هیچ حادثهای رخ نداده است.
۷.۳ محافظت با Shift-left قبل از اینکه گوگل آن را ببیند
زمانبندی اهمیت دارد.
به جای واکنش نشان دادن به:
Xygeni مشکل را متوقف میکند:
- At commit زمان
- در طی pull request اعتبار سنجی
- در طی pipeline اعدام
- قبل از انتشار اثر
اگر گزارش هرگز عمومی نشود، گوگل هرگز آن را ایندکس نمیکند.
نکتهی پایانی: اگر گوگل میتواند چیزی را ایندکس کند، مهاجمان قبلاً این کار را کردهاند
لاگها بیضرر نیستند. در واقع، آنها به ندرت موقتی هستند. به طور پیشفرض، آنها خصوصی نیستند. بنابراین، هر فایل لاگ باید به عنوان یک دارایی مرتبط با امنیت در نظر گرفته شود، نه فقط خروجی اشکالزدایی.
اگر دادههای حساس به ... برسند .log بایگانی میشود و به صورت عمومی قابل دسترسی میشود، بلافاصله به یک سطح حمله تبدیل میشود. علاوه بر این، پس از ایندکس شدن توسط موتور جستجو، میزان نمایش آن فراتر از کنترل شما خواهد بود.
راه حل، متوقف کردن ثبت وقایع نیست. بلکه، ثبت مسئولانه وقایع و اعمال کنترلهای سختگیرانه در مورد ذخیرهسازی و توزیع است. به عبارت دیگر، امنیت باید فراتر از خود برنامه و به لایه مشاهدهپذیری گسترش یابد.
بجای:
- ثبت اطلاعات محرمانه را متوقف کنید
- قفل کردن فضای ذخیرهسازی لاگ
- اجرای pipeline guardrails
- خودکارسازی تشخیص و اجرای سیاستها
در نهایت, پیشگیری به زمانبندی بستگی دارد. زیرا یک بار allintext:login نوع فایل: لاگ دامنه شما را برمیگرداند، حادثه از قبل آغاز شده است.
