Kwetsbaarheden melden: een ervaring uit de eerste hand

Vulnerability disclosure? Responsible disclosure?

Het blijkt dat we het als community zelfs niet eens kunnen worden over de juiste terminologie: 'private', 'public', 'responsible', 'full' en 'coordinated disclosure' zijn termen die binnen de academische wereld of de industrie geen algemeen aanvaarde betekenis hebben.

Coordinated Vulnerability Disclosure (CVD) is de voorkeursterm, aangezien 'responsible' in 'responsible disclosure' impliceert dat er een morele plicht rust op de meldende partij, terwijl de verantwoordelijkheid in werkelijkheid ligt bij de partij die de kwetsbaarheid heeft veroorzaakt en niet bij degene die hem heeft ontdekt.

De tsuNAME-kwetsbaarheid

De tsuNAME-kwetsbaarheid bestond uit clients en/of recursieve resolvers (loop in de onderstaande figuur) die aan één stuk door query's naar autoritatieve servers stuurden. Als hier met beleid misbruik van zou worden gemaakt, zou dit kunnen worden aangewend om autoritatieve servers te overbelasten en neer te halen, waardoor hele DNS-zones onbereikbaar zouden worden. Om in zo'n lus (loop) terecht te komen, moest een resolver of client op een DNS-zonelus stuiten in de zonebestanden op afzonderlijke servers.

Denk bijvoorbeeld aan een autoritatieve server voor de fictieve zone dog.com:

dog.com NS ns.cat.org

En stel dat dit het zonebestand van cat.org is:

cat.org NS ns.dog.com

We kunnen een lus zien in de 2 zones: cat.org <-> dog.com. Aangezien ze dit soort antwoorden niet in de cache opslaan, zouden sommige resolvers in een oneindige lus terechtkomen – of sommige clients. We bespreken de kwetsbaarheid in detail in ons wetenschappelijke artikel. Daarin laten we zien hoe .nz , het ccTLD van Nieuw-Zeeland, als gevolg van de kwetsbaarheid 50% meer verkeer te verwerken kreeg.

Het meldingsproces

Toen we tsuNAME voor het eerst aantroffen, realiseerden we ons dat in onze datasets 99% van de lusquery's die we zagen afkomstig was van Google Public DNS (GDNS). Omdat we een aantal GDNS-beheerders persoonlijk kennen, besloten we om het probleem eerst aan hen te melden, in de hoop dat het dan sneller verholpen zou zijn. (Dat was niet het geval en hadden we beter niet kunnen doen, maar daarover later meer.)

De onderstaande figuur geeft een overzicht van onze melding. Eerst waarschuwden we in september 2020 onze contactpersonen bij GDNS. Na maanden wachten waarschuwden we in november 2020 Google via hun officiële CVD-kanaal. Weer gingen er een paar maanden voorbij zonder oplossing, dus besloten we om een groep DNS-beheerders, die het slachtoffer hadden kunnen worden van tsuNAME-achtige aanvallen, persoonlijk te waarschuwen. Met hulp van DNS-OARC planden we een online meldingssessie, om onze bevindingen te presenteren tijdens hun online OARC34-bijeenkomst. Om de mensen bij GDNS op de hoogte te houden, lieten we hen weten dat we deze groep gingen inlichten.

Figuur 2: tijdlijn van tsuNAME-melding.

In de tussenliggende tijd namen onze collega's bij GDNS contact met ons op en losten ze het probleem snel op – officieel 1 dag voor onze persoonlijke melding tijdens OARC34.

Vervolgens brachten we meerdere partijen persoonlijk op de hoogte (het gele gebied in de bovenstaande figuur). In april repareerde ook Cisco zijn OpenDNS-dienst en in mei 2021 maakten we het probleem openbaar. In totaal gingen er 8 maanden voorbij tussen het eerste contact en de openbare melding.

Geleerde lessen

1. Openbare melding is de moeite waard: iedereen heeft er baat bij

De potentiële schade die zou kunnen worden veroorzaakt door ontwrichtende tsuNAME-aanvallen op de beheerder van een topleveldomein was een bron van zorg. Ook vroegen we ons af waarom er geen openbare verslagen van dergelijke aanvallen waren – tenslotte was de kwetsbaarheid waarschijnlijk niet nieuw. Was dat omdat aanvallers de kwetsbaarheid nog niet hadden ontdekt of waren er andere, toegankelijkere en effectievere methoden beschikbaar? We stonden voor een ethisch dilemma: of we de kwetsbaarheid wel of niet moesten openbaren. Ondanks het risico om als paniekzaaiers te worden gezien, besloten we uiteindelijk tot groeps- en openbare bekendmaking.

Onze beslissing om de kwetsbaarheid te openbaren heeft er uiteindelijk toe bijgedragen dat tsuNAME is verholpen, zodat andere beheerders niet aan deze aanvallen ten prooi konden vallen. Er hoeft maar één partij een probleem te melden om zo een kettingreactie op gang te brengen waarvan uiteindelijk iedereen profiteert. We adviseren onderzoekers daarom om kwetsbaarheden wel te melden.

2. Meldingen hebben ethische implicaties

Onderzoekers kunnen de beste bedoelingen hebben wanneer ze een kwetsbaarheid melden, maar moeten zich ervan bewust zijn dat er keuzes gemaakt moeten worden en dat elke beslissing gevolgen kan hebben voor anderen.

Wij zijn van mening dat we de juiste keuze hebben gemaakt door tsuNAME te openbaren. Zo konden de leveranciers het probleem verhelpen, waardoor voorkomen werd dat het in amplificatieaanvallen werd gebruikt.

Achteraf bezien beseffen we dat we een fout hebben gemaakt toen we ervoor kozen om in eerste instantie alleen GDNS op de hoogte te stellen. We zien nu in dat we alle leveranciers van DNS-resolvers hetzelfde hadden moeten behandelen en hen allemaal tegelijk hadden moeten waarschuwen. Onze fout leidde tot een vertraging in de mitigatie van de kwetsbaarheid. Bovendien leverden onze persoonlijke meldingen niet het gewenste resultaat op, dus het was echt nodig om een datum voor openbare bekendmaking te prikken en leveranciers dienovereenkomstig te informeren.

3. Vraag om hulp om de last te verlichten

Het melden van tsuNAME kostte meer tijd en energie dan we aanvankelijk hadden verwacht. Naast het voorbereiden van presentaties maakten we ook handleidingen voor beheerders en ontwikkelaars waarin we de stappen beschreven die nodig waren om tsuNAME te reproduceren.

Als het geen deel uitmaakt van hun dagelijkse taken, bestaat de kans dat veel beheerders en ontwikkelaars ervan afzien om kwetsbaarheden te melden, omdat ze er de tijd en energie niet voor hebben. Om het communicatieproces in goede banen te leiden, zou een onderzoeker de hulp kunnen inroepen van een meldingscoördinator. Deze coördinator kan de taak op zich nemen om contact op te nemen met leveranciers, waardoor de onderzoeker van deze last en de bijbehorende publiciteit wordt bevrijd. Dergelijke hulp wordt bijvoorbeeld geboden door organisaties als CISA.

4. Je hebt geen volledig beeld

Tijdens de Q&A-sessie van de groepsgewijze bekendmaking op OARC34 bevestigden 2 ccTLD-beheerders dat ze eerder DNS-incidenten met GDNS hadden meegemaakt. Een van hen, een Europees ccTLD, was zo vriendelijk om de verkeersstatistieken van hun DNS-incident te delen. Anders dan bij het .nz-incident, dat een verkeerstoename van 50% liet zien, had deze beheerder 10 keer zoveel verkeer te verwerken gekregen.

Figuur 3 toont het totale verkeer van de beheerder, waarbij elke kleur het verkeer naar een van hun autoritatieve servers weergeeft. We zien een sterke toename van het verkeer, die begint om 19:00 UTC en een piek bereikt van 10 keer het normale verkeer, voordat het de volgende dag om 11:00 UTC, toen de cyclische afhankelijkheid handmatig uit de zone werd verwijderd, drastisch afneemt.

Figuur 3: DNS-incident bij ccTLD-beheerder in EU.

Een tweede ccTLD-beheerder op het Amerikaanse continent nam na de presentatie per e-mail contact met ons op om te vertellen dat ze meerdere keren met soortgelijke incidenten te maken hadden gehad. Ook zij hadden het probleem persoonlijk gemeld aan hun contacten bij Google, maar het probleem hield jarenlang aan en leidde tot frustratie Hoewel we hun beweringen niet kunnen verifiëren, illustreert hun verhaal dat persoonlijke meldingen mogelijk niet effectief zijn.

5. Wees voorbereid op stressvolle reacties

We kregen 2 soorten reacties op onze melding:

• Positief: voornamelijk van leveranciers – GDNS, Unbound/NLnet Labs, BIND/ISC, Cisco/OpenDNS. Dit waren de mensen die in staat waren om kwetsbare software te repareren, dus onze belangrijkste doelgroep.

• Negatief: sommige beheerders beschuldigden ons van angstzaaierij, terwijl een andere aangaf dat het probleem al bekend was. Hoewel het klopt dat het probleem van cyclische afhankelijkheden al in eerdere RFC's aan de orde werd gesteld (RFC1034, RFC1035, RFC1536), werd het niet afdoende behandeld, wat de reden is dat de kwetsbaarheid nog steeds bestaat. Wij schreven er een Internet Draft over, die later werd verwerkt in een andere IETF-draft.

Bij het melden van een kwetsbaarheid is het belangrijk om voorbereid te zijn op de daaruit voortvloeiende publiciteit en mogelijke negatieve reacties. Op socialemediaplatforms als Twitter kan feedback of kritiek snel escaleren en gemakkelijk wijd verspreid worden. Het is van belang hierop voorbereid te zijn en te beseffen dat niet alle feedback op een constructieve manier zal worden gepresenteerd. Daarnaast is het belangrijk te erkennen dat het meldingsproces emotioneel belastend kan zijn en dat onderzoekers dit niet altijd kunnen of willen aangaan.

We begrijpen heel goed dat niet alle onderzoekers zich op hun gemak voelen bij de aandacht en mogelijke stress die het openbaar maken van een kwetsbaarheid met zich mee kan brengen. Om hieraan te ontkomen, kunnen ze ervoor kiezen om kwetsbaarheden anoniem te melden door gebruik te maken van nieuwe e-mailaccounts, aliassen en anonimiseringstools. Ook kunnen ze de hulp inroepen van een meldingscoördinator.

Verbetering van het meldingsproces

We kunnen 2 lessen trekken uit onze meldingservaring:

Rol van leverancier en tijdskaders helder omschrijven: bestaande documenten richten zich voornamelijk op de melding zelf en zeggen weinig over wat er van leveranciers wordt verwacht. Nadat een kwetsbaarheid aan de leverancier is gemeld, is het diens verantwoordelijkheid om te bepalen wanneer en hoe het probleem wordt aangepakt. Maar wat gebeurt er als de leverancier weigert het probleem te verhelpen of eindeloos lang wacht met het oplossen ervan?

In ons geval duurde het meer dan 60 dagen nadat we hen via hun officiële meldingssysteem hadden gewaarschuwd voordat Google het probleem aanpakte. Hoewel het bugtrackingsysteem van Google ons in elke fase van updates voorzag, bleef de tijdlijn voor het verhelpen van de fout onduidelijk. Het enige wat ze daarover zeiden, was een vaag '[P2-problemen] moeten binnen een redelijk tijdsbestek worden aangepakt'.

We maakten ons grote zorgen over de mogelijkheid dat andere beheerders het doelwit zouden worden van DDoS-aanvallers terwijl we op een oplossing wachtten, waardoor we in potentie medeplichtig zouden worden als er aanvallen zouden plaatsvinden.

We zouden graag een duidelijker tijdsbestek zien waarbinnen leveranciers een probleem moeten oplossen, deels om de risico's (en stress) te beperken dat de fout tussentijds uitlekt of door anderen wordt ontdekt.

CVD-richtlijnen bijwerken en omschrijven: De community zou gebaat zijn bij goed gedefinieerde, beknopte richtlijnen voor het melden van kwetsbaarheden. Deze richtlijnen moeten de melders beschermen en de ethische overwegingen die in elke fase spelen aan de orde stellen. Bovendien moeten ze omschrijven welke activiteiten er binnen welke tijdskaders van leveranciers worden verwacht. Zoals de zaken er nu voorstaan, leidt het ontbreken van regelmatig bijgewerkte, beknopte en breed onderschreven documenten tot verwarring, zoals wij persoonlijk hebben kunnen vaststellen.

Meer informatie

We hebben een peerreviewed wetenschappelijk artikel over onze ervaringen met het melden van de tsuNAME-kwetsbaarheid geschreven.