OK...I've been learning about network security for a few months now. In these few months I have learned how to write code, compile it and ultimately...compromise a machine on a network using several different methods.

When it comes to the basics of exploiting a buffer overflow vulnerability and writing code to run on the remote host, I know almost nothing...which is why I'm asking for someone with a bit more knowledge than myself to help the other members and I.

Ok. What I do know is that buffer overflows occur when attempting to write data outside of an arrays memory reference range. By this, I mean, for example, trying to assign a value to array_var[11] when array_var has only been allocated 10 slots of memory for the data in declaration.

So heres some vulnerable code below:

----------------------+ Turbo Pascal +------------------------

Program Buffer_Overflow;

uses WinCrt;

var
vuln: array[0..9] of char; {vulnerable array}
n: integer;

begin
for n := 0 to 10 do
vuln[n] := readkey; {assign vuln[n] single key pressed by the user}
end.

----------------------+ Turbo Pascal +------------------------

Well even if you havn't learned Turbo Pascal (easiest language in the world) then I'm sure you can work out what the above code does. When compiled, the overflow occurs on the 11th keypress of the user. The program will then stop responding.

Maybe someone can now elaborate on this and explain what an attacker might be able to do with this (if the data was entered over a network with a streaming data socket) to compromise your system.

This link may help:

Haitchttp://www.uhagr.org/papers/UHAGr-Bof.txt

What you have stated so far is correct. I will attempt to explain the basic theory of stack based buffer overflow exploitation.


Certain languages such as C, C++ and Pascal don't have garbage collectors preventing data from being written outside of allocated space - other languages such as Perl and Python are therefore immune, as they do have garbage collectors to prevent this type of thing.

A buffer overflow occurs when too much data is written into a buffer, which doesn't have enough bytes allocated to hold it all. Therefore, the remainder of the data spills over the 'bounds' of the buffer, overwriting the Stack Frame Pointer, return address, several general purpose registers and other parts of the memory. The 'return address' is a very important part of program execution - this register controls the "program flow". It works basically like this:

- An instruction finishes executing
- The address of the next instruction in memory is placed into EIP, the instruction pointer - this register holds the "return address"
- The program "jumps" to the address held in EIP
- The instruction is executed

This process basically happens in a non-ending loop until all of the instructions in the program are executed (in theory, but some instructions are in reality skipped, because users can choose different options and stuff).

So, now we know this; after the execution of an instruction, the memory address held in EIP is jumped to, and the instruction found there is executed.

However, what do we know about buffer overflows? So far we know that when more data is shoved into a buffer (array) than is physically possible, it OVERFLOWS THE BOUNDS OF THE BUFFER, "SPILLING" INTO UNAUTHORISED MEMORY. It should now be noted than data which overflows the bounds of the buffer/array, if there is enough of it, can overwrite EVERYTHING on the stack beyond the location of our buffer, in theory.

Therefore, if we overflow a buffer in a vulnerable program with enough data, WE CAN OVERWRITE EIP, THE RETURN ADDRESS. This is a VERY important concept to learn, as this is what makes exploitation of buffer overflows possible. But what if we overflow the bounds of the buffer with enough data to overwrite the content of EIP? The program *WILL* jump to that memory location. But, what if we overwrite EIP with a memory address which WE KNOW DESIRABLE CODE IS LOCATED AT? The program *WILL* execute that code! Exploited. This can potentially result in a shell or execution of any other code, if we can overflow the buffer to put that code somewhere in memory, and then overwrite EIP with the approximate address of that code.

So let's sumarise what we would need to do to exploit a buffer overflow vulnerability:

- Place our arbitrary code ("shellcode") in memory by overflowing the buffer
- Overwrite EIP with the memory address of our shellcode by overflowing the buffer
- The program jumps to the NEW contents of EIP - THUS EXECUTING OUR SHELLCODE

0wned

Do you understand the basic concept. If you don't, or my explanation was shitty, I WILL explain again. Don't by any means just say you did understand my explanation, if you don't understand it yet, PLEASE DO ASK ME AGAIN. I literally have all day. Drop by on IRC aswell

If you want, I will do a demo for you. Not faked - just a real demo.


-Shaun.

nice explanation

thhnx

yeah this thread could become interesting

i also have some questions on that matter - hope it isnt too much ^^:^

1.) how do u know how much data (shellcode) u can stuff into the buffer? i mean it isnt unlimited is it? does it depend on the program u want to exploit?

2.) is there a difference between offset and ret-addy or is it the same?

3.) why can u chose the ret-addy as a conastant value? i mean doesnt the ret depend on how "full" the stack is? or is the buffer always on the same place on the stack?

4.) could u generally explain how u work with that jump and call commands? i didnt really get that yet :S

5.) how many NOPs do u have to put @ the beginning of ur shellcode? does this also depend on the program u want to exploit?

well i think enough questions for now. would appreciate it if u could help me a bit. and sry for my bad english...

