جزئیات آسیب پذیری بحرانی دفترکل XRP و وصله فوری

چه اتفاقی افتاد و چرا اهمیت دارد

تیم دفترکل XRP (XRPL) یک آسیب‌پذیری بحرانی را در موتور پرداخت این شبکه افشا و وصله کرد؛ نقصی که در بدترین سناریو می‌توانست به مهاجم اجازه دهد مقدار قابل خرجی از XRP را بسیار فراتر از سقف سخت ۱۰۰ میلیارد واحدی پروتکل ایجاد کند. این باگ از کدهای قدیمی سال ۲۰۱۵ سرچشمه می‌گرفت و طی آزمون‌های امنیتی خودکار توسط Veria AI و پژوهشگر امنیتی Cayden Liao شناسایی شد. مشارکت‌کنندگان XRPL و RippleX یک به‌روزرسانی نرم‌افزاری اضطراری با نام xrpld 3.4.1 منتشر کردند و اعتبارسنج‌ها به‌سرعت برای نصب اصلاحیه اقدام کردند. این رخداد درس‌های مهمی درباره امنیت متن‌باز، افشای مسئولانه و هماهنگی اعتبارسنج‌ها در شبکه‌های بلاکچینی برجسته می‌کند.

نکات کلیدی

واقعیت‌های فوری

• این باگ یک سرریز عدد صحیح ۶۴ بیتی در موتور پرداخت XRPL بود که پرداخت‌های چندپیشنهادی و تعاملات دفتر سفارشات را پردازش می‌کرد.
• پژوهشگران امنیتی یک نمونه اثبات مفهوم ارائه کردند که نشان می‌داد در شرایط آزمایشگاهی، با یک تراکنش ویژه‌سازی‌شده می‌توان حدود ۱۸ تریلیون XRP تولید کرد. این مقدار تقریبا ۱۸۴ برابر عرضه هدف‌گذاری‌شده ۱۰۰ میلیارد واحدی دفترکل است.
• مشارکت‌کنندگان XRPL نسخه xrpld 3.4.1 را به‌عنوان وصله اضطراری منتشر کردند و بیش از ۸۰٪ اعتبارسنج‌های پیش‌فرض طی چند روز آن را ارتقا دادند و از سوءاستفاده در شبکه اصلی جلوگیری شد.
• بنیاد XRPL و RippleX اعلام کردند هیچ نشانه‌ای از استفاده از این آسیب‌پذیری در شبکه‌های عمومی وجود ندارد و هیچ دارایی کاربری یا کلید خصوصی به خطر نیفتاده است.
• پژوهشگری که این مسئله را از طریق برنامه رسمی باگ‌بانتی گزارش کرده بود، حداکثر پاداش ۲۵۰ هزار دلاری را دریافت کرد.

این آسیب‌پذیری چگونه کار می‌کرد: توضیح فنی

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

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

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

کشف و افشا: خط زمانی

۲۱ سپتامبر ۲۰۲۶

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

۲۲ سپتامبر ۲۰۲۶

پژوهشگران یک نمونه اثبات مفهوم عملی را در محیط تست‌نت محلی ساختند و سازوکار و مقیاس بالقوه مشکل را نشان دادند. Cayden Liao این یافته را از مسیر افشای هماهنگ به برنامه باگ‌بانتی XRPL ارسال کرد.

۲۳ سپتامبر ۲۰۲۶

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

۲۵ سپتامبر ۲۰۲۶

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

۸ اکتبر ۲۰۲۶

Veria AI حداکثر پاداش باگ‌بانتی ۲۵۰ هزار دلاری را برای افشای مسئولانه دریافت کرد.

۹ اکتبر ۲۰۲۶

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

استقرار اضطراری و پیامدهای حاکمیتی

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

برای کاهش ریسک فوری، توسعه‌دهندگان و اپراتورهای اعتبارسنج یک ارتقای اضطراری را هماهنگ کردند: اصلاحیه به محض نصب xrpld 3.4.1 توسط اعتبارسنج‌ها موثر شد. این مسیر اضطراری مصالحه‌های عملیاتی خود را دارد، از جمله خطر اختلاف موقت در صورتی که اعتبارسنج‌ها نسخه‌های نرم‌افزاری متفاوتی اجرا کنند. حامیان شبکه تاکید کردند این تصمیم با مشورت اپراتورهای اعتبارسنج، RippleX و بنیاد XRPL گرفته شد و کاهش سریع ریسک را بر زمان‌بندی معمول اصلاحیه ترجیح دادند. تا ۲۵ سپتامبر، بیش از ۸۰٪ اعتبارسنج‌های پیش‌فرض ارتقا داده بودند و از دوره طولانی مواجهه با خطر جلوگیری شد.

