A ConnectWise felhőszolgáltatásait érintő ellátásilánc-incidens során támadók üzleti alkalmazások korábban jóváhagyott jogosultságaival éltek vissza, hogy Microsoft 365-környezetekhez férjenek hozzá. A szolgáltató hét alkalmazásazonosságot tiltott le, miközben a vizsgálat és a helyreállítás miatt több szolgáltatása is szünetel.
Az incidens középpontjában a korábban SkyKick néven ismert ConnectWise Cloud Backup alkalmazásazonosságaihoz kapcsolódó hitelesítő adatok állnak. Az eset arra világít rá, hogy a támadók az üzleti szoftvereknek már korábban átadott hozzáféréseket is felhasználhatják a vállalati adatok elérésére.
A Huntress frissített beszámolója szerint a gyanús IP-címről közel ezer Entra-bérlőt érintő bejelentkezési aktivitást azonosítottak, és több mint 300 bejelentkezés sikeres volt. A bejelentkezések, az érintett szervezetek és az igazolt adatlopások száma azonban különböző mutató: ezekből nem következik, hogy minden megcélzott környezethez hozzáfértek, vagy minden sikeres hitelesítés után adatot is másoltak. Huntress: a ConnectWise-hitelesítő adatokkal való visszaélés vizsgálata
A ConnectWise megerősítette az alkalmazásazonosságokhoz történt jogosulatlan hozzáférést. Az október 19-i tájékoztatás szerint a Cloud Backup, a SaaS Security és a Cloud Management továbbra is szünetel, miközben a vállalat a biztonságos visszaállításon dolgozik.
A szolgáltató nem talált arra utaló jelet, hogy a nála tárolt biztonsági mentési archívumokat kompromittálták volna. Ennek az állításnak ugyanakkor meghatározott a hatóköre: a mentési archívumok biztonsága külön kérdés attól, hogy a támadók mihez férhettek hozzá a kapcsolódó Microsoft 365-környezetekben. ConnectWise Trust Center: incidens- és szolgáltatásközlemények
Egy megbízható integráció vált belépési ponttá
Technikai szempontból az a meghatározó, hogy a támadók milyen identitást használtak. Egy üzleti feladatok végrehajtására jóváhagyott alkalmazás azoktól a munkavállalóktól függetlenül is működhet, akiknek az adatait feldolgozza.
A Microsoft alkalmazásszintű, felhasználói közreműködés nélküli hozzáférésről szóló dokumentációja szerint egy szolgáltatás saját identitásával hitelesítheti magát, és hozzáférési tokent kérhet például a Microsoft Graph használatához. Az alkalmazásengedélyeket az adminisztrátor előzetesen jóváhagyja; a későbbi tokenkérésekhez nem szükséges minden alkalommal újabb felhasználói hozzájárulás. Microsoft: alkalmazásszintű hozzáférés
Ez alapvető feltétel az önállóan működő háttérszolgáltatások számára. Egy automatikus mentési folyamat nem várhat arra, hogy valaki minden engedélyezett művelet előtt jóváhagyjon egy bejelentkezést.
Ugyanez azonban biztonsági függőséget is teremt: aki megszerzi az alkalmazás hitelesítéséhez szükséges adatokat, az a hozzá rendelt jogosultságokat is gyakorolhatja.
Ez magyarázza, hogyan alakulhat ki felhős kitettség új adathalász levél vagy egy alkalmazott által jóváhagyott rosszindulatú bejelentkezés nélkül. A támadó olyan kapcsolatot használhat fel, amelyet a szervezet már jóval az incidens előtt engedélyezett.
Miért érinthet sok ügyfelet egyetlen szolgáltatói identitás?
A Microsoft alkalmazásokról és szolgáltatásnevekről szóló dokumentációja bemutatja, hogyan jön létre egy több bérlőt kiszolgáló alkalmazás helyi identitása az egyes ügyfélkörnyezetekben.
Ez a helyi objektum a service principal, vagyis szolgáltatásnév. Az adott bérlőben ehhez kapcsolódnak az alkalmazás hozzáférési jogosultságai.
Az alkalmazás globális azonosítója és a bérlőn belüli szolgáltatásnév-objektum összefügg, de nem ugyanaz. Az adminisztrátoroknak ezért az alkalmazás helyes azonosítása mellett azt is meg kell állapítaniuk, hogy annak helyi példánya milyen engedélyekkel rendelkezik. Microsoft: alkalmazásobjektumok és szolgáltatásnevek
Egy szolgáltatói hitelesítő adat kompromittálódása így a meglévő felhatalmazásokon keresztül több szervezet határát is átlépheti. Az ügyfeleknek külön Microsoft 365-környezetük lehet, miközben ugyanannak a külső alkalmazásnak az identitásától függnek.
Az alkalmazásleltár ezért üzleti kockázatkezelési kérdés is. A szolgáltató nevének ismerete mellett azt is tudni kell, milyen identitások kapcsolják a szolgáltatását a vállalati adatokhoz, mit tehetnek ezek az identitások, és ki képes letiltani őket egy incidens során.
A vizsgálat a Cloud Backup szolgáltatáson túlra is kiterjedt
A Huntress október 17-i frissítésében nagy bizonyossággal állította, hogy a támadók a ConnectWise Cloud Management Exchange Online-, Microsoft Teams- és SharePoint Online-alkalmazásaival is visszaéltek.
A ConnectWise későbbi technikai közleménye hét alkalmazásazonosságot sorol fel, amelyet október 17-én, 07:00 UTC-kor letiltott. A vizsgálat során az alábbi azonosítók alapján lehet megkülönböztetni ezeket:
| Alkalmazás | Application ID / ügyfélazonosító |
|---|---|
| ConnectWise Cloud Backup | 506e08f9-6e9a-4da4-942b-a099a03644ae |
| ConnectWise Cloud Management | 2399d300-6fca-4e6a-a686-399fefe75b83 |
| Cloud Management – MS Teams | 24205314-2b89-4e07-a2a4-579e898a5640 |
| Cloud Management – Exchange Online | b78f6a77-d4e5-46fb-87e5-d1648bd02519 |
| Cloud Management – MS Graph | 0de14c77-b9b0-4137-9360-34878a929827 |
| Cloud Management – Partner Center | 412dcf96-176d-4b3a-a1b0-4981ad66971e |
| Cloud Management – SharePoint Online | b2b55f5b-7758-4719-8d8f-88ae172e6bdb |
A lista a letiltott alkalmazásazonosságokat azonosítja; önmagában nem bizonyítja, hogy mindegyikkel minden ügyfélnél visszaéltek. Régebbi telepítésekben SkyKick Cloud Manager megjelenítési nevek is szerepelhetnek, ezért az ellenőrzést az alkalmazásazonosítóra kell alapozni. ConnectWise: technikai vizsgálati és helyreállítási útmutató
A Huntress az érintett alkalmazások letiltását javasolta törlés helyett, továbbá az október 13. óta hozzáadott alkalmazástitkok és tanúsítványok ellenőrzését, valamint a jogosulatlan hitelesítő adatok és címtárszerepkörök eltávolítását.
Az érintett integrációkat a szolgáltató hivatalos helyreállítási útmutatásáig nem szabad újra engedélyezni. A szolgáltatói letiltás mellett a helyi vállalati alkalmazások állapotát is ellenőrizni kell: a két intézkedés külön hozzáférési kontroll.
A bővülő vizsgálati kör azt is megmutatja, miért szükséges követni a frissített közleményeket. Az elsőként publikált alkalmazásazonosító nem feltétlenül írja le a teljes kitettséget.
A támadók által hozzáadott hitelesítő adatok megnehezítik a helyreállítást
A Huntress egy olyan esetet is ismertetett, amelyben egy külön ConnectWise Teams-kezelő alkalmazás globális rendszergazdai szerepkört rendelt saját magához, majd új hitelesítő adatokat adott hozzá egy partnerhez kötött, egyetlen bérlőben működő Huntress-alkalmazáshoz és egy másik alkalmazáshoz.
Ez nem bizonyítja a Huntress teljes platformjának feltörését. Egy konkrét partner környezetében található alkalmazásidentitás manipulálásáról van szó.
A Huntress arra is figyelmeztetett, hogy a naplózott privát IPv6-cím önmagában nem alkalmas a tevékenység elkövetőhöz rendelésére. Ugyanabból a Microsoft-felhőhöz tartozó címtartományból legitim ConnectWise-forgalom és más ügyfelek ettől független forgalma is megjelenhet. Huntress: az alkalmazásmódosítások és a vizsgálat korlátai
Az alkalmazott hozzáférés-fenntartási módszer ismert. A MITRE ATT&CK dokumentálja, hogy a támadók új hitelesítő adatokat adhatnak meglévő felhős alkalmazásokhoz és szolgáltatásnevekhez. Egy új alkalmazástitok vagy tanúsítvány további lehetőséget teremthet arra, hogy egy már megbízhatónak tekintett identitás nevében hitelesítsenek. MITRE ATT&CK: további felhős hitelesítő adatok
A helyreállításnak ezért a behatolás után végrehajtott változtatásokat is fel kell tárnia. Az eredeti belépési út lezárása nem érvényteleníti automatikusan egy másik alkalmazáshoz hozzáadott hitelesítő adatot.
Az incidenskezelők előtt két összekapcsolódó feladat áll: meg kell szüntetniük a kompromittált szolgáltatói integráción keresztüli hozzáférést, és azonosítaniuk kell azokat a további identitásokat, hitelesítő adatokat vagy jogosultságokat, amelyek fenntarthatják a támadó jelenlétét.
A ConnectWise arra is kitér, hogy a korábban kiadott hozzáférési tokenek lejáratukig vagy más módon történő érvénytelenítésükig még használhatók maradhatnak. Emiatt a hitelesítő adatok visszavonása sem azonos valamennyi korábbi hozzáférés azonnali megszűnésével.
Az adatkitettség mértéke továbbra is nehezen állapítható meg
A Todyl Nicholas Koken észlelésmérnökségi vezető által jegyzett vizsgálata egymástól függetlenül is azonosított jogosulatlan alkalmazásbejelentkezéseket a vállalat által felügyelt bérlőkben.
A Todyl szerint az alkalmazás engedélyei hozzáférést biztosítottak e-mailekhez és mellékletekhez, OneDrive- és SharePoint-fájlokhoz, valamint Teams-beszélgetésekhez. Az általuk vizsgált környezetekben ugyanakkor nem találtak olyan címtármódosításokat, amelyekkel a mentési alkalmazáson keresztül tartós hozzáférést alakítottak volna ki.
Ez nem mond ellent a Huntress beszámolójának, amely egy másik kezelőalkalmazás másik bérlőben megfigyelt visszaélését írta le. Eltérő megfigyelésekről van szó, amelyekből nem lehet arra következtetni, hogy minden érintett szervezetnél ugyanaz a támadási folyamat zajlott le.
A Todyl egy forenzikus korlátra is rámutatott: ahol működtek a legitim mentések, a rendelkezésre álló adatok alapján nem lehetett megbízhatóan elválasztani a szolgáltatás adatolvasási műveleteit a támadói tevékenységtől. Ezekben a bérlőkben nem gyűjtötték a részletes Microsoft Graph-tevékenységnaplókat. Todyl: a jogosulatlan ConnectWise-alkalmazáshozzáférés vizsgálata
A sikeres hitelesítés, az adatok elérésének lehetősége és az igazolt adatkiszivárogtatás három külön megállapítás. A nyilvános bizonyítékok alátámasztják a jogosulatlan hozzáférést, de nem igazolják, hogy minden elérhető postafiók vagy fájl tartalmát ellopták.
Ugyanakkor az igazolt adatlopás hiánya sem tekinthető automatikusan megnyugtató eredménynek, ha a rendelkezésre álló naplózás nem teszi lehetővé az események teljes rekonstruálását.
Miért nem oldja meg ezt a támadási útvonalat a dolgozói MFA?
A Microsoft munkaterhelés-identitásokkal kapcsolatos dokumentációja szerint az alkalmazásidentitások nem képesek úgy többtényezős hitelesítést végrehajtani, ahogyan az emberi felhasználók.
Ezért a munkavállalói hitelesítés megerősítése – bár alapvető fontosságú – önmagában nem védi meg az alkalmazások önálló hozzáférését. Egy felhasználói jelszó visszaállítása más identitást érint, mint az automatikus integráció által használt szolgáltatásnév.
A feltételes hozzáférés, vagyis a Conditional Access hatóköre is lényeges. A Microsoft szerint a munkaterhelés-identitásokra vonatkozó házirendek a szervezet saját bérlőjében regisztrált, megfelelő egybérlős szolgáltatásnevekre alkalmazhatók. A külső SaaS-alkalmazások, köztük a több bérlőt kiszolgáló alkalmazások, nem tartoznak e házirendek hatókörébe. Microsoft: feltételes hozzáférés munkaterhelés-identitásokhoz
A biztonsági csapatoknak ezért ellenőrizniük kell, hogy egy javasolt védelmi intézkedés valóban érvényes-e az érintett identitásra. Jelentős rés maradhat a védelemben, ha feltételezik, hogy a munkavállalókra vonatkozó helyalapú korlátozás vagy MFA-előírás egy külső alkalmazást is ugyanúgy szabályoz.
Milyen naplókat kell megvizsgálniuk az adminisztrátoroknak?
A Microsoft külön kategóriában kezeli a szolgáltatásnevek bejelentkezési naplóit. Ezek az események alkalmazáshitelesítést rögzítenek, és nem járnak emberi felhasználó bejelentkezésével.
Ez a különbség a vizsgálat során is meghatározó: ha csak a dolgozói bejelentkezéseket tekintik át, a releváns bizonyítékok kimaradhatnak. A szolgáltatásnév-bejelentkezések között az összevont eseményeket is ki kell bontani az egyedi időpontok ellenőrzéséhez. Microsoft: szolgáltatásnév-bejelentkezési naplók
A ConnectWise eredetileg a 144.172.64[.]128 címet jelölte meg vizsgálandó indikátorként. Október 18-i frissítésében további két címet adott hozzá:
144.172.64[.]99144.172.64[.]60
Egy ilyen címhez kapcsolódó eseményt a körülményekkel együtt kell értékelni; az egyezés önmagában nem bizonyít kompromittálódást. ConnectWise: frissített vizsgálati indikátorok
A hitelesítési naplók azonban csak a kérdés egyik részére adnak választ. A Microsoft Graph-tevékenységnaplók kérésenként tartalmazhatják az alkalmazásazonosítót, a kliens IP-címét, a kérés metódusát, a cél URI-ját és a válaszkódot.
Ezek az adatok segíthetnek összekapcsolni az alkalmazás hitelesítését a későbbi API-tevékenységgel. Gyűjtésükhöz a Microsoft Entra ID P1 vagy P2 bérlői licenc mellett megfelelő Azure-előfizetésre és naplózási célhelyre is szükség van. Microsoft: Graph-tevékenységnaplók
Biztonsági vezetői szempontból a tanulság működési jellegű: a naplózásnak a hozzáférés megszerzését és az annak birtokában végrehajtott műveleteket egyaránt le kell fednie. Egy sikeres bejelentkezésről szóló riasztás önmagában nem mutatja meg, milyen információkat kértek le.
A mentések kiesése külön üzleti kockázatot teremt
A biztonsági vizsgálat mellett az ügyfeleknek a mentési szolgáltatás kiesését is kezelniük kell.
A ConnectWise október 19-i közlése szerint az ütemezett mentések, az érintett archívumok elérése és a visszaállítás továbbra sem áll rendelkezésre. A meglévő archívumok megőrzése tehát nem jelenti azt, hogy azokból a szolgáltatásszünet alatt azonnal helyre is lehet állítani. A vállalat ekkor még nem közölt megerősített helyreállítási időpontot. ConnectWise: október 19-i szolgáltatásállapot
Ez konkrét üzletmenet-folytonossági kérdést vet fel: mennyi új adat keletkezik a normál mentés szünetelése alatt, és mi lenne helyreállítható, ha közben egy másik incidens következne be?
Ez kockázatértékelési feladat, nem annak bizonyítéka, hogy az éles Microsoft 365-adatok elvesztek. A szervezeteknek meg kell határozniuk az utolsó sikeres mentési pontot, és a szolgáltatójukkal tisztázniuk kell a ténylegesen rendelkezésre álló helyreállítási lehetőségeket.
Hosszabb távon az alkalmazásidentitások védelme megköveteli a jogosultságok felmérését, a hitelesítő adatok védelmét és a hozzáférések feladathoz szükséges minimumra korlátozását.
A szolgáltatói integrációknál ehhez egyértelmű felelőst kell kijelölni, a szolgáltatások változásakor vagy a szerződések megszűnésekor felül kell vizsgálni a hozzáféréseket, és biztonsági szempontból fontos eseményként kell figyelni az alkalmazások hitelesítését.
A vizsgálat továbbra is folyamatban van. Az azonnali feladat az egyes bérlők kitettségének megállapítása, a jogosulatlan hozzáférési lehetőségek megszüntetése és a helyreállítás ellenőrzése az integrációk újbóli engedélyezése előtt.
Az eset tágabb kérdése az, hogy a szervezetek képesek-e pontosan nyilvántartani és szükség esetén gyorsan korlátozni azokat a nagy jogosultságú alkalmazásidentitásokat, amelyek a felhős környezetükben működnek.
Eredeti cím: WARNING: ConnectWise Supply-Chain Attack Exposes Microsoft 365 Tenants
