9:16
26/2/2013

Obejście googlowego dwuskładnikowego uwierzytelnienia już raz miało miejsce — zrobiła to grupa UGNazi w trakcie swojego ataku na CloudFlare. Teraz DuoSecurity informuje o kolejnej słabości Googlowego dwuskładnikowego uwierzytelniania.

Hasła specyficzne dla danej aplikacji

Dwuskładnikowe uwierzytelnianie w Google działa tylko dla HTTP — po podaniu hasła do konta jesteśmy proszeni o wpisanie kodu z SMS-a lub aplikacji-tokena, zainstalowanej na naszym telefonie komórkowym.

Two step verification

Dwukrokowe uwierzytelnienie

Niestety dwuskładnikowe uwierzytelnienie nie wspiera wszystkich protokołów i dlatego dla SMTP lub IMAP Google wprowadziło tzw. “Application Specific Passwords” — losowo generowane hasła dające dostęp do konta Google tylko konkretnej aplikacji. Nazwa “specyficzne dla aplikacji hasła” może sugerować, żę jeśli np. wycieknie nasze ASP dla klienta Google Talk na telefonie komórkowym, to atakujący nie będzie w stanie zalogować się przy pomocy tego hasła do GMaila przez przeglądarkę — nic bardziej mylnego.

Telefon z Androidem + ASP = obejście 2FA

Ekipa DuoSecurity dowiodła, że każde ze “specyficznych dla aplikacji haseł” dawało nieograniczony dostęp do konta i pozwalało obchodzić dwuskładnikowie uwierzytelnienie (przy użyciu ASP nie byliśmy pytani o kod z SMS-a lub aplikacji). Jak?

Przy pomocy ASP należało zlinkować telefon z Androidem z kontem Google’a (to włączało funkcję “autologinu”, która de facto obchodziła 2 factor authentication). Następnie z poziomu telefonu miało się dostęp do poszczególnych ustwień konta Google, w tym — tzw. recovery options — czyli strony na której można zmienić hasło do konta ofiary — oczywiście bez dodatkowego uwierzytelnienia.

ASP to nie OAuth

Jak widać powyżej, niestety ASP to nie OAuth, gdzie każdy z tokenów może mieć dostęp tylko do wybranych danych/funkcji konta użytkownika. Błąd popełniony przez Google należy rozpatrywać w kategoriach błędów “designu”/”logiki biznesowej” — przy tak szerokim wdrożeniu (tyle urządzeń, metod dostępu) łatwo o pomyłkę nawet najlepszym. Obecnie dziura została załatana przez Google.

PS. Warto też podkreślić, że aby ominąć dwuskładnikowe uwierzytelnienie, atakujący musiał najpierw zdobyć ASP ofiary, a to wcale nie jest łatwe zadanie (albo znajdziemy czyjś telefon i wyciągniemy ASP z konfiguracji, albo założymy własną “fałszywą” usługę spinającą się z kontem Google — np. aplikację na iOS). To powoduje, że atakującym prościej wykonać klasyczny atak typu phishing lub włamać się do innego serwisu i wykraść z niego hasło ofiary — wiemy przecież, że większość internautów naiwnie korzysta ona z jednego hasła do wielu usług…

Przeczytaj także:


15 komentarzy

Dodaj komentarz
  1. Czytam 2 raz i nic nie rozumiem :(.
    Prosze o v. dla laików.

    • Sporo aplikacji korzystających z usług Google’a nie wspiera dwuskładnikowego uwierzytelniania (tj. po wpisaniu hasła musisz jeszcze wpisać kod przesłany SMSem albo wygenerowany na telefonie, taka dodatkowa bramka bezpieczeństwa) – w związku z tym wymyślili sobie, że utworzą hasła dodatkowe, które nie będą wymagać tego kodu, więc wszystkie aplikacje będą z nimi kompatybilne bez zmian. No i problem w tym, że takie hasło jest na równi z uprawnieniami jak twoje zwykłe hasło – każdy może się zalogować bez przesłanego/wygenerowanego kodu.

  2. A co z Google Authenticator? Ja zrezgnowałem – tam gdzie można z haseł aplikacji na rzecz Authenticatora. Generalnie raz na jakis czas zalecany chyba jest tez review “dopuszczonych” aplikacji… :)

    • “A co z Google Authenticator?” – jeśli zadajesz takie pytanie to widać że poruszasz się w temacie po omacku. Artykuł nie jest o sms-ach, tylko o ASP.

  3. No to teraz pryszczersi będą nawoływali za siedmioskładnikowym uwierzytelnianiem

  4. A w jaki sposób Google załatało problem? (hasła ASP nie dają dostępu do wszystkich usług / recovery options wymaga dodatkowego uwierzytelnienia)

    • Dokładnie dla przykładu proszę sobie takie hasło wygenerować i spróbować dostać się do konta z poziomu www gmail’a. Poza tym w przypadku przejęcia urządzenia (tabletu, komputera) szybko logujemy się na konto i wywalamy ASP. Gorzej z telefonem ale tutaj IMO lepiej skonfigurować dodatkowo kod przez połączenie – dzwonimy do operatora, który blokuje kartę SIM a my spokojnie czekamy na duplikat.

  5. A co za problem wdrożyć dwuskładnikowe uwierzytelnianie dla innych usług, na przykład IMAP? Przykładowo, użytkownik loguje się swoim klientem pocztowym i za pierwszym razem dostaje komunikat błąd “530 prosze wprowadzic haslo+kod SMS wyslany na numer 48601XXXXXX”. Użytkownik wprowadza hasło którego część jest stała a część jednorazowa i następuje druga próba połączenia. Jeśli dane były prawidłowe, jest zalogowany. Trudne?

    • Będziesz wpisywał to hasło co 5 minut, za każdym razem jak klient pocztowy odświeża pocztę?

    • Nie. Jak klient będzie się łączył z nieznanego urządzenia czyli na przykład po zmianie adresu IP. A u mnie IP nie zmienia się co pięć minut!

    • Telefony komórkowe, internet mobilny np.Play, Neostrada, ludzie z laptopami i hotspoty… Spora grupa ludzi, która ma zmienne IP. Można powiedzieć, że już jesteś w mniejszości z swoim komputerem stacjonarnym uziemionym i z stałym IP na miesiące.

  6. AFAIK IMAP nie wspiera ciasteczek, a to że u Ciebie IP sie nie zmienia nie oznacza że tak jest również u milionów userów którzy korzystają z gmaila.
    Ciekawym w jaki sposób google załatało tą dziurę.

  7. Pewnie manualnie. Hotline z Indii prowadzi współdzielony w Dokumentach Google’a arkusz kalkulacyjny i tam zaznacza: adres IP, expired, a w ostatniej kolumnie fingerprint OS-a i browsera. Jak mija pewien czas albo się zmieni fingerprint, to odpowiednie makro albo pracownik kasuje wiersz z arkusza. Problem solved.

  8. “wiemy przecież, że większość internautów naiwnie korzysta ***ona*** z jednego hasła do wielu usług…”
    :)

  9. […] — albo na skutek błędów w jego implementacji, jak to było w przypadku PayPala, Apple oraz GMaila (nawet dwukrotnie) albo przy pomocy ataków socjotechnicznych mających na celu resetowanie haseł, […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: