Thursday, January 22, 2009
Tactical Exploitation at Black Hat DC
Valsmith and I are offering a Tactical Exploitation course for BlackHat DC on February 16th and 17th. This two-day course introduces a tactical approach that does not rely on exploiting known vulnerabilities. Using a combination of new tools and lesser-known techniques, students will learn how to compromise systems without depending on standard exploits. This course is limited to a small number of seats (less than 15) and we only have few spots left. For examples of the types of things this course covers, please see our original Black Hat slides and the first half of our Defcon talk. This is only the second time that we have offered the full two-day course and is the first class that covers a huge set of new tools and techniques. Register before February 1st to get the cheapest rate. Hope to see you there!
Sunday, January 18, 2009
Netcat-like Console Command: Connect
A few weeks ago I committed the initial version of a new console command used to communicate with a host: connect. Since then I've slowly added a few more features.
If you've ever used Netcat (all of you I'm sure), you'll feel right at home. If not, connect is quite simple to use and you should pick up on it quickly given the text below.
As you can see, connect has many options to choose from. One very cool one is the -c option which allows you to, for example, route through a Meterpreter session. I show this below.
I've blocked HTTP access for this computer at the router:
But let's see if we can re-route this through another computer and get it working anyway:
Booyah.
Of course that was just one contrived example, but having a built-in netcat-like command should open up some doors for fun and profit.
Enjoy!
Kris Katterjohn
If you've ever used Netcat (all of you I'm sure), you'll feel right at home. If not, connect is quite simple to use and you should pick up on it quickly given the text below.
msf > connect -h
Usage: connect [options] <host> <port>
Communicate with a host, similar to interacting via netcat.
OPTIONS:
-C Try to use CRLF for EOL sequence.
-S <opt> Specify source address.
-c <opt> Specify which Comm to use.
-i <opt> Send the contents of a file.
-p <opt> List of proxies to use.
-s Connect with SSL.
-w <opt> Specify connect timeout.
As you can see, connect has many options to choose from. One very cool one is the -c option which allows you to, for example, route through a Meterpreter session. I show this below.
I've blocked HTTP access for this computer at the router:
msf > connect metasploit.com 80
[-] Unable to connect: The connection timed out (metasploit.com:80).
But let's see if we can re-route this through another computer and get it working anyway:
msf > sessions -l
Active sessions
===============
Id Description Tunnel
-- ----------- ------
1 Meterpreter 192.168.10.3:44692 -> 192.168.10.7:4444
msf > connect -c 1 metasploit.com 80
[*] Connected to metasploit.com:80
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Sun, 18 Jan 2009 15:01:22 GMT
[...]
Booyah.
Of course that was just one contrived example, but having a built-in netcat-like command should open up some doors for fun and profit.
Enjoy!
Kris Katterjohn
Friday, January 16, 2009
identBuf has a new format and new features
I've added the ability to import files into tracked buffers, and also added the ability to make use of them as a memDiff input type. This means a new format for the
Depending on the TYPE, the rest of the command may have different parts. Lets examine the currently supported types:
ASCII
The ascii type acts in the same way as you're used to. It requires a name, and a value which will be tracked, but no size. The string will be null terminated as normal.
msfPattern
The msfpattern input type has been enhanced to allow for you to provide a custom name. It requires a name and a size, but no value. Future enhancements may involve multiple msfpatterns starting where the last left off in the pattern so as to not confuse multiple pattern buffers with one another. The format looks like this:
File
The file input type will suck in a file of any format and register it as a tracked buffer. It requires a name, and takes the file path as a value. It also requires a size to be input. Future enhancements may include ability to provide an offset into the file to start reading from. Let me know if you'd like to see this. Currently though, the format looks like:
Note that listing non-ascii buffers with
All binaries are updated with these new changes.
!jutsu identBuf command:!jutsu identBuf TYPE NAME [VALUE SIZE]
Depending on the TYPE, the rest of the command may have different parts. Lets examine the currently supported types:
ASCII
The ascii type acts in the same way as you're used to. It requires a name, and a value which will be tracked, but no size. The string will be null terminated as normal.
!jutsu identBuf ascii myAsciiBuf CatImAKittyCatAndIDanceDanceDance
msfPattern
The msfpattern input type has been enhanced to allow for you to provide a custom name. It requires a name and a size, but no value. Future enhancements may involve multiple msfpatterns starting where the last left off in the pattern so as to not confuse multiple pattern buffers with one another. The format looks like this:
!jutsu identBuf msfpattern myMsfPattern 16
File
The file input type will suck in a file of any format and register it as a tracked buffer. It requires a name, and takes the file path as a value. It also requires a size to be input. Future enhancements may include ability to provide an offset into the file to start reading from. Let me know if you'd like to see this. Currently though, the format looks like:
!jutsu identBuf file myFileBuf C:\msf3\input.bin 64
Note that listing non-ascii buffers with
!jutsu listBuf may result in some funny output, but this wont break anything...All binaries are updated with these new changes.
Thursday, January 15, 2009
!jutsu memDiff
On request, I've added a memory diffing function to byakugan, which will allow you to compare a segment of memory to any buffer that's tracked with identBuf. Shortly I'll be adding the ability to pull buffers in from files, and even directly from metasploit through a back channel. (I promise back channel support is next!)
To test (and explain) functionality, I threw together a simple program:
This code makes a simple MSF pattern, then corrupts a few random characters, and replaces all '6's with '1's.
If we then load this program in byakugan, and then register a buffer with
The arguments to memDiff are
In this case, the output will look something like this:
The differ will show actual and expected with changes in bold on the actual side. In addition to that, it will store "bad chars" as well as corrupted offsets. It uses a simple algorithm to decide which is which. If a byte is modified, but that same byte is seen later in the payload, the assumption is made that the corruption is offset based, however, if all of a given character are missing, that is assumed to be a bad character. Obviously this approach falls down without a sufficiently complex input, but it certainly helps at times. I'll be augmenting this shortly with a truncation check to clean up the output in cases where you just dont have the space.
New binaries are uploaded for XPSP2, Vista, and Win7. New inputs coming soon!
To test (and explain) functionality, I threw together a simple program:
This code makes a simple MSF pattern, then corrupts a few random characters, and replaces all '6's with '1's.
If we then load this program in byakugan, and then register a buffer with
identBuf we can diff the registered buffer with the pattern in memory and see the changes:!jutsu memDiff buf 64 msfPattern 0x0012fef0The arguments to memDiff are
type size value and address. For now the only accepted type is buf. This will take the name provided as value and pull that buffer from the tracked list for diffing. The size is the number of bytes to diff, and the address is the beginning address of the diff.In this case, the output will look something like this:
The differ will show actual and expected with changes in bold on the actual side. In addition to that, it will store "bad chars" as well as corrupted offsets. It uses a simple algorithm to decide which is which. If a byte is modified, but that same byte is seen later in the payload, the assumption is made that the corruption is offset based, however, if all of a given character are missing, that is assumed to be a bad character. Obviously this approach falls down without a sufficiently complex input, but it certainly helps at times. I'll be augmenting this shortly with a truncation check to clean up the output in cases where you just dont have the space.
New binaries are uploaded for XPSP2, Vista, and Win7. New inputs coming soon!
Friday, January 9, 2009
Windows 7 Byakugan Binaries Added!
It's true! They're in subversion now in the byakugan/bin/Win7 directory - detours and all. If you're interested in building your own on windows 7, you'll just need to nab the WDK and SDK, then remove the TARGETPATH from the sources files in both the base dir and the injectsu dir. Simply build as usual, running setup.bat from a free build WDK window. Your newly built bins will end up in objfre_win7_x86/i386.
To build detours, go to the detours directory with an SDK build cmd prompt and just do an nmake -f Makefile. It'll place the new detoured.dll in byakugan/bin.
If you use this, let me know how it goes - I haven't put it through any kind of testing, just built, made sure some basic things worked, and commited.
Oh! And if you DO decide to build it on your own, how cool is it that the WDK auto-runs prefast over you code and shows you my use of strncpy?? Effin' sweet. All built into the task bar an' shit. Nice gui too!
To build detours, go to the detours directory with an SDK build cmd prompt and just do an nmake -f Makefile. It'll place the new detoured.dll in byakugan/bin.
If you use this, let me know how it goes - I haven't put it through any kind of testing, just built, made sure some basic things worked, and commited.
Oh! And if you DO decide to build it on your own, how cool is it that the WDK auto-runs prefast over you code and shows you my use of strncpy?? Effin' sweet. All built into the task bar an' shit. Nice gui too!
Wednesday, January 7, 2009
New justsu: trackVal
I've just added a new jutsu method to byakugan to help you find the address of a particular primitive (DWORD, WORD, or BYTE) in memory. Obviously, this isn't a terribly difficult task - you use the search function in windbg. What trackVal will do for you is allow you to see which of the thousand some-odd addresses search returns is actually storing the primitive you care about. For example, I'll demonstrate how to use trackVal to determine where the result value lives in calc.exe
First, we load calc.exe and do a simple operation which will give us a result. I'll just do 9999 + 1, which will of course give us a value of 10000 or 0x2710 in hex. With the value displayed in calc, we'll attach with windbg, load byakugan, and issue the first trackVal command:
Lets disect the command:
- result is the unique name of the value we're tracking - it's arbitrary, but we'll need to remember it for later
- 4 is the size of the primitive we're concerned with; it can be 4, 2, or 1
- 0x2710 is the hex value that we'd like to find
Once the command is issued, we're informed that the name is unrecognized so an initial sweep of process memory is occuring to find all the possible candidate addresses for our value. When this is finished, we're informed that there are 115 possibilities. Far too many.
Our next task is to continue the process and make a minor change to the value in question. We'll add 3 to it, for a value of 0x2713, then break again and reissue our command:
The command is the same as before, apart from the value. It is important that we use the same name, because this time around we will only be searching the previously discovered candidate addresses. Out of the 115 addresses, only one has our new value in it, and we are informed of this. Score. If more than one had the value, we could repeat this exercise until it's fully narrowed down.
To list what values you're tracking, their sizes, and what how many candidates they have, simply type:
And to see what the candidates are, just add a name to that command, and no size or value:
This new tool is expecially useful for cracking software, and cheating at Fallout 3. Happy hunting!
BONUS: There are now updated XPSP2 binaries in svn, along with the updated Vista binaries!
First, we load calc.exe and do a simple operation which will give us a result. I'll just do 9999 + 1, which will of course give us a value of 10000 or 0x2710 in hex. With the value displayed in calc, we'll attach with windbg, load byakugan, and issue the first trackVal command:
0:002> !jutsu trackVal result 4 0x2710
[J] Creating new list of candidates for result.
[J] Discovered 115 possible candidate addresses for result
Lets disect the command:
- result is the unique name of the value we're tracking - it's arbitrary, but we'll need to remember it for later
- 4 is the size of the primitive we're concerned with; it can be 4, 2, or 1
- 0x2710 is the hex value that we'd like to find
Once the command is issued, we're informed that the name is unrecognized so an initial sweep of process memory is occuring to find all the possible candidate addresses for our value. When this is finished, we're informed that there are 115 possibilities. Far too many.
Our next task is to continue the process and make a minor change to the value in question. We'll add 3 to it, for a value of 0x2713, then break again and reissue our command:
0:002> !jutsu trackVal result 4 0x2713
[J] Narrowing down candidate list for result from 115 candidates.
[J] Value result is stored at address 0x0014cc64
The command is the same as before, apart from the value. It is important that we use the same name, because this time around we will only be searching the previously discovered candidate addresses. Out of the 115 addresses, only one has our new value in it, and we are informed of this. Score. If more than one had the value, we could repeat this exercise until it's fully narrowed down.
To list what values you're tracking, their sizes, and what how many candidates they have, simply type:
0:001> !jutsu trackVal
[J] Currently tracking:
Name: result Size: 4 Candidates: 111
And to see what the candidates are, just add a name to that command, and no size or value:
0:001> !jutsu trackVal result
[J] Currently tracking 111 candidates for result:
Address: 0x00684962
Address: 0x006c3fa8
Address: 0x006c9758
Address: 0x7463a0a6
Address: 0x74644707
Address: 0x74646042
....
This new tool is expecially useful for cracking software, and cheating at Fallout 3. Happy hunting!
BONUS: There are now updated XPSP2 binaries in svn, along with the updated Vista binaries!
Saturday, January 3, 2009
Scanning for MD5-signed SSL Certificates
Efrain Torres just committed an improvement to the Metasploit source tree that allows the framework to be used as a SSL certificate scanner. This provides a simple way to identify SSL certificates in use that were signed with the MD5 algorithm and need to re-issued. To use the new module, update to the latest version of the development framework (3.3-dev) and follow the steps below.
msf > use auxiliary/scanner/http/wmap_ssl
msf auxiliary(wmap_ssl) > set RHOSTS admin.censored.bad
msf auxiliary(wmap_ssl) > set RPORT 443
msf auxiliary(wmap_ssl) > set SSL true
msf auxiliary(wmap_ssl) > run
[*] Subject: /C=US/O=admin.censored.bad/OU=https://services.choicepoint.net/get.jsp?XXXXXXX/OU=See www.freessl.com/cps (c)04/OU=Domain Control Validated - This is a GeoTrust StarterSSL(TM) Certificate/CN=admin.censored.bad Signature Alg: md5WithRSAEncryption
[*] A.B.C.D WARNING: Signature algorithm using MD5 (md5WithRSAEncryption)
[*] A.B.C.D is host admin.censored.bad
To scan a wider range of addresses, specify a CIDR or address range for the RHOST parameter, and set the THREADS parameter to something bigger (256 on Unix, 10 on Windows).
msf > use auxiliary/scanner/http/wmap_ssl
msf auxiliary(wmap_ssl) > set RHOSTS admin.censored.bad
msf auxiliary(wmap_ssl) > set RPORT 443
msf auxiliary(wmap_ssl) > set SSL true
msf auxiliary(wmap_ssl) > run
[*] Subject: /C=US/O=admin.censored.bad/OU=https://services.choicepoint.net/get.jsp?XXXXXXX/OU=See www.freessl.com/cps (c)04/OU=Domain Control Validated - This is a GeoTrust StarterSSL(TM) Certificate/CN=admin.censored.bad Signature Alg: md5WithRSAEncryption
[*] A.B.C.D WARNING: Signature algorithm using MD5 (md5WithRSAEncryption)
[*] A.B.C.D is host admin.censored.bad
To scan a wider range of addresses, specify a CIDR or address range for the RHOST parameter, and set the THREADS parameter to something bigger (256 on Unix, 10 on Windows).
Fuzzing Flash For Fun (ASNative)
Yesterday, Bas Alberts (of Immunity) posted to his blog about the recent Flash patch and his work reversing the code and exploiting the bug. The vulnerable function is exposed through the System.Product namespace but is also accessible by using the ASnative API directly.
The ASnative API is interesting because it offers a different way to call builtin functions, and the only way to call certain undocumented functions. ASnative functions are indexed in a two-dimensional array, with the first index being between 1 and 3000, while the second index is usually below 300. The "escape" function has an index value of (100,0). The two lines of code below are equivalent:
flash.Lib._root.escape("&");
flash.Lib._root._global.ASnative(100,0)("&");
The neat thing about accessing functions by index is that it provides a way to enumerate all available native functions. This can be used to write a quick input fuzzer that may shake out programming flaws in the Flash plugin API. Before we can get started, we still have a few problems to address.
First off, we need to determine what parameters should be passed to each function and how many parameters to test. The Flash ASnative API does not give us any information about parameter counts or types of each entry. The easy way to solve this is to try a set of "bad" inputs and pass these up to four times as four different parameters. This would lead to a series of calls like:
var str:String = "AAA[...]AAA";
flash.Lib._root._global.ASnative(100,0)();
flash.Lib._root._global.ASnative(100,0)(str);
flash.Lib._root._global.ASnative(100,0)(str,str);
flash.Lib._root._global.ASnative(100,0)(str,str,str);
flash.Lib._root._global.ASnative(100,0)(str,str,str,str);
This is far from perfect, but it does provide us with a starting point.
Next, we need a way to report progress back to the user. A common problem with client-side fuzzing (ActiveX, browser native objects, DOM, etc) is that while the test is happening, the user interface appears to be frozen. This makes it tough to provide meaningful feedback about progress during the test. Additionally, it makes it harder to determine what actual function and input that caused a crash when one occurs. In the case of AxMan, progress could be determined by watching the web server logs and the Internet Explorer status bar. In the case of Flash, we would have to call back via Javascript, since the normal UI elements aren't updated fast enough to track progress.
While using a Javascript callback might work, Flash has a feature which can make this process much easier. The XMLSocket class allows the Flash code to connect back to the originating server on a TCP port and perform bidirectional communication. This is a great way to report progress, since the last received TCP message will indicate what ASnative call and input combination triggered a crash. This requires a server-side daemon which handles the XML policy request and displays the progress reports to the user.
Finally, we have to solve one of the most dreaded issues in client-side programming -- the execution watchdog. In the case of Flash, any computation task that takes more than a few seconds will cause a dialog to appear that gives the user the option to interrupt the code. While this is a great feature and prevents a rogue Flash applet from hijacking a browser's resources, it does get in the way of automated testing, since the popups would require constant input from the user. To solve this, the testing loop is broken into chunks of 50 iterations, with each iteration scheduling the next iteration for 250ms in the future. This provides just enough of a break that the watchdog does not kick in. The required test time increases, but the process no longer needs to have a human clicking through the dialogs.
Once the initial code was complete, I tested the latest version of Flash on Ubuntu Linux (10.0.15.3) and Windows XP (10.0.12.36). Both tests resulted in the discovery of about four different fatal crashes. While these all appear to be NULL dereferences, sometimes these are exploitable after all (if you happen to be Mark Dowd).
To test the full set of ASnative functions, I updated the starting counter (createInput(): x = 0) to run the next test immediately after the function which triggered a crash. This, along with the input testing method itself, should be improved in the future to be configurable by the user and passed as parameters to the Flash code. This fuzzer barely scratched the surface in terms of coverage and features, but it still managed to find a handful of new bugs, and only took a couple hours to hack together. The full source code, along with instructions for use, can be found online at:
http://metasploit.com/users/hdm/tools/flashboom-0.02.tar.gz
A live demo of the Flash fuzzer can be found at the URL below:
http://metasploit.com/users/hdm/tools/flashboom-demo/
Have fun!
-HD
The ASnative API is interesting because it offers a different way to call builtin functions, and the only way to call certain undocumented functions. ASnative functions are indexed in a two-dimensional array, with the first index being between 1 and 3000, while the second index is usually below 300. The "escape" function has an index value of (100,0). The two lines of code below are equivalent:
flash.Lib._root.escape("&");
flash.Lib._root._global.ASnative(100,0)("&");
The neat thing about accessing functions by index is that it provides a way to enumerate all available native functions. This can be used to write a quick input fuzzer that may shake out programming flaws in the Flash plugin API. Before we can get started, we still have a few problems to address.
First off, we need to determine what parameters should be passed to each function and how many parameters to test. The Flash ASnative API does not give us any information about parameter counts or types of each entry. The easy way to solve this is to try a set of "bad" inputs and pass these up to four times as four different parameters. This would lead to a series of calls like:
var str:String = "AAA[...]AAA";
flash.Lib._root._global.ASnative(100,0)();
flash.Lib._root._global.ASnative(100,0)(str);
flash.Lib._root._global.ASnative(100,0)(str,str);
flash.Lib._root._global.ASnative(100,0)(str,str,str);
flash.Lib._root._global.ASnative(100,0)(str,str,str,str);
This is far from perfect, but it does provide us with a starting point.
Next, we need a way to report progress back to the user. A common problem with client-side fuzzing (ActiveX, browser native objects, DOM, etc) is that while the test is happening, the user interface appears to be frozen. This makes it tough to provide meaningful feedback about progress during the test. Additionally, it makes it harder to determine what actual function and input that caused a crash when one occurs. In the case of AxMan, progress could be determined by watching the web server logs and the Internet Explorer status bar. In the case of Flash, we would have to call back via Javascript, since the normal UI elements aren't updated fast enough to track progress.
While using a Javascript callback might work, Flash has a feature which can make this process much easier. The XMLSocket class allows the Flash code to connect back to the originating server on a TCP port and perform bidirectional communication. This is a great way to report progress, since the last received TCP message will indicate what ASnative call and input combination triggered a crash. This requires a server-side daemon which handles the XML policy request and displays the progress reports to the user.
Finally, we have to solve one of the most dreaded issues in client-side programming -- the execution watchdog. In the case of Flash, any computation task that takes more than a few seconds will cause a dialog to appear that gives the user the option to interrupt the code. While this is a great feature and prevents a rogue Flash applet from hijacking a browser's resources, it does get in the way of automated testing, since the popups would require constant input from the user. To solve this, the testing loop is broken into chunks of 50 iterations, with each iteration scheduling the next iteration for 250ms in the future. This provides just enough of a break that the watchdog does not kick in. The required test time increases, but the process no longer needs to have a human clicking through the dialogs.
Once the initial code was complete, I tested the latest version of Flash on Ubuntu Linux (10.0.15.3) and Windows XP (10.0.12.36). Both tests resulted in the discovery of about four different fatal crashes. While these all appear to be NULL dereferences, sometimes these are exploitable after all (if you happen to be Mark Dowd).
To test the full set of ASnative functions, I updated the starting counter (createInput(): x = 0) to run the next test immediately after the function which triggered a crash. This, along with the input testing method itself, should be improved in the future to be configurable by the user and passed as parameters to the Flash code. This fuzzer barely scratched the surface in terms of coverage and features, but it still managed to find a handful of new bugs, and only took a couple hours to hack together. The full source code, along with instructions for use, can be found online at:
http://metasploit.com/users/hdm/tools/flashboom-0.02.tar.gz
A live demo of the Flash fuzzer can be found at the URL below:
http://metasploit.com/users/hdm/tools/flashboom-demo/
Have fun!
-HD
Subscribe to:
Posts (Atom)
