11:11
5/6/2012

Grupa UGNazi mogła podmienić treści widziane przez internautów po wpisaniu w przeglądarkę domeny Niebezpiecznik.pl. Jednak zamiast nas, atakujący na cel wybrali sobie bardziej znaną stronę — 4Chan.org…

Cloudflare (outsourcing DNS-ów)

Zarówno Niebezpiecznik, 4Chan jak i kilkanaście tysięcy innych stron internetowych korzysta z CDN-ów Cloudflare’a do serwowania statycznego contentu (obrazki, skrypty js, css). Wszystkie wasze requesty, zamiast trafiać na nasz fizyczny serwer lecą najpierw do chmury, na adresy IP należące do serwerów Cloudflare znajdujących się najbliżej waszej fizycznej lokalizacji. Adresy te podawane są przeglądarkom przez DNS Cloudflare, a żeby korzystać z usług Clodflare’a należy ustawić primary i secondary DNS na ich serwery.

Cloudflare

Cloudflare - uproszczona zasada działania

Mając dostęp do danego konta klienta Cloudflare’a — co oczywiste — można przekierować domenę na dowolny adres IP. I w ten właśnie sposób “zdeface’owano” 4Chana. Ale ponieważ atakujący mogli kontrolować dowolny wpis w DNS-ach Cloudflare’a, mogli także podmienić adres IP dla domeny Niebezpiecznik.pl.

Warto tu podkreślić, że tymczasowe przekierowanie domeny na inny IP korzystając z podatności u dostawcy usług DNS (tu: Cloudflare oraz jak się później okazało także Google) nijak ma się do włamania na faktyczne, fizyczne serwery 4Chana czy też Niebezpiecznika. Ale po kolei…

Po pierwsze: Słabości w dwuskładnikowym uwierzytelnieniu od Google

Matthew Prince to szef Cloudflare’a. Cloudflare korzysta z Google Apps dla poczty. UGNazi zdobyli dostęp do korporacyjnej skrzynki mailowej Prince’a na Google Apps, chronionej przez 2 składnikowe uwierzytelnienie.

Wait, WHAT!? Jak można pokonać dwuskładnikowe uwierzytelnienie!? Otóż UGNazi wykorzystali pewną “słabość” — błąd potwierdza Google:

[Google] fixed a flaw that, under very specific conditions, existed in the account recovery process for Google Apps for Business customers.

Błąd polegał na tym, że jeśli konto administratora domeny chronione przez dwuskładnikowe uwierzytelnienie było skonfigurowane w taki sposób żeby wysyłać instrukcje resetu hasła na “secondary e-mail”, to “odzyskanie” konta administratorskiego przez “secondary e-mail” automatycznie wyłączało na koncie administratora dwuskładnikowe uwierzytelnienie.

Krótko mówiąc, jeśli ktoś kontrolował “secondary e-mail” dla administratora domeny Google Apps, mógł spowodować wyłaczenie 2 factor autentication. Wystarczyło zainicjować reset hasła.

W przypadku Prince’a, secondary e-mailem był prywatny e-mail na GMailu, który nie wykorzystywał 2 factor authentication. A jak UGNazi przejęli prywatnego GMaila Prince’a? Byli w stanie przekonać AT&T, operatora telefonu Prince’a, do tego aby przekierować jego pocztę głosową na inny numer.

Google umożliwia reset hasła poprzez wysłanie SMS-a lub odebranie połączenia telefonicznego na powiązanym ze swoim kontem telefonie. W skrócie, oznacza to tyle, że jeśli powiązałeś z kontem Google swój telefon, a atakujący zna jego numer, to bezpieczeństwo twojej skrzynki mailowej jest wprost proporcjonalne bezpieczeństwa PIN-u jaki ustawiłeś na wejściu do poczty głosowej. Atakujący bowiem może zespoofować twój numer telefonu i odsłuchać twoją pocztę głosową.

Po drugie: poczta głosowa jest niezdrowa

