This blog post is to document how to get started analysing a Ruby code base for trivial security vulnerabilities. Particularly in the case, like me, when you have absolutely no ability in Ruby. If you are being asked to do an actual code review then I feel sorry for you dear reader. This will help you get started, but you cannot replace having developed something sizeable within the target language and elbow grease.

The sum total of my Ruby experience was my entirely unpopular module for metasploit a few years ago called “git_enum“. This is a post exploitation module which will seek to rob any stored git passwords or authentication tokens from a user’s home folder. I wanted to merge it into MSF but I am locked in anxiety about how awful that was to write, and assuming it will be laughed out of town if I dared try and contribute it!

I digress. My point was that I am not going to be getting scheduled on any Ruby source code reviews any time soon. The syntax is just alien enough to successfully spurn my interest.

This has been prompted by me having access to source code during an application test. This is a move from a black-box to white-box methodology to aid defence in depth recommendations to be made. There is no assumption that I am reading everything line by line. In saying that, when I have access to source code so I like to leverage automation where possible to maybe point toward weaknesses.

Overview of the process

1. Obtain the source and save it locally
2. Identify Static Code analysis tools for the target language
3. Identify tools to check dependencies for known vulnerabilities

I don’t need to say much about 1. so I will move right on to discussing 2. and 3. below.

Static Code Analysis Tools for Ruby

There is almost always some very expensive commercial tool for doing automated static code analysis. They are probably very good at what they do. However, they always have eye watering license fees and I have never actually had the privilege of using one to find out!

As this is not a full code review you will likely have no budget and so you need to find open source projects that support your target language. A great place to start is this URL from OWASP:

• https://owasp.org/www-community/Source_Code_Analysis_Tools

I picked two tools from that list which were open source and which seemed active within the last 2 years of development:

• Brakeman – https://github.com/presidentbeef/brakeman
• Dawnscanner – https://github.com/thesp0nge/dawnscanner

Both were easy to install and use within a Kali host. The other tools may be as good but for me I had two static analysers and that was enough for me.

Brakeman installation and usage

gem install brakeman
brakeman -o brakeman_report.html /path/to/rails/application

Dawnscanner installation and usage

gem install dawnscanner 
dawn --file dawn_report.html --html /path/to/rails/application

Dependency Scanning Tool for Ruby

A dependency is an extension from the core language which has been made by a project and then made available for others to use. Most applications are made using dependencies because they save development time and therefore cost.

The downside of using dependencies is that they are shared by hundreds, thousands, or millions or of other applications. They therefore get scrutinised regularly and a vulnerable dependency can be a bad day for many sites at a single time. One thing you have to stay on top of is the version of dependencies in use and that is why it is an important check to make even if you are not doing a full code review.

The best dependency scanner out there is OWASP’s own Depedenency-check. This tool is getting better every time I use it. It integrates with more dependency management formats all the time. As per the URL below:

• https://jeremylong.github.io/DependencyCheck/analyzers/bundle-audit.html

This is capable of doing Ruby but to do so it uses “bundler-audit“. For this one I went straight to Bundler-Audit.

Bundler-Audit Installation and Usage

gem install bundler-audit
cd /path/to/rails/application # folder where the Gemile.lock file is.
bundler-audit chec

I would include one vulnerability in my Report for the outdated dependencies which summarises in a table the known vulnerabilities and the CVSS risk rating taken from the CVE references from bundler-audit. If there are hundreds of known vulnerabilities you should prioritise and summarise further.