نماینده رسمی فروش محصولات کسپرسکی در ایران

حمله کرم شای‌هولود: ۱۸۰ پکیج npm در خطر قرار گرفت

دنیای توسعه نرم‌افزار هر روز با تهدیدات جدید امنیتی روبرو می‌شود، اما آنچه در روزهای گذشته رخ داد، یکی از خطرناک‌ترین حملات در تاریخ npm بود. حمله‌ای که نه تنها صدها package محبوب را آلوده کرد، بلکه خصوصیات یک کرم واقعی خودتکثیر را نشان داد. این حادثه نشان می‌دهد که حتی معتبرترین مخازن نرم‌افزاری نیز […]

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

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

 

چگونه متوجه شدیم که npm تحت حمله قرار گرفته؟

ماجرا از کجا شروع شد؟ یک پکیج به نام rxnt-authentication در ۱۴ سپتامبر ساعت ۱۷:۵۸ UTC آلوده شد و از همان جا شروع به گسترش کرد. دانیل دوس سانتوس پرریرا، مهندس نرم‌افزار شرکت Loka، روز بعد متوجه موضوع شد و هشدار داد. او در توییتر نوشت: “یک کرم npm در حال گسترش است که اعتبارنامه‌های توسعه‌دهندگان را می‌دزدد.”

اولین نشانه‌ها عجیب بودند. چند توسعه‌دهنده متوجه شدند که packages آن‌ها به طور خودکار نسخه‌های جدیدی منتشر می‌کنند بدون اینکه خودشان کاری انجام داده باشند. وقتی کد packages جدید را بررسی کردند، کد مخربی پیدا کردند که قبلاً وجود نداشت.

محققان امنیتی به سرعت دریافتند که این یک حمله زنجیره‌ای است. هر package آلوده، سعی می‌کرد packages دیگری را پیدا کند تا آن‌ها را هم آلوده کند. این رفتار دقیقاً مانند یک کرم رایانه‌ای بود – چیزی که در npm تا به حال دیده نشده بود.

 

آناتومی یک کرم هوشمند: چطور شای‌هولود کار می‌کند؟

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

بعد از پیدا کردن این اطلاعات حساس، کرم آن‌ها را مستقیماً به سرور مهاجمان ارسال می‌کرد. آدرس سرور webhook[.]site بود – سرویسی که معمولاً برای تست webhookها استفاده می‌شود، اما در اینجا برای جمع‌آوری اطلاعات سرقتی به کار گرفته شده بود.

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

علاوه بر این، کرم سعی می‌کرد repository‌های خصوصی GitHub شما را عمومی کند. برای این کار، پسوند -migration به نام repository اصلی اضافه می‌کرد و یک کپی عمومی از آن ایجاد می‌کرد. هدف این بود که به کدهای منبع خصوصی و رازهای hard-coded درون آن‌ها دسترسی پیدا کند.


قربانیان بزرگ: وقتی CrowdStrike هم گرفتار شد

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

یکی از packages مشهوری که آلوده شد @ctrl/tinycolor بود – package‌ای که هفته‌ای بیش از ۲ میلیون بار دانلود می‌شود. تصور کنید که چند میلیون پروژه در معرض این تهدید قرار گرفتند! این package برای کار با رنگ‌ها در جاوا اسکریپت استفاده می‌شود و در هزاران پروژه وب کاربرد دارد.

packages آلوده دیگر شامل موارد مهمی مثل angulartics2، koa2-swagger-ui و مجموعه‌ای از packages تحت نام @nativescript-community بودند. هر کدام از این packages هزاران کاربر داشتند و آلوده شدن آن‌ها تأثیر گسترده‌ای روی جامعه توسعه‌دهندگان گذاشت.

خوشبختانه CrowdStrike به سرعت واکنش نشان داد. آن‌ها در بیانیه‌ای اعلام کردند: “بلافاصله پس از شناسایی packages مخرب، آن‌ها را حذف کردیم و کلیدهای عمومی‌مان را تغییر دادیم. این packages در محصول Falcon sensor استفاده نمی‌شدند و مشتریان ما همچنان محافظت هستند.”

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

قربانیان بزرگ: وقتی CrowdStrike هم گرفتار شد

واکنش سریع جامعه: چطور npm جلوی فاجعه را گرفت؟

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

Socket، شرکت امنیت زنجیره تأمین که اولین گزارش تخصصی از این حمله را منتشر کرد، در بیانیه‌ای نوشت: “این حمله نشان‌دهنده تحول نگران‌کننده‌ای در تهدیدات زنجیره تأمین است. برای اولین بار با یک کرم واقعی در npm روبرو هستیم.”

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

محققان امنیتی معتقدند که حمله احتمالاً با یک کمپین فیشینگ شروع شده که npm را تقلید می‌کرده. این ایمیل‌های جعلی از developers می‌خواستند تا برای “بهبود امنیت” تنظیمات FA2 خود را “به‌روزرسانی” کنند. متأسفانه بعضی از توسعه‌دهندگان به این دام افتادند و اعتبارنامه‌هایشان لو رفت.

 

آمار تکان‌دهنده: چه چیزی دزدیده شد؟

وقتی محققان امنیتی داده‌های لو رفته روی GitHub را تجزیه و تحلیل کردند، نتایج واقعاً تکان‌دهنده بود. GitGuardian، شرکتی که در حوزه شناسایی رازهای درز شده فعالیت می‌کند، گزارش داد که مجموعاً ۲۷۸ راز مختلف در این حمله درز کرده است.

از این ۲۷۸ راز، ۹۰ تای آن‌ها مستقیماً از سیستم‌های محلی توسعه‌دهندگان جمع‌آوری شده بود. این شامل فایل‌های .env، کلیدهای SSH و رازهای hard-coded در پروژه‌ها می‌شد. ۱۸۸ راز باقی‌مانده از طریق workflows مخربی که کرم ایجاد کرده بود به دست آمده بود.

بیشترین نوع رازهای دزدیده شده به ترتیب عبارت بودند از:

  • GitHub Personal Access Tokens
  • npm tokens برای انتشار packages
  • کلیدهای AWS (AWS_ACCESS_KEY_ID و AWS_SECRET_ACCESS_KEY)
  • توکن‌های سرویس‌های cloud دیگر
  • رازهای API مختلف

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

 

ارتباط با حملات قبلی: آیا این یک الگوی جدید است؟

این حمله تنها نیست. محققان امنیتی شباهت‌های زیادی بین شای‌هولود و حمله “s1ngularity” که ماه گذشته سیستم build nx را نشانه گرفته بود، پیدا کرده‌اند. هر دو حمله از همان تاکتیک‌ها استفاده کرده‌اند:

  • سرقت GitHub tokens
  • ایجاد workflows مخرب
  • عمومی کردن repository‌های خصوصی با پسوند -migration
  • استفاده از TruffleHog برای جستجوی رازها

کارلو ژانکی، محقق امنیت در ReversingLabs، معتقد است: “شباهت طراحی و عملکرد کمپین nx با کرم شای‌هولود قابل توجه است. آنچه بیشتر نگران‌کننده است، گسترش خودکار بدافزار به packages تحت مدیریت حساب‌های npm آلوده است.”

شرکت Wiz هم در تحلیل خود نوشته که این حمله “مستقیماً پایین‌دست” از حمله s1ngularity قرار دارد. این یعنی احتمالاً همان گروه مهاجمان پشت هر دو حمله قرار دارند و دارند تاکتیک‌هایشان را تکامل می‌دهند.

چارلی اریکسن، محقق Aikido، درباره ماهیت این حملات می‌گوید: “یکی از چشمگیرترین ویژگی‌های این حمله این است که مانند یک کرم واقعی رفتار می‌کند. این چرخه باعث می‌شود بدافزار به طور مداوم هر package‌ای که maintainer به آن دسترسی دارد را آلوده کند.”

 

تهدید همزمان: حمله فیشینگ علیه Rust

همزمان با حادثه npm، یک کمپین فیشینگ هم علیه کاربران Rust راه‌اندازی شده بود. مهاجمان از دامنه جعلی rustfoundation[.]dev استفاده می‌کردند و ایمیل‌هایی از آدرس security@rustfoundation[.]dev ارسال می‌کردند.

