Microsoft verklaart missen van Internet Explorer lek
Microsoft hanteert al enkele jaren de Security Development Lifecycle, een methode die het aantal beveiligingslekken in software moet verminderen, maar hoe kon het dan dat de softwaregigant het recent gepatchte Internet Explorer lek miste? Daar geeft het zelf antwoord op. Er zijn namelijk verschillende redenen waarom deze bug aan de aandacht wist te ontsnappen. De eerste is de aard van het lek, die maakt het lastig te vinden. Microsoft bekijkt de code van haar software, maar via de zogeheten "code review" kom je dit soort kwetsbaarheden niet tegen.
Daarnaast zijn de programmeurs nooit over dit soort problemen voorgelicht, iets wat nu ook gaat veranderen. Verder bleken de statische analyse tools de code ook niet te begrijpen en sloegen daarom geen alarm. Microsoft beveiligingsexpert Michael Howard geeft toe dat men de kwetsbaarheid via fuzz testing, het bestoken van progamma's met willekeurige data, had kunnen vinden, maar dat er geen testscenario voor deze code bestond.
Verdediging omzeild
Windows Vista en Windows Server 2008 gebruiken verschillende technieken om misbruik van beveiligingslekken tegen te gaan, zoals ASLR en No eXecute (NX), die moeten voorkomen dat een aanvaller code op het systeem kan uitvoeren. In het geval van dit lek was het voor de aanvallers mogelijk om een component aan te roepen dat niet via ASLR en NX beveiligd was, waardoor de verdediging omzeild werd.
Ontdekking
Microsoft heeft nog geen idee hoe het lek is gevonden, hoewel het rekening houdt dat de aanvallers het per ongeluk ontdekten of fuzzing gebruikten. "De ontdekker had zoveel tijd uit kunnen trekken om dit ene lek te vinden. Dit is een van de dingen die security zo moeilijk maakt, het heeft een hoog asymmetrisch probleem: software ontwikkelaars moeten de code in alle gevallen en in een korte tijd perfect krijgen, terwijl aanvallers zoveel tijd als mogelijk uit kunnen trekken. Dit is geen excuus, maar een feit", aldus Howard.
Volgens hem laat het lek zien dat je code nooit 100% in orde krijgt, waardoor meerlaagse verdediging zo belangrijk is. "Als er een andere les is die we geleerd hebben, dan is het wel dat de software industrie harder moet werken om applicaties de door Windows geboden beveiliging te laten gebruiken."
Maar het niet gebruiken van "fuzz testing" terwijl je weet dat de aanvallers dit wel doen, is toch wel een beetje raar verhaal. Er zijn voldoende boeken op de markt die je vertellen hoe je als security expert moet denken als aanvaller om achter de echte problemen te komen.
Maar goed, als men dit nu onderkend, is er toch weer iets gewonnen...
Maar het niet gebruiken van "fuzz testing" terwijl je weet dat de aanvallers dit wel doen, is toch wel een beetje raar verhaal. Er zijn voldoende boeken op de markt die je vertellen hoe je als security expert moet denken als aanvaller om achter de echte problemen te komen.
Maar goed, als men dit nu onderkend, is er toch weer iets gewonnen...
True ik sluit me hier helemaal bij aan
Ik vind het alleen ook wel slordig m.b.t. dit gedeelte:
"Daarnaast zijn de programmeurs nooit over dit soort problemen voorgelicht, iets wat nu ook gaat veranderen."
Ik neem aan dat ontwikkelaars met een research team werken welke deze toelichting moeten geven.
Zeker in een global bedrijf als MS, en trust me ondanks dat ik verschillende OS'en gebruik heb ik echt wel een hoge pet op van MS.
Maar ik kon me bij dit gedeelte niet helemaal vinden, maar zoals vermeld gelukkig komt hier verandering in.
En toch blijf ik erbij ... Microsoft, Linux, Novell (reeds Linux), en alle andere OS'en, let's share the knowledge and make 1 OS with the best of all worlds
Maar het niet gebruiken van "fuzz testing" terwijl je weet dat de aanvallers dit wel doen, is toch wel een beetje raar verhaal. Er zijn voldoende boeken op de markt die je vertellen hoe je als security expert moet denken als aanvaller om achter de echte problemen te komen.
Maar goed, als men dit nu onderkend, is er toch weer iets gewonnen...
Je leest het niet goed.
Er staat:
Zelfs als je alle boeken die er over fuzzing zijn geschreven hebt gelezen en begrijpt, dan nog had je dit gat niet kunnen vinden als je niet zelf een 'template' had geschreven om deze specifieke html code te generen.
Geloof me, fuzzing met tools die op het internet te vinden zijn is leuk, maar ook daar had je niets mee gevonden zonder zelf diep in de door IE ondersteunde parsing opties te duiken.
Ik heb zelf meerdere fuzzers geschreven die problemen met IE hebben gevonden, en de gemiddelde reactie die ik terug kreeg van MS (viavia) was: WTF? Wegens de complexiteit van de gevonden gaten, puur omdat ik net een iets andere insteek heb dan MS en met mij anderen die ook weer andere dingen bedenken.
Protocol fuzzing is bijvoorbeeld relatief simpel, aangezien van de meeste protocols vrij makkelijk een template valt te maken.
Een van de problemen met browser fuzzing is de gigantische hoeveelheid mogelijkheden die je hebt om iets door een browser te laten verwerken.
En dan heb ik het alleen nog maar over html/xml/vml parsing, en nog niet de mogelijkheden die scripting je geeft om met heel veel object allemaal rare dingen te doen.
Al met al: MS fuzzt wel degelijk, maar ik vind het helemaal niet vreemd dat ze dit gat niet hadden gevonden.
Maar het niet gebruiken van "fuzz testing" terwijl je weet dat de aanvallers dit wel doen, is toch wel een beetje raar verhaal. Er zijn voldoende boeken op de markt die je vertellen hoe je als security expert moet denken als aanvaller om achter de echte problemen te komen.
Maar goed, als men dit nu onderkend, is er toch weer iets gewonnen...
True ik sluit me hier helemaal bij aan
Ik vind het alleen ook wel slordig m.b.t. dit gedeelte:
"Daarnaast zijn de programmeurs nooit over dit soort problemen voorgelicht, iets wat nu ook gaat veranderen."
Ik neem aan dat ontwikkelaars met een research team werken welke deze toelichting moeten geven.
Zeker in een global bedrijf als MS, en trust me ondanks dat ik verschillende OS'en gebruik heb ik echt wel een hoge pet op van MS.
Maar ik kon me bij dit gedeelte niet helemaal vinden, maar zoals vermeld gelukkig komt hier verandering in.
En toch blijf ik erbij ... Microsoft, Linux, Novell (reeds Linux), en alle andere OS'en, let's share the knowledge and make 1 OS with the best of all worlds
De eerste stelling is juist maar nietszeggend. De ontwikkelaar heeft na de ontwikkeling ook nog tijd om door te gaan met het zoeken naar exploits, net zo goed als de aanvaller de dat heeft.
De tweede stelling, dat het geen excuus is, is onjuist. Natuurlijk is het excuus en iedereen met algemeen verstand (en de wetten van logica) kan zien dat het geen geldig excuus is.
Typisch voorbeeld van publieksmanipulatie (spin doctoring).
"Ja, mooi, dan hoeven ze nog maar 1 kraak te maken om iedereen te kunnen treffen."
Is dat momenteel zoveel anders dan? Met het marktaandeel van Microsoft van rond de 90% weet men (theoretisch) ook een zeer groot deel van de gebruikers te treffen. Internet Explorer, die deze keer het haasje is, heeft rond de 70% marktaandeel. Das ook een behoorlijk deel van de gebruikers.
@Anoniem 16.12 Ik wil daar nog 'Damage Control' aan toevoegen.
...en da's best wel een lastige, niet?
Laat nu het merendeel van de OS'en juist de code met elkaar delen. Er zijn slechts een paar uitzonderingen.
Jammer dat M$ het over de review van de code heeft en wat daar allemaal mis is gegeaan. Maaruhhh terug naar af: Ze schrijven die code toch zelf ? Of is het allemaal jatwerk dat ze een beetje reviewen ?
Krijgen we nog te horen wat er mis was?
Zo met het idee dat we het zelf ook kunnen voorkomen?
Deze posting is gelocked. Reageren is niet meer mogelijk.
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?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
