Artykuły dotyczące tematu: OAuth

dodany: 30.07.2013 | tagi: , , , ,

LinkedIn załatał poważną lukę

0

Serwis LinkedIn załatał dość poważną lukę, która pozwalała na przejęcie tokena dowolnego użytkownika. Błąd leżał konkretnie w otwartym standardzie uwierzytelniania OAuth, który wykorzystują także serwisy Facebook, Twitter oraz FourSquare.

Słabość odnalazł brytyjski deweloper oprogramowania Richard Mitchell. Luka zaszyta w implementacji OAuth pozwalała na pobranie tokena, poprzez błąd w API, który zwracał tokena w przypadku żądania wyświetlenia systemu pomocy przez JavaScript.

Wykorzystanie luki było jak najbardziej realne – jeśli atakujący użyłby jakiejkolwiek sztuczki, która by skusiła ofiarę do uruchomienia systemu pomocy  LinkedIn, mógłby zrobić z stroną nieświadomego użytkownika cokolwiek, np. zmienić nasze CV. Trzeba zaznaczyć,  że przejęcie tokena jest równoznaczne z możliwością zalogowania się na konto. Pomóc w tym mogłaby np. odpowiednio spreparowana strona z zachęcającym linkiem.

Na szczęście LinkedIn naprawił lukę w ciągu 48 godzin od daty zgłoszenia.

dodany: 14.03.2013 | tagi: , ,

Problemów z OAuth ciąg dalszy

2

Niecały miesiąc temu pisaliśmy o niebezpieczeństwie kryjącym się w module uwierzytelniania OAuth, z którego korzysta m.in. Facebook (zobacz newsa: Poważna luka w module Facebooka).  Zespół odpowiedzialny za bezpieczeństwo serwisu co prawda naprawił tę lukę, ale ten sam badacz bezpieczeństwa, Nir Goldshlage, odnalazł kolejny sposób na przejęcie uprawnień.

Tym razem poszło mu zdecydowanie łatwiej – Nir odkrył właściwość parametru o nazwie next. „Przepuszcza” on domenę facebook.facebook.com jako prawidłową oraz pozwala obejść mechanizm Regex Protection, który Facebook wprowadził jako element zabezpieczający przed poprzednią luką.

Obecnie serwis odrzuca pojedynczy hasz w żądaniu przekierowania URI poprzez wspomniany parametr next:

(next=%23/xxxx,next=%23xxx!).

Wszystko to po to, aby uniknąć powodzeń ataków na OAuth. Sęk w tym, że programiści Facebooka widać nie są specjalnie rozgarnięci,  gdyż  podwójne (i wielokrotne) użycie hasza w żądaniu przekierowania wg nich jest już ok (czytaj – nikt nie zawaha się go użyć?), przez co zapis do parametru next o następującej postaci jest już jak najbardziej prawidłowy:

next=%23/xxx/%23/xxx

 

Przykłady:

facebook.com/#/x/#/messages prowadzi do http://facebook.com/x/#/messages/

http://facebook.com/x/#/messages/ prowadzi do http://facebook.com/messages/

 

Co ciekawe, Nir zauważył, że mobilna wersja odrzuca powyższe przekierowania – dlaczego? Ano z tego powodu, że po prostu odrzuca nieznane subdomeny, np. aaa.facebook.com.

Dotyczy to mobilnych „fejsbuków” dostępnych z adresów: touch.facebook.comm.facebook.com0.facebook.com.

 

Jak to zastosować w praktyce?

Nir odkrył, że jeśli dodamy 5 bajtów do pliku l.php, to Facebook pominie komunikat o niebezpieczeństwie związanym z zewnętrzną aplikacją:

Oryginalny link: https://www.facebook.com/l/;touch.facebook.com/apps/sdfsdsdsgs

Spreparowany:   https://www.facebook.com/l/goldy;touch.facebook.com/apps/sdfsdsdsgs

 

Zbierając 3 powyższe uwagi razem Nir przedstawił dowód na słabość implementacji OAuth, który ponownie pozwala za przejęcie tokena, który tak jak poprzednio nie wygasa aż do zmiany hasła przez użytkownika:

https://www.facebook.com/connect/uiserver.php?app_id=220764691281998&next=https://facebook.facebook.com/%23/x/%23/l/ggggg%3btouch.facebook.com/apps/sdfsdsdsgs%23&display=page&fbconnect=1&method=permissions.request&response_type=token

Link działa w każdej przeglądarce. Po drodze Nir odkrył także inny problem związany z FB, ale tylko w przypadku przeglądarki Firefox – Facebook na szczęście naprawił to. W tym scenariuszu ataku możliwe było obejście zabezpieczeń OAuth poprzez zastosowanie podwójnego kodowania URL.

dodany: 11.03.2013 | tagi: , , ,

Jak odpalić nieautoryzowane aplikacje w Twitterze

1

