BeyondTrust nulles dienas kļūda jau izmantota — ar ielāpu vien nepietiek

BeyondTrust incidenta aprakstā norāda, ka 15. oktobrī publiskotā Remote Support ievainojamība CVE-2026-102764 jau 29. augustā tika izmantota pret vienu ražotāja uzturētu un vienu klienta paša uzturētu instalāciju. Pašu uzturēta servera labošana tādēļ ir steidzama, taču pēc tās jāpārbauda arī agrākas piekļuves pazīmes: ielāps nevar atcelt izmaiņas, kas veiktas pirms tā uzstādīšanas.

Kanādas Kiberdrošības centra 16. oktobra brīdinājums par skartām norāda Remote Support versijas līdz 26.2.3 ieskaitot, paredz BT26-05-RS ielāpu versijām no 24.3.1 līdz 26.2.3 un vēsta, ka Remote Support SaaS vides ražotājs salabojis līdz 9. oktobrim. Organizācijai ar pašu uzturētu instalāciju jānoskaidro gan tās versija, gan faktiskā ielāpa uzstādīšana; SaaS klientam pašam šis ielāps nav jāuzstāda.

Kāpēc pēc salabošanas jāmeklē agrākas piekļuves pēdas

Rapid7 19. oktobra analīze ievainojamībai piešķir CVSS v4 vērtējumu 9,3 un iesaka ārkārtas kārtā labot skartās pašu uzturētās instalācijas, vienlaikus izmeklējot iespējamu agrāku kompromitēšanu. Kļūda saistīta ar nepietiekamu ziņojumu izcelsmes pārbaudi Remote Support iekšējos komponentos. Attāls uzbrucējs bez piekļuves datiem vai lietotāja līdzdalības var veikt neatļautas failu darbības iekārtā.

Aprakstītajā ielaušanās gaitā uzbrucējs izvietoja tīmekļa čaulu un tunelēšanas rīku, ieguva augstākas privilēģijas, pievērsās glabātajiem piekļuves datiem un dzēsa žurnālus. Tās ir darbības, kuru sekas var saglabāties arī tad, kad ievainojamība jau novērsta. Pārbaudei tāpēc jāaptver laiks, kad konkrētā instalācija bija pieejama ar ievainojamu versiju, un konti vai citas sistēmas, kurām caur Remote Support bija iespējams piekļūt. Zināma uzbrucēja faila vai adreses neatrašana pati par sevi neizslēdz ielaušanos, jo rīki un infrastruktūra citā incidentā var atšķirties.

Kurām Remote Support instalācijām vajadzīgs ielāps

Vispirms jāatšķir ražotāja uzturēta SaaS vide no pašu uzturētas iekārtas. Pašu uzturētajā vidē versijas numurs viens pats nepasaka, vai serveris vēl ir ievainojams: jāapstiprina arī konkrētā drošības ielāpa uzstādīšana. Ja automātiskā atjaunināšana nav ieslēgta, labojums jāuzliek manuāli. Arī ieslēgtas automātiskās atjaunināšanas gadījumā operators pārbauda rezultātu pašas iekārtas pārvaldības saskarnē, nevis paļaujas tikai uz iestatījumu.

Vecāku pašu uzturētu instalāciju nevar salabot, vienkārši mēģinot uzlikt tai paredzētā diapazona ielāpu. Tā vispirms jāatjaunina līdz versijai, kas šo ielāpu atbalsta, un pēc tam jāuzstāda labojums. Inventarizācijā jāiekļauj arī rezerves un reti lietotas instances: nepamanīta pieejama iekārta var palikt par ieejas punktu pat tad, ja galvenais serveris ir salabots. SaaS vides labojuma statuss atrisina ievainojamības novēršanas jautājumu, bet aizdomīgas agrākas sesijas vai kontu izmaiņas joprojām prasa incidenta pārbaudi.

Ārējie žurnāli var saglabāt izdzēsto darbību pēdas

Lokālo žurnālu trūkums šajā gadījumā nav drošs pierādījums tam, ka uzbrukuma nav bijis. Aprakstītajā incidentā uzbrucējs dzēsa ierakstus uz pašas iekārtas; iepriekš pārsūtītas syslog un sesiju notikumu kopijas var saglabāt laiku un darbību secību, kas lokāli vairs nav redzama. Tādēļ esošie ārējie ieraksti jāpasargā no parastās pārrakstīšanas, pirms pārstartēšanas vai pārbūves, ciktāl tas iespējams, neatliekot steidzamo aizsardzību.

Noderīgi ir SIEM saņemtie notikumi, reversā starpniekservera un perimetra ugunsmūra ieraksti, kā arī administratoru un atbalsta sesiju vēsture. Salīdzinot tos, var noteikt, vai neparasts pieprasījums sakrita ar privileģētu sesiju, faila augšupielādi, konta maiņu vai piekļuvi iekšējai sistēmai. Īpaši jāievēro pēkšņi pārrāvumi žurnālu pārsūtīšanā: tie var sakrist ar darbībām, kuras uzbrucējs centās noslēpt. Pārsūtīšanas ieslēgšana tagad palīdzēs saglabāt turpmākos notikumus, taču neatjaunos jau izdzēstu vēsturi.

Reaģēšanas secība pašu uzturētas vides operatoram

Atjaunināšana un incidenta izmeklēšana jāvada kā saistīti darbi. Operators var ātri aizvērt ievainojamību, vienlaikus saglabājot jau pieejamos pierādījumus un nosakot, vai piekļuve bijusi vēl pirms labojuma. Secība ir šāda:

1. Apzināt instalācijas. Uzskaitīt visas Remote Support instances, to uzturēšanas veidu un pieejamību no interneta. Katrai pašu uzturētajai iekārtai noteikt, kad tā darbojās ar ievainojamu versiju un kādi ārējie žurnāli par šo periodu ir saglabāti.
2. Pārbaudīt versiju un ielāpu. Salīdzināt uzstādīto versiju ar skarto diapazonu un iekārtas pārvaldībā apstiprināt labojuma statusu. Ja instalācija ir pārāk veca, vispirms atjaunināt to līdz ielāpu atbalstošai versijai; automātiskās atjaunināšanas iestatījumu neuzskatīt par uzstādīšanas pierādījumu.
3. Salabot un saglabāt pierādījumus. Neatlikt ievainojamības novēršanu līdz kārtējam apkopes logam. Ja ir aizdomas par kompromitēšanu, pirms pārstartēšanas vai pārbūves saglabāt pieejamos ārējos ierakstus un saskaņot iekārtas izolēšanu ar incidenta reaģēšanas komandu.
4. Meklēt uzbrucēja darbības. Salīdzināt nezināmas privileģētās sesijas ar administratoriem un izmaiņu pieteikumiem. Pārbaudīt negaidītus skriptus tīmekļa direktorijās, čaulas procesus no tīmekļa servisa kontiem, neatļautas Jump Items vai Teams tiesību izmaiņas un žurnālu pārsūtīšanas pārrāvumus.
5. Noteikt piekļuves apjomu. Ja pazīmes apstiprinās, noskaidrot, kuri konti, atbalsta sesijas un gala datori bija sasniedzami caur skarto iekārtu. Pārskatīt arī privileģēto kontu jaunās daudzfaktoru autentifikācijas reģistrācijas un pieslēgšanās ārpus ierastajām pārvaldītajām sesijām.
6. Atjaunot uzticamu vidi un mainīt piekļuves datus. Kompromitētas iekārtas gadījumā saglabāt tās izmeklēšanai vajadzīgo kopiju un lemt par pārbūvi no tīras, salabotas instalācijas. Pēc kontroles atgūšanas nomainīt iekārtā glabātos vai caur to nodotos administratoru, integrāciju un mērķsistēmu piekļuves datus.

Ja ārējie ieraksti rāda neatļautu sesiju vai piekļuvi citām sistēmām, izmeklēšanas robeža paplašinās līdz šiem kontiem un gala datoriem. Tieši saglabātā notikumu vēsture palīdzēs noteikt, kuras piekļuves jāatsauc un kuras sistēmas jāpārbauda tālāk.

Lasiet arī:

• E-rēķins nav PDF: XML kļūda var apturēt nodošanu VID
• Patiesā labuma guvēja maiņa: uzņēmumam ir tikai 14 dienas
• Kvalificēta investora statuss: vienam čekam nepietiek ar 60 000 eiro