Fout in html-parser CloudFlare leidde tot risico lekken inloggegevens klanten

Door een bug in de html-parser van CloudFlare konden gevoelige gegevens van klanten van het bedrijf lekken en stond data in de cache van zoekmachines. Na een melding van Google heeft de dienst voor optimalisatie van websites het lek in zeven uur gedicht.

CloudFlare meldt niet bekend te zijn met meldingen waaruit zou blijken dat er misbruik is gemaakt van de bug. De bug zou bestaan hebben tussen september vorig jaar en afgelopen week, meldt contentleverancier CloudFlare. Onder meer Fitbit en Uber zouden gebruik maken van de diensten van CloudFlare en dus mogelijk kwetsbaar zijn geweest. Door de fout in de code leidde een klein aantal verzoeken tot een geheugenlek. Onder meer headers, tokens en andere inloggegevens belandden daardoor in de cache van zoekmachines en waren zo vindbaar.

Googles Project Zero vond de bug en lichtte CloudFlare in. Na de melding zette binnen drie kwartier de dienst om e-mailadressen vaag te maken uit, wat een groot deel oploste. Naar eigen zeggen had CloudFlare het lek na zeven uur gedicht.

Het lek zat in de Ragel-code in de html-parser. Die parser verborg e-mailadressen en zette http-links om in https. De code checkte niet goed als het einde van de buffer was bereikt. Volgens CloudFlare was het gebruik van ">=" in plaats van "==" genoeg om het probleem te voorkomen.

Reacties (54)

[Tk55]

Lijst met websites die mogelijk last hebben gehad van deze bug:

https://github.com/pirate...are/blob/master/README.md


Edit:

Er zou geen misbruik zijn gemaakt van de bug.

Weten ze dat ook zeker? Informatie is gewoon gecached bij zoekmachines. De bug was ook vrij lang aanwezig.

We fetched a few live samples, and we observed encryption keys, cookies, passwords, chunks of POST data and even HTTPS requests for other major cloudflare-hosted sites from other users. Once we understood what we were seeing and the implications, we immediately stopped and contacted cloudflare security.

https://bugs.chromium.org...ero/issues/detail?id=1139

Edit2:
Het is nogal ernstig:

I don't know if this issue was noticed and exploited, but I'm sure other crawlers have collected data and that users have saved or cached content and don't realize what they have, etc. We've discovered (and purged) cached pages that contain private messages from well-known services, PII from major sites that use cloudflare, and even plaintext API requests from a popular password manager that were sent over https (!!).

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. I've informed cloudflare what I'm working on. I'm finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We're talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.

[Reactie gewijzigd door Tk55 op 28 juli 2024 03:41]

[bwerg]

Er zou geen misbruik zijn gemaakt van de bug.

Dat is inderdaad de flauwekul die standaard gezegd wordt door bedrijven die geen klandizie willen verliezen, maar het valt me tegen dat tweakers dit gewoon overneemt. Als mensen bevestigen dat ze hun wachtwoorden in zoekmachines terugvinden is dit gewoon een heel foute stelling.

Een reactie van het bedrijf opnemen in het artikel is natuurlijk niet gek maar zonder kanttekening erbij lijkt tweakers te suggereren dat dit ook klopt.

Nou lees ik in andere reacties dat cloudflare ook veel en genuanceerde informatie geeft, dus misschien dat deze zin een samenvatting zou moeten zijn, in dat geval is het (om bovenstaande reden) erg karig.

[Reactie gewijzigd door bwerg op 28 juli 2024 03:41]

[bbob]

Idd standaard antwoord, het echte antwoord is we weten niet of er misbruik is gemaakt van de bug.

[Dubbeldrank]

Zo te zien is CloudFlare bezig om de boel heel hard te downplayen en is er daadwerkelijk meer aan de hand dan ze zeggen. Hieronder de Reddit met meer informatie betreffende getroffen sites:

https://www.reddit.com/r/...dbleed_cloudflare_leaked/

[wica]

Idd, dit is een zeer erg lek.

