A SharePoint Server inak biztonságossá tétele

Amikor a helyszíni SharePoint-felhasználók és rendszergazdák feltöltenek egy fájlt, azt vagy egy harmadik féltől származó víruskeresővel, vagy AMSI-kompatibilis motorokkal (például a Microsoft Defenderrel) ellenőrzik. Ha a fájl átmegy ezen az első ellenőrzésen, akkor azt kezelettnek tekintik. Egyszer megtisztítva, örökre tiszta. Pontosan ez a feltételezés teszi lehetővé, hogy a rosszindulatú programok és a zsarolóprogramok hasznos terhelései észrevétlenül maradjanak a tárhelyben; néha akár évekig is.

A Microsoft ezt egyértelműen kijelenti: a SharePoint rosszindulatú programok elleni védelme ugyan csökkentheti a károkat, de nem szolgál egyetlen védelmi pontként.

A BFSI (banki, pénzügyi szolgáltatások és biztosítás), az egészségügy, a közszféra, valamint az OT (operatív technológia) vagy a kritikus infrastruktúra területén a veszélynek kitett adatok közé tartoznak a jogszabályi bejelentések, a betegnyilvántartások, az ügyiratok és a műszaki dokumentáció. Mindezek egy olyan adattárban találhatók, amely évről évre folyamatosan bővül, miközben senki sem tér vissza ahhoz, hogy újra átvizsgálja a már benne lévő adatokat.

A következőkben három dologra fogunk összpontosítani: hogyan működik valójában a SharePoint víruskeresése, mit nem fed le, és hogyan kellene kinéznie egy többszintű, hatékony SharePoint-fájltár-biztonsági rendszernek.

Az Enlyft technológiai bevezetési adatai 256 295 olyan vállalatot fednek le, amelyek jelenleg a Microsoft SharePoint rendszert használják, és amelyek az informatikai szolgáltatásoktól kezdve a banki szektoron, az egészségügyön, az olaj- és gáziparon át egészen a közszféráig terjedő iparágakban működnek. Ezek a vállalatok általában 50–200 főt foglalkoztatnak, és 1 millió–10 millió dollár közötti árbevétellel rendelkeznek.

Pontosan ez a méret az, ami miatt a támadók odafigyelnek a SharePoint-tárolókra, és azokat kiemelt fontosságú célpontoknak tekintik.

A fentiekből egyáltalán nem következik, hogy a SharePoint nem védi a szervereit, vagy elhanyagolná a fájlok biztonságát. A Microsoft dokumentációja szerint a SharePoint Server kétféle vizsgálati felülettel Server :

• A VSAPI (Virus Scanning API) egy SharePoint-víruskereső-integrációs felület, amely lehetővé teszi a kompatibilis, harmadik féltől származó víruskereső szoftverek számára, hogy olyan műveletek során, mint például a feltöltés és a letöltés, ellenőrizzék a dokumentumokat.

• Az AMSI (Antimalware Scan Interface) egy Microsoft által fejlesztett rosszindulatú programok elleni integrációs keretrendszer, amely lehetővé teszi a SharePoint Server a támogatott tartalomműveletek során fájlokat továbbítson AMSI-kompatibilis víruskereső motorokhoz (például a Microsoft Defenderhez) rosszindulatú programok ellenőrzése céljából.

A SharePoint Server úgy konfigurálható, hogy VSAPI-t, AMSI-t vagy az automatikus módot használja. Függetlenül attól, hogy melyik opció van beállítva, egy fájlt egyszerre csak egy vizsgálati motor értékel.

A vizsgálat eseményalapú, és akkor indul el, amikor a felhasználók dokumentumokat töltenek fel vagy töltenek le; nem pedig visszamenőlegesen vagy rendszeres időközönként. A fájlt kizárólag egy motor (a Microsoft Malware Protection Engine, közismert nevén MpEngine.dll) vizsgálja meg.

Főbb tanulság: A fájlokat egyetlen motorral vizsgálják át feltöltéskor vagy letöltéskor, az adott motor aktuális szignatúráinak és észlelési képességeinek felhasználásával.

Ez a módszer nem arra szolgál, hogy olyan, fájlokon keresztül terjedő fenyegetéseket észleljen, amelyeket kifejezetten az adott észlelési algoritmus kijátszására terveztek. Különösen a fejlett, tartós fenyegetések gyakran éppen ezt a korlátot használják ki, és hosszú ideig észrevétlenül maradnak.

Ez a kitartás lehetőséget teremt a támadók számára, hogy a megbízható SharePoint-tartalmakat támadási célokra használják fel. Már vannak dokumentált támadások, amelyek során a támadók feltört SharePoint-webhelyeket használtak fel adathalász dokumentumok és rosszindulatú linkek tárolására.

Egy zero-day fájl ugyanúgy zero-day a vizsgálaton, mint egy tiszta fájl, egyszerűen azért, mert még nincs olyan víruskereső motor, amely jelzéssel ellátná. Mivel pedig a SharePoint később nem vizsgálja újra a meglévő tartalmakat, egy zero-day , amely az első napon átmegy a vizsgálaton, a kétszázadik napon sem kerül újra ellenőrzésre, még akkor sem, ha a gyártó kiad egy olyan szignatúra-frissítést, amely felismerné azt.

Az ismeretlen fenyegetések is ugyanazon a logikán alapulnak. Mivel nincs hozzájuk kapcsolva szignatúra, a statikus elemzés (amit a víruskereső motorok végeznek) nem képes felismerni a fenyegetést.

Megjegyzés: ezek nem hibák, hanem a rendszer hatókörének hiányosságai. Server SharePoint Server beépített víruskeresőjét úgy tervezték, hogy meghatározott interakciós pontokon időszakos ellenőrzéseket végezzen, nem pedig arra, hogy a folyamatosan bővülő, verziókezelés alatt álló adattárat a változó fenyegetési környezethez igazodva folyamatosan újraellenőrizze.

2025 júliusában a Microsoft nyilvánosságra hozta, hogy aktívan kihasználják a helyszíni SharePoint Server érintő, hitelesítés nélküli távoli kódvégrehajtási sebezhetőségi láncot: CVE-2025-49706, CVE-2025-49704, amelyhez később a CVE-2025-53770 és a CVE-2025-53771 is csatlakozott. A sebezhetőség kihasználásához nem volt szükség hitelesítő adatokra vagy bejelentkezésre.

A Microsoft ezt követően kiadott egy javítást, és a kihasználási lánc elnevezést kapott: ToolShell.

Az Infosecurity Magazine által idézett Eye Security elemzése szerint 41 országban, 145 szervezetnél összesen 396 fertőzött rendszert tártak fel. A kormányzati szektor szenvedte el a legnagyobb károkat: a megerősített fertőzések 30%-a ide tartozott, és egyedül az Egyesült Államok adta a teljes szám 31%-át. Ettől függetlenül a Shadowserver Foundation arról számolt be, hogy több mint 10 700 SharePoint-példány maradt sebezhető állapotban, és bárki elérhette őket, aki ugyanazt a kihasználási láncot futtatta, még azután is, hogy nyilvánosságra került a sebezhetőség, amely több száz szervezetet érintett. A Storm-2603, az exploit mögött álló csoportok egyike, ezt a sebezhetőséget Warlock ransomware-terheléssé alakította át.

Miután bejutottak, a Storm-2603 ellopott hitelesítő adatokat és legitim rendszergazdai eszközöket használt fel a rendszereken belüli oldalirányú terjedéshez. Ez a mozgás nem keltett gyanút, mivel olyan eszközökre támaszkodott, amelyeknek ott kellett lenniük. A Storm-2603 web-shell-eket telepített, és fontos adatokat szivárogtatott ki. A sebezhetőség kijavítása után is megőrizték a hozzáférést, mivel a támadók már korábban ellopták azokat a kulcsokat, amelyek az érvényes hitelesítési tokenek hamisításához szükségesek voltak.

A ToolShell négy, egymáshoz kapcsolódó CVE-re épül, amelyekbe már a kezdetektől fogva beépítették a javítások megkerülését. A CVE-2025-53770 és -53771 kifejezetten azért léteznek, mert a CVE-2025-49704 és -49706 eredeti javításai megkerülhetők voltak.

Ami igazán számít, az az, hogy egy támadó kétszer is gyorsabban alkalmazkodott, mint a javítási ciklus, ugyanazon a célponton, néhány héten belül.

Az olyan statikus ellenőrzési módszerek, mint az egyes antivírusprogramok, amelyek egy fájlt egyszer ellenőriznek egy adott gyártó aláírásai alapján, eleve nem arra lettek kifejlesztve, hogy kiszűrjék a szerveroldali támadási láncokat. Ráadásul nem képesek védelmet nyújtani olyan támadó ellen, aki a javítás kiadása után visszatér egy, a javítást megkerülő módszerrel.

A ToolShell jól szemlélteti, hogy milyen kifinomult támadásokra számíthatunk manapság kifejezetten a SharePoint-kiszolgálók ellen. Nincs okunk feltételezni, hogy ez volt az utolsó ilyen jellegű támadás. Vajon az ezeken a kiszolgálókon tárolt adatokat olyan védelem óvja, amely lépést tart a fejleményekkel, vagy csupán egy egyszeri ellenőrzés, ami után a dolgot lezártnak tekintik?

Igazság szerint a ToolShell nem egy olyan rosszindulatú dokumentum volt, amely átcsúszott volna a feltöltéskor végzett ellenőrzésen. De a támadók által elhelyezett webes shell (a spinstall0.aspx és annak átnevezett változatai)? Az már egy fájl. Ott maradt a szerveren, és hogy észlelték-e, az a korábban leírt korlátoktól függött: egy ellenőrzőmotor, egyszeri ellenőrzés, egy adott időpontban.

Ez az a mechanizmus, amely összeköti ezt az esetet a tágabb értelemben vett érveléssel. A javítás kifejezetten a ToolShell-sebezhetőségi láncot zárja le. A tárolóban már meglévő, még nem vizsgált következő fájlra azonban nincs hatással.

