خانه » آسیب‌پذیری HTTP/2 Bomb امکان حملات انکار سرویس از راه دور علیه وب‌سرورهای مطرح را فراهم می‌کند

آسیب‌پذیری HTTP/2 Bomb امکان حملات انکار سرویس از راه دور علیه وب‌سرورهای مطرح را فراهم می‌کند

توسط Vulnerbyte_News
26 بازدید

پژوهشگران امنیت سایبری از شناسایی آسیب‌پذیری HTTP/2 Bomb خبر داده‌اند؛ ضعفی که می‌تواند امکان حمله انکار سرویس از راه دور (Remote DoS) علیه وب‌سرورهای مهمی مانند NGINX، Apache HTTPD، Microsoft IIS، Envoy و Cloudflare Pingora را فراهم کند. آسیب‌پذیری HTTP/2 Bomb در پیکربندی پیش‌فرض HTTP/2 این سرورها وجود دارد و با جلوگیری از آزادسازی حافظه تخصیص‌یافته، می‌تواند در مدت کوتاهی دسترس‌پذیری سرویس را مختل کند.

مکانیزم فنی آسیب‌پذیری HTTP/2 Bomb در پروتکل HTTP/2

شرکت Calif این ضعف امنیتی را با نام HTTP/2 Bomb معرفی کرده و اعلام کرده است که این آسیب‌پذیری در پیکربندی پیش‌فرض HTTP/2 تمامی سرورهای تحت تأثیر وجود دارد. به گفته این شرکت، این حمله با کمک OpenAI Codex و از طریق زنجیره‌سازی دو تکنیک شناخته‌شده شامل بمب فشرده‌سازی (Compression Bomb) و روشی مشابه حفظ اتصال‌های باز به سبک Slowloris (Slowloris-style hold) شناسایی شده است.

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

هدف اصلی این حمله، سازوکار HPACK، یعنی سیستم فشرده‌سازی هدرها در HTTP/2 است. در این روش، تنها یک بایت داده ارسالی می‌تواند در سمت سرور منجر به تخصیص یک ورودی هدر کامل شود و این فرآیند هزاران بار در قالب یک درخواست تکرار گردد. سپس مهاجم با استفاده از یک پنجره کنترل جریان با مقدار صفر بایت از آزاد شدن حافظه تخصیص‌یافته جلوگیری می‌کند؛ وضعیتی که در نهایت منجر به مصرف گسترده حافظه و از دسترس خارج شدن سرویس می‌شود.

نقش HPACK و Slowloris

HPACK الگوریتم اختصاصی فشرده‌سازی هدرها در HTTP/2 است که برای کاهش حجم اطلاعات مربوط به درخواست‌ها و پاسخ‌ها مورد استفاده قرار می‌گیرد. این الگوریتم با بهره‌گیری از کدگذاری هافمن (Huffman Encoding) به‌طور میانگین اندازه هدرها را حدود 30 درصد کاهش می‌دهد. همچنین HPACK به‌گونه‌ای طراحی شده است که در برابر حملاتی مانند CRIME (Compression Ratio Info-leak Made Easy) مقاوم باشد؛ حمله‌ای که می‌تواند از طریق داده‌های فشرده‌شده، اطلاعات حساسی مانند کوکی‌های احراز هویت را افشا کند.

در مقابل، Slowloris نوعی حمله انکار سرویس (DoS) در لایه اپلیکیشن است که به مهاجم اجازه می‌دهد با ایجاد و حفظ تعداد زیادی اتصال HTTP به‌صورت هم‌زمان، سرور هدف را با کمبود منابع مواجه کند. در آسیب‌پذیری HTTP/2 Bomb نیز از رویکردی مشابه استفاده می‌شود؛ به‌طوری‌که حافظه تخصیص‌یافته برای هدرها برای مدت طولانی آزاد نمی‌شود و در نتیجه، مصرف حافظه سرور به‌سرعت افزایش پیدا می‌کند.

چه چیزی آسیب‌پذیری HTTP/2 Bomb را از حملات مشابه متمایز می‌کند؟

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

  • HPACK Bomb با شناسه CVE-2016-6581 که نخستین‌بار در سال 2016 افشا شد.
  • CVE-2025-53020؛ یک آسیب‌پذیری مصرف کنترل‌نشده حافظه در پیاده‌سازی HTTP/2 در Apache httpd.
  • CVE-2016-8740؛ یک ضعف انکار سرویس در Apache HTTP Server که از طریق فریم‌های CONTINUATION دستکاری‌شده قابل سوءاستفاده است.
  • CVE-2016-1546؛ یک آسیب‌پذیری انکار سرویس که در اثر مصرف کامل Threadهای پردازشی سرور (Worker-Thread Starvation) در اتصال‌های HTTP/2 ایجاد می‌شود.

با این حال، به گفته شرکت Calif، تفاوت اصلی آسیب‌پذیری HTTP/2 Bomb با حملات مشابه در منشأ افزایش چشمگیر مصرف منابع سرور است.

در حملات کلاسیک HPACK Bomb، مهاجم یک مقدار بزرگ را در جدول فشرده‌سازی قرار داده و بارها به آن ارجاع می‌دهد. به همین دلیل، بسیاری از سرورها محدودیت‌هایی را برای اندازه نهایی هدرهای رمزگشایی‌شده اعمال می‌کنند.

اما در این روش، هدر ارسالی تقریباً خالی است و افزایش مصرف منابع از حافظه و ساختارهایی ناشی می‌شود که سرور برای مدیریت هر ورودی هدر اختصاص می‌دهد. در نتیجه، مکانیزم‌های دفاعی مبتنی بر محدودسازی اندازه هدر قادر به شناسایی این عملکرد نیستند؛ زیرا حجم داده‌ای که باید رمزگشایی شود بسیار ناچیز است، در حالی که مصرف حافظه در سمت سرور همچنان به‌طور قابل‌توجهی افزایش می‌یابد.

سناریوی حمله و میزان تأثیر بر سرورهای آسیب‌پذیر

بر اساس سناریوی مطرح‌شده در گزارش، حتی یک رایانه خانگی با اتصال 100 مگابیت بر ثانیه (Mbps) می‌تواند ظرف چند ثانیه یک سرور آسیب‌پذیر را از دسترس خارج کند. علاوه بر این، یک کلاینت قادر است تنها در حدود 20 ثانیه، نزدیک به 32 گیگابایت از حافظه سرور را در سامانه‌هایی مانند Apache HTTPD و Envoy مصرف کرده و مانع آزادسازی آن شود.

این سناریو نشان می‌دهد که ریسک سوءاستفاده از آسیب‌پذیری HTTP/2 Bomb صرفاً به حجم ترافیک یا توان پردازشی مهاجم وابسته نیست. عامل اصلی موفقیت این حمله، توانایی مهاجم در حفظ منابع تخصیص‌یافته روی سرور برای مدت طولانی است. به همین دلیل، حتی حجم محدودی از ترافیک نیز می‌تواند منجر به اختلال جدی در دسترس‌پذیری سرویس شود.

راهکارهای کاهش ریسک و وضعیت پچ‌های امنیتی

پژوهشگران برای کاهش ریسک سوءاستفاده از آسیب‌پذیری HTTP/2 Bomb، اجرای اقدامات زیر را توصیه می‌کنند:

  • NGINX: کاربران باید این محصول را به نسخه 1.29.8 یا بالاتر به‌روزرسانی کنند. در این نسخه، قابلیت max_headers با مقدار پیش‌فرض 1000 اضافه شده است. در صورت عدم امکان به‌روزرسانی، توصیه می‌شود پشتیبانی از HTTP/2 از طریق گزینه http2 off غیرفعال شود.
  • Apache HTTPD: این آسیب‌پذیری در نسخه mod_http2 v2.0.41 برطرف شده است. در صورتی که امکان به‌روزرسانی وجود نداشته باشد، توصیه می‌شود با تغییر تنظیمات به Protocols http/1.1، پشتیبانی از HTTP/2 غیرفعال شود.
  • Cloudflare Pingora: نیازی به اقدام خاصی نیست.
  • Microsoft IISو Envoy: تا زمان انتشار این گزارش، پچ امنیتی برای این آسیب‌پذیری منتشر نشده است.

در همین حال، سخنگوی کلودفلر اعلام کرد معماری فعلی این شرکت و سازوکارهای مقابله با حملات DDoS به‌صورت خودکار این الگوی حمله را شناسایی و متوقف می‌کنند؛ موضوعی که مشتریان این سرویس را در برابر این تهدید مقاوم می‌سازد.

شرکت Calif معتقد است مشکل اصلی به نحوه ارزیابی ریسک مصرف حافظه در استاندارد HTTP/2 بازمی‌گردد. این استاندارد معمولاً سطح ریسک را بر اساس میزان افزایش مصرف منابع در مقایسه با حجم داده دریافتی می‌سنجد، در حالی که این معیار به‌تنهایی تصویر کاملی از تهدید ارائه نمی‌دهد. به گفته این شرکت، حتی اگر یک مکانیزم بتواند مصرف حافظه را تا 70 برابر افزایش دهد، تا زمانی که حافظه پس از پردازش درخواست آزاد شود، لزوماً تهدیدی جدی محسوب نخواهد شد.

با این حال، آنچه این سناریو را به یک حمله عملی تبدیل می‌کند، امکان باز نگه داشتن اتصال در HTTP/2 با هزینه‌ای بسیار ناچیز برای مهاجم است. در این سناریو، حافظه اختصاص‌یافته در سمت سرور برای مدت طولانی آزاد نمی‌شود و همین مسئله منجر به افزایش مداوم مصرف حافظه و از دسترس خارج شدن سرویس می‌شود.

منابع

همچنین ممکن است دوست داشته باشید

پیام بگذارید