I'm finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, ...

en

If you enabled 2FA recently in the past few months, it's possible that the 2FA secret ITSELF was leaked. You should disable and re-enable 2FA.

[tom.cx]

1Password geeft in elk geval aan dat er niks gelekt is van haar gebruikers.

[z1rconium]

Er zijn 4+ miljoen potentiele sites die getroffen zouden kunnen zijn.

The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).

Maar downplayen? Veel transparanter dan hun blogpost kun je denk ik niet worden. Elk detail word uitgelegd.

Ze hebben een probleem, geven het toe, lossen het op en zijn helder over hun acties. Wat verwacht je nog meer dan ?

[Nox]

Zie "Er zou geen misbruik zijn gemaakt van de bug." terwijl er al mensen gewoon passwords, 2FA secrets en weet ik veel wat voor gegevens hebben gevonden.

Je doet alsof je een bug hebt gevonden en gefixt welke potentieel risicovol kon zijn maar nu al zeker weet dat er niemand misbruik heeft gemaakt. CF had makkelijk kunnen zeggen 'Het is onbekend of er misbruik is gemaakt'. Want dat is de waarheid.

[z1rconium]

Ik weet niet waar dat "geen misbruik" statement vandaan komt, ze zeggen precies wat jij zegt:

The bug was serious because the leaked memory could contain private information and because it had been cached by search engines. We have also not discovered any evidence of malicious exploits of the bug or other reports of its existence.

btw. die 2FA secrets en passwords, kun je een source geven ? "it's possible that the 2FA secret ITSELF was leaked", maakt het nog geen feit.

[Reactie gewijzigd door z1rconium op 28 juli 2024 03:41]

[wica]

It became clear after a while we were looking at chunks of uninitialized memory interspersed with valid data

https://bugs.chromium.org...ero/issues/detail?id=1139

als je en stukje van uit het geheugen mee krijgt, kan de data van alles zijn en dus ook 2FA secret.

[Nox]

Eerste zin, 2e alinea. Tenzij Tweakers de vertaling fout heeft gedaan...

En zie de reactie boven je, wica in 'nieuws: Fout in html-parser CloudFlare leidde tot risico lekken inlo...

[svenslootweg]

Het geven van details maakt het nog niet transparent. De blogpost mist het "verander je wachtwoorden advies", evenals een eerlijke omschrijving van de impact (namelijk: ga ervanuit dat alles dat je ooit naar een CloudFlare-gebruikende site hebt verstuurd, gelekt is).

De hele post is geschreven om aandacht af te leiden van de consequenties en onverantwoordelijkheid vanuit CloudFlare voor het bouwen van zo'n groot SPOF, en focust in plaats daarvan op de technische details.

Dat is geen transparentie, dat is slimme marketing naar een technisch publiek.

[z1rconium]

zucht:

the bug had been dormant for years until the internal feng shui of the buffers passed between NGINX filter modules changed with the introduction of cf-html.

The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).

[svenslootweg]

Wat is je punt hiermee?

[Alexji]

Hier ook een goede discussie op HN:
https://news.ycombinator.com/item?id=13718752

Het is inderdaad wel iets erger dan een "risico op lekken". Er zijn gewoon dingen gelekt die nu ook weer door andere sites zijn geïndexeerd/gecached.

[GrooV]

Beetje overdreven reactie niet? Cloudflare is niet aan het downplayen, ze zijn juist er open over alles wat er gebeurd is.

Lees de blog post eens ipv Reddit

https://blog.cloudflare.c...by-cloudflare-parser-bug/

[Reactie gewijzigd door GrooV op 28 juli 2024 03:41]

[biglia]

Zonet een mail gehad:


----

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.c...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

[GrooV]

Het gaat alleen om het scrape shield, als je die uit had staan dan was er niks aan de hand. Verder erg netjes binnen 7 uur opgelost

[biglia]

Die parser verborg e-mailadressen en zette http-links om in https.

