dodany: 14.03.2013 | tagi: , ,

Autor:

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.

Redaktor działu aktualności WebSecurity.pl. Pasjonat komputerów od czasów epoki "bezmyszkowej".

2 odpowiedzi na “Problemów z OAuth ciąg dalszy”

  1. This ain’t hot at all…

  2. I am actually pleased to read this website posts which includes plenty of useful facts, thanks for providing these kinds of
    information.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *