Zimbra-ს ხარვეზს ერთი წერილიც ააქტიურებს — პატჩი კვალს არ შლის

2026 წლის 30 სექტემბერს Microsoft-ის ტექნიკურმა ანგარიშმა აღწერა Zimbra Collaboration Suite-ის ხარვეზის, CVE-2026-73570-ის, გამოყენებით დაფიქსირებული შეტევების ჯაჭვი. ინტერნეტიდან ხელმისაწვდომ სერვერზე სპეციალურად შედგენილმა წერილმა შეიძლება ბრძანების შესრულება გამოიწვიოს ავტორიზაციისა და მომხმარებლის მოქმედების გარეშე. ამისთვის სერვერზე დაყენებული უნდა იყოს არასავალდებულო zimbra-snmp პაკეტი და ჩართული უნდა იყოს SNMP შეტყობინებები.

ანგარიშში აღწერილი შეღწევების შემდეგ თავდამსხმელებმა განათავსეს ვებგარსები, მოიპოვეს უფრო მაღალი უფლებები და შექმნეს დისტანციური წვდომის სხვა გზები. ITPro-ს 26 აგვისტოს გაშუქებით, Shadowserver-ს უკვე აღრიცხული ჰქონდა სულ მცირე 274 კომპრომეტირებული, ინტერნეტიდან ხელმისაწვდომი ინსტანცია, მაშინ როცა გამოსწორება 20 ივლისს გამოშვებულ ZCS 10.1.20-ში იყო შეტანილი. ეს გლობალური მონაცემია და საქართველოში დაზიანებული სერვერების რაოდენობას არ ადგენს. ადგილობრივი ორგანიზაციისთვის მთავარი საკითხია, მუშაობდა თუ არა მისი სერვერი დაუცველი კონფიგურაციით და რა მოხდა მასზე განახლებამდე.

როგორ შეიძლება წერილმა სერვერზე ბრძანება შეასრულოს

შეტევის საწყისი წერტილი SMTP მოთხოვნაა. სპეციალურად შედგენილი მონაცემი ხვდება Zimbra-ს SNMP შეტყობინებების დამუშავების გზაზე; სერვისის მდგომარეობის ცვლილებისას მონიტორინგის კომპონენტი მას snmptrap ბრძანების გამოძახებაში იყენებს. არასაკმარისად დამუშავებულ მონაცემში ჩასმული shell ბრძანება შეიძლება zimbra სერვისული ანგარიშის უფლებებით შესრულდეს. სწორედ ამიტომ საფოსტო ყუთში წერილის გახსნა, ბმულზე გადასვლა ან დანართის ჩამოტვირთვა შეტევის წინაპირობა არ არის.

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

რა დატოვეს თავდამსხმელებმა საწყისი შეღწევის შემდეგ

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

აღწერილ ჯაჭვში ასევე ჩანდა უკუმიმართული ინტერაქტიული კავშირები, ფონური პროცესები და გაშვებისას ამოქმედებული მექანიზმები. ერთ სერვერზე თავდამსხმელმა zimbra ანგარიშიდან root უფლებებამდე მიაღწია, შემდეგ კი სისტემურ სერვისად zimlog.service დაამატა. სერვისის სახელი Zimbra-ს ლოგირების კომპონენტს ჰგავს; მისი მდებარეობა, მფლობელი, ჩართვის ისტორია და შესრულებული ბრძანებები უფრო მეტს ამბობს, ვიდრე მხოლოდ დასახელება. სხვა შემთხვევებში წვდომის შესანარჩუნებლად გამოიყენებოდა დაგეგმილი ამოცანები, SSH გასაღებები ან რამდენიმე ვებგარსი სხვადასხვა საფოსტო კვანძზე.

საფოსტო მონაცემებთან ერთად სამიზნე იყო სერვისული პაროლები და ავთენტიფიკაციის გასაღებები, მათ შორის zimbraPreAuthKey და zimbraAuthTokenKey. ასეთი მონაცემები მნიშვნელოვანია, რადგან მათი მოპოვების შემდეგ თავდამსხმელის წვდომა საწყის ხარვეზზე დამოკიდებული აღარ უნდა დარჩეს. ერთ სერვერზე მომზადდა საფოსტო სარეზერვო მონაცემების არქივი და ამოქმედდა მისი ღრუბლოვან საცავში გადატანის ინსტრუმენტი. Ars Technica-ს 30 სექტემბრის გაშუქება აღნიშნავს, რომ გადაცემის წარმატებით დასრულება ხელმისაწვდომი მტკიცებულებით ვერ დადასტურდა. არქივის შექმნა და მონაცემების დადასტურებული გატანა ინციდენტის განსხვავებული შედეგებია.

რომელ სერვერზე უნდა დაიწყოს კვალის ძიება

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

1. შეინახეთ ხელმისაწვდომი სისტემური, საფოსტო და ქსელური ლოგები, სანამ ისინი ჩანაცვლდება. SNMP დამუშავების შემდეგ მოძებნეთ უჩვეულო shell პროცესები, wget ან curl გამოძახებები, უცნობ მისამართებზე გამავალი კავშირები და ისეთი snmptrap ბრძანებები, რომელთა არგუმენტებშიც shell-ის სპეციალური სიმბოლოები ჩნდება.
2. გადაამოწმეთ Zimbra-ს ვებაპლიკაციისა და დროებითი servlet საქაღალდეები უცნობი JSP ფაილებისა და მათი წარმოქმნილი არტეფაქტებისთვის. შეადარეთ ფაილების შექმნისა და შეცვლის დრო ლოგებს; საქაღალდის ამჟამინდელ უფლებებზე დაყრდნობა საკმარისი არ არის.
3. შეამოწმეთ სისტემური სერვისები, დაგეგმილი ამოცანები, SSH გასაღებები და პრივილეგირებული წვდომის წესები. თუ Zimbra კლასტერში რამდენიმე საფოსტო კვანძია, ძიება მათზეც გავრცელდეს: აღწერილ შეტევებში ფაილები თავდაპირველად დაზიანებული სერვერიდან სხვა კვანძებზეც გადაიტანეს.

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

რატომ არ სრულდება რეაგირება განახლებით

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

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

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

• NetScaler-ის ორი კრიტიკული ხარვეზი უკვე გამოიყენეს — განახლება საკმარისი არაა