بدافزار XCPE چگونه ۱٫۳ میلیون دستگاه را آلوده کرد؟
بدافزار XCPE یک درِ پشتی از پیش نصب‌شده در میان‌افزار برخی تجهیزات اندرویدی بود که دستگاه‌ها را بدون اطلاع صاحبانشان به شبکه‌ای تحت کنترل گردانندگان بدافزار متصل می‌کرد. گزارش‌های این پرونده از آلودگی بیش از ۱٫۳ میلیون دستگاه، عمدتاً گیرنده‌های تلویزیونی، خبر می‌دهند. این تهدید، مسئله اعتماد به میان‌افزار تجهیزات را از زمان خرید تا پایان بهره‌برداری مطرح می‌کند.
آلودگی پیش از خرید دستگاه…
گزارش‌های گوگل، TrendAI و Plume درباره بدافزار XCPE در ۲ نوامبر ۲۰۲۶ منتشر شدند. طبق گزارش گروه اطلاعات تهدیدات گوگل، عامل آلودگی پیش از رسیدن دستگاه به دست خریدار در آن حضور داشت؛ بنابراین، پرهیز از نصب برنامه‌های ناشناس به‌تنهایی نمی‌توانست مانع این تهدید شود.
بدافزار XCPE چیست و چرا ماندگار بود؟
XCPE امکان دریافت فرمان و اجرای مؤلفه‌های ناخواسته را در دستگاه فراهم می‌کرد. تجهیزات آلوده عضو یک بات‌نت بودند؛ شبکه‌ای از دستگاه‌ها که گردانندگان آن می‌توانند منابع و ارتباط اینترنتی آن‌ها را از راه دور به کار بگیرند. در این پرونده، نقطه شروع آلودگی در میان‌افزار قرار داشت؛ نرم‌افزار پایه‌ای که بخشی از عملکرد دستگاه را کنترل می‌کند.
طبق گزارش فنی گوگل، بسته اولیه با نام x.cpe یا در برخی نسخه‌ها com.oemservice اجرا می‌شد و دسترسی سیستمی داشت. حذف نسخه نصب‌شده در بخش داده‌ها الزاماً آلودگی را برطرف نمی‌کرد؛ زیرا پس از راه‌اندازی مجدد، امکان نصب دوباره از پارتیشن /oem/ وجود داشت.
وقتی عامل آلودگی در میان‌افزار باقی مانده است، حذف برنامه یا بازنشانی کارخانه، بدون بررسی مجدد، اثبات‌کننده پاک‌سازی کامل نیست.
گستره آلودگی XCPE و مسئولیت سازنده
در اطلاعیه Plume درباره گستره آلودگی XCPE، از حضور دستگاه‌های آلوده در بیش از ۲۰۰ کشور خبر داده شده است. بخش عمده تجهیزات این پرونده، گیرنده‌های تلویزیونی اندرویدی بودند. این آمار درباره تجهیزات شناسایی‌شده در همین پرونده است و نمی‌توان آن را به همه دستگاه‌های اندرویدی تعمیم داد.
گوگل با درجه اطمینان بالا، توسعه و بهره‌برداری عمدی از این درِ پشتی را برای کسب درآمد به شرکت Videostrong Technology نسبت داده است. این انتساب، ارزیابی منتشرشده گوگل درباره مسئولیت سازنده است و باید با همین نسبت در بازگویی خبر حفظ شود.
دستگاه‌های آلوده چگونه درآمدزایی می‌کردند؟
گردانندگان شبکه، امکان اجرای مؤلفه‌های متعلق به همکاران خود را روی تجهیزات آلوده فراهم می‌کردند. این مؤلفه‌ها از پهنای باند، توان پردازشی و دسترسی‌های دستگاه برای فعالیت‌هایی استفاده می‌کردند که بدون رضایت مالک انجام می‌شد.
۱. عبور ترافیک از اینترنت کاربران
برخی تجهیزات به گره خروجی پراکسی خانگی تبدیل می‌شدند و ترافیک اشخاص ثالث را از اینترنت صاحب دستگاه عبور می‌دادند. در نتیجه، سامانه مقصد آدرس IP مالک را مبدأ ارتباط می‌دید؛ وضعیتی که تشخیص ترافیک سوءاستفاده‌گر را بر پایه اعتبار آدرس مبدأ دشوار می‌کرد.
۲. ایجاد تعامل تبلیغاتی غیرواقعی
برخی تجهیزات با بارگذاری پنهانی صفحات و تبلیغات، برای تقلب تبلیغاتی به کار گرفته می‌شدند. این فعالیت‌ها می‌توانستند نمایش یا تعامل غیرواقعی ایجاد کنند، بدون آنکه کاربر متوجه شود. در نتیجه، کارکرد عادی دستگاه برای اطمینان از سلامت آن کافی نبود.
۳. اجرای کد و جمع‌آوری اطلاعات
برخی تجهیزات با دریافت فرمان‌های بعدی، کد جدید اجرا می‌کردند یا اطلاعات دستگاه و تصویر صفحه را در اختیار گردانندگان قرار می‌دادند. در نتیجه، ارزیابی خطر باید علاوه بر رفتار مشاهده‌شده، سطح دسترسی عامل اولیه و توانایی آن برای دریافت مؤلفه‌های تازه را نیز در بر می‌گرفت.
جدول زیر، فعالیت‌های گزارش‌شده در دستگاه‌های آلوده به XCPE را در کنار نحوه استفاده از تجهیزات و پیامدهای آن‌ها برای صاحبان دستگاه‌ها نشان می‌دهد.
| نوع فعالیت | نحوه استفاده از دستگاه | پیامد برای مالک |
|---|---|---|
| پراکسی خانگی | عبور ترافیک دیگران از اتصال اینترنت دستگاه | مصرف پهنای باند و استفاده از IP مالک |
| تقلب تبلیغاتی | بارگذاری پنهانی صفحات و تبلیغات اینترنتی | مصرف منابع برای ثبت فعالیت غیرواقعی |
| اجرای مؤلفه‌های بیشتر | دریافت و اجرای کد با فرمان گردانندگان شبکه | تغییر رفتار دستگاه بدون رضایت مالک |
| جمع‌آوری اطلاعات | دریافت اطلاعات دستگاه، حساب‌ها و محیط شبکه | افشای داده‌ها و شناخت محیط ارتباطی |
ارتباط بدافزار XCPE با سرور فرماندهی
در معماری گزارش‌شده، عامل اولیه ارتباط با زیرساخت فرماندهی و کنترل یا C2 را برقرار می‌کرد و اجرای ماژول‌ها به مؤلفه‌های جداگانه سپرده می‌شد. این جداسازی، تغییر ماژول‌های عملیاتی و استفاده از دستگاه برای فعالیت‌های مختلف را آسان‌تر می‌کرد.
دستگاه ابتدا تنظیمات لازم را از طریق HTTP دریافت می‌کرد و سپس با پروتکل MQTT به کانال دریافت فرمان متصل می‌شد. در بخشی از نسخه‌ها، بارگذار com.abc.nexus اجرای مؤلفه‌ها را بر عهده داشت. طبق گزارش گوگل، در نسخه‌های جدیدتر، برخی بارگذارهای اختصاصی جایگزین آن شده بودند.
بخشی از فایل‌های موردنیاز نیز از GitHub Releases دریافت می‌شدند. استفاده از MQTT یا ارتباط با GitHub به‌تنهایی نشانه آلودگی نیست؛ هر دو کاربردهای مشروع دارند. برای تشخیص، باید مقصد دقیق ارتباط، فایل دریافتی و رفتار فرایند اجراکننده در کنار هم بررسی شوند.
بدافزار XCPE چه خطری برای زنجیره تأمین دارد؟
امنیت زنجیره تأمین تجهیزات، بررسی منشأ سخت‌افزار و نرم‌افزار و مسئولیت نگهداری آن‌ها را در بر می‌گیرد. پرونده XCPE نشان می‌دهد نرم‌افزار تحویلی دستگاه نیز باید موضوع ارزیابی باشد. نام تجاری روی محصول، همه شرکت‌های دخیل در توسعه نرم‌افزار پایه آن را مشخص نمی‌کند.
این مسئله برای ارزیابی نمایشگرهای دیجیتال، کیوسک‌ها و تجهیزات اینترنت اشیا هم کاربرد دارد. این شباهت به معنای آلودگی آن‌ها به XCPE نیست؛ موضوع، شناخت منشأ میان‌افزار و محدودکردن دسترسی دستگاه به نیاز واقعی آن است.
آیا Secure Boot و امضای دیجیتال کافی هستند؟
راه‌اندازی امن یا Secure Boot، اعتبار مؤلفه‌های راه‌اندازی را در چارچوب زنجیره اعتماد پیکربندی‌شده بررسی می‌کند. امضای دیجیتال نیز می‌تواند منشأ فایل و تغییرنکردن آن پس از امضا را مشخص کند، اما به‌تنهایی سلامت محتوا را ثابت نمی‌کند.
اگر کد مخرب با کلیدی مورداعتماد امضا شده باشد، اعتبار امضا به‌تنهایی نشانه بی‌خطر بودن آن نیست. این توضیح، تحلیل عمومی سازوکار اعتماد است و نباید به‌عنوان اثبات دورزدن Secure Boot در تمام دستگاه‌های آلوده به XCPE برداشت شود.
چک‌لیست کاهش ریسک میان‌افزار آلوده در سازمان
اقدام‌های این بخش برای مدیریت خطر میان‌افزار آلوده پیشنهاد می‌شوند. اولویت اجرا را بر اساس حساسیت تجهیز، ارتباط آن با سامانه‌های داخلی و شواهد فنی تعیین کنید. جدول زیر، اقدام پیشنهادی در هر مرحله و خروجی قابل ثبت آن را نشان می‌دهد. نتیجه بررسی‌ها را در سوابق پذیرش و نگهداری دستگاه ثبت کنید.
| مرحله بررسی | اقدام پیشنهادی | خروجی قابل ثبت |
|---|---|---|
| پیش از خرید | شناسایی توسعه‌دهنده میان‌افزار و مسئول اصلاحیه‌ها | مشخصات تأمین‌کننده و تعهد پشتیبانی امنیتی |
| پذیرش فنی | بررسی بسته‌های سیستمی و رفتار ارتباطی دستگاه | فهرست سرویس‌ها، مجوزها و مقصدهای ارتباطی |
| بهره‌برداری | محدودسازی ارتباطات و جداسازی تجهیزات حساس | قواعد دسترسی و سوابق پایش ترافیک خروجی |
| به‌روزرسانی | بررسی اصالت بسته و آزمایش نسخه جایگزین | نتیجه آزمون و تأیید نسخه قابل استقرار |
| واکنش به حادثه | جداسازی دستگاه و ارزیابی پاک‌سازی یا تعویض | شواهد آلودگی و تصمیم نهایی درباره تجهیز |
برای اجرای اقدام‌های جدول، از بررسی تأمین‌کننده در زمان خرید شروع کنید و ارزیابی را در طول بهره‌برداری ادامه دهید. موارد زیر توضیح می‌دهند در هر مرحله چه چیزی را بررسی کنید و چه اطلاعاتی برای پیگیری فنی و واکنش به حادثه ثبت شود.
۱. منشأ میان‌افزار را مشخص کنید
در فرایند خرید، توسعه‌دهنده میان‌افزار، نهاد امضاکننده و مسئول انتشار اصلاحیه امنیتی را مشخص کنید. دریافت فهرست مؤلفه‌های نرم‌افزاری یا SBOM به شناخت وابستگی‌ها کمک می‌کند، اما جای ارزیابی فنی محصول را نمی‌گیرد. مشخصات تأمین‌کنندگان و تعهد پشتیبانی آن‌ها را ثبت کنید.
۲. رفتار دستگاه را آزمایش کنید
پیش از بهره‌برداری، بسته‌های سیستمی، سرویس‌های دارای دسترسی ویژه و ارتباطات خروجی دستگاه را در محیط آزمایشی بررسی کنید. آزمون را پس از نخستین اتصال به اینترنت و دریافت به‌روزرسانی نیز انجام دهید. سرویس‌های فعال، مجوزها و مقصدهای ارتباطی مشاهده‌شده را ثبت کنید.
۳. دسترسی شبکه را محدود کنید
ارتباط دستگاه را به مقصدها و سرویس‌های موردنیاز محدود کنید. جداسازی اینترنت از شبکه داخلی و تفکیک شبکه می‌توانند تماس دستگاه مشکوک با سامانه‌های حساس را کاهش دهند. حضور در شبکه داخلی، دلیل کافی برای دسترسی گسترده نیست. قواعد دسترسی و ارتباطات مجاز تجهیز را ثبت کنید.
۴. نسخه جایگزین را ارزیابی کنید
پیش از نصب، منبع انتشار، اصالت بسته و تغییرات نسخه جایگزین را بررسی کنید. برای تجهیزات حساس، نسخه جدید را ابتدا آزمایش کنید و برنامه بازیابی را بر پایه میان‌افزاری سالم و پشتیبانی‌شده تدوین کنید. نتیجه آزمون و نسخه تأییدشده برای استقرار عملیاتی را ثبت کنید. مطلب الزامات پایش به‌روزرسانی خودکار تجهیزات به بررسی این فرایند کمک می‌کند.
۵. برنامه واکنش را تدوین کنید
در صورت مشاهده شواهد آلودگی، دستگاه را طبق برنامه واکنش به حادثه از بخش‌های حساس جدا کنید. شواهد فنی را پیش از تغییراتی که ممکن است آن‌ها را از بین ببرند، حفظ کنید. سلامت میان‌افزار جایگزین را بررسی کنید و اگر پاک‌سازی قابل‌اعتماد ممکن نبود، تعویض تجهیز را در نظر بگیرید. نتیجه بررسی و تصمیم نهایی را ثبت کنید.
اختلال در بات‌نت XCPE چه تفاوتی با پاک‌سازی دستگاه دارد؟
عملیات مشترک شرکت‌های امنیتی و پلیس ملی ژاپن، زیرساخت کنترل این شبکه را هدف گرفت. بااین‌حال، قطع ارتباط با سرورهای شناخته‌شده، عامل نصب‌شده روی تجهیزات را خودبه‌خود حذف نمی‌کند. در گزارش پژوهشی TrendAI درباره تجهیزات از پیش آلوده تأکید شده است که رسیدگی به این آلودگی ممکن است به اقدام سازنده، حفاظت پلتفرم یا جایگزینی دستگاه نیاز داشته باشد.
گوگل همچنین از قطع همکاری با Videostrong و منع این شرکت و زیرمجموعه‌ها یا وابستگان آتی آن از ساخت و فروش دستگاه‌های دارای گواهی اندروید یا تأمین نرم‌افزار برای دیگر عرضه‌کنندگان دارای گواهی خبر داده است. این اقدام، بخشی از پاسخ به نقض اعتماد در زنجیره تأمین بوده است.
اختلال بات‌نت دسترسی گردانندگان را هدف می‌گیرد؛ پاک‌سازی دستگاه به حذف عامل آلودگی و تأیید دوباره سلامت تجهیز نیاز دارد.
امنیت تجهیزات از پذیرش فنی آغاز می‌شود
پرونده بدافزار XCPE نشان می‌دهد ارزیابی امنیت دستگاه باید نرم‌افزار پایه آن را نیز در بر بگیرد. سلامت میان‌افزار، مقصد ارتباطات و امکان بازیابی باید قابل‌بررسی باشند. انجام وظیفه اصلی دستگاه، جای بررسی امنیتی آن را نمی‌گیرد.
برای سازمان‌ها، تصمیم قابل‌اتکا به ثبت مشخصات تجهیز، شناخت مسئول پشتیبانی و ارزیابی رفتار آن در طول بهره‌برداری وابسته است. اگر شواهد آلودگی وجود داشته باشد، ادامه استفاده باید بر اساس ارزیابی ریسک و وجود یک مسیر اصلاحی معتبر تعیین شود.
