Nytro

Eu nu fac afaceri cu nimeni, puteai sa ma intrebi daca am avut vreo treaba cu el. Asteptam si un raspuns din partea lui, poate are vreo scuza. PS: Acum am vazut: Total posts: 1 Nu suntem nebuni cand cerem minim 50 de posturi pentru postat la Market. Nici nu ma obosesc sa ii dau ban pentru asta.

Cel mai cunoscut site de seriale piratate din România a fost închis de Poli?ie de Vlad Andriescu Domeniul de internet vplay.ro, unde exista unul dintre cele mai mari platforme de filme piratate din România a fost închis de Poli?ia Român?. Potrivit hotnews.ro, Institutul Na?ional de Cercetare în Informatic?, care administreaz? domeniile de internet .ro a suspendat domeniul vplay.ro, dup? o sesizare a Poli?iei. Aceasta se referea la un clip de pornografie infantil? care nu putea fi îndep?rtat de pe site, potrivit lui Eugen St?icu?, ?eful departamentului RoTLD din cadrul ICI. Domeniul vplay.ro este de?inut de o persoan? fizic? din Ucraina, c?ruia Poli?ia i-a cerut îndep?rtarea con?inutului de pe site. "În cazule de pornografie infantil? ?i în cazurile de phising se ac?ioneaz? imediat. Poli?ia a contactat ?i autorit??ile din ucraina, dar întrucât nu au primit un r?spuns, ne-a cerut s? t?iem accesul pân? la rezolvarea investiga?iilor cu partea ucrainean?", a decalrat St?icu? pentru hotnews.ro. vplay.ro a fost înregistrat prin Hostway în 2009, dar nu a fost g?zduit de firma de hosting ?i servere din Bucure?ti. VPlay era considerat? cea mai mare platform? de filme piratate de pe internetul românesc. Utilizatorii g?seau aici seriale de la televiziunile americane. Con?inutul site-ului era unul pus acolo ilegal, dar autorit??ile nu au putut ancheta cine se afl? în spatele platformei, deoarece era înregistrat? în afara României. "Mai exist? ?i alte cazuri în curs de anchet? privind site-uri care ar difuza con?inut protejat de drepturi de autor f?r? a avea acordul de?in?torilor acelor drepturi", au mai spus oficialii Poli?iei. Sursa: Cel mai cunoscut site de seriale piratate din România a fost închis de Poli?ie | adevarul.ro mai cunoscut site de seriale piratate din România a fost închis de Poli?ie

Vin multe persoane de aici. Eu vin.

Spui asta pentru ca l-ai vazut acum mult timp sau pentru ca nu e FullHD? E ceva ce ar trebui vazut de catre toti tinerii cu aspiratii de programator/hacker din ziua de azi.

Introducing Enhanced Mitigation Experience Toolkit (EMET) 4.1 swiat 11 Nov 2013 4:57 PM In June 2013, we released EMET 4.0 and customer response has been fantastic. Many customers across the world now include EMET as part of their defense-in-depth strategy and appreciate how EMET helps businesses prevent attackers from gaining access to computers systems. Today, we’re releasing a new version, EMET 4.1, with updates that simplify configuration and accelerate deployment. EMET anticipates the most common techniques adversaries might use and shields computer systems against those security threats. EMET uses security mitigation technologies such as Data Execution Prevention (DEP), Mandatory Address Space Layout Randomization (ASLR), Structured Exception Handler Overwrite Protection (SEHOP), Export Address Table Access Filtering (EAF), Anti-ROP, and SSL/TLS Certificate Trust Pinning, to help protect computer systems from new or undiscovered threats. EMET can also protect legacy applications or third party line of business applications where you do not have access to the source code. Today’s EMET 4.1 release includes new functionality and updates, such as: Updated default protection profiles, Certificate Trust rules, and Group Policy Object configuration. Shared remote desktop environments are now supported on Windows servers where EMET is installed. Improved Windows Event logging mechanism allows for more accurate reporting in multi-user scenarios. Several application-compatibility enhancements and mitigation false positive reporting. EMET built by Microsoft Security Research Center (MSRC) engineering team, brings the latest in security science to your organization. While many EMET users exchange feedback and ideas at TechNet user forums, a less known fact is that Microsoft Premier Support options are also available for businesses that deploy EMET within their enterprise. Many of our customers deploy EMET - at scale - through the Microsoft System Center Configuration manager and apply enterprise application, user and accounts rules through Group Policy. EMET works well with the tools and support options our customers know and use today. As we continue to advance EMET, we welcome your feedback on what you like and what additional features would help in protecting your business. If you are attending RSA Conference at San Francisco, or the Blackhat Conference in Las Vegas next year, be sure to stop by the Microsoft booth, and share your feedback with us. We look forward to hearing from you. The Microsoft EMET Team Microsoft Security Response Center (MSRC) Engineering Sursa: Introducing Enhanced Mitigation Experience Toolkit (EMET) 4.1 - Security Research & Defense - Site Home - TechNet Blogs

Security Advisory 2868725: Recommendation to disable RC4 swiat 12 Nov 2013 10:00 AM In light of recent research into practical attacks on biases in the RC4 stream cipher, Microsoft is recommending that customers enable TLS1.2 in their services and take steps to retire and deprecate RC4 as used in their TLS implementations. Microsoft recommends TLS1.2 with AES-GCM as a more secure alternative which will provide similar performance. Background Developed in 1987 by Ron Rivest, RC4 was one of the earliest stream ciphers to see broad use. It was initially used in commercial applications and was faster than alternatives when implemented in software and over time became pervasive because of how cheap, fast and easy it was to implement and use. Stream vs. Block At a high level, a stream cipher generates a pseudorandom stream of bits of the same length as the plaintext and then XOR's the pseudorandom stream and the plaintext to generate the cipher text. This is different than a block cipher, which chunks plaintext into separate blocks, pads the plaintext to the block size and encrypts the blocks. A History of Issues RC4 consists of a Key Scheduling Algorithm (KSA) which feeds into a Psuedo-Random Generator (PRG), both of which need to be robust for use of the cipher to be considered secure. Beyond implementation issues with RC4, such as, document encryption and the 802.11 WEP implementation, there are some significant issues that exist in the KSA which lead to issues in the leading bytes of PRG output. By definition, a PRG is only secure if the output is indistinguishable from a stream of random data. In 2001, Mantin and Shamir < CiteSeerX — A Practical Attack on Broadcast RC4 > found a significant bias in RC4 output, specifically that the second byte of output would be ‘0’. Attacks and research have evolved since 2001, the work of T. Isobe, T. Ohigashi, Y. Watanabe, M. Morii of Kobe University in Japan is especially significant when evaluating the risk of RC4 use. Their findings show additional, significant bias in the first 257 bytes of RC4 output as well as practical plaintext recovery attacks on RC4. The plaintext recovery attacks show a passive attacker collecting ciphertexts encrypted with different keys. Given 2^32 ciphertexts with different keys, the first 257 bytes of the plaintext are recovered with a probability of more than .5 < http://home.hiroshima- u.ac.jp/ohigashi/rc4/Full_Plaintext_Recovery%20Attack_on%20Broadcast_RC4_pre-proceedings.pdf >. Since early RC4 output cannot be discarded from SSL/TLS implementations without protocol-level changes, this attack demonstrates the practicality of attacks against RC4 in common implementations. Internet Use of RC4 One of the first steps in evaluating the customer impact of new security research and understanding the risks involved has to do with evaluating the state of public and customer environments. Using a sample size of five million sites, we found that 58% of sites do not use RC4, while approximately 43% do. Of the 43% that utilize RC4, only 3.9% require its use. Therefore disabling RC4 by default has the potential to decrease the use of RC4 by over almost forty percent. Microsoft's Response Today's update provides tools for customers to test and disable RC4. The launch of Internet Explorer 11 (IE 11) and Windows 8.1 provide more secure defaults for customers out of the box. IE 11 enables TLS1.2 by default and no longer uses RC4-based cipher suites during the initial TLS handshake. More detailed information about these changes can be found in the IE 11 blog <http://blogs.msdn.com/b/ie/archive/2013/11/12/IE11-Automatically-Makes-Over-40-of-the-Web- More-Secure-While-Making-Sure-Sites-Continue-to-Work/> For application developers, we have implemented additional options in SChannel which allow for its use without RC4. Today's Updates Today's update KB 2868725provides support for the Windows 8.1 RC4 changes on Windows 7, Windows 8, Windows RT, Server 2008 R2, and Server 2012. These updates will not change existing settings and customers must implement changes (which are detailed below) to help secure their environments against weaknesses in RC4. Call to Action Microsoft strongly encourages customers to evaluate, test and implement the options for disabling RC4 below to increase the security of clients, servers and applications. Microsoft recommends enabling TLS1.2 and AES-GCM. Clients and servers running on Windows with custom SSL/TLS implementations, such as, Mozilla Firefox and Google Chrome will not be affected by changes to SChannel. How to Completely Disable RC4 Clients and Servers that do not wish to use RC4 ciphersuites, regardless of the other party's supported ciphers, can disable the use of RC4 cipher suites completely by setting the following registry keys. In this manner any server or client that is talking to a client or server that must use RC4, can prevent a connection from happening. Clients that deploy this setting will not be able to connect to sites that require RC4 while servers that deploy this setting will not be able to service clients that must use RC4. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128] "Enabled"=dword:00000000 How Other Applications Can Prevent the Use of RC4 based Cipher Suites RC4 is not turned off by default for all applications. Applications that call into SChannel directly will continue to use RC4 unless they opt-in to the security options. Applications that use SChannel can block the use of RC4 cipher suites for their connections by passing the SCH_USE_STRONG_CRYPTO flag to SChannel in the SCHANNEL_CRED structure. If compatibility needs to be maintained, then they can also implement a fallback that does not pass this flag. Microsoft recommends that customers upgrade to TLS1.2 and utilize AES-GCM. On modern hardware AES-GCM has similar performance characteristics and is a much more secure alternative to RC4. - William Peteroy, MSRC I would like to thank the Windows, Internet Explorer and .NET teams for their work in this effort as well as Ali Rahbar and Suha Can of the MSRC Engineering team for their hard work and input. I would also like to thank Matthew Green for the excellent write-ups he has for this and other applied cryptography issues on his blog. Sursa: Security Advisory 2868725: Recommendation to disable RC4 - Security Research & Defense - Site Home - TechNet Blogs

Security Advisory 2880823: Recommendation to discontinue use of SHA-1 swiat 12 Nov 2013 10:00 AM Microsoft is recommending that customers and CA’s stop using SHA-1 for cryptographic applications, including use in SSL/TLS and code signing. Microsoft Security Advisory 2880823 has been released along with the policy announcement that Microsoft will stop recognizing the validity of SHA-1 based certificates after 2016. Background Secure Hashing Algorithm 1 (SHA-1) is a message digest algorithm published in 1995 as part of NIST’s Secure Hash Standard. A hashing algorithm is considered secure only if it produces unique output for any given input and that output cannot be reversed (the function only works one-way). Since 2005 there have been known collision attacks (where multiple inputs can produce the same output), meaning that SHA-1 no longer meets the security standards for a producing a cryptographically secure message digest. For attacks against hashing algorithms, we have seen a pattern of attacks leading up to major real-world impacts: Short history of MD5 Attacks Source: Marc Stevens, Cryptanalysis of MD5 and SHA-1 1992: MD5 published 1993: Pseudo-collision attack 2004: Identical-prefix collision found in 2^40 calls 2006: chosen-prefix collision found in 2^49 calls 2009: identical-prefix and chosen prefix optimized to 2^16 and 2^39 calls respectively, Rouge CA practical attacks implemented It appears that SHA-1 is on a similar trajectory: 1995: SHA-1 published 2005: SHA-1 collision attack published in 2^69 calls 2005: NIST recommendation for movement away from SHA-1 2012: Identical-prefix collision 2^61 calls presented 2012: Chosen-prefix collision 2^77.1 calls presented Current Issues Microsoft is actively monitoring the situation and has released a policy for deprecating SHA-1 by 2016. Microsoft Recommendations Microsoft recommends that Certificate Authorities (CA’s) stop using SHA-1 for digital signatures and that consumers request SHA-2 certificates from CA’s. Microsoft Policy Microsoft has publicized a new policy that calls for users and CA’s to stop using SHA1-based certificates by 2016. - William Peteroy, MSRC I would like to thank the Microsoft PKI team as well as Ali Rahbar of the MSRC Engineering team for their hard work and input. Sursa: Security Advisory 2880823: Recommendation to discontinue use of SHA-1 - Security Research & Defense - Site Home - TechNet Blogs

File Analyzer analyses the behavior of potential malicious executables such as *.exe, *.dll and *.sys files. It's built on top of Joe Sandbox Desktop. Executables are analyzed with a technology called Hybrid Code Analysis (HCA). HCA combines dynamic and static program analysis into one powerful tool. Joe Sandbox Desktop uses over 300 behavior signatures to detect, classify and rate malicious behavior and artifacts. To find out more about Joe Sandbox Desktop go to: JOE SANDBOX DESKTOP - Next-Generation Sandbox for in-depth malware analysis!. http://www.file-analyzer.net/

