Käytännön IT-työstä

PHP2Shell: kenen on toimittava nyt – tarkista NAS, Docker ja julkiset palvelut

NAS, verkkosovellus tai kontti: tarkista PHP-ympäristö, julkiset yhteydet ja saavutettavat verkkokohteet erikseen. Valmistajatiedotteet ja seitsemän käytännön tehtävää.

Tietoturva
DAXS-logo, verkkopalvelu, määritelty pääsyraja ja toisistaan erotetut verkkokohteet

Etäkäyttöön tarkoitettu NAS, julkaistu konttiportti tai joskus väliaikaisesti avattu yhdyskäytävä: tällaiset palvelut unohtuvat helposti. PHP2Shellin kohdalla ratkaisee kolme kysymystä: mikä on saavutettavissa, mikä ajoympäristö käsittelee verkkopyynnöt ja mihin muihin järjestelmiin palvelu pääsee?

Sarjan kaksi ensimmäistä artikkelia käsittelevät PHP:n tietoturvatilannetta ja toimiamme sekä tekoälyn tukea järjestelmäkartoituksessa. Tässä keskitymme yritysten ja yksityisten NAS-käyttäjien käytännön tarkistuksiin. Tuotemerkki ei korvaa järjestelmäluetteloa. Ajantasainen laiteohjelmisto ei myöskään todista, että kaikki paketit ja käynnissä olevat kontit olisi päivitetty.

PHP2Shell koskee verkkopyyntöjä todellisuudessa käsittelevää PHP-ympäristöä

CVE-2026-109618 ja CVE-2026-109619 voivat mahdollistaa koodin suorittamisen ennen sovellukseen kirjautumista. Molempien CVSS v4.0 -pistemäärä on 9,2. PHP-projekti julkaisi korjatut versiot 8.2.35, 8.3.36, 8.4.27 ja 8.5.12 lokakuun 21. päivänä 2026. Valmistajat voivat tarjota omia pakettejaan, joissa korjaukset on sovitettu vanhempiin versiohaaroihin. Ratkaisevaa on siis tuotteen oma tietoturvatiedote, ei pelkkä versionumero.

Kirjautumissivu ei tässä takaa turvallisuutta. Tarkista verkkopyyntöjä oikeasti käsittelevä tulkki ja käynnissä olevat työprosessit. Komentorivin ajantasainen PHP-versio ei yksin osoita verkkopalvelun olevan korjattu. Tämä koskee perinteisiä verkkopalvelimia sekä sovellusten, laitteiden ja konttikuvien mukana toimitettuja ajoympäristöjä.

Julkinen saavutettavuus on muutakin kuin porttiohjaus

Kartoitukseen kuuluvat IPv4 ja IPv6, reitittimen säännöt, UPnP, DDNS-nimet, käänteisen välityspalvelimen kohteet, tunnelit ja pilvipalvelun välittämä etäkäyttö. Selvitä jokaisessa tapauksessa todellinen yhteysreitti: julkinen IP-osoite ei itsessään ole haavoittuva sovellus. Valmistajan välityspalvelu ei myöskään automaattisesti tarkoita samaa hyökkäysreittiä. Unohtunut sääntö voi toisaalta avata sisäiseksi tarkoitetun palvelun internetiin.

Listaa verkkosivustot, julkaisujärjestelmät, asiakasportaalit, hosting-paneelit sekä varmistuksen, valvonnan ja hallinnan käyttöliittymät. Sama koskee NAS-alustoja, VoIP-järjestelmiä, kameroita, tulostimia ja ohjausjärjestelmiä. Laitteet, joissa ei ole asiaan liittyvää PHP-komponenttia, eivät automaattisesti kuulu näiden kahden CVE:n piiriin. Niiden julkinen saavutettavuus kannattaa silti arvioida.

Kaksi esimerkkiä: laajat oikeudet saanut verkkopalvelu voi saavuttaa lisää sisäisiä kohteita. Erillinen verkkopalveluverkko sallii vain tarvittavan tietokantayhteyden; hallinta ja varmistukset on erotettu.
Esimerkkejä verkkoreiteistä: todellisuudessa sallitut yhteydet ja oikeudet ratkaisevat.

Synology: arvioi käyttöjärjestelmä ja paketit erikseen

