Subdomain Takeover: ডিএনএস কনফিগারেশনের ভুলে পরিত্যক্ত সাবডোমেইন হাইজ্যাক করার সাইবার পদ্ধতি!

Subdomain Takeover-এর core principle অত্যন্ত সহজ। যখন কোনো কোম্পানি একটি subdomain (যেমন blog.example.com) এর জন্য DNS-এ CNAME record তৈরি করে যা একটি external service (যেমন example-blog.herokuapp.com)-এর দিকে point করে, তখন সেই Heroku app যদি delete হয়ে যায় কিন্তু CNAME record DNS-এ থেকে যায়, তবে যে কেউ Heroku-তে গিয়ে example-blog নামে নতুন app তৈরি করতে পারে এবং কার্যকরভাবে blog.example.com এর নিয়ন্ত্রণ পেয়ে যায়।

এই dangling record-এর impact বিশাল। আক্রমণকারী subdomain-এ যেকোনো content host করতে পারে — phishing page, malware drop, credential harvesting form। ব্যবহারকারীরা legitimate domain-এ আছেন ভেবে সব trust দিয়ে দেন। যদি parent domain-এ session cookie scope থাকে (যেমন .example.com), তবে আক্রমণকারী cookie steal করতে পারে এবং main application-এও pivot করতে পারে। Email phishing campaign-এ legitimate domain-এর subdomain ব্যবহার করলে spam filter সহজে bypass হয়।

বিভিন্ন ধরনের DNS record subdomain takeover-এ সম্পৃক্ত হতে পারে। CNAME record সবচেয়ে common attack vector — যখন alias একটি unclaimed external service-এর দিকে point করে। NS record-এ যদি name server-এর কোনো একটি unclaimed হয়, তবে partial DNS hijacking সম্ভব। MX record-এর dangling reference email interception-এর সুযোগ দিতে পারে।

A record-এ direct IP point করা থাকলে সাধারণত takeover সম্ভব নয় (unless IP cloud provider-এর pool থেকে), কিন্তু ALIAS এবং ANAME record-এ CNAME-এর মতই risk। TXT record-এ verification token leftover থাকলে সেটা domain ownership claim করতে ব্যবহার করা যেতে পারে কিছু service-এ। DNS zone delegation-এর misconfiguration-এ আরও দূরবর্তী takeover-এর সুযোগ তৈরি হতে পারে।

প্রায় সব major cloud এবং SaaS provider-এর কিছু services subdomain takeover-এর জন্য vulnerable। AWS S3-এ যদি bucket delete হয়ে যায় এবং CNAME bucket-name.s3.amazonaws.com-এর দিকে point করে, তবে আক্রমণকারী একই নামে নতুন bucket তৈরি করতে পারে — যদি bucket name globally available থাকে।

Azure-এর বিভিন্ন service যেমন Azure Storage, Azure Web App, Azure CDN, Traffic Manager সবগুলোতেই এই risk রয়েছে। GitHub Pages একটি classic target — যদি username.github.io বা repo-name available থাকে, takeover সম্ভব। Heroku, Netlify, Vercel, Fastly, Shopify, Tumblr, WordPress.com, Zendesk, Helpjuice, Statuspage — তালিকা দীর্ঘ। প্রতিটি service-এর fingerprint আলাদা — কিভাবে detect করবেন এবং কিভাবে claim করবেন তার পদ্ধতিও আলাদা।

EdgeOne, Cloudflare-এর কিছু legacy product, Fastly-এর older domain mapping এবং বিভিন্ন regional CDN provider-এও takeover সম্ভব হয়েছে। প্রতিটি cloud provider সময়ের সাথে নিজেদের verification mechanism উন্নত করছে, কিন্তু legacy resource এবং deprecated service এখনও বিশাল attack surface।

Subdomain takeover discover করার জন্য systematic recon process প্রয়োজন। প্রথম ধাপ হলো comprehensive subdomain enumeration। Subfinder, Amass, assetfinder, chaos client — এসব tool ব্যবহার করে certificate transparency log, DNS bruteforce, web archive এবং passive DNS source থেকে subdomain collect করা হয়। বড় প্রতিষ্ঠানের জন্য ১০,০০০+ subdomain পাওয়া অস্বাভাবিক নয়।

এরপর প্রতিটি subdomain-এর DNS resolution check করা হয়। যেগুলোতে CNAME record exists কিন্তু final resolution fail করে (NXDOMAIN বা specific error), সেগুলো potential takeover candidate। dnsx, massdns-এর মতো high-speed DNS resolver bulk checking-এ ব্যবহৃত হয়।

Specialized tool যেমন subjack, subzy, takeover, nuclei (subdomain-takeover template সহ), can-i-take-over-xyz repository-র signature-এর সাথে match করে। প্রতিটি service-এর জন্য specific HTTP response pattern থাকে — যেমন GitHub Pages-এ "There isn't a GitHub Pages site here", Heroku-তে "No such app", Shopify-তে "Sorry, this shop is currently unavailable" — এই signature-গুলো detection-এ ব্যবহৃত হয়।

একটি confirmed takeover candidate পাওয়ার পর exploitation process service-specific হয়। GitHub Pages takeover-এ আক্রমণকারী একটি GitHub repository তৈরি করেন expected name-এ, settings-এ Pages enable করেন এবং custom domain হিসেবে target subdomain set করেন — কয়েক মিনিটের মধ্যেই subdomain attacker-controlled content serve শুরু করে।

Heroku-তে একই pattern — heroku create vulnerable-app-name চালালেই যথেষ্ট। S3-এ region-specific bucket creation — তবে globally unique name requirement থাকায় কিছু ক্ষেত্রে অন্য region-এ creation প্রয়োজন। Azure-এ Microsoft account দিয়ে Azure portal-এ resource creation।

বাস্তব example হিসেবে, 2014 সালে Detectify researcher Frans Rosén Microsoft, Tesla, Uber এবং Heroku-এর subdomain takeover demonstrate করেছিলেন। Uber-এর ক্ষেত্রে tcsdn.uber.com (Heroku-pointed) successful takeover-এর জন্য $৫,০০০ bounty পেয়েছিলেন। Starbucks-এর একটি subdomain takeover-এ research community $২,০০০ পেয়েছে। মার্কিন সরকারের .gov domain-এও বিভিন্ন সময়ে takeover discovered হয়েছে, যা বিশেষ concerning।

Subdomain takeover-এর সরাসরি impact-এর মধ্যে রয়েছে phishing হোস্টিং, যেখানে user trust-এর সুযোগ নিয়ে credential harvest করা যায়। login.bank.com.attacker.subdomain.com এর চেয়ে support.bank.com অনেক বেশি believable।

Cookie theft বড় ধরনের impact। যদি parent domain .bank.com-এ session cookie set থাকে (scope = .bank.com), তবে takeover-ed subdomain থেকেও সেই cookie read করা সম্ভব। Same-origin policy bypass-এর জন্য SOP technically apply হয় individual origin-এ, কিন্তু cookie scope এবং certain header (Access-Control-Allow-Origin wildcard-এর মতো) cross-subdomain attack সম্ভব করে।

OAuth এবং SSO callback অনেক সময় subdomain-এর জন্য whitelisted থাকে। Takeover-এর মাধ্যমে valid OAuth flow trigger করে authorization code intercept করা যায়। Email forging-এর ক্ষেত্রে takeover-ed subdomain SPF/DKIM-এর সাথে যুক্ত হলে spoofed email-এর deliverability বাড়ে। SEO manipulation-এর মাধ্যমে brand reputation damage এবং search ranking abuse করা সম্ভব।

Bug bounty hunter-দের জন্য subdomain takeover একটি favorite category — কারণ এর finding criteria clear, false positive কম এবং impact demonstrate করা সহজ। তবে responsible disclosure-এর জন্য কিছু important rule আছে। Proof of concept-এ minimal demonstration করতে হবে — শুধু একটি simple HTML page যা confirm করে takeover successful, কোনো malicious content নয়।

কখনোই legitimate user-দের affect করতে পারে এমন কিছু করা যাবে না — কোনো credential capture form, কোনো fake login page, কোনো cookie theft script। শুধু একটি text file বা simple PoC page যথেষ্ট। Disclosure-এর পর immediately resource release করতে হবে যাতে কেউ ইতিমধ্যে service exploit না করে।

Bounty payout সাধারণত medium থেকে high severity range-এ পড়ে — $৫০০ থেকে $১০,০০০+। Impact depends on parent domain criticality, cookie scope এবং OAuth integration। main-product.company.com এর takeover অনেক বেশি payout দিবে temp-event-2018.company.com এর তুলনায়।

Subdomain takeover প্রতিরোধে কয়েকটি critical strategy আছে। সবচেয়ে গুরুত্বপূর্ণ হলো DNS hygiene — proper lifecycle management। যখন কোনো cloud resource decommission করা হয়, একই সময়ে সেই DNS record-ও cleanup করতে হবে। অনেক প্রতিষ্ঠানে DNS ownership এবং cloud resource ownership আলাদা team-এর কাছে থাকে, যা coordination challenge তৈরি করে।

Centralized DNS management এবং Infrastructure as Code (Terraform, Pulumi) ব্যবহার করলে drift detection সহজ হয়। CI/CD pipeline-এ DNS record validation step যোগ করা যায়। Periodic audit এবং automated scanning — internal tool বা commercial solution (Detectify, ProjectDiscovery cloudlist) — দিয়ে dangling record discover করা যায়।

Cloud provider-level protection-এ many service এখন domain verification require করে CNAME activation-এর আগে। AWS-এর Route53 health check, Azure-এর DNSSEC, Cloudflare-এর registrar service এই risk কমায়। CAA (Certificate Authority Authorization) record certificate-level abuse কমাতে সাহায্য করে।

প্রতিষ্ঠানের জন্য proactive bug bounty program একটি good investment — external researcher-রা automated tool-এর চেয়ে বেশি sophisticated findings discover করেন। Security awareness-এ DevOps এবং Marketing team-কে include করতে হবে কারণ অনেক subdomain তাদের initiative থেকেই তৈরি হয়।