Nytro

Pe langa faptul ca e o porcarie, uite cata rahatul: for(i=0;i<1;i++)

Daca nu e ceva strict, poti trimite date din server cand exista. Problema e cu keep-alive-ul, dupa ceva timp, ti se taie conexiunea daca nu se trimit date. Cred ca e ok sa faci un request la 15-20 de secunde, desi nu e rapid, nu faci tone de trafic. Dar mai simplu e sa pastrezi o conexiune activa, cu pachete de keep-alive, si din server trimiti datele cand apar.

Eu. Dar nu sunt convins de idei. Cine voteaza? Pe cine? De ce? Pe ce criterii se aleg? Cand se voteaza? Cat timp se voteaza? Conteaza detalii ca vechime, numarul de posturi, numarul de like-uri sau reputatia acelui user?

POC or didn't happen

Cred ca daca pun la vot, "Cati vreti sa NU mai fiu administrator", am o vaga impresie ca va trebui sa imi dau demisia Nu, daca noi decidem ca un moderator a gresit, discutam cu el si se rezolva. Apoi, 5 noiembrie? Cu asta ai stricat tot.

Cu ce l-ar incanta pe un utilizator sa vada IP-urile cu care a intrat? Sigur, sa poata vedea daca altcineva a intrat pe contul sau, dar presupunandu-se ca e un forum de securitate IT, nu prea ar trebui sa fie cazul... PS: Acum ceva timp, tex a dat un UPDATE ... SET ipaddress = "127.0.0.1", fara WHERE, deci intelegti cam care e ideea.

Membri: 85,146 Sa vedeti cati vor fi diseara. :-> Continua Polonic.

Linux Gaming News: Vote on Your Linux Games Now We've known for a while that Valve is bringing Steam to Linux. One of the most exciting Steam projects for Linux gamers is... || Join the chat: http://bit.ly/nixgoogleplus || Steam Greenlight, where we, the gamers, can vote on which games we want to see made. In this week's OS.ALT I discuss Steam Greenlight and how it impacts Linux Games. Via: Facebook...

Merge greu

Live streaming: http://www.privesc.eu/Arhiva/12404/Marsul-unionist-din-16-septembrie-2012 Am scos si eu steagul cu Romania pe geam.

Warn - Categorie gresita.

Acum, haideti cel putin sa incercam, sa vedem ce iese. Vom discuta cei din staff, si vom face categoria respectiva, sper ca diseara.

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.