آسیب‌پذیری تراکنش گروهی و عرضه اصلاح‌شده

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

اگر قابلیت تراکنش گروهی با این ناسازگاری اعتبارسنجی حل‌نشده فعال می‌شد، شبکه ممکن بود با اختلال اجماع روبه‌رو شود. توسعه‌دهندگان XRPL اصلاحیه fixBatchV1_2 را معرفی کردند که قالب فیلد تاییدشده را الزام‌آور می‌کند و ورودی‌های گروهی بدفرم را رد می‌کند. در نتیجه، توسعه‌دهندگان زمان‌بندی فعال‌سازی اولیه BatchV1_1 را به تعویق انداختند تا اصلاح اعمال شود. هر دو اصلاحیه fixBatchV1_2 و BatchV1_1 پس از کسب حمایت کافی اعتبارسنج‌ها در ۹ اکتبر روی شبکه اصلی فعال شدند. سرورهایی که هنوز نسخه‌های قدیمی‌تر را اجرا می‌کنند اکنون به دلیل اصلاحیه مسدود شده‌اند و برای باقی ماندن در اجماع باید به xrpld 3.4.1 یا نسخه‌های جدیدتر ارتقا یابند.

آیا واقعا XRP در شبکه اصلی ایجاد شد؟

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

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

چرا این باگ برای سلامت بازار اهمیت داشت

عرضه ثابت ۱۰۰ میلیارد واحدی XRPL یکی از ویژگی‌های بنیادینی است که صرافی‌ها، متولیان نگهداری دارایی، بازارسازان و معامله‌گران خرد به آن اتکا می‌کنند. هر مسیر معتبر برای ایجاد XRP قابل خرج جدید می‌توانست کمیابی دفترکل، مانده صرافی‌ها و ثبات قیمت را زیر سوال ببرد. از منظر برآوردهای نظری، پژوهشگران امنیتی میزان ریسک را با ارجاع به ارزش بازار نزدیک به زمان کشف تخمین زدند. با این حال، آن عدد نشان‌دهنده ریسک مالی بالقوه بود، نه زیان تحقق‌یافته.

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

واکنش جامعه و گام‌های بعدی

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

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

این موضوع برای صرافی‌ها، متولیان نگهداری و کاربران چه معنایی دارد

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

درس‌هایی برای امنیت بلاکچین

چند درس گسترده‌تر از این رخداد به دست می‌آید:

• کدهای قدیمی می‌توانند آسیب‌پذیری‌های سیستمی را پنهان کنند. حتی پروژه‌های متن‌باز جاافتاده و معتبر نیز به ممیزی‌های خودکار و دستی مستمر نیاز دارند.
• افشای هماهنگ و پاداش‌های معنادار باگ‌بانتی، نتایج بهتری نسبت به افشای عمومی بدون راهکار کاهش ریسک ایجاد می‌کنند. پاداش ۲۵۰ هزار دلاری در این مورد، انگیزه لازم برای مدیریت مسئولانه یک مسئله بسیار حساس را فراهم کرد.
• سازوکارهای حاکمیتی باید میان تمرکززدایی و ایمنی تعادل برقرار کنند. سامانه‌های اصلاحیه از تغییرات یک‌جانبه جلوگیری می‌کنند، اما می‌توانند واکنش‌های اضطراری را کند کنند. جامعه XRPL برای کاهش مواجهه با ریسک، یک مسیر اضطراری عمل‌گرایانه را انتخاب کرد.
• ریسک‌های اجماع میان نسخه‌ای برای هر قابلیتی که معناشناسی تراکنش را تغییر می‌دهد، نیازمند توجه ویژه است. آسیب‌پذیری تراکنش گروهی بار دیگر ضرورت عرضه محتاطانه و آگاه از نسخه‌ها را نشان داد.

جمع‌بندی نهایی

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

برای معامله‌گران، توسعه‌دهندگان و نهادهایی که با XRPL تعامل دارند، این رخداد یادآور آن است که سامانه‌های بلاکچینی نیز پروژه‌های نرم‌افزاری هستند و به هوشیاری امنیتی مداوم نیاز دارند. همچنین نشان می‌دهد وقتی آسیب‌پذیری‌ها به‌صورت مسئولانه کشف شوند، اکوسیستم می‌تواند واکنشی موثر داشته باشد.

برای دریافت به‌روزرسانی‌ها درباره نسخه‌های xrpld، راهنمایی اعتبارسنج‌ها و هرگونه هشدار تازه مرتبط با دفترکل XRP، همچنان منابع تاییدشده بنیاد XRPL، RippleX و رسانه‌های معتبر اخبار ارز دیجیتال را دنبال کنید.