Twitter podobnie jak Facebook korzysta z metody uwierzytelniania OAuth. Niestety nie jest ona doskonała – ostatnio informowaliśmy Was jakie niebezpieczeństwo owe API powodowało w przypadku FB  (zobacz newsa: Poważna luka w module Facebooka), a teraz wyszło na jaw, że jest problem z Twitterem, choć przyczyna jest zdecydowanie inna, gdyż w tym wypadku wyciekły klucze, które pozwalają na autoryzację zewnętrznych aplikacji. Dzięki temu możliwe jest uruchomienie dowolnej aplikacji, która może zrobić z naszym kontem praktycznie wszystko – włącznie z czytaniem prywatnych wiadomości!

Owe klucze składają się z dwóch elementów: jeden to consumer key, natomiast drugi do consumer secret. Krótko mówiąc zestaw ten jest odpowiednikiem login/hasło, który pozwala na uwierzytelnienie aplikacji w powiązaniu z Twitterem. Klucze te są dostępne w serwisie GitHub.

Oto przykładowy zestaw dla Google TV:

Inne opublikowane klucze są dostępne dla iPhone’a, Androida, iPada, Maca, Windows Phone oraz TweetDeck.

Oczywiście ujawnione klucze zostały zresetowane, ale to nie rozwiązuje problemu – kto wie, kiedy pojawi się ich aktualizacja? Właśnie taka sytuacja miała teraz miejsce – wcześniej klucze zostały opublikowane 5 miesięcy temu. Metoda OAuth została wprowadzona w Twitterze w sierpniu 2010 roku.

To nie jedyna wpadka z API OAuth – w ostatnim czasie wykryto, że pomimo zmiany hasła, token uzyskany przy logowaniu na starym haśle nadal działał.

dodany: 21.02.2013 | tagi: , , ,

Poważna luka w module Facebooka

2

Facebook OAuth to moduł używany w komunikacji pomiędzy aplikacjami a użytkownikami Facebooka – zapewnia on dostęp do naszych aplikacji – w skrócie jest odpowiedzialny za to okno, w którym mamy wybór na zezwolenie bądź zablokowanie dostępu danej aplikacji:

OAuth Facebook

Sęk w tym, że posiada on dość poważną lukę, która pozwala na pełną kontrolę nad danym kontem, bez konieczności potwierdzenia dostępu dla danej aplikacji! Odkrył to haker z jasnej strony mocy – Nir Goldshlage.

 

Z czego wynika niebezpieczeństwo?

Aby zrozumieć problem tej luki należy poznać schemat tworzenia adresów URL dla OAuth. Dzięki odpowiedniej modyfikacji parametrów w adresie, możliwie jest ominięcie wymogu autoryzacji aplikacji przez użytkownika.

Przykładowy URL OAuth wygląda następująco:

Pierwszym elementem adresu jest app_id, który jak nie trudno się domyślić, jest ID konkretnej aplikacji.
Parametr next zawiera domenę z adresu URL danej aplikacji.
Jako przykład niech posłuży nam w ostatnim czasie głośna aplikacja Texas Holdem Poker:
jej app_id=2389801228, natomiast parametr  next  zawiera domenę zynga.com (next=http://zynga.com). Jeśli w linku pojawiłaby się inna domena, Facebook zablokowałby ją.

 

Magiczny parametr w adresie URL
Goldshlage odkrył fakt, że można użyć własnej domeny w parametrze next w adresie URL – pozwala to na dodanie wpisu ‚#xxx!‚ – przykład: https://beta.facebook.com/#xxx!/messages/.

 

Okazało się jednak, że parametr ten nie działał w każdej przeglądarce. Dlatego Goldshlage szukał dalej, aż odnalazł dwa inne, które działają w każdej przeglądarce – są to %23~! oraz %23%09!

Jednak to tylko część drogi do ominięcia mechanizmu zabezpieczającego Facebooka. Aby wykorzystać ten fakt, haker stworzył prostą aplikację, która służy do przekierowania użytkownika wraz z jego tokenem sesji do zdalnej strony, która rejestruje wszystkie tokeny w swoim logu.

Do dzieła!

Do wykonania ataku brakuje nam zgody użytkownika z podmienioną domeną aplikacji. W poniższym przykładzie haker posłużył się także aplikacją Texas Holdem Poker, tyle że jeśli ofiara zaakceptuje żądanie, to zostanie faktycznie przekierowana do dowolnej strony, która już z kontem użytkownika może zrobić co chce – jak np. ta, którą stworzył Goldshlage

Aby mieć najwięcej możliwości nad przejętym kontem, to najlepiej wybrać aplikację, która daje pełny dostęp  – taką jest choćby wbudowany Facebook Messenger  – w tym wypadku nie jest wymagane nawet potwierdzenie zgody na użycie aplikacji.

Przykładowy spreparowany złośliwy link: 

 

Link ten pozwala on na przejęcie tokena z największymi uprawnieniami do „fejsbukowego” konta – mało tego – token zdobyty w ten sposób praktycznie nigdy nie wygasa. Stanie się to dopiero wtedy, gdy użytkownik zmieni hasło. Oczywiście sam link nie jest groźny, gdyż nie mamy dostępu do wspomnianej aplikacji (haker stworzył go tylko w celach demonstracyjnych). Efekty działania możecie zobaczyć na poniższym wideo:

http://youtu.be/UlF7TeRKzt0