Nytro

Si cam ce sugestii aveti in legatura cu numele categoriei: 1355 1337 Zone, Noob Zone, Incepatori, Plm... ?

Pune la vot.

The Case of the PDF Malware 2012.07.31 I’ve been working with PDFs for the past few weeks and since I have a large collection of PDF files, going through them all has been taking a lot of time. I’ve seen a few different exploits, but there is one that especially caught my attention because I thought it was pretty wicked and nicely conceived. It all started after I ran a couple of samples through a script a while ago. The Strange PDF File The PDF in question can be found on Virus Total: MD5: 805538ff200ec714a735ef3bc1fff1f0 SHA256: e108432dd9dad6ff57c8de6e907fd6dd25b62673bd4799fa1a47b200db5acf7c Figure 1. PDF parsing In Figure 1, we can see that the PDF contains data that will be decoded using the /CCITTFaxDecode filter (see Portable Document Format - Wikipedia, the free encyclopedia). Since this is not very common, I decided that it was worth a little more investigation. We know that opening that file will cause Acrobat Reader to attempt to fetch something from a given web server (which is bad for obvious reasons). Once we launch Acrobat Reader and open that file, nothing seems to happen. From a user’s standpoint, it may not be much of a concern, but from ours, it is worrisome. The PDF file gets loaded by AcroRd32.exe and, while the window doesn’t appear, the application is obviously doing something. There is no Heap Spray attempt by any script inside the PDF but there is something running that should not be doing so. Catching Network Activity Since we know that the malware is trying to retrieve something off of the internet, I put a breakpoint inside urlmon.dll. Most malware use urlmon!URLDownloadToFileA() because it’s very simple to call, as all that is required is a URL and a file name. With my breakpoint set up, I let the malware run and lo and behold, we get a hit on the aforementioned API: Figure 2. URLDownloadFileToA call We can see here that the malware has made the call to the API and looking at the stack we can trace it back to see where is exploit is running from. Let’s take a look at the stack: Figure 3. URLDownloadFiletoA stack frame The call seems to emanate from icucnv34.dll, which is a valid DLL loaded by Acrobat Reader. So far, nothing seems to be particularly wrong, but if we look at the caller address a little further, we can see that there’s something fishy about it. As a reminder, before we go ahead, most shell code is located somewhere on the stack or on the heap. For instance, after a successful heap spray, the shell code will be running from some part of the heap allocated by the malicious script. This is where it becomes interesting… Where is the shell code? As we saw in Figure 3, URLDownloadFileToA is called from somewhere within icucnv34.dll (or so it seems). Let’s see what the PEB can tell us. After entering the !PEB command, here’s what Windbg gives us: Figure 4. PEB We’ve spotted our DLL. The module start address is 0x4a800000. In Figure 4, it says that the return address for URLDownloadFileToA is icucnv34+0x456b1, which is 0x4a8456b1. This is rather interesting because the DLL itself is only 300K and obviously not all of it is code. Here are the details: Figure 5. Module Information What did we get here? Base address = 0x4a800000 Size of code = 0x21000 Since the return address of the API is icucnv34+0x456b1, the code is not running inside the DLL code segment! So where is it exactly? Figure 6. Shell code memory dump It appears that the code we are looking at is located right before the modules resources. Going to 0x4a8456b1 and back a little, we can determine the entry point of the shell code. As shown in Figure 6, the URL accessed by the API is located at the end of the code, which starts with a NOP (0x90) followed by a short jump (0xeb 0x11). Initially this shell code is XORed out and the code that is between the beginning and the first jump address is used to XOR the rest of it with 0xA6. As we know, a Windows executable is structured something like this (rough description): Figure 7. Executable structure If some shell code is copied somewhere in between the data and the resources, it will appear to be part of the DLL. Hiding with a module space As we’ve just observed, the shell code is not copied on the heap but within the address space of a chosen DLL. This is pretty wicked because regular shell code detection may be fooled by this, as it would expect the return address of an API to be on the heap/stack and therefore not inside a DLL address space. If your detection is based on checking whether a return address is within the boundaries of a module, this sort of shell code will evade it. What the detection engine must do is to narrow the address range to be within the code segment of the module. In this particular case, the icucnv43.dll is loaded at 0x4a800000 and the code starts at base image + 0x1000, hence 0x4a801000. As the [!dh] showed us, the code size is 0x21000 which means that the runnable code of the DLL is 0x4a801000 – 0x4A822000. Looking at Figure 7, it becomes obvious that the shell code we’re looking at is running outside the .text segment. Since the shell code executes way outside of this range, we can deduct that it is indeed some malicious code and we can report the network activity as well as the use of shell code for that sort of PDF exploit. Emmanuel Thioux on 2012.07.31 Malware Research Sursa: Malware Intelligence Lab from FireEye - Research & Analysis of Zero-Day & Advanced Targeted Threats:The Case of the PDF Malware

