Check Point management zero-day حملوں میں، LivePatch 28/29 اسے نہیں روکتا

Check Point کی 22 ستمبر 2026 کی سکیورٹی ایڈوائزری کے مطابق Security Management میں CVE-2026-93616 نامی zero-day محدود، ہدفی حملوں میں استعمال ہوئی، اس کا CVSS اسکور 9.8 ہے، اصلاح دستیاب ہے اور LivePatch Take 28/29 اسے نہیں روکتا۔ نقص management کی web service میں ہے؛ gateway پر LivePatch کی موجودگی management server کے محفوظ ہونے کا ثبوت نہیں۔ متاثرہ ادارے کے لیے فیصلہ سرور کے کردار، نصب شدہ release اور Jumbo Hotfix Take سے شروع ہوتا ہے۔

نیوزی لینڈ کے NCSC کی 23 ستمبر 2026 کی تنبیہ میں Security Management Server، Multi-Domain Security Management Server، Log Server، Multi-Domain Log Server اور SmartEvent کو متاثرہ دائرے میں رکھا گیا ہے اور حقیقی حملوں کی تصدیق کی گئی ہے۔ ان نظاموں کو ایک ہی نام، یعنی firewall، کے تحت گننے سے اہم فرق چھپ جاتا ہے: کمزوری انتظامی اور متعلقہ logging نظاموں میں ہے، جبکہ الگ Security Gateway میں اسی CVE کی براہِ راست کمزوری بیان نہیں کی گئی۔

کمزوری management server پر کیا کر سکتی ہے؟

یہ تصدیقِ شناخت سے پہلے path traversal کا نقص ہے۔ اگر حملہ آور کمزور management web service تک نیٹ ورک کے ذریعے پہنچ سکے تو وہ متوقع ڈائریکٹری کی حد سے باہر script چلانے اور Java class لوڈ کرنے کے راستے استعمال کر سکتا ہے۔ اس راستے کے لیے درست administrator اکاؤنٹ درکار نہیں؛ اسی وجہ سے صرف لاگ اِن اکاؤنٹس کی حفاظت یا مضبوط پاس ورڈ اس مخصوص خطرے کا مکمل جواب نہیں ہیں۔

تصدیق شدہ تکنیکی اثر management server پر غیر مجاز code چلانے کی صلاحیت ہے۔ اس سے یہ نتیجہ خود بخود نہیں نکلتا کہ ہر متاثرہ gateway بھی قبضے میں آ گیا، ہر policy بدلی گئی یا حملہ آور کو لازماً اعلیٰ ترین اختیارات ملے۔ تاہم management نظام security policies اور objects کو سنبھالتا ہے: اگر وہاں غیر مجاز تبدیلی کی جائے اور بعد میں وہ policy gateway پر نصب ہو، تو ٹریفک کے تحفظ پر بالواسطہ اثر پڑ سکتا ہے۔ اس لیے gateway کا براہِ راست غیر متاثر ہونا موصول ہونے والی policy کی سالمیت کی ضمانت نہیں۔

ورژن کے مطابق ابھی پیچ، اپگریڈ یا غیر متاثر ہونے کا فیصلہ

CheckMates کی متاثرہ ورژن اور اصلاحی Takes کی جدول میں R82.20 کے لیے مخصوص Security Hotfix، R82.10 کے لیے Jumbo Hotfix Take 45 یا بعد کا، R82 کے لیے Take 127 یا بعد کا، R81.20 کے لیے Take 170 یا بعد کا اور R81.10 کے لیے Take 192 یا بعد کا درج ہے۔ اسی جدول کے مطابق R82.10 میں Take 44 یا اس سے پہلے، R82 میں Take 126 یا اس سے پہلے، R81.20 میں Take 166 یا اس سے پہلے، اور R81.10 میں Take 190 یا اس سے پہلے کا دائرہ متاثرہ ہے۔ فیصلہ نصب شدہ Take کو مقررہ اصلاحی Take سے ملا کر ہونا چاہیے۔

• ابھی پیچ کریں: معاونت یافتہ متاثرہ management یا logging تنصیب پر اس کی release کے لیے مقررہ Security Hotfix یا Jumbo Hotfix لگائیں۔ R81.20 کے متاثرہ Take اور اصلاحی Take کے درمیان جو Takes جدول میں واضح نہیں، انہیں اندازے سے محفوظ نہ سمجھیں؛ R81.10 کے لیے بھی یہی احتیاط ضروری ہے۔ R82.20 پر صرف release کا نام دیکھنا کافی نہیں، کیونکہ اس کے لیے مخصوص hotfix درکار ہے۔
• اپگریڈ کا منصوبہ بنائیں: R80 کی شاخیں اور R81 معاونت کی مدت سے باہر درج ہیں اور ان کے لیے اس جدول میں اصلاحی Take نہیں دیا گیا؛ معاونت یافتہ اور درست طور پر پیچ شدہ release کی طرف منتقلی درکار ہے۔ R81.10 بھی معاونت کی مدت سے باہر ہے۔ اس کے لیے درج Take فوری کمزوری بند کر سکتا ہے، مگر پرانی release کی معاونت بحال نہیں کرتا۔
• غیر متاثر دائرہ الگ کریں: Smart-1 Cloud پہلے ہی پیچ کیا جا چکا ہے، جبکہ الگ Check Point firewall appliances اور Spark firewalls اس management CVE سے براہِ راست متاثر نہیں بتائے گئے۔ یہ ان کے اپنے software کے بارے میں فیصلہ ہے۔ اگر کوئی firewall ایک ہی appliance پر management بھی چلا رہا ہے، تو management والے حصے کو اس فہرست سے خارج نہیں کیا جا سکتا۔