Dat zijn 2 afzonderlijke opties in Cloudflare. Ik heb ze beide ook niet aan staan. In principe zijn dat opties voor luie mensen of mensen die technisch niet zo onderlegd zijn. Ik kan me niet voorstellen dat grote websites die opties aanhebben staan.

[MikeN]

Dat maakt niet uit. Iedere site achter Cloudflare is vulnerable geweest en kan data gelekt hebben. Effectief betekent dit bijvoorbeeld NRC, Wehkamp, Fok, Geenstijl enz. onder de Nederlandse wetgeving al hun klanten zo spoedig mogelijk moeten informeren. Ben benieuwd of dit ook gaat gebeuren.

[StefanJanssen]

Ook de communicatie tussen niet cloudflare sites en cloudflare sites kan gelekt zijn. Ik mag hopen dat de telefoon bij de centrale voor het melden van datalekken roodgloeiend staat

[Tsunami]

Het ziet er naar uit dat het standaard aan staat, dus ben bang dat veel mensen het aan hebben staan tenzij ze iedere optie hebben uitgeplozen.

[Tsunami]

En moest je ook niet malformed HTML hebben?

[smeaggie]

Gevoelige data van jouw website kan echter wél gelekt zijn hierdoor, ook als jij deze opties niet aan hebt staan. De infrastructuur wordt shared over alle klanten, en het gaat hier om een memory leak (buffer overrun) waarbij dus data uit het nginx geheugen in response HTML terecht kwam.

Een request op een website met bepaalde invalid HTML die deze opties dus aan had staan was genoeg om random geheugen te lekken, waar dus ook data van hele andere domeinen en websites kan staan. Het is maar net wat het nginx proces op dat moment daar in het geheugen had staan.

Lees vooral de blog van cloudflare voor details: https://blog.cloudflare.c...by-cloudflare-parser-bug/ ze kunnen het beter uitleggen dan ik.

[bones]

"Volgens CloudFlare was het gebruik van ">=" in plaats van "==" genoeg om het probleem te voorkomen."

Moet dit dan 7 uur duren? Simpele find&replace commando is dan toch voldoende of denk ik dan te simpel? Of hebben ze eerst 6 uur en 59 minuten gezocht naar deze oplossing?

[DynaSpan]

Je moet eerst de oorzaak vinden, vervolgens uitrollen op alle servers e.d. Dan is 7 uur nog best snel naar mijn mening.

[Haan]

In het algemeen ben je inderdaad het grootste deel van de tijd bezig met uit te zoeken wat de bug is (bug reproduceren, uitzoeken waar het mis gaat, e.d.), als je het eenmaal hebt gevonden, is de fix vaak triviaal.

[Reactie gewijzigd door Haan op 28 juli 2024 03:41]

[Blokker_1999]

- Fout identificeren
- Fout oplossen
- Code testen
- Code accepteren
- Code uitrollen

Een hoop stappen die niet allemaal door 1 persoon gedaan kunnen worden. Ja, daar kruipt al snel enkele uren in. Het is ook niet alsof ze het maar naar 1 enkel servertje moeten pushen, er steekt een enorme infrastructuur achter hun dienst.

[Patrick_Wolf]

Voornamelijk dat laatste denk ik, alhoewel ze binnen 45 minuten al een 'tijdelijke' oplossing hadden geboden. Wellicht dat er naast allerlei unitest ook nog op een testingomgeving de meest gangbare situaties handmatig is geverfieerd? Want een bedrijf als CloudFlare kan het zich natuurlijk niet permiteren dat er iets niet meer werkt voor de eindklant.

[thomas1907]

Het is niet zo makkelijk. Wat als dat weer een andere bug "activeert"? Het moet allemaal getest worden.

Logisch nadenken

[mkools24]

Weet je hoeveel sites Cloudflare host en wat voor gevolgen iedere aanpassing kan hebben? Dan vind ik 7 uur nog supersnel.

Het is geen thuisprinter he waar je een firmware update van doet.

[Anoniem: 426269]

Ja, dit kan makkelijk 7 uur duren. Je laatste regel zal dus wel kloppen.

