Apple herintroduceerde Safari-zeroday door refactoren van code in 2016
Begin dit jaar kwam Apple met een beveiligingsupdate voor een actief aangevallen zerodaylek in Safari voor iOS en macOS. Het beveiligingslek, aangeduid als CVE-2022-22620, was in 2013 al een keer door Apple verholpen, maar in 2016 geherintroduceerd bij het refactoren van de code. Dat laat Google op basis van een analyse weten.
Het beveiligingslek was aanwezig in WebKit, de door Apple ontwikkelde browser-engine. Alle browsers op iOS en iPadOS zijn verplicht om van WebKit gebruik te maken. Door het verwerken van malafide webcontent ontstaat er een "use after free" kwetsbaarheid en is het uitvoeren van willekeurige code op het systeem mogelijk. Hiervoor is geen interactie van de gebruiker vereist, behalve het bezoeken van bijvoorbeeld een compromitteerde website. Dit wordt ook wel een drive-by download genoemd.
Volgens Google komt het vaak voor dat softwareontwikkelaars kwetsbaarheden niet volledig patchen, waardoor aanvallers op een iets andere manier misbruik van een beveiligingslek kunnen maken. In dit geval kwam Apple begin 2013 met een patch voor de kwetsbaarheid. Die was zo grondig dat alle mogelijke paden voor misbruik werden verholpen. In 2016 besloot Apple de betreffende code te refactoren. Dit is het opschonen en updaten van code.
Hierbij werd de kwetsbaarheid opnieuw geïntroduceerd en bleef tot begin van dit jaar onopgemerkt, toen aanvallers er actief misbruik van maakten en Apple een update uitrolde. Hoelang aanvallers misbruik van het WebKit-lek hebben gemaakt is onbekend. "Maar we weten dat de kwetsbaarheid opnieuw vijf jaar lang heeft bestaan: van december 2016 tot januari 2022", zegt Maddie Stone van Google Project Zero.
Ze merkt op dat er geen eenvoudig antwoord is voor wat Apple anders had kunnen doen. De initiële bug werd namelijk grondig verholpen. Volgens Stone is het probleem niet uniek voor Safari. "We hebben actief aangevallen zerodaylekken gezien die varianten van eerder onthulde kwetsbaarheden in Chromium, Windows, Pixel en iOS waren. Het is een goede reminder dat we als verdedigers alert moeten blijven bij het reviewen en auditen van code en patches."
Geef een project een obscure naam en security mensen krijgen een fijn gevoel in hun broekje.
Het goed repareren van een bug begint met het schrijven van een unit test die bewijst dat de bug niet aanwezig is.
Toegepast op de nog niet gerepareerde software faalt deze test.
Daarna verhelp je de bug.
Tenslotte gebruik je de unit test om te bewijzen dat de bug verholpen is.
De nieuwe unit test hou je (voor altijd) in je test suite. Mocht de bug bij een latere update per ongelijk terugkeren, dan zal deze unit test 'm detecteren.
Geef een project een obscure naam en security mensen krijgen een fijn gevoel in hun broekje.
Het is gewoon een naam met een getal… ik denk dat dat fijne gevoel in je broekje gelimiteerd is tot jou broekje. Ik voel namelijk niks bij zero.
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.
