Controlling cuckoo-sandbox from C#

After testing some metasploit modules today, I decided writing some bindings for cuckoo-sandbox would be fun. I have been writing a small project that my clamav bindings to watch high risk areas and scan them on the fly. A fun, new addition would be to automagically submit anything found by clamav straight to cuckoo-sandbox and get the report back.

The code is on github and there is a small example application. Not every method is implemented fully, but it is still fun to play with. I did have to use a third party library for JSON parsing because of a bug in Mono's JavaScriptSerializer.

There is also an example program.

Added environment variable recovery from pagefiles to volatile reader

I added string search support to page files inside volatile reader, and used that as an opportunity to add environment variable recovery as well. The following pagefile was taken from a 64-bit windows 7 VM and was 4.3 GB. The code is in github.

evtx support pretty much added

Evtx format was a real PITA. Took me way longer than I expected to write the code to parse the offline logs. Not being shown in the UI yet, but I checked in support for reading offline evtx files today. Will only print out the parsed data to the console atm.

https://github.com/brandonprry/volatile_reader

volatile_reader reads legacy evt files

volatile_reader now reads legacy XP evt files. evtx up next!

Introducing volatile_reader

Today I decided I was going to write a small offline registry reader in C# using GTK for the UI. I actually intend on adding both evt and evtx support as well, but these will come later.

In order to read the hives, I wrote a small library included with the utility called VolatileReader.Registry. It is super fast and efficient, it uses a BinaryReader to zip around and read the hive rather than reading the hive into memory, then parsing it. All you must do is pass the contructor of RegistryHive the path to your hive:


RegistryHive hive = new RegistryHive(file);

You can check out the code here: https://github.com/brandonprry/volatile_reader

Introducing rising_sun

I have recently open-sourced a personal project of mine that I have used as an automated security test bed of a sort. Using bindings I have written for popular pieces of software, I have written a small framework for automating these tools and passing their relevant data from one tool to the next. A general architecture overview is required. Most of the tools are free and open source.

The framework has three main parts. An API (needs a lot of work), a Web UI (kind of OK), and a Service (solid, small, runs and manages the Profiles and Scans). It is written in C# and ASP.NET, so it is cross platform (I develop on Linux using monodevelop). Most tools are in scripting languages too or are also cross-platform. Using PGSql as the DB backend and FluentNHibernate for persistence. In order to automate OpenVAS, Nexpose, Nessus, and Metasploit, I am using my openvas-sharp, nexpose-sharp, nessus-sharp, and metasploit-sharp bindings.

When you create a profile via the Web UI, the scan of the profile takes place in two parts, breadth and depth. First, the service gathers as much surface area of the host as possible. This is called the Profile phase. Once the host has been profiled and it's attack surface area figured out, we move onto the Scan phase, where we actively attempt to find vulns using the surface area we determined in the previous phase.

Current tools automated during the Profile phase are Nmap (in a few incarnations), Nikto, sslscan, onesixtyone, smbclient, and a few others off the top of my head, with more web fingerprinting and other tools  in the pipeline (MBSA is one). smbclient will loop through each share it can find and attempt to log in anonymously (unless creds are provided) and attempt an "ls;recurse" which tells smbclient to list all files on the share. This phase can be considered mostly passive and can be run on it own with no Scan attached.

Current tools automated during the Scan phase are OpenVAS, Nexpose, Nessus, Metasploit/Pro, Wapiti, DSXS, and SQLMap. This phase is by far the most important and integrative. We use all the data collected in the previous profile to decide what to scan. By using as many vuln scanners like OpenVAS, Nexpose, and Nessus as possible, you can find far better results in terms of deducing false positives and false negatives (2 out of 3 report this, 33% chance false positive. 1 out of 3 report that, 66% chance false positive). This phase is laid out like a pyramid, with Metasploit on top. Before Wapiti and SQLMap are run, your vuln assessment scans are kicked off. As these run, we fuzz any known web services running that we know about with Wapiti (not just port 80 and 443, anything NMap decided was http). We take this XML report it creates (must run trunk) and parse it and figure out exactly what wapiti found and pass on the relevant details to SQLMap and DSXS to figure out exactly how to exploit any SQL injection or XSS  vulnerabilities. I use some novel methods to ensure SQLMap only tests what Wapiti was found to find vulnerable, so it is pretty quick, and can be made quicker with a few tweaks. This requires a Profile to have been run.

In the end, the data from wapiti, openvas, nessus, and nexpose are fed into metasploit via sshfs mountint the remote /tmp locally. Then a metasploit pro discovery  is done, then a quick bruteforce, then an exploit task is started using all the data from the previous scans. Once this is done, the scan phase is over and persisted and your results will be in the web UI.

