F5:n nollapäivä osuu tiettyyn OAuth-rooliin – tarkista lokit

CERT-EU:n 22. syyskuuta 2026 julkaisema varoitus kertoo, että F5:n BIG-IP Access Policy Managerin haavoittuvuutta CVE-2026-94127 käytetään aktiivisesti hyväksi. Kyse on keon puskuriylivuodosta, jonka CVSS 3.1 -arvo on 9,8 ja joka voi antaa tunnistautumattomalle hyökkääjälle mahdollisuuden suorittaa koodia BIG-IP-järjestelmässä.

Altistuminen edellyttää täsmällistä kokoonpanoa: BIG-IP APM toimii OAuth Authorization Server -roolissa, ja samalla virtuaalipalvelimella ovat käytössä APM access policy sekä OAuth-profiili. Tällaisen palvelimen ylläpitäjän pitää tunnistaa ohjelmistohaara, asentaa siihen tarkoitettu hotfix tai pyytää väliaikainen iRule sekä selvittää, näkyykö lokeissa ja TMM:n toiminnassa hyväksikäytön merkkejä. Päivitys estää haavoittuvuuden myöhemmän hyödyntämisen, mutta aiempaa tapahtumaketjua se ei selvitä.

Tunnista haavoittuva OAuth-rooli ja ohjelmistohaara

Aloita virtuaalipalvelimista, jotka vastaanottavat OAuth-liikennettä. Selvitä kunkin palvelimen access policy ja siihen liitetty OAuth-profiili sekä se, toimiiko APM tässä yhteydessä valtuutuspalvelimena eli myöntääkö se sovelluksille käyttöoikeustunnuksia. Pelkkä APM:n käyttöönotto tai OAuth-maininta kokoonpanossa ei vielä osoita, että juuri kyseinen palvelin täyttää haavoittuvuuden ehdot.

Jos APM toimii vain OAuth Client- tai Resource Server -roolissa eikä OAuth Authorization Server -profiilia ole määritetty, tämä haavoittuvuus ei koske kyseistä kokoonpanoa. Rajaus on tehtävä virtuaalipalvelin kerrallaan: samassa BIG-IP-ympäristössä voi olla eri tehtäviin määritettyjä palvelimia. Tarkista myös varalla olevat ja erikseen julkaistut saman tuotteen instanssit, jotta yhden palvelimen turvallinen rooli ei peitä toisen altistumista. Eri virtuaalipalvelimille määritetyt access policy ja OAuth-profiili eivät muodosta altistavaa yhdistelmää vain siksi, että ne sijaitsevat samassa laitteessa.

Haavoittuvat ohjelmistohaarat ovat BIG-IP APM 21.1.0, 17.5.0–17.5.1 ja 17.1.0–17.1.3 ennen niitä vastaavia korjauksia. Haavoittuvuus koskee liikennettä käsittelevää tietotasoa, ja myös Appliance mode kuuluu vaikutuspiiriin, jos altistava OAuth-kokoonpano on käytössä. Hallintaliittymän pääsyn rajaaminen ei siksi poista virtuaalipalvelimeen tulevan liikenteen aiheuttamaa riskiä. Teknisen tuen päättäneitä versioita ei ole arvioitu, joten niiden puuttuminen luettelosta ei ole osoitus turvallisuudesta. Tällaisen version kohdalla ylläpitäjä tarvitsee erillisen suunnitelman tuettuun ja korjattuun ohjelmistoon siirtymiseksi.

Asenna omaan haaraan kuuluva hotfix tai pyydä iRule

Korjaus valitaan ohjelmistohaaran perusteella. F5:n julkaisemassa CVE-tietueessa korjaavat paketit ovat Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG ja Hotfix-BIGIP-17.1.3.5.0.41.14-ENG. Nimet vastaavat edellä mainittuja kolmea ohjelmistohaaraa samassa järjestyksessä. Tarkista käytössä oleva versio ja asennettu hotfix jokaisesta altistavasta järjestelmästä ennen kuin merkitset sen korjatuksi.

