روابط عمومی شرکت ایدکو (توزیع کننده محصولات کسپرسکی در ایران)؛ ماه گذشته، سایت‌های خبرگزاری آی‌تی گزارش دادند که RubyGems–کانال رسمیِ توزیع آرشیوها برای زبان برنامه‌نویسی Ruby- آلوده شده است. مهاجمی بسته‌های جعلی حاوی یک اسکریپت آلوده را آپلود کرده بود؛ بنابراین تمامی برنامه‌نویسانی که از این مد در پروژه‌های خود استفاده کرده بودند ناخواسته با این بدافزار، کامپیوترهای کاربران را آلوده کردند (همین امر باعث شد آدرس‌های کیف‌پول‌های رمزارز عوض شود). البته این اولین حمله‌ی زنجیره تأمین نبود که مخزن عمومی را اکسپلویت می‌کرد. اما این جنس سناریو به نظر بسیار محبوب می‌آید که البته جای تعجب هم ندارد؛ یک حمله‌ی موفق می‌تواند از ده‌ها تا صدها کاربر قربانی بسازد.
چطور بسته‌های آلوده به مخازن راه پیدا می‌کنند؟
در مورد RubyGems، مجرم سایبری کلی پروژه در مخزن با نام‌هایی مشابه با بسته‌های محبوب و قانونی درست کرده بود. این تکنیک که به typosquatting معروف است تمام نقطه اتکایش این است که توسعه‌دهندگان به طور ناصحیحی نام یک بسته را وارد کرده و تصادفاً بسته آلوده را دانلود کنند و یا تازه جولان دادنشان زمانی شروع می‌شود که توسعه‌دهندگان فهرست نام بسته‌ها را از یک پرسمان جستجوی وب -آن هم بدون اینکه بدانند این بسته‌ها قانونی‌اند یا نه- دریافت کنند. این تاکتیک –به طور کلی رایج‌ترین فن در حوزه سم سایبری[1] است- از طریق مخزن بسته‌های پیتون[2] در حملات به کار گرفته می‌شود و همچنین از آن در آپلود کردن عکس‌های جعلی در Docker Hub استفاده می‌شود. در رخداد کیف‌پول رمزارز Copay، مهاجمین از آرشیوی استفاده کردند که مخزنش روی GitHub میزبانی شد. سازنده‌ی آن علاقه‌اش را از دست داد و بعد حقوق ادمین را فاش و این آرشیو محبوب را دستکاری کرد؛ آرشیوی که بسیاری از توسعه‌دهندگان از آن در تولیدات خود استفاده کرده بودند.
برخی‌اوقات، مجرمان سایبری می‌توانند از اکانت یک توسعه‌دهنده‌ی قانونی بدون اینکه آن توسعه‌دهنده روحش هم از این ماجرا باخبر باشد استفاده کنند و به بسته‌های جعلی را به جای بسته‌های واقعی بگذارند. در مورد ESLint همین اتفاق افتاد؛ آرشیوهای آن در پایگاه اطلاعاتی آنلاین npm (مدیر بسته نود[3]) میزبانی شد.
دستکاری محیط همگردانی
شرکتهای توسعه‌دهنده‌ی محصولات نرم‌افزاری همچنین به طور بالقوه طعمه‌های چرب و نرمی برای عاملین APT هستند. مواردی از حمله‌ی آنها به کلاینت‌های چنین شرکت‌هایی هر از چندگاهی نظر متخصصین امنیتی را به خود جلب می‌کند:
- در آگوست 2017، برخی عاملین APT خود را به نرم‌افزاری ساخت شرکت NetSarang (با ماژول‌های آلوده) تجهیز کردند. به نقل از محققین، این مهاجمین ممکن است سرورهای سازه نرم‌افزاری را دستکاری کرده باشند.
- در سال 2018، مجرمان سایبری سرور سازه اپ Piriform را آلوده کردند که بعدش، سازه‌های برنامه CCleaner به همراه کد منبعی سالم در طول این فرآیند همگردانی به عنوان سلاحی مبارز به کار گرفته شد.
- در سال 2019، متخصصین ما کمپین APT موسوم به ShadowHammer را که در طول آن مهاجمین بک‌دری را در محصولات نرم‌افزاری از چندین شرکت جاگذاری کردند کشف نمودند. بر اساس نتایج این بررسی، مهاجمین یا به کد منبع دسترسی نموده و یا در مرحله همگردانی کد آلوده را معرفی کرده بودند.
دستکاری محیط همگردانی نه تنها «آلودگی» محصول نهایی را در پی دارد که همچنین به توزیع بدافزاری مسلح که در خود امضای دیجیتال قانونی از سوی توسعه‌دهنده‌‌ای قابل‌اطمینان را حمل می‌کند می‌انجامد. به همین دلیل است که فرآیند توسعه باید در برابر مداخله‌های خارجی حسابی محافظت گردد.
ریشه‌ی مشکل
در حقیقت، منشأ این خطر استفاده از مخازن عمومی نیست بلکه این خطر ریشه در نقصِ رویکرد مدرنِ توسعه‌ی نرم‌افزار دارد (همان متودولوژیِ DevOps). DevOps مجموعه ایست از اقداماتی که هدفشان کوتاه کردن چرخه توسعه برنامه است. توسعه همیشه باید بین امنیت و کاربردپذیری تعادلی ایجاد کند. توسعه‌دهندگان برای ماندن در فضای رقابتی امروزی باید نسخه‌های جدیدی از برنامه‌ها را (آن هم با حداکثر سرعت) عرضه کنند اما ارتقای کاربردپذیری یا موجب کاهش کیفیت می‌شود و یا TTM طولانی‌تر. در نتیجه، توسعه‌دهندگان همیشه در تلاشند تا مداخله‌ی پرسنل امنیتی را در فعالیت‌هایشان تماماً دور زده و یا میزان مداخله آنها را به حداقل برسانند.
در نتیجه، امنیت اطلاعات عملاً هیچ کنترلی روی این بخش زیرساخت ندارد. اما حوزه‌های توسعه، آی‌تی و امنیت همگی در راستای هدفی مشترک گام برمی‌دارند: تحویل محصولی امن و باکیفیت آن هم سر موقعش. اگر آپدیتی حاوی بک‌در یا ماژول جاسوسی باشد بدرد نمی‌خورد. بنابراین، به نظر ما این صنعت باید به سمت متودولوژی DevSecOps حرکت کند. DevSecOps تلاشی است برای پل زدن میان شکاف امنیتی و DevOps. این کار با معرفی فرهنگ امنیت سایبری و کاربرد اجراییِ بررسی‌های تمام مراحل توسعه‌ی نرم‌افزار (آن هم بدون دستکاری میزان انعطاف و سطح سرعت) صورت می‌گیرد. ما ابزارهایی ارائه می‌دهیم که به جنبه‌ی فنی این فرآیند کمک می‌کند.
راهکار ما
بازار با کمبود ابزارهایی مواجه است که به طور خاص کارشان امنیت‌دهیِ فرآیند توسعه نرم‌افزار می‌باشد. از این رو، ما در آپدیت راهکار Kaspersky Hybrid Cloud Security خود، نیازهای برنامه‌نویسان را مد نظر قرار داده و اجزای این راهکار را با فناوری‌هایی تطبیق دادیم که بواسطه آنها می‌شود ابزارهای امنیتی را بدون اینکه به عملکرد خدشه‌ای وارد شود با فرآیند توسعه ادغام نمود. اینها فناوری‌هایی هستند که عمدتاً مخصوص اسکن مخازن، عکس‌ها و کانتینرها هستند (فناوری‌هایی که جلوی حملات زنجره تأمین را می‌گیرند).
Kaspersky Hybrid Cloud Security رابط‌هایی برای هم‌کنش‌پذیری[4] با پلت‌فرم‌های یکپارچه‌سازی مداوم (CI) و تحویل پیوسته (CD) همچون TeamCity و Jenkins دارد. راهکار ما را می‌توان از طریق خط فرمان یا رابط برنامه‌نویسی یک اپ، در فرآیند توسعه ادغام کرد. هرچند این صرفاً نوآوری راهکار ما نیست!
[1] cyberpoisoning
[2] Python Package Index
[3] Node Package Manager
[4] interoperability
منبع: کسپرسکی آنلاین (ایدکو)
کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.