یہ تقسیم اثاثوں کے نام کے بجائے ان کے کام پر مبنی ہے۔ ایک ادارے میں gateway غیر متاثر ہو سکتا ہے، مگر اس کے لیے policy جاری کرنے والا management server متاثرہ Take پر چل رہا ہو۔ اسی طرح Log Server یا SmartEvent کو صرف اس بنا پر نظرانداز نہیں کرنا چاہیے کہ وہ ٹریفک کو خود فلٹر نہیں کرتے؛ وہ متاثرہ مصنوعات کی فہرست میں شامل ہیں اور تفتیش کے ریکارڈ سے بھی جڑے ہیں۔

LivePatch کی حد اور عبوری تحفظ

LivePatch Take 28/29 کی موجودگی اس management نقص کے لیے hotfix کا متبادل نہیں۔ جب تک متعلقہ اصلاح نصب نہ ہو، management web service تک رسائی صرف قابلِ اعتماد انتظامی پتوں تک محدود کرنا حملے کی دستیاب راہ کم کر سکتا ہے۔ اس حد میں اندرونی نیٹ ورک اور VPN سے ممکنہ رسائی بھی شامل ہونی چاہیے؛ صرف انٹرنیٹ سے براہِ راست رسائی بند ہونا کافی نتیجہ نہیں دیتا، اگر کمزور سروس تک کوئی غیر ضروری اندرونی راستہ کھلا رہے۔

رسائی محدود کرنا اور hotfix نصب کرنا آئندہ اسی کمزوری سے حملے کا امکان کم کرتے ہیں، مگر پہلے ہو چکی دراندازی کے آثار خود بخود نہیں مٹاتے۔ اگر server کے بارے میں شبہ موجود ہو تو تازہ patch status کو صفائی کا سرٹیفکیٹ سمجھنا درست نہیں۔ اسی طرح انتظامی خدمت میں خلل آنے کا مطلب یہ بھی نہیں کہ ہر gateway نے فوراً ٹریفک چلانا بند کر دی؛ اس کا انحصار متاثرہ کام اور مقامی ترتیب پر ہے۔

ممکنہ دراندازی کے بعد policy کی سالمیت

تفتیش کا آغاز management web service اور متعلقہ لاگز میں مشکوک درخواستوں سے ہوتا ہے۔ غیر معمولی طور پر لمبے صارف نام کے ساتھ login کی کوششیں، مشکوک راستوں سے فائل لوڈ کرنے کی ناکامیاں، اور ان کے وقت سے ملتی غیر متوقع process یا فائل سرگرمی قابلِ توجہ اشارے ہیں۔ ایسا اشارہ ملنا کامیاب code execution کا قطعی ثبوت نہیں؛ اس کی تعبیر server کے دیگر شواہد کے ساتھ کرنی ہوگی۔ اشارہ نہ ملنا بھی قطعی صفائی ثابت نہیں کرتا، خصوصاً جب پرانے لاگز موجود نہ ہوں یا ان کی سالمیت مشکوک ہو۔

پھر سوال gateway پر exploit تلاش کرنے کا نہیں بلکہ یہ معلوم کرنے کا ہے کہ management سے کیا جاری ہوا۔ مشتبہ عرصے کی انتظامی سرگرمی، policy اور object کی تبدیلیاں، policy کی اشاعت اور gateways پر اس کی تنصیب ایک زمانی ترتیب میں دیکھنے سے غیر مجاز تبدیلی کا راستہ سامنے آ سکتا ہے۔ اگر غیر متوقع policy نصب ہوئی ہو تو اسی سے بالواسطہ اثر کا دائرہ متعین ہوگا؛ صرف management server میں کمزوری کی موجودگی اس نتیجے کی تصدیق نہیں کرتی۔

Multi-Domain Management میں متعلقہ domains کی سرگرمی الگ دیکھی جائے گی، کیونکہ ایک domain کے شواہد کو بلا تحقیق سب پر لاگو نہیں کیا جا سکتا۔ Log Server اور SmartEvent کے ریکارڈ بھی اہم ہیں، مگر ممکنہ دراندازی کے بعد انہی ریکارڈ کی قابلِ اعتماد حیثیت سوال بن سکتی ہے۔ اسی وجہ سے محفوظ شدہ لاگز، دستیاب system artifacts اور مجاز انتظامی تبدیلیوں کا باہمی موازنہ patch لگانے سے الگ تفتیشی کام ہے۔

اس وقت تصدیق کی حد

عوامی طور پر محدود ہدفی حملے، management web service کی کمزوری اور متاثرہ releases کے لیے اصلاح کی دستیابی تصدیق شدہ ہیں۔ دستیاب معلومات ہر متاثرہ ادارے، ہر حملے کے بعد ہونے والی سرگرمی یا کسی مخصوص gateway policy میں حقیقی تبدیلی کی مکمل فہرست نہیں دیتیں۔ اس لیے دو نتائج الگ رہیں گے: مقررہ hotfix کمزوری کا راستہ بند کرتا ہے، جبکہ management اور اس سے جاری شدہ policies پر دوبارہ اعتماد کے لیے ہر مشتبہ تنصیب کے شواہد کی جانچ درکار ہے۔

یہ بھی پڑھیں:

• PaperCut zero-day کے لیے دوسرا emergency patch؛ پہلے والا کافی نہیں
• Claude کے حفاظتی بند توڑے گئے، نیت اور جائز تحقیق میں فرق اب بھی مشکل
• Chrome کا V8 zero-day زیرِ استعمال ہے—152.0.7977.82 سے کم خطرے میں