Jos sopivaa hotfixiä ei voi ottaa heti käyttöön, väliaikainen iRule-lievennys on saatavilla pyynnöstä haavoittuvalle virtuaalipalvelimelle. Sitä varten avataan tukipyyntö F5:lle; iRule ei ole yleinen OAuth-asetusten muutos, joka voitaisiin päätellä pelkästä haavoittuvuuden kuvauksesta. Säilytä mahdollisen tutkinnan lokit ja muut jäljet ennen muutoksia. Näin korjaustoimet eivät katkaise mahdollisuutta selvittää, mitä haavoittuvalla palvelimella tapahtui ennen niiden käyttöönottoa.

Hotfixin ja iRulen tehtävä on pienentää uutta altistumista. Koska hyväksikäyttöä havaittiin jo julkistuksen aikaan, korjattu kokoonpano ja puhdas tapahtumahistoria ovat eri kysymyksiä. Käy lokit läpi myös silloin, kun asennus onnistui eikä palvelussa näy käyttäjille poikkeavaa toimintaa.

Hae UserInfo-virheet, audit-merkinnät ja TMM-jäljet

JPCERT/CC:n 24. syyskuuta 2026 julkaisema hälytys ohjaa etsimään /var/log/apm-lokista OAuth UserInfo -pyyntöjen virheitä, joiden lokitunnus on 01990004. Erityinen tarkistussignaali on vähintään kymmenen toistuvaa virhettä, varsinkin jos ne tulevat samasta IP-osoitteesta lyhyessä ajassa. Merkinnässä voi näkyä invalid_token-virhe; sen esiintyminen yksin ei kuitenkaan ratkaise, onko järjestelmä murrettu.

1. Rajaa /var/log/apm-lokin tarkastelu altistavan virtuaalipalvelimen liikenteeseen ja etsi toistuvaa Request UserInfo -epäonnistumista. Ryhmittele tapahtumat lähdeosoitteen ja kellonajan mukaan. Lokimerkinnän profiilin nimi auttaa yhdistämään virheen oikeaan OAuth-kokoonpanoon, kun laitteessa on useita profiileja. Näin saman osoitteen lyhyessä ajassa aiheuttama virhesarja erottuu yksittäisistä virheellisistä käyttöoikeustunnuksista.
2. Suorita komento tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed. Katso, onko total_failed-arvo noussut selittämättömästi suhteessa pyyntöjen määrään ja ympäristön tavalliseen liikenteeseen. Tilastopiikki ohjaa tutkimaan tarkempaa aikaväliä, mutta laskuri ei yksin kerro virheiden lähdettä tai osoita onnistunutta hyökkäystä.
3. Jos OAuth-virheet toistuvat nopeasti, tarkista saman ajanjakson /var/log/audit ja etsi komentoja, joille ei löydy ylläpitotoimista selitystä. Yhdistä audit-merkintöjen aika UserInfo-virhesarjaan. Pelkkä virheen ja ylläpitokomennon esiintyminen samana päivänä on heikompi havainto kuin tiiviisti toisiaan seuraava tapahtumaketju.
4. Tutki TMM-prosessin core-tiedostot ja mahdollinen SIGABRT-keskeytys samalta aikaväliltä. Havaittu tapahtumakulku voi sisältää TMM:n joutumisen silmukkaan, minkä jälkeen SOD lähettää sille SIGABRT-signaalin. Core-tiedosto voi syntyä muistakin syistä, joten tulkitse sitä yhdessä OAuth-virheiden ja audit-lokin kanssa.

Jos näitä jälkiä löytyy, tarkista lisäksi liikennetiedoista poikkeuksellisen pitkä Authorization-otsake UserInfo-polkuun /f5-oauth2/v1/userinfo ja selvitä, onko /etc/bigstart/scripts/tmm.finish muuttunut odottamatta. Muokattuja pyyntöjä voi esiintyä myös muilla poluilla, joten yhden polun puuttuminen liikennetiedoista ei sulje hyökkäysyritystä pois. Säilytä tapahtumien kellonajat, lähdeosoitteet ja käytettävissä olevat core-tiedostot tutkintaa varten.

Kun virhesarja, selittämättömät audit-komennot ja TMM:n keskeytys osuvat samaan tapahtumaketjuun, käsittele järjestelmää mahdollisesti murrettuna ja käynnistä häiriöselvitys. Selvityksen kohde on silloin myös korjausta edeltävä aika: hotfix ei poista järjestelmässä jo tehtyjä muutoksia eikä palauta kadonneita lokitietoja.