Atlassian-ის ხარვეზს უკვე იყენებენ — Cloud ვერსია მოქმედებას არ ითხოვს

Atlassian-ის CVE-2026-21589-ის გამოყენების მცდელობები 7 ოქტომბრიდან რეალურ ტრაფიკში ფიქსირდება: CrowdSec-ის ცოცხალი ტრეკერი პირველ შემთხვევას ამ დღით ათარიღებს და 13 ოქტომბრის აქტივობასაც აჩვენებს. საქმე თვითმართულ Data Center ინსტალაციებს ეხება. დაფიქსირებული მოთხოვნა ხარვეზის გამოყენების მცდელობას ნიშნავს, თუმცა თავისთავად ვერ ამტკიცებს, რომ თავდამსხმელმა ფაილი მიიღო.

Atlassian-ის 5 ოქტომბრის უსაფრთხოების ბიულეტენის მიხედვით, დაზიანებულია Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo და Crowd Data Center, ასევე Crucible და Fisheye; დაზიანებული Cloud პროდუქტები უკვე გასწორებულია, მათ მომხმარებლებს მოქმედება არ სჭირდებათ და Cloud გარემოში ექსპლუატაციის მტკიცებულება გამოძიებას არ უპოვია. დაზიანებული თვითმართული ინსტალაციები შესაბამის გამოსწორებულ ვერსიამდე უნდა განახლდეს. თუ ეს დაუყოვნებლივ ვერ ხერხდება, მათზე ინტერნეტიდან წვდომა დროებით უნდა შეიზღუდოს.

რომელი პროდუქტები და ვერსიებია გასაახლებელი

რისკს მხოლოდ პროდუქტის სახელი არ განსაზღვრავს: ადმინისტრატორმა დაყენებული ვერსია თავისი პროდუქტის გამოსწორებულ გამოშვებას უნდა შეადაროს. ქვემოთ ჩამოთვლილი რიცხვები სხვადასხვა გამოშვების ხაზისთვის განკუთვნილი პირველი გამოსწორებული ვერსიებია. თუ ორგანიზაციაში რამდენიმე Atlassian პროდუქტი მუშაობს, თითოეული ინსტალაცია ცალკე შესამოწმებელი და გასაახლებელია.

• Bitbucket Data Center — 9.4.26, 10.2.8 ან 10.5.1.
• Confluence Data Center — 9.2.26 ან 10.2.19.
• Jira Service Management Data Center — 5.12.40, 10.3.26 ან 11.3.12.
• Jira Software Data Center — 9.12.40, 10.3.26 ან 11.3.12.
• Bamboo Data Center — 10.2.24 ან 12.1.12.
• Crowd Data Center — 6.3.7, 7.0.3, 7.1.7 ან 7.2.4.
• Crucible — 4.9.15.
• Fisheye — 4.9.15.

გამოსწორება შესაბამისი ხაზის ჩამოთვლილ ვერსიაში ან უფრო ახალ გამოცემაშია; ერთი პროდუქტის ვერსიის ნომერი მეორისთვის მითითებად არ გამოდგება. Jira Software-სა და Jira Service Management-ს ზოგიერთ ხაზში ერთნაირი ნომრები აქვთ, მაგრამ ეს ცალკეული ინსტალაციების განახლების საჭიროებას არ ცვლის. საჯარო ქსელიდან ხელმისაწვდომი ძველი ვერსიის გადადება განსაკუთრებით სარისკოა: ფაილზე მოთხოვნის გასაგზავნად ანგარიშში შესვლა საჭირო არ არის. ვერსიის დადგენისას გასათვალისწინებელია თითოეული ცალკე გაშვებული კვანძიც, რათა კლასტერში ძველი გამოცემა არ დარჩეს.

რომელ ფაილამდე აღწევს მოთხოვნა

ხარვეზი ავტორიზაციის გარეშე ვებაპლიკაციის ძირეულ საქაღალდეში მდებარე კონკრეტული ფაილის წაკითხვის საშუალებას იძლევა. თავდამსხმელმა მისი ზუსტი სახელი და ბილიკი წინასწარ უნდა იცოდეს: საქაღალდის შიგთავსის ჩამოთვლა ამ გზით შეუძლებელია. შეზღუდვა რისკს არ აქრობს, რადგან აპლიკაციის სტანდარტული ფაილების სახელები შეიძლება ცნობილი იყოს. შესაძლო ზიანი დამოკიდებულია იმაზე, ინახება თუ არა კონკრეტულ ინსტალაციაში ამ არეში მგრძნობიარე კონფიგურაცია.

მოთხოვნა აპლიკაციის რესურსების ჩამოტვირთვის მისამართს იყენებს და ფაილის ბილიკს ისე ცვლის, რომ რესურსების საქაღალდიდან ვებაპლიკაციის სხვა ნაწილში გადავიდეს. შესაძლო სამიზნეებს შორისაა WEB-INF/web.xml და, კონფიგურაციის მიხედვით, WEB-INF/classes/crowd.properties. ამ უკანასკნელის მნიშვნელობა განსაკუთრებით იზრდება მაშინ, როცა Jira მომხმარებლების მართვისთვის Crowd-ს უკავშირდება: ფაილი შეიძლება ამ კავშირის პაროლს შეიცავდეს. ამიტომ ადმინისტრატორისთვის დასადგენია არა მხოლოდ პროგრამის ვერსია, არამედ ისიც, რომელი კონფიგურაციის ფაილებია მის ვებაპლიკაციაში განთავსებული.

CrowdSec-ის 12 ოქტომბრის ანალიზში აღწერილი watchTowr-ის დემონსტრაციით, Crowd-თან დაკავშირებულ Jira-ს სატესტო კონფიგურაციაში crowd.properties-ის პაროლმა ადმინისტრატორის ანგარიშის შექმნის გზა გახსნა. ეს კონკრეტული კონფიგურაციის დემონსტრირებული შედეგია და არა CrowdSec-ის მიერ დაფიქსირებული მოთხოვნების დადასტურებული შედეგი. იმავე ანალიზში 7–11 ოქტომბრის 6 657 შესაბამისი სიგნალია დათვლილი; მათგან 5 853 კეთილგანწყობილად კლასიფიცირებულ მისამართებს დაუკავშირდა, ძირითადად კვლევით სკანირებას. დარჩენილი 804 სიგნალი სხვა 43 მისამართიდან მოვიდა. ეს რიცხვები წარმატებულ შეღწევებს ან ცალკეულ თავდამსხმელებს არ ითვლის: ისინი CrowdSec-ის ქსელში ხარვეზის გამოყენების ნიმუშთან დამთხვევებს ასახავს.

რატომ განსხვავდება Cloud და Data Center მომხმარებლის გადაწყვეტილება

გადამწყვეტია, ვინ მართავს ინსტალაციას. ორგანიზაციას, რომელიც მხოლოდ Atlassian Cloud-ს იყენებს, ამ ხარვეზისთვის საკუთარი სერვისის დაპატჩვა არ სჭირდება: დაზიანებული Cloud პროდუქტების გამოსწორება უკვე განხორციელებულია. Cloud გარემოში ექსპლუატაციის მტკიცებულების არარსებობის შესახებ შეფასება სწორედ ამ მომსახურებას ეხება; ის ორგანიზაციის მიერ მართულ Data Center გარემოზე არ ვრცელდება.

Data Center-ის შემთხვევაში შესადარებელია დაყენებული ვერსია და შესაბამისი გამოსწორებული გამოშვება. თუ ვერსია ჯერ კიდევ დაზიანებულია, განახლება ხარვეზის აღმოფხვრის გზაა. მანამდე გარე ქსელიდან წვდომის შეზღუდვა საჯარო ინტერნეტიდან მოთხოვნის გაგზავნის შესაძლებლობას ამცირებს, თუმცა პროგრამულ სისუსტეს არ ასწორებს. მხოლოდ პაროლით დაცული შესასვლელი საკმარისი გამონაკლისი არ არის: აღწერილი ფაილის წაკითხვისთვის თავდამსხმელს ავტორიზაცია არ სჭირდება. შიდა ქსელიდან მისაწვდომი ინსტალაციისთვისაც ვერსიის შემოწმება საჭიროა, რადგან წვდომის შეზღუდვა განახლების შემცვლელი არ არის.

რა შეიძლება შეიზღუდოს განახლებამდე

თუ პატჩის დაუყოვნებლივ დაყენება ვერ ხერხდება, პირველი დროებითი ზომა დაზიანებული ინსტალაციის ინტერნეტიდან გამოტანა ან მასზე გარე ქსელიდან წვდომის შეზღუდვაა. როცა სრული იზოლაცია შეუძლებელია, ყველა დაზიანებული პროდუქტისთვის გათვალისწინებულია ვებაპლიკაციის ფაიერვოლის ან პროქსის წესი, რომელიც ფაილის ბილიკით მანიპულირების შესაბამის მოთხოვნებს ბლოკავს. წესმა უნდა ამოიცნოს ჩვეულებრივი და URL-კოდირებული ფორმები; მხოლოდ ფაიერვოლის ჩართვა კონკრეტული ნიმუშის დაბლოკვას არ ადასტურებს. შეზღუდვა დროებითია და განახლების დაგეგმვას არ აუქმებს.

პროდუქტის მიხედვით დამატებითი დროებითი წესები განსხვავდება. Confluence-ის, Jira Software-ის, Jira Service Management-ის, Bamboo-სა და Crowd-ისთვის გათვალისწინებულია Tomcat RewriteValve-ის კონფიგურაცია, რომელიც Data Center კლასტერის თითოეულ კვანძზე უნდა ამოქმედდეს. Bitbucket-ს ცალკე წესი აქვს urlrewrite.xml-ში; კლასტერში ის ყველა კვანძსა და სარკეზეც ვრცელდება. ამ ცვლილებების წინ საჭიროა კონფიგურაციის სარეზერვო ასლი და კვანძის ხელახლა გაშვება. Crucible-სა და Fisheye-სთვის იგივე RewriteValve ან Bitbucket-ის წესი მითითებული არ არის; მათთვის საერთო ფაიერვოლის წესი და გარე წვდომის შეზღუდვა რჩება.

საჯაროდ ხელმისაწვდომი ინსტალაციის განახლების შემდეგ წვდომის ჟურნალებში ადრინდელი საეჭვო მოთხოვნებიც შესამოწმებელია. საძიებელია ფაილის ბილიკის შეცვლის ნიშნები როგორც გაშიფრულ მოთხოვნებში, ისე ნედლ ჩანაწერებში, რადგან კოდირებულმა ფორმამ ჩვეულებრივ ძებნას შეიძლება თავი აარიდოს. პატჩი ახალ მოთხოვნას აჩერებს, მაგრამ ვერ აჩვენებს, რა მოხდა მის დაყენებამდე. თუ ჟურნალი საეჭვო წვდომას აჩვენებს, გამოსაკვლევი საკითხი უკვე შესაძლო წაკითხული ფაილის შიგთავსი და მასში არსებული საიდუმლო მონაცემებია.

ასევე წაიკითხეთ:

• Cisco SD-WAN-ის ხარვეზს უკვე იყენებენ — დროებითი დაცვა საკმარისი არაა
• CData-ს AI Gateway აგენტის მოქმედებას ჩანაწერის დონეზე აკონტროლებს
• NetScaler-ის ორი კრიტიკული ხარვეზი უკვე გამოიყენეს — განახლება საკმარისი არაა