Buffer Overflow Questions (newbie here)

I've read several books now on hacking- I am A+, CCNA, MCP, & Webmaster Cert. but I
never learned anything of hacking- now I'm interested in this area since I feel secure,
in general, with computers.

I sometimes tend to analyze too much and blind myself to "obvious" answers and solutions.

QUESTION: Where to input/deliver the overflow exploit (egg, PERL code, etc.) ?? I can code, compile, chmod to change permissions, and I understand PERL, I JUST DON'T KNOW WHERE TO PUT THE CODE!!

I know you can cause overflows (& spawn shells) with URL input (like the old phf exploit) , through form text entries on web pages, etc. but, say you telnet to a web server:
>telnet 10.2.40.5 80

and you've telnetted from within a shell on a Linux box at home, and connect to port 80, can you put/run exploit code [perl, C prog (egg), etc.] here, within YOUR shell, on YOUR Linux box or do you need a shell account from THAT ISP, to input the perl code, egg, etc. to try and
spawn a root shell or do some other wak thing ? (or, of course, if you can spawn a regular user shell some other way (URL input, Form input, etc.) you can then run some exploit code within that shell, and try for root. Alos, does the phrase "Shell Code" have different meanings?

BOTTOM LINE: BUFFER OVERFLOWS: WHERE TO RUN THE EXPLOIT ???????????

THANKS, Jim

Jim, this is a place where prevention of such is the goal, not telling you how to run an exploit of all things. I'm sorry dude but you may have the wrong impression of this site.

Not to give the impression that I support the line of questions you've put forth (as this is a security site, not how to exploit), I will answer the question simply.

No, you cannot run shell or exploit code strictly through a telnet'd connection on port 80. That's generally the web server and it's not going to know what to do with your "exploit". Now, if the exploit is specifically through text input on a badly-checked field or wrong data can be entered into a spoofed url (or other such things), then yes, the "exploit" could be manipulated through whatever is doing the processing (cgi, php, asp, etc)...

Yes, indolent, I fully respect your position and reply to my post.
I really don't "hack/crack"- as I've never done this in my life- just
learning how it's done- and I've learned "TONS" about security in
the process. Just love "learning".

Thanks for the reply-

Jim

Depends.

Many compiled/executable exploits you just run and it prompts for the target IP (and port)...
Remote buffer overflow exploits can involve techniques such as remote telnet/netcat to "send back" a shell prompt...

Ammo

heartbreaking jim i must selute you.what a wonderful way of asking "how to hack?"on AO.

Jim,

You don't seem to be a bad guy and if you are stuck at this point then you are going to have a real hard time moving forward if you are a nasty little POS....... ;)

Any buffer overflow is basically exploited in the same way as you have described. The problem you have is the proper examination of the system you are trying to exploit. Let's say you want to bash away through a telnet connection and that the telnet server is actually vulnerable to a buffer overflow. What you have to determine by watching the way memory is allocated and buffer space, (which is just memory space), is allocated for each input at any point in a given sequence of events. You may issue commands 1, 2 and 3 in that order and find no potential exploit since the memory usage would be such that the injection of your code will no get exactly into the right place to be executed on a jmp or ret for example. If however you were to execute the same instructions in the order 2, 1, 3 you may find that the exploitable buffer in command 3 could now effectively inject executable code into the appropriate area of the stack such that a cancel command for example would cause a ret to be executed calling the code you injected into the stack.

Now, remember, for the most part you need the exact version of the remote OS and telnet server running on your own system in order to be able to capture the information you require. You also need a lot of time and patience before you stumble across the appropriate sequence of events that would create the potential for exploit and then you have to be able to recognize the fact that the potential is there. Then you have to write the code and translate it such that it can be injected into the remote stack in an appropriate fashion so as not to crash the remote.

Now, if you really have the time and energy to go through all that simply to own another box good luck to you.

OTOH, if you are truly interested in security you will spend that time learning how to recognize compromise and how to ensure that you have all the log files and systems in place to be able to recreate the events and, hopefully, prevent such from occurring again or, even better, track the little B@st@rd down and report his dumb @$$.