RE: Techniques for Vulneability discovery

[Ed Moyle <emoyle () scsnet csc com>]

On Thursday, April 04, 2002 20:05, kaipower wrote:

> Anybody out there care to give a methodology/strategy in finding
> vulnerabilities?

Hi.  I'm responding to this on vuln-dev because it seems 
most appropriate there.  Sorry in advance for the long mail, but
I've been thinking about this myself recently.  I'll share with
you my speculations on the topic thus far.

I'm of the opinion that unless your job/hobby is looking for this
stuff full-time, an effective strategy is to "keep your eyes open."
Most software, in my opinion, is poorly written enough to contain
multiple security problems.  Many people say that security problems
in software are inevitable, but I heartily disagree with this.  For
example, why do we still have buffer overflows in software when 
object-orientation can completely eliminate this type of problem?
(specifically, write a string class and use it everywhere.  Make
sure that it does appropriate bounds checking and allocates memory 
on the heap.)

In general, it would seem to me that cultivating the
ability to always keep one eye open for potential attacks and
ways to defend is part of what it means to work in security.  If 
this is your philosophy, the hard part becomes not the discovery of
problems, but in working up the motivation to write it up and 
do the other associated legwork required in order to contact vendors, 
write exploits (if you are so inclined,) research previous alerts to 
find out if it is already addressed, etc.

> How relevant is reverse engineering in this context?

I think it depends somewhat on the type of vulnerability you are 
analyzing, but in general, it seems to me that mostly it comes 
down to trial-and-error rather than reversing.

For example, if you're trolling for buffer overflow problems, it
would be somewhat useful to have a working knowledge of C or C++.
(Really, though, you don't need to be a professional developer
to do this, because you don't have to care about supportability,
elegance, readability, reproducibility, etc in order to find bugs
or write exploits.)  All you have to do is know how to use a
debugger and be familiar with the platform you are on (e.g. how
memory is laid out on your target OS and architecture.) In this
case, you really don't have to "reverse engineer" per-se, you just
need to pay attention to what the app is doing and think about how
developers might make the "classic mistakes".  Then, just try
different things to see how you might make it fail given your
hunch about what the developer is probably doing.

If you consider the case of cross-site scripting, trying to 
reverse engineer software to find this would be a little bit... 
um... over ambitious.  In this case, trial and error would seem to 
be the way to go.  I would think that probably sites are vulnerable 
to cross-site scripting more often than not.

I don't know anything about SQL injection or race conditions, so 
I won't go there.

I guess if you are trolling for hard-coded passwords/keys in
application software (more apps than you think do this,) this
is when a really solid knowledge of reversing would be good and
the trial-and-error bit ceases to be as useful as in other cases.
There is a really strong "body of knowledge" (shady though it
might be) out there for doing this, because it is essentially 
the same skills that people have used to break software copy 
protection schemes since the 80s.  Note that this is not a really
smart activity to participate in (what with DMCA and all) but
there has been a *LOT* of discussion on the topic over the last
couple decades.

Oh well, sorry for rambling,
-E