Les premières plaintes sont arrivées via Twitter et certains sites américains auraient identifié le problème. Il proviendrait d’un compte appartenant à un certain Thuat Nguyen dans l’entreprise “mycompany” (!), ayant comme site internet: home.com (!). Ce compte est utilisé pour vendre des mangas japonais. Voici un exemple avec le manga de Conan 3. Vous remarquerez que certains commentaires fait déjà mention du problème.

L’autre chose étonnante, et qui démontre qu’il s’agit d’une attaque assez bien organisée, c’est le nombre d’applications de “mycompany” qui sont en tête des ventes:

À cout de 4.99$ par application et vu le nombre de ventes qu’il faut pour se retrouver en tête du classement un bon nombre d’utilisateurs ont du se faire pirater leur compte. À première vue cette situation ne se retrouve que sur le store américain, malgré le fait que ces applications sont également disponibles sur d’autre AppStore (notamment l’AppStore Suisse) [voir update en bas de la news].

Je pense que la réaction d’Apple ne devrait pas se faire attendre et ce développeur devrait se faire bloquer son compte. Mais il reste à savoir comment il est possible d’accéder à autant de compte iTunes et dans quelle mesure le monitoring d’Apple concernant les achats d’applications n’auraient pas du sonner l’alarme plus rapidement.

[Update] Voici quelques informations supplémentaires:

• Cette situation n’est pas limitée à l’AppStore US, il se trouve que la majorité des AppStore seraient touchés
• Le schéma de base de l’attaque serait de récupérer le mot de passe via du phishing puis d’acheter quelques applications à bas prix et une application bien plus coûteuse. Il semblerait que les montants se situent entre 100 et 160$.
• Le 4 juillet est une date feriée au US et un weekend prolongé pour cause de fête national. Cela pourrait avoir comme conséquence de ralentir la réponse d’Apple. Qui d’ailleurs n’a pas encore officiellement répondu, outre la recommendation de changer de mot de passe et de vérifier l’historique de vos achats.

Certains d’entre vous le savent déjà, mais la version 10.6 de Mac OS X inclut un logiciel de détection de malware. Plus particulièrement les logiciels utilisant LSQuarantine (ndr: LSQuarantine existe depuis Mac OS X 10.5 mais son fonctionnement a été amélioré dans Mac OS X 10.6), entre autres Entourage, Safari, Mail, Firefox, Thunderbird, iChat, sont maintenant dotés d’un détection automatique. Cette détection se fait sur la base d’un fichier nommé XProtect.plist (pour les petits curieux, ils se trouvent ici /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/). C’est justement dans ce fichier que la mention a HellRTS a été rajoutée. Par conséquent, ce fichier permet de détecter, pour les applications utilisant LSQuarantine, les malwares suivants:

• OSX.RSPlug.A
• OSX.Iservice
• OSX.HellRTS (il y a plusieurs mentions pour ce malware afin de couvrir)

Merci de bien noter que l’on parle de malware et non de virus.

Certains d’entre vous seraient tentés de dire que c’est une bonne chance qu’Apple prenne soin de mettre-à-jour ce fichier. Ce qui est vrai, mais de loin pas suffisant. D’une part la protection fournie par XProtect et LSQuarantine n’est de loin pas effective. En particulier elle ne couvre pas l’entier des applications permettant de télécharger des fichiers (toutes les applications de téléchargement de fichiers torrents, tous les logiciels de chat, etc. n’utilisent pas ce système) et ce n’est pas en mettant à jour le fichier de définition à jour un mois après la propagation du malware que cela va fournir un niveau de protection intéressant.

L’autre débat concerne le pourquoi Apple n’a pas communiqué autour de cet ajout dans le fichier XProtect. Retombant sur le mini-débat concernant la manière dont Apple gère la sécurité, nous sommes en bon droit de nous demander à quel moment Apple va sortir du bois. Allons-nous avoir droit à un “coming-out” propre en ordre (sous entendu un mea-coulpa concernant la sécurité) et Apple va continuer à ajouter des éléments concernant la sécurité en catimini? L’avenir nous le dira!

* il y a quand même un élément intéressant dans cette liste. Il s’agit de la version du tant décrié plug-in Flash. La version 10.1 de Flash, qui inclut des correctifs de sécurité très importants, n’est pas incluse dans cet update. Plus particulièrement c’est une version antérieure qui est installée…par conséquent il faut réinstaller la dernière version du plug-in…quand on vous dit qu’Apple a des soucis en terme de gestion de la sécurité…

Suite à la publication de cette faille, heise.de (désolé c’est en Allemand) a creusé plus loin la faille et a réussi à accéder lors de la synchronisation de l’iPhone avec iTunes aux différentes sauvegardes et par conséquent aux fichiers et autres informations sensibles (par exemple, numéro de téléphone, sms et même des mot de passe en clair). A première vue, il serait possible de reproduire cette faille uniquement si l’iPhone est éteint alors qu’il n’est pas verrouillé par un mot de passe. Dans ce cas, lors du démarrage du téléphone, le système va se synchroniser avec iTunes et du coup mettre à disposition l’entier de contenu. Lorsque le téléphone est éteint tout en étant verrouillé cette synchronisation ne peut pas se faire puisque le téléphone est complètement verrouillé et par conséquent va refuser toute connexion avec iTunes ou un autre logiciel.

Conclusion: un iPhone perdu ne sera pas vulnérable, puisqu’il y a de fortes chances qu’il soit verrouillé et par conséquent même un redémarrage n’y changera rien. Par contre Apple, a reconnu le problème et a promis, sans donner de date, de fournir une solution à cette faille.

D’après la croyance populaire, Mac OS X serait plus sécurisé que Windows. Malheureusement dans le milieu des professionnels de la sécurité ce n’est pas le même son de cloche. De récents articles, et en particulier Charlie  Miller, critiquent la manière dont Mac OS X intègre les différents éléments de sécurité. Loin de s’arrêter là, des critiques s’élèvent également contre la gestion de la sécurité au sein d’Apple. Plus particulièrement le manque de guideline en terme de “secure development practice”. Apple est conscient du problème et à d’ailleurs engagé l’ancienne responsable sécurité de Mozilla Corporation (et précédemment en charge de la sécurité du service pack 2 pour Windows XP). Vous vous demandez où je veux en venir? Et bien l’annonce de Google est à première vie une bonne nouvelle pour Apple. Mais en y regardant de plus près, c’est surtout un test pour la sécurité de Mac OS X. En effet ce n’est pas Mac OS X qui va arrêter des hackers (chinois ou autres d’ailleurs) et Google représente une cible de choix par conséquent cela peut augmenter “l’intérêt” des hackers pour OS X (et du coup l’iPhone OS). L’avenir nous dira si Apple arrivera à augmenter le niveau de sécurité de ses systèmes d’exploitation ainsi que des multiples applications qu’elle développe en interne.

Les “nouveautés” de Snow Leopard:

• Plus de sécurité concernant la gestion de la mémoire et sa protection
• Meilleure protection des “Trojan Horse”
• Meilleure compatibilité concernant le VPN
• Support de nouvelle technologie en terme de cryptage (notamment Elliptical Curve Cryptography)
• Le support des “Extended Validation Certificates”
• Support des “wildcards” pour les domaines dans le Trousseau d’accès
• Mise-à-jour des commandes “security” and “networksetup”
• Meilleure sécurité dans Safari 4.0

Concernant la partie plus sécurité, cette mise-à-jour inclut les correctifs suivants:

• Les correctifs de la version Java 1.6.0_17, sous entendus les vulnérabilités suivantes sont corrigées: CVE-2009-1105, CVE-2009-3555, CVE-2009-3910, CVE-2010-0082, CVE-2010-0084, CVE-2010-0085, CVE-2010-0087, CVE-2010-0088, CVE-2010-0089, CVE-2010-0090, CVE-2010-0091, CVE-2010-0092, CVE-2010-0093, CVE-2010-0094, CVE-2010-0095, CVE-2010-0837, CVE-2010-0838, CVE-2010-0840, CVE-2010-0841, CVE-2010-0842, CVE-2010-0843, CVE-2010-0844, CVE-2010-0846, CVE-2010-0847, CVE-2010-0848, CVE-2010-0849, CVE-2010-0886, CVE-2010-0887
• Correction de la vulnérabilité CVE-2010-0538. Les objets de type “mediaLibImage” peuvent avoir un problème de gestion de la mémoire (out of bounds memory access). En visitant une page web qui contient un applet Java corrompu, il se peut que l’application se termine de manière inadéquate ou que du code arbitraire s’exécute avec les privilèges de l’utilisateur actuel. A noter que cette vulnérabilité et corrigé simplement en empêchant l’utilisation de la librairie com.sun.medialib.mlib depuis un Applet. Cette vulnérabilité touche uniquement l’implémentation de Java sous Mac OS X.
• Correction de la vulnérabilité CVE-2010-0539: Il existe un problème lors de la gestion des dessins des fenêtres (windows drawing). Comme lors de la vulnérabilité précédente, en visitant une page web qui contient un applet Java corrompu, il se peut que l’application se termine de manière inadéquate ou que du code arbitraire s’exécute avec les privilèges de l’utilisateur actuel. Cette vulnérabilité touche uniquement l’implémentation de Java sous Mac OS X.

A noter qu’une partie de ces vulnérabilités sont également corrigées pour la version de Mac OS X 10.5. Vous trouverez toutes les informations à cette addresse: http://support.apple.com/kb/HT4170.

La faille profite de la mauvaise gestion des “parent windows” (e.g. par exemple les fenêtres pop-up), en conséquence une fonction pourrait utiliser un “pointer” invalide. Du coup il est possible d’exécuter du code arbitraire quand un utilisateur visite une page web corrompue en particulier lorsqu’il ferme une fenêtre pop-up.

Cette vulnérabilité a été trouvée sur la version Windows de Safari 4.0.5, mais il est fort probable que la version Mac soit également concernée.

Références:

• MacGeneration
• Secunia

Cet article est purement informatif et en aucun cas une incitation au hacking ou/et autres activités illégales. ll s’agit simplement d’explications vous permettant de pouvoir tester et mettre en place les mesures de sécurité adéquates dans le cadre de vos applications web.

En aucun cas, ce site internet et l’auteur de cet article ne peuvent être reconnus responsables en cas d’activité illégale.

Burp Suite

Burp Suite est un ensemble d’outils utilisés afin de tester la sécurité des sites internet. Cette suite contient plusieurs outils ainsi que des interfaces afin de faciliter et d’accélérer le processus d’attaque sur une application. Un framework commun est utilisé afin de gérer les requêtes HTTP, la persistance, l’authentification, les proxy, etc.

L’un des gros avantages de cette suite c’est qu’il permet d’utiliser une combinaison de techniques manuelles et automatiques afin d’effectuer des analyses, des scans, des énumérations ainsi que l’exploitation des vulnérabilités d’une application web. Les différents outils de la suite fonctionnent de concert, vous pouvez utiliser l’un pour faire de l’énumération de login/password et un autre afin de le tester sur plusieurs pages ou plusieurs applications web.

Burp Proxy

Il s’agit d’un serveur de proxy HTTP/S. Il fonctionne comme un “man-in-the-middle” entre le navigateur et le serveur web que vous souhaitez atteindre, en particulier ce proxy permet d’intercepter, d’inspecter et de modifier les trafics (i.e. les requêtes HTTP par exemple) dans les deux directions. Vous pouvez donc trouver et exploiter des vulnérabilités en observant et manipulant des paramètres critiques et autres données transmises dans une application. En modification ces requêtes de manière “créative”, le proxy peut être utilisé afin d’effectuer des attaques de type SQL injection, “cookie subversion”, privilege escalation, hijacking session, buffer overflows, etc.

Burp Spider

Le Spider est un outil afin d’effectuer un “mapping” d’une application web. Utilisant des techniques dites “intelligentes” cet outil permet d’établir un inventaire du contenu et des fonctionnalités d’une application (i.e. entre autres une liste des différents fichiers et dossiers). Par conséquent, cet outil vous permet d’obtenir rapidement et automatiquement beaucoup d’information très utile dans le cadre du test d’une web application.

Burp Repeater is a tool for manually modifying and reissuing individual HTTP requests, and analysing their responses. It is best used in conjunction with the other Burp Suite tools. For example, you can send a request to Repeater from the target site map, from the Burp Proxy browsing history, or from the results of a Burp Intruder attack, and manually adjust the request to fine-tune an attack or probe for vulnerabilities.

Burp Intruder

L’Intruder est un outil permettant d’automatiser des attaques sur une application web. Vous pouvez utiliser cet outil pour effectuer différentes tâches, par exemple: énumération de compte utilisateurs, obtention d’informations utiles, techniques de “fuzzing”. Loin de se limiter à cette liste, l’Intruder pour également être utilisé pour tester des SQL injection, cross-site scripting, buffer overflows; attaque de type brute force sur les mécanismes d’authentification; recherche de contenu cachés; attaque sur les sessions token; et pour finir, on peut effectuer des attaques concurrentes afin de tester l’application en cas d’attaque de type deni de service.

Burp Repeater

Le Repeater permet, manuellement, de modifier et de soumettre à nouveau une requête HTTP. Bien l’analyse de la réponse à cette même requête est possible. Pour tirer le meilleur de cet outil, il est très souvent utilisé conjointement avec les autres outils de la suite. Afin d’y arriver, il est possible de transférer une requête HTTP vers le Repeater depuis Intruder, le Proxy, etc. et ainsi de l’analyser plus en détail.

Burp Sequencer

Cet outil permet de tester si les token de session (session ID) sont générés de manière aléatoire. On peut imaginer certains cas où il est possible de découvrir un schéma qui se répète dans ce processus de création de session ID et par conséquent pouvoir les prédire.

Burp Decoder et Burp Comparer

Les deux derniers outils permettent, respectivement de “décoder” des caractères et de faire une comparaison entre deux requêtes.

Burp Suite Professional

Il est existe une version professionnelle de la suite Burp. Cette version se différencie de la manière suivante:

• Possibilité d’enregistrer et de restaurer la configuration des différents outils
• Burp Scanner, qui permet d’effectuer de la recherche de vulnérabilités automatisées dans une application web.
• Engagement tools: ensemble d’outils secondaires par exemple: recherche, planification du lancement des outils, etc.
• Le prix (!), 149£ par année

Burp Suite sous Mac OS X

Burp Suite est un logiciel JAVA, il fonctionne parfaitement sous Mac OS X 10.6 (je n’ai pas testé sous les versions précédentes) malgré un message d’avertissement lorsque vous lancez le logiciel.

Partant du principe que Burp Proxy est l’outil de base, indispensable pour effectuer une analyse. Voici comment configurer le Burp Proxy ainsi que votre ordinateur:

HellRTS est un exécutable crée en RealBasic et compilé en Universal Binary. Il peut donc être exécuté sur les Power-PC et sur les Mac avec processeurs Intel. Il installe son propre serveur, il se duplique via différentes applications (y compris dans les applications lancées à l’ouverture de la session). Par la suite il peut envoyé des email, contact un serveur distant, donner un accès direct à l’ordinateur infecté, partager l’écran (screen-sharing), éteindre ou redémarrer l’ordinateur, etc.

Bien entendu Intego recommande l’utilisation de VirusBarrier afin d’éviter tout problème. Outre l’utilisation d’un tel logiciel, ou de celui d’un concurrent, nous ne serions que, vous recommander d’être prudent lors de vos sessions de surf et de téléchargement.

HellRTS -image via Intego.com

Il est intéressant de noter que cet update, corrige la faille qui a permis à Charlie Miller, analyste dans une entreprise de sécurité indépendante, de gagner le concours Pwn2Own à la fin du mois de mars 2010. Le moyen utilisé par Charlie Miller consiste à exploiter une faille dans ATS (Apple Type Services) via Safari. En fait ATS est utilisé par tout le système afin d’afficher et de gérer les fonts, il est d’ailleurs considéré par Apple comme un “Legacy API” puisqu’il est recommandé d’utilisé Core Text pour gérer et afficher les font depuis Mac OS X 10.5. Apple a donc confirmé la chose via cet article de la KB: About the content of Security Update 2010-003.

Derniers petits détails, la faille utilisée est un “zero-day” sous entendu, Charlie Miller était le seul à la connaître puisque ni Apple ni d’autres personnes n’étaient au courant.