წინა ეპიზოდში, ღია კოდის მავნე პაკეტები: პრობლემა, ჩვენ განვიხილეთ, თუ რატომ იყვნენ საფრთხის შემქმნელები ასე ენთუზიაზმით აღსავსეა ახალი მავნე კომპონენტების გამოქვეყნება ან არსებული კომპონენტების უახლეს ვერსიებში მავნე პროგრამების ინექცია: ღია კოდის ინფრასტრუქტურა ნებისმიერს, ნებისმიერი ადგილიდან, საშუალებას აძლევს შექმნას ეფემერული ანგარიში. კომპონენტების რეესტრში (როგორიცაა NPM, PyPI, Docker Hub ან Visual Studio Marketplace) ან კოლაბორაციული განვითარების პლატფორმაში (როგორიცაა GitHub). ნულოვანი ღირებულება და მრავალი შესაძლებლობა იმ ჭარბი ნდობის გამოსაყენებლად, რომელიც ტრადიციულად პროგრამული უზრუნველყოფის გუნდებს აქვთ მესამე მხარის კომპონენტებზე.
ასიმეტრიამ შორის, თუ რამდენად მარტივია თავდამსხმელებისთვის ღია კოდის ინფრასტრუქტურის გამოყენებით მავნე პროგრამების გავრცელება და რამდენად რთულია პროგრამული უზრუნველყოფის შემმუშავებელი ორგანიზაციებისთვის (ყველასთვის?) მავნე პროგრამებით ინფიცირების თავიდან აცილება (და მავნე პროგრამების სხვებისთვის გავრცელებული პროგრამული უზრუნველყოფის მეშვეობით მიწოდება), გასულ წელს მავნე პაკეტების თითქმის მეოთხედ მილიონ ნიშნულს მიაღწია.
ეს იმდენად მასშტაბური პრობლემაა, რომ ვერც ერთი ორგანიზაცია ვერ გადაჭრის მას და საზოგადოება ამჟამად ღია კოდის პროცესის გადახედვის პროცესშია ნდობის, ნაგულისხმევად უსაფრთხო და დიზაინის მიხედვით უსაფრთხო პრინციპების და კომპონენტების სასიცოცხლო ციკლის შესახებ. ასეთ იდეებს შემდეგ ეპიზოდში განვიხილავთ. ღია კოდის მავნე პაკეტებისგან დაცვა: რა მუშაობს (არ მუშაობს).
გახსოვდეთ, რომ ჩვენ ვსაუბრობთ პროგრამული უზრუნველყოფის კომპონენტებზე, რომლებიც უმეტეს შემთხვევაში შეესაბამება პროგრამული პაკეტები: მრავალჯერადი გამოყენების კომპონენტები შეფუთულია ისე, რომ მათი მითითება პროგრამული უზრუნველყოფის მანიფესტში დამოკიდებულების სახით იყოს შესაძლებელი და დაინსტალირებული იყოს პაკეტების მენეჯერის ან შექმნის ინსტრუმენტის გამოყენებით. გაითვალისწინეთ, რომ ეს შემთხვევა შეიძლება გაფართოვდეს საჯარო ინფორმაციის ჩათვლით. კონტეინერის სურათები (გამოიყენება კონტეინერის გაშვების დროისა და ორკესტრაციის პლატფორმების მიერ, როგორიცაა Kubernetes) და პროგრამული ინსტრუმენტების გაფართოებები (შენობისთვის, ავტომატიზაციისა და განლაგებისთვის).
აქ ჩვენ გავაანალიზებთ, თუ როგორ მავნე კომპონენტებზე დაფუძნებული შეტევის ტაქტიკა მუშაობს წარსული მაგალითებისა და ჩვენს პლატფორმაზე მავნე პროგრამების ადრეული გაფრთხილების მიხედვით (MEW). ჩვენ მავნე კომპონენტებს სხვადასხვა განზომილებაში გავაანალიზებთ:
(1) გავრცელების არჩეული გზა (გამოყენებული რეესტრი ახალ ან არსებულ კომპონენტში და გამოქვეყნებული კომპონენტის ვერსიის ინფიცირებისთვის გამოყენებული ტექნიკა), (2) როგორ აქტიურდება ან ირთვება მავნე პროგრამა, (3) მავნე ქცევა, ანუ რა მავნე ქმედებები შეინიშნება და რა არის თავდამსხმელის მოტივაცია, (4) რომელი ტექნიკებია გავრცელებული დაფარვისთვის, შეუმჩნევლად დამალვისთვის, გვერდითი მოძრაობისთვის, ბრძანებისა და კონტროლის (C2) მასპინძლებთან კომუნიკაციისთვის და ა.შ.; და (5) ტექნიკები საკმარისი პოპულარობისა და ნდობის მოსაპოვებლად, რათა მსხვერპლმა კომპონენტი დააინსტალიროს.
არჩეული განაწილების მექანიზმი
ჩვენ ვაკვირდებით „ფონის ხმაური„არასპეციფიკური მავნე პაკეტების“ ჯგუფი, რომლებიც იყენებენ ტიპოსკუატინგით გაუფრთხილებელი დეველოპერების მოსატყუებლად, თუ პაკეტის სახელწოდებაში დაშვებულია ორთოგრაფიული შეცდომა მათი დამოკიდებულების გამო. ბევრი პოპულარული პაკეტი იღებს მსგავსი სახელწოდების პაკეტების ნაკადს ორთოგრაფიული შეცდომებით, იმ მოლოდინით, რომ ისინი მოატყუებენ ზოგიერთ გაუფრთხილებელ დეველოპერს.
ისინი იყენებენ ეფემერულ ანგარიშს, აქვეყნებენ typosquat პაკეტების ჯგუფს, ქმნიან სხვას და აქვეყნებენ სხვა ჯგუფს... გარკვეული ავტომატიზაციისა და გამომგონებლობის გამოყენებით მათ შეუძლიათ გარკვეული დახვეწილობის მიღწევა, მაგრამ, როგორც წესი, ისინი საკმაოდ ტრივიალურია. ჩვენ შინაგანად მათ ვუწოდებთ „anchovies„მთავარი მიზანი ავტორიზაციის მონაცემების მოპარვაა, თუმცა ზოგჯერ ვხვდებით ჯაშუშურ პროგრამებს, რომლებიც იპარავენ საწყის კოდს ან მგრძნობიარე მონაცემებს, როგორიცაა პერსონალური საიდენტიფიკაციო ინფორმაცია (PII), ბუფერში ჩაწერას და სხვა ეჭვებს.“
მოულოდნელად ვხედავთ უფრო დახვეწილ მავნე კომპონენტებს, „ზვიგენებს“. უმცირესობა მიმართულია კონკრეტული ჯგუფების ან ორგანიზაციებისკენ, როგორც წესი, კრიპტო დრეინერების ან ვებ სკიმერების გამოყენებით, რომლებიც პირობითად აქტიურდება, შესაძლოა, როგორც ნაჩვენებია ამ სტატიაში. ღონისძიების ნაკადის ინციდენტი შეტევის დატვირთვის გაშიფვრა მხოლოდ მაშინ, როდესაც პაკეტი სამიზნე პაკეტიდან არის მითითებული.
განაწილების მექანიზმი გაანალიზდა შესანიშნავ და ახლა უკვე კლასიკურ ნაშრომში, „Backstabber's Knife Collection: ღია კოდის პროგრამული უზრუნველყოფის მიწოდების ჯაჭვზე თავდასხმების მიმოხილვა„, რომელიც აუცილებლად წასაკითხია. ეს კარგი დიაგრამა ალბათ ადრეც გინახავთ:
ყველა გზა იქნა შესწავლილი, მათ შორის ახალი და არსებული პაკეტები; საწყისი კოდის, შექმნის სისტემის ან თავად შეფუთული კომპონენტის გავლენა; მოპარული ავტორიზაციის ან სოციალური ინჟინერიის გამოყენება; მიტოვებული ანგარიშებისა და საცავების მითვისება ან შენახული ანგარიშებისა და საცავების მოწამვლა. ზოგიერთ შეტევას სახელი მიენიჭა (ტიპოქტაცია, დამოკიდებულების დაბნეულობა, აშკარა დაბნეულობა, რეპო-ჯეკინგ. და ა.შ.) და უკვე განხილული იყო სხვაგან.
რაც შეეხება არჩეულ რეესტრებს?
NPM კვლავ ლიდერობს მავნე პაკეტების საერთო რაოდენობით, თუმცა PyPI-ზე ზრდა წელს დაიწყო. Python მონაცემთა მეცნიერებისა და მანქანური სწავლების პოპულარული ეკოსისტემაა. სინამდვილეში, მავნე პროგრამების სიმჭიდროვე ახლა PyPI-ში უფრო მაღალია, ვიდრე NPM-ში.
როგორ აქტიურდება მავნე პროგრამა
მავნე პაკეტები ინსტალაციის დროს მხოლოდ 10-დან 4 შემთხვევაში აქტიურდება (ბოლო წლებში ეს მაჩვენებელი 10-დან 6-ს უახლოვდებოდა). დანარჩენი პაკეტები მავნე ქცევას გაშვების დროს ახორციელებენ, 100-დან 1 კი ტესტების გაშვებისას აქტიურდება. როგორც ჩანს, მოწინააღმდეგეებმა იციან, რომ ინსტალაციის სკრიპტების უკონტროლო შესრულება ბევრგან გამორთულია.
რას იღებენ ბოროტმოქმედები?
ჩვენ ჩამოვთვლით მავნე ქცევის კატეგორიებს, პირველ რიგში ყველაზე პოპულარულით. გაითვალისწინეთ, რომ გავლენა შეიძლება საკმაოდ განსხვავებული იყოს: ა საწმენდი ჯიუტად დამანგრეველია, თუმცა ის გავრცელებული არ არის და მხოლოდ რამდენიმე შემთხვევაში შეინიშნებოდა, რაც მიზნობრივ კიბერომის კამპანიებს ან სასტიკ ჰაკტივიზმს უკავშირდებოდა. საკმაოდ გავრცელებულია შემდეგი კატეგორიები:
- InfoStealer / Credentials Drainerყველაზე ხშირი, არასპეციფიკური შეტევების 90%-ზე მეტი მარტივი მოპარვის მეთოდებია, რომლებიც ძირითადად ეძებენ ისეთ სერთიფიკატებს, როგორიცაა პაროლები, წვდომის ნიშნები, API გასაღებები და პირადი გასაღებები (SSH-სთვის და ა.შ.). ალბათ ყველაზე მარტივი ჩაწერაა (საწმენდებთან ერთად?). ისინი ჩამოთვლიან ცნობილ ფაილებს/დირექტორიებს და სხვა წყაროებს (მაგ. რეესტრის გასაღებებს), აფუთავენ შინაარსს და აგზავნიან ამ მონაცემებს C2 სერვერზე. იდეა მარტივია: „მე ვაქვეყნებ მოპარვის მეთოდს ფიშინგის სერთიფიკატებისთვის, რათა მოგვიანებით გამოვიყენო სერთიფიკატები მიმართული შეტევის დასაწყებად“.
დაკვირვებული C2 ქსელი, როგორც წესი, იაფფასიანი და უხარისხოა, მაგალითად, Telegram-ის არხები ან ნგროკის მსგავსი გვირაბის საბურღი ხელსაწყოები (ხშირად VPN გასასვლელი IP-ების მეშვეობით გამოვლენილი უკუ პროქსი სერვერების სახით). არსებობს ასობით (!) შესაძლებლობა, მრავალი GitHub პროექტი კი ამ პროექტშია. პაროლის მოპარვის თემა. ისეთი სპეციალიზაციები, როგორიცაა keyloggers, იშვიათია მავნე პაკეტებისა და კონტეინერის სურათებისთვის, მაგრამ უფრო ხშირია ხელსაწყოების გაფართოებებში, სადაც მომხმარებლის ურთიერთქმედებაა მოსალოდნელი.
- Dropper / Downloaderპოპულარობით მეორე, როგორც წესი, მრავალსაფეხურიანი შეტევების პირველი ადგილი. მავნე კომპონენტების სამიდან ერთზე მეტს აქვს dropper-ები (თუ მავნე დატვირთვა შედის პაკეტში) ან download-ები (ჩატვირთვა იტვირთება თავდამსხმელის კონტროლის ქვეშ მყოფი საბოლოო წერტილიდან). დატვირთვა ხშირად ცნობილი ბინარული მავნე პროგრამის ვარიანტია და ის მუშაობს და ზოგჯერ მუდმივ რეჟიმში ინახება უკანა კარების, ჯაშუშური პროგრამების, კრიპტო დრეინერების და სხვა გამოყენების შემთხვევების დასაყენებლად. ჩამოტვირთული ან განლაგებული დატვირთვა იწყებს მეორე ფაზის შეტევას არსებული მავნე ფაილების მიერ მოწოდებული მთელი ძალით. ბინარული ფაილების განაწილება შესაძლებელია პაკეტში, ხშირად შენიღბული სურათების ან სავარაუდოდ უვნებელი ფაილების ტიპების სახით, რათა თავიდან იქნას აცილებული მათი აღმოჩენა მოულოდნელ საიტებთან დაკავშირებისას.
- კრიპტოვალუტის მოპარვის სპეციალისტები / მაინერებიფინანსურად მოტივირებული მოწინააღმდეგეები მზად არიან გამოიყენონ თქვენი ღრუბლოვანი აქტივები კრიპტომაინერების გასაშვებად (ისინი აფიქსირებენ კიდეც, მუშაობენ თუ არა ისინი ღრუბლოვან ვირტუალურ აპარატში). მათ არ აინტერესებთ დაბალი მოგების კოეფიციენტი ღრუბლოვანი ინფრასტრუქტურის მოპარვისთვის დაზარალებულისთვის დაკისრებული ყოველ 53 დოლარზე 1 დოლარი. დაზარალებულებმა შესაძლოა ამის შესახებ ვერც კი იცოდნენ მანამ, სანამ მოულოდნელ ანგარიშს არ მიიღებენ. საბედნიეროდ, ეს დრო და დრო მოდის. Cryptojacking მავნე პაკეტებში არსებული კამპანიები ხანდახან ჩნდება და შემდეგ ქრება, ფიშინგს უკეთებს საფულის მომხმარებლებს ან საბოლოოდ საფულის პროვაიდერს ისახავს მიზნად, როგორც ეს ხდება ლეჯერის შეტევა.
სხვა ქცევები, როგორიცაა განლაგება backdoor დისტანციური კოდის შესრულებისთვის საპირისპირო გარსის გახსნით გამოყენება ახლა ნაკლებად ხშირია, ვიდრე წარსულში. მაგალითად, 123rf_contributor_web პაკეტი (რომელიც ამჟამად რეესტრიდან ამოღებულია) იხსნება ყოველგვარი დაბინდვის გარეშე, საპირისპირო გარსი კოპირებულია და ჩასმულია უკუ შელი შაბლონი:
ლეგიტიმური და მავნე კომპონენტების გარდა, ჩვენ დავაკვირდით რამდენიმე ბოროტად გამოყენების შემთხვევას, მათ შორის:
სპამ პაკეტები
ათასობით პატარა პაკეტია, ძირითადად NPM-ში, რომლებიც არ შეიცავს მავნე პროგრამებს, მაგრამ გვპირდებიან მარტივ შემოსავალს, „გველის ზეთს“, Viagra-ს შეთავაზებების ბმულებს და ა.შ. რამდენიმე მომხმარებელი აქვეყნებს ასეთ სპამს და რეესტრიდან დიდ გამტარუნარიანობას იღებს. კიდევ ერთმა მოთამაშემ, შესაძლოა ინდონეზიიდან, სცადა სარგებლის მიღება ამით. teaRank-ის ბოროტად გამოყენება განკუთვნილია ღია კოდის დეველოპერების კომპენსაციისთვის, ათიათასობით ურთიერთდაკავშირებული NPM პაკეტის შექმნით დაკავშირებულ GitHub-ის ფიქტიური საცავების მეშვეობით. ეს გამოყენების პირობების აშკარა დარღვევაა.
შეცდომების ჯილდოს და უსაფრთხოების კვლევის თაღლითობები
როდესაც პაკეტი აღწერს საკუთარ თავს, როგორც მონაცემების მოპარვას კეთილი მიზნებისთვის, მაგალითად, შეცდომების საძიებო პროგრამების უსაფრთხოების ხარვეზების აღმოჩენის ან ეკოსისტემის გარკვეული ასპექტების კვლევის მიზნით. ჩვენ ვნახეთ ამ კატეგორიაში ათასობით პაკეტი, რომლებიც PortSwigger-დან (მაგ. ჰოსტი oastify.com დომენში) Burp Collaborator-ის მისამართზე იგზავნება საიდენტიფიკაციო, მაგრამ არა ძალიან მგრძნობიარე მონაცემები. ჩვენ ხშირად ვაკვირდებით ამ პაკეტის კოპირატორებს. დამოკიდებულების დაბნეულობა ალექს ბირსანის კონცეფციის დამტკიცება, მაგალითად aurora-webmail-pro პაკეტი (ამოღებულია რეესტრიდან), რომელიც უბრალოდ გაუშვებს ამ უსიამოვნო კოდს წინასწარი ინსტალაციის სკრიპტში:
და ასევე მოიცავდა „ეს არის მარტივი დამოკიდებულების დაბნეულობის შეტევის კონცეფციის დამტკიცებაპასუხისმგებლობის შეზღუდვის აღწერა პაკეტი.jsonეს მომსახურების პირობების აშკარა დარღვევაა, თუნდაც ბოროტი განზრახვის გარეშე.
კარგი ამბავია? ჩვენ (ჯერჯერობით) არ გვინახავს მავნე კომპონენტების მეშვეობით გამოსასყიდის მოთხოვნით განხორციელებული შეტევები. უცნობი მიზეზების გამო, კიბერდანაშაულები, როგორც ჩანს, უპირატესობას ანიჭებენ უფრო ტრადიციულ ელექტრონული ფოსტის ფიშინგს, RDP-ზე დაფუძნებულ და დრაივ-ბაი ჩამოტვირთვის მიწოდების მექანიზმებს.
დამატებითი დაკვირვებული ტექნიკები
მრავალი ტექნიკა გამოიყენებოდა დაჟინებული მოქმედების, თავდაცვის თავიდან აცილების, ინფორმაციის შეგროვების, სარდლობისა და კონტროლის მასპინძლებთან კომუნიკაციისა და ექსფილტრაციისთვის.
არსებულ მავნე კომპონენტებში დაცვა მიიღწევა მეორე ეტაპის ბინარული მავნე პროგრამის მუდმივობის ფუნქციების გამოყენებით, თუმცა ზოგჯერ ქცევა პაკეტის კოდშია განთავსებული, ყველაზე გავრცელებული კი დაგეგმილი დავალებები და Windows-ის რეესტრში ცვლილებებია.
ჩავარდნა გავრცელებულია, მაგრამ არასპეციფიკური. ტიპოსკუტანციის პაკეტების უმეტესობა (გახსოვდეთ „anchovies"?) საერთოდ არ იყენებენ ობსუქციას; ბევრი იყენებს ან ტრივიალურ ობსუქციას (base64/hex კოდირება ან ჩანაცვლებითი შიფრები, როგორიცაა rot13) ან არსებულ კოდის ობსუქტორებსა და მინიფიკაციას, რომლის შექცევაც სწორი ხელსაწყოებით მარტივია. მხოლოდ „ზვიგენები“ ახერხებენ რეალურ, მყარ ობსუქციას, რომლის უკუინჟინერია ძნელია.
შესაძლოა, დაფარვამ შეტევა დამალოს, მაგრამ რატომ უნდა იყოს ღია კოდის კომპონენტში კოდის დაფარვა საჭირო? არსებობს თუ არა მტკიცებულება, რომ რაღაც უნდა დაიმალოს თვალსაჩინო ადგილიდან? ჩვენ აღმოვაჩინეთ არამავნე პაკეტების მრავალი შემთხვევა, რომლებიც იყენებენ დაფარვას ინტელექტუალური საკუთრების დასაცავად, რაც ეწინააღმდეგება „ღია კოდის“ კონცეფციას. დაფარვა შეიძლება გამოყენებულ იქნას მავნე პროგრამის მტკიცებულებად, მაგრამ ის არ არის დამაჯერებელი. ასევე რთულია მისი მოხსნა.
გადაუხდელობის აღკვეთის შესახებ დაცვის კონტროლიდან მარტივ ტექნიკას იყენებს. მავნე კოდი ხშირად დაცულია სცადე… დაიჭირე ბლოკები, რომლებიც უგულებელყოფენ ნებისმიერ გამონაკლისს, ამიტომ არანორმალური აქტივობა არ აისახება ჟურნალებში. გარემოს დადასტურება (მუშაობს ვირტუალურ მანქანაში ან კონტეინერში) იშვიათია, გარდა კონკრეტული ორგანიზაციის ან გარემოს წინააღმდეგ მიმართული მავნე პროგრამისა.
ბინარული ფაილების სურათებსა და PDF ფაილებში შენიღბვა (ერთგვარი სტეგანოგრაფია) კიდევ ერთი ტექნიკა იყო, რომელიც აღმოჩენისგან თავის არიდების მიზნით გამოიყენებოდა.
რადგან ყველაზე გავრცელებული მავნე კომპონენტები ინფორმაციის მოპარვის პროგრამებია, მონაცემთა შეგროვების აუცილებელია. საიდუმლოებები (პაროლები, წვდომის ნიშნები, API გასაღებები, კრიპტოგრაფიული გასაღებები) რუტინულად სკანირდება ჟურნალის ფაილებში, გარემოს ცვლადებში და ბუფერშიც კი (რაც შეინიშნება საბანკო ტროიანებსა და კრიპტოს ქურდებში). წყაროს კოდის ამოღებაც ხშირია, რადგან პაკეტის ინსტალაცია ხშირად ხდება განვითარების კვანძში, სადაც შეიძლება შიდა git საცავების კლონირება. ჩვენ გვინახავს პაკეტები, რომლებიც ჩამოთვლიან დირექტორიებს git საცავების მოსაძებნად. საკმაოდ ხშირია ისეთი ადგილების ძებნა, როგორიცაა .env, private.pem, settings.py, app.js ან application.properties.
ექსტრაქცია კიდევ ერთი ფართოდ გავრცელებული ქმედებაა. მავნე პაკეტების მხოლოდ მცირე ნაწილი ცდილობს მოპოვებული მონაცემების დანიშნულების ადგილის დამალვას. Telegram-ის არხები და ნგროკის მსგავსი გვირაბები ხშირად გამოიყენება. და ბევრია როგორც წესი, თეთრ სიაში მყოფი დომენები გამოიყენება ექსფილტრაციისთვის.
სხვა ტექნიკა, როგორიცაა პრივილეგიების ესკალაცია ან გვერდითი მოძრაობა, ნაკლებად გავრცელებული იყო.
პოპულარობისა და ნდობის მოპოვება
წარმოიდგინეთ ტექნოლოგიური თაღლითი, რომელსაც მზა, მავნე ნივთი აქვს და ფიქრობს: „როგორ გავხადო ეს სისულელე სანდო ამ არაფრისმომცემი იდიოტებისთვის?“.
ეს ნიშნავს, თუ როგორ უნდა გავაკეთოთ ჩანაწერი მავნე კომპონენტისთვის, რათა აჩვენოს მრავალი ვარსკვლავი / განშტოება (პოპულარობისთვის), პლუს ვერსიები / პრობლემები და pull requests (აქტივობისთვის). იდეა ფიქტიური პოპულარობის (ვარსკვლავების) და დამოკიდებულების მოპოვებაა, ასევე შესაბამისობისა და შენარჩუნების დამაჯერებელი ხედვა.
რეესტრი არ ამოწმებს, ემთხვევა თუ არა GitHub პროექტის შინაარსი და პაკეტის შინაარსი.ეს პროგრამული უზრუნველყოფის მიწოდების ჯაჭვში კარგად ცნობილი პრობლემაა. საჯარო რეესტრები გიგანტური „ჩაძირვებია“, რომლებიც ყლაპავენ ყველაფერს, რასაც მათ ესვრიან. თქვენ შეგიძლიათ დააკავშიროთ ნებისმიერი რეპოზიტორი.
თუ მავნე პაკეტის ორთოგრაფიული შეცდომა პოპულარულ პაკეტს აჭერს, ეს მარტივია: უბრალოდ მიუთითეთ არსებული GitHub რეპოზიტორია დამოკიდებულებების მანიფესტში, რომელიც გამოიყენება პაკეტის შესაქმნელად და რეესტრში მისი გამოქვეყნებისთვის. ყალბ GitHub რეპოზიტორზე ახალი პაკეტებისთვის შეიძლება დაგჭირდეთ მეტი გამომგონებლობა, შესაძლოა ყალბი პაკეტების შექმნა. ვარსკვლავების ყურება/გაყოფილება GitHub ანგარიშები სკრიპტინგის საშუალებით.
და თუ თქვენი პაკეტის შინაარსი საკმაოდ ჰგავს რეპოზიტორის შინაარსს, შეიტანეთ რამდენიმე კარგად შემუშავებული ცვლილება აქა-იქ... შეგიძლიათ თქვენი მავნე პროგრამა შეიყვანოთ ახალ პაკეტში, რომელიც წააგავს პოპულარულ პაკეტს და რომელიც არსებულის რეპოზიტორიას იყენებს და დაელოდოთ შეცდომებს. თუ ვინმე გაბედავს პაკეტის tarball-ის შინაარსის შედარებას GitHub რეპოზიტორიის შინაარსთან, მავნე პროგრამის შეყვანის წერტილებში განსხვავებები ადვილად შეუმჩნეველი დარჩება. ეს მიდგომა ადრეც ბევრჯერ გვინახავს.
მისასალმებელი იქნებოდა კომპონენტისთვის ისეთი მექანიზმის შექმნა, რომელიც გაყალბებისგან დაცულ განცხადებას გააკეთებდა პაკეტის წარმომავლობის, მისი შექმნის, წყაროებიდან და ვის მიერ. თუმცა ეს სხვა ამბავია.
X კომპონენტი მავნე პროგრამაა?
არსებობს თუ არა მავნე პაკეტების (ყოვლისმომცველი) მონაცემთა ბაზა? არა. ღია კოდის დაუცველობებს ენიჭებათ CVE ID, მაგრამ მხოლოდ რამდენიმე მავნე პაკეტს (განსაკუთრებით მათ, რომლებიც სათაურებში ხვდებიან) ენიჭება ის. მავნე პაკეტების CWE არის CWE-506 (ჩაშენებული მავნე კოდი).
ჩვეულებრივი მავნე პროგრამები (VirusTotal, MalwareBazaar, SOREL-20M…) არ ითვალისწინებენ მავნე კომპონენტებისთვის სპეციალურ დებულებებს. ეს მისასალმებელი იქნებოდა!
ანალიზისთვის არსებობს კვლევის ნიმუშების მონაცემთა ბაზები და მონაცემთა ნაკრებები (ჩვენ რამდენიმე მათგანს ვიყენებთ), მაგრამ ჩანაწერები განახლდება მხოლოდ მაშინ, როდესაც მავნე პაკეტი ცნობილია, რაც ხშირად ძალიან გვიანია. თუ დაინტერესებული ხართ, OpenSSF მავნე პაკეტები კარგი დასაწყისია.
შემდეგ პოსტში განვიხილავთ, თუ როგორ გავიგოთ, არის თუ არა მოცემული პაკეტი მავნე. სპოილერი: დიახ, არსებობს მავნე კომპონენტების შემოწმების გზები ექსპოზიციის ფანჯრის ადრეულ ეტაპზე, სანამ რეესტრი წაშლის ცნობილ მავნე კომპონენტს.
შემდგომი მოსმენით
შემდეგ ეპიზოდში „ღია კოდის მავნე პაკეტებისგან დაცვა: რა მუშაობს (არ მუშაობს)" ჩვენ განვიხილავთ ღია კოდის უსაფრთხოებისთვის გასაკეთებელ და არასაჭირო რჩევებს. უსაფრთხოების საკითხებში ჩართული პროფესიონალების უმეტესობას აქვს ინტუიცია იმის შესახებ, თუ როგორ უნდა გაუმკლავდეს ამ საფრთხეს, თუმცა არსებობს მცდარი წარმოდგენები.
ჩვენ განვიხილავთ, თუ რატომ არის ეს იდეები არასწორი და როგორ უწყობს ხელს ასეთი მცდარი წარმოდგენები ამ შეტევის მექანიზმის პოპულარობას და იმ უზარმაზარ რისკს, რომელსაც ორგანიზაციები განიცდიან. შემდეგ გავაგრძელებთ იმის განხილვას, თუ რა მუშაობს და რა ძალისხმევა და რესურსებია საჭირო.
ასევე, ჩვენ ვაპირებთ გამოვაქვეყნოთ მავნე პაკეტების ევოლუციის შესახებ მათი განზრახვის, ინექციის მექანიზმისა და შეტევის ტექნიკის თვალსაზრისით.
ადევნეთ თვალყური!
