Dependency Confusion: থার্ড-পার্টি লাইব্রেরির নাম ব্যবহার করে কর্পোরেট সিস্টেমে অনুপ্রবেশ!

আধুনিক সফটওয়্যার ডেভেলপমেন্ট third-party library-এর ওপর প্রবলভাবে নির্ভরশীল। JavaScript ecosystem-এ npm registry, Python-এ PyPI, Ruby-তে RubyGems, Java-তে Maven Central, .NET-এ NuGet— এই public registry-গুলো লক্ষ লক্ষ open source package হোস্ট করে। কিন্তু প্রতিষ্ঠানগুলো শুধু public package-ই ব্যবহার করে না; তারা নিজস্ব internal package-ও তৈরি করে— common utility, internal SDK, business logic library— যেগুলো private registry-তে hosted থাকে অথবা সরাসরি local filesystem থেকে install হয়।

Dependency Confusion-এর মূল ধারণা হলো— যখন একটি package manager কোনো package খোঁজে, তখন সে public এবং private উভয় registry-তে search করতে পারে। যদি একই নামের package দুই জায়গায় পাওয়া যায়, তাহলে অধিকাংশ package manager— default আচরণে— সর্বোচ্চ version-এর package ব্যবহার করে, সেটা public বা private যেখানেই থাকুক না কেন।

আক্রমণকারীরা এই আচরণের সুযোগ নেন। তারা কোনো প্রতিষ্ঠানের internal package-এর নাম জোগাড় করেন (যা প্রায়ই accidentally leaked থাকে— GitHub public repo-তে, blog post-এ, এমনকি job posting-এ)। তারপর সেই একই নামে public registry-তে একটি package upload করেন, কিন্তু অনেক উচ্চ version number দিয়ে— যেমন 99.99.99। যখন প্রতিষ্ঠানের build system package install করে, তখন সে public registry থেকে আক্রমণকারীর malicious package নিয়ে আসে, এবং সেই package-এর install script execute হয়— প্রতিষ্ঠানের internal build server-এ।

Birsan-এর gimmick এত পরিশীলিত ছিল যে তিনি কোনো প্রকৃত backdoor রাখেননি; শুধু DNS request পাঠাতেন আক্রান্ত system থেকে, যা প্রমাণ করত আক্রমণ সফল হয়েছে। এই proof-of-concept-এর জন্য তিনি অনেক bug bounty পেয়েছিলেন।

Dependency Confusion-এর কার্যপদ্ধতি বিভিন্ন package manager-এ কিছুটা ভিন্ন। npm-এ default আচরণ হলো— package.json-এ listed package খোঁজার সময় npm registry-তে যায়। যদি প্রতিষ্ঠান একটি private registry কনফিগার করে রাখে .npmrc-এ, তবু default npm public registry থেকে fallback নিতে পারে যদি scope সঠিকভাবে কনফিগার করা না থাকে।

Scoped package— @company/package-name— এ scope-এর জন্য পৃথক registry কনফিগার করা যায়। কিন্তু unscoped private package-এর ক্ষেত্রে সাধারণত এই সুরক্ষা থাকে না। যদি কোনো প্রতিষ্ঠানের internal package-এর নাম হয় internal-logger, এবং সেটি scope ছাড়া ব্যবহৃত হয়, তাহলে npm public registry-তে এই নামে package দেখলে এবং তার version বেশি হলে সেটা install করবে।

Python-এ pip-এর সমস্যা আরো প্রকট। Default behavior-এ pip multiple index— public PyPI এবং private index— থেকে package খোঁজে এবং সর্বোচ্চ version নেয়। --extra-index-url ব্যবহার করলে এই সমস্যা হতে পারে। --index-url-এর সাথে শুধু একটি index-এর সীমাবদ্ধতা থাকে।

Ruby-তে Bundler default-ভাবে শুধু Gemfile-এ specified source থেকে package নেয়, যা কিছুটা ভালো অবস্থা। কিন্তু multi-source Gemfile-এ এই সুরক্ষা ভেঙে পড়তে পারে।

Maven-এ pom.xml-এ defined repository-গুলোর order অনুযায়ী package search হয়, যা কিছু সুরক্ষা দেয় কিন্তু সম্পূর্ণ নয়।

আক্রমণকারীর dependency confusion-এর জন্য কয়েকটি step অনুসরণ করতে হয়। প্রথমে target প্রতিষ্ঠানের internal package name জোগাড়— GitHub-এ search, leaked package.json file, employee LinkedIn profile-এ technology stack mention, এমনকি বাহ্যিক webpack bundle-এর comment-এ। দ্বিতীয়ত, public registry-তে সেই নামে package upload, উচ্চ version number সহ। তৃতীয়ত, package-এ post-install script যোগ করা যা target environment-এর information বের করে আনে।

