Un trou de sécurité dans Android...c’est à voir!

Vous avez tous entendu parlé de la possibilité d'installer une application Android malveillante (bug 8219321 et bug 9695860) en la signant avec une application bien officielle.

Pour plus de détails voir le blog de Jay Freeman (@saurik)

On trouve également sur le github de Fuzion24 quelques "apk" (comprendre applications Android) modifiés qui permettent d'installer une application malveillante signée en utilisant ces bugs.

Essayons les!

On copie d'abord l'"apk" sur notre téléphone puis on installe l'application.

On obtient alors un magnifique message en provenance du Google Play Store nous informant que cette application est malveillante car elle exploite un bug connu, et que l'installer c'est prendre un très gros risque!

Continuons tout de même!

On obtient alors un message nous informant que notre paramétrage interdit l'installation des applications en dehors du Google Play Store.

Conseil: vérifier le paramétrage de votre téléphone permettant d’interdire l’installation d’applications en dehors du Google Play Store

Quant on sait que Google affirme qu'il n'y a aucune application compromise dans le Google Play Store, le risque semble faible

Déception! Ou pas!

Maintenant toutes ces manipulations m'ont donné une idée!

Pré-requis: Imaginons que le paramètre "USB Debugging" que l'on peut trouver dans "Settings / Developer Options" soit activé. Vous avez par exemple eu besoin d'afficher l'écran de votre téléphone sur votre ordinateur (pour plus d'informations voir "Afficher l’écran de votre téléphone sur votre ordinateur") et vous n'avez pas désactivé l'option.

Dans ce cas, l'attaquant peut installer son environnement Android sur sa clef USB et lancer l'installation de l'"apk" à partir de sa clef. A condition bien sûr que la cible ait son téléphone connecté en USB sur son PC (pour recharger son téléphone ou bien transfèrer des données comme des photos par exemple). Alors si l'attaquant réussi à connecter sa clef USB sur le PC de la cible et à executer son programme, c'est gagné.

En effet si je lance la commande:

> adb install -r SecurityDemo.apk

alors l'installation réussie.

Une autre approche consiste à inciter votre cible à connecter son téléphone sur votre PC.

Référez vous au blog "La clef USB: le maillon faible ?" qui décrit quelques techniques permettant d'automatiser l'exécution de commande à partir d'une clef USB.

La charge utile pour installer et lancer l'application malveillante pourrait alors ressembler à:

> nircmd.exe execmd /Android/SDK/platform-tools/adb install -r /Android/Projects/SecurityDemo/bin/SecurityDemo.apk
> nircmd.exe execmd /Android/SDK/platform-tools/adb shell am start -n com.proxia.securitydemo/com.proxia.securitydemo.SecurityDemo

Il est aussi possible pour faire disparaître les traces de notre passage d'arrêter l'application et de la désinstaller avec les commandes suivantes:

> adb shell am force-stop com.proxia.securitydemo
> adb uninstall com.proxia.securitydemo

Et ca marche!

Social Engineering Toolkit (Partie II: le site web malveillant)

Dans notre série "découverte de SET” (Social Engineering Toolkit) nous allons nous intéresser à la création d'une page web contenant un code malveillant permettant de prendre la main sur la machine de la victime.
Une fois l'accès permis, nous allons récupérer les mots de passe de la victime en utilisant le bon vieux "John The Ripper".

Après avoir configuré SET (en utilisant notre Backtrack 5 préféré) pour générer une fausse page web, et après avoir choisi le type de charge utile, nous lançons le serveur nous permettant d'attendre patiemment la connexion de la machine de la victime.

Dans cet article nous ne nous intéressons pas aux moyens permettant de provoquer le "clic" de la victime sur notre fausse page web. Mais comme vous le savez il en existe de nombreux comme par exemple l'envoi d'un mail de phishing ciblé ou l'utilisation des réseaux sociaux.

Le scénario est donc le suivant:

