GUIDE to (mostly)
Volume 3, Number 12
Shortcuts to Discovering New Ways to Break
In this Guide you will encounter:
* Tools that can help you discover
new ways to break into computers:
-- source code
you can do with your discoveries
*** Tools ___________________________________________________________
This Guide will not guarantee that you will suddenly start
finding lots of "0-day" exploits. However, it does
offer tools and strategies that make it more likely that you
could join the ranks of those who discover them.
Newbie note: "0-day" is pronounced
zero day, and is hacker slang for break-in exploits that have
not yet been made public.
There are many ways to discover new ways to break into computers.
You could set thousands of crows to work pecking up birdseed
scattered over the keyboards of thousands of computers. In theory,
this could work, but it might take a million years. You could
just sit and think hard enough and discoveries would pop into
your head, but this is almost as hard as using those crows.
It is much more fun to try to discover security flaws when
you know you are likely to succeed. Those who do this for a living
have developed many tools to make discoveries almost certain.
This Guide shows you where to find these tools and how to use
However, before we go any further, here is the most important
point of all. If someone is dumb enough to run tests for security
flaws against somebody else's computer without their permission
IN WRITING, and that fool manages to break in, that is definitely,
absolutely, screamingly illegal. Computer security researchers
who have at least half a brain test programs on their own computers
and networks. Beside being legal, this makes it much easier to
observe the results of your tests.
*** Source Code Tests
Many companies have teams that test their products for security
flaws. Analysts with these teams have access to the source code
of the programs they test. This is called "white box"
analysis. Usually they do this with programs that scan for commands
or syntaxes that may predispose programs to problems.
You don't need to have a job testing software to get to do
your own white box testing. Your first step is to get the source
code of the program you want to study. "Open Source"
programs (see http://www.opensource.org/docs/products.php)
all make their source code public. Any software developed under
the GNU license (see http://www.gnu.org/
also has publicly available source code. If you can find security
flaws in any Open Source or GNU software, and if you report the
flaw to the programming team, they will usually thank you for
your help. (See below for more about options for reporting your
Another consideration in choosing which programs you want
to test is that some languages make it easier for programmers
to accidentally create security flaws. C and C++ are super notorious
for this. Nevertheless, many people choose to program in C or
C++ because they run much faster than, for example, the super
safe (but not perfect!) Java language.
The greatest opportunity to find security flaws is within
software written by organizations that use hazardous programming
languages, whose programmers don't know how to write secure code,
and who don't test their software for security flaws.
For example, many CGI programs (Common Gateway Interface,
a standard for webserver helper programs) are written in "interpreted"
languages such as Perl. These programs are often called "scripts."
An interpreted language isn't stored on a computer as a compiled
program (binary). Instead, it is stored in the form of the original
programming commands: source code! Each time a program that was
written in an interpreted language is run, its commands are converted
on the fly into the sequence of zeroes and ones (binary) that
the CPU can understand. Therefore, if you can get a copy of a
program written in an interpreted language, it will always, by
definition, be the source code.
Many CGI programs are publicly available, and are written
in interpreted languages. Examples:
· Matt's Script Archive, free Perl CGI programs: http://www.scriptarchive.com/
· A collection of CGI scripts in many programming languages:
Oftentimes CGI programs have been custom written for a specific
web site. Sometimes you can find their source code with this
sort of URL: http://victim.com/cgi-bin/. Most of the time when
you try this trick, you'll just get something like "You
don't have permission to access /cgi-bin/ on this server."
At other websites, you might get lucky. You can see a screen
shot of one of the times when I got lucky at http://happyhacker.org/gtmhh/searchengine3xtra.shtml.
If you want to be a good guy, you can tell the webmaster that
his or her CGI is showing.
Once you have decided which program you will test, the next
step is to obtain tools that scan code written in that language
for vulnerabilities. Warning: the false positive rate for some
of these tools is over 90%. That means that some nine out of
every ten vulnerabilities some of these programs say they find
will turn out not to be security flaws, after all. (How many
false negatives they miss is another issue!) However, these programs
at least narrow down your search to sections of code that have
a higher probability of containing security flaws.
Free programs that scan source code for flaws include:
· ITS4: A Static Vulnerability Scanner for C and C++ Code:
· Flawfinder C code scanner: http://www.dwheeler.com/flawfinder/
· RATS - Rough Auditing Tool for Security: http://www.securesoftware.com/rats/
Once one of these programs identifies suspect portions of
code, your next step is to figure out an exploit program that
can test it. How you test will depend upon the kind of flaw you
think you have found. This is a complicated topic; for lots of
details, see my book Uberhacker II:
More Ways to Break into Computers. Some chapters are
available free online at http://happyhacker.org/uberhacker/.
Note that most exploit programs are written in C or Perl.
Yes, that means you need to learn how to program if you are serious
about making discoveries. See http://happyhacker.org/gtmhh/
for some tutorials that can get you started. However, your best
bet for learning how to write exploit programs to test for security
flaws is to go to a four year college and get a degree in computer
science, computer engineering or electrical engineering. Those
computer security certification courses and hacking boot camps
are no substitute for a college education. Nor is reading a stack
of computer security books enough. If you are serious, think
four years. Or six or more if you have the guts to go for an
Back to the Guides to
(mostly) Harmless Hacking --->>