Malicious package-এর payload সাধারণ চারটি কাজ করে— environment information collect, command and control server-এর সাথে যোগাযোগ, persistence স্থাপন, এবং lateral movement-এর সুযোগ খোঁজা। কেউ কেউ শুধু DNS exfiltration ব্যবহার করেন (যেমন Birsan-এর demonstration), কেউ কেউ সম্পূর্ণ reverse shell স্থাপন করেন।

Birsan-এর মূল গবেষণায় তিনি Apple-এর appleconnect সহ বিভিন্ন internal package name চিহ্নিত করেছিলেন, যা leaked package.json file-এ পাওয়া গিয়েছিল। তিনি npm-এ এই name-গুলোতে package upload করেন এবং কয়েক ঘণ্টার মধ্যে DNS callback পান— Apple, Microsoft, PayPal এর internal server থেকে। মোট ৩৫টিরও বেশি প্রতিষ্ঠান এই গবেষণায় আক্রান্ত হয়েছিল।

এই revelation-এর পর copycat আক্রমণের ঢল নামে। নিরাপত্তা গবেষক এবং ম্যালিশিয়াস actor— উভয়ই public registry-তে এই ধরনের package upload করতে শুরু করেন। ২০২১ সালের মার্চে npm-এ ৩০০-এর বেশি malicious package চিহ্নিত হয়, যেগুলো dependency confusion-এর জন্য designed ছিল।

WhiteSource-এর গবেষণায় দেখা গেছে, dependency confusion-এর জন্য target হিসেবে Amazon, Lyft, Slack, Zillow সহ Fortune 500 প্রতিষ্ঠানগুলোর internal package নাম-ও public registry-তে upload হয়েছিল।

PyTorch-এর ক্ষেত্রে ২০২২ সালে একটি বাস্তব dependency confusion ঘটনা ঘটে। PyPI-তে torchtriton নামে একটি malicious package upload করা হয়, যা PyTorch nightly build-এর কাছ থেকে actual installation request পায়। আক্রমণটি কয়েক হাজার system-কে প্রভাবিত করেছিল এবং SSH key, .gitconfig এবং অন্যান্য সংবেদনশীল ফাইল exfiltrate করেছিল।

বাংলাদেশের প্রেক্ষাপটে যেসব প্রতিষ্ঠান international payment gateway, ERP, বা banking software develop করে, তাদের ক্ষেত্রে এই হুমকি বিশেষভাবে প্রাসঙ্গিক। ছোট অসতর্কতাও বড় ক্ষতির কারণ হতে পারে।

Dependency Confusion-এর আক্রমণ পৃষ্ঠ বুঝতে হলে modern build pipeline সম্পর্কে কিছু গভীরতা প্রয়োজন। Continuous Integration বা CI pipeline-এ প্রতিটি commit-এ build চলে, যেখানে dependency install হয়। যদি কোনো নতুন dependency add করা হয় বা existing dependency update হয়, তাহলে CI সার্ভার সেটা ফেচ করবে। যদি সেই ফেচ-এ malicious package আসে, তাহলে CI সার্ভারে কোড execute হবে— সাধারণত উচ্চ privilege-এ, যেহেতু CI server-এর কাছে কোড sign করার ক্ষমতা, secret deploy করার ক্ষমতা থাকে।

Lock file— package-lock.json, Pipfile.lock, Gemfile.lock— এই সমস্যাকে কিছুটা mitigate করে। Lock file-এ প্রতিটি package-এর exact version এবং hash রেকর্ড থাকে। নতুন install যদি hash mismatch করে, install ব্যর্থ হয়। কিন্তু সমস্যা হলো, যখন নতুন package add হয় বা existing package upgrade করা হয়, তখন lock file regenerate হয়— এবং সেই moment-এ public registry থেকে malicious package চলে আসতে পারে।

আধুনিক attack-এ আক্রমণকারীরা আরো পরিশীলিত। তারা typosquatting-এর সাথে dependency confusion combine করেন— পরিচিত package-এর সামান্য misspelled নামে upload (যেমন cross-env-এর জন্য crossenv)। তারা legitimate maintainer-এর সাথে impersonation-ও চেষ্টা করেন।

GitHub repository-তে সাধারণ ভুল হলো— internal package name accidentally commit করা। package.json, requirements.txt, এমনকি sample code-এ এই information leak হতে পারে। .gitignore-এ private file include না করা, accidentally পুরো config push— এসব নিয়মিত ঘটে।

Dependency Confusion প্রতিরোধে সবচেয়ে কার্যকর কৌশল হলো Scoped Package এবং Namespace ব্যবহার। npm-এ @yourcompany/package-name format ব্যবহার করুন, এবং @yourcompany scope-এর জন্য আপনার private registry কনফিগার করুন। এমনকি আক্রমণকারী public registry-তে package-name upload করলেও, scope নির্দিষ্ট থাকায় সেটা বিভ্রান্তি তৈরি করতে পারবে না।

দ্বিতীয়ত, Reserve Your Names। আপনার internal package-গুলোর নাম public registry-তেও reserve করে রাখুন— এমনকি যদি সেখানে actual code না থাকে। একটি ফাঁকা placeholder package upload করুন যাতে অন্য কেউ সেই নাম দখল করতে না পারে। npm-এ এই কৌশল "package squatting" নামে পরিচিত, এবং defensive purpose-এ বৈধ।

