RE: Techniques for Vulneability discovery

["Marc Maiffret" <marc () eeye com>]

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:kaipower () subdimension com]
| Sent: Thursday, April 04, 2002 5:05 PM
| To: security-basics () securityfocus com; vuln-dev () security-focus com;
| vuln-dev () securityfocus com
| 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