buffer overflow

im learning buffer-overflow and im tring to attack a server that i was build , but the server is not using the function "strcpy()" , so what else did i need to search, for doing the BOF ?

welcome to AO!

we probably need some more info about the server... whats running on it?

ya think :rolleyes:

MLF

the server got tcp-connections, and if u connect with the standart client (that i was build speccely for this server) u`ll get menu with this option :
1.add user (and then u send him the username)
2.start new game and so on..
i tryed to send allot of junk beside the username and look at ollydbg what happened, but nothing happened..
there is any more details i can tell u ?

Why not learn with something you've made yourself instead of a blackbox?

http://insecure.org/stf/smashstack.html

its not a black-box its a server that i was build...

by the way: i was read this article , but its not help me coz the server isnt using functions like "strcpy(), scanf() and so..", so i want to know what did i need to search for now... i mean , how can i found a vulerability in this server ? (what did i need to looks for..).. ?
thanks !

Hi

I like your approach to learn the issue of buffer overflows. As per answering
your question:

Simply spoken, all buffer overflows have in common that you are using some
fixed buffer or you allow the user (or service) to specify the buffer to be
allocated. While the latter seems strange, still nowadays some (older)
applications are in use, which actually trust their clients, allowing for this
scenario.

Because of this generic character, it is thus impossible to give a complete
list (I wouldn't be able to) - sure, check for strcpy, scanf etc. but, more
general, check for all parts in your code where user (or service/protocol/...)
input from "outside" is used - directly, or more difficult to detect, indirectly.
For example, with your little server - what happens with the recv-buffer?
When do you use it, where does it have some impact?

Furthermore, which OS do you use, which Programming Language, which
Framework? It all depends - in particular the existence of a vulnerability:
even if you have found a security flaw, a vulnerable state, which
allows to reach a compromised state using authorised transitions, may not
exist at all.

If you post reasonable code-snippets, I will try to have a look at it :)

Cheers, and good luck.

P.s. Nowaday, fuzzers become more and more popular. What kind of protocol
are you using? You may find one, which will be appropriate to find some flaw
in your program.

first of all, thanks sec_ware !
the protocol that running is TCP and i tryed to send data and triggered the overflow and when im watching ollydbg i saw that the eip is overwrited by this address: 000012FF (no matter is im sending 1 byte more or 500 bytes more), and i want to know if this is a well known address or something common ?

if some1 know a good article (and programs) about fuzzer ,i`ll apericate her help..

@mystic-d

First You must learn about security protections of yours OS. If I`m right you are using Windows and that means that you must know what is /safeseh, /GS, DEP, etc ... (this allude that you know what is buffer overflow, format string, code injections, pointers overwite, memory leaks, race conditions, etc ...).

Than, If you write your own server You will know if there any vuln ... and You can practise writing exploits (You "must" be master of debuging).

Read, read and read ;)

By blackbox I meant something which you don't know about.. A blackbox approach means I know nothing about the internals and I'm just using varied inputs to see how it would respond. This is a different approach from having access to the source and being able to see the internals of the software, how it works.

The simplest is to use A (0x41) as your buffer.. If eip gets overwritten with something in your bufffer it will show up as 0x41414141. By using AAABACAD etc. you can even work out which bytes in your buffer are actually overwriting eip.

like i said before: thats what i did, but all the time the eip was overwrting by this address: 0x000012FF , so maybe its one of the defense on windows..

Then you aren't overwriting EIP..

It might be some errorhandling routine that chokes.. Look at the backtrace to see what's happening before the crash.

how can i do this backtrace ?

someone ?

Mystic-D ....Obviously ...your havent read the posts...but want someone to spoon feed you....

sorry..cant help you...but I do see alot of informatiom in the thread

you havent answered any questions...but want answers from your very vague questions....therefore you get and well deserve.. very vague answers

:rolleyes:

MLF

maybe im not clear,so i'll ask again ... (sorry if im disrupt someone, im just tring to learn) , i have a server (that i was build in C), this server is got username from the client (the username is going onto buffer of 24 bytes) and im trying to exploit this buffer and overwrite the eip...
the connection is over TCP protocol.
so i was trying to exploit this buffer by send 50 bytes of junk (AAA'..) and by send 1000bytes of this junk, and no matter how much im sending, when im watching the olldbg i saw that the eip got this address: 0x000012ff, i removed the DEP option for my server exe file.. and i know that maybe its going to this address all the time is coz the SEH..
so plz maybe someone can help me and tell me how can i overcome this or give me a cue to what can i do now..(or how can i backtrace it..) ?
if someone have any questions about the server so jusk ask.. (its a really minimal server...)
thanks alot !

Yes, you've been very clear. You've said the same things over and over again. I can read, even between the lines...

You're trying to run before you can walk my friend.. It took me 20 years of computing, learning and trying to become what I am today and I'm still learning new things every single day.. Learn the basics first, learn them well, take it step by step.. You simply cannot cut corners or you'll be lost. Despite what everyone wants you to believe, buffer overflows are far from simple. They're only simple if you know how a computer works, how compilers do their job, what makes them 'tick'. Yeah, sure, you might get there faster then me but please, don't think you can master this in a week..

Learn how to use a debugger first.. Then you would know how to backtrace.. Learning how to use debuggers and the interaction between assembly and C/C++ is essential knowledge if you want to learn about buffer overflows..

so first i`ll learn to walk... so i have another question:
did someone know how can i exploit the function "recv()" in C ?
im trying to send more than the buffer size can get..but the recv() function write only the first data into the buffer....
or maybe someone know whats happened to the last DATA that was not write to the buffer..( i mean,where the func or OS write the last data)..
thanks !

Hi

Apologies: I will be slightly off-topic regarding the initial request,
but on-topic with respect to the last questions posted by the thread
starter.
--

Quote:

---

did someone know how can i exploit the function "recv()" in C ?
im trying to send more than the buffer size can get..but the recv() function write only the first data into the buffer....
or maybe someone know whats happened to the last DATA that was not write to the buffer..( i mean,where the func or OS write the last data)..

---

These are good questions - I was asking myself the same a while ago.
You should realise that there is no magic in all that - most of the basics
are documented and ready to be studied - since at least 1981 ...


To give a short anwer:

Based on the here discussed sockets-approach, the recv-call, which is
available to the user, reads a certain amount of bytes from a receiving
buffer (often called recvQ). Since recv() allocates the needed amount of
bytes in the memory, and does not read more than that, it is not possible
to find a direct attack vector in this strict sense. However, you have to
check the specific implementation (easier if open source) - what you find
is that recv.c calls _recfrom, which itself calls kernel_recvmsg, which
again call socket_recvmsg, which uses _sock_recvmsg - so to speak
going to lower and lower layers.

Let's go back to recv() ("first step"), which reads from the receiving buffer.
The size of that receiving buffer ("second step") is being controlled by a
parameter called SO_RCFBUF (the sendQ-buffer is controlled by SO_SNDBUF),
which can be tuned: as you may know, the performance of a connection
strongly depends on this parameter and the nature of the media, the MTU resp.

Now, what happens if you send more than the recvQ-buffer can hold. At
this point, the TCP flow control kicks in: the recvQ-buffer will not receive
anymore data. However, it will be (at least partially) cleared as soon as
the next recv() is called - allowing for new data to be received in recvQ.
So, can you force the recvQ-buffer to receive more data than it can hold?
No. So can you abuse it? No, not directly.
What about the TCP flow control ("third step")?


So, what can we learn from this?

Maybe, it is not the obvious path, which leads to "success" in abusing
some protocols or implementations of them. But by learning the details,
one may recognise one or another weakness - maybe just a flaw, maybe
a vulnerability. I won't tell you that you should read the rfc's (you
won't do it anyway ;) ), however, have a look at this paper[1], which
gives a nice overview of the TCP protocol and some of its weaknesses
(congestion, handshake) - in case you want to go a bit deeper than ordinary
(but not simple) application vulnerability development. Certainly, there
are dozens of papers like these, but I liked it and it is a start - even,
if those weaknesses get obsolete.

Have in mind, that from a security perspective, flaws which can lead
to denial of services (as a while ago in setsockopt in the
bsd-implementation), also are critical, even if the flaw cannot be
misused to "spawn a shell".


Anyway: you see there is a huge pile to learn - do you want to
understand application debugging (user mode), do you want to
get a general understanding of protocols, etc.etc. choose what
you like and what gives you "the kick" - motivation is crucial.

Cheers.


[1] http://www.csc.lsu.edu/~durresi/CSC7.../3_7502_04.pdf