مخازن بسته های عمومی هزاران توکن امنیتی API را در معرض دید قرار می دهد – و آنها فعال هستند

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

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

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

پلتفرم

نمونه نشانه

—

کدام مخازن منبع باز را اسکن کردیم؟

ما مصنوعات را در رایج‌ترین رجیستری‌های نرم‌افزار منبع باز اسکن کردیم: npm، PyPI، RubyGems، crates.io، و DockerHub (هر دو Dockerfiles و لایه های Docker کوچک). در مجموع، ما بیش از ۸ میلیون مصنوع را اسکن کردیم.

در هر مصنوع، از تشخیص اسرار برای یافتن نشانه‌هایی استفاده کردیم که به راحتی قابل تأیید باشند. به عنوان بخشی از تحقیقات خود، ما حداقل درخواستی برای هر یک از نشانه‌های یافت شده ارائه کردیم:

1. بررسی کنید آیا رمز هنوز فعال است (به هر دلیلی لغو نشده یا در دسترس عموم قرار نگرفته است).
2. مجوزهای نشانه را درک کنید.
3. مالک نشانه را (در صورت امکان) درک کنید تا بتوانیم مشکل را به صورت خصوصی برای آنها فاش کنیم.

برای npm و PyPI، ما همچنین چندین نسخه از یک بسته را اسکن کردیم تا سعی کنیم نشانه‌هایی را پیدا کنیم که زمانی در دسترس بودند اما در نسخه‌های بعدی حذف شدند.

توکن‌های «فعال» در مقابل «غیرفعال»

همانطور که در بالا ذکر شد، هر نشانه ای که به صورت ایستا شناسایی می شد نیز از طریق تأیید پویا اجرا می شد. این بدان معناست که، برای مثال، تلاش برای دسترسی به یک API که هیچ کاری انجام نمی دهد (بدون عملیات) در سرویس مربوطه ای که توکن به آن تعلق دارد، فقط برای اینکه ببینید که توکن «برای استفاده در دسترس است». رمزی که این تست را پشت سر گذاشته است (ژتون “فعال”) برای مهاجمان در دسترس است تا بدون هیچ گونه محدودیت دیگری از آن استفاده کنند.

از توکن‌های تأییدشده به‌صورت پویا به‌عنوان توکن‌های «فعال» و نشانه‌هایی که تأیید پویا ناموفق بوده‌اند، به‌عنوان توکن‌های «غیرفعال» یاد می‌کنیم. توجه داشته باشید که ممکن است دلایل زیادی وجود داشته باشد که یک توکن به عنوان “غیرفعال” نشان داده شود. به عنوان مثال:

• توکن باطل شد.
• توکن معتبر است، اما محدودیت‌های اضافی برای استفاده از آن دارد (به عنوان مثال، باید از محدوده IP منبع خاصی استفاده شود).
• خود نشانه در واقع یک نشانه نیست، بلکه عبارتی است که “شبیه” یک نشانه است (مثبت نادرست).

کدام مخازن بیشترین توکن های لو رفته را داشتند؟

اولین سوالی که می‌خواستیم به آن پاسخ دهیم این بود: “آیا پلتفرم خاصی وجود دارد که توسعه‌دهندگان در آن توکن‌ها را به بیرون درز کنند؟”

