چه اتفاقی افتاد و چرا مهم است
تیم دفترکل XRP (XRPL) یک آسیبپذیری حیاتی در موتور پرداخت شبکه را کشف و برطرف کرد که در بدترین حالت میتوانست به یک مهاجم اجازه دهد میزان قابلمصرف XRP را بسیار فراتر از سقف سختکدشده ۱۰۰ میلیارد ایجاد کند. این باگ از کدی قدیمی متعلق به ۲۰۱۵ سرچشمه میگرفت و در جریان آزمایشهای امنیتی خودکار توسط شرکت Veria AI و پژوهشگر امنیتی کیدن لیا کشف شد. مشارکتکنندگان XRPL و RippleX یک بهروزرسانی اضطراری نرمافزاری، xrpld 3.4.1، منتشر کردند و اعتباردهندهها سریعاً این اصلاح را نصب کردند. این رخداد درسهای مهمی درباره امنیت متنباز، افشای مسئولانه و هماهنگی اعتباردهندهها در شبکههای بلاکچینی ارائه داد.
نکات کلیدی
حقایق فوری
- باگ ناشی از سرریز عدد صحیح ۶۴ بیتی در موتور پرداخت XRPL بود که پرداختهای چندپیشنهادی و تعاملات دفتر سفارش را مدیریت میکرد.
- پژوهشگران یک نمونه اثباتپذیر ساختند که نشان داد در شرایط آزمایشگاهی میتوان حدود ۱۸ تریلیون XRP توسط یک تراکنش ویژه تولید کرد. این مقدار تقریباً برابر با ۱۸۴ برابر عرضه مورد نظر دفترکل یعنی ۱۰۰ میلیارد است.
- مشارکتکنندگان XRPL xrpld 3.4.1 را بهعنوان یک وصله اضطراری منتشر کردند و بیش از ۸۰٪ از اعتباردهندههای پیشفرض طی چند روز ارتقا دادند که از بهرهبرداری در شبکه اصلی جلوگیری کرد.
- بنیاد XRPL و RippleX گزارش دادند هیچ مدرکی دال بر استفاده از این آسیبپذیری در شبکههای عمومی وجود ندارد و هیچ وجوه کاربری یا کلید خصوصی فاش نشده است.
- پژوهشگری که مسئله را از طریق برنامه رسمی جایزه باگ گزارش کرد، پاداش حداکثری ۲۵۰٬۰۰۰ دلاری را دریافت کرد.
نحوه عملکرد آسیبپذیری: توضیح فنی
این نقص از محدودیتهای محاسباتی در کد قدیمی ناشی میشد که پرداختهایی را که روی چند پیشنهاد در صرافی غیرمتمرکز و دفتر سفارش گسترده میشوند، مدیریت میکرد. وقتی موتور پرداخت XRPL مقادیر XRP را از روی چندین پیشنهاد جمع میکرد، برای محاسبه مجموع مبلغی که یک خریدار باید در یک تسویه چندپیشنهادی بپردازد از یک عدد صحیح ۶۴ بیتی استفاده میکرد.

سرریز عدد صحیح زمانی رخ میدهد که یک محاسبه از بیشترین مقداری که در نوع عدد صحیح انتخابشده قابلذخیره است، فراتر رود. در این مورد، پژوهشگران نشان دادند یک مهاجم میتواند صدها پیشنهاد با قیمتهای ویژه قرار دهد و یک تراکنش اتمیک واحد بسازد که بسیاری از آنها را مصرف کند. اگر مجموع تجمعی از حد ۶۴ بیتی فراتر رود، مقدار عدد ممکن است به یک عدد بسیار کوچکتر بازگردد. موتور سپس بهاشتباه اجازه پردازش پرداخت را میداد در حالی که فروشندگان هنوز با مبالغ کامل پیشنهادها اعتبار داده میشدند. اختلاف بین مقدار خریداریشدهای که بازگشته بود و اعتبار کامل فروشندگان عملاً XRP جدیدی را از هیچ ایجاد میکرد.
مهم است تأکید شود که این سناریوی تجاری معمولی نبود. بهرهبرداری نیازمند یک توالی عمدی بود: ساخت حسابها و پیشنهادهای متعدد با قیمتهای افراطی، سپس اجرای یک تراکنش واحد و دقیق برای ایجاد سرریز. روند بررسی عرضه نیز از همان محاسبات استفاده میکرد، بنابراین XRP ایجادشده را شناسایی نکرد. علاوه بر این، ماندههای تازهتولیدشده میتوانست در حسابهای متعدد توزیع شود تا از چکهای سادهٔ موجودی عبور کند.
کشف و افشا: خط زمانی
۲۱ سپتامبر ۲۰۲۶
ابزارهای امنیتی خودکار Veria AI یک وضعیت بالقوه خطرناک در کد متنباز XRPL علامتگذاری کردند. فازهای فازینگ خودکار و تستهای هدفمند سناریوی سرریز عدد صحیح را آشکار ساختند.
۲۲ سپتامبر ۲۰۲۶
پژوهشگران یک اثباتپذیر عملی روی یک شبکه آزمایشی محلی ساختند که مکانیک و مقیاس بالقوه مسئله را نشان داد. کیدن لیا یافته را از طریق افشای هماهنگشده به برنامه جایزه باگ XRPL ارسال کرد.
۲۳ سپتامبر ۲۰۲۶
مهندسان RippleX رفتار را روی یک سرور منزوی بازتولید کردند و تأیید کردند که یک پرداخت چندپیشنهادی ساختهشده میتواند در یک تراکنش بعدی XRP قابلمصرف تولید کند.
۲۵ سپتامبر ۲۰۲۶
پس از مهندسی و بررسی سریع، جامعه XRPL xrpld 3.4.1 را بهعنوان یک بهروزرسانی امنیتی اضطراری منتشر کرد. وصله بررسیهای دفاعی برای جلوگیری از محاسباتی که از دامنه مجاز عدد صحیح فراتر میروند اضافه کرد و محاسبات شکننده را با شمارندههای گستردهتر جایگزین کرد تا تأیید عرضه تقویت شود.
۸ اکتبر ۲۰۲۶
Veria AI جایزه حداکثری ۲۵۰٬۰۰۰ دلاری بابت افشای مسئولانه را دریافت کرد.
۹ اکتبر ۲۰۲۶
یک افشای تکمیلی به یک مسئله تأیید جداگانه مربوط به قابلیت تراکنش گروهی (Batch) پرداخت که همان روز وصله و بهصورت ایمن فعال شد.
استقرار اضطراری و پیامدهای حاکمیتی
XRPL تغییرات پروتکل را از طریق سیستم اصلاح (amendment) خود اعمال میکند که معمولاً بیش از ۸۰٪ پشتیبانی از اعتباردهندههای مورد اعتماد را برای دو هفته متوالی قبل از فعالسازی لازم دارد. از آنجا که انتشار یک وصله در مخزن عمومی میتواند هم نقص و هم اصلاح آن را فاش کند، جامعه XRPL قضاوت کرد که انتظار در چارچوب جدول زمانی اصلاح معمولی یک پنجره ریسک غیرقابلقبول ایجاد میکرد. مهاجمان میتوانستند اصلاح عمومی را بررسی کرده و در حالی که اصلاح در انتظار بود، به ساخت بهرهبرداریها بپردازند.
برای کاهش ریسک فوری، توسعهدهندگان و اپراتورهای اعتباردهنده یک ارتقای اضطراری را هماهنگ کردند: اصلاح به محض نصب xrpld 3.4.1 توسط اعتباردهندهها مؤثر شد. این مسیر اضطراری همراه با مصالحههای عملیاتی است، از جمله احتمال اختلاف موقت اگر اعتباردهندهها نسخههای نرمافزاری متفاوتی اجرا کنند. حامیان شبکه تأکید کردند تصمیم آنها با مشورت اپراتورهای اعتباردهنده، RippleX و بنیاد XRPL اتخاذ شد و اولویت آنها کاهش سریع خطر نسبت به جدول زمانی معمول اصلاح بود. تا ۲۵ سپتامبر بیش از ۸۰٪ اعتباردهندههای پیشفرض ارتقا دادند و از یک دوره در معرض طولانی جلوگیری شد.
آسیبپذیری تراکنش گروهی و اجرای اصلاحشده
افشای ۹ اکتبر شامل یک مسئله جداگانه در قابلیت تراکنش گروهی (Batch) بود. Batch اجازه میدهد تا تا هشت تراکنش در یک عملیات اتمیک گروهبندی شوند. در طول آزمایش، پژوهشگران یک ناهماهنگی تأییدی در نحوه بستهبندی تراکنشهای منفرد درون یک Batch پیدا کردند. بهطور مشخص، پروتکل انتظار دارد فیلد RawTransaction برای هر مؤلفه وجود داشته باشد. تحت شرایط خاص، نامهای فیلدی جایگزین ممکن بود توسط برخی نسخههای سرور پذیرفته شود که خطر اختلاف بین نسخهها درباره اعتبار تراکنش را در پی داشت.
اگر Batch با این تناقض تأییدی حلنشده فعال میشد، شبکه ممکن بود با اخلال در اجماع مواجه شود. توسعهدهندگان اصلاح fixBatchV1_2 را معرفی کردند که قالب فیلدی مورد تأیید را الزام میکند و ورودیهای نامنظم Batch را رد مینماید. در نتیجه، توسعهدهندگان برنامه فعالسازی اولیه BatchV1_1 را بهمنظور اعمال اصلاح به تعویق انداختند. هر دو fixBatchV1_2 و BatchV1_1 در ۹ اکتبر روی شبکه اصلی پس از کسب حمایت کافی اعتباردهندهها فعال شدند. سرورهایی که همچنان نسخههای قدیمی را اجرا میکنند اکنون توسط اصلاح مسدود شدهاند و باید برای باقیماندن در اجماع به xrpld 3.4.1 یا نسخههای جدیدتر ارتقا یابند.
آیا واقعاً XRP روی شبکه اصلی ایجاد شد؟
هیچ مدرک تأییدشدهای وجود ندارد که نشان دهد XRP بهصورت غیرقانونی روی شبکههای عمومی ایجاد یا منتقل شده باشد. پژوهشگران بهرهبرداری را صرفاً در یک محیط کنترلشده نشان دادند. مشارکتکنندگان XRPL، RippleX و بنیاد XRPL تاریخچه دفترکل و رفتار شبکه را بررسی کردند و هیچ نشانهای از تورم غیرمجاز ارز گزارش ندادند. هیچیک از کاربران وجوه خود را از دست نداده و کلید خصوصیای فاش نشده است.
با وجود عدم بهرهبرداری عمومی، شدت مسئله به سطح حیاتی ارتقا یافت بهخاطر میزان بالقوه تورم عرضه و امکانپذیری مهندسی شرایط چندپیشنهادی توسط یک مهاجم.
چرا این باگ برای یکپارچگی بازار اهمیت داشت
عرضه ثابت ۱۰۰ میلیاردی XRPL یک ویژگی محوری است که توسط صرافیها، نگهبانان، بازارسازها و معاملهگران خرد مورد اتکا است. هر مسیر قابلباور برای ایجاد XRP جدید قابلمصرف، میتواند کمیابی دفترکل، ماندههای صرافی و ثبات قیمت را زیر سؤال ببرد. بهصورت تخمینی، پژوهشگران امنیتی قرار گرفتن در معرض را با ارجاع به یک رقم سرمایه بازار در زمان کشف برآورد کردند. با این حال این عدد نشانگر ریسک مالی بالقوه بود، نه زیان محققشده.
کشف سریع و وصله اضطراری هماهنگشده از یک پنجره بهرهبرداری که میتوانست اعتماد بازار را تهدید کند جلوگیری کرد. پرداخت جایزه باگ و فرایند افشای شفاف نیز مدلی برای گزارش مسئولانه آسیبپذیریها در فضای رمزنگاری تقویت کرد.
واکنش جامعه و گامهای بعدی
بنیاد XRPL تغییراتی در فرایند تأیید انتشار خود اعلام کرده است. از این پس، مسائل امنیتی قبلاً گزارششده باید پیش از اینکه یک اصلاح بهعنوان حلشده شناخته شود، مجدداً در برابر نسخههای کاندید انتشار آزمایش شوند. این الزام اضافی تأییدی شامل یافتههای حاصل از حسابرسیها، ارسالهای برنامه جایزه باگ، تستهای امنیتی مبتنی بر هوش مصنوعی و دیگر ارزیابیها خواهد بود. هدف این اقدام پوشاندن شکافهای بین کشف و رفع موفق و کاهش احتمال بازگشت مجدد مشکل است.
اپراتورهای اعتباردهنده اهمیت حفظ نرمافزار بهروز و مشارکت در ارتقاهای بهموقع را تأکید کردهاند. این حادثه همچنین مزایای تست امنیتی خودکار، افشای هماهنگ و انگیزههای مالی برای پژوهشگران کلاهسفید را برجسته کرد.
این برای صرافیها، نگهبانان و کاربران چه معنایی دارد
- صرافیها و نگهبانان باید تأیید کنند که به اعتباردهندههایی تکیه دارند که نسخههای xrpld بهروز را اجرا میکنند و فرایندهای واریز و برداشت آنها وضعیت دفترکل را بهصورت مستمر تأیید میکند.
- توسعهدهندگانی که روی XRPL کار میکنند باید محیطهای آزمایشی را ارتقا داده و مسیرهای کدی که با دفتر سفارش، پرداختهای چندپیشنهادی و صرافی غیرمتمرکز تعامل دارند را ممیزی کنند تا اطمینان حاصل شود که موارد مرزی بهصورت ایمن مدیریت میشوند.
- کاربران باید اطمینان حاصل کنند که هیچ بهرهبرداری شناختهشدهای روی شبکه اصلی رخ نداده، اما باید به رعایت اصول پایهای امنیت مانند استفاده از کیفپولهای مورد اعتماد و مدیریت امن کلیدها ادامه دهند.
درسهایی برای امنیت بلاکچین
چند درس کلی از این رخداد استخراج میشود:
- کد قدیمی میتواند آسیبپذیریهای سیستمی پنهان کند. حتی پروژههای متنباز قدیمی و مستحکم نیاز به حسابرسیهای خودکار و دستی مداوم دارند.
- افشای هماهنگ و جایزههای معنیدار برای باگ نتایج بهتری نسبت به افشای عمومی بدون رفع به همراه دارد. جایزه ۲۵۰٬۰۰۰ دلاری در این مورد انگیزهای برای برخورد مسئولانه با یک مسئله با شدت بالا فراهم کرد.
- مکانیسمهای حاکمیتی باید تعادل بین عدم تمرکز و ایمنی را حفظ کنند. سیستمهای اصلاح از تغییرات یکجانبه محافظت میکنند اما میتوانند پاسخهای اضطراری را کند کنند. جامعه XRPL مسیر اضطراری عملی برای کاهش دوره ریسک انتخاب کرد.
- ریسکهای اجماع میاننسخهای مستلزم توجه ویژه برای هر ویژگیای است که معنای تراکنش را تغییر میدهد. آسیبپذیری Batch نیاز به عرضههای محتاطانه آگاه از نسخه را تقویت کرد.
افکار نهایی
حادثه امنیتی XRPL نشان داد چگونه یک فرض حسابی دههقدیم میتواند یک حالت خطای نظریاً فاجعهآمیز برای یک رمز ارز بزرگ ایجاد کند. خوشبختانه ابزارهای مدرن امنیتی، پژوهش مسئولانه و هماهنگی سریع بین RippleX، بنیاد XRPL و اپراتورهای اعتباردهنده از بهرهبرداری در شبکه اصلی جلوگیری کردند. جامعه با وصلههای اضطراری، الزام تأیید اضافی برای انتشارهای آینده و افشایی شفاف که تعادل بین جزئیات فنی و اطلاعرسانی ریسک را حفظ کرد، پاسخ داد.
برای معاملهگران، توسعهدهندگان و نهادهایی که با XRPL تعامل دارند، این رخداد یادآور این است که سیستمهای بلاکچینی پروژههای نرمافزاری هستند که نیاز به هوشیاری امنیتی مستمر دارند. همچنین نشان میدهد که اکوسیستم میتواند وقتی آسیبپذیریها مسئولانه کشف میشوند، بهطور مؤثر واکنش نشان دهد.
برای بروزرسانیهای مربوط به نسخههای xrpld، راهنمایی اعتباردهندهها و هر اطلاعیهٔ جدید مرتبط با دفترکل XRP، به منابع تأییدشده بنیاد XRPL، RippleX و منابع معتبر خبری در حوزه رمزنگاری مراجعه کنید.






نظر بگذارید
نظرات (1)
وای... جدی؟ ۱۸ تریلیون! 😬 کاش زودتر میافتادن دستشون، دمشون گرم که سریع وصله کردن، ولی واقعا استرسزا بود.