Gebruiker:Pieterjan E/Zero-dayaanval
Aan deze pagina of deze sectie wordt de komende uren of dagen nog druk gewerkt.
Klik op geschiedenis voor de laatste ontwikkelingen.
Een zero-day (of nul-uren of nul dagen) aanval, aanslag of dreiging is een computer dreiging dat probeert misbruik te maken van zwakke delen in software welke onbekend zijn voor anderen of de software-ontwikkelaar. Zero-day exploits (software die daadwerkelijk via een gat in de beveiliging gebruik maakt van het uitvoeren van een aanval) worden gebruikt of gedeeld door aanvallers vóór de ontwikkelaars van de doelsoftware iets afweten van de kwetsbaarheid. De term is afgeleid van de leeftijd van de exploit. Een "zero day" aanval start op of vóór de eerste dag dat de ontwikkelaar bewust is van het beveiligingslek, wat betekent dat de ontwikkelaar geen enkele kans heeft om een fix voor de software te distribueren naar gebruikers ervan. [1]
Aanvalsvectoren[bewerken | brontekst bewerken]
Malwareschrijvers zijn in staat om ‘zero-day-kwetsbaarheden’ uit te buiten door middel van een aantal verschillende aanvalsvectoren. Web browsers zijn een bijzonder doelwit vanwege hun grote verspreiding en gebruik. Aanvallers kunnen ook e-mailbijlagen versturen, die bij het openen van de bijlage actief worden en de kwetsbare software gaan aanvallen.[2] Exploits die gebruik maken van vaak gebruikte bestandstypen worden opgenomen in databanken zoals US-CERT (United States Computer Emergency Readiness Team). Malware kan worden gemanipuleerd om te profiteren van deze bestandstype om zo aangevallen systemen te compromitteren of vertrouwelijke gegevens te stelen, zoals bank-wachtwoorden en persoonlijke identiteitsgegevens. [3]
Kwetsbaar moment[bewerken | brontekst bewerken]
Zero-day aanvallen treden op tijdens de het kwetsbare moment dat bestaat uit de tijd tussen het moment dat er een eerste uitbuiting is van het beveiligingslek en wanneer de softwareontwikkelaars beginnen met oplossing voor de bedreiging tegen te gaan. Bij virussen, Trojaanse paarden en andere zero-day aanvallen, zijn meestal van toepassing volgens deze tijdslijn:
- De ontwikkelaar maakt software met een (onbekend) beveiligingslek
- De aanvaller vindt het lek vóór de ontwikkelaar
- De aanvaller schrijft en distribueert een exploit, terwijl het lek nog niet bekend is bij de ontwikkelaar
- De ontwikkelaar is bewust van het beveiligingslek en start met de ontwikkeling van een software fix.
Het meten van de lengte van dit kwetsbare moment kan moeilijk zijn. Aanvallers kondigen niet aan wanneer ze een lek voor het eerst ontdekken. Het is ook mogelijk dat de ontwikkelaars de gegevens niet willen verspreiden voor commerciële- of veiligheidsredenen. Soms weten de ontwikkelaars niet dat het lek al wordt misbruikt na de fix van de software, en dus weten ze het niet dat er een zero-day aanval was. Het kan wel gemakkelijk worden aangetoond dat het lek verover langere tijd, bijvoorbeeld verschillende jaren, actief was. Een voorbeeld van in 2008 toen Microsoft bekent maakte dat er een beveiligingslek in Internet Explorer was, waardoor sommige versies, uitgebracht in 2001, getroffen waren. [4] De datum van de ontdekking van het lek is niet bekend, maar het kwetsbare moment zou in dit geval tot 7 jaar geweest zijn.
Ontdekking[bewerken | brontekst bewerken]
Een speciaal type van procesmanagement bij softwareontwikkelaars is gericht op het vinden en elimineren van zero-day beveiligingslekken. Het is een proces om de veiligheid en kwaliteit te waarborgen dat gericht is op het garanderen van de veiligheid en sterkte van zowel in-house software als software van derden door het vinden en de vaststelling van onbekende (zero-day) kwetsbaarheden. Deze onbekende manier van procesmanagement bestaat uit vier fasen: Analyseren, testen, rapporteren en het inperken van.[5]
- Analyseren: deze fase richt zich op de oppervlakteanalyse van de aanval
- Test: de test fase richt zich op het testen van de geïdentificeerde aanvalsvectoren
- Rapport: deze fase is gericht op de reproductie van de gevonden problemen voor ontwikkelaars
- Beperken: in deze fase wordt er gekeken naar beschermende maatregelen.
Ontdekking[bewerken | brontekst bewerken]
Een speciaal type van procesmanagement is gericht op het vinden en elimineren van zero-day beveiligingslekken. Het is een proces om de veiligheid en kwaliteit te waarborgen dat gericht is op het garanderen van de veiligheid en sterkte van zowel in-house software als software van derden door het vinden en de vaststelling van onbekende (zero-day) kwetsbaarheden. Deze onbekende manier van procesmanagement bestaat uit vier fasen:. Analyseren, testen, rapporteren en het inperken van.[5] • Analyseren: deze fase richt zich op de oppervlakteanalyse van de aanval • Test: de test fase richt zich op het testen van de geïdentificeerde aanvalsvectoren • Rapport: deze fase is gericht op de reproductie van de gevonden problemen voor ontwikkelaars • Beperken: in deze fase wordt er gekeken naar beschermende maatregelen.
Bescherming[bewerken | brontekst bewerken]
Zero-day bescherming geeft men de mogelijkheid om zich te beschermen tegen zero-day exploits. Zero-day aanvallen kunnen ook onopgemerkt blijven nadat ze zijn gelanceerd. [6] Er bestaan veel technieken om de effectiviteit , te beperken van de zero-day aanval met aantasting van het geheugen, zoals een [[bufferoverloop] of buffer overflow. Deze beschermingsmechanisme bestaat in de huidige besturingssystemen zoals Windows 7, Windows Vista, Apple's Mac OS X, de recente Oracle Solaris, Linux en mogelijk ook andere Unix en Unix-achtige omgevingen. Microsoft Windows XP Service Pack 2 bevat een beperkte bescherming tegen de kwetsbaarheid van corrupt geheugen corruptie.[7] De beveiligingssoftware voor desktops en servers bestaat ook om de van Zero-day kwetsbaarheid van een bufferoverloop tegen te gaan. Het gebruik van port knocking of singel packet authorization daemons kunnen een effectieve bescherming bieden tegen zero-day exploits in een netwerkdiensten. Deze technieken zijn echter niet geschikt voor omgevingen met een groot aantal gebruikers.
whitelisting beschermt effectief tegen zero day bedreigingen. Whitelisting laat alleen goede en gekende toepassingen toegang tot het systeem en dus elke nieuwe of onbekende exploits hebben geen toegang. Hoewel whitelisting zeer effectief is tegen zero-day aanvallen, kan een toepassing, gekend om zijn “goedheid”, kwetsbaarheden hebben die niet ontdekt zijn tijdens het testen op beveiligingslekken. Om de beveiliging te versterken, wordt dit vaak gecombineerd met andere beveiligingsmethoden zoals een host-based en:intrusion-prevention systeem of een blacklist van virusdefinities en het kan soms erg beperkend zijn voor de gebruiker. Ingenieurs en leveranciers, zoals Gama-Sec in Israël en DataClone Labs in Reno, Nevada proberen ondersteuning te bieden met het Zeroday Project,[8], dat probeert informatie te bieden toekomstige aanvallen en ondersteuning te bieden aan kwetsbare systemen. De computers software up-to-date houden is ook erg belangrijk en dit helpt. Gebruikers moeten voorzichtig te zijn wanneer ze klikken op links of bij het openen van e-mailbijlagen met afbeeldingen of PDF-bestanden van onbekende gebruikers. Zo worden er veel mensen misleid door cybercriminelen, ze doen zich anders voor dan ze zijn en krijgen zo het vertrouwen van de gebruiker. Door sites te gebruiken met Secure Socket Layer (SSL), wordt de informatie veilig doorgezonden tussen de gebruiker en de bezochte website.
Ethiek[bewerken | brontekst bewerken]
Er bestaan verschillende opvattingen rond het verzamelen en gebruiken van informatie over de zero-day kwetsbaarheid. Veel computer beveiligingsbedrijven voeren onderzoek uit naar zero-day kwetsbaarheden om de aard en de exploitatie ervan door individuen, computerwormen en virussen beter te kunnen begrijpen. Als alternatief kopen bepaalde leveranciers kwetsbaarheden om hun onderzoekscapaciteit te verhogen. Een voorbeeld van zo'n programma is het Zero Day Initiative van TippingPoint.[9] Technisch gezien is het niet illegaal om deze kwetsbaarheden te kopen en verkopen maar in de meeste delen van de wereld, is er veel controverse over de wijze van openbaarmaking. Een recente Duitse beslissing om artikel 6 van het Verdrag inzake Cybercriminaliteit en het EU-Kaderbesluit over Aanvallen op Informatiesystemen kan dit het verkopen of zelfs produceren van kwetsbaarheden illegaal maken. De meeste formele inspanningen volgen een bepaalde vorm van en:RFPolicy onthullende richtlijnen, of de meer recente OIS richtlijnen voor Security Vulnerability Reporting and Response.[10] In het algemeen verbieden deze regels de openbaarmaking van kwetsbaarheden, zonder kennisgeving aan de ontwikkelaar en voldoende tijd om een patch te produceren.