Re: Blind Remote Buffer Overflow

[marc () EEYE COM (Marc)]

| -----Original Message-----
| From: VULN-DEV List [mailto:VULN-DEV () SECURITYFOCUS COM]On Behalf Of
| Granquist, Lamont
| Sent: Thursday, April 27, 2000 4:47 PM
| To: VULN-DEV () SECURITYFOCUS COM
| Subject: Blind Remote Buffer Overflow
|
| What does a theoretically feasible attack of this nature look like?  Lets
| say that you're up against a webserver that runs some CGI C.  How do you
| find and exploit a buffer overflow without having access to the code?
|
| It seems that you first need to find a buffer overflow.  What is the
| symptom here because when you dump core on one httpd proc then you'll just
| spawn another one.  The service doesn't go down, so how do you know you
| just caused the proc to core?

I do not do Unix but in the NT world a few things can tell you you've found
an overflow:
When you start stuffing buffers into the exe or cgi and it returns nothing
at all and the connection drops.
When the web server returns you an error saying "cgi script returned an
invalid set of headers"

| Then once you've found a buffer overflow, I guess you need to start
| blindly guessing buffer sizes and locations until you get a winning
| combination -- here the fact that webservers respawn would decidedly work
| to your advantage.  You can also probably bet that the buffer size is damn
| close to whatever size causes the proc to core, if you can determine that.

As for buffer sizes you could do the following:
First do a regular request on the cgi to learn the "norm"
Then start loop request and changing the buffer sizes.
For example start with 4096 A's as your buffer and see if it returns "the
norm"
if it doesnt return the norm then make your buffer smaller and smaller until
it does return the norm. this way you can learn the last size of "norm" and
the first size of the "diff1". now you know the max input size before the
server overflows.

Now sometimes you might pass an input buffer 1k of characters and have it
return one thing then 2k return another and 3k return another.

In Retina we have code that searches out overflow lengths. We can pinpoint
the overflow because we know the two returns with the biggest lengths are
our norm and overflow. For example 1-1k of chars will return norm. Then
maybe 1k to 1.5k will return an error message, call this diff1, then 1.6k
and beyond return another value or nothing at all. that way we can have the
software search out overflows without a human needing to read through GET
logs. entrance mini-ai. bla bla bla i'm probably not making sense.

| Can anyone flesh this out further, or knock big holes in this process, or
| think of a radically different approach which is better?  Then, how can
| you make it even harder to exploit these kinds of holes blindly?

the next thing you'll need is offsets to functions of dll's you think will
be loaded (for your shellcode). the first thing you want to know is if the
remote server is NT3.51, NT4, or NT5. Nmap should tell you that. So says its
NT4 then the next thing, to make life easier, we want to know is what
service pack it has. We can usually determine service pack by querying other
services. For example if netbios is open (hopefully it isnt) we can easily
learn the service pack. However, say netbios is not open but FTP is... some
FTP command return different depend on what service pack your running 4,5,6
etc... the once we know the sp version we can get the correct offsets for
functions.

anyways hope this helps and isnt just a lameass brainfart

dont forget the small little point of a mem location that returns to your
shell code heh.

Signed,
Marc
eEye Digital Security
http://www.eEye.com