‏نت‌جک؛ فرض‌های امنیتی NAT زیر سؤال

تو Black Hat USA 2026، مالکوم استگ، محقق مستقل و عضو تیم قرمز Synack، از کلاس حمله‌ای به اسم NatJack رونمایی کرد که مستقیم سراغ جدول ردیابی اتصال (connection tracking) توی NAT می‌ره. به گفتهٔ خودش کاملاً اتفاقی به این ماجرا رسیده: دیده بعضی وقت‌ها پاسخ‌هایی می‌گیره که به بسته‌های ارسالی‌ش ربطی ندارن، و همین نشون می‌داده یه جور خرابی داخل جدول NAT داره اتفاق می‌افته.

حرف اصلی مقاله اینه که NAT هیچ‌وقت به‌عنوان یه کنترل امنیتی ساخته نشده بود؛ اوایل دههٔ ۹۰ فقط یه راه‌حل موقت برای کمبود آدرس‌های IPv4 بود که فرض می‌کرد همتاهای داخل شبکه قابل‌اعتمادن. به گفتهٔ استگ، ریشهٔ ماجرا به کم‌دقتی همین RFCهاست. برخلاف حمله‌های قدیمی‌تر مثل NAT Pinning و NAT Slipstreaming، اینجا نه ALG لازمه، نه جعل IP، نه دسترسی به broadcast domain — و قربانی هم کاری نمی‌کنه جز اینکه یه اتصال فعال داشته باشه.

NatJack چهار تکنیک داره که همه به یه ضعف مشترک برمی‌گردن: ربودن اتصال TCP، مسموم‌کردن پاسخ‌های DNS روی UDP، از کار انداختن سرویس با پر کردن خود جدول NAT، و شناسایی پورتی که NAT به یه اتصال فعال اختصاص داده. تو حالت اول مهاجم اتصال قربانی رو به وضعیت بسته می‌بره و بعد ورودی جدول رو با ورودی خودش عوض می‌کنه؛ مکانیزم TIME-WAIT Assassination در RFC 1337 باعث می‌شه این کار به‌جای انتظار برای تایم‌اوت، با چندتا بسته انجام بشه.

جداسازی لایه ۲ اینجا جواب نمی‌ده: VLAN و port isolation کمکی نمی‌کنن، چون حمله زیرساخت مشترک NAT رو تو لایه‌های ۳ و ۴ هدف می‌گیره. مشکل روی ویندوز، لینوکس و مک‌اواس تأیید شده، با اینکه کدبیس مشترکی ندارن — یعنی پای یه فرض طراحی مشترکه، نه یه باگ موردی. سیزده سازنده مطلع شدن و تو ۹۵ گزارش، ۳۲ محصول و پیکربندی تست شد که همه‌شون به بخشی از تکنیک‌ها آسیب‌پذیر بودن.

واکنش سازنده‌ها یکدست نبود. تیم امنیت کرنل لینوکس اولش گزارش رو رد کرد، ولی بعداً به درخواست مایکروسافت برای Azure Kubernetes Service پچ شد و CVE-2026-63913 گرفت؛ آسیب‌پذیری NAT خود ویندوز هم که Hyper-V رو درگیر می‌کنه با CVE-2026-56181 ثبت شد. در مقابل، سیسکو و اپل این رفتار رو «محدودیت طراحی» دونستن نه آسیب‌پذیری. استگ می‌گه رمزنگاری بدترین پیامدها رو کم می‌کنه، ولی مهاجم هنوز می‌تونه اتصال رو ببنده یا حذف کنه.

برای کاهش ریسک، استگ پیشنهاد می‌کنه نشانه‌های حمله رو مانیتور کنین (پر شدن جدول NAT، سیل بسته‌های TCP/UDP روی بازهٔ پورت وسیع، دیده شدن یه IP تو دو مکان فیزیکی)، محافظت‌هایی مثل IP Source Guard رو روشن کنین، کاربرهای نامطمئن رو تو ساب‌نت یا VLAN جدا بذارین و تعداد اتصال هر کلاینت رو زیر حدود ۱۰٬۰۰۰ نگه دارین، حالت‌های loose connection tracking و port preservation و endpoint-independent mapping رو خاموش کنین، و بار کاری نامطمئن رو با NAT gateway مشترک اجرا نکنین.

نکات کلیدی:

• NatJack جدول ردیابی اتصال NAT رو دستکاری می‌کنه، نه ALG رو
• چهار تکنیک: ربودن اتصال TCP، مسموم‌کردن DNS، DoS با پر کردن جدول، و شناسایی پورت
• جداسازی لایه ۲ مثل VLAN جلوش رو نمی‌گیره
• CVE-2026-63913 برای کرنل لینوکس و CVE-2026-56181 برای NAT ویندوز ثبت شده
• سیسکو و اپل این رو محدودیت طراحی می‌دونن نه آسیب‌پذیری
• مانیتورینگ، IP Source Guard، جداسازی ساب‌نت و خاموش‌کردن حالت‌های loose از راه‌های کاهش ریسکه