graudit is a static analysis tool which is basically grep on crack. It is essentially a bash script which uses grep to find very low hanging fruit (issues) with your PERL, PHP, JSP, .Net, and Python source code. While this tool is a good first start, especially for developers with little secure coding knowledge, it does not take the place of a good audit application like O2 or Fortify 360 SCA.
Getting a feel for the tool
graudit is developed and maintained at http://www.justanotherhacker.com/projects/graudit by a very knowledgeable hacker (whos name I do not know and could not find on the website – sorry). The reason I think the developer is knowledgeable is due to the other blog posts on the website. Going by these articles, the developer has a vast knowledge of web application security and posts regularly with his/her thoughts. I highly recommend ingesting the RSS feed on your fav reader.
graudit is currently at v1.6 and v1.7 is supposed to be available soon as well. It is an OSS project and the developer has another project to test websites and clients to those websites as well.
After downloading and extracting the tarball, we are left with a directory structure like so…
drwxr-xr-x 3 mduncan mduncan 4096 2010-05-14 05:27 ./
drwxr-xr-x 80 mduncan users 4096 2010-06-02 12:53 ../
-rw-r–r– 1 mduncan mduncan 1463 2010-05-14 05:27 Changelog
-rwxr-xr-x 1 mduncan mduncan 2815 2010-05-14 05:27 graudit*
-rw-r–r– 1 mduncan mduncan 35148 2010-05-14 05:27 LICENSE
-rw-r–r– 1 mduncan mduncan 1951 2010-05-14 05:27 README
drwxr-xr-x 2 mduncan mduncan 4096 2010-05-14 05:27 signatures/
The primary executable is a bash script which loads disctionary-like signature (or database) files from the signatures directory. Currently, the tool has signature/database files for a number of languages including PERL, PHP, JSP, .Net and Python. More of these signatures can be developed by you — they are pretty simple — or passed to the developer for incorporation into the project.
Each signature file is basically sent to grep using the -f <pattern file> option and contains (on each line) some pattern to look for in files it will search. For example, in the PERL signature file, it will look for any read or open function calls.
Running the tool
To run graudit on a script, you simply run it like so…
<path to graudit install dir>/graudit <filename or directory to audit>
You can run the script on a directory containing sources for your application or simply a file. Either way, grep is used to scan the file(s) for key words listed in the signature. By default, it uses the all database, but you can hone your scans to a particular language/signature/database like so…
graudit -d <name of dictionary> <filename or directory to audit>
The option -d <name of dictionary> is just the dictionary/signature to use without the .db extension from the signatures directory.
Assessing the results
graudit is a great start to writing more secure applications. Unfortunately, because it uses only grep to find keywords, you are going to get a lot of false positives. For example, when scanning the following code (PERL)…
[perl]
use strict;
my $file = "myfile.txt";
my @contents = ();
die "Error: $!\n\n" unless(open(FILE, "<". $file));
@contents = <FILE>;
close(FILE);
[/perl]
…I get the following result(s) from graudit…
# ~/apps/graudit-1.6/graudit -d perl test.pl
test.pl-4-my @contents = ();
test.pl:5:die “Error: $!\n\n” unless(open(FILE, “<“. $file));
test.pl-6-@contents = <FILE>;
What graudit is picking up on is the fact I am using the open function to open a file here. This in most instances would cause some alarm to auditors, but graudit does not pick up on all of the issues here. We are using strict, which is a good start, but we are not validating $myfile and we are not using taint checks.
Now, if I edit the test.pl script I created above, remove the use strict line and set the $myfile variable to $ARGV[0], then there should be some concern by the auditor here looking over the code. This is because we could be using possibly tainted and unvalidated arguments to open a file on the system. Of course, this does not mean much here because we are not outputting the file nor are we using the arguments except to test open the file, but generally ALL PERL scripts should use strict, use taint checks and ensure that all inputs are properly validated before use within the script. Unfortunately, graudit falls short here…not picking up on the real security issues…
[perl]
my $file = $ARGV[0];
my @contents = ();
die "Error: $!\n\n" unless(open(FILE, "<". $file));
@contents = <FILE>;
close(FILE);
[/perl]
# ~/apps/graudit-1.6/graudit -d perl test.pl
test.pl-3-my @contents = ();
test.pl:4:die “Error: $!\n\n” unless(open(FILE, “<“. $file));
test.pl-5-@contents = <FILE>;
Conclusion
While graudit is a good start, this article should point out that it does lack the capabilities of a good auditor and tool like O2 and Fortify 360. These tools know to look at the flow of code as well as the keyword searches that graudit performs. Fortify, which I use regularly, will for example, notice the lack of validation on inputs. But, unfortunately, because O2 and Fortify have to parse the language first, PERL support is not there. So, graudit is a good start to looking for issues in PERL scripts, but you will need to understand good secure coding and application design before using the tool. Like all security analysis tools, the auditor is the key to performing accurate and complete scans/audits on applications. Only an auditor knowing the languages and other technologies used can audit application effectively even with the best tools available.