Lors de la conférence de sécurité BlackHat 2009, Stefan Esser, chercheur réputé pour ses nombreuses découvertes concernant le moteur PHP, a rendu publiques deux vulnérabilités "0-day" dans le moteur PHP :

• Une vulnérabilité de type fuite d'information dans la fonction explode(), pouvant être exploitée afin de lire certaines structures internes du moteur (Réf. Lexsi 12585) ;
• Une vulnérabilité de type corruption de la mémoire dans la fonction "usort()" (Réf. Lexsi 12304).

Ces deux vulnérabilités font partie d'une classe de vulnérabilités que Stefan Esser nomme "Vulnérabilités d'interruption", consistant à stopper l'exécution d'une fonction interne de PHP afin d'en modifier les arguments, avant de rendre la main à la fonction. Ceci permet par exemple de modifier le type d'une variable, de "string" en "array", afin de pouvoir lire la structure représentant le tableau du point de vue du moteur PHP.

La combinaison de ces deux vulnérabilités permet d'obtenir un accès complet à la mémoire du processus en cours, par le biais suivant :

• On créé en mémoire une fausse structure représentant une chaîne de caractères commençant à l'adresse 0 et de taille 0x7fffffff ;
• On récupère l'adresse en mémoire de cette fausse structure grâce à la première vulnérabilité ;
• On corrompt l'une des entrées d'un tableau en insérant notre fausse structure grâce à la seconde vulnérabilité.

Nous nous retrouvons donc alors avec une entrée de tableau représentant une chaîne de caractères commençant à l'adresse 0 et de taille 0x7fffffff, ce qui nous procure un accès complet au 2 premiers Go de la mémoire du processus.
Une exploitation plus détaillée de ces vulnérabilités est disponible sur le blog Sécurité Offensive.

Si ces vulnérabilités ne permettent pas directement de compromettre un serveur web, elles deviennent particulièrement critiques dans le cas où il est possible pour un tiers d'exécuter du code PHP arbitraire, tel que dans les environnements d'hébergement mutualisé.
En effet, un accès complet à la mémoire du processus permet à un attaquant de reconfigurer complètement le moteur PHP, rendant inutiles les protections telles que safe_mode, open_basedir ou les disable_functions, voire même d'exécuter directement du code arbitraire avec les privilèges du serveur web.

Ces vulnérabilités ont été corrigées silencieusement (aucune apparition dans le ChangeLog) dans les versions suivantes de PHP :

