Fermer le menu

SSL

Toute l'actualité sur SSL

Les apps touchées par la faille SSL

| 24/02/2014 | 10:30 |  

Comme nous l’expliquions dans notre papier consacré à la faille SSL, celle-ci ne concerne pas uniquement Mail et Safari. Elle touche de nombreuses applications.

Un chercheur en sécurité, Ashkan Soltani, s’est amusé à lister quelques applications répandues qui ont recours à SSL. Dans les applications livrées avec le système, on trouve Calendrier, FaceTime, iBooks, Keynote, Twitter, iMessage, le système de push ou encore le VPN du système. Ce rapport est très très loin d’être exhaustif, mais donne une idée du grand nombre d’angles d’attaque qu’ont les hackers pour exploiter cette faille.

Notez que certaines apps comme iMessage et FaceTime possèdent des dispositifs de sécurité supplémentaires qui rendent éventuellement cette faille un peu moins dangereuse. Même le mécanisme de mise à jour intégré au système est concerné, la connexion avec les serveurs d’Apple étant chiffrée.

SSL : une faille majeure dans iOS et OS X

| 22/02/2014 | 22:45 |  

La faille de sécurité relative à la vérification de la connexion SSL est sans doute l’une des plus graves dans l’histoire d’Apple. Avant d’entrer dans les détails, nous ne pouvons que vous encourager à faire de toute urgence la mise à jour de tous vos terminaux iOS. Au passage, elle n'est pas problématique pour le jailbreak.

La sortie des mises à jour de sécurité pour iOS 6.1.x et 7.0.x fait l’objet d’une belle polémique depuis hier. En proposant ce correctif, Apple a officialisé cette faille en quelque sorte et rendu publique son existence. Comment a-t-elle pu faire cela tout en laissant OS X dans le noir et dans une moindre mesure ses testeurs sous 7.1 ? Précisons d’emblée que celle-ci touche « seulement » les personnes sous Mavericks.

Pourquoi cette faille est dangereuse

Revenons-en à la faille : Transport Layer Security (TLS), et son prédécesseur Secure Sockets Layer (SSL) sont des protocoles permettant de sécuriser les échanges sur Internet. Le problème dans l’implémentation d’Apple, c’est que le système de vérification de l’authentification SSL est en proie à un gros bogue d’une étonnante maladresse (on reviendra sur ce point un peu plus tard).

Qu’est-ce que cela signifie concrètement ? Une personne malintentionnée peut exploiter ce bogue très simplement. Elle peut initier une connexion soi-disant sécurisée en disant « je suis Google.com, regarde mon certificat ». Normalement, grâce à un système de clé, le système qui initie la connexion est en mesure de vérifier l’authenticité de ce certificat. Malheureusement, le système de vérification n’étant pas du tout opérationnel, la personne malintentionnée peut sans la moindre difficulté se faire passer pour quelqu’un d’autre.

Cette faille peut être très facilement exploitée par exemple avec un hot-spot Wi-Fi. En se débrouillant bien, son propriétaire peut par exemple déchiffrer vos échanges de données. Ce n'est qu'un exemple (le plus parlant), mais les angles d'attaque sont très nombreux.

Une erreur de programmation à peine croyable

Ce qui est hallucinant dans cette affaire, c’est que cette faille est particulièrement grossière. Spécialiste de ce genre de questions, Adam Langley a publié le code fautif en question, celui-ci étant open source. Il est relatif à SecureTransport, l’implémentation d’Apple donc pour SSL et TLS.

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;

}

Si vous développez un peu, même sans tout comprendre, vous comprendrez aisément le problème. Ces quelques lignes de code sont donc censées vérifier l’authenticité de la connexion SSL. Le problème se situe dans la vérification de la seconde condition if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)

Il y a, à la suite de cette condition, deux goto fail. Si le premier obéit à une condition, le second s’exécute directement. Résultat, tout programme faisant appel à cette routine, pour vérifier l’authenticité d’une connexion SSL, obtient une réponse « bidon ».

L’erreur est tellement grossière que certains spécialistes en sécurité se demandent s’il ne s’agit pas d’un acte malveillant. À l’heure où nous écrivons ces lignes, personne ne sait si cette faille a été exploitée par un hacker malintentionné ou par des organismes de type NSA. Dans sa note de sécurité parue hier, Apple ne crédite personne.

Que faire pour se prémunir de cette faille ?

Ceux qui aiment bidouiller peuvent toujours installer ce correctif réalisé par l’expert en sécurité Stefan Esser. Installez-le uniquement si vous savez ce que vous faites. Et en sachant que celui-ci provoque des incompatibilités avec certains programmes.

Sur OS X, cette faille touche seulement 10.9 et ses « descendants ». Si cette faille est grave, il ne convient pas de céder à la panique pour autant. On peut imaginer qu’Apple proposera un correctif au plus tard en début de semaine prochaine.

D’ici là, pour minimiser les risques, passez-vous de Safari et de Mail. Chrome et Firefox, par exemple, ne sont apparemment pas concernés par ce problème, ils utilisent leur propre implémentation de SSL. Le souci c’est que ce problème n’est pas limité à Safari et Mail, un grand nombre de programmes font appel à des connexions sécurisées. Une page de test a d’ailleurs été mise au point pour savoir si votre navigateur est concerné ou non par cette faille. Si votre configuration est sécurisée, vous devriez obtenir un message d’erreur. Sinon, vous obtiendrez un court message vous confirmant que votre navigateur est bel et bien vulnérable. Enfin, évitez d’utiliser des connexions Internet qui ne sont pas dignes de confiance comme les hot-spot Wi-Fi.

OS X est aussi concerné par la faille SSL bouchée dans iOS

| 22/02/2014 | 10:00 |  

La faille de sécurité bouchée hier par Apple dans iOS est également présente dans OS X 10.9.0 et 10.9.1, ont observé des chercheurs interrogés par Reuters. Ils ont pour cela analysé le patch et remarqué qu'OS X présentait la même vulnérabilité.

Apple a distribué trois mises à jour hier pour iOS 6, 7 et le firmware des Apple TV. Il s'agissait de combler une faille importante dans la manière dont est vérifiée l'authenticité d'une connexion SSL. Jusque-là, le contenu d'une connexion supposément sécurisée à un site ou un service, via un réseau Wi-Fi par exemple, pouvait être en réalité observée par un tiers. Des étapes nécessaires à la validation pleine et entière de la sécurité de cette connexion n'étaient pas réalisées.

Une mise à jour est attendue pour OS X, probablement au travers de la version 10.9.2 actuellement en bêta, à moins qu'un patch séparé soit distribué pour tenir compte aussi des plus anciennes versions du système. Quoi qu'il en soit, c'est probablement l’une des plus grosses failles dans l’histoire d’Apple. Ce n’est pas pour rien qu’une fois n’est pas coutume, Apple a daigné proposer un patch pour la précédente version d’iOS. Alors ne tardez pas à faire la mise à jour !

OS X Lion et le problème des certificats TLS/SSL

| 01/09/2011 | 14:44 |  

skitchedLes certificats TLS/SSL sont indispensables à la communication sécurisée sur Internet : ils sont le garant de la confiance que vous pouvez accorder au site sur lequel vous allez vous connecter. Pierre angulaire de la sécurité sur Internet, ils sont aujourd'hui une cible de choix pour les pirates : obtenez-en un, et vous pourrez montrer patte blanche avec les plus mauvaises intentions du monde.

En mars dernier, un hacker iranien avait réussi à obtenir du fournisseur de certificats Comodo neuf certificats pour des domaines appartenant à Microsoft, Google, Mozilla ou Skype. Un hacker qui aurait réussi à détourner le système DNS d'un utilisateur dont l'OS ou le navigateur considère que le certificat contrefait est valide pourrait mener l'utilisateur a un site malicieux qui aurait non seulement l'apparence d'un site connu, mais se ferait techniquement passer pour lui (URL d'origine affichée dans le navigateur, connexion sécurisée, etc.).

Ce problème s'est à nouveau posé ces derniers jours : des hackers, à nouveau iraniens semble-t-il, ont réussi à obtenir des certificats valides sur l'ensemble des services de Google chez Diginotar. De quoi construire par exemple un faux Gmail se faisant complètement passer pour le vrai, et ainsi intercepter les communications des opposants au régime. Un véritable effet domino qui pose la question de la faiblesse — relative — du système TSL/SSL centralisé et basé uniquement sur la confiance envers un tiers : Diginotar (par le biais de sa maison-mère Vasco) et Comodo ont tout deux délégation de Verisign pour fournir des certificats numériques.

Google a rapidement réagi en révoquant 247 certificats de Diginotar. Chrome est capable de détecter le certificat usurpé, Mozilla explique comment le supprimer dans Firefox, et Microsoft a mis à jour Internet Explorer. Apple, elle, n'a pas réagi : il serait certes plutôt compliqué de mettre en œuvre une attaque man-in-the-middle avec DNS poisoning utilisant ces certificats sur OS X, mais la firme de Cupertino montre à nouveau sa réactivité très moyenne sur ces sujets.

DigiNotar%20Root%20CA

On peut révoquer le certificat SSL Diginotar dans le Trousseau d'accès : ouvrez le Trousseau d'accès, trouvez le certificat Diginotar, ouvrez-le, et choisissez Se fier > Lors de l'utilisation de ce certificat > Ne jamais approuver. Ce n'est cependant pas suffisant pour assurer la sécurité d'OS X : si un site utilise un certificat Extended Validation SSL Diginotar usurpé, OS X utilise une autre méthode de vérification, qui peut ignorer la révocation du « simple » certificat SSL.

Un problème qui n'a que peu d'applications pratiques, mais qu'Apple devra corriger. Et vite, tant qu'à faire.