Enfim uma maillist…   2 comments

Olá, espero que estejam todos ok…

Depois de muito bate cabeça e controversias frequentando a lista exploits-brasil um grupo com ideias em comum resolveu criar uma nova lista de discussões…

A lista criada foi chamada de 0ops-br, uma breve tradução da wiki seria:

Um “oops” é um *desvio* do comportamento correto do kernel do linux, o qual produz algum tipo de erro/log.

Tá, pode não ser o melhor nome do mundo mas se você já sabe o significado é bem provável que trará discussões interessantes pra lista ;).

Algumas considerações:
— A lista é moderada
— Os moderadores são bastardos (fdpsemcostume!)
— Os interesses estão entre, mas não somente, OS Internals, Programação baixo nível (C, assembly), Exploração de Softwares, Engenharia Reversa, Malware Analysis e Hacking/Phreaking em geral (exemplo: Lock Picking, DIY projects…)
— …

O endereço da lista é: http://groups.google.com/group/oops-br
Apenas as postagens são moderadas (pra evitar sujeira na lista).

Se você se interessa pelos assuntos acima e sabe como se portar em uma maillist, será bem vindo :).
Sobre o numero de mensagens/dia, só vai passar o que os moderadores julgarem interessantes, então pode ser produtiva ou nenhuma mensagem mas dificilmente será “suja/poluida”…

waKKu

Publicado 18/05/2011 por waKKu em Food for thoughts, Segurança

Etiquetado com ,