Doet me denken aan een fout in mijn eigen code jaren geleden. Pas na een volle werkdag kwam ik erachter dat het slechts 1 puntcomma was die verkeerd stond. En aan het einde van de dag was mijn baas erg blij dat het probleem opgelost was, haha.

[Neko Koneko]

Ik heb vaak genoeg best grote bugs opgelost door één regel code te wijzigen, maar voordat je de specifieke regel hebt gevonden ben je vaak alweer een uurtje of twee verder. Het is niet zo dat omdat de uiteindelijke oplossing één regel wijzigen is, je ook direct weet waar de betreffende regel in de code staat (je weet niet eens dat het een oplossing van één regel gaat zijn).

Daarnaast wat de rest zegt, testen, acceptatie en doorzetten naar productie. Daar gaat ook tijd in zitten, en ik kan je verzekeren dat 7 uur heel erg snel is. De meeste grote organisaties hebben hiervoor een proces dat dagen in beslag neemt.

[StefanJanssen]

Eerste prioriteit was direct zorgen dat het niet meer plaatsvond. Binnen 30 minuten na de bugreport werden de kapotte onderdelen met een kill switch uitgeschakeld. Daarna is het zoeken naar de fout.
De eerste gedachte ging niet uit naar een stuk code die al sinds het ontstaan van cloudflare gebruikt werd.

Ook zat deze fout in de compilede code, al met al is zeven uur bijzonder snel.

[gpgekko]

CloudFlare heeft het probleem bij hun opgelost zodat er geen nieuwe informatie wordt gelekt. Maar opgelost zou ik het niet willen noemen...
En de vraag is nog hoeveel proxy caches, crawlers en dergelijke niet opgeschoond zijn.

It is far from over, too! Google Cache still has loads of sensitive information, a link away!
Look at this, click on the downward arrow, "Cached": https://www.google.com/se...st-Origin-IP:"+"author...
(And then, in Google Cache, "view source", search for "authorization".)
(Various combinations of HTTP headers to search for yield more results.)

I'm also seeing a ton from cn-dc1.uber.com with oauth, cookies and even geolocation info.

The information exposed through the bug though can be from any domain that uses Cloudflare.
So: all services that have one or more domains served through Cloudflare may be affected.
The consensus seem to be that no one discovered this before now, and no bad guys have been scraping this leak for valuable data (passwords, OAuth tokens, PII, other secrets). But the data still was saved all over the world in web caches. So the bad guys are now probably after those. Though I don't know how much 'useful' data they would be able to extract, and what the risks for an average internet user are.

Bron: https://news.ycombinator.com/item?id=13718752

Belangrijkste discussie is echter natuurlijk hoe het lek moet heten

- Downpour is my preference right now. The clouds are dumping everything they got
- How about Cloudburst?
- CloudBust
- If only CloudShare wasn't a thing already.
- I'd suggest "FlareOut".
- Cloudflush.

[Reactie gewijzigd door gpgekko op 28 juli 2024 03:41]

[GrooV]

Dat zijn 15 resultaten, waarvan er een paar maar daadwerkelijk getroffen sites zijn

[gpgekko]

Die gevonden zijn door iemand die gewoonweg de eerste query die in hem op kwam heeft ingetyped. Het is geenszins een volledige lijst van alle probleem sites. Daarnaast is Google nog continue dingen aan het weggooien, toen ik keek waren het er namelijk meer.
Het is vrij lastig is om een volledige, uitputtende lijst te maken van alle sites / gegevens.

[croiky]

Misschien is dit ernstiger dan gemiddeld, misschien ook niet. Ben geen expert maar in dat lijstje op GitHub staan een aantal heel populaire websites waarvan Nederlandse domeinen:

-Dumpert
-Geenstijl
-Fok
-NRC
-Wehkamp
-Downloads
-Sitedeals
-Voetbalzone

Ik las dat het werd aangeraden om wachtwoorden te wijzigen. Als je een account hebt op deze websites zou ik die zeker wijzigen. Natuurlijk ook op alle andere.