[h=2]Getting Tricky With Shellcode[/h]2012.09.11 For those who read my previous blog regarding a very interesting shellcode exploit running inside a PDF, I got a little curious during my spare time and, upon further research, I realized that there is yet another way to insert shellcode inside a Windows program. The assumption here is that the reader knows about the Windows executable format (hence PE headers) and has some knowledge of DEP, ASLR, and some exploit techniques such as ROP chains. [h=3]Bypassing DEP[/h] For a while now, Windows has been using DEP to prevent a lot of exploits from working. The way it works is quite simple. Memory (in the form of subsequent pages) is allocated with certain protection attributes, those being: Read Write Execute Combination of all the above Code is normally flagged as Read/Executable, while data is Read/Write. Some other things like resources (Icons, Bitmaps, etc.) are set as Read Only. If memory is allocated as Read/Write and a program attempts to execute from that location, an exception will be thrown and the program will be stopped. Windows will then inform the user that DEP prevented something bad from happening. Currently, shell code is using ROP as a mean to bypass DEP. By creating ROP gadgets on the stack, the code that is executed is valid and won’t trigger DEP. Most of the time, ROP gadgets will make a call to VirtualProtect: BOOL WINAPI VirtualProtect( _In_ LPVOID lpAddress, _In_ SIZE_T dwSize, _In_ DWORD flNewProtect, _Out_ PDWORD lpflOldProtect ); There are other APIs that can be used to accomplish the same thing, but for simplicity's sake, I will only use VirtualProtect. By using this API, the malware, once the memory has been allocated or found otherwise, will change the protection flags to include EXECUTE. From that point on, the battle is pretty much won since DEP won’t see anything. [h=3]Filling the gap[/h] The issue with the aforementioned approach is that a call to VirtualProtect can be detected fairly easily. So how can we do without it? [h=3]Windows Executable Files And Their Sections[/h] As shown in my other post, a Windows executable is made of several, contiguous chunks of bytes. [TABLE] [TR] [TD=width: 147] DOS headers [/TD] [/TR] [TR] [TD=width: 147] PE headers [/TD] [/TR] [TR] [TD=width: 147] Code segment(s) [/TD] [/TR] [TR] [TD=width: 147] Data segments(s) [/TD] [/TR] [TR] [TD=width: 147] Resources [/TD] [/TR] [/TABLE] You can find a much better explanation here. Let’s look at a real sample. I am running Regedit.exe on Windows XP SP3. Figure 1. PEB In Figure 1, we can see the PEB of Regedit.exe. I have outlined RPCRT4.dll because it is of particular interest. The module is located at 0x77E70000 and here’s the output of [!dh 0x77E70000]: 0:001> !dh 77e70000 File Type: DLL FILE HEADER VALUES 14C machine (i386) 5 number of sections 49E5F46D time date stamp Wed Apr 15 07:51:25 2009 0 file pointer to symbol table 0 number of symbols E0 size of optional header 210E characteristics Executable Line numbers stripped Symbols stripped 32 bit word machine DLL OPTIONAL HEADER VALUES 10B magic # 7.10 linker version 89200 size of code 5C00 size of initialized data 0 size of uninitialized data 628F address of entry point 1000 base of code ----- new ----- 77e70000 image base 1000 section alignment 200 file alignment 3 subsystem (Windows CUI) 5.01 operating system version 5.01 image version 4.10 subsystem version 92000 size of image 400 size of headers 938E3 checksum 00040000 size of stack reserve 00001000 size of stack commit 00100000 size of heap reserve 00001000 size of heap commit 0 DLL characteristics 19C8 [ 436F] address [size] of Export Directory 82290 [ 64] address [size] of Import Directory 8C000 [ 408] address [size] of Resource Directory 0 [ 0] address [size] of Exception Directory 0 [ 0] address [size] of Security Directory 8D000 [ 4488] address [size] of Base Relocation Directory 836EC [ 38] address [size] of Debug Directory 0 [ 0] address [size] of Description Directory 0 [ 0] address [size] of Special Directory 0 [ 0] address [size] of Thread Storage Directory 30468 [ 40] address [size] of Load Configuration Directory 0 [ 0] address [size] of Bound Import Directory 1000 [ 378] address [size] of Import Address Table Directory 0 [ 0] address [size] of Delay Import Directory 0 [ 0] address [size] of COR20 Header Directory 0 [ 0] address [size] of Reserved Directory SECTION HEADER #1 .text name 8274B virtual size 1000 virtual address 82800 size of raw data 400 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 60000020 flags Code (no align specified) Execute Read Debug Directories(2) Type Size Address Pointer cv 23 83728 82b28 Format: RSDS, guid, 2, rpcrt4.pdb ( 10) 4 83724 82b24 SECTION HEADER #2 .orpc name 690D virtual size 84000 virtual address 6A00 size of raw data 82C00 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 60000020 flags Code (no align specified) Execute Read SECTION HEADER #3 .data name EC8 virtual size 8B000 virtual address C00 size of raw data 89600 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers C0000040 flags Initialized Data (no align specified) Read Write SECTION HEADER #4 .rsrc name 408 virtual size 8C000 virtual address 600 size of raw data 8A200 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 40000040 flags Initialized Data (no align specified) Read Only SECTION HEADER #5 .reloc name 4488 virtual size 8D000 virtual address 4600 size of raw data 8A800 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 42000040 flags Initialized Data Discardable (no align specified) Read Only If we look at the optional header values, we can see that the size of the code for the entire module is 0x89200. Now, if you look at the two first sections, [.text] and [.orpc] we can see that [.text] has a size of 0x82800 and [.orpc] has a size of 0x6A00. 0x82800 + 0x6A00 = 0x89200, so far so good. Let’s look closely at those two sections… [.text]: Virtual Address: 0x1000, which goes with the Optional Header. Therefore, the code starts at 0x77E71000 and ends at 0x77EF3800. [.orpc]: Virtual Address: 0x8B000 Therefore, the code starts at 0x77EFB000 and ends at 0x77F01A00. If we were to compute the size of those sections combined we would end up with 0x90A00 which is 0x7800 (30720d) bytes larger than the given code size. [h=3]Section Padding[/h] The 30720 extra bytes are basically just padding. Most are set to zero and some may contain some random looking values. That space between [.text] and [.orpc] is not part of those sections, and its use is unknown. Since it is not declared data or code, we can assume that those bytes can be overwritten. Figure 2. End of .text section As the figure above shows, the end of the [.text] code section ends with some debug info and the rest of the page is padded with zeros. Then, there is more padding until the address reaches 0x77EFB000, which is the start of the [.orpc] section. Those padded gaps are very interesting because they are part of some code section, but obviously are not used. In this particular case, the padding spreads across a fair amount of memory and the protection of that chunk of memory is marked as EXECUTE. Of course, in order to write the shellcode in that spot, we would have to temporarily change the page protection to [W]rite, or call WriteProcessMemory() which would essentially do this for us. Let’s go back to the fictitious ROP exploit I was talking about earlier. Since we know that there is available memory with the proper protection flag, there is no longer a need to bother with VirtualProtect. The compiler used to create the DLL is kind enough to provide our exploit with that little piece of malware heaven. We can now craft a targeted exploit (on the same OS/Service Pack) since we know the location of the padded area, or if we want to be fancy, we could read the sections from the PE header and figure out a spot to write our code into. There is nothing DEP can do about this since the page protection never changes and the shell code resides within the code segment. The only way to detect the shellcode is to validate the address it runs at. For instance, looking at Figure 2, if the shellcode was to be written at [0x77EF3800], we would be able to find it because the section actually ends there. The detection algorithm would have to go through each Code section, calculate the address range and check whether or not the code runs within those limits. By placing the shell code within those tiny gaps in the executable, malware writers could potentially defeat anti-malware software that make sloppy checks as to from where APIs are called. Therefore, it is crucial for the "good guys" to be thorough in their work and to make sure to check every nook and cranny where malware could hide. Emmanuel Thioux on 2012.09.11 Sursa: Malware Intelligence Lab from FireEye - Research & Analysis of Zero-Day & Advanced Targeted Threats:Getting Tricky With Shellcode

Da postati si voi unde apare aia, ca nu am de unde sa stiu: Search, New posts sau cine stie unde.

Baaa, cum sa pui X pe Dinamo - CFR? Se muta la gunoi.

Si cum putem avea garantia ca nu e backdoored? Nu sta nimeni sa analizeze fiecare executabil care se posteaza. Daca are un format video nu e nicio problema. Apoi, desigur, calitatea ar fi mult mai buna. Ai putea incerca sa scapi de aceste aere de expert, nu dau deloc bine.

Ha?

A Guide To Kernel Exploitation.pdf File size: 15972 KB (449 pages). Contents Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii About the Authors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix About the Technical Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi PART I A JOURNEY TO KERNEL LAND CHAPTER 1 From User-Land to Kernel-Land Attacks. . . . . . . . . . . . . . . . 3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Introducing the Kernel and the World of Kernel Exploitation . . . 3 The Art of Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Why Doesn’t My User-Land Exploit Work Anymore?. . . . . . . . . . 9 Kernel-Land Exploits versus User-Land Exploits. . . . . . . . . 11 An Exploit Writer’s View of the Kernel. . . . . . . . . . . . . . . . . . . . . . 13 User-Land Processes and the Scheduler . . . . . . . . . . . . . . . . . . 13 Virtual Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Open Source versus Closed Source Operating Systems . . . . . . . . 18 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Related Reading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Endnote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 CHAPTER 2 A Taxonomy of Kernel Vulnerabilities. . . . . . . . . . . . . . . . 21 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Uninitialized/Nonvalidated/Corrupted Pointer Dereference. . . . . 22 Memory Corruption Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Kernel Stack Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Kernel Heap Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Integer Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 (Arithmetic) Integer Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Sign Conversion Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Race Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Logic Bugs (a.k.a. the Bug Grab Bag). . . . . . . . . . . . . . . . . . . . . . . . 39 Reference Counter Overflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Physical Device Input Validation. . . . . . . . . . . . . . . . . . . . . . . . 40 Kernel-Generated User-Land Vulnerabilities. . . . . . . . . . . . . 41 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Endnotes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 CHAPTER 3 Stairway to Successful Kernel Exploitation. . . . . . . . . . 47 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 A Look at the Architecture Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Generic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 x86 and x86-64. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 The Execution Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Placing the Shellcode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Forging the Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 The Triggering Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Memory Corruption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 The Information-Gathering Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 What the Environment Tells Us. . . . . . . . . . . . . . . . . . . . . . . . . 91 What the Environment Would Not Want to Tell Us: Infoleaks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Related Reading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 PART II THE UNIX FAMILY, MAC OS X, AND WINDOWS CHAPTER 4 The UNIX Family. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 The Members of the UNIX Family. . . . . . . . . . . . . . . . . . . . . . . . . . 104 Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Solaris/OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 BSD Derivatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 The Execution Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Abusing the Linux Privilege Model. . . . . . . . . . . . . . . . . . . . 126 Practical UNIX Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Kernel Heap Exploitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Attacking the OpenSolaris Slab Allocator . . . . . . . . . . . . . . 139 Attacking the Linux 2.6 SLAB^H^HUB Allocator. . . . . . 160 Attacking (Linux) Kernel Stack Overflows. . . . . . . . . . . . . 177 Revisiting CVE-2009-3234. . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Endnotes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 CHAPTER 5 Mac OS X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 An Overview of XNU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Mach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 BSD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 IOKit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 System Call Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Kernel Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Kernel Extensions (Kext) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 IOKit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Kernel Extension Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 The Execution Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Exploitation Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Arbitrary Memory Overwrite . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Stack-Based Buffer Overflows. . . . . . . . . . . . . . . . . . . . . . . . . 239 Memory Allocator Exploitation . . . . . . . . . . . . . . . . . . . . . . . . 253 Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Snow Leopard Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Endnotes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 CHAPTER 6 Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Windows Kernel Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Kernel Information Gathering. . . . . . . . . . . . . . . . . . . . . . . . . . 272 Introducing DVWD: Damn Vulnerable Windows Driver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Kernel Internals Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . 278 Kernel Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 The Execution Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Windows Authorization Model. . . . . . . . . . . . . . . . . . . . . . . . . 286 Building the Shellcode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Practical Windows Exploitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Arbitrary Memory Overwrite . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Stack Buffer Overflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Endnotes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 PART III REMOTE KERNEL EXPLOITATION CHAPTER 7 Facing the Challenges of Remote Kernel Exploitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Attacking Remote Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Lack of Exposed Information. . . . . . . . . . . . . . . . . . . . . . . . . . 344 Lack of Control over the Remote Target. . . . . . . . . . . . . . . 347 Executing the First Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Direct Execution Flow Redirection . . . . . . . . . . . . . . . . . . . . . 349 Arbitrary Write of Kernel Memory. . . . . . . . . . . . . . . . . . . . . 360 Remote Payloads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Payload Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Endnote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 CHAPTER 8 Putting It All Together: A Linux Case Study. . . . . . . . 385 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 SCTP FWD Chunk Heap Memory Corruption . . . . . . . . . . . . . . . 386 A Brief Overview of SCTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 The Vulnerable Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Remote Exploitation: An Overall Analysis . . . . . . . . . . . . . . . . . . . 393 Getting the Arbitrary Memory Overwrite Primitive . . . . . . . . . . . 394 Remotely Adjusting the Heap Layout. . . . . . . . . . . . . . . . . . 395 Building SCTP Messages: From Relative to Absolute Memory Overwrite. . . . . . . . . . . . . . . . . . . . . . . . 397 Installing the Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Directly Jumping from Interrupt Context to User Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Executing the Shellcode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Checking the Current Process and Emulating the gettimeofday() function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Executing the Connect-Back. . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Recovering the Vsyscall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Related Reading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Endnote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 PART IV FINAL WORDS CHAPTER 9 Kernel Evolution: Future Forms of Attack and Defense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Kernel Attacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 Kernel Defense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 Kernel Threat Analysis and Modeling. . . . . . . . . . . . . . . . . . 425 Kernel Defense Mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Kernel Assurance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 Beyond Kernel Bugs: Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . 432 Hypervisor Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 Guest Kernel Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Index.......................................................................................................................437 Download: http://www.pdf-archive.com/2011/02/24/a-guide-to-kernel-exploitation/ http://www.multiupload.nl/EGTCK09D6R

