* et hop ca root

On vient de me passer l’url d’un petit papier qui détaille les risques des wildcards en shell. Encore une vilaine méthode pour élever ses privilèges que je ne connaissais pas.

Petit exemple concret…  un backup est fait quotidiennement par root sur un répertoire.

Et bien si en tant que quidam on as l’accès en écriture dans ce répertoire, a nous le root.  Il suffit de poser quelques fichiers bien sentis. Le wildcard va les déposer devant la commande tar, et ils seront interprétés comme des arguments. Checkpoint dans tar peut etre détourné afin de lancer le script de son choix.

Avant de vous laisser vous rendre dingue, petit help; Sachez que le paramètre «–» utilisé tout seul désactive la lecture des paramètres qui viennent après. on peut donc créér le tout avec :

On se retrouve avec deux fichier étranges.

Reste à construire le 3eme fichier

Quand tar sera exécuté, notre scrip install_suidbackdoor.sh aussi. Et la backdoor sera en place.

Bon… C’est un exemple, en fonctions des OS (genre ubuntu/debian), ne venez pas vous plaindre, bash droppera généralement le setuid. Soyez inventifs, echo “quidam” dans sudoers ca passe aussi.

C’est d’une certaine violence, il existe des tricks à wildcards pour chmod, tar, rsync. On remercie léon de son Paper que je vous invite à lire.

http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt

Posted in Hacking | Tagged , , | 1 Comment

INJECTION – WAF : 1 – 0

Petit truc pour injecter de la commande avec un Waf négatif devant;

En reviewant la liste plus qu’exhaustive des injections interdites par les signatures d’un WAF (Web Application Firewall) commercial. Et quand je dit exhaustive je pese mes mots, le bignou interdit même emacs, nano et vi (non mais sérieux ?? Qu’on me briefe sur un use case). Je suis tombé sur un binaire linux. Dispo dans /bin que ce soit chez Red-Hat, SuSe ou Debian. il se nomme lessecho. Évidemment il est ignoré de toutes signatures et jusqu’a hier, il m’était aussi inconnu. Lessecho est une commande qui a une petite particularité intéressante pour bypasser tout waf negatif (un Waf qui match des mots clef quoi).

lessecho permet d’ajouter des quotes autour d’un mot.

mais surtout lessecho permet de choisir ces quotes.

Le plus vifs d’entre vous auront déja trouvé le moyen de bypasser les signatures de leur waf si “$”,”(“,”)” et ” ” passent. Attention, moment de fiertée ;

L’autre solution étant la quote d’exécution.

Pour les moins vifs;  ce lessecho met “u” devant, “e” derriere le mot nam. Ca fait la commande “uname” qui passe le waf comme une fleur. Car la signature qui cherche “uname” ne trouve jamais la string.

Encore une nouvelle raison de changer d’idée pour ce qui pensent que le modèle négatif est suffisant.

Posted in WebSecurity | Tagged , | 2 Comments

Sinon y a Google translate quoi.

J’ai reçu un commentaire avec une traduction pas piquée des hannetons. Je pensais que c’était de l’humour mais je la soupçonne d’être un spam :) Trop drôle…

Screen Shot 2014-06-18 at 7.34.38

Sérieux, on s’applique un peu M. Spammeurs SVP !

 

Posted in BlaBla | Leave a comment

Packer sans ta mère, Level II, Prérequis III : LoaderDATA

On va voir aujourd’hui un grand classique des packer et aussi des shellcodes; Comment trouver et parser la liste des DLL afin de trouver le début d’une DLL mappée en mémoire;

Désormais on sait que grace au PEB + 0xC on peut trouver l’emplacement de la structure Loader Data.

Screen Shot 2014-05-24 at 9.43.52

 

Loader Data nommé aussi PEB_LDR_DATA va contenir la liste des DLL et a quel offset mémoire trouver les DLL de notre process. Mais si on regarde à cet emplacement on tombe sur une structure fort déroutante (Moi je vous jure, j’ai mis du temps à comprendre et avec le livre de  Sir Russinovich sur les genoux !). Cette structure ne propose pas une seul liste de DLL chargée mais 3 listes. Ces listes utilisent un format de liste chainée.  Ce que chez M. Windows on nomme des LIST_ENTRY.

