GUIDE to (mostly) Harmless Hacking

Volume 3, Number 12

Shortcuts to Discovering New Ways to Break into Computers
____________________________________________________________

In this Guide you will encounter:

* Tools that can help you discover new ways to break into computers:

-- source code tests
-- disassemblers and decompilers
-- debuggers
-- fault injection
-- memory exploits

* What 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 them.

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/ and http://directory.fsf.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 discoveries.)

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: http://www.hotscripts.com/
· Java and Javascript: http://www.javascriptkit.com/cutpastejava.shtml

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: http://www.cigital.com/its4/
· 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 advanced degree.

More --->>

---

Back to the Guides to (mostly) Harmless Hacking --->>  

---