Results 1 to 7 of 7

Thread: Buffer Overflow Questions (newbie here)

  1. #1
    Junior Member
    Join Date
    Feb 2003

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


    THANKS, Jim

  2. #2
    Senior Member
    Join Date
    Jan 2002
    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.
    what is love but contempt for hate?

  3. #3
    PHP/PostgreSQL guy
    Join Date
    Dec 2001
    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)...
    We the willing, led by the unknowing, have been doing the impossible for the ungrateful. We have done so much with so little for so long that we are now qualified to do just about anything with almost nothing.

  4. #4
    Junior Member
    Join Date
    Feb 2003
    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-


  5. #5
    Senior Member
    Join Date
    Sep 2001

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

    Credit travels up, blame travels down -- The Boss

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

  7. #7
    AO Ancient: Team Leader
    Join Date
    Oct 2002

    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 @$$.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts