Linux x86 Shellcoding – 102   5 comments

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

    Hi again…

    The objective for our shellcode today is execute the following syscall:
    execve(‘/bin/bash’, [ ‘/bin/bash’, 0x00 ], [ 0x00 ])

    1. Intelligence Gathering

    We are going to consider 0x00, 0x0d and 0x0a as bad chars.

    A. Our syscall specification:
    man 2 execve

    #include <unistd.h>

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

    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[]).

    Then we have:
    Read the rest of this entry »


    Posted April 29, 2011 by waKKu in Assembly, Exploiting, Programming, Security, Shellcoding

    Linux x86 Shellcoding – 101   3 comments

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

    Hi everyone…

    Some days ago we were chatting at #dclabs channel about this blog and people asked for some posts about shellcoding
    Well, I’m not an expert in this subject but I’ll try to write all I know and sometimes we’ll be learning together, writing and reading these posts ;).
    Nowadays is pretty unusual when we really need to write our own shellcode, we can always go to MetaSploit Framework and grab a fresh one there, well written, reliable and even encoded. Well, where is the fun of it, huh?… I like to know where everything is and why, I promise that on the end of our saga you’ll be able to understand every detail about shellcoding and write your own shellcode, able to exploit a vulnerability that before was not exploitable using metasploit shellcodes.

    1. Introduction
    First of all, what is ShellCode?
    Read the rest of this entry »

    Posted April 16, 2011 by waKKu in Assembly, Exploiting, Programming, Security, Shellcoding

    Stack Overflows: EIP Overwrite – A different approach…   2 comments

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

    Today my pal tuxtrack at #dclabs ( asked me some help to understand Stack Overflow (more precisely EIP Overwrite part)…
    As I know him (and part of his knowledge), I decided to take a different approach from usual “blah, blah, blah” about C, strcpy() and stack.
    Possibly it could be useful to anyone else, so I’m posting it:

    Before our journey inside gdb, lemme explain some details:

    First question:
    — Why are we seeing instructions like this:
    0x08048383 : mov %eax,0x4(%esp)
    0x0804838a : mov %eax,(%esp)
    – instead of usual:
    push %eax
    (Some instructions to set a new value for %eax)
    push %eax

    Answer: Well, at each “push” instruction, what really happens is a cycle of instructions similar to:
    movl %eax, (%esp)
    sub $-4, %esp

    Thus we can easily see that it is SLOWER than a single “movl” instruction using a referenced address, like this one:
    0x08048383 : mov %eax,0x4(%esp)

    Reason for this is GCC optimizations, we could use some specific options while compiling the program to generate the old “push” style…
    But the real world nowadays is optimization, so I thought better to work with it.

    Second Question:
    — Why did you tell “Call pushes the current value of EIP + 5 bytes (eip == own CALL instruction address)?

    – EIP at moment CALL is being executed, obviously, points to the own address of CALL instruction. This CALL instruction has 5 bytes (when pointing execution flow to another memory address (label), 1 byte for CALL mnemonic + 4 to memory address being called), therefore the address right after the CALL instruction is exactly “Address of CALL” + 5 bytes.

    <shinku> CALL isn’t ALWAYS 5 bytes long ;P (Translated IRC talk)
    — True, when using call with, for example, a register it has a different size:
    0: ff d0 call *%eax
    More about CALL instruction:
    Obviously, in this case, the pushed address would be CURRENT_EIP + CALL_LENGTH…

    And I talk a bit more about it below.

    Finally, the code and comments trying to explain this “technique”:
    Read the rest of this entry »

    Posted April 6, 2011 by waKKu in Exploiting, Programming, Security

    YOPS Webserver Stack Buffer Overflow   1 comment

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

    Welcome back, goodfella ;)

    This is another post in “Vulnerability Analysis” category, but at this time, this is one of our (DcLabs) 0-days.

    1. Introduction
    YOPS is a really simple webserver we’ve found an Arbitrary (Remote) Code Execution and released an advisory and exploit last year.

    2. Triggering the bug
    One of DcLabs members, ipax, using a fuzzer noticed that when sending a big buffer and using the “HEAD” HTTP Method the software crashed with a segfault signal.

    He then asked me to take a look and, some time later, here we are ;). Ok, first thing to do is download a copy of the software and (God bless open source) compile it with debugging symbols, then running our “trigger” again, we were able to identify the crash:

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

    The flaw happened at function logger_th(), something overwrote its argument address, as seen in (logger_th (arg=Cannot access memory at address 0xa30300c)) gdb message.

    3. Hunting down a vulnerability
    Read the rest of this entry »

    Posted March 24, 2011 by waKKu in Exploiting, Security, Vulnerability Analysis

    how strcmp() made my week…   3 comments

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

    Howdy fellas… me again ;)
    This post is a bit different from the last one, you’ll probably have some fun with it…

    1. Introduction
    Long time ago (2009), in Brazil, we got a huge blackout we called “Apagão”. A brazilian blogger posted about a possible SQL Injection flaw into ONS’s system… Well, this isn’t relevant, but this post has literally shined in almost all internet news portals here in Brazil.
    I, curious as I usually am, ended up reading a lot of other things on that blog that day…
    Yesterday on #dclabs IRC channel, I have no idea why, but me and raph0x88 started chatting about Information Leakage when a programmer “forgots” to return() a value on his/her program (API/libraries included).
    This post exists because more than curious I am really stubborn confident. One post that I’d read that day, was a post about strcmp() C function and its return value, but I’d never spent time testing it…

    Translating, the post says something like:

    As everyone knows (if don’t: man strcmp), the function strcmp() is responsible by compare two strings and return a value that has the same sign as the difference between the first differing pair of characters. This means that if we compare char by char, in the moment of the char in the left parameter differs to the char in the right parameter, the function will return the difference between them. If they match, the function returns 0 (zero).

    Ok, back to our story and my relutant mind, I was thinking: Há, raph0x88 doesn’t know this “feature” of strcmp() – I can fool him! ;D. Below is 10% of our (portuguese) talk:

    <waKKu> raph0x88 eu to dizendo q eu levo menos de 10 tentativas pra identificar CADA caracter da senha
    <waKKu> raph0x88 valendo 1 semana de MESTRE waKKu ? 
    <raph0x88> DUVIDOOOO
    <raph0x88> menos de 10 tentativas?
    <raph0x88> valendo..
    <raph0x88> 1 semana de mestre wakku
    <raph0x88> ou uma semana de mestre raph
    <raph0x88> tu tem q me mostrar um codigo que advinhe uma senha q eu colocar de  10 characteres
    <raph0x88> em menos de 100 tentativas
    <raph0x88> senão é 1 semana me chamando de mestre
    <waKKu> aceito
    <raph0x88> e se tu conseguir, eu te chamo de mestre

    Long story short: I told raph0x88 that I was able to break any character of a string in less than 10 tries. He doubt it and I proposed a challenge: If I get it done, he’d MUST call me MASTER waKKu for one week – If I don’t, I’d call him.
    Well, as I said earlier I actually thought I would need only 1 try for each character, but my subconscious told me to say 10 ;)
    Read the rest of this entry »

    Posted February 10, 2011 by waKKu in Exploiting, Food for thoughts, Programming, Security

    CVE: 2009-0692 – ISC-dhclient stack overflow   Leave a comment

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

    Wassup fellas…

    During H2HC 6th Edition (2009) I went through the COSEINC Linux Exploitation training, taught by Rodrigo Rubira Branco a.k.a. BSDaemon. On the last day Rodrigo launched a “challenge” that could give us an “especial” certificate.
    It was November/2009 and the month’s headline vulnerability was a classic stack overflow in “netmask” field of isc-dhclient.

    I’ll try to disclose all details in the path until the flaw, the flaw itself and at last: my exploit ;).

    So, before start posting a lot of dhclient’s source code here, I’ll try to explain the process within DHCP protocol:
    1– The client (in our case dhclient process) sends a broadcast packet: DHCPDISCOVER
    2– DHCP server answers with a DHCPOFFER packet offering an IP address, netmask, lease-time and other configs
    3– So the client sends a DHCPREQUEST for that offered IP, notifying an acceptance for that configuration
    4– DHCP server then sends a DHCPACK packet, meaning “configuration saved” and finishing the process.

    A– The client now calculates, based on that lease-time previously provided by server, and schedule to send a new DHCPREQUEST packet (also known as Renewing Process) before lease’s expiration time, notifying the server that the client still holds this IP and avoiding the server to deliver it to another client.
    B– Again DHCP server sends a DHCPACK packet to confirm.
    If DHCP server configuration has changed between step 2 and B (e.g.: dns servers, new domain, router, whatever…), the server should attach these new options to DHCPACK packet.

    If we pay attention in this process we realize a “gap” to consider: Until step 4 the client HAS NO IP address! It leaves us with 2 attacking vectors:
    1) Break-in the first 4 steps and utilize a non-network shellcode;
    2) Break-in between step 4 and B and to depend on client’s renew interval.
    I was using an academic setup and had control of both (client and server machines), so decided to go with option 2 and manipulate server’s lease-time.

    After all this intro we still need to understand the flaw, let’s take a look at DHCP’s internal structures:
    Read the rest of this entry »

    Posted February 6, 2011 by waKKu in Exploiting, Programming, Security, Vulnerability Analysis

    0xcd80!?!? What tha f…   Leave a comment

  • Post Info:
    1. # Author: Flavio do Carmo Junior aka waKKu
      # URL: Author’s Webpage
      # Date: February 04, 2011
      # Category: Food for Thoughts, Programming

    You are probably sick of these blog names making reference to l33t assembly instructions but, (un)fortunately, this is another one: – Nbrito – x9090 – xorl

    To those who doesn’t realize the meaning of our blog’s name, here is a not so short explanation:
    “Show me the code!” – People shouted ;)…

    Let’s begin with a simple “shellcode”
    Goal: Perform the syscall exit() with “123” as parameter.

    waKKu@0xcd80: blog$ cat 0xcd80.s
    .globl _start
            movl $1, %eax
            movl $123, %ebx
            int $0x80

    Ok, let’s assembly it. I’m using a x86_64 (64 bits) machine so I’ll specify the parameter --32, so the code will be generated as a 32bits code (actually, in this simple example there is no diference between 32 or 64 bits code).

    waKKu@0xcd80: blog$ as --32 -o 0xcd80.o 0xcd80.s

    Once assembled, the (object) file 0xcd80.o has been created.
    Let’s take a look on opcodes generated by our code:

    waKKu@0xcd80: blog$ objdump -d 0xcd80.o
    0xcd80.o:     file format elf32-i386
    Disassembly of section .text:
    00000000 <_start>:
       0:   b8 01 00 00 00          mov    $0x1,%eax
       5:   bb 39 05 00 00          mov    $0x7b,%ebx
       a:   cd 80                   int    $0x80

    Some of you probably have found our blog already ;).

    For those who still didn’t, I want to introduce you to one of my tools that I always keep into my toolbox.
    Here is the

    waKKu@0xcd80: blog$ ./ 0xcd80.o
    ***** NULL BYTE FOUND (5) *****
    Using 16 opcodes/line
    // ShellCode -> [ 'File:0xcd80.o', 'Size:12 bytes', 'NULLs: 5' ]
    waKKu@0xcd80: blog$

    Hooray!, there is our “\xcd\x80”

    Well, all these lines to say: 0xcd80 or “\xcd\x80” are the opcodes responsible by assembly instruction: int $0x80 when using a Linux x86 system.

    What does this instruction do? This is subject for another post ;)

    Well, we’ve got so far.. Let’s execute our shellcode, but first we need to link it.
    I’ll be using the 32 bits libraries here:

    waKKu@0xcd80: blog$ ld -m elf_i386 -o 0xcd80 0xcd80.o
    waKKu@0xcd80: blog$ file 0xcd80
    0xcd80: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
    waKKu@0xcd80: blog$ objdump -d 0xcd80
    0xcd80:     file format elf32-i386
    Disassembly of section .text:
    08048074 <_start>:
     8048074:       b8 01 00 00 00          mov    $0x1,%eax
     8048079:       bb 7b 00 00 00          mov    $0x7b,%ebx
     804807e:       cd 80                   int    $0x80
    waKKu@0xcd80: blog$

    Trying to ring some bells, another binary’s dump after we’ve linked it. Check the instructions addresses.

    And at last but not least, we execute it:

    waKKu@0xcd80: blog$ ./0xcd80
    waKKu@0xcd80: blog$ echo $?

    There is it, as promised, a beautiful exit(123) executed… Outstanding, no? :X

    That’s all folks!

    PS: If you notice that “NULL BYTE FOUND” warning when using, don’t worry we’ll be talking a lot about it soon.


    Posted February 4, 2011 by waKKu in Assembly, Food for thoughts