There are many classes of vulnerabilities that affect software. One of the first things you have to do is identify a piece of software that you deem worthy to find a vulnerability in. This could be picking a software product run by millions or it could be that your doing a pen test and their is a certain software product that is not well know. After identifying your target you must then learn the software product inside and out and understand as many of the features it provides as possible. The main goal being that you want to attempt to identify all possible area's within a software product where your able to supply data that is then processed directly by your victim program, or area's that eventually pass your user supplied data down to your victim program. An example of a directed attack would be something trivial like overflowing the user command on a ftp server etc... An indirect attack might be handing an sql attack to a web based application which is not stripping "evil" data. If your targeting a product that communicates using an undocumented protocol then your going to have to do a lot more reverse engineering to be able to understand how the product communicates, which leads to you understanding more possible area's where the product is manipulating user supplied data. If you don't have access to the software, binaries or source, then your job is going to be much tougher yet not impossible. However, you should exhaust all possible resources in an effort to obtain the software or an understanding of how the software communicates or works. This could include social engineering the software vendor to obtain a "trial" version of the software or compromising another system, via a known attack, that runs the software and then downloading the software etc... A lot of times though your not going to be stuck in such a black box situation ... unless you've got the NSA or foreign governments hiring you to "break their shit". ;-] In the case of a commercial software product or something more easily attainable... your most likely going to find a wealth of information on how the product works, the protocols it uses, and how those protocols function. In the example of a web server product you already have a big piece of the puzzled solved. You know that its going to be using the HTTP protocol for its communication so your able to read the many many many documents on how the HTTP protocol functions. This makes finding all possible places, to insert user supplied data, much easier. After going through the documented functionality of a product or protocol you will want to do a bit of reverse engineering to find undocumented, or poorly documented, functionality within a product. You can do this a number of ways, pay off an employee that develops the software (heh just kidding), or use reverse engineering techniques. Some of the best reverse engineer tools, for windows anyways, would be IDA (Interactive Disassembler) (http://www.datarescue.com/) and Softice (http://www.numega.com). Although some people, the same "forensic analysis experts" will resort to using just a Strings program to look for hidden commands and such. Not that there is anything wrong with that but I definitely suggest learning some assembly and learning to use tools like IDA and Softice. After you've gone and collected as many possible places where your target product interprets your user supplied data, then you must attempt to attack those different places. Whether they be commands, arguments passed to commands, headers, whatever. The best idea is to make a tool to automate the many possible combinations of attacks. Two of the most common ways to write such a tool would be some sort of a binary auditor tool, or a protocol/network based tool. In the case of a binary auditor you have to understand software a bit more and things such as assembly. Some people write their own binary auditors from scratch and some people go the route of writing a binary auditor that is a plug-in for a disassembly program such as IDA. Binary auditing is good for uncovering hidden vulnerabilities that are not always going to pop up via researching how a program works, from an external perspective. However one of the problems with binary auditing is once you've identified vulnerable code within a binary, how do you trace back up to see how do you, or can you? get your user supplied data into that vulnerable code. For example a program could be using a typically vulnerable strcpy function however if its using that function for two static binaries, which you have no control over, then your binary auditor flagging such code is going to be creating a false positive. Now there have been advancements in automating the tracing of a vulnerable function, within a binary, to see if its ever in a state where it can be manipulated by user supplied data. I know eEye, NSA, China, and the handful of typical "usual suspects" in the hacker circles, all have been working hard on such tools as it makes "slicing" through binaries for vulnerabilities, an easier task. Much like all the source code analysis tools for Unix platforms and such. Also there are some classes of attacks which can be very hard to find within software at a binary auditing level but at the same time there are some vulnerabilities which _ONLY_ can be found via a binary audit. Re: havlar's advanced concepts paper etc... As mentioned earlier the other way to go about things would be at the protocol/network level. The best way to implement an attack at this level would be to write a program, could be in Perl, C, C++ etc... to automate the testing of a piece of software. Sometimes people will write a program to test specific functionality of a software product. For example a tool that simply tries all possible HTTP headers and tries to overflow HTTP headers automatically by incrementing buffers and such. Some people however have more advanced systems that are built off of a database, after lots and lots of research, of how a certain type of product/protocol works. So with HTTP as an example one might have a database of all HTTP methods, headers, specific structures within headers, etc... Then you simply keep updating this database "of how things works" so that your automated tool can use the known structures and understanding of a protocol in an effort to attack that protocol/software to find vulnerabilities. There is a lot more to look for beyond simply shoving large buffers into certain fields within a request. There are also the directory traversal attacks, "evil byte" attacks, format string attacks, and so on. So having your database of information correlate functionality, to types of attacks that the functionality is possibly vulnerable to, will help keep down on the number of different attacks you have to perform. In the end you should have a system that will attempt many different attacks based on the information you've gathered on what user supplied data a program is manipulating, and the classes of attacks that can potentially be passed via your user supplied data. Once you have exhausted the top layer trivial attacks, generic overflows, directory traversials etc... then you can start looking at specific functionality a bit closer to see if by handing a certain functionality a specific buffer it then changes the path of execution to lead you down a path which is vulnerable to a more typical buffer overflow. That is to say that the more you truly understand a protocol and give a program more valid data then the more it is going to process therefore opening up more windows in which code is going to be processing your user supplied data where it was not before. well there is a lot more to it then that and I've merely scratched the surface but i think I've probably rambled more then you all wish me too so i digress. then again its Friday and beer sounds more fun than email. :-] Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities P.S. As to the question on who gives training on such reverse engineering and vulnerability discovery practices... eEye does but its rather expensive, NSA does but its not open to the public, China does but if they see your good at it you wont leave the country. Heh. but seriously its all about reading and learning as much as possible. If you look at bugtraq you'll see most vulnerabilities share a simplistic set of common characteristics. Discovering vulnerabilities is not harder... pushing the ideas on how to go about discovering vulnerabilities, or classes of attacks, now that's fun. | -----Original Message----- | From: kaipower [mailto:kaipowerat_private] | Sent: Thursday, April 04, 2002 5:05 PM | To: security-basicsat_private; vuln-dev@security-focus.com; | vuln-devat_private | Subject: Techniques for Vulneability discovery | | | Hi, | | After reading the mailing list for quite a while, there is a burning | question which I kept asking myself: | | How do experts discover vulnerabilities in a system/software? | | Some categories of vulnerabilities that I am aware of: | 1) Buffer overflow (Stack or Heap) | 2) Mal access control and Trust management | 3) Cross site scripting | 4) Unexpected input - e.g. SQL injection? | 5) Race conditions | 6) password authentication | | Do people just run scripts to brute force to find vulnerabilities? (as in | the case of Buffer overflows) | Or do they do a reverse engineer of the software? | | How relevant is reverse engineering in this context? | | Anybody out there care to give a methodology/strategy in finding | vulnerabilities? | | Mike | | | _________________________________________________________ Do You | Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b30 : Fri Apr 05 2002 - 20:25:47 PST