CreateRemoteThread. Bypass Windows 7 Session Separation Internet is full of programmers' forums and those forums are full with questions about CreateRemoteThread Windows API function not working on Windows 7 (when trying to inject a DLL). Those posts made by lucky people, somehow, redirect you to the MSDN page dedicated to this API, which says: "Terminal Services isolates each terminal session by design. Therefore, CreateRemoteThread fails if the target process is in a different session than the calling process." and, basically, means - start the process from your injector as suspended, inject your DLL and then resume the process' main thread. This works... Most of the time... But sometimes you really need to inject your code into a running process. Isn't there a way to do that? Well, there is. As a matter of fact, it is so easy, that I decided not to attach my source code to this article (mainly, because I am too lazy to make it look readable ). It appears to be that I am not the only one lazy here , so I have uploaded the source code. Let me start as usual, with a note for nerds in order to avoid meaningless comments and stupid discussions. The code provided within the article is for example purposes only. Error checks have been omitted on purpose. Yes, there may be another, probably even better, way of doing this. No, manual DLL mapping is not better unless you have plenty of time and nothing to do with it. All others, let's get to business Opening the Victim Process This is the easiest part. At this stage you will see whether you are able to inject your code or not (in case of a system process, for example). Nothing unusual here - you simply invoke the good old OpenProcess API [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwDesiredAccess, [I][COLOR=purple]/* in our case PROCESS_ALL_ACCESS */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]BOOL[/COLOR][/B] bInheritHandle, [I][COLOR=purple]/* no need, so FALSE */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwProcessId [I][COLOR=purple]/* self explanatory enough */[/COLOR][/I][/FONT] [FONT=Courier New]);[/FONT][FONT=Courier New][B][COLOR=blue]HANDLE[/COLOR][/B] [B]WINAPI[/B] OpenProcess([/FONT] which opens the process specified by dwProcessId and returns a handle to that process, unless, you have no sufficient rights to access that process. Reading the Shellcode What you usually see in the examples of shellcode over the internet, is an unsigned char array of hexadecimal values somewhere in the C code. Helps to keep the amount of files smaller, but is not really comfortable to deal with. I decided to store the shellcode in a separate binary file, produced with FASM (Flat Assembler): [FONT=Courier New] [I][COLOR=purple]; offset of the LoadLibraryA address within the shellcode[/COLOR][/I][/FONT] [FONT=Courier New] dd [B]func[/B][/FONT] [FONT=Courier New] [I][COLOR=purple]; save all registers[/COLOR][/I][/FONT] [FONT=Courier New] push [COLOR=blue]eax ebx ecx edx ebp edi esi[/COLOR][/FONT] [FONT=Courier New] [COLOR=purple]; get your EIP[/COLOR][/FONT] [FONT=Courier New] call [B]next[/B][/FONT] [FONT=Courier New][B]next[/B]:[/FONT] [FONT=Courier New] pop [COLOR=blue]eax[/COLOR][/FONT] [FONT=Courier New] mov [COLOR=blue]ebx[/COLOR], [COLOR=blue]eax[/COLOR][/FONT] [FONT=Courier New] [COLOR=purple][I]; get the address of the DLL name[/I][/COLOR][/FONT] [FONT=Courier New] mov [COLOR=blue]eax[/COLOR], [B]string[/B] - [B]next[/B][/FONT] [FONT=Courier New] [I][COLOR=purple]; do this to avoid possible negative values (due to sign extend)[/COLOR][/I][/FONT] [FONT=Courier New] movzx [COLOR=blue]eax[/COLOR], [COLOR=blue]al[/COLOR][/FONT] [FONT=Courier New] add [COLOR=blue]eax[/COLOR], [COLOR=blue]ebx[/COLOR][/FONT] [FONT=Courier New] [I][COLOR=purple]; pass it to the LoadLibraryA API[/COLOR][/I][/FONT] [FONT=Courier New] push [COLOR=blue]eax[/COLOR][/FONT] [FONT=Courier New] [COLOR=purple][I]; get the address of the LoadLibraryA function[/I][/COLOR][/FONT] [FONT=Courier New] mov [COLOR=blue]eax[/COLOR], [B]func[/B] - [B]next[/B][/FONT] [FONT=Courier New] movzx [COLOR=blue]eax[/COLOR], [COLOR=blue]al[/COLOR][/FONT] [FONT=Courier New] add [COLOR=blue]eax[/COLOR], [COLOR=blue]ebx[/COLOR][/FONT] [FONT=Courier New] mov [COLOR=blue]eax[/COLOR], [[COLOR=blue]eax[/COLOR]][/FONT] [FONT=Courier New] [I][COLOR=purple]; call LoadLibraryA[/COLOR][/I][/FONT] [FONT=Courier New] call [COLOR=blue]eax[/COLOR][/FONT] [FONT=Courier New] [I][COLOR=purple]; restore registers[/COLOR][/I][/FONT] [FONT=Courier New] pop [COLOR=blue]esi edi ebp edx ecx ebx eax[/COLOR][/FONT] [COLOR=purple][FONT=Courier New][I] ; return[/I][/FONT][/COLOR] [FONT=Courier New] ret[/FONT] [FONT=Courier New][B]func[/B] dd 0x12345678 [COLOR=purple][I]; placeholder for the address[/I][/COLOR][/FONT] [FONT=Courier New][B]string[/B]:[/FONT][FONT=Courier New][B]use32[/B][/FONT] Compiling this code with FASM.EXE will produce a raw binary file, where all offsets are 0 - based. There are some parts in the code above, that may require some additional explanation (for example, why does it not end with ExitThread()). I am aware of this and I will provide you with the explanation a little bit later. For now, allocate an unsigned char buffer for your shellcode. Make this buffer large enough to contain the shellcode and the name of the DLL (my assumption is, that you passed that name as a command line parameter to your injector). with it's terminating zero. Once you have read the shellcode into that buffer - append the name of the DLL (which may be a full path to the DLL) to the end of the shellcode with, for example, memcpy() function. Half done with it. Now we still have to "tell" the shellcode where the LoadLibraryA API function is located in memory. Fortunately, the load address randomization in Windows is far from being perfect (addresses of loaded modules may vary between subsequent reboots, but are the same for all processes). This means that, just as in usual DLL injection, we obtain the address of this API in our process by calling good old GetProcAddress(GetModuleHandleA("kernel32.dll"), "LoadLibraryA") and save it to the "func" variable of the shellcode. Due to the fact that our shellcode may vary in size from time to time (that depends on the needs), we saved the offset to that variable in the first four bytes of the shellcode, which eliminates the need to hardcode the offset. Simply do the following: [FONT=Courier New]*([B][COLOR=blue]unsigned int[/COLOR][/B]*)(shellcode_ptr + *([B][COLOR=blue]int[/COLOR][/B]*)(shellcode_ptr)) = ([COLOR=blue][B]unsigned int[/B][/COLOR])LoadLibraryA_address;[/FONT] Our shellcode is ready now. "Create remote thread" without CreateRemoteThread() As the title of this paragraph suggests - we are not going to use the CreateRemoteThread(). In fact, we are not going to create any thread in the victim process (well, the injected DLL may, but the shellcode won't). Code Injection Surely, we need to move our shellcode into the victim process' address space in order to load or library. We are doing it in the same manner, as we would copy the name of the DLL in regular DLL injection procedure: Allocate memory in the remote process with LPVOID WINAPI VirtualAllocEx( HANDLE hProcess, /* the handle we obtained with OpenProcess */ LPVOID lpAddress, /* preferred address; may be NULL */ SIZE_T dwSize, /* size of the allocation in bytes */ DWORD flAllocationType, /* MEM_COMMIT */ DWORD flProtect /* PAGE_EXECUTE_READWRITE */ ); This function returns the address of the allocation in the address space of the victim process or NULL if it fails. Copy the shellcode into the buffer we've just allocated in the address space of the victim process: BOOL WINAPI WriteProcessMemory( HANDLE hProcess, /* same handle as above */ LPVOID lpBaseAddress, /* address of the allocation */ LPCVOID lpBuffer, /* address of the local buffer with the shellcode */ SIZE_T nSize, /* size of the shellcode together with the appended NULL-terminated string */ SIZE_T *lpNumberOfBytesWritten /* if this is zero - check your code */ ); If the return value of this function is non zero - we have successfully copied our shellcode into the victim process' address space. It may also be a good idea to check the value returned in the lpNumberOfBytesWritten. Make It Run So, we have copied our shell code. The only thing left, is to make it run, but we cannot use the CreateRemoteThread() API... Solution is a bit more complicated. First of all, we have to suspend all threads of the victim process. In general, suspending only one thread is enough, but, as we cannot know for sure what is going on there, we should suspend them all. There is no specific API that would provide us with the list of threads for a specified process, instead, we have to create a snapshot with CreateToolhelp32Snapshot, which provides us with the list of all currently running threads of all processes running in the system: [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwFlags, [I][COLOR=purple]/* TH32CS_SNAPTHREAD = 0x00000004 */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] th32ProcessID [COLOR=purple][I]/* in this case may be 0 */[/I][/COLOR][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][FONT=Courier New][COLOR=blue][/COLOR][/FONT][I][FONT=Courier New][COLOR=blue][/COLOR][/FONT][/I][B][B][B][I][FONT=Courier New][B][COLOR=blue]HANDLE[/COLOR][/B] [B]WINAPI[/B] CreateToolhelp32Snapshot([/FONT] This function returns the handle to the snapshot, which contains information on all present threads. Once we have this, we "iterate through the list" with Thread32First and Thread32Next API functions: [FONT=Courier New] [B][COLOR=blue]HANDLE[/COLOR][/B] hSnapshot, [I][COLOR=purple]/* the handle to the snapshot */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]LPTHREADENTRY32[/COLOR][/B] lpte [COLOR=purple][I]/* pointer to the THREADENTRY32 structure */[/I][/COLOR][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][I][FONT=Courier New][/FONT][/I][FONT=Courier New][/FONT][FONT=Courier New][COLOR=blue][/COLOR][/FONT][I][FONT=Courier New][COLOR=blue][/COLOR][/FONT][/I][B][B][B][I][FONT=Courier New][B][COLOR=blue]BOOL[/COLOR][/B] [B]WINAPI[/B] Thread32First([/FONT] The Thread32Next has the same prototype as Thread32First. [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwSize; [I][COLOR=purple]/* size of this struct; you have to initialize this field before use */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] cntUsage; [/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] th32ThreadID; [I][COLOR=purple]/* use this value to open thread for suspension */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] th32OwnerProcessID; [COLOR=purple][I]/* compare this value against the PID of the victim [/I][/COLOR][/FONT] [FONT=Courier New][COLOR=purple][I] to filter out threads of other processes */[/I][/COLOR][/FONT] [FONT=Courier New] [B][COLOR=blue]LONG[/COLOR][/B] tpBasePri;[/FONT] [FONT=Courier New] [B][COLOR=blue]LONG[/COLOR][/B] tpDeltaPri;[/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwFlags;[/FONT] [FONT=Courier New]} [B][COLOR=blue]THREADENTRY32[/COLOR][/B], [B][COLOR=blue]*PTHREADENTRY32[/COLOR][/B];[/FONT][/I][/B][/B][/B][B][B][B][I][FONT=Courier New][COLOR=blue]typedef[/COLOR] [COLOR=blue]struct[/COLOR] [B]tagTHREADENTRY32[/B]{[/FONT] For each THREADENTRY32 with matching th32OwnerProcessID, open it with OpenThread() and suspend with SuspendThread: [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwDesiredAccess, [I][COLOR=purple]/* THREAD_ALL_ACCESS */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]BOOL[/COLOR][/B] bInheritHandle, [I][COLOR=purple]/* FALSE */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]DWORD[/COLOR][/B] dwThreadId [COLOR=purple][I]/* th32ThreadID field of THREADENTRY32 structure */[/I][/COLOR][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][FONT=Courier New][COLOR=blue][/COLOR][/FONT][I][FONT=Courier New][COLOR=blue][/COLOR][/FONT][/I][B][B][B][I][FONT=Courier New][B][COLOR=blue]HANDLE[/COLOR][/B] [B]WINAPI[/B] OpenThread([/FONT] and [FONT=Courier New] [B][COLOR=blue]HANDLE[/COLOR][/B] hThread, [COLOR=purple][I]/* Obtained by OpenThread() */[/I][/COLOR][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][B][B][B][I][FONT=Courier New][B][COLOR=blue]DWORD[/COLOR][/B] [B]WINAPI[/B] SuspendThread([/FONT] Don't forget to CloseHandle(openedThread) Take the first thread, once it is opened (actually, you can do that with any thread that belongs to the victim process) and suspended, and get its CONTEXT (see "Community Additions" here) using the GetThreadContext API: [FONT=Courier New] [B][COLOR=blue]HANDLE[/COLOR][/B] hThread, [I][COLOR=purple]/* handle to the thread */[/COLOR][/I][/FONT] [FONT=Courier New] [B][COLOR=blue]LPCONTEXT[/COLOR][/B] lpContext [I][COLOR=purple]/* pointer to the CONTEXT structure */[/COLOR][/I][/FONT] [FONT=Courier New]);[/FONT][/I][/B][/B][/B][B][B][B][I][FONT=Courier New][B][COLOR=blue]BOOL[/COLOR][/B] [B]WINAPI[/B] GetThreadContext([/FONT] Now, when all the threads of the victim process are suspended, we are may do our job. The idea is to redirect the execution flow of this thread to our shellcode, but make it in such a way, that the shellcode would return to where the suspended thread currently is. This is not a problem at all, as we have the CONTEXT of the thread. The following code does that just fine: [COLOR=purple][FONT=Courier New][I]/* "push" current EIP of the thread onto its stack, so that the ret instruction in the shellcode returns the execution flow to this address (which is somewhere in WaitForSingleObject for suspended threads) */[/I][/FONT][/COLOR] [FONT=Courier New]ctx.Esp -= [COLOR=blue]sizeof[/COLOR]([COLOR=blue][B]unsigned int[/B][/COLOR]);[/FONT] [FONT=Courier New]WriteProcessMemory(victimProcessHandle, [/FONT] [FONT=Courier New] ([B][COLOR=blue]LPVOID[/COLOR][/B])ctx.Esp, [/FONT] [FONT=Courier New] ([COLOR=blue][B]LPCVOID[/B][/COLOR])&ctx.Eip,[/FONT] [FONT=Courier New] [COLOR=blue]sizeof[/COLOR]([COLOR=blue][B]unsigned int[/B][/COLOR]),[/FONT] [FONT=Courier New] &bytesWritten);[/FONT] [COLOR=purple][FONT=Courier New][I]/* Set the EIP to our injected shellcode; do not forget to skip the first four bytes */[/I][/FONT][/COLOR] [FONT=Courier New]ctx.Eip = remoteAddress + [COLOR=blue]sizeof[/COLOR]([COLOR=blue][B]unsigned int[/B][/COLOR]);[/FONT] [FONT=Courier New] [/FONT][/I][/B][/B][/B][B][B][B][I] Almost there. All we have to do now, is resume the previously suspended threads in the same manner (iterating with Thread32First and Thread32Next with the same snapshot handle). Don't forget to close the victim process' handle with CloseHandle() Shellcode After all this, the execution flow in the selected thread of the victim process reaches our shellcode, which source code should be pretty clear now. It simply calls the LoadLibraryA() API function with the name/path of the DLL we want to inject. One important note - it is a bad practice to do anything "serious" inside the DllMain() function. My suggestion is - create a new thread in DllMain() and do all the job there, so that it may return safely. Hope this article was helpful. Have fun injecting and see you at the next. Posted by Alexey Lyashko at 4:36 AM Sursa: System Programming: CreateRemoteThread. Bypass Windows 7 Session Separation

Se duc pe pula si rusii...

What can I do for Mozilla? http://www.whatcanidoformozilla.org/

Unmasking a Spoofed MAC Address Certain Atheros wireless drivers do not properly update the MAC address when changed (spoofed) by a user. This allows an active attacker to retrieve the original MAC address. In short, spoofing your MAC address does not always hide the original MAC address. Background While working on the ath9k_htc driver (used by Atheros USB WiFi dongles) I noticed the driver did not properly set a spoofed MAC address. Though the device appears to use the newly assigned MAC address correctly, the flaw allows an attacker capable of injecting packets towards the target to uncover the original MAC address. The cause of the problem lies in how the driver and hardware implement Multiple Virtual Interface (VIF) support. Using this technology a single wireless chip can listen on multiple MAC addresses. Because sending an acknowledgement to correctly received packets is done in hardware, a question that arises is how the wireless chip can quickly determine whether a wireless packet was destined for it. At first you'd think there must be some method to give the hardware a (possibly fixed length) list of MAC addresses to listen on. However, some devices uses a different strategy (and in particular Atheros devices uses this method). Their strategy is the following: the wireless chip has a register which contains the "main" hardware MAC address (mainmac), and a register containing a mask (macmask). Given an incoming frame destined for a particular mac (incmac), it sends an ACK and accepts the frame if and only if: (mainmac & macmask) == (incmac & macmask). You can see that macmask determines which bits of incmask (MAC of the packet being received) have to match those of mainmac. Essentially the macmask represents the locations where the bits of all the virtual MAC addresses are identical to the "main" hardware MAC address (mainmac). To clarify, consider a device having two virtual interfaces, one with MAC address 72:40:a2:3f:65:5a and another one with address 8e:8e:95:cd:90:4e. In binary these MAC addresses are: 01110010 : 01000000 : 10100010 : 00111111 : 01100101 : 01011010 (72:40:a2:3f:65:5a) 10001110 : 10001110 : 10010101 : 11001101 : 10010000 : 01001110 (8e:8e:95:cd:90:4e) Now, macmask should consist of the bits where both these MAC addresses are the same (mathematically that's the negation of the XOR). In our example the mask would be: 00000011 : 00110001 : 11001000 : 00001101 : 00001010 : 11101011 (03:31:c8:0d:0a:eb) So the wireless chip can pick either 72:40:a2:3f:65:5a or 8e:8e:95:cd:90:4e as its main MAC address, and then set the mask to 03:31:c8:0d:0a:eb. Frames sent to either of these MAC addresses will now be accepted and acknowledged. For more details see the comments in the atheros driver source file. Unfortunately this technique has the side effect that the wireless chipset now listens on more MAC addresses then we really want, as not all bits of incoming frames are checked! Vulnerability Details When a MAC address is spoofed the driver does not simply update the mainmac register. Instead the mainmac register will still contain the original MAC address, and macmask will contain the bits where the original and spoofed MAC agree (see previous section). The wireless chip will acknowledge frames sent to the spoofed MAC addresses, and the operating system will include the spoofed MAC address in all packets, so everything will seem to work properly. Unfortunately this method allows an attacker to uncover the original MAC address bit by bit (given the spoofed MAC address). Specifically we can determine the value of any bit of the original MAC address as follows: Flip the bit in the spoofed MAC address and send a packet to the modified MAC address. We now have two cases: The device replies with an ACK: This means the mask for this bit is zero, thus the bit in the spoofed MAC address was different than the original MAC address. Device doesn't reply: This means the mask for this bit is one, so the bit we are guessing was identical to the bit in the spoofed MAC By doing this for each bit, we eventually learn the complete original MAC address. The vulnerability has been successfully exploited against AR7010 and AR9271 chipsets (which use the ath9k_htc driver) under following operating systems: Debian 7.2.0 amd64 and i386 Kali 1.0.5 amd64 and i386 Ubuntu 13.10 amd64 and i386 The ath5k, ath9k, and ath10k drivers might also be vulnerable, unfortunately I cannot perform tests against these drivers because I do not have the appropriate hardware. Other drivers also capable of creating multiple virtual interfaces with different MAC addresses, on a single device, might also be susceptible to the same vulnerability (so feel free test your device and post results). Exploit A proof of concept has been implemented in python using scapy. Given a MAC address that you suspect to be spoofed the tool will attempt to uncover the original MAC address. In case the tool returns the same MAC address as you entered, it means the target is not susceptible to the attack, or that the target is using the default MAC address of the device. Patch We are not yet aware of an official patch (the ath9k-devel mailing list has been notified of this issue). Final Remarks Though spoofing a MAC address can be done securely by simply updating mainmac, an attacker can use the same technique to learn that two virtual MAC addresses actually belong to the same user. So if you put up several virtual interfaces (possibly with random MAC addresses) they can be easily linked back together (again, that's if your device uses a method similar to the one described above). This flaw is inherent to usage of macmask and, at first sight, seems difficult to fix. Geplaatst door Mathy op 16:24 Sursa: Mathy Vanhoef: Unmasking a Spoofed MAC Address

