CVE-2009-2692 : Linux Kernel 2.x sock_sendpage() Local Ring0 Root Exploit

Tavis Ormandy (ancien responsable de la sécurité chez Gentoo) et Julien Tinnes de “Google Security Team” ont découvert une vulnérabilité locale importante dans le Kernel Linux, toute les versions Kernel Linux 2.4.4 à 2.4.37.4, et 2.6.0 à 2.6.30.4 sont vulnérables.

Un utilisateur local malveillant pourrait par le biais de cette vulnérabilité prendre un contrôle total du système. Quand on voit le nombre de vulnérabilité RFI qui traînent sur Internet, l’on peut imaginer que cette vulnérabilité va faire très très mal dans les jours et semaines qui viennent.

Ce qui est encore plus inquiétant c’est que cette vulnérabilité est présente dans le Kernel Linux depuis près de 8 ans !!! Est-ce que cette vulnérabilité n’a pas été exploitée auparavant, on peut douter que non … si les membres de l’équipe Google Security Team l’ont découverte, d’autres l’ont sûrement aussi découverte.

Une mise à jour a été mise à disposition, afin de combler cette vulnérabilité, par les dévelopeurs du Kernel Linux.

Un exploit est disponible sur Milw0rm depuis le 14 Août, la vidéo ci-dessous et le test que j’ai effectué démontre qu’il fonctionne à merveille (sic.) !

[youtube -3qu2WCLF5Y]

Les solutions Cloud ne sont pas “compliant” avec PCI

Malgré toutes les bonnes volontés, il ne se passe pas un jour sans que l’on retrouve des données bancaires sur Internet, soit par le biais d’un piratage, soit tous simplement par le biais d’un “Google Hacking“. Ces données bancaires dérobées et exploitées par des pirates informatiques mettent à mal le commerce électronique et la confiance des internautes dans les paiements en ligne.

Vous connaissez sûrement tous le standard PCI qui promeut la protection des données de paiement tels que vos données personnelles, vos identifiants et surtout votre numéro de carte bancaire, sa date d’expiration et son cryptogramme visuel. Le forum PCI Security Standards Council a élaboré desstandards de sécurité qui nécessitent des pré-requis pour la gestion quotidienne de la sécurité, autant en terme technique, qu’en terme de règles de sécurité et de processus.

De plus en plus d’entreprises, ont alors décidées de rejoindre le forum PCI et de se faire certifier compliant PCI-DSS, afin de redorer leurs images et des redonner de la confiance aux internautes envers les paiements en ligne.

Malheureusement, ces mêmes entreprises, dans le même temps, toujours en recherche d’économie d’échelle, se sont montrées très intéressées par les solutions Cloud, tels que les SaaS (Cloud Application), PaaS (Cloud Software Environment) et IaaS (Cloud Infrastructure). De nombreux chercheurs en sécurité informatique, ainsi que de nombreux professionnels de la sécurité doutaient déjà à l’époque de la possibilité d’affirmer qu’une solution Cloud soit complètement sécurisé et compliant avec de nombreux standards.

Amazon avec ses solutions Cloud EC2 et S3 (IaaS), a malheureusement confirmé, en toute honnêteté, qu’il serait impossible pour une entreprise utilisant ses solutions d’obtenir le niveau 1 du standard PCI-DSS si les données bancaires seraient stockées sur ses solutions.

De nombreux autres fournisseurs de solutions Cloud vont malheureusement devoir s’aligner sur les paroles de Amazon afin que les entreprises intéressées par leurs solutions connaissent les risques encourus en terme de sécurité et de normalisations.

ICANN mets un frein à la pratique du Domain Tasting

Vous avez sûrement tous déjà navigué sur des sites dédiés à la publicité jouant avec les pratiques du “Typosquatting” ou encore du “Domain Hijacking“. Une autre technique utilisée par les “domainers” (oups faut pas dire ce mots, ils aiment pas cela) se nomme le “Domain Tasting“, qui consiste à acheter un nom de domaine et tester sa popularité et sa rentabilité sur une période de 5 jours. Si le nom de domaine n’est pas populaire, donc pas rentable, au bout de 5 jours, le “domainers” pourra alors invoquer le principe “Add Grace Period” auprès de son registrar pour se faire rembourser le coût total du nom de domaine.

Ce principe de “Add Grace Period” a été mis en place par l’ICANN afin de donner une chance à l’acheteur du nom de domaine pour pouvoir se le faire rembourser en cas d’erreur dans l’orthographe du domaine.

Malheureusement, de nombreuses personnes (“domainers”) mal intentionnées ont exploités cette faille, permettant d’avoir un nom de domaine gratuit pendant 5 jours. Cette “période de grâce” leurs permettait d’enregistrer des noms de domaine en masse, de tester leurs popularités et leurs rentabilités publicitaire. Si un nom de domaine enregistré réussissait à rembourser son coût d’achat avant la période de 5 jours, celui-ci était conservé par le domainer, tous les autres domaines moins rentables étaient tous simplement rendus au “registrar” en invoquant le principe de “Add Grace Period”.

Le 17 Décembre 2008, l’ICANN ne supportant plus cette situation, le principe de “Add Grace Period” a été revu, demandant depuis au “registrar” de payer 6,75$ par nom de domaine qui ne serait pas conservé. Le “registrar” bien sûr a répercuter ce coût sur les “domainers” et tous naturellement la technique de “Domain Tasting” c’est réduite de 99.7% !!! Comme quoi l’argent, c’est le nerf de la guerre

Hijacking Safari 4 Top Sites with Phish Bombs

Inferno de SecureThoughts.com a rapporté une vulnérabilité dans le navigateur Internet Safari 4 de Apple. Cette vulnérabilité assez particulière et unique exploite les fonctionnalitées “Top Sites” et “Cover Flow” introduitent dans Safari 4.

La fonctionnalité “Top Sites” fournit une vue graphique des sites web favoris de l’utilisateur final, permettant ainsi d’accéder rapidement aux sites que l’on accède le plus souvent, comme par exemple eBay, Amazon, Facebook, Gmail, etc.

La vulnérabilité consiste à placer des sites malveillant, par exemple des sites de phishing, dans “Top Sites”, et cette vulnérabilité est exploitable tous simplement en surfant sur Internet, et en cliquant sur un lien malveillant. Un code Javascript basic sera alors exécuté dans une petite fenêtre afin de simuler des navigations répétées sur ces sites web malveillant afin que ceux-ci apparaissent comme populaires. La fenêtre en cause est totalement invisible par le biais de la fonction javascript “window.blur” et l’utilisateur final n’a aucune connaissance de l’attaque en cours.

L’exploit est vraiment basic et il est vraiment regrettable que Apple ne prenne pas la peine d’étudier et de tester au préalable toutes les éventuelles vulnérabilités de ces nouvelles fonctionnalités ou produits. Apple, stp, ne devient pas comme Adobe sad.gif

[youtube iQuUTz1XAZw]