Obsługa rozszerzonej ochrony uwierzytelniania (EPA) w usłudze

Jaki jest problem?

Istnieje klasa ataków na uwierzytelnione usługi nazywana atakami przekazującymi. Te ataki umożliwiają przeciwnikom obejście uwierzytelniania i działanie jako inny użytkownik. Ponieważ są to ataki na usługę, a nie sam protokół uwierzytelniania, obowiązek udaremnienia ataków przekazywania spoczywa na uwierzytelnionej usłudze.

Jak działają ataki przekazujące?

Gdy usługa lub aplikacja wywołuje interfejs API AcceptSecurityContext w celu uwierzytelnienia klienta, przekazuje porcję danych odebranych z wywołania klienta do InitializeSecurityContext. Protokół uwierzytelniania jest odpowiedzialny za sprawdzenie, czy podany obiekt blob pochodzi od wskazanego użytkownika. AcceptSecurityContext nie może zawierać żadnych asercji dotyczących autentyczności pozostałej części komunikatu aplikacji, którego nie widział.

Typowym błędem zabezpieczeń w aplikacjach jest traktowanie ruchu aplikacji jako uwierzytelnionego po pomyślnym uwierzytelnieniu wewnętrznego elementu „blob” w protokole uwierzytelniania. Najczęściej występuje to w przypadku aplikacji korzystających z protokołu TLS dla protokołu przewodowego. Protokół TLS często nie używa certyfikatów klienta; zapewnia serwerowi gwarancje integralności i poufności, ale nie uwierzytelniania. Uwierzytelnianie wewnętrzne zapewnia uwierzytelnianie klienta, ale tylko dla jego blobu. Nie uwierzytelnia kanału TLS ani pozostałej części zawartego w nim protokołu aplikacji.

Osoba atakująca wykonuje atak przekazujący, wstawiając obiekt uwierzytelniania z jednego źródła, w żądanie spreparowane przez tę osobę. Na przykład osoba atakująca może obserwować ruch uwierzytelniania w sieci i wstawiać go do własnego żądania na serwerze. Dzięki temu osoba atakująca może uzyskać dostęp do serwera jako klienta z przechwyconego ruchu uwierzytelniania.

Kluczową koncepcją jest to, że komunikaty uwierzytelniania SSPI są przeznaczone do uwidocznienia na przewodach; nie powinny być przechowywane w tajemnicy. Różni się to od wielu internetowych schematów uwierzytelniania, które używają tokenów elementu nośnego, które są zawsze poufne wewnątrz kanałów TLS.

Co to jest rozwiązanie?

Preferowanym rozwiązaniem jest użycie klucza sesji protokołu uwierzytelniania do podpisywania lub szyfrowania (MakeSignature, EncryptMessage) pozostałego ruchu. Ponieważ klucz sesji jest kryptograficznie uzyskiwany podczas wymiany protokołu uwierzytelniania, jego uwierzytelnione dane i każdy ruch chroniony przez ten klucz jest gwarantowany z uwierzytelnionego klienta.

Nie zawsze jest to opcja. W niektórych przypadkach format komunikatu protokołu aplikacji jest ustalony przez standardy przeznaczone dla tokenów elementu nośnego. W takim przypadku rozszerzona ochrona uwierzytelniania (EPA), znana również jako powiązanie kanału, może chronić przed przekazywaniem za pośrednictwem kanału TLS/SSL.

Co to jest EPA?

Epa kryptograficznie wiąże klucz sesji TLS z kluczem sesji protokołu uwierzytelniania, dzięki czemu protokół TLS może zapewnić to samo uwierzytelnianie klienta co klucz protokołu uwierzytelniania. Więcej informacji znajdziesz w Extended Protection for Authentication Overview.

Powiązanie usługi

