Stel je bent een beveiligingsonderzoeker en je hebt na weken trial and error een kritieke kwetsbaarheid gevonden in een wijdverspreid internetprotocol. Hoe ga je dan te werk? Kies je ervoor om het stilletjes te melden aan de verantwoordelijke partij en na de patch een blogpost te schrijven in de hoop dat deze wordt opgepakt? Of ga je aan de slag en maak je een bijbehorende pagina met pakkende naam, logo, uitleg en links naar nieuwsberichten?
Er is een goede kans dat de namen Krack en Blueborne je iets zeggen. Als dat geen belletje doet rinkelen, dan misschien Heartbleed wel. En als je heel goed hebt opgelet, dan kun je je een voorstelling maken bij Duhk en Roca. En als al die namen je helemaal niets zeggen, dan niet getreurd. We gaan in dit stuk namelijk in op zogenaamde branded vulnerabilities, oftewel kwetsbaarheden die een naam en vaak een logo hebben meegekregen.
Het lijkt erop dat dit fenomeen steeds vaker de kop opsteekt en ook dit jaar weer hebben we er een paar voorbij zien komen. Dat roept de vraag op waarom dit gebeurt, wat voor soort kwetsbaarheden een dergelijke 'marketingcampagne' verdienen en of het juist iets toevoegt of dat men er beter mee kan stoppen. Is het alleen maar weggelegd voor kwetsbaarheden in software met grote gevolgen, of leent ieder lek zich voor een dergelijke aanpak?
Tegelijkertijd grijpen we de gelegenheid aan om terug te kijken op verschillende grote kwetsbaarheden die het afgelopen jaar aan het licht zijn gekomen.
Een stapje terug
Als we TechCrunch moeten geloven, was Heartbleed de eerste grote kwetsbaarheid met een marketingcampagne eromheen. Omdat 2014 alweer even geleden is, even een opfrisser over de kwetsbaarheid. Optioneel kun je natuurlijk ook nog even de bijbehorende xkcd-strip bekijken, die een treffende uitleg geeft. Heartbleed is een lek in OpenSSL dat al twee jaar voor zijn ontdekking in de implementatie aanwezig was. Het lek maakte het mogelijk om het geheugen van een webserver uit te lezen. Daardoor was het bijvoorbeeld mogelijk om privésleutels te achterhalen. De ernst van de kwetsbaarheid was groot, omdat hij gevolgen had voor veel aan het internet verbonden apparaten en omdat hij vrij eenvoudig te gebruiken was. De kwetsbaarheid was in de code terechtgekomen doordat een ontwikkelaar vergat een variabele te valideren en doordat deze niet werd opgemerkt tijdens de controle.
Omdat we het nu toch over geschiedenis hebben, kunnen we ook even een blik werpen op de totstandkoming van de Heartbleed-pagina en het bekende ‘bloedende hart’-logo. Zoals ZDNet destijds schreef, claimde het Finse bedrijf Codenomicon dat het de kwetsbaarheid net iets na de oorspronkelijke ontdekking door Google-onderzoeker Neel Mehta had gevonden. Die meldde het in eerste instantie direct aan OpenSSL, terwijl de Finnen ermee naar hun nationale Cert gingen. Het bedrijf legde uit dat een van zijn medewerkers de term Heartbleed had verzonnen, omdat de kwetsbaarheid aanwezig was in de zogenaamde heartbeat-extensie van tls. Het inmiddels welbekende logo was het werk van een Codenomicon-medewerkster genaamd Leena Snidate, een grafisch vormgever. De site kwam uiteindelijk tot stand doordat het bedrijf een soort interne vraag-en-antwoordsessie hield en besloot om de inhoud daarvan online te zetten om mensen te informeren.
De publicatie kreeg enige kritiek over zich heen, omdat het erop leek dat er eerst een grote marketingcampagne op touw was gezet zonder dat de nodige partijen van tevoren waren ingelicht. Een ander effect was dat de kwetsbaarheid veel aandacht kreeg in de media. Cryptograaf Bruce Schneier zei destijds tegen Harvard Business Review: "In de beveiligingsgemeenschap zijn we doorgaans erg slecht in het communiceren van informatie over kwetsbaarheden aan het grote publiek. Heartbleed was een uitzondering: de onderzoekers hebben het probleem en de oplossing uitstekend beschreven. Ze hadden een strakke en informatieve website en gaven de kwetsbaarheid een coole naam en een logo. Dat logo werkte; alle media gebruikten het en het gaf mensen een visuele herinnering aan de gebeurtenis. Het creëerde bewustzijn op een slimme manier."
Toch wijst Schneier ook op de andere kant van het verhaal: "Er bestaat een risico dat men wordt beschuldigd van het slaan van loos alarm. Als er geen bloed vloeit of vliegtuigen in de lucht botsen, gaan mensen zich afvragen waar alle opwinding voor nodig was, zoals bij Y2K. Als je elke kwetsbaarheid gaat voorzien van een logo, zullen mensen vraagtekens plaatsen bij je geloofwaardigheid en ze gaan negeren."
Heartbleed was slechts het begin
Het slaan van loos alarm is ook wat Andy Patel, de 'Cyber Gandalf' van beveiligingsbedrijf F-Secure, noemt als grootste risico. Hij legt aan Tweakers uit dat dit ook de reden is dat branding van lekken in de beveiligingswereld een slechte naam heeft, naast het feit dat er soms hype wordt gecreëerd rond kwetsbaarheden die in feite alleen in een niche spelen. Hij nuanceert zijn standpunt vervolgens enigszins: "Het is nooit erg om publiciteit rond een nieuw lek te zien, zelfs als uiteindelijk blijkt dat het om een nichegeval gaat. Het geven van een naam maakt het eenvoudiger voor de pers om er iets mee te doen en het biedt een referentiepunt." Het toevoegen van een logo of een eigen pagina vindt hij minder belangrijk, zo zou een pagina eigenlijk alleen maar een technische uitleg hoeven te bevatten, samen met een faq en links naar proof of concept-code. Het van tevoren aankondigen van een kwetsbaarheid en het opvolgen met veel marketing ervaart Patel als over the top.
Dat branded kwetsbaarheden in de beveiligingswereld enigszins verguisd zijn, blijkt bijvoorbeeld uit het feit dat de host van de wekelijkse Risky Business-podcast, Patrick Gray, weigert deze lekken bij naam te noemen. Anderen nemen het wat luchtiger op en publiceren een uiterst treffende Twitter-thread.
Het is eigenlijk ook niet zo gek dat het is aangeslagen om grote kwetsbaarheden van een logo te voorzien als we erover nadenken wat het alternatief is. Zo krijgen lekken doorgaans een identificatiecode toegewezen, die aan de buitenkant niet zoveel verraadt behalve het jaar waarin deze is toegewezen. Zo staat Heartbleed bijvoorbeeld ook bekend als CVE-2014-0160. Tenzij je goed bent in het onthouden van nummers maakt deze code het moeilijk om ernaar te refereren zonder in algemeenheden te vervallen als ‘het grote lek in OpenSSL van drie jaar terug’. Sommige van deze codes hebben ook zonder naam een bijzondere betekenis gekregen, maar daar later meer over. Bovendien omvatten kwetsbaarheden met een naam soms meerdere cve-codes, wat het makkelijker maakt om ze allemaal in een keer aan te duiden.
Hoe er ook over gedacht mag worden, de discussie staat ons niet in de weg om kort terug te blikken op de kwetsbaarheden die we dit jaar voorbij hebben zien komen, met of zonder naam. Voordat we daaraan toekomen, hebben we hier ter illustratie nog even een kleine bloemlezing van bekende lekken uit het verleden opgenomen. Je kunt het natuurlijk niet over branded vulnerabilities hebben zonder kort aandacht te besteden aan lekken als Stagefright, Shellshock en Drown.
Stagefright Wie herinnert zich niet meer dit Android-lek, dat ergens halverwege 2015 werd ontdekt. Deze kwetsbaarheid, vernoemd naar een softwarebibliotheek die intern als ‘libstagefright ‘ werd aangeduid, maakte het mogelijk om op afstand code uit te voeren op een kwetsbaar Android-toestel. Dat kon bijvoorbeeld met een speciale mms, waardoor een aanvaller in feite alleen het nummer van een doelwit nodig had. De aanduiding omvat verschillende cve’s. Naast een naam was de kwetsbaarheid voorzien van een logo, dat een Android-robotje met een Phantom of the Opera-masker toont, wat moet refereren aan ‘stagefright’, oftewel plankenkoorts.
Shellshock Deze klassieker uit 2014 is ook wel bekend onder de naam Bashdoor. Het gaat om een verzameling kwetsbaarheden die door beveiligingsonderzoeker Robert Graham ‘net zo erg als Heartbleed’ zijn genoemd, omdat ze een aanvaller in staat stelden om willekeurige code uit te voeren op systemen met een kwetsbare versie van Bash. Kort na de openbaring van het lek waren kwaadwillenden er al mee aan de haal gegaan om systemen te rekruteren voor hun botnets. Ook moesten onder meer Yahoo en hoster OVH eraan geloven. Het logo is afgeleid van dat van Heartbleed en toont een schelp, oftewel shell, wat weer staat voor opdrachtprompt.
Ghost Ghost deed zich voor aan het begin van 2015 en betrof een kwetsbaarheid in de glibc-softwarebibliotheek, die in veel Linux-distributies wordt gebruikt. Opmerkelijk was dat het om een vrij oude bug ging die al langer bekend was, maar niet was gecategoriseerd als kwetsbaarheid. Ook dit lek maakte het op afstand uitvoeren van code mogelijk. In opvolging van de Heartbleed-pagina had beveiligingsbedrijf Qualys destijds een vraag-en-antwoordpagina in het leven geroepen, waarop ook een logo was weergegeven van een klein rood spookje met een shell-icoontje. De naam is afgeleid uit het feit dat het lek zich voordeed bij de gethost-functie, die enkele letters verwijderd is van ‘ghost’.
Drown Met de Drown-aanval komen we niet alleen dichter bij het heden, maar hebben we ook een aanval te pakken die weer voorzien was van een eigen domein en internetpagina. Die was voorzien van een paper, infographics en een uitgebreide q&a. De naam staat voor ‘Decrypting RSA with Obsolete and Weakened eNcryption’. De aanval maakte gebruik van een combinatie tussen tls en sslv2 en laat een aanvaller internetverkeer ontsleutelen. Veel servers bleken rond de publicatie nog het verouderde sslv2 te ondersteunen en waren daardoor kwetsbaar. Het Drown-logo is een ‘verdrinkend’ en opengebroken hangslot, dat we allemaal kennen uit de browser-ui voor een beveiligde https-verbinding.
Badlock Laten we eindigen met een voorbeeld voor hoe een kwetsbaarheid beter niet naar buiten kan worden gebracht. Zoals hiervoor al aangestipt is het gevaar aanwezig dat er veel hype ontstaat rond een kwetsbaarheid die uiteindelijk weinig voorstelt. Zo was Badlock al enige tijd voor de uiteindelijke publicatie aangekondigd als een ‘cruciale bug in Windows en Samba’. Uiteindelijk bleek het allemaal mee te vallen en uitten mensen kritiek op het feit dat degene die de bug had gevonden, dezelfde persoon was die aan de software had gewerkt. Bovendien zou de vroege aankondiging kwaadwillenden tijd geven om zelf op zoek te gaan naar het lek en zorgden alle ophef en aandacht er misschien voor dat andere, ernstigere kwetsbaarheden werden genegeerd. Hierdoor is de kwetsbaarheid uiteindelijk door sommigen omgedoopt naar Sadlock en ontving hij een Pwnie-award voor ‘most overhyped bug’.
Beveiligingsonderzoeker Rik van Duijn refereert in een reactie aan Tweakers naast Badlock ook aan Venom, waar eveneens een stevige marketingcampagne achter zat. Dat zou meteen door bedrijven worden aangegrepen voor marketingsdoeleinden om op die manier producten of diensten te verkopen. Over Heartbleed en Shellshock zegt hij dat het problemen zijn waar we iets mee moeten en waarop gereageerd moet worden. "Ik denk dat branded vulnerabilities op zich niet verkeerd zijn, het bevordert awareness in alle lagen van een organisatie", voegt hij daaraan toe. "Branded bugs blijven bestaan, marketingteams gaan deze steeds vaker proberen te gebruiken en uiteindelijk is het aan techneuten om te duiden zodat de juiste mensen een keus kunnen maken."
De trend zet zich voort
Ook dit jaar was het weer raak en hebben we voldoende creatieve namen voorbij zien komen. Het gaat te ver om ze allemaal te noemen, maar we kunnen er wel een handjevol interessante exemplaren tussenuit plukken. Zo toonde de Krack-aanval aan dat veel aandacht voor één onderwerp soms ten koste kan gaan van genoeg exposure voor andere zaken.
Voor wie het weer even kwijt was: Krack was opmerkelijk omdat het om een lek in de wpa2-standaard ging, waar we het met z'n allen al vrij lang mee doen. De naam staat voor 'key reinstallation attacks' en omvat net als andere namen een aantal verschillende cve's. Wpa2 zorgt voor een beveiligde netwerkverbinding, maar door de kwetsbaarheid is het voor een aanvaller mogelijk om alsnog mee te luisteren. Wat de gevolgen van de aanval enigszins beperkte, is het feit dat wifi vereist dat een aanvaller zich in ieder geval in de buurt van het draadloze netwerk bevindt. Bovendien waren verbindingen via https niet aangetast. De bekendmaking vond plaats op een maandag in oktober en kende een korte aanloop met enige oproer omdat het Amerikaanse Cert een waarschuwing had uitgestuurd voordat de informatiesite online stond. Dat zorgde binnen de beveiligingscommunity voor enige opwinding. Toen de site eenmaal online kwam, was deze voorzien van veel informatie en een uitgebreide vraag-en-antwoord-afdeling.
Op dezelfde dag dat het Krack-nieuws zich over de wereld verspreidde, publiceerde een groepje wetenschappers ook hun onderzoek naar het aanmaken van onveilige rsa-sleutels. Ondanks dat het nieuws door een aantal grote sites is opgepikt, leek het enigszins ondergesneeuwd te worden door de lawine aan Krack-informatie. De materie zelf was echter hoogst interessant en wees op een kwetsbare methode voor het aanmaken van rsa-sleutels in de softwarebibliotheek van het Duitse bedrijf Infineon. De chips van dit bedrijf zitten in allerlei producten van andere grote fabrikanten, zoals Microsoft en Google. Het bleek dat ook een deel van de id-kaarten van Estland nieuwe certificaten nodig had; om precies te zijn ging het om 760.000 kaarten. De onderzoekers gaven hun ontdekking de naam Roca, wat staat voor 'The Return of Coppersmith's Attack'. Het lek hield in dat het bij de kwetsbare sleutels mogelijk was om de privésleutel van een rsa-sleutelpaar te achterhalen aan de hand van de publieke sleutel. Dit had ook gevolgen voor bepaalde smartcards van Gemalto.
Voor Roca geen logo, maar wel een infographic
Als we Blueborne, Broadpwn en minder ernstige consorten van dit jaar als Mailsploit en Robot voor nu even opzij schuiven, kunnen we nog aandacht besteden aan de 'naamloze' kwetsbaarheden die niet onderdoen voor hun gedoopte soortgenoten. Feit is namelijk dat die maar een uiterst klein deel van alle softwarelekken uitmaken, maar soms onevenredig veel aandacht krijgen. Soms kan het echter ook gebeuren dat de generieke aanduiding van een lek uit zichzelf een bijzondere betekenis krijgt, zonder dat er een kekke naam bedacht hoeft te worden.
Bug zonder naam
Een van deze lekken is MS17-010, vernoemd naar het gelijknamige security bulletin van Microsoft. Dat is de verzameling patches waarmee Microsoft in maart van dit jaar het SMB-lek dichtte waardoor zich onder meer de WannaCry-ransomware zich zo snel over de wereld kon verspreiden. Daarvoor paste de malware een NSA-exploit toe die bekendstaat onder de inmiddels welbekende naam Eternalblue. Deze is dan ook onlosmakelijk verbonden met het bijbehorende lek. Hierbij is dan ook geen sprake van vooraf bepaalde branding. Al doen de door de NSA gekozen namen van hun tools vermoeden dat er iemand veel plezier beleefde aan het bedenken ervan met varianten als Educatedscholar, Ewokfrenzy en Eskimoroll.
De naam MS17-010 zal waarschijnlijk lange tijd in het geheugen van menig beveiliger gegrift blijven, net als zijn niet minder bekende oudere broer MS08-067. Microsofts John Lambert schreef daar in 2015 in een zeer lezenswaardig stuk over: "In 2008 had een onbekende groep aanvallers een zeroday in handen die al snel de aandacht van de hele wereld zou trekken. Ze waren geduldig en gebruikten hem stilletjes in een aantal Aziatische landen. De kwetsbaarheid was niet alleen goed - het was het soort kwetsbaarheid waarvan offensieve teams en bug hunters alleen van kunnen dromen. Hij was, zoals dat in jargon heet, 'wormable'. Dat woord zorgt bij elke verdediger voor koude rillingen. Kort gezegd hadden de aanvallers een lek waarmee ze op afstand code konden uitvoeren op elk Windows-systeem, met systeemrechten, dat weinig sporen achterliet en dat anoniem vanuit elke plek op internet uitgevoerd kon worden. De exploit was 95 procent betrouwbaar en bijna perfect." Sommigen zullen inmiddels tot de juiste conclusie zijn gekomen dat dit het lek is dat werd gebruikt door de Conficker-malware.
Tot slot
Het moge duidelijk zijn dat de door Heartbleed ingezette trend van het optuigen van een soort marketingcampagne rond een kwetsbaarheid niet snel zal verdwijnen. Er bestaat al lange tijd discussie over de praktijk, waarbij de meesten het erover eens lijken te zijn dat het van tevoren creëren van onnodige hype eigenlijk alleen maar schadelijk is. Toch zijn er niet veel branded bugs te noemen waarbij het helemaal verkeerd is gegaan en ook dit jaar waren de 'grote namen' doorgaans ernstig genoeg om de aandacht en publiciteit eromheen te verdienen. In 2018 zullen er ongetwijfeld nieuwe grote lekken aan het licht komen en wie weet zien we nog een overtreffende trap in marketing. Laten we alleen hopen dat het tussen nu en het nieuwe jaar nog even rustig blijft.
Ik vind het goed dat er branding plaatsvindt, niet voor mij persoonlijk als CERT medewerker, maar voor awareness. Als m'n baas vroeger vroeg waarom mijn team en ik weer eens een nacht moesten doorhalen om patches te checken, uit te rollen, klanten te informeren etc. snapte hij de urgentie gewoon niet. Het was voor hem niet uit te leggen aan zijn baas waarom wij ineens weer extra uren (kosten) genereerde en intensief klantencontact hadden. Er was nooit extra geld voor nieuwe processen, mensen en uiteindelijk ook voor de nodige hardware/software.
Maar nu het "op het nieuws is" en zelfs politici beginnen mee te praten, is het topic niet meer te negeren. Dus voor mij is een belangrijk doel bereikt!
Welkom in de corporate wereld, waar menig management liever de vinger in de oren doet dan naar de security afdeling luistert (als die überhaupt al bestaat).
Luisteren naar je IT afdeling kost bijna altijd tijd en geld. Luisteren naar je Security Officers maakt dingen ook nog moeilijker (toegang tot data, facilteiten etc). Dus dat doen ze liever niet.
Het is dus goed dat er zoveel aandacht voor dit soort lekken is. Ook helpt het dat er tegenwoordig stevige boetes staan op datalekken. Dit werkt allemaal motiverend om te zorgen dat je omgeving en data zo veilig mogelijk zijn.
Het feit dat Microsoft de eternalblue exploit op Windows XP en 2003 Server heeft gepatched terwijl die allang EOL waren geeft wel aan hoe belangrijk het is.
Met andere woorden, als dit soort berichten door management wordt genegeerd dan is het heel slecht management. Het eerste en minste wat ze moeten doen is zich afvragen welke gevolgen het lek heeft.
Ik denk dat het meer is van, ALS mensen dit proberen KAN er iets gevaarlijks gebeuren. Als het wijd in het nieuws komt en je klanten gaan vragen van 'is mijn systeem wel veilig' en je weet dat je vannacht een groep devs weg hebt gestuurd omdat je het onzin vond, dan sta je daar met je mond vol tanden.
Dit help zeker mee in de security tak! Heb dit gemerkt afgelopen jaar dat er veel meer draagvlak is bij klanten om software te upgraden of configuratie aan te laten passen.
Er zit in de praktijk bij veel CVE's of fabrikant security meldingen ook veel ruis. Bijvoorbeeld dan zijn er critical meldingen die je alleen kunt exploiten als je al admin toegang tot het device hebt.
[Reactie gewijzigd door kr4t0s op 23 juli 2024 15:46]
Mooi artikel, ben zelf niet zo thuis in de hacking/bug-scene, maar er zijn wel een flink aantal van deze namen die ik langs heb zien komen (en niet alleen op Tweakers)! Als ze nooit van die fancy namen en logo's hadden gekregen, had ik er waarschijnlijk nooit van gehoord, laat staan op de artikels geklikt op Tweakers, aangezien een naam als CVE-2014-0160 veel te technisch klinkt voor mijn interesse.
En ik denk dat dat voor heel veel mensen geldt! Daarnaast zorgen goede logo's en namen er ook voor dat de mainstream media er over schrijft, wat er weer voor zorgt dat het ook bij de gewone huis- tuin- en keukengebruiker aankomt.
Het is wel handig om iets een herkenbare naam te geven om naar te refereren. “Onderzoek #6461” en “Onderzoek #6462” klint wat kak en hoe meer er zijn hoe lastiger het wordt om te onthouden wat nou wat was Codenamen voor projecten ed zijn niet vreemd, zo ook voor onderzoeken en zo te zien ook praktische toepassing voor lekken.
Bedankt voor je reactie. Nu is het zo dat de betreffende papers eerder ”dit effect in die situatie” heten dan ”onderzoek#zoveel”, maar ik begrijp goed wat je bedoelt. Was voor de goede lezer trouwens ook gewoon in het stuk te lezen :-)
In andere bedrijfstakken komt dit ook voor. Ik Werk in de werktuigbouw, tijdens het ontwerp krijgen verschillende onderdelen namen zoals sjoelbak, knikkerputje, hoefijzer. Een reden waarom dit gedaan wordt is dat iedereen weet waar het om gaat ookal slaat de naam soms nergens op. Een beetje humor op zijn tijd kan ook geen kwaad.
Dat een onderzoek een leuke naam (titel) krijgt daar kan ik zeker inkomen. Alleen vraag ik me in die sector soms af hoe ze hun producten namen geven. Precies of ze plakken enkele willekeurige lettergrepen achter elkaar.
Leuk stuk, maar zowel voor de vurnable sector als farmaceutische industrie geldt dat er nog wat (heel veel) verbetering te behalen valt op het gebied van marketing. Als marketeer kijk ik toch wat anders naar bovenstaand artikel. Ze hebben hun best gedaan en aandacht gegenereerd maar maar er valt nog een hoop verbetering te behalen wat ook direct duidelijk is als je naar de gekunstelde namen en logo's kijkt.
Zelfde geldt voor de farmaceutische industrie. Zo gebruik ik zelf medicijnen met een naam die ik niet kan onthouden en niet kan uitspreken met een logo dat niets zegt en dat geld zelfs voor de bekendere medicijnen etc. De beste marketeers werken duidelijk niet in de beveiligingssector of farmaceutische industrie.
Ik heb geen probleem met branding, maar waar je wel weer terecht komt is één van de twee bekende problemen in de IT:
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
Het zou handig zijn geweest als je in ieder geval uit de naam kon halen waar de bug betrekking op heeft zonder het weer te moeten googlen om erachter te komen dat Roca staat voor 'The Return of Coppersmith's Attack' dat weer verwijst naar een eerdere aanval die je dan weer kan opzoeken.
IT'ers lijken zaken soms zo ontoegankelijk mogelijk te willen maken met rare namen. Net als de eerste keer dat ik een kijkje kwam nemen in de wereld van CSS preprocessors. Dan krijg je een berg warrige termen als npm, gulp, grunt, bower, ruby gems, less, scss/sass, compass voorgeschoteld. Bij Malware heb je wel weer een duidelijkere naamgeving.
Een andere optie zou zijn dat er een commissie wordt opgezet bugs beoordeelt en namen kan uitdelen als deze erg genoeg zijn. En er dan een systeem in houdt zodat je het meteen kan herkennen en dat je geen wildgroei krijgt.
Ernstige fouten zijn van alle tijden zelfs in software welke gebruikt wordt om goede veiligheid te waarborgen zoals destijds de remote hole in OpenSSH. Het beestje een naam geven maakt het eenvoudiger om te weten waar je het over hebt. Het is ook van alle tijden. Napoleon heeft bij ons de achternaam ingevoerd omdat "Kees uit de Jordaan" te vaag is. Exploits hadden of kregen vroeger ook al namen. Dat is ook van alle tijden. Zoals bijvoorbeeld de eerste worm ooit (gebruik makende van een Sendmail remote hole) de Morris worm heette. Het maakt het makkelijker om erover te praten of er naar te refereren. Een CVE nummer is voor een computer handig om onderscheid te maken; voor het menselijk oog is het lastiger te onderscheiden. Het marketing en awareness gedeelte bedient een behoefte, en men heeft behoefte aan een naam want "het bedrijf van Kees uit de Jordaan" is te vaag, te lang, en omschrijft het bedrijf niet terwijl iets simpels als "loodgieter Jordaan" dat wel doet (hoewel in dit geval er misschien ook meerdere zijn). Een logo werkt, net als emoticons, in elke taal terwijl een naam of acronym vaak gericht is op primair Engels. Een domeinnaam met heldere uitleg zorgt er voor dat mensen makkelijk worden geinformeerd zonder dat men steeds moet herhalen, of een lange URL in moet typen (CVE reference). Zo'n acronym heeft ook de functie om te omschrijven. Helpt ook als geheugensteuntje.
Timing is ook belangrijk, zo ook het lekken van details. Badlock is daar een mooi voorbeeld van, maar ook niet de eerste. Bij die OpenSSH remote hole ging ook e.e.a. mis, wat ook deels te wijten was aan de belangen van het OpenBSD team.
‘het grote lek in OpenSSL van drie jaar terug’
Het is handiger om een jaartal te gebruiken. Henk16 blijft maar max 1 jaar een accurate naam terwijl Henk2001 voor altijd accuraat blijft. (Tot Henk z'n tweede naam gaat gebruiken (of tot Tweakers.net hem slacht )).
Het beestje een naam geven maakt het eenvoudiger om te weten waar je het over hebt. Het is ook van alle tijden. Napoleon heeft bij ons de achternaam ingevoerd omdat "Kees uit de Jordaan" te vaag is.
Maar dat is precies mijn punt. Aan de achternaam kan je zien uit tot welke familie iemand behoort. Dat kan je niet als je alleen maar een voornaam hebt en dat is precies wat je nu ziet: ze bedenken allemaal voornamen als naam voor de vulnerability. Dat werkt als het nog niet vaak is voorgekomen, maar niet als dat zo door blijft gaan. Ik pleit juist voor een achternaam die aangeeft waar de bug bij hoort. De malware naamgeving lijkt er redelijk geschikt voor.
Vulnerability:OpenSSL/Heartbleed is in mijn ogen duidelijker dan alleen Heartbleed of CVE-2014-0160. Dat bepaalde bugs worden afgekort in de volksmond vanwege de impact is logisch, maar elke nieuwe bug een random naam geven maakt het er niet duidelijker op. Zeker niet als je ook nog eens generieke woorden gaat gebruiken als Ghost.
Een domeinnaam met heldere uitleg zorgt er voor dat mensen makkelijk worden geinformeerd zonder dat men steeds moet herhalen, of een lange URL in moet typen (CVE reference).
Totdat de domeinnaam verloopt en gekaapt wordt door een partij die malware serveert .
Net als de eerste keer dat ik een kijkje kwam nemen in de wereld van de bouw. Dan krijg je een berg warrige termen als spijker, hamer, schroef, bout, moer, hout, steen, cement, beton voorgeschoteld.
Er is geloof ik redelijk wat consensus dat nonpetya een test run was, dus dat de echt grote klapper nog moet komen. Gezien het aantal lekken vanuit de intel agencies ben ik bang dat de aanvallen die gaan komen steeds erger in omvang en schade worden.
Denk daarbij aan banken of nutsvoorzieningen die compleet worden plat gelegd.
Tsja dat met het lekken van gevaarlijkere tools geloof ik best. We gaan er denk ik pas van leren als het een keer écht fout gaat. Wat mij betreft had Stuxnet al motivatie moeten zijn om belangrijke infra strenger te airgappen maar we zien net te vaak onderzoeken waar dit niet bij blijkt te zijn, zeker in het buitenland.
Volgens mij hebben veel verantwoordelijke it'ers van NotPetya wel geleerd om (Windows) updates sneller uit te rollen. Tenminste, wat ik zo om me heen zie.
Leuk verhaal en met plezier gelezen. Mij lijkt branding van exploits prima omdat het zo een makkelijker gespreksonderwerp is en iedereen het over hetzelfde heeft. De vaak wat prutserige logo’s zijn minder belangrijk imho. Het is meer een kwestie van “het beestje moet een naam hebben”.
Er werken hier mensen aan, die ook betaald moeten worden. En het liefst zoveel mogelijk natuurlijk, dan is mooie marketing nooit ver weg. Een beetje "de een z'n dood is een ander z'n brood".
Het lastige is natuurlijk om een "product" te beoordelen adhv de marketing campagne. Maar hoe mooier de campagne, hoe vlugger de bug wordt opgelost hopelijk. En hopelijk werkt dat niet omgekeerd: Gevaarlijke bugs zonder mooie campagne blijven lang open.
[Reactie gewijzigd door KopjeThee op 23 juli 2024 15:46]
Hoevaak zie een 0-day vinder presentatie houden over door hem/haar gevonden bug en exploit(p0c) ervoor.
Het aantal publiekelijk gegeven presentaties staat tot niets tov aantal bug/0days.
Als iemand voor zichzelf besluit om in sprekerscircuit te kapitaliseren heb je met branded vulns een business model, waar anderen niet mee kunnen weglopen.
[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 15:46]
Je hebt zonder meer gelijk. De meeste branded vulnarabilities zijn wel gepatched.
Een paar dagen geleden de youtube video "Zero Days, Thousands of nights" gezien. Ik had nooit gedacht dat de gemiddelde 0-day exploit zeven jaar bestaat. Interessante video waarbij zaken als open vs closed source en bewust geheimhouding worden aangeroerd. Verwacht geen technische uiteenzetting van de exploits, het gaat vooral om statistieken.
Mooi achtergrond artikel en ik heb er in ieder geval weer een hoop bijgeleerd. De ene bug stond wat dichter op mijn netvlies dan bij de ander. Met de ene bug heb ik ook wat meer moeten checken dan bij de ander. Zo heb ik met de Heartbleed bug veel servers moeten updaten met de patch die speciaal voor dat doel werd gereleased.
De logo's ben ik nooit tegengekomen of het viel niet op, maar de benamingen zijn wel belangrijk geweest voor mij.
Omdat we het nu toch over geschiedenis hebben, kunnen we ook even een blik werpen op de totstandkoming van de Heartbleed-pagina en het bekende ‘bloedende hart’-logo. Zoals ZDNet destijds schreef, claimde het Finse bedrijf Codenomicon dat het de kwetsbaarheid net iets na de oorspronkelijke ontdekking door Google-onderzoeker Neel Mehta had gevonden. Die meldde het in eerste instantie direct aan OpenSSL, terwijl de Finnen ermee naar hun nationale Cert gingen. Het bedrijf legde uit dat een van zijn medewerkers de term Heartbleed had verzonnen, omdat de kwetsbaarheid aanwezig was in de zogenaamde heartbeat-extensie van tls. Het inmiddels welbekende logo was het werk van een Codenomicon-medewerkster genaamd Leena Snidate, een grafisch vormgever. De site kwam uiteindelijk tot stand doordat het bedrijf een soort interne vraag-en-antwoordsessie hield en besloot om de inhoud daarvan online te zetten om mensen te informeren.
Wie herinnert zich niet meer dit Android-lek, dat ergens halverwege 2015 werd ontdekt. Deze /i/2001754279.png?f=imagenormal)
Deze /i/2001754281.png?f=imagenormal)
Ghost deed zich voor aan het begin van 2015 en betrof een /i/2001754283.png?f=imagenormal)
Met de /i/2001754285.png?f=imagenormal)
Laten we eindigen met een voorbeeld voor hoe een kwetsbaarheid beter niet naar buiten kan worden gebracht. Zoals hiervoor al aangestipt is het gevaar aanwezig dat er veel hype ontstaat rond een kwetsbaarheid die uiteindelijk weinig voorstelt. Zo was 
Voor wie het weer even kwijt was: Krack was opmerkelijk omdat het om een lek in de wpa2-standaard ging, waar we het met z'n allen al vrij lang mee doen. De naam staat voor 'key reinstallation attacks' en omvat net als andere namen een aantal verschillende cve's. Wpa2 zorgt voor een beveiligde netwerkverbinding, maar door de kwetsbaarheid is het voor een aanvaller mogelijk om alsnog mee te luisteren. Wat de gevolgen van de aanval enigszins beperkte, is het feit dat wifi vereist dat een aanvaller zich in ieder geval in de buurt van het draadloze netwerk bevindt. Bovendien waren verbindingen via https niet aangetast. De bekendmaking vond plaats op een maandag in oktober en kende een korte aanloop met enige oproer omdat het Amerikaanse Cert een waarschuwing had uitgestuurd voordat de informatiesite online stond. Dat zorgde binnen de beveiligingscommunity voor enige opwinding. Toen de site eenmaal online kwam, was deze voorzien van veel informatie en een uitgebreide vraag-en-antwoord-afdeling./i/2001754289.png?f=imagenormal)
/i/2003127262.png?f=fpa)
/i/1057741947.png?f=fpa)
:strip_exif()/i/2001740637.jpeg?f=fpa)
/i/2000562773.png?f=fpa)
:strip_exif()/i/1185182814.gif?f=fpa)
:strip_exif()/u/483953/crop56fe86220014b_cropped.gif?f=community){kind=small}
/u/158148/crop5d2f87b2c1740_cropped.png?f=community){kind=small}
:strip_exif()/u/38542/Scrat1ani.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/438249/crop5f2583b7d1758_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/176404/crop5d8a18233281d_cropped.jpeg?f=community){kind=small}
/u/407403/WAhack.png?f=community){kind=small}
Codenamen voor projecten ed zijn niet vreemd, zo ook voor onderzoeken en zo te zien ook praktische toepassing voor lekken.
:strip_icc():strip_exif()/u/78725/train-icon3.jpg?f=community){kind=small}
/u/217510/crop660db19c1cf7b_cropped.png?f=community){kind=small}
)).
.
:strip_exif()/u/591794/crop61a251d10f7b3.gif?f=community){kind=small}
/u/32247/jayce.JPG?f=community){kind=small}
:strip_icc():strip_exif()/u/173388/crop5dbbf7660b2c7_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/90600/1005246_647191608633641_119027804_n%252060x60.jpg?f=community){kind=small}
.
:strip_icc():strip_exif()/u/344279/crop5b2268e424c02_cropped.jpeg?f=community){kind=small}
:strip_exif()/u/94091/lynxa.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/129865/crop5cb775b8692d8.jpeg?f=community){kind=small}