ဤသည်မှာ အဖြစ်အများဆုံး ဆော့ဖ်ဝဲလ်ထောက်ပံ့ရေးကွင်းဆက်တိုက်ခိုက်မှုအမျိုးအစားများအကြောင်း ဆောင်းပါးစီးရီး၏ ပထမဆုံးအပိုင်းဖြစ်သည်- ဆော့ဖ်ဝဲလ်အစိတ်အပိုင်းများ၏ အများသုံးမှတ်ပုံတင်ခြင်းကို အသုံးပြုသော ဆော့ဖ်ဝဲလ်အစိတ်အပိုင်းများ open-source ပရောဂျက်များ အခြားအသုံးပြုသူများနှင့် မျှဝေနိုင်သော artifacts များကို upload လုပ်ရန်။ မကောင်းဆိုးဝါးများသည် registry ကို malware ဖြန့်ဖြူးမှုအတွက် ယာဉ်တစ်ခုအဖြစ် အသုံးပြု၍ malicious software ကို ထိုနေရာတွင် ထုတ်ဝေသောအခါ၊ သားကောင်အဖွဲ့အစည်းများသည် ကူးစက်ခံရသော software component ကို install လုပ်ခြင်း သို့မဟုတ် run ခြင်းပြုလုပ်သောအခါတွင် ကျွန်ုပ်တို့တွင် supply chain attack တစ်ခုရှိသည်။
ဆွေးနွေးမှုကို ရိုးရှင်းအောင် ကျွန်တော်တို့ ဆွေးနွေးပါမယ် ဆော့ဖ်ဝဲလ်ပက်ကေ့ဂျ်များ:, ပြင်ပအဖွဲ့အစည်းများမှ ထုတ်လုပ်ထားသော ထုပ်ပိုးပုံစံဖြင့် အစိတ်အပိုင်းများ။ ၎င်းတွင် NPM သို့မဟုတ် Poetry ကဲ့သို့သော package manager များမှ အသုံးပြုသော အစိတ်အပိုင်းများသာမက လည်ပတ်မှုစနစ် အစိတ်အပိုင်းများ libraries တွေနဲ့ executable binaries တွေ အပါအဝင်၊ ကွန်တိန်နာပုံများ၊ နှင့် virtual machine များ၊ သို့မဟုတ် ကိရိယာတိုးချဲ့မှုများ ဖွံ့ဖြိုးတိုးတက်ရေး၊ တည်ဆောက်ရေးနှင့် ဖြန့်ကျက်ရေးကိရိယာများအတွက်။ ကျွန်ုပ်တို့သည် အန္တရာယ်ရှိသော package များကို နေရာတိုင်းတွင် မြင်တွေ့ခဲ့ရသည်။ ဆိုက်ဘာရာဇဝတ်ကောင်များသည် ဂရုမစိုက်ပါ- ၎င်းတို့သည် ခေတ်မီဆော့ဖ်ဝဲလ် အခြေခံအဆောက်အအုံများမှ ပံ့ပိုးပေးသော အခြားရွေးချယ်စရာများကို နှစ်သက်ကြပြီး registry နှင့် ၎င်းတို့၏ ရည်ရွယ်ချက်နှင့် အကိုက်ညီဆုံး tool ကို အသုံးပြုကြသည်။ ထို့ကြောင့် software package များသည် container image များ၊ binary package များ၊ open-source repositories များနှင့် extension များ သို့မဟုတ် plugin အမျိုးအစားအားလုံး (IDE များ) အတွက် အတိုကောက်ဖြစ်ကြောင်း သတိရပါ။ CI/CD စနစ်များ၊ တည်ဆောက်ကိရိယာများ)။ အားလုံးသည် ပုံမှန်တိုက်ခိုက်မှုအောက်တွင် ရှိနေသည်။
ဒီဇာတ်လမ်းတွဲမှာ အပိုင်း ၅ ပိုင်း ပါဝင်မှာဖြစ်ပါတယ်-
- Open Source Package တွေမှာ ဘာပြဿနာရှိလဲ။ ဒါက ဒီပို့စ်ရဲ့ အဓိကအကြောင်းအရာပါ။ ဘာကြောင့် ရာဇဝတ်သားအမျိုးမျိုးက အန္တရာယ်ရှိတဲ့ ပက်ကေ့ဂျ်တွေကို ထုတ်ဝေနေကြတာလဲ။ ကျွန်တော်/ကျွန်မ ဘာလို့ စိုးရိမ်ရမှာလဲ။
- အန္တရာယ်ရှိသော အထုပ်များ၏ ခန္ဓာဗေဒ- ခေတ်ရေစီးကြောင်းများကား အဘယ်နည်း။ ဒီဇာတ်လမ်းတွဲမှာ ကျွန်တော်တို့ရဲ့ MEW စနစ်နဲ့ နေ့စဉ် စောင့်ကြည့်နေတဲ့ ခြိမ်းခြောက်မှုကို အဓိကထားပါတယ်။ typosquatting ဒါမှမဟုတ် dependency confusion ကို အသုံးပြုထားတဲ့ malicious packet အများအပြားကြောင့် နောက်ခံဆူညံသံကြီးတစ်ခုကြောင့် တိုက်ခိုက်မှုရာခိုင်နှုန်းနည်းပါးတာက ပိုပြီး လျှို့ဝှက်ဆန်းကြယ်ပြီး အန္တရာယ်ပိုများပါတယ်။ မကြာသေးခင်က OS နဲ့ ပတ်သက်ပြီး မကောင်းတဲ့ လုပ်ရပ်တွေရဲ့ အပြုအမူက ဘယ်လိုပြောင်းလဲသွားလဲ။ ကိန်းဂဏန်းတွေက ဘာတွေလဲ။ အသုံးပြုခဲ့တဲ့ နည်းဗျူဟာတွေ၊ နည်းပညာတွေနဲ့ လုပ်ထုံးလုပ်နည်းတွေနဲ့ အန္တရာယ်ရှိတဲ့ လုပ်ဆောင်ချက်တွေက ဘာတွေလဲ။
- Open Source Malicious Package များမှ ကာကွယ်ခြင်း- ဘာတွေက (အလုပ်မလုပ်ဘူး) လဲ။လုံခြုံရေးကို သတိထားတဲ့ ပညာရှင်အများစုမှာ ဒီခြိမ်းခြောက်မှုကို ဘယ်လိုကိုင်တွယ်ရမလဲဆိုတဲ့ အကြံဥာဏ်တွေ ရှိပါတယ်။ လုံခြုံရေးမန်နေဂျာတွေက တွန့်ဆုတ်ခြင်းမရှိဘဲ ပြောနေတာကို ကျွန်တော်တို့ ကြားဖူးပါတယ်- SCA tools တွေက package version တစ်ခုဟာ malware ဖြစ်တဲ့အခါ သင့်ကို ပြောပြပြီးသားပါ။ ဒါမှမဟုတ် malware တွေကို ချက်ချင်းရှာဖွေတွေ့ရှိပြီး ဖယ်ရှားနိုင်တဲ့ လူသိများပြီး အဆင့်မြင့်သုံးသပ်ထားတဲ့ software components တွေပေါ်မှာ မှီခိုနေရတယ်လို့ ဆိုပါတယ်။ သူတို့ဟာ vulnerability fix တွေကို အလိုအလျောက်ရရှိဖို့အတွက် open minor/patch version တွေကို အသုံးပြုကြပြီး အဲဒါက “စောစော patch လုပ်ပါ၊ မကြာခဏ patch လုပ်ပါ” ဆိုတဲ့ မူကို လိုက်နာပြီး open source dependencies တွေအပေါ် အန္တရာယ်ကို လျှော့ချဖို့ အကြံပြုထားတဲ့ မှန်ကန်တဲ့နည်းလမ်းပါပဲ။ ဒီအပိုင်းမှာ ဒီအတွေးအခေါ်တွေ ဘာကြောင့်မှားယွင်းနေလဲ၊ ဒီလိုအထင်အမြင်လွဲမှားမှုတွေက ဒီတိုက်ခိုက်မှုယန္တရားရဲ့ ရေပန်းစားမှုကို ဘယ်လိုအထောက်အကူပြုနေလဲ၊ အဖွဲ့အစည်းတွေ ကြုံတွေ့နေရတဲ့ ကြီးမားတဲ့အန္တရာယ်ကို ဘယ်လိုအထောက်အကူပြုနေလဲဆိုတာကို ပြန်လည်သုံးသပ်သွားပါမယ်။ ဘာတွေအလုပ်လုပ်လဲ၊ ဘာတွေပါဝင်ပတ်သက်တဲ့ ကြိုးစားအားထုတ်မှုနဲ့ အရင်းအမြစ်တွေလဲဆိုတာနဲ့ အဆုံးသတ်ပါမယ်။
- ပွင့်လင်းသောရင်းမြစ် အန္တရာယ်ရှိသော အထုပ်များ- Xygeni ချဉ်းကပ်မှုဒီဇာတ်လမ်းတွဲမှာ Xygeni မှာ ကျွန်ုပ်တို့ရဲ့ Malware Early Warning (MEW) စနစ်အတွက် ဘယ်လိုဗျူဟာတွေကို လိုက်နာတယ်ဆိုတာကို တင်ပြထားပါတယ်။ ဒီ multi-stage စနစ်က package ဗားရှင်းအသစ်ထုတ်ဝေတဲ့အခါ real-time မှာ ဘယ်လိုအလုပ်လုပ်သလဲ၊ မတူညီတဲ့ရင်းမြစ်တွေကနေ အထောက်အထားတွေကို ဘယ်လိုရယူသလဲ၊ ဘယ်လို triage လုပ်သလဲ၊ ဘယ်လို classification criteria တွေကို လိုက်နာသလဲ၊ malicious package candidate ရဲ့ သဘောသဘာဝကို အတည်ပြုဖို့ manual analysis အချို့ ဘာကြောင့် လိုအပ်သေးလဲ။ ကျွန်ုပ်တို့ရဲ့ internal နဲ့ registry team တွေဆီက feedback က system ကို စုဆောင်းထားတဲ့ အတိတ်က အထောက်အထားတွေကနေ ဘယ်လိုလေ့လာပြီး false positives တွေကို အနည်းဆုံးဖြစ်အောင် လျှော့ချဖို့ ဘယ်လိုကူညီပေးသလဲ။ ပြီးတော့ open-source open source ecosystem တွေမှာ NPM၊ GitHub၊ PyPI နဲ့ တခြား key infrastructure တွေကို dwell time လျှော့ချဖို့ ဘယ်လိုကူညီပေးနေလဲဆိုတာကို ရှင်းပြပါမယ်။.
- Open Source ကို အသုံးချခြင်း- လူဆိုးများထံမှ မျှော်လင့်ရမည့်အရာများစီးရီးသည် ရန်သူများက တိုက်ခိုက်မှုများကို ပိုမိုခိုးကြောင်ခိုးဝှက်၊ ထောက်လှမ်းရန်ခက်ခဲစေရန်၊ သီးခြားစက်မှုလုပ်ငန်းများကို ပိုမိုပစ်မှတ်ထားကာ ဤတိုက်ခိုက်မှုအမျိုးအစားမှ အကျိုးကျေးဇူးများ ပိုမိုရရှိရန်အတွက် အသစ်ဆုံးလုပ်ဆောင်ချက်များကို အဓိကထား၍ အဆုံးသတ်ထားသည်။ ransomware တိုက်ခိုက်မှုများကို ဤယာဉ်ကို အသုံးပြု၍ ပေးပို့မည်လား။ မကောင်းဆိုးဝါးများသည် AI tools များကို မည်သို့အသုံးချကာ ပိုမိုရှုပ်ထွေးသော malicious package များ ပေးပို့နေသနည်း။ ထိပ်တန်းလူကြိုက်များသော ပရောဂျက်များသည် အန္တရာယ်ကျရောက်နေပါသလား။ ဤသည်မှာ စာဖတ်သူများအား ဤလက်နက်ပြိုင်ဆိုင်မှုအကြောင်းနှင့် ရေတို (၂၀၂၄ ခုနှစ် ဒုတိယနှစ်ဝက်) နှင့် အလယ်အလတ်ကာလ (၂၀၂၅) တွင် မည်သို့မျှော်လင့်ရမည်ကို ခံစားရစေရန်ဖြစ်သည်။ မကြာသေးမီက တိုက်ခိုက်မှုများကဲ့သို့သော တိုက်ခိုက်မှုများကို မည်သို့လေ့လာကြပါမည်။ XZ-Utils Backdoorသို့မဟုတ် မြေပြင်ပေါ်ရှိ သက်ရှိများအပေါ် တိုက်ခိုက်မှု အီလက်ထရွန်တည်ဆောက်သူ ၂၀၂၄ ခုနှစ် မတ်လတွင် ရန်သူများ မည်သို့တိုးတက်ပြောင်းလဲလာသည်ကို ကျွန်ုပ်တို့ သတိထားသင့်ကြောင်း ပြသနေပါသည်။
ပထမအပိုင်းနဲ့ စင်မြင့်ကို စလိုက်ကြရအောင်- အန္တရာယ်ရှိတဲ့ open-source open source package တွေနဲ့ ဘာတွေဖြစ်နေတာလဲ။
Open Source Package တွေမှာ ဘာပြဿနာရှိလဲ။
မကြာသေးမီနှစ်များအတွင်း၊ အမျိုးမျိုးသော ပြစ်မှုကျူးလွန်သူများသည် အန္တရာယ်ရှိသော အပြုအမူများကို ပေးပို့ရန်အတွက် open-source open source software registry များကို အသုံးပြုခဲ့ကြသည်။ ဤလုပ်ဆောင်ချက်များသည် open source ကဲ့သို့ပင် ရှေးကျသော်လည်း ၎င်းတို့၏ကြိမ်နှုန်းသည် လွန်ခဲ့သောသုံးနှစ်အတွင်း မြင့်တက်လာခဲ့သည်။
အန္တရာယ်ရှိသော အစိတ်အပိုင်းများကို အများသုံး မှတ်ပုံတင်စာရင်းထဲသို့ ထုတ်ဝေခြင်း (မှီခိုမှုအခြေပြုတိုက်ခိုက်မှုများ) သည် ခြိမ်းခြောက်မှုပြုလုပ်သူများသည် malware များဖြန့်ဝေရန်အသုံးပြုသည့် asymmetric guerilla warfare ဖြစ်ပြီး၊ အဖွဲ့အစည်းများသည် မသိသော developer များထံမှလာသော open-source components များတွင် ယုံကြည်မှုကို အသုံးချသည် (သတိရပါ) မှီခိုမှု xkcd ရုပ်ပြ?). သင်ဟာ package တွေကို ယုံကြည်ပြီး package content တွေနဲ့ သူတို့ရဲ့ dependencies တွေကို ကိုယ်တိုင် ပြန်လည်သုံးသပ်တာကို ဂရုမစိုက်တဲ့အတွက် ဒီတိုက်ခိုက်မှုတွေဟာ အလွန်ထိရောက်မှုရှိပါတယ်။ ပြီးတော့ asymmetry ဖြစ်ပေါ်လာတာက ၎င်းတို့ကို အများအားဖြင့် အလိုအလျောက်လုပ်ဆောင်နိုင်ပြီး မကောင်းတဲ့လူတွေဟာ သားကောင်နဲ့ တိုက်ရိုက်ထိတွေ့ဆက်ဆံဖို့ မလိုအပ်လို့ပါ။ သူတို့က package ကို public registry ထဲကို upload လုပ်ပြီး လွှတ်လိုက်ရုံပါပဲ။
အန္တရာယ်ရှိသော ပက်ကေ့ဂျ်များ ၂၀၂၂ ခုနှစ်တွင် ၆ ဆ မြင့်တက်လာခဲ့သည်, နှင့် ၂၀၂၃ ခုနှစ်တွင် ၂.၅ ဆ ဆ တိုးလာခဲ့သည်။ ပြီးခဲ့သည့်နှစ်က အန္တရာယ်ရှိသော ပက်ကေ့ဂျ် ၂၄၅,၀၀၀ ကို မြင်တွေ့ခဲ့ရပြီး၊ ယခင်နှစ်များ ပေါင်းစပ်ထားသည်ထက် နှစ်ဆကျော် ပိုများသော ကိန်းဂဏန်းဖြစ်သည်။ ဤသည်မှာ အဆမတန် တိုးတက်မှုပင် ဖြစ်သည်။ ၂၀၂၁ ခုနှစ်တွင် အတည်ပြုထားသော malware အဖြစ် ပက်ကေ့ဂျ် ဖယ်ရှားမှုများမှ ၂၀၂၂ ခုနှစ်တွင် ထောင်ပေါင်းများစွာအထိ ရှိလာခဲ့ပြီး ယခုနှစ်အတွက် အလားတူနှုန်းဖြင့် ၂၀၂၃ ခုနှစ်အတွင်း နောက်ခံ “ဆူညံသံ” များကို ကျွန်ုပ်တို့ မြင်တွေ့ခဲ့ရသည်။ ထို့အပြင် “ခုခံမှု အနည်းဆုံးလမ်းကြောင်း” ကို လိုက်နာသော ရိုးရှင်းသော ဆိုက်ဘာရာဇဝတ်သားများကြောင့် ဖြစ်ပေါ်လာသော ထိုနောက်ခံတွင် ဖုံးကွယ်ထားသော၊ ထင်ရှားသော တိုက်ခိုက်မှု အနည်းငယ်သည် ယေဘုယျမီဒီယာများတွင်ပင် သတင်းခေါင်းစဉ်များအထိ ရောက်ရှိခဲ့သည်။
ဘာကြောင့် ဒါက ဒီလောက်ကြီးမားတဲ့ ပြဿနာတစ်ခု ဖြစ်နေရတာလဲ။ ယုံကြည်မှုလွန်ကဲခြင်း ကွင်းဆက်တစ်ခုလုံးမှာ။ Open-source software ကို ၎င်း၏ source code နှင့်အတူ ဖြန့်ဝေပြီး ပေးထားသောလိုင်စင်အောက်တွင် ထုတ်ပြန်ထားသည်။ ဟုတ်ကဲ့၊ မည်သူမဆို source code ကို စစ်ဆေးနိုင်သည်။ သို့သော်၊ မည်သူက ယေဘုယျအားဖြင့် စစ်ဆေးသနည်း။ software တွင် malware မရှိကြောင်း စစ်ဆေးပြီးနောက် မည်သူက source များမှ software ကို တည်ဆောက်သနည်း။ packaged component (a ဟုလည်း လူသိများသည်) ကို မပေးပို့မီ မည်သူက အထုပ်) package manager ဒါမှမဟုတ် build tool ရဲ့ downstream မှာ package ဟာ malware တွေနဲ့ မပြည့်နှက်နေဘဲ ၎င်းလာသင့်တယ်လို့ ယူဆရတဲ့ source code နဲ့ ကိုက်ညီမှုရှိမရှိ သေချာစေတယ်။
ဘာကြောင့် အခြေခံအဆောက်အအုံက ဒီလောက်လွယ်တဲ့ တိုက်ခိုက်မှုတွေကို ခွင့်ပြုထားတာလဲ။
ပက်ကေ့ဂျ် မှတ်ပုံတင်များ ပွင့်လင်းနေပြီး ထုတ်ဝေသူ၏ အထောက်အထားကို အနည်းဆုံး အတည်ပြုရန် မကြာခဏ လိုအပ်ပါသည်။ “မည်သူမဆို ဤနေရာတွင် ၎င်းတို့၏ ဆော့ဖ်ဝဲကို ထုတ်ဝေရန် ကြိုဆိုပါသည်!” တိုက်ခိုက်သူများအတွက် ကန့်သတ်ချက်ကို နိမ့်ကျအောင် ပြုလုပ်ထားသည်- ၎င်းတို့သည် တစ်ခါသုံး အီးမေးလ်လိပ်စာများနှင့် တစ်ခါသုံး GitHubgithub အကောင့်များကို အသုံးပြု၍ တိုတောင်းသော phishing ကဲ့သို့သော campaign များတွင် အန္တရာယ်ရှိသော package ရာပေါင်းများစွာကို ဖန်တီးကြသည်။ ပစ်မှတ်ထားသူများအတွက်သာ ပိုမိုမြင့်မားသော ခေတ်မီဆန်းပြားမှု လိုအပ်သည်- ကြယ်ပွင့်များစွာပါရှိသော ယုံကြည်စိတ်ချရသော GitHub source repository တစ်ခုကိုပင် ကျွန်ုပ်တို့ ဖန်တီးခဲ့သည်ကို မြင်တွေ့ခဲ့ရသည်။ commitအတုအယောင်ပံ့ပိုးကူညီသူများစွာနှင့် လူကြိုက်များမှုနှင့် ထိန်းသိမ်းမှုဆိုင်ရာ အခြားမက်ထရစ်များထံမှ s များ။ ရယူခြင်း ကြယ်ကြည့်သူများနှင့် အတုအယောင်ပံ့ပိုးမှုများမှ ဂုဏ်သတင်း အလိုအလျောက်လုပ်ဆောင်ရန် မခက်ခဲပါ။ malware များသာမက open software infrastructure အမျိုးမျိုးတွင် အလွဲသုံးစားပြုမှုများကို ကျွန်ုပ်တို့တွေ့မြင်ခဲ့ရသည် လက်ဖက်ရည်ပရိုတိုကောဖြစ်ရပ်.
Package manager များကို လုံခြုံရေးအတွက် မဟုတ်ဘဲ အသုံးပြုရလွယ်ကူစေရန် ဒီဇိုင်းထုတ်ထားသည်။၎င်းတို့သည် install မလုပ်မီနှင့် install လုပ်ပြီးနောက် post-install script များကို လုပ်ဆောင်နိုင်သည် (တစ်ခါတစ်ရံတွင် library အတွက် native code ကို compile လုပ်ရန် လိုအပ်သည်)။ ထို့အပြင်၊ အထုပ်မန်နေဂျာများ ရင်းမြစ်များစွာမှ package များကို ထည့်သွင်းပါ၊ တစ်ခါတစ်ရံတွင် မူရင်းအားဖြင့် public registry များကို အသုံးပြုရန်ဖြစ်သည်။ publish request ရှိ metadata နှင့် package ရှိ metadata အကြား မကိုက်ညီမှုကို ၎င်းတို့ မစစ်ဆေးခဲ့ပါ။
မှီခိုမှုများကို အစုအဝေးဖွဲ့ပြီး ဂရပ်တစ်ခုဖွဲ့စည်းထားသည်။ Node (JavaScript) ကဲ့သို့သော ဂေဟစနစ်အချို့တွင်၊ အသေးစားမှီခိုမှုများသည် ရာပေါင်းများစွာ သို့မဟုတ် ထောင်ပေါင်းများစွာဖြင့် စုပုံလာသည်။ တစ်ခုကတော့ ကျွန်တော့်ရဲ့ ဆော့ဖ်ဝဲလ်ပရောဂျက်တွေက ကြေငြာထားတဲ့ တိုက်ရိုက်မှီခိုမှုတွေကို တင်းကျပ်စွာ ထိန်းချုပ်ဖို့ပါပဲ၊ ဒါပေမယ့် အကူးအပြောင်း မှီခိုမှုများ ထိန်းချုပ်ရန် ပိုခက်ခဲပါသည်။ Open source ကို လိုက်နာပြီး “ငါ့သူငယ်ချင်းတွေရဲ့ သူငယ်ချင်းတွေက ငါ့သူငယ်ချင်းတွေပါပဲ” လို့ ခေါ်ဆိုကြပါတယ်။ ညီအစ်ကိုမောင်နှမတွေဟာ အရှေ့ဖျားဒေသမှာ ပုံမှန်ပါပဲ။ ခြိမ်းခြောက်မှု ကျူးလွန်သူတွေက ဒါကို သိပြီး မသိရတဲ့ ထင်ရှားတဲ့ မှီခိုမှုတွေမှာ အန္တရာယ်ရှိတဲ့ အပြုအမူကို နက်နက်ရှိုင်းရှိုင်း ဖုံးကွယ်ထားပါတယ်။ ဒါဟာ ဖြစ်ရပ်ပါ။ ဖြစ်ရပ်-စီးကြောင်း ဖြစ်ရပ်ကို ပစ်မှတ်ထားခြင်း ကူပွန်ပိုက်ဆံအိတ်.
ဒါက open-source software စတင်တည်ထောင်ချိန်ကတည်းက ဘယ်လိုအလုပ်လုပ်ခဲ့လဲဆိုတာပါ။ အများကြီးပြောင်းလဲမှာမဟုတ်ပါဘူး။ အချို့ package registry တွေဟာ အကောင်းဆုံးအခြေအနေမှာ two-factor authentication ကို တောင်းဆိုလေ့ရှိပြီး မကြာခဏဆိုသလို အလွန်ရေပန်းစားတဲ့ package တွေအတွက်ပဲ တောင်းဆိုလေ့ရှိပါတယ်။ အချို့ registry တွေက စိစစ်ပြီးသား အဖွဲ့အစည်းတစ်ခုပိုင် namespace တစ်ခုဖြစ်တဲ့ scope တွေကို ပေးစွမ်းပေမယ့် ကြေကွဲစရာ အခြားသူများက ၎င်းကို မပံ့ပိုးပါ (PyPI) သို့မဟုတ် ရွေးချယ်နိုင်စေသည် (NPM)။ စိတ်ဝင်စားစရာကောင်းတာက တစ်ခုတောင် ရိုးရှင်းသောစိစစ်ရေးစနစ် (အုပ်စု ID နှင့် ကိုက်ညီသော DNS သို့မဟုတ် GitHub repository/အဖွဲ့အစည်း၏ ထိန်းချုပ်မှုအပေါ် အခြေခံ၍) နှင့် ပြုလုပ်ခြင်း PGP လက်မှတ်များ မဖြစ်မနေ ရေးသွင်းရမည် checksum များမှလွဲ၍ artifacts အားလုံးအတွက် "noise"၊ typosquatting နှင့်ဆင်တူသော malicious package အများစုကို ဖယ်ရှားပေးပြီး အများစုကို ကန့်သတ်ထားသည်။ မှီခိုမှုရှုပ်ထွေးမှု။ ခေတ်မီသောတိုက်ခိုက်မှုများသည် ဖြစ်နိုင်သော်လည်း ပိုမိုခက်ခဲပြီး ඒවෙනුවට အနည်းငယ်သာရှိသည်။ com.github.codingandcoding:maven-compiler-plugin Maven Central အတွက် လူသိများပါတယ်။ maven registry အားလုံးက တူညီတဲ့ အလေ့အကျင့်တွေကို လိုက်နာကြတာ မဟုတ်ပါဘူး။
package manager များပေါ်ရှိ လုံခြုံရေးထိန်းချုပ်မှုများသည် dependency attack များကို ဝန်ထုပ်ဝန်ပိုးဖြစ်စေနိုင်သော်လည်း မတားဆီးနိုင်ပါ။ multi-factor authentication ၏ ပြဿနာမှာ automation အတွက်၊ access tokens သို့မဟုတ် APIapi keys ကဲ့သို့သော derived credentials များကို automation scripts များမှပြုလုပ်သော APIapi calls များတွင် အသုံးပြုရန်အတွက် အကောင့်များအတွက် ထုတ်ပေးထားပြီး၊ backing interactive user မှ second factor မပေးဘဲ ထုတ်ပေးပါသည်။ MFA သည် user account များကို password leak များမှ ကာကွယ်ရန်အတွက် ကောင်းမွန်သော်လည်း၊ generated access tokens သို့မဟုတ် APIapi keys များကို active အနေဖြင့် ကာကွယ်ရန် လိုအပ်ပါသည်၊ သို့မဟုတ်ပါက ၎င်းတို့၏ပိုင်ရှင်ကို ရန်သူများက အယောင်ဆောင်ထားမည်ဖြစ်သည်။ package-based supply chain campaign အများစုသည် leak လုပ်ထားသော key/token ဖြင့် စတင်ပါသည်။ ကဲ့သို့သော အဖြစ်အပျက်များကိုသာ သတိရပါ လယ်ဂျာ, 3CXနှင့် အခြားအရာများစွာတွင်၊ ထောက်ပံ့ရေးကွင်းဆက်တိုက်ခိုက်မှုကို စတင်ရန်အတွက် ကနဦးကျူးကျော်ဝင်ရောက်မှုတွင် အပြန်အလှန်တုံ့ပြန်မှုမရှိသော အထောက်အထားများကို ဦးစွာထုတ်ယူခဲ့သည်။
ဒီခြိမ်းခြောက်မှုအပေါ် တုံ့ပြန်မှုက လုံလောက်အောင် ခိုင်မာမှုမရှိပါဘူး။ တတိယအပိုင်းမှာတော့ ဘာတွေအောင်မြင်ခဲ့လဲ၊ ဘာတွေဆိုးရွားစွာကျရှုံးခဲ့လဲဆိုတာကို အာရုံစိုက်သွားပါမယ်။ ဒီလုပ်ငန်းက ပူးပေါင်းဆောင်ရွက်ဖို့ လိုအပ်ပါတယ်။ standardကမ္ဘာလုံးဆိုင်ရာ ထောက်ပံ့ရေးကွင်းဆက်များအတွက် အန္တရာယ်များကို လျှော့ချရန်အတွက် s၊ လုပ်ငန်းစဉ်များ၊ ပညာရေးနှင့် ကိရိယာများ။ ဤသည်မှာ အဖွဲ့အစည်းတစ်ခုတည်းကသာ ဖြေရှင်းနိုင်သော ပြဿနာမဟုတ်ပါ။
ဒီအပိုင်းကို အဆုံးသတ်ဖို့အတွက်၊ အရေးကြီးတဲ့ အထင်အမြင်လွဲမှားမှု- ကျွန်တော်တို့ ပြောနေတာက အန္တရာယ်ရှိတဲ့ အထုပ်တွေ မဟုတ်ဘူး အားနည်းချက် တစ်ခု။ အားနည်းချက်များသည် မကောင်းတဲ့ရည်ရွယ်ချက်မရှိဘဲ ဒီဇိုင်း သို့မဟုတ် ကုဒ်ရေးသားခြင်းအမှားများမှ ဖြစ်ပေါ်လာသည်။ အားနည်းချက်များကို အသုံးချနိုင်သော်လည်း အများစုမှာ မဟုတ်ပါ။ အန္တရာယ်ရှိသော ပက်ကေ့ဂျ်များသည် အမြဲတမ်း ရည်ရွယ်ချက်ရှိရှိ လုပ်ဆောင်ကြပြီး ၎င်းတို့ကို လုပ်ဆောင်ပါက 100% အသုံးချနိုင်စွမ်း ရှိသည်။ နှိုင်းယှဉ်နိုင်သော အန္တရာယ်မရှိပါ။ ထို့ကြောင့် အားနည်းချက်များကို ထောက်လှမ်းခြင်းနှင့် လျော့ပါးစေရန် မည်မျှကြိုးပမ်းအားထုတ်ထားသည်ကို မြင်ရခြင်းနှင့် အန္တရာယ်ရှိသော အစိတ်အပိုင်းများအတွက် ညီမျှသော အစီအမံများ မရှိခြင်းတို့သည် ဆန့်ကျင်ဘက်ဖြစ်သည်။.
"ကျွန်ုပ်တို့သည် လုံခြုံရေးကို အလေးအနက်ထားပါသည်"
ရိုးရာဓလေ့ကို စိတ်ကူးကြည့်ရအောင် Acme ကော်ပိုရေးရှင်းWileCoyote.com ရဲ့ အဓိကပံ့ပိုးပေးသူဖြစ်တဲ့ Acme ဟာ သူ့ရဲ့ software အများစုကို third party တွေဆီကနေ ရယူထားပြီး ၈၀% ကျော်ဟာ open-source source project တွေကနေ ရရှိပါတယ်။ သူတို့ဟာ internal use အတွက် software တွေကို ထုတ်လုပ်ပေမယ့် သူတို့ရဲ့ partner တွေ၊ provider တွေနဲ့ customer တွေ / end-user တွေအတွက်လည်း software တွေကို ပံ့ပိုးပေးပါတယ်။ Acme မှာ Go, JavaScript, Java, C# နဲ့ Python တို့နဲ့ ရေးသားထားတဲ့ software တွေ ရှိပြီး သူ့ရဲ့ software အများစုကို Kuberneteskubernetes clusters အောက်မှာ cloud ပေါ်မှာ run ပါတယ်။ Acme ဟာ Docker Hub နဲ့ တခြား registry တွေကနေ ရယူထားတဲ့ base image တွေကနေ custom image တွေကို တည်ဆောက်ပါတယ်။ ပြီးတော့ သူတို့ဟာ libraries, packages နဲ့ container image အနည်းငယ်ကိုလည်း public registry တွေမှာ မျှဝေပါတယ်။
Acme က လုံခြုံရေးကို အလေးအနက်ထားပါတယ်။ သူတို့ဟာ ပြဿနာကို အတော်လေး သတိထားမိကြပါတယ်။ open source securityနှင့် ၎င်းကြောင့် ဖြစ်ပေါ်လာသော အန္တရာယ်။ developer အားလုံး၊ system manager များနှင့် DevOps devops engineer များသည် ထိုချစ်စရာကောင်းသော crypto key လေးများကို second-factor authentication အဖြစ် အသုံးပြုကြသည်။ အားလုံး commitကုဒ် repos များသို့ s များကို လက်မှတ်ရေးထိုးထားပြီး၊ မဖြစ်မနေ ကုဒ်ပြန်လည်သုံးသပ်ခြင်းဖြင့် branch protection ကို enable လုပ်ထားသည်။ CI/CD သော့ခတ်ထားပြီး၊ လျှို့ဝှက်ချက်များကို လျှို့ဝှက်သေတ္တာထဲတွင် သိမ်းဆည်းထားပြီး၊ ခွင့်ပြုထားသော၊ white-listed component များကိုသာ သိမ်းဆည်းထားသည့် internal registry တစ်ခုဖြင့် external registry များကို တစ်စိတ်တစ်ပိုင်း mirroring လုပ်ထားသည်။ Acme မှ တည်ဆောက်ထားသော software သည် ဤ registry မှ third-party dependencies များကို ရယူရန် လိုအပ်ပါသည်။
အဖွဲ့အစည်းအများစုဟာ ဒီပရိုဖိုင်နဲ့ ကိုက်ညီနိုင်ပါတယ်။ ချစ်လှစွာသော စာဖတ်သူ၊ သင်ဒီမှာရှိနေသေးရင် သင့်ပရိုဖိုင်က ကိုက်ညီမှာ သေချာပါတယ်၊ မဟုတ်လား။
ပြီးတော့ ကံဆိုးတဲ့တစ်နေ့မှာ အရေးပါတဲ့ frontend developer တစ်ယောက်ဟာ Acme မှာ ပြေးခဲ့တယ် npm သည် acme-cute-lib ကို install လုပ်ပါ@acme/cute-lib ဟာ မှန်ကန်တဲ့ scoped dependency ဖြစ်တယ်ဆိုတာ မေ့လျော့နေတာပါ။ တိကျတဲ့အမှားက အရေးမကြီးပါဘူး၊ software lifecycle ကို ပြီးပြည့်စုံစွာ ထိန်းချုပ်နိုင်ရင်တောင် အရာများစွာ မှားယွင်းသွားနိုင်ပါတယ်။ ကျွန်ုပ်တို့ရဲ့ developer ဟာ APT အဖွဲ့တစ်ဖွဲ့က Acme ကို ပစ်မှတ်ထားပြီး အဲဒီနာမည်အောက်မှာ malicious component တစ်ခုကို လိမ္မာပါးနပ်စွာ ထုတ်ဝေခဲ့တယ်ဆိုတာ မသိခဲ့ပါဘူး၊ ဒါကြောင့် software ကို Acme ကွန်ပျူတာတွေမှာ install လုပ်မှသာ malicious အပြုအမူက အသက်ဝင်ပါတယ်။ package ကို ထုတ်ဝေပြီး ရက်သတ္တပတ်အတော်ကြာတဲ့အထိ မတွေ့ရှိခဲ့ပါဘူး။
အထောက်အထားများကို ရှာဖွေသည့် installation script တစ်ခုကို လုပ်ဆောင်သည် (ကျွန်ုပ်တို့၏ developer ၏ laptop တွင် access token များစွာရှိသည်)၊ internal software repositories များနှင့် အထက်ဖော်ပြပါ internal repository တို့ကို ဝင်ရောက်ခွင့်ပြုသည်၊ ၎င်းတို့ကို VPN မှတစ်ဆင့်သာ ဝင်ရောက်ကြည့်ရှုနိုင်သည်။ malicious code သည် လက်ရှိ VPN ချိတ်ဆက်မှုကို အသုံးပြု၍ ဒုတိယအဆင့် malicious component ကို internal registry ထဲသို့ publish လုပ်ခဲ့ပြီး Acme မှ ပေးပို့သော software အများစုမှ မျှဝေထားသော utils library ကို ထိခိုက်စေခဲ့သည်။
ရက်သတ္တပတ်အနည်းငယ်အကြာတွင် Acme ၏ထုတ်ဝေထားသော tool များကိုအသုံးပြုသည့် အခြားအဖွဲ့အစည်းများသည် ၎င်းတို့၏ကွန်ရက်များတွင် ထူးဆန်းသော traffic ကိုစတင်မြင်တွေ့ခဲ့ရပြီး Acme ၏ protocol ကိုအသုံးပြုသော်လည်း Acme domain နှင့်ဆင်တူသော host များထံ traffic များရောက်ရှိခဲ့သည်။ traffic ကို encrypt လုပ်ထားသော်လည်း system monitoring tool များသည် မမျှော်လင့်ထားသောဖိုင်များနှင့် system command များနှင့်ဆင်တူသော်လည်း download လုပ်ထားသော executable များကို လည်ပတ်စေသည့် process များကို execute လုပ်သည်ကိုတွေ့ရှိခဲ့သည်။
ကျန်တာတွေကတော့ သမိုင်းပါပဲ။ Acme က အဲဒီလိုအပြုအမူဟာ သူတို့အတွက် စွပ်စွဲခံရမှာမဟုတ်ဘူးလို့ ပထမဆုံးငြင်းဆိုခဲ့ပြီး လုံခြုံရေးအစီအမံအားလုံး ကျင့်သုံးထားတယ်လို့လည်း ဆိုပါတယ်။ ဆိုက်ဘာလုံခြုံရေးမီဒီယာတွေက တွေ့ရှိရတဲ့အပြုအမူရဲ့ရင်းမြစ်ဟာ Acme ရဲ့အစိတ်အပိုင်းတွေကနေ ဘာကြောင့်စတင်ခဲ့တာလဲလို့ မေးမြန်းပြီးနောက်မှာမှ လုံခြုံရေးခွဲခြမ်းစိတ်ဖြာမှုက အဲဒီအစိတ်အပိုင်းတွေမှာ ခိုးကြောင်ခိုးဝှက် malware တွေ ဘယ်လောက်ပြည့်နှက်နေလဲဆိုတာကို ဖော်ပြခဲ့ပြီးမှသာ Acme ဟာ ဖြစ်ရပ်ကို သိရှိပြီး ဖြစ်ရပ်တုံ့ပြန်မှုကုမ္ပဏီတစ်ခုကို ခေါ်ယူခဲ့ရပါတယ်။ တစ်စက္ကန့်အတွင်းမှာပဲ ခက်ခဲစွာရှာဖွေထားတဲ့ ယုံကြည်မှုကို ထိခိုက်စေတဲ့ အပျက်သဘောဆောင်တဲ့ စျေးကွက်ရှာဖွေရေးလှုပ်ရှားမှုတစ်ခုပါပဲ။Acme ကို di မှ npm တစ်ခု install လုပ်ရန် လိုအပ်ပါသည်saster" ဟူသော ခေါင်းစဉ်သည် အသုံးများသော ခေါင်းစဉ်တစ်ခုဖြစ်သည်။ ထို့နောက် တရားစွဲဆိုမှုများနှင့် ဖျက်သိမ်းလိုက်သော စာချုပ်များလည်း လိုက်ပါလာခဲ့သည်။
လူသိများသော အတိတ်ဖြစ်ရပ်များနှင့် ဆင်တူသည်ဟု သင်မြင်ပါသလား။ Acme သည် အောက်ပါတို့ကို ရောနှောအသုံးပြု၍ ထောက်ပံ့ရေးကွင်းဆက်ဖြစ်ရပ်နှစ်ခုတွင် ကျရောက်ခဲ့သည်။ မှီခိုမှုရှုပ်ထွေးမှု/စာလုံးပေါင်းမှားခြင်း developer workstation ကို အဓိကအချက်အဖြစ် အသုံးပြုပြီး ပြင်ပအဖွဲ့အစည်းများ အသုံးပြုသော software များထဲသို့ ရောက်သွားသော component များကို ကူးစက်သည့် တိုက်ခိုက်မှုများ။ ၎င်းကို မည်သို့ကာကွယ်နိုင် သို့မဟုတ် လျော့ပါးစေနိုင်မည်နည်း။
အဆိပ်ခတ်ထားတဲ့ အထုပ်တွေ ဘာကြောင့် ဒီလောက်ရေပန်းစားတာလဲ
ဤယူဆချက်ဖြစ်ရပ်က open-source လုံခြုံရေးအတွက် ကျိုးကြောင်းဆီလျော်သော ချဉ်းကပ်မှုဖြင့်ပင် အဖွဲ့အစည်းများသည် open-source အစိတ်အပိုင်းများတွင် malware များ၏ သားကောင်မဖြစ်စေရန် တိကျသော အစီအမံများ လိုအပ်ကြောင်း ပြသနေသည်။ ပုံကြမ်းအားဖြင့် ခြိမ်းခြောက်မှုသရုပ်ဆောင်သည်-
- package အသစ်တစ်ခု ဖန်တီးပါ (လူသိများသော typosquatting သို့မဟုတ် dependency confusion လမ်းကြောင်းများကို လိုက်နာခြင်းဖြင့်၊ ၎င်းသည် volume တွင် မကောင်းသူများ အများဆုံးဖြတ်သန်းသွားသော လမ်းကြောင်းဖြစ်သည်)။
- ရှိပြီးသားတစ်ခုကို ကူးစက်အောင်ကြိုးစားပါ၊ ၎င်းကို source code ထဲသို့ ထိုးသွင်းခြင်း သို့မဟုတ် ၎င်းကို contributor အဖြစ် ဖုံးကွယ်ရန် ကြိုးစားခြင်း pull requestသို့မဟုတ် လူမှုရေးအင်ဂျင်နီယာကို အသုံးပြု၍ ပြုပြင်ထိန်းသိမ်းသူဖြစ်လာခြင်း (“Jao Tan” XZ Backdoor တွင်ပြုလုပ်ခဲ့သကဲ့သို့ သို့မဟုတ် ညာဘက်၉ctrl GitHub အသုံးပြုသူက လုပ်ခဲ့တာက ဖြစ်ရပ်-စီးကြောင်း ၂၀၁၈ ခုနှစ် ဆောင်းဦးရာသီတွင် ဖြစ်ပွားခဲ့သော ဖြစ်ရပ်တစ်ခု)၊ သို့မဟုတ် open source repository အထောက်အထားများကို ရယူခြင်းနှင့် ပြုပြင်ထိန်းသိမ်းသူအဖြစ် အယောင်ဆောင်ခြင်းဖြင့်။
- package တည်ဆောက်နေစဉ်အတွင်း malware ထည့်သွင်းခြင်း၊ malicious build script တစ်ခုကို run ခြင်းဖြင့်သို့မဟုတ် package downloads များကို man-in-the-middle intercepts များဖြင့် နှောင့်ယှက်ခြင်း (ကံကောင်းထောက်မစွာ၊ TLS ကို registry အများစုတွင် အမြဲလိုအပ်ပါသည်)။
- packaged component ကို registry ထဲသို့ တိုက်ရိုက်ထိုးသွင်းပါ၊ ပုံမှန်အားဖြင့် registry credentials များကို ဖမ်းယူခြင်းဖြင့်ဖြစ်သည် (Acme ၏ တိုက်ခိုက်မှုများကဲ့သို့ ရှုပ်ထွေးသော တိုက်ခိုက်မှုများစွာအတွက် ဦးစားပေးရွေးချယ်မှုဖြစ်ပြီး၊ ပထမအဆင့်တွင် compromised workstation တွင် internal registry access token ရှိခဲ့သည်)။ .env or ~/.m2/settings.xml: မကောင်းတဲ့သရုပ်ဆောင်တွေက လျှို့ဝှက်ချက်တွေကို ဘယ်နေရာမှာရှာရမလဲဆိုတာ သိပါတယ်။) မှတ်ပုံတင်ခြင်းမှာရှိတဲ့ အားနည်းချက်တွေကိုလည်း အသုံးချခဲ့ပါတယ်။
malware များဖြင့် မှတ်ပုံတင်များကို အဆိပ်သင့်စေခြင်းသည် dependency attacks များအတွက် အခြေခံဖြစ်သည်။ နေအောက်တွင် အသစ်အဆန်းတော့ မဟုတ်ပါ။ ၎င်း၏ပျံ့နှံ့မှု မြင့်တက်လာသော်လည်း၊ ငါးနှစ်ကကဲ့သို့ပင် ယခုနည်းစနစ်များသည် အလုပ်လုပ်နေပါသည်။
source: နောက်ကျောဓားသမားရဲ့ဓားစုဆောင်းမှု.
အန္တရာယ်ရှိတဲ့ package ဟာ install လုပ်တဲ့အခါ၊ software build လုပ်တဲ့အခါ ဒါမှမဟုတ် runtime မှာ အလုပ်လုပ်နိုင်ပါတယ်။ ပြီးတော့ လုပ်ဆောင်ချက်က သတင်းအချက်အလက်တွေကို exfiltration လုပ်တာကနေ ဒုတိယအဆင့်ကြိုးပမ်းမှုအတွက် လျှို့ဝှက်ချက်တွေကို ထုတ်ယူတာ၊ source code ထုတ်ယူတာ၊ နောက်ထပ် malware တွေကို ဖြုတ်ချတာအထိ အမျိုးမျိုးရှိပါတယ်။ နောက်အပိုင်းမှာ အန္တရာယ်ရှိတဲ့ package တွေနဲ့ ဘယ်လိုထုတ်ဝေထားလဲဆိုတာကို ကျွန်တော်တို့ ခွဲခြမ်းစိတ်ဖြာသွားပါမယ်။
နောက်ထပ်ဖတ်ရန်
နောက်ဇာတ်လမ်းတွဲ အန္တရာယ်ရှိသော အထုပ်များ၏ ခန္ဓာဗေဒ- ခေတ်ရေစီးကြောင်းများကား အဘယ်နည်း။ ကျွန်ုပ်တို့၏ Malware Early Warning စနစ်ဖြင့် နေ့စဉ် စောင့်ကြည့်နေသော တကယ့်ဖြစ်ရပ်များကို အာရုံစိုက်ပါမည်။ မည်သည့် malware အမျိုးအစားများကို တွေ့ရှိခဲ့ပြီး မည်သည့်နည်းဗျူဟာများ၊ နည်းပညာများနှင့် လုပ်ထုံးလုပ်နည်းများကို အကြိုက်ဆုံးဖြစ်သည်ကို ကျွန်ုပ်တို့ ပြန်လည်သုံးသပ်ပါမည်။ ဖုံးကွယ်ထားခြင်းနှင့် ၎င်းတို့သည် အလားအလာရှိသော ပြန်လည်သုံးသပ်သူများထံမှ မည်သို့ပုန်းအောင်းရန် ကြိုးစားကြသည်၊ ထောက်လှမ်းခြင်းကို ရှောင်ရှားရန် ရှောင်ရှားသည့် နည်းပညာများနှင့် telemetry နှင့် lateral movement ဖြင့် ၎င်းတို့ မည်သို့တိုးတက်ပြောင်းလဲနေသည်ကို ကျွန်ုပ်တို့ ဆန်းစစ်ပါမည်။ စောင့်မျှော်ကြည့်ရှုပါ။
ကိုးကား
- Backstabber's Knife Collection: Open Source Software Supply Chain တိုက်ခိုက်မှုများကို ပြန်လည်သုံးသပ်ခြင်းအမ်. အိုမ် နှင့် အဖွဲ့၊ မေလ ၂၀၂၀။
- အခမဲ့ရင်းမြစ် မဲလ်ဝဲကာကွယ်မှုXygeni မှ Whitepaper။
- Software Supply Chain Security ပြန်ပြောင်းသုံးသပ်ခြင်း- ပိုမိုဘေးကင်းသော ၂၀၂၄ ခုနှစ်ကို ပုံဖော်ခြင်း။ Xygeni မှ အစီရင်ခံစာ။
