10:31
24/2/2017

Dziś, chwilę po północy, znany badacz bezpieczeństwa pracujący w Google, Tavis Ormandy ujawnił informacje na temat ogromnej luki w Cloudflare. Z Cloudflare korzysta ponad 5,5 milionów serwisów internetowych, takich jak Uber, FitBit, 1Password. Wrażliwe dane użytkowników tych serwisów, w tym hasła, ciasteczka, adresy IP, tokeny, dane osobowe, prywatne wiadomości, zdjęcia oraz klucze szyfrujące “losowo” wyciekały i co gorsza część z nich wciaż jest zcache’owana przez wyszukiwarki internetowe… Szanse na to, że ktoś pozyskał wasze dane może i są małe, ale radzimy nie ryzykować i jak najszybciej zmienić hasła w serwisach, z których korzystacie, a które wykorzystują usługę Claudflare. Pod koniec artykułu publikujemy ich pełną listę.

Problem dotyczy wszystkich klientów Cloudflare

Historia odkrycia tego błędu, który w usłudze Cloudflare istniał od 22 września 2016, zaczyna się 17 lutego 2017, czyli jak każdy kryzys, wybucha w piątek. Wtedy to Tavis poprosił na Twitterze o kontakt do kogoś z działu bezpieczeństwa Cloudflare. W przypadku Tavisa, taka prośba zawsze oznacza odkrycie przez niego poważnego błędu.

Powodem pilnego kontaktu z kimś z Cloudflare była luka, na którą Tavis natknął się przypadkiem. Podczas analizy wyników w projekcie nad którym pracował, zauważył dziwne, niepasujące do oczekiwanych dane. Po chwili analizy zorientował się, że dane te pochodzą z serwerów reverse-proxy Cloudflare, z których korzysta naprawdę spora liczba znanych serwisów internetowych.

Jak opisuje swoje znalezisko Tavis:

Wyglądało to tak, jakby specyficzna kombinacja niedomkniętych tagów na stronie HTML była podczas parsowania przez Cloudflare uzupełniana danymi z pamięci serwera proxy. Ponieważ serwery te współdzielone są przez wielu klientów, zdałem sobie sprawę z tego, że problem dotyczy wszystkich klientów Cloudflare.

Co znajdowało się w danych z pamięci serwerów, które były wstrzykiwane do odpowiedzi na żądania przypadkowym klientom?

  • klucze szyfrujące i klucze API
  • ciasteczka
  • hasła
  • adresy IP użytkowników
  • tokeny OAuth
  • parametry URI
  • fragmenty żądań POST zawierające np.:
  • prywatne wiadomości z serwisów randkowych
  • żądania API z managerów haseł przesłane przez HTTPS
  • stopklatki z filmów pornograficznych
  • potwierdzenia rezerwacji hoteli

Informacje te otrzymywał każdy, kto “wchodził” na pewne strony stojące za Cloudflarem, choć nie zdawał sobie z tego sprawy. Przeglądarka nie wyświetlała ich w łatwodostępny sposób.

Co gorsza, dane te były również odczytywane i zapamiętywane przez crawlery wyszukiewarek internetowych, które regularnie odwiedzają strony internetowe aby je zideksować lub wykonać ich kopię. TAK, dane użytkowników korzystającyc z serwisów stojących za CloudFlare wciąż są zapisane na tysiącach dysków różnych firm crawlujących internet. Także Google — dlatego Tavis skontaktował się z kolegami z firmy i Google rozpoczęło “czyszczenie” zcache’owanych stron z wrażliwych danych, które zwracał Cloudflare, a które znajdowały się w kodzie pozyskanym przez crawlery.

Tavis wspomniał też, że dane, które pozyskał w trakcie analizy błędu, z racji ich “wrażliwości”, zostały usunięte. Wyraził też obawę, że błąd mógł być przez kogoś odkryty wcześniej i nie wiadomo, czy ktoś o nim wiedział i wcześniej go wykorzystywał do zbierania informacji lub ataków.

Cloudflare szybko podjął działania, ale…

Cloudflare szybko wkroczył do akcji, zreprodukował problem i wspólnie z Taviso pracował nad usunięciem błędu. Tavis wspomniał, że ze względu na powagę sytuacji, anulował swoje plany weekendowe aby wspomóc zespół Cloudflare w usuwaniu błędów.

The examples we’re finding are so bad, I cancelled some weekend plans to go into the office on Sunday to help build some tools to cleanup.

Tym bardziej dziwi to, co stało się potem… Cloudflare, bardzo komunikatywne i szybko przystępujące do łatania, obiecuje poinformować o błędzie swoich klientów we wtorek. Ale nie dotrzymali tego terminu. Nie dotrzymali też kolejnego terminu i nie chcieli Tavisowi podesłać oświadczenia, jakie planują opublikować. Proces opóźniali tłumacząc, że jeszcze wiele wariantów problemu może być obecnych w ich infrastrukturze i prosząc Tavisa o weryfikację pewnych danych — które nie były zbyt sensowne, a co gorsza zawierały wrażliwe dane:

Cloudflare explained that they pushed a change to production that logged malformed pages that were requested, and then sent me the list of URLs to double check. Many of the logged urls contained query strings from https requests that I don’t think they intended to share. Nevertheless, we will keep the data safe and destroy it once we’ve checked if they match any cached pages.

Wreszcie jednak, Cloudflare, któremu Tavis zagroził 7-dniową polityką ujawniania błędów, zdecydowało się na publikację swojego oświadczenia w tej sprawie. Tavis uważa, że jest ono dobre, choć ignoruje wagę niektórych ryzyk płynących z tego błędu.

Cloudbleed — na czym polegała ta luka i kto został nią dotknięty?

Z opisu Cloudflare wynika, że za błąd odpowiedzialne były następujące funkcje, korzystające z tego samego wadliwego parsera HTML, zawierającego błąd klasy buffer overrun (użycie == zamiast >=):

  • email obfuscation,
  • Server-side Excludes
  • Automatic HTTPS Rewrites

Wedle Cloudflare, wyciek danych zachodził przede wszystkim w datach od 13 do 18 lutego, z częstością 1 żądania na każde 3,300,000 żądań obsługiwanych przez Cloudflare (to ok. 0.00003% ruchu). Problem ujawniał się podczas odwiedzin stron z błędnymi tagami (ok. 0,06% wszystkich stron obsługiwanych przez Cloudflare) ale

dane, które pojawiały się na tej “niewielkiej” liczbie stron, mogły pochodzić z dowolnej innej usługi stojącej za Cloudflarem. Ta “niewielka liczba stron” została też niestety zcache’owana przez wiele crawlerów i dane te są wciąż dostępne dla ich właścicieli. Google i Bing skasowali już cache dla tych stron.

Tu znajdziecie listę wszystkich domen korzystających z Cloudflare, czyli tych, których wrażliwe dane mogły znaleźć się w odpowiedziach na żądania skierowane do wspomnianych wcześniej 0,06% stron zawierających błędne tagi. Przykłady takich “błędnych danych” zcache’owanych przez wyszukiwarki możecie zobaczyć poprzez wykonanie tego zapytania do DuckDuckGo:

Warto jednak zaznaczyć, że najwcześniej problem mógł ujawnić się od 22 wrzesnia 2016 roku, ale na bardzo specyficznej, mało popularnej kombinacji usług w Cloudflare. Co istotne — ze względu na separację infrastruktury — prywatne klucze SSL klientów Cloudflare nie mogły przedostać się do zwracanych danych.

Szybkość działania Cloudflare dotyczącego błędu o takiej skali budzą podziw:
2017-02-18 0011 Tweet from Tavis Ormandy asking for Cloudflare contact information
2017-02-18 0032 Cloudflare receives details of bug from Google
2017-02-18 0040 Cross functional team assembles in San Francisco
2017-02-18 0119 Email Obfuscation disabled worldwide
2017-02-18 0122 London team joins
2017-02-18 0424 Automatic HTTPS Rewrites disabled worldwide
2017-02-18 0722 Patch implementing kill switch for cf-html parser deployed worldwide
2017-02-20 2159 SAFE_CHAR fix deployed globally
2017-02-21 1803 Automatic HTTPS Rewrites, Server-Side Excludes and Email Obfuscation re-enabled worldwide

To nie pierwsza wpadka Cloudflare (por. jak można było zhackować Niebezpiecznika), ale firma zawsze dość otwarcie informuje nie tylko o tym co robi, ale także skąd wynikały i na czym polegały popełniane przez nią błędy. Co ciekawe, podobny problem z wyciekiem danych od jednego klienta pojawiającym się w odpowiedzi na żądania kierowane do drugiego klienta w przeszłości dotyczył także konkurencyjnej do Cloudflare firmy Incapsula.