Better safe than sorry hm?

[raider009]

Je kan inderdaad het beste gewoon al je wachtwoorden veranderen als je lid bent van die websites, hoewel er wordt geclaimd dat er geen misbruik is gemaakt zijn er toch meldingen op Reddit te vinden dat het om een zeer ernstig lek gaat: https://www.reddit.com/r/...dbleed_cloudflare_leaked/

Aangezien ik bij meerdere van deze websites lid ben heb ik al mijn wachtwoorden veranderd. Ook wachtwoorden van dienste wen websites die niet op de lijst staan, zoals je zelf al zegt. Better safe than sorry.

[jpgview]

Het is inderdaad niet leuk dat dergelijke bugs persoonsgegevens compromiteren. Anderzijds is het vrijwel uniek te horen dat de bug binnen zo'n korte tijd is opgelost.
Het mag m.i. ook gezegd worden dat cloudflare een van de weinige domains is die correct voorzien zijn van DNSSEC domain entries. Ik gebruik DNSSEC (pi-hole installatie) en moet helaas vaststellen dat de meeste domains niet echt veel aandacht besteden aan een technologie die een poging doet om het internet veiliger te maken, zoals cloudflare (<quote> make the Internet work the way it should </quote>)

mijn log (maar helaas de uitzondering):
Feb 24 11:09:16 dnsmasq[6592]: forwarded www.cloudflare.com to 127.10.10.2
...
Feb 24 11:09:16 dnsmasq[4884]: validation result is SECURE

[R4gnax]

Het mag m.i. ook gezegd worden dat cloudflare een van de weinige domains is die correct voorzien zijn van DNSSEC domain entries. Ik gebruik DNSSEC (pi-hole installatie) en moet helaas vaststellen dat de meeste domains niet echt veel aandacht besteden aan een technologie die een poging doet om het internet veiliger te maken, zoals cloudflare

Dat mag je dan ook wel weer gelijk afzetten tegen het achterlijke besluit om programmeerwerk met unsafe memory manipulatie in talen zoals C in te gaan zetten voor je eigen web-facing materiaal.

[Reactie gewijzigd door R4gnax op 28 juli 2024 03:41]

[jpgview]

Ongetwijfeld wil je dit verduidelijken. Met mijn beperkte kennis ontgaat mij het verband totaal tussen een DNS record, aangemaakt door een DNS administrator, opgehaald door de DNSSEC aware DNS client en het gebruik van C voor web-facing materiaal.

[Reactie gewijzigd door jpgview op 28 juli 2024 03:41]

[R4gnax]

Heel simpel: het is fijn dat Cloudflar met DNSSEC "veel aandacht besteedt aan een technologie, die een poging doet om het internet veiliger te maken"

maar tegelijkertijd zouden ze dat soort investering beter ook in hun programmeerwerk steken en bijv. een memory-safe systems taal als Rust gebruiken, in plaats van de compleet achterlijke beslissing om web-facing C code te draaien.

[Reactie gewijzigd door R4gnax op 28 juli 2024 03:41]

[jpgview]

Je opmerking heeft dus, als ik het begrijp, niets te maken met DNSSEC als technologie, maar wel met het beleid dat cloudflare voert (de programeer taal), om hun produkten aan de man te brengen. Voor mij geen reden om DNSSEC uit te schakelen, er zijn nog andere domains die DNSSEC enabled zijn, en vooral, domains die niet zijn wat ze beweren (validation result is BOGUS)

[unilythe]

Hij heeft nooit gezegd dat dnssec uitgeschakeld moest worden. Is echt totaal niet waar hij het over had.

[jveldijk]

De project-zero bugtracker heeft ook een foto waarin je kan zien dat uber getroffen is: https://bugs.chromium.org...hment?aid=271988&inline=1

[Reactie gewijzigd door jveldijk op 28 juli 2024 03:41]

[xoniq]

Hier ook nog wat info over iemand die het geconstateerd had:

http://www.theverge.com/2...ords-dating-site-messages