Hackers misbruiken vaker opensource-lekken
Beveiligingslekken in opensource software worden vaker en sneller door hackers aangevallen dan kwetsbaarheden in gesloten software, zo blijkt uit onderzoek. Volgens onderzoeker Sam Ransbotham geeft de beschikbaarheid van broncode aanvallers mogelijk een voordeel bij het ontwikkelen van exploits. Tijdens het onderzoek "An Empirical Analysis of Exploitation Attempts based on Vulnerabilities in Open Source Software" werd twee jaar lang data van intrusion detection systemen geanalyseerd, in totaal 400 miljoen waarschuwingen. Aanvallen op lekken in opensource software zouden drie dagen eerder plaatsvinden en met bijna vijftig procent grotere frequentie.
Ransbotham erkent dat het bekijken van de broncode voordat een product verschijnt grote voordelen heeft en ervoor kan zorgen dat opensource software in potentie veiliger is dan gesloten software. "Voor wat betreft lekken die na de release worden gevonden, werkt het voordeel van veel mensen die meekijken tegen de veiligheid van opensource software." Aangezien aanvallers ook toegang tot de code hebben, kunnen ze de details van een lek achterhalen en uitzoeken hoe het te misbruiken is.
Exploits
Volgens experts kan er geen algemene conclusie worden getrokken dat opensource software eenvoudiger te hacken is. "Dat is zeker niet waar", zegt Dave Aitel van Immunity. "Je kunt zelfs de tegenovergestelde conclusie trekken aan de hand van het aantal exploits dat op websites zoals Packetstorm aanwezig is."
Gary McGraw van Cigital merkt op dat het niet om opensource of gesloten source gaat, maar hoe een bedrijf software ontwikkelt. "Aanvallers kunnen uiteindelijk de informatie bemachtigen om een lek te misbruiken, zij het via geautomatiseerde aanvalssoftware, het reverse engineeren van patches of door iemand die toegang tot de broncode krijgt, dus bedrijven moeten daar rekening mee houden."
Microsoft
Het onderzoek is ook bij Microsoft niet onopgemerkt voorbij gegaan. "Komt het de beveiliging ten goede als iedereen de code kan zien of helpt het de aanvallers?" is de vraag die Microsoft beveiligingschef Roger Halbheer stelt. Hij merkt meteen op dat hij geen religieuze discussie wil over welk model nu veiliger is. "Ik geloof niet dat zo'n discussie veel waarde heeft."
Sinds enige jaren deelt Microsoft de broncode van Windows met bepaalde landen. "Soms hebben we de discussie met overheidsfunctionarissen of het hebben van toegang tot de code een aanvallend land een voordeel geeft op het gebied van cyberoorlog of cyberspionage. Naar die discussie kijkend, zou opensource helemaal slecht af zijn, aangezien daar iedereen toegang tot de code heeft." Wat betreft het grotere aantal lekken in opensource software, komt dit volgens Halbheer vanwege het gebrek aan processen om beveiliging vanaf het begin aan het product toe te voegen.
In zijn onderzoek zegt Ransbotham ook dat als de verdedigers patchen, aanvallers voor een andere exploit kiezen. "In andere woorden, het hebben van een sterk incident respons team, naast het engineering proces, is net zo belangrijk", laat Halbheer weten.
Greetingz,
Jacco
Open source is misschien makkelijker te hacken, maar de lekken worden ook veel sneller gefixed.
Dit gaat weer helemaal nergens over, Microsoft heeft voor lange tijd iedereen Administrator laten zijn en dat was ook geen beveiliging vanaf het begin. Dat ze nu op de goede weg is een ander verhaal.
"Ik geloof niet dat zo'n discussie veel waarde heeft."
Volgens mij is dat de eerste keer dat MS zelf spreekt en niet de marketing afdeling. Goed zo, grote jongen!
Allereerst baseert deze 'onderzoeker' (dat vind ik al een overrated term voor zo'n prutser) zijn mening op basis van 960 installaties klanten van één leverancier. De 400.000.000 logentries zijn voornamelijk uit 2006 en de eerste weken van 2007, TOEVALLIG net de meest rustige jaren voor Microsoft ellende.
Ik zal een overzichtje proberen te maken ter verduidelijking:
2001: Sadmind, Sircamm, Code Red, Code Red II, Nimda, Klez
2002: SQL Slammer, Beast, Optix Pro
2003: SQL Slammer, Graybird, ProRat, Blaster, Welchia/Nachi, Sobig, Sobig A, Sobig B, Sobig, C, Sobig D, Sobig E, Sobig F, Sober
2004: SQL Slammer, Blaster, Welchia/Nachi/Sobig A-F, Sober
2005: Samy XSS, Ziob, Bandook, Nyxem
2006: Stration
2007:
2008: Storm Worm, Conficker, Rustock
2009: Dozor, Daprosy
Iemand die echt academisch onderzoek doet kijkt allereerst of zijn verzamelde data wel representatief is. Dat doe je niet door data van 2006 te pakken en vervolgens een CVE database van 2008 erbij pakken. Overigens is het vreemd dat deze onderzoeker de CVE database van Mitre pakt, dit omdat de verzamelde data van een bedrijf komt welke niet in de lijst van gecertificeerde Intrusion Detection Systemen staat. De fabrikant staat alleen in de lijst van intrusion monitoring, niet Intrusion Detection and Management.
Verder heeft hij geen 100% of enigzins statistisch verantwoord onderzoek gedaan naar de qualificatie van open source dan wel closed source. Van meer dan de helft van de producten kon de onderzoeker niet achterhalen of het closed of open source was. In het geval dat het niet duidelijk is lijkt het me voor de hand te liggen dat het closed source is, daar het anders duidelijk aangegeven was ivm licenties zoals bijvoorbeeld GPL. Dat is juist de bedoeling van Open Source namelijk, dat het duidelijk is dat iedereen mag spitten en verbeteren. In dit geval betekent dat dit dat het waarschijnlijk is dat de meerderheid van de applicaties (74%) Closed Source is. Dat houdt in dat 26% van de software Open Source was. Echter, in de statistieken van deze 'onderzoeker' wordt dus rekening gehouden met 50/50 verhouding ipv 3/1 verhouding. Dat is een factor 3 discrepantie. Hiermee is het onderzoek al volledig onderuit gehaald.
Wat nog erger is, is dat wanneer een lek gevonden wordt in zowel Open Source als Closed Source, het lek toegeschreven wordt aan Open Source. Wanneer bijvoorbeeld Microsoft Windows een lek heeft in de door hen geleende IP stack of een closed source pakket leentje buur gespeeld heeft met OpenSSH, dan wordt het lek in de Closed Source applicatie toegeschreven aan Open Source.
Lekker makkelijk want er is altijd wel een closed source pakket te vinden wat al dan niet illegaal code leent van Open Source (ze kunnen er immers bij, en dankzij closed source is het lastig te achterhalen of er inderdaad illegaal verkregen Open Source code in verwerkt zit) dus zijn veel lekken toe te schrijven aan Open Source.
De onderzoeker (kuch) geeft aan dat beveiligingslekken in opensource vaker en sneller worden aangevallen. Echter geeft hij hier geen enkel bewijs voor. Academisch onverantwoord om stellingname te doen zonder deze stellingen ook maar enigzins te onderbouwen met feiten (correct dan wel onjuist). Feiten zijn zaken die we zelf zouden kunnen controlleren en dat blijkt iets te zijn waar deze onderzoeker geen zin in heeft.
Verder heeft de onderzoeker gebruikt gemaakt van log entry telling. Wanneer één aanvaller één doel aanvalt en hij herhaalt de aanval vier maal, zijn het vier aanvallen. Ter vergelijk, wanneer je een PING doet onder Windows (DOS scherm) dan zal gemiddeld er vier PINGs uitgevoerd worden en zullen er acht logentries gevuld worden. Het is echter één aanval, niet acht.
Onderzoeker Ransbotham beweert ook dat wanneer er een patch uit komt dat de aanvallers een andere exploit kiezen. Ook dat is niet juist want op dit moment kun je nog steeds in grote aantallen Slammer, Blaster en Conficker tegenkomen terwijl daar al lange tijd patches voor zijn uitgebracht.
Het lijkt er dan ook sterk op dat dit onderzoek samen met twee andere 'onderzoeken' zijn gesponsord door Microsoft. Wat ook een beetje jammer is dat MIT zich hiervoor laat strikken.
Schijnbaar zitten Amerikaanse universiteiten en colleges ook om geld verlegen in deze crisis tijden.
Het grootste probleem wat ik met dit onderzoek heb is overigens hetvolgende:
Het onderzoek stelt dat vulnerabilities en aanvallen worden vergeleken. Dat is niet juist. Het onderzoek vergelijkt (open source) vulnerability signatures met aanvallen. Daar bij Open Source het evident is waar een lek zit en hoe deze werkt is het voor antivirus/intrusion detection systemen fabrikanten een eitje om hiervoor een signature te maken. Hierdoor zijn voor Open Source ook minder false positives in IDP/IDS wat resulteert in betere hits. False Positives zijn slecht voor IDP/IDS systemen en closed source maakt het moeilijk om goede signatures te bouwen. Deze signatures verklappen op hun beurt ook weer hoe de exploit zou kunnen werken. Dus eigenlijk veroorzaken IDS/IDP fabrikanten zelf een eventuele verhoging van snelheid en aantal exploits.
Al met al kan ik maar één kwalificatie geven aan dit onderzoek en dat is Fear, Uncertainty and Doubt aka FUD.
Ik vraag me af wanneer er nieuwe Halloween Documents naar boven komen. Waarschijnlijk moeten we toch 31 october wachten.
ASL
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?