• vulnérabilité explode() : version 5.3.1 (la branche 5.2.x n'a actuellement pas de correctif) ;
• vulnérabilité usort() : versions 5.2.11 et 5.3.1.

La réponse de Stefan Esser n'a pas tardé, et celui-ci a présenté peu de temps après une façon simple de contourner la protection contre l'exploitation de la vulnérabilité dans usort() grâce à la variable $_SESSION.
Cette nouvelle vulnérabilité a été corrigée dans la version 5.2.12 de PHP (Réf. Lexsi 12689) en modifiant certaines propriétés de la variable, et était cette fois-ci présente dans le ChangeLog.

Malheureusement, les corrections silencieuses de vulnérabilités posent des problèmes aux mainteneurs de paquets des principales distributions GNU/Linux, qui ne voient pas de mise à jour de sécurité à backporter dans leurs paquets. En effet, les versions de base de ces paquets sont généralement anciennes (version 5.2.6 dans Debian, par exemple), et les correctifs de sécurité doivent être intégrés à ces anciennes versions, sans pour autant y intégrer les autres modifications. Ces vulnérabilités, corrigées dans le moteur PHP depuis la mi-décembre 2009, ne sont pas corrigées dans la plupart des distributions Linux faisant office de serveurs Web :

• Red Hat Enterprise Linux : aucune mention des vulnérabilités dans explode() et usort(), seule la correction concernant la variable $_SESSION est abordée, mais le verdict est sans appel :

This flaw can be used by PHP script author to bypass restrictions such as safe_mode or open_basedir
Red Hat does not treat such issue as security flaws

• Mandriva Enterprise Server : aucune mention des vulnérabilité dans explode() et usort() ;
• Debian Lenny : la vulnérabilité concernant la variable $_SESSION vient d'être corrigée. Toutefois, les deux autres vulnérabilités n'ayant pas été corrigée, le risque est toujours autant présent ;
• Ubuntu : les correctifs sécurité d'Ubuntu se basant sur ceux de Debian, les vulnérabilités ne sont pas non plus corrigées.

Certaines distributions intégrant les versions 5.2.12 ou 5.3.1 de PHP sont quand à elles protégées de facto (OpenSuSE 11.2, Mandriva Linux 2010, Fedora 11/12 ...). Malheureusement, celles-ci sont beaucoup plus rares dans le domaine de l'hébergement, où l'on retrouve surtout des Red Hat Enterprise Server et des Debian.

Après la récente 0-day dans Internet Explorer (Réf Lexsi 12808) et l'Opération Aurora, c'est au tour du sous-système 16 bits de Windows d'être vulnérable à une élévation locale de privilèges. Toutes les versions de Windows sont affectées, de NT 3.1 (!) à Windows 7.

La vulnérabilité (Réf Lexsi 12828) affecte le composant VDM (Virtual DOS Machine) de Windows, chargé de permettre aux applications 16 bits en mode réel de s'exécuter dans un environnement 32 bits en mode protégé, via le mode 8086 virtuel du processeur. Lors de la restauration du contexte et de la pile par le gestionnaire de l'interruption General Protection Fault (interruption 0x0d), celui-ci vérifie qu'ils sont valides, mais se base sur 3 assertions qui peuvent être contournées une par une, permettant de fournir son propre contexte et sa pile noyau. Tavis Ormandy (Google) a publié les détails sur Full-Disclosure, accompagné d'un code d'exploitation.

La séquence est la suivante :

1. lancement d'un processus (ici cmd.exe)
2. détermination de l'adresse de base de Ntoskrnl
3. scan en mémoire à la recherche de l'offset de Ki386BiosCallReturnAddress() par rapport à Ntoskrnl
4. lancement d'une application 16 bits quelconque (ex : debug.exe) pour initialiser le sous-système NTVDM
5. injection d'une DLL dans le processus ntvdm.exe

La DLL effectue alors les opérations suivantes :

1. récupération de l'adresse de Ki386BiosCallReturnAddress() passé en variable d'environnement par le binaire précédent
2. mise en place d'une fausse pile noyau avec comme sauvegarde de l'adresse de retour une fonction quelconque (payload)
3. dans le TEB courant, on fait pointer VDM_TIB.VdmContext.Esi vers notre fausse pile et VDM_TIB.VdmContext.Eip vers l'adresse de Ki386BiosCallReturnAddress()
4. exécution de NtVdmControl() pour déclencher la vulnérabilité et exécuter notre fonction quelconque dans le contexte du noyau

Une fois la vulnérabilité correctement exploitée, la payload recherche le jeton de sécurité du processus SYSTEM et remplace celui du processus ciblé (cmd.exe). Sur la capture ci-dessous issue de Windows 7, on voit par exemple que le jeton du processus initial à gauche correspond à l'utilisateur Lexsi, alors que celui du nouveau cmd.exe à droite est devenu SYSTEM :

Tavis Ormandy avait contacté Microsoft au mois de juin dernier, mais a tout de même décidé de publier cette vulnérabilité de manière "non responsable". Heureusement, il suffit de déployer la GPO permettant de désactiver le sous-système 16 bits pour ne plus être vulnérable.

Petit patch day pour Microsoft (une seule vulnérabilité), mais Oracle et Adobe en ont aussi profité pour publier des mises à jour de sécurité critiques.

Microsoft n'a publié qu'un seul bulletin ce mois-ci :
MS10-001 : vulnérabilité dans le parsing des polices EOT, permettant d'exécuter du code arbitraire (Réf Lexsi 12790)

La vulnérabilité dans le composant SMB de Windows 2008 R2 et Windows 7 (Réf Lexsi 12542) n'est toujours pas corrigée, alors que le code d'exploitation est publié depuis 2 mois.

Quant à la vulnérabilité dans IIS dans la gestion du caractère ";" dans les URL (permettant de faire exécuter en tant que script ASP un fichier nommé foo.asp;bar.jpg) (Réf Lexsi 12724), elle reste sans correctif alors qu'elle est triviale à exploiter ; les conditions nécessaires (un répertoire accessible à la fois en écriture et en exécution) ne sont pas celles par défaut et sont même officiellement déconseillées, mais il n'est malheureusement pas rare de les rencontrer dans la nature.

Dans le cadre de sa publication trimestrielle, Oracle a publié de nouvelles versions de ses principaux produits (Database, Application Server, etc) corrigeant un total de 24 vulnérabilités. Trois vulnérabilités ont un score CVSSv2 de 10.

Adobe a également publié les versions 8.2 et 9.3 d'Acrobat/Reader, corrigeant plusieurs vulnérabilités critiques dont la récente 0-day dans la méthode JavaScript "newPlayer()" (Réf Lexsi 12676).

Petite digression sur les codes d'exploitation. Il est couramment admis qu'à mesure que les vulnérabilités système vont devenir de plus en plus difficile à trouver et/ou à exploiter, les vulnérabilités dans les applications tierces courantes vont être de plus en plus utilisées, de façon massive ou ciblée. Parmi ces applications, Adobe Flash Player et surtout Adobe Acrobat/Reader sont les plus exploitées. F-Secure a par exemple récemment indiqué qu'Adobe Acrobat/Reader était utilisé dans près de 50% des attaques ciblées en 2009 utilisant des documents malveillants, soit quasiment deux fois plus qu'en 2008.

Dans ce contexte, il semble pertinent de s'intéresser de près à l'efficacité des produits antivirus sur ce type de document malveillant. Prenons par exemple la 0-day dans Adobe Acrobat/Reader évoquée ci-dessus, pour laquelle un code d'exploitation est disponible dans le framework Metasploit depuis le 15/12. D'après nos tests, le PDF généré par Metasploit est aujourd'hui détecté par 6 antivirus sur les 19 principaux du marché :

Plaçons-nous maintenant dans un cas réel. Pour cela, nous allons prendre un fichier PDF légitime quelconque et y injecter le code d'exploitation et la payload fournis par Metasploit grâce au framework Origami présenté au SSTIC en 2009. Il existe de nombreuses manières de lancer du code JavaScript (ici celui directement issu de l'exploit Metasploit) automatiquement à l'ouverture d'un PDF ; nous allons ici choisir d'ajouter une annotation à une page. L'utilisateur lira ainsi tranquillement son document soi-disant légitime, jusqu'à atteindre la page piégée qui déclenchera l'exécution de la payload (de quoi augmenter la crédibilité de l'attaque :).

La surprise provient alors de la détection antivirale qui chute brusquement (le code d'exploitation étant identique) lors de l'utilisation de ce PDF légitime piégé, comparé au PDF directement fourni par Metasploit : seulement 2 sur les 19 testés.

Que penser de ces résultats ? Au premier abord, on pourrait se dire que ce n'est pas le rôle des antivirus de détecter des codes d'exploitation, mais plutôt les malware éventuellement droppés. Pour ainsi dire, on n'en voudrait pas à un antivirus de ne pas lever d'alerte sur un code d'exploitation exécutant calc.exe. Cependant, la plupart des antivirus intègrent effectivement des signatures pour les codes d'exploitation PDF ; les détecter dans le premier cas mais pas dans le second peut donc être considéré comme une faiblesse des moteurs d'analyse de documents.

L'annonce fracassante de Google, dont des secrets industriels auraient été volés par des hackers chinois, fait énormément de bruit aujourd'hui, et relance l'arlésienne de l'espionnage économique venu de Chine.

En réalité, très peu de détails ont été révélés sur cette attaque : Google parle d'une part d'une intrusion qui aurait également affecté d'autres entreprises, puis dans un deuxième temps, mentionne des vols de comptes d'opposants au gouvernement chinois par phishing ou par malware. Ce mélange de modes opératoires très différents rend difficile d'estimer la réalité et l'ampleur de ces attaques.

Aucun moyen donc d'analyser sérieusement cette annonce sous l'angle de la sécurité. Le mystère restera entier à moins que la firme dévoile davantage d'informations. Par contre, il nous semble opportun de replacer cette annonce dans son contexte : elle arrive en effet à point nommé pour Google, dont les récentes déclarations de son PDG à propos du respect de la vie privée des internautes avaient provoqué un tollé. La position de Google sur la Chine a toujours été compliquée : d'un côté, la firme a toujours refusé de collaborer avec le gouvernement chinois en fournissant les adresses IP des dissidents qui utilisent son réseau -- bien qu'en certaines occasions et dans d'autres pays, elle ait pu s'adonner à ce genre de pratiques (lien, lien) ; et de l'autre côté, le moteur de recherche Google.cn a toujours répondu présent face aux demandes pressentes du gouvernement chinois pour censurer certains sites web, pour leur caractère pornographique ou politiquement incorrect.

Il faut donc lire cette annonce comme une occasion pour Google d'endosser de nouveau un rôle de chevalier blanc, largement émoussé avec les années : Google, qui avait bâti sa réputation sympathique sur la voie alternative qu'il proposait face à l'acteur dominant Microsoft, a bien changé et désormais agace, assumant un rôle de Goliath, attaqué de toutes parts pour son arrogance et ses positions dominantes. La firme joue donc probablement un gros coup de bluff : qui imaginerait que le gouvernement chinois autoriserait Google à sortir de sa politique de censure du web ? Qui croirait un instant que Google tournerait définitivement le dos à un marché de plus de 300 millions d'internautes, le plus grand marché au monde ? Et quel poids possède Google dans les négociations, écrasé par Baidu qui totalise 77% des parts du marché de la recherche Internet en Chine ?

De plus en plus d'entreprises font le choix d'utiliser de l'authentification forte, afin de garantir une sécurité qui n'est aujourd'hui plus assurée par un simple mot de passe. Celui-ci est en effet facilement trouvable par un attaquant, que ce soit par ingénierie sociale, keylogging, cassage par force brute ou rainbow tables ...

Ce que l'on nomme authentification forte est la combinaison de deux facteurs d'authentification parmi les trois suivants :

• Ce que je sais : c'est dans cette catégorie qu'entre le mot de passe ;
• Ce que je possède : il peut s'agir ici d'une carte à puce, à bande magnétique, RFID ou encore d'un token USB ;
• Ce que je suis : il s'agit ici d'éléments biométriques, qui peuvent être l'empreinte digitale, l'empreinte rétinienne, ou encore la paume de la main.

Dés lors, si l'on souhaite mettre en place un mécanisme d'authentification forte, il faut réunir deux de ces facteurs. Une combinaison souvent rencontrée est l'association d'une carte à puce ou d'un token usb (contenant les données d'identification de l'utilisateur, le plus souvent un certificat X.509), avec un code PIN permettant de la/le déverrouiller (combinaison "ce que je possède" + "ce que je sais").

Toutefois, on constate de plus en plus l'apparition de la biométrie dans la chaîne, et plus particulièrement des empreintes digitales, remplaçant le code PIN pour le déverrouillage de la carte à puce (combinaison "ce que je possède" + "ce que je suis"). Cette biométrie a plusieurs atouts comparé au mot de passe :

• l'utilisateur n'a pas à se souvenir d'un mot de passe compliqué ;
• l'utilisateur se fait plus difficilement voler son empreinte digitale.

L'utilisateur se sent ainsi plus en sécurité, en plus d'avoir gagné un certain confort d'utilisation. Mais l'est-il vraiment ?

Tout d'abord, il a été prouvé qu'il est facile de reconstituer une empreinte digitale trouvée par exemple sur un verre, afin de tromper un lecteur d'empreintes peu regardant.

Ensuite, l'utilisation de la biométrie en France est règlementée par la CNIL. Concernant les gestions d'accès par empreinte digitale, la CNIL stipule que les informations biométriques d'un utilisateur ne doivent pas être centralisées dans une base de données. Dans notre cas de figure, celles-ci doivent donc être stockées sur la carte à puce. Ceci peut alors poser un problème lors de l'implémentation logicielle de l'authentification forte.

Dans le cas où l'authentification forte repose sur un couple carte à puce / code PIN, il peut être intéressant pour le confort des utilisateurs d'ajouter la possibilité de déverrouiller la carte à puce par le biais de leur empreinte digitale. La vérification des données biométriques peut alors s'effectuer dans l'application gérant l'authentification, donc au niveau du poste utilisateur. Cette implémentation pose les problèmes suivants :

• les données biométriques de l'utilisateur doivent être disponibles sur la carte à puce en lecture pour tout le monde (pour que le programme puisse y accéder pour comparaison). Celles-ci peuvent bien sûr être chiffrée, et l'application dispose de la clé permettant de les déchiffrer ;
• une fois l'utilisateur reconnu, l'application doit être à même d'envoyer une information (par exemple un code PIN) à la carte afin de déverrouiller les informations qu'elle contient, et ainsi authentifier l'utilisateur. Pour cela, l'application doit connaître cette information. Celle-ci est donc tout naturellement stockée, en lecture pour tout le monde (chiffrée là aussi), sur la carte à puce.

L'introduction de la biométrie introduit alors une baisse de la sécurité du système; il suffit en effet de disposer de la carte à puce pour retrouver l'information (donc souvent le code PIN, en ayant récupéré la clé de chiffrement de l'application), et s'authentifier.

Une façon sécurisée de mettre en place ce type d'authentification forte (biométrie + carte à puce) est alors la technologie Match On Card, permettant d'effectuer la vérification de l'empreinte digitale directement au sein de la carte à puce. On s'assure alors que c'est la carte qui gère le déverrouillage du certificat d'authentification, uniquement si l'empreinte présentée correspond à celle enregistrée.

La biométrie est donc une technologie intéressante avec ses avantages et ses limites pour gérer des authentifications, mais comme toujours, tout dépend de l'implémentation.

Fervent utilisateur de Facebook depuis quelques semaines, j’ai très vite succombé à ses charmes, et ai également vite pu constater l’ampleur des dégâts en matière de sécurité. Et au fond, je crois qu’il ne faudra jamais attendre de Facebook (ou de tout autre réseau social personnel) qu’il développe chez ses utilisateurs une quelconque culture de la sécurité face aux risques qu’il porte : la sécurité est tout simplement antinomique de Facebook, pour des raisons intrinsèques au réseau.

Il n’y aura jamais de contrôles d’identité sur Facebook. Le premier réseau social qui mettra en place des contrôles d’identité réels à l’inscription se suicidera. Ce n’est pas une question de moyens : aujourd’hui il est évidemment impensable de demander aux utilisateurs de Facebook de fournir à l’entreprise une copie de leur carte d’identité à chaque inscription ; mais même à l’avenir, lorsque ces contrôles seront automatisables par l’informatisation des documents d’identité nationaux, aucun réseau social majeur n’y prêtera attention : la raison est toute simple, un réseau social existe d’abord parce qu’il offre un espace de liberté suffisant à ses utilisateurs pour leur permettre de changer d’identité. Et contrairement aux déclarations publiques de certains, il existe mille raisons légitimes pour changer d’identité : signer un article sous un pseudonyme, par exemple, est une pratique extrêmement répandue dans la presse et qui ne choque personne ; de même qu’adopter un surnom fantaisiste est à la racine même de tous les systèmes de messagerie instantanée, à commencer par les systèmes de radio amateur, des décennies avant la généralisation d’Internet. De plus, changer d’identité ne signifie évidemment pas usurper une identité.

Il n’y aura pas d’authentification forte avant longtemps – voire jamais. Là encore, l’authentification forte contredit l’un des piliers des réseaux sociaux personnels : la gratuité. N’oublions pas que Facebook a recherché sa rentabilité organique pendant des années, et que ce n’est que tout récemment que l’entreprise a commencé à gagner de l’argent autrement qu’en attirant des investisseurs. Il est donc très loin, le jour où Facebook dépensera ne serait-ce que quelques Euros pour déployer un token d’authentification à chacun de ses 200 millions d’utilisateurs. Inconcevable également, l’option de rendre Facebook payant : le réseau disparaîtrait en quelques semaines en perdant 95% de ses internautes, qui se reporteraient sur des équivalents gratuits. L’authentification par mot de passe, reconnue comme obsolète depuis des années et attaquée par tout cheval de Troie qui se respecte, a donc encore de beaux jours devant elle, et les comptes Facebook continueront d’être usurpés en masse par les criminels.

Il n’y aura jamais de modération adéquate. Il faudrait rien moins qu’une armée pour modérer le réseau de façon préventive : ne serait-ce que lire un échantillon d’un dixième de pourcent des messages échangés quotidiennement sur Facebook relève des douze travaux d’Hercule. Du côté de la modération corrective, point d’espoir non plus : d’une part, les signalements d’abus sont extrêmement rares, trop rares pour faire remonter à la surface les dérives vraiment graves sur le réseau ; d’autre part, la fermeture d’un groupe / d’une page / d’un profil sont des évènements vécus comme traumatisants pour les principaux concernés, et la société évite donc les fermetures inconsidérées sur un simple signalement, et privilégie les cas graves ; enfin, et c’est sans doute la raison principale : Facebook est devenu le pendant libertaire de sociétés de plus en plus sous contrôle. Les évènements qu’on ne peut pas écrire dans la presse ou commenter en public, par l’effet de la censure, on les relate sur Facebook ; les opinions contestataires, pratiques marginales, ou simplement les coups de gueule qu’on n’ose pas exprimer en public, on les libère sur Facebook. Facebook est devenu l’un des réceptacles de notre droit à l’irresponsabilité et à la contradiction, et le jour où il faudra s’y conduire de manière responsable et cohérente, le réseau s’effondrera tout seul.

Et enfin, les salariés utiliseront toujours Facebook sur leur lieu de travail. Non pas parce qu’il est difficile de bloquer l’accès à ce site – c’est techniquement très simple ; non plus en raison du prétendu choc des générations, les « jeunes » - la fameuse « génération Y » - étant soupçonnés d’allergie massive à l’autorité et aux pratiques managériales traditionnelles ; mais d’abord parce que l’usage de Facebook sur le lieu de travail n’est pas une question de sécurité, mais de productivité. Qu’un salarié utilise Facebook sur son lieu de travail ou à la maison, le risque est le même, en termes de fuites d’information. S’il a l’intention de commenter publiquement son travail, il le fera de toutes façons, et peut-être même de manière encore plus virulente à la maison s’il en a été empêché sur son lieu de travail. Le véritable enjeu, c’est sa productivité, le temps qu’il y passe en ne travaillant pas ; mais sur cette route, Facebook est loin d’être le seul gouffre de productivité sur le web, et suivre ce raisonnement jusqu’au bout reviendrait à filtrer les flux à base d’une liste blanche de sites dédiés à l’activité professionnelle du salarié, en interdisant tous les autres sites. En dehors de certains cas très précis, un tel filtrage en liste blanche est globalement impensable, l’activité quotidienne de beaucoup de salariés reposant sur la consultation de sources d’information sur le web, impossibles à identifier au préalable.

Il me paraît ainsi évident que le principe même de sécurité est incompatible avec Facebook. Mais au final, est-ce si grave ?

La lecture du billet de l'ISC de ce matin rappelle une astuce que nous avions récemment rencontrée lors de l'analyse d'un document PDF malveillant.

Celui-ci explique une méthode un peu particulière de shellcode dans un document PDF exploitant la dernière vulnérabilité 0-day dans Adobe Reader (Réf. Lexsi 12676). En effet, celui-ci est d'une taille très réduite (38 octets uniquement), et va effectuer une recherche à travers les pages mémoires du processus, jusqu'à trouver un certain motif, puis sauter à l'adresse de celui-ci, pour continuer l'exécution. Le-dit motif se trouve dans un objet de type flux compressé du document PDF malveillant. Le second shellcode a pour effet de décoder puis lancer deux exécutables, eux aussi contenus dans le PDF. Le premier va provoquer l'ouverture d'un document PDF non malveillant, tandis que le second est un malware tentant de se connecter à un canal de contrôle.

La méthode que nous avions rencontrée est sensiblement identique. La vulnérabilité exploitée est alors un débordement de tampon dans le tas dans la gestion des fichiers U3D (Réf. Lexsi 12415), et la technique du heap-spraying est employée, afin de mettre en forme le tas pour y rediriger l'exécution. Un coup d'oeil rapide au document nous montre que le shellcode injecté dans le tas est le suivant :

Une fois celui-ci chargé dans le débogueur, nous nous trouvons face à un début plutôt classique (pour de plus amples détails, voir cette précédente analyse de shellcode) :

• une boucle se charge de déchiffrer la suite du shellcode par un XOR avec la valeur "0xF9"

• ensuite, celui-ci va rechercher les adresses de plusieurs fonctions de l'API Windows

L'étape suivante est plus intéressante : le shellcode va effectuer un brute-force des descripteurs de fichiers ouverts, jusqu'à en trouver un dont l'entête de fichier correspond à celle d'un document PDF, puis vérifier la présence de certains motifs à certains offsets.

Ceci va lui permettre de disposer d'un handle vers le document PDF malveillant, et une fois celui-ci obtenu, d'extraire puis de décoder un second shellcode en le recherchant à un offset bien précis. La suite est très similaire à l'analyse de l'ISC : le second shellcode va ouvrir un document PDF légitime et exécuter un binaire de type downloader inclus dans le PDF malveillant.

Cette méthode permet de rechercher un deuxième étage de shellcode de façon plus fiable qu'un parcours complet des pages mémoires du processus, dans lesquelles il existe un risque de trouver une suite d'octet correspondant au motif recherché sans pour autant que ce soit le début du shellcode, ou encore de provoquer une erreur en accédant à de la mémoire non mappée.

Une proposition de loi américaine, approuvée début novembre par le House Financial Services Committee, vise à rendre responsables les fournisseurs d’accès Internet de la protection de leurs utilisateurs contre les contenus à caractère usurpatoire ; notion suffisamment large pour englober à la fois l’usurpation de marque, la contrefaçon de site, le phishing, etc. Cette proposition de loi prévoit ainsi de contraindre les FAI à filtrer ces contenus lorsqu’ils transitent sur leurs réseaux.

Cette proposition de loi laisse perplexe la plupart des fournisseurs d’accès américains, car le texte du Congrès est particulièrement vague sur les moyens pouvant être mis en Å“uvre pour assurer la conformité à cette loi : qui aura l’autorité pour désigner un contenu devant être filtré ? Quel type de filtrage est acceptable – IP, DNS, inspection en profondeur du trafic réseau ? Le texte ne fait pas non plus de distinction entre les FAI de détail (particuliers et entreprises) et les FAI de transit (assurant la connectivité des réseaux), et ne dit rien non plus quant aux dommages collatéraux lors du filtrage erroné d’un site légitime, ce qui ne manquera pas de se produire.

Cette nouvelle arrive peu de temps après la signature d’un accord entre les quatorze principaux FAI néerlandais, représentant 98% du marché des Pays-Bas : ces fournisseurs d’accès se sont entendus sur le principe de la notification des internautes en cas de détection d’un trafic Internet généré par un virus ou un cheval de Troie ; les mesures prises par les FAI pouvant aller jusqu’à la mise en quarantaine de la connexion affectée.

Ces mesures, qui commencent à être prises à grande échelle, et plus sous la seule impulsion des forces de l’ordre (blocage de sites pédo-pornographiques ou de sites de jeu d’argent en ligne) et des maisons de disque, entérinent la fin d’une certaine idée de l’Internet : c’est le concept de neutralité du réseau qui disparaît.

Alors, pour ou contre ? Tout dépend évidemment de ce qui est filtré, et dans quelles circonstances ; peu de gens iront blâmer les FAI pour le filtrage des sites pédophiles ou des malware. Certains pensent qu’entrer dans cet engrenage, c’est ouvrir la boîte de Pandore : du moment que le dispositif de filtrage existe, même mis en place initialement à des fins légitimes, alors la tentation de la censure sera telle que les Etats y succomberont un jour ou l’autre. N’anticipons pas outre mesure, l’Histoire nous le dira bien assez tôt ; en ce qui me concerne, je considère que c’est la fin d’une certaine forme d’irresponsabilité collective, et peut-être le début d’une prise de conscience qu’Internet n’a jamais été un média neutre, son instabilité pouvant mettre en péril entreprises, particuliers, services civils d’urgence (police, pompiers, hôpitaux, …). Un péril qui n’a rien de virtuel, celui-là.

Un ver se propage actuellement sur les iPhone jailbreakés, exploitant le fait que peu de gens ont pensé à changer leur mot de passe root suite à l'installation du serveur SSH.

Jailbreaker un iPhone (ou un iPod Touch) est une opération consistant à sortir de la sandbox dans laquelle l'utilisateur et ses applications se situent normalement dans le but d'exécuter du code en tant que root et prendre ainsi le contrôle total de l'appareil. Une fois l'opération réalisée, l'installation de paquets se réalise souvent via Cydia, une interface graphique de gestion des paquets. Les problèmes commencent lorsque l'utilisateur décide d'installer OpenSSH, ouvrant ainsi l'accès distant aux comptes hardcodés de l'iPhone, dont le fameux root:alpine.

La méthode d'attaque est triviale : scan d'IP à la recherche de systèmes ayant le port 22/tcp ouvert, tentatives de connexion SSH sous le compte root:alpine et exécution de commandes en tant que root. Récemment, il a été fait état d'un chantage aux Pays-Bas, un utilisateur peu scrupuleux ayant pris le contrôle de certains iPhone par ce biais et demandant 5 euros à ses victimes afin de leur indiquer comment mieux sécuriser leurs téléphones (il est aujourd'hui revenu sur sa décision et sa page montre simplement comment supprimer les traces de son application malveillante).

On vient de passer à l'étape suivante avec la propagation du ver Ikee exploitant exactement la même méthode. Le code source de ce ver a été rendu public pendant un moment mais l'accès est désormais suspendu. Plusieurs variantes sont cependant déjà en circulation (quatre au moment de la rédaction de ce billet).

Pour sa propagation, Ikee utilise plusieurs méthodes de génération d'adresses IP :

• des adresses "proches" de l'IP du périphérique sur lequel il est en train de s'exécuter

   char *locRanges = getAddrRange(); // cette fonction appelle getifaddrs() permettant d'obtenir les IP des interfaces
   char *lanRanges = "192.168.0.0-192.168.255.255";

• des plages codées en dur, principalement Australiennes (opérateurs Vodaphone, Optus et Telstra)

   char *vodRanges1 = "202.81.64.0-202.81.79.255";
   char *vodRanges2 = "23.98.128.0-123.98.143.255";
   char *vodRanges3 = "120.16.0.0-120.23.255.255";
   char *optRanges1 = "114.72.0.0-114.75.255.255";
   char *optRanges2 = "203.2.75.0-203.2.75.255";
   char *optRanges3 = "210.49.0.0-210.49.255.255";
   char *optRanges4 = "203.17.140.0-203.17.140.255";
   char *optRanges5 = "203.17.138.0-203.17.138.255";
   char *optRanges6 = "211.28.0.0-211.31.255.255";
   char *telRanges = "58.160.0.0-58.175.255.25";

• des adresses IP tirées au hasard

L'infection par ce ver particulier ne pourra donc avoir lieu que si le périphérique vulnérable dispose d'une IP routable sur Internet. Une fois trouvé un port 22/tcp ouvert, il tente la connexion en tant que root :

asprintf(&execLine, "sshpass -p %s ssh -o StrictHostKeyChecking=no root@%s 'echo 99'", VULN_PASS, host);

S'il reçoit bien un message contenant 99 en retour, le périphérique en face est bien vulnérable et la procédure d'infection peut être lancée. Les variantes actuelles d'Ikee ne sont pas réellement malveillantes et se contentent de modifier le fond d'écran en mode verrouillé vers une image de Rick Astley. Le ver termine également le service OpenSSH et va jusqu'à supprimer le binaire /usr/sbin/sshd, empêchant de fait un autre attaquant ou ver d'exploiter la même faille :

    if (!(in = popen("rm -f /usr/sbin/sshd; killall sshd", "r"))) {

Ironiquement, on peut donc dire que le téléphone est plus sécurisé après l'infection qu'avant

Les recommandations d'usage sont évidemment de ne pas jailbreaker un iPhone si celui-ci contient des données sensibles (téléphone professionnel par exemple), de ne pas y installer de serveur SSH ou alors de bien penser à modifier son mot de passe root.

Depuis quelques jours circule un courriel semblant provenir de l'équipe technique Facebook. Mais sa pièce jointe n'est autre qu'une variante du downloader Bredolab, déjà connu pour installer d'autres logiciels malveillants (Waledac, Daurso, Koobface, etc).

Voici un exemple de message (que vous avez aussi certainement reçu) :

Le message fait croire à l'utilisateur que son mot de passe Facebook a été changé et que le nouveau est dans la pièce jointe (ici Facebook_Password_6dd19.zip). Celle-ci contient un simple fichier .exe qui se révèle bien entendu malveillant.

En analysant rapidement le malware, on se rend compte qu'il s'injecte dans des processus Windows, via la méthode classique OpenProcess/VirtualAllocEx/WriteProcessMemory/CreateRemoteThread :

Sur la figure ci-dessus, il demande un handle sur le processus 0x478 (explorer.exe sur notre système de test). Après avoir réalisé les appels à WriteProcessMemory pour recopier le code malveillant dans ce processus, le thread distant est ensuite créé :

Bredolab n'est qu'un downloader ; cet échantillon se connecte au domaine mmsfoundsystem[dot]ru par HTTP afin de télécharger et exécuter d'autres logiciels malveillants :

Afin d'assurer son lancement au prochain redémarrage, il se contente de se recopier dans le dossier Démarrage de l'utilisateur :

Comme indiqué dans un précédent billet, l'outil MSRT de Microsoft est documenté comme supportant Bredolab ; notre échantillon est effectivement détecté comme TrojanDownloader:Win32/Bredolab.X :