OIDC Exploitation: ওপেনআইডি কানেক্ট প্রোটোকলের দুর্বলতা কাজে লাগিয়ে সাইবার হামলা!

OpenID Connect হলো OAuth 2.0 এর উপর একটি simple identity layer যা client কে end-user এর identity verify করতে দেয়। OAuth শুধু authorization handle করে (token কী কী access করতে পারে), কিন্তু OIDC authentication add করে (user কে?)।

OIDC এর core component হলো ID Token, যা একটি JWT (JSON Web Token)। ID Token এ user সম্পর্কে claims থাকে: sub (subject identifier), iss (issuer), aud (audience), exp (expiration), iat (issued at), auth_time (authentication time), nonce, এবং optional claims যেমন email, name, picture।

OIDC এর তিনটি main flows আছে: Authorization Code Flow, Implicit Flow (deprecated), এবং Hybrid Flow। Authorization Code Flow এ tokens token endpoint থেকে আসে (back channel)। Implicit Flow এ tokens directly authorization endpoint থেকে URL fragment এ আসে। Hybrid Flow এ কিছু tokens front channel এ এবং কিছু back channel এ আসে।

OIDC এর গুরুত্বপূর্ণ endpoints: Authorization Endpoint (user interaction), Token Endpoint (token issuance), UserInfo Endpoint (user details), JWKS Endpoint (public keys), Discovery Endpoint (configuration), এবং Logout Endpoint।

Discovery Document (/.well-known/openid-configuration) একটি গুরুত্বপূর্ণ endpoint। এটি OIDC provider এর সব endpoints, supported algorithms, claims, scopes ইত্যাদি প্রকাশ করে। এই document দিয়ে clients automatically configure হতে পারে।

JWT structure তিনটি Base64-encoded parts: Header, Payload, Signature। Header এ alg (algorithm), kid (key ID), typ (type)। Payload এ claims। Signature এ Header এবং Payload এর cryptographic signature।

OIDC exploitation এর সবচেয়ে common vector হলো JWT signature verification flaws। Algorithm Confusion attacks এ attacker alg=none দিয়ে signature বাদ দিতে চেষ্টা করে। যদি library এটি accept করে, যেকোনো claims forge করা যায়।

RS256 to HS256 confusion আরেকটি কুখ্যাত attack। RS256 এ asymmetric verification (private key দিয়ে sign, public key দিয়ে verify)। HS256 এ symmetric (same key দিয়ে sign এবং verify)। যদি verification code algorithm parameter trust করে, attacker public key (যা সবার জন্য available) HS256 secret হিসেবে ব্যবহার করে valid token তৈরি করতে পারে।

kid (Key ID) parameter abuse আরেকটি vector। কিছু implementation kid থেকে key fetch করে database query এর মাধ্যমে। SQL injection বা path traversal এই jain place এ exploit করা যায়। কিছু ক্ষেত্রে kid এ specific values যেমন "../../../dev/null" দিয়ে empty key force করা যায়।

jku (JWK Set URL) header parameter অত্যন্ত dangerous যদি validate না করা হয়। Attacker তার own URL দিয়ে valid signature তৈরি করতে পারে। RFC 7515 এ jku এর strict validation requirement আছে।

x5u (X.509 URL) এবং x5c (X.509 Certificate Chain) similar risk বহন করে।

Token Audience Validation Failures common vulnerabilities। যদি client aud claim verify না করে, একটি AS থেকে issued token অন্য client এ ব্যবহার করা যায়। Cross-tenant attacks এ multi-tenant SaaS এ এক tenant এর token অন্য tenant এ ব্যবহার করার চেষ্টা।

Issuer Validation Bypass এ attacker malicious issuer থেকে token তৈরি করে যদি client iss claim properly check না করে।

Nonce Replay Attacks এ ID token এর nonce যদি validate না করা হয়, একই token multiple times ব্যবহার করা যায়।

State Parameter omission OIDC এও OAuth এর মতো CSRF risk তৈরি করে।

OIDC exploitation এর বাস্তব ঘটনা অনেক। ২০২৩ সালের Microsoft Storm-0558 incident এ Chinese threat actors একটি Microsoft consumer signing key চুরি করেছিল। সেই key দিয়ে তারা Azure AD এর enterprise customers এর mailboxes access করার জন্য valid OIDC tokens forge করেছিল। US State Department সহ অনেক organization এই attack এর victim ছিল।

CVE-2018-1000531 (Jose4j library) এ একটি critical vulnerability ছিল যেখানে JWE alg=none accept করা হত। CVE-2022-21449 (Java psychic signatures) এ ECDSA signatures এর verification bypass সম্ভব ছিল।

GitHub Actions এর একটি incident এ OIDC tokens via workflow logs leak হয়েছিল। Actions workflows AWS, Azure, GCP এ deploy করার জন্য OIDC tokens generate করত। কিছু workflows tokens log করে দিচ্ছিল যা public repositories থেকে readable ছিল।

Auth0 (এখন Okta এর অংশ) ২০২২ সালে একটি configuration vulnerability disclose করেছিল যেখানে custom domains এর সাথে JWT validation এ flaw ছিল।

একটি practical exploitation scenario বিবেচনা করা যাক। একটি SaaS application "Login with Google" support করে। Pentester প্রথমে discovery document fetch করেন: curl https://accounts.google.com/.well-known/openid-configuration।

এই document থেকে JWKS endpoint এবং supported algorithms জানা যায়। তারপর tester একটি valid OIDC flow চালু করেন এবং একটি real ID token capture করেন।

JWT.io বা CyberChef এ token decode করে header, payload, signature বিশ্লেষণ করা হয়। উদাহরণস্বরূপ একটি token:

• Header: {"alg":"RS256","kid":"abc123","typ":"JWT"}
• Payload: {"iss":"https://accounts.google.com","sub":"1234567890","aud":"client-id","exp":1716422400,"iat":1716418800,"email":"[email protected]","email_verified":true}

Attack #1 - Algorithm None: Header কে {"alg":"none","typ":"JWT"} এ change করে, signature remove করে। যদি client accept করে, যেকোনো claims forge করা যায়।

Attack #2 - HS256 Confusion: যদি client RS256 expect করে কিন্তু algorithm trust করে, attacker public key (JWKS থেকে) দিয়ে HS256 signature তৈরি করে।

Attack #3 - kid Manipulation: kid header কে "../../../dev/null" বা malicious SQL injection payload দিয়ে replace করে।

Attack #4 - jku Injection: একটি malicious JWKS endpoint তৈরি করে যা attacker এর public key serve করে। JWT header এ jku পরিবর্তন করে own URL এ point করে। Self-signed JWT তৈরি করে।

Attack #5 - aud Confusion: একটি legitimate application এর জন্য issued token নিয়ে target application এ ব্যবহার করার চেষ্টা।

Attack #6 - Email Verification Bypass: যদি client শুধু email match করে user identify করে, attacker একটি unverified email দিয়ে account hijack করতে পারে। OIDC provider এ email change করে, "email_verified": false রেখে।

একটি real-world bug bounty scenario। Researcher একটি major fintech application এ "Login with Microsoft" feature test করছিলেন। তিনি লক্ষ্য করলেন application multi-tenant Azure AD configuration ব্যবহার করছে কিন্তু tenant restrictions enforce করছে না।

তিনি Azure AD এ তার own tenant তৈরি করলেন এবং সেখানে victim এর email তে একটি account তৈরি করলেন (since multi-tenant accepts any tenant)। তিনি login করলেন এবং তার tenant এর OIDC token পেলেন। Token এ iss claim তার own tenant এর। Application যদি iss properly validate না করে এবং শুধু email match করে, account takeover সম্ভব।

আরেকটি incident এ একটি healthcare platform এ OIDC Discovery Document caching vulnerability ছিল। Application discovery document শুধু একবার fetch করে long-term cache করছিল। Attacker একটি SSRF vulnerability ব্যবহার করে cache poison করতে পেরেছিল, যা OIDC এর fundamental trust break করেছিল।

Federated Identity Attacks বিশেষভাবে দুর্ভাবনার বিষয়। যখন একটি organization SAML থেকে OIDC এ migrate করে বা hybrid চালায়, transition period এ vulnerabilities দেখা দেয়। CVE-2023-50164 এর মতো issues federation এর জটিলতা প্রদর্শন করে।

বাংলাদেশের একটি e-government platform এ OIDC implementation এর সময় common mistake দেখা গেছে। ID token signature verification ছিল কিন্তু claims validation incomplete ছিল। Pentester দেখান যে exp claim manipulate করে expired tokens reuse করা যায়।

Cross-Origin Token Theft আরেকটি concern। যদি OIDC tokens browser fragments বা localStorage এ store করা হয় এবং application এ XSS vulnerability থাকে, complete account takeover সম্ভব।

PKCE Downgrade Attack এ যদি AS PKCE optional রাখে এবং client malicious হতে পারে, attacker authorization code intercept করে নিজে redeem করতে পারে।

Logout Flaws এ যদি OIDC logout endpoint properly implement না হয়, session fixation এবং persistence issues দেখা যায়। RP-Initiated Logout এর proper implementation critical।

OIDC implementations কে সুরক্ষিত করতে comprehensive approach প্রয়োজন। প্রথমেই, well-maintained libraries ব্যবহার করতে হবে। নিজস্ব JWT parsing বা signature verification লেখা পরিহার করতে হবে। OIDC certified libraries যেমন node-openid-client, oidc-client-ts, Microsoft.AspNetCore.Authentication.OpenIdConnect, Python authlib ইত্যাদি ব্যবহার করা উচিত।

JWT Validation এর প্রতিটি step thoroughly perform করতে হবে। Signature verification (always required), expiration check (exp claim), not-before check (nbf claim), issuer validation (iss claim), audience validation (aud claim), এবং nonce validation (OIDC এ)।

Algorithm Whitelist enforce করতে হবে। JWT library এ explicitly allowed algorithms specify করতে হবে। alg=none কখনো accept করা যাবে না। Algorithm parameter কে blindly trust করা যাবে না - server-side এ expected algorithm independently determine করতে হবে।

Key Management সাবধানে করতে হবে। JWKS endpoint থেকে keys fetch করার সময় HTTPS verify করতে হবে। Keys cache করতে হবে কিন্তু reasonable expiration সহ। kid mismatch হলে JWKS refresh করতে হবে। Hardcoded keys পরিহার করতে হবে।

jku, x5u, x5c headers ignore করতে হবে অথবা strict whitelist এর বিরুদ্ধে validate করতে হবে। বেশিরভাগ scenario এ এই headers একদম process না করা best।

Discovery Document Validation: HTTPS over verified TLS। Periodic refresh কিন্তু reasonable interval এ। Critical fields যেমন issuer, jwks_uri একবার determined হলে strictly validate করতে হবে।

Tenant Restrictions Multi-tenant scenarios এ critical। যদি একটি application specific organizations এর জন্য, iss claim এ allowed tenants whitelist করতে হবে। Microsoft Entra ID এ tid (tenant ID) claim verify করা উচিত।

Email Verification policy strict হতে হবে। শুধু email basis এ account linking বিপজ্জনক। email_verified claim mandatory check। যদি provider verification status report না করে, default এ untrusted treat করতে হবে।

Account Linking Carefully implement করতে হবে। যদি একই user multiple OIDC providers দিয়ে login করে, accounts merge করার আগে strong verification (যেমন email confirmation) প্রয়োজন।

Token Storage best practices অনুসরণ করতে হবে। Server-side sessions preferred over JWT in cookies/localStorage। যদি tokens browser এ store করা লাগে, httpOnly secure cookies।

PKCE Mandatory করতে হবে সব OIDC flows এ। শুধু public clients নয়, confidential clients এও PKCE recommended।

State এবং Nonce parameters mandatory করতে হবে। Cryptographically secure random values, session এর সাথে bound, single-use।

ID Token vs Access Token এর সঠিক ব্যবহার বুঝতে হবে। ID Token authentication এর জন্য, Access Token authorization এর জন্য। ID Token API calls এ ব্যবহার করা উচিত নয়।

Logout Implementation comprehensive হতে হবে। Local session termination, OIDC provider session termination (RP-Initiated Logout), token revocation, এবং proper redirect handling।

Refresh Token Handling সাবধানে। Refresh tokens shorter lifetime এর সাথে rotation, abuse detection (reuse → revoke entire family), এবং secure storage।

Audit Logging comprehensive: Login events, token validation failures, suspicious patterns, configuration changes। SIEM integration through structured logging।

Monitoring এবং Anomaly Detection: Impossible travel, multiple device logins, unusual login times, geographic anomalies, repeated failed authentications।

Federation Trust Carefully Established। যেকোনো OIDC provider কে blindly trust করা যাবে না। Verified providers এর whitelist maintain করতে হবে। Provider এর security practices regularly review করতে হবে।

Library Updates Critical। JWT libraries তে নিয়মিত CVEs publish হয়। Automated dependency scanning এবং rapid patching essential।

Security Testing Specific to OIDC: jwt_tool, oidc-vulnerability-scanner এর মতো tools দিয়ে regular testing। Manual review of token validation logic। Bug bounty programs এ OIDC scope include করা।

Standards Compliance এ OpenID Foundation এর Certified Implementations preferred। Connect2id, ForgeRock, Okta, Auth0, Microsoft Identity Platform - সবাই certified providers।

FAPI (Financial-grade API) profile high-security scenarios এর জন্য। Banking, healthcare, government এ FAPI requirements consider করতে হবে।

Privacy Considerations। OIDC tokens এ unnecessary PII অন্তর্ভুক্ত না করা। Claims minimization principle। Pairwise subject identifiers যেখানে user privacy critical।

Documentation এবং Training: Developers দের OIDC এর nuances বুঝতে regular training। Security teams এর OIDC attack vectors সম্পর্কে updated knowledge। Incident response plans এ OIDC scenarios।

Disaster Recovery: Key compromise scenarios pre-planned। Mass token revocation procedures। Backup signing keys properly secured।