Poniedziałek z trenerem – Wirtualna rzeczywistość – realne błędy

W trakcie naszych szkoleń zawsze zachęcamy użytkowników, by nie bać się szukać błędów w dużych i popularnych serwisach, dysponujących ogromnymi działami bezpieczeństwa – bo tam też sporo można znaleźć. Przykład poniżej.

Dziś będzie można kolejny raz przeczytać o błędach bezpieczeństwa, które dotykały społecznościowego giganta – Facebooka. Ryzyko wynikające z ich wykorzystania to przejęcie aktualnie zalogowanego konta użytkownika. Problematyczna okazała się integracja z Oculus, czyli goglami wirtualnej rzeczywistości.

W poprzednich odcinkach

We wcześniejszych wpisach cyklu Poniedziałek z trenerem:

• dwa proste błędy w kodzie Facebooka,
• cztery błędy do zdalnego wykonania kodu,
• modyfikacja jednego parametru za 10 000 dolarów,
• ciekawe ataki na nagłówki wiadomości,
• wykonanie kodu na firewallach PaloAlto,
• jak można było przejąć dowolne konto VirusTotal,
• dwa błędy prowadzące do wykradania kontaktów Yahoo.

Wirtualne okulary, realne problemy

Kto przynajmniej raz miał na sobie podobny wynalazek z pewnością przyzna, że technologia jest interesująca. Na pewno podobnie pomyślał Facebook, który kupił firmę Oculus kilka lat temu. Dziś można korzystać z Facebooka za pośrednictwem takiego interfejsu. By jednak zachęcić do tego użytkowników, przygotowano możliwość powiązania kont obu rozwiązań. Sam błąd był bardzo podobny do tego opisanego w pierwszym odcinku serii.

Integracja jest możliwa poprzez interfejs przeglądarkowy i wykorzystywany przez aplikację natywną. Odkrywca błędu przyjrzał się interfejsowi implementacji natywnej, najwyraźniej możliwe było korzystanie z niego również przez przeglądarkę. Okazało się, że możliwe jest przeprowadzenie ataku typu CSRF. Napastnik mógł wtedy postąpić w taki sposób:

1. Na swoim własnym koncie stworzyć następującą mutacje GraphQL (funkcja w języku operowania danymi na FB):

   Mutation Test {
           facebook_sso_uri_generate( <input> ) { uri } }
           &query_params={"input":{"client_mutation_id":"1"}}

2. Odczytać odnośnik z odpowiedzi serwera na dodanie mutacji, powinien mieć on format taki jak:

   https://www.oculus.com/facebook_login_sso/?username=grozny.zloczynca321&ext=1508804050&hash=AeQ6a90lgYfffT5k

3. Wysłać link ofierze lub w inny sposób sprawić, by przeglądarka wysłała żądanie pod ten URL (np. umieszczając go jako obrazek na swojej stronie internetowej).

Efektem było przekierowanie na FB i powiązanie kont przy pomocy OAuth, tylko że z pominięciem stosownych zabezpieczeń. Prawdopodobnie nie zostało przewidziane, że interfejs przeznaczony dla aplikacji natywnej może być użyty również w przeglądarce. Powiązane samo w sobie umożliwiało przeglądanie części znajomych i uzyskanie kilku innych informacji, badacz postarał się jednak o więcej. Oglądając aplikację natywną, w pliku app.asar natrafił na taką mutację GraphQL:

viewer(){ linked_accounts_info { facebook_account { facebook_id } } }

Funkcja zwracała tylko id użytkownika, czyli nic wyjątkowo interesującego. Jeśli jednak zmodyfikować nazwę odczytywanego parametru, możliwy był dostęp do innych właściwości powiązanego konta. Na przykład do access_token.

viewer(){ linked_accounts_info { facebook_account { access_token } } }

Token taki, w odróżnieniu od tokenów używanych przez aplikacje zewnętrzne, umożliwia dostęp do pełnej wersji GraphQL na stronie FB. Dzięki informacjom z poprzednich analiz (dekompilacji innych aplikacji FB), odkrywca wiedział, jak wykorzystać to by przejąć pełną kontrolę nad kontem. Poniżej sposób, jak przejąć konto z poziomu GraphQL:

1. Wykonać żądanie do

   graph.facebook.com/graphql?doc_id=10153582085883380&variables={"input":{"client_mutation_id":1,"actor_id":"FBID","phone_number":"+NUMER_TELEFONU"}}&access_token=ACCESS_TOKEN_OFIARY

   gdzie doc_id=10153582085883380 to identyfikator operacji odczytany z innej aplikacji.

2. Potwierdzić operację kodem SMS odebranym na wybranym numerze telefonu:

   graph.facebook.com/graphql?doc_id=10153582085808380&variables= {"input":{"client_mutation_id":1,"actor_id":"FBID","confirmation_code":"CODE"}}&method=post&access_token=ACCESS_TOKEN_OFIARY

3. Odzyskać hasło do konta w oparciu o nowo dodany numer telefonu.

Zabezpieczenie wprowadzone przez FB polegało na sprawdzeniu, czy parametr username z konta użytkownika w serwisie Oculus zgadza się z wartością przekazaną w odnośniku. To znaczy, że jeśli istniałaby możliwość automatycznego zalogowania użytkownika w serwisie Oculusa, to poprzedni atak można mimo wszystko wykonać. Scenariusze to umożliwiające to na przykład podatność typu Session fixation, czy CSRF w funkcji logowania. Okazuje się, że tak właśnie było, ponownie w wariancie CSRF. Tym razem atak można było przeprowadzić następująco:

1. Wykonać pierwszy i drugi krok z metody przejęcia access_token ofiary, i jeśli odnośnik odczytany z odpowiedzi serwera oznaczymy $ODNOŚNIK, to wykonać jeszcze jedno żądanie:

   curl -v --cookie "oc_ac_at=..snip.." --referer "https://auth.oculus.com/"  -d    "require_token_for=752908224809889&redirect_uri=https://www.oculus.com/account_receivable/?redirect_uri=$ODNOŚNIK" https://auth.oculus.com/nonce-redirect/
   

2. Odczytać link z odpowiedzi i tym razem ten odnośnik wykorzystać do ataku na ofiarę. Po odwiedzeniu go ofiara była automatycznie logowana na konto Oculus atakującego, przekierowywana na $ODNOŚNIK, tym razem z poprawnym parametrem username i przekierowywana na FB, gdzie dokonywało się powiązane kont.

Za drugim razem naprawa dotyczyła obu błędów. Po pierwsze, automatyczne logowanie na do serwisu Oculus przy pomocy powyższej metody jest już niemożliwe. Po drugie, powiązane kont wymaga świadomej akcji ze strony użytkownika, tj. kliknięcia na potwierdzenie. Wszystko wskazuje na to, że tym razem poprawka jest wystarczająca.

Szkolenie z bezpieczeństwa aplikacji WWW

Zapraszamy na nasze szkolenia, gdzie oprócz solidnych podstaw można też posłuchać o rażąco podobnych błędach, spotkanych przez nas w trakcie testów.