Synology rajaa vaikutukset tiettyihin PHP:stä riippuvaisiin paketteihin, kuten Web Stationiin, WordPressiin, Calendariin ja MailStationiin. Lokakuun 22. päivän tiedote mainitsee PHP-päivitykset DSM 7.4:lle, 7.3:lle ja nimenomaisesti myös DSM 7.2:lle, vaikka viimeksi mainittu DSM-versio on jo elinkaarensa lopussa. Vanhemmille DSM-versioille valmistaja suosittelee kyseisten pakettien väliaikaista poistamista käytöstä.

PHP päivitetään Pakettikeskuksen kautta. MailStation edellyttää lisäksi paketin manuaalista päivitystä. Tietoturvatiedote ei ilmoita korjausta Synologyn PHP 7.3 -paketille. Valmistajan mukaan DSM:n sisäisesti käyttämä PHP on eri tavoin altistunut eikä sisällä ulkoa saavutettavia moduuleja. Myös nimet on erotettava: kolmannen osapuolen IDrive-paketti ei ole Synology Drive. Tiedotteen mukaan Synology Drive ei ole haavoittuvuuksien vaikutuspiirissä.

Epävirallisissa XPEnology-pohjaisissa DSM-asennuksissa laite, käynnistyslataaja, DSM ja paketit on arvioitava tapauskohtaisesti. Kyseessä ei ole tavanomaisesti tuettu Synology-kokonaisuus. Tämä ei tarkoita, ettei päivittäminen koskaan onnistuisi tai että kaikki tällaiset asennukset olisivat haavoittuvia. Epävarma päivitettävyys on kuitenkin syy rajoittaa suoraa internetyhteyttä ja suunnitella luotettavasti ylläpidettävä ympäristö.

QNAP: tarkista muuttunut tilanne

Lokakuun 24. päivänä päivitetty QNAP QSA-26-18 -tiedote luettelee korjauksia useisiin QTS-, QuTS hero- ja QuTScloud-haaroihin. Muiden lueteltujen sovellusten tila on edelleen ”Fixing”. Tilannetta ei siis kuvaa oikein ”QNAPilla ei vielä ole korjausta” eikä ”kaikki on korjattu”. Ratkaisevia ovat täsmällinen tuote, sen versiohaara ja sitä vastaava korjattu julkaisu. QNAPin järjestelmäpäivitys ei automaattisesti korjaa kolmannen osapuolen sovellusten tai omien konttien PHP:tä.

Konttien kohdalla on vastattava kahteen eri kysymykseen

Ensinnäkin: onko käynnissä olevan kontin ajoympäristö korjattu? Päivitetty isäntä ei korvaa vanhaa konttikuvaa. Pohjakuvan, lisäpakettien ja todellisuudessa ajossa olevan käyttöönoton on vastattava toisiaan. Uusi paikallisesti tallennettu kuva auttaa vasta, kun palvelu otetaan uudelleen käyttöön korjatusta kuvasta ja sen toiminta on tarkistettu.

Toiseksi: millaiset oikeudet ja verkkoreitit palvelulla on? Dockerin bridge-verkot sallivat lähtökohtaisesti ulospäin suuntautuvat yhteydet, ja saman bridge-verkon kontit voivat viestiä keskenään. Sisäisten kohteiden saavutettavuus riippuu muun muassa reitityksestä ja palomuurisäännöistä. Murrettu kontti ei siksi automaattisesti ota koko lähiverkkoa haltuun. Yhteiset tunnukset, tarpeettomat isännän hakemistoliitokset, lisäoikeudet tai konttiin liitetty Docker-socket voivat kuitenkin laajentaa seurauksia merkittävästi. Erilliset verkot, täsmälliset ulosmenoliikenteen säännöt ja vähimmäisoikeudet on tarkistettava käytännössä.

Päätöspolku: tunnista haavoittuva komponentti. Jos päivitys on saatavilla, asenna se ja tarkista aktiivinen palvelu. Muuten rajaa julkista pääsyä ja dokumentoi väliaikainen ratkaisu. Molemmat polut johtavat vaikutuksen tarkistamiseen ja jatkoseurantaan.
Pääsyn rajaaminen ei korvaa päivitystä. Tarkista molempien toimenpiteiden vaikutus.

Seitsemän tarkistusta seuraavaan työkierrokseen

  1. Kartoita yhteydet: dokumentoi laitteet, sovellukset, julkaistut portit ja välityspalvelut vastuuhenkilöineen. Huomioi IPv6 ja unohtuneet väliaikaiset avaukset.
  2. Tunnista ajoympäristöt: kirjaa palvelukohtaisesti käyttöjärjestelmä, paketit, lisäosat ja verkkopyyntöjä käsittelevä PHP. Tarkista valmistajan tiedotteet ja ylläpitotilanne.
  3. Korjaa ja varmista: asenna sopivat päivitykset tai uudet kuvat, käynnistä palvelut asianmukaisesti uudelleen ja tarkista oikeasti aktiivinen versio.
  4. Vähennä altistumista: sulje tarpeeton julkinen hallintapääsy. VPN tai luotettu hallintaverkko voi rajata yhteyksiä, mutta päivitykset ovat tarpeen myös niiden takana.
  5. Testaa reitit ja oikeudet: rajaa tietokanta-, NAS-, varmistus- ja hallintayhteydet tarpeelliseen laajuuteen. Muuta sääntöjä hallitusti ja tarkista sen jälkeen hyväksyttyjen sovellusten toiminta.
  6. Tarkista jäljet ja palautus: arvioi poikkeavat yhteydet, käyttäjätilit ja ulospäin suuntautuva liikenne. Ylläpidä riippumattomia, luvattomilta muutoksilta suojattuja varmistuksia ja testattua palautusta. Pelkät tilannevedokset eivät riitä.
  7. Seuraa poikkeuksia: kirjaa ilman korjausta oleville järjestelmille vastuut, väliaikainen toimenpide ja suunnitelma korvaamisesta tai käytöstäpoistosta.
Seitsemän tehtävää: kartoita yhteydet, tunnista ajoympäristöt, varmista päivitykset, vähennä altistumista, testaa verkko-oikeudet, tarkista jäljet ja palautus sekä seuraa poikkeuksia.
Jokainen tehtävä tarvitsee vastuun, toteutuksen ja tarkistuksen.

Korjaus ei automaattisesti päätä poikkeaman selvittämistä

Sophos viittaa Amazon Threat Intelligencen jo lokakuun 17. päivänä havaitsemaan hyväksikäyttöyritykseen ennen julkista tiedotetta. Todella altistuneiden järjestelmien arvioinnissa on siksi huomioitava myös aiempi toiminta. Onnistunut päivitys ei todista, ettei luvatonta pääsyä tapahtunut ennen sitä. Epäilyttävät merkit edellyttävät järjestelmällistä poikkeamankäsittelyä, asianmukaista jälkien säilyttämistä ja hallittua palautusta.

PHP on lisäksi kertonut lokakuun 23. päivästä lähtien harvinaisesta lisätapauksesta, joka riippuu istunnon tiedostolatauksen etenemisseurannan asetuksista. Ajantasaiset valmistajatiedotteet ovat siis tärkeitä myös ensimmäisen päivityksen jälkeen. Yleiset asetusmuutokset ilman tietoa niiden toiminnallisista vaikutuksista eivät ole hyvä oikotie.

Sen, minkä ei tarvitse olla julkista, ei pitäisi olla saavutettavissa internetistä ennen tarkistusta. Tämä pienentää hyökkäyspintaa, mutta ei korvaa korjausta. DAXS auttaa tunnistamaan palvelut, priorisoimaan toimenpiteet ja tarkistamaan niiden vaikutuksen dokumentoitavasti. Keskustellaan omasta ympäristöstäsi.

Lähteet: PHP: tietoturvatiedotteet ja korjatut versiot · ENISA: PHP-sovellusten tunnistaminen ja altistumisen rajaaminen · Synology: paketit ja DSM-versiot · Synology-SA-26:14 · QNAP QSA-26-18: tuotekohtaiset korjaukset · Docker: bridge-verkkojen ominaisuudet · Sophos: altistuminen, havainnot ja poikkeamien selvittäminen · NCSC-NL: PHP-riippuvuudet · Red Hat: ajoympäristöt ja taaksepäin siirretyt korjaukset.