Daniël Hruska Een paar dagen geleden bracht Apple de honderdste uit iOS 7.0.6-update, over de vrijgave waarvan wij u op de hoogte hebben gesteld. Velen zullen misschien verbaasd zijn geweest dat de update ook voor oudere iOS 6 (versie 6.1.6) en Apple TV (versie 6.0.2) is uitgebracht. Dit is een beveiligingspatch, dus Apple kon het zich niet veroorloven om slechts een deel van zijn apparaten te updaten. Bovendien treft dit probleem ook OS X. Volgens Apple-woordvoerder Trudy Muller komt er zo snel mogelijk een OS X-update uit.
Waarom is er zoveel hype rond deze update? Door een fout in de systeemcode kan serververificatie worden omzeild bij veilige verzending op de relationele laag van het ISO/OSI-referentiemodel. De fout is met name een slechte SSL-implementatie in het gedeelte waar de verificatie van servercertificaten plaatsvindt. Voordat ik inga op verdere uitleg, geef ik er de voorkeur aan om de basisconcepten te beschrijven.
SSL (Secure Socket Layer) is een protocol dat wordt gebruikt voor beveiligde communicatie. Het realiseert veiligheid door middel van encryptie en authenticatie van communicerende partijen. Authenticatie is de verificatie van de gepresenteerde identiteit. In het echt zeg je bijvoorbeeld je naam (identiteit) en laat je je identiteitsbewijs zien zodat de ander deze kan verifiëren (authenticeren). Authenticatie wordt vervolgens opgesplitst in verificatie, wat slechts een voorbeeld is met een nationale identiteitskaart, oftewel identificatie, waarbij de persoon in kwestie uw identiteit kan vaststellen zonder dat u deze vooraf aan hem hoeft te presenteren.
Nu wil ik kort ingaan op het servercertificaat. In het echte leven kan uw certificaat bijvoorbeeld een identiteitskaart zijn. Alles is gebaseerd op asymmetrische cryptografie, waarbij elk individu twee sleutels bezit: privé en openbaar. Het hele mooie ligt in het feit dat het bericht kan worden gecodeerd met de publieke sleutel en kan worden gedecodeerd met de privésleutel. Dit betekent dat alleen de eigenaar van de privésleutel het bericht kan ontsleutelen. Tegelijkertijd hoeft u zich geen zorgen te maken over de overdracht van de geheime sleutel aan beide communicerende partijen. Het certificaat is dan de publieke sleutel van het onderwerp, aangevuld met de bijbehorende informatie en ondertekend door de certificeringsinstantie. In Tsjechië is een van de certificeringsinstanties bijvoorbeeld Česká Pošta. Dankzij het certificaat kan de iPhone verifiëren dat hij echt communiceert met de gegeven server.
SSL maakt bij het tot stand brengen van een verbinding gebruik van asymmetrische encryptie, de zogenaamde SSL-handdruk. In dit stadium verifieert uw iPhone dat hij communiceert met de gegeven server, en tegelijkertijd wordt met behulp van asymmetrische codering een symmetrische sleutel tot stand gebracht, die voor alle daaropvolgende communicatie zal worden gebruikt. Symmetrische codering is sneller. Zoals reeds geschreven, treedt de fout al op tijdens de serververificatie. Laten we eens kijken naar de code die deze systeemkwetsbaarheid veroorzaakt.
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa,
SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen)
{
OSStatus err;
…
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
…
fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
}
In de tweede voorwaarde if Hieronder ziet u twee opdrachten ga mislukken;. En dat is het struikelblok. Deze code zorgt er vervolgens voor dat de tweede opdracht wordt uitgevoerd in de fase waarin het certificaat moet worden geverifieerd ga mislukken;. Hierdoor wordt de derde voorwaarde overgeslagen if en er zal helemaal geen serververificatie plaatsvinden.
De implicaties zijn dat iedereen met kennis van deze kwetsbaarheid uw iPhone een nepcertificaat kan aanbieden. Jij of je iPhone, dan denk je dat je versleuteld communiceert, terwijl er een aanvaller tussen jou en de server zit. Zo’n aanval wordt genoemd man-in-the-middle-aanval, wat zich grofweg vertaalt in het Tsjechisch als man-in-the-middle-aanval of mens onder. Een aanval waarbij gebruik wordt gemaakt van deze specifieke fout in OS X en iOS kan alleen worden uitgevoerd als de aanvaller en het slachtoffer zich op hetzelfde netwerk bevinden. Daarom is het beter om openbare Wi-Fi-netwerken te vermijden als u uw iOS niet heeft bijgewerkt. Mac-gebruikers moeten nog steeds voorzichtig zijn met de netwerken waarmee ze verbinding maken en welke sites ze op die netwerken bezoeken.
Het is ongelooflijk hoe zo’n fatale fout in de definitieve versies van OS X en iOS terecht heeft kunnen komen. Het kan een inconsistente test van slecht geschreven code zijn geweest. Dit zou betekenen dat zowel de programmeur als de testers fouten zouden maken. Dit lijkt misschien onwaarschijnlijk voor Apple, en daarom komen er speculaties naar boven dat deze bug eigenlijk een zogenaamde achterdeur is. achterdeur. Ze zeggen niet voor niets dat de beste achterdeurtjes op subtiele fouten lijken. Dit zijn echter slechts onbevestigde theorieën, dus we gaan ervan uit dat iemand eenvoudigweg een fout heeft gemaakt.
Als u niet zeker weet of uw systeem of browser immuun is voor deze bug, bezoek dan de pagina gotofail.com. Zoals je in de onderstaande afbeeldingen kunt zien, bevat Safari 7.0.1 in OS X Mavericks 10.9.1 een bug, terwijl in Safari in iOS 7.0.6 alles in orde is.
Aanval DOOR…. Ik heb in lange tijd niet meer zo goed en hartelijk gelachen!
Hoe het ook zij - ik begrijp het persoonlijk als een bericht van APPLE aan alle gebruikers - of het op de een of andere manier was (en ik denk niet dat meer dan de genoemde twee mogelijkheden voor het optreden van deze fout reëel zijn), beide zijn een simpele aanfluiting van gewone eigenaren van APPLE-dingen!
Godzijdank had je gelijk.
Ik zou geloven dat dit een echte vergissing is. Ik kan me voorstellen dat het is ontstaan bij het samenvoegen van twee takken in het versiebeheersysteem als één tak een regel langer was. Hoe dan ook, dit is gewoon weer een geval dat bevestigt dat programmeurs gedwongen worden om zelfs maar één regel in te sluiten als body in een blok zinvol is.
Bedankt voor de gedetailleerde beschrijving!
Sorry dat ik buiten de discussie schrijf, maar nu las ik op idnes dat de zogenaamde grotere iPhone iPhablet zou moeten heten :-D Ik was hem bijna kwijt.. :-D Groeten aan alle Apple-liefhebbers
….. Wauw, creativiteit verdwijnt niet langzaam ….. misschien is het maar een eend!
Hallo, heb je problemen met de batterijduur na de update? Ik heb na veel klachten over de iP5 een nieuwe gekregen, dus ik heb een nieuwe batterij die bijna twee dagen meeging. Na de update stierf mijn telefoon binnen 8 uur en ik gebruik hem niet veel.
Persoonlijk heb ik geen enkel probleem met de zaklamp geregistreerd. Ja, in het verleden wel, en een back-up en een schone herinstallatie van iOS heeft altijd geholpen. Hopelijk zal het je helpen.
Dat heb ik vandaag gedaan en helaas geen verandering :-/