SSH-ის უკანა ღილაკები
ბოროტმოქმედმა ან კომპრომეტირებულმა მომვლელმა ჩასვა მავნე ქცევა სახელწოდების ბიბლიოთეკაში ლიბლზმა, xz შეკუმშვის ხელსაწყოებისა და ბიბლიოთეკების ნაწილი, რამაც გამოიწვია SSH-ში უკანა კარი. ეს არის მოწინავე პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის შეტევა, რადგან ბიბლიოთეკა განზრახ იყო მოდიფიცირებული უკანა კარიბჭისთვის, შეტევის დატვირთვის მიმომხილველებისგან დასამალად დაბინდვისა და ფარული ტექნიკის გამოყენებით.
ის ახლახან აღმოაჩინეს და გაამჟღავნეს (29 მარტს) და შეტევის მართვა კვლავ გრძელდება. თუმცა, ის სწრაფად იქნა შეჩერებული, რადგან, როგორც ჩანს, ის გავლენას ახდენს მხოლოდ შეზღუდული რაოდენობის გარემოს წინასწარ გამოშვებულ ვერსიებზე (DEB და RPM პაკეტები, x86_64 არქიტექტურისთვის და GCC-ით აგებული). ყოველ შემთხვევაში, CVE მიეცა CVSS-ის საბაზისო ქულა 10-დან, რომელიც კიბერუსაფრთხოების ყველაზე კრიტიკული დაუცველობებისთვისაა განკუთვნილი. თუ ის სტაბილურ დისტრიბუციებში მოხვდება, ზემოქმედება უზარმაზარი იქნება.
თავდასხმის ტექნიკური ანალიზი, მათ შორის xz უკანა კარი დეტალურად არის ახსნილი, სხვაგან იყო გაანალიზებული. ეს პოსტი ფოკუსირებული იქნება თავდასხმის ქრონოლოგიაზე, იმაზე, თუ როგორ შეიძლებოდა მისი გამოვლენა, როგორ იქნა ინციდენტი მოგვარებული დღემდე და რა გაკვეთილების გამოტანა შეიძლება თავდასხმიდან.
უკანა კარის გრძელი კუდი თავდაპირველი პატჩის შემდეგაც გაგრძელდა. 2025 წლის აგვისტოში, CVE-2024-3094-ის გამჟღავნებიდან ერთ წელზე მეტი ხნის შემდეგ, Binarly-ის უსაფრთხოების მკვლევარებმა აღმოაჩინეს, რომ უკანა კარი კვლავ არსებობდა Docker Hub-ზე გამოქვეყნებულ ათეულ Debian Docker-ის სურათში, თუმცა Debian-ის გუნდმა უარი თქვა მათ წაშლაზე და მათ ისტორიული განვითარების არტეფაქტებად მიიჩნია და არა აქტიურ რისკად. ცალკე, OpenSSF და OpenJS-მა XZ ინციდენტიდან მალევე გამოაქვეყნეს ერთობლივი გაფრთხილება, რომ სოციალური ინჟინერიის მსგავსი მცდელობები უკვე მიმართული იყო JavaScript პროექტებისკენ, რაც იმაზე მიუთითებს, რომ აქ გამოყენებული შემნახველი-ნდობის შეტევის ნიმუში სხვაგანაც გამოიყენება.
როგორ იქნა შეყვანილი XZ-ის უკანა კარი
შენიშვნა: git საცავი მდებარეობს git.tukaani.org. თუმცა, ასევე იყო GitHub-ის მიერ ჰოსტირებული საცავი (ამჟამად დაბლოკილია), სადაც GitHub ანგარიში აქვეყნებდა ცვლილებებს, რომლებიც მოგვიანებით ინტეგრირებული იქნა Git საცავში.
როგორც ჩანს, უკანა კარის ერთი ნაწილი მხოლოდ 5.6.0 და 5.6.1 ვერსიების განაწილებულ tarball ფაილებშია და არა git რეპოზიტორიებში და ეყრდნობა a-ს. ერთი ხაზი build-to-host.m4 ფაილში მაკრო ფაილი, რომელიც გამოიყენება autoconf-ის მიერ. მეორე ნაწილი ორ სავარაუდო ტესტფაილში იყო. bad-3-corrupt_lzma2.xz მდე good-large_compressed.lzma
ეს იყო commitტედ GitHub ანგარიშის „Jia Tan“-ის მიერ (JiaT75) xz საცავი 23 თებერვალს. ეს იყო უწყინარი ცვლილება, რომელიც ტესტფაილებს (სავარაუდოდ, .lzma და .xz შეკუმშულ ბლოკებს) ამატებდა. საინტერესოა, რომ ტესტების მიერ ტესტის ფაილები არ გამოიყენებოდა! .m4 ფაილში მოცემული ხაზი შეჰყავს დაბინდულ სკრიპტს (შედის tarball-ში), რომელიც უნდა შესრულდეს კონფიგურაციის ბოლოს, თუ გარკვეული პირობები ემთხვევა. ის ცვლის Makefile-ს ლიბლზმა ბიბლიოთეკა, რომელიც შეიცავს კოდს, რომელიც იღებს მონაცემებს .xz ფაილიდან, რომელიც დებფუსკაციის დასრულების შემდეგ ამ სკრიპტში, გამოიძახება კონფიგურაციის ბოლოს. ის წყვეტს, შეცვალოს თუ არა აწყობის პროცესი კოდის ინექციისთვის: მხოლოდ GCC-სა და GCC ლინკერის ქვეშ, Debian-ის ან rpm-ის ქვეშ და მხოლოდ x86_64 Linux-ისთვის. შესაბამისობის შემთხვევაში, ინექცირებული კოდი წყვეტს შესრულებას ორი იფუნკი რეზოლვერები, რათა გარკვეული გამოძახებები ჩანაცვლდეს. ეს იწვევს სიმბოლოების ცხრილების მეხსიერებაში დამუშავებას (ამას დრო სჭირდება, რამაც გამოიწვია აღმოჩენა, როგორც მოგვიანებით აიხსნება).
შემდეგ ყველაფერი საინტერესო ხდება: უკანა კარი დინამიურ ლინკერში აინსტალირებს აუდიტის კაუჭს და ელოდება RSA_public_decrypt ფუნქციის სიმბოლოს მოსვლას, რომელიც გადამისამართდება უკანა კარიბჭის კოდის წერტილში, რომელიც თავის მხრივ უკან იძახებს. libcrypto, სავარაუდოდ, ნორმალური ავტორიზაციის შესასრულებლად. და დატვირთვა აქტიურდება, თუ გაშვებულ პროგრამას აქვს პროცესის სახელი /usr/sbin/sshd. აშკარა იყო, რომ სამიზნე SSH სერვერები იყო. ტრადიციულად, სშდ OpenSSH-ის მსგავსი სერვერები არ იყო დაკავშირებული ლიბლზმა, მაგრამ sshd არის ხშირად შელესილი systemd-notify-ის მხარდასაჭერად, რათა სხვა სერვისებმა შეძლონ sshd-ის გაშვებისას ჩართვა. შემდეგ კი liblzma ირიბად იტვირთება systemd, წრის დახურვა.
უკანა კარი ჯერ სრულად არ არის გაანალიზებული, მაგრამ, როგორც ჩანს, დისტანციური ბრძანების შესრულების დაშვება (RCE) sshd დემონის პრივილეგიებით, რომელიც წინასწარი ავტორიზაციის კონტექსტში მუშაობს. დისტანციური სერტიფიკატიდან მიღებული ინფორმაცია, როდესაც ის უკანა კართან ემთხვევა, გაშიფრულია ChaCha20-ით და წარმატებით გაშიფვრის შემდეგ, ის გადაეცემა სისტემა()ასე რომ, ეს არსებითად დახურული RCE-ა, გაცილებით უარესი, ვიდრე უბრალოდ საჯარო გასაღების გვერდის ავლა.
უფრო გვიანდელ 5.6.1 tarball-ში დამატებითი ძალისხმევა იყო საჭირო კვალის დასამალად, სიმბოლოების სახელწოდებებისთვის დამატებითი დაბინდვის დამატებით და ნანახი შეცდომების გამოსწორების მცდელობით. გაფართოების მექანიზმი სადაც დამატებითი სატესტო ფაილები მოიძებნა გარკვეული ხელმოწერებისთვის, რომლებიც უკანა კარში უნდა დაემატებინათ, ასევე დამონტაჟდა.
ეს საკმაოდ დახვეწილი შეტევა შეიძლება შეუმჩნეველი დარჩეს სტაბილურ Linux დისტრიბუციებამდე. საბედნიეროდ, ზოგიერთ ადამიანს მოსწონს იმის შემოწმება, თუ რატომ ხდება უჩვეულო რამ.
XZ Backdoor შეტევის აღმოჩენა
ბევრჯერ ინექციური მავნე ქცევა შემთხვევით ან შემთხვევით ვლინდება. კარგი მაგალითი იყო მოძველების გაფრთხილება („ვის აინტერესებს გაფრთხილებები?“), რამაც გამოიწვია აღმოჩენა მოვლენების ნაკადის შეტევა 2018 წლის ოქტომბერში. კიდევ ერთი მომხმარებელია, რომელმაც გააფრთხილა Codecov 2021 წლის აპრილში განაცხადეს, რომ მათ bash ატვირთვის სკრიპტმა ვერ გაიარა ჩეკსუმი („ვინ ამოწმებს არტეფაქტების მთლიანობას ჩეკსუმებით“?) ssh-ის ანომალიები და უცნაური სიმპტომები logins (loginCPU-ს დიდი დატვირთვა და გაზრდილი დროის ხარჯვა, valgrind შეცდომები) ცნობისმოყვარეობა გააღვივა ანდრეს ფროუნდი, ფხიზელი PostgreSQL დეველოპერი, მაგრამ არა უსაფრთხოების ანალიტიკოსი (როგორც მან განაცხადა)). Debian Sid-ზე OpenSSH-ით გარკვეული გამოძიების შემდეგ, მან დაასკვნა, რომ რეაგირების დროის პრობლემა ბიბლიოთეკაზე იყო დამოკიდებული, ლიბლზმანაწილი xz-utils შეკუმშვის ბიბლიოთეკა. მიზეზი: „ზედა ნაკადის xz რეპოზიტორი და xz tarball-ები დახურულია.„ეს დიაგნოსტიკა ძალიან ზუსტი იყო!“ 2024 წლის 29 მარტს ანდრესმა Openwall-ში პირველი ანალიზი გამოაქვეყნა: „xz/liblzma-ს ზემოთ მდებარე უკანა კარი, რაც ssh სერვერის დაზიანებას იწვევს.ფაქტი: XZ Utils 5.6.0 და 5.6.1 tarball-ები შეიცავს უკანა კარს. ეს tarball-ები შეიქმნა და ხელმოწერილი იქნა ზემოხსენებული Jia Tan ანგარიშის მიერ. He გამოქვეყნებულია Mastodon-ში იმავე დღეს, მოგვიანებით, გააცნობიერა, რომ აღმოჩენა შემთხვევითი იყო და ბევრი დამთხვევა მოითხოვა. სხვა მომხმარებლების კომენტარების წაკითხვა ღირს. GitHub-ის მომხმარებელი იგივე (ასევე ცნობილი როგორც სემ ჯეიმსი) გამოაქვეყნა კარგი შინაარსი ხშირად დასმული კითხვები xz-utils-ის უკანა კარის შესახებ სადაც თავდასხმა შეჯამებული იყო, დამატებით ბმულებთან სიღრმისეული ანალიზები შეტევითი დატვირთვისა. ეს ანალიზები ტექნიკურად საკმაოდ დახვეწილი იყო და დაგვეხმარა ინექციის უკეთ გაგებაში, რომელიც ძალიან დეტალურად იყო აღწერილი:- xz/liblzma: Bash-ეტაპის დაბჟენა ახსნილიაკარგი ანალიზია ინექციის სკრიპტით დეობსუქციის შესახებ, ოთხ „ეტაპად“.
- ფილიპო ვალსორდას ლურჯი ცის თემა RSA_public_decrypt-ში თავად უკანა კარის ანალიზი, რომელიც მის ბუნებას აჩვენებს: RCE, არა ავტორიზაციის გვერდის ავლითი და კარიბჭით დაცული (მიიღებს ავტორის პირად გასაღებს და თუ არა, უბრუნდება ნორმალურ ქცევას) / ანაზღაურების გარეშე. ავტორს განზრახული ჰქონდა დახურულიყო, რათა თავიდან აეცილებინა გამოვლენის თავიდან აცილება!
- XZ Backdoor ანალიზი @smx-smx-ის მიერ (WIP) – დამატებითი ანალიზი უკანა კარის შესახებ (თითქმის თავიდანვე დავიკარგე 😀)
- xz უკანა კარის დოკუმენტაციის ვიკი, 5.6.1 ინექციის სკრიპტის კიდევ ერთი ანალიზი.
როგორ მოხდა ინციდენტის მოგვარება
ანდრეას ფროინდის მიერ გამჟღავნება ფრთხილი იყო, რადგან, მისივე სიტყვებით:„აშკარა ზემოდან სტრიმის ჩართულობის გათვალისწინებით, მე არ შემიტყობინებია ზემოდან სტრიმის შეცდომის შესახებ. რადგან თავდაპირველად ვიფიქრე, რომ ეს Debian-ის სპეციფიკური პრობლემა იყო, უფრო წინასწარი ანგარიში გავგზავნე security@...ian.org-ზე. შემდგომში, პრობლემის შესახებ ვაცნობე distros@-ს.“ CISA-ს დისტრიბუციამ შეატყობინა.“
ვინ არის თავდასხმის ქვეშ?
ან GitHub JiaT75 ანგარიში იყო კომპრომეტირებული (გახსოვდეთ, რომ GitHub-მა ცოტა ხნის წინ დააწესა 2FA), ან ანგარიშის მფლობელი ფიზიკური მომხმარებელი ბნელ მხარეს გადავიდა. თუმცა, არსებობს დამაჯერებელი მიზეზები, რომ ვიფიქროთ მოწინავე მუდმივ საფრთხეზე (APT), შესაძლოა სახელმწიფოს მიერ მხარდაჭერილზე, შეტევის ტექნიკური დახვეწილობის გამო. კიბერუსაფრთხოების სააგენტოებისა და სამართალდამცავი ორგანოების მიერ შემდგომი გამოძიება გვიჩვენებს... ეს ჩანაწერი YCombinator Hacker News-ში ჯია ტანის შესახებ გარკვეულ ნათელს ჰფენს „ვინ“-ს და მის აქტივობას. რეკომენდებულია! ის უამრავ ინფორმაციას გვაწვდის იმის შესახებ, თუ როგორ ცდილობენ ბოროტმოქმედები სხვა მომხმარებლების მოტყუებას სოციალური ინჟინერიის გამოყენებით.„ძალიან შემაწუხებელია - backdoor-ის სავარაუდო ავტორი რამდენიმე კვირის განმავლობაში ჩემთან (rwmj) კომუნიკაციაში იყო და ცდილობდა xz 5.6.x-ის Fedora 40-სა და 41-ში დამატებას მისი „შესანიშნავი ახალი ფუნქციების“ გამო. ჩვენ მასთან ერთად ვიმუშავეთ valgrind-ის პრობლემის გამოსასწორებლად (რომელიც, როგორც აღმოჩნდა, მის მიერ დამატებული backdoor-ის შედეგი იყო). გუშინ ღამით პრობლემის გამოსასწორებლად ჩქარი ნაბიჯი მოგვიწია ემბარგოს შემთხვევითი დარღვევის შემდეგ. ის xz პროექტის ნაწილია 2 წელია, რაც ყველანაირ ბინარულ სატესტო ფაილს ამატებს და სიმართლე გითხრათ, ამ დონის დახვეწილობის გამო, მე ეჭვის თვალით ვუყურებ xz-ის ძველ ვერსიებსაც კი, სანამ საპირისპირო არ დამტკიცდება.“
ჯია ტანმა ზომები მიიღო თვალთვალის თავიდან ასაცილებლად: როგორც ჩანს, დასაკავშირებლად VPN (vpn.singapore.witopia.net) გამოიყენა - რაც თავისთავად ნორმალურია. და როგორც ჩანს, ბევრ ცვლილებას დროებითი, ერთჯერადი ელფოსტით (ამ შემთხვევაში ProtonMail-ისგან) ადასტურებს, რომელიც ცვლილებების გაერთიანებისკენ მოუწოდებს.
შესაძლოა, მსახიობს სურდეს კიდევ უფრო ღრმად ჩაუღრმავდეს Linux-ის ბირთვს, როგორც ამ პროცესის კონტრიბუტორს. xy-ჩაშენებული პროექტი. საწყისმა ანალიზმა დღეის მდგომარეობით, მუცლის მოშლის ნიშნები არ აჩვენა.
შენიშვნა: კიდევ ერთი დაბალი პროფილის XZ კონტრიბუტორი „ჰანს იანსენი“ (GitHub-ის მომხმარებელი „hansjans162“) არის დაკვირვების ქვეშმისი ანგარიში debian-ზე ახლა არის ბლოკირებულიმან Debian Games-ში მრავალი განახლება შეიტანა, რათა debian/xz-utils-ზე ის ვერსია დაემალა, რომელიც მას სურდა, განახლება upstream 5.6.1-ზე, რათა დაეჩქარებინა უკანა კარის გავრცელება. debian/არასტაბილური.
ჯერჯერობით მხოლოდ იმის თქმა შეგვიძლია, რომ ეს არის (ჯერჯერობით დაუდგენელი) APT, რომელიც სხვადასხვა ანგარიშებს იყენებს, ამ კამპანიაზე სულ მცირე ორი წელია მუშაობს და მოთმინებით მუშაობს SSH-ში RCE-ის იმპლანტაციაზე.
ამ წერის მომენტისთვის, „ჯია ტანის“ ვინაობა დაუდასტურებელი რჩება. საჯაროდ არ დადასტურებულა კონკრეტული პირის, ორგანიზაციის ან სახელმწიფო მოქმედი პირის სანდო მიკუთვნება, რაც კიდევ ერთხელ ადასტურებს, თუ რამდენად ეფექტური იყო პერსონას ოპერატიული დისციპლინა.
შესაძლებელი იყო XZ-ის უკანა შეტევის თავიდან აცილება?
საკმაოდ რთული.
პირველ რიგში, ინექციური უკანა კარის ნაწილი შეკუმშულ სატესტო ფაილებში მოხვდა, რომლებიც ტესტების მიერ არ გამოიყენებოდა. რეტროსპექტულად, ამან შეიძლება გამოიწვიოს გარკვეული (ხმაურიანი) განგაში, მაგრამ ვის აინტერესებს იმის შემოწმება, გამოიყენება თუ არა ყველა სატესტო ფაილი რეალურ სამყაროში რეალური ტესტების მიერ? მეორეც, ინექციური უკანა კარის ნაწილი მაკრო ფაილებში მოხვდა გამოშვების tarball ფაილებში და რთულია ხელით შეამოწმოთ განსხვავებები მოსალოდნელ tarball ფაილებთან. ავტომატიზაცია ასევე რთულია, რადგან თავად აწყობიდან მოსალოდნელი შედეგის (ყველასთვის, ვინც იცის, როგორ მუშაობს automake/autoconf) მოდელირება რთულია იმის გასაანალიზებლად, შეესაბამება თუ არა რეალური tarball მოლოდინებს. ზოგიერთმა ეს წარმოადგინა as „git ხიდან tarball-ების შეუსაბამობა ფუნქციაა და არა შეცდომა“ბინარული tarball ფაილების წყაროდან წარმოშობა გადაუჭრელი პრობლემაა.
მომხმარებლის რეპუტაცია? წარსულში არსებული ცნობების თანახმად, JiaTan75 GitHub ანგარიში არასწორ ქმედებებს არ ახორციელებდა. commitს. ის მხოლოდ მტკიცებულებების დაგროვების შემდეგ შეჩერდა, თუმცა 29 მარტამდე ის ჩვეულებრივი მომხმარებელი იყო, რომელიც ჩვეულებრივ საქმიანობას ეწეოდა. უფრო სწორად, არც ისე ჩვეულებრივად. მოგვიანებით. commits (ამ, ამ, ამდა ამ რომელმაც შეცვალა ექსპლოიტის კოდი) ცდილობდა გამოესწორებინა valgrind-ის შეცდომები და ზოგიერთ კონფიგურაციაში ავარიები, რაც გამოწვეული იყო backdoor-ის მიერ მოსალოდნელ სტეკის განლაგებასთან განსხვავებებით. Commit მიმოხილვებმა შეიძლება ამის აღმოჩენა შეძლონ, მაგრამ ვის აქვს მოთმინება, გააანალიზოს ცვლილებები ორობითი სატესტო ფაილში ან რეალური მოტივაცია C კოდის GCC ატრიბუტების ცვლილებისთვის?
უნდა გავააქტიურო თუ არა განგაში SSH-ის დროს? login 300 მილის ნაცვლად 800 მილისწლიწადს მოითხოვს? ალბათ მხოლოდ ზედმეტად წინდახედული ადამიანები მიაქცევდნენ ყურადღებას. ციცერონმა თქვა, „სიგიჟე ახალგაზრდობას ეკუთვნის, წინდახედულობა კი - სიბერეს.“
ifunc-ის ინფრასტრუქტურა 2023 წლის ივნისში „ჰანს იანსენმა“ და „ჯია ტანმა“ დაამატეს. ეს პირველია. commit crc64_fast.c-სთვის (მოგვიანებით გამოყენებული backdoor-ის ინექციისთვის) ifunc მხარდაჭერის დამატება. backdoor-ის ბინარული ფაილების სატესტო ფაილებში ინექციამდე რამდენიმე თვით ადრე!
შენიშვნა: ავტორი და commitაქ განსხვავება შეიძლება იყოს, მაგრამ ეს ნორმალურია: ლასე კოლინი პროექტის მმართველია და მან გააერთიანა ცვლილებები. მან მადლობაც კი გადაუხადა „ჰანს იანსენს“...
ანდრეს ფროინდის პოსტამდე და RedHat-ის მიერ შექმნილ CVE-მდე არავის გამოუთქვამს შეშფოთება. თუ ხედავთ ინსტრუმენტების კასკადს, რომლებიც ამას დააფიქსირებენ, ისინი ახლავე აფიქსირებენ დაზარალებულ კომპონენტს. ex post facto.
სავარაუდოდ, საუკეთესო პრევენცია Linux-ის დისტრიბუციების ბუნებიდან მომდინარეობს და იმით, რომ არასტაბილური, მოწინავე ვერსიები სტაბილურ დისტრიბუციებზე მხოლოდ ტემპური პროცესის შემდეგ გადადის.
XZ bBackdoor შეტევიდან მიღებული გაკვეთილები
ჩვენ აღვნიშნეთ, რამდენად რთულია მისი აღმოჩენა განზრახ უკანა კარები. უკანა კარები შიდა საფრთხედ უნდა ჩაითვალოს, რადგან მათ შიდა პერსონალი ან კომპრომეტირებული შიდა ანგარიშების მეშვეობით ამონტაჟებს. და ეს ადამიანები ძირითადად სანდოები არიან. და როდესაც უკანა კარი განაწილებულ არტეფაქტშია ჩანერგილი, მისი აღმოჩენა უფრო რთულია.
ზოგიერთი ავტორი, მაგალითად კევინ ბომონტი მიუთითა სისტემა, რაც მესამე მხარის სერვისების დიდ შეტევის ზედაპირს უკანა კარისთვის ხსნის. სწორედ ეს გამოიყენა ბოროტმოქმედმა აქ ბოროტად. Systemd-ს ბევრი თვალი აქვს, მაგრამ XZ არის ბუნდოვანი ბიბლიოთეკა ჯაჭვის ზემოთ. „როდესაც ზემო დინება დაბინძურებულია, ყველა სვამს მოწამლულ წყალს ქვემოთ“.
სისტემაში დაუკავშირებელი ცვლილების მოთხოვნა დინამიურად იტვირთება შეკუმშვის ბიბლიოთეკები, რომელიც უკანა კარს მოხსნიდა, უკვე გაერთიანებული იყო სისტემაში, მაგრამ ჯერ არ იყო მიწოდებული. libsystemd-ის მიერ შემოღებული დამატებითი დამოკიდებულებები შესაძლოა დაუცველობის წყარო იყოს., და გუშინ ეს მოთხოვნა გაიხსნა.
A კომენტარის „xz: გამორთეთ ifunc პრობლემის გამოსასწორებლად“-ში commit მომცა მკაფიო წარმოდგენა იმის შესახებ, თუ სად უნდა გავამახვილოთ ყურადღება, თუ გვსურს ასეთი აქტივობის პრევენცია (ხაზგასმა ჩემია):
„გაკვეთილი, რომელიც საზოგადოებამ უნდა ვისწავლოთ, უფრო მეტად უსაფრთხოების უზრუნველყოფაა“ software supply chain security ჰოლისტურად, აუდიტი ახორციელებდა სისტემების შექმნას, რომლებიც მხოლოდ საწყისი კოდის მიღმაა. მაგალითად, SolarWinds-ის შეღწევის შემთხვევაში, როდესაც თავდამსხმელებმა შეცვალეს SolarWinds-ის დახურული კოდის მონიტორინგის პროგრამული უზრუნველყოფის განახლებები.
კითხვა-პასუხი
XZ-ის უკანა კარი დღესაც საფრთხეს წარმოადგენს?
ძირითადად შეკავებულია, მაგრამ სრულად არ გამქრალია. 2025 წლის აგვისტოში მკვლევრებმა აღმოაჩინეს, რომ უკანა კარი კვლავ არსებობდა Debian Docker Hub-ის რამდენიმე სურათში, რომლებსაც Debian უმოქმედო ისტორიულ არტეფაქტებად მიიჩნევდა. გუნდებმა უნდა დაადასტურონ, რომ ისინი არ იყენებენ მოძველებულ, დაუპატჩებელ საბაზისო სურათებს და არ უნდა ჩათვალონ, რომ 2024 წლის პატჩმა მთლიანად დახურა კარი.
