Leaderboard

Target: hxxp://www.polercisewa.com.au/subcat.php?catid=OSAg&PHPSESSID=a9dae1baf405f3382d9efbfc09c1b9dd Task: display version with your name Proof: Rules: use union select based SQLi post picture as proof send me your command to PM Solvers: - SelfDestruct - boogy

It Looks Like this Java Patch 7u11 Will Need to be Patched – OOPS | SiliconANGLE It’s been just over a month since Oracle released their latest update for Java. The updates were needed to cover a very public and very ugly giant vulnerability. Recall that it was just before that time that there was continued advice and calls to disable and even uninstall Java on your systems. As it turns out, one of the components, an exploit code for Patch 7u11 turned up on Pastebin about 13 hours ago. The code has been accessed close to 3500 times at this time. If it’s on Pastebin, then who knows how long this has been out in the wild. tsk. tsk. The good news is that Oracle did quickly deploy that last update and perhaps we’ll see a rapid response to this exploit. Clearly Java is something that has been under attack for a while and there are some very serious security fears by many people in the industry at least on the client side. The guys over at DotTech responsible for that great image predicted that there were issues with the patch last month. If you haven’t disabled or removed Java on your systems thus far, it might be a good time to do that. Sursa It Looks Like this Java Patch 7u11 Will Need to be Patched – OOPS | SiliconANGLE

Analyzing the First ROP-Only, Sandbox-Escaping PDF Exploit | Blog Central The winter of 2013 seems to be “zero-day” season. Right after my colleague Haifei Li analyzed the powerful Flash zero day last week, Adobe sent a security alert for another zero-day attack targeting the latest (and earlier) versions of Adobe Reader. Unlike Internet Explorer zero-day exploits that we have seen in the past, this Reader zero-day exploit is a fully “weaponized” affair. It contains advanced techniques such as bypassing address-space layout randomization/data-execution prevention by using memory disclosure and a sandbox escape in the broker process. In this blog we will give a brief analysis of the exploitation. The malicious PDF file used in the this exploitation consists mainly of three parts: Highly obfuscated JavaScript code, containing heap-spray data with a return-oriented programming (ROP) payload and the JavaScript code to manipulate Adobe XML Forms Architecture (XFA) objects to trigger the vulnerability A flat-encoded XFA object An encrypted binary stream, which we believe is related to the two dropped DLLs The exploitation has two stages. The first-stage code execution inside the sandboxed process happens in the AcroForm.api module. A vtable pointer will be read from the attacker-controlled heap-spray area and later will be used in the call instruction. This exploit can leak the base-module address of AcroForm.api. The embedded JavaScript code is used to detect the current version of Adobe Reader, and all the ROP payload can be built at runtime. Most important, there is no traditional shellcode at all! All the required shellcode functions are implemented in the ROP code level. That means most emulation-based shellcode-detection techniques will fail in detecting such an exploitation, because those techniques see only a bunch of addresses within a legitimate module. It’s similar to the old iOS jailbreak exploit that can be used to defeat the iOS code-signing enhancement. The ROP shellcode first decrypts an embedded DLL (D.T) in memory and drops it to the AppData\Local\Temp\acrord32_sbx folder. Then, it loads the DLL into the current process. After that, the hijacked thread suspends itself by calling Kernel32!Sleep API. When D.T runs in the sandboxed process, it drops other DLLs (L2P.T, etc.) and is ready to escape the sandbox by exploiting another Adobe vulnerability. The second-stage code execution occurs inside the broker process. The destination of the call instruction can also be controlled by the attacker. The second-stage ROP shellcode is very short. It simply loads the dropped DLL L2P.T and goes into a sleep state. At this point, the exploit has already successfully broken out of the Reader sandbox because the attacker-controlled code (L2P.T) managed to run in the high-privileged broker process. This is the first in-the-wild exploit we have seen that has fully escaped the sandbox. Previously, we had only heard of the possibility of full sandbox escaping at a top hacking competition such as pwn2own. Besides the complicated exploitation portion, this exploit also uses multiple evasion techniques such as highly obfuscated JavaScript, ROP-only shellcode, and multistaged encrypted malware to bypass network and endpoint security detection and protection. After succeeding, the exploit code exits the hijacked process and creates new processes to render a normal PDF file. The exploitation happens in a split second; thus the victim who opens that original malicious PDF file will not observe any abnormal behavior. We will continue our analysis and provide more detail later on the sandbox escape. For now, we strongly recommend that all Reader users enable protected view and disable JavaScript (Edit -> Preferences -> JavaScript -> Uncheck the “Enable Acrobat JavaScript” option) until Adobe releases a patch. For McAfee customers, we have released signature 0x402e0600 “UDS-HTTP: Adobe Reader and Acrobat XFA Component Remote Code Execution” for the Network Security Platform appliances. Also, the generic buffer overflow prevention (Sigs 6013 and 6048) feature on our HIPS product will help to stop related attacks. Thanks to Bing Sun, Chong Xu, and Haifei Li for their help with this analysis. Sursa Analyzing the First ROP-Only, Sandbox-Escaping PDF Exploit | Blog Central

ma doare'n pula.