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.
Subscribe to:
Posts (Atom)