Prince przypomina sobie, że ktoś do niego dzwonił w piątek, ale ponieważ nie znał numeru, przerzucił go na pocztę głosową. 2 minuty później otrzymał wiadomość z poczty głosowej, że jego hasło do konta Google zostało zmienione. Prince zainicjował więc procedurę odzyskania hasła. UGNazi też. I tak przejmowali między sobą skrzynkę ok. 10 razy. Dopiero wieczorem, po informacji od znajmego, który próbując się dodzwonić do Prince’a usłyszał dziwne rzeczy, Prince zdał sobię sprawę, że ktoś przekierował jego pocztę głosową.

A teraz najlepsze. PIN do poczty głosowej Prince ustawił sobie na 24 losowe cyfry. Nikłe są więc szanse, że UGNazi zgadli PIN. Bardziej prawdopodobne, że po prostu korzystając z socjotechniki przekonali pracownika sieci GSM do przekierowania skrzynki na którą trafiają nagrania z poczty głosowej.

Po trzecie: Cloudflare sam strzelił sobie w kolano

No dobra, ale jakim cudem dostęp do skrzynki prezesa Cloudflare’a daje możliwość sterowania kontami wszystkich klientów? No właśnie… tu dochodzimy do momentu, w którym okazuje się, że w tym ataku nie tylko Google dało ciała (błąd w logice biznesowej polegający na usunięciu 2 factor authentication po resecie hasła), nie tylko AT&T dało ciała (przekierowanie numeru poczty głosowej), ale ciała dał także Cloudflare.

Na jedną ze skrzynek w Google Apps (do której UGNazi miało dostęp bo mając konto Prince’a miało uprawnienia administratora domeny) forwardowane były wszystkie e-maile resetu haseł do kont klientów Cloudflare’a. Cloudflare twierdzi, że w celu monitoringu… A więc coś co miało być funkcją “podnoszącą” bezpieczeństwo klientów, zadziałało na ich niekorzyść.

Jak się zabezpieczyć?

Cloudflare podjęło decyzję o usunięciu wszystkich numerów telefonów jako metod odzyskania/resetu hasła dla kont Google. My dodajmy tylko tyle, że usuniecie telefonów z kont Google nie uniemożliwia wykorzystania 2 składnikowego uwierzytelnienia — Google udostępnia bowiem podwójne uwierzytelnienie nie tylko via SMS/telefon, ale również poprzez osobną aplikację generującą tokeny. Aplikację można pobrać na iPhone’a, Androidy oraz Blackberry i korzystać z niej “offline” bez spinania telefonu z kontem Google.

Zapis ataku na CloudFlare

Zapis ataku na CloudFlare

PS. Aha, UGNazi osiągnęli swój cel i jedyne co zrobili to przekierowali domenę 4Chana na ich konto Twitterowe. Ale nawet tak bzdurne uwieńczenie tych zabaw nie umniejsza tak fajnego wektora ataku… Na marginesie, poważniejszym efektem działań UGNazi było opisywane przez nas niedawno włamanie i wyciek danych z popularnego systemu billingowego WHCMS.

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

45 komentarzy

