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
This archive was generated by hypermail 2b30 : Fri Apr 05 2002 - 14:57:09 PST