E tutorial video. Posteaza o versiune .swf, .mp4, .avi sau orice alt format accesibil te rog, nu .exe...

Directory structure of www file store. • www/appserv AppServ file, you can delete it after install. • www/index.php AppServ index.php file you can delete it after install. Deci nu e niciun XSS in Apache, si "exploit-ul" e un rahat, mai ales pentru ca cica: "Security -::RISK: Critical". E problema in rahatul de pagina web a AppServ.

Am scos, postati aici daca mai au si altii.

NU e Apache, e AppServ ala, ce-o mai fi si el. Am redenumit topicul.

Hidden Rootkit Process Detection [TABLE] [TR] [TD=class: page_subheader]Contents [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Introduction to Rootkits Userland Rootkit & their Hidden Operations Hidden Userland Rootkit Process Detection Methods Direct NT System Call Implemenation HPD using PIDB (Process ID Bruteforce) method HPD with CSRSS Process Handle Enumeration [*] Other Methods of Detecting Hidden Processes [*] References [/TD] [/TR] [TR] [TD] [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: page_subheader]Introduction to Rootkits [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Rootkits are one of the advanced species in today's every changing technical world. They are known for their sophisticated techniques to hide their presence often evading their detection from top notch Antiviruses and detection tools. Antivirus solutions often hit the wall when it comes to Rootkit detection and there is a greater need for dedicated Anti-Rootkit tools. Rootkits use combination of user land and kernel level techniques to evade their detection. In this article we will throw light on how userland Rootkits work under the hood and different techniques which can be used to detect such Rootkits. Though these methods are effective only against user land Rootkits, in some cases they can even detect kernel based Rootkits unless they haven't taken proper care to remove all those traces. [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Userland Rootkits & their Hidden Operations [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Userland Rootkits use different techniques to hide their process and to prevent its termination. One such method is to hook the NtOpenProcess function (OpenProcess API internally calls NtOpenProcess) and return negative result whenever Anti-Rootkit application try to open such process. As a result Rootkit process will remain hidden from any process viewer tools. This is just one of the method and often you will find more such internal functions such as NtQuerySystemInformation being hooked to filter out their process from the list. [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Hidden Userland Rootkit Process Detection Methods [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Detection of hidden process is equally challenging as Rootkit can employ one or more methods to cover its presence. Here are some of the very effective methods to detect such userland Rootkit processes. All these detection methods work on common approach. First they get the list of all running processes using standard API functions such as EnumProcesses or Process32First. Then one or more special methods mentioned below are used to enumerate the processes. Finally this new process list is compared with previously obtained list and any new process found in this new list is detected as hidden rootkit process. [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]HPD using Direct NT System Call Implemenation [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] This is very effective method to detect any hidden userland rootkit processes. One of the lesser-known methods of enumerating the processes is to use NtQuerySystemInformation function by passing first parameter as SystemProcessesAndThreadsInformation. The drawback of this method is that it can be easily circumvented by hooking the NtQuerySystemInformation function and then by tampering with the results. The NtQuerySystemInformation is basically stub having few lines of code to transition from user to kernel land. It finally calls the NtQuerySystemInformation function within the kernel. So the trick here is to implement the NtQuerySystemInformation without directly calling the function. Here is the sample code that shows how one can directly implement NtQuerySystemInformation on various platforms. On Windows2000, INT 2E and from XP onwards 'sysenter' instruction is used to transition from user to kernel. [/TD] [/TR] [/TABLE] __declspec(naked) NTSTATUS __stdcall DirectNTQuerySystemInformation (ULONG SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength) { //For Windows 2000 if( OSMajorVersion == 5 && OSMinorVersion == 0 ) { __asm { mov eax, 0x97 lea edx, DWORD PTR ss:[esp+4] INT 0x2E ret 0x10 } } //For Windows XP if( OSMajorVersion == 5 && OSMinorVersion == 1 ) { __asm { mov eax, 0xAD call SystemCall_XP ret 0x10 SystemCall_XP: mov edx, esp sysenter } } //For Windows Vista & Longhorn if( OSMajorVersion == 6 && OSMinorVersion == 0 ) { __asm { mov eax, 0xF8 call SystemCall_VISTA ret 0x10 SystemCall_VISTA: mov edx, esp sysenter } } //For Windows 7 if( OSMajorVersion == 6 && OSMinorVersion == 1 ) { __asm { mov eax, 0x105 call SystemCall_WIN7 ret 0x10 SystemCall_WIN7: mov edx, esp sysenter } } } } [TABLE] [TR] [TD]This technique can discover any userland rootkit process and only way for rootkit process to defeat against this technique is to move into kernel. However, due to low-level implementation, there is slight risk in using this method in production code.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]HPD using PIDB (Process ID Bruteforce) method [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] This method was first used by BlackLight and it turned out to be very effective yet simple. Here, it enumerates through process id from 0 to 0x41DC and then check if that process exist by calling OpenProcess function. Then this list of discovered processes are compared with normal process list got using standard enumeration functions (such as Process32First, EnumProcesses functions). During the testing, it is found that some process id on server machines were more than magic number 0x41DC. So in order to be effective the magic number is doubled to take care of all possible running processes on latest operating systems. Here is the sample code that implements PIDB method: [/TD] [/TR] [/TABLE] for(int i=0; i < 0x83B8; i+=4) { //These are system idle and system processes if( i == 0 || i==4 ) { continue; } hprocess = OpenProcess (PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, i); if( hprocess == NULL ) { if( GetLastError() != ERROR_INVALID_PARAMETER) { // If the error code is other than // ERROR_INVALID_PARAMETER that means this // process exists but we are not able to open. //check if this process is already discovered //using standard API functions. if( IsHiddenProcess(i) ) { printf("\n Hidden process found %d", i); } } continue; } dwExitCode = 0; GetExitCodeProcess(hprocess, &dwExitCode); // check if this is active process... // only active process will return error // code as ERROR_NO_MORE_ITEMS if( dwExitCode == ERROR_NO_MORE_ITEMS ) { //check if this process is already discovered if( IsHiddenProcess(i) ) { printf("\n Hidden process found %d", i); } } CloseHandle(hprocess); } [TABLE] [TR] [TD]Though this is very effective method, rootkit can easily defeat this technique by hooking OpenProcess or its native version NTOpenProcess function and then returning NULL with error code as ERROR_INVALID_PARAMETER. To defend against such tricks anti-rootkit softwares can call NtOpenProcess using direct system call method as shown in "Detection of Hidden Process using Direct NT System Call Implemenation".[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]HPD with CSRSS Process Handle Enumeration [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Any windows process when run will have lot of open handles realted to process, thread, named objects, file, port, registry, etc. that can be used to detect hidden process. One can use the native API function. The effective way to enumerate handles is to use NtQuerySystemInformation with first parameter as SystemHandleInformation. It lists the handles from all running processes in the system. For each enumerated handle, it provides information such as handle, handle type and process id of the owning process. Hence, by enumerating through all the handles and then using the associated process id, one can detect all possible hidden processes that are not revealed through standard API functions. There is one interesting system process called CSRSS.EXE, which holds the handles to all running processes. So instead of going through all the different handles, one can just scroll through the process handles of CSRSS.EXE process. Interestingly this method can, not only detect userland hidden processes but also some of the rootkit processes which have used kernel land techniques without taking care of hiding process handles within CSRSS.EXE process. Here is the code snippet, which can demonstrate this method: [/TD] [/TR] [/TABLE] PVOID bufHandleTable = malloc(dwSize); status = NtQuerySystemInformation (SystemHandleInformation, bufHandleTable, dwSize, 0); SYSTEM_HANDLE_INFORMATION *HandleInfo = (SYSTEM_HANDLE_INFORMATION *) bufHandleTable; // Process handles within CSRSS will not have handle // to following processes system idle process, system // process, smss.exe, csrss.exe. for(int i=0; i< HandleInfo->NumberOfHandles; i++) { int pid = HandleInfo->Handles[i].UniqueProcessId; // For XP & 2K3 : HANDLE_TYPE_PROCESS = 0x5 // For Vista & Longhorn : HANDLE_TYPE_PROCESS = 0x6 if( HandleInfo->Handles[i].ObjectTypeIndex == HANDLE_TYPE_PROCESS) { //check if this process id is that of CSRSS.EXE process. if( IsCSRSSProcess(pid) ) { hprocess = OpenProcess(PROCESS_DUP_HANDLE, false, pid); if( hprocess ) { if( DuplicateHandle(hprocess, (HANDLE)HandleInfo->Handles[i].Handle, GetCurrentProcess(), &tprocess, PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, 0)) { targetPid = GetProcessId(tprocess); //check if this is hidden process if( IsHiddenProcess(targetPid) ) { printf("\n Found hidden process %d", targetPid); } } }// End of if( hprocess ) } // End of if( IsCSRSSProcess(pid) ) } // End of if } // End of for-loop [TABLE] [TR] [TD]Since the CSRSS.EXE is not first process started when Windows boots, it does not contains handles to already started processes such as system idle process(pid=0), system process (pid=4), smss.exe and its process itself. On Windows Vista system it is possible to more than one CSRSS.EXE process in case of multiple users logged in. Same situation arises on XP system, when more than one user is operating through 'Switch User' mechanism. In such case, one has to check if the enumerated process belongs to any of these CSRSS process ids. The function IsCSRSSProcess() above does exactly the same by comparing the discovered process id with list of all running CSRSS.EXE processes. One more way is to enumerate all thread handles within CSRSS process instead of process handles, as most rootkits are aware of this technique. The CSRSS process not only has process handles but also thread handles for every running processes. Once the thread handle is known, one can use GetProcessIdOfThread function to get process id associated with that thread after duplicating it. Though any rootkit process can defeat this technique by hooking NtQuerySystemInformation or NtOpenProcess function, it can easily be circumvented by using direct implementation of these native API functions as described in the "Detection of Hidden Process using Direct NT System Call Implemenation". [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Other Methods of Detecting Hidden Processes [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] There exists several other userland methods to detect hidden rootkit processes, but they are not as effective as the ones described above. However they can be used on need basis and often to target specific rootkit. One such method is to enumerate through all the open Windows created by the processes within the system using EnumWindows API function and then calling the GetWindowThreadProcessId function to get the process id associated with that Window. Here is the sample code that does the same... [/TD] [/TR] [/TABLE] //Setup the callback function to enumerate through windows EnumWindows(EnumWindowsProc, NULL); //This is callback function to enumerate windows BOOL CALLBACK EnumWindowsProc(HWND hwnd, PARAM lParam) { DWORD procId; GetWindowThreadProcessId(hwnd, &procId); if( IsHiddenProcess(procId) ) { printf("Found hidden process %d", procId); } } There exist several other ways to detect the hidden processes in user land and new ways are being discovered everyday. Though these detection techniques can be easily defeated from kernel land, they present simple and less risky mechanism to uncover the userland rootkits. [TABLE] [TR] [TD=class: page_subheader]References [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]1. Detection of Hidden Processes 2. Hiding Rootkit process from CSRSS Handle Enumeration Method[/TD] [/TR] [TR] [TD] [/TD] [/TR] [/TABLE] Sursa: Hidden Rootkit Process Detection - www.SecurityXploded.com

Hidden Registry Detection [TABLE] [TR] [TD=class: page_subheader]Contents[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Introduction to Registry Rootkit & Reason to Hide Registry Art of Detecting Hidden Registry Keys Hidden Registry Detection using Direct NT System Call Method Hidden Registry Detection by Directly Reading Registry Hives Conclusion References [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: page_subheader]Introduction to Registry [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Registry is the large database where Windows stores all the system, security and software specific settings. It is a tree like structure, which can be viewed or modified using the standard windows utilities such as Regedit.exe (start->run-> regedit) . [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD] In addition to all system settings, Registry also contains various startup entries for processes and services that are automatically started when Windows starts. For example, all Windows services are stored under the following Registry key, [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD="class: page_code"]'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services'. [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD]Similarly some of the startup process entries can be found in the following Registry locations, [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD="class: page_code"]HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, [B] HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\explorer\Run[/B] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Rootkit & Reason to Hide Registry [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Rootkits generally modifies these entry points to start their own processes, services or drivers. So it's important for the Rootkit to hide these registry entries to prevent its detection from various system-monitoring tools such as Autoruns, HijackThis, etc.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] Rootkits use various methods to hide their registry infiltration. One of the most commonly used techniques is hooking the registry API functions such as RegOpenKey, RegEnumKey, RegEnumValue etc. All of these top level API functions in turn will call low level NT functions such as NTOpenKey, NtEnumerateKey and NtEnumerateValueKey etc. So in order to be more effective, Rootkits typically hook NT version of these functions. As a result whenever any application calls these registry functions, Hooked Rootkit function will return the filtered results there by hiding its presence.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Art of Detecting Hidden Registry Keys [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Most common detection mechanism used in these cases is the cross-view comparison method. In this method initially, high level registry API functions (such as RegEnumKey, RegEnumValue) are used to enumerate the keys and values. Next some of the advanced techniques are used to enumerate the same registry keys. Then the both results are compared to find out the hidden Rootkit entries. Many such lower level techniques are present to detect hidden registry keys. Here we will discuss about two such prominent methods in detail. [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Hidden Registry Detection using Direct NT System Call Method [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] As mentioned previously, Rootkits hide their registry entries by hooking the lower level NT functions. In order to effectively detect these entries, one can directly invoke those NT functions rather than using API functions. Every NT function in Windows is uniquely identified through its service number (For NtEnumerateKey its 0x47). So instead of calling these NT functions, one can directly call these functions by using INT 2E (for Windows 2K) or Sysenter (Windows XP onwards) instruction by passing the respective service number. Here is the direct implementation of NtEnumerateKey and NtEnumerateValueKey function, which can be directly called to bypass any API level hooks put by the Rootkits. [/TD] [/TR] [/TABLE] //For Windows XP, for other platforms only service number will differ _declspec(naked) NTSTATUS __stdcall DirectNtEnumerateKey( IN HANDLE KeyHandle, IN ULONG Index, IN KEY_INFORMATION_CLASS KeyInformationClass, OUT PVOID KeyInformation, IN ULONG KeyInformationLength, OUT PULONG ResultLength ) { __asm { mov eax, 0x47 call DirectCall_XP ret 0x18 DirectCall_XP: mov edx, esp sysenter } } //For Windows XP, for other platforms only service number will differ _declspec(naked) NTSTATUS __stdcall DirectNtEnumerateValueKey( IN HANDLE KeyHandle, IN ULONG Index, IN KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass, OUT PVOID KeyValueInformation, IN ULONG KeyValueInformationLength, OUT PULONG ResultLength ) { __asm { mov eax, 0x49 call DirectCall_XP ret 0x18 DirectCall_XP: mov edx, esp sysenter } } Rootkits may also hook the NtOpenKey function to prevent any hidden key from being opened. So it will become useless even if one is able to discover the key name. In such case, one can use direct NtOpenKey function as shown below... //Note that this code is written for Windows XP. For other platforms only service number will differ _declspec(naked) NTSTATUS __stdcall DirectNtOpenKey( OUT PHANDLE KeyHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes ) { __asm { mov eax, 0x77 call DirectCall_XP ret 0x0C DirectCall_XP: mov edx, esp sysenter } } [TABLE] [TR] [TD]Though Rootkits can bypass this technique by hooking the above-mentioned NT functions in the kernel, it presents simple but very effective mechanism to detect any hidden Rootkit registry entries in user land.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Hidden Registry Detection by Directly Reading Registry Hives [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] Windows stores the entire registry contents into the different files called Hives in a standard format. A different portion of registry is stored in respective hive files such as SYSTEM, SOFTWARE, SECURITY, SAM, etc. in the 'C:\Windows\System32\Config' folder. Here is the table showing the mapping between the registry section and corresponding registry hive file. [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [TABLE=class: page_code_reg_table, width: 550] [TR] [TD=class: page_cell_reg_table_header]Registry Key Name[/TD] [TD=class: page_cell_reg_table_header]Hive Filename[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_CURRENT_USER[/TD] [TD=class: page_cell_reg_table_border]NTuser.dat[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_LOCAL_MACHINE\SAM[/TD] [TD=class: page_cell_reg_table_border]SAM[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_LOCAL_MACHINE\SECURITY[/TD] [TD=class: page_cell_reg_table_border]SECURITY[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_LOCAL_MACHINE\SOFTWARE[/TD] [TD=class: page_cell_reg_table_border]SOFTWARE[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_LOCAL_MACHINE\SYSTEM[/TD] [TD=class: page_cell_reg_table_border]SYSTEM[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_USERS\DEFAULT[/TD] [TD=class: page_cell_reg_table_border]DEFAULT[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border][/TD] [TD=class: page_cell_reg_table_border] [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] Though the internal format of these registry hive file is undocumented, lot of code samples and good amount of documentation can be found on the net. These hive files are generally locked while Windows is running and hence remains inaccessible. However if you like to understand internal storage structure of these hive files, you can use the API function such as RegSaveKey (or equivalent NT function NtSaveKey) to save any registry section to the chosen file. Then you can manually traverse through this hive file to decipher the low level of registry entries. Detailed code sample to traverse the hive file can be found in the article [1] 'How to avoid the detection of hidden regkey by hooking RegSaveKeyA' written by EiNSTeiN_. Also the whitepaper [2] 'Detection of Rootkits in Windows registry' by miel-labs explains in detail the complete structure of registry hive file. In this detection method, all registry entries are retrieved by traversing through these hive files. Then this list is compared against the high level list obtained through normal registry API functions such as RegEnumKey, RegEnumValue etc. At the end any additional entries discovered will be marked as Hidden Rootkit registry entries. Though this method involves using undocumented registry hive traversal method, it is very effective method in detecting the registry entries hidden through even the Kernel level hooks (such as SSDT hooks). [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Conclusion [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]This article shows why Rootkits hide their registry entries and some of the methods which can be used to detect such hidden entries to reveal the traces of Rootkits. Though some of these techniques can be bypassed by Rootkits operating in Kernel land, these methods present very simple and powerful methods to detect any registry entries hidden by userland Rootkits.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]References [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]1. How to avoid the detection of hidden regkey by hooking RegSaveKeyA 2. Detection of Rootkits in Windows registry 3. How to become unseen on Windows NT by HxDef[/TD] [/TR] [TR] [TD] [/TD] [/TR] [/TABLE] Sursa: Hidden Registry Detection - www.SecurityXploded.com

Am vazut ca incepe cu dork-uri, nu stau sa citesc pentru ca sunt sigur ca e o porcarie. Nu cauti "orice" site, vulnerabil sa fie, ori ai un motiv, ori iti vezi de treburile tale, nu ataci site-uri la intamplare de dragul de a incerca sa pari 1337.

[h=2]Protectie SMS[/h]Published on septembrie 9th, 2012 by Bogdan Alecu in Android, Securitate, SMS ?i s-a întâmplat vreodat? s? prime?ti un SMS de la un num?r care nu exist?? Ai primit mesaje de la diverse campanii electorale ce p?reau a veni din partea operatorului de telefonie? Dar mesaje cu un expeditor modificat? Sunt convins c? o parte vor r?spunde cu DA la cel pu?in una din aceste întreb?ri. Din p?cate în cazul SMS-urilor nu avem cum ?ti dac? ele vin din partea operatorului, din partea b?ncii, etc. S? ne imagin?m urm?torul scenariu: utilizatorul prime?te un mesaj venind din partea serviciului clien?i, în care este anun?at c? a câ?tigat o ma?in?. Totodat? utilizatorului i se spune s? sune la un anumit num?r pentru a confirma premiul. Num?rul poate fi cu supratax? sau nu. Sunt convins c? mul?i ar c?dea prad? acestor tipuri de mesaje. Astfel mul?i ar suna ?i ar pl?ti 2 EUR / min sau ?i-ar da datele personale întrucât, nu-i a?a, expeditorul e Serviciul Clien?i. Sau ?i mai bine hai s? ne imagin?m c? mesajul vine din partea b?ncii. Sunt nepl?cute aceste situa?ii ?i nu avem cum s? ne protej?m de ele. Ei bine, acum exist? ?i solu?ia. SMS Protect – o aplica?ie ce te anun?? în momentul primirii mesajului dac? acesta este legitim sau nu. Destul de interesant, nu? Întrucât este în varianta pre-beta ?i sunt convins c? nu va func?ia chiar perfect pe toate telefoanele a?a cum trebuie, o pute?i desc?rca ?i folosi gratuit. Disponibil? doar pe Android, versiunile de la 2.2 în sus. Cum func?ioneaz? aplica?ia? Se instaleaz? pe telefon (aten?ie c? trebuiesc acordate mai întâi permisiuni de a instala aplica?ii ce nu vin din Google Play) ?i asta e tot. În momentul în care ve?i primi un SMS, aplica?ia va afi?a în partea de jos o informare asupra acestui SMS primit – dac? e unul real sau unul fals. A?a cum spuneam, e într-o variant? simplist?, iar dac? ave?i telefonul în stand-by (ecranul oprit) ?i nu v? uita?i pe ecran imediat ce a?i primit mesajul, nu ve?i putea ?ti dac? mesajul e unul real sau nu întrucât acel tooltip de informare nu st? decât vreo 2 secunde pe ecran. Repet – asta e varianta actual?. SMS Protect func?ioneaz? pentru toate tipurile de mesaje primite: normale, WAP Push, flash, etc. Iat? ?i cum func?ioneaz? (da?i pe 720p) ATEN?IE! Aplica?ia nu con?ine niciun fel de malware. E posibil ca anumite solu?ii de protec?ie s? o raporteze ca troian, îns? nu este cazul. Am raportat deja ca fiind false positive. A?a cum a?i v?zut ?i în film, solu?ia BitDefender spune c? aplica?ia e curat?. Am de gând s? o dezvolt ?i s? ofere loguri pentru a vedea exact cine ?i când v-a trimis un mesaj fals. Cel mai probabil va fi o variant? pl?tit?, disponibil? pe Google Play. A?tept reac?iile privind SMS Protect pentru o prim? aplica?ie dezvoltat? de mine personal,?inând cont c? nu ?tiu programare, e prima dat? când fac a?a ceva iar timpul de lucru cu instalarea de la zero a masinilor de test, mediului de dezvoltare, etc a fost de aproximativ 5 ore. Sursa: Technology Blog - Protectie SMS Felicitari...

[h=2]La ce sunt bune jocurile violente pe calculator[/h]9 septembrie 2012, 11:37 | Autor: C?t?lina Mihu | 553 afi??ri De?i îndelung criticate pentru violen?a grafic? excesiv?, jocurile sângeroase pe calculator aduc ?i beneficii, conform unui studiu re recent al Universit??ii Keele, din Marea Britanie. Avantajul descoperit de cercet?torii britanici este acela c? „gamerii” care împu?c? du?mani virtuali, în jocuri, au o toleran?? la durere cu pân? la 65% mai ridicat? decât persoanele care nu au acest hobby, informeaz? Daily Mail. Cei 40 de voluntari care au participat la experimentul f?cut de Universitatea Keele au putut îndura durerea fizic? cu pân? la 65% mai mult dup? jocuri „first person shooter” (cu împu?c?turi, din perspectiva juc?torului), în compara?ie cu cei care jucaser? golf pe calculator. Participan?ii au jucat timp de 10 minute atât un joc violent, cât ?i unul pa?nic, în dou? ocazii diferite, ca parte a experimentului. Ulterior, ?i-au introdus o mân? în ap? rece ca ghea?a pentru a li se testa reac?ia la durere. În medie, voluntarii au reu?it s?-?i ?in? mâna în apa înghe?at? cu 65% mai mult dup? ce jucaser? un joc violent, „shooter”. Un alt efect înregistrat de cercet?tori a fost pulsul ridicat al acestor participan?i. Cercet?torii sugereaz?, în urma acestui experiment, c? toleran?a ridicat? la durere ?i pulsul ridicat pot fi atribuite r?spunsului natural al organismului la stress: creierul activeaz? inhibitori ai durerii. „Acest studiu ?i-a propus s? testeze presupunerea conform c?reia cre?terea nivelului agresiunii, printr-un joc video violent, va cre?te toleran?a la durere. Rezultatul confirm? presupunerile noastre c? aceste jocuri video cresc sentimentele de agresivitate ?i toleran?a la durere”, spunea Richard Stephens, doctor în psihologie ?i lector la Universitatea Keele. „Cercet?torii în domeniu au explorat deja utilizarea realit??ii virtuale pentru a ajuta oamenii s? tolereze mai u?or durerea fizic?”, cel pu?in pe termen scurt, a ad?ugat Stephens. Studiul este o continuare a unuia în acela?i domeniu, în care aceea?i echip? de cercet?tori demonstra c? înjur?turile cresc toleran?a oamenilor la durere. Sursa: La ce sunt bune jocurile violente pe calculator

[h=1]Adev?ratul "Big Brother". FBI a dezvoltat un sistem performant de identificare care te poate g?si oriunde[/h] FBI-ul a început s? ruleze oficial noul program de recunoa?tere facial? (NGI), pe care a început s?-l dezvolte în 2005 ?i în care a investit miliarde de dolari. Sistemul vine ca o completare a programului de identificare a amprentelor care ruleaz? la nivel na?ional ?i va fi instalat în toate statele pân? la finalul anului 2014, scrie rt.com. "Rolul programului NGi este de a reduce rata criminalit??ii ?i terorismul prin accesul autorit??ilor din toat? ?ara la o baz? de date cu cât mai multe informa?ii biometrice", scrie într-un comunicat FBI Oficialii FBI au declarat c? în urma testelor pe care le-au f?cut în acest an, în statul Michigan, dintr-o baz? de date de 1,6 milioane de fotografii programul a identificat corect o persoan? în 92% din cazuri. Baza de date NGI va include peste 14 milioane de fotografii în urm?torii doi ani, iar pentru o identificare cât mai exact?, programul va folosi ?i datele publice de pe re?elele sociale Facebook ?i Google. Lansarea programului NGI a stârnit ?i reac?ii negative, unii politicieni fiind de p?rere c? încalc? flagrant dreptul la intimitate: "Când cineva are amprenta ta facial?, î?i poate afla numele, î?i poate g?si conturile de pe re?elele sociale ?i poate afla în orice moment pe ce strad? e?ti sau când cineva posteaz? o fotografie cu tine online. Asta poate înc?lca dreptul la via?? privat?", a declarat senatorul american Al Franken Sursa: Adev?ratul "Big Brother". FBI a dezvoltat un sistem performant de identificare care te poate g?si oriunde - Gandul

Da, face o treaba excelenta Vivek.

uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu

zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz