Na skutek błędu na serwerach Cloudflare potrafiły one w określonych warunkach w odpowiedzi dla klienta serwować takie dane jak hasła, tokeny czy inne poufne informacje należące do zupełnie innych serwisów. Takie odpowiedzi indeksował m.in. Google.
Wiadomość o kolizji SHA-1 została zupełnie przyćmiona informacją o fatalnym błędzie Cloudflare. Błędzie, który powodował ujawnianie najbardziej poufnych danych potencjalnie z każdej strony korzystającej z Cloudflare, którego skutki mogły być indeksowane przez wyszukiwarki ( i były!).
Odkrycie
Kilka dni temu zwróciliśmy uwagę na niepokojącego tweeta Tavisa Ormandy z zespołu Google Project Zero
Tavis znany jest z odkrywania bardzo poważnych błędów w zupełnie nieoczekiwanych miejscach. Tym razem szukał materiału do testów – i najwyraźniej szukał go w Google. W pewnym momencie natrafił na dziwne dane, które okazały się być zindeksowanymi przez Google fragmentami pamięci serwerów brzegowych Cloudflare. Cloudflare (z którego usług także my korzystamy) jest chyba największym „serwerem proxy” internetu. Za pośrednictwem jego serwerów przesyłana jest spora część internetowego ruchu milionów stron na całym świecie. Znalezisko było więc bardziej niż niepokojące.
Zespół Google w krótkim czasie odkrył, że na skutek błędu po stronie Cloudflare czasem jego serwery oprócz strony żądanej przez przeglądarkę serwowały także „śmieci” – pozornie przypadkowe dane. Niestety te „przypadkowe dane” okazały się:
- pełnymi sesjami aplikacji Ubera, FitBit czy portalu randkowego OKCupid (i potencjalnie milionów innych stron),
- kluczami API czy tokenami OAuth,
- hasłami zapisanymi otwartym tekstem,
- i wszystkimi innymi danymi przesyłanymi za pomocą żądań HTTPS do serwerów obsługiwanych przez Cloudflare.
Przykład ujawnionych danych
Reakcja
Google natychmiast powiadomiło Cloudflare i obie firmy wspólnie rozpoczęły prace nad usunięcie przyczyn i skutków. Cloudflare w ciągu kilku godzin usunęło przyczyny wycieku a około tygodnia trwało szacowanie jego rozmiaru i usuwanie śladów z największych wyszukiwarek. Zarówno Cloudflare jak i Google opublikowały dość szczegółowe opisy podejmowanych czynności – polecamy lekturę (choć trudno oprzeć się wrażeniu, że Cludflare trochę minimalizuje skutki incydentu w swoim opisie).
Strony zindeksowane przez największe wyszukiwarki zostały usunięte – lecz ujawniona lista wyszukiwarek współpracujących w tym zadaniu nie obejmuje np. firm chińskich czy rosyjskich (Cloudflare wspomina tylko o Google, Yahoo i Bingu). Do wycieków pamięci z Cloudflare nie powinno już dochodzić. Ich ślady można jednak nadal znaleźć. Np. szukając ciągu
"CF-Visitor: {scheme:http} CF-Host-Origin-IP"
w wyszukiwarce Yandex.ru możemy zobaczyć taki przykład:
Przyczyna
Wpis Cludflare zawiera dość szczegółową analizę, ale skracając ją dla niecierpliwych czytelników: 22 września 2016 nastąpiły zmiany w sposobie obsługi niektórych reguł serwerowych po stronie Cloudflare. Zmieniła się konfiguracja narzędzi filtrujących ruch, np. ukrywających adresy email, przepisujących linki z HTTP na HTTPS i blokujących niektóre elementy ruchu. Ta zmiana spowodowała, że błąd ujawnienia pamięci istniejący we wcześniej używanych narzędziach nie był już (przypadkowo) likwidowany na kolejnym etapie przetwarzania informacji i zaczęło dochodzić do wycieków. 13 lutego po uruchomieniu kolejnych funkcji błąd stał się bardziej widoczny i po 4 dniach trafił na niego Taviso.
Sam błąd polegał na niewłaściwych przetwarzaniu błędnego kodu HTML, np. przy braku zamkniętego znacznika. Występował tylko w niektórych serwisach, ale powodował wyciek danych serwisów zupełnie niepowiązanych – ponieważ wszystkie korzystały z tych samych serwerów pośredniczących i tej samej pamięci operacyjnej. Cloudflare wspomina, że błąd HTML dotyczył 161 domen, które łącznie powiązane były z 770 adresami URL zwracającymi ujawnione dane. Same dane mogły dotyczyć każdego serwera korzystającego z Cloudflare.
Skutki
Cloudflare twierdzi, że strony zawierające ujawnione dane zostały usunięte z wyszukiwarek. Nie wszyscy się zgadzają – kilka godzin temu można było np. znaleźć ciasteczka giełdy BTC Poloniex:
https://twitter.com/julianor/status/834930622334439427
Warto także zauważyć, że jeśli nawet z dużych wyszukiwarek strony zniknęły, to wcale nie jest powiedziane, że nie zostały zapisane w innych miejscach, przez inne skrypty.
Zmieniać hasła?
Prawdopodobieństwo, że Wasze dane wyciekły w tym incydencie oceniamy jako raczej niskie. Problem został dość szybko wykryty i załatany. Trudno jednak ocenić, jak wiele informacji mogło zostać przypadkowo ujawnionych. Np. w przypadku naszego serwisu najgorsze, co mogło zostać ujawnione, to hasła dostępu redakcji – i te zaraz zmieniamy, bo wypada. Każdy musi sam ocenić ryzyko i potencjalne skutki. Dla superwrażliwych danych zalecamy zmianę kluczy lub haseł – ale kto trzyma superwrażliwe dane w chmurze…
Komentarze
Każda okazja do zmiany haseł jest dobra :) Nie ma tego złego…
… co by NSA nie wyszło ;)
Czy zagrożone są dane tylko tych osób, które w podanym okresie logowały się i korzystały z usług powiązanych z Cloudflare, czy też każdego, kto posiadał w tym okresie konto w tych usługach, nawet, jeśli się na nie nie logował?
Teoretycznie, jeżeli się nie logowałeś, to Twoje dane nie powinny być przetwarzane (i tym samym potencjalnie wyciec), ale nie ma gwarancji, że inny klient nie 'wzbudził’ mechanizmu po stronie serwera, który wysłał do CloudFlare 'za dużo’ – np. fukcja 'Inni klienci kupili to czy tamto’ – teoretycznie nie powinna wyciągać z bazy danych personalnych innych klientów, ale nie masz gwarancji, że nie jest błędnie zaimplementowana (logicznie, lub technicznie) i nie spowodowała wysłania całości SELECT * from X WHERE Y w jakimś ukrytym polu, pliku XML itp.
Też nie do końca – wystarczy, że jakiś uprzywilejowany użytkownik/zarządzający stroną zalogował się do panelu webowego, który potencjalnie mógł zawierać więcej wrażliwych danych. Wówczas teoretycznie wszystkie te dane mogły wyciec.
Poszedł mailing od CloudFlare w którym piszą czy Twoje domeny są podatne czy nie.
„(…)
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.
(…)”
Czy można sprawdzić czy dana strona korzysta z Cloudflare?
Czy duże podmioty np. banki, microsoft, google korzystają z cloudflare w swoich usługach? (przypuszczam, że nie)
Pytam ponieważ nie mam ochoty zmieniać haseł wszędzie gdzie się logowałem przez ten czas.
Dziękuję za wszelkie merytoryczne odpowiedzi.
Sprawdź DNS-y.
@Borys ale DNS-y w Cloudflare Enterprise mogą być customizowane, podobnie jak strony błędów etc. Prościej: pokaż źródło, wyszukaj po „cloudflare”/”cf”, np. „try{if (!window.CloudFlare)” i już wiadomo.
whatsmydns.net
To jest kolejny przykład jak daje się kolejny narzut na swoją infrastrukturę, nad którym nie ma się kontroli.
Najgorsze jest to że ponad połowa osób, które korzystają ( nie kiedy nie świadomie z Cloudflare ) nigdy się o tym nie dowie i nic w tej kwestii nie zrobią.
Cześć developerów, nawet wiedząc o tym incydencie nawet nie powiadomi swoich klientów o tym.
Na pewno wnioski zostaną wyciągnięte.
Tak się kończy centralizacja. Jak w ogóle można oddać komuś cały nieszyfrowany ruch swojej strony? Przecież to jest proszenie się o kłopoty.
Naprawdę nigdy niczego nie kupiłeś dlatego że było najtańsze? Nie szukasz tanich ofert? Cena nie ma dla ciebie żadnego znaczenia przy wyborze? No jak myślisz dlaczego ludzie wybierają CloudFlare?
Na bezpieczeństwie nie powinno się oszczędzać. Zwłaszcza gdy chodzi o dane wrażliwe w wielkich firmach (duża ilość danych w bazach).
Panowie, sorry, ale trochę p*****licie. Uważacie, że robienie wszystkiego samemu, niekorzystanie z zewnętrznych dostawców usług ma same zalety? Albo, że wybór droższego dostawcy, dajmy na to Akamai by coś zmienił?
Po pierwsze błędy zdarzają się wszystkim. Cloudflare nie jest pierwszy i nie będzie ostatni. Wczoraj Yahoo, dziś Cloudflare, jutro Google albo inna znana firma. Naprawdę uważacie, że jesteście w stanie zarządzać swoim oprogramowaniem i infrastrukturą lepiej niż super specjaliści w tej dziedzinie? Uważacie, że w Waszym oprogramowaniu nie ma takich błędów? Cloudflare mogło potencjalnie zapobiec problemowi fuzz-testując swój legacy code. Wy rozumiem tego typu testy regularnie przeprowadzacie? To trochę jak nie wiem, powiedzieć że będę self-hostował swoją pocztę, bo jak można trzymać coś na GMailu, przecież złe Google czyta nasze maile! A jak nastąpi wyciek z GMaila (bo prędzej czy później nastąpi) to jeszcze się śmiać i mówić he he debile, trzeba było pocztę trzymać tak jak ja na własnym serwerze, a nie na jakimś darmowym mailu. Ale słyszałem o wielu padach poczty na własnych serwerach, a nie słyszałem o większym padzie GMaila. Tak samo słyszałem o wielu zDDoSowanych stronach, ale nie słyszałem o wielu takich przypadkach kiedy strona była za Cloudflarem.
Nie wiem czym kierowały się firmy przy wyborze Cloudflare, czy to była cena, czy to był fakt że CF daje sobie radę z mocnymi DDoSami, czy może łatwiejsza integracja z daną stroną. Mogę mówić za siebie – z moim malutkim serwisem poszedłem tam faktycznie dlatego, że było za darmo i za tą „cenę” dostaję moim zdaniem całkiem sporo. Przechwytywanie i modyfikacja ruchu przez CF sprawia, że owszem czuję się niekomfortowo, ale korzyści (dla mnie) przeważają. Mogę dodać, że w pracy podpinamy strony klientów pod różne CDNy lub usługi antyDDoS (choć akurat nie pod CF) i mogę powiedzieć, że ilość wydanej kasy niekoniecznie przekłada się na dobrą wartość końcową danej usługi.
> jak w ogóle można oddać komuś cały nieszyfrowany ruch
A jak można oddać komuś wszystkie swoje pieniądze (bank), dostęp do wszystkich naszych rozmów (operator komórkowy) albo nawet powierzyć swoje życie (pilot samolotu)? Robisz rachunek zysków i strat i decydujesz czy pakujesz się w coś takiego czy nie. Pieniądze w skarpecie mogą być, ale niekoniecznie są bezpieczniejsze niż w banku (skarpeta może spłonąć) a stawianie wszystkich usług samemu może ale nie musi dać lepszych rezultatów niż powierzenie tego profesjonalistom.
Ale trochę czymś innym jest, jeśli kilka tysięcy firm korzysta z jednego usługodawcy, a czymś zupełnie innym, gdy jest tam prawie 60M hostowanych stron. Bo przy ewentualnym wycieku mamy – tak jak na przykładzie – prawie 6 milionów potencjalnie skompromitowanych stron. Toż to masakra. Zrozumiałbym wyciek danych z takiej z3s i jej podobnych, ale już koncentracja takich stron jak Digital Ocean, z milionami wrażliwych danych, to jest już coś nie tak i ja bym się nie zdecydował na CF. Dlatego ja nikomu nie bronię wybrania tańszej oferty, tym bardzie skorzystanie z doświadczenia profesjonalistów CF. Ja jestem przeciwnikiem wrzucania dziesiątków milionów kluczowych danych udostępnionych przez wielu klientów, w dodatku całkowicie zawierzając usługodawcy w kwestii bezpieczeństwa. Nie zapominajmy też, że niektórych danych nigdy już nie uda się nam zmienić i już zawsze będą one krążyć na przestępczych forach. Bardzo źle będzie też, gdy informatyzacja całej polskiej administracji pójdzie właśnie w centralizację. Niestety na to się zanosi. A to będzie miało ogromnie niekorzystny wpływ na obywateli. Bo jak sam piszesz – nie jest kwestią czy będzie wyciek, ale kiedy on nastąpi.
Ale jak byś chciał to zorganizować, ustawą regulującą że dany hostingodawca nie może hostować więcej niż x tysięcy stron? Czy chodzić od drzwi do drzwi i „dzień dobry, czy chciałby pan porozmawiać o niebezpieczeństwach płynących z hostowania stron w wielkich hostowniach”? ;)
Dlatego piszę na własnym przykładzie, że tam gdzie byłoby tak wiele hostowanych stron, nie zdecydowałbym się na wybranie takiego usługodawcy. A to ze względu, że jeden wyciek potrafiłby uwalić wszystkich (patrz Yahoo i wyciek miliarda kont). A to mogłoby się przyczynić do skompletowania przez cyberrabusiów wszystkich danych userów i tym samym ułatwić im ataki. Dlatego dbający o klienta to taki usługodawca, który wybiera mniej popularne rozwiązania. Bo nie od dziś wiadomo, że jeśli coś jest niebezpieczne, to jest popularne i wystawione dużo bardziej na cel przestępcom.
Dalej nie rozumiem do czego zmierzasz, jaka to różnica czy trzymasz hosting u dużego czy małego dostawcy w sytuacji gdy nastąpił wyciek? Poprawi ci humor że jedyną ofiarą będziesz ty sam, dajmy na to, a nie ty sam oraz tysiące innych ludzi?
@Przemko: No przecież tam wszystko masz już napisane. Przede wszystkim nie chodzi o mnie, ale o naszych klientów i ich dane. Mniejszy wyciek, to mniejsze koszty. Klient też będzie inaczej patrzył, gdy wycieknie tylko jego email. A zupełnie inaczej gdy wykradną: nr konta, imię oraz nazwisko, email, pesel, dane medyczne, nr tel. i mnóstwo innych rzeczy. Nawet nie tylko my musielibyśmy się do wycieku takiej osoby przyczynić. Także mało roztropni przedsiębiorcy, ktorzy korzystaliby z rozwiązań ogromnych dostawców, takich samych jak my. Wtedy takiego klienta moglibyśmy stracić. Wiem to z własnego doświadczenia, jak reaguję na różne wycieki. Np. system OpenID, ktory może przyczynić się do dostępu do mnostwa kont – na pierwszy rzut oka w ogóle ze sobą niepowiązanych.
Przy takim przyroście incydentów to niedługo będziemy musieli wszystkie hasła zmieniać przynajmniej raz dziennie a kto wie czy to coś da bo przecież podczas zmiany serwery mogą cieknąć….
Ired w Polsce 10. Moim zdaniem drogo. A i Google wkoncu skasowałem utrudnien8a w wyszukiwaniu plików na tabletkach. Tak nie wiele a ile radosci + tablet
Tutaj jest lista stron (domen) potencjalnie dotkniętych atakiem:
https://github.com/pirate/sites-using-cloudflare
Może komuś się przyda, choć Ci naprawdę dotknięci wyciekiem z pewnością zostali już poinformowani przez Cloudflare.
no i cert.pl leży i kwiczy :(