Archives du mot-clé Apple

OSX : sécurité insuffisante

Pour Patrick Wardle de chez Synhack, le système OSX d’Apple a encore beaucoup de lacunes en terme de sécurité, en particulier ses défenses contre les malwares.

Le chercheur à l’origine de l’exploitation par Dylib Hyjacking indique qu’il est simple de bypasser le mécanisme de signature des exécutables sur le système (GateKeeper) et que si les malwares touchant OSX sont aussi basiques c’est qu’ils n’ont pas besoin de se donner du mal pour prendre le contrôle du système.

La faute aussi aux éditeurs d’antivirus pour OSX qui se reposeraient sur leurs lauriers. Un peu comme si les antivirus Windows ne cherchaient la présence de malwares qu’en regardant dans les clés de registre \Software\Microsoft\Windows\CurrentVersion\Run

Des slides intitulées Writing Bad@ss OS X Malware datant de la dernière conf RSA de San Francisco sont trouvables via l’article de TheRegister.

OSX : Dylib hijacking (whitepaper)

Le whitepaper de la présentation qui a eu lieu à la CanSecWest est finalement disponible sur le site de VirusBulletin (pdf).

EDIT:

Le white-paper montre deux cas d’attaques sur les binaires OSX.

Dans le premier cas un binaire peut avoir un lien optionnel (weak) pour le chargement d’une librairie (on peut imaginer que ce soit utilisé par un système de plugin). L’avantage de ce cas là c’est que potentiellement aucune librairie n’est présente au path indiqué dans le header du binaire OSX (format MachO) laissant ainsi à l’attaquant la possibilité de placer sa librairie malicieuse.

Le second cas se base sur les @rpath. Un binaire peut indiquer qu’il a besoin d’une librairie dont il ne connait pas exactement le path. Dans ce cas là le header contiendra des paths du type @rpath/chemin/vers/lib.dylib. Le binaire aura aussi une liste de ces rpath possibles indiquée dans son header.
Le loader OSX va donc substituer la chaine « @rpath/ » dans le chemin exporté par chaque valeur de la liste jusqu’à trouver un chemin où la librairie est présente.
Si aucune librairie n’est présente dans le (ou les) premier paths calculés alors ça laisse à l’attaquent la possibilité de placer une librairie qui sera prioritaire par rapport à celle légitime.

La création d’une librairie malicieuse fonctionnelle requiert quelques particularités qui peuvent être définies depuis XCode.
Sur Github, Synhack fournit un script Python facilitant la génération d’une dylib malicieuse fonctionnelle pour peut que l’on dispose d’un squelette de dylib.

Il fournit aussi un script Python permettant de scanner le système à la recherche de programmes vulnérables à ces attaques.
Et c’est la grande question qu’on attendait : est-ce que ça touche beaucoup de programmes ? La réponse est oui, la technique devrait par conséquent attirer de nombreux auteurs de malwares.

L’autre question est à quoi peut servir cette attaque ?
Principalement ça permettra à des malwares de se rendre persistant tout en étant discret. Comme si sous Windows un malware se faisait charger par un programme légitime sans avoir à créer la moindre clé en registre.
Ensuite l’auteur indique que l’attaque peut être utilisé contre l’outil interne Gatekeeper d’OSX qui demande à l’utilisateur une validation pour lancer un exécutable si celui-ci ne provient pas du AppStore. Dès lors un malware ayant obtenu un accès sur un système pourrait exploiter cela pour installer d’autres malwares… De quoi intéresser les botherders.

Est-ce que ça permet d’entrer dans un système OSX ou de faire une escalade de privilège ?
Vraisemblablement non, il faudrait en plus que les PATHs où l’on peut placer la dylib malicieuse soient peu protégés (mauvaises permissions), ce qui n’est pas discuté dans le whitepaper. Mais peut-être que des cas particuliers seront découverts.

Pour le moment il semble qu’Apple ne souhaite pas corriger le problème.

La conférence secrète de la CIA où l’on cherche à hacker les logiciels Apple

Dans un long (trop long ?) article de The Intercept, on apprend que la CIA organise en secret une conférence régulière baptisée Jamboree.

A cette conférence des chercheurs sécu et entreprises spécialisées présentent leurs travaux dans l’espoir de décrocher un contrat.
Les sujets demandés par la CIA se concentrent majoritairement sur le cassage et l’interception de cryptosystèmes et mécanismes d’authentification que l’on trouve dans les machines couramment utilisées.

Il apparaît que les attaques ciblées sur les logiciels Apple soient aussi une habitude de ces présentations avec par exemple un projet permettant de modifier la plateforme de développement Xcode pour faire en sorte que chaque logiciel compilé avec cette plateforme se voit injecter une backdoor ouvrant alors la porte aux machines OSX ou IOS…

La première conférence Jamboree a eu lieu en 2006.

Open-source : Microsoft ouvre le CoreCLR de .NET

Après avoir ouvert différents composants de sa plateforme .NET, Microsoft a finalement passé le CoreCLR (le runtime, l’équivalent de la JVM pour Java) en open-source et a publié le code sur Github.

Bien sûr à l’heure actuelle il est difficile voire impossible de faire des applis .NET sous OSX et Linux mais Microsoft promet des avancées dans les mois qui viennent.
Comme il n’y a pas de support graphique de ces deux plateformes il ne sera possible que de faire des applis console et de l’ASP.NET pendant un moment.

Wait and see mais Microsoft prend des chemins intéressants 🙂

Parallels : s’échapper d’une VM Windows pour infecter un système OSX

Ceux qui utilisent OSX et le système de virtualisation Parallels ont déjà dû remarquer que certaines fonctionnalités appréciables font toutefois de Parallels une passoire en matière d’isolation des VMs.

Les options par défaut permettent le partage de dossiers et le lancement d’exécution de programmes OSX depuis la machine virtuelle (menu contextuel Ouvrir sur Mac).

Le rerverser cr4sh a mis en ligne sur son blog un PoC qui automatise l’exploitation via l’ouverture de programme Java sur la machine hôte qui lance des commandes OSX.