Każdy z nas jest potencjalną ofiarą — co robić, jak żyć?

Wyciec mogły dane każdej osoby, która korzystała z jakiekolwiek z setek tysięcy serwisów internetowych, które korzystają z Cloudflare. Także, jeśli robiła to przy pomocy nie przeglądarki internetowej, a aplikacji mobilnej.

Dane, które mogły wyciec, to wszystko co jest wymieniane w ruchu do serwisów korzystających z Cloudflare. Wasze adresy IP, hasła, tokeny, wiadomości prywatne, nagie zdjęcia. Na podstawie tych danych, o ile ktoś je przejął, można was szantażować (na to nic nie poradzicie, ale jest to małoprawdopodobne) albo próbować przejmować wasze konta. Dlatego w pierwszej kolejności:

  • ZMIEŃCIE HASŁA do każdego serwisu, z którego korzystacie, a który korzysta z Cloudflare’a (tutaj pełna lista)
  • WŁĄCZCIE 2FA w każdej z usług, która na to pozwala. Nie pomoże to w przypadku, gdy ktoś pozyskał wasz token sesyjny, a serwis nie wiąże go z lokalizacją / fingerprintem przeglądarki, ale znacznie ograniczy przejęcie konta w przypadku pozyskania jedynie hasła.

Zresztą włącznie 2FA, zwłaszcza w oparciu o klucz U2F to podstawa ochrony przed poważniejszym problem, phishingiem, i tak czy inaczej warto to w końcu zrobić. Wierzcie nam, że kiedyś podziękujecie nam za tą radę. Tutaj znajdziecie opis jak to zrobić w przypadku GMaila, Dropboksa, GitHuba i Facebooka na przykładzie kluczy YubiKey.

PS. Te i inne rady, zapewniające bezpieczeństwo podczas korzystania ze współczesnych technologii (nie tylko serwisów w chmurach, ale IoT, smartphonów, etc.) przekazujemy w ramach cyberwykładów. Od wczoraj można zamówić sobie taki wykład w siedzibie swojej firmy — zapraszamy do zapoznania się z dostępnymi tematami naszych cyberwykładów. :)


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.

53 komentarzy

Dodaj komentarz
  1. Warto wspomniec, ze wsrod dotknietych stron sa takie adresy konczace sie na .pl:
    antyweb.pl
    cda.pl
    chomikuj.pl
    demotywatory.pl
    fotka.pl
    goldenline.pl
    kwejk.pl
    peb.pl
    sadistic.pl
    trojmiasto.pl

    czyli twoje konto na demotywatorach jest w niebezpieczenstwie! goldenline tez…

    • Nie każda z tych stron korzysta z proxy CF tylko jako serwer DNS.

    • twój email który podałeś na niebezpiecznik.pl też :>

    • arabek

      No tak, ponieważ strona korzysta z DNSów cloudflarowych ale nie korzysta z ich proxy.
      Podobna sytuacja jak z fastmail

      https://twitter.com/FastMail/status/834939787924557824

      Chyba że jestem w błędzie :D

    • @Tavin jesteś w błędzie:

      [ userhost: ~ ]$ host niebezpiecznik.pl
      niebezpiecznik.pl has address 104.31.8.183
      niebezpiecznik.pl has address 104.31.9.183

      $ whois 104.31.8.183
      NetRange: 104.16.0.0 – 104.31.255.255
      CIDR: 104.16.0.0/12
      NetName: CLOUDFLARENET

    • Może się mylę, ale chyba w tym wypadku bezpieczniejsze byłoby logowanie się na stronie za pomocą fb…

    • loteriaparagonowa.gov.pl

    • @Paweł
      no, logowanie się przez fb wszędzie gdzie się da to rewelacyjny pomysł. Będziesz szczególnie zachwycony, gdy fb da Ci bana na np. tydzień, za wypowiadanie swojego zdania na jakiś temat, a Twoje zdanie nie będzie się zgadzało z poprawnością polityczną fb.

    • Problem jest mocno nadmuchany, aby być podatnym to trzeba było włączyć w CF tego parsera. Większość serwisów tego nie robiła.

    • Nie. Przeczytaj dokladnie.

  2. No to czeka nas dużo zabawy z zmienianiem haseł :/

  3. Poraża ilość typosquattingu… Ale ‘niebespiecznik.pl’ jest klasa!

  4. http://niebespiecznik.pl :D

  5. Przyjmimy, że wycieki miały miejsce w dniach 13-18 lutego. Czy to oznacza, że jeśli nie logowałem się w tym okresie do stron korzystających z Cloudflare, to żadne moje dane nie mogły wyciec?

    • No na to wygląda, bo to leciało z pamięci proxy, a skąd tam mialoby się wziąć hasło kogoś kto się ostatnimi czasy nie logował.
      Ale to tylko mój domysł na podstawie artykułów z netu.

    • Mógł polecieć hash albo plaintext jeśli administrator tego serwisu oglądał sobie tabele SQL po HTTP(S) przez jakiś interfejs/panel zarządzający ;)

    • @Piotr Konieczny , a jaka jest realnie szansa, że coś takiego miało miejsce? Może to głupie pytanie, ale nie znam się na adminowaniu i nie wiem, jak bardzo rutynowe jest takie zadanie dla admina.

    • Prawdopodobieństwo jest niezerowe. Intuicja i opisy Tavisa / CF podpowiadają, że niewielkie. Ale decyzję czy ryzykować (i nic nie robić) czy zmieniać hasła, niech każdy podejmie sam.

  6. Jest jeszcze joemonster.org

  7. Czy z WaybackMachine (archive.org) też możnaby pozyskać dane tego typu?

    • Jeśli ich specjalnie nie usuną, to obstawiam, że tak. Archive.org zapisuje w końcu źródło strony.

  8. A, to dlatego Uber wymusił mi dwa dni temu zmianę hasła…

  9. Tutaj jest lista wstawiona przeze mnie stron z domeną .pl (ale nie .org.pl i pochodnymi) -> http://pastebin.com/MiaqM5Sb

    • i co wskazuje ta lista domeny, które są podatne na atak?

  10. jedynie chomikuj

    sprawdzałem kończące się ctrl+f i wpisałem .pl

    tylko chomik

  11. Właśnie dostałem maila od ceo cf że żadne info z moich domem nie wyciekło i że jak coś znajdą to natychmiast dadzą znać, taki masowy widać, ciekawe czy ci którym wyciekło też go dostali. Ktoś się może pochwalić?

  12. Lista serwisów nie działa…

  13. Dzisiejszy mail od CF:

    Dear Cloudflare Customer:

    Thursday afternoon, we published a blog post describing a memory leak caused by a serious bug that impacted Cloudflare’s systems. If you haven’t yet, I encourage you to read that post on the bug:

    https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/

    While we resolved the bug within hours of it being reported to us, there was an ongoing risk that some of our customers’ sensitive information could still be available through third party caches, such as the Google search cache.

    Over the last week, we’ve worked with these caches to discover what customers may have had sensitive information exposed and ensure that the caches are purged. We waited to disclose the bug publicly until after these caches could be cleared in order to mitigate the ability of malicious individuals to exploit any exposed data.

    In our review of these third party caches, we discovered data that had been exposed from approximately 150 of Cloudflare’s customers across our Free, Pro, Business, and Enterprise plans. We have reached out to these customers directly to provide them with a copy of the data that was exposed, help them understand its impact, and help them mitigate that impact.

    Fortunately, your domain is not one of the domains where we have discovered exposed data in any third party caches. The bug has been patched so it is no longer leaking data. However, we continue to work with these caches to review their records and help them purge any exposed data we find. If we discover any data leaked about your domains during this search, we will reach out to you directly and provide you full details of what we have found.

    To date, we have yet to find any instance of the bug being exploited, but we recommend if you are concerned that you invalidate and reissue any persistent secrets, such as long lived session identifiers, tokens or keys. Due to the nature of the bug, customer SSL keys were not exposed and do not need to be rotated.

    Again, if we discover new information that impacts you, we will reach out to you directly. In the meantime, if you have any questions or concerns, please don’t hesitate to reach out.

    Matthew Prince
    Cloudflare, Inc.
    Co-founder and CEO

  14. Przydałby się plugin do keepassx, żeby porównać listę domen z zapisanymi hasłami i sorted_unique_cf.txt…

    • To go napisz ;)

  15. Czy to ma coś wspólnego ze stronami googla i gmail w Polsce? od wczoraj obserwuję dziwne zachowania. Mobilny poprosił mnie o podanie hasła do poczty (mam dwustopniowe zabezpieczenie). Na tym mobilu mam apkę Ubera…

  16. Czy dzisiejsze pytanie o hasło do konta google w telefonach na androidzie jest z tym związane ? Reset/wylogowanie z sesji ?

  17. i znowu muszę żółte karteczki zmieniać :/

    a swoją drogą, ciekawe czy w wycieku poszły też numery kart kredytowych hm…

  18. A jak się ma logowanie przez inne serwisy do dotkniętych domen?
    Czy jeśli podpinam się do ktoregoś z serwisów przez “Zaloguj przez FB” to jestem “bezpieczny” czy wręcz przeciwnie, moje credentiale FB zostały skompromitowane?

    • Twoje “credentiale” z Facebooka w związku z tym błędem na 100% nie zostały skradzione. Ale identyfikator twojej sesji mogły zostać skopiowane i ktoś może się na danym serwisie pod ciebie podszywać. Lepiej wyloguj się i zaloguj ponownie.

  19. morele.net na liście :P A dopiero co hasło zapamiętałem :>

    • ooo, i taka ironia: haveibeenpwned.com :}

    • morele.net jest obsługiwane przez CloudFlare, ale nie ma potwierdzenia, że jakie kolwiek dane związane z tym serwisem wyciekły. Czytaj: wpamięci podręcznej wyszukiwarki Google jak i Bing dla stron wywołujących ten błąd nie znaleziono odnośnika do tego serwisu.

  20. nawet WOŚPa nie oszczedzili

  21. http://pastebin.com/tFZ4DnNS poprawiłem delikatnie moja listę polskich domen – dodałem .org.pl, .com.pl i .net.pl :)

    Podepnijcie to do artykułu jak możecie, może komuś się przyda.

    • pocztwp.p – taki adres jest na liście.
      Czy to aby nie jest literówka i chodzi o stare, poczciwe wp.pl?

  22. A wiadomo czy ktoś poniósł wymierne straty, czy na razie problem jest techniczny?

    • Jak na razie problem jest teoretyczny. Aby znaleźć wrażliwe dane z losowych serwisów trzeba było wejść na stronę hostowaną w jednym z 770 domen z 5,5 mln obsługiwanych przez ClaudFlare pomiędzy 13 a 18 lutego. Do tego zajrzeć do otrzymanych nagłówków HTTP. Gdyby ktoś z bardzo zainteresowanych takimi informacjami to zauważył i pobierał te dane to na pewno spowodowałoby to znaczny wzrost ruchu na tych stronach w okolicy tej daty. Tak samo by się stało, gdyby ktoś korzystał w tym celu z domeny skonfigurowanej w CloudFlare w nietypowy sposób pomiędzy 22 września 2016 a 18 lutego 2017 roku.

      Akurat dobrze się stało, że ktoś z Google prowadził badanie używanych znaczników w nagłówkach HTTP i wykrył anomalię w zachowaniu pewnych serwisów.

  23. Przydałby się plugin do takiego KeePassa aby mógł w łatwy sposób zweryfikować/porównać zapisane hasła do serwisów z tymi co siedziały w ClaudFlare i zostały złamane.
    Ręcznie przeglądać listę i porównywać ją z bazą zapisaną w managerze haseł – absurd.

  24. A co w sytuacji gdy ktoś wykorzystał CF do wydelegowania domeny i obsługi poczty?

  25. I w ten sposób kilkadziesiąt tysięcy klientów XABO straciło miliony dolarów.

  26. Przed wrześniem też były widoczne podobne sekwencje w Tor Browser w miejscu niektórych reklam.

  27. To wskazuje wprost. Nigdy na żadnym serwisie nie podawaj swoich prawdziwych danych. To co wprowadzisz do internetu nawet pod hasłem i po https – kiedyś stanie się jawne i na 100% wycieknie. Zawsze ktoś się o to postara pod pretekstem błędu.

  28. 1Password nie zagrożony. W końcu jaki jest najlepszy manager haseł? Wiadomo 1Password:)

  29. no i cert.pl leży i kwiczy :(

Twój komentarz

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

RSS dla komentarzy: