افشای اسرار: یک قدم تا دیsaster

دادن کلید خانه به مجرمان قطعاً ایده خوبی نیست. اما این اتفاقی است که اغلب در اکثر سازمان‌هایی که نرم‌افزارهای مدرن توسعه می‌دهند، رخ می‌دهد.

در این اولین پست در مورد نشت اطلاعات محرمانه، بررسی خواهیم کرد که چرا این اتفاق اینقدر زیاد می‌افتد، عواقب آن چیست و چه اقداماتی باید برای جلوگیری یا کاهش مشکل و مدیریت حوادث نشت اطلاعات محرمانه انجام شود.

خدای من! کلیدهای دسترسی ابری‌ام را در یک مخزن عمومی قرار دادم

اسرار کدگذاری شده در کد منبع یا فایل‌های پیکربندی در ابزارهای DevOps ممکن است به دست افراد نادرست بیفتد. اگر راز این است commitاگر در یک مخزن منابع عمومی قرار دارید، مطمئناً محکوم به فنا هستید. اما حتی مخازن خصوصی نیز ایمن نیستند، زیرا اسرار از طریق فایل‌های باینری برنامه‌ها، گزارش‌ها یا کد منبع دزدیده شده نیز فاش می‌شوند.

در نگاه به گذشته، نگران‌کننده است چقدر پیش آمده که یک سهل‌انگاری ساده منجر به نقض امنیتی جدی شده است. فقط گوگل کنید "نشت کلید AWS"،"نشت توکن دسترسی به گیت‌هاب«و غیره. این مثال‌ها را به عنوان توصیه‌های پنهان برای این یا آن فروشنده در نظر نگیرید. از مثال‌های خودتان استفاده کنید!»

برای مثال، (بدنام) حمله کدکوف حمله آوریل ۲۰۲۱ امکان‌پذیر بود زیرا تصویر داکر Codecov حاوی اطلاعات احراز هویت git بود که به یک مهاجم اجازه می‌داد به مخازن خصوصی git Codecov دسترسی پیدا کند و یک خط واحد در اسکریپت آپلودکننده bash Codecov برای جمع‌آوری متغیرهای محیطی و URLهای مخزن git اضافه کند.

به یاد داشته باشید که بخشی از پاداش حملات، اسرار دسترسی به سیستم‌های اضافی است و بسیاری از حملات سرمایه‌گذاری زیادی روی اعتبارنامه‌ها، کلیدهای رمزنگاری و استخراج توکن‌ها انجام می‌دهند. 

مشکل این است که رازهای رمزگذاری‌شده، امری عادی هستنددر مارس ۲۰۲۲، Lapsus$ APT ۱۸۹ گیگابایت لو رفت از کد منبع سامسونگ و سایر فایل‌های حساس. تجزیه و تحلیل نشان داد که حاوی برخی از موارد است ۶۶۰۰ راز کدگذاری‌شده۹۰٪ برای سیستم‌های داخلی، اما ۱۰٪ برای سرویس‌ها و ابزارهای خارجی مانند GitHub، AWS یا Google. این اسرار شامل کلیدهای AWS / Twilio / Google API، رشته‌های اتصال پایگاه داده و سایر اطلاعات حساس بود. این آخرین فناوری در اکثر پایگاه‌های کد است.

افشای اسرار، ساده‌ترین راه برای حملات زنجیره تأمین است

وابستگی‌های بسته در حال حاضر رایج‌ترین هدف حملات زنجیره تأمین هستند، هرچند که منحصر به فرد نیستند. افراد بد می‌توانند بسته جدیدی ایجاد کنند که در نهایت در نرم‌افزار قربانیان نصب شود (با استفاده از جعلی و سایر تکنیک‌ها)، اما معمولاً آنها سعی می‌کنند یک بسته موجود را با افزودن تغییراتی به کد منبع در مخازن نرم‌افزار آلوده کنند (SCM) مانند GitHub، GitLab یا BitBucket، یا با اضافه کردن نسخه‌های مخرب به رجیستری‌های عمومی مانند NPM، PyPI، RubyGems، Maven Central.

اما تزریق کد مخرب یا یک وابستگی مخرب پنهان شده در یک گراف وابستگی پیچیده نیازمند ... login اطلاعات احراز هویت مانند نام کاربری/رمز عبور، توکن‌ها یا کلیدهای دسترسی (بیایید آنها را "کلیدبه اختصار «»، به ترتیب برای مخزن منبع هدف یا رجیستری عمومی. 

افراد شرور گاهی اوقات کلیدها را از طریق ... به دست می‌آورند. مهندسی اجتماعی.  حمله به event-stream بسته محبوب NPM مثال خوبی ارائه می‌دهد. اما جستجوی اطلاعات نشت‌شده login استفاده از اعتبارنامه‌ها یا کلیدهای دسترسی، رایج‌ترین تکنیک حمله برای حملات زنجیره تأمین نرم‌افزار است.

مخازن منبع و ثبت بسته‌ها دو سیستم ضروری در ساخت نرم‌افزار هستند. pipelineاما ابزارهای زیادی در DevOps وجود دارد: CI/CD سیستم‌ها، ابزارهایی برای اجرای تست‌ها، پیکربندی و اتوماسیون تأمین، یا استقرار و انتشار. همه آنها می‌توانند برای تزریق کد مخرب در نرم‌افزار مورد سوءاستفاده قرار گیرند. افشای کلیدهای معتبر برای این ابزارها مستقیماً منجر به بدبختی و عذاب می‌شود. تصور کنید که کلیدهای دسترسی ریشه با کنترل کامل بر منابع ابر عمومی شما فاش شوند...

توصیه‌های معمول

ما اینجا چیز جدیدی نمی‌گوییم، همه شما این را می‌دانید. اما اقدام کنید! به یاد داشته باشید که ربات‌ها مرتباً همه اطلاعات عمومی را اسکن می‌کنند. SCM مخازن. چند توصیه، بدون ترتیب خاص.

• اگر مسئولیت مدیریت امنیت فناوری اطلاعات را بر عهده دارید، تعریف کنید که چگونه باید با اسرار برخورد شود در سیاست امنیتی. اما سیاست‌ها فقط به اندازه اجرا خوب هستند: اطمینان حاصل کنید که یک دستورالعمل مدیریت اسرار در سازمان شما اجرا می‌شود - نه تنها شامل تیم‌های DevOps شما، بلکه شامل تأمین‌کنندگان نرم‌افزار شما نیز می‌شود، و اینکه طرح واکنش به حوادث سازمان شما شامل تمهیداتی برای حوادث نشت اسرار است.
• اجرا و اجرا شود احراز هویت چند عامل (MFA، 2FA یا هر مخفف دیگری). و بدون هیچ کاهشی در امنیت: یک کلید امنیتی USB ارزش چند دلاری که خرج می‌کند را دارد. شما باید هر یک از هزاران اعتبارنامه خود را git-push کنید (آسان است) و سپس مست شوید و کلیدهای خود را در یک بار با چیزی که به شما لینک می‌دهد، بگذارید (شانس کمی کمتر است، به خصوص اگر اهل مشروبات الکلی نباشید).
• از یک برنامه مدیریت رمز عبور با یک رمز عبور قوی و ذخیره نشده استفاده کنید. برای مدیریت اطلاعات محرمانه در سیستم‌ها از خزانه‌های مخفی. CI/CD سیستم‌ها، ارائه‌دهندگان خدمات ابری، SCMs و سایر ابزارهای DevOps این سرویس را ارائه می‌دهند، اما شما می‌توانید یک راه‌حل عمومی Secret Vault را انتخاب کنید.
• ترجیح می دهند کوتاه مدت توکن‌ها به کلیدهای دسترسی با طول عمر بالا. لغو آنها آسان‌تر است و پنجره‌ی محدودتری را در معرض خطر قرار می‌دهند.
• محدود کردن استفاده مجدد از اعتبارنامهمهاجمان از اعتبارنامه‌های جمع‌آوری‌شده برای یک هدف در سیستم‌های دیگر استفاده مجدد خواهند کرد، که نکته‌ی دیگری برای استفاده از یک مدیر رمز عبور است. مدیران رمز عبور و خزانه‌های مخفی باید استفاده‌ی مجدد از اعتبارنامه‌ها را به خاطره‌ای از گذشته تبدیل کنند.
• محدود کردن و نظارت بر استفاده از مدیر سایت رمزهای عبور. آنها به اندازه کافی قدرتمند هستند که شایسته ردیابی ویژه باشند.
• پیاده سازی هشینگ و رمزگذاری قویبازگشت به کلیدهای USB (رمزنگاری)، رویه‌های سختگیرانه برای انتقال اعتبارنامه‌ها با شرکا و همکاران و غیره.
• استفاده اسکنر اسراربرای مثال، اجرا در یک pre-commit قلاب برای جلوگیری از نشت اطلاعات در سیستم‌های کنترل نسخه، به عنوان یک دروازه امنیتی. قبل از آن چیز در اینجا مهم است. به عنوان یک روش جایگزین، از اسکن‌های پس از وقوع برای شناسایی اسرار فاش شده، به عنوان مثال به عنوان یک بررسی قبل از آن، استفاده کنید. pull request ادغام می‌شود. توجه: پلتفرم Xygeni ما شامل یک اسکنر اسرار است که هر دو حالت عملکرد را امکان‌پذیر می‌کند. 
• جایگزین دستی استفاده از بررسی کد جستجوی اسرار کدگذاری شده هزینه‌های بالاتری دارد و پس از...commit (اما امیدواریم حداقل قبل از اینکه این راز در دسترس افراد خارجی قرار گیرد). اما بررسی‌ها ممکن است رازهای غیرمتعارفی را شناسایی کنند که ممکن است از اسکنرهای اسرار پنهان بمانند.       
• به طور تصادفی اجتناب کنید commitفایل‌های رایج را با رمزهایشان به کنترل نسخه با روش‌های مناسب وصل کنید الگوها را حذف کنید (مانند الگوی `gitignore`)، با در نظر گرفتن فایل‌هایی مانند .env, .npmrc, .pypirc، فایل‌های موقت… در واقع یک لایه اضافی در امنیت onion.
• و آخرین مورد در این فهرست طولانی: اجازه دهید ارائه‌دهندگان فضای ابری، در صورت امکان، اسکن‌هایی را برای نشت کلیدهایشان انجام دهند. حداقل، این ممکن است در صورت وقوع نشت اطلاعات، شما را مطلع خواهیم کرد، اما امنیت برای ارائه دهندگان خدمات ابری ضروری است. این تعقیبی اسکن مخفی در مورد مکان و تعداد دفعات انجام اسکن چندان شفاف نیست و اغلب نیاز به تنظیمات صریح دارد، اما مطمئناً آخرین منبعی است که وقتی همه چیز دیگر از کار می‌افتد، استفاده می‌شود.

خدای من! کلیدهای دسترسی ابری‌ام را در یک مخزن عمومی قرار دادم، شماره ۲ را انتخاب کنید.

این اتفاق می‌تواند برای بهترین‌های ما هم بیفتد. آستین‌هایتان را بالا بزنید!

فوراً رمز فاش شده را تمدید/لغو/غیرفعال کنید! اگر حساب کاربری MFA مناسبی داشته باشد، ریسک بسیار کمتر است. این کار می‌تواند مثلاً در مورد کلیدهای خصوصی در وب‌سایت‌ها دشوارتر باشد (شما باید برای یک کلید خصوصی جدید، یک گواهی جدید صادر کنید و گواهی موجود را لغو کنید)، اما ابزارهای مدرن راهی سریع برای تمدید اعتبارنامه‌ها یا لغو توکن‌ها دارند. 

در صورت امکان، مراحل توصیه شده توسط ارائه دهنده را دنبال کنید، مانند AWS در این مثال.

علت نشت را شناسایی کنید. دانستن چگونگی وقوع آن برای افشا، تجزیه و تحلیل، مهار و فعالیت‌های درس‌آموز ضروری است.

سپس نشتی را به طرف‌های آسیب‌دیده گزارش دهید و اقداماتی را که برای رفع نشتی و کاهش خسارت انجام می‌دهید، توضیح دهید. هیچ راهی برای جبران خسارت وارده وجود ندارد، آنچه فاش شده، دیگر فاش شده است. شفاف باشید و به دیگران اطلاع دهید تا بتوانند اقدامی انجام دهند. 

سپس با پزشکی قانونی.  پنجره نوردهی زمان بین نشت اطلاعات و زمانی است که اطلاعات محرمانه معتبر نبوده‌اند. در طول آن بازه زمانی، آماده خواندن گزارش‌ها و ردیابی فعالیت‌های غیرمعمول با حساب کاربری آسیب‌دیده باشید. حساب‌ها و کلیدهای تولید شده با استفاده از حساب کاربری آسیب‌دیده را حذف کنید. به یاد داشته باشید که اگر حساب کاربری آسیب‌دیده دارای امتیازات ادمین باشد، رفع مشکل بسیار پیچیده‌تر خواهد بود. 

تاریخچه بازنویسی (کنترل نسخه) پیچیده است. حتی دولت‌های تمامیت‌خواه هم این کار را امتحان می‌کنند اما فایده‌ای ندارد (منظور جناس است.) و احتمالاً بی‌ربط: هکرها یا ربات‌های موجود در مخازن عمومی ممکن است مخزن را کپی کرده باشند یا قبلاً طلا را استخراج کرده باشند، به‌خصوص اگر بازه زمانی افشای اطلاعات به اندازه کافی بزرگ باشد. 

اگر ماجراجو هستید و می‌خواهید خودتان ببینید چقدر طول می‌کشد تا ربات‌ها یک راز فاش شده را کشف کنند، ترفندهایی مانند توکن‌های قناری به شما اجازه آزمایش می‌دهم. به یاد داشته باشید، ربات‌ها پیش‌فرض را در لیست سیاه قرار می‌دهند canarytokens.org دامنه …