TL; DR
အစုအဝေးတစ်ခု npm package ငါးခုအကောင့်လက်ကိုင်နှစ်ခုတွင် ထုတ်ဝေခဲ့ပြီး ပေးပို့ခဲ့သည် postinstall host မှ cloud credentials များကို ဖတ်ရှုပြီး off-box မှ ပို့ဆောင်ပေးသော hook။ package များတွင် ghost-and-pirate အမည်များ ပါရှိသည် — coral-wraith, ecto-corsair-whisper-6f3b9, ecto-corsair-flag-x9m4, ecto-rust-read-f3a9c1, ecto-nightly-spirit — ပြီးတော့ သူတို့စုဆောင်းထားတဲ့ အရာအားလုံးကို အတုအယောင်အဖြစ် စီစစ်ပါ ecto_module: YAML ကို မပို့မီ manifest လုပ်ပါတယ်။ cluster ကို အောက်ပါအတိုင်း ခြေရာခံပါတယ် အတ္ထုပ္ပတ္တိ.
payload သည် သတ်မှတ်ထားသော ပတ်ဝန်းကျင်တစ်ခုဖြစ်သည့် host ၏ အမည်ကို သိရှိသည့်အခါတွင်သာ အလုပ်လုပ်ပါသည်။ ၁၂-လုံးပါ hex စာကြောင်း နှင့် အောက်တွင် အလုပ်လုပ်သော directory တစ်ခု /app/node_modules — ကွန်တိန်နာထဲထည့်ထားတဲ့ တည်ဆောက်ပုံ ဒါမှမဟုတ် CI အလုပ်သမားရဲ့ပုံသဏ္ဌာန်။ အဲဒီဂိတ်ကို ဖြတ်သွားတဲ့အခါ ချိတ်က မေးခွန်းထုတ်ပါတယ်။ AWS instance metadata ဝန်ဆောင်မှု (IMDSv2) IAM role credentials အတွက်၊ စာရင်းပြုစုသည် AWS လျှို့ဝှက်မန်နေဂျာ ဒေသသုံးခုတွင်၊ ပတ်ဝန်းကျင် variable များကို စွန့်ပစ်ပြီး အောက်ပါဖိုင်များကို ဖတ်ရှုသည် /appနှင့် capture-the-flag string များအတွက် ခြစ်ရာများ။ ထို့နောက် ၎င်းသည် ရလဒ်ကို နည်းလမ်းနှစ်မျိုးဖြင့် ထုတ်ယူသည်- beacon တစ်ခုသို့ webhook.site collector နှင့် manifest တစ်ခုကို localhost-first fallbacks စာရင်းပါရှိသော raw-IP endpoint သို့ PUT လုပ်ပါ။
နောက်ပိုင်း package ဖော်ပြချက်များတွင် "CTF payload for verdaccio supply-chain testing" ဟု ရေးထားသည်။ ကျွန်ုပ်တို့သည် ထိုကိုယ်တိုင်ဖော်ပြချက်ကို လေ့လာနိုင်သောအချက်အလက်တစ်ခုအဖြစ် တင်ပြပါသည်။ အပြုအမူကိုယ်တိုင်က — အများသုံး IP သို့ တိုက်ရိုက်ထွက်ခွာခြင်း၊ တကယ့် IMDS အထောက်အထားဖတ်ရှုခြင်း၊ တကယ့် Secrets Manager မှ ဖုန်းခေါ်ဆိုခြင်း — သည် အညွှန်းမည်သို့ပင်ရှိစေကာမူ ၎င်းဖြစ်ပြီး ဤဗားရှင်းများကို အန္တရာယ်ရှိသော အမျိုးအစားခွဲခြားရသည့် အကြောင်းရင်းဖြစ်သည်။
အစုအဝေးထဲက နာမည်တစ်ခု၊ coral-wraith၊ တစ်ကြိမ်တည်းသော ထုတ်ဝေမှုတွင် ရပ်တန့်မသွားပါ။ နာရီပိုင်းအတွင်း ဗားရှင်းများစွာဖြင့် ဆက်တိုက်ပြန်လည်ထုတ်ဝေခဲ့သည် - 1.0.0 တက်ခြင်း။ 6.0.0 — ပြီးတော့ အရင်နာမည်တူ run တစ်ခုက inflated ကို သုံးခဲ့တယ်။ 9999.0.x ဗားရှင်းနံပါတ်များ၊ ဂန္ထဝင်ပုံသဏ္ဍာန် မှီခိုမှု-ရှုပ်ထွေးမှု ကြိုးပမ်းမှုထိုတစ်လျှောက်တွင် churn သည် payload ကို သိသိသာသာ ရင့်ကျက်လာသည်- one-shot host-enumeration beacon မှ ၎င်း၏ ရည်ရွယ်ထားသော ပစ်မှတ်အပြင်ဘက်တွင် တိတ်ဆိတ်နေစေသည့် environment check များဖြင့် ရစ်ပတ်ထားသော AWS credential pivot အပြည့်အစုံသို့။
| packages | အမည် ၅ ခု; coral-wraith ဗားရှင်းများစွာတွင် ပြန်လည်ထုတ်ဝေခဲ့သည် |
| ဂေဟစနစ် | npm |
| ဗက်တာ ထည့်သွင်းပါ | postinstall သက်တမ်းစက်ဝန်း script |
| အဓိကပစ်မှတ် | AWS IAM အခန်းကဏ္ဍ အထောက်အထားများ + Secrets Manager လျှို့ဝှက်တန်ဖိုးများ၊ ပတ်ဝန်းကျင်ပြောင်းလဲမှုများ၊ /app ဖိုင်တွေ |
| အိတ်စ်ဖီးလ် | webhook.site beacon + raw-IP C2 PUT |
| ခလုတ်တံခါး | ၁၂-hex hostname + /app/node_modules cwd ပါဝင်ပြီး ပတ်ဝန်းကျင်စစ်ဆေးမှုတစ်ခုအပြင် ထိုပတ်ဝန်းကျင်ပြင်ပရှိ payload ကို နှိမ်နင်းပေးသည် |
| ပြင်းထန်မှု | မြင့်သော — cloud အထောက်အထားနှင့် စီမံခန့်ခွဲထားသော လျှို့ဝှက်ထုတ်ဖော်မှုမှ ကွန်တိန်နာထဲ ထည့်သွင်းထားသော တည်ဆောက်မှုနှင့် လည်ပတ်ချိန်ပတ်ဝန်းကျင်များ |
တိုက်ခိုက်မှုခန္ဓာဗေဒ
cluster ထဲက package တိုင်းကို အတူတူပဲ တည်ဆောက်ထားပါတယ်- ဗလာနီးပါးဖြစ်နေတဲ့ package တစ်ခုပါ index.js (module.exports = {}) တစ်ကြောင်းတည်းသော မြတ်စွာဘုရား ဇာတ်ညွှန်း — “postinstall”: “node postinstall.js” — နှင့် ဝန်ထုပ်ဝန်ပိုး postinstall.jspackage ကို install လုပ်ရုံနဲ့ hook ကို run ဖို့ လုံလောက်ပါတယ်။ import လုပ်စရာ ဒါမှမဟုတ် call လုပ်စရာ မလိုပါဘူး။
ပစ်မှတ်တံခါး။ ဘာမှမလုပ်ခင်မှာ ecto-family payload သည် ၎င်းရဲ့ပတ်ဝန်းကျင်ကို စစ်ဆေးပါတယ်။
function isAppWorker(): host = os.hostname() if host does NOT match /^[0-9a-f]{12}$/ -> exit if cwd does NOT contain "/app/node_modules" -> exit if cwd contains "/tmp/npm-safe" -> exit otherwise -> proceed12-hex hostname သည် Docker မှ container တစ်ခုသို့ သတ်မှတ်ပေးသော default shape ဖြစ်ပြီး /အက်ပ်/နိုဒ်_မော်ဂျူးများ သည် ရိုးရာ in-container install path တစ်ခုဖြစ်သည်။ path သည် sandboxed extraction directory နှင့်တူပါက တတိယစာပိုဒ်သည် ကင်းလွတ်ခွင့်ပေးသည်။ အသားတင်အကျိုးသက်ရောက်မှုမှာ payload သည် developer laptop သို့မဟုတ် analysis sandbox တွင် dormant ဖြစ်နေပြီး containerized build သို့မဟုတ် runtime worker အတွင်းရှိသာ activate လုပ်သည် - live cloud credentials များသယ်ဆောင်ရန် အလားအလာအရှိဆုံးပတ်ဝန်းကျင်မျိုးဖြစ်သည်။ cluster တွင် အစောဆုံး package သည် သန္တာကျောက်တန်းနတ်ဆိုးတွင် ထိုကဲ့သို့သော gate မရှိဘဲ ၎င်း၏ (ပိုမိုရိုးရှင်းသော) collection ကို ခြွင်းချက်မရှိ လည်ပတ်သည်။
စုဆောင်းမှုဂိတ်ဖြတ်သွားသောအခါ ချိတ်သည် ဖောက်ထွက်နေသည် execFileSync(“/bin/sh”၊ [“-c”၊ …]) ပြီးတော့ တစ်ခုတည်းသော compound command ကို run ပါတယ်-
1. PUT /latest/api/token to 169.254.169.254 (IMDSv2 token request) 2. GET .../iam/security-credentials/ (IAM role name) 3. GET .../iam/security-credentials/<role> (temporary credentials) 4. dump env | sort (environment variables) 5. list /app (excl. node_modules) + cat first 15 (application files) 6. aws secretsmanager list-secrets (us-east-1, eu-west-1, eu-central-1) 7. scrape readable files for HTB{...} (capture-the-flag strings)အဆင့် ၁ မှ ၃ သည် စာအုပ် IMDSv2 ပြန်လည်ရယူခြင်းဖြစ်သည်- session token တစ်ခုကို တောင်းဆိုပြီးနောက် ၎င်းကို ပူးတွဲပါ X-aws-ec2-metadata-token instance ရဲ့ IAM role နဲ့ အဲဒီ role ရဲ့ temporary access key တွေကို pull လုပ်ဖို့ header ကိုသုံးပါ။ ရိုးရှင်းတဲ့ unauthenticated IMDSv1 အစား IMDSv2 ကို implement လုပ်ဖို့ ရွေးချယ်ခွင့်။ GET မှတ်သားထားသင့်သည် — ၎င်းသည် payload သည် AWS မှ အကြံပြုထားသော hardening ဖြစ်သည့် token-based metadata access လိုအပ်ရန် configure လုပ်ထားသော instance များတွင်ပင် အလုပ်လုပ်သည်ဟု ဆိုလိုသည်။ အဆင့် 3 မှ ပြန်ပေးသော credentials များသည် သက်တမ်းတိုသည်။ AccessKeyId/SecretAccessKey/တိုကင် triples များကို instance ၏ အခန်းကဏ္ဍအထိ ကန့်သတ်ထားသည်။ ထို role က ဘာလုပ်နိုင်ပါစေ၊ ထို key များ၏ ပိုင်ရှင်သည် credential ၏ တစ်သက်တာလုံး လုပ်ဆောင်နိုင်သည်။
အဆင့် ၄ မှ ၆ အထိသည် ချဉ်းကပ်မှုကို ကျယ်ပြန့်စေသည်။ ပို့ပါ။ dump သည် build သို့မဟုတ် runtime လုပ်ငန်းစဉ်မှ အမွေဆက်ခံထားသော မည်သည့်အရာကိုမဆို ဖမ်းယူသည် - လက်တွေ့တွင် ဤနေရာသည် registry tokens၊ database connection strings နှင့် API keys များ အများဆုံးတည်ရှိသည့်နေရာဖြစ်သည်။ / app ကို file walk သည် အပြင်ဘက်ရှိ application ဖိုင် ၁၅ ခုအထိ ဖတ်ရှုသည် node_modules၊ မျက်နှာပြင်ဖွဲ့စည်းပုံကို ပြသနိုင်သည်၊ .env ဖိုင်များ သို့မဟုတ် ရင်းမြစ်။ အဆင့် ၆ ခေါ်ဆိုမှုများ aws secretsmanager စာရင်း-လျှို့ဝှက်ချက်များ ဒေသသုံးခုတွင်၊ အဆင့် ၁ မှ ၃ အထိ ဆွဲထုတ်ထားသော အထောက်အထားများသည် ထိုခေါ်ဆိုမှုများကို စစ်မှန်ကြောင်းအထောက်အထားပြသည့်အရာများဖြစ်သောကြောင့် IMDS သည် ဖတ်ရှုပြီး Secrets Manager enumeration chain ကို တစ်ခုတည်းသော escalation တစ်ခုအဖြစ် ပေါင်းစပ်ထားသည်- instance role → managed-secret inventory။ အဆင့် ၇ သည် capture-the-flag framing ကို ညွှန်ပြသည် — အခါ HTB{…} အလံကို တွေ့ရှိပါက ၎င်း၏ သီးသန့်ပေးပို့သည်၊ မဟုတ်ပါက စုဆောင်းထားသော ကုန်ကြမ်းအစက်အပြောက်ကို အပိုင်းလေးပိုင်း ပိုင်းပြီး ပေးပို့သည်။
cluster ရှိ နောက်ပိုင်းဗားရှင်းများသည် escalation ကို ပိုမိုသယ်ဆောင်သည်။ inventory တွင် ရပ်တန့်မည့်အစား ၎င်းတို့သည် IMDS response ကို parse လုပ်ကာ temporary keys များကို အောက်ပါအတိုင်း export လုပ်သည် AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN ပတ်ဝန်းကျင်ပြောင်းလဲမှုများ၊ အထောက်အထားကို အတည်ပြုပါ aws sts ခေါ်ဆိုသူ အထောက်အထား ရယူပါ, ထို့နောက် ပြန်ပေးသော လျှို့ဝှက်ချက်တိုင်းကို ထပ်ခါတလဲလဲ လုပ်ဆောင်ပါ စာရင်းလျှို့ဝှက်ချက်များ တောင်းဆို aws secretsmanager လျှို့ဝှက်တန်ဖိုးရယူပါ တစ်ခုချင်းစီတွင် — ၎င်းတို့၏အမည်များကိုသာမက လျှို့ဝှက်အကြောင်းအရာများကို ပြန်လည်ရယူသည်။ တူညီသောဗားရှင်းများတွင် process-substituted flag binaries များကိုလည်း ဖတ်ရှုသည် (/ဖတ်အလံ နှင့် သူငယ်ချင်းများ) ကြိုးစားပါ ကုန်တင်ပြေး အောက်တွင်တွေ့ရှိရသော မည်သည့် Rust ပရောဂျက်ကိုမဆို ဆန့်ကျင်သည် / app ကိုcloud အထောက်အထားများထက်ကျော်လွန်၍ ထုတ်လုပ်မှုပမာဏကို တည်ဆောက်မှုပတ်ဝန်းကျင်က ဖော်ထုတ်သည့် မည်သည့်အရာသို့မဆို ချဲ့ထွင်ခြင်း။
ဤနောက်ပိုင်းဗားရှင်းများသည် ၎င်းတို့ကိုယ်တိုင် ပိုမိုရန်လိုစွာ တံခါးဖွင့်ကြသည်။ 12-hex-hostname အပြင် /အက်ပ်/နိုဒ်_မော်ဂျူးများ စစ်ဆေးမှုများပြုလုပ်သောအခါ၊ payload သည် active package-registry configuration နှင့် working-directory path ကို စစ်ဆေးပြီး ၎င်းတို့သည် live target မဟုတ်ဘဲ analysis သို့မဟုတ် mirror context ကို ညွှန်ပြသောအခါ တိတ်ဆိတ်စွာ ထွက်သွားသည်။ ပေါင်းစပ်အကျိုးသက်ရောက်မှုမှာ payload တစ်ခုဖြစ်ပြီး စစ်ဆေးရေးပတ်ဝန်းကျင်အများစုတွင် မြင်သာထင်သာမရှိပဲ ၎င်း၏ full collection ကို run ပြီး စစ်မှန်သော containerized host ပေါ်တွင်ရှိသည်ဟု ဆုံးဖြတ်သည့်နေရာတွင်သာ လုပ်ဆောင်သည်။
Exfiltration။ စုဆောင်းထားသောဒေတာသည် host ကို channel နှစ်ခုတွင်ထားခဲ့သည်။ ပထမ၊ beacon တစ်ခု POST တည်မြဲရာသို့ webhook.site collector တွင် hostname၊ numeric UID၊ working directory နှင့် စုဆောင်းထားသောဒေတာ 120 KB အထိ ပါဝင်သည်။ ဒုတိယအချက်အနေဖြင့် ဒေတာကို အတုအယောင် YAML “module manifest” ထဲသို့ ခေါက်ထည့်ပြီး ထား သို့ /api/မော်ဂျူးများ/ ပစ်မှတ်ဆာဗာပေါ်တွင်-
ecto_module: name: "<flag-or-chunk-0>" version: "1.0.0" power_level: "<chunk-1>" ship_deck: "<chunk-2>" cargo_hold: "<chunk-3>"မန်နီးဖက်စ် လယ်ကွင်းအမည်များ (ပါဝါ_အဆင့်, သင်္ဘောကုန်းပတ်, ကုန်တင်/တင်ဆောင်ရန်) များသည် အလှဆင်ပစ္စည်းများဖြစ်သည် — ခိုးယူခံရသောဒေတာသည် string တန်ဖိုးများအတွင်း၌ စီးဆင်းနေသည်၊ ထို့ကြောင့် ကွန်ရက်မော်နီတာသည် ထင်ရှားသောဒေတာ dump ထက် အန္တရာယ်ကင်းသော package-registry manifest upload တစ်ခုကဲ့သို့ ထင်ရသောအရာကို မြင်ရသည်။ beacon channel သည် ပိုမိုသယ်ဆောင်သည်- POST ကိုယ် webhook.site hostname၊ ဂဏန်း UID၊ အလုပ်လုပ်သော directory နှင့် စုဆောင်းထားသော blob ၏ 120 KB အထိ ပါဝင်သောကြောင့် အောင်မြင်သော beacon တစ်ခုတည်းပင် အပြည့်အဝ ရယူနိုင်မည်ဖြစ်သည်။ webhook.site သည် အခမဲ့ တောင်းဆိုမှု စစ်ဆေးရေး ဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ ၎င်းကို စုဆောင်းသူအဖြစ် အသုံးပြုခြင်းဖြင့် အော်ပရေတာသည် ထိုချန်နယ်အတွက် ၎င်းတို့၏ကိုယ်ပိုင် အခြေခံအဆောက်အအုံကို လက်ခံရရှိရန် ဘယ်တော့မှ မလိုအပ်ဘဲ မှတ်တမ်းတင်ထားသော တောင်းဆိုမှုများသည် ဝန်ဆောင်မှု၏ ပုံးထဲတွင် ရှိနေမည်ဖြစ်သည်။
ထင်ရှားသောအချက် ထား အများအပြားနဲ့ စတင်တဲ့ fallback list တစ်ခုကို လျှောက်သွားပါတယ် 127.0.0.1/localhost port များပြီးနောက် `ရှိ အများပြည်သူသုံး လိပ်စာသုံးခုသို့ ကျဆင်းသွားသည်၁၅၄.၅၇.၁၆၄.၀/၂၄` range ကို 2xx status ဖြင့် အဖြေပေးသည့် ပထမဆုံး endpoint တွင် ရပ်တန့်စေသည်။ localhost-first ordering သည် “verdaccio testing” self-description (loopback ရှိ local registry တစ်ခု) နှင့် ကိုက်ညီသော်လည်း public-IP fallbacks များသည် loopback သည် နားမထောင်သည့်အခါတိုင်း data သည် host မှ ထွက်ခွာသွားသည်ဟု ဆိုလိုသည် - ဆိုလိုသည်မှာ စာရေးသူ၏ကိုယ်ပိုင် test rig မဟုတ်သော မည်သည့်စက်တွင်မဆို ဖြစ်သည်။
timeline ကို
cluster သည် တစ်ကြိမ်တည်းကျဆင်းခြင်းထက် တဖြည်းဖြည်းချင်း စွမ်းရည်တိုးတက်မှုကို ပြသထားသည်။ ကျွန်ုပ်တို့သည် ၎င်းကို နံရံကပ်နာရီထုတ်ဝေခြင်းဖြင့် မဟုတ်ဘဲ လေ့လာတွေ့ရှိထားသော အပြုအမူဖြင့် စီစဉ်ပါသည်။
cluster ရဲ့ အဓိပ္ပါယ်ဖွင့်ဆိုချက်ကတော့ ၎င်းရဲ့ ထုတ်ဝေမှု cadence ပါပဲ- package တစ်ခုတည်းနဲ့ version တစ်ခုတည်းအစား၊ နာမည်တူကို မြန်မြန်ဆန်ဆန်နဲ့ ထပ်ခါထပ်ခါ ပြန်ထုတ်ဝေပါတယ်၊ တစ်ခုချင်းစီဟာ နောက်ဆုံး version မှာ ကွဲပြားတဲ့ ကွဲပြားမှုလေးတွေနဲ့ payload တူတူကို သယ်ဆောင်ထားတဲ့ မောင်နှမအနည်းငယ်နဲ့အတူ ထုတ်လွှတ်ပါတယ်။ တီးတိုးစကားပွော မိသားစုကုဒ်သည် နီးကပ်သော လက်ဗွေရာနှစ်ခုအဖြစ် ကွဲသွားသည် - တစ်စုံသည် အရေးကြီးသော ထောက်လှမ်းမှုနှစ်ခုကို tripping လုပ်သည်၊ နောက်ထပ်သုံးခု (ဖိုင်ဖတ်သည့် sink တစ်ခု) - သို့သော် နှစ်ခုစလုံးသည် payload တစ်ခုတည်းသို့ ဆုံးဖြတ်သည်။ ကွာခြားချက်မှာ ကုဒ် drift ဖြစ်ပြီး behavioral fork မဟုတ်ပါ။ ဗားရှင်းများ တီးတိုးစကားပွော ခွဲခြမ်းစိတ်ဖြာထားသော အတိုင်းအတာထက် ကျော်လွန်၍ (ရေးသားချိန်တွင် အနည်းဆုံး 1.0.25 အထိ) မှတ်ပုံတင်ခြင်းတွင် တိုက်ရိုက်တွေ့ရှိရပြီး၊ သန္တာကျောက်တန်းနတ်ဆိုး နာမည်ဟာ တူညီတဲ့ ဝင်းဒိုးကို ကျော်ဖြတ်ပြီး သူ့ရဲ့ကိုယ်ပိုင်ဗားရှင်း လှေကားကို ဆက်လက်တက်နေပါတယ်။
ညှိနှိုင်းမှု၏ ညွှန်ပြချက်များ
အောက်ဖော်ပြပါ အညွှန်းကိန်းအားလုံးကို ဒစ်ခ်ပေါ်ရှိ ပက်ကေ့ဂျ်ရင်းမြစ်မှ ထုတ်ယူထားပါသည်။ ကွန်ရက်အညွှန်းကိန်းများကို ဖယ်ရှားလိုက်ပါပြီ။
Network
အပြုအမူ/ဖိုင်
ဖိုင် hash များ (sha256၊ ခွဲခြမ်းစိတ်ဖြာချိန်တွင် မှတ်တမ်းတင်ထားသည်)
အထောက်အထားနှင့် လေ့လာတွေ့ရှိထားသော အပြုအမူ
package name ငါးခုကို npm account handles နှစ်ခုအောက်မှာ ထုတ်ဝေခဲ့ပေမယ့် cluster တစ်ခုတည်းအဖြစ် ဆက်ဆံဖို့ infrastructure လုံလောက်စွာ မျှဝေထားပါတယ်။ ecto_module ထင်ရှားသော ပုံစံ၊ အတူတူပင် ECT-၄၇၂၈၃၉ အဓိက နစ်မြုပ်အမှတ်အသား၊ အတူတူပါပဲ webhook.site collector ID နှင့် C2 endpoint များကို တစ်ခုတည်းတွင် ထားရှိသည် ၁၅၄.၅၇.၁၆၄.၀/၂၄` ဘလောက်။ အစေ့ထုပ် (`coral-wraith, ရိုးရှင်းပြီး ungated) နှင့် gated ecto-family သည် ထို့ကြောင့် သီးခြားကြိုးပမ်းအားထုတ်မှုများထက် ကိရိယာတန်ဆာပလာတစ်ခုတည်းပေါ်တွင် ထပ်ခါတလဲလဲလုပ်ဆောင်ခြင်းအဖြစ် ဖတ်ရှုရသည်။
ပက်ကေ့ဂျ်များက နောက်ပိုင်းဗားရှင်းများတွင် ၎င်းတို့ကိုယ်တိုင် အောက်ပါအတိုင်း ဖော်ပြကြသည်- “verdaccio ထောက်ပံ့ရေးကွင်းဆက်စမ်းသပ်မှုအတွက် CTF payload။” ကျွန်ုပ်တို့သည် ထိုတံဆိပ်ကို မြင်သာသောအချက်အလက်တစ်ခုအဖြစ် ဖော်ပြပြီး ရည်ရွယ်ချက်နှင့်ပတ်သက်သော တွေ့ရှိချက်တစ်ခုအဖြစ် ပြန်လည်ဖော်ပြခြင်းမပြုပါ။ ကုဒ်၏လုပ်ဆောင်ချက်သည် ရှင်းလင်းပြတ်သားပြီး ၎င်းကို မည်သို့တံဆိပ်ကပ်ထားသည်နှင့် မသက်ဆိုင်ပါ- ၎င်းသည် instance metadata service မှ IAM role credentials များကို ဖတ်ရှုပြီး၊ AWS ဒေသသုံးခုတွင် managed secrets များကို စာရင်းပြုစုကာ ရလဒ်များကို public IP နှင့် third-party webhook collector သို့ ပေးပို့သည်။ အမှန်တကယ် loopback-only test harness သည် public-IP fallback list၊ IMDS credential reads သို့မဟုတ် cross-region Secrets Manager calls များ မလိုအပ်ပါ။ egress နှင့် credential reach များသည် အစစ်အမှန်ဖြစ်သောကြောင့် gated versions များကို အန္တရာယ်ရှိသော အမျိုးအစားခွဲခြားထားသည်။
container-only gate သည် လုပ်ငန်းလည်ပတ်မှုအရ အထင်ရှားဆုံးသော လက္ခဏာဖြစ်သည်။ ၎င်းသည် laptop များနှင့် analysis sandbox များတွင် တိတ်ဆိတ်နေခြင်း — evasion measure တစ်ခုဖြစ်ပြီး အစစ်အမှန် IAM role နှင့် live secrets များ အရှိဆုံးရှိနိုင်သည့်နေရာတွင်သာ firing targeting measure တစ်ခုလည်းဖြစ်သည်။ generic sandbox တွင် ဤ package များကို run နေသော analyst များသည် မည်သည့်အရာကိုမျှ မတွေ့ရှိရပါ။ ထိုအပြုအမူသည် Docker-style hostname နှင့် in-container install path အောက်တွင်သာ ပေါ်လွင်သည်။
ကာကွယ်သူများအတွက် သက်ရောက်မှု၊ လမ်းကြောင်းများနှင့် လမ်းညွှန်ချက်များ
ဤနေရာတွင် ထုတ်ဖော်ချက်မှာ cloud-credential နှင့် build နှင့် runtime containers များအတွင်းရှိ secret disclosure ဖြစ်သည်။ IMDS မှ ရယူထားသော IAM role credential တွင် ထို role တွင်ရှိသော permission များ ပါဝင်သည်။ secretsmanager: စာရင်းလျှို့ဝှက်ချက်များ (နှင့် နောက်ဆက်တွဲတစ်စုံတစ်ရာ လျှို့ဝှက်တန်ဖိုး ရယူပါ) သည် ၎င်းကို သိမ်းဆည်းထားသော application လျှို့ဝှက်ချက်များအထိ ကျယ်ပြန့်စေသည်။ Environment-variable dumps များတွင် registry tokens၊ database URLs နှင့် API keys များကို မကြာခဏ သယ်ဆောင်လေ့ရှိသည်။ CI သို့မဟုတ် container context တွင် — gate မှ ရွေးချယ်သည့်အရာ — ဤ package များထဲမှ တစ်ခုကို transitive install တစ်ခုတည်းဖြင့် ထို material ကို ပေါက်ကြားစေရန် လုံလောက်ပါသည်။
Ectoplasm သည် ကျွန်ုပ်တို့ဆက်လက်မြင်တွေ့နေရသော ပုံစံနှင့်ကိုက်ညီသည်- install-time payloads များသည် local files များထက် cloud metadata နှင့် managed secrets များအတွက်ရောက်ရှိပြီး high value environments များတွင်သာ ပစ်ခတ်ရန် ၎င်းတို့ကိုယ်တိုင်တံခါးဖွင့်ထားသည်။ ကာကွယ်ရေးဆိုင်ရာ လေ့လာတွေ့ရှိချက်နှစ်ခုကို နောက်ဆက်တွဲဖော်ပြထားသည်။
- ပုံသဏ္ဍာန်ကို ထင်ရှားစွာ တွေ့မြင်နိုင်သည်cloud secrets API နှစ်ခုစလုံးသို့ ရောက်ရှိသော call graph တစ်ခုဖြစ်သည့် npm/PyPI install hook တစ်ခု (aws လျှို့ဝှက်မန်နေဂျာ, gcloud လျှို့ဝှက်ချက်များ, az keyvault) သို့မဟုတ် IMDS လိပ်စာနှင့် ကွန်ရက်ထွက်ခွာသည့် ဆင်းခ်သည် ကျဉ်းမြောင်းပြီး အချက်ပြမှုမြင့်မားသော ပုံစံတစ်ခုဖြစ်သည် - ၎င်းသည် တရားဝင် lifecycle script တွင် မကြာခဏ မဖြစ်ပေါ်ပါ။ တည်ငြိမ်စီးဆင်းမှု ခွဲခြမ်းစိတ်ဖြာခြင်း မည်သည့် domain သို့မဟုတ် IP ကိုမျှ မှီခိုစရာမလိုဘဲ flag လုပ်နိုင်သည်။
- ပတ်ဝန်းကျင် တင်းမာခြင်းက ၎င်းကို ပျော့ပျောင်းစေသည်။ IMDSv2 ကို hop limit ၁ ဖြင့် ပြဋ္ဌာန်းခြင်းသည် container workloads များသည် instance metadata သို့ မရောက်ရှိစေရန် တားဆီးပေးပြီး၊ IAM role များကို အနည်းဆုံး privilege အထိ scope လုပ်ခြင်းသည် leak လုပ်သည့် credential ၏ blast radius ကို ကန့်သတ်ပေးပြီး၊ install များကို လုပ်ဆောင်ခြင်း –လျစ်လျူရှု-scripts CI မှာ install-hook vector ကို မလိုအပ်တဲ့ package တွေအတွက် လုံးဝဖယ်ရှားပါတယ်။
ကာကွယ်သူများအတွက် လက်တွေ့စစ်ဆေးမှုများမှာ- build/CI ကွန်တိန်နာများမှ ခွင့်ပြုမထားသော အများသုံး IP များသို့ ထွက်သွားသော ချိတ်ဆက်မှုများအပေါ် သတိပေးချက် npm installpackage lifecycle scripts များမှ ဆင်းသက်လာသော IMDS access ကို စောင့်ကြည့်ပါ။ cloud CLI သို့ ပေးပို့သော install hook များကို သက်သေမပြနိုင်မချင်း သံသယရှိဖွယ်အဖြစ် သတ်မှတ်ပါ။
ဤ cluster နှင့် သက်ဆိုင်သော နောက်ထပ်မှတ်စုနှစ်ခု။ ပထမအချက်အနေဖြင့်၊ activation ကို containerized environments များအတွက်သာ ကန့်သတ်ထားသောကြောင့်၊ workstation တွင် စိစစ်သောအခါ inert ဟုထင်ရသော package သည် production တွင် live ဖြစ်နိုင်သေးသည် — စိစစ်ခြင်းသည် container hostname နှင့် path conditions များကို ပြန်လည်ထုတ်လုပ်ရန် သို့မဟုတ် "ကျွန်တော် install လုပ်ပြီးသား ဘာမှမဖြစ်ပါဘူး" ဟူသော ဝေါဟာရကို အားကိုးမည့်အစား source ကို တိုက်ရိုက်ဖတ်ရှုရန် လိုအပ်ပါသည်။ ဒုတိယအချက်အနေဖြင့်၊ beacon collector အဖြစ် public request-inspection service ကို အသုံးပြုခြင်းသည် exfiltrated data အချို့ကို incident response အတွက် ပြန်လည်ရယူနိုင်သည်ဟု ဆိုလိုသည်- ဤ package များထဲမှ တစ်ခုကို ၎င်း၏ dependency tree တွင် တွေ့ရှိသော အဖွဲ့အစည်းတစ်ခုသည် အောင်မြင်သော beacon တွင် payload ၏ collection logic မှ မည်သည့်အရာများ ပါဝင်မည်ကို ကျိုးကြောင်းဆင်ခြင်နိုင်ပြီး၊ သက်ရောက်မှုရှိသော build သို့မဟုတ် runtime environment မှ ရရှိနိုင်သော မည်သည့် IAM role credentials၊ registry tokens နှင့် managed secrets များကို လှည့်ပတ်သင့်သည်။ အထောက်အထားလှည့်ပတ်မှုpackage ဖယ်ရှားခြင်းမဟုတ်ဘဲ၊ ထည့်သွင်းမှုတစ်ခု လုပ်ဆောင်ပြီးသည်နှင့် လက်တွေ့ပြုပြင်မှုဖြစ်သည်။