Il y a 3 listes disponible concernant les DLL en mémoire ;

  • La liste de DLL chargée par windows au démarrage de l’exécutable (InLoadOrderModuleList)
  • La liste de DLL actuellement en mémoire. (InMemoryOrderModuleList)
  • La liste de DLL initialisée (InInitialisationOrderModuleList)

Je vous l’accorde pour l’instant c’est pas trop parlant;  Autant les deux premier on comprend bien la différence, si un exécutable après initialisation charge avec la fonctions LoadLibrary une nouvelle DLL on ne la retrouvera pas dans la première liste. La 3eme liste en fait ne comprend pas notre exécutable lui même. C’est donc équivalent à la seconde option sans notre propre process, car oui le listing des DLL en mémoire contient notre propre process.

Bon ça c’était la partie facile. Voyons ces listes chainées. Une liste chainée utilise deux pointeurs FLINK (Forward Link) et BLINK (BackWard link). Et c’est à partir de là qu’il faut sortir un schéma. Voici un petit exemple de cette structure. Cet exemple contient 3 records.

list_entry

Personne est tombé dans les pommes ? J’ai un ancien collègue qui aurait probablement éructé un “C’est quoi c’te structure de Nazi”. Alors petite explication. Chaque Flink donne l’adresse du Flink suivant, idem pour le Blink qui donne lui l’adresse du Blink précédent. Les deux premiers records sont les header il n’ont pas de data, seul le prochain Flink vous permettra d’arriver à la structure qui nous intéresse.

Donc si on veut voir la structure 2, il faut lire le 1re Flink, puis le Second, et enfin sous le Flink on trouvera le record qui vous intéresse.Mais il reste une petite subtilitée… Dans notre cas, Il y a 3 listes, donc chaque entrée comporte en header 3 couples de flink/blink. Donc en fait pour une entrée la structure est :

Diagram2

Donc si on suis les flink de InLoadOrderModuleList notre structure sera 0X18 bytes plus loin. Si on suit les Flink de InInitialisationOrderModuleList, la structure n’est qu’a 0x8 bytes plus loin. Funny n’est-ce pas.

Ha ! Et en plus quand on cherche quelque chose, il faut retenir l’offset du premier Flink des headers sous peine de tourner en boucle Ad Vitam. Donc pour aider à la comprenette, prenons un exemple. Dans cet exemple 32 bits, le Loader data d’après le PEB est situé en 0x211EA0. Le format de loader data au final c’est :

  • 0x0 Dword Lenght (Bullshit, on s’en sert pas)
  • 0x4 Dword Unused
  • 0x8 Dword SSHandle (On s’en fout aussi)

Et on attaque les fameuses list entry.

  • 0x0C List_Entry (Donc 2 Dword, le Flink et le Blink) InLoadOrderModuleList
  • 0x14 List_Entry InMemoryOrderModuleList
  • 0x1C List_Entry InInitialisationOrderModuleList

blinkheader

Ok donc admettons que l’on souhaite voir la première entrée de  la liste InInitialisationOrderModuleList, le Flink de ce header nous informe d’allez voir le premier record en 0x241F58 (regardez en 0x1c). Je suis en train de suivre le flink de la 3eme liste donc j’ai ma structure si chèrement désirée en flink + 0x8. Et devinez  ce qu’on y trouve…

Victoire enfin une structure tant recherchée. En 241F58 j’ai bien le flink suivant, mais surtout ;

module

On trouve en 0X241f60 l’offset en mémoire de notre image PE loadée de ntdll.dll. Je sais que c’est ntdll.dll car en 0x241F78 j’ai l’offset d’une string unicode donnant de nom de la DLL.

cette structure, Qui démarre au flink de la 1ere listes se nomme LDR_MODULE. En deux mots pour les packers il y a deux trucs juteux

  • En 0x18 la base adresse, ici en 0x24160 qui nous dit que cette dll est loadée en 0x7C900000
  • En 0x30 un pointeur sur la chaine unicode du nom de la DLL (ici en 0x241f78 qui pointe vers 0x7C92040c)