[h=1]Rust a safe, concurrent, practical language[/h] Rust is a curly-brace, block-structured expression language. It visually resembles the C language family, but differs significantly in syntactic and semantic details. Its design is oriented toward concerns of “programming in the large”, that is, of creating and maintaining boundaries – both abstract and operational – that preserve large-system integrity, availability and concurrency. It supports a mixture of imperative procedural, concurrent actor, object-oriented and pure functional styles. Rust also supports generic programming and metaprogramming, in both static and dynamic styles. http://www.rust-lang.org/

[h=1]Beleth[/h] Beleth is a multi-threaded asynchronous SSH password auditing tool written in C. There are plenty of other password cracking programs out there that can do the job, but I wanted something small, fast, and custom as a proof of concept. After preliminary tests, Beleth was able to outperform both THC-Hydra and Ncrack. Beleth also allows you to run a remote command after successfully cracking a password. Pull requests are welcome as the development is an ongoing process. For a more in depth look at the code, check out Chokepoint development blog. [h=2]Disclaimer[/h] Beleth is a password auditing tool and should not be run against anyone else's system without receiving proper permission first. By using this application on a live connection, you do so at your own risk. [h=2]Get the source[/h] Beleth is available on github and will continue to be updated with new features. The only library dependency is LibSSH2. Included with Beleth is the 2012 Top 25 most used passwords list. $ git clone https://github.com/chokepoint/Beleth.git $ cd beleth $ make $ ./beleth -h Usage: ./beleth [OPTIONS] -c [payload] Execute payload on remote server once logged in -h Display this help -l [threads] Limit threads to given number. Default: 10 -p [port] Specify remote port -t [target] Attempt connections to this server -u [user] Attempt connection using this username -v -v (Show attempts) -vv (Show debugging) -w [wordlist] Use this wordlist. Defaults to wordlist.txt $ ./beleth -t 127.0.0.1 -u root -w wordlist.txt -c 'uname -a' -l 15 +-----------------------------------------+ | Beleth | | www.chokepoint.net | +-----------------------------------------+ [*] Read 25 passwords from file. [*] Starting task manager [*] Spawning 15 threads [*] Starting attack on root@127.0.0.1:22 [*] Authentication succeeded (root:jesus@127.0.0.1:22) [*] Executing: uname -a [*] Linux eclipse 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1+deb7u1 i686 GNU/Linux [*] Cleaning up child processes. Sursa: Beleth - Security101 - Blackhat Techniques - Hacking Tutorials - Vulnerability Research - Security Tools

INTERPRETER EXPLOITATION: POINTER INFERENCE AND JIT SPRAYING ABSTRACT As remote exploits have dwindled and perimeter defenses have become the standard, remote client-side attacks are the next best choice for an attacker. Modern Windows operating systems have quelled the explosion of clientside vulnerabilities using mitigation techniques such as data execution prevention (DEP) and address space layout randomization (ASLR). This work will illustrate two novel techniques to bypass DEP and ASLR mitigations. These techniques leverage the attack surface exposed by the advanced script interpreters or virtual machines commonly accessible within the browser. The first technique, pointer inference, is used to find the memory address of a string of shellcode within the ActionScript interpreter despite ASLR. The second technique, JIT spraying, is used to write shellcode to executable memory by leveraging predictable behaviors of the ActionScript JIT compiler bypassing DEP. Future research directions and countermeasures for interpreter implementers are discussed. INTRODUCTION The difficulty in finding and exploiting a remote vulnerability has motivated attackers to devote their resources to finding and exploiting client side vulnerabilities. This influx of different client side attackers has pushed Microsoft to implement robust mitigation techniques to make exploiting these vulnerabilities much harder. Sotirov and Dowd [1] have described in detail each of the mitigation techniques and their default configurations on versions of Windows through Windows 7 RC. Their work shows some of the techniques available to bypass these protections and how the design choices made by Microsoft has influenced the details of these bypasses. One thing that stands out throughout this paper is how ripe a target the browser is for exploitation – the attacker can use multiple plugins, picking and choosing specific exploitable features, to set-up a reliable exploit scenario. The classic web browser, bursting at the seams with plug-ins, could not have been designed with more exploitation potential. It requires a robust parser to parse and attempt to salvage 6 versions of mark-up. With the advent of “Web 2.0”, a browser must now include a high performance scripting environment with the ability to rewrite those parsed pages dynamically. The library exposed to the scripting runtime continues to grow. Additionally, most browsers are now taking advantage of recent JIT and garbage collection techniques to speed up Javascript execution. All this attack surface and we haven’t begun to discuss the plug-ins commonly installed. Rich internet applications (RIAs) are not going away and Adobe currently maintains a hold over the market Download: http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Paper.pdf

Return-Oriented Rootkits: Bypassing Kernel Code Integrity Protection Mechanisms Abstract Protecting the kernel of an operating system against attacks, especially injection of malicious code, is an important factor for implementing secure operating systems. Several kernel integrity protection mechanism were proposed recently that all have a particular shortcoming: They cannot protect against attacks in which the attacker re-uses existing code within the kernel to perform malicious computations. In this paper, we present the design and implementation of a system that fully automates the process of constructing instruction sequences that can be used by an attacker for malicious computations. We evaluate the system on different commodity operating systems and show the portability and universality of our approach. Finally, we describe the implementation of a practical attack that can bypass existing kernel integrity protection mechanisms. 1 Introduction Motivation. Since it is hard to prevent users from running arbitrary programs within their own account, all modern operating systems implement protection concepts that protect the realm of one user from another. Furthermore, it is necessary to protect the kernel itself from attacks. The basis for such mechanisms is usually called reference monitor [2]. A reference monitor controls all accesses to system resources and only grants them if they are allowed. While reference monitors are an integral part of any of today’s mainstream operating systems, they are of limited use: because of the sheer size of a mainstream kernel, the probability that some system call, kernel driver or kernel module contains a vulnerability rises. Such vulnerabilities can be exploited to subvert the operating system in arbitrary ways, giving rise to so called rootkits, malicious software running without the user’s notice. Download: https://www.usenix.org/legacy/event/sec09/tech/full_papers/hund.pdf

Security Mitigations for Return-Oriented Programming Attacks Abstract With the discovery of new exploit techniques, new protection mechanisms are needed as well. Mitigations like DEP (Data Execution Prevention) or ASLR (Address Space Layout Randomization) created a significantly more difficult environment for vulnerability exploitation. Attackers, however, have recently developed new exploitation methods which are capable of bypassing the operating system’s security protection mechanisms. In this paper we present a short summary of novel and known mitigation techniques against return-oriented programming (ROP) attacks. The techniques described in this article are related mostly to x86-321 processors and Microsoft Windows operating systems. 1 Introduction In order to increase the security level of the operating system, Microsoft has implemented several mitigation mechanisms, such as DEP and ASLR. Data Execution Prevention (DEP) is a security feature that prohibits the application from executing code from non-executable memory area. To exploit a vulnerability, an attacker must find a executable memory region and be able to fill it with necessary data (e.g., shellcode instructions). Generally, achieving this goal using old exploitation techniques is made significantly more difficult with the addition of the DEP mechanism. As a result, attackers improved upon the classic “return-into- libc” technique and started using return-oriented programming (ROP) [3, 7] to bypass Data Execution Prevention. Techniques like ROP are still based on the attacker understanding memory layout characteristics, leading Microsoft to implement Address Space Layout Randomization (ASLR) as a countermeasure. ASLR renders the layout of an application’s address space less predictable because it relocates the base addresses of executable modules and other memory mappings. In order to bypass DEP protection mechanism ROP technique was introduced. In this article we present novel and known mechanisms which are created specifically to prevent attackers from exploiting vulnerabilities based on the ROP method. Presented mitigations will be divided in two general categories: • Compiler-level mitigations — mitigations that can be only applied by the compiler or linker. • Binary-level mitigations — mitigations that can be applied without knowing the source code of the protected code fragment. Download: http://kryptoslogic.com/download/ROP_Whitepaper.pdf

Return-Oriented Programming without Returns ABSTRACT We show that on both the x86 and ARM architectures it is possible to mount return-oriented programming attacks without using return instructions. Our attacks instead make use of certain instruction sequences that behave like a return, which occur with sufficient frequency in large libraries on (x86) Linux and (ARM) Android to allow creation of Turing-complete gadget sets. Because they do not make use of return instructions, our new attacks have negative implications for several recently proposed classes of defense against return-oriented programming: those that detect the too-frequent use of returns in the instruction stream; those that detect violations of the last-in, first-out invariant normally maintained for the return-address stack; and those that modify compilers to produce code that avoids the return instruction. 1. INTRODUCTION This paper is about the feasibility of certain defenses against return-oriented programming. In the last year, several natural defenses have been proposed that target properties of return-oriented attacks and are intended to be simpler and have lower overhead than a comprehensive defense such as Control-Flow Integrity (CFI) [1, 14].1 In this paper, we show that these narrowly tailored defenses are incomplete by devising a new variant of return-oriented programming that evades them. Our results call into doubt the usefulness of these ad-hoc defenses. Download: http://www.cs.jhu.edu/~s/papers/noret_ccs2010/noret_ccs2010.pdf

ROPdefender: A Detection Tool to Defend Against Return-Oriented Programming Attacks ABSTRACT Modern runtime attacks increasingly make use of the pow- erful return-oriented programming (ROP) attack techniques and principles such as recent attacks on Apple iPhone and Acrobat products to name some. These attacks even work under the presence of modern memory protection mecha- nisms such as data execution prevention (DEP). In this pa- per, we present our tool, ROPdefender, that dynamically de- tects conventional ROP attacks (that are based on return in- structions). In contrast to existing solutions, ROPdefender can be immediately deployed by end-users, since it does not rely on side information (e.g., source code or debugging in- formation) which are rarely provided in practice. Currently, our tool adds a runtime overhead of 2x which is comparable to similar instrumentation-based tools. 1. INTRODUCTION Runtime attacks on software aim at subverting the execu- tion ow of a program by redirecting execution to malicious code injected by the adversary. Typically, the control- ow of a program is subverted by exploiting memory vulnera- bilities. Despite extensive research and many proposed so- lutions in the last decades, such vulnerabilities ) are still the main source of vulnerabilities in to- day's applications. Figure 1 shows that the number of buer over ow vulnerabilities (according to the NIST1 Vulnerabil- ity database) continues to range from 600 to 700 per year. Operating systems and processor manufactures provide solutions to mitigate these kinds of attacks through the W X (Writable XOR Executable) security model [49, 43], which prevents an adversary from executing malicious code by marking a memory page either writable or executable. Current Windows versions (such as Windows XP, Vista, or Windows 7) enable W X (named data execution preven- tion (DEP) [43] in the Windows world) by default. Download: http://www.informatik.tu-darmstadt.de/fileadmin/user_upload/Group_TRUST/PubsPDF/ropdefender.pdf

On the Effectiveness of AddressSpace Randomization ABSTRACT Address-space randomization is a technique used to fortify systems against buer over ow attacks. The idea is to in- troduce articial diversity by randomizing the memory lo- cation of certain system components. This mechanism is available for both Linux (via PaX ASLR) and OpenBSD. We study the eectiveness of address-space randomization and nd that its utility on 32-bit architectures is limited by the number of bits available for address randomization. In particular, we demonstrate a derandomization attack that will convert any standard buer-over ow exploit into an ex- ploit that works against systems protected by address-space randomization. The resulting exploit is as eective as the original exploit, although it takes a little longer to compro- mise a target machine: on average 216 seconds to compro- mise Apache running on a Linux PaX ASLR system. The attack does not require running code on the stack. We also explore various ways of strengthening address- space randomization and point out weaknesses in each. Sur- prisingly, increasing the frequency of re-randomizations adds at most 1 bit of security. Furthermore, compile-time ran- domization appears to be more eective than runtime ran- domization. We conclude that, on 32-bit architectures, the only benet of PaX-like address-space randomization is a small slowdown in worm propagation speed. The cost of randomization is extra complexity in system support. Download: http://benpfaff.org/papers/asrandom.pdf

On the effectiveness of DEP and ASLR swiat 8 Dec 2010 9:59 AM DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) have proven themselves to be important and effective countermeasures against the types of exploits that we see in the wild today. Of course, any useful mitigation technology will attract scrutiny, and over the past year there has been an increasing amount of research and discussion on the subject of bypassing DEP and ASLR [1,2]. In this blog post we wanted to spend some time discussing the effectiveness of these mitigations by providing some context for the bypass techniques that have been outlined in attack research. The key points that should be taken away from this blog post are: DEP and ASLR are designed to increase an attacker's exploit development costs and decrease their return on investment. The combination of DEP and ASLR is very effective at breaking the types of exploits we see in the wild today, but there are circumstances where they can both be bypassed. Exploits targeting Microsoft and third party vulnerabilities have been created that are capable of bypassing DEP and ASLR in the context of browsers and third party applications. We are currently not aware of any remote exploits that are capable of bypassing DEP and ASLR in the context of in-box Windows services and various other application domains. Knowledge of potential bypass techniques directly informs our future work to improve the robustness and resiliency of DEP, ASLR, and our other mitigation technologies. DEP effectiveness (without ASLR) In a previous blog post series we went into detail on what DEP is and how it works[part 1, part 2]. In summary, the purpose of DEP is to prevent attackers from being able to execute data as if it were code. This stops an attacker from being able to directly execute code from the stack, heap, and other non-code memory regions. As such, exploitation techniques like heap spraying (of shellcode) or returning into the stack are not immediately possible. The effectiveness of DEP hinges on the attacker not being able to 1) leverage code that is already executable or 2) make the attacker's data become executable (and thus appear to be code). On platforms without ASLR (that is, versions of Windows prior to Windows Vista), it is often straightforward for an attacker to find and leverage code that exists in modules (DLLs and EXEs) that have been loaded at predictable locations in the address space of a process. Return-oriented programming (ROP) is perhaps the most extensive example of how an attacker can use code from loaded modules in place of (or as a stepping stone to) their shellcode [3,1]. In addition to loaded modules, certain facilities (such as Just-In-Time compilers) can allow an attacker to generate executable code with partially controlled content which enables them to embed shellcode in otherwise legitimate instruction streams ("JIT spraying")[2]. The fact that modules load at predictable addresses without ASLR also makes it possible to turn the attacker's data into executable code. There are a variety of ways in which this can be accomplished, but the basic approach is to use code from loaded modules to invoke system functions like VirtualAlloc or VirtualProtect which can be used to make the attacker's data become executable. Summary: DEP breaks exploitation techniques that attackers have traditionally relied upon, but DEP without ASLR is not robust enough to prevent arbitrary code execution in most cases. ASLR effectiveness (without DEP) Attackers often make assumptions about the address space layout of a process when developing an exploit. For example, attackers will generally assume that a module will be loaded at a predictable address or that readable/writable memory will exist at a specific address on all PCs. ASLR is designed to break these assumptions by making the address space layout of a process unknown to an attacker who does not have local access to the machine. This prevents an attacker from being able to directly and reliably leverage code in loaded modules. The effectiveness of ASLR hinges on the entirety of the address space layout remaining unknown to the attacker. In some cases memory may be mapped at predictable addresses across PCs despite ASLR. This can happen when DLLs or EXEs load at predictable addresses because they have not opted into ASLR via the /DYNAMICBASE linker flag. Prior to Internet Explorer 8.0 it was also possible for attackers to force certain types of .NET modules to load at a predictable address in the context of the browser[6]. Attackers can also use various address space spraying techniques (such as heap spraying or JIT spraying) to place code or data at a predictable location in the address space. In cases where the address space is initially unpredictable an attacker can attempt to discover the location of certain memory regions through the use of an address space information disclosure or through brute forcing[5]. An address space information disclosure occurs when an attacker is able to coerce an application into leaking one or more address (such as the address of a function inside a DLL). For example, this can occur if an attacker is able to overwrite the NUL terminator of a string and then force the application to read from the string and provide the output back to the attacker [4]. The act of reading from the string will result in adjacent memory being returned up until a NUL terminator is encountered. This is just one example; there are many other forms that address space information disclosures can take. Brute forcing, on the other hand, can allow an attacker to try their exploit multiple times against all of the possible addresses where useful code or data may exist until they succeed. Brute forcing attacks, while possible in some cases, are traditionally not practical when attacking applications on Windows because an incorrect guess will cause the application to terminate. Applications that may be subjected to brute force attacks (such as Windows services and Internet Explorer) generally employ a restart policy that is designed to prevent the process from automatically restarting after a certain number of crashes have occurred. It is however important to note that there are some circumstances where brute force attacks can be carried out on Windows, such as when targeting an application where the vulnerable code path is contained within a catch-all exception block. Certain types of vulnerabilities can also make it possible to bypass ASLR using what is referred to as a partial overwrite. This technique relies on an attacker being able to overwrite the low order bits of an address (which are not subject to randomization by ASLR) without perturbing the higher order bits (which are randomized by ASLR). Summary: ASLR breaks an attacker's assumptions about where code and data are located in the address space of a process. ASLR can be bypassed if the attacker can predict, discover, or control the location of certain memory regions (particularly DLL mappings). The absence of DEP can allow an attacker to use heap spraying to place code at a predictable location in the address space. DEP+ASLR effectiveness In the previous sections we described the effectiveness of DEP and ASLR in isolation from one another. In reality, DEP and ASLR are designed to be used in combination on Windows Vista and beyond. Both of these mitigations are enabled in the context of important applications like Internet Explorer 8, Microsoft Office 2010, and in-box services and applications that ship with the OS. This means that attackers looking to exploit vulnerabilities in these environments will need to overcome both obstacles (in addition to numerous other mitigations). The DEP+ASLR bypass techniques that are currently being explored in attack research have primarily focused on identifying and refining methods of bypassing ASLR. Once ASLR has been bypassed it is typically straightforward to bypass DEP using established techniques such as return-oriented programming. At this point in time there have been multiple exploits which have demonstrated that it is possible in practice to bypass the combination of DEP+ASLR in the context of certain application domains (such as browsers and third party applications). These exploits have bypassed ASLR through the use of predictable DLL mappings, address space information disclosures, or JIT spraying and have bypassed DEP through the use of return-oriented programming (or some simpler variant thereof) or JIT spraying. In many cases these exploits have relied on predictable mappings caused by DLLs that ship with third party components or by JIT compilation capabilities included in non-default browser plugins. This means that these exploits will fail if the required components are not installed. Although exploits have been written which are capable of bypassing the combination of DEP+ASLR, the vast majority of exploits that have been written to date do not have such capabilities and instead strictly target applications and platforms that do not enable these mitigations. This affirms our position that DEP+ASLR are strong countermeasures for the types of attacks that we see in the wild today despite weaknesses in their current implementations. Summary: DEP+ASLR are most effective when used in combination; however, their combined effectiveness is heavily dominated by the effectiveness of ASLR. Exploits have been developed that are able to bypass DEP+ASLR in the context of browsers and third-party applications. Nevertheless, the vast majority of exploits written to date do not attempt to bypass the combination of DEP+ASLR. Future directions As we look toward the future it is clear that attackers will continue to become increasingly incentivized to attempt to develop exploits which are capable of bypassing the combination of DEP+ASLR. Our understanding of the ways that DEP and ASLR can be bypassed directly informs the future work we are doing to improve the robustness and resiliency of our mitigation technologies. Although this work is ongoing there are two noteworthy improvements that we would like to highlight. The first improvement can be seen in the latest version of the Enhanced Mitigation Experience Toolkit (EMET) which now includes support for a feature known as mandatory ASLR. This feature enforces ASLR for all modules regardless of whether or not they are ASLR aware (which effectively eliminates predictable DLL mappings when enabled on Windows Vista and above). This resolves the ASLR bypass technique we described previously and it has been used in practice to successfully mitigate exploits in the wild. The second improvement consists of JIT spraying mitigations that have been directly incorporated into the JavaScript JIT compiler that was recently released in the Internet Explorer 9 beta. These mitigations act as countermeasures against the JIT spraying techniques that have been described in attack research. These two improvements help to further illustrate our belief that DEP, ASLR, and exploit mitigations in general are extremely important due to the impact they have on the cost of developing reliable exploits and due to the knowledge demands they place on attackers. Mitigations such as these enable us to be proactive about providing additional protection to customers who may be running software with an unknown or unpatched vulnerability. Ultimately our goal with exploit mitigations is to reach a point where vulnerabilities become too expensive to reliably exploit - and this is a goal we are actively working toward. Recommendations For enterprises and users We recommend that enterprises and users enable DEP for all critical applications and run a version of Windows that supports ASLR (such as Windows 7). The Enhanced Mitigation Experience Toolkit (EMET) can be used to easily enable DEP and other mitigations for a process. You can read more about EMET here: The Enhanced Mitigation Experience Toolkit For ISVs The effectiveness of mitigations like DEP and ASLR across the Windows ecosystem is heavily contingent on ISV adoption. ISVs that are interested in more details on how to enable DEP, ASLR, and other mitigations in their products are encouraged to refer to the guidance below: Windows ISV Software Security Defenses Matt Miller, MSEC Security Science References [1] Dino Dai Zovi. Practical Return-Oriented Programming. April, 2010. [2] Dionysus Blazakis. Interpreter Exploitation: Pointer Inference and JIT Spraying. February, 2010. [3] Hovav Shacham. Return-Oriented Programming: Exploits Without Code Injection. August, 2008. [4] Peter Vreugdenhil. Pwn2Own 2010 Windows 7 Internet Explorer 8 Exploit. March, 2010. [5] Hovav Shacham et al. On the Effectiveness of Address-Space Randomization. 2004. [6] Alexander Sotirov and Mark Dowd. Bypassing Browser Memory Protections. August, 2008. *Posting is provided "AS IS" with no warranties, and confers no rights.* Sursa: On the effectiveness of DEP and ASLR - Security Research & Defense - Site Home - TechNet Blogs

Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP swiat 2 Feb 2009 5:53 PM One of the responsibilities of Microsoft’s Security Engineering Center is to investigate defense in depth techniques that can be used to make it harder for attackers to successfully exploit a software vulnerability. These techniques are commonly referred to as exploit mitigations and have been delivered to users in the form of features like /GS, Data Execution Prevention (DEP), and Address Space Layout Randomization (ASLR). In Windows Server 2008 and Windows Vista SP1, Microsoft released support for a new platform mitigation known as Structured Exception Handler Overwrite Protection (SEHOP). The purpose of this article is to explain the problem this feature is attempting to solve, how it goes about solving it, and what you can do take advantage of it. The exploitation technique: SEH overwrites The purpose of the SEHOP mitigation is to prevent an attacker from being able to make use of the Structured Exception Handler (SEH) overwrite exploitation technique. This exploitation technique was publicly documented by David Litchfield of NGS Software in a research paper that he published in September, 2003[1]. Since this publication, the SEH overwrite technique has become a standard weapon in an attacker’s arsenal. Roughly 20% of the exploits included in the latest version of the Metasploit framework make use of the SEH overwrite technique. SEH overwrites are also commonly used by exploits that target the increasing number of browser-based vulnerabilities[4]. At a high-level, the SEH overwrite technique uses a software vulnerability to execute arbitrary code by abusing the 32-bit exception dispatching facilities provided by Windows. At a functional level, an SEH overwrite is generally accomplished by using a stack-based buffer overflow to overwrite an exception registration record that has been stored on a thread’s stack. To provide some context, an exception registration record is composed of two fields: a next pointer and an exception handler function pointer. The next pointer is used to link an exception registration record to the next record in the singly-linked list of registered exception handlers. The exception handler function pointer is called by the Windows exception dispatcher when an exception occurs. The definition for an exception registration record can be seen below: typedef struct _EXCEPTION_REGISTRATION_RECORD { struct _EXCEPTION_REGISTRATION_RECORD *Next; PEXCEPTION_ROUTINE Handler; } EXCEPTION_REGISTRATION_RECORD, *PEXCEPTION_REGISTRATION_RECORD; After an exception registration record has been overwritten, an exception must be raised so that the exception dispatcher will attempt to handle it. This can be accomplished in a number of ways, such as by overwriting a return address on the stack with a bogus address in order to cause an access violation exception to be raised. When an exception is raised, the exception dispatcher will attempt to enumerate the list of exception registration records for the thread and call the exception handler that is associated with each record. By corrupting the next pointer and exception handler function pointer of one of the exception registration records, the exception dispatcher can be made to execute code from an arbitrary address as specified by the corrupt exception handler function pointer. In many cases, an attacker will choose to overwrite the exception handler function pointer with an address that contains instructions that are equivalent to a pop reg, pop reg, ret. This allows an attacker to reliably execute arbitrary code by transferring control to the EstablisherFrame that the exception dispatcher passes as the second parameter when calling an exception handler. This works because the EstablisherFrame parameter holds the address of the attacker-controlled exception registration record. Attackers have also used heap spraying in conjunction with an SEH overwrite to reliably execute arbitrary code. The following diagram illustrates what an SEH overwrite would typically look like from an exploitation perspective: The mitigation technique: SEHOP There are two general approaches that can be considered when attempting to mitigate the SEH overwrite exploitation technique. The first approach involves making changes to the compiled versions of code such that executable files are made to contain metadata that the platform would need to properly mitigate this technique. Microsoft pursued this approach and released a functional mitigation with Visual Studio 2003. This mitigation took the form of a new linker flag known as /SAFESEH. Unfortunately, the need to rebuild executables in combination with the inability to completely handle cases where an exception handler is pointed outside of an image file make the SafeSEH approach less attractive. The details relating to how SafeSEH works are beyond the scope of this article, but more information can be found on MSDN[2]. The second approach involves adding dynamic checks to the exception dispatcher that do not rely on having metadata derived from a binary. This is the approach taken by SEHOP. At a high-level, SEHOP prevents attackers from being able to use the SEH overwrite technique by verifying that a thread’s exception handler list is intact before allowing any of the registered exception handlers to be called. This mitigation technique is made possible because of an implicit side effect of an SEH overwrite. When the majority of stack-based buffer overflows occur, an attacker will implicitly overwrite the next pointer of an exception registration record prior to overwriting the record’s exception handler function pointer. Since the next pointer is corrupted, the integrity of the exception handler chain is broken. This insight, in combination with ASLR, is what allows SEHOP to effectively mitigate SEH overwrites. From an implementation perspective, SEHOP achieves this functionality in two distinct steps. The first step involves the insertion of a symbolic exception registration record as the tail record in a thread’s exception handler list. This step occurs when a thread first begins executing in user mode. Since exception registration records are always inserted at the head of the exception handler list, the symbolic record is guaranteed to be the final exception registration record. The second step consists of walking the exception handler list at the time that an exception is being dispatched to ensure that the symbolic record can be reached and that it is valid. This step happens when the exception dispatcher is notified that an exception has occurred in user mode. If the symbolic record cannot be reached, the exception dispatcher can assume that the exception handler list is corrupt and that an SEH overwrite may have occurred. The exception dispatcher is then able to safely terminate the process. If the symbolic record is found, the exception dispatcher is able to proceed as it normally would and call each of the registered exception handlers. An illustration of this logic can be seen in the following diagram: How you can use SEHOP SEHOP is enabled by default on Windows Server 2008 and disabled by default on Windows Vista SP1. The primary reason this feature was disabled by default on Windows Vista SP1 was due to a lack of adequate application compatibility data. KB article 956607 documents how SEHOP can be enabled or disabled on a system-wide basis[3]. Wrapping up We are continuing to investigate new and enhanced exploit mitigation techniques and feel that SEHOP is a valuable addition that can help protect users. We encourage users to enable this feature if it is not enabled by default in order to better protect themselves against the SEH overwrite exploitation technique. For more information about the origins of SEH overwrites and SEHOP, it may be helpful to refer to the cited work[1,5]. Matt Miller, MSEC Security Science *Posting is provided "AS IS" with no warranties, and confers no rights.* References [1] Litchfield, David. Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server. Sep, 2003. Information Security Software & Services - NCC Group [2] Microsoft Corporation. /SAFESEH (Image has Safe Exception Handlers). http://msdn.microsoft.com/en-us/library/9a89h429(VS.80).aspx [3] Microsoft Corporation. SEHOP. How to enable Structured Exception Handling Overwrite Protection (SEHOP) in Windows operating systems [4] Microsoft Corporation. Microsoft Security Intelligence Report volume 5. Nov, 2008. Download Microsoft Security Intelligence Report volume 5 (January – June 2008) from Official Microsoft Download Center [5] skape. Preventing the Exploitation of SEH Overwrites. Sep, 2006. Uninformed - vol 5 article 2 Sursa: Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP - Security Research & Defense - Site Home - TechNet Blogs

Understanding DEP as a mitigation technology part 1 swiat 12 Jun 2009 1:30 PM We have mentioned DEP in several recent blog posts (1, 2, 3, and 4). This blog post will answer: What is DEP? How can you enable DEP? What are the risks in enabling different modes of DEP? This is the first of a two-part blog series on DEP as a mitigation technology. What is DEP? DEP or “Data Execution Prevention” is a hardware + software solution for preventing the execution of code from pages of memory that are not explicitly marked as executable. Windows XP SP2, Windows Server 2003 SP1, and later operating systems check if the CPU supports enforcement of the ‘no execute’ or ‘execute disable bit’ for a page of memory. Before Windows XP SP2, an exploit (“code”) could execute from memory allocated without the execute memory protection constant set. For example, if a page of memory were allocated using the VirtualAlloc() function specifying PAGE_READWRITE, it was still possible to execute code from that page of memory. Starting with Windows XP SP2 and Windows Server 2003 SP1, if the CPU supports the execute disable (XD – Intel CPUs) or no execute (NX – AMD CPUs) bits, any attempts to execute code from a page of memory with a (for example) PAGE_READWRITE memory protection will generate a STATUS_ACCESS_VIOLATION (0xC0000005) access violation exception. For more information on how hardware enforced DEP works please refer to the following article: Part 3: Memory Protection Technologies. DEP is “always on” for 64bit processes on 64bit versions of Windows and it cannot be disabled. The Windows DEP policy can be managed on both a system wide and per-process basis and both approaches will be discussed below. This blog post will apply specifically to 32bit processes running on either a 32bit or 64bit version of Windows. How robust is DEP? DEP presents a hurdle to attackers as they attempt to successfully exploit security vulnerabilities. In some cases, it is possible for an attacker to evade DEP by using an exploitation technique such as return-to-libc. DEP by itself is generally not a robust mitigation. DEP is a critical part of the broader set of exploit mitigation technologies that have been developed by Microsoft such as ASLR, SeHOP, SafeSEH, and /GS. These mitigation technologies complement one another; for example DEP’s weaknesses tend to be offset by ASLR and vice versa. DEP and ASLR used together are very difficult to bypass. The known bypasses that exist have been tied to specific application contexts (such as the IE7 and earlier bypass from Mark Dowd and Alex Sotirov). How do I enable DEP? If you have hardware that supports DEP and you are running Windows XP SP2 or newer operating system – you are already using DEP to some extent! Hardware enforced DEP can be configured system wide (applying to all processes) or using per-process policies. There are four different ways of enforcing a system wide DEP policy on platforms that support it. “Opt-In” – In this mode of operation DEP is enabled only for processes that explicitly opt-in to DEP. This is the default configuration for client operating systems such as Windows XP and Windows Vista. “Opt-Out” – In this mode of operation DEP is enabled by default for all processes except those that explicitly opt-out of DEP. This is the default configuration for server operating systems such as Windows Server 2003 and Windows Server 2008. “Always On” – In this mode of operation DEP is always enabled for all processes regardless of whether the program is compatible with DEP or not. “Always Off” – In this mode of operation DEP is always disabled for all processes. Windows XP SP2 and Windows Server 2003 SP1 This article does a great job explaining how to use the boot.ini or the GUI to configure the memory protection settings on Windows XP SP2 and Windows Server 2003 SP1. Note that configuring the “system wide” DEP policy requires administrative privileges. Windows Vista and Windows Server 2008 To configure the system-wide DEP policy on Windows Vista and Server 2008, modify the Boot Configuration Database using the bcdedit.exe console application from an elevated command prompt. You can find more information about how to do that here: Content Moved (Windows) Potential application compatibility issues with DEP “Always On” Setting DEP to always be enabled for all processes may increase the risk of causing application problems due to certain behavior from versions of ATL prior to version 7.1. Older versions of ATL generated machine code at runtime and then attempted to execute this code from pages of memory that were not marked as executable, thus causing a DEP violation if DEP is enabled. If the system-wide setting is “opt-in”, a process known as “ATL thunk emulation” is used to avoid ATL related DEP crashes. “ATL thunk emulation” is not used if DEP is “Always On”. NOTE: When the "Always On" setting is used there are known compatibility issues with Microsoft Office applications when opening documents that contain VBA (Visual Basic for Applications) macros that can lead to DEP related crashes. How can I tell if a specific process has opted-in or will opt-in to DEP? The easiest way to tell if a process is currently using DEP is to use Process Explorer and to configure it to show the processes DEP status (View->Select Columns->Process DEP status) as shown below: To determine why a process uses (or does not use) DEP requires a bit more investigative work. Here are the ways the system could have decided on a process’s DEP state. Each will be explored in more detail later in the blog post. The system-wide DEP policy was set to "AlwaysOn". DEP is enabled for all processes. The system-wide DEP policy was set to "OptIn" and the process opted-in via an entry in the Application Compatibility Database. The system-wide DEP policy was set to "OptOut" and the process did not explicitly opt-out. The process executable was linked with the /NXCOMPAT linker switch and is running on a Vista or newer operating system. The process has the "ExecuteOptions" registry value set to 0 in the "Image File Execution Options" registry key and is running on a Windows Vista or newer operating system. The process called the new SetProcessDEPPolicy API on Vista SP1, XPSP3 or Windows Server 2008. How Per-Process DEP policy works on Windows XP SP2 & Windows Server 2003 SP1 Windows XP SP2 and Windows Server 2003 SP1 included a heavy emphasis on security. As such, many of the default Windows programs were opted-in to DEP via the Application Compatibility database. To explore which programs opt-in to DEP on Windows XP SP2 or Windows Server 2003 SP1 you can download and install the latest Application Compatibility Toolkit and browse the main system database under the 'Windows Components' subset of applications. All Windows XP SP2 applications opt-in to DEP if in category “Windows Components” with “AddProcessParametersFlags" compatibility fix applied: The Windows Server 2003 SP1 default system wide policy is “OptOut”. That means all processes that do not explicitly opt-out will have DEP enabled. If the system-wide policy is changed, an application could still have DEP enabled by using the EnableDEP compatibility fix as shown below: These compatibility fixes set the PEB's ProcessParameters value to 0x00020000, causing Windows XP SP2 and Windows Server 2003 SP1 to opt a process in to DEP. We found 305 processes opted-in to DEP on Windows XP SP2 and Windows Server 2003 SP1 via the main application compatibility database (%windir%\AppPatch\sysmain.sdb) using this particular compatibility fix. We have attached the list of processes at the bottom of the blog. New Per-Process DEP options on Windows Vista, Windows Server 2008 and newer operating systems Microsoft has introduced options on newer operating systems to opt a process in to DEP. /NXCOMPAT linker switch On Vista and newer operating systems, processes linked with the /NXCOMPAT option are opted-in to DEP by default. Developers of 3rd party applications that want to take advantage of this mitigation technology can re-link their applications using the Visual C++ 2003 or newer version of the linker by passing in the “/NXCOMPAT” flag. This will cause the linker to emit a binary that declares that it supports DEP via an optional image header field supported on Vista and later operating systems. You can determine whether a process has been linked with the /NXCOMPAT linker switch using dumpbin.exe (which ships with Visual Studio): C:\Windows\System32>dumpbin /headers dllhost.exe Microsoft (R) COFF/PE Dumper Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file dllhost.exe PE signature found File Type: EXECUTABLE IMAGE FILE HEADER VALUES 8664 machine (x64) 5 number of sections 4549BBFF time date stamp Thu Nov 02 05:35:59 2006 0 file pointer to symbol table 0 number of symbols F0 size of optional header 22 characteristics Executable Application can handle large (>2GB) addresses OPTIONAL HEADER VALUES 20B magic # (PE32+) 8.00 linker version 1400 size of code 1000 size of initialized data 0 size of uninitialized data 1818 entry point (0000000100001818) 1000 base of code 100000000 image base (0000000100000000 to 0000000100006FFF) 1000 section alignment 200 file alignment 6.00 operating system version 6.00 image version 6.00 subsystem version 0 Win32 version 7000 size of image 400 size of headers E1C5 checksum 2 subsystem (Windows GUI) 8140 DLL characteristics Dynamic base NX compatible Terminal Server Aware ExecuteOptions registry setting Windows Vista and Windows Server 2008 can also force a process to use DEP using the ExecuteOptions registry setting. ExecuteOptions can force a process to use DEP without changing the system-wide policy. Processes opted-in to DEP using the ExecuteOptions registry setting will be DEP-enabled for the life of the process (DEP cannot be turned off via any API calls). Compared to the system-wide Opt-In / Opt-Out approach, this could be seen as a disadvantage as discussed above regarding “ATL thunk emulation” when it comes to application compatibility. “ATL thunk emulation” is not used when a process is forced to use DEP via either the ExecuteOptions registry setting or /NXCOMPAT linker switch. Finally, the Windows Compatibility Database contains a list of DLLs that are known to be incompatible with DEP and when this registry setting is used, since DEP cannot be disabled for the process by the compatibility infrastructure in Windows, DEP related crashes may result if applications attempt to load DLLs that are not compatible with DEP. Microsoft encourages 3rd party ISVs to support DEP (and other exploit mitigation technologies). The latest versions of Acrobat, Flash, QuickTime, and Sun’s Java runtime (JRE 6 Update 12) all support DEP. For more information on how to avoid ATL related DEP crashes when DEP is enabled for a process, refer to Applications Using Older ATL Components May Experience Conflicts With DEP. SetProcessDEPPolicy API Finally, a new way of opting-in to DEP is available on our latest versions of Windows. Windows Vista SP1, Windows Server 2008 and Windows XP SP3 includ the SetProcessDEPPolicy API to allow an application to opt-in to DEP programmatically without /NXCOMPAT or being marked up in the appcompat database or registry. Exposing an API not only makes it easier for developers to opt-in to DEP but when using this API, ATL thunk emulation is performed and processes using older versions of ATL should not crash due to DEP violations. For example, Internet Explorer 8 takes advantage of this new functionality. In part two of this series, we’ll demonstrate how to change an application’s DEP policy to mitigate a real-world attack. - Robert Hensing, MSRC Engineering *Postings are provided "AS IS" with no warranties, and confers no rights.* AddProcessParametersFlags - XPSP2.txt Sursa: Understanding DEP as a mitigation technology part 1 - Security Research & Defense - Site Home - TechNet Blogs

