Thursday, October 13, 2011

Scanning for bypassable reverse proxies

Context recently wrote an interesting article on a new technique to bypass reverse proxies. I, of course, got right to work on writing a Metasploit scanner module to check for vulnerable servers. This is a quick log dump of using that module.

chao@blog:/opt/framework3$ ./msfconsole -L
msf > use auxiliary/scanner/http/rewrite_proxy_bypass
msf  auxiliary(rewrite_proxy_bypass) > info

       Name: Reverse Proxy Bypass Scanner
     Module: auxiliary/scanner/http/rewrite_proxy_bypass
    Version: 13886
    License: Metasploit Framework License (BSD)
       Rank: Normal

Provided by:

Basic options:
  Name               Current Setting  Required  Description
  ----               ---------------  --------  -----------
  BASELINE_URI       /                yes       Requested to establish that EXPECTED_RESPONSE is not the usual response
  ESCAPE_SEQUENCE    @                yes       Character(s) that terminate the rewrite rule
  EXPECTED_RESPONSE  502              yes       Status code that indicates vulnerability
  INJECTED_URI       ...              yes       String injected after escape sequence
  Proxies                             no        Use a proxy chain
  RHOSTS                              yes       The target address range or CIDR identifier
  RPORT              80               yes       The target port
  THREADS            1                yes       The number of concurrent threads
  VHOST                               no        HTTP server virtual host

  Scan for poorly configured reverse proxy servers. By default, this 
  module attempts to force the server to make a request with an 
  invalid domain name. Then, if the bypass is successful, the server 
  will look it up and of course fail, then responding with a status 
  code 502. A baseline status code is always established and if that 
  baseline matches your test status code, the injection attempt does 
  not occur. "set VERBOSE true" if you are paranoid and want to catch 
  potential false negatives. Works best against Apache and mod_rewrite


msf  auxiliary(rewrite_proxy_bypass) > set rhosts
rhosts =>
msf  auxiliary(rewrite_proxy_bypass) > exploit

[+] is vulnerable!
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf  auxiliary(rewrite_proxy_bypass) > set verbose true
verbose => true
msf  auxiliary(rewrite_proxy_bypass) > exploit

[*] took 0.0856 seconds to respond to URI /
[*] responded with status code 302 to URI /
[*] took 0.056552 seconds to respond to URI @...
[*] responded with status code 502 to URI @...
[+] is vulnerable!
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Thursday, July 14, 2011

Release notes for revision 13181.

"Committed revision 13181...."

Improvements to testing
  • Railgun::UnitTest now has tests for .const, .method_missing, .get_dll, in addition to the new known_dll_names
  • ApiConstants::UnitTest now has a test for the new get_manager function
  • DLLHelper::UnitTest is now ruby 1.8.6 compatible
  • DLL::UnitTest became cleaner after adjusting for the changes to DLL
  • DLLWrapper::UnitTest was added to test the newly added class DLLWrapper.
  • railgun.rb.ts.rb contains tests that should have but weren't added
Performance Tweaks
  • DLLs with definition classes (railgun/def/Def_*) are loaded once and shared across instances (railgun.add_function makes a local copy so you can still thread-safely make changes to just that instance)
  • No calculations are performed when the railgun instance initializes. All loading is done lazily.
Changes that affect you
  • Support for dlls with a corresponding Def_ class is added by adding the DLL's name to BUILTIN_DLLS instead of editing code in get_dll
  • Def classes load dlls by creating them explicitly (as in and then adding functions directly instead of going through the railgun instance like before.
  • Def classes now have the ability to control what WinConstManager a given DLL will contain. Will be important later.
  • Documentation scattered throughout railgun.rb
  • Styling in railgun.rb was redone to match my target style for railgun
  • Removed some code silliness from various places
  • ApiConstants now has a class-scoped WinConstManager that is accessible through ApiConstants.get_manager and is lazily loaded.
  • Added method to display the names of dlls available to be loaded. (This was needed in areas that wanted to show what was available, but instead only showed what had been loaded so far)
  • method_missing now returns a wrapper class that acts as an interface to the underlying Railgun::DLL instance. This helped remove Railgun::DLL's dependence on Client

New way to add DLLs to railgun

If you are reading this, I probably submitted to the Metasploit repository directly for the first time! That's right, I have commit rights now. My first round of changes closed bug #3073 "Railgun DLL cache/definition loader needs a rewrite." This lead me to rewrite large chunks of code including how DLLs are defined and handled behind the scenes. This tutorial is a complement to those changes.

And here we go.

If the DLL you want to access is shipped with Windows and its API remains somewhat consistent, then you should NEVER load the DLL/Functions on the fly. Instead, benefit everyone and expand Railgun itself by adding support at a framework-level. This practice leads to better performance (the DLLs/Functions will be cached), cleaner code (the definitions will have their own place), and greater accessibility (the DLLs will be accessible wherever you can type client.railgun). In this blog post, I will show you how.

In our example we will be adding support for the DLL ws2_32.

1. Create a file to contain your definition class

DLL definition classes can be found in lib/rex/post/meterpreter/extensions/stdapi/railgun/def. The file name should be "def_" followed by your DLL's name. In our example, our file would be lib/rex/post/meterpreter/extensions/stdapi/railgun/def/def_ws2_32.rb

2. Declare the definition class

The class name should start with Def_ followed by your DLL name (case sensitive, underscores). In our case we would end up with thhe following code:
module Rex
module Post
module Meterpreter
module Extensions
module Stdapi
module Railgun
module Def
class Def_ws2_32
end; end; end; end; end; end; end
3. Add the create_dll method

The create_dll class method is responsible for returning a fully functional DLL. Within it, we will have the oppertunity to specify the DLL's path, what constants should be defined, and what functions will be available.

3.1 declare the method
def self.create_dll(dll_path = 'ws2_32')
3.2 Instantiate the DLL
dll =, ApiConstants.manager)
3.3 Add some functions
dll.add_function('WSACleanup', 'DWORD',[])
3.5 Love it!
def self.create_dll(dll_path = 'ws2_32')
dll =, ApiConstants.manager)
dll.add_function('WSACleanup', 'DWORD',[])
return dll
4. Make the DLL available

Making the DLL available to be used (client.railgun.my_dll_name) is straightforward. Open railgun.rb and add the name of your dll to BUILTIN_DLLS. Be sure to read the comment.

5. Enjoy!

Yep, that was it.

Monday, July 11, 2011

Urban Dictionary Wordlist

EDIT: Unfortunately my VPS went down and took with it the list. If you have a backup PLEASE let me know.

Hello all!

I have built a wordlist that includes all terms defined on I have already tweeted a link to it and almost 1500 have downloaded so far, with the rate of downloads increasing exponentially. I am now posting about it on my blog so that I can both bring it to a wider audience and get feedback from those downloading it.

Was it useful? What did you use it for? Discover anything interesting? Run some kind of statistical analyses? If used for cracking, what word mangling rules did you find useful with it? Etc? If I get enough interesting comments, I will hurry up and post some of my other lists/scripts/rules as I develop them.

Find it here: 

I dedicate this wordlist to the great folks at SkullSpace and to iagox86 who is kind enough to share even coolor wordlists with us.

NOTE: There may be a slight flaw in the word list. Due to a bug, perhaps two or three of the lines are garbage, consisting of half of the next line. To be honest though, this is trivial considering how big the collection is. With the possibility of that tiny exception, it should be rock solid.

Happy hacking friends!
chao-mu@blog:~$ logout

Saturday, June 4, 2011

Railgun Update: Milestone 1 Reached!

This is a well overdue post and I apologise for my lateness. However, I have some cool stuff to point out on the horizon.

Milestone 1, as a reminder, was to increase test coverage. Well, the ticket tracking it ( is now officially closed. In other words, I am satisfied with railgun test coverage to an extent that I feel comfortable moving on to implementing features again. (As for that matter, I have already started to do so.) This certainly doesn't mean I wont stop writing new test cases; it just means that I wont feel like I am constantly "playing catch-up."

One of the coolest new additions is "mock_magic.rb". I will dedicate the rest of this blog post to talking about it, in fact. Railgun::MockMagic is a mixin that provides mock objects and staging to help facilitate thorough (and easy) testing.

Open lib/rex/post/meterpreter/extensions/stdapi/railgun/mock_magic.rb up and take a look! I would like to draw your attention particularly to the function "mock_function_descriptions". This method returns an array of hashes each representing a function. The hash contains everything needed to recreate the function and full lifecycle of it being called. This is remarkably useful when testing. It obviates the need for a living client when testing! It also provides an input and output snapshot of sorts, giving us some level of confidence that changes in how we encode/decode values is backwards compatible. Quality here, however, is dependent on quantity and diversity therein.

So how are such snapshots generated and how can you help expand them or make sure I don't break your changes?
  1. edit lib/rex/post/meterpreter/extensions/stdapi/railgun/dll.rb
  2. Search for "=== START of proccess_function_call snapshot ==="
  3. Uncomment from the start of the "puts" call to its end
  4. Make some Railgun calls in your Metasploit post modules
  5. Add the output to mock_magic.rb and/or email it to me
Okay, enough of this for now.

Finally, I conclude this post with a sample of some output:
chao@blog:/opt/framework3/lib/rex/post/meterpreter/extensions/stdapi/railgun$ ls *.ut.rb | while read x; do ruby $x; done
Loaded suite api_constants.rb.ut
Finished in 0.045200 seconds.

1 tests, 1 assertions, 0 failures, 0 errors, 0 skips

Test run options: --seed 16551
Loaded suite buffer_item.rb.ut
Finished in 0.000417 seconds.

1 tests, 4 assertions, 0 failures, 0 errors, 0 skips

Test run options: --seed 3861
Loaded suite dll_function.rb.ut
Finished in 0.000417 seconds.

1 tests, 0 assertions, 0 failures, 0 errors, 0 skips

Test run options: --seed 36917
Loaded suite dll_helper.rb.ut
Finished in 0.000889 seconds.

6 tests, 15 assertions, 0 failures, 0 errors, 0 skips

Test run options: --seed 56098
Loaded suite dll.rb.ut
Finished in 0.001357 seconds.

2 tests, 18 assertions, 0 failures, 0 errors, 0 skips

Test run options: --seed 15811
Loaded suite railgun.rb.ut
Finished in 0.001458 seconds.

2 tests, 4 assertions, 0 failures, 0 errors, 0 skips

Test run options: --seed 5062
Loaded suite win_const_manager.rb.ut
Finished in 0.000555 seconds.

4 tests, 10 assertions, 0 failures, 0 errors, Any ways, I will ping you again when I update 0 skips

Test run options: --seed 5801

Monday, April 18, 2011

Railgun update: 1st Milestone almost reached!

Hello again!

A few posts back I proposed a "timeline" of sorts to organize my focus on Railgun development. The first one, logically, was to increase test coverage:

1. Huge increase of test coverage alongside organisational changes to facilitate the effort

When I wrote the above, test coverage for railgun was zilch and the majority of classes were crammed into a single file. And now, a month later, that file has been broken up and there is test coverage for every single class that was in it! Let's show that off now:

chao@blog:/opt/framework3/lib/rex/post/meterpreter/extensions/stdapi/railgun$ ls *.rb.ut.rb | while read test; do ruby $test; done | grep -P 'Loaded|assertions'
Loaded suite api_constants.rb.ut
1 tests, 1 assertions, 0 failures, 0 errors, 0 skips
Loaded suite buffer_item.rb.ut
1 tests, 4 assertions, 0 failures, 0 errors, 0 skips
Loaded suite dll_function.rb.ut
1 tests, 0 assertions, 0 failures, 0 errors, 0 skips
Loaded suite dll_helper.rb.ut
6 tests, 15 assertions, 0 failures, 0 errors, 0 skips
Loaded suite dll.rb.ut
2 tests, 18 assertions, 0 failures, 0 errors, 0 skips
Loaded suite win_const_manager.rb.ut
4 tests, 10 assertions, 0 failures, 0 errors, 0 skips

Sexy? I think so. That's a total of 48 assertions testing 15 ruby methods in order to supply coverage for 6 out of 8 core Railgun classes. /me takes a bow

Okay, enough of me bragging.

So why did I say "almost reached"? Because no one has applied my latest submitted patch yet! Also, I anticipate some tweaking after I get feedback from jcran and others (hopefully that includes you).

For more details you can see the ticket I filed for this:

Stay Froody!
chao-mu@blog:~$ logout

Saturday, March 19, 2011

Die railgun/model.rb!

A super trivial update...

rex/post/meterpreter/extensions/stdapi/railgun/model.rb contained about 5 different classes, linked only by the commonality that they were part of the Railgun API. Well, I just hacked it into smaller pieces! This should make finding files easier. I feel more organised already and I am celebrating by writing unit tests :-)

rex/post/meterpreter/extensions/stdapi/railgun/ now contains...


My remaining gripe is that multicall.rb is the file for MultiCaller. I would rename it, but I don't yet have a handle on its usage outside of the checked-in framework. Does anyone use it?

Stay Froody!
chao-mu@blog:~$ logout