Дзве дзіркі NetScaler ужо атакуюць: стандартная канфігурацыя не ратуе

27 верасня 2026 года Citrix у бюлетэні па NetScaler пацвердзіла эксплуатацыю дзвюх уразлівасцей — CVE-2026-88771 і CVE-2026-88772 — у NetScaler ADC і NetScaler Gateway. Для першай дастаткова ўразлівай зборкі: дадатковыя функцыі ўключаць не трэба, таму стандартная канфігурацыя прыладу не абараняе. Другая становіцца актуальнай пры ўключаным DTLS, які на віртуальным VPN-серверы працуе па змаўчанні. Citrix заклікала кліентаў тэрмінова ўсталяваць выпраўленыя зборкі.

Канадскі цэнтр кібербяспекі ў папярэджанні AL26-024 паведаміў пра атакі ў некалькіх кліенцкіх асяроддзях у розных краінах; поўны маштаб пакуль невядомы. CVE-2026-88771 дазваляе зламысніку без аўтэнтыфікацыі выконваць каманды і можа прывесці да поўнай кампраметацыі прылады. Пры CVE-2026-88772 магчымыя выкананне кода або адмова ў абслугоўванні. Адміністратарам трэба вызначыць версію кожнай інсталяцыі, асобна праверыць DTLS і шукаць прыкметы доступу, атрыманага яшчэ да абнаўлення.

Якія зборкі NetScaler трэба абнавіць

Пачніце з поўнага нумара зборкі і галіны праграмнага забеспячэння кожнай прылады. Для NetScaler ADC і NetScaler Gateway галіны 14.1 мэтавая зборка — 14.1-73.37 або навейшая ў той жа галіне; для галіны 13.1 — 13.1-64.23 або навейшая. NetScaler ADC 14.1-FIPS патрабуе 14.1-73.37 FIPS або навейшай, а NetScaler ADC 13.1-FIPS і 13.1-NDcPP — 13.1.37.279 або навейшай у сваёй галіне. Параўноўваць трэба поўную зборку, а не толькі першыя лічбы версіі.

Гэтыя межы датычацца інсталяцый, якімі кіруе кліент. Сюды ўваходзяць асобнікі NetScaler у Secure Private Access Hybrid: іх таксама трэба праверыць і абнавіць. Для воблачных сэрвісаў і Adaptive Authentication пад кіраваннем Citrix абнаўленне ўсталёўвае пастаўшчык. Калі ў арганізацыі некалькі шлюзаў, праверка аднаго віртуальнага VPN-сервера нічога не кажа пра зборкі астатніх прылад.

На старой зборцы CVE-2026-88771 застаецца рызыкай незалежна ад таго, ці наладжаны VPN і DTLS. Адсутнасць дадатковых функцый не зніжае прыярытэт такога абнаўлення. Асобна варта адзначыць прылады, даступныя з інтэрнэту: менавіта іх рэкамендавана абнаўляць у першую чаргу і даследаваць на прыкметы ранейшага ўмяшання.

Калі DTLS змяняе ацэнку рызыкі

Для CVE-2026-88772 важны стан DTLS на ўразлівай зборцы. У запісе VPN vServer без «-dtls OFF» пратакол застаецца ўключаным па змаўчанні. Запіс з «-dtls OFF» азначае, што на гэтым серверы перадумова для другой уразлівасці не выконваецца. Трэба таксама шукаць віртуальныя серверы тыпу DTLS, у тым ліку серверы балансавання нагрузкі: праверка толькі VPN-запісаў можа прапусціць іншую канфігурацыю з тым жа пратаколам.

Вынік гэтай праверкі адносіцца толькі да CVE-2026-88772. Калі DTLS адключаны ўсюды, гэта не змяняе стану прылады адносна CVE-2026-88771: на старой зборцы яна ўразлівая і са стандартнымі наладамі. Таму дрэва рашэнняў простае: спачатку вызначыць галіну і зборку, затым для старой зборкі адзначыць CVE-2026-88771, а для другой уразлівасці дадаткова праверыць DTLS. Іншыя памылкі таго ж бюлетэня маюць уласныя перадумовы; пацверджанне эксплуатацыі датычыцца менавіта гэтых дзвюх.

Якія сляды пакінулі назіраныя атакі

У даследаванні Unit 42 апісаныя два ланцужкі атак да публікацыі выпраўленняў: выкарыстанне DTLS з размяшчэннем шкоднасных файлаў у /vpn/scripts/linux/ і камандная ін’екцыя з наступным размяшчэннем PHP-абалонкі. Сярод названых прыкмет — /vpn/scripts/linux/nsgclient18.deb, /vpn/scripts/linux/nsg64.deb і /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver. У выпадку каманднай ін’екцыі даследчыкі таксама апісалі шкоднасныя запісы ў журналах і змены канфігурацыі Apache, якія давалі доступ да абалонкі праз адрас, падобны да файла CSS.

Гэтыя назвы карысныя для пошуку, але расследаванне не варта абмяжоўваць імі. Трэба супаставіць журналы NetScaler з аддаленым syslog, падзеямі аўтэнтыфікацыі і запісамі міжсеткавага экрана; праверыць нечаканыя выходныя злучэнні, падазроныя адміністрацыйныя сеансы і прабелы ў журналах. У каталогах вэб-праграмы, сцэнарыях запуску і запланаваных задачах варта шукаць несанкцыянаваныя змены. Адсутнасць пералічаных файлаў не выключае іншага спосабу замацавацца ў сістэме.

Паслядоўнасць: захаваць сведчанні, абнавіць, расследаваць

1. Складзіце пералік кліенцкіх NetScaler ADC і Gateway, уключна з асобнікамі Secure Private Access Hybrid. Для кожнай прылады зафіксуйце галіну, поўную зборку, даступнасць з інтэрнэту і канфігурацыю DTLS.
2. Калі гэта магчыма без небяспечнай затрымкі, перад перазагрузкай або змяненнем прылады захавайце яе журналы, даныя аддаленага syslog і NetScaler Console, дыягнастычны пакет і падазроныя файлы. Для віртуальнай прылады карысна таксама захаваць здымак стану.
3. Усталюйце выпраўленую зборку сваёй галіны і пасля запуску пераканайцеся, што працуе менавіта яна. Першымі апрацуйце інсталяцыі, даступныя з інтэрнэту, не адкладаючы астатнія старыя зборкі толькі таму, што на іх адключаны DTLS.
4. Праверце падзеі да абнаўлення і звязаныя сістэмы. Калі знойдзены прыкметы кампраметацыі, ізалюйце закранутую прыладу, ацаніце рызыку для ўліковых даных і сеансаў, а аднаўленне праводзьце з даверанага праграмнага забеспячэння і праверанай канфігурацыі.

Абнаўленне закрывае апісаныя ўразлівасці ў новай зборцы, але само па сабе не выдаляе шкоднасны файл або іншы механізм доступу, пакінуты раней. Таму вынік праверкі версіі і вынік расследавання трэба фіксаваць асобна: першы паказвае, ці ўсталявана выпраўленне, другі — ці можна давяраць прыладзе і доступам, якія праз яе праходзілі.

Чытайце таксама:

• Ghost ці Substack: 10% камісіі даражэюць ужо пры 29 падпісчыках