Tout a commencé lorsque l’équipe sécurité de l’opérateur hollandais XS4ALL remarque un trafic particulièrement élevé en provenance de terminaux iPhone de certains clients et vers les réseaux de plusieurs opérateurs (UPC, Optus et T-Mobile).

Le point commun de ces iPhones : tous sont débridés (« jailbroken ») et disposent donc d’OpenSSH. De là à penser qu’un nouveau ver exploite la faiblesse bien connue du cocktail iPhone / OpenSSH (voir encadré), il n’y a qu’un pas que franchi rapidement Scott McIntyre, le RSSI de l’opérateur. Il constate en effet que les terminaux sont infectés par un ver inconnu dont le comportement est inédit pour un téléphone mobile.

A première vue pourtant, il n’y a rien de nouveau : le parasite, une fois installé sur un iPhone (ou iPod Touch), télécharge et installe de nouveaux composants, modifie les scripts de démarrage de l’appareil puis se met à rechercher activement de nouveaux terminaux à infecter (et plus activement encore lorsque l’iPhone est connecté à un point d’accès WiFi, ce qui aurait tendance à rapidement épuiser la batterie). Jusque là, rien de très étonnant pour un ver.

Le parasite collecte ensuite un maximum de données personnelles sur le terminal (SMS, liste de contacts) et les transmets à un serveur basé en Lituanie (aujourd’hui neutralisé, mais d’autres semblent avoir pris le relais). Plus original, il semble aussi rechercher spécifiquement certains SMS liés à une authentification à deux facteurs, probablement dans le cadre de transactions bancaires en ligne.

Mais – et c’est là la nouveauté – la connexion n’est pas à sens unique : le serveur a la possibilité d’installer des plugins additionnels sur l’iPhone, à distance, ou de mettre à jour le code du ver. Il agit ainsi tel un véritable centre de contrôle (C&C) traditionnel d’un botnet.

Baptisé Ikee.B par F-Secure, le ver est ainsi probablement le premier à tenter de créer un vrai botnet à partir de terminaux mobile. L’idée, bien entendu, était dans les cartons depuis un moment. En début d’année Rik Ferguson, un expert sécurité chez Trend Micro, prédisait même que 2009 verrait le premier botnet 3G. Il a eu raison.

Certes, l’ébauche d’un tel botnet mobile avait été observée dès cet été dans le comportement d’un ver pour Symbian. Celui-ci était capable de se remonter les données dérobées vers un serveur web et d’envoyer du spam SMS aux contacts de l’appareil infecté. Mais Ikee.B va plus loin et peut être mis à jour par son créateur via le C&C, ce qui en fait un véritable bot… mobile.

Un botnet mobile présente beaucoup d’intérêt d’un point de vue de l’attaquant : la sensibilisation des utilisateurs vis-à-vis des risques mobiles est faible, les appareils contiennent des courriers et des données personnelles de valeur et ils sont de plus en plus utilisés comme moyen d’authentification. En outre, le potentiel de déni de service à l’encontre d’un opérateur est élevé (il n’y a qu’à voir comment la « simple » 3G des iPhone semble mettre à mal le réseau d’Orange actuellement). Et puis le réseau d’un opérateur, c’est son outil de travail : l’extorsion n’en sera probablement que plus efficace. Et cela d’autant plus que l’opérateur a rarement la main directement sur les terminaux infectés afin de le nettoyer.

Bien entendu, il n’y a pas que des avantages à être mobile pour un bot : l’activité accrue draine la batterie beaucoup plus vite et neutralise donc le bot plus rapidement (en plus d’alerter l’utilisateur). En outre l’opérateur qui voit son réseau – donc sa source de revenus – menacé sera probablement plus enclin à mettre de vrais moyens dans la lutte contre le botnet que ne le sont aujourd’hui les FAI traditionnels.

Pour les entreprise enfin, le risque d’avoir accepté des iPhone personnels dans le parc est que ceux-ci ne sont pas gérables, contrairement à un terminal Blackberry. Et à moins de tous les scanner afin de découvrir les ports SSH ouverts, il n’y a aucun moyen de déterminer ceux qui ont étés débridés par leur utilisateur.

Note : bien que le C&C initial du ver soit désactivé, les terminaux infectés tentent toujours de s’y connecter. Les administrateurs peuvent ainsi les repérer grâce à l’adresse IP de celui-ci (92.61.38.16). Il s’agit d’un serveur hébergé par le lituanien Hostex, et il ne devrait pas y avoir beaucoup de trafic légitime dans cette direction ! Par ailleurs, il semble que l’auteur ait prévu un mécanisme de mise à jour, et qu’un nouveau C&C soit actif.