Cisco ISE کی صفر روزہ خامی حملوں میں—workaround موجود نہیں

Cisco نے 16 ستمبر 2026 کو تصدیق کی کہ Cisco Identity Services Engine، یعنی ISE، اور ISE Passive Identity Connector میں CVE-2026-76460 حملوں میں استعمال ہو رہی ہے۔ Cisco کی 16 ستمبر کی advisory کے مطابق کمپنی نے fixed software جاری کر دیا ہے، مگر خامی کو دور کرنے والا کوئی workaround دستیاب نہیں۔

یہ خامی ایک غیر مصدقہ remote attacker کو crafted API request کے ذریعے web-based management interface کی authentication عبور کرکے متاثرہ ISE یا ISE-PIC نظام تک غیر مجاز رسائی دے سکتی ہے۔ کامیاب exploitation کے بعد root privileges کے ساتھ command execution ممکن ہے، اس لیے پاکستان میں ان مصنوعات کو چلانے والے اداروں کے لیے صرف exposure محدود کرنا کافی نہیں؛ متاثرہ release کو درست شدہ software پر منتقل کرنا ضروری ہے۔

یہ خامی اسی ہفتے کی دوسری ISE خرابیوں سے کیوں الگ ہے

16 ستمبر کو ISE سے متعلق متعدد security advisories شائع ہوئیں، لیکن ان سب کے exploitation status یکساں نہیں۔ CVE-2026-76460 کی امتیازی بات فعال حملوں کی تصدیق ہے: حملہ آور کو پہلے سے account، password یا صارف کے کسی عمل کی ضرورت نہیں، کیونکہ خرابی API endpoint پر ناکافی authentication control سے پیدا ہوتی ہے۔

خامی ISE اور ISE-PIC کو device configuration سے قطع نظر متاثر کرتی ہے اور اس کا CVSS base score 10.0 ہے۔ management interface تک غیر مجاز رسائی اس کا ابتدائی نتیجہ ہے؛ root-level command execution کی صلاحیت configuration، حساس معلومات اور پورے appliance کی سالمیت کو خطرے میں ڈال سکتی ہے۔ تاہم یہ کہنا درست نہیں کہ ہر کامیاب request کے بعد کسی مخصوص data set کی چوری لازماً ہوئی، کیونکہ Cisco نے حملوں کے بعد کی سرگرمی کی تفصیل جاری نہیں کی۔

امریکی CISA نے بھی 16 ستمبر کو اس CVE کو Known Exploited Vulnerabilities catalog میں شامل کیا۔ 17 ستمبر کے Canadian Cyber Centre کے انتباہ میں فعال exploitation کی تصدیق کرتے ہوئے اداروں کو اسی خامی کی remediation کو دوسری حالیہ ISE خرابیوں پر ترجیح دینے کا کہا گیا ہے۔

متاثرہ branches اور پہلے fixed releases

صرف یہ جاننا کافی نہیں کہ deployment ورژن 3.x استعمال کر رہا ہے؛ مکمل branch اور patch level دیکھنا ہوگا۔ پہلے fixed releases یہ ہیں:

• ISE یا ISE-PIC 3.1 کے لیے 3.1 Patch 12؛
• 3.2 کے لیے 3.2 Patch 11؛
• 3.3 کے لیے 3.3 Patch 12؛
• 3.4 کے لیے 3.4 Patch 7؛
• 3.5 کے لیے 3.5 Patch 4۔

Release 3.0 اپنی software-maintenance مدت پوری کر چکا ہے، اس لیے اسے اسی branch کے کسی آئندہ patch پر چھوڑنے کے بجائے supported fixed release پر منتقل کرنا ہوگا۔ 3.0 سے پہلے کے releases کے لیے بھی راستہ کسی درست شدہ، supported release کی طرف migration ہے۔ distributed deployment میں ہر node کا الگ version اور patch level درج ہونا چاہیے؛ primary node کی update خود بخود باقی nodes کو محفوظ ثابت نہیں کرتی۔

Workaround اور mitigation ایک چیز نہیں

“No workaround” کا مطلب ہے کہ configuration کی کوئی تبدیلی بنیادی vulnerability ختم نہیں کرتی۔ infrastructure access control lists یا iACLs کے ذریعے متاثرہ device تک صرف ضروری management اور control-plane traffic آنے دینا remote exploitation کا راستہ محدود کر سکتا ہے، مگر یہ عارضی mitigation ہے، مستقل remediation نہیں۔

اسی طرح internet سے management interface کی براہ راست رسائی بند کرنا، اسے trusted administration network تک محدود کرنا یا segmentation سخت کرنا exposure گھٹا سکتا ہے۔ غیر patched node پھر بھی vulnerable رہتا ہے، خصوصاً اگر کسی compromised internal host، VPN segment یا jump host کو اس کے management path تک رسائی حاصل ہو۔ اس لیے network restriction کو fixed release کی تنصیب کے بدلے استعمال نہیں کیا جا سکتا۔

منتظمین کے لیے ردعمل کی ترجیحی ترتیب

فعال exploitation کے پیش نظر پہلے deployment کی مکمل وسعت اور ممکنہ compromise دونوں کو دیکھنا ہوگا۔ عملی ترتیب یہ ہے:

1. Assets شناخت کریں: تمام ISE اور ISE-PIC nodes، ان کے exact releases، patch levels، deployment roles اور management addresses درج کریں۔ standby، disaster-recovery اور عارضی طور پر disconnected nodes بھی inventory میں شامل ہوں۔
2. Exposure متعین کریں: معلوم کریں کہ API یا management traffic کن internal networks، VPNs، jump hosts اور external addresses سے پہنچ سکتا ہے۔ غیر ضروری راستے موجودہ ACLs اور segmentation کے ذریعے محدود کیے جا سکتے ہیں، مگر اسے patching مکمل ہونے کا ثبوت نہ سمجھا جائے۔
3. ہر node کے logs دیکھیں: ise-kong/access.log اور API gateway access logs میں مشتبہ usernames اور غیر متوقع API activity تلاش کریں۔ distributed deployment میں صرف primary node کے logs کافی نہیں۔
4. بیرونی telemetry محفوظ کریں: متاثرہ appliance سے باہر موجود firewall اور network logs میں غیر متوقع uploads، downloads یا بیرونی IP connections دیکھیں۔ root access حاصل کرنے والا حملہ آور appliance پر موجود شواہد مٹا یا چھپا سکتا ہے۔
5. Fixed release نصب کریں: متعلقہ branch کا پہلا fixed patch یا اس سے نیا vendor-supported release اپنائیں۔ compatibility، backup اور nodes کی upgrade ترتیب کی جانچ ضروری ہے، لیکن فعال exploitation کے باعث معمول کے طویل patch cycle کا انتظار خطرہ بڑھاتا ہے۔

Compromise کا شبہ ہو تو upgrade کافی نہیں

اگر access log، firewall telemetry یا network records ممکنہ exploitation دکھائیں تو صرف software upgrade پہلے سے قائم دخل اندازی ختم کرنے کی ضمانت نہیں دیتا۔ ایسے nodes کو re-image کرنا اور ضرورت پڑنے پر known-good configuration backup سے بحال کرنا مناسب incident-response قدم ہے، کیونکہ root privileges persistence قائم کرنے اور مقامی indicators چھپانے کی گنجائش دیتے ہیں۔

The Register کی 17 ستمبر کی رپورٹ نے اسے actively exploited zero-day قرار دیا، لیکن حملہ آور کی شناخت، مہم کے آغاز کا وقت اور کامیاب رسائی کے بعد کیے گئے اقدامات اب بھی عوامی طور پر معلوم نہیں۔ فی الحال ثابت شدہ صورت حال یہی ہے کہ ISE اور ISE-PIC کے متاثرہ releases کے لیے fixes موجود ہیں، iACLs صرف exposure محدود کرتی ہیں، اور vulnerability کو ختم کرنے والا کوئی workaround نہیں۔

یہ بھی پڑھیں:

• NetScaler کی login bypass خامی حملوں میں، صرف مخصوص ترتیبات خطرے میں ہیں
• Thunderbird 155 میں high-risk خامیاں بند، صرف email کھولنا بڑا خطرہ نہیں
• HAProxy خامی نہیں، binary بدل دی گئی—Ted backdoor logs سے بھی چھپتا ہے