3 ways to improve appsec code auditing with graudit

Graudit is a tool used for static code analysis, designed to find security vulnerabilities in code. It is a script (found here) that wraps around the GNU grep tool and utilizes various patterns to detect potential security issues.

It can scan a variety of codebases, including those written in C, DotNet, Java, Javascript, PHP, and Python. In fact, graudit includes several dozen signature databases for many different languages and platforms. Once installed, you can list out what is available to you on your host with the command graudit -l. 

Graudit is useful for quickly identifying common vulnerabilities such as SQL injection, cross-site scripting (XSS), Command injection, and buffer overflows. It achieves this by searching your target codebase for patterns that match dangerous functions, commonly known as “sinks” in reverse engineering parlance.

If this is all new to you, I highly recommend you check out my article on Tracing API exploitability through code review and taint analysis. It covers the concepts of “sources” and “sinks” and how to conduct data flow analysis and taint tracing.

In this article, I will show you three ways to improve your application security code auditing when using graudit.

Let’s get right to those tips. 

TIP #1 – Review the dangerous functions (sinks) databases

One of the biggest values of the graudit toolchain is its robust set of pre-defined databases already included. These are typically found in the signatures directory of the graudit install, or a subdirectory under it.

Reviewing the databases relevant to your codebase’s tech stack is crucial for understanding the dangerous functions that can lead to security vulnerabilities, which Graudit targets during an audit. By understanding and validating these patterns, you can ensure they are pertinent to your specific codebase and context.

This review process helps customize and refine the detection mechanisms, reducing false positives and ensuring that critical vulnerabilities are not overlooked. Moreover, it empowers your teams to stay updated with evolving security threats and coding practices, ultimately leading to more secure and robust applications.

TIP #2 – Reduce false positives by using high-impact databases

Fun fact: graudit stands for “grep rough audit”. 

Now you know.

But what does that mean? 

If you have ever seen grep before, you know its output isn’t the prettiest. Combine that with the complexity of extended regular expression patterns that graudit databases provide, and you get some pretty rough output that could very well contain tons of false positives.

Don’t lose hope. Graudit includes some pre-built databases that can help you find more potentially critical and impactful security vulnerabilities without all the noise.   

“Flatline”

If your target codebase is written in PHP, then consider using flatline.db. You can usually find it in the misc directory.

The flatline database includes patterns for the most common dangerous functions that lead to remote code execution. 

Why is it called flatline? 

I dunno. But if a dangerous function is detected from this database and accepts user-controlled data, it’s pretty much a surefire way to exploit the code and cause remote code execution.

It’s game over. You’re dead. Beeeeeeeeeeeeeep. Flatline.

Low-hanging “Fruit”

In the main signatures directory lies fruit.db. It is a general database of patterns that represents the low-hanging fruit typically found during security code auditing across all languages.

Use it. 

But I have an even better suggestion for you…

Many languages that graudit supports also include a dedicated fruit.db for it. If you look in the subdirectory for the language, you may find it there. As an example, ./signatures/java/fruit.db holds all the patterns for the low-hanging fruit dedicated to code written in Java.

Why use it? Speed. And noise reduction by eliminating the number of patterns to test across the entire codebase.   

“OWASP”

If you have been following me for any length of time, you know I am a big supporter of OWASP. I really align with their mission to improve software security through Open Source initiatives and community education. It’s why I’m a member. And a director of OWASP Vancouver.

One of the projects I support and recommend to all appsec professionals includes the OWASP Code Review Guide. It covers the types of vulnerabilities to look for and how to identify them throughout code review.

Graudit includes several databases that represent the unique dangerous sources and sinks defined in the OWASP Code Review Guide. These include ASP, DotNet, Java, and Javascript. It even includes a legacy database for Apache for those hardcore C/C++ codebases that build modules on top of the Apache web server.

You will find these databases in ./signatures/owasp/.   

TIP #3 – Learn to use non-destructive code review tools

When graudit outputs its findings during an audit, by default it will show the filename and the line number. Tools like nano, sublime, and VS Code can quickly open these files for you. But it comes at a cost. You are always opening the code in write mode in the editor, which can accidentally modify the code base if you aren’t careful.

There are ways to avoid this. 

Vi or die

If you are proficient with vi or vim, you can use the -L argument to graudit to output “vi-friendly line numbers” which will allow you to open the file and go straight to that line immediately.

It’s very fast and efficient as you quickly move around code looking to validate potential security vulnerabilities.

It’s a great parameter to use and I recommend you check it out if you are a fellow vi-or-die fan.

And the chances of you editing the file “accidentally” are almost impossible; then again few people can properly enable editing mode using the proper shortcut keys anyway. lol

Vi is great; but it’s not the answer either.

Let me show you a better way.

Build a non-destructive code review alias

In pretty much every shell environment, you can cat a file to screen to look at it quickly. You can pipe it to the more command (or less) to control the movement through the file. I highly recommend you use “less” for this, as less does more than more — it allows you to scroll forward and backward and supports color output.

(More on the whole idea of color in code in a moment.)

Let’s take code review to the next level. When you cat out a file, the output is in a boring mono-color that is hard to read and follow. So, let’s fix that.

Install highlight on your system and create an alias that will highlight the code with color, and make it easy to move around in.

Here is the alias I use:

alias src='(){ highlight -O ansi -l "$@" | less }'

The result? There is a night and day difference in the output. It’s much easier to read. 

Here is the raw output from cat index.js | less:

And here is what it looks like when I use the alias of src index.js:

You can move around the code quite quickly with these shortcuts:

• Use up and down arrows to move up or down a line
• Use Page Up or Page Down to jump a page in the appropriate direction
• Use #g to jump to a specific line number. ie: 42g to move to the 42nd line
• Use /searchterm to find the first instance of a search string. ie: /exec to move to the first instance of the string “exec”
• Hit n to go to the next instance of a search term currently searching for.
• Hit q to drop out of the highlighted code view

BONUS TIP #4 – Don’t be afraid to build your own custom db

An added benefit of following my previous tips is that you will be exposed to a ton of pattern file databases, and the expected regular expressions. Use this as a guide to build your own custom databases. 

If you have a unique need to look for certain patterns within your codebase, then leverage graudit to do so. Create a new file called something like custom.db in $HOME/.graudit and build out your own patterns.

Then call it directly:

graudit -d custom /path/to/codebase

Conclusion

Graudit is a powerful tool for static code analysis designed to uncover security vulnerabilities in various codebases efficiently. With its robust set of pre-defined databases and flexible pattern matching, Graudit can help you quickly identify common vulnerabilities in the code you are reviewing.

By taking the time to review and customize these databases, you can tailor Graudit to your specific tech stack, reducing false positives and ensuring critical vulnerabilities are not missed. Utilizing high-impact databases like flatline.db and fruit.db, as well as specialized OWASP databases, further enhances your auditing process by focusing on the most relevant and dangerous functions.

Additionally, adopting non-destructive code review tools and building your own custom databases can significantly streamline your security audit workflow. By leveraging tools like vi, or creating aliases with highlight and less, you can review code more efficiently without risking unintentional changes.

Ultimately, these practices improve the accuracy and efficiency of your appsec code audits and empower your team to stay current with evolving security threats and best practices. By integrating these tips into your workflow, you will find common security vulnerabilities in your codebase before your adversaries do.

HTH. Good luck!

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe today at https://apihacker.blog.