Not all tools are required, if you don't have access to Metasploit Pro, you can simply choose to not run it. The same goes for OpenVAS, Nexpose, and Nessus. It is granular to that point. You may also choose to not run the web assessment, and only run the general vuln assessment(s).

Most of the data collected is presented in the UI in some form or fashion, but not all of it is. Installation isn't straight forward so please read the README.

Generally I run against: a vulnerable FreeNAS distro, Metasploitable2 with TWiki removed, BadStore, and a vulnerable Windows XP SP2 machine.

Please hit me up on IRC (bperry on Freenode, idle in #metasploit) if you have trouble setting up (you probably will, but I hope you don't!).

Integrating ClamAV into your C# applications

During the VP debate, I decided to write some ClamAV bindings for C# that were up to date. The current C# lib for libclamav that is linked on the ClamAV website is from 2005 and no longer useful. Here is a small introduction.

The main objects you will probably work with as a programmer is probably the ClamEngine and ClamResult objects. Since we are interfacing with a library written in C, we must take into account memory leaks. The ClamEngine implements IDisposable and is intended to be used in the context of a using statement. If you are using .NET 1.1 and do not have the using statement available, you will need to call Dispose() explicitly. Here is an example application:

using System;
using clamsharp;

namespace testing
{
   class MainClass
   {
 public static void Main (string[] args)
 {
  using (ClamEngine e = new ClamEngine())
  {
   foreach (string file in args)
   {
    ClamResult result = e.ScanFile(file); //pretty simple!
     
    if (result != null && result.ReturnCode == ClamReturnCode.CL_VIRUS)
     Console.WriteLine("Found: " + result.VirusName);
    else
     Console.WriteLine("File Clean!");
   }
  } //engine is disposed of here and the allocated engine freed
 }
   }
}

One note: If you want it to build on Windows, you will need to change the DllImport's to point to where ever on Windows you need to point to in ClamBindings.

clamd TCP bindings are probably on their way soon, it will be easy enough. The main code is thoroughly documented, but if you still have question after that, feel free to ask on Github.

If you would like to test this without a real virus, I recommend using EICAR.

Theoretical vulnerabilities using the Spring Expression Language

The past two days, I have been taking Core Spring training (work paid for it, why not). Our instructor ended up bringing up the Spring Expression Language (or SpEL), and showed us how it could be used to parse values and various other things.

While playing around with it, I was curious if I could evaluate java code at runtime that could execute calc.exe and after a few minutes of tinkering, I was able to execute calc.exe via the Spring Expression Language. It was easy enough:

ExpressionParser p = new SpelExpressionParser(); 
Expression e = p.parseExpression("T(Runtime).getRuntime().exec('calc.exe')"); //set expression to eval 
e.getValue(); //eval

Once I had this bit figured out, I realised the potential for Remote Command Execution via the expression language. The way to get a program using the Spring Expression Language to evaluate unintended code is very similar to the way a SQL injection works, but there are some catches and nuances, and I will go over them here. This whole post is theoretical only, as I have never actually come across this vulnerability before. However, it would be easy for a programmer not completely familiar with how the expression language works to write vulnerable code that allowed remote code execution.

For instance, take the following code:

import org.springframework.expression.Expression;
import org.springframework.expression.ExpressionParser;
import org.springframework.expression.spel.standard.SpelExpressionParser;
import org.springframework.util.Assert;
import org.apache.commons.logging.LogFactory; 
import java.io.*;
import java.util.Date;

public class main {

 /**
  * @param args
  * @throws Exception 
  */
 public static void main(String[] args) throws Exception {
  // TODO Auto-generated method stub
  ExpressionParser parser = new SpelExpressionParser();

  System.out.println("Please enter a date and I will parse it:");
  java.io.BufferedReader stdin = new java.io.BufferedReader(new java.io.InputStreamReader(System.in));
         String line = stdin.readLine();
  Expression exp = parser.parseExpression(line);  
  Date date = (Date)exp.getValue();

  System.out.println(date.toString());
 }
}

The vulnerability is obvious, the program does no checking whatsoever to ensure the user isn't inputing something they shouldn't. Simply typing:

T(Runtime).getRuntime().exec('calc.exe')

would execute calc.exe, then error out since the string you passed in is obviously not a Date.

Let's take the vulnerability a step further though. Let's modify the above code slightly.

Turn the following:

Expression exp = parser.parseExpression(line);

into:

Expression exp = parser.parseExpression("'" + line + "'");

This code change technically fixes a bug in our code. In the previous code, if the user entered a Date that was not surrounded by single-quotes, then the application would error out. By adding the single-quotes in our code, the user can enter the Date value without the single-quotes. This also makes it a bit more difficult to exploit, however not impossible. In order to exploit this new code, we can think about this vulnerability as if it were a SQL injection vulnerability, with a few catches.

We need to make a semantically-correct string that will be eval'ed that will "break out" of the current quotes that we have added to the codebase. To do this, we can use some of the operators at our disposal that the Spring Expression Language has.

My first attempt to exploit the new code was to use the 'and' operator. This was fruitless since Java is a strongly-typed language and Java was trying to evaluate the strings as boolean values, which did not work. After a few more minutes, I figured out how to break out of the quotes and have Spring evaluate and execute my payload:

02/12/2012' == T(Runtime).getRuntime().exec('calc.exe').toString() + '

The resulting string that gets eval'ed is this:

'02/12/2012' == T(Runtime).getRuntime().exec('calc.exe').toString() + ''

Basically, I am asking Spring to evaluate whether the string to the left of my == operator is the same as my payload, which must be evaluated and executed before the comparison can happen. calc.exe gets executed and now I am happy.

You may find the full code examples here and here.

Security on the AWS cloud

I have been working with EC2 in my free time (what's that?) and realised some bad information had been spread about how to get your instances to talk with one another. By default, the instances do not respond to pings or nmap's from other machines due to very restrictive firewall settings. This is a good thing. The bad thing was that I was reading on forums that setting your All ICMP, All UDP, and All TCP firewall settings to 0.0.0.0/0 was the easiest fix. While this is true, it is the easiest fix, it isn't very secure. I was able to nmap a small subnet inside the EC2 cloud (internal network, not external) and found 30 machines responding. When you put 0.0.0.0/0, you let everyone inside that network ping, port scan, and connect to your computer. By being more granular, and setting your firewall rules to the specific instances that you want talking (111.222.122.123/32), you are protecting your machine from threats inside this cloud network. Setting your All ICMP, All UDP, and All TCP to 0.0.0.0/0 is just opening yourself up needelessly for an attack. It may take you an extra 5 minutes to create a rule for each host you want communicating.

Performing forensics on RAMDisk based operating system via QEMU

I came across a problem requiring me to get to a filesystem resident in RAM via a RAMDisk. I used QEMU to dump this to a file for further analysis.

The system at hand was disk encryption software that performs some disk trickery in order to unlock the drive after supplying credentials to the disk encryption software. The disk encryption software was Linux based. However, the RAMDisk was being initiated by MSDOS startup files. It was a very weird setup.

I was able to use QEMU and an Ubuntu Live USB disk to dump what I needed. Because the disk encryption was resident on the HDD instead of the BIOS, I was able to boot to my Live USB and circumvent the HDD entirely. Once in the Live System, I installed qemu and ghex.

Using

qemu-system-i386 -hda /dev/sda -monitor stdio
 

I was able to boot the hard disk into a virtualised environment. -monitor stdio gives me a qemu shell prompt in the bash shell that I started the QEMU instance in. This is how we will be saving the full state of the VM. Once booted into the disk encryption software, I ran the following to see what devices I had at my disposal

(qemu) info block
ide0-hd0: removable=0 io-status=ok file=/dev/sda ro=0 drv=raw encrypted=0
ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
floppy0: removable=1 locked=0 tray-open=0 [not inserted]
sd0: removable=1 locked=0 tray-open=0 [not inserted]
(qemu)

Now that I have the disks, the hd0 block is what I want. We want to create a new file to save our vm into.

snapshot_blkdev ide0-hd0 dump

Now save the vm's state into the dump file

savevm

You may now use further, more advanced techniques to analyse the contents of the RAM disk by using a hex editor or various other tools to extract the wanted data from the saved state of the vm.

Automating SQLMap with data from wapiti

Wapiti is really fast at finding possible sql injection points in a web application or website. SQLMap is great at figuring out how to exploit these possible injection points. The following script runs Wapiti on a host to find possible injection points, then passes that data to SQLMap to try and exploit. Tested on BadStore and running SVN latest of both Wapiti and SQLMap. You can play around with the arguments I am passing to SQLMap and make the scans a bit more thorough, but at the expense of speed.

#!/usr/bin/env ruby
 
require 'active_support/secure_random'
require 'rexml/document'
 
wapiti_path = '/home/bperry/tools/wapiti/trunk/src/'
sqlmap_path = '/home/bperry/tools/sqlmap/'
 
wapiti_report_path = '/tmp/wapiti_report_' + SecureRandom.uuid + '.xml'
 
remote_host = ARGV[0]
 
p "Running wapiti..."
`#{wapiti_path}wapiti.py #{ARGV[0]} -f xml -o #{wapiti_report_path}`
 
p "Report saved to #{wapiti_report_path}"
 
p "Parsing results"
 
results = []
 
report = ::File.open(wapiti_report_path, "rb")
doc = REXML::Document.new report.read
 
doc.elements.each('/report/bugTypeList/bugType') do |element|
        bug_type = element.attributes["name"]
 
        next if bug_type != "SQL Injection"
 
        p "Parsing " + bug_type
 
        result = {}
        element.elements.each("bugList/bug") do |bug|
                result[:type] = bug_type
               
                bug.elements.each do |child|
                        if child.name == "url"
                                result[:url] = child.text
                        elsif child.name == "parameter"
                                result[:parameter] = child.text
                        end
                end
                results << result
                result = {}
        end
end
 
results.each do |result|
        next if result[:type] !~ /SQL Injection/
        p "Running sqlmap"
       
        if result[:url].index(result[:parameter])
                url = result[:url].gsub("%BF%27%22%28", "abcd")
       
                params = result[:url].split("?")[1].split("&")
 
                skipped_params = []
                params.each do |param|
                        skipped_params << param.split("=")[0] if not param.index("%BF%27%22%28")
                end
                       
                p "Running GET sql injection test on url: " + url
                sqlmap_command = "#{sqlmap_path}sqlmap.py -u \"#{url}\" --smart --skip=\"#{skipped_params.join(",")}\" --technique=EUS --flush-session --fresh-queries --level=2 --batch"
                out = `#{sqlmap_command}`
                printf out
        else
                url = result[:url]
                p "Running POST sql injection test on url: " + url
                p "With data: " + result[:parameter]
 
                parameter = result[:parameter].gsub("%BF%27%22%28", "abcd")
 
                params = result[:parameter].split("&")
 
                skipped_params = []
                params.each do |param|
                        skipped_params << param.split("=")[0] if not param.index("%BF%27%22%28")
                end
 
                sqlmap_command = "#{sqlmap_path}sqlmap.py -u \"#{url}\" --data=\"#{parameter}\"  --skip=\"#{skipped_params.join(",")}\" --smart --technique=EUS --flush-session --fresh-queries --level=2 --batch"
                p sqlmap_command
                sqlmap_output = `#{sqlmap_command}`
               
                printf sqlmap_output
        end
end

Simple CVE stats from 2001-2011

Year 2001 has 1538 vulnerabilities
2001 had 8 vulns of type:  Buffer Errors
2001 had 4 vulns of type:  Cryptographic Issues
2001 had 4 vulns of type:  Path Traversal
2001 had 2 vulns of type:  Authentication Issues
2001 had 2 vulns of type:  Permissions, Privileges, and Access Control
2001 had 2 vulns of type:  Code Injection
2001 had 2 vulns of type:  Input Validation
2001 had 1 vulns of type:  Resource Management Errors
2001 had 1 vulns of type:  Link Following
2001 had 0 vulns of type:  Credentials Management
2001 had 0 vulns of type:  Cross-Site Request Forgery (CSRF)
2001 had 0 vulns of type:  Cross-Site Scripting
2001 had 0 vulns of type:  Format String Vulnerability
2001 had 0 vulns of type:  Configuration
2001 had 0 vulns of type:  Information Leak / Disclosure
2001 had 0 vulns of type:  Numeric Errors
2001 had 0 vulns of type:  OS Command Injections
2001 had 0 vulns of type:  Race Conditions
2001 had 0 vulns of type:  SQL Injection
Total vulns in 2001 with CWE: 26
Percentage of vulns with CWE: 1.69050715214564%


Year 2002 has 2368 vulnerabilities
2002 had 41 vulns of type:  Buffer Errors
2002 had 32 vulns of type:  Permissions, Privileges, and Access Control
2002 had 32 vulns of type:  Cross-Site Scripting
2002 had 29 vulns of type:  Input Validation
2002 had 17 vulns of type:  Information Leak / Disclosure
2002 had 13 vulns of type:  Path Traversal
2002 had 9 vulns of type:  Configuration
2002 had 8 vulns of type:  Credentials Management
2002 had 8 vulns of type:  Code Injection
2002 had 7 vulns of type:  SQL Injection
2002 had 6 vulns of type:  Numeric Errors
2002 had 6 vulns of type:  Resource Management Errors
2002 had 5 vulns of type:  Authentication Issues
2002 had 3 vulns of type:  Cryptographic Issues
2002 had 2 vulns of type:  Race Conditions
2002 had 2 vulns of type:  Link Following
2002 had 1 vulns of type:  Cross-Site Request Forgery (CSRF)
2002 had 1 vulns of type:  Format String Vulnerability
2002 had 1 vulns of type:  OS Command Injections
Total vulns in 2002 with CWE: 223
Percentage of vulns with CWE: 9.41722972972973%


Year 2003 has 1515 vulnerabilities
2003 had 59 vulns of type:  Buffer Errors
2003 had 40 vulns of type:  Cross-Site Scripting
2003 had 30 vulns of type:  Input Validation
2003 had 25 vulns of type:  Information Leak / Disclosure
2003 had 24 vulns of type:  Permissions, Privileges, and Access Control
2003 had 17 vulns of type:  Path Traversal
2003 had 13 vulns of type:  Code Injection
2003 had 12 vulns of type:  Configuration
2003 had 12 vulns of type:  SQL Injection
2003 had 9 vulns of type:  Authentication Issues
2003 had 9 vulns of type:  Credentials Management
2003 had 8 vulns of type:  Cryptographic Issues
2003 had 6 vulns of type:  Resource Management Errors
2003 had 4 vulns of type:  Numeric Errors
2003 had 2 vulns of type:  Format String Vulnerability
2003 had 2 vulns of type:  Race Conditions
2003 had 2 vulns of type:  Link Following
2003 had 0 vulns of type:  Cross-Site Request Forgery (CSRF)
2003 had 0 vulns of type:  OS Command Injections
Total vulns in 2003 with CWE: 274
Percentage of vulns with CWE: 18.0858085808581%


Year 2004 has 2669 vulnerabilities
2004 had 30 vulns of type:  Buffer Errors
2004 had 22 vulns of type:  Permissions, Privileges, and Access Control
2004 had 20 vulns of type:  Cross-Site Scripting
2004 had 9 vulns of type:  Path Traversal
2004 had 9 vulns of type:  Input Validation
2004 had 8 vulns of type:  SQL Injection
2004 had 6 vulns of type:  Authentication Issues
2004 had 6 vulns of type:  Credentials Management
2004 had 6 vulns of type:  Code Injection
2004 had 5 vulns of type:  Configuration
2004 had 4 vulns of type:  Information Leak / Disclosure
2004 had 4 vulns of type:  Resource Management Errors
2004 had 3 vulns of type:  Cryptographic Issues
2004 had 3 vulns of type:  Format String Vulnerability
2004 had 2 vulns of type:  Race Conditions
2004 had 2 vulns of type:  Link Following
2004 had 1 vulns of type:  Numeric Errors
2004 had 1 vulns of type:  OS Command Injections
2004 had 0 vulns of type:  Cross-Site Request Forgery (CSRF)
Total vulns in 2004 with CWE: 141
Percentage of vulns with CWE: 5.28287748220307%


Year 2005 has 4684 vulnerabilities
2005 had 64 vulns of type:  Buffer Errors
2005 had 48 vulns of type:  SQL Injection
2005 had 32 vulns of type:  Permissions, Privileges, and Access Control
2005 had 31 vulns of type:  Resource Management Errors
2005 had 28 vulns of type:  Cross-Site Scripting
2005 had 21 vulns of type:  Input Validation
2005 had 20 vulns of type:  Code Injection
2005 had 18 vulns of type:  Information Leak / Disclosure
2005 had 15 vulns of type:  Numeric Errors
2005 had 10 vulns of type:  Path Traversal
2005 had 5 vulns of type:  Link Following
2005 had 4 vulns of type:  Authentication Issues
2005 had 3 vulns of type:  Cryptographic Issues
2005 had 3 vulns of type:  Configuration
2005 had 2 vulns of type:  Credentials Management
2005 had 2 vulns of type:  Race Conditions
2005 had 1 vulns of type:  Cross-Site Request Forgery (CSRF)
2005 had 1 vulns of type:  Format String Vulnerability
2005 had 1 vulns of type:  OS Command Injections
Total vulns in 2005 with CWE: 309
Percentage of vulns with CWE: 6.59692570452605%


Year 2006 has 7043 vulnerabilities
2006 had 199 vulns of type:  Code Injection
2006 had 145 vulns of type:  Buffer Errors
2006 had 87 vulns of type:  Cross-Site Scripting
2006 had 84 vulns of type:  SQL Injection
2006 had 74 vulns of type:  Resource Management Errors
2006 had 63 vulns of type:  Input Validation
2006 had 50 vulns of type:  Permissions, Privileges, and Access Control
2006 had 37 vulns of type:  Numeric Errors
2006 had 29 vulns of type:  Information Leak / Disclosure
2006 had 21 vulns of type:  Path Traversal
2006 had 17 vulns of type:  Format String Vulnerability
2006 had 14 vulns of type:  Authentication Issues
2006 had 8 vulns of type:  Cryptographic Issues
2006 had 7 vulns of type:  Race Conditions
2006 had 6 vulns of type:  Configuration
2006 had 5 vulns of type:  Credentials Management
2006 had 3 vulns of type:  Cross-Site Request Forgery (CSRF)
2006 had 2 vulns of type:  OS Command Injections
2006 had 1 vulns of type:  Link Following
Total vulns in 2006 with CWE: 852
Percentage of vulns with CWE: 12.0971177055232%


Year 2007 has 6505 vulnerabilities
2007 had 451 vulns of type:  Buffer Errors
2007 had 366 vulns of type:  Cross-Site Scripting
2007 had 296 vulns of type:  Code Injection
2007 had 263 vulns of type:  SQL Injection
2007 had 229 vulns of type:  Permissions, Privileges, and Access Control
2007 had 228 vulns of type:  Input Validation
2007 had 164 vulns of type:  Path Traversal
2007 had 107 vulns of type:  Numeric Errors
2007 had 104 vulns of type:  Resource Management Errors
2007 had 96 vulns of type:  Information Leak / Disclosure
2007 had 69 vulns of type:  Authentication Issues
2007 had 41 vulns of type:  Cross-Site Request Forgery (CSRF)
2007 had 36 vulns of type:  Configuration
2007 had 31 vulns of type:  Format String Vulnerability
2007 had 25 vulns of type:  Link Following
2007 had 24 vulns of type:  Credentials Management
2007 had 19 vulns of type:  Cryptographic Issues
2007 had 18 vulns of type:  Race Conditions
2007 had 6 vulns of type:  OS Command Injections
Total vulns in 2007 with CWE: 2573
Percentage of vulns with CWE: 39.554189085319%


Year 2008 has 7031 vulnerabilities
2008 had 1480 vulns of type:  SQL Injection
2008 had 981 vulns of type:  Cross-Site Scripting
2008 had 582 vulns of type:  Buffer Errors
2008 had 574 vulns of type:  Permissions, Privileges, and Access Control
2008 had 467 vulns of type:  Input Validation
2008 had 447 vulns of type:  Path Traversal
2008 had 385 vulns of type:  Code Injection
2008 had 322 vulns of type:  Resource Management Errors
2008 had 222 vulns of type:  Authentication Issues
2008 had 221 vulns of type:  Information Leak / Disclosure
2008 had 177 vulns of type:  Link Following
2008 had 166 vulns of type:  Numeric Errors
2008 had 119 vulns of type:  Cross-Site Request Forgery (CSRF)
2008 had 69 vulns of type:  Credentials Management
2008 had 61 vulns of type:  Cryptographic Issues
2008 had 41 vulns of type:  Configuration
2008 had 33 vulns of type:  Format String Vulnerability
2008 had 25 vulns of type:  Race Conditions
2008 had 12 vulns of type:  OS Command Injections
Total vulns in 2008 with CWE: 6384
Percentage of vulns with CWE: 90.797895036268%


Year 2009 has 4848 vulnerabilities
2009 had 734 vulns of type:  Cross-Site Scripting
2009 had 673 vulns of type:  SQL Injection
2009 had 558 vulns of type:  Buffer Errors
2009 had 329 vulns of type:  Permissions, Privileges, and Access Control
2009 had 266 vulns of type:  Code Injection
2009 had 247 vulns of type:  Input Validation
2009 had 245 vulns of type:  Path Traversal
2009 had 237 vulns of type:  Resource Management Errors
2009 had 164 vulns of type:  Numeric Errors
2009 had 148 vulns of type:  Authentication Issues
2009 had 141 vulns of type:  Information Leak / Disclosure
2009 had 86 vulns of type:  Cryptographic Issues
2009 had 84 vulns of type:  Cross-Site Request Forgery (CSRF)
2009 had 56 vulns of type:  Credentials Management
2009 had 47 vulns of type:  Configuration
2009 had 32 vulns of type:  Race Conditions
2009 had 29 vulns of type:  Link Following
2009 had 23 vulns of type:  Format String Vulnerability
2009 had 11 vulns of type:  OS Command Injections
Total vulns in 2009 with CWE: 4110
Percentage of vulns with CWE: 84.7772277227723%


Year 2010 has 4696 vulnerabilities
2010 had 578 vulns of type:  SQL Injection
2010 had 566 vulns of type:  Cross-Site Scripting
2010 had 536 vulns of type:  Buffer Errors
2010 had 319 vulns of type:  Permissions, Privileges, and Access Control
2010 had 299 vulns of type:  Input Validation
2010 had 270 vulns of type:  Resource Management Errors
2010 had 256 vulns of type:  Path Traversal
2010 had 248 vulns of type:  Code Injection
2010 had 162 vulns of type:  Information Leak / Disclosure
2010 had 154 vulns of type:  Numeric Errors
2010 had 66 vulns of type:  Cross-Site Request Forgery (CSRF)
2010 had 62 vulns of type:  Cryptographic Issues
2010 had 56 vulns of type:  Authentication Issues
2010 had 51 vulns of type:  Credentials Management
2010 had 33 vulns of type:  Race Conditions
2010 had 26 vulns of type:  Link Following
2010 had 21 vulns of type:  Configuration
2010 had 12 vulns of type:  Format String Vulnerability
2010 had 12 vulns of type:  OS Command Injections
Total vulns in 2010 with CWE: 3727
Percentage of vulns with CWE: 79.3654173764906%


Year 2011 has 3733 vulnerabilities
2011 had 648 vulns of type:  Buffer Errors
2011 had 372 vulns of type:  Input Validation
2011 had 367 vulns of type:  Cross-Site Scripting
2011 had 366 vulns of type:  Resource Management Errors
2011 had 295 vulns of type:  Information Leak / Disclosure
2011 had 285 vulns of type:  Permissions, Privileges, and Access Control
2011 had 120 vulns of type:  Numeric Errors
2011 had 107 vulns of type:  SQL Injection
2011 had 92 vulns of type:  Code Injection
2011 had 91 vulns of type:  Path Traversal
2011 had 60 vulns of type:  Authentication Issues
2011 had 57 vulns of type:  Cross-Site Request Forgery (CSRF)
2011 had 57 vulns of type:  Cryptographic Issues
2011 had 34 vulns of type:  Configuration
2011 had 32 vulns of type:  Credentials Management
2011 had 26 vulns of type:  Link Following
2011 had 14 vulns of type:  Race Conditions
2011 had 13 vulns of type:  OS Command Injections
2011 had 8 vulns of type:  Format String Vulnerability
Total vulns in 2011 with CWE: 3044
Percentage of vulns with CWE: 81.5429949102599%
Total: 49439

To be honest, I am a bit dismayed at the quality of the data. 2001 only categorized 1.7% of the vulns recorded (I am sure most, if not all, were added retroactively). The highest percentage of vulns that had been categorized was 90% in 2008. I find it interesting that the first few years are dominated by buffer overflows (perhaps because of poor data), and then around 2008, web vulns become the top recorded and categorized. Perhaps this is because of the vast amount new web technologies emerging. That is, until 2011 where buffer overflows are once again the most. I used the xml files from the NIST and my source code that I used to generate the stats is on github. Using LINQ, so it isn't super speedy. Takes a few minutes. Works with Mono or .NET.

Communicating with your Metasploit server via Mono/.NET

A few months ago, I released a library that helped integrate Nexpose into your .NET/Mono applications. A few nights ago, I checked in my library that allows communication and integration with Metasploit from your .NET/Mono applications. Very much in beta, and I am not calling it feature complete. Works for the most part, but bugs will be found (and patches accepted!). Take a look at the Example I have to see it in action. It follows the same Session/Manager pattern as the nexpose library does. No pro methods added yet, just core.

What browsers support @import in their CSS?

I prefer the following CSS:

<html>
<body>
<head>
<style type="text/css">
        @import url(/css/style.css);
      </style>
</head>
</body>
</html>

But not all browsers support @import. I wanted to see exactly which ones didn't so I used browsershots.org with a simple test.

Here are the results: http://browsershots.org/http://volatileminds.net/import_test.html

Black means it supports it. White means it doesn't.

Communicating with your NeXpose server via Mono/.NET

I have a public repo on github that houses my nexpose-sharp library. It is written in C# and consumes the NeXpose XML API (both 1.1 and 1.2). Here is an example of how easy it is to get all the vuln checks NeXpose has:

using System;
using System.Xml;
using nexposesharp;

namespace nexposeclient
{
class MainClass
{
public static void Main (string[] args)
{
using (NexposeSession session = new NexposeSession("192.168.56.101"))
{
session.Authenticate("nexpose"/*user*/, "nexpose"/*password*/);

using (NexposeManager11 manager = new NexposeManager11(session))
{
XmlDocument vulns = manager.GetVulnerabilityListing();

int i = 0;
foreach (XmlNode vuln in vulns.FirstChild.ChildNodes)
{
string vulnID = vuln.Attributes["id"].Value;

XmlDocument deets = manager.GetVulnerabilityDetails(vulnID);

string title = deets.FirstChild.FirstChild.Attributes["title"].Value;
string severity = deets.FirstChild.FirstChild.Attributes["severity"].Value;

Console.WriteLine(String.Format("{0} has a severity of {1} and an id of {2}", title, severity, vulnID));

i++;
}

Console.WriteLine("\n\nTotal vulnerabilities in database: " + i);
}
}
}
}
}


The library has 2 manager implementations. The above example use the 1.1 API. A NexposeManager12 class exists that inherits from NexposeManager11 (available from NeXpose 4.0) and implements the extended 1.2 API (available for NeXpose installations of 4.8+). I am currently in the process of writing some unit tests, which will be committed as soon as possible.

You can grab a copy of NeXpose Community Edition today and try it out!

Reading offline registry hives in pure ruby

If you have ever wanted to peruse a registry hive on Linux, you know that options are really lacking. Most people wonder why you would even want to read a registry hive on Linux, but it is fairly straightforward when you think of the kind of people who will be traversing through registry hives in the first place. Forensics and reverse engineers will often run Linux.

Last night, I checked in my offline registry hive library written in Ruby. I had written a really crappy one in C# based on key signatures, rather than parsing the actual tree. This library does it correctly, by parsing the tree. It is still in its infancy, but it works well enough. You may view the code here. One day, I hope this gets merged in to the Metasploit trunk in some form or fashion. Tested on Ubuntu 11.10 on ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux].

root@w00den-pickle:/home/bperry/tmo/hives/ntreg-ruby# ruby ntreg.rb '\Select' ../SYSTEM
Hive name: "SYSTEM"
Found root key: CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144}
The values and data of \CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144}\Select are:
"Current: \x01\x00\x00\x00"
"Default: \x01\x00\x00\x00"
"Failed: \x00\x00\x00\x00"
"LastKnownGood: \x02\x00\x00\x00"
root@w00den-pickle:/home/bperry/tmo/hives/ntreg-ruby# ruby ntreg.rb '\ControlSet001\Control\Lsa' ../SYSTEM
Hive name: "SYSTEM"
Found root key: CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144}
The children of \CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144}\ControlSet001\Control\Lsa are:
"AccessProviders"
"Audit"
"Credssp"
"Data"
"FipsAlgorithmPolicy"
"GBG"
"JD"
"Kerberos"
"MSV1_0"
"Skew1"
"SSO"
"SspiCache"
The values and data of \CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144}\ControlSet001\Control\Lsa are:
"auditbaseobjects: \x00\x00\x00\x00"
"auditbasedirectories: \x00\x00\x00\x00"
"crashonauditfail: \x00\x00\x00\x00"
"fullprivilegeauditing: \x00\x00\x00\x00"
"Bounds: \x000\x00\x00\x00 \x00\x00"
"LimitBlankPasswordUse: \x01\x00\x00\x00"
"NoLmHash: \x01\x00\x00\x00"
"Notification Packages: s\x00c\x00e\x00c\x00l\x00i\x00\x00\x00\x00\x00"
"Security Packages: k\x00e\x00r\x00b\x00e\x00r\x00o\x00s\x00\x00\x00m\x00s\x00v\x001\x00_\x000\x00\x00\x00s\x00c\x00h\x00a\x00n\x00n\x00e\x00l\x00\x00\x00w\x00d\x00i\x00g\x00e\x00s\x00t\x00\x00\x00t\x00s\x00p\x00k\x00g\x00\x00\x00p\x00k\x00u\x002\x00u\x00\x00\x00\x00\x00"
"Authentication Packages: m\x00s\x00v\x001\x00_\x000\x00\x00\x00\x00\x00"
"LsaPid: \xEC\x01\x00\x00"
"SecureBoot: \x01\x00\x00\x00"
"ProductType: \x02\x00\x00\x00"
"disabledomaincreds: \x00\x00\x00\x00"
"everyoneincludesanonymous: \x00\x00\x00\x00"
"forceguest: \x00\x00\x00\x00"
"restrictanonymous: \x00\x00\x00\x00"
"restrictanonymoussam: \x01\x00\x00\x00"
root@w00den-pickle:/home/bperry/tmo/hives/ntreg-ruby#