Dodaj komentarz
  1. Pełen szacun za to jak wiele kroków tak mało pewnych, musieli wykonać aby tylko na chwilę podmienić 4chan :) Cała operacja pewnie zajęła nie jak zwykle chwilę, tylko godzinę albo dwie, żeby przegadać AT&T, powalczyć 10 razy o skrzynkę i resety haseł :)

    • Akcja trwała ok. 2 tygodnie. Myślę, że nie mieli pełnego scenariusza tego co i jak chcą zrobić (nie mogli przewidzieć, że prezes będzie miał admina/dostęp do tokenów resetujących hasła innych klientów). Pewnie z ciekawości chcieli zaatakować CEO CF, a przy okazji wyszły ciekawe błędy i łut szczęścia sprawił, że wpadli na ten wewnętrzny debuggingowy mechanizm CF-a z reset tokenami — jak popatrzysz na ich inne dokonania, to oni nie “hackują” oni odpowiadają na pytania resetujące hasła ;)

  2. Mindhacking na pracowniku AT&T

  3. Ładnie ;>

  4. Dwuskładnikowa autoryzacja jest rownież do obejścia jak ktoś używa natywnego klienta Google Talk. Przejście do poczty z klienta GT odbywa się bez logowania i tylko na podstawie hasła aplikacji. Same hasła dla aplikacji Google to bezsens, ponieważ są generowane automatycznie (losowe znaki i długie hasło) i nikt ich nie zapamięta i dlatego użytkownicy wybierają zapamiętanie hasła w aplikacji …

    • A mnie się wydaję, że hasło do aplikacji to hasło do konta Google.

    • Tylko wtedy jak nie ma autoryzacji dwuetapowej

    • Niedawno jak logowałem się przez AdWords na konto Google to też nie musiałem podawać kodu SMS/hasła wygenerowanego a w tym dniu nie logowałem się jeszcze na konto. Nie wiem czy to zostało już naprawione ale logując się na AdWords mogłem buszować bez niczego po GMailu.

  5. Dawno tak ciekawej historyjki nie było. Respect dla kolesi.

  6. Nice. To się nazywa profeska. A nie SQL Injection w stronach rządowych i od razu wielka duma ;)

  7. Jak się to wszystko ma do:

    This is where UGNazi steps in. The hackers claim that Prince and Google are both wrong.

    “Nah. There’s no way you can social engineer a Google App. I don’t know what he was talking about. We did get in his emails though: matthew@cloudflare.com and mprince@gmail.com,” Cosmo told Softpedia.

    “We got into their main server. We could see all customer account information, name, IP address, payment method, paid with, user ID, etc. and had access to reset any account on CloudFlare,” he said.

    • Ciekawe. Od siebie dorzucę, że do tej pory Cloudflare nie wysłało żadnego e-maila klientom i nie wymusiło resetu haseł, co jeśli ktoś korzysta z ich usług, to niezależnie od tego kto ma rację (google+cloudflare) czy (ugnazi) warto wykonać w tego typu sytuacjach ;)

  8. Bardzo dobry art. Niezly fail z forwardem maili resetujacych hasla na prezesa ;)

  9. Świetna historia, oby więcej takich ciekawostek. Daje to pogląd na rzeczy, o których często się zapomina albo nie bierze pod uwagę (2-factor auth fail? niemożliwe :-) ).

  10. Sprawa pokazuje też problem z puszczaniem swoich usług przez cudze CDN – jednak co własna infrastruktura, to własna…

  11. “do serwowania statycznego contentu”
    “Wszystkie wasze requesty”
    “ustawić primary i secondary DNS”

    “Adresy te podawane są przeglądarkom”
    Powinno być: “browserom”.

    • Zastanawiałem się czy tłumaczyć. Podjąłem decyzję, że nie. Ciężko jest wyważyć granicę pomiędzy terminologią techniczną polską i angielską — nie twierdzę, że Niebezpiecznik jest w tym mistrzem, ale zakładam, że nasi czytelnicy nie mieli problemu z w/w zwrotami (podobnie jak i “secondary e-mail”), a ze zwrotami dodatkowy e-mail do konta Google lub “wasze żądania” ew. “pierwszy serwer DNS” mogą brzmieć dwuznacznie… ;)

    • @mkl: Mógłbyś chociaż zaproponować dobre tłumaczenia — konstruktywna krytyka jest zwykle dużo skuteczniejsza. Żeby nie było: też mi się nie podobają “wektor” i “serwowanie” w znaczeniach pozamatematycznych i pozasportowych, a zamiast “content” i “request” zdecydowanie napisałbym treść i żądanie.

      @pk: Moim zdaniem od strony językowej Niebezpiecznik stale się poprawia, bardzo mnie to cieszy. Ale weźcie też pod uwagę, że to właśnie ludzie tacy jak Wy powinni tworzyć dobre polskie tłumaczenia. Może warto napisać np. “pierwszy serwer DNS (primary DNS)” z angielską wersją kursywą w nawiasie i potem konsekwentnie stosować tłumaczenie? Wiele obecnie powszechnych zwrotów początkowo budziło opory.

      Jeśli można przy okazji złożyć kilka wniosków w sprawach językowych:

      * może piszcie np. “Że co?!” zamiast “Wait, what?!”
      * interpunkcja, interpunkcja, interpunkcja…
      * (wspomniane wyżej) obce słowa tradycyjnie zapisuje się kursywą

      Dobry artykuł, tak trzymać!

    • No po polskiemu byłoby tak:

      “do podawania nieruchomej zawartości”
      “wszystkie Wasze żądania”
      “ustawić pierwszorzędny i drugorzędny system nazw domenowych”

      faktycznie jakoś nie takoś, ale nawet bardziej uczenie
      ;)

    • Panowie po co takie potworki: podstawowy i dodatkowy serwer DNS.

    • But srsly, kto nie zrozumiał “primary” i “secondary” w configach macie serwer_nazw=”” czy nameserver? :) W zasadzie to co jakiś czas wraca temat pisania Niebezpiecznika po angielsku…

    • Niebezpiecznik czytają głównie ludzie z określonej branży, która posługuje się własnym, charakterystycznym językiem.
      “Wszystkie wasze żądania HTTP” brzmi po prostu dosyć sztucznie ;)

    • tia… All your base are belong to us! ;)

    • Ja bym przetłumaczył tak:
      “do podawania statycznej zawartości”
      “wszystkie Wasze żądania”
      “ustawić podstawowy i zapasowy DNS”

      DNS bym zostawił nieprzetłumaczony bo to prawie jak nazwa własna (podobnie jak UDP, TCP, IP)

    • @PK
      Tak! Piszcie niebezpiecznik po angielsku, bede mogl kumplom z pracy podsylac linki :). Jak pomysle ile ich omija bo nie znaja polskiego to az mi sie smutno robi :).

  12. Historia tak ciekawa, że aż trudno w to uwierzyć… Resetowanie hasła szefowi firmy, przekierowanie adresu jego poczty głosowej, walka na hasła do skrzynki mailowej i to wszystko tylko po to, żeby zdeface’ować 4chana? “WTF” samo się ciśnie na usta :D

  13. Jestem pełen podziwu. Miło tak po szkolę wejść i sobie poczytać że w internecie cały czas się coś dzieję. Dzięki redakcjo, bardzo przyjemnie się to czyta, dobrze opisane artykuły i wspaniałe tematy. Pozdrawiam

  14. nawiązując do tytułu:
    zdaje się, że Was też wtedy trochę podmieniło ;))
    http://img440.imageshack.us/img440/1020/201206010916niebezpiecz.png

    • Nie, to standardowy komunikat błędu CF kiedy nie moze sie dobić do backendu (fizycznie nie działa nasz prawdziwy serwer — a nie działał, bo na skutek awarii w Beyond, przez pół godziny nasza serwerownia straciła łączność ze światem).

  15. No i wyszedł kolejny błąd, jakim jest drugi zapasowy adres do resetowania konta u tego samego dostawcy. Ten drugi adres nie powinien być w Gmailu. Na dodatek tamten adres nie uzywał dwuskładnikowego uwieżytelniania.

  16. Nie zwykle ciekawa historia, a buntownicy odmian się czepiają… Ciekawe jak oni wyglądają ;)

  17. Gdzie w tym wszystkim anonimowość? O ile w sieci Internet można użyć którejś z metod Tor/Proxy/VPN to co z poniższymi aspektami?

    – odbiór poczty głosowej: musiało nastąpić przekierowanie na konkretny numer, który w tym czasie był podłączony do konkretnego BTSa (mamy przybliżoną lokalizację). Budka telefoniczna? No to przeglądamy kamery z monitoringu miejskiego.
    – nakłonienie operatora AT&T: telefonicznie (patrz. powyżej) czy osobiście w biurze? Jeśli w biurze to pewnie są kamery CCTV. Jeśli telefoniczna, czy podczas rozmowy użyto jakiegoś syntezatora mocy? Może chociaż jakieś filtry zniekształcające głos? Skąd pewność, że NCIS, FBI, Secret Service (i NASA :P) nie potrafią “odfiltrować” tych zniekształceń.

  18. > Zarówno Niebezpiecznik, 4Chan jak i kilkanaście tysięcy innych stron internetowych
    > korzysta z CDN-ów Cloudflare’a do serwowania statycznego contentu (obrazki,
    > skrypty js, css).

    Przez chwilę myślałem, że “nadużywacie” Cloudflare, jako że Cloudflare NIE POZWALA na wykorzystywanie ich jako magazyn (cały ruch musi ich przez ich serwery, nie tylko statyczne rzeczy) :)

  19. GMail… Zaczynam go traktować jako zabawkę.

    Za pomocą funkcji -nie mogę użyć żadnej z metod odzyskania hasła-, można przejąć praktycznie każde konto…. Wystarczy garść informacji o userze, a jak ich nie ma, to można sprowokować jego zachowanie i już są informacje.

    Google za bardzo przejął się automatami facebooka i też chce być trendy.

  20. […] pamiętacie grupę UGNazi, która mając więcej szczęścia niż rozumu uzyskała obeszła podwójne uwierzytelnienie na GMailu i włamała się do usługi CDN z której m.in. korzysta […]

  21. […] na Dropbox, jest więc bardzo podobny do ataku na Cloudflare, do którego również dostano się dzięki przejętej skrzynce pocztowej jednego z pracowników i […]

  22. […] tego ataku jest tak samo dobra (i równie skomplikowana) co opisywany przez nas niedawno atak na usługę Cloudflare, dzięki której można było podmienić zawartość milionów serwisów…. Tym razem atakującymi była grupa o nazwie Clan VV3, a wszystko zaczęło się od […]

  23. […] Apps I to jest trzeci błąd JoeMonstera. Brak włączonego dwuskładnikowego uwierzytelnienia, jak wielokrotnie już wspominaliśmy, zazwyczaj kończy się […]

  24. […] grupie UGNazi pisaliśmy na Niebezpieczniku już kilka razy. Jej lider, Cosmo, został niedawno zatrzymany przez FBI. Ma 15 lat, a swoimi zdolnościami […]

  25. […] 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 […]

  26. […] W skrócie: CloudFlare’owi zależy na tym, żeby o ataku było jak najgłośniej, bo wtedy więcej osób dowie się o tym, co sprzedają i że całkiem nieźle radzą sobie z DDoS-ami (trochę gorzej z fuckupami ich własnych pracowników: jeden rozłożył całą firmę, drugi –a był nim sam prezes — spowodował wyciek danych klientów). […]

  27. […] ..i przede wszystkim, zawsze bądźcie czujni! Z ostrożnością podchodźcie także do wiadomości przekazywanych przez ten blog (zwłaszcza w pierwszego kwietnia ;) — w końcu i nas ktoś kiedyś może “zhackować”. […]

  28. […] przejął konto u rejestratora domeny i przekierował ją na swoje serwery czyli wykonał tzw. atak DNS hijacking, polegający na uzyskaniu nieuprawnionego dostępu do konta rejestratora domeny google.ps, a […]

  29. […] przejęcie komputerów Apple jednego z dziennikarzy oraz historię Cloudflare, gdzie od włamania na skrzynkę prezesa atakujący doszedł do przejmowania kont użytkowników […]

  30. nie mozna sobie strzalic w kolano. w stope mozna

Odpowiadasz na komentarz mkl

Kliknij tu, aby anulować

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

RSS dla komentarzy: