This week's update has a nice new asymmetric DoS condition module, a bunch of churn in Metasploit's Rails components, and some new Citrix attacks, so let's get right into it.

Fuzzing for Citrix Opcodes

This week's update includes three new exploits for Citrix Provisioning Services, the solution by Citrix "to stream a single desktop image to create multiple virtual desktops on one or more servers in a data center" (vendor quote). These modules exploit the same code JITED by the .NET Manager.dll component used by the StreamProcess.exe service (and patched in http://support.citrix.com/article/CTX130846):

0:012> kb ChildEBP RetAddr  Args to Child 04d3f37c 012ba6c4 04d3f4d4 04e40042 ffffffff MSVCR90!wcsncpy [f:\dd\vctools\crt_bld\self_x86\crt\src\wcsncpy.c @ 43] 04d3f424 7c809bbf ffffffff 04d3f450 04d3f454 0x12ba6c4 04d3f444 7c809b89 ffffffff 04c20000 00010000 kernel32!VirtualFreeEx 0x37 04d3f45c 79e8d09b 04c20000 00000000 79e8d0b7 kernel32!VirtualFree 0x15 04d3f494 79e8d0cb 04c20000 00000000 00008000 mscorwks!EEVirtualFree 0x95 04d3f4a8 79082ba9 7a3bdc9c 04c20000 00000000 mscorwks!CExecutionEngine::ClrVirtualFree 0x11 04d3f4cc 79082b6d 790b0000 7907799d 790b7064 mscorjit!norls_allocator::nraToss 0x44 04d3f4d8 790b7064 00000000 79076f16 79065d56 mscorjit!norls_allocator::nraRlsm 0x13 04d3f4e0 79076f16 79065d56 70410543 00000000 mscorjit!___PchSym_ 0x2c 04d3f588 79fc71b7 04d3f780 79fc71db 7045188c mscorjit!jitNativeCode 0x12f 04d3f5e4 79fc722d 001a6a28 04d3f738 04d3f6b0 mscorwks!invokeCompileMethodHelper 0x91 04d3f62c 79fc8da9 035d86fc 04c32830 00000571 mscorwks!invokeCompileMethod 0x31 04d3f66c 79f908a1 79fc357e 70451bf0 035d86fc mscorwks!CallCompileMethodWithSEHWrapper 0xaa 04d3fa18 001f0578 04d3fa54 79e7a14a 04d3faf0 mscorwks!Thread::StackWalkFramesEx 0x109 00000000 00000000 00000000 00000000 00000000 0x1f0578 

With the new modules, now four different paths can be taken to exploit Citrix Provisioning Services. Two of the vulnerable opcodes were disclosed through ZDI advisories (0x40020000 and 0x40020006) while the other two (0x40020002 and 0x40020004) were posted as private exploits. With a little bit of fuzzing, Metasploit exploit developer Juan Vazquez was able to make streamprocess.exe crash with opcodes 0x40020002, 0x40020004, and 0x40020006. Combined with the awesome DEP bypass found by the contributor "Alino" (author of the citrix_streamprocess_data_msg.rb module which exploits the 0x40020000 opcode), we have all the known opcode paths available for Metasploit users.

Here's a complete list of available opcodes can be obtained from the disassemble of the "Manager.dll" component:

seg000:1D558 Ardence.CManagerRequestReceiver.dispatchPacket              ldc.i4 0x40020000 seg000:21803 Ardence.CProtocol.Build_MGR_VDISK_CREATE_REQUEST              ldc.i4 0x4002000A seg000:218E4 Ardence.CProtocol.GetMgrVdiskDeleteRequest              ldc.i4 0x4002000B seg000:218F4 Ardence.CProtocol.GetMgrVdiskDescribeContainerRequest              ldc.i4 0x4002000F seg000:21904 Ardence.CProtocol.GetMgrVdiskGetHeaderRequest              ldc.i4 0x40020000 seg000:21915 Ardence.CProtocol.GetMgrVdiskSetHeaderRequest              ldc.i4 0x40020001 seg000:21925 Ardence.CProtocol.GetMgrVdiskSetFooterRequest              ldc.i4 0x40020003 seg000:21935 Ardence.CProtocol.GetMgrVdiskSetBootRecordRequest              ldc.i4 0x40020005 seg000:21943 Ardence.CProtocol.Build_MGR_VDISK_LIST_REQUEST              ldc.i4 0x4002000E seg000:21973 Ardence.CProtocol.Build_MGR_VDISK_LIST_DIRECTORIES_REQUEST             ldc.i4 0x40020019 seg000:219A3 Ardence.CProtocol.Build_MGR_VDISK_CREATE_DIRECTORY_REQUEST             ldc.i4 0x4002001A seg000:219C3 Ardence.CProtocol.Build_MGR_VDISK_REMOVE_DIRECTORY_REQUEST             ldc.i4 0x4002001B seg000:219EC Ardence.CProtocol.Build_MGR_VDISK_CHECK_SIDECAR_REQUEST              ldc.i4 0x40020017 seg000:21AD3 Ardence.CProtocol.Build_MGR_VDISK_LOCK_REQUEST              ldc.i4 0x40020010 seg000:21B33 Ardence.CProtocol.Build_MGR_VDISK_UNLOCK_REQUEST              ldc.i4 0x40020011 seg000:21B84 Ardence.CProtocol.GetMgrVdiskIsLockedRequest              ldc.i4 0x40020013 seg000:21B94 Ardence.CProtocol.GetMgrVdiskReleaseAllLocksRequest              ldc.i4 0x40020012 seg000:21BA4 Ardence.CProtocol.GetMgrVdiskGetLockInfoRequest              ldc.i4 0x40020014 seg000:21C04 Ardence.CProtocol.GetMgrVdiskGetFooterRequest              ldc.i4 0x40020002 seg000:21C64 Ardence.CProtocol.GetMgrVdiskGetBootRecordRequest              ldc.i4 0x40020004 seg000:21C73 Ardence.CProtocol.Build_MGR_VDISK_GET_OBJECTS_REQUEST              ldc.i4 0x40020006 seg000:22314 Ardence.CProtocol.GetMgrVdiskCheckRequest              ldc.i4 0x40020015 seg000:22325 Ardence.CProtocol.GetMgrVdiskCheckFreeSpaceRequest              ldc.i4 0x40020016 seg000:2235C Ardence.CProtocol.Build_MGR_VDISK_DELETE_DEVICE_DISK_CACHE_FILE_REQUEST              ldc.i4 0x40020018 seg000:2AE27 Ardence.CRemoteManagedVdisk.handleCreateRequest              ldc.i4 0x4002000A seg000:2B30D Ardence.CRemoteManagedVdisk.handleCancelCreateRequest              ldc.i4 0x4002000C seg000:2B65D Ardence.CRemoteManagedVdisk.handleGetCreateProgressRequest             ldc.i4 0x4002000D seg000:2BAFD Ardence.CRemoteManagedVdisk.handleDeleteRequest              ldc.i4 0x4002000B seg000:2BE3D Ardence.CRemoteManagedVdisk.handleDescribeContainerRequest             ldc.i4 0x4002000F seg000:2C18D Ardence.CRemoteManagedVdisk.handleGetBootRecordRequest              ldc.i4 0x40020004 seg000:2C4DD Ardence.CRemoteManagedVdisk.handleGetObjectsRequest              ldc.i4 0x40020006 seg000:2C89D Ardence.CRemoteManagedVdisk.handleGetFooterRequest              ldc.i4 0x40020002 seg000:2CBED Ardence.CRemoteManagedVdisk.handleGetHeaderRequest              ldc.i4 0x40020000 seg000:2CF4D Ardence.CRemoteManagedVdisk.handleListRequest              ldc.i4 0x4002000E seg000:2D2ED Ardence.CRemoteManagedVdisk.handleListDirectoriesRequest              ldc.i4 0x40020019 seg000:2D68D Ardence.CRemoteManagedVdisk.handleCreateDirectoryRequest              ldc.i4 0x4002001A seg000:2D9FD Ardence.CRemoteManagedVdisk.handleRemoveDirectoryRequest              ldc.i4 0x4002001B seg000:2DD6D Ardence.CRemoteManagedVdisk.handleLockRequest              ldc.i4 0x40020010 seg000:2E0CD Ardence.CRemoteManagedVdisk.handleUnlockRequest              ldc.i4 0x40020011 seg000:2E41D Ardence.CRemoteManagedVdisk.handleCheckRequest              ldc.i4 0x40020015 seg000:2E586 Ardence.CRemoteManagedVdisk.handleCheckRequest              ldc.i4 0x40020015 seg000:2E69D Ardence.CRemoteManagedVdisk.handleIsLockedRequest              ldc.i4 0x40020013 seg000:2E91D Ardence.CRemoteManagedVdisk.handleReleaseAllLocksRequest              ldc.i4 0x40020012 seg000:2EC5D Ardence.CRemoteManagedVdisk.handleGetLockInfoRequest              ldc.i4 0x40020014 seg000:2EFED Ardence.CRemoteManagedVdisk.handleSetFooterRequest              ldc.i4 0x40020003 seg000:2F27D Ardence.CRemoteManagedVdisk.handleSetHeaderRequest              ldc.i4 0x40020001 seg000:2F50D Ardence.CRemoteManagedVdisk.handleSetBootRecordRequest              ldc.i4 0x40020005 seg000:2F9DD Ardence.CRemoteManagedVdisk.handleCheckFreeSpaceRequest              ldc.i4 0x40020016 seg000:2FB50 Ardence.CRemoteManagedVdisk.handleCheckFreeSpaceRequest              ldc.i4 0x40020016 seg000:2FC6D Ardence.CRemoteManagedVdisk.handleCheckSidecarRequest              ldc.i4 0x40020017 seg000:2FEB9 Ardence.CRemoteManagedVdisk.handleCheckSidecarRequest              ldc.i4 0x40020017 seg000:2FFCD Ardence.CRemoteManagedVdisk.handleDeleteDeviceDiskCacheFile              ldc.i4 0x40020018 

