Organisaties modelleren hun patchbeleid naar wat de leveranciers aankondigen, omdat het aanvalsoppervlak zo groot is geworden. Maar de eerste onthulling komt niet altijd van de leveranciers en het wachten erop kan je dagen of zelfs weken achterop de aanvallers raken. Zij bediscussiëren nieuwe lekken binnen enkele uren nadat ze bekend zijn gemaakt en maken tutorials voor het misbruik ervan.
Kletsende hackers
"Het gepraat online begint doorgaans binnen 24 tot 48 uur na de eerste publieke bekendmaking", weet Levi Gundert wiens bedrijf Recorded Future beveiligingsanalyses uitvoerde aan de hand van online discussies op buitenlandse fora. Niet alleen beveiligers lezen advisory's, blogposts, mailinglist-berichten en CERT-waarschuwingen. Door te weten waar aanvallers in zijn geïnteresseerd - en hoe ze kwetsbaarheden willen gebruiken voor leveranciers reageren - is een goede manier om aanvallers een stapje voor te zijn.
Een mooi voorbeeld. In januari vorig jaar werd op een conferentie een Java-fout besproken, maar de kwetsbaarheid trok niemands aandacht tot 6 november, toen onderzoekers van FoxGlove stuitten op het probleem in meerdere zakelijke softwaretoepassingen, zoals WebSphere en JBoss. Het duurde daarna nog eens twaalf dagen voor Oracle en 19 dagen voor Jenkins het probleem aanpakten met formele aankondigingen.
Aanvallers allang actief
Maar communities waar aanvallers actief zijn, begonnen de blogpost van FoxGlove binnen enkele uren te bespreken en een proof-of-concept exploitcode verscheen zes dagen later, zo ontdekte Recorded Future. Een gedetailleerde tutorial waarin werd uitgelegd hoe je de aanval kunt uitvoeren verscheen op 13 november, nog vijf dagen voordat Oracle officieel reageerde. Begin december wisselde aanvallers uit welke organisaties kwetsbaar waren en beschreven ze hoe bij hen de kwetsbaarheid benut kon worden.
"De tijd die tussen het identificeren van een kwetsbaarheid en de patch of workaround van de leverancier zit, is uiteraard een waardevolle periode voor aanvallers", zegt Gundert. "Maar als in die periode gedetailleerde exploitgidsen beschikbaar komen in meerdere talen, kan deze delta rampzalig zijn voor bedrijven."
Ook obscure blogs besproken
Nog een voorbeeld waarin aanvallers een voorsprong nemen op beveiligers is de PHP-kwetsbaarheid in OPcache Binary Webshell. Beveiligingsbedrijf GoSecure beschreef een exploit op 27 april en op 30 april verscheen er een tutorial die verwees naar de proof-of-concept van GoSecure. De kwetsbaarheid was niet van universele toepassing op alle PHP-applicaties, maar met behulp van de tutorial konden aanvallers gemakkelijker de configuraties ontdekken die vatbaar waren voor malafide uploads.
"Zelfs obscure blogs vallen op", vertelt Gundert. Voor het overgrote deel bleef de blogpost van GoSecure onopgemerkt. Met zoveel beveiligingsverhalen die schreeuwen om aandacht, wordt een blog gauw over het hoofd gezien en blijft de aanvalsvector bestaan. Aan de andere kant van het gevecht zien aanvallers deze verhalen wel, bespreken ze en delen ze informatie en tools om er gebruik van te maken.
Een reden waarom aanvallers zo'n voorsprong krijgen op leveranciers en beveiligers is het Disclosure-proces zelf. Aankondigingen bevatten meestal een CVE. Die identifier wordt beheerd door non-profit MITRE en CVE's vormen een database van beveilgingskwetsbaarheden waar professionals informatie uit putten. MITRE ontvangt aanvragen voor het toewijzen van een CVE als een softwaremaker, ontwikkelaar, onderzoeker of wie dan ook een gat vindt en een verzoek indient.
Voorsprong door gebrek aan CVE
Als Mitre een CVE toewijst kunnen beveiligers, leveranciers en bedrijven deze gebruiken om een specifiek gat te bespreken om te kijken hoe deze gedicht kan worden. In gevallen waar de oorspronkelijke onthulling niet van de leverancier komt, zoals in het voorbeeld op de vorige pagina van de Java-fout, hebben aanvallers een voorsprong op beveiligers die wachten op de toewijzing van de CVE.
Dat tijdsverschil is van cruciaal belang. Met zoveel kwetsbaarheden om te onderzoeken en aan te pakken en een beperkte hoeveelheid resources om dat uit te voeren, is het filteren op basis van of er een CVE is een redelijke houding, vindt Nicko van Someren, CTO van de Linux Foundation. De implicatie is dat als een bug eenmaal een CVE heeft, deze echt bestaat en aandacht verdient.
Meer software = meer gaten
Maar de laatste tijd is het CVE-systeem zelf een probleem aan het worden. Beveiligingsprofessionals klagen dat MITRE niet tijdig CVE's toewijst. Die vertraging heeft een impact, want het is voor softwareproducenten, partners en onderzoekers moeilijk om een oplossing te coördineren zonder systeem die garandeert dat iedereen het over hetzelfde heeft. Deels wordt het huidige probleem veroorzaakt door schaal: de softwaresector is een stuk groter dan tien jaar geleden en kwetsbaarheden worden in grotere kwantiteiten ontdekt.
Uit de analyse van Recorded Future blijkt dat vertragingen in het toewijzen van CVE's aanvallers de tijd geeft om technieken en tools te ontwikkelen en te verfijnen. "Er zijn een heleboel mensen die geloven dat als er geen CVE is, het geen echt issue is en dat is een groot probleem", aldus Jake Kouns, CISO van Risk Based Security.
Meer gaten dan CVE's
Een ander issue is dat niet alle kwetsbaarheden een CVE krijgen, zoals webapplicaties die op de server worden bijgewerkt en geen directe interactie met de klant hebben. Helaas geldt dat ook voor gaten in mobiele apps, die wel interactie vereisen van consumenten om een update te installeren. Vorig jaar waren er 14.185 kwetsbaarheden gemeld, 6000 meer dan in de National Vulnerability Database en CVE, staat te lezen in een rapport van Risk Based Security.
De echte waarde van het CVE-systeem voor consumenten en securityprofessionals is niet het daadwerkelijk meten van het risico en de impact, maar het in kaart brengen van alle bekende risico's voor een systeem, ongeacht de ernst ervan", vindt Kymberlee Price, hoofdonderzoeker bij BugCrowd.
Een nieuwe strategie
Omdat CVE's niet alle exploits behandelen, moet je verder kijken dan de CVE om een beeld te krijgen van wat eraan zit te komen. Dat betekent dat patchbeleid niet meer gekoppeld moet worden aan aankondigingen van leveranciers, maar dat je andere informatiebronnen moet gebruiken om de laatste onthullingen te zien. Je beveiligingsteam zou effectiever zijn als ze actief zochten op proof-of-concepts alsmede tekenen van exploitactiviteit richting de eigen organisatie of sector.
Er is een hoop openbare informatie beschikbaar buiten de aankondigingen van producenten om. Zoveel zelfs dat je niet van beveiligers kunt verwachten dat ze op de hoogte zijn van alle blogposts met onthullingen, mailinglist-discussies tussen onderzoekers over beveiligingsfouten en andere publieke aankondigingen. In plaats van abonneren op alle mogelijke mailinglists en RSS-feeds, is het beter om direct naar (ondergrondse) fora te gaan om te kijken wat er leeft bij de aanvallers.
Scannen begint direct
Threat Intelligence vermindert de ruis en geeft je nuttige informatie, maar het is niet de enige manier om deze conversaties te volgen. Het verdient aanbeveling om in de gaten te houden of scannende activiteiten toenemen, want dat geeft een aardige indicatie dat er discussies worden gevoerd over hoe een kwetsbaarheid benut kan worden.
Zo merkte Recorded Future op dat toen een kwetsbaarheid in de Groovy-scriptingengine in Elasticsearch werd ontdekt, vrijwel onmiddellijk daarop gescand werd op deze kwetsbaarheid. Ondertussen werd op fora besproken hoe het gat benut kan worden en aanvallers hun malware persistent kunnen houden in overgenomen omgevingen.
Volg de vijand
"Als ik verantwoordelijk zou zijn voor patchbeleid of het analyseren van kwetsbaarheden in mijn organisatie, zou ik kijken naar gesprekken op fora, met name naar discussies over specifieke kwetsbaarheden", zegt Recorded Future's Gundert. "Je vangt zerodays daar niet mee op, maar je ziet wel welke fouten aandacht krijgen nog weken voordat je er advies over krijgt van leveranciers."
Organisaties zouden een handvol fora, IRC-kanalen en andere bronnen kunnen monitoren in plaats van af te wachten op officiële kanalen. Analisten van Recorded Future melden dat bepaalde gebruikers die informatie plaatsen een betrouwbare bron van informatie vormen. Door simpelweg deze kwaadwillende experts te volgen, vind je gesprekken over de populairste nieuwe gaten. Ook door in de gaten te houden wat er via deze personen wordt gedeeld op GitHub, krijg je een beeld van de plannen die er worden ontwikkeld.
-
-
Er zijn nog geen reacties.Reageer
Preview