SAML Hacking: এন্টারপ্রাইজ സിঙ্গেল সাইন-অন প্রোটোকল বাইপাস করে অননুমোদিত অ্যাক্সেস!

SAML একটি XML-based open standard, যা OASIS দ্বারা স্ট্যান্ডার্ডাইজড। এর কেন্দ্রে তিনটি প্রধান entity—Identity Provider (IdP), Service Provider (SP), এবং User Agent (সাধারণত একটি browser)।

একটি সাধারণ SP-initiated SSO flow এভাবে চলে। ব্যবহারকারী একটি SP-এর কোনো protected resource access করতে চান। SP যাচাই করে দেখে যে কোনো active session নেই, তাই এটি একটি SAML AuthnRequest তৈরি করে এবং browser-এর মাধ্যমে IdP-তে redirect করে। IdP ব্যবহারকারীকে authenticate করে (পাসওয়ার্ড, MFA, যা-ই থাকুক), এবং একটি SAML Response তৈরি করে যার মধ্যে একটি signed Assertion থাকে। এই Assertion-এ ব্যবহারকারীর identity, attribute, এবং কত সময়ের জন্য valid—সব তথ্য থাকে। Browser এই Response-কে SP-র Assertion Consumer Service (ACS) endpoint-এ POST করে। SP signature verify করে এবং valid হলে user-কে session দেয়।

পুরো নিরাপত্তা মডেলটি XML Digital Signature (XML-DSig)-এর উপর নির্ভরশীল। Assertion-এ যা লেখা আছে সেটি সত্য কিনা—তা signature দিয়ে যাচাই করা হয়। সমস্যা হলো XML-DSig একটি ভয়ংকর জটিল spec, এবং এর implementation-এ ঐতিহাসিকভাবে অসংখ্য subtle vulnerability ধরা পড়েছে।

SAML-এর সবচেয়ে বিখ্যাত vulnerability class হলো XML Signature Wrapping বা XSW। এর মূল ধারণা হলো signature যেই element-এ apply করা হয়েছে এবং SP যেই element কে process করছে—এই দুটির মধ্যে disconnect তৈরি করা।

একটি SAML Response-এ একাধিক Assertion থাকতে পারে। আক্রমণকারী একটি valid signed Assertion (যা তারা পূর্বে capture করেছে) নিয়ে সেটিকে document-এর কোনো এক জায়গায় রাখে, এবং একটি forged Assertion তৈরি করে অন্য জায়গায় inject করে। যদি signature verifier signed Assertion-কে valid বলে, কিন্তু SAML processor unsigned Assertion থেকে attribute (যেমন NameID) extract করে, তাহলে আক্রমণ সফল।

এই attack-এর বহু variant আছে। Type 1-এ original Assertion-কে wrap করা হয় একটি new wrapper element-এ। Type 2-এ Extensions element ব্যবহার করা হয়। Type 8-এ XPath-based অস্পষ্টতা exploit করা হয়। প্রতিটি variant signature validation logic-এ ভিন্নভাবে আঘাত করে।

২০১২ সালের একাডেমিক গবেষণায় Somorovsky-র দল Salesforce, Shibboleth, IBM, SAP-এর মতো প্রধান SAML implementation-এ এই vulnerability ধরে ফেলেন। ১২টির মধ্যে ১১টিই vulnerable ছিল। এর পর থেকে অনেক library fix হলেও, custom implementation আজও এই সমস্যায় আক্রান্ত পাওয়া যায়।

আরেকটি classic attack হলো signature পুরোপুরি strip করে দেওয়া। কিছু dilettante SAML library "signature optional" mode সাপোর্ট করে—যদি SAML Response-এ Signature element না থাকে, তাহলে এটি unsigned হিসেবে accept করে। এই অপশন নিরাপত্তার দৃষ্টিকোণ থেকে disastrous। আক্রমণকারী Signature element সরিয়ে দিলেও SP Assertion accept করে নেয়।

Algorithm confusion আরেকটি বিপদ। SAML XML-DSig HMAC এবং asymmetric signature উভয়ই সাপোর্ট করে। যদি verifier algorithm-কে trust করে document-এর declared algorithm থেকে, তাহলে আক্রমণকারী public key-কে HMAC secret হিসেবে ব্যবহার করে নিজেই signature generate করতে পারে।

২০১৭ সালে CyberArk-এর গবেষকরা "Golden SAML" নামে একটি ভয়াবহ post-compromise attack technique প্রকাশ করেন। এর ধারণা সরাসরি Active Directory-র Golden Ticket-এর সাথে সমান্তরাল।

যদি আক্রমণকারী IdP-র (যেমন ADFS) signing certificate-এর private key পেতে সক্ষম হয়, তাহলে তারা যেকোনো user-এর জন্য, যেকোনো attribute সহ, যেকোনো validity period-এর Assertion তৈরি করতে পারে। SP-র কাছে এই Assertion একদম legitimate দেখাবে, কারণ signature valid। কোনো brute force, MFA bypass, বা credential theft দরকার নেই।

SolarWinds হামলায় (২০২০) এই কৌশল ব্যাপকভাবে ব্যবহৃত হয়। UNC2452/Nobelium গোষ্ঠী compromised on-premise environment থেকে ADFS token signing certificate চুরি করে এবং Microsoft 365 cloud environment-এ যেকোনো user হিসেবে অনুপ্রবেশ করতে সক্ষম হয়। এর কারণে SAML token forgery cloud security-র এক নম্বর উদ্বেগে পরিণত হয়।

XML External Entity (XXE) injection SAML-এ একটি common সমস্যা। SAML Response XML, এবং অনেক parser default-এ external entity resolve করে। একটি malicious DOCTYPE declaration দিয়ে আক্রমণকারী SP-র server থেকে file পড়তে পারে বা SSRF করতে পারে।

Replay attack-ও একটি concern। SAML Assertion-এ NotBefore, NotOnOrAfter, এবং Conditions থাকে যা time window define করে। যদি SP এই সব check ঠিকমতো না করে, তাহলে পুরাতন captured Response replay করে session hijack করা যায়।

Audience restriction bypass আরেকটি subtle bug। প্রতিটি Assertion-এ "AudienceRestriction" থাকার কথা যা বলে এই Assertion কোন SP-র জন্য valid। যদি SP এই check skip করে, তাহলে একটি SP-র জন্য issued Assertion অন্য SP-তে accept হয়ে যেতে পারে।

Recipient validation missing হলেও বিপদ। AssertionConsumerService URL match না করলে cross-SP token reuse সম্ভব।

URL parser-এর difference-ভিত্তিক attack: SAML বিভিন্ন endpoint URL parse করে। যদি IdP এবং SP URL-কে ভিন্নভাবে normalize করে, তাহলে redirect-এর সময় token মাঝপথে hijack হতে পারে।

২০২৩ সালে ownCloud-এ একটি SAML-related vulnerability (CVE-2023-49105) প্রকাশ পায়, যেখানে subdomain validation bypass করে authentication bypass করা যেত। এর কয়েক মাস আগে GitHub Enterprise Server-এও SAML SSO-তে authentication bypass বাগ পাওয়া যায়, যা সব tenant-কে affect করত।

Citrix-এর ADFS-related issue, Microsoft-এর SAML2-related advisory—এই ধরনের headline প্রতি বছরই উঠে আসে। SAML standard পুরাতন, library mature, কিন্তু integration এবং customization-এ ভুল হওয়ার সুযোগ এখনও বিস্তর।

SAML অ্যাসেসমেন্টের জন্য SAML Raider (Burp Suite extension), samlsplitter, এবং WS-Attacker-এর মতো specialized tool আছে। Burp-এ SAML Editor extension Assertion সরাসরি Burp interface-এ edit করার সুবিধা দেয়।

প্রথম পদক্ষেপ হলো SAML metadata XML সংগ্রহ এবং বিশ্লেষণ। সাধারণত IdP এবং SP-র metadata public URL-এ থাকে। এটি signing/encryption certificate, supported binding, এবং endpoint URL সম্পর্কে গুরুত্বপূর্ণ তথ্য দেয়।

পরবর্তী ধাপ হলো লাইভ SAML Response intercept করা এবং বিভিন্ন XSW variant চেষ্টা করা। SAML Raider-এর built-in XSW templates এই কাজ সহজ করে। Signature wrap করে দেখুন SP কীভাবে react করে—accept করে, reject করে, না crash করে।

Audience, Recipient, NotOnOrAfter manipulate করে boundary case test করুন। Assertion-এর NameID পরিবর্তন করে impersonation চেষ্টা করুন। যদি SP unauthenticated assertion accept করে, তাহলে critical bug।

Encrypted Assertion-এর জন্য চেক করুন—encryption mandatory কি না, কোন algorithm allowed, এবং padding oracle attack possible কিনা।

SAML নিরাপদ রাখতে কিছু অপরিহার্য practice অনুসরণ করতে হবে।

প্রথমত, mature SAML library ব্যবহার করুন। নিজে XML Signature validation কখনো implement করবেন না। OneLogin's python-saml, Spring Security SAML, Microsoft IdentityModel-এর মতো well-maintained library ব্যবহার করুন এবং নিয়মিত update করুন।

দ্বিতীয়ত, signature validation strict রাখুন। Unsigned Response কখনো accept করবেন না। Signature element-এর reference সঠিকভাবে validate করুন—signed element-ই যেন process হয়, অন্য কোনো wrapped element নয়।

তৃতীয়ত, প্রতিটি field validate করুন: Issuer, Audience, Recipient, NotBefore, NotOnOrAfter, InResponseTo, Destination। কোনোটিই optional হিসেবে treat করবেন না।

চতুর্থত, Assertion encryption enable করুন যেখানে possible। Confidentiality-এর জন্য এটি অপরিহার্য, বিশেষ করে যদি Assertion-এ sensitive attribute থাকে।

পঞ্চমত, certificate management discipline। IdP-র signing certificate-এর private key HSM-এ রাখুন। Certificate rotation policy তৈরি করুন। কখনোই signing certificate-এর private key file system-এ unencrypted রাখবেন না।

ষষ্ঠত, Golden SAML বিরুদ্ধে layered defense। ADFS-এর জন্য Azure AD Connect Health-এর মতো monitoring tool ব্যবহার করুন যা token signing-এর anomaly detect করতে পারে। Cloud-এ চলে গেলে on-premise dependency কমাতে চেষ্টা করুন।

সপ্তমত, XML parser hardening। DOCTYPE disable করুন, external entity resolution off করুন। প্রতিটি SAML parser-এ এই hardening একটি baseline requirement।

অষ্টমত, modern alternative consider করুন। নতুন application-এর জন্য OIDC (OpenID Connect) সাধারণত SAML-এর তুলনায় simpler এবং কম error-prone। JSON-based, REST-friendly, এবং mobile-friendly। নতুন project-এ SAML-এর চেয়ে OIDC বেশি সুপারিশযোগ্য।

SAML-related compromise detect করা চ্যালেঞ্জিং, কারণ valid signed Assertion দেখতে legitimate। তবে কিছু behavioral indicator আছে।

IdP log-এ অস্বাভাবিকভাবে অনেক token issuance, বিশেষ করে service account থেকে। Cloud platform-এ (যেমন Microsoft 365) sign-in log-এ unusual IP, geo-location, বা device থেকে login। Token-এর unusual validity period—সাধারণত ১ ঘণ্টা valid token হঠাৎ ২৪ ঘণ্টা valid হওয়া।

Microsoft দিয়েছে কিছু advisory এবং tooling, যেমন Azure AD Sign-in Risk policy, যা ML-ভিত্তিক anomaly detection করে। Splunk, Sentinel-এ SAML-specific detection rule deploy করা যায়।

Incident response-এর সময় প্রথম পদক্ষেপ হলো signing certificate rotation। Compromise সন্দেহ হলে অবিলম্বে নতুন certificate generate করুন এবং পুরাতনটি revoke করুন। সব active session terminate করুন। User-এর জন্য re-authentication বাধ্যতামূলক করুন।