তৃতীয়ত, Explicit Registry Configuration। .npmrc, pip.conf, bundle config— এই ধরনের configuration file-এ স্পষ্টভাবে নির্দিষ্ট করুন কোন package কোন registry থেকে আসবে। npm-এ always-auth=true এবং specific scope-এর জন্য registry নির্দিষ্ট করুন। pip-এ --index-url ব্যবহার করুন, --extra-index-url এড়িয়ে চলুন।

চতুর্থত, Private Registry Mirror। JFrog Artifactory, Sonatype Nexus, GitHub Packages— এই ধরনের enterprise package manager ব্যবহার করুন যেখানে public registry-ও mirror করা থাকে। সমস্ত package— public বা private— এই central proxy থেকেই আসবে। আপনি control করতে পারবেন কোন public package allowed এবং কোন version।

পঞ্চমত, Hash Pinning এবং Lock File Discipline। Lock file commit করুন version control-এ, এবং production build-এ npm ci বা pip install --require-hashes ব্যবহার করুন যা শুধু lock file-এ specified exact version এবং hash-এর package install করবে। কোনো new dependency add করার সময় careful review করুন।

ষষ্ঠত, Dependency Scanning। Snyk, Socket.dev, npm audit, GitHub Dependabot— এই ধরনের tool dependency-তে known vulnerability এবং suspicious package শনাক্ত করতে পারে। Socket-এর মতো নতুন tool specifically supply chain attack-এর জন্য designed।

সপ্তমত, Build Environment Isolation। CI/CD pipeline-এ build environment ephemeral এবং isolated হওয়া উচিত। প্রতিটি build নতুন container-এ চালাতে হবে, যাতে কোনো compromise persistent না হয়। Network access সীমিত রাখতে হবে— শুধু approved registry-তে access।

অষ্টমত, Secret Hygiene। CI server-এ secret— API key, deployment credential— কে careful protection-এ রাখতে হবে। GitHub Actions-এ secrets context-এর সাথে dependency-এর সরাসরি access থাকা উচিত নয়। OIDC-based authentication, short-lived credential, এবং principle of least privilege— এসব প্রয়োগ করতে হবে।

প্রযুক্তিগত নিয়ন্ত্রণের পাশাপাশি organizational culture-ও গুরুত্বপূর্ণ। Developer awareness training-এ supply chain security অন্তর্ভুক্ত করতে হবে। প্রতিটি developer-কে বুঝতে হবে নতুন dependency add করা মানে শুধু কোড না— পুরো প্রতিষ্ঠানের attack surface বৃদ্ধি।

Dependency review process স্থাপন করতে হবে। নতুন dependency add করার আগে— তার maintainer reputation, recent activity, download statistics, এবং transitive dependency— সব যাচাই করা উচিত। কিছু প্রতিষ্ঠান "dependency approval committee" তৈরি করে যেখানে নতুন library inclusion-এর জন্য approval প্রয়োজন।

Open Source software inventory maintain করুন। Software Bill of Materials বা SBOM— প্রতিটি deployed application-এর সমস্ত dependency-এর comprehensive list— এই inventory-র ভিত্তি। যখন নতুন vulnerability প্রকাশিত হয়, SBOM থেকে দ্রুত শনাক্ত করা যায় কোন application impacted।

Incident response plan-এ supply chain attack-এর scenario অন্তর্ভুক্ত করতে হবে। যদি কোনো compromised package install হয়ে যায়, কীভাবে দ্রুত শনাক্ত করব, কীভাবে rollback করব, কীভাবে blast radius determine করব— এই questions-এর উত্তর আগে থেকেই প্রস্তুত থাকতে হবে।

Software supply chain security একটি দ্রুত developing ক্ষেত্রে পরিণত হয়েছে। SLSA (Supply-chain Levels for Software Artifacts) framework Google-এর initiative, যা সমস্ত artifact-এর provenance এবং integrity নিশ্চিত করার একটি কাঠামোগত পদ্ধতি সরবরাহ করে। In-toto, Sigstore, এবং Cosign— এই ধরনের tool cryptographically signed package এবং reproducible build সম্ভব করছে।

US Executive Order 14028-এর পর federal contractor-দের জন্য SBOM বাধ্যতামূলক হয়েছে। European Union-এর Cyber Resilience Act-এও supply chain security-র কঠোর requirement যোগ হয়েছে। বাণিজ্যিক pressure এবং regulatory pressure— দুটোই এই দিকে ঠেলে দিচ্ছে।

Package registry-গুলো-ও সুরক্ষা বাড়াচ্ছে। npm 2FA বাধ্যতামূলক করেছে maintainer-দের জন্য, PyPI publishing-এর জন্য trusted publisher এবং OIDC প্রবর্তন করেছে। এই প্রক্রিয়া চলতে থাকবে।