greetz,
buzz

Can I just say that the link posted by OneNight was a very good paper - I read that but did get a little confused when they started disassembling programs and overwriting the EIP to execute cached system calls.

Anyway...Shaun2k yes I do fully understand the concept of it and how it is done and the demo sounds great! Maybe you can do a win32 demo and show us how to find the exact amount of bytes it will take to cause a segment fault, where we can start inserting shellcode and then how to execute it. I've still got a great deal to learn, and my advice to other readers would be to read the paper posted by OneNight then read shaun2k's post....and hopefully he can give us a demo?

thx for ur answers first of all! that helped me a lot!

as for the demo: i would prefer a demo of a shellcode executing a cammandshell on a win32 machine! im not that much into unix yet...

greetz

Yeah, this topic is very interesting.

So, how would you exploit some code like this:

Yeah, this would be quite easy. Gimme 10 minutes, and I'll post a sploit for this code.


-Shaun.

Blasta, I compiled your example program, set it to SUID root, and exploited it.

Here:

so this is a new exploit thats been discovered or just testing ?

Its an example exploit...
The easist exploits to do are the ones that use Enviroment variables to store the shellcode.. You dont even have to have a NOP sled you can get the exact location of the shellcode and avoid ids detection just by doing the math.. and getting the exact location and keep in mind litte-endian.. which means
0xbfff8080 would have to be put into memory like \x80\x80\xff\xbf

So, I got 2 questions:

1) Why did u use the perl command (echo `perl -e 'print "..."'`)? Can't you just use echo "HACK\x90\x1f\x0e\x40HACK\x27\xfe\xff\xbf\x22\xfb\xff\xbf"?
2) How did u get the offsets of the chmod call and your two variables OURSH and OURMODE?

Ok I here i go hope that nobody beats me for that

I found a (I thought) very simple example of a way the buffer can be manipulated.

The code
############

I'm not sure it's actually possible that way. Use some assembly language to munipulate the EIP instead:

__asm__(" add $0x??, %eip
ret ")

From your code I can't tell how much to add to the Infrastructure Pointer but I think you can do it this way.

you cant use echo because it doesnt convert the hex values to ascii to pass to the buffer
and you can make a simple c program to get the enviorment variables address
char *hax;
hax=getenv(argv[1]);
if(hax==NULL) exit(1);
printf("%s locatated at %p\n,argv[1],hax);

Listen to blackknight, he knows his shit.

Yeah would be good to give to the community good bunch of guys..
I can even tell you howto write your own shellcode
and how the calls are made.. so you can pretty much write any shellcode you want
Will even tell you howto print it so u can easily import into a file...

Windows shellcode is a bit of a tedious task and requires screenshots normally.. so we should start off with linux and see where people are at and what needs to be done

But yeah post ideas on what you guys want the lecture to be about.. i can explain very indepth on how the whole process works. And explain why it works etc..
and tricks to avoid IDS detection

edit: Note when you are explotining using getenvaddr the env variable will be padding the shellcode etc.. so keep that in mind because if its not divisible by 4 you will have a segment overflow

An IRC-lecture would be great, but I think it could get difficult because of the different time zones. I, for example, live in Germany. Don't know where you live?!

Another prob I see is, that I don't know much about Linux. I installed Knoppix under Vmware on my laptop, but don't know if this is the best?!

Blackknight has agreed to do a lecture with me. He'll be head-lecturer - we'll give details of when a little later.

We will keep a log of the lecture, so something can still be gained from it. Any questions that weren't asked because of absence can be asked in a thread we open, to distribute the IRC log.

To help combat the problem of misunderstandings and not having Linux, we are going to prepare lecture notes after the lecture is over, helping people further with concepts explained. We will also seperate the lecture into seperate parts, such as Windows, Linux, etc. Blackknight has access to Windows & Linux, so it shouldn't be a problem.




-Shaun.

OK. Thanks guys for taking the time to do this but could you keep in mind for the lecture that I'm still pretty uneducated as far as programming is concerned. I understand the concepts of exploiting a segment fault vulnerability (aka stack overflow) but only understand what I've been taught in college about assembly code and registers, which, inconveniently, isn't much

I'll read some stuff about dynamic memory allocation and hex etc. before the lecture, as to be up to scratch on my knowledge of what your gonna be talking about.

Thanks again

and script god is right u never overwrite the eip.. you overwrite the stack frame pointer so it jumps to ur function after that function has finnished..
In asm you can actually right a lil piece of code that prevents this

cool . can't wait for the lectures. this topic is very interesting. thanks a lot to all of you

Gonna install linux again, very nice there people that want to show his skills and want to teach people

Interesting discussion. I'd like to hear more about Windows stack based overflows while you guys are at it.

I've already read every Windows based text that I could find on the web. There hasn't really been a clear tutorial on windows using a simple C++ applet that actually details exploitation from start to cms shell or cmd execution.