Miałem dziś napisać o pewnej niespodziance jaką ekipa z Cloudflare w ostatnich dniach sprawiła tym, którzy korzystają z ich programu „Project Galileo”, ale życie często pisze własne scenariusze. Zaczęło się od konieczności ponownego zalogowania do wszystkich kont Google na telefonie, a już po chwili wiedziałem, że o ile faktycznie będzie dziś okazja do napisania o Cloudflare, to wydźwięk tego wpisu nie będzie „aż tak pozytywny” jak wcześniej zakładałem (w trakcie zbierania materiałów niejaka Dana najwidoczniej postanowiła, że prewencyjnie poprawi mi humor i zaczęła swój komentarz od słów „Ty palancie!!!!!!!!!!!!!!! wyłudzaczu debilu” skierowanych w moją stronę).

Cloudbleed, czyli i Cloudflare czasem krwawi

Chwilę po północy (a jakże by inaczej niż w piątek ;-)) okazało się, że „w ostatnich dniach” w usłudze Cloudflare w pewnych sytuacjach dochodziło do wycieku „przypadkowych danych, z przypadkowych stron” korzystających z usługi. A patrząc na to, że Cloudflare jest chyba najpopularniejsza usługą typu proxy, obsługującą kilka milionów stron/domen sytuacja zaczyna wyglądać na niezwykle poważną. Na tyle poważną, że wiadomość o udanej „kolizji” skrótów SHA-1 wydaje się nie mieć większego znaczenia… ;-)

Wszystko zaczęło się od tweeta jakiego kilka dni temu opublikował na swoim koncie Tavis Ormandy z zespołu Google Project Zero:

Zapewne prośba Tavisa o pilny kontakt z zespołem bezpieczeństwa jakiejkolwiek usługi musi budzić „popłoch”, to w przypadku usługi typu Cloudflare zdecydowanie nie jest to dobra wiadomość (no chyba, że w Google szukaliby pilnej ochrony przed atakiem DDoS ;-)).

Wyciek pamięci, wrażliwej pamięci

Jak można przeczytać na blogu Cloudflare, oraz na stronach Google Project Zero błąd mógł w (nie)sprzyjających warunkach w odpowiedzi na zapytanie np. przeglądarki użytkownika odwiedzającego stroną schowaną za Cloudflare przesłać dane pochodzące z innych stron/serwisów, w tym również takie dane, które nie powinny być dostępne publicznie.

Co gorsze – na tego typu odpowiedzi trafiały również roboty indeksujące wyszukiwarek i innych usług/serwisów „przeczesujących zakamarki internetu”. Na szczęście – dzięki wspólnej akcji Google i Cloudflare – w najpopularniejszych usługach tego typu nie powinno już być tych danych, choć internet przeczesuje też sporo innych „robotów” i nie można wykluczyć, że jakieś dane znajdują się również w ich bazach.

Modyfikacja kodu HTML

Wiele usług działających w ramach Cloudflare dokonuje „w locie” modyfikacji kodu HTML strony, tak by np. do przeglądarki użytkownika przesłać go zgodnie z ustawieniami na koncie, czyli. np. zakamuflowanymi adresami e-mail, wstawionymi kodami Google Analytics itp.

I to właśnie w tym mechanizmie, w wyniku błędu dochodziło do wycieków pamięci, co skutkowało m.in. dopisywania – w pewnych okolicznościach – danych pochodzących z jednej strony schowanej za Cloudflare do kodu HTML innej strony, na której znajdowała się „specyficzna kombinacja niedomkniętych tagów HTML” (bardziej szczegółowy opis znajdziecie na blogu Cloudflare).

/* generated code */
if ( ++p == pe )
 goto _test_eof;

Wprawdzie błąd mógł występować od 22 września 2016 (zmiany w sposobie działania niektórych narzędzie dostępnych w ramach usługi Cloudflare), to przez szczęśliwy przypadek do wycieków pamięci zaczęło dochodzić dopiero w okolicach 13 lutego, więc wszystko trwało ok 4 dni, bo „chwilę” po tweecie Tavisa zespół Cloudflare usunął/zablokował przyczynę, wyłączając globalnie część funkcji, w przypadku których mogło dochodzić do wycieków pamięci:

Między 13 a 18 lutego błąd dotyczył 1 na 3 300 000 zapytań HTML, czyli ok 0,00003% wszystkich zapytań – niby mało, ale pamiętajcie, że skala działania Cloudflare jest na tyle duża, że nawet „promile promili” to już całkiem sporo przypadków.

Według dostępnych informacji problem wycieku „potencjalnie wrażliwych danych” dotyczył około 150 klientów/stron i ekipa z Cloudflare jest z nimi w kontakcie. Odpowiedni e-mail dostałem również i ja, choć w moim przypadku jest to na szczęście tylko informacja o problemie, oraz informacja, że nie dotyczy to moich domen – a przynajmniej nie wykryto, by dotyczyło to moich domen:

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.

Chronologia wydarzeń

Chronologicznie wyglądało to tak:

  • 2016-09-22 Automatic HTTP Rewrites enabled
  • 2017-01-30 Server-Side Excludes migrated to new parser
  • 2017-02-13 Email Obfuscation partially migrated to new parser
  • 2017-02-18 Google reports problem to Cloudflare and leak is stopped

Więc jak widać – najwięcej „roboty” było 18 lutego:

  • 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

Na koniec najtrudniejsze, czyli odpowiedź na pytanie co dalej?

Na pewno nie ma co panikować – mleko i tak się już rozlało, zapewne warto prewencyjnie rozważyć zmianę haseł w serwisach korzystających z usług Cloudflare, nawet jeśli nie logowaliście się do nich w dniach 13-18 luty – zawsze mógł to robić np. administrator, przeglądający „jakieś dane” za pomocą panelu zarządzania działającego za Cloudflare.

Można też spodziewać się kolejnych wymuszonych resetów haseł, jak choćby sytuacja z dzisiejszego poranka i konieczności ponownej autoryzacji wszystkich kont Google w telefonie, choć oficjalnie Google nie potwierdza związku, a wręcz „słowami Tavisa” zaprzecza.

Warto też aktywować uwierzytelnienie dwuskładnikowe w każdym serwisie który je oferuje, zwłaszcza, jeśli konto służy nam do czegoś więcej niż np. „łapania SPAMu”, oraz rozważyć wygenerowanie różnych tokenów/kluczy API wykorzystywanych do autoryzacji stron i usług.

Czy to koniec Cloudflare?

W jednym z komentarzy (chyba na blogu Cloudflare) znalazłem stwierdzenie, że to jest ich koniec. Raczej tak nie będzie, choć na pewno zostawi to na usłudze sporą rysę, którą – i to akurat być może dobra dla nas strona tej historii – będą musieli postarać się, i to mocno zakopać.

Sam z usług Cloudflare rezygnować nie zamierzam, zwłaszcza że ciężko o jakąś sensowną alternatywę – mamy tu nie tylko usługę CDN, ochronę przed różnymi zagrożeniami (tak, tak… ;-)), ale również szybkie i wygodne w konfiguracji serwery DNS.

No cóż – wpadki się zdarzają, całość może sprawiać wrażenie dość poważnych, ale na szczęście bliższe przyjrzenie się sprawie uspakaja, przynajmniej mnie, choć oczywiście wolałbym by ta sytuacja nie miała miejsca…

[Aktualizacja 2017.03.02]

Szczegółowe wyjaśnienia

Na blogu Cloudflare pojawił się długi i dość szczegółowy wpis dotyczący problemy. Nie będę przytaczał tutaj całego wpisu, ale pozwolę sobie zacytować/wkleić „tabelkę” opisującą potencjalne szanse na to, że to właśnie nasze dane wyciekły:

 Requests per Month       Anticipated Leaks
 ------------------       -----------------
        200B – 300B         22,356 – 33,534
        100B – 200B         11,427 – 22,356
         50B – 100B          5,962 – 11,427
          10B – 50B           1,118 – 5,926
           1B – 10B             112 – 1,118
          500M – 1B                56 – 112
        250M – 500M                 25 – 56
        100M – 250M                 11 – 25
         50M – 100M                  6 – 11
          10M – 50M                   1 – 6
              < 10M                     < 1

Pamiętajcie tylko, że jest to statystyka, więc jeśli ja mam dwa jabłka, Ty nie masz akurat żadnego, to statystycznie mamy po jabłku – niby OK, ale problem się pojawi, gdy każdy z nas postanowi zjeść „swoje jabłko”.

(!) Zgłoś błąd na stronie
Pomogłem? To może postawisz mi wirtualną kawę?
LUTy dla D-Cinelike (DJI Mini 3 Pro, DJI Avata, OSMO Pocket) od MiniFly
Wdrożenie Omnibusa w sklepie na WooCommerce
Jak (legalnie) latać dronem w Kategorii Otwartej
Patryk