SSRF Exploitation: সার্ভার-সাইড রিকোয়েস্ট ফোর্জারি ব্যবহার করে ইন্টারনাল নেটওয়ার্ক স্ক্যানিং এবং হ্যাকিং!

SSRF-এর মূল কারণ হলো user-supplied URL বা hostname-কে server-side থেকে কোনো validation ছাড়া fetch করা। উদাহরণস্বরূপ, একটি image-fetching feature যেখানে user URL provide করে এবং server সেই URL থেকে image download করে preview দেখায়। যদি validation না থাকে, attacker URL হিসেবে http://localhost:8080/admin বা http://169.254.169.254/latest/meta-data/ দিতে পারে, যা server-এর perspective থেকে fetch হবে।

এই দুর্বলতা সাধারণত PDF generation, webhook integration, URL preview, file import, OAuth/SSO callback, image processing, RSS feed reader এবং proxy functionality-তে পাওয়া যায়। SSRF কে দুই ভাগে ভাগ করা যায় — Basic SSRF যেখানে response attacker-কে ফিরিয়ে দেওয়া হয়, এবং Blind SSRF যেখানে response visible নয় কিন্তু side channel (timing, error message, DNS lookup) দিয়ে information extract করা যায়। উভয়ই সমানভাবে বিপজ্জনক হতে পারে।

SSRF-এর সবচেয়ে devastating impact দেখা যায় cloud environment-এ। AWS, Azure, GCP — সব major cloud provider-এ একটি instance metadata service থাকে যা ১৬৯.২৫৪.১৬৯.২৫৪ IP-এ accessible। এই service থেকে instance role-এর temporary IAM credential পাওয়া যায়, যা ব্যবহার করে attacker সম্পূর্ণ AWS account compromise করতে পারে।

AWS IMDSv1-এ কোনো authentication ছিল না — শুধু HTTP GET request পাঠালেই credential মিলত। http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name endpoint থেকে AccessKeyId, SecretAccessKey এবং Token পাওয়া যেত, যা ব্যবহার করে AWS CLI দিয়ে S3 bucket, RDS database, এমনকি EC2 instance manipulate করা সম্ভব। Capital One incident-এ ঠিক এই pattern follow করা হয়েছিল।

AWS IMDSv2 এই সমস্যা সমাধানে session token-based access introduce করেছে — যেখানে PUT request দিয়ে token নিতে হয় এবং সেই token দিয়ে GET request পাঠাতে হয়। তবে অনেক organization এখনও IMDSv1 enable রেখেছে backward compatibility-র জন্য। Azure এবং GCP-এর metadata service-এও similar pattern রয়েছে, প্রতিটিতে আলাদা header requirement (Metadata: true, Metadata-Flavor: Google)।

SSRF-এর মাধ্যমে internal network পুরোপুরি scan করা সম্ভব। যেহেতু request server-side থেকে initiate হচ্ছে, তাই internal IP range (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) accessible। Attacker http://10.0.0.1:22, http://10.0.0.1:3306, http://10.0.0.1:6379 ইত্যাদি endpoint scan করে open port এবং service identify করতে পারে — response time, error message এবং banner থেকে service fingerprinting করা যায়।

অভ্যন্তরীণ admin panel যেমন Jenkins, GitLab, internal Confluence, ElasticSearch, MongoDB, Redis — যেগুলো সাধারণত public internet থেকে accessible নয় — SSRF-এর মাধ্যমে অ্যাক্সেস করা সম্ভব। অনেক internal service-এ default credential বা no authentication থাকে কারণ তাদের "trusted network" assumption থাকে। Redis-এ unauthenticated SSRF দিয়ে SET, GET এমনকি SAVE command চালানো যায়, যা remote code execution-এ পরিণত হতে পারে।

Gopher protocol exploitation একটি advanced technique যেখানে SSRF-এর মাধ্যমে arbitrary TCP packet পাঠানো যায়। gopher://internal-redis:6379/_SET key value এর মতো payload Redis-এ command inject করতে পারে। MySQL, Memcached, SMTP-এও gopher-based exploit demonstrated হয়েছে।

Developer-রা প্রায়ই naive blacklist-based validation implement করেন যা সহজে bypass করা যায়। সবচেয়ে সাধারণ bypass হলো IP encoding variation। 127.0.0.1 কে 2130706433 (decimal), 0x7f000001 (hex), 0177.0.0.1 (octal), 127.1 (shortened) — বিভিন্নভাবে represent করা যায়। IPv6 representation যেমন [::1] বা [0:0:0:0:0:ffff:127.0.0.1] কেও blacklist মিস করে।

DNS rebinding একটি sophisticated technique যেখানে attacker-controlled domain প্রথমে valid public IP-এ resolve করে validation pass করে, এবং কিছুক্ষণ পর internal IP-এ resolve করে actual request fulfill করে। এর বিরুদ্ধে DNS pinning এবং consistent resolution checking প্রয়োজন।

URL parser inconsistency exploit করাও একটি বড় bypass class। Browser এবং server-এর URL parsing-এ differ থাকতে পারে — যেমন http://[email protected]/ URL-এ অনেক parser expected.com কে hostname হিসেবে নেয়, আবার অনেকে attacker.com কে। Trailing dot (http://attacker.com.), URL fragment, double-encoding, Unicode normalization — সব ধরনের edge case attacker-রা explore করে। Redirect-based bypass-এ attacker-controlled URL initial validation pass করে এবং HTTP 302 redirect-এর মাধ্যমে internal target-এ পাঠায়।

Blind SSRF-এ response পাওয়া যায় না, তাই detection কঠিন। Out-of-band detection technique-এ Burp Collaborator, interact.sh বা custom-controlled DNS server ব্যবহার করা হয়। Attacker একটি unique subdomain payload হিসেবে inject করেন এবং DNS query/HTTP hit থেকে confirm করেন যে server request পাঠাচ্ছে।

Time-based detection-এ internal port-এ request পাঠিয়ে response time observe করা হয় — open port quickly response করে, closed port-এ timeout হয়। Boolean-based exploitation-এ error message বা HTTP status code-এর difference থেকে information extract করা যায়। Blind SSRF অনেক ক্ষেত্রেই internal service exploitation-এ ব্যবহৃত হয় যেখানে output প্রয়োজন নয় — যেমন internal API trigger, queue manipulation বা destructive action।

Capital One breach (২০১৯) ছিল সবচেয়ে আলোচিত SSRF incident। Paige Thompson একটি misconfigured Web Application Firewall exploit করে ModSecurity-র through SSRF করেন, AWS metadata থেকে temporary credentials সংগ্রহ করেন এবং S3 buckets থেকে ১০৬ মিলিয়ন গ্রাহকের তথ্য exfiltrate করেন।

২০২১ সালের Microsoft Exchange ProxyShell vulnerability chain-এ SSRF একটি critical component ছিল। GitLab-এর CVE-2021-22214-এ SSRF discovered হয়েছিল যা authenticated user-কে internal endpoint access-এর সুযোগ দিত। Shopify-তে অনেকবার SSRF discovered হয়েছে যেগুলোর bug bounty $২৫,০০০-এর বেশি পেয়েছে। Twitter-এর URL preview functionality-তেও বিভিন্ন সময়ে SSRF found হয়েছে।

২০২৪ সালের Ivanti Connect Secure এবং Fortinet FortiOS-এ পাওয়া SSRF-related CVE এই দুর্বলতা যে শুধু ওয়েব অ্যাপ্লিকেশনে সীমাবদ্ধ নয়, বরং network appliance এবং VPN gateway-এও সমান বিপজ্জনক তা প্রমাণ করেছে।

Source code review-এ SSRF detect করতে কিছু pattern খুঁজতে হয়। যেকোনো HTTP client library-র call (Python requests, Node.js axios/fetch, Java HttpURLConnection, PHP curl) যেখানে URL component user-controlled, সেখানে সতর্ক হতে হয়। urllib.request.urlopen(user_url), axios.get(req.body.url), file_get_contents($_GET['url']) — এসব classic SSRF sink।

Indirect SSRF-এ user input directly URL নয়, কিন্তু URL construction-এ influence করে — যেমন subdomain, path বা query parameter control। SSRF-aware SAST tool (Semgrep, CodeQL, Checkmarx) এই pattern detect করতে পারে কিন্তু false positive rate বেশি। DAST এবং IAST tool runtime behavior observe করে accurate detection দেয়। Manual penetration testing এখনও SSRF discovery-তে সবচেয়ে effective।

SSRF প্রতিরোধে multiple layer defense প্রয়োজন। Application layer-এ strict allowlist-based validation implement করতে হবে — শুধু specific domain বা URL pattern allow করতে হবে। Blacklist approach almost সবসময় bypass হয়। URL parsing-এ standard library ব্যবহার করতে হবে এবং hostname resolution-এর পর IP validation করতে হবে — internal IP range, loopback এবং metadata IP block করতে হবে।

DNS pinning implement করতে হবে যাতে DNS rebinding attack প্রতিরোধ হয়। Redirect-following disable করতে হবে অথবা প্রতিটি redirect-এ destination validate করতে হবে। HTTP client library-তে timeout এবং response size limit set করতে হবে যাতে resource exhaustion এড়ানো যায়।

Network layer-এ application server থেকে metadata service-এ access block করতে হবে — iptables বা security group rule দিয়ে 169.254.169.254 এবং internal range-এ outbound traffic restrict করতে হবে। AWS-এ IMDSv2 enforce করা mandatory। Cloud-native solution যেমন AWS PrivateLink, VPC endpoint এবং internal-only ALB SSRF impact কমায়।

Architecture-level mitigation-এ separate egress proxy থাকা উচিত যা সমস্ত outbound request-এ central enforcement করে। Network segmentation-এ application server এবং sensitive internal service আলাদা subnet-এ রাখতে হবে। Logging এবং monitoring critical — anomalous outbound request pattern detect করতে SIEM rule থাকতে হবে।