ROPC – czy polisa 'Block Legacy Authentication’ ma sens?
ROPC, czyli „Resource Owner Password Credentials”- jest częścią OAuth 2.o i daje możliwość logowania aplikacji bezpośrednio podając hasło. zgodnie z opisem na stronie „it’s incompatible with multifactor authentication (MFA)„.
do tego wpisu usiadłem po śledztwie – jak to jest, że niektóre konta logują się bez MFA pomimo, że jest ustawiona polityka Conditional Access zarówno wymuszająca MFA jak i wyłączająca legacy authentication. pomimo to urządzenia nadal mogą logować się do Exchange, bez MFA, korzystając z czystego SMTP…
w EID wygląda to tak:
w tym scenariuszu, to konto reprezentujące skaner, do realizacji scan-to-email – MFD (Multi-Function Device) nadal spokojnie wysyła skany przez EXO. to wzbudziło moją ciekawość – czemu żadna z polityk nie zadziałała, i czemu legacy authentication nadal jest możliwe – a koniec końców: w jaki sposób można omijać CA wyznaczającą politykę bezpieczeństwa? co tak na prawdę blokuje 'block legacy authentication’, skoro nie zablokował tego połączenia?
jak to się dzieje?
odpowiedź na część problemu już jest, ze wspomnianego artykułu:
- ROPC nie jest zgodne z MFA – mówiąc inaczej, omija je
- przykładem kiedy jest wykorzystywane – jest użycie ’hasła aplikacji’ dla konta
a co z 'legacy authentication’? jak zwykle chodzi o semantykę i prawidłowe zrozumienie modelu ISO/OSI albo 4/5 warstwowego modelu Internetowego. najpierw ciekawe spojrzenie któreż to protokoły mają status 'legacy’:
- Autodiscover
- Exchange ActiveSync
- Exchange Online PowerShell
- Exchange Web Services
- IMAP
- MAPI over HTTP
- Offline Address Book
- Other Clients
- Outlook Anywhere (RPC over HTTP)
- POP
- Reporting Web Services
- SMTP
- Universal Outlook
…w zasadzie cały Exchange do niedawna… (czym jest 'Universal Outlook’ wie chyba tylko developer który implementował filtr protokołów w EID), co ciekawe 'legacy’ są tylko protokoły związane z Exchange, co pokazuje równocześnie priorytetowy obszar do zaadresowania elementów bezpieczeństwa. o ile ’łamie się ludzi a nie systemy’, co pokazują statystyki najpopularniejszych metod włamania, to SMTP pozostaje cały czas najłatwiejsze dla bruteforce. Microsoft
to z czego w końcu korzysta Exchange Online, skoro wszystko jest poblokowane? jak wymienia się z innymi serwerami, skoro nawet SMTP jest na liście?
po pierwsze, trzeba przyjąć do wiadomości, że chodzi o uwierzytelnienie. nie została wyłączona obsługa całego protokołu, również Conditional Access nie pełni roli firewalla – używany jest do weryfikacji uwierzytelnienia (trochę kłamię, bo obsługa sesji to w sumie sporo więcej, ale to advanced feature więc pomijam tutaj). nie chodzi więc np. o SMTP jako protokół wymiany informacji a o SMTP AUTH – i wyłączenie tych starych, jak PLAIN czy LOGIN.
podobnie Outlook – nadal używa jakiejś tam wersji MAPI do komunikacji. problem z ogarnięciem jak zwykle ma naturę semantyczno-marketingową:
- MAPI jest protokołem aplikacji, językiem jakim rozmawia Outlook z Exchange
- do tego jest warstwa transportowa – i ta mocno się zmieniła powolnie transformując od paskudnego RPC, przez zamknięcie w HTTP, potem silniejszą integrację z MAPI… na dziś dzień te warstwy nie są już tak oczywiste bo zbyt to jest wymieszane, stąd twory nazewnicze
- i do tego dochodzi uwierzytelnienie. które jest jakby obok, albo bardziej dosłownie – na froncie. stosuje swoje własne protokoły, które również operują w kilku warstwach, a po zakończonym procesie uwierzytelnienia przekazują pałeczkę do części operującej transportem i aplikacją.
kiedy dokona się analizy i porozkłada się pojedyncze nazwy na ich składowe – zaczyna powoli być jasne które elementy podlegają, a które nie podelagają polityce Conditional Access. CA zajmuje się wyłącznie ostatnim z wymienionych – uwierzytelnieniem i nie dotyka warstw transportu ani aplikacji wykorzystywanych do komunikacji.
kiedy jeszcze używany jest ROPC, poza scenariuszem z EXO? przez developerów/adminów tworzących zapytania przez SPN aplikacji.
w-files
niby szczegół. ale nadal pozostaje wiele niedomówień w kwestii tego kiedy i co de facto zadziała, co ma bezpośrednie przełożenie na bezpieczeństwo. w jaki sposób mechanizmy CA wiedzą żeby nie przetwarzać polityki MFA ale uznać inną?
wszystko jasne z ROPC, tak? ot, przykład z innego tenanta, skonfigurowanego zasadniczo tak samo:
i tutaj ROPC, który wedle dokumentacji nie obsługuje MFA – nagle magicznie zaczyna je obsługiwać i żądać. co więcej – nagle został zaliczony do 'legacy’ – ale jak, skoro ROPC nie jest 'legacy’, bo jest częścią oAuth2?
albo np. Microsoft zaznacza, że basic authentication jest wyłączony. skoro został wyłączony.. to czemu nadal wszędzie jest włączony i po co polisa na coś, co niby od dawna nie powinno działać? pojawiła się polityka 'block legacy authentication’ ale to nie jest wyłącznie. kolejne zdanie, z tego samego artykułu, również idiotyczne:
„We also disabled SMTP AUTH in all tenants where it wasn’t being used.”
nie chce mi się teraz rozkodowywać ruchu i sprawdzać, ale w sumie nie muszę, bo standardy 'starego internetu’ są opisywane w RFC i SMTP AUTH jest podstawową komendą. skróty myślowe w dokumentacji technicznej prowadzą do zamieszania i dezorientacji. generyczny log pokazujący negocjację protokołu z Outlook (modern auth):
2024-02-19 10:12:45 SMTP AUTH connection started from [192.168.1.100] (client.w-files.pl)
2024-02-19 10:12:46 EHLO client.w-files.pl
2024-02-19 10:12:46 250-server.w-files.pl Hello [192.168.1.100]
2024-02-19 10:12:46 250-AUTH LOGIN PLAIN XOAUTH2 OAUTHBEARER
2024-02-19 10:12:46 250-SIZE 15728640
2024-02-19 10:12:46 250 STARTTLS
2024-02-19 10:12:47 STARTTLS
2024-02-19 10:12:47 220 2.0.0 Ready to start TLS
2024-02-19 10:12:48 TLS negotiation successful (TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384)
2024-02-19 10:12:49 EHLO client.w-files.pl
2024-02-19 10:12:49 250-server.w-files.pl Hello [192.168.1.100]
2024-02-19 10:12:49 250-AUTH LOGIN PLAIN XOAUTH2 OAUTHBEARER
2024-02-19 10:12:50 AUTH XOAUTH2 dXNlcj1hbGljZUBleGFtcGxlLmNvbQFhdXRoPUJlYXJlciB5YTI5LkEwQWY2eHplN…
2024-02-19 10:12:51 235 2.7.0 Authentication successful
2024-02-19 10:12:52 MAIL FROM:<nexor@w-files.pl>
2024-02-19 10:12:52 250 2.1.0 Sender OK
2024-02-19 10:12:53 RCPT TO:<b0b@w-files.pl>
2024-02-19 10:12:53 250 2.1.5 Recipient OK
2024-02-19 10:12:54 DATA 2024-02-19 10:12:54 354 Start mail input; end with <CRLF>.<CRLF>
2024-02-19 10:12:56 Message content sent successfully
2024-02-19 10:12:56 250 2.0.0 OK 2024-02-19 10:12:57 QUIT
2024-02-19 10:12:57 221 2.0.0 server.w-files.pl closing connection
czyli jednym sensownym wyjaśnieniem byłoby 'wyłączyliśmy SMTP AUTH w tenantach gdzie nie ma Exchange’. co za ściema.
nie lubię niejasności. ciężko się zabezpieczać a wśród niejasności rodzą się potencjalne furtki. a po wszystkich tych testach niby wiem więcej a czuję się tak samo bezradny.
eN.
’touch me’ – nieoczywista oczywistość
czemu tokeny FIDO chcą żeby je dotknąć?
ktoś zadał mi takie pytanie i w sumie ja też sobie je kiedyś zadawałem…
kiedyś
jako dinozaur, bardziej naturalnym [czy też tradycyjnym] sposobem uwierzytelnienia są dla mnie karty karty inteligentne. nie do końca rozumiem, czemu nigdy nie zdobyły popularności na rynku małych i średnich firm oraz prywatnie:
taki klasyczny 'żarcik edukacyjny’ w niektórych firmach w jakich pracowałem, to szybka podmiana pulpitu na jakieś złośliwe zdjęcie, albo wysłanie maila do całego teamu 'stawiam wszystkim pączki!’, kiedy ktoś odszedł od kompa nie blokując pulpitu… dodatkowa zaleta smartcard jest taka, że kiedy osoba odchodzi od komputera – np. do toalety – musi użyć tej samej karty, a wyjmując ją z kompa automatycznie blokowana jest stacja.
a jednak to tokeny FIDO2, ze wszystkimi swoimi wadami, od ceny zaczynając, rozpychają się na obecnym rynku…
dodatkowo przez jakiś czas zastanawiałem się po co trzeba je dotknąć? spodziewałem się że to małe coś na tokenach, to czytnik linii papilarnych – to by miało sens. ale nie – to zwykłe zwarcie jest. niektóre 'nowoczesne’ modele są tak zaprojektowane, żeby były malutkie i 'nie przeszkadzały’ podobnie do nadajników radiowych, i żeby nie trzeba było ich w ogóle wyciągać – a więc co to za zabezpieczenie? to tak jakby zostawiać klucz w zamku – wystarczy przyjść i przekręcić.
odpowiedź
odpowiedź jest prosta – te klucze nie mają chronić przed próbą dostępu fizycznego. konieczność dotyku powoduje, że przy próbie uwierzytelnienia zdalnego, kiedy wymagany jest 2FA, potencjalny atakujący nie będzie w stanie go użyć… bo jest zdalnie, czyli nie może dotknąć tokenu. statystycznie patrząc, nie bronimy się raczej przed kolegami z pracy, dość rzadkim scenariuszem są również sytuacje, w których atakujący ma fizyczny dostęp do naszego komputera.
dodatkowo, bardziej prawidłową odpowiedzią będzie – „wygoda”. bo przecież konieczność wpisania PINu daje ten sam poziom [ba! wyższy! bo ktoś musi go znać], tylko jest bardziej upierdliwa. zresztą do tokenów też trzeba często podać PIN.
no to czemu nie smart card?
Pozostaje pytanie – czemu jednak nie karty inteligentne, skoro mają tyle zalet? w końcu to, że tokeny są tak ładnie obsługiwane przez przeglądarki i urządzenia to kwestia tego, że powstały standardy, które zostały zaimplementowane przez dostawców. są takie, ale mogły być inne. czego zatem brakuje kartom inteligentnym i czemu nie dostosowano tej technologii do protokołów Chmurowych WebAuthn/CTAP? co przełamało prawo konwergencji, forkując technologię, która wydawała się wygodniejsza [i tańsza] – pozostawiając karty inteligentne w niszy dostępu fizycznego, a stworzono Fast IDentity Online [FIDO]?
podstawowym powodem jest cały model uwierzytelnienia, tzw. authentication workflow. obsługa certyfikatu zorientowana jest na zcentralizowanym modelu. FIDO z założenia jest zdecentralizowane, oparte na szybkiej weryfikacji, bez konieczności dodatkowego sięgania do jakiegoś centralnego serwera. niepotrzebna jest Infrastruktura Klucza Publicznego [PKI] – która ma swoją własną złożoność, problemy, podatności etc…
można z tym wszystkim niby polemizować – że certyfikaty nie muszą być drogie, że wdrożenia PKI to wcale nie musi być nie-wiadomo-jak-skomplikowane… ale jak to wszystko zebrać razem, to po prostu nie tędy droga. tak na prawdę FIDO powinno być ewolucyjnie porównywane z tokenami OTP – np. RSA SecureID – a nie z kartami inteligentnymi. elektronika, która jest w tokenach pozwala na wiele więcej, niż pasywne przechowywanie certyfikatów:
w skrócie – wymagana była aktywna elektronika.
pisząc ten art zadałem sobie pytanie – czemu nie połączy się tych dwóch technologii tworząc FIDO2 smart card… i jak to zwykle bywa – ktoś już odpowiedział na to pytanie – a czemu by nie? mam nadzieję kiedyś pracować przy wdrożeniu takiego cuda, jako część Integrated Security System, bo wygląda smacznie.
Exit
jednym z drażniących ograniczeń FIDO jest brak jego natywnej obsługi przez Windows logon. do tego celu można oczywiście wykorzystać system innych firm – jak np. Duo. problemem są koszty rozwiązania – same tokeny FIDO do najtańszych nie należą, a i subskrypcja Duo kosztuje… dochodzi dodatkowy poziom integracji, wybór IdP i tak dalej…
…nie podejmuję się odpowiedzi na pytanie 'dlaczego?’… a w każdym razie nie dzisiaj…
eN.