از لجر تا بیت‌گت: امنیت کریپتو، چه «نقاط کوری» نادیده گرفته شده‌ای وجود دارد؟

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

نویسنده: imToken

یک کیف پول سخت‌افزاری که چیپ‌ست اصلی آن سالم و فریم‌ور آن اصل است و حتی می‌تواند به راحتی از طریق تأیید اعتبار رسمی (Genuine Check) تأیید شود، ممکن است دارایی‌های داخل آن همچنان توسط هکرها دزدیده شود؟

اخیراً حادثه امنیتی لجر، این خطر به ظاهر غیرممکن را به وضوح نشان داد.

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

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

علاوه بر این، این تنها حادثه امنیتی قابل توجه در این مدت نیست.

از سپتامبر، از بهره‌برداری از آسیب‌پذیری محصولات امنیتی شخص ثالث در بیت‌گت گرفته تا هک شدن ارائه‌دهنده خدمات ایمیل Trezor به نام Brevo و ظهور مشکلات امنیتی در برخی زیرساخت‌های MetaMask، یک سری از حوادث به ما یادآوری می‌کند که با پیچیده‌تر شدن محصولات کریپتو، امنیت دیگر تنها به حفاظت از کلید خصوصی و جلوگیری از آسیب‌پذیری‌های قراردادهای هوشمند محدود نمی‌شود.

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

یک. زنگ خطر جدید «امنیت زنجیره تأمین» که لجر به صدا درآورد

بیایید ابتدا به تجزیه و تحلیل حادثه لجر بپردازیم.

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

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

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

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

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

بدتر از آن، حتی اگر دستگاه از تأیید اعتبار رسمی Genuine Check عبور کند، ممکن است نتواند این سخت‌افزار اضافی را شناسایی کند، زیرا تأیید اعتبار اصلی عمدتاً بر روی شناسایی هویت چیپ امنیتی و اعتبار فریم‌ور متمرکز است.

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

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

دو. از Trezor تا Bitget: مهاجمان چگونه از خط دفاعی اصلی عبور می‌کنند؟

با درک مشکل لجر، حالا به حوادث امنیتی اخیر در Bitget و Trezor نگاه می‌کنیم و متوجه می‌شویم که منطق زیرین به طرز شگفت‌انگیزی مشابه است: مهاجمان نیز از خط دفاعی محکم عبور کرده و از «خدمات شخص ثالث» در حاشیه وارد شده‌اند.

ابتدا به Trezor نگاه کنیم.

در اوایل سپتامبر، برخی از کاربران Trezor ایمیلی با موضوع «هشدار امنیتی بحرانی: آسیب‌پذیری تصادفی STM32» دریافت کردند که ادعا می‌کرد کیف پول سخت‌افزاری دارای آسیب‌پذیری امنیتی جدی است و باید فوراً اقداماتی انجام شود.

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

این دقیقاً همان چیزی است که مهاجمان از پلتفرم بازاریابی ایمیل شخص ثالث Trezor به نام Brevo استفاده کردند تا محتوای مخرب را از طریق زیرساخت‌های ارسال ایمیل عادی به صندوق ورودی کاربران برسانند.

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

Trezor سپس تأیید کرد که 347149 آدرس مخاطب ایمیل‌های بازاریابی در این حادثه استخراج شده است و ایمیل‌های حمله سعی کردند کاربران را به دانلود برنامه‌های مخرب و وارد کردن اطلاعات پشتیبان کیف پول ترغیب کنند.

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

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

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

حالا به Bitget نگاه کنیم.

در 24 سپتامبر، برخی از کیف پول‌های داغ و گرم Bitget دچار انتقال دارایی غیرمجاز شدند و در نهایت تأیید شد که حدود 3.88 میلیون دلار تحت تأثیر قرار گرفته است.

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

Bitget اعلام کرد که در این حادثه هیچ نشانه‌ای از افشای کلید خصوصی وجود ندارد و کیف پول سرد نیز تحت تأثیر قرار نگرفته است. این به نظر می‌رسد که کمی متناقض باشد: اگر کلید خصوصی دزدیده نشده، چرا پول می‌تواند منتقل شود؟

در واقع، این موضوع دشوار نیست که درک کنیم.

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

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

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

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

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

با این حال، این به این معنا نیست که بروز مشکل در زیرساخت‌ها تأثیرات دیگری نخواهد داشت. راه‌حل‌های غیرنگهداری عمدتاً به مسئله کنترل دارایی مربوط می‌شوند، اما نمی‌توانند به‌طور خودکار خطرات عملیاتی زیرساخت‌های خارجی را از بین ببرند.

با کنار هم قرار دادن این چند مورد، خط سیر واقعاً بسیار واضح است:

• لجر خطر تغییر فیزیکی در مراحل جریان سخت‌افزاری را به نمایش گذاشت که ممکن است منجر به سرقت عبارت یادآور شود؛
• Trezor / Brevo خطر افشای اطلاعات کاربران و سوءاستفاده از کانال‌های ارتباطی رسمی را به نمایش گذاشت که به معنای نفوذ به کیف پول نیست؛
• Bitget خطر انتقال آسیب‌پذیری‌های محصولات شخص ثالث به سیستم‌های داخلی با دسترسی بالا را به نمایش گذاشت که می‌تواند به‌طور مستقیم بر اجرای وجوه تأثیر بگذارد؛
• MetaMask نیز به ما یادآوری می‌کند که کنترل دارایی و خطرات عملیاتی خدمات یک مفهوم نیستند.

به‌طور کلی، محصولات کریپتو امروز دیگر جزایر جداگانه‌ای نیستند.

کیف پول‌ها باید برای خواندن داده‌های زنجیره‌ای به گره‌های RPC خارجی متکی باشند، برای کشف قیمت‌ها به رابط‌های تجمیع متکی باشند؛ صرافی‌ها به نظارت امنیتی خارجی، تأیید KYC و اجزای کنترل ریسک وابسته هستند؛ و فراتر از آن، اپراتورهای گره، ارائه‌دهندگان ابری، بلیط‌های خدمات مشتری و سیستم‌های ایمیل مانند Brevo وجود دارند.

این خدمات خارجی باعث می‌شوند که محصولات به‌طور مؤثرتری عمل کنند و تجربه کاربری را بهبود بخشند، اما در عین حال، هر بار که یک وابستگی خارجی جدید وارد می‌شود، محصول یک لایه دیگر از روابط اعتماد را که باید مدیریت شود، اضافه می‌کند:

خدمات شخص ثالث چه دسترسی‌هایی دارند، چه میزان مجوزی دارند و آیا در صورت شکست، آیا خطرات به سیستم‌های اصلی دیگر منتقل می‌شوند یا خیر؟

سه. محصولات و کاربران چگونه باید از خود محافظت کنند؟

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

آزمایش واقعی قدرت معماری امنیتی، کاهش هر یک از نقاط خطر ممکن است.

به عنوان مثال، یک ارائه‌دهنده خدمات SaaS که فقط مسئول ارسال ایمیل‌های بازاریابی است، چرا باید داده‌های تماس تمام کاربران را برای مدت طولانی نگه دارد؟ ابزارهای نظارت امنیتی شخص ثالث، چرا باید بدون مجوزهای مستقل و چندگانه به محیط تولید اصلی دسترسی داشته باشند؟ به‌ویژه در مورد اقدامات حساس مربوط به انتقال وجوه، سیستم‌های داخلی هرگز نباید «اعتماد پیش‌فرض» داشته باشند و باید جداسازی مجوزها و تأیید متقابل مستقل را به‌طور جدی انجام دهند.

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

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

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

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

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

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

اولاً، سعی کنید در فرآیند خرید کیف پول سخت‌افزاری، انتقال‌های غیرضروری را کاهش دهید.

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

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

دوماً، نیاز است که دوباره درک کنیم که آیا «اخبار رسمی» قابل اعتماد است یا خیر.

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

به‌ویژه در مورد به‌روزرسانی کیف پول، مسدود کردن حساب، انتقال دارایی، رفع آسیب‌پذیری‌ها و سایر عملیات حساس، بهتر است به‌جای کلیک بر روی لینک‌های موجود در پیام، از آدرس وب‌سایت خودتان یا برنامه رسمی که قبلاً نصب کرده‌اید، برای تأیید استفاده کنید.

برای کیف پول‌های غیرنگهداری مانند imToken، کاربران نیز باید به کانال‌های رسمی توجه کنند و برنامه را از token.im دانلود و نصب کنند و در صورت مواجهه با اطلاعات غیرعادی، ابتدا از طریق ورودی‌های رسمی مانند «کمک و بازخورد» در برنامه تأیید کنند.

چه طرف مقابل خود را به عنوان خدمات مشتری رسمی، تیم امنیتی معرفی کند یا توضیحات آسیب‌پذیری به‌ظاهر حرفه‌ای ارائه دهد، نباید به آن‌ها عبارت یادآور یا کلید خصوصی را افشا کرد.

در نهایت، باید تفاوت تأثیرات مختلف حوادث امنیتی بر خود را شناسایی کنیم.

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

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

و در مورد نقص خدمات شخص ثالث یا مشکلات زیرساختی، باید به دامنه تأثیرات منتشر شده توسط مقامات رسمی توجه کنید و بررسی کنید که آیا شامل دارایی‌های خود، قابلیت استفاده از خدمات یا درآمد شما می‌شود یا خیر.

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

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

در پایان

در گذشته، یکی از جملات پرکاربرد در صنعت کریپتو این بود که «کلیدهای شما، سکه‌های شما نیستند».

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

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

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

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

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