Category Archives: Development

Basic code review tools for Ruby

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:

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

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:

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.

That is it for this blog post. You have to interpret the results yourselves.

Hope that helps.

Using Jython’s PIP to add dependencies to Burp Extenders

Ever wanted to use 3rd party python libraries when making a Burp Extender? I had somehow avoided it until recently.

Warning: Be aware before pasting in the commands below that I think they configure your new pip environment and store all dependencies inside a new folder within the current directory.

In a nutshell it works like this:

java -jar jython-standalone-2.7.1.jar -m ensurepip
java -jar jython-standalone-2.7.1.jar -m pip install --upgrade pip
java -jar jython-standalone-2.7.1.jar -m pip install jsbeautifier

Making dependencies available in Burp

You need to configure the Python Environment on the “Extenders” -> “Options” tab as shown:

The second option needs to point to the folder where pip just initialised itself to. For me it was inside the BurpSuitePro folder as shown.

The source for this wizardry is the video below:

Happy Extender making you python wizards.

Upgrading an old Netbeans Project to use maven

In this blog post I discuss how I migrated an old Netbeans project (Specifically ReportCompiler) to retrofit Maven and to integrate OWASP’s dependency check into the build process.

You can get ReportCompiler:

What is the target?

I made ReportCompiler a long time ago (long enough that Java was a sane choice). It is in no way complete and has adorable missing or half implemented thoughts throughout it.

It will import “.nessus” XML files and various other vulnerability scanners too. I use it mostly as a Nessus viewer since my gripes with the UI experience in browser are legion. I have a love affair with it in particular though because it has saved me an unbelievable amount of time over the years even accounting for the initial intense development time.

I do not use it every day like I used to and so the project is only lightly supported by me.

Getting up and running

  • Open up netbeans (I originally designed the GUI in this so it kind of needs to be netbeans unless another GUI editor works just as well?).
  • Create a new “maven” project.
  • Copy the source code from your previous project into the source folder.
  • Deal with any package renaming because of this movement. They will be highlighted in red at the top of every class file.
  • Check import statements for warnings. Each underline here points to a dependency we will need to include using maven now.
  • For each import error copy the package name for example “org.python.util.PythonInterpreter” and google it with the word “maven”. This will find the package that you need to import. For example:
Google Hacks Confirmed!
  • Clicking on the top result will show you the information about the relevant maven package:
Found Jython Package
  • Notice that in this example the latest version was newer as highlighted. Click on the newer version. Then copy and paste the “<dependency>” tag into your projects “pom.xml”.
  • After adding each dependency build the app again and watch that import statement fix itself. Repeat until all the red underlines have vacated your project.

Given the age of ReportCompiler there were a few deprecation warnings around the use of Vectors etc. I did not massively feel the need to redo the code for that since it has Vectors in pretty much every single area of the application. Now I feel the developer pain. Some day the rug will be pulled but for now we are golden. Vectors survive for now.

By the end of this my application compiled and executed. The only thing that did not seem to work was the resources folder including the risk icons. I wrapped the code loading these icons in a “try catch” statement to see a more verbose error message and to ensure the app loaded despite the wonky icons.

Bundling the app and dependencies into a single Jar

To fix the wonky icons I needed to ensure the resources were included inside the Jar file or otherwise copied during the build.  The simplest route I found was to use the “maven-assembly-plugin”. Adding this to the “pom.xml” file resulted in a self-contained single jar file with all resources:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-assembly-plugin</artifactId>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>single</goal>
      </goals>
      <configuration>
        <archive>
          <manifest>
            <mainClass>
            com.cornerpirate.reportcompiler.GUI.MainWindow                                
            </mainClass>
          </manifest>
        </archive>
        <descriptorRefs>
          <descriptorRef>jar-with-dependencies</descriptorRef>
        </descriptorRefs>
        <finalName>ReportCompiler</finalName>
        <appendAssemblyId>false</appendAssemblyId>
      </configuration>
    </execution>
  </executions>
</plugin>

In my new project the image icons were located under the “src/main/resources” folder. Maven tutorials all say this is where to put them:

resources folder

To access these resources I modified my code to use “getClass().getResource()” as shown:

