ეს არის სტატიების სერიის პირველი ეპიზოდი პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის ყველაზე გავრცელებული ტიპის შეტევების შესახებ: ისინი, რომლებიც (ბოროტად) იყენებენ პროგრამული კომპონენტების საჯარო რეესტრს, რომლებიც განკუთვნილია... ღია კოდის პროექტები არტეფაქტების ატვირთვა, რომელთა გაზიარებაც სხვა მომხმარებლებთან იქნებოდა შესაძლებელი. როდესაც ბოროტმოქმედები აქვეყნებენ მავნე პროგრამულ უზრუნველყოფას, რეესტრის გამოყენებით მავნე პროგრამების გავრცელების საშუალებად, ჩვენ გვაქვს მიწოდების ჯაჭვის შეტევა, როდესაც მსხვერპლი ორგანიზაციები აინსტალირებენ ან ამუშავებენ ინფიცირებულ პროგრამულ კომპონენტს.
დისკუსიის გასამარტივებლად, ჩვენ ვისაუბრებთ პროგრამული პაკეტები:, კომპონენტები შეფუთული სახით, რომლებიც წარმოებულია მესამე მხარის მიერ. ეს მოიცავს არა მხოლოდ კომპონენტებს, რომლებსაც იყენებენ პაკეტის მენეჯერები, როგორიცაა NPM ან Poetry, არამედ ოპერაციული სისტემის კომპონენტები მათ შორის ბიბლიოთეკები და შესრულებადი ბინარული ფაილები, კონტეინერის სურათები, და ვირტუალური მანქანები, ან ხელსაწყოს გაფართოებები განვითარების, შექმნისა და განლაგების ინსტრუმენტებისთვის. ჩვენ ყველგან ვნახეთ მავნე პაკეტები. კიბერკრიმინალებს ეს არ აწუხებთ: ისინი აღფრთოვანებულნი არიან თანამედროვე პროგრამული ინფრასტრუქტურის მიერ შემოთავაზებული ალტერნატივებით და იყენებენ რეესტრს და ინსტრუმენტს, რომელიც საუკეთესოდ შეესაბამება მათ მიზანს. ამიტომ, გთხოვთ, გახსოვდეთ, რომ პროგრამული პაკეტები არის კონტეინერის სურათების, ბინარული პაკეტების, ღია კოდის საცავების და ყველა სახის გაფართოების ან მოდულის (IDE-ები, CI/CD სისტემები, შექმნის ინსტრუმენტები). ყველა მათგანი რეგულარულად ექვემდებარება თავდასხმებს.
სერიალს 5 ეპიზოდი ექნება:
- რა პრობლემაა ღია კოდის პაკეტებთან დაკავშირებით? ეს არის ამ პოსტის თემა. რატომ აქვეყნებენ ყველანაირი დამნაშავე მავნე პაკეტებს? რატომ უნდა ვიყო შეშფოთებული?
- მავნე პაკეტების ანატომია: რა ტენდენციებია? ამ ეპიზოდში ჩვენ ყურადღებას გავამახვილებთ იმ საფრთხეზე, რომელსაც ყოველდღიურად ვაკვირდებით ჩვენი MEW სისტემით. დიდი რაოდენობით მავნე პაკეტების გამო, რომლებიც იყენებენ typosquatting-ს ან დამოკიდებულების დაბნეულობას, დიდი ფონური ხმაურის გამო, შეტევების მცირე პროცენტი გაცილებით მზაკვრულია და უფრო დიდ რისკს წარმოადგენს. როგორ შეიცვალა ცუდი აქტორების ქცევა ოპერაციულ სისტემასთან დაკავშირებით ბოლო დროს? რა რიცხვებია ეს? რა ტაქტიკა, ტექნიკა და პროცედურები იქნა გამოყენებული და რა მავნე ქმედებები დაფიქსირდა?
- ღია კოდის მავნე პაკეტებისგან დაცვა: რა მუშაობს (არ მუშაობს)უსაფრთხოების შესახებ ინფორმირებული სპეციალისტების უმეტესობას აქვს იდეები, თუ როგორ გაუმკლავდეს ამ საფრთხეს. ჩვენ გვსმენია, როგორ ამბობენ უსაფრთხოების მენეჯერები ყოყმანის გარეშე, რომ SCA ინსტრუმენტები უკვე გეუბნებიან, როდის არის პაკეტის ვერსია მავნე. ან რომ ისინი დამოკიდებულნი არიან ცნობილ, მაღალრეიტინგულ პროგრამულ კომპონენტებზე, სადაც ნებისმიერი მავნე პროგრამა დაუყოვნებლივ იქნება აღმოჩენილი და წაშლილი. ისინი ამბობენ, რომ ისინი იყენებენ ღია მცირე/პატჩ ვერსიებს დაუცველობის ავტომატურად გამოსასწორებლად და ეს არის სწორი, რეკომენდებული გზა ღია კოდის დამოკიდებულებებთან დაკავშირებული რისკის შესამცირებლად, „ადრე გაასწორე, ხშირად გაასწორე“ პრინციპის დაცვით. ამ ეპიზოდში განვიხილავთ, თუ რატომ არის ეს იდეები არასწორი და როგორ უწყობს ხელს ასეთი მცდარი წარმოდგენები ამ შეტევის მექანიზმის პოპულარობას და იმ გადაჭარბებულ რისკს, რომელსაც ორგანიზაციები განიცდიან. დასასრულს, ჩვენ ვისაუბრებთ იმაზე, თუ რა მუშაობს და რა არის ჩართული ძალისხმევა და რესურსები.
- ღია კოდის მავნე პაკეტები: Xygeni-ს მიდგომაამ ეპიზოდში წარმოგიდგენთ, თუ რა სტრატეგიას ვიყენებთ Xygeni-ში ჩვენი მავნე პროგრამების ადრეული გაფრთხილების (MEW) სისტემისთვის. როგორ მუშაობს ეს მრავალსაფეხურიანი სისტემა რეალურ დროში, როდესაც გამოქვეყნდება პაკეტის ახალი ვერსია, როგორ ხდება მტკიცებულებების შეგროვება სხვადასხვა წყაროდან, როგორ ხდება ტრიაჟი, რა კლასიფიკაციის კრიტერიუმებს ვიცავთ და რატომ არის საჭირო გარკვეული ხელით ანალიზი მავნე პაკეტის კანდიდატის ბუნების დასადასტურებლად? როგორ ეხმარება ჩვენი შიდა და რეესტრის გუნდების უკუკავშირი სისტემას ისწავლოს წარსული შეგროვებული მტკიცებულებებიდან, რათა მინიმუმამდე დაიყვანოს ცრუ დადებითი შედეგები. ჩვენ და ჩვენ ავხსნით, თუ როგორ ვეხმარებით NPM-ს, GitHub-ს, PyPI-ს და ღია კოდის ეკოსისტემებში არსებულ სხვა ძირითად ინფრასტრუქტურებს ყოფნის დროის შემცირებაში..
- ღია კოდის ექსპლუატაცია: რას უნდა ველოდოთ ბოროტმოქმედებისგანსერიალი მთავრდება იმ უახლეს ქმედებებზე ფოკუსირებით, რომლებსაც მოწინააღმდეგეები იყენებენ, რათა თავდასხმები უფრო ფარული, უფრო რთული აღმოსაჩენი, უფრო კონკრეტული ინდუსტრიების წინააღმდეგ მიმართული და ამ კლასის თავდასხმებიდან მეტი სარგებელი მიიღონ. განხორციელდება თუ არა გამოსასყიდის მოთხოვნით შექმნილი თავდასხმები ამ მექანიზმის გამოყენებით? როგორ იყენებენ ბოროტმოქმედები ხელოვნური ინტელექტის ინსტრუმენტებს უფრო დახვეწილი მავნე პაკეტების გადასაცემად? საფრთხე ემუქრებათ თუ არა ყველაზე პოპულარულ პროექტებს? ეს კეთდება იმისათვის, რომ მკითხველს წარმოდგენა შეექმნას ამ შეიარაღების რბოლის შესახებ და რას უნდა ელოდონ მოკლევადიან (2024 წლის მეორე ნახევარი) და საშუალოვადიან (2025) პერიოდში. ჩვენ შევისწავლით, თუ როგორ მოქმედებს ისეთი თავდასხმები, როგორიცაა ბოლო... XZ-Utils-ის უკანა კარიან ხმელეთიდან გამოსული ადამიანების თავდასხმა ელექტრონების შემქმნელი 2024 წლის მარტში ჩატარებული ღონისძიებები აჩვენებს, რომ ფხიზლად უნდა დავაკვირდეთ მოწინააღმდეგეების ევოლუციას.
დავიწყოთ პირველი ეპიზოდით: რა ხდება მავნე ღია კოდის პაკეტებთან დაკავშირებით?
რა პრობლემაა ღია კოდის პაკეტებთან დაკავშირებით?
ბოლო წლებში, ყველა სახის დამნაშავე იყენებდა ღია კოდის პროგრამული უზრუნველყოფის რეესტრებს მავნე ქცევის განსახორციელებლად. ეს აქტივობები ისეთივე ძველია, როგორც ღია კოდის პროგრამული უზრუნველყოფა, მაგრამ მათი სიხშირე ბოლო სამი წლის განმავლობაში მკვეთრად გაიზარდა.
მავნე კომპონენტების საჯარო რეესტრებში გამოქვეყნება (დამოკიდებულებაზე დაფუძნებული შეტევები) არის ასიმეტრიული პარტიზანული ომი, რომელსაც საფრთხის შემქმნელები იყენებენ მავნე პროგრამების გასავრცელებლად, რაც ორგანიზაციების მიერ უცნობი დეველოპერებისგან მომდინარე ღია კოდის კომპონენტებზე დაფუძნებულ ნდობას იყენებს (გახსოვდეთ დამოკიდებულება xkcd კომიქსი?). რადგან თქვენ ენდობით პაკეტებს და არ გეწყინებათ პაკეტის შინაარსისა და მათი დამოკიდებულებების ხელით გადახედვა, ეს შეტევები განსაკუთრებით ეფექტურია. ასიმეტრია კი იმიტომ ხდება, რომ მათი დიდწილად ავტომატიზირება შესაძლებელია და ბოროტმოქმედებს არ სჭირდებათ მსხვერპლთან პირდაპირი ურთიერთქმედება. ისინი უბრალოდ ატვირთავენ პაკეტს საჯარო რეესტრში და უშვებენ მას.
მავნე პაკეტები 2022 წელს 6-ჯერ გაიზარდადა 2023 წელს 2.5-ჯერ გაიზარდა. გასულ წელს 245 000 მავნე პაკეტი დაფიქსირდა, რაც წინა წლების საერთო რაოდენობას ორჯერ აღემატება. ეს ექსპონენციალური ზრდაა! 2021 წელს ასობით დადასტურებული მავნე პროგრამის სახით პაკეტების წაშლიდან დაწყებული, 2022 წელს ათასობით პაკეტებით დამთავრებული, 2023 წელს გაცილებით მეტი ფონური „ხმაური“ დავინახეთ, წელს კი მსგავსი ტემპით. და ამ ფონზე, რომელიც გამოწვეული იყო არაპროფესიონალი კიბერდანაშაულებით, რომლებიც „უმცირესი წინააღმდეგობის გზას“ მიჰყვებოდნენ, გახმაურებული თავდასხმების უმცირესობამ სათაურები მოიპოვა, თუნდაც ზოგადი მედიის სათაურებში.
რატომ არის ეს ასეთი მასშტაბის პრობლემა? არსებობს ნდობის გადაჭარბება მთელი ჯაჭვის განმავლობაში. ღია კოდის პროგრამული უზრუნველყოფა ვრცელდება თავისი საწყისი კოდით და გამოდის მოცემული ლიცენზიით. დიახ, ნებისმიერს შეუძლია საწყისი კოდის შემოწმება; მაგრამ ვინ აკეთებს ამას ზოგადად? ვინ, პროგრამული უზრუნველყოფის მავნე პროგრამების არარსებობის შემოწმების შემდეგ, ქმნის პროგრამულ უზრუნველყოფას საწყისი წყაროებიდან? ვინ, შეფუთული კომპონენტის (ასევე ცნობილი როგორც პაკეტი) პაკეტების მენეჯერის ან შექმნის ინსტრუმენტის ქვემოთ, უზრუნველყოფს, რომ პაკეტი არ არის დატვირთული მავნე პროგრამებით და შეესაბამება იმ სავარაუდო საწყის კოდს, საიდანაც ის უნდა მოდიოდეს?
რატომ იძლევა ინფრასტრუქტურა ასეთი მარტივი შეტევების საშუალებას?
პაკეტის რეესტრები ღიაა, ხშირად საჭიროებს გამომცემლის ვინაობის მინიმალურ დადასტურებას. „ნებისმიერს შეუძლია თავისი პროგრამული უზრუნველყოფის აქ გამოქვეყნება!“ თავდამსხმელებისთვის ზღვარი დაბალია: ისინი იყენებენ ერთჯერადი ელექტრონული ფოსტის მისამართებს და ერთჯერადი GitHubgithub ანგარიშებს ასობით მავნე პაკეტის შესაქმნელად მოკლე, ფიშინგის მსგავს კამპანიებში. მხოლოდ მიზნობრივი პაკეტებისთვის არის საჭირო უფრო მაღალი დახვეწილობა: ჩვენ ვნახეთ სანდო GitHub წყაროს საცავის შექმნაც კი მრავალი ვარსკვლავით და commitმრავალი ყალბი კონტრიბუტორისგან და პოპულარობისა და შენარჩუნების სხვა მაჩვენებლები. მიღება ვარსკვლავთმცოდნეები და რეპუტაცია ყალბი წვლილისგან ავტომატიზაცია რთული არ არის. ჩვენ ვნახეთ ყველა სახის ღია პროგრამული უზრუნველყოფის ინფრასტრუქტურის ბოროტად გამოყენების შემთხვევები, არა მხოლოდ მავნე პროგრამები, როგორიცაა ჩაის პროტოკოლის ინციდენტი.
პაკეტის მენეჯერები შექმნილია გამოყენების სიმარტივისთვის და არა უსაფრთხოებისთვის.მათ შეუძლიათ ინსტალაციამდელი და ინსტალაციის შემდგომი სკრიპტების გაშვება (ზოგჯერ ბიბლიოთეკისთვის მშობლიური კოდის კომპილაცია აუცილებელია). ასევე, პაკეტის მენეჯერები პაკეტების ინსტალაცია მრავალი წყაროდან და ზოგჯერ ნაგულისხმევად საჯარო რეესტრების გამოყენებაა. მათ არ შეამოწმეს შეუსაბამობა გამოქვეყნების მოთხოვნაში არსებულ მეტამონაცემებსა და თავად პაკეტში არსებულ მეტამონაცემებს შორის.
დამოკიდებულებები ჩადგმულია და ქმნის გრაფიკს. გარკვეულ ეკოსისტემებში, როგორიცაა Node (JavaScript), მცირე მარცვლოვანი დამოკიდებულებები ასობით ან ათასობით გროვდება. ერთი რამ არის მკაცრი კონტროლი ჩემი პროგრამული პროექტების მიერ გამოცხადებულ პირდაპირ დამოკიდებულებებზე, მაგრამ გარდამავალი დამოკიდებულებები უფრო რთული კონტროლირებადია. ღია კოდი მიჰყვებოდა პრინციპს „ჩემი მეგობრების მეგობრები ჩემი მეგობრები არიან“. ძმობა ნორმაა ველურ შორეულ აღმოსავლეთში! საფრთხის შემქმნელებმა იციან ეს და ღრმად მალავენ მავნე ქცევას ბუნდოვან დამოკიდებულებებში, რომლებიც ხშირად უცნობია. ეს იყო შემთხვევა ღონისძიების ნაკადი ინციდენტი, რომელიც მიზნად ისახავდა Copay საფულე.
ასე მუშაობდა ღია კოდის პროგრამული უზრუნველყოფა მისი დაარსების დღიდან. ეს დიდად არ შეიცვლება. ზოგიერთი პაკეტის რეესტრი, საუკეთესო შემთხვევაში, ორფაქტორიან ავთენტიფიკაციას მოითხოვს და ხშირად მხოლოდ ყველაზე პოპულარული პაკეტებისთვის. ზოგიერთი რეესტრი უზრუნველყოფს სკოპებს, სახელთა სივრცეს, რომელიც შემოწმებული ორგანიზაციის საკუთრებაშია, მაგრამ ტრაგიკულად სხვები არ უჭერენ მხარს მას (PyPI) ან არჩევითს ხდიან (NPM). საინტერესოა აღინიშნოს, რომ თუნდაც ა. მარტივი სკრინინგის სქემა (ჯგუფის ID-თან შესაბამისობაში მყოფი DNS ან GitHub საცავის/ორგანიზაციის კონტროლის საფუძველზე) და შექმნა PGP ხელმოწერები სავალდებულოა ყველა არტეფაქტისთვის, გარდა ჩეკსუმებისა, შლის „ხმაურის“ უმეტესობას, ტიპოსკუტის მსგავს მავნე პაკეტებს და ზღუდავს მათ დიდ ნაწილს. დამოკიდებულების დაბნეულობადახვეწილი შეტევები შესაძლებელია, მაგრამ გაცილებით რთული, მხოლოდ რამდენიმე მსგავსი com.github.codingandcoding:maven-compiler-plugin ცნობილია Maven Central-ით. და ყველა Maven-ის რეესტრი ერთსა და იმავე პრაქტიკას არ მისდევს!
პაკეტების მენეჯერების უსაფრთხოების კონტროლი შეიძლება ამძიმებდეს, მაგრამ არ აფერხებდეს დამოკიდებულების შეტევებს. მრავალფაქტორიანი ავტორიზაციის პრობლემა ის არის, რომ ავტომატიზაციისთვის, ანგარიშებისთვის გენერირდება ისეთი სერთიფიკატები, როგორიცაა წვდომის ტოკენები ან APIapi გასაღებები, რომლებიც გამოიყენება ავტომატიზაციის სკრიპტებიდან განხორციელებულ APIapi ზარებში, ხოლო მეორე ფაქტორი არ არის მხარდაჭერილი ინტერაქტიული მომხმარებლის მიერ. MFA კარგია მომხმარებლის ანგარიშების პაროლის გაჟონვისგან დასაცავად, მაგრამ გენერირებული წვდომის ტოკენები ან APIapi გასაღებები უნდა იყოს დაცული აქტიურობისას, წინააღმდეგ შემთხვევაში მოწინააღმდეგეები მათ მფლობელს გააყალბებენ. პაკეტებზე დაფუძნებული მიწოდების ჯაჭვის კამპანიების დიდი ნაწილი იწყება გაჟონილი გასაღებით/ტოკენით. უბრალოდ გახსოვდეთ ისეთი ინციდენტები, როგორიცაა ledger, 3CXდა მრავალი სხვა, სადაც არაინტერაქტიული ავტორიზაციის მონაცემები პირველად იქნა ამოღებული წინასწარი შეჭრის დროს მიწოდების ჯაჭვზე შეტევის განსახორციელებლად.
ამ საფრთხეზე რეაგირება საკმარისად ძლიერი არ იყო. მესამე ეპიზოდში ყურადღებას გავამახვილებთ იმაზე, თუ რა გაამართლა და რა ჩავარდა სავალალოდ. ინდუსტრიამ კოლექტიურად უნდა იმუშაოს ამ მიმართულებით. standards, პროცესები, განათლება და ინსტრუმენტები გლობალური მიწოდების ჯაჭვების რისკების შესამცირებლად. ეს არ არის პრობლემა, რომლის გადაჭრაც ერთ ორგანიზაციას დამოუკიდებლად შეუძლია.
ამ ნაწილის დასასრულებლად, მნიშვნელოვანი გაუგებრობა: ჩვენ ვსაუბრობთ ბოროტი პაკეტები, არა დაუცველი ერთეულები. დაუცველობები გამოწვეულია დიზაინის ან კოდირების შეცდომებით, რომლებიც შემთხვევით არის შეტანილი ცუდი განზრახვის გარეშე. დაუცველობები შეიძლება გამოყენებულ იქნას, მაგრამ ბევრი არა. მავნე პაკეტები ყოველთვის განზრახულია და მათი შესრულების შემთხვევაში 100%-იანი ექსპლუატაციაა შესაძლებელი. შედარებადი რისკი არ არსებობს! აქედან გამომდინარე. პარადოქსულია იმის დანახვა, თუ რამდენი ძალისხმევა იხარჯება დაუცველობის გამოვლენასა და შემცირებაზე და რამდენი ექვივალენტური ზომების არარსებობა მავნე კომპონენტებისთვის..
„ჩვენ უსაფრთხოებას სერიოზულად ვეკიდებით“
წარმოვიდგინოთ ჩვეულება, კორპორაცია AcmeAcme, WileCoyote.com-ის მთავარი პროვაიდერი, თავისი პროგრამული უზრუნველყოფის უმეტესი ნაწილი მესამე მხარისგან მოდის, რომელთა 80%-ზე მეტი ღია კოდის პროექტებია. ისინი ქმნიან პროგრამულ უზრუნველყოფას შიდა გამოყენებისთვის, მაგრამ ასევე აწვდიან პროგრამულ უზრუნველყოფას თავიანთ პარტნიორებს, პროვაიდერებს და მომხმარებლებს/საბოლოო მომხმარებლებს. Acme-ს აქვს Go, JavaScript, Java, C# და Python ენებზე დაწერილი პროგრამული უზრუნველყოფა და მისი პროგრამული უზრუნველყოფის უმეტეს ნაწილს ღრუბელში, Kuberneteskubernetes კლასტერების ქვეშ მართავს. Acme ქმნის თავის მორგებულ სურათებს Docker Hub-დან და სხვა რეესტრებიდან აღებული ძირითადი სურათებიდან. ასევე, ისინი იზიარებენ რამდენიმე ბიბლიოთეკას, პაკეტს და კონტეინერის სურათს საჯარო რეესტრებში.
Acme სერიოზულად ეკიდება უსაფრთხოებას. ისინი საკმაოდ კარგად აცნობიერებენ პრობლემას open source securityდა მის მიერ მოტანილი რისკი. ყველა დეველოპერი, სისტემის მენეჯერი და DevOpsdevops ინჟინერი იყენებს ამ საყვარელ პატარა კრიპტო გასაღებებს მეორე ფაქტორიანი ავტორიზაციისთვის. ყველა commitკოდის საცავები ხელმოწერილია, ფილიალის დაცვა ჩართულია სავალდებულო კოდის მიმოხილვებით, CI/CD დაკეტილი, საიდუმლოებები შენახულია საიდუმლო საცავაში და შიდა რეესტრი ნაწილობრივ ასახავს გარე რეესტრებს, სადაც მხოლოდ დაშვებული, თეთრ სიაში შეტანილი კომპონენტებია შენახული. აუცილებელია, რომ Acme-ს მიერ შექმნილმა პროგრამულმა უზრუნველყოფამ ამ რეესტრიდან მესამე მხარის დამოკიდებულებები მიიღოს.
ალბათ, ორგანიზაციების უმეტესობა ამ პროფილს შეესაბამება. ძვირფასო მკითხველო, თუ უკვე აქ ხართ, თქვენი ნამდვილად შეესაბამება, არა?
შემდეგ კი ერთ უიღბლო დღეს, მნიშვნელოვანმა ფრონტ-ენდ დეველოპერი Acme-ში გაიქცა npm-ის acme-cute-lib-ის ინსტალაცია, დავიწყებული იყო, რომ @acme/cute-lib იყო სწორი დიაპაზონის დამოკიდებულება. ზუსტი შეცდომა არ არის მნიშვნელოვანი, ბევრი რამ შეიძლება არასწორად წავიდეს, მაშინაც კი, როდესაც ადამიანი პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის სრულყოფილ კონტროლს იღებს. ჩვენმა დეველოპერმა არ იცოდა, რომ APT ჯგუფი Acme-ს ესხმოდა თავს და ამ სახელით გამოაქვეყნა მავნე კომპონენტი, ეშმაკური გზით, ამიტომ მავნე ქცევა მხოლოდ მაშინ აქტიურდება, როდესაც პროგრამა დაინსტალირებულია Acme კომპიუტერებზე. პაკეტი გამოქვეყნებიდან რამდენიმე კვირის განმავლობაში არ აღმოჩენილა.
ინსტალაციის სკრიპტი მუშაობს, რომელიც ეძებს ავტორიზაციის მონაცემებს (ჩვენი დეველოპერის ლეპტოპში ბევრი საინტერესო წვდომის ნიშანი იყო), რაც საშუალებას იძლევა წვდომა ჰქონდეს შიდა პროგრამული უზრუნველყოფის საცავებსა და ზემოხსენებულ შიდა საცავზე, რომელიც, რა თქმა უნდა, მხოლოდ VPN-ის საშუალებით არის ხელმისაწვდომი. მავნე კოდმა მოახერხა არსებული VPN კავშირის გამოყენება და მეორე ეტაპის მავნე კომპონენტის შიდა რეესტრში გამოქვეყნება, რამაც გავლენა მოახდინა Acme-ს მიერ მოწოდებული პროგრამული უზრუნველყოფის უმეტესობის მიერ გაზიარებულ საერთო უტილიტების ბიბლიოთეკაზე.
რამდენიმე კვირის შემდეგ, Acme-ს გამოქვეყნებული ინსტრუმენტების გამოყენებით სხვა ორგანიზაციებმა თავიანთ ქსელებში უცნაური ტრაფიკის დანახვა დაიწყეს, რომელიც Acme-ს პროტოკოლს იყენებდა, მაგრამ Acme დომენის მსგავს ჰოსტებზე იყო მიმართული. ტრაფიკი დაშიფრული იყო, მაგრამ სისტემის მონიტორინგის ინსტრუმენტებმა მოულოდნელ ფაილებზე წვდომა და ისეთი პროცესების შესრულება იპოვეს, რომლებიც სისტემის ბრძანებებს ჰგავდა, მაგრამ საბოლოოდ ჩამოტვირთული შესრულებადი ფაილების გაშვებას იწვევდა.
დანარჩენი ისტორიაა: Acme-მ თავდაპირველად უარყო, რომ ასეთი ქცევა მათ დაეკისრებოდათ და რომ ყველა უსაფრთხოების ზომა მიღებული იყო. მხოლოდ მას შემდეგ, რაც კიბერუსაფრთხოების მედიამ დაიწყო კითხვა, თუ რატომ მომდინარეობდა აღმოჩენილი ქცევის წყარო Acme-ს კომპონენტებიდან და უსაფრთხოების ანალიზმა აჩვენა, თუ რამდენად იყო ეს კომპონენტები დაფარული ფარული მავნე პროგრამებით, Acme-ს მოუწია ინციდენტის ამოცნობა და ინციდენტებზე რეაგირების ფირმა გამოიძახა. ნეგატიური მარკეტინგული კამპანია, რომელმაც წამში შეარყია შრომით მოპოვებული ნდობა.Acme-ს დი-სგან ერთი npm ინსტალაცია აშორებდა.saster„- ეს იყო გავრცელებული სათაური. შემდეგ სასამართლო პროცესები და გაუქმებული კონტრაქტები მოჰყვა.
ხედავთ მსგავსებას წარსულში ცნობილ ინციდენტებთან? Acme მიწოდების ჯაჭვის ინციდენტში ორ ფაზაში ჩავარდა, შემდეგი ფაქტორების ნაზავის გამოყენებით: დამოკიდებულების დაბნეულობა/ტიპოსკუთრება თავდასხმები, რომლებშიც დეველოპერის სამუშაო სადგური გამოიყენებოდა, როგორც პლაცდარმი კომპონენტების დასაინფიცირებლად, რომლებიც მესამე მხარის მიერ გამოყენებულ პროგრამულ უზრუნველყოფაში მოხვდებოდა. როგორ შეიძლება ამის თავიდან აცილება ან შემცირება?
რატომ არის მოწამლული პაკეტები ასეთი პოპულარული
ეს ჰიპოთეტური ინციდენტი აჩვენებს, რომ ღია კოდის უსაფრთხოებისადმი გონივრული მიდგომის მიუხედავად, ორგანიზაციებს სჭირდებათ კონკრეტული ზომები, რათა თავიდან აიცილონ ღია კოდის კომპონენტებში მავნე პროგრამების მსხვერპლი გახდომა. სქემატურად, საფრთხის შემქმნელს შეუძლია:
- შექმენით ახალი პაკეტი (ცნობილი typosquatting-ის ან დამოკიდებულების დაბნეულობის გზების გამოყენებით, ეს არის ყველაზე ხშირად გამოყენებული გზა ბოროტმოქმედების მიერ მოცულობის მხრივ);
- სცადეთ არსებულის დაინფიცირება, ან მისი საწყის კოდში ინექციით, ან მისი კონტრიბუტორად შენიღბვით pull request, ან სოციალური ინჟინერიის გამოყენებით, რათა გახდეთ შემნახველი (როგორც ეს „ჯაო ტანმა“ გააკეთა XZ Backdoor-ში ან right9ctrl GitHub-ის მომხმარებელმა გააკეთა ღონისძიების ნაკადი ინციდენტი 2018 წლის შემოდგომაზე), ან ღია კოდის საცავის ავტორიზაციის მოპოვებით და მომვლელის გასაყალბებლად წარდგენით;
- პაკეტის შექმნის დროს მავნე პროგრამის ინექცია, ან მავნე შექმნის სკრიპტის გაშვებით., ან პაკეტების ჩამოტვირთვისას შუამავალი ადამიანის ჩარევა (საბედნიეროდ, TLS ახლა ყოველთვის საჭიროა რეესტრების უმეტესობაში).
- შეფუთული კომპონენტის პირდაპირ რეესტრში შეყვანა, როგორც წესი, რეესტრის მონაცემების აღებით (სასურველი ალტერნატივა მრავალი დახვეწილი შეტევისთვის, როგორიცაა Acme-ს შეტევა, სადაც კომპრომეტირებულ სამუშაო სადგურს პირველ ეტაპზე ჰქონდა შიდა რეესტრის წვდომის ნიშანი, მაგ. ჩვეულებრივ .ენვ or ~/.m2/settings.xml: ბოროტმოქმედმა პირებმა იციან, სად ეძებონ საიდუმლოებები). ასევე გამოყენებული იქნა რეესტრების დაუცველობა.
დამოკიდებულების შეტევების საფუძველია რეესტრების მავნე პროგრამებით მოწამვლა. მზის ქვეშ არაფერი ახალი: მისი გავრცელება მკვეთრად გაიზარდა, მაგრამ იგივე ტექნიკა მუშაობს ახლა, როგორც ხუთი წლის წინ.
წყარო: Backstabber-ის დანების კოლექცია.
მავნე პაკეტს შეუძლია იმუშაოს ინსტალაციის, პროგრამული უზრუნველყოფის შექმნის ან გაშვების დროს. მისი ქცევა მოიცავს ინფორმაციის ამოღებიდან, მაგალითად, მეორე ფაზის მცდელობისთვის საიდუმლოებების მოპოვებიდან დაწყებული, საწყისი კოდის ამოღებითა და დამატებითი მავნე პროგრამების განთავსებით დამთავრებული. შემდეგ ეპიზოდში ჩვენ გავაანალიზებთ მავნე პაკეტებს და მათ გამოქვეყნების წესს.
შემდგომი მოსმენით
შემდეგი ეპიზოდი მავნე პაკეტების ანატომია: რა ტენდენციებია? ყურადღებას გავამახვილებთ რეალურ შემთხვევებზე, რომლებსაც ყოველდღიურად ვაკვირდებით ჩვენი მავნე პროგრამების ადრეული გაფრთხილების სისტემის მეშვეობით. ჩვენ განვიხილავთ, თუ რა ტიპის მავნე პროგრამები იქნა ნანახი და რომელი ტაქტიკა, ტექნიკა და პროცედურებია ფავორიტი. ჩვენ განვიხილავთ დაფარვას და იმას, თუ როგორ ცდილობენ ისინი დამალვას პოტენციური შემფასებლებისგან, თავის არიდების ტექნიკას აღმოჩენის თავიდან ასაცილებლად და როგორ ვითარდებიან ისინი ტელემეტრიისა და გვერდითი მოძრაობის გამოყენებით. გთხოვთ, დარჩით ჩვენთან!
ლიტერატურა
- Backstabber's Knife Collection: ღია კოდის პროგრამული უზრუნველყოფის მიწოდების ჯაჭვზე თავდასხმების მიმოხილვამ. ომი და სხვ., 2020 წლის მაისი.
- ღია კოდის მავნე პროგრამებისგან დაცვაXygeni-ს ოფიციალური დოკუმენტი.
- Software Supply Chain Security რეტროსპექტივა: უფრო უსაფრთხო 2024 წლის ჩამოყალიბებარეპორტაჟი Xygeni-დან.