Alors après il est rare que les packers testent le nom de la dll directement. Soit certains savent que kernel32.dll c’est toujours la seconde et que la 1ere c’est toujours ntdll.dll. Soit ils utilisent un genre de hash du pauvre pour retrouver le nom de la DLL.

Petit exemple de “Use the force luke” tiré d’un malware quelconque..

Un autre générique et chiadé a moi :) (Oui je t’ai vu toi dans le fond ricaner, on peut faire mieux)

et un autre petit exemple “Use the force en 64 Bits”. Tout est pareil, sauf la taille des adresse évidemment ce qui décale toute notre affaire.

Et voila, la structure est bien chelou mais désormais vous êtes aptes à retrouver l’offset de n’importe quelle DLL mappée en mémoire et/ou détecter cette action dans le packer de votre choix.

a+

Posted in Asm, Malware, Reverse, Windows | Tagged , , , , , | Leave a comment

Packer sans ta mère level II prerequis II le PEB

Il y a 5 mois que je vous ai laissé tomber au milieu de cette série de post. Je me rend compte qu’il faut y avancer un peu car sinon tenter d’expliquer le dernier packer au plus grand nombre sans perdre quelques personne ne sera pas aisé.

On avait précédemment regardé comment était emmanché un exécutable dans la mémoire d’un Windows et survolé le concept d’EAT et IAT. Aujourd’hui on va voir une structure rigolote et indispensable le PEB.

Le PEB alias Process Environnement Bloc est une structure dite opaque (en clair peu documenté officiellement, voir documentée sur le tard, où normalement un programme normal est pas supposé s’y pointer).

C’est un pan de mémoire maintenu par windows pour chacun des process et qui va donner des informations vaste et variées. On peut par exemple trouver l’offset qui nous dira où est mappé en mémoire notre exécutable. On peut aussi savoir si le processe est débuggé ou pas. etc…

L’offset de la PEB  est toujours disponible en regardant dans FS[0x30]  en 32 bits ou GS[0x60] en 64 bits. A chaque instant il suffit de lire ce dword/qword et on connait l’adresse du PEB. Généralement en 32bits vers 7FFDxxxx tachez d’arriver à repérer un offset de cette trempe.

Microsoft documente un peu le PEB dans son MSDN mais c’est assez minable. Heureusement en 32 bits Ollydbg connait cette structure à fond. Elle est directement visible dans Olly depuis la fenêtre de memory map (Alt+M).

Screen Shot 2014-05-24 at 0.16.11

Et il sait aussi décoder cette structure ce qui est TRÈS pratique.

Screen Shot 2014-05-24 at 0.19.31

Donc que peut t’on faire concrètement avec cet structure ? Premièrement de l’anti-debug avec l’info qui traine dans ce PEB. Il y a deux grand classique;

C’est pareil que d’appeler la fonction de kernel32 IsDebuggerPresent, sauf que là, pas besoin de la déclarer une fonction et pas besoin non plus d’appeler une fonction ! tout n’est qu’access mémoire.

Le second anti-débug possible est plus étrange;

Celui la se base sur le fait qu’un process débuggé à normalement 3 flags de mis dans le PEB

  • 0x10 pour HEAP_ENABLE_TAIL_CHECK
  • 0x20 pour HEAP_ENABLE_FREE_CHECK
  • 0x40 pour HEAP_VALIDATE_PARAMETERS

Pour être au top sur ces anti debug, je vous invite a lire le chapitre 2.1 et 2.2 de “The Art of Unpacking” de Mark Vincent Yason;

Bien sur généralement l’accès à fs[0x30] est caché de toutes les façons du monde, petit exemple :

On peut trouver aussi l’offset du PEB par une autre méthode, il est laissé par windows dans le registre EBX à l’entry point d’un programme x32.

Mais le PEB ne sert pas qu’a tester de debugging;

Il contient des infos sur le nombre de CPU (si c’est 1.. en 2014, c’est probablement une VM !). Il peut servir pour déterminer la version de windows(+0xA4 et +0xA8), il contient l’adresse de base de l’exécutable (+0x8) et enfin l’adresse d’une structure nommée LoaderData ou PPEB_LDR_DATA (en +0xC)

Cette dernière structure va nous permettre de retrouver l’offset où est mappé en mémoire les DLL nécessaire à notre exécutable. (A minima kernel32 et ntdll).

Vous l’aurez compris grâce à cela, on va pouvoir parser l’EAT de ces DLL et retrouver les offset des fonctions en mémoire afin de pourvoir les appeller sans avoir à les déclarer dans l’IAT de notre programme, bref un GetProcAddresseA mais totalement discret.

On verra cela la prochaine fois. mais retenez, si vous voyez passer un FS[0x30] ou un GS[0x60] Inquiétez vous !

Posted in Reverse, Windows | Tagged , , | 2 Comments

IDAPYTHON pour nommer les appels indirects aux fonctions

Après avoir recherché partout et fatigué tout le monde via IRC, je n’ai pas trouvé de solution sympa pour résoudre automatiquement les noms de fonction dans IDA quand les appels à celles-ci ne sont pas déclarées dans l’IAT.

Bon, j’ai perdu un lecteur ou deux, Je m’explique;

Par exemple, si je veux faire un programme windows qui pond une messagebox, cet appel de fonctions sera déclarée dans l’IAT et la DLL responsable de la fonction pour ce popup sera elle aussi déclarée et chargée à l’initialisation de l’executable. Cette publicité inattendue est peu souhaité par l’écrivain de malware. Celui-ci préfère éviter de déclarer les fonctions qu’il utilise. Et c’est du travail de se cacher.

J’ai pondu un petit exemple dans le github : https://github.com/Th4nat0s/Chall_Tools/tree/master/asm/hellostealth

Ce n’est pas le but aujourd’hui d’expliquer comment retrouver l’offset d’une fonctions en parsant la table d’EAT d’une dll; Mais en deux mots;  Ici je retrouve les adresse des fonctions à partir d’un hash de leur nom grâce à une petite procédure qui parse l’EAT de la dll chargée en mémoire (un grand classique).

Grosso modo dans tous les cas il faut passer par les étapes suivantes :

Une fois compilé, notre appel à MSGBOX est totalement incognito dans la table d’import

Et dans ida, rien n’est résolu et nous on ne sait pas trop ce qu’il se passe.

Et pour cause… Rien n’est initialisé, les appels sont cachés.

La solution facile dans ce cas là, si l’auteur du malware est sympas et charge tous les offset de fonctions dans une procédure pas loin du démarrage, c’est de dumper le process dans olly après résolution. A partir de là les offsets sont remplis.

Si on utilise olly on peut connaitre l’offset de la dite fonction et se transformer en Champollion. (View > Executable Modules > Bouton Droit > Show File in all module)

Screen Shot 2014-05-22 at 1.11.32

Bon là ca va il y en a que deux fonctions à trouver, mais avec un petit droppeur ou un malware, au bout de la 50eme c’est assez pénible. D’ou le script du jour.

Etape 1, sauver la liste de “All Names”  dans c:\temp\export.txt.

Etape 2, Se rendre ensuite dans IDA avec Python d’actif , mettre le curseur dans une fonction et faire Shift + F7 puis sélectionner ce script magique :  https://github.com/Th4nat0s/Chall_Tools/blob/master/ollylink.py

Etape 3, hurler de joie, ce qui était non renommé et inconnu en Dword_ et qui a trouvé correspondance dans une table d’export est enfin nommé. IDA fait le reste pour mettre les commentaires adaptés.

Voila qui est mieux.

Posted in Asm, Reverse | Tagged , , | 2 Comments

Le Droppeur du jour, label231486.pdf – Part 2

Suite de l’analyse de la facture de chez DHL :) On le dépacke !

Le dit sample est dispo dans AvCaesar chez Malware.lu mais on n’y apprend pas grand chose de plus. A première vue, on n’arrivera pas a dépacker en statique. (Enfin pas moi quoi). Que ce soit radare ou Ida c’est mal partis.

Screen Shot 2014-05-17 at 6.20.04 Voyons comment on peut louvoyer pour dépacker le bignou avec OllyDbg dans une VM sous Fusion. Si quelqu’un a des TIPs pour aller encore plus vite, je suis preneur ! En analysant la table d’import on tombe sur une ou deux fonctions chelou. C’est d’ailleurs étonnant qu’il y ait autant de fonctions déclarées pour un truc packé.

Donc je le renomme en 2.exe comme le veut le précédent batch au cas ou et  je le charge dans Olly. Là on met un breakpoint dans kernel32.dll sur les fonctions habituelles.

(Pour breaker on se rappelle, View > Executable Modules > Mickey Bouton Droit > Show Name > F2 pour breaker) Screen Shot 2014-05-17 at 6.44.34 En plus de cela à coté un Russinovich Process monitor afin de récolter les potentielles lectures/écriture dans la registry et/ou fichiers. Et c’est partis. Screen Shot 2014-05-17 at 7.04.23 Cela break en 0x422477 à l’appel à VirtualAlloc et un nouveau segment en 0x33000 est alloué en Read Write Execute. Coté registry de l’étrange, 200 clef de cet acabit on été testée. pas une n’a de sens.

A partir de là, (Snapshot vmware !!)  et je vais lancer le mode trace de demander en plus à Olly de breaker quand il devra executer quelque chose dans le range nouvellement alloué. (ctrl-T puis hit trace dans «Trace») Screen Shot 2014-05-17 at 7.12.53   Quand enfin olly break, dans ce nouveau segment, on se dit qu’on est pas sortis du bois. nous voici dans le stage2 du packeur, une succession de “une a deux instructions, jump” bref du code spaghetti. Petit example remis dans l’ordre :

Bref… c’est pas humain a suivre. Donc on fait le contraire, je trace et je demande à Olly de s’arrêter si on sort du segment avec le code spaghetti. Screen Shot 2014-05-17 at 7.32.07 Et je relance le hit trace. Et là PAF… on sombre dans l’étrange… Packer/Thanat0s 1-0 !… Screen Shot 2014-05-17 at 7.34.23 Là on apprend plein de chose; Premièrement Olly se plain qu’on lui à changé un breakpoint par un 0x00. Normalement le breakpoint software alias l’instruction Int3 , c’est 0xCC en hexa et il est posé en lieu et place de l’instruction que l’on veut arrêter. Ca c’est le signe que notre stage2 chipote dans le code. Amis polymorphes bonjour. Donc il va falloir faire gaffe avec les breakpoint software.

En plus le code tripoté est pas dans le segment que nous suivons mais dans le segment 0x400000 bref là ou il y avait le code loadé initialement. Cela veut dire que le code original de l’executable est remplacé.

Ensuite, l’EIP est arrivé en 0x7FFDE000 qui l’addresse notre PEB, le process environnement bloc, c’est un bout de mémoire avec  une structure certes essentielle mais qui n’est absolument pas supposé être exécutée. Ca n’a pas de sens !

Coté registry cela comment à devenir compréhensible. Il semblerai que l’on soit dans les tests offensifs. Le packer cherche NOD32. Etonnant de la part d’un fichier issus d’un spam qui dit être déjà passé par cet antivirus, n’en doutons pas c’est surement pour nous éviter un second et inutile test :)

Quoi qu’il en soit.. Il a gagné, l’exe va au crash. Déjà, voyons ou s’est passé cet read dans la registry à la recherche de l’antivirus. Pour cela bonne nouvelle Russinovich sauve l’état de la stack à l’appel de la fonction le lecture de la clef de registre. Screen Shot 2014-05-17 at 8.09.54 Après l’appel à ADVAPI32 pour lire la registry le programme est supposé retourner en 0x33b5b il y a donc fort à parier que l’instruction de devant c’est notre fameux call. Et effectivement si on regarde le code, on tombe sur un call EAX

On reprend donc notre snapshot vmware, . Dans la mesure ou le code se modifie de partout et qu’étonnamment 0x33B59 tombe en plein milieu de deux instructions on va utiliser un break point hardware ce coup ci (Shift+F5). Screen Shot 2014-05-17 at 8.26.08 Et on lance, cela confirme que c’est bien là qu’il faut breaker si on veut éviter le test avec node 32. Petit truc, en examinant un peut plus haut la stack on retrouve l’adresse de base de la DLL ADVAPI32. (Struct IMAGE_DOS_HEADER) cela est un bon indicateur que le packer parse lui meme les dll à la recherche des adresse des fonctions et que la table d’import originale n’est qu’un leurre. Screen Shot 2014-05-17 at 8.37.17 Bon, ca c’était pour le fun.. J’ai pas NOD32.

Maintenant gérons notre crash quand il nous a envoyé nous balader sur le PEB. On reprend le snapshot vmware au moment du crash et on va analyser la pile.

Au dessus de 7FFDE00 on retrouve l’offset de retour d’une fonction en 0x401235 et on est passé par la juste avant le crash. Et oui vu qu’il modifie le code, il a réussis son coup le packeur, mais le breakpoint du trace n’a pas fonctionné.  Pas grave on sait où regarder… Regardons la fonction autour de cette adresse.

On reprend notre snapshot, et comme le code se modifie, on break en hardware en 0x401235. Arrivé en 0x40124D tout s’explique. Toute la mamaille entre 0x401235 et 0x40124B sert uniquement à mettre 0x30 dans EAX. Et FS:[0x30] c’est à retenir, cela pointe le PEB. Du coup ce qu’il se passe en fait. C’est un test d’anti debugging. le fameux PEB!BEINGDEBUGGED C’est cela en clair:

Donc si je débugge, il le sent,il pousse l’offset du PEB et jumpe dessus ce qui conduit à mon crash. Il faut donc sauter en 0x401258 pour passer outre l’antidebug. On recommence, snapshot, hdw breakpoint sur 0x401254 et on rebranche avec «bouton droit > New origin here »quand on à la main. 401245 Si on step un peu, on passe par une petite procédure qu’on va retrouver plusieurs fois encore et qui xor un énième pan de mémoire dans le bloc mémoire 0x40000 avec des 0x5E.

Et enfin on retombe sur un peu le même soucis qui conduit au crash, la faute à ce bout de code :

C’est un autre test d’anti debugging. le fameux PEB!NTGLOBALFLAG . arrivé en 0x401208, EBX pointe sur le PEB et  quand on débuggue, les flags HEAP_ENABLE_TAIL_CHECK, HEAP_ENABLE_FREE_CHECK et HEAP_VALIDATE_PARAMETERS sont mis. Du coup on se fait gauler. Il faut jumper en 0x40120F pour bypasser ce test. Petite aparté non primordiale mais classique, quand juste après après avoir re xoré encore un coup un pan de code avec 0x5E  on tombe sur ce genre de code, c’est intéressant.

Ce genre de code est un classique, Voici un exemple typique d’un parseur de EAT qui va s’occuper de chercher l’addresse d’une fonction dans une DLL. cette fonction est appelée avec un hash, ce hash est le nom de la fonction ou chaque lettre est décalée d’un octet et xorée avec ce qu’il y a avant (voir 0x401115 et 0x40118).  Bref c’est une fonction obfusquée qui fait le même travail que GetProcAddress

Il est toujours juteux de breaker sur cette fonction car on peut y apprendre quel sont les fonctions que le packers souhaite utiliser sans oser les déclarer. En breakant sur le mov avant le popad on découvre donc les fonctions :

  • ntdll.NtAllocateVirtualMemory
  • ntdll.NtTerminateProcess

Et maintenant on sait avec quoi il alloue ses pans de mémoire. Le debug continue et on s’arrête désormais (merci olly) au chargement de la DLL msasn1.dll qui est en fait appelée par le chargement de crypt32.dll. Si on prend les calltrace (View > CallStack) dans olly, on découvre que notre loadlibrary est appelé depuis 0x36343d. Fichtre encore un nouveau segment avec du code. Stage 3 ! Screen Shot 2014-05-17 at 16.10.00 Et là on est très heureux, il semblerai que le segment 0x360000 soit enfin le bon. En 0x361000 plein de strings bien claires et du code pile poil en 0x36500. Screen Shot 2014-05-17 at 16.17.02 Bon, on est presque au bout, mais il nous faut juste un entry point propre. Bref s’arrêter au plus tôt dans le code exécuté dans le segment 0x36000. On reprend le dernier snapshot et on ajoute un breakpoint sur le NTAllocateVirtualmemory découvert plus tot. Au terme d’un peu de steeping on arrive enfin au Graal

EDX contient 0x364A00 notre EntryPoint ! Le call Dword[0x401009] d’après contient NTTerminateProcess.

VICTORY !   Au final on sais le dépacker avec ces 3 steps.

  • Mettre 3 hardware Breakpoints en execution qui ne semblent pas n’avoir de sens en 0x401254 et  0x40120b et 0x4010E5
  • On aide à passer les deux anti-debug
  • Au break sur 0x4010E5 on dump le segment pointé par EDX et dont l’entry point est EDX.

Donc je repart depuis le début et je suis ces 3 steps.. ce coup-ci c’est le segment 0x9C0000 qui est alloué pour notre stage 3 (précédemment 0x360000)

Arrivé là on tape un peut dans le code et on assemble un mov edx pour aider a faire marcher le call EDX

Et on dump avec le plugin OllyDumpEX le segment 40000 et 9C4A00 (ici celui pointé par EDX) Dépacké enfin ! On set l’entry point sur notre bidouille.

Screen Shot 2014-05-20 at 1.54.31

Bingo on l’a dépacké le bignou

Allez bientôt on dépècera cet executable.

 

Posted in Malware, Reverse | Tagged , , , | Leave a comment

Le Droppeur du jour, label231486.pdf – Part 1

Quel ne fut pas ma joie d’ouvrir ma boite aux lettres et de tomber sur une facture envoyée par “sales@meyda.com”. Une sombre histoire de facturation.

Fichtre, un problème de facturation… Heureusement je ne risque rien, le fichier semble passé à l’antivirus :).

Bref j’ouvre l’«arhive» avec le mot de passe indiqué (sans le «.») et je me retrouve avec un fichier .pdf ……….exe :) Bon jusque là… pas trop impressionné. Même la transparence sur l’icone est dégueulasse. On le renomme en .bin et on avance.

pdfexe

Au détour d’un strings on découvre que cela semble être un RAR self extractible.

Une fois ce SFX décompressé bêtement avec 7Zip on tombe enfin sur quelque chose qui peut nous amuser. 4 fichiers;

Bon, on au vu des scripts, on se doute que le SFX doit pouvoir lancer le script visual basic .vbs. Le seul but dans la vie de ce vbs étant de lancer le .bat

Le .bat s’occupe de virer ce qui pourrait être existant, de renommer le pdf et l’exe et ensuite, d’une part de lancer le pdf, histoire de satisfaire le bon père de famille qui a cliqué sur ce malware en affichant quelque chose. Et d’autre part de lancer le fameux exe afin d’aller dropper le malin.

Le pdf et l’exe sont enfin «caché» au mieux en prenant l’attribut fichier «system» et «hidden» et on se débarrasse du vbs et du .bat (le %0).

Aucuns doutes à avoir l’executable sent le packing au vue de l’entropie et de la taille du segment de data par rapport a celle du code.

Un coup de rabin2 permet de confirmer que sur 270 strings, il n’y a pas une string potable là dedans.

La suite ca sera donc olly :)

Posted in Malware, Reverse | Tagged , , , | 1 Comment

SQLi, ce n’est pas assez SELECT.

Un petit article sympas d’un certain Osanda Malith Jayathissa. Sri lankais de son état et qui documente bien les injections MySQL possible avec les méthodes update, delete et insert into. Il revient en détail et par l’exemple sur les injections possibles avec les fonctions :

Pour sur, il va y avoir de la DB bien cochonnée…

SQL Injections without SELECT

Posted in WebSecurity | Tagged , , | Leave a comment

Marty va chercher la DELOREAN.

Oui vous ne rêvez pas… Un CVE de 2014 pour le vénérable Mosaic, alias le père de tous les browsers pour les plus jeunes d’entre vous qui l’ignorez. Browser dont la dernière version date de 1997. Je parie qu’on aura pas de patch !.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3425

Au moins avec ce browser la, <blink> fonctionne encore.

Tout cela en fait pour dédoiner un Emacs de ses responsabilités… Le VIM user est mort de rire. C’est ridicule.

Posted in BlaBla, WebSecurity | Tagged | Leave a comment