• la victime clique sur la page web
• le browser s'arrête brutalement
• un faux exécutable est lancé à l'insu de la victime (la machine est corrompue)
• l'attaquant prend la main sur la machine de la victime

La vidéo ci-dessous décrit les détails de cette attaque et de sa configuration:

Prenons le cas où le compte de la victime a des droits "utilisateur" alors l'attaquant accède à la machine mais il lui est nécessaire de mettre en œuvre une élévation de privilèges pour accéder aux mots de passe.
Si le compte de la victime a les droits "administrateur" alors tout devient plus simple; l'attaquant accède directement au fichier des mots de passe.

Il ne lui reste alors plus qu'à utiliser John The Ripper pour découvrir le mot de passe "administrateur" de la machine (et ce n'est qu'un exemple).

Pour information le test a été fait avec un Windows XP SP3 et Internet Explorer 6 (selon SET cette attaque fonctionne également avec IE 6, 7, 8, 9 et Firefox).

Est-il nécessaire de rappeler les règles élémentaires de protection? Non bien sûr, vos droits, lorsque vous surfez sur internet, ne sont pas des droits "administrateur"!

Je veux et j’exige les droits “administrateurs”!

Comme la plupart des développeurs j’ai besoin des droits “administrateurs” sur mon PC. Sinon, c’est bien simple, je ne peux pas travailler dans de bonnes conditions. En tout cas c’est que j’affirme haut et fort à qui veut l’entendre !

Le choix d’avoir les droits administrateur sur son poste de travail présente effectivement de nombreux avantages mais aussi quelques dangers.

Dans ce qui suit nous allons montrer une des nombreuses actions offensives qu’il est possible de réaliser avec quelques lignes de code sans beaucoup de complexité.

Au lieu d’essayer de cracker le mot de passe “administrateur” de notre développeur imprudent, nous allons simplement ajouter notre propre utilisateur “local” avec les droits “administrateurs” en profitant des privilèges locaux.

Dans ce qui suit nous faisons l’hypothèse que l’attaquant est en contact direct avec la cible. Il va ainsi pouvoir exécuter le code malicieux permettant de créer notre compte utilisateur “pirate”.

Les moyens à la disposition du pirate peuvent s’appuyer sur une clef USB, un CD ou un DVD (si l’autorun n’est pas désactivé sur le poste de la cible) ou sur le partage d’une application embarquant notre code malicieux (un jeu, un utilitaire,…) via une clef USB, un CD ou un DVD (cf l’article La clef USB: le maillon faible ?).

Vous trouverez ci-dessous le code nécessaire:

Ce code permet de:

• désactiver momentanément le son du PC cible
• ajouter les utilisateurs en fonction des informations stockées dans le fichier “myusers.txt”
• donner le droit de “Interactive Logon” à l’utilisateur hacker1. Cette commande n’est pas nécessaire dans notre contexte car les membres du groupe “Administrators” possède déjà ce droit (elle peut cependant être utile dans d’autres cas).

Vous trouverez ci-dessous le contenu du fichier “myusers.txt”

Ce fichier permet de:

• créer 2 utilisateurs: hacker1, hacker2
• donner les droits administrateurs à hacker1 et hacker2

Ce code a été testé avec succès sous Windows XP SP3 et Windows 7 (avec la fonction UAC, User Access Control, désactivée cependant).

Est-il vraiment nécessaire de conclure ?

Tags:

BuzzNet Tags: AutoIt,hacking

Technorati Tags: AutoIt,hacking

del.icio.us Tags: AutoIt,hacking

Forger des PDFs malveillants avec Origami

Dans cet article nous allons voir comment créer des PDFs malveillants en utilisant Origami. Origami est un ensemble d'outils en Ruby permettant d'analyser et de forger des documents PDF.

La vidéo ci-dessous décrit succintement comment utiliser Origami pour forger un PDF malveillant.

Vous pouvez télécharger ci-après 2 exemples de PDFs malveillants:


PDF contenant l'exécution de code Javascript et lancement du browser

PDF contenant le lancement de l'application "calc.exe"

D'une manière générale pour éviter d'avoir des applicatifs présentant des failles de sécurité, vous devez posséder un outil comme Secunia permettant de détecter les mises à jour de sécurité disponibles pour les applicatifs installés sur votre machine.

Dans un prochain article nous verrons comment, avec Origami, il est possible d'analyser les fichiers PDF afin d'y découvrir d'éventuels dangers. Mais c'est une autre histoire...!


Source: http://security-labs.org/origami/ de Guillaume Delugré & Fred Raynal. Merci également à Laurent Butti.

Quand Metasploit joue au Keylogger!

Au travers de cet article nous allons découvrir que Metasploit permet aussi de faire du keylogging à distance.

L'attaque se passe en trois temps. La première étape consiste à exploiter une faille présente sur la machine cible (dans notre cas un Windows XP SP2). La faille choisit est la faille MS08-067.
La deuxième étape consiste à injecter la dll qui nous permettra de faire du keylogging sur le poste cible. La dernière étape consiste à exploiter cette faille en associant le keylooging aux processus qui fonctionnent sur la machine cible et que l'on veut surveiller. Dans le cadre de la vidéo nous associons notre keylogger aux processus "explorer.exe" et "winlogon.exe".


Afin de décrire en quoi consiste la faille MS08-067, vous trouverez ci-après un extrait du bulletin de sécurité Microsoft MS08-067 paru le 23 octobre 2008:

"Cette mise à jour de sécurité corrige une vulnérabilité signalée confidentiellement dans le service Serveur. La vulnérabilité pourrait permettre l'exécution de code à distance si un système affecté recevait une requête RPC spécialement conçue. Sur les systèmes Windows 2000, Windows XP et Windows Server 2003, un attaquant pourrait exploiter cette vulnérabilité pour exécuter du code arbitraire sans nécessiter d'authentification. Il serait possible d'utiliser cette vulnérabilité dans la création d'un ver. Les meilleures pratiques en matière de pare-feu, ainsi que les configurations par défaut des pare-feu, contribuent à protéger les ressources réseau contre les attaques lancées depuis l’extérieur de l’entreprise.

Il s'agit d'une mise à jour de sécurité de niveau « critique » pour toutes les éditions prises en charge de Windows 2000, Windows XP, Windows Server 2003 et de niveau « important » pour toutes les éditions prises en charge de Windows Vista et Windows Server 2008."

Pour information les bulletins de sécurité de Microsoft peuvent être consultés à l'adresse suivante: http://www.microsoft.com/france/technet/security/bulletin/default.mspx

Sur ce site vous avez la possibilité de vous abonner aux newsletters et alertes Sécurité Microsoft.

Pour ceux qui ne sont pas familier avec les processus de Windows, l'explorateur Windows ("explorer.exe") est l'application utilisée dans le système d'exploitation Windows pour l'affichage, l'exploration et l'utilisation des fichiers et répertoires.

Quant à "winlogon.exe", c'est un composant de Windows qui gère l'ouverture et la fermeture de session, et le "Ctrl-Alt-Delete".
En particulier, il charge le profil d'un utilisateur après qu'il se soit authentifié, et il gère l'écran de veille.

Vous trouverez ci-dessous la vidéo de l'exploit:

D'une manière générale pour éviter d'être la cible de ce type d'attaque vous devez avoir un pare-feu personnel mis à jour.

Bien entendu votre pare-feu peut lui même être la cible d'attaque afin de vous laisser croire qu'il contrôle la situation alors qu'il a été désactivé. Mais ceci est une autre histoire...!

La clef USB: le maillon faible ?

Dans cet article nous allons décrire comment préparer une clef USB pour récupérer des informations sur la machine de notre utilisateur "cible"


Première étape

La première étape consiste à créer le "malware".

Les fichiers qui composent le "malware" sont les suivants:
· autorun.inf
· nircmd.exe
· malware.bat
· folder.ico
· payload.exe

