Avast 5 : Détection du Sandbox

Bonzour, ce n'est pas dans mes habitudes ce genre d'interventions. Mais je pense tout de même que c'est mon autre coté diabolique qui prend le dessus actuellement à travers cette entrée Blog, bref.. Diable je peux devenir parfois :)

La firme Tchécoslovaque Alwil a présenté dernièrement une toute nouvelle version de leur antivirus Avast. Le passage de la version 4.8 vers la version 5.0 leur a demandé presque une année de travail intensif, bien-sur que ce n'est pas toujours facile, même pour une équipe de 30 ou 40 développeurs aussi chevronnés que les leurs. Après avoir installé, leur nouvel antivirus et fait le tour sommairement, les 1ère impressions ont été positives dans leur globalités, même si elles manquent de précision :

• L'habillage et le nouveau moteur visuel GUI est très beau et très bien soigné. Ils ont battu tout le monde sur ce niveau. Kaspersky Labs utilise depuis des années cette même méthode d'habillage HTML, mais l'idée d'aller utiliser très intelligemment le composant HTML Layout s'avère plus payante et moins complexe à maintenir.
• Le Kernel Antivirus est maintenant "presque" multi-moteurs : ils y sont presque enfin :)
• Toujours adeptes de la compression ZLib pour les bases de données ?
• Support Heuristiques ? Donc support While List ? ah bon c'est le pourquoi du SQLite 3 :)
• Le Support WEB Sandboxing est une excellente nouvelle idée. Bravo pour l'idée, même si le Hooking à la méthode Sandboxie ne permet pas la portabilité de ce module sur Unix et dérivés.
• Le support Win32 est vraiment tout nouveau pour la boite Alwil, ont ils fait de nouveaux recrutements pour cette tâche ? Bon, à 1ère vue, le moteur Win32 Sandbox est vraiment très immature :)

Maintenant laissons place à l'œil du Diable hehe..

char IsAvast_5_SandBox(void)

{
char szFileName[MAX_PATH];

GetModuleFileName(NULL,szFileName,MAX_PATH);

if (!strcmp(szFileName,"C:\\emu\tmp.tmp")) return 1;

if (!strcmp(szFileName,"C:\\emu\fajl.exe")) return 1;

return 0;

}

Et si on pouvait atteindre le Kernel d'analyse Avast depuis un code viral ? c'est une bonne idée n'est ce pas ? Mais ne soyez pas trop gourmands Diaboliquement parlant hehe...

Ceci dit, un énorme Bravo tout de même à la firme Alwil avec un grand B; sans oublier comme toujours et sans la moindre hésitation : je les emmerde quand même haha..., bien-sur avec un grand E !!!

La détection algorithmique

La détection de certains virus très complexes, qu'ils soient Polymorphiques ou Métamorphiques, nécessite en effet, un développement de routines de détections dites spécifiques. La détection algorithmique est dans ce cas, une méthode de plus, dans l'arsenal antiviral, qui permet entre autre de couvrir ce genre de menaces illicites. En parlant de cette méthode, je vais citer sommairement quelques exemples, qui en quelques sortes, résument bien l'état actuel de la technologie antivirale.

La détection algorithmique comme méthode de détection antivirale, prouve en effet,toute son importance, spécifiquement contre les virus informatiques dits réplicatifs. Et en parlant de réplication virale, je cible certains PE32 Infectors, qui par leurs natures, sont très difficiles à couvrir que ce soit heuristiquement ou par signatures. D'ailleurs, à mon humble avis, j'estime que cette méthode de détection permet de construire un jugement fiable sur le professionnalisme antiviral de l'équipe de développement de telle ou telle boîte Antivirus; Pourquoi penser de la sorte ? Pour la simple raison, que les antivirus sont entrain de pousser partout dans le monde comme des champignons, et que la chasse aux signatures virales indépendamment des algorithmes de hachage, cache de plus en plus les incompétences humaines dans ce domaine critique. Justement il ya des virus spécifiques qui sont intraitables par les méthodes de détection par signatures. Qu'est ce qu'il reste alors ? Il faut que l'équipe d'analyse et de développement soit capable de déchiffrer tout le fonctionnement interne de la menace et plus encore : être vraiment capable de développer une méthode de détection très efficace et pouvant surtout couvrir toutes les générations infectieuses de cette même menace.