A fentiak közül egyik sem számít igazán azoknál a tartalmaknál, amelyek 2023 óta érintetlenül állnak, hacsak azokat ténylegesen be nem szkennelik.

Ez az a szint, amelyet a SharePoint beépített víruskeresője nem tud lefedni: a tárolt tartalmak – beleértve a verziótörténetben megőrzött régebbi verziókat is – rendszeres vagy folyamatos ellenőrzése, nem csupán a feltöltés vagy letöltéskor. A valós idejű, ütemezett és igény szerinti újraellenőrzés pótolja ezt a hiányosságot, mivel az adatbázisok frissülésekor rendszeresen ellenőrzi a fájlokat.

Ezek az ellenőrző mechanizmusok külön-külön mindegyike egy-egy, korábban említett konkrét biztonsági rést szüntet meg. Együttesen pedig pontosan azt a többszintű védelmet alkotják, amelyre a Microsoft saját dokumentációja is utal, amikor kijelenti, hogy a beépített víruskereső nem szolgálhat egyetlen védelmi pontként.

MetaDefender Storage Security többféle modellbenis bevezethető: fizikai szervereken közvetlen hardveres telepítéssel, virtualizációs platformokon (VMware, Hyper-V és XenServer kompatibilis), a főbb felhőszolgáltatók IaaS (Infrastructure as a Service) szolgáltatásain keresztül, illetve konténeres telepítéssel Kubernetes-klaszterekben.

Ez az ellenőrzőlista a CISA ToolShell-kizsákmányolással kapcsolatos iránymutatásán alapul.

1. Ellenőrizze a javítás állapotát.

Az összes kihasznált CVE-hez elérhetőek a biztonsági frissítések, de a még nem javított szerverek továbbra is ki vannak téve a ToolShell támadásainak. Telepítse a Microsoft biztonsági frissítéseit az összes érintett Server .

2. Ellenőrizze, hogy az AMSI be van-e állítva.

A telepített, de helytelenül konfigurált AMSI ugyanolyan biztonsági rést hagy, mintha egyáltalán nem lenne AMSI. Győződjön meg arról, hogy az AMSI-integráció engedélyezve van, és minden SharePoint-kiszolgálón telepítve van egy vírusirtó megoldás.

3. Az ASP.NET-gépkulcsok cseréje

Az ellopott gépi kulcsok lehetővé teszik a támadók számára, hogy érvényes hitelesítési tokeneket hamisítsanak még a szerver frissítése után is. A frissítés önmagában nem érvényteleníti a már ellopott kulcsokat. Cserélje ki a gépi kulcsokat, telepítse a biztonsági frissítést, majd cserélje ki újra a gépi kulcsokat. Minden kulcscsere után indítsa újra az IIS-t az iisreset.exe parancs segítségével, hogy eltávolítsa a rosszindulatú bejegyzéseket az applicationHost.config és a web.config fájlokból.

4. Kézzel keresse meg a korábbi támadásra utaló jeleket.

A CISA felhívja a figyelmet arra, hogy a kampányban használt .dll-fájlok segítségével megszerezhetők a rendszerkulcsok. A javítások nem távolítják el a szerverre már elhelyezett kártékony kódot. A rendszereket és az egyes fájlokat ne csupán a sebezhetőség szempontjából vizsgálják meg, hanem az IOC-k (behatolásra utaló jelek) szempontjából is.

5. Ellenőrizze, hogy vannak-e már kivezetett vagy támogatásuk lejárt verziók.

Egyes SharePoint-példányok életciklusuk végéhez értek, és – függetlenül attól, hogy kihasználják-e őket – többé nem kapnak biztonsági frissítéseket. Ellenőrizze, hogy a vállalat által használt verziók még támogatottak-e. Ha nem, tegye meg a szükséges lépéseket.

6. Az ismert jelzők ellenőrzése a naplóbejegyzésekben

A CISA azonosította a kampányhoz kapcsolódó konkrét lekérdezési mintákat és IP-címeket. Keresse meg a CISA hivatkozásainak megfelelő lekérdezéseket a naplófájlokban.

7. Az adminisztrátori és az elrendezési jogosultságok ellenőrzése.

A kár mértékének korlátozása érdekében ellenőrizze, kinek vannak elrendezési és rendszergazdai jogosultságai a SharePointon, és vonja vissza azokat a hozzáférési jogosultságokat, amelyekre nincs aktív szükség.

8. Vizsgálja meg, mi van már tárolva, ne csak azt, ami jelenleg látható

A fentiak mind a támadási láncra vonatkoznak. Egyik sem vizsgálja a dokumentumtárakban már meglévő tartalmakat, beleértve azokat a fájlokat is, amelyek bármelyik javítás megjelenése előtt készültek.

Állapítsa meg, hogy a tárolóban található tartalmakat a vonatkozó javítások és aláírásfrissítések óta újra beolvasották-e, vagy továbbra is az eredeti, esetleg elavult vizsgálati eredményt hordozzák-e.