Stack Overflow: EIP Overwrite – Uma visão diferente   1 comment

  • Post Info:
    1. # Author: Flavio do Carmo Junior aka waKKu
      # URL: Author’s Webpage
      # Date: April 06, 2011
      # Category: Exploiting, Programming, Security

    Bom, já viram que eu meio que abandonei isso aqui né…
    Resolvi que escrever em inglês seria mais vantajoso pra mim (estou indo embora do BR em breve e seria uma forma de expor minhas habilidades/curriculo).

    De qualquer forma, hoje o meu camaradinha tuxtrack lá do #dclabs na FreeNode me pediu um help sobre stack overflow…

    Como eu sei alguma coisa sobre o conhecimento dele, eu preferi explicar o EIP Overwrite (stack overflow) de uma forma diferente, talvez seja util pra mais alguém então aí está:

    Explicando melhor as dúvidas que surgiram:
    – Porque estamos vendo instruções como:
    0x08048383 : mov %eax,0x4(%esp)
    0x0804838a : mov %eax,(%esp)
    – Ao invés dos clássicos:
    push %eax
    (calcula um novo eax aqui)
    push %eax
    ???????

    Resposta: Porque a cada push, na verdade, o ciclo de instruções executa um:
    movl %eax, (%esp)
    sub $-4, %esp
    Então podemos ver claramente que isso ai é MAIS lento do que eu fazer um único movl usando um endereçamento de referencia, como acontece aqui:
    0x08048383 : mov %eax,0x4(%esp)

    Isso são otimizações do gcc, tem opções específicas do compilador que produzem o codigo com push’s normal…
    Hoje em dia a realidade já é otimização, então é importante trabalhar com elas.

    Outra pergunta:
    – Porque você falou que a call empurra o valor EIP+5 (eip == propria call)??
    Resposta:
    – EIP no momento da execução da instrução call, obviamente, aponta para o proprio endereço de memória da instrução call. A instrução call tem 5 bytes (quando desviando para um endereço de memória (label), sendo 1 opcode + 4 bytes do endereço sendo chamado), então o endereço da proxima instrução depois da CALL é exatamente o “Endereço da CALL” + 5.
    Mais sobre isso no final do post…

    UPDATE: <shinku> Nem toda call tem 5 bytes ;P (Conversa no IRC)
    — É verdade, quando uma call usa um registrador, ela tem outro tamanho, exemplo:
    0: ff d0 call *%eax

    Num caso desse, obviamente, o endereço “empurrado” vai ser EIP_ATUAL+Tamanho_da_Instr_CALL…
    Mais info sobre CALL: http://home.comcast.net/~fbui/intel_c.html#call

    Agora sim, segue o que construi para minha explicação pro tuxtrack:
    Leia o resto deste post »

    Publicado 06/04/2011 por waKKu em Exploiting, Programação, Segurança

    Etiquetado com ,

    Linux x86 ShellCodes – 103   5 comments

  • Post Info:
    1. # Author: Flavio do Carmo Junior aka waKKu
      # URL: Author’s Webpage
      # Date: March 17, 2011
      # Category: Assembly, Exploiting, Programming, Security, Shellcoding

    Dae povo…

    Se você não leu nossos outros posts da saga Linux x86 ShellCodes – 10X, LEIA ANTES DESSE, HÁ MUITA COISA LÁ QUE NÃO SERÁ REPETIDA AQUI.

    1. Introdução
    Conforme prometido no post anterior, dei a ideia de abordarmos um exemplo da técnica “CALL + POP”…
    Vamos lá… Dessa vez o assembly vai ser um pouco mais “completo”.

    Objetivo do nosso ShellCode de hoje: Criar um usuário com uma senha predefinida por nós e com uid = 0.

    Considerações:
    – O Linux armazena os usuários e senhas no arquivo /etc/passwd *
    – A senha será gerada usando o crypt(3) e um MD5-based
    – Teremos que inserir uma linha no arquivo utilizando só assembly
    * O Linux só consulta o /etc/shadow se o valor do campo password no /etc/passwd for “x”, caso a senha já conste no arquivo ele autentica diretamente.
    Do man 5 passwd

    The encrypted password field may be blank, in which case no password is required to authenticate as the specified login name. However, some applications which read the /etc/passwd file may decide
    not to permit any access at all if the password field is blank. If the password field is a lower-case “x”, then the encrypted password is actually stored in the shadow(5) file instead; there must
    be a corresponding line in the /etc/shadow file, or else the user account is invalid. If the password field is any other string, then it will be treated as an encrypted password, as specified by
    crypt(3).

    OK, já vimos que esse shellcode vai ser bem diferente…

    a. A nossa syscall(): write(2) – Número: 4
    Leia o resto deste post »

    Linux x86 ShellCodes – 102   3 comments

  • Post Info:
    1. # Author: Flavio do Carmo Junior aka waKKu
      # URL: Author’s Webpage
      # Date: March 10, 2011
      # Category: Assembly, Exploiting, Programming, Security

    Olá povo…

    Como prometido, vamos evoluir nossos shellcodes (pelo menos tornar isso útil né).

    Se você não leu nossos outros posts da saga Linux x86 ShellCodes – 10X, LEIA ANTES DESSE, HÁ MUITA COISA LÁ QUE NÃO SERÁ REPETIDA AQUI.

    Objetivo do nosso shellcode: Executar a syscall:
    execve(‘/bin/bash’, [ ‘/bin/bash’, 0x00 ], [ 0x00 ])

    1. Origanizando as ideias

    Vamos considerar como Bad Chars os bytes 0x00 - 0x0d - 0x0a.

    a. Especificação da nossa syscall:
    man 2 execve

    SYNOPSIS
    #include

    int execve(const char *filename, char *const argv[],
    char *const envp[]);

    DESCRIPTION
    execve() executes the program pointed to by filename. filename must be either a binary executable, or a script starting with a line of the form “#! interpreter [arg]”. In the latter case, the interpreter must be a valid pathname for an executable which is not itself a script, which will be invoked as interpreter [arg] filename.

    argv is an array of argument strings passed to the new program. envp is an array of strings, conventionally of the form key=value, which are passed as environment to the new program. Both argv and envp must be terminated by a null pointer. The argument vector and environment can be accessed by the called programâs main function, when it is defined as int main(int argc, char *argv[], char *envp[]).

    Então, temos:
    1o. Argumento: Ponteiro para uma string contendo o filename
    2o. Argumento: Ponteiro para um array de argumentos, terminando com 0x00*
    3o. Argumento: Ponteiro para um array de ambiente (environment), terminando com 0x00
    *: O primeiro valor do array de argumentos deve ser o caminho do programa sendo executado.

    b. Número da nossa syscall: 11 (ou 0x0b em hexa)

    waKKu@blog$ grep __NR_execve /usr/include/asm-i486/unistd.h
    #define __NR_execve              11
    

    2. Escrevendo na stack
    Leia o resto deste post »

    Linux x86 ShellCodes – 101   7 comments

  • Post Info:
    1. # Author: Flavio do Carmo Junior aka waKKu
      # URL: Author’s Webpage
      # Date: March 03, 2011
      # Category: Assembly, Exploiting, Programming, Security, Shellcoding

    Dae povo…

    <HERESIA> Querem contribuir com os posts no blog? Deem uma olhada no Sobre isso aqui…</HERESIA>

    Esses dias atrás conversando no canal #dclabs com a galera sobre os posts e tal e pediram pra gente falar um pouco sobre shellcodes
    Bom, não sou nenhum especialista no assunto mas vou tentar passar um pouco das minhas experiências. Apesar de hoje em dia todo mundo acabar usando o MetaSploit Framework pra gerar seus shellcodes e encoda-los ainda, mas eu gosto de saber como as coisas funcionam “de verdade”…

    Heads-up: Eu me reservo o direito de errar, mas prometo que tudo que ta aqui foi/será testado. Tudo que to escrevendo aqui vem da minha cabeça e, dentro dela, faz mto sentido ;).

    1. Introdução
    Shellcode é aquele pedaço mágico de código dentro do nosso payload que enviamos em Opcodes e que será injetado diretamente na memória do programa vulnerável e, se tudo der certo, será executado ao final da nossa exploração.
    A origem do nome shellcode é porque inicialmente o que todos desejavam era que após a execução de um exploit nós tivessemos acesso a shell do sistema, e assim poderiamos fazer o que quiser, hoje em dia isso nem sempre é verdade, as vezes o que queremos é adicionar um usuário no sistema ou baixar as proteções de um firewall.
    E por que continuamos a chama-lo de shellcode?
    — Sei lá… Talvez porque é mais fácil do que chamar de “Pedaço mágico de código inserido na memória de um programa vulnerável a fim de executar <INSIRA AQUI O OBJETIVO DO SEU SHELLCODE>”… Mas de qualquer forma, algumas aplicações já estão abolindo a separação “payload” e “shellcode” – chama tudo de payload pra simplificar.

    2. Bad Chars
    Leia o resto deste post »

    uCon 2009- CTF Challenge Stack 02   Leave a comment

    • Post Info:
      # Author: Raphael Prudencio aka raph0x88
      # URL:

    Author’s Webpage

      # Date: February 28, 2011
      # Category: Exploiting, Programming, Security

    Sup guys…

    Depois de tanto tempo dando desculpas eu consegui sentar pra terminar o post. Alguns meses atrás jogaram um challenge lá no #dclabs e como sou bastante curioso, fui ver do que se tratava, era um challenge de stack overflow da uCon 2009 porém com frescuras requintes interessantes e um detalhe curioso, vamos ao que interessa;

    int main (int argc , char *argv[]) {
      if (argc != 2) {
        __print_sw_title(argv[0]);
        return ERRO;
      }
    
      if (__lets_play(argv[1])) {
        __create_tag(argv[0]);
        printf("\n +-+ Bang ! +-+ \n");
      } else {
        printf("\n Shut your fucking face, uncle fucka! \n");
      }
    
      return OK;
    }
    
    ...
    
    int __lets_play (char *param) {
      int i = 0;
      char buffer[2];
    
      for(i = 0; i < strlen(param); i++) {
        if (i % 2)
          buffer[i] = param[rand() % strlen(param)];
        else
          buffer[i] = '\0';
      }
    
      if ((int) buffer < 0)
        return 0;
    
      return 1;
    }
    

    Antes de entrar nos requintes desse challenge que deveria ser o rand(), vamos ao pequeno detalhe.

    Leia o resto deste post »

    YOPS 2009 – Stack Buffer Overflow   4 comments

  • Post Info:
    1. # Author: Flavio do Carmo Junior aka waKKu
      # URL: Author’s Webpage
      # Date: February 16, 2011
      # Category: Exploiting, Programming, Security

    Post na correria, foi quase um copy & paste da análise que tinha feito pro grupo, mas só pra não passar em branco…

    1. Introdução
    O YOPS é um Web Server extremamente simples que o grupo DcLabs lançou um advisory de Remote Command Execution no ano passado.

    2. Encontrando o bug
    O ipax usou um fuzzer no software e descobriu que enviando um buffer grande com o comando “HEAD” o software abortava com “Segmentation Fault” (quando um programa tenta acessar memória fora do seu segmento o kernel mata ele com esse sinal
    (man 7 signal)).

    Utilizando uma versão compilada com debug symbols do programa, um debugger (gdb) e utilizando nosso fuzzer podemos identificar onde a falha ocorre e qual o caminho até ela:

    # --- gdb output ---
    MANAGER: 1 jobs in ACCEPTOR->PARSER queue
    errorer #1 has job (status = 400) (.errors/400.html)
    
    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 1208023360 (LWP 14222)]
    logger_th (arg=Cannot access memory at address 0xa30300c
    ) at main.c:383
    383                     printf("logger #%d: '%s' LOGGED [%d]\n", id, job->hdr.request_line, job->status);
    # --- gdb output ---
    

    A falha aconteceu na função logger_th(), alguma coisa sobrescreveu o endereço de seus argumentos (logger_th (arg=Cannot access memory at address 0xa30300c)).

    3. Bug ou Vulnerabilidade
    Leia o resto deste post »