„FortiMail“ spraga jau išnaudojama: saugi versija priklauso nuo šakos

„FortiMail“ spraga CVE-2026-104286 jau išnaudojama atakose: JAV CISA žinomų išnaudojamų spragų katalogas ją įtraukė 2026 m. spalio 1 d. Neprisijungęs užpuolikas, siųsdamas specialiai parengtas HTTP arba HTTPS užklausas, gali įrašyti failus į „FortiMail“ sistemą. Dėl to internetui atvira pažeidžiama valdymo sąsaja reikalauja ir apsaugos priemonių, ir incidento patikros.

Pagal CERT Polska perspėjimą, paveiktos „FortiMail“ 7.2.0–7.2.9, 7.4.0–7.4.8, 7.6.0–7.6.6 ir 8.0.0–8.0.1 versijos; numatytos pataisos atitinkamai 7.4.9, 7.6.7 ir 8.0.2 leidimuose, o 7.2 naudotojams reikia pereiti į pataisytą naujesnę šaką. Spalio 2 d. skelbiant perspėjimą šie pataisyti leidimai dar nebuvo išleisti. Todėl administratorius pirmiausia turi nustatyti tikslią naudojamą versiją ir apriboti galimą atakos kelią, nelaukdamas atnaujinimo.

Pažeidžiamų versijų matrica

Vien produkto pavadinimo nepakanka nuspręsti, kokio atnaujinimo reikia. Versijos numerį būtina vertinti kartu su šaka: vėlesnis numeris vienoje šakoje nereiškia, kad kitos šakos diegimas jau apsaugotas. Paskelbtos ribos atrodo taip:

• 7.2 šaka: paveiktos 7.2.0–7.2.9 versijos. Atskiras pataisytas 7.2 leidimas nenurodytas; reikia planuoti perėjimą į 7.4 arba naujesnę šaką, pasirinkus leidimą, kuriame pataisa iš tiesų yra.
• 7.4 šaka: paveiktos 7.4.0–7.4.8 versijos. Numatyta pataisymo riba yra 7.4.9.
• 7.6 šaka: paveiktos 7.6.0–7.6.6 versijos. Numatyta pataisymo riba yra 7.6.7.
• 8.0 šaka: paveiktos 8.0.0–8.0.1 versijos. Numatyta pataisymo riba yra 8.0.2.

Šios ribos apibūdina, kuriuose „FortiMail“ leidimuose numatyta pataisa, o ne garantuoja, kad juos jau galima atsisiųsti. Tai ypač svarbu 7.2 naudotojams: perėjimas į bet kurią 7.4 versiją problemos neišsprendžia, nes ankstesni tos šakos leidimai taip pat paveikti. Prieš keičiant šaką reikia patikrinti konkretaus pataisyto leidimo prieinamumą ir suplanuoti diegimui tinkamą migracijos kelią.

Kodėl vien prisijungimų žurnalų neužtenka

Spraga susijusi su „FortiMail“ valdymo sąsaja. Jos išnaudojimui nereikia galiojančios administratoriaus paskyros: specialiai suformuota užklausa gali apeiti failo kelio apribojimus ir leisti įrašyti pasirinktą failą į pagrindinę sistemą. Toks įrašymas gali sudaryti sąlygas vykdyti kodą nuotoliniu būdu. Tai galimybė, kurią suteikia spraga, o ne teiginys, kad kiekviena pažeidžiama sistema jau buvo užvaldyta.

Incidento patikrai todėl neužtenka peržiūrėti tik sėkmingus prisijungimus prie administravimo sąsajos. Jei sąsaja buvo pasiekiama iš interneto, reikia vertinti ir žiniatinklio užklausų, sistemos failų bei konfigūracijos pokyčius. Svarbu nustatyti, kada prieiga buvo atvira ir kiek to laikotarpio žurnalų išliko: nepilni įrašai riboja galimybę atmesti ankstesnį spragos išnaudojimą.

Apsauga iki pataisyto leidimo

Kol konkrečiai šakai skirta pataisa neprieinama, pirmasis veiksmas yra sumažinti valdymo sąsajos pasiekiamumą. Prieigą iš interneto galima išjungti arba leisti ją tik iš patikimų privačių tinklų. Apribojimas turi galioti visiems viešiems adresams ir prieigos keliams, kuriais sąsaja galėtų būti pasiekta; vien taisyklės įrašymas konfigūracijoje dar neparodo, kad ji veikia iš išorės.

Kita paskelbta laikina priemonė – išjungti tapatybe pagrįsto šifravimo funkciją IBE. Jei organizacija ją naudoja šifruotiems laiškams, prieš pakeitimą būtina įvertinti poveikį pašto darbui. Šios priemonės mažina galimybę išnaudoti spragą dabar, tačiau neištrina anksčiau įrašytų failų ir neparodo, ar užpuolikas jau pakeitė sistemos nustatymus.

Kai pataisytas leidimas pasirodo, reikia atnaujinti būtent „FortiMail“ diegimą iki atitinkamos šakos saugios versijos. Versijų numerių nereikia painioti su kitais „Fortinet“ produktais: toks pat numeris kitame produkte nieko nepasako apie šios spragos pataisymą „FortiMail“. Po atnaujinimo verta dar kartą patikrinti, ar valdymo sąsajos prieigos ribojimai tebegalioja.

Kokie požymiai verčia tirti incidentą

Patikra turi apimti paskelbtus failų, užduočių ir pašto archyvavimo pakeitimus. „BleepingComputer“ aprašyti indikatoriai apima pridėtą /data/lib/liblog.so failą, pridėtą /data/etc/ld.so.preload failą ir pakeistą /bin/smit failą. Paskelbtuose žurnalo pavyzdžiuose taip pat matoma suplanuota užduotis, susijusi su /migadmin, bei archyvavimo paskyra archive234, nukreipta į nuotolinį serverį. Pastarasis pakeitimas svarbus todėl, kad pašto archyvavimas gali tapti duomenų perdavimo keliu.

Tokius radinius reikia palyginti su patvirtintais administratorių veiksmais ir ankstesne konfigūracija. Netikėtas failas arba neautorizuota archyvavimo paskyra yra pagrindas pradėti incidento tyrimą; vien paskelbtų indikatorių neradimas įsilaužimo nepaneigia. Užpuolikas gali pakeisti savo veiksmus, o dalis žurnalų gali būti neprieinami. Prieš šalinant įtartinus failus ar keičiant konfigūraciją naudinga išsaugoti žurnalus ir tyrimui reikalingą sistemos būseną.

Ką keičia patvirtintas kompromitavimas

Jei aptinkami neautorizuoti failai, užduotys ar archyvavimo nustatymai, vien programinės įrangos atnaujinimas neužbaigia incidento. Pataisa uždaro žinomą spragą, tačiau savaime nepašalina per ją atliktų pakeitimų. Tokiu atveju sistemą reikia tirti pagal organizacijos incidentų valdymo tvarką, nustatyti galimą prieigą prie pašto duomenų ir pašalinti nepatvirtintus pakeitimus.

Jei tyrimas rodo, kad galėjo būti atskleisti administratoriaus prisijungimo duomenys ar kitos sistemoje saugotos paslaptys, jas reikia pakeisti. Taip pat būtina įvertinti, ar archyvavimo konfigūracija negalėjo siųsti laiškų į užpuoliko nurodytą vietą. Internetui atviros pažeidžiamos sistemos atveju incidento patikra prasideda dar prieš gaunant pataisą ir tęsiama po jos įdiegimo: saugus versijos numeris neatsako į klausimą, kas sistemoje vyko anksčiau.

Taip pat skaitykite:

• Make ar Zapier: pigi automatizacija priklauso nuo skaičiuojamo veiksmo
• „YouTube“ leis bandyti tris vaizdo versijas: kūrėjų darbą perima DI
• Paysera ar Stripe: pigesnis tarifas priklauso nuo pirkėjo kortelės