Quelques mots sur l'"autorun.inf". Ce fichier permet de lancer automatiquement une application lors de l'insertion de la clef USB. C'est ce comportement que nous allons utiliser pour exécuter notre "malware".

Cepandant, la fonctionnalité "autorun" peut être désactivé sur la machine "cible" pour des raisons de sécurité que l'on comprend aisément.

Dans ce cas l'"autorun.inf" est malgré tout exécuté lorsque l'utilisateur essaie d'explorer le contenu de la clef avec l'explorateur (double-click sur "My Computer", puis double-click sur la clef USB).

Notre fichier « autorun.inf » est configuré de telle façon que lors de l’insertion de la clef USB, l’utilisateur est averti et on lui demande de confirmer l’ouverture. Le message « Open folder to view files » est affiché et sélectionné par défaut.

Ce message est celui défini dans le fichier « autorun.inf ». L’icône associée est une icône qui représente un répertoire (c’est l’icône « Folder.ico ») définit dans le fichier « autorun.inf ».

Le comportement semble tout à fait normal pour l’utilisateur mais en réalité en choisissant d’ouvrir le contenu de sa clef USB, l’utilisateur choisit d’exécuter le « malware ». La commande exécutée est celle décrite dans le fichier « autorun.inf ».


La ligne de commande utilise un outil appelé « nircmd.exe » disponible à l’URL suivante : http://www.nirsoft.net/utils/nircmd.html . Cet outil permet d’exécuter quelques tâches sans afficher d’interface utilisateur. L’option « execmd » permet d’exécuter une commande Windows. C’est cet outil que nous utilisons pour exécuter notre commande « CALL malware .bat ».

Le fichier « malware.bat » lors de son exécution permet de faire 3 opérations essentielles. La première consiste à cacher les fichiers qui ont été copiés sur la clef USB par le pirate (attrib + H fichier).

La deuxième permet d’ouvrir le contenu de la clef ; c’est le comportement attendu par l’utilisateur (start .).

La troisième et dernière permet d’exécuter la charge utile (CALL payload.exe).

La charge utile correspond au fichier « payload.exe ». Cet exécutable n’est pas présenté dans cet article. Mais il pourrait réaliser les opérations suivantes :
- voler les mots de passe Internet Explorer de l’utilisateur « cible »
- copier des fichiers systèmes
- installer un malware (permettant de prendre le contrôle de la machine)
- transférer des données privées sur la clef USB pour une récupération ultérieure ou sur un serveur « pirate »

Nous allons nous intéresser dans ce qui suit à la récupération de données privées sur la clef USB à l’insu de l’utilisateur.

Deuxième étape

La deuxième étape consiste à infecter la clef USB avec un "malware".

Cette étape peut être facilement réalisée en développant un petit logiciel qui sur détection de l’insertion d’une clef USB copie les fichiers du « malware » sur la clef.

Troisième étape

La troisième étape est l'exécution du malware sur le poste "cible".
Comme nous l’avons vu précédemment lors de l’insertion de la clef sur le poste « cible », l’utilisateur voit apparaître la fenêtre suivante qui correspond au comportement habituel lié à l’insertion de sa clef.

Si l’utilisateur est prudent (et même les plus avertis d’entre eux le sont rarement ; nous l’avons testé pour vous…), il peut remarquer que l’option « Open folder to view files » se trouve à 2 endroits dans la liste. Un utilisateur paranoïaque peut également remarquer que la première option fait référence à un exécutable qui se trouve sur la clef USB (ce qui bien entendu ne devrait pas être le cas).

Quatrième étape

La dernière étape consiste à récupérer les données
Comme pour la corruption de la clef avec le « malware » la récupération des données fonctionne sur le même principe : lors de l’insertion de la clef sur le poste « pirate », le logiciel détecte l’insertion de la clef et la présence éventuelle des données piratées. Si les données sont présentes elles sont alors copiées sur le poste « pirate ».

Prox-IA est à votre entière disposition pour vous fournir des informations complémentaires sur ce thème.

Source: MISC