آسیب‌پذیری‌های رایج امنیتی در پل‌های بلاکچین

تعریف پل‌های بلاکچین

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

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

چرا امنیت پل‌های بلاکچین حیاتی است؟

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

بر اساس برآورد CertiK، حملات به پل‌ها منجر به خسارات بیش از ۱٫۳ میلیارد دلار در سال ۲۰۲۲ شد که ۳۶ درصد از کل خسارات سال را به خود اختصاص داد.

آسیب‌پذیری‌های مشترک امنیتی پل‌های بلاکچین

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

اعتبارسنجی ضعیف آنچین

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

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

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

برخی از پل‌ها مفهوم Wrapped Tokens را اجرا می‌کنند. به عنوان مثال، هنگامی که کاربر DAI را از اتریوم به زنجیره BNB منتقل می‌کند، DAI از قرارداد اتریوم گرفته می‌شود و مقدار معادل wrapped DAI در زنجیره BNB صادر می‌شود.

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

مهاجمان همچنین به قربانیانی نیاز دارند که قرارداد پل را برای انتقال توکن‌ها با استفاده از تابع “transferFrom” برای تخلیه دارایی‌ها از قرارداد پل تایید کنند.

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

اعتبارسنجی ضعیف آفچین

در برخی از پل‌ها، سرور پشتیبان (Bakcend) آفچین نقش مهمی در تأیید مشروعیت پیام‌های ارسال شده از بلاکچین ایفا می‌کند. در این مثال، ما بر تأیید معاملات سپرده تمرکز می‌کنیم.

یک پل بلاکچین با اعتبارسنجی آفچین به شرح زیر عمل می‌کند:

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

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

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

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

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

پل‌ها رویکردهای متفاوتی را برای مدیریت توکن‌های بومی و توکن‌های کاربردی دارند. به عنوان مثال، در شبکه اتریوم، توکن بومی ETH است و اکثر توکن‌های کاربردی از استاندارد ERC-20 تبعیت می‌کنند.

زمانی که کاربر قصد دارد ETH خود را به زنجیره دیگری منتقل کند، ابتدا باید آن را به قرارداد پل واریز کند. برای دستیابی به این هدف، کاربر به سادگی ETH را به تراکنش متصل می‌کند و مقدار ETH را می‌توان با خواندن قسمت “msg.value” تراکنش بازیابی کرد.

واریز توکن‌های ERC-20 به طور قابل توجهی با واریز ETH متفاوت است. برای واریز توکن ERC-20، کاربر ابتدا باید به قرارداد پل اجازه دهد تا توکن‌های خود را خرج کند. پس از تایید این موضوع و واریز توکن‌ها به قرارداد پل، قرارداد یا توکن‌های کاربر را با استفاده از تابع “burnFrom()” می‌سوزاند یا توکن کاربر را با استفاده از تابع “transferFrom()” به قرارداد منتقل می‌کند.

یک روش برای متمایز کردن این مورد استفاده از عبارت if-else در همان تابع است. روش دیگر ایجاد دو تابع مجزا برای مدیریت هر سناریو است. تلاش برای واریز ETH با استفاده از تابع سپرده ERC-20 می‌تواند منجر به از دست رفتن این وجوه شود.

هنگام رسیدگی به درخواست‌های واریز ERC-20، کاربران معمولاً آدرس توکن را به عنوان ورودی تابع سپرده ارائه می‌کنند. این یک خطر قابل توجه است؛ زیرا تماس‌های خارجی غیر قابل اعتماد ممکن است در طول تراکنش رخ دهد. اجرای یک لیست سفید که فقط شامل توکن‌های پشتیبانی شده توسط پل باشد، یک روش معمول برای به حداقل رساندن ریسک است. فقط آدرس‌های لیست سفید مجاز به ارسال به عنوان آرگومان هستند. این از تماس‌های خارجی جلوگیری می‌کند؛ زیرا تیم پروژه پیش از این آدرس توکن را فیلتر کرده است.

با این حال، هنگامی که پل‌ها انتقال کراس چین توکن بومی را انجام می‌دهند، ممکن است مشکلاتی نیز ایجاد شود، زیرا توکن بومی آدرسی ندارد. آدرس صفر (0x000…0) نماینده توکن اصلی است. این می‌تواند مشکل‌ساز باشد؛ زیرا ارسال آدرس صفر به تابع می‌تواند تأیید لیست سفید را دور بزند حتی اگر به درستی اجرا نشده باشد.

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

پیکربندی اشتباه

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

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

چگونه امنیت پل را بهبود بخشیم؟

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

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

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