Röviden: A CERT-EU beszámolók szerint azt javasolja, hogy mérjék fel a PHP-telepítéseket, azonnal javítsanak, és izolálják a nyilvánosan elérhető alkalmazásokat, ha azok nem javíthatók időben. A CERT-Bund (a német kormányzati CERT) és a BSI (a német szövetségi információbiztonsági hivatal) figyelmeztetésében az azonnali frissítést javasolja, és ha az nem megy, az érintett webszerverek átmeneti leválasztását a hálózatról. Az ajánlások lényegében fedik egymást: először a frissítés, az izolálás vészmegoldásként, az átmeneti intézkedések csak kiegészítésként.
Ki figyelmeztet, és kinek?
A PHP2Shell esetében több hivatalos szerv reagált néhány órán belül. A németországi vállalatok számára a BSI a számítógépes vészhelyzeti csapatával, a CERT-Bunddal az első cím. A CERT-EU az EU-intézmények kiberbiztonsági szolgálata; az útmutatásai elsősorban nekik szólnak, de egész Európában olvassák őket. A BleepingComputer szerint a brit National Cyber Security Centre is figyelmeztetett. A magánszektorból egyebek mellett a Huntress és a Cloudflare jelentkezett.
Üzemeltetőként az Ön számára a származásnál fontosabb az egyezés. Ha több független szerv ugyanazt javasolja, az erős jel.
CERT-Bund, CERT-EU és mások: a PHP-figyelmeztetések összehasonlítása
| Szerv | Fő ajánlás | Sajátosság |
|---|---|---|
| BSI / CERT-Bund | azonnal frissíteni, különben a webszervert átmenetileg leválasztani a hálózatról | 3-as / narancs riasztási szint |
| CERT-EU | a PHP-telepítések felmérése, azonnali javítás, különben a nyilvános alkalmazások izolálása | beszámolók szerint a PHP 5-től felfelé tartotta lehetségesnek az érintettséget |
| UK NCSC | azonnal frissíteni, vagy az érintett rendszereket a javításig leválasztani a hálózatról | a BleepingComputer szerint |
| php.net | frissítés 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra, az átmeneti intézkedések csak részleges védelem | elsődleges forrás a verziókhoz és a beállításokhoz |
Egyik szerv sem javasolja, hogy kizárólag egy Web Application Firewallra vagy a php.ini beállításaira hagyatkozzon. Mindegyik a frissítést nevezi meg tényleges megoldásként. Hogy a BSI ezen túl részletesen mit javasol, azt a Mit javasol a BSI a PHP2Shellről oldal tartalmazza.
A verziókérdés: mit jelent a „PHP 5-től”
A CERT-EU beszámolók szerint lehetségesnek tartotta, hogy a PHP 5-től felfelé érintettek a verziók. A szerv ehhez szakmai beszámolók szerint a hivatalos közlemény előtt keringő információkra támaszkodott. A szaksajtó szinte az összes verzióról beszél egészen a PHP 5.4-ig visszamenőleg.
A gyakorlatban a pontos határ keveset változtat. A PHP 8.1-hez és a régebbiekhez a PHP-projekt már nem ad ki hivatalos frissítéseket. A 7.4-hez, a 8.0-hoz és a 8.1-hez léteznek minimális forrásszintű backportok, de kiadások nem. Aki még PHP 5-öt vagy 7-et üzemeltet, a disztribúciókra, harmadik felekre vagy egy migrációra van utalva. Hogy a disztribúciója szállított-e javítást, azt azok saját biztonsági oldalai mutatják, például a Debian Security Tracker, az Ubuntu Security Notices vagy a Red Hat közleményei. Kereskedelmi hosszú távú ajánlatok is léteznek régi PHP-verziókhoz; hogy lefedik-e a PHP2Shellt, azt írásban erősíttesse meg a szolgáltatóval. Az ágak részleteit a Mely PHP-verziók érintettek? és a PHP 8.1 és régebbi oldal tartalmazza.
Izolálás: így hajtsa végre az ajánlást
Az „izolálás” elvontan hangzik. Azt jelenti, hogy az internetről érkező kérések már nem érik el a sebezhető PHP-alkalmazást. Az alkalmazástól függően több fokozat van:
- Teljes leállítás: A weboldalt egy statikus, PHP nélküli vészhelyzeti oldal váltja fel. Ez a legbiztonságosabb változat.
- A hozzáférés korlátozása: Az alkalmazás üzemben marad, de már csak VPN-en vagy meghatározott IP-címekről érhető el, például belső portáloknál.
- Előtét-bejelentkezés: Bejelentkezés a webszerver vagy a proxy szintjén az alkalmazás előtt. Figyelem: a mod_php esetében az exploitot azelőtt mutatták be, hogy az alkalmazáskód futna. A bejelentkezésnek ezért a PHP előtt kell működnie, nem az alkalmazásban.
- A közvetlen hozzáférés lezárása az eredeti szerverhez: Aki proxy- vagy CDN-szolgáltatást használ, gondoskodjon arról, hogy a szerver ne legyen emellett közvetlenül is elérhető.
A webszerveren a korlátozás így nézhet ki, veszélytelen konfigurációként Apache-hoz:
# Hozzáférés engedélyezése csak a belső hálózatról (a példatartományt igazítsa)
<Location "/">
Require ip 192.0.2.0/24
</Location>
Tesztelje a hatást kívülről, például mobilkapcsolaton keresztül. Az az izoláció, amelyet csak az irodai hálózatban ellenőriztek, nem ellenőrzött izoláció.
Az izolálás áthidalás. Az izoláláskor azonnal rögzítse, mikorra érkezik a frissítés, és ki telepíti. Különben a vészmegoldásból tartós állapot lesz.
Amit az ajánlások közösen megkövetelnek: egy leltár
Az összes hivatalos szerv feltételezi, hogy tudja, hol fut PHP. Sok vállalatnál éppen ezen bukik el a dolog: régi kampányok mikrooldalai, egy elfelejtett ügyfélportál, egy nyilvános címmel rendelkező tesztrendszer, egy NAS-on futó alkalmazás. A CERT-EU kifejezetten első lépésként nevezi meg a PHP-telepítések felmérését.
Az elfelejtett rendszereket három úton találja meg a legkönnyebben: a domainjei DNS-zónáin, a kiállított TLS-tanúsítványok listáján, valamint az ügynökségekkel, tárhelyszolgáltatókkal és szoftverszállítókkal kötött szerződéseken keresztül. Minden bejegyzés, amelyről senki sem tudja azonnal megmondani, mi fut mögötte, az ellenőrzőlistára kerül. Éppen az ilyen rendszerek veszélyesek egy PHP2Shellhez hasonló helyzetben, mert senki sem javítja őket, és senki sem hiányolja őket, ha feltörik azokat.
Egy használható leltár rendszerenként tartalmazza: a címet, a célt, az üzemeltetőt, a PHP-verziót és az üzemmódot, a csomagok forrását és a frissítések kapcsolattartóját. Hogyan építheti fel és tarthatja naprakészen, azt a Az összes weboldal és szerver leltára írás mutatja.
Hogyan segít konkrétan a PHP SOS?
- Felmérés: Meghatározzuk a nyilvánosan elérhető PHP-rendszereit, és kockázat szerint rendezzük őket.
- Javítás vagy izolálás: Telepítjük a frissítéseket, vagy izoláljuk azokat az alkalmazásokat, amelyek nem javíthatók azonnal, és kívülről ellenőrizzük a hatást.
- Régi verziók: A PHP 8.1-es és régebbi verziójú rendszerekhez Önnel közösen megtervezzük az utat egy támogatott állapotig.
- Igazolás: Dokumentációt kap a végrehajtott ajánlásokról rendszerenként.
Hogyan visszük át a régi alkalmazásokat támogatott verziókra, azt a PHP-migráció régi rendszerekhez szolgáltatás írja le.
Összegzés
A CERT-EU, a CERT-Bund, a BSI és a PHP-projekt egy hangon beszél: frissíteni, és ahol ez nem megy azonnal, izolálni. A különbségek részletekben vannak, például a verziók határában. A gyakorlatban az az első lépés számít, amelyet mindenki feltételez: tudni, hol fut mindenhol PHP.
Gyakori kérdések
Mi a különbség a CERT-Bund és a CERT-EU között?
A CERT-Bund a BSI-nál (a német szövetségi információbiztonsági hivatalnál) működő számítógépes vészhelyzeti csapat, és Németországban figyelmeztet a sebezhetőségekre. A CERT-EU az Európai Unió intézményeinek és szerveinek kiberbiztonsági szolgálata. Mindkettő olyan ajánlásokat ad ki, amelyek a vállalatok számára is hasznosak.
Mit jelent egy PHP-alkalmazás izolálása?
Az alkalmazás ezután már nem érhető el szabadon az internetről. Ez lehetséges vészhelyzeti oldallal, csak VPN-en vagy meghatározott IP-címekről történő hozzáféréssel, vagy teljes leállítással. Az a döntő, hogy a kívülről érkező kérések már ne érjék el a sebezhető PHP-folyamatot.
A CERT-EU szerint a PHP 5-ös verziók is érintettek?
A CERT-EU beszámolók szerint lehetségesnek tartotta, hogy a PHP 5-től felfelé érintettek a verziók, és erre a hivatalos közlemény előtt keringő információkra támaszkodott. A szaksajtó a PHP 5.4-ig szinte minden verziót említ. Ilyen régi verziókhoz nincsenek hivatalos frissítések.
Vannak hivatalos felismerési jegyek a támadásokra?
Nem. Eddig nincsenek közzétett, megerősített Indicators of Compromise a PHP2Shellhez. A felismerés viselkedéselemzésen alapul, például shellt indító webszerver-folyamatokon vagy új PHP-fájlokon a feltöltési mappákban.