از نظر حجم عظیم اسرار فاش شده، به نظر می رسد که توسعه دهندگان باید هنگام ساخت تصاویر Docker خود مراقب افشای اسرار باشند (برای راهنمایی در این مورد به بخش “نمونه ها” زیر مراجعه کنید.

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

یک مشکل دیگر با Docker Hub این است که هیچ اطلاعات تماسی برای هر تصویر به طور عمومی نشان داده نمی شود، بنابراین حتی اگر یک راز فاش شده توسط محقق کلاه سفید پیدا شود، گزارش مشکل به نگهدارنده تصویر ممکن است بی اهمیت نباشد. در نتیجه، می‌توانیم تصاویری را مشاهده کنیم که رازهای افشا شده یا انواع دیگر مسائل امنیتی را برای سال‌ها حفظ می‌کنند.

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

در نهایت، ما همچنین می‌توانیم به توزیع توکن‌هایی که به تعداد مصنوع‌هایی که برای هر پلتفرم اسکن شده‌اند، عادی شده نگاه کنیم.

وقتی تعداد مصنوعات اسکن شده برای هر پلتفرم را نادیده می گیریم و روی تعداد نسبی نشانه های لو رفته تمرکز می کنیم، می بینیم که لایه های Docker Hub همچنان بیشترین توکن ها را ارائه می دهند، اما جایگاه دوم اکنون توسط PyPI. (هنگامی که به داده های مطلق نگاه می کنیم، PyPI چهارمین توکن لو رفته را داشت.)

کدام انواع توکن بیشتر لو رفت؟

پس از اسکن انواع توکن‌هایی که توسط Secrets Detection پشتیبانی می‌شوند و تأیید پویایی نشانه‌ها، نتایج را جمع‌آوری کردیم. ۱۰ نتیجه برتر در نمودار زیر نمایش داده شده است.

ما به وضوح می‌بینیم که توکن‌های خدمات وب آمازون، پلتفرم ابری گوگل و توکن‌های API تلگرام بیشترین لو رفتن را دارند (به ترتیب). با این حال، به نظر می رسد که توسعه دهندگان AWS در مورد لغو توکن های استفاده نشده هوشیارتر هستند، زیرا تنها ۴۷٪ از توکن های AWS فعال هستند. در مقابل، GCP نرخ توکن فعال ~۷۳% داشت.

نمونه هایی از اسرار فاش شده در هر مخزن

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

DockerHub – لایه‌های Docker

بررسی نام فایل‌هایی که در لایه Docker وجود داشتند و حاوی اطلاعات کاربری لو رفته بودند نشان می‌دهد که رایج‌ترین منبع نشت برنامه‌های Node.js هستند که از dotenv برای ذخیره اعتبارنامه ها در متغیرهای محیطی. دومین منبع متداول، توکن های AWS کدگذاری شده بود.

جدول زیر متداول‌ترین نام‌های فایل در لایه‌های Docker را فهرست می‌کند که حاوی یک نشانه لو رفته است.

نام فایل

# مورد با نشانه‌های لو رفته فعال

—

لایه‌های Docker را می‌توان با کشیدن تصویر و اجرای آن بررسی کرد. با این حال، مواردی وجود دارد که یک راز ممکن است توسط یک لایه میانی حذف شده باشد< /a> (از طریق یک فایل “whiteout”)، و اگر چنین است، راز هنگام بررسی تصویر نهایی Docker ظاهر نمی شود. با استفاده از ابزارهایی مانند dive می توان هر لایه را به صورت جداگانه بررسی کرد و راز را در “حذف شده” یافت. ” فایل. تصویر صفحه زیر را ببینید.

لایه داکر با اطلاعات کاربری باز شده در بازرس لایه dive.

بازرسی محتویات فایل “مطالب کاربری” نشانه های لو رفته را نشان می دهد.

اطلاعات AWS از طریق ./aws/credentials لو رفت.

DockerHub – Dockerfiles

Docker Hub حاوی بیش از ۸۰ درصد از اعتبارنامه های لو رفته در تحقیقات ما بود.

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

اعتبارنامه AWS از طریق متغیرهای محیط Dockerfile لو رفت.

یکی دیگر از گزینه های رایج استفاده از رازها در دستورات Dockerfile است که محتوای مورد نیاز برای راه اندازی برنامه Docker را دانلود می کند. مثال زیر نشان می‌دهد که چگونه یک کانتینر از یک راز احراز هویت برای شبیه‌سازی یک مخزن در ظرف استفاده می‌کند.

اطلاعات AWS از طریق Dockerfile از طریق دستور git clone لو رفت.

crates.io

با crates.io، مدیر بسته Rust، ما با خوشحالی شاهد نتیجه ای متفاوت از سایر مخازن بودیم. اگرچه Xray نزدیک به ۷۰۰ بسته حاوی اسرار را شناسایی کرد، تنها یکی از این رازها فعال نشان داده شد. جالب است که این راز حتی در کد استفاده نشده است، اما در یک نظر یافت شده است.

PyPI

در اسکن‌های PyPI ما، بیشتر نشت‌های توکن در کد واقعی پایتون پیدا شد.

به عنوان مثال، یکی از توابع در یک پروژه تحت تأثیر یک نشانه آمازون RDS (سرویس پایگاه داده رابطه ای) بود. اگر توکن فقط اجازه دسترسی به پرس و جو در پایگاه داده نمونه RDS را بدهد، ممکن است ذخیره یک توکن مانند این خوب باشد. با این حال، هنگام جمع‌آوری مجوزها برای توکن، متوجه شدیم که توکن به کل حساب AWS دسترسی می‌دهد. (این نشانه پس از افشای ما به نگهبانان پروژه باطل شده است.)

نشت توکن AWS در کد منبع یک بسته PyPI.

مجوزهای کامل سرپرست ناخواسته (*/*) در یک توکن “مثال” آمازون RDS.

npm

به‌جز توکن‌های کدگذاری‌شده در کد Node.js، بسته‌های npm می‌توانند اسکریپت‌های سفارشی تعریف شده در بلوک اسکریپت فایل package.json داشته باشند. این اجازه می دهد تا اسکریپت های تعریف شده توسط نگهدارنده بسته در پاسخ به محرک های خاص، مانند بسته در حال ساخت، نصب، و غیره را اجرا کنید.

یک اشتباه تکراری که دیدیم این بود که توکن‌ها را در بلوک اسکریپت‌ها در طول توسعه ذخیره می‌کردیم، اما پس از انتشار بسته فراموش می‌کردیم که نشانه‌ها را حذف کنیم. در مثال زیر، توکن‌های npm و GitHub لو رفته را می‌بینیم که توسط ابزار ساخت release معنایی.

نشت رمز npm در بلوک npm “scripts” (package.json).

معمولاً، بسته dotenv قرار است این مشکل را حل کند. این به توسعه دهندگان اجازه می دهد تا یک فایل محلی به نام .env در دایرکتوری ریشه پروژه ایجاد کنند و از آن برای پر کردن متغیرهای محیطی در یک محیط آزمایشی استفاده کنند. استفاده صحیح از این بسته نشت مخفی را برطرف می کند، اما متأسفانه، استفاده نادرست از بسته dotenv را یکی از رایج ترین دلایل نشت مخفی در بسته های PyPI دانستیم. اگرچه اسناد بسته به صراحت می گوید که فایل های .env را به کنترل نسخه متعهد نکنید، ما بسته های زیادی پیدا کردیم که در آن فایل .env در npm منتشر شده بود و حاوی اسرار بود.

مستندات dotenv صریحاً در مورد انتشار فایل‌های env .

هشدار می‌دهد

خیر. اکیداً توصیه می‌کنیم که فایل .env خود را به نسخه کنترل نکنید. فقط باید مقادیر محیطی خاص مانند رمزهای عبور پایگاه داده یا کلیدهای API را شامل شود. پایگاه داده تولید شما باید رمز عبور متفاوتی نسبت به پایگاه داده توسعه شما داشته باشد.

RubyGems

با مروری بر نتایج بسته‌های RubyGems، هیچ نقطه‌ی پرت خاصی مشاهده نکردیم. اسرار شناسایی شده یا در کد Ruby یا در فایل‌های پیکربندی دلخواه در داخل جواهر یافت شدند.

برای مثال، در اینجا می‌توانیم یک YAML پیکربندی AWS را ببینیم که توکن‌های حساس را فاش می‌کند. این فایل قرار است یک مکان نگهدار برای پیکربندی AWS باشد، اما بخش توسعه با یک کلید دسترسی/مخفی زنده تغییر داده شد.

نشت توکن AWS در spec/dummy/config/aws.yml.

شایع ترین اشتباهات هنگام ذخیره نشانه ها

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

اشتباه شماره ۱. عدم استفاده از اتوماسیون برای بررسی قرار گرفتن در معرض مخفی

موارد زیادی وجود داشت که اسرار فعالی را در مکان‌های غیرمنتظره پیدا کردیم: نظرات کد، فایل‌های مستندات، نمونه‌ها یا موارد آزمایشی. بررسی این مکان ها به صورت دستی و به روشی ثابت بسیار سخت است. پیشنهاد می‌کنیم یک اسکنر اسرار را در خط لوله DevOps خود تعبیه کنید و قبل از انتشار یک ساخت جدید در مورد نشت‌ها هشدار دهید.

ابزارهای متن باز و رایگان بسیاری وجود دارند که این نوع عملکرد را ارائه می دهند. یکی از توصیه‌های OSS ما TruffleHog است که از مجموعه‌ای از اسرار پشتیبانی می‌کند و یافته‌ها را به صورت پویا تأیید می‌کند و موارد مثبت کاذب را کاهش می‌دهد.

برای خطوط لوله پیچیده تر و پشتیبانی گسترده تر از یکپارچه سازی، ما JFrog Xray را ارائه می دهیم.

یک توکن GitHub در اسناد فاش شد، که فقط خواندنی در نظر گرفته شده بود، اما در واقع مجوزهای ویرایش کامل را ارائه می‌کرد.

• امنیت
• امنیت برنامه< /a>
• امنیت ابری< /a>
• دوپس
• توسعه نرم افزار< /a>
• رایانش ابری< /a>