try {
    this.critical_risk_icon = new ImageIcon(getClass().getResource("/critical-icon.png"));
    this.high_risk_icon = new ImageIcon(getClass().getResource("/high-icon.png"));
    this.medium_risk_icon = new ImageIcon(getClass().getResource("/medium-icon.png"));
    this.low_risk_icon = new ImageIcon(getClass().getResource("/low-icon.png"));
    this.info_risk_icon = new ImageIcon(getClass().getResource("/info-icon.png"));
    this.no_risk_icon = new ImageIcon(getClass().getResource("/none-icon.png"));
    this.computer_icon = new ImageIcon(getClass().getResource("/computer-icon.png"));
    this.show_highlights = showHighlights;
} catch (Exception ex) {
    ex.printStackTrace();
}

Terrific. Now the risk icons were loading beautifully.

Integrating OWASP’s Dependency Check

The reason I was moving to maven was to add sanity into the dependency management. The version of ReportCompiler to date was stuck with whatever jar files I downloaded back when I wrote the project. I consoled myself with the fact that none of the code is remotely accessible which reduced the threat profile.

But here was a Pentester clearly not practising what they preach. Yelling “patch all the things” by day while my barn was on fire. This gave me an opportunity to experience life from the other side of the fence for a bit. Which we should all practice regularly.

OWASP’s Dependency Check does an excellent job of listing known vulnerabilities in dependencies. I have tried it out in a few different contexts over the years and wholeheartedly recommend it to customers. It will not solve security problems on its own. But it will highlight easily fixable weaknesses from third party libraries.

I added this to my “pom.xml” to add it into my build process:

<plugin>
  <groupId>org.owasp</groupId>
  <artifactId>dependency-check-maven</artifactId>
  <version>5.3.2</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

The goal was set to “check”. In this configuration dependency-check runs when the application is built and an HTML report will be created in the target folder next to my jar file. You can set the build to halt if risks over a certain CVSS score appear which I would recommend for an actively maintained project which is mission critical.

Below is an example report kicked out during a build with some CVE’s to show:

Dependency-Check Report Containing 55 known vulnerabilities

I went through all my maven dependencies and ensured the most recent releases were included (or so I thought). By running “clean and build” again the vulnerabilities related to Apache POI disappeared. Partial success!

My “pom.xml” did not point specifically to any of the remaining vulnerable libraries meaning that they were most likely “dependencies of my dependencies”. I shook my fist at the sky and cried out about how the supply chain will always get you.

I found that netbeans will draw a handy dependency graph. In “Project” view expand the “Project Files” folder and click on “pom.xml” and then on the tab labelled “Graph” along the top to see this:

Image
Netbeans POM.xml dependencies graph

I could now throw shade at “docx4j” 6.1.2 which was build with Apache Commons Compress version 1.12 when version 1.20 is available. On looking into this 6.1.2 was nowhere near the latest version of “docx4j”! There were newer ones with slightly different names available. Hot swapping that out solved the “apache-commons-compress” related CVEs.

The most recent maven release of “docx4j” (version notes for 11.1.8) was compiled with several outdated dependencies. Unfortunately “jackson-databind-2.9.9” was included and vulnerable to 26 known CVEs. There was no danger of fixing this soon and it would most likely require opening a ticket on the docx4j project.

Drilling into the others I found that “jexcelapi” had a vulnerable version of “log4j” as shown in the graph below:

Log4j 1.2.14 baked into jexcelapi

Looking into it the project for “jexcelapi” was no longer supported since it was last released in 2009. A prime candidate for being entirely replaced. A quick google found that Apache POI is the new hotness. I cutout the old library and went for something that was supported.

At the end of this process I had tried my best but ended up with vulnerabilities via docx4j’s jackson-databind dependency. C’est la vie.

Fixing vulnerable Dependencies is Hard

After thinking about it I can see four ways to proceed with fixing all known CVEs in my dependency chain:

  • Do I really have the most recent release of my dependency? Look up the actual project’s page and see if there is a later release.
  • Can I contact the maintainer and get them to update their public build with the newer dependency baked in? This would fix the issue and eventually filter back into the maven ecosystem. Probably need to do that for docx4j.
  • Do I need that dependency? If it is a minor feature and you are all up to date maybe you can remove the feature or implement it another way. As per jexcelapi.
  • Can I build my own version which is secure (recompiling with the latest libraries)? However, this instantly breaks the mavenness of the dependencies

Now I imagine what it is like when a Pentest report lands heartlessly saying “update your dependencies”. It is clear that this is still a tricky problem in 2020.

This is the end

That was the end of the process. The application compiled and had the same bugs it had before but now had more up-to-date dependency management. Folks may now be more inclined to contribute to the project, and I am more inclined to support it.

Hopefully you found something of value in the tale.