Nytro

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

Test

Majoritatea a decis.

Pentru ca nu o sa fie pe RST, in banner, poza cu cine stie ce boschetar de pe aici.

[h=2]DLL Injection and Windows 8[/h]By Nagareshwar Talekar on Sep 7 2012 Recently while working on new version of RemoteDLL, I discovered interesting changes around DLL injection on Windows 8. Before I actually talk about new changes, here is little background story. CreateRemoteThread is most common method used for DLL injection. It used to work flawlessly till Windows XP. However since Vista, it changed the colors, mainly it could no more inject DLL across sessions. This was attributed to new ‘Session Separation’ feature introduced in Vista. To beat that limitation, we discovered new undocumented method NTCreateThread which could inject DLL across session boundaries on Vista/Win7. Now while testing RemoteDLL on Windows 8, I tried (halfheartedly) injecting DLL into process running in Session 0. And to my utter surprise it worked just like magic in old days. I tried again to make sure that I am not dreaming So it looks like M$ has put things back in order. The question arises whether CreateRemoteThread changes in Vista was done intently or accidentally. Because we could still use NTCreateThread with little risk. Quick analysis point us to other direction. CreateRemoteThread actually calls NTCreateThread somewhere down the layer. May be some extra checking code that was added in Vista actually caused CreateRemoteThread to exit. So it is possible that this extra code was for something else but it adversely blocked injection across sessions. Now Microsoft may have realized the problem and must have fixed it to work normally. On the other hand, CreateRemoteThread have legitimate uses and certainly some of its big customers may have made the noise To conclude, now CreateRemoteThread works well in Windows 8 across sessions (tested with consumer edition). However we still have to rely on NTCreateThread on Vista/Win7 for injection beyond session boundaries. Another notable change that I have observed is w.r.t Reference Count or Load Count for DLLs. Few years back, we have written research article ‘The covert way to find the Reference Count of DLL’ explaining about hidden/undocumented Load Count field in LDR_MODULE structure. struct _LDR_MODULE { LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; USHORT LoadCount; USHORT TlsIndex; LIST_ENTRY HashTableEntry; ULONG TimeDateStamp; } LDR_MODULE, *PLDR_MODULE; PEB within each process stores information on all Loaded DLLs in an linked list. Each dll in this list is represented by LDR_MODULE structure. One of the important but undocumented field here is ‘LoadCount’ (reference count of dll). This ‘Load Count’ plays an important role in deciding when the DLL has to be completely unloaded from the process. It is also useful in Removing Injected DLL from the running process. Even our tools, RemoteDLL and SpyDLLRemover use it while removing Malware DLLs from process. Here is the screenshot of RemoteDLL showing Load Count for all DLLs in selected process. As you see LoadCount for static DLL is set to -1 as usual but for dynamically loaded DLLs it is set to 6. So where the hell it has gone? It has to be somewhere as every process needs it. It is possible that LDR_MODULE structure may have changed or some of its fields may have altered or it is moved somewhere else altogether. We have to dig further. This is just the tip of iceberg, more reversing will reveal the real truths. And as I discover more, I will put it here. Meanwhile if you find any interesting things around it do share ! Sursa: DLL Injection and Windows 8 | SecurityXploded Blog

E updated acum, votati, va dati acolo cu parerea.

Votul nu este neaparat decisiv, nu stim inca ce vom face cu headerul, dar vrem sa vedem care va plac mai mult. Poate le punem aleator, nu stim inca. Votati-le pe TOATE care va plac, nu unul singur. Votati bannerele preferate: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

Cica luam virusi din filme, asa a zis un nene in filmulet

[h=1]New Attack Uses SSL/TLS Information Leak to Hijack HTTPS Sessions[/h]September 5, 2012, 1:27PM by Dennis Fisher There is a feature supported by the SSL/TLS encryption standard and used by most of the major browsers that leaks enough information about encrypted sessions to enable attackers decrypt users' supposedly protected cookies and hijack their sessions. The researchers who developed the attack that exploits this weakness say that all versions of TLS are affected, including TLS 1.2, and that the cipher suite used in the encrypted session makes no difference in the success of the attack. The attack was developed by researchers Juliano Rizzo and Thai Duong, the same pair who last year released details of a similar attack on SSL/TLS and wrote a tool called BEAST, which also gave them the ability to decrypt users' cookies and hijack sessions with sensitive sites such as e-commerce or online banking sites. That attack targeted a specific problem with the AES (Advanced Encryption Standard) algorithm as it was implemented in TLS 1.0 and SSL 3.0 and were able to use the BEAST tool to grab encrypted cookies from active user sessions that were supposedly protected by SSL/TLS. Once they had the cookie, Rizzo and Duong could return to whatever site the user was visiting and log in using her credentials. The attack caused quite a stir in the security and cryptography communities and browser vendors were forced to issue fixes. One of the workarounds that defeated BEAST (Browser Exploit Against SSL/TLS) was to switch from TLS 1.0 to TLS 1.2 or to switch from AES to the RC4 cipher suite. However, Rizzo said that defense won't work against their new attack, which they've dubbed CRIME. The researchers plan to present their findings at the Ekoparty conference in Argentina later this month and are not revealing exactly which feature of SSL/TLS is providing the information leak, but they said that the new attack works much like the BEAST attack. Once they have a man-in-the-middle position on a given network, they can sniff HTTPS traffic and launch the attack. "By running JavaScript code in the browser of the victim and sniffing HTTPS traffic, we can decrypt session cookies. We don't need to use any browser plug-in and we use JavaScript to make the attack faster but in theory we could do it with static HTML," Rizzo said. Right now, Rizzo said, both Mozilla Firefox and Google Chrome are vulnerable to the attack. However, the researchers said that the browser vendors have developed patches for the problem that will be released in the next few weeks. "We need to load JavaScript code into the victim's browser and sniff the HTTPS traffic. All SSL/TLS versions including TLS 1.2 are affected if the implementation supports the feature that we abuse to leak information about the encrypted data," Rizzo said. "The cipher-suite being used doesn't matter, a workaround for BEAST was switching from AES to RC4 but for CRIME this is not important. The feature must be supported by the client and the server." Rizzo said that the specific feature in TLS that he and Duong are using in this attack has not been a major subject of security research in the past. "The risk of implementing the feature has been superficially discussed before. However we haven't found previous research showing how efficient an attack could be or any attempt by the authors of secure protocols to avoid the problem," he said. Although the CRIME attack can use JavaScript, it's not required. Rizzo said that it really shouldn't be possible to hijack a user's session with one site just by loading JavaScript into the victim's browser from a separate site. But that's exactly what the new attack allows him to do. In addition to their work developing the BEAST attack, Rizzo and Duong in 2011 also developed a padding oracle attack on Microsoft's ASP.NET that affected millions of applications and forced the software giant to issue an emergency patch. Sursa: New Attack Uses SSL/TLS Information Leak to Hijack HTTPS Sessions | threatpost

Mai veniti cu idei, mai multe variante de banner, diseara punem la vot si il alegem.