It's quite likely there are more crashes lurking in the code base, so fuzzing out a few more is left as an exercise to the reader.

When Hashes Collide

It's not often one module references four different CVE's across two different web technologies, but this week's update features just that: the Hashtable Collisions module submitted by Christian Mehlmauer, which incorporates his work along with Alexander Klink, Julian Waelde, Scott A. Crosby, Dan S. Wallach, and Krzysztof Kotowicz. The most complete reference about this vulnerability can be found over on oCERT, but the short story is, this module exercises an "algorithmic complexity" vulnerability with the way some (most) web application frameworks generate hash tables based on POST requests. Ultimately, vulnerable sites can end up eating hours of CPU time in the face of just a few requests, making for a classical asymmetric DoS condition. While this module may not have a lot of use in the course of a normal penetration testing engagement, it illustrates the kind of nifty research avenues that Metasploit modules can lend themselves to.

Rails Version Shuffle

As you may or may not know, both Metasploit Framework and Metasploit Pro both ship with Ruby on Rails as a core component. This last week, there was a SQL injection vulnerability announced that affects versions prior to 3.2.4. Although a code review showed that none of the Metasploit products were affected by the vulnerability, we updated to 3.2.4 with a better-safe-than-sorry attitude. Well, it turns out, 3.2.4 contained a show-stopper regression as well as the security fix. Given that we're not vulnerable to begin with, we've rolled back to 3.2.2 until we get a chance to test 3.2.5 more thoroughly (once bitten and all).

So, for those of you who track Metasploit changes via SVN or GitHub, that's why we've been shuffling around our Rails versions this week. Sorry for the commit spam!

Other New Modules with Links to our Exploit Database (DB)

Availability

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

For additional details on what's changed and what's current, please see the most excellent release notes.