De récentes nouvelles sur des sites d'informations et blogs spécialisés remettent en question le fait que la plateforme d'Apple soit exempte de code malveillant. Pire encore : même les terminaux non jailbreakés seraient en danger !
1. Rappel des faits
1.1 Introduction
Pour paraphraser le rapport DBIR 2015 de Verizon [DBIR] : la plupart des activités suspectes détectées et recensées comme visant les terminaux iOS étaient en fait des codes d'exploitation visant Android (most of the suspicious activity logged from iOS devices was just failed Android exploits). La notoriété de cette publication impliquerait que nous, les utilisateurs de terminaux Apple, sommes sauvés !
Pour une majorité des gens dans le domaine, le danger provient des magasins tiers, types Cydia, et par conséquent, ils ne jailbreakent pas leur iPhone comme indiqué dans la politique de sécurité. Ce qui inquiète maintenant, ce sont les terminaux non jailbreakés dont parle l'article. Au moment d'écrire cet article, ce sont YiSpecter [SPECTER] et XcodeGhost [XCODE] qui font parler d'eux.
L'objectif ici est de présenter de manière claire les actions réalisables selon que le terminal soit jailbreaké ou pas. Ce point manque régulièrement dans les analyses publiées.
Note : le lecteur pourra sans doute questionner l'exhaustivité de l'étude Verizon, puisque les participants proviennent majoritairement des pays occidentaux. La majorité des cas récents de code malveillant iOS (WireLurker, YiSpecter, Muda [MUDA]) proviennent de magasins tiers principalement asiatiques.
Note : les analyses réalisées dans cet article ont pu l'être grâce à la mise à disposition des binaires malveillants par l'analyste Claud Xiao.
1.2 Notions de base sur la sécurité iOS
Le but de l'article n'est pas d'expliquer les concepts de sécurité d'iOS. Pour rappel, le code exécuté sur les terminaux iOS doit être signé par Apple. Le tout repose sur le concept de hardware root of trust qui, en résumé, implique qu'un composant physique du terminal valide le tout dès la phase de démarrage.
De ce fait il existe, en théorie, trois méthodes permettant d'exécuter du code sur ces terminaux, en dehors des applications fournies par Apple :
- via une application téléchargée depuis l'AppStore officiel et signée par un certificat type Developer fourni par Apple (payant) ;
- via une application en développement et distribuée à des fins de tests (Ad Hoc). Celle-ci également signée et distribuable uniquement sur une liste limitée de terminaux grâce au renseignement des UDID (identifiant unique du terminal) et nécessitant un certificat de développeur (payant) ;
- via une application distribuée en mode In House dans une entreprise et signée par un certificat Enterprise fourni par Apple (validation numéro DUN). À noter que dans le cas d'une application en mode Enterprise, le binaire n'est pas chiffré, ce qui permet d'analyser le code sans passer par une phase de déchiffrement [REV]. Ce mode est également payant.
Il existe une méthode à la croisée des méthodes 1 et 2 et qui permet de distribuer une application à une liste limitée d'utilisateurs. Cette dernière, nommée TestFlight se base sur une distribution via l'AppStore dans le but de réaliser une évaluation de l'application avant une distribution réelle sur l'AppStore. Les adresses e-mail rentrées dans iTunes Connect reçoivent alors une invitation à télécharger et installer l'application.
Depuis peu, il est possible de créer gratuitement un compte développeur permettant de compiler une application à destination d'iOS ou OS X. Cette nouvelle méthode pourrait être utilisée par les outils de jailbreak pour signer le binaire exploitant une élévation de privilèges ou encore des codes malveillants afin de pivoter d'un Mac à un terminal iOS. La création d'un tel compte se fait directement depuis Xcode sous . L'outil f.lux a récemment fait parler de lui [FLUX] du fait que ses développeurs proposaient cette méthode pour contourner les restrictions de l'Apple Store (présentées ci-dessous). Apple a alors jugé non conforme aux règles du programme de développement cette méthode, notamment du fait qu'il s'agissait d'un binaire et non du code source qui était distribué.
Moyennant quelques prérequis comme une corruption mémoire et une divulgation d'adresses, il est également possible d'exécuter du code via du ROP dans le contexte d'un processus vulnérable.
Le jailbreak a pour lui le but de désactiver les protections d'exécution de code du système iOS afin d'ouvrir la porte à d'autres magasins d'applications tels que Cydia. Le contournement des restrictions de l'environnement d'exécution restreint (sandbox) est par contre possible via la distribution en mode Ad-Hoc, comme expliqué ci-après.
2. Techniques utilisées
2.1 Infection
2.1.1 Méthodes d'installation non conventionnelles
2.1.1.1 Phishing
La principale méthode d'installation de code malveillant sur les terminaux iOS (jailbreakés ou non) est le phishing. Les attaquants utilisent alors un mail ou des promotions pour une application qui servira d'infection initiale.
Dans le cas d'un terminal jailbreaké et utilisant un magasin d'applications tierces, il est également possible aux attaquants de publier leur code malveillant sur ces derniers. Ils peuvent alors proposer des applications payantes piratées et contenant leur code malveillant.
2.1.1.2 Injection dans le trafic
Intercepter le trafic est une méthode qui semble courante en Asie d'après des présentations sur les codes malveillants pour terminaux mobiles [BAIDU]. Cela peut se faire de manière assez simple sur un réseau WiFi public ou, via une fausse eNodeB sous le contrôle des attaquants, en insérant un lien pour télécharger l'application malveillante dans les communications 2G/3G. LTE réalisant une authentification mutuelle, cela n'est pas possible, sauf compromission d'une femtocell officielle.
Il semblerait également que des FAI chinois (entre autres) subissent des attaques de type usurpation DNS permettant aux attaquants de servir les pages contenant les applications malveillantes [SPECTER].
2.1.1.3 USB
En connectant un terminal iOS à un Mac ou un PC, il est possible d'utiliser les services installés par Apple (usbmuxd sur OSX) afin de lister les applications, les installer ou les désinstaller. Cette technique repose sur la bibliothèque MobileDevice (MobileDevice.framework et iTunesMobileDevice.dll qui sont généralement instrumentées via la bibliothèque libimobiledevice [LIBMOB]). À titre d'exemple, l'outil de HackingTeam pour iOS a la capacité d'être installé depuis OS X ou Windows [HACKDED], tout comme l'application malveillante WireLurker [RUMP].
C'est également la technique utilisée par l'outil zYiRemoval [ZYIREM] de Zimperium compilé en statique avec cette dernière. On peut y voir la création d'une instance du service com.apple.mobile.installation_proxy qui est ensuite utilisé via les fonctions instproxy_browser en demandant le BundleIdentifier, BundleDisplayName au préalable, puis instproxy_uninstall pour supprimer le code malveillant.
Fig. 1 : Lancement du service com.apple.mobile.installation_proxy par zYiRemoval.
2.1.2 Terminal jailbreaké
Utiliser un terminal jailbreaké est le plus simple pour installer de manière non conventionnelle une application sous iOS puisque les vérifications de signature des binaires sont désactivées, entre autres dans le but d'installer des applications depuis des magasins tiers ou de permettre l'étude par rétroconception du système et des applications. Dès lors, il est possible à un attaquant de créer une application sans la signer via un certificat Developer ou Enterprise délivré par Apple.
Par exemple, iOS.KeyRaider [KEYR] utilise cette méthode d'infection.
2.1.3 Terminal standard
Dans le cas d'un terminal iOS non jailbreaké, il est nécessaire que l'application soit signée. S'offre alors une distribution via l'AppStore officiel ou la distribution In-House avec un certificat Enterprise.
À noter que le nouveau compte Developer gratuit permet uniquement de déployer des applications sur des terminaux enregistrés dans Xcode via une connexion câblée. Pour utiliser cette méthode, il est nécessaire que la cible ait configuré au préalable un tel compte sous l'EDI d'Apple (non installé par défaut).
2.1.3.1 AppStore
La première méthode requiert de passer outre les validations effectuées par Apple et limite tout de même les actions, du fait de Seat-Belt, l'environnement d'exécution restreint d'Apple sur iOS et OSX. Les points validés par Apple (en théorie) sont entre autres les privilèges (entitlements) demandés par l'application et l'utilisation des API privées, comme récemment mentionnés dans la presse [PRIV1]. L'idée est alors pour des attaquants de créer une application malveillante et de lui faire passer les différentes étapes nécessaires à la validation d'Apple, ou encore de mettre en place une porte dérobée dans les applications légitimes comme récemment dans XcodeGhost.
2.1.3.2 In House
Dans le cas d'une application signée avec un certificat Enterprise, son installation peut être réalisée en suivant un lien vers le fichier manifest.plist depuis Safari. Une connexion sécurisée avec un certificat délivré par une autorité de certification racine installée sur le terminal est nécessaire pour accéder au fichier IPA, indiqué sous le champ software-package du fichier manifest.plist.
Lors de l'installation, l'utilisateur est averti par une première notification concernant l'installation d'une application signée par <nom de l'entité enregistrée>. Dans les versions antérieures à iOS 9, un autre avertissement est affiché lors de la première exécution. Le second avertissement ne sera plus affiché dans le cas où l'application est supprimée et réinstallée après cette exécution initiale (astuce notamment utilisée par des commerciaux lors de certaines démos de produits de sécurité pour iOS ;)). Un profil Enterprise App sera également installé.
Avec iOS 9, le flux d'exécution diffère après le premier avertissement. L'application ne pourra pas être exécutée que lorsque l'utilisateur aura validé le profil sous
. À noter que dans le cas d'un déploiement d'applications au travers d'une solution de gestion des terminaux mobiles (MDM), cette étape n'est pas requise, le profil étant distribué par la solution lors de l'enrôlement du terminal.2.2 Actions malveillantes
2.2.1 Terminal standard
2.2.1.1 Environnement d'exécution restreint
Dans le cas d'une application signée par un certificat Developer ou Enterprise, les règles de la sandbox iOS s'appliquent de la même façon. A contrario une application Developer passe par la phase de validation d'Apple qui doit valider l'utilisation de certaines API et les privilèges définis dans le fichier entitlements.plist.
Ces applications sont ainsi soumises aux règles de Seat-Belt et aux autorisations données par les utilisateurs. Sous réserve d'autorisation, le code malveillant peut accéder aux contacts et notes, à l'agenda, aux photos et données de santé. Les privilèges demandés par une application peuvent être listés via l'application codesign, comme démontré en 2.2.1.3.
Un potentiel exemple d'attaque d'application malveillante serait la capture de la vidéo ou de l'audio alors que l'application est en tâche de fond et le terminal dans une salle de réunion. Bien que la capture audio soit possible via l'option UIBackgroundModes à définir à audio dans le fichier Info.plist du projet, une indication visuelle est faite pour avertir l'utilisateur.
Les applications ne définissant pas cette option pourront être suspendues par l'orchestrateur des tâches de l'OS.
La gestion de droits spécifiques se fait également via les privilèges attribués aux applications. Depuis l'interface web https://developer.apple.com/, il est uniquement possible de demander des droits pour iCloud ou pour les notifications, les autres valeurs étant réservées à Apple ou à des partenaires spécifiques. Ce fut le cas pour JunOS Pulse qui pouvait lister les profils installés et établir un VPN bien avant que cette fonctionnalité ne soit offerte sous iOS 8.
2.2.1.2 Keylogging
Depuis iOS 8, il est possible de développer des extensions aux fonctionnalités diverses, comme proposer un clavier alternatif, comme c'est le cas sous Android. La première réaction est alors de penser aux possibilités comme le keylogging, Apple a toutefois mis en place deux mesures de protection.
La première remplace ce type de clavier lors de l'écriture dans des champs marqués comme étant Secure.
La seconde est l'isolation par défaut de l'extension avec le système de fichiers et le réseau. Pour rappel, une extension clavier doit être installée via une application standard, mais ne partage pas son espace d'adressage afin d'empêcher le transfert d'informations et donc le risque de keylogging.
Il existe toutefois une option de configuration à renseigner dans le fichier Info.plist depuis Xcode : NSExtensionAttributes :: RequestsOpenAccess. Une extension de clavier possédant cette option est alors en mesure de stocker des fichiers, accéder au Keychain et au réseau. HackingTeam utilise cette technique dans son extension malveillante [KEYB1].
Il est à noter que dans le cas d'une extension publiée sur l'AppStore, des validations plus poussées devraient être effectuées par Apple [KEYB2] et l'utilisateur doit activer cette extension manuellement depuis open-access. Cette technique n'est pas réservée aux codes malveillants et des applications légitimes comme le clavier Swift demandent ce type d'accès, pour le bien de l'utilisateur.
ainsi qu'autoriser le modeFig. 2 : Activation du mode open-access pour le clavier Swift.
2.2.1.3 Private API
Dans le contrat de licence que les développeurs acceptent en intégrant le programme iOS Developer, il est stipulé que l'utilisation d'API privées est strictement interdite et cette politique est validée via le processus de revue (assez obscur il faut noter). Ce point a néanmoins été remis en question avec les quelque 200 applications qu'Apple a supprimées de l'AppStore suite au contournement de cette règle [SOURCE]. Pour information, les fonctions ou méthodes classées comme privées sont celles non présentes dans les entêtes du SDK fourni par Apple. Rappel : l'utilisation de l'API privée ne permet pas de se soustraire à l'environnement d'exécution restreint, ce serait trop facile ;)
La liste des API privées peut être récupérée via :
- l'extraction de leurs définitions avec l'outil classdump-dyld depuis un terminal jailbreaké ;
- la consultation de la liste mise à disposition par Nicolas Seriot [HEADR].
# classdump-dyld -o classes/ -c
Now dumping /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64...
Dumping /.../AXSpeechImplementation.bundle/AXSpeechImplementation...(3 classes)
Dumping /.../AccessibilitySettingsLoader.bundle/AccessibilitySettingsLoader...(15 classes)
Dumping /System/Library/AccessibilityBundles/AccountsUI.axbundle/AccountsUI...(5 classes)
…
# cat classes/System/Library/PrivateFrameworks/SpringBoardUI.framework/SBAlertItem.h
...
#import <UIKit/UIAlertViewDelegate.h>
@class UIAlertView, NSArray, NSString;
@interface SBAlertItem : NSObject <UIAlertViewDelegate> {
UIAlertView* _alertSheet;
BOOL _orderOverSBAlert;
...
}
@property (assign,nonatomic) BOOL ignoreIfAlreadyDisplaying;
...
-(id)alertController;
-(id)alertSheet;
-(void)didDeactivateForReason:(int)arg1 ;
Les API privées peuvent être appelées directement si exportées en tant que fonctions C, ou encore via l'utilisation de dlopen/dlsym (l'utilisation de ces fonctions est laissée en étude au lecteur si ce n'est déjà fait). La première méthode n'est probablement pas furtive vis-à-vis des validations effectuées par Apple, mais pour les codes malveillants distribués en mode In House, le problème ne se pose évidemment pas.
À titre d'exemple, le binaire DaPian de YiSpecter appelle directement des méthodes de l'API privée, comme le montre la liste des bibliothèques auxquelles il est lié :
$ otool -L DaPian
DaPian (architecture armv7):
/usr/lib/libstdc++.6.dylib (...)
...
/System/Library/PrivateFrameworks/MobileInstallation.framework/MobileInstallation (...)
/System/Library/Frameworks/MediaPlayer.framework/MediaPlayer (...)
Le langage ObjectiveC étant réflectif, il est également possible d'appeler des méthodes via leur représentation en chaîne de caractères après le chargement du framework. Par exemple, l'appel de la méthode [LSApplicationWorkspace allApplications] permettant de lister les applications installées sur un terminal iOS se fait de la manière suivante :
Class lsapp = objc_getClass("LSApplicationWorkspace");
s1 = NSSelectorFromString(@"defaultWorkspace");
NSObject* workspace = [lsapp performSelector:s1];
s2 = NSSelectorFromString(@"allApplications");
NSLog(@"apps: %@", [workspace performSelector:s2]);
Le chargement d'un framework et l'appel d'une méthode peuvent également se faire via [NSBundle bundleWithPath],[NSBundle NSClassFromString] et objc_msgSend*. Ces points sont couverts dans l'article de MISC n°57 [MISC57] sur le reverse engineering d'applications iOS.
Via le privilège com.apple.CommCenter.fine-grained (nécessitant d'être distribué hors de l'AppStore), il est également possible à un code malveillant d'utiliser la classe CoreTelephony et ainsi de réaliser des actions telles que :
- notification lors de la réception et envoi d'un SMS ;
- notification lors d'un appel téléphonique ;
- récupération des informations IMSI/IMEI ;
- ...
2.2.1.4 Installation d'applications
Une fois une première application installée via les méthodes décrites ci-dessus, il est possible de déployer d'autres applications dans le but d'assurer de la persistance via deux méthodes :
- demander gentiment à installd de s'en charger ;
- utiliser l'API privée [MobileInstallation MobileInstallationInstall] sous réserve que le binaire possède le privilège com.apple.private.mobileinstall.allowedSPI défini à Install.
Dans le premier cas, il s'agit du mécanisme suivi lors de l'installation d'une application depuis Safari en cliquant sur une URL de la forme suivante :
itms-services://?action=download-manifest&url=<url to plist>
Sous iOS, le URL handler itms-services:// est lié au démon installd qui gère les applications.
La seconde méthode requiert un privilège spécifique qui n'est pas accepté sur l'AppStore, mais ce problème ne se pose pas dans le cas d'une application signée avec un compte Enterprise. Les privilèges se trouvent dans la load command LC_CODE_SIGNATURE. Pour la récupérer, soit on parse le format Mach-O, soit on utilise sed à la recherche des balises <dict> et </dict> ou tout simplement via codesign :
$ codesign -d --entitlements - NoICon
Executable=/Users/.../samples/yispecter/NoIcon
??qq<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>application-identifier</key>
<string>VN36KFTLTA.com.weiying.hiddenIconLaunch</string>
<key>com.apple.developer.team-identifier</key>
<string>VN36KFTLTA</string>
<key>com.apple.private.mobileinstall.allowedSPI</key>
<array>
<string>Install</string>
<string>Browse</string>
<string>Uninstall</string>
<string>Archive</string>
<string>RemoveArchive</string>
</array>
<key>com.apple.springboard.launchapplications</key>
<true/>
<key>get-task-allow</key>
<false/>
<key>keychain-access-groups</key>
<array>
<string>com.weiying.noicon</string>
</array>
</dict>
</plist>
L'API privée [MobileInstallation MobileInstallationInstall] est utilisée comme dans l'exemple ci-dessous tiré de YiSpecter.NoIcon.
__text:0000F5F4 LDR R0, [SP,#0x68+var_54]
__text:0000F5F6 MOVS R1, #0
__text:0000F5F8 MOVS R2, #0
__text:0000F5FA MOVS R3, #0
__text:0000F5FC BLX _MobileInstallationInstall
La nouvelle application peut être masquée via l'option hidden du dictionnaire SBAppTags du fichier Info.plist. Encore une fois, ce comportement devrait, en toute logique, lever des suspicions lors de la validation sur l'AppStore. Dans le cas de HackingTeam, leur approche était d'utiliser une icône transparente et une application liée à Newsstand (jusqu'à iOS 9 uniquement).
Fig. 3 : Option du fichier Info.plist.
2.2.1.5 Profils de configuration
Ce dernier point n'est pas lié aux applications, mais aux profils de configuration qui peuvent être installés aussi simplement, en suivant un lien. Au moment de l'installation, l'utilisateur devra valider le profil avec un message assez clair.
L'installation d'un profil est souvent utilisée lors d'analyses sécurité d'applications iOS afin d'ajouter un certificat racine, contrôlé par l'ingénieur, dans le magasin du terminal. Le problème est un peu différent quand il s'agit d'un attaquant qui utilise cette méthode pour définir un proxy ou VPN en plus. Dans ce cas, il serait en mesure d'intercepter le trafic en clair ou passant dans une connexion SSL, sous réserve que l'application ne fasse pas du certificate pinning. À noter que la définition d'un proxy ne peut être faite que pour les requêtes HTTP(S), la définition d'un proxy global requérant que le terminal soit en mode supervised.
Ce cas a récemment été répertorié pour des applications se présentant comme des solutions de filtrage de publicités. Avec les extensions Content-Blocker de Safari sous iOS 9, ce cas ne devrait plus arriver pour des applications légitimes.
2.2.2 Terminal jailbreaké
2.2.2.1 Injection de code et interception
Sur un terminal non jailbreaké, les applications n'ont pas les droits suffisants pour accéder à l'espace d'adressage des applications ayant des privilèges égaux ou inférieurs. Tout cela change lors du jailbreak où il est possible d'avoir des applications exécutées en tant que root. La majorité des outils de jailbreak modifient également vm_map_protect afin d'autoriser les pages mémoire avec des droits RWX, technique utilisée par des outils comme Frida pour l'injection de code. D'autre part, les droits du système de fichiers ne limitent plus les applications en root qui peuvent alors modifier des fichiers de configuration.
Des codes malveillants utilisent cette fonctionnalité afin d'intercepter des fonctions des bibliothèques, comme WireLurker l'a fait pour SSLWrite afin de récupérer les identifiants iTunes de l'utilisateur. Dans ce cas de figure, c'est Cydia Substrate qui a été utilisé via la fonction MSHookFunction [HOOK] qui se base sur le swizzling. L'avantage de cette méthode est qu'elle ne requiert pas la modification de vm_map_protect, car c'est une fonctionnalité du langage ObjectiveC. Le chargement de la bibliothèque effectuant l'interception est réalisé automatiquement par Cydia Substrate du moment qu'elle se trouve dans le répertoire :
/Library/MobileSubstrate/DynamicLibraries/
L'interception pourrait également être mise en place afin de supprimer la validation de présence de l'utilisateur réalisée via la méthode [LocalAuthentication evaluatePolicy] en la remplaçant par une implémentation retournant toujours 0.
L'injection de code dans les autres processus permet également d'accéder au contenu du KeyChain spécifique à chaque application ou encore, en injectant dans mediaserverd et en interceptant la fonction AudioUnitProcess, d'enregistrer les conversations téléphoniques.
2.2.2.2 Installation
Sur un terminal jailbreaké, il est possible de démarrer le service com.apple.afc2 permettant de copier des fichiers sur l'intégralité du système de fichiers depuis usbmuxd (connexion câblée). L'infection du terminal est alors effectuée via le déploiement de binaires et l'ajout de LaunchDaemon pour fournir une persistance lors du redémarrage du terminal, comme c'est le cas avec WireLurker.
Une telle infection sera plus furtive, l'application n'apparaissant pas dans SpringBoard, mais surtout intéressante, launchd permettant de créer le processus avec des droits plus élevés.
Une application avec des privilèges élevés a également la possibilité d'accéder aux fichiers tels que com.apple.mobilesafari.plist pour modifier la configuration de Safari comme YiSpecter.
3. Protection et détection
« C'est bien toutes ces explications, mais comment se protège-t-on ? » va vous demander votre CISO. La première étape (ok, elle est simple celle-là) passe par la sensibilisation des utilisateurs pour qu'ils ne valident pas les profils tiers (i.e. ceux pas déployés via votre solution MDM). De même, la sensibilisation aux risques du jailbreak est à effectuer.
Du côté du MDM, il est possible de lister les applications installées sur vos terminaux pour détecter des bundles ID suspicieux ou connus comme malveillants. La détection du jailbreak peut être réalisée via l'agent de la solution MDM, avec le risque que ces tests soient contournés par une injection de code. Ces tests comprennent les éléments suivants :
- présence de binaires tiers comme sshd, apt, … ou de bibliothèques comme MobileSubstrate ;
- support de gestionnaires d'URL installés par ces applications (ex : cydia://).
Si vous vous trouvez dans le cas d'un développement d'application à destination de l'AppStore et que vous générez des clefs pour le chiffrement asymétrique, il est recommandé d'utiliser les fonctionnalités d'iOS 9 qui stockent la clef privée dans le composant Secure Enclave et y effectuent les opérations cryptographiques. Cela permet d'éviter le vol de cette clef ainsi que le contournement de l'authentification locale si effectuée via evaluatePolicy.
Il existe une option allow installing configuration profiles qui peut être désactivée via un profil de configuration, mais malheureusement cette modification n'est effective que si le terminal est en mode supervised, c'est-à-dire enrôlé via une connexion USB.
Dans le cadre du développement d'une application à usage purement interne, il pourrait être intéressant de lister les profils et applications installés pour valider l'état du terminal. Ce point peut être lui aussi développé en interne, ou fourni par certaines solutions de gestion d'applications mobiles (MAM) qui ont pour vocation d'être distribuées via le canal In House.
L'initiative de Zimperium avec ZiYremoval est intéressante. Peut-être verra-t-on bientôt des AV PC/Mac incluant une validation des terminaux iOS ou Android via, respectivement, libmobiledevice ou ADB (qui ne devrait pas être activé en dehors d'environnements de développement).
Références
[DBIR] http://www.verizonenterprise.com/DBIR/
[MUDA] https://paloaltonetworks.app.box.com/MudaSample
[REV] http://connect.ed-diamond.com/MISC/MISC-057/Introduction-au-reverse-engineering-d-applications-iOS
[LIBIMOB] http://www.libimobiledevice.org
[HACKED] https://github.com/hackedteam/core-ios/tree/master/ios-install-osx
[RUMP] https://speakerdeck.com/milkmix/osx-malware-wirelurker
[ZIYREM] https://blog.zimperium.com/zyiremoval-free-tool-to-remove-yispecter/
[FLUX] https://justgetflux.com/sideload/
[BAIDU] https://www.hackinparis.com/sites/hackinparis.com/files/ThomasLeiWang.pdf
[KEYB1] https://github.com/hackedteam/core-ios/blob/master/ios-newsstand-app/keyboard/Info.plist
[SOURCE] https://sourcedna.com/blog/20151018/ios-apps-using-private-apis.html
[HEADR] https://github.com/nst/iOS-Runtime-Headers
[MISC57] http://connect.ed-diamond.com/MISC/MISC-057/Introduction-au-reverse-engineering-d-applications-iOS
[HOOK] http://www.cydiasubstrate.com/api/c/MSHookFunction/