Re: Techniques for Vulneability discovery

[3APA3A <3APA3A () SECURITY NNOV RU>]

Dear kaipower,

I   can   say   for   SECURITY.NNOV   (you   can   find   advisories  on
http://www.security.nnov.ru/advisories  ).  We're  not "bug hunters" and
never specially dig for bugs in software (except very few situation than
I  was  asked  to  check  software  for vulnerabilities, like in case of
FTGate).

Usually  bugs  discovered  as a result of problem solving (that is after
we're aware of some problem found by user or system administrator we try
to  research this problem and discover the source of problem. If the bug
found  in  software  we check for possible security impact). For example
The  Bat!  directory  traversal  was  found because of attachment bug in
chat.ru  freemail  server,  Outlook  Express address book weakness after
researching  the  problem messages sent by user to specific e-mail never
reached  recipient.  Format  string  in  AVP for sendmail as a result of
coredump research after continuing server crash, etc.

Few bugs found are result of "Mind games": we just try to do new concept
of  attack.  "Unsafe fgets()" bugs, content filtering bypassing, Windows
2000  Group  policy  DoS  and few not yet released bugs were guessed and
than confirmed to be in-the-wild in different software.

Third  category  of  bugs  are  bugs discovered during source code audit
(bugs  in RADIUS, sendmail/qpop, few non-exploitable buffer overflows in
fetchmail,  etc)  -  I  needed  to  check  some pieces of code from this
products and during source code review these problems were discovered.

--Friday, April 5, 2002, 5:04:33 AM, you wrote to security-basics () securityfocus com:

k> Hi,

k> After reading the mailing list for quite a while, there is a burning
k> question which I kept asking myself:

k> How do experts discover vulnerabilities in a system/software?

k> Some categories of vulnerabilities that I am aware of:
k> 1) Buffer overflow (Stack or Heap)
k> 2) Mal access control and Trust management
k> 3) Cross site scripting
k> 4) Unexpected input - e.g. SQL injection?
k> 5) Race conditions
k> 6) password authentication

k> Do people just run scripts to brute force to find vulnerabilities? (as in
k> the case of Buffer overflows)
k> Or do they do a reverse engineer of the software?

k> How relevant is reverse engineering in this context?

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

k> Mike




k> _________________________________________________________

k> Do You Yahoo!?

k> Get your free @yahoo.com address at http://mail.yahoo.com





-- 
~/ZARAZA
Ñòðåëÿÿ âî âòîðîé ðàç, îí èñêàëå÷èë ïîñòîðîííåãî. Ïîñòîðîííèì áûë ÿ. (Òâåí)