Last updated at Thu, 11 Jan 2024 20:57:20 GMT
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.
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)
- pcAnywhere Login Scanner by TheLightCosine bruteforces pcAnywhere installations
- S40 0.4.2 CMS Directory Traversal Vulnerability by sinn3r and Osirys exploits OSVDB-82469
- Log1 CMS writeInfo() PHP Code Injection) by sinn3r, Adel SBM, and EgiX exploits CVE-2011-4825
- PHP Volunteer Management System v1.0.2 Arbitrary File Upload Vulnerability by sinn3r and Ashoo exploits OSVDB-82391
- Apache Struts <= 2.2.1.1 Remote Command Execution by sinn3r, juan vazquez, Andreas Nusser, and Johannes Dahse exploits CVE-2012-0391
- GIMP script-fu Server Buffer Overflow by juan vazquez and Joseph Sheridan exploits CVE-2012-2763
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.