Maintenant, voyons sommairement quelques points de filtrage / d'enclenchement des procédures algorithmiques de détection contre certains virus spécifiques :


Remarque : les nominations des virus sont spécifiques aux FSB Antivirus.



Win9x-Virus/CIH :

• Entry Point qui pointe vers l'epace PE Header : ( EntryPointOffset < IMAGE_SECTION_HEADER.PointerToRawData)

• Code Execution Redirection / Saut d'exécution vers l'espace PE Header, qu'il soit direct à travers un CALL ou un JMP, voir même à travers d'un SEH. ( Scénario que j'ai pas vu à travers les échantillons que j'ai pu analyser, mais bon c'est une spéculation sur un possible scénario d'une possible modification ).
  

Win32-Virus/Virut :

• La valeur du champ IMAGE_FILE_HEADER.Characteristics est différente de IMAGE_FILE_DLL.
  

• La valeur du champ IMAGE_OPTIONAL_HEADER.Checksum est égale à zéro.

• La valeur du champ IMAGE_DOS_HEADER.e_res[] contient des données / marqueurs.

• Entry Point pointe vers la dernière section PE (ou / et) Entry Point intacte mais la dernière Section PE contient des overlays ( C'est différent des Extra données pouvant être introduis par les installateurs ou les archives SFX, mais plutôt des données résultant d'un élargissement de la taille de la section; exemple : Dernière section PE est une section ressources et que la taille de cette section est plus large que la (valeur d'alignement + Taille globale des ressources), ou que la dernière section PE est une section d'Imports et que la taille de cette section est plus large que la (valeur d'alignement + Taille globale des Imports) etc... ).
  

Win32-Virus/Leon :

• Les Imports Data contiennent une entrée qui a été injecté ( PATCHED IAT )
  

• 

• Les Imports Data contiennent une entrée qui a pointe vers la bibliothèque Advapi32.dll et que celle-ci fait appel aux fonctions API Suivantes : CryptAcquireContextA , CryptCreateHash, CryptHashData, CryptDeriveKey, CryptDecrypt .

Win32-Worm/Polip :

• La valeur du champ IMAGE_FILE_HEADER.Characteristics est différente de IMAGE_FILE_DLL.
  

• La valeur du champ IMAGE_OPTIONAL_HEADER.NumberOfSections est strictement supérieure à 2 et strictement inferieure à 11.

• La structure PE SECTIONS HEADER contient une section PE dont les attributs (IMAGE_SECTION_HEADER.Name[0] == NULL) et (IMAGE_SECTION_HEADER.PhysicalAddress <= IMAGE_SECTION_HEADER.SizeOfRawData) et (IMAGE_SECTION_HEADER.SizeOfRawData >= 0x9000) et (IMAGE_SECTION_HEADER.Characteristics == 0xE0000060).

• Optionnellement si l'engin d'émulation le permet bien : Code Execution Redirection vers un espace d'alignement de la section PE en cours d'émulation.

Closing words :

C'était donc juste une petite projection très simplifiée sur l'état des lieux de ce qu'on peut appeler la détection algorithmique appliquée à quelques virus spécifiques. Kaspersky Labs comme boîte antivirus, est une très solide boîte je l'avoue bien, mais un simple coup d'œil sur leurs bases de données actuelles, me laisse par contre très perplexe quant au nombre gigantesque des signatures statiques de Win32-Virus/Virut, j'ai dénombré à peu près, plus de 1500 entrées de signatures rien qu'à lui tout seul !! on comprend bien donc, comment leurs bases puissent contenir plus de 3.400.000 signatures et par conséquent tout le gâchis de ressources mémoires et CPU des moteurs antiviraux de Kaspersky Antivirus :)

Bruno Bouvet, il te faudra surement un peu de temps avant que tu tombes un jour par hasard sur cette page de mon blog :) Mais en attendant que ce jour vienne, saches frère, que malgré les milliers de kilomètres qui nous séparent : tu as été le seul homme sur terre à être toujours présent pour moi sans conditions, alors que ceux qui ont été à quelques mètres près : ne m'ont même pas vu des yeux. Merci Bruno même si tu m'avais dit et sans cesse répété qu'il n'y a pas de Merci entre nous ;) FSB !!! FSB !!! FSB !!! FSB !!!

Le Kernel Antiviral est récursif

Je pense que la maitrise des principaux algorithmes informatiques est une condition fondamentale dans la conception d'un kernel antiviral efficace et performant. Je pense malheureusement aussi qu'un nombre très important de programmeurs négligent encore les fondamentales algorithmiques lorsqu'ils font leur travail.

Dans le cas de la programmation antivirale en général, et des kernels antiviraux en particulier : Il est préférable, voir recommandable et quasi important que le moteur d'analyse soit bâti avec une prise en charge de la récursivité. Bien sur, si je parle d'un antivirus professionnel et commercial avec une prise en charge d'un nombre important de formats de données ( Fichiers exécutables, fichiers scripts, Fichiers compressés etc.. ). Car si le kernel est destiné a traiter divers formats de données, des formats pouvant être combinés ensembles, je ne vois pas comment pourrait-on éviter la récursivité dans ce cas.

Format1 + Format2 = Format3

Objet ZIP + Object PE = Objet ZIP SFX ( Un fichier exécutable qui se transforme en un archive Zip qui se transforme en données décompressées sur le disque dur ).

On peut même aller plus loin :

(Objet Zip1 + Objet Zip2 + Objet Zip3) + (Objet PE + Objet UPX + Objet Aspack) = Objet Zip Sfx !!

tout en sachant que Objet Zip ~= Object PE + Objet HTML + Objet RAR + Objet JPEG + ...Objet n

Je veux dire qu'on peut facilement combiner un format de données vers un autre qu'on pourra ensuite combiner avec un autre et ainsi de suite. Ceci dit, pour pouvoir analyser l'objet de format de données final obtenu : le kernel antiviral se retrouvera dans la contrainte fonctionnelle d'analyse de tous les objets qui ont été combiné un par un !! Donc, jusqu'à maintenant je ne vois pas comment conduire cette tâche correctement sans avoir à passer par la récursivité.

L'entropie statistique au service de la détection Antivirale

Bien, j'ai évolué dans mon projet d'antivirus depuis 2007, je suis sur le plan de créer ma propre boîte Antivirus en collaboration avec un ami français de longue date ( Bruno Bouvet ); j'ai donc donné des nouvelles avant que la question ne se pose par elle même hehe...

L'entropie c'est quoi au juste ? je vais utiliser une définition Thermodynamique que j'ai trouvé sur wikipédia puisqu'elle me parait plus descriptive dans mon esprit littéraire que la définition Informatique de l'entropie de Shanon. La définition Thermodynamique de l'entropie est donc : "...elle mesure le degré de désordre d'un système au niveau microscopique. Plus l'entropie du système est élevée, moins ses éléments sont ordonnés, liés entre eux..."

L'analyse entropique est un outil incontournable dans les domaines de cryptoanalyses ( ciphers outputs & RNG etc...), compressions des données.. Veuillez excusez mes lacunes mathématiques, mais pratiquement parleant : on remarque une relation concrètement directe entre la distribution aléatoire et le taux entropique d'un flux de données, de façon à ce que : plus le flux de données est aléatoire et plus importante est sa moyenne entropique.

Maintenant en parleant de virus et d'antivirus, si vous examinez un peu la page des résultats du scanner en ligne virustotal par exemple, vous allez sans doute rencontrer ce genre de données :

name | viradd | virsiz | rawdsiz | ntrpy | md5

CODE 0x1000 0x13D000 0x6C000 8.00 29cdbb6c32b3eea627f34f62e03feb9e
DATA 0x13E000 0x5000 0x1A00 7.83 89053885934bd7d4262305a02a5afb50
BSS 0x143000 0x3000 0x0 0.00 d41d8cd98f00b204e9800998ecf8427e
.idata 0x146000 0x4000 0x1200 7.77 881c791e3a9e4016a13440626cec1a42
.tls 0x14A000 0x1000 0x0 0.00 d41d8cd98f00b204e9800998ecf8427e
.rdata 0x14B000 0x1000 0x200 0.21 0d91c61ea7a575278f4be61b95f7857d
.reloc 0x14C000 0x16000 0x0 0.00 d41d8cd98f00b204e9800998ecf8427e
.rsrc 0x162000 0xC2000 0x48800 7.97 8b2a2a582af95161ce28806715f43df7
.aspack 0x224000 0x3000 0x2400 5.34 f7f2539e9fa1b75f0b5c9a0ff4937866
.adata 0x227000 0x1000 0x0 0.00 d41d8cd98f00b204e9800998ecf8427e

A travers ce petit dump d'un fichier compressé et crypté par Aspack, la remarque est que la compression introduite par Aspack sur les sections PE de cet exécutable : augmente catégoriquement la moyenne Entropique de ces sections; l'entropie peut donc être une preuve tangible de compression / cryptage.

La moyenne Entropique est donc devenu depuis un certain moment un de facto heuristique dans la détection des virus que ce soit au niveau des heuristiques statiques; exemple : la moyenne entropique de la section exécutable PE; ou au niveau des heuristiques dynamiques; exemple : détéction du point d'arrêt d'émulation...

J'ai rien à dire quand à l'utilité heuristique de l'entropie en général comme étant un outil de plus à ajouter au méthodes déjà existantes de détections, et qui peut nous aider à détecter plus de virus génériquement. Mais pendant le développement des engins statiques du FSB Antivirus j'ai pu tirer plusieures conclusions de taille quand au usage abusif et non intelligent de cette méthode. Comment ça ?

• Les procédures de calcul de la moyenne entropique peuvent s'avèrer beaucoup trop couteuses en terme de charge processeur et par conséquent donc temp et ressources de calcul.
• Je pense que certains ingenieurs, pour ne pas dire beaucoup, confondent encore entre données compressé et données cryptées. Un mixage entre Data et Code dans une section PE peut influer considérablement sur la moyenne entropique de cette dernière.

Je n'ai cité que 2 exemples concrets et c'est intentionnel.

Le calcul Pragmatique de la moyenne entropique :

Comme j'ai cité plus haut, les procédures de calcul de la moyenne entropique peuvent s'avèrer trop couteuses en terme de rapidité d'analyse, biensur à partir d'un point de vue Antiviral. Il serait préfèrable donc que l'élement entropique ne ralentisse en aucun cas les procédures globales de l'analyse antivirale, ou que le ralentissement soit très minime et imperceptible, d'où l'usage du mot pragmatique que j'ai introduit dans le titre. Je veux dire par calcul pragmatique, une méthode de calcul entropique optimale et très optimisée. Pendant mes recherches, j'ai observé plusieures méthodes d'optimisation algorithmique du calcul entropique et ceci à travers ce qu'on appelle techniquement parlant "les filtres".

Je veux dire par "Les filtres", un ensemble de conditions booléennes logiques qui contrôlent l'enclenchement des calculs entropiques, je cite à titre d'exemples :

• Bounds check - contrôle de l'espace d'alignement des sections DATA.
• Décompilation linéaire des premières instructions exécutables de la section CODE à l'affût des instructions invalides, mal formées, illicites ou des bouclent décryptives.
  

Pour vous expliquer l'avantage de la décompilation partielle comme filtre de condition d'analyse entropique, il faut savoir que le cryptage et surtout la compression introduisent ce qu'on appelle des noises visibles au tout début et tout au long de la section compressé ou crypté. Par exemple la décompilation des 64 premières instructions d'une section CODE compressée ou cryptée peut révéler un nombre important d'instructions CPU invalides, mal formées ou privilégiées et non exécutable en USER MODE ! Dans la majorité des cas, la détections de ces altérations à travers la décompilation partielle peut suffire à prouver la compression ou le cryptage d'une section PE, sans avoir à lancer les procédures de calculs de la moyenne entropique sur la totalité de cette section !

Le concept de filtrage en général, est vraiment très puissant puisqu'il permet d'implémenter une entropie pragmatique : calculer au bon moment, au bon endroit et utiliser juste une taille buffer optimale !