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.
Exchange – uprawnienia do kalendarzy zasobów
prosty scenariusz: trzeba założyć zasób, reprezentujący samochód firmowy tak, aby ludzie mogli go sobie rezerwować. następnie chcemy aby wszyscy widzieli kto go wypożyczył i dokąd zabrał. standardowo większość informacji jest ukryta i widać tylko ogólny wpis.
w tym celu należy nadać uprawnienia do kalendarza nie jest trudno i jest sporo linków, które szybko wskażą, że można to zrobić poleceniem:
… ale:
lokalizacja
czemu w PL nie zadziała? ponieważ 'calendar’ to nazwa katalogu, a ta jest zlokalizowana. żeby było śmieszniej nazwa będzie zależna od… ustawień przeglądarki w momencie tworzenia obiektu zasobu (użytkownikom definiuje się kraj). sweet. ponieważ mam główną przeglądarkę ustawiona na en-US, żeby nie oglądać raniących w oczy auto-tłumaczeń technetowych czy portalu office365 w którym ciężko się połapać, część obiektów ma 'calendar’ a część 'kalendarz’. zakładając z command line zawsze tworzy 'calendar’ pomimo polskich regionalsów, więc mniemam, że ten sposób jest bardziej deterministyczny (ale trzeba by porobić więcej testów na różnie zlokalizowanych systemach).
czyli zapis ścieżki do konkretnego folderu to „roomResource@wfiles.pl:\kalendarz” . i znów – tyle dość łatwo i szybko można wyszperać na forach… ale pozostaje pytanie – jak wylistować wszystkie katalogi?? skoro jest kalendarz, to pewnie są jakieś inne foldery i może da się z nimi coś zrobić? i jak sprawdzić czy to jest 'calendar’ czy 'kalendarz’? ale najpierw…
uprawnienia
standardowo, po utworzeniu zasobu sali lub ekwipunq jedyne co widać w kalendarzu to 'busy’.
można to zmienić i umożliwić bardziej pełny widok nadając uprawnienia LimitedDetails lub Reviewer (pełna lista uprawnień tutaj). różnica jest dość poważna. ograniczone detale pozwolą na zobaczenie organizatora i lokalizacji ale nie pozwolą otworzyć zdarzenia ze względu na brak uprawnień:
na pierwszy rzut oka może wygląda dobrze, ale ktoś choć trochę bardziej spostrzegawczy zauważy, że pole tematu oraz szczegółowe informacje chyba nie dają pełnych informacji. i faktycznie – standardowo, założenie jest takie: ktoś wynajmuje salę, wysyła zaproszenie, więc w tym zaproszeniu umieszcza informacje o czym będzie rozmowa, pewnie agendę, może jakieś materiały dodatkowe itd. zasób sali dostaje to samo zaproszenie co każdy inny – a to byłby niekontrolowany wyciek informacji. nie byłoby miło, gdyby cała firma wiedziała, że właśnie dyrektorzy spotykają się, np. żeby omówić zwolnienia pracowników… dla tego standardowe opcje są ustawione restrykcyjnie i wycinają wszystkie informacje.
są jednak scenariusze, w których niektóre osoby muszą wiedzieć więcej – np. dział logistyki musi wiedzieć gdzie jest samochód i po co. wtedy trzeba wykonać następujące operacje:
zobaczmy jakie zachowania można dla zasobu ustawić:
wszystkich nie ma sensu tłumaczyć, można przeczytać na technecie, nas interesują konkretnie DeleteSubject, DeleteComents. jak widać można również pozwolić na załączniki, kontrolować czy zatwierdzanie jest automatyczne czy wymaga ręcznego potwierdzenia, czy w polu tematu dodawana jest nazwa użytkownika… i inne. przykładowa konfiguracja zasobu:
i w takim przypadq dział logistyki może zobaczyć takie krzaczki…
na koniec powrócę do listy folderów. tu niestety niespodzianka: nie da się wylistować folderów dla zasobu. ponieważ zasób jest skrzynką… ale równocześnie nią nie jest. jest – i te foldery są, ale nie jest – bo tak twierdzi system. poniżej mała zabawa – wylistowanie folderów dla regularnego mailboxa, próba wylistowania dla zasobu i dowód, że jednak wszystkie foldery są…
przy czym normalny user ma nazwy katalogów po polsq bo zakładając tak miał zdefiniowaną licencję, a zasób po ang. bo był zakładany z linii poleceń, a zasoby licencji nie posiadają. wykorzystanie 'get-mailboxfolderpermission’ w połączeniu z intuicją to jedyny sposób jaki znalazłem, żeby sprawdzić czy dany folder istnieje dla zasobu…
eN.