Druga część EPA jest nazywana wiązaniem usług. W przeciwieństwie do wiązania kanału, nie dostarcza usłudze kryptograficznych gwarancji i służy jako ostatnia linia obrony, gdzie wiązanie kanału nie jest możliwe. Ten mechanizm umożliwia serwerowi wywołanie QueryContextAttributes w celu pobrania atrybutu SECPKG_ATTR_CLIENT_SPECIFIED_TARGET, który zawiera nazwę podaną przez uwierzytelnionego klienta do InitializeSecurityContext.

Załóżmy na przykład, że usługa mieszka za modułem równoważenia obciążenia kończącym protokół TLS. Nie ma dostępu do klucza sesji TLS i może określić tylko na podstawie powiązania kanału, że uwierzytelnianie klienta miało na celu usługę chronioną protokołem TLS. Nazwa podana przez klienta powinna być taka sama jak nazwa używana do sprawdzania poprawności certyfikatu serwera TLS. Sprawdzając, czy klient uwierzytelniał się pod nazwą zgodną z certyfikatem TLS serwera z modułu równoważenia obciążenia, usługa zyskuje wysoką pewność, że uwierzytelnianie pochodzi z tego samego klienta co kanał TLS.

W tym artykule nie omówiono, jak obsługiwać powiązanie usługi. Aby uzyskać więcej informacji, zobacz Jak: określić powiązanie usługi w konfiguracji.

Jak wspierać EPA?

Podczas wymuszania zgodności z regulacjami EPA usługi mogą zauważyć, że klienci nie uwierzytelniają się z powodu problemów ze zgodnością. W związku z tym utworzyliśmy tryb audytu EPA, w którym usługi mogą włączyć audytowanie, dając administratorom możliwość obserwowania, jak respondenci reagują, zanim zostanie wymuszone wykonywanie EPA.

Usługi firmy Microsoft obsługujące tryb inspekcji obejmują:

• LDAP

Klient

1. Użyj QueryContextAttributes(TLS), aby uzyskać wiązania kanału, wypełniając informacje unikatowe kontra punkt końcowy.
2. Wywołaj InitializeSecurityContexti przekaż powiązania kanału w SECBUFFER_CHANNEL_BINDINGS

Serwer

1. Użyj QueryContextAttributes(TLS), jak na kliencie
2. (Opcjonalnie) Ustawia tryb tylko do audytu przez wywołanie SspiSetChannelBindingFlags
3. (Opcjonalnie) Dodaj bufor wyniku powiązania kanału do buforów wyjściowych dla ASC.
4. Określ poziom EPA i inne konfiguracje, wywołując AcceptSecurityContext za pomocą SECBUFFER_CHANNEL_BINDINGS
5. (Opcjonalnie) Użyj flag do kontrolowania zachowania w przypadkach narożnych:
   • ASC_REQ_ALLOW_MISSING_BINDINGS — Nie zawiedź klientów, którzy w ogóle nic nie powiedzieli, np. starych urządzeń innych firm. Oświeceni klienci, którzy nie uzyskali SECBUFFER_CHANNEL_BINDINGS, będą wysyłać puste powiązanie zamiast niczego.
   • ASC_REQ_PROXY_BINDINGS — rzadki przypadek dla modułów równoważenia obciążenia, które kończą połączenia TLS. Nie mamy SECBUFFER_CHANNEL_BINDINGS do przekazania, ale nadal chcemy wymusić, aby klienci przesyłali żądania przez kanał TLS. Jest to najbardziej przydatne w przypadku powiązania usługi, aby upewnić się, że klient został również włożony do kanału TLS, dla którego certyfikat serwera odpowiadał naszej nazwie.

Jak egzekwować przepisy EPA?

Gdy usługa obsługuje EPA, administratorzy mogą kontrolować stan EPA przez cały sposób od inspekcji do pełnego egzekwowania prawa. Zapewnia to usługom narzędzia do oceny gotowości ekosystemu do epa, korygowania niezgodnych urządzeń i progresywnego wymuszania epa w celu ochrony środowiska.

Następujące atrybuty i wartości mogą służyć do wymuszania różnych poziomów EPA w środowisku:

Te atrybuty można połączyć z funkcjonalnością audytową w celu zbierania informacji na temat zgodności urządzeń na różnych poziomach egzekwowania przepisów EPA. Żądaną konfigurację przekażesz do SspiSetChannelBindingFlags.

• Audyt — tryb audytu może być używany w połączeniu z dowolnym z powyższych poziomów egzekwowania EPA.

Jak interpretować wyniki inspekcji EPA?

Wyniki inspekcji to zestaw flag bitowych:

Istnieją również definicje zestawów bitów:

Przepływ inspekcji

Każdy system operacyjny obsługujący te rezultaty zawsze ustawi co najmniej jeden bit z SEC_CHANNEL_BINDINGS_RESULT_VALID i SEC_CHANNEL_BINDINGS_RESULT_NOTVALID.

powiązanie kanału nie powiodło się: Test dla dowolnych bitów z SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. W przypadku powiązań, które nie służą wyłącznie do audytu, odpowiada to błędowi ASC z STATUS_BAD_BINDINGS lub SEC_E_BAD_BINDINGS.

• SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: klient i serwer wiedzą o powiązaniach kanału, ale nie zgadzają się co do kanału. Jest to przypadek ataku lub niewłaściwa konfiguracja zabezpieczeń, która jest nie do odróżnienia od ataku, ponieważ konfiguracja naruszyła protokół HTTPS w celu sprawdzenia ruchu (np. Fiddler). Może to być również klient i serwer nie zgadzający się co do unikalnych wiązań końcowych.
• SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING dzieli się na dwa przypadki:
  • Z SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORToznacza to, że klient potwierdza, że wie o powiązaniach z kanałem i stwierdził, że nie ma kanału. Może to być atak przekierowujący z usługi innej niż TLS, ale prawdopodobnie jest to niedoświadczona aplikacja działająca na kliencie, która stosuje protokół TLS, ale nie informuje o tym procesu wewnętrznego uwierzytelniania.
  • Bez SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTjest to klient, który nie jest w stanie wiązać kanałów. Wszystkie obsługiwane wersje systemu Windows są w stanie wiązać kanał, więc jest to systemu innej firmy lub system, w którym ustawiono wartość rejestru SuppressExtendedProtection. Jest to przypadek, który zostaje przekształcony w SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING, jeśli przekażesz ASC_REQ_ALLOW_MISSING_BINDINGS.

Powiązanie kanału zakończyło się pomyślnie: Jest to odwrotność sprawdzania pod kątem niepowodzenia lub testu dla SEC_CHANNEL_BINDINGS_RESULT_VALID.

• SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED jest przykładem sukcesu. Ochrona bezpieczeństwa działa (lub działa, jeśli EPA jest włączona jako tylko inspekcja).
• SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING oznacza, że ASC_REQ_ALLOW_MISSING_BINDINGS została użyta, dlatego zezwoliliśmy klientowi, który nie deklarował obsługi powiązania kanału. Klienci, którzy napotykają ten przypadek, nie są chronieni i powinni być badani, aby zobaczyć, co jest złe. Należy je zaktualizować w celu obsługi powiązania kanału lub wartość rejestru SuppressExtendedProtection powinna zostać wyczyszczona po zaktualizowaniu starszych aplikacji.
• SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY jest specjalnym przypadkiem skojarzonym z flagą ASC_REQ_PROXY_BINDINGS, która jest używana w przypadku zakończenia protokołu TLS w module równoważenia obciążenia zamiast docierania do serwera. Serwer nie może zweryfikować, czy klient korzysta z tego samego połączenia TLS, które kończy się na równoważniku obciążenia. W celach inspekcji jest to traktowane tak samo jak SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.

Zobacz też

AcceptSecurityContext

InitializeSecurityContext

TworzeniePodpisu

SzyfrujWiadomość

QueryContextAttributes

Rozszerzona ochrona w zakresie uwierzytelniania — podsumowanie

Jak określić powiązanie usługi w konfiguracji