Kiterjesztett hitelesítés (EPA) támogatása egy szolgáltatásban
| Funkció | A következőkre vonatkozik: |
|---|---|
| EPA | az összes támogatott Windows operációs rendszer |
| EPA ellenőrzési mód | Windows Server 2019 Windows Server 2022 Windows Server 23H2 |
Mi a probléma?
A hitelesített szolgáltatások elleni támadások egy osztálya, az úgynevezett továbbítási támadások. Ezek a támadások lehetővé teszik a támadók számára, hogy megkerüljék a hitelesítést, és más felhasználóként viselkedjenek. Mivel ezek a szolgáltatásra irányuló támadások, és nem maga a hitelesítési protokoll, a hitelesített szolgáltatáson múlik, hogy meghiúsítsa a támadások továbbítását.
Hogyan működnek a továbbítási támadások?
Amikor egy szolgáltatás vagy alkalmazás meghívja az API-t AcceptSecurityContext az ügyfél hitelesítéséhez, az ügyfél hívásából kapott adatok blobját továbbítja az InitializeSecurityContext. A hitelesítési protokoll feladata annak ellenőrzése, hogy a megadott blob a megadott felhasználótól származik-e. Az AcceptSecurityContext nem tudja érvényesíteni az alkalmazásüzenet fennmaradó részének hitelességét, amelyet nem látott.
Az alkalmazások gyakori biztonsági hibája, hogy az alkalmazás forgalmát hitelesítettként kezeli a belső hitelesítési protokoll blobjának sikeres hitelesítése után. Ez leggyakrabban azokban az alkalmazásokban fordul elő, amelyek TLS-t használnak a vezetékes protokollhoz. A TLS általában nem használ ügyféltanúsítványokat; integritási és titoktartási garanciákat biztosít a kiszolgáló számára, de hitelesítést nem. A belső hitelesítés ügyfélhitelesítést biztosít, de csak a blob számára. Nem hitelesíti a TLS-csatornát vagy az abban található alkalmazásprotokoll fennmaradó részét.
A támadó úgy hajt végre továbbítási támadást, hogy egy hitelesítési blobot szúr be egy forrásból egy támadó által létrehozott kéréssel. A támadó például megfigyelheti a hálózati hitelesítési forgalmat, és beszúrhatja a kiszolgálóra irányuló saját kérésébe. Ez lehetővé teszi, hogy a támadó ügyfélként hozzáférjen a kiszolgálóhoz a rögzített hitelesítési forgalomból.
A fő koncepció itt az, hogy az SSPI hitelesítési üzenetek úgy vannak kialakítva, hogy a vezetéken legyenek közzétéve; nem várható, hogy titokban tartsák őket. Ez különbözik számos olyan webalapú hitelesítési sémától, amelyek tulajdonosi jogkivonatokat használnak, amelyeket mindig bizalmasan kezelnek a TLS-csatornákon belül.
Mi a megoldás?
Az előnyben részesített megoldás a hitelesítési protokoll munkamenet-kulcsának használata más forgalom aláírására vagy titkosítására (MakeSignature, EncryptMessage). Mivel a munkamenetkulcs kriptográfiailag származik a hitelesítési protokoll cseréje során, a hitelesített adatok és a kulcs által védett forgalom garantáltan a hitelesített ügyféltől származik.
Ez nem mindig lehetőség. Bizonyos esetekben az alkalmazásprotokoll-üzenet formátumát a tulajdonosi jogkivonatokhoz tervezett szabványok rögzítik. Ebben az esetben a Kiterjesztett hitelesítésvédelem (EPA), más néven Csatornakötés védelmet nyújt a TLS/SSL-csatornán keresztüli továbbítás ellen.
Mi az EPA?
Az EPA kriptográfiailag a TLS-munkamenetkulcsot a hitelesítési protokoll munkamenetkulcsához köti, így a TLS ugyanazt az ügyfél-hitelesítést biztosítja, mint a hitelesítési protokoll kulcsa. További információkért lásd A hitelesítéshez szükséges kiterjesztett védelem áttekintése.
Szolgáltatáskötés
Az EPA második részét szolgáltatáskötésnek nevezzük. A Csatornakötéssel ellentétben ez nem nyújt titkosítási garanciákat a szolgáltatás számára, és védelmet nyújt a végső megoldásnak, ahol a csatornakötés nem lehetséges. Ez a mechanizmus lehetővé teszi a kiszolgáló számára, hogy meghívja a QueryContextAttributes-t az SECPKG_ATTR_CLIENT_SPECIFIED_TARGET attribútum lekérésére, amely tartalmazza annak a névnek az értékét, amelyet az azonosított kliens adott meg az InitializeSecurityContext-nek.
Tegyük fel például, hogy egy TLS-kapcsolatot befejező terheléselosztó mögötti szolgáltatás. Nem rendelkezik hozzáféréssel a TLS-munkamenetkulcshoz, és csak a csatornakötésből tudja megállapítani, hogy az ügyfél hitelesítése TLS-védelem alatt álló szolgáltatáshoz készült. Az ügyfél által megadott névnek meg kell egyeznie a TLS-kiszolgáló tanúsítványának érvényesítéséhez használt névvel. Annak ellenőrzésével, hogy az ügyfél a kiszolgáló TLS-tanúsítványának megfelelő névre hitelesített-e a terheléselosztótól, a szolgáltatás nagy megbízhatóságot szerez abban, hogy a hitelesítés a TLS-csatornával azonos ügyféltől származik.
Ez a cikk nem tárgyalja, hogyan támogatják a szolgáltatáskötést. További információkért lásd a Hogyan kell: a szolgáltatás kötésének megadása a konfigurációban.
Hogyan támogatja az EPA-t?
Az EPA kényszerítésekor előfordulhat, hogy a szolgáltatások kompatibilitási problémák miatt nem hitelesítik az ügyfeleket. Ezért létrehoztunk egy EPA-naplózási módot, ahol a szolgáltatások engedélyezhetik a naplózást, így a rendszergazdák figyelhetik, hogyan reagálnak az ügyfelek az EPA kényszerítése előtt.
A naplózási módot támogató Microsoft-szolgáltatások a következők:
Jegyzet
Az alábbiakban az EPA-naplózási funkciók engedélyezésének választható lépéseit találja. Vegye figyelembe, hogy az EPA naplózási funkcióinak engedélyezése az EPA kényszerítése nélkül nem véd a továbbítási támadások ellen. Azt javasoljuk, hogy azok a szolgáltatások, amelyek először csak naplózási módban engedélyezik az EPA-t, később tegyenek lépéseket az inkompatibilis ügyfelek szervizelésére, és végül szigorúan kényszerítse az EPA-t a lehetséges továbbítási támadások elkerülése érdekében.
Jegyzet
A AcceptSecurityContext metódusba átadott csatornakötéseknek nem kell kizárólag naplózási kötéseknek lenniük a naplózási eredmények eléréséhez. A szolgáltatások auditálási módot futtathatnak, miközben továbbra is érvényesítik az EPA-t.
Ügyfél
- A QueryContextAttributes(TLS) használata csatornakötések lekéréséhez (egyedi és végpont kitöltése)
- Hívja meg az InitializeSecurityContext-et, és adja át a csatornakötéseket a SECBUFFER_CHANNEL_BINDINGS-ba.
Kiszolgáló
- QueryContextAttributes(TLS) használata az ügyfélhez hasonlóan
- (Opcionálisan) Audit módban futtatja, csak naplózást engedélyezve SspiSetChannelBindingFlags meghívásával.
- (Opcionálisan) Adjon hozzá csatornakötési eredménypuffert az ASC kimeneti puffereihez.
- Határozza meg az EPA szintet és az egyéb konfigurációkat az AcceptSecurityContext meghívásával SECBUFFER_CHANNEL_BINDINGS
- (Opcionálisan) A jelölőkkel szabályozhatja a viselkedést a sarkokban:
- ASC_REQ_ALLOW_MISSING_BINDINGS – Ne okozzon hibát azoknak az ügyfeleknek, akik egyáltalán nem mondtak semmit, például régi harmadik fél által gyártott eszközöknek. Azok a felvilágosult ügyfelek, akik nem kapták meg a SECBUFFER_CHANNEL_BINDINGS, üres kötést küldenek a semmi helyett.
- ASC_REQ_PROXY_BINDINGS – Ritka eset a TLS-nek a terheléselosztók megszüntetésére. Nincs átadandó SECBUFFER_CHANNEL_BINDINGS, de továbbra is meg akarjuk követelni, hogy az ügyfelek belefoglalják a kérésüket egy TLS-csatornába. Ez a szolgáltatáskötések esetében hasznos annak biztosítása érdekében, hogy az ügyfél olyan TLS-csatornába is bekerüljön, amelyhez a kiszolgáló tanúsítványa megfelelt a nevünknek.
Hogyan érvényesíti az EPA-t?
Ha egy szolgáltatás támogatja az EPA-t, a rendszergazdák a naplózástól a teljes végrehajtásig szabályozhatják az EPA állapotát. Ez eszközöket biztosít a szolgáltatások számára az ökoszisztéma EPA-ra való felkészültségének értékeléséhez, az inkompatibilis eszközök szervizeléséhez és az EPA fokozatos kényszerítéséhez a környezetük védelme érdekében.
A következő attribútumok és értékek használhatók az EPA különböző szintjeinek kényszerítésére a környezetben:
| Név | Leírás |
|---|---|
| Egyik sem | A rendszer nem végez csatornakötés-ellenőrzést. Ez a nem frissített kiszolgálók viselkedése. |
| Engedélyez | Minden frissített ügyfélnek csatornakötési információkat kell megadnia a kiszolgálónak. A nem frissített ügyfeleknek nem kell ezt megtenniük. Ez egy köztes lehetőség, amely lehetővé teszi az alkalmazások kompatibilitását. |
| Szükséges | Minden ügyfélnek meg kell adnia a csatornakötési információkat. A kiszolgáló elutasítja a nem ilyen ügyfelektől érkező hitelesítési kéréseket. |
Ezek az attribútumok összekapcsolhatók a naplózási funkcióval, hogy információkat gyűjtsenek az eszközkompatibilitásról az EPA-kényszerítés különböző szintjein. A kívánt konfigurációt adja át a SspiSetChannelBindingFlags-ba.
- Ellenőrzési – Az ellenőrzési mód a fenti EPA-végrehajtási szintek bármelyikével együtt használható.
Hogyan értelmezi az EPA auditeredményeket?
Az audit eredmények egy bitjelző készlet.
| Zászló | Leírás |
|---|---|
| Az ügyfél támogatásának csatornakötési eredménye | Az ügyfél jelezte, hogy képes csatornakötésekre. |
| Biztonsági csatorna kötési eredménye nincs jelen | Az ügyfél nem biztosított kötést külső csatornához. |
| SEC_CSATORNA_CSATOLÁS_Eredmény_NemÉrvényes_NemEgyezés | Az ügyfélkötések a kiszolgálótól eltérő csatornát jelölnek. |
| SEC_CSATORNA_KÖTÉSVÉDELMI_EREDETMÉNY_NEMÉRVÉNYES_HIÁNYZIK | A csatornakötés SEC_CHANNEL_BINDINGS_RESULT_ABSENTmiatt meghiúsult. |
| SEC_CSATORNA_KÖTÉSEK_EREDETMÉNY_ÉRVÉNYES_EGYEZÉS | A csatornák kötése sikeresen megtörtént. |
| SEC_CSATORNA_KÖTÉS_EREDMÉNY_ÉRVÉNYES_PROXY | Az ügyfél egy külső csatornához kötést jelzett, amelyet a ASC_REQ_PROXY_BINDINGSeredményeként hagytak jóvá. |
| SEC_CSATORNA_KÖTÉSEK_EREDEMLÉNY_ÉRVÉNYES_HIÁNYOZIK | A csatornakötés ASC_REQ_ALLOW_MISSING_BINDINGSmiatt sikeresen teljesült. |
A bitkészletekhez definíciók is tartoznak:
| Zászló | Leírás |
|---|---|
| SEC_CSATORNA_KÖTÉSEK_ÉRVÉNYES_EREDMÉNY | Az összes SEC_CHANNEL_BINDINGS_VALID_* eset tesztelésére szolgál. |
| SEC_CSATORNA_KÖTÉSEK_EREDEMÉNYE_NEM_ÉRVÉNYES | A SEC_CHANNEL_BINDINGS_NOTVALID_* összes eset tesztelésére használatos. |
Ellenőrzési folyamat
Minden olyan operációs rendszer, amely támogatja az eredményt, mindig beállít legalább egy bitet a SEC_CHANNEL_BINDINGS_RESULT_VALID és a SEC_CHANNEL_BINDINGS_RESULT_NOTVALIDközül.
Csatornakötés sikertelen: Vizsgálat a SEC_CHANNEL_BINDINGS_RESULT_NOTVALIDbármely bitjére. A nem csak naplózási célú kapcsolatok esetében ez az ASC STATUS_BAD_BINDINGS vagy SEC_E_BAD_BINDINGShibával való meghiúsulásának felel meg.
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: Az ügyfél és a kiszolgáló is tud a csatornakötésekről, de nem ért egyet a csatornával. Ez a támadási eset vagy egy nem megfelelő biztonsági konfiguráció, amely megkülönböztethetetlen a támadástól, mert a konfiguráció feltörte a HTTPS-t a forgalom vizsgálatához (pl. Fiddler). Előfordulhat, hogy az ügyfél és a kiszolgáló nem ért egyet az egyedi és a végpontkötésekkel kapcsolatban.
-
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING két esetre oszlik:
- A SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTazt jelenti, hogy az ügyfél igazolja, hogy ismeri a csatornakötéseket, és kijelentette, hogy nincs csatorna. Ez lehet egy nem TLS-szolgáltatástól érkező továbbítási támadás, de valószínű, hogy egy nem felügyelt alkalmazás fut azon az ügyfélen, amely TLS-t végez, de nem mondja el a belső hitelesítést.
- SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTnélkül ez egy olyan ügyfél, amely nem képes a csatornakötésekre. Minden támogatott Windows-verzió képes csatornakötésre, ezért ez vagy külső féltől származó, vagy olyan rendszer, amely rendelkezik a SuppressExtendedProtection beállításjegyzék-értékkel. Ez az eset ASC_REQ_ALLOW_MISSING_BINDINGSátadásakor válik SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING-é.
csatornakötés sikeres volt: Ez a hibaellenőrzés inverze, vagy a SEC_CHANNEL_BINDINGS_RESULT_VALIDtesztelése.
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED a sikeres eset. A biztonsági védelem működik (vagy működik, ha az EPA csak naplózási funkcióként van engedélyezve).
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING azt jelenti, hogy a ASC_REQ_ALLOW_MISSING_BINDINGS át lett adva, ezért engedélyeztünk egy olyan ügyfelet, amely nem igényelt támogatást a csatornakötéshez. Az ilyen eseteket elérő ügyfelek nem védettek, ezért meg kell vizsgálni, hogy mi a probléma. Ezeket vagy frissíteni kell a csatornakötés támogatásához, vagy a hibás alkalmazások frissítése után törölni kell a SuppressExtendedProtection beállításjegyzék-értéket.
- SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY egy speciális eset, amely a jelölővel ASC_REQ_PROXY_BINDINGS van társítva, amikor a TLS a terheléselosztónál fejeződik be, nem érve el a kiszolgálót. A kiszolgáló nem tudja ellenőrizni, hogy az ügyfél ugyanazt a TLS-kapcsolatot használja-e, mint a terheléselosztónál. Auditálási célokra ez úgy van kezelve, mint SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.