[h=1]Solving the Mystery of the Office Zero-Day Exploit and DEP[/h]By Vinay Karecha on Nov 07, 2013 On November 5 McAfee Labs blogged about a Microsoft Office zero-day attack that we spotted in the wild. In another post we discussed coverage for our various products. Now, we’d like to report some interesting technical findings from our research team. As pointed out in our previous post, we found the exploit works pretty well on Office 2007 running Windows 7. We originally thought there must be some technique used by the exploit to bypass address space layout randomization and data execution prevention. However, our findings show something different because of the DEP system policy setting. While debugging the shellcode, we noticed quite a few interesting things. First, the shellcode was in a PAGE_READWRITE memory block, which encouraged us to further check the DEP status of the process winword.exe. We found the DEP status was “on” at the process start but “off” during shellcode execution. McAfee Labs researcher Haifei Li found this exploit worked on system-level DEP options, including both the Opt-In and Opt-Out for Office 2007. If the system policy is set to Opt-In, DEP is enabled only for processes that explicitly opt-in to DEP. Office 2007 Word is not in the DEP-enabled list; thus DEP is not enabled for Office 2007 under the Opt-In mode and there is no need for an exploit to bypass DEP to succeed. We tested further for the Opt-Out mode. If the system policy is set to Opt-Out, DEP is enabled by default for all processes except those that explicitly opt out of DEP. That means usually DEP is on for all processes for this option when they start, but a process has the option to opt out of DEP at any moment. We figured out that if we blocked the loading of VBE6.DLL (C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL), the exploit would not work–a DEP-violation error was triggered. Also, if we forced DEP with Microsoft EMET, the exploit would not work. The test results caused us to wonder whether there was a DEP bypass, such as using ROP gadgets. Though many other researchers claimed this point after their analysis, they might have analyzed different samples. (The MD5 hash for our analyzed sample is 1FD4F3F063D641F84C5776C2C15E4621.) Quickly we injected our DLL in winword.exe with a hooked LoadLibraryExA and called GetProcessDEPPolicy before and after the loading of each module. We opened the log and found that DEP status changed to “off” just after the loading of VBE6.DLL. After some investigation we I found that ntdll!ZwSetInformationProcess can be called with parameters -1 and 0×22 to turn off DEP for the process. So, just before the call to LoadLibrary with VBE6.DLL, we set a break point at ntdll!ZwSetInformationProcess, and it got hit with the expected parameters (-1,0×22). Back-tracing the call, we came across this: This is the code to disable DEP for the process: This solves the mystery of the exploitation. Our analyzed exploit didn’t bypass ASLR and DEP. Instead, it leveraged a backward compatibility feature in Office 2007 to disable DEP. Without DEP, ASLR is quite easy to bypass with heap spraying, as discussed in this Microsoft SRD post. We believe that the DEP compatibility issue of old DLLs such as VBE6.DLL makes this exploitation possible. Microsoft’s guidance confirmed our suspicions. The DEP system policy can be set to Opt-In, Opt-Out, Always-On, and Always-Off. Only the Always-On option enforces DEP, which means that a process cannot turn off DEP. For compatibility reasons, the Always-On setting may cause DEP-related crashes due to Microsoft Office applications opening documents that contain Visual Basic for Applications macros. The lesson we learned is interesting. For better security, the system setting for DEP should be Always-On. But for compatibility, Opt-Out can be used to protect applications that assume DEP availability. However, the Opt-Out system setting does not necessarily have full DEP protection for an application that does not explicitly opt out of DEP; thus such an application (Microsoft Word in this case) is still subject to exploits that may be prevented by DEP. Thanks to Hirosh Joseph, Haifei Li, Bing Sun, Chong Xu, and Lijun Cheng for their support and help with the analysis. Sursa: http://blogs.mcafee.com/mcafee-labs/solving-the-mystery-of-the-office-zero-day-exploit-and-dep

Sa fim seriosi... Nu e nicio problema.