این ایمیل‌ها ادعا می‌کردند که crates.io مخزن packages راست hack شده و کاربران باید “فوراً” اطلاعات login خود را تغییر دهند. لینک موجود در ایمیل، github.rustfoundation[.]dev، صفحه‌ای کاملاً شبیه GitHub را نشان می‌داد اما در واقع برای سرقت اعتبارنامه‌ها طراحی شده بود.

خوشبختانه Rust Security Response Working Group خیلی سریع هشدار داد: “این ایمیل‌ها مخرب هستند و از دامنه‌ای می‌آیند که تحت کنترل Rust Foundation نیست. هدف آن‌ها سرقت اعتبارنامه‌های GitHub شماست. هیچ مدرکی از سازش زیرساخت crates.io وجود ندارد.”

این نشان می‌دهد که مهاجمان استراتژی چندجانبه‌ای دارند و همزمان چندین اکوسیستم را نشانه می‌گیرند.

تأثیرات گسترده روی صنعت

این حمله تأثیرات گسترده‌ای روی صنعت نرم‌افزار گذاشت. بسیاری از شرکت‌های بزرگ مجبور شدند تیم‌های امنیتی‌شان را فعال کنند تا dependency‌هایشان را بررسی کنند. GitHub هم اعلام کرد که سیستم‌های تشخیص خودکار آن‌ها را تقویت می‌کند تا workflows مشکوک سریع‌تر شناسایی شوند.

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

شرکت‌های امنیتی هم محصولات جدیدی معرفی کردند. Socket اعلام کرد که ابزار جدیدی برای تشخیص خودکار کرم‌های npm در حال توسعه است. ReversingLabs هم گفت که الگوریتم‌های machine learning جدیدی برای شناسایی رفتارهای خودتکثیری در حال آزمایش است.

 

چه کاری باید انجام دهیم؟

برای توسعه‌دهندگان:

اقدامات فوری:

  • فوراً فهرست dependencies پروژه‌هایتان را با لیست packages آلوده مقایسه کنید
  • تمام GitHub و npm tokens خود را rotate کنید – حتی اگر فکر می‌کنید آلوده نشده‌اید
  • repositories GitHub خود را برای workflows مشکوک یا غیرمنتظره اسکن کنید
  • فایل‌های .github/workflows را به دقت بررسی کنید

اقدامات میان‌مدت:

  • 2FA را روی تمام account‌هایتان فعال کنید
  • از dependency scanning tools استفاده کنید
  • npm audit را مرتب اجرا کنید
  • .env files خود را از repository‌ها حذف کنید

برای شرکت‌ها:

  • Software Bill of Materials (SBOM) برای پروژه‌هایتان تهیه کنید
  • CI/CD pipelines خود را برای dependency scanning پیکربندی کنید
  • private npm registry راه‌اندازی کنید
  • تیم‌های توسعه را درباره supply chain security آموزش دهید

 

آینده امنیت npm چگونه خواهد بود؟

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

محققان امنیتی انتظار دارند که در آینده شاهد حملات مشابه اما پیشرفته‌تری باشیم. استفاده از AI برای تولید کدهای مخرب، حملات هدفمند به maintainerهای خاص و استفاده از zero-day vulnerabilityها در خود npm احتمالات آینده هستند.

npm و GitHub اعلام کرده‌اند که روی سیستم‌های پیشرفته‌تری برای تشخیص انواع جدید این تهدیدها کار می‌کنند. اما واقعیت این است که این جنگ همیشه ادامه خواهد داشت – هر تکنولوژی امنیتی جدید، مهاجمان هم روش‌های جدیدی برای دور زدن آن پیدا می‌کنند.

آینده امنیت npm چگونه خواهد بود؟

حمله کرم شای‌هولود یکی از مهم‌ترین حوادث امنیتی در تاریخ npm بود که نشان داد چقدر اکوسیستم متن‌باز در برابر حملات پیچیده آسیب‌پذیر است. آلودگی بیش از ۱۸۰ package، سرقت صدها راز و درگیر شدن شرکت‌های بزرگ، همگی نشان‌دهنده جدیت این تهدید بودند.

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

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

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

 

برای اطلاع از آخرین اخبار امنیت سایبری و راهکارهای محافظت از سیستم‌هایتان، خبرنامه ما را دنبال کنید.

ثبت نام مشتری جدید

لطفاً برای ادامه شرایط و ضوابط را قبول کنید.