نتایج ارزیابی حمله CDN Tsunami
نتایج آزمایش‌ها نشان داد هر شش ارائه‌دهنده در برابر تقویت پهنای باند آسیب‌پذیر بودند. همچنین، پنج ارائه‌دهنده در برابر تقویت اتصال آسیب‌پذیری نشان دادند. کلودفلر در برابر تقویت اتصال آسیب‌پذیر نبود، زیرا پیش از برقراری ارتباط با سرور مبدأ، کل درخواست را به‌طور کامل در بافر ذخیره می‌کند.
برای اجرای حمله CDN Tsunami، وب‌سایت باید روی یکی از این شش ارائه‌دهنده میزبانی شود و HTTP/3 در لایه لبه (Edge) آن فعال باشد. این حمله به هیچ تغییری در پیکربندی وب‌سایت نیاز ندارد.
در این مقاله، HTTP/3 به‌عنوان پروتکل پیش‌فرض در کلودفلر و کلودفرانت معرفی شده است. بااین‌حال، طبق مستندات کلودفلر، HTTP/3 در تمام پلن‌ها در دسترس است و روش فعال‌سازی آن نیز ارائه شده، اما فعال بودن پیش‌فرض این پروتکل تأیید نشده است. از سوی دیگر، طبق مستندات AWS، توزیع‌های جدید کلودفرانت به‌طور پیش‌فرض از HTTP/2 استفاده می‌کنند.
در آزمایش‌ها، ضریب تقویت در علی‌بابا ، بایدو و تنسنت به 350 برابر رسید. هر سه ارائه‌دهنده از جدول پویای QPACKپشتیبانی می‌کردند و بیشترین ضریب تقویت در حدود 64 استریم هم‌زمان (Concurrent Streams) ثبت شد. در مقابل، در سه ارائه‌دهنده دیگر، یعنی کلودفلر، کلودفرانت و فستلی، حداکثر ضریب تقویت بین 36.41 تا 51.2 برابر ثبت شد.
وضعیت CVE و اصلاحات امنیتی
تاکنون، این آسیب‌پذیری هیچ شناسه CVE دریافت نکرده و گزارشی از سوءاستفاده از آن در حملات واقعی منتشر نشده است. بایدو و تنسنت نیز گزارش‌های مربوط به حمله CDN Tsunami را تأیید کرده و اصلاحات پیشنهادی را اعمال کرده‌اند.
پژوهشگران تأکید کرده‌اند که تمام راهکارهای کاهش ریسک (Mitigation) پیشنهادی باید در سطح شبکه توزیع محتوا (CDN) اجرا شوند و وب‌سایت مبدأ نیازی به تغییر یا پیکربندی جدید ندارد.
سازوکار تقویت پهنای باند و تقویت اتصال در حمله CDN Tsunami
پژوهشگران این دو تکنیک را تقویت پهنای باند HTTP/3 (HTTP/3 Bandwidth Amplification یا HBA) و تقویت اتصال HTTP/3 (HTTP/3 Connection Amplification یا HCA) نام‌گذاری کرده‌اند.
هر دو تکنیک از یک ناهماهنگی در نحوه استقرار پروتکل‌ها در شبکه‌های توزیع محتوا (CDN) سوءاستفاده می‌کنند. در این معماری، CDN از طریق HTTP/3 با مرورگر ارتباط برقرار می‌کند، اما برای ارتباط با وب‌سایت مبدأ از HTTP/1.1 استفاده می‌کند. پژوهشگران معتقدند این تفاوت در پروتکل‌های ارتباطی به این دلیل وجود دارد که CDNها از HTTP/3 به‌صورت سرتاسری (End-to-End) پشتیبانی نمی‌کنند.
تکنیک HBA از QPACK برای فشرده‌سازی هدرها (Header Compression) در HTTP/3 استفاده می‌کند. در مقابل، HTTP/1.1 از سازوکاری مشابه برای فشرده‌سازی هدرها برخوردار نیست. به همین دلیل، CDN پیش از ارسال درخواست به سرور مبدأ، باید هر ایندکس (Index) کوچک را به یک هدر کامل و خام (Raw Header) تبدیل کند.
در این شرایط، مهاجم می‌تواند یک درخواست را با ارسال تنها چند بایت ترافیک ایجاد کند، اما همان درخواست پس از خارج شدن از حالت فشرده در سمت سرور مبدأ، به داده‌ای بسیار بزرگ‌تر تبدیل می‌شود. در نتیجه، اختلاف قابل‌توجه میان ترافیک ارسالی مهاجم و داده‌ای که به سرور مبدأ می‌رسد، زمینه را برای ایجاد ضریب تقویت بالا فراهم می‌کند.
در آزمایش‌ها، مهاجم برای ایجاد این حمله در سه CDN مجهز به جدول پویای QPACK به کمتر از 500 کیلوبیت بر ثانیه (Kbps) پهنای باند نیاز داشت. این میزان در سه CDN دیگر نیز کمتر از 5 مگابیت بر ثانیه (Mbps) بود. در مقابل، پهنای باند مصرف‌شده در سمت سرور مبدأ در تمام آزمایش‌ها از 100 مگابیت بر ثانیه فراتر رفت.
در مجموع، حمله CDN Tsunami نشان می‌دهد تفاوت در نحوه فشرده‌سازی و پردازش هدرها میان HTTP/3 و HTTP/1.1 می‌تواند به مهاجم اجازه دهد با صرف منابع محدود، بار بسیار بیشتری را به زیرساخت سرور مبدأ تحمیل کند.
سازوکار جدول پویای QPACK
در نسخه مبتنی بر جدول پویا، مهاجم ابتدا یک درخواست HTTP/3 حاوی هدر بزرگی ارسال می‌کند. CDN این هدر را در جدول پویا قرار می‌دهد و مهاجم پس از آن می‌تواند با استفاده از مقادیر ایندکس کوچک، بارها همان ورودی را فراخوانی کند. در این روش، حمله CDN Tsunami تنها روی علی‌بابا، بایدو و تنسنت قابل اجرا بود. هر سه ارائه‌دهنده از جدول 4 کیلوبایتی پشتیبانی می‌کنند و حداکثر اندازه هر ورودی در این جدول 3,072 بایت است.
بیشترین ضریب تقویت پهنای باند اندازه‌گیری‌شده در این شش ارائه‌دهنده به شرح زیر بود:
- بایدو: ضریب تقویت پهنای باند 66.06 برابر اندازه‌گیری شد. این ارائه‌دهنده از جدول پویای QPACK پشتیبانی می‌کند.
- علی‌بابا: ضریب تقویت پهنای باند 65.8 برابر اندازه‌گیری شد. این ارائه‌دهنده از جدول پویای QPACK پشتیبانی می‌کند.
- تنسنت: ضریب تقویت پهنای باند 54.08 برابر اندازه‌گیری شد. این ارائه‌دهنده از جدول پویای QPACK پشتیبانی می‌کند.
- آمازون کلودفرانت: ضریب تقویت پهنای باند 51.2 برابر اندازه‌گیری شد. این ارائه‌دهنده از جدول پویای QPACK پشتیبانی نمی‌کند.
- کلودفلر: ضریب تقویت پهنای باند 48.27 برابر اندازه‌گیری شد. این ارائه‌دهنده از جدول پویای QPACK پشتیبانی نمی‌کند.
- فستلی: ضریب تقویت پهنای باند 36.41 برابر اندازه‌گیری شد. این ارائه‌دهنده از جدول پویای QPACK پشتیبانی نمی‌کند.
سازوکار HCA برای افزایش فشار بر ظرفیت اتصال
تکنیک HCA به‌جای پهنای باند، ظرفیت اتصال را هدف قرار می‌دهد. پنج مورد از شش CDN، به‌محض دریافت فریم HEADERS در HTTP/3 و پیش از دریافت بدنه درخواست، یک اتصال HTTP/1.1 با سرور مبدأ برقرار می‌کنند. در HTTP/3، یک اتصال از سمت کلاینت می‌تواند چندین استریم را به‌صورت هم‌زمان منتقل کند. هر یک از این استریم‌ها می‌تواند یک اتصال TCP جداگانه در سمت سرور مبدأ ایجاد کند.
مهاجم با ارسال فریم‌های DATA با نرخ بسیار پایین، باعث می‌شود این اتصال‌ها همچنان برقرار بمانند. در این شرایط، CDN همچنان درخواست را ناقص تشخیص می‌دهد و اتصال‌های برقرارشده با سرور مبدأ نیز قطع نمی‌شوند. در نتیجه، حمله CDN Tsunami می‌تواند با اشغال ظرفیت اتصال سرور مبدأ، عملکرد آن را مختل کند.
پژوهشگران این تکنیک را روی یک سرور آپاچی با زمان انتظار 300ثانیه و سقف 256 اتصال آزمایش کردند. چهار اتصال HTTP/3 که هرکدام 96 استریم هم‌زمان داشتند، در مجموع 384 اتصال در سمت سرور مبدأ ایجاد کردند. در فستلی ، هر اتصال HTTP/3 حداکثر 10 اتصال با سرور مبدأ ایجاد می‌کند. به همین دلیل، برای ایجاد 384 اتصال در سمت سرور مبدأ، 48 اتصال HTTP/3 لازم بود که هرکدام 8 استریم داشتند.
افزایش زمان پاسخ‌گویی و محدودیت‌های آزمایش
آزمایش‌ها نشان دادند که زمان پاسخ‌گویی به یک کلاینت عادی در علی‌بابا به 60 ثانیه و در بایدو و کلودفرانت به 90 ثانیه رسید. در این شرایط، بایدو و کلودفرانت کد وضعیت HTTP 504 را به کلاینت ارسال کردند.
زمان پاسخ‌گویی فستلی نیز به 15 ثانیه افزایش یافت و در ادامه، این سرویس کد وضعیت HTTP 503 را به کلاینت ارسال کرد. تنسنت نیز حدود 10 ثانیه پس از دریافت یک درخواست آزمایشی، اتصال کلاینت را قطع کرد و پاسخی به آن نداد.
پژوهشگران آزمایش‌ها را با اعمال محدودیت‌های مشخص انجام دادند. پهنای باند سرور مبدأ در این آزمایش‌ها حداکثر 100 مگابیت بر ثانیه و پهنای باند مهاجم حداکثر 30 مگابیت بر ثانیه در نظر گرفته شد. هیچ آزمایشی با مقادیری بالاتر از این سقف‌ها انجام نشد. پژوهشگران احتمال می‌دهند این حملات روی سرورهایی با ظرفیت بالاتر نیز قابل اجرا باشند، اما این فرضیه در آزمایش‌ها مورد بررسی قرار نگرفته است.
همچنین، پژوهشگران دریافتند که ضریب تقویت در حدود 64 استریم هم‌زمان به بیشترین میزان خود می‌رسد و پس از آن کاهش پیدا می‌کند. پژوهشگران معتقدند افزایش فشار پردازشی روی پردازنده (CPU) در لایه لبه (Edge) CDN باعث کاهش ضریب تقویت می‌شود. بااین‌حال، این پژوهش هیچ اندازه‌گیری مستقیمی از میزان مصرف پردازنده در لایه لبه ارائه نکرده است.
بررسی دامنه‌های آسیب‌پذیر
پژوهشگران برای بررسی میزان مواجهه سرویس‌ها با این حمله، زیر دامنه‌های موجود در فهرست یک میلیون دامنه برتر ترانکو (Tranco Top 1M) را استخراج کردند. سپس رکوردهای CNAME و NS این زیر دامنه‌ها را بررسی کرده و آن‌ها را با پسوندهای شناخته‌شده مورد استفاده CDNها تطبیق دادند. در ادامه، پژوهشگران هر زیر دامنه را با استفاده از ابزار aioquic از طریق ارسال درخواست HTTP/3 بررسی کردند.
این بررسی در مجموع 151,685 زیر دامنه را شناسایی کرد که روی شش ارائه‌دهنده میزبانی می‌شدند. از میان آن‌ها، 42,330 زیر دامنه به درخواست HTTP/3 پاسخ دادند و به‌عنوان موارد بالقوه آسیب‌پذیر شناسایی شدند. کلودفرانت با 17,431 مورد، کلودفلر با 12,371 مورد و فستلی با 11,606 مورد، بیشترین تعداد را به خود اختصاص دادند.
بااین‌حال، پاسخ‌گویی لایه لبه CDN به HTTP/3 به‌تنهایی برای تأیید آسیب‌پذیری کافی نیست. پژوهشگران در این بررسی هیچ سرور مبدأ خارج از محیط آزمایشی خود را هدف قرار ندادند. بنابراین، شناسایی این زیر دامنه‌ها به معنای تأیید آسیب‌پذیری آن‌ها در برابر حمله CDN Tsunami نیست.
پژوهشگران نتایج این مطالعه را با پژوهش CDN Judo مقایسه کردند. این پژوهش که در سال 2020 انجام شد، نحوه تبدیل ترافیک HTTP/2 به HTTP/1.1 در CDNها را بررسی کرده بود. در پژوهش CDN Judo، ضریب تقویت برای تبدیل HTTP/2 به HTTP/1.1 با استفاده از جدول ایستا حدود 44 برابر و با استفاده از جدول پویا حدود 166 برابر گزارش شده بود. مقایسه این نتایج نشان می‌دهد این حمله در برخی پیکربندی‌ها می‌تواند ضریب تقویتی بسیار بالاتری نسبت به حملات مبتنی بر تبدیل HTTP/2 به HTTP/1.1 ایجاد کند.
راهکارهای پیشنهادی برای کاهش ریسک
پژوهشگران برای کاهش ریسک این حملات، مجموعه‌ای از راهکارها را پیشنهاد کرده‌اند که همگی باید در سطح CDN اجرا شوند. مهم‌ترین این راهکارها عبارتند از:
- محدود کردن اندازه هر ورودی هدر در جدول پویای QPACK: حداکثر اندازه پیشنهادی برای هر ورودی 512 بایت است.
- محدود کردن دفعات استفاده از هر ورودی جدول پویا در یک استریم: پژوهشگران پیشنهاد کرده‌اند هر ورودی حداکثر 10 بار در یک استریم مورد استفاده قرار گیرد.
- تعیین سقف برای اندازه درخواست HTTP/1.1 پس از خارج شدن از حالت فشرده: درخواست‌هایی که از سقف تعیین‌شده بیشتر باشند، باید پیش از ارسال به سرور مبدأ رد شوند. اندازه پیشنهادی این سقف 64 کیلوبایت است.
- دریافت کامل درخواست HTTP/3 پیش از برقراری اتصال با سرور مبدأ: CDN باید پیش از برقراری اتصال با سرور مبدأ، هر دو نوع فریم HEADERS و DATA را به‌طور کامل دریافت کند.
- محدود کردن تعداد اتصال‌های ایجادشده در سمت سرور مبدأ: هر اتصال HTTP/3 از سمت کلاینت نباید بتواند تعداد نامحدودی اتصال با سرور مبدأ ایجاد کند.
- تعیین زمان انتظار مستقل برای اتصال CDN به سرور مبدأ: پژوهشگران پیشنهاد کرده‌اند اگر به مدت 30 ثانیه داده قابل‌توجهی به سرور مبدأ ارسال نشود، اتصال قطع گردد.
تنسنت اصلاحاتی را برای محدود کردن تعداد اتصال‌های CDN به سرور مبدأ و کاهش اندازه هدرهای ذخیره‌شده در جدول پویا اجرا کرده است. طبق بخش افشای آسیب‌پذیری مقاله، بایدو حدود 350 دلار و تنسنت حدود 150 دلار در قالب برنامه باگ‌بانتی به پژوهشگران پرداخت کرده‌اند.
آسیب‌پذیری‌های مرتبط با QPACK
جدول پویای QPACK پیش از این نیز در ارتباط با یک آسیب‌پذیری دیگر مورد توجه قرار گرفته بود. به گفته پژوهشگران شرکت FoxIO در 8 جولای، ارسال حدود 260 بایت ترافیک QPACK منطبق با مشخصات پروتکل می‌توانست هر سروری را که از XQUIC استفاده می‌کند، از دسترس خارج کند. XQUIC کتابخانه علی‌بابا برای پروتکل‌های QUIC و HTTP/3 است و امکان استفاده از HTTP/3 را در وب‌سرور Tengine فراهم می‌کند. علی‌بابا نیز از Tengine در زیرساخت ابری و CDN خود استفاده می‌کند.
این گزارش در شرایطی منتشر شد که پروژه OpenSSL نیز در 13 آگوست آسیب‌پذیری CVE-2026-14456 را افشا کرد. این آسیب‌پذیری با شدت پایین باعث می‌شود سرور QUIC اتصال‌های ورودی مربوط به شناسه‌های اتصال مقصد ناشناخته را بدون اعمال هیچ محدودیتی مدیریت کند. اصلاحیه منتشرشده برای این ضعف، تعداد اتصال‌های در انتظار را به 256 مورد محدود می‌کند.
کلودفلر نیز در گزارش تهدیدات DDoS نیمه نخست سال 2026 اعلام کرد که الگوی تهدیدها در این بازه از ترافیک مخرب گسترده مبتنی بر بات‌نت به سمت روش‌های بازتابی (Reflection) و تقویتی تغییر کرده است. طبق این گزارش، ترافیک مبتنی بر DNS در نیمه نخست سال 2026، 34.3 درصد از کل فعالیت‌های لایه شبکه را به خود اختصاص داده است.
