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

|ავტორი: QUASA-ს სარედაქციო გუნდი|4 წთ საკითხავი| 1
NetScaler-ის ორი კრიტიკული ხარვეზი უკვე გამოიყენეს — განახლება საკმარისი არაა

Citrix-მა 2026 წლის 27 სექტემბერს NetScaler-ის უსაფრთხოების ბიულეტენში დაადასტურა, რომ დაუცველ სისტემებზე უკვე გამოიყენეს ორი კრიტიკული ხარვეზი — CVE-2026-88771 და CVE-2026-88772. ისინი ეხება თვითმართვად NetScaler ADC-სა და NetScaler Gateway-ს. პირველი ხარვეზი არაავთენტიფიცირებულ თავდამსხმელს ბრძანებების შესრულების საშუალებას აძლევს, მეორე კი DTLS-ის ჩართვის შემთხვევაში შეიძლება კოდის შესრულება ან მომსახურების შეფერხება გამოიწვიოს.

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

რომელ ინსტანციას სჭირდება რომელი რელიზი

პირველი გამყოფი ხაზი მართვის პასუხისმგებლობაა: პრობლემა ეხება მომხმარებლის მიერ მართულ NetScaler ADC-სა და Gateway-ს, მათ შორის Secure Private Access Hybrid-ის განთავსებას, თუ ის NetScaler-ის ინსტანციას იყენებს. Citrix-ის მიერ მართულ ღრუბლოვან სერვისებსა და Adaptive Authentication-ს საჭირო პროგრამულ განახლებას პროვაიდერი თავად აწვდის. Hybrid-ის სახელწოდებამ შეცდომაში არ უნდა შეიყვანოს გუნდი: მასში გამოყენებული თვითმართვადი NetScaler ცალკე უნდა განახლდეს.

მეორე ნაბიჯია პროდუქტის შტოსა და დაყენებული ბილდის დადგენა. ჩვეულებრივი NetScaler ADC-სა და Gateway-სთვის 14.1 შტოში დაზიანებულია 14.1-73.37-მდე ვერსიები, ხოლო 13.1 შტოში — 13.1-64.23-მდე. უსაფრთხო საწყისი ბილდებია, შესაბამისად, 14.1-73.37 და 13.1-64.23; იმავე შტოების უფრო ახალი გამოსწორებული ბილდებიც გამოდგება. შედარება თითოეულ მოწყობილობაზე უნდა შესრულდეს და არა მხოლოდ საერთო სერვისის ან მაღალი ხელმისაწვდომობის წყვილის სახელით.

FIPS და NDcPP გამოშვებებს საკუთარი ზღვარი აქვთ. NetScaler ADC 14.1-FIPS-ს სჭირდება 14.1-73.37 FIPS ან უფრო ახალი შესაბამისი ბილდი; ADC 13.1-FIPS-სა და 13.1-NDcPP-ს — 13.1-37.279 ან უფრო ახალი შესაბამისი ბილდი. ჩვეულებრივი 13.1-ის ზღვარი FIPS/NDcPP შტოსთვის არ გამოიყენება: ერთსა და იმავე მთავარ ნომერზე სხვადასხვა უსაფრთხო ბილდის არჩევა შეიძლება შეცდომა იყოს. თუ ინსტანციის შტო გაურკვეველია, განახლების პაკეტის შერჩევამდე მისი ზუსტი გამოშვება და კონფიგურაცია უნდა დადგინდეს.

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

DTLS-ის შემოწმება რისკს ორ ნაწილად ყოფს

CVE-2026-88771 შესაბამის დაუცველ NetScaler-ზე დამატებითი ფუნქციის გარეშეც მოქმედებს, მათ შორის ნაგულისხმევი კონფიგურაციით. ამიტომ DTLS-ის გათიშვა ამ ხარვეზს ვერ აგვარებს. CVE-2026-88772-ის წინაპირობა განსხვავებულია: მოწყობილობაზე DTLS უნდა იყოს ჩართული, რაც VPN vServer-ზე ნაგულისხმევი მდგომარეობაა.

VPN ვირტუალური სერვერის ჩანაწერში „-dtls OFF“ აშკარად უნდა იყოს მითითებული, რომ ეს კონკრეტული წინაპირობა მოიხსნას. ცალკე უნდა შემოწმდეს DTLS ტიპის სხვა ვირტუალური სერვერებიც, მათ შორის დატვირთვის გამანაწილებელი სერვერები, თუ ასეთი კონფიგურაცია არსებობს. მხოლოდ იმის ცოდნა, რომ ადმინისტრატორს DTLS ხელით არ ჩაურთავს, VPN vServer-ის შემთხვევაში უსაფრთხო დასკვნას ვერ იძლევა.

ამიტომ გადაწყვეტილების მიმდევრობა ასეთია: ჯერ გამოაცალკევეთ პროვაიდერის მიერ მართული სერვისი თვითმართვადი ინსტანციისგან; შემდეგ შეადარეთ თითოეული თვითმართვადი ინსტანციის შტო მის გამოსწორებულ ბილდს; დაუცველ ინსტანციაზე CVE-2026-88771 უკვე გასათვალისწინებელია; ბოლოს DTLS-ის ფაქტობრივი პარამეტრით განსაზღვრეთ, ემატება თუ არა CVE-2026-88772. ამ თანმიმდევრობით DTLS-ის შემოწმება ვერ გადაფარავს უფრო ფართო, პირველი ხარვეზით გამოწვეულ რისკს.

რას აკეთებს განახლება და რას ტოვებს გამოსაკვლევს

გამოსწორებული ბილდის დაყენება მთავარი ტექნიკური ზომაა. თუ ეს დაუყოვნებლივ ვერ ხერხდება, საჯარო წვდომის შეზღუდვა შესაძლებელია ქსელის ზედა დონეზე; DTLS-ის გათიშვა ან შემომავალი UDP/443-ის დაბლოკვა მხოლოდ მეორე ხარვეზის ზედაპირს ამცირებს. ფართოდ ხელმისაწვდომ VPN-ზე მისამართების მკაცრმა შეზღუდვამ შეიძლება თანამშრომლების წვდომა შეაფერხოს, ამიტომ დროებითი ზომა კონკრეტულ სერვისთან უნდა შეთანხმდეს. ქსელის ზედა დონეზე ფილტრაციას განსაკუთრებული მნიშვნელობა აქვს: მხოლოდ NetScaler-ის ლოკალურ წესზე დაყრდნობით მავნე პაკეტი შეიძლება მაინც მივიდეს მოწყობილობის დამუშავების მექანიზმამდე. თუ DTLS ბიზნესისთვის აუცილებელია, მისი გათიშვის ნაცვლად შემომავალი კავშირები დასაშვები წყაროებით უნდა შეიზღუდოს, სანამ შესაბამისი ბილდი დაიყენება.

Mandiant-ისა და Google Threat Intelligence Group-ის გამოძიებაში აღწერილია CVE-2026-88772-ის გამოყენება სულ მცირე სექტემბრის დასაწყისიდან: მკვლევრებმა ნახეს თავდამსხმელის წვდომა უმაღლესი პრივილეგიით, PHP ვებგარსები და შიდა ქსელში გადაადგილებისთვის გამოყენებული ტუნელი. ერთ დაფიქსირებულ შეღწევაში ამ ტუნელით შიდა სისტემების დათვალიერება და სააღრიცხვო მონაცემების მოპოვებაც მოხდა. ეს კონკრეტული შემთხვევების მიგნებებია და ყველა დაზიანებული NetScaler-ის კომპრომეტაციას არ ნიშნავს.

შესაბამისად, ინციდენტის შემოწმებამ უნდა მოიცვას დაუცველი პერიოდის ჟურნალები, კონფიგურაციის მთლიანობა და მოწყობილობიდან უჩვეულო გამავალი კავშირები. DTLS-ზე მომხდარი შეტევისას საყურადღებოა ხელის ჩამორთმევის შეცდომისა და NetScaler Packet Processing Engine-ის მოულოდნელი შეწყვეტის თანხვედრა. ვებგარსის მოსაძებნად მნიშვნელოვანია VPN-სკრიპტების არეალში მოულოდნელი ფაილები და შეცვლილი httpd.conf; ცალკეული შეცდომა თავისთავად წარმატებულ შეღწევას არ ამტკიცებს. შეფასება უფრო დამაჯერებელია, როცა ერთსა და იმავე დროის მონაკვეთში ერთმანეთს უკავშირდება ქსელური მოთხოვნა, პროცესის შეფერხება, ახალი ფაილი და გამავალი კავშირი. თუ მოწყობილობა უკვე გადაიტვირთა ან ჟურნალები არასრულია, ეს შეზღუდვა ინციდენტის შეფასებაში პირდაპირ უნდა აისახოს.

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

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

გაზიარება:

გამოიწერეთ ჩვენი ბიულეტენი

მიიღეთ უახლესი ამბები Web3-ის, AI-სა და კრიპტოს შესახებ პირდაპირ თქვენს ელფოსტაზე.

0