XRP Ledger: کشف حفره ۱۰ ساله “چاپ پول از هیچ”؛ رفع اضطراری خارج از نوبت

XRP Ledger: کشف یک نقص امنیتی ۱۰ ساله و رفع فوری آن

یک نقص امنیتی در موتور پرداخت XRP Ledger که از سال ۲۰۱۵ وجود داشت، می‌توانست به مهاجمان اجازه دهد تا با هزینه‌ای اندک، مقادیر عظیمی از XRP جدید را فراتر از سقف ۱۰۰ میلیارد واحدی ایجاد کنند. ریپل‌اکس (RippleX) به سرعت این مشکل را برطرف کرده و اعلام کرده است که هیچ نشانه‌ای از سوءاستفاده در شبکه عمومی کشف نشده است.

جزئیات نقص و نحوه عملکرد آن

این نقص که در موتور پرداخت XRP Ledger نهفته بود، تقریباً یک دهه فرصت سوءاستفاده را فراهم کرده بود. طبق گزارشی که در تاریخ ۹ اکتبر منتشر شد، این نقص از زمان نگارش موتور پرداخت فعلی در سال ۲۰۱۵ وجود داشته و تا ۲۲ سپتامبر سال جاری میلادی گزارش نشده بود.

با این حال، خبر خوب این است که این نقص برطرف شده و مقامات تأیید کرده‌اند که هیچ نشانه‌ای از سوءاستفاده در شبکه عمومی وجود ندارد. نکته قابل توجه در این رفع نقص، این است که فرآیند معمول به‌روزرسانی از طریق «اصلاحیه» (amendment) که بیش از ده سال است اجرا می‌شود، نادیده گرفته شده است.

داستان از ۲۲ سپتامبر آغاز شد، زمانی که کیدن لیائو (Cayden Liao) و وریا ای‌آی (Veria AI) از طریق کانال جایزه باگ، این نقص را گزارش کردند. در ابتدا، این نقص در سطح «عمده» (Major) ارزیابی شد. ریپل‌اکس بلافاصله در سرورهای مستقل محلی خود آن را آزمایش کرد و با استفاده از تست‌های واحد، تأیید کرد که XRP تولید شده واقعاً قابل پرداخت است. به همین دلیل، سطح خطر بلافاصله از «عمده» به بالاترین سطح، یعنی «بحرانی» (critical) ارتقا یافت.

کد اصلاحی به صورت خصوصی بین ۲۲ تا ۲۳ سپتامبر توسعه یافت و پس از چندین دور بازبینی، در ۲۵ سپتامبر همراه با نسخه xrpld 3.4.1 منتشر شد. در توضیحات نسخه ذکر شده است که این یک نسخه اضطراری برای رفع یک مشکل امنیتی حساس است.

نکته کلیدی، سرعت عمل بود: در روز انتشار، بیش از ۸۰ درصد از تأییدکنندگان (validators) در لیست مورد اعتماد پیش‌فرض (UNL) به‌روزرسانی را انجام دادند، حتی قبل از اینکه کد منبع اصلاحی در دسترس عموم قرار گیرد. در گزارش ۹ اکتبر، کد منبع به صورت عمومی منتشر شد.

نحوه عملکرد نقص

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

پیامد این امر این بود که هر سفارش‌دهنده، مبلغ کامل XRP را دریافت می‌کرد، در حالی که از خریدار تنها چند صد «دراپ» (drop) به همراه کارمزد کسر می‌شد. مابه تفاوت، XRPهایی بود که نباید در دفتر حساب وجود می‌داشت، اما همچنان قابل استفاده در پرداخت‌های بعدی بود.

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

مکانیزم‌های امنیتی و شکست آن‌ها

XRP Ledger دو لایه امنیتی داشت. لایه اول، بررسی عدم ایجاد XRP جدید در تراکنش‌ها بود. اما این بررسی نیز از همان شمارنده ۶۴ بیتی بدون بررسی سرریز استفاده می‌کرد که صفر می‌شد و تغییر خالص را تنها به اندازه کارمزد نشان می‌داد.

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

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

راه حل و تغییرات اعمال شده

راه حل پیشنهادی این بود که قبل از جمع زدن هر مرحله از محاسبه مجموع پرداخت، بررسی شود که آیا از سقف فراتر می‌رود یا خیر. اگر این اتفاق می‌افتاد، آن مرحله از پرداخت به طور صحیح ناموفق تلقی می‌شد و تراکنش با نتیجه «مسیر خشک» (path dry) یا «پرداخت جزئی» (partial payment) خاتمه می‌یافت و هیچ XRP جدیدی ایجاد نمی‌شد. مراحل ادغام چندین مسیر نیز با محافظت‌های مشابه همراه شد و بررسی عدم ایجاد XRP نیز با یک شمارنده وسیع‌تر که صفر نمی‌شد، جایگزین گردید.

نادیده گرفتن فرآیند اصلاحیه

قوانین عادی تغییرات، ابتدا همراه با نرم‌افزار منتشر می‌شوند اما به طور پیش‌فرض غیرفعال هستند. پس از کسب حمایت بیش از ۸۰ درصد از تأییدکنندگان مورد اعتماد و حفظ آن برای دو هفته، فعال می‌شوند. اما در این مورد، اصلاحیه بلافاصله پس از ارتقاء هر سرور به نسخه 3.4.1 فعال شد. دلیل رسمی این اقدام این بود که xrpld متن‌باز است و انتشار اصلاحیه به معنای افشای محل نقص بود. در صورت طی کردن فرآیند اصلاحیه، نقص برای چندین هفته عمومی می‌ماند، در حالی که شبکه اصلی همچنان در معرض حمله قرار داشت.

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

نقص دیگر و رفع آن

همین گزارش همچنین از نقص اعتبارسنجی در قابلیت «بسته» (Batch) که امکان بسته‌بندی حداکثر ۸ تراکنش را فراهم می‌کند، پرده برداشت. این امر می‌توانست منجر به اختلاف نظر بین سرورهای جدید و قدیمی در مورد اعتبار یک تراکنش شود. ریپل و سایر تأییدکنندگان ابتدا با رأی مخالف، فعال‌سازی BatchV11 را به تعویق انداختند تا زمانی که اصلاحیه fixBatchV12 آماده شد. هر دو در تاریخ ۹ اکتبر همزمان در شبکه اصلی فعال شدند. این قابلیت قبلاً هرگز در شبکه اصلی فعال نشده بود و هیچ حساب یا وجوهی تحت تأثیر قرار نگرفت.

پیامدها برای اپراتورهای نود

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

درس‌های آموخته شده

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

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

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

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

کل XRP در زمان راه‌اندازی دفتر حساب در سال ۲۰۱۲ ایجاد شده بود و افزایش ناگهانی عرضه، اساس ارزش آن را به شدت تحت تأثیر قرار می‌داد. خوشبختانه، این بار مورد سوءاستفاده قرار نگرفت و برای دارندگان و مؤسسات، یک نگرانی بی‌مورد بود. اما در نهایت، سقف عرضه توسط کد حفظ شد، نه توسط اعلامیه‌ها.