حمله VORACLE: افشای داده‌ها با فشرده‌سازی در VPN و دلایل حذف آن

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

مبنای فنی این تفکر بر این فرض ساده استوار بود: الگوریتم‌های رمزنگاری نوین مانند AES-256-GCM یا ChaCha20-Poly1305 محتوای بایت‌ها را به رشته‌های شبه‌تصادفی تبدیل می‌کنند که با نویز تفاوتی ندارد. بنابراین باور عمومی بر این بود که یک شنودکننده روی خط ارتباطی هرگز نمی‌تواند از روی بسته‌های رمزگذاری‌شده به اطلاعات متن اصلی پی ببرد.

با این حال، در سال ۲۰۱۸ احمد نفیس، پژوهشگر امنیت سایبری، با معرفی حمله VORACLE (تحت شناسه CVE-2018-3972 در کنفرانس‌های Black Hat USA و DEF CON 26) این پندار را ابطال کرد. حمله VORACLE نشان داد که فشرده‌سازی ترافیک شبکه پیش از رمزنگاری، یک کانال جانبی (side-channel) خطرناک بر پایه طول بسته‌ها ایجاد می‌کند. با بررسی نوسانات اندازه بسته‌های رمزگذاری‌شده، مهاجم حاضر در مسیر شبکه می‌تواند بدون شکستن الگوریتم‌های رمزنگاری، بایت به بایت داده‌های محرمانه از جمله کوکی‌های احراز هویت و توکن‌های نشست کاربر را بازسازی کند.

+-------------------------------------------------------------------------+
|                  سازوکار کانال جانبی فشرده‌سازی VORACLE                  |
+-------------------------------------------------------------------------+
|                                                                         |
|  مهاجم حدس‌های آزمایشی را ("Cookie: auth=a...")                         |
|  به همراه داده‌های محرمانه قربانی ("Cookie: auth=s3cr3t...") تزریق می‌کند|
|                                                                         |
|         جریان متن اصلی (توکن محرمانه کاربر + حدس‌های مهاجم)             |
|                                    │                                    |
|                                    ▼                                    |
|                       [ موتور فشرده‌سازی LZO / DEFLATE ]                |
|                                    │                                    |
|    - حدس نادرست -> عدم تطابق بایت‌ها -> اندازه بسته بزرگ می‌ماند        |
|    - حدس درست   -> فعال‌سازی اشاره‌گر LZ77 -> اندازه بسته کوچک می‌شود!    |
|                                    │                                    |
|                                    ▼                                    |
|                       [ رمزنگاری متقارن AES / ChaCha ]                  |
|                                    │                                    |
|                                    ▼                                    |
|    بسته رمزگذاری‌شده در شبکه (طول بسته بازتاب‌دهنده میزان فشرده‌سازی)    |
|                                    │                                    |
|    تحلیل تغییر اندازه بسته -> بازسازی کاراکتر به کاراکتر کلید!          |
+-------------------------------------------------------------------------+

نظریه اطلاعات و منشأ نشت اندازه بسته‌ها

برای درک علل موفقیت حمله VORACLE، باید نحوه عملکرد الگوریتم‌های فشرده‌سازی بدون اتلاف را در لایه ریاضی بررسی کرد. الگوریتم‌های رایج مانند DEFLATE (استاندارد RFC 1951) و LZO بر دو ستون اصلی تکیه دارند: جایگزینی فرهنگ لغت پنجره لغزان LZ77 و کدگذاری هافمن.

در روش LZ77، رمزگذار جریان بایت‌های ورودی را برای یافتن توالی‌های تکراری بررسی می‌کند. هنگامی که یک رشته از بایت‌ها در محدوده پنجره تاریخچه (معمولاً ۳۲ یا ۶۴ کیلوبایت) مجدداً مشاهده شود، رمزگذار آن بخش تکراری را با یک اشاره‌گر کوتاه شامل دو مقدار جایگزین می‌کند:

1. فاصله (Distance): فاصله بایت‌های فعلی تا محل ظهور اولیه رشته در تاریخچه.
2. طول (Length): تعداد بایت‌های متوالی که دقیقاً یکسان هستند.

اگر یک بسته شامل دو رشته ۱۶ بایتی کاملاً مشابه باشد، وقوع دوم تنها با یک اشاره‌گر ۲ یا ۳ بایتی ثبت می‌شود و در نتیجه حجم کل داده فشرده به نسبت میزان تشابه ورودی کاهش می‌یابد.

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

رمزنگاری‌های جریانی (نظیر ChaCha20 یا AES در حالت CTR) جریان کلید را بایت به بایت با متن ورودی XOR می‌کنند. یک ورودی ۴۱۲ بایتی دقیقاً به یک خروجی ۴۱۲ بایتی رمزگذاری‌شده (به همراه برچسب اعتبارسنجی) تبدیل می‌شود. در رمزنگاری‌های قالبی (AES-CBC) نیز با وجود پدگذاری مضرب ۱۶ بایتی، کاهش حجم فشرده‌سازی به طور مداوم از مرز قالب‌ها عبور کرده و اطلاعات طول را با دقت ۱۶ بایت فاش می‌سازد.

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

چگونگی اجرای عملیاتی حمله VORACLE

حمله VORACLE به طور مشخص اتصالات OpenVPN را که گزینه‌های فشرده‌سازی در آن‌ها فعال بود (comp-lzo yes یا دستور compress) هدف قرار داد. سناریوی حمله با استفاده از روش حمله با متن مشخص انتخابی تطبیقی (adaptive chosen-plaintext attack) اجرا می‌شود:

۱. استقرار در مسیر ارتباطی شبکه

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

۲. تزریق متن ورودی تحت کنترل

مهاجم کاربر را به سمت باز کردن یک صفحه وب هدایت می‌کند یا اسکریپتی را در بستر ترافیک HTTP عادی تزریق می‌نماید. این قطعه کد به طور خودکار درخواست‌های پی‌درپی از نوع cross-origin به سمت یک سامانه مقصد (نظیر پورتال اداری یا سرویس ایمیل کاربر) ارسال می‌کند.

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

۳. فراخوانی اوراکل فشرده‌سازی

سیستم‌عامل بسته ترکیبی HTTP را به آداپتور مجازی تونل VPN منتقل می‌کند. نرم‌افزار تونل پیش از ورود داده به لایه رمزنگاری، کل داده را فشرده می‌سازد:

ساختار بسته متن اصلی ترکیب‌شده:
[GET /api/user?probe=GUESS_CHAR HTTP/1.1\r\n]  <-- کاراکتر حدسی مهاجم
[Cookie: auth_token=7a8b9c0d1e2f3a4b\r\n]     <-- توکن محرمانه کاربر

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

اما اگر کاراکتر حدسی اشتباه باشد، هیچ انطباقی شکل نگرفته و اندازه بسته فشرده بدون تغییر و در حالت بزرگ‌تر باقی می‌ماند.

۴. استخراج تدریجی کاراکترهای کلید

مهاجم اندازه بسته‌های UDP یا TCP رمزشده ارسالی از دستگاه قربانی به سمت سرور VPN را رصد می‌کند. با مشاهده افت ناگهانی در اندازه بسته به ازای یک کاراکتر معین، مهاجم به درستی آن کاراکتر پی می‌برد.

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

پیشینه حملات: از CRIME و BREACH تا VORACLE

حمله VORACLE یک پدیده اتفاقی نبود، بلکه نقطه تکامل حملات کانال جانبی فشرده‌سازی در لایه‌های مختلف پروتکل‌های اینترنتی به شمار می‌رود:

پس از معرفی حمله CRIME توسط جولیوس ریتسو و تای دونگ در سال ۲۰۱۲، کارگروه مهندسی اینترنت در استاندارد RFC 7540 فشرده‌سازی را در TLS به طور قطعی متوقف کرد؛ زیرا ترکیب داده‌های با سطح اعتماد متفاوت در یک جریان فشرده ذاتاً ناامن است.

تا پیش از VORACLE، این تصور وجود داشت که فعالیت در لایه ۳ شبکه (بسته‌های IP) مانع از بروز آسیب‌پذیری‌های لایه کاربرد می‌شود. اما VORACLE ثابت کرد که همان مخاطرات در لایه تونل شبکه نیز تکرارپذیر هستند.

علل بنیادین عدم به‌کارگیری فشرده‌سازی در WireGuard

جیسون دوننفلد، طراح پروتکل WireGuard، از همان ابتدا امکان فشرده‌سازی بسته‌ها را به کلی از ساختار این پروتکل حذف کرد.

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

دلایل فنی حذف فشرده‌سازی در WireGuard شامل موارد زیر است:

۱. خنثی‌سازی نشت اندازه بسته‌ها: با حذف فشرده‌سازی، اندازه داده ورودی پیوند ثابتی با ساختار شبکه دارد و امکان بهره‌برداری از کانال‌های جانبی اندازه از مهاجم سلب می‌شود. ۲. امنیت حافظه و پایداری پردازش: کتابخانه‌های فشرده‌سازی مانند zlib یا LZO کدهای پیچیده‌ای با تخصیص پویای حافظه دارند و بارها دچار آسیب‌پذیری‌های سرریز بافر شده‌اند. WireGuard در فضای هسته سیستم‌عامل با حافظه ایستا و بدون تخصیص پویا اجرا می‌شود. ۳. پایداری توان پردازشی و رفع نوسان تأخیر: داده‌های رمزگذاری‌شده موجود در اینترنت (ویدیوهای HTTPS و تصاویر فشرده) قابلیت فشرده‌سازی مجدد ندارند. تلاش پردازنده برای فشرده‌سازی این بسته‌ها نتیجه‌ای جز اتلاف منابع، افزایش حرارت پردازنده و افت شدید کارایی در ترافیک سنگین نخواهد داشت.

معماری RiceGuard: سازوکار بدون فشرده‌سازی و پدگذاری استاندارد

در سامانه‌های امنیتی مدرن، فشرده‌سازی بسته‌های شبکه به عنوان یک ریسک امنیتی شناخته می‌شود. در سرویس VPNRice، موتور شبکه RiceGuard فشرده‌سازی بار داده را در تمامی سرورها و برنامه‌های کاربردی به کلی متوقف کرده است.

+-----------------------------------------------------------------------+
|                    فرایند بسته‌بندی امن در RICEGUARD                  |
+-----------------------------------------------------------------------+
|  [ بسته IP ارسالی کاربر ]                                             |
|         │                                                             |
|         ▼                                                             |
|  [ بدون فشرده‌سازی ]        -> مسدودسازی کامل کانال جانبی LZ77        |
|         │                                                             |
|         ▼                                                             |
|  [ پدگذاری اندازه ]        -> همسان‌سازی اندازه داده به مضارب ثابت    |
|         │                                                             |
|         ▼                                                             |
|  [ رمزنگاری ChaCha20-Poly1305 ] -> رمزنگاری احرازشده در زمان ثابت    |
|         │                                                             |
|         ▼                                                             |
|  [ دیتگرام بیرونی UDP ]     -> الگوی ترافیکی یکنواخت در بستر شبکه     |
+-----------------------------------------------------------------------+

RiceGuard از تدابیر مشخصی برای پایداری ارتباط بهره می‌گیرد:

• ممنوعیت فشرده‌سازی پیش از رمزگذاری: حذف کامل ماژول‌های فشرده‌سازی در لایه انتقال؛ بسته‌ها بدون تغییر شکل فشرده وارد چرخه رمزنگاری می‌شوند.
• پدگذاری اندازه (Padding): بهره‌گیری از فیلدهای خالی در قالب فریم‌ها به منظور گرد کردن اندازه بسته‌های کوتاه و درخواست‌های با طول متغیر به گام‌های استاندارد، که مانع از تحلیل الگوهای ترافیکی می‌شود.
• بهره‌برداری با حداکثر سرعت خط: عدم نیاز به عملیات سنگین فشرده‌سازی و بازگشایی، امکان عبور بی‌وقفه ترافیک را در خطوط ارتباطی گیگابیتی بدون ایجاد صف در هسته سیستم‌عامل تضمین می‌کند.

جهت بررسی نرم‌افزارهای امن برای رایانه‌ها و دستگاه‌های همراه می‌توانید به صفحه دانلود وی‌پی‌ان مراجعه فرمایید.

راهنمای بازبینی و ایمن‌سازی سرورهای موجود

اگر مدیریت سرورهای اختصاصی VPN را بر عهده دارید، لازم است پیکربندی‌های فعال را بررسی کرده و گزینه‌های ناامن فشرده‌سازی را خاموش کنید.

بررسی پیکربندی OpenVPN

فایل‌های تنظیمات سرور (server.conf) و کلاینت (client.ovpn) را باز کرده و پارامترهای زیر را بیابید:

# گزینه‌های ناامن - باید فوراً حذف یا غیرفعال شوند:
comp-lzo yes
comp-lzo adaptive
compress lzo
compress deflate

جهت مصون‌سازی در برابر خطرات VORACLE، تنظیمات را مطابق پیکربندی استاندارد زیر به‌روزرسانی نمایید:

# پیکربندی ایمن و پیشنهادی:
# در OpenVPN نسخه ۲.۴ به بالا:
compress migrate
comp-lzo no

# در OpenVPN نسخه ۲.۵ و بالاتر:
# توقف کامل پشتیبانی از فشرده‌سازی:
compress stub-v2

اعمال گزینه comp-lzo no یا پاک کردن کامل دستورات فشرده‌سازی تضمین می‌کند که بسته‌ها پیش از ورود به فرایند رمزنگاری دچار دستکاری اندازه نمی‌شوند.

توصیه‌های کلیدی برای مدیران شبکه

۱. گذار به پروتکل‌های نوین: در صورت امکان، زیرساخت ارتباطی سازمان را به ساختارهای مبتنی بر WireGuard یا RiceGuard منتقل کنید که ذاتاً فاقد کد فشرده‌سازی هستند. ۲. الزام کامل بر استفاده از HTTPS: اطمینان یابید سامانه‌های وب داخلی از استانداردهای TLS 1.3 و HSTS بهره می‌گیرند تا فرصت تزریق بسته‌های آزمایشی از مهاجم سلب شود. ۳. بازبینی تجهیزات میانی شبکه: اطمینان حاصل فرمایید شتاب‌دهنده‌های ارتباطی WAN و سامانه‌های SD-WAN در مسیر ترافیک به صورت خودکار